* Albert Cervera i Areny: " Re: [tryton] Changing maturity dates" (Thu, 24 Apr 2014 09:35:21 +0200):
> 2014-04-23 11:28 GMT+02:00 Mathias Behrle <[email protected]>: > > * Albert Cervera i Areny: " Re: [tryton] Changing maturity dates" (Wed, 23 > > Apr 2014 02:08:46 +0200): > > > > [...] > > > >> Not a matter of a mistake but renegotiation of due date after invoice > >> is sent, typically because the customer simply did not pay. > > > > Hi Albert, > > > > just a question: if you don't want to take legal steps, but keep the > > original legal state, wouldn't it be better to adapt the dunning term in > > this case? Seems to me the correct layer to handle such a problem. Because > > this is, what really changed. You resign to take the legal steps, but they > > are existent nevertheless. > > It might be, but I thought that at move line was simpler. Let me put > an example and let's forget by now about changing get_lines_to_pay() > from account.invoice. Thanks for the explanation, I now understand better. > Let's say we have an invoice that once confirmed creates a maturity > date for April 1st. So we apply the dunning procedure assigned to the > party (which let's say that sends a reminder every 5 days) and on > April 5th we send him an e-mail reminding about the payment. He then > answers to us saying that he's having some temporary financing issues > but promises to pay 50% on 20th and the rest on 30th. > > Ideally we'd want here is: > - The dunning process do not annoy us on 10th, 15th and 20th: > Currently we should manage that manually. > - The dunning process should be activated if we do not receive the > payment on the 20th for 50% or if we do not receive the 50% on the > 30th. > - The payments forecast (which at least we take from > account.move.line) should show that information updated. > > So the idea was to create a move with 3 lines. The first one has 100% > on credit and is reconciled with the original line (so the system does > not continue the dunning process), the second one with 50% on debit > with maturity date April 20th and the third with 50% on debit with > maturity date April 30th. > > It is already possible to do this manually but the problem with this > is that the invoice will be shown as paid when it actually is not. Let me put in, what I know from german accounting. The rules in Germany say, that each business process (at least targeting money and taxes, and that is pretty much every process ;)) must be mirrored in accounting. A tax inspector must be able to read the situation of an enterprise at each moment. So with respect to the problem of this thread I am inclined to say, that if it is solved cleanly at accounting level, it should be ok. A clean solution from my POV would mean: - invalidating the original move of the invoice by cancelling it, giving the reason and pointing to the new move, you will create - creating a new move based on the new payment term (this is basically, what you agree to do with this customer), including the reason of the change and pointing to the old move Disadvantage: - this change is still undercocumented, because on the invoice saved in the database you still have the conditions of your original contract (i.e. the original payment term). While the latter isn't a show stopper for me, it is still ugly to have a divergence between original documents and accounting. Though it can be done the way you are proposing, I would still prefer to have a wizard creating a customized dunning term applicable for this very incident. Which meets more the facts: when resigning from *enforcing* the legal arrangement at that point, you probably don't want to resign from your claims, that were originally agreed upon. I see here a slight, but (may be) important difference: changing the moves will more likely be considered to change the legal basis of the business process. I suppose, that this is not the desired result. > So > I proposed to change get_lines_to_pay() basically to get that > functionality. A short glance at the code shows, that move lines are sorted by maturity date. Is the result from [1] still different? [1] https://bitbucket.org/trytonspain/trytond-account_payment_type_move/src/8907116e20def8f5d7515a1515916378cb782167/account.py?at=default#cl-91 -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://m9s.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
signature.asc
Description: PGP signature
