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.

> Also you can choose the date of the invoice.

Not really because there must be a correlation between dates and
invoice numbers...

>
>> 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/



-- 
Albert Cervera i Areny
Tel. 93 553 18 03
@albertnan
www.NaN-tic.com

Reply via email to