2014-04-23 8:51 GMT+02:00 Cédric Krier <[email protected]>: > On 23 Apr 02:08, Albert Cervera i Areny wrote: >> 2014-04-23 1:02 GMT+02:00 Cédric Krier <[email protected]>: >> > On 23 Apr 00:11, Albert Cervera i Areny wrote: >> >> 2014-04-22 20:00 GMT+02:00 Cédric Krier <[email protected]>: >> >> > On 20 Apr 10:58, Albert Cervera i Areny wrote: >> >> >> I'm thinking of creating a wizard for updating maturity dates of >> >> >> payment lines. In some cases allowing to update maturity date when the >> >> >> account move is confirmed would be enough but in other cases it is >> >> >> necessary to split one maturity date into several ones. >> >> >> >> >> >> So the idea is just to create a wizard to help the user create a new >> >> >> account move that would work like this: >> >> >> >> >> >> - The user selects one or several move lines (all of them must have >> >> >> the same account, party and origin) >> >> >> - User executes the new action "Change payment dates/amounts" >> >> >> - A wizard is shown with the total debit, credit and balance to be >> >> >> split (or joined) and One2Many field with: >> >> >> - Description >> >> >> - Maturity date >> >> >> - Debit >> >> >> - Credit >> >> >> - Once the "Ok" button is pushed the wizard ensures that sum(Debit - >> >> >> Credit) is equal to the balance field. >> >> >> - Then, it creates a move with one line equal to the total balance and >> >> >> reconciles selected entries with this move line. The move also >> >> >> contains each of the lines the user introduced in the wizard. Move >> >> >> lines would have the appropriate "Origin" pointing to the >> >> >> corresponding Invoice. >> >> >> - Joining and splitting lines would take into account invoices so it >> >> >> would not be possible to join if two invoices are involved. At the >> >> >> same time, this means that it can be used for partial reconciliation. >> >> >> >> >> >> get_lines_to_pay() from account_invoice module should be changed so >> >> >> that it looks like [1] (move lines should be sorted by maturity date). >> >> >> >> >> >> For me, such wizard should be part of "account" module because >> >> >> although the user can do most of this manually, a) it is cumbersome >> >> >> and b) he would not get the desired result in the invoice because it >> >> >> currently only looks for move lines of the account move created by the >> >> >> invoice. That is, the invoice would look like paid while it is not. >> >> >> >> >> >> Anybody else sees it is an interesting addition to core modules? >> >> > >> >> > I don't agree. An invoice is a contract which defines among other things >> >> > payment terms. So you can not change it without prior agreement of both >> >> > parties. In this case of agreement, the proper way to deal with such >> >> > changes is to credit/cancel the current invoice and make a new one. >> >> > In case of manual account move, it should not be posted until it is sure >> >> > to be right. >> >> >> >> That would not be a good policy in Spain because there are some legal >> >> terms for when you can start legal actions if an invoice has not been >> >> paid, and that starts counting from the time the invoice had to be >> >> paid. So making a credit note and sending the invoice again is like >> >> admitting the invoice was wrong and the "time counter" starts over >> >> again. >> > >> > Yes and so what. >> > You make mistake you pay for it. >> >> Not a matter of a mistake but renegotiation of due date after invoice >> is sent, typically because the customer simply did not pay. > > WTF! In such case, I will never pay any of your invoices. > >> > Also you can choose the date of the invoice. >> >> Not really because there must be a correlation between dates and >> invoice numbers... > > All those arguments sound completly absurd to me because you complain > about legal stuff about invoice date but you don't care about prior > agrements which are set in the original the invoice.
I understand it can sound absurd but those are daily tasks in companies in Spain. And the way of working with invoices and payments has been asked to lawyers and accountants here. And also, all applications in Spain manage this kind of stuff and we badly need that functionality here. The question was more about if that was a general or "local" need, and I guess it is the latter (in fact, AFAIK that functionality was added to Dynamics specifically for Spain so no surprises here). -- Albert Cervera i Areny Tel. 93 553 18 03 @albertnan www.NaN-tic.com
