On 07/06/13 23:58 +0200, Albert Cervera i Areny wrote: > A Divendres 07 Juny 2013 19:22:51, Cédric Krier va escriure: > > On 07/06/13 15:16 +0000, [email protected] wrote: > > > Please review this at http://codereview.tryton.org/923002/ > > > > > > Affected files: > > > M PaymentOrder.wiki > > > > I think this is a more flexible and simple design for payment. > > Especially because it deals with a one to one relation between > > accounting lines and payment instead of grouping lines. > > Also it takes care of the succes or not of the payment, and in some way > > it will allow to have a kind of forecast about liquidity in the future. > > > > I think I sum up all the comments, please tell me if not. > > Some comments: > - In Spain we would eventually need a document that groups payments together. > That document is named "Remesa" in Spain and is needed in some cases when for > some special payment types it has to be printed together and it needs a > reference number, date, etc.
That's part of the sending process. > It is also interesting to ease bank > reconciliation because the bank may print a single statement line for a bunch > of bank transfers. This looks weird if user did not ask for it. But anyway, this is still part of the sending process. I guess in the furture there will be modules that generate clearing move(s). > - If I understand it correctly, one example of a 'account.payment' would be > writing a cheque. What happens if a user writes a single cheque to pay two or > three invoices? Don't. > I mean, is the goal of account.payment match real-world > payment documents? Here, we design a workflow. And when you think about it, it becomes a mess if you don't clearly link one payment to one "invoice". But of course you could still have a sending process that groups payment and print 1 check. -- Cédric Krier B2CK SPRL Rue de Rotterdam, 4 4000 Liège Belgium Tel: +32 472 54 46 59 Email/Jabber: [email protected] Website: http://www.b2ck.com/
pgpucBTqrKw_l.pgp
Description: PGP signature
