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

[Thomas Baumgart]

Hi guys (did not spot any gals yet),

on Wednesday 25 May 2011 Klaas Freitag wrote:



> Am Mittwoch 25 Mai 2011, 07:33:03 schrieb Thomas Baumgart:
> Hi,
> 
> thanks, Samir, for sharing :-)
> 
> > 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.
> 
> Thats true. The ID generator has to be in the DBus backend, as various apps
> could generate a transaction and still the ID needs to be unique. However,
> on the mobile device, there is no connection to the service on the bus,
> so the mobile entry can only be unique in the mobile device. So the data
> should contain a "local ID" (assigned in the mobile) and a 'really' global
> unique ID assigned by Alkimia at sync time. That, however, is only true if
> we want continous IDs. If not, we could create real unique ids if we
> combine for example the netcard MAC ID with a timestamp and calc an MD5
> from it. That results in a worldwide unique ID and can be done locally
> easily.

Sorry, but I have to object here. The source of the transaction (in this case 
the mobile device) *must* assign the unique ID. See 
http://linux.die.net/man/3/libuuid for example. Use existing stuff and don't 
reinvent the wheel.

The transaction is generated by the mobile app and later transfered to the 
desktop.

> > - 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.
> 
> Can these file formats also store the status such as "Money expected but
> not yet there" for example which are needed for example for the Kraft
> usecase (You remember: Invoice sent, money expected) ?

Why would I want to trigger such a transaction from a mobile device? It should 
be generated by the application that prints the invoice. During the last (or 
better first) finance sprint I tried to explain, that this status is handled 
by transaction towards a specific account. There is no need for such a flag.

> Sorry if I sound dumb to you, I am absolutely without knowledge in that
> space. Can one of you recommend a resource to learn the basics of
> "transactions" and stuff? Maybe we should set up a glossar to make clear
> what what is, or is that common knowledge?

A glossar is probably not enough - though helpful. And on top, we do have one 
on http://techbase.kde.org/Projects/KdeFinanceGlossary

We all need some basic understanding of accounting practices.  Maybe an idea 
to get together during akademy for it.

-- 

Regards

Thomas Baumgart

GPG-FP: E55E D592 F45F 116B 8429   4F99 9C59 DB40 B75D D3BA
-------------------------------------------------------------
The only 'intuitive' interface is the nipple. After that, it's all learned.
 -- Bruce Ediger, bediger at teal.csn.org, on X interfaces
-------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 224 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-finance-apps/attachments/20110525/1a6a7fa5/attachment.sig