Hi all.<br><br>I was wondering what fields I should take as input from the user in the mobile client software I am working on. The purpose is to let a user input a transaction he did with as few typing as possible, thereby recording just what is required. I would like to know which fields I must include, so that when I export the transactions to a xml, I can use the file to import it into any financial application. Such an import will adjust the accounts that will change due to the transaction. I would like to ensure the fact that I am taking enough information from the user to update these accounts.<br>
<br>These are the fields I have thought of:<br><ul><li>UId</li><li>transaction_description <br></li><li>additional_note <br></li><li>payment_mode (cash, credit card)<br></li><li>amount<br></li><li>datetime_of_transaction</li>
<li>transaction_type (change in expense, liability or asset)</li></ul><br><br><br><div class="gmail_quote">On Fri, May 27, 2011 at 1:25 AM, Guillaume DE BURE <span dir="ltr"><<a href="mailto:guillaume.debure@gmail.com">guillaume.debure@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Le mercredi 25 mai 2011 07:33:03, Thomas Baumgart a écrit :<br>
<div class="im">> Hi,<br>
><br>
> on Tuesday 24 May 2011 22:29:31 Alvaro Soliverez wrote:<br>
><br>
> > Forwarding to the finance apps mailing list so that others can review too.<br>
><br>
> Good idea. Samir, are you subscribed to the list?<br>
><br>
> The use case diagram and the accompanying description look good to me. Could<br>
> be extended in a second round to cover things like 'sync/load accounts from<br>
> app on PC' so that you don't have to enter data into the mobile app that is<br>
> already present on the PC.<br>
><br>
> A few things to keep in mind that ease later integration into any application:<br>
><br>
> - assign a unique ID to each transaction<br>
> this allows to transfer transactions from the mobile to the PC more than<br>
> once. The desktop applications can usually deal with duplicates if they only<br>
> find an ID.<br>
><br>
> - data transfer<br>
> using a known and already implemented file format would ease implementation<br>
> work on the desktop side. With the current understanding even QIF could do the<br>
> job (I know, we all hate it but this time we have the sending side under<br>
> control ;) ) and the software to create it is lightweighted. OFX seems to be<br>
> a bit of overhead since you need external libs (libOFX). Coming up with YAXF<br>
> (Yet Another Xfer Format) adds additional work on the application side. Maybe<br>
> the Skrooge logic to be moved into Alkimia could help here.<br>
<br>
</div>Agreed with everything here, and in the following mails (I answer to this specific one because of the last sentence).<br>
<br>
I will generate a scheme of the Skrooge datamodel: it is needed for this, but also for many other topics, like welcoming new contributors. Then we can discuss on what needs to be evolved for alkimia :)<br>
<div><div></div><div class="h5">_______________________________________________<br>
Kde-finance-apps mailing list<br>
<a href="mailto:Kde-finance-apps@kde.org">Kde-finance-apps@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-finance-apps" target="_blank">https://mail.kde.org/mailman/listinfo/kde-finance-apps</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>samir<br>{ <a href="http://www.incurlybraces.com" target="_blank">www.incurlybraces.com</a> }<br><br>