[Kde-finance-apps] Re: Fwd: Season of KDE status check

[samir]

Hi all.

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.

These are the fields I have thought of:

   - UId
   - transaction_description
   - additional_note
   - payment_mode (cash, credit card)
   - amount
   - datetime_of_transaction
   - transaction_type (change in expense, liability or asset)




On Fri, May 27, 2011 at 1:25 AM, Guillaume DE BURE <
guillaume.debure at gmail.com> wrote:

> Le mercredi 25 mai 2011 07:33:03, Thomas Baumgart a écrit :
> > Hi,
> >
> > on Tuesday 24 May 2011 22:29:31 Alvaro Soliverez wrote:
> >
> > > Forwarding to the finance apps mailing list so that others can review
> too.
> >
> > Good idea.  Samir, are you subscribed to the list?
> >
> > The use case diagram and the accompanying description look good to me.
> Could
> > be extended in a second round to cover things like 'sync/load accounts
> from
> > app on PC' so that you don't have to enter data into the mobile app that
> is
> > already present on the PC.
> >
> > A few things to keep in mind that ease later integration into any
> application:
> >
> > - assign a unique ID to each transaction
> >   this allows to transfer transactions from the mobile to the PC more
> than
> > once. The desktop applications can usually deal with duplicates if they
> only
> > find an ID.
> >
> > - data transfer
> >   using a known and already implemented file format would ease
> implementation
> > work on the desktop side. With the current understanding even QIF could
> do the
> > job (I know, we all hate it but this time we have the sending side under
> > control ;) ) and the software to create it is lightweighted.  OFX seems
> to be
> > a bit of overhead since you need external libs (libOFX).  Coming up with
> YAXF
> > (Yet Another Xfer Format) adds additional work on the application side.
> Maybe
> > the Skrooge logic to be moved into Alkimia could help here.
>
> Agreed with everything here, and in the following mails (I answer to this
> specific one because of the last sentence).
>
> 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 :)
> _______________________________________________
> Kde-finance-apps mailing list
> Kde-finance-apps at kde.org
> https://mail.kde.org/mailman/listinfo/kde-finance-apps
>



-- 
samir
{ www.incurlybraces.com }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-finance-apps/attachments/20110602/5a35094f/attachment.htm