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. Also you can choose the date of the invoice. > Keeping the original invoice legally shows that there was a breach of > contract by the customer. Yes original must be kept. -- Cédric Krier - B2CK SPRL Email/Jabber: [email protected] Tel: +32 472 54 46 59 Website: http://www.b2ck.com/
pgpulkTOPa0MF.pgp
Description: PGP signature
