Merge lp:~akretion-team/openobject-addons/better-progressive-invoicing into lp:openobject-addons
Status: | Rejected |
---|---|
Rejected by: | Fabien (Open ERP) |
Proposed branch: | lp:~akretion-team/openobject-addons/better-progressive-invoicing |
Merge into: | lp:openobject-addons |
Diff against target: |
31 lines (+11/-10) 1 file modified
sale/sale.py (+11/-10) |
To merge this branch: | bzr merge lp:~akretion-team/openobject-addons/better-progressive-invoicing |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
OpenERP Core Team | Pending | ||
Review via email: mp+86618@code.launchpad.net |
Description of the change
Hello
this merge proposal is the concrete result of 2 limitations we have seen in OpenERP:
1) In some countries, we may not mix everything on an invoice and use negative quantities. Take Brazil, service and product invoices need to be different records. If you sale both a service and a product, you will need to split the order in 2 invoices: one for service and an other one for products. A convenient way to generate 2 invoices is calling the sale.order#
This would almost work but the 2nd invoice would contain the lines of the 1st invoice with a negative value. We need a way to avoid this. Generating the invoice lines to delete them is really not a clean options as it would make OpenERP even more slower than it is already.
2) Take progressive invoicing of projects based on orders (you invoice ordered value by parts according to some progress estimation, it's common in civil engineering for instance), so you have the same need to partition order lines over several invoices. Again, the natural way to implement this is to call sale.order#
The simplest way I found to implement that is to have an option in the context, so that an overrider might skip that default advance invoice logic when calling super.
We used that in production for nearly a year now. Could you merge it in 6.1?
Unmerged revisions
- 6099. By Raphaël Valyi - http://www.akretion.com
-
[IMP] sale: add a way through which an overrider (like localization) can easily partition a sale order over several invoices WITHOUT having to use the default negative quantities which may not be very readable nor legal in some countries.
I don't think it's logic to introduce a context that is used but not defined in the sale module.
Is there any other solution ?