We're starting to work on the Spanish localization and one of the many things in the TODO list involves improvements to account.invoice.payment_term model. Let me list the required changes:
1) Add the possibility that the delay is calculated in months instead of days. So January 30th + 1 month = 28 February (instead of 2 of March if one specified 30 days) 2) Add the possibility of dividing instead of making a percentage. So if an invoice must have 3 payments we "Type" is set to "Division" and the value to "3". So the division is always correct (instead of having to write "33.3333333"). 3) Add the possibility of several payment days. In Spain, some companies only pay at day 15th of each month (or day 20th, or 30th, or whatever), but some of them have two payment days (15th and 30th of each month for example). For example: - A customer pays after 1 month at days 15th or 30th. - If we create an invoice on January 5th it will be paid on February 15th. - If we create an invoice on January 16th it will be paid on February 28th. The days in which a party pays should, ideally be stored on party.party, not account.invoice.payment_term. The reason is that the number of possibilities in payment terms explodes a lot with the payment day condition. The problem is that the function compute() in account.invoice.payment_term currently only accepts the payment term and, optionally, the date. Would it be possible to change the API too include the partner so compute's signature would look like this: def compute(self, amount, currency, payment_term, party, date=None): AFAIK whenever you need to calculate a payment term you will also have a partner available so I don't think it should be a problem. By the way, I do not intend to change core account_invoice module but only do the API change there, although maybe others may be interested in points 1) and 2) to be included in core. I think 3) is very Spanish specific. -- Albert Cervera i Areny http://www.NaN-tic.com OpenERP Partners Tel: +34 93 553 18 03 http://twitter.com/albertnan http://www.nan-tic.com/blog -- [email protected] mailing list
