A Dissabte 08 Juny 2013 03:31:48, Cédric Krier va escriure: > 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.
But in your design the account.payment.send wizard does not link all the payments together. > > > 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. -- Albert Cervera i Areny Consultor funcional Tel. 93 553 18 03 @albertnan www.NaN-tic.com Avís legal >>
