Alkimia is a general KDE based framework to share financial information across applications. The rational is to not duplicate financial functionality across applications but to let the applications focus on their specialized purpose.
In the center of the efforts is the benefit of the user. We want to provide a collection of well integrated financial applications from which the user can pick the apps she or he needs and want to use. We want to break the trend that every application has to implement all functionality which especially can be seen in commercial software of this kind.
The following list of use cases should give the reader an idea what Alkimia could provide to applications using it.
More and more actions that can be undertaken on a modern desktop like KDE require payment, for example KDE already provides applications with which the user can buy content, such as Amarok. The payment process is usually implemented in the specialized application. But as soon as the user has commited the transaction, Alkimia should be aware that money was payed and thus left one of the various accounts of the user.
That also works the other way round, for incoming payments:
The user sends out an invoice through Kraft. Kraft knows the amount of money that it expected to be payed by the receiver of the invoice. The date, amount and identifying number should show up in KMyMoney and Skrooge as expected payment and also can be booked as not yet received payment or scheduled transaction.
When the user pays in a shop he also logs the payment into a simple application on cellphone/PDA/notebook. When he arrives home he connects his cellphone using D-Bus subsystem and send those payments to kMyMoney/Skrooge.
A more technical description can be found in the Billing page.
As soon KMyMoney or Skrooge becomes aware of an incoming payment, either through online banking or manual entry, it should
a more technical description can be found on payment page
Alkimia is aware of expected payments and its due dates. If the date exceeds the framework should mark the transaction as overdue. All interested applications can pick the status up and inform the user about.
An calendar file is maintained with the current due dates which can be plugged into KOrganizer.
All contacts involved in the transactions should be maintained in KAddressbook. The KDE Finance Framework uses the Addressbook-UIDs to reference the entries.
All contacts involved in the transactions should be maintained in KAddressbook. Alkimia uses the Addressbook-UIDs to reference the entries whereever needed. The apps using Alkimi can make advanced use of the contacts.
Alkimia offers easily accessible interface to the general finance status of the user for all kinds of user apps.
Your current Financial Situation: Cash: -3,465 Euro on 4 Accounts Expected: 7,643 Euro within 7 days. last balanced today, 10:12 am
For Kraft and similar apps a lot depends on the document identifier. Currently it is generated by Kraft and stored in its database. That makes it hard to use other applications to create a document in the same number circle. Alkimia could provide a general number generator with different number formats and number circles, depending on the document type. Note: there are law requirements in some countries.
A plasmoid wants to show for example a stock overview of the users stocks. A central service downloads stock price information and notifies registered applications about changes.