Alkimia/Usecases

Alkimia Use Cases

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.

Money Flow

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.

Example:

Fred purchases the album of his favorite band in an online music store and pays 5,99$ for it. The commitment is done in Amarok. Next time Fred starts KMyMoney or Skrooge it notifies him that he did this payment and if he wants to put it on the right account.

That also works the other way round, for incoming payments:

Example:

In KMail, Anneliese receives email from EBay stating "Your fire red pumps were sold for 35,34 Euro." KMail automatically registers incoming but not yet received money in Alkimia.

Expected 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.

Mobile Billing System

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.

Payment Detection

As soon KMyMoney or Skrooge becomes aware of an incoming payment, either through online banking or manual entry, it should

1. try to detect an unique identifier
2. validate if there is an expected payment filed with this unique identifier
3. if so, let the user validate if the detection is correct (optional)
4. mark the payment to be received

Example:

Elena issues an invoice with Kraft over 364 Euro, due in 10 days. She marks the invoice to be sent in Kraft. In KMyMoney and Skrooge the amount of 364 Euro shows up as expected money together with the document id number, date and addressee of the invoice. Four days later, Elena checks the accounts via online banking. One transaction record contains the document id and the finance manager asks Elena if she can confirm that this is the money paying the invoice. She confirms that.\\Next time she starts Kraft she sees that the invoice is marked as payed.

a more technical description can be found on payment page

Dunning

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.

Contacts

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.

Finance Status

Alkimia offers easily accessible interface to the general finance status of the user for all kinds of user apps.

Example:

A plasmoid can present the current fincance status of the user, for example

Your current Financial Situation:
Cash: -3,465 Euro on 4 Accounts
Expected: 7,643 Euro within 7 days.
last balanced today, 10:12 am

Centralized Document ID Generation

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.

Example:

Evelyn usually uses Kraft to write invoices for her hat manufacturing. Today she would like to rather use KOffice to write a special invoice. In KOffice, she clicks on the menu item "Get Document ID". In the upcoming dialog, she picks "Invoice" and gets an identifying string (the next in the sequence of the number cycle) to be used as a document number. The number gets striked out and registered to be used by koffice, possible with a document save file name.

Central Stock Price Information

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.