On 24 Apr 09:35, Albert Cervera i Areny wrote: > 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. > > 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.
Not at all, just block the dunning. > - 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. That's a little bit tricky but you can at least unblock the dunning the 30th. > - The payments forecast (which at least we take from > account.move.line) should show that information updated. You are using the wrong tools. > 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. And then lost that the customer was in fault. > 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. So > I proposed to change get_lines_to_pay() basically to get that > functionality. It is wrong to change the accounting for that. The customer even after his promise still own you money for the first date. More over, it will be even a accounting fault if you do that over a fiscalyear or tax period. So I repeat this feature is wrong. Dunning do by default almost all the job but can be tunned (if it is really necessary) for the percentage case and a unblock date could be added. -- Cédric Krier - B2CK SPRL Email/Jabber: [email protected] Tel: +32 472 54 46 59 Website: http://www.b2ck.com/
pgpD1W31gjAiS.pgp
Description: PGP signature
