[Kde-finance-apps] Re: payment detection

Klaas Freitag freitag at kde.org
Sun Jun 5 20:49:49 CEST 2011


Am Sonntag, 5. Juni 2011, 14:33:22 schrieb Thomas Baumgart:

Good evening,

> > The invoice manager is not a different app right?
> > each finance manager has a built in invoice manager?
> 
> Hmm, not really. Currently, we see Kraft as the application issueing an
> invoice. There could be others that we don't know of.
Maybe the Lemon POS could make use of this kind of functionality?
> 
> In general, I think each (KDE) user has a selected (preferred if you wish)
> finance mangement tool in his/her environment. So I don't see the use case
> to have one application sending the notification about a generated invoice
> and just one that needs to receive it.  Why would I want to manage my
> finances using two different tools?
> 
> How would the workflow look like? Start e.g. Kraft, create an invoice,
> print it (either to PDF or paper) and then? What is next?
IMO: If the user in Kraft clicks: "This invoice is sent out to the customer."
it becomes kind of official, which means the payment is expected. (BTW, note
that the functionality to mark the invoice "official" is not yet implemented
in Kraft.)

After that Kraft will call the Alkimia DBus-Service API (see 
http://community.kde.org/Alkimia/dbus-service) to announce that the payment
is expected. The DBus-Service, if I understood Thomas correctly recently,
creates an transaction and puts it into a special account which has the 
meaning "Payment expected". Which account that is is in the domain of 
the finance managers and probably will be configured for the DBus Service
maybe in an Alkimia KDE Control Center module, which we would have to 
create later than. This API call should return the transaction number to 
allow Kraft to associate a document number with a transaction ID.

On Krafts startup, I would hope that the Alkimia API provides a call to 
receive the status certain transactions. That would give Kraft the 
possibility to query for the payment status of certain transactions.

Brainstorm for the existing Status: 
UNKNOWN - The transaction is not known
PAYMENT DUE - The payment is still expected
PAYMENT OVERDUE - The payment is expected and overdue
PAYED   - The money was received
more? Or is that a bad idea because it focusses to much on Kraft?

IMO we should let deal the Alkimia Service only with transactions, not 
with documents, customers and such. The association between the docs
and the transactions should be done in the client programs like Kraft.

Hope that was on topic ;-)

Klaas

 
> > On Sun, Jun 5, 2011 at 5:06 PM, Alvaro Soliverez <asoliverez at kde.org> 
wrote:
> > > On Sun, Jun 5, 2011 at 3:20 AM, puneet goyal <puneetgoyal08 at gmail.com>
> 
> wrote:
> > >> hello sir,
> > >> i was having a problem
> > >> wil the user have to update in every finance manager he/she uses, or
> > >> any one of them? and the rest gets updated themselves if the user
> > >> validates it any one of the finance manager?
> > > 
> > > As far as I can say, the user should choose to update manually from
> > > each finance manager.
> > > 
> > > Keep in mind that the payment originates in the finance manager. The
> > > invoice manager is the one that stores the document that explain the
> > > payment, and should be informed when the payment is made.
> > > 
> > > Others may disagree with me. Please always send the messages to the
> > > list. You may have more timely answers from the rest, as I'm in the
> > > furthest timezone from you.
> > > 
> > > Regards,
> > > Alvaro



More information about the Kde-finance-apps mailing list