Merge lp:~akretion-team/account-invoicing/70-add-invoice_fiscal_position_update into lp:~account-core-editors/account-invoicing/7.0
- 70-add-invoice_fiscal_position_update
- Merge into 7.0
Status: | Merged |
---|---|
Merged at revision: | 24 |
Proposed branch: | lp:~akretion-team/account-invoicing/70-add-invoice_fiscal_position_update |
Merge into: | lp:~account-core-editors/account-invoicing/7.0 |
Diff against target: |
324 lines (+293/-0) 6 files modified
invoice_fiscal_position_update/__init__.py (+23/-0) invoice_fiscal_position_update/__openerp__.py (+40/-0) invoice_fiscal_position_update/account_invoice.py (+103/-0) invoice_fiscal_position_update/account_invoice_view.xml (+28/-0) invoice_fiscal_position_update/i18n/fr.po (+51/-0) invoice_fiscal_position_update/i18n/invoice_fiscal_position_update.pot (+48/-0) |
To merge this branch: | bzr merge lp:~akretion-team/account-invoicing/70-add-invoice_fiscal_position_update |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Joël Grand-Guillaume @ camptocamp | code review, no tests | Approve | |
Graeme Gellatly | (code review, no test) | Approve | |
Ronald Portier (Therp) (community) | code review and test | Approve | |
Mathieu Vatel - Julius Network Solutions (community) | Approve | ||
Review via email: mp+200358@code.launchpad.net |
Commit message
Description of the change
Add the module invoice_
When the invoice is in draft state, you can change the fiscal position and click on a button "(update)" next to the fiscal position to update the taxes and the accounts on all the invoice lines.
Graeme Gellatly (gdgellatly) wrote : | # |
Ronald Portier (Therp) (rportier1962) wrote : | # |
Alexis,
Very well that when a user changes the fiscal position, there is the possibility to adapt the taxes and accounts.
Just wondering why the user should need to press a button. Should this not be an onchange action on the fiscal position?
As for the code itself it mostly seems good to me. Just two remarks:
1. Maybe better to avoid the line continuation with \ at #129 and #133 by using ( and )
2. The extremely long lines in the xml at #168 and #185 might be avoided by having each attribute on its own line.
So for the moment I abstain on this proposal.
- 25. By Alexis de Lattre
-
Take into accout the code style remarks of Ronald Portier.
Add info about the fact that the lines without a product are not updated in the module description and in the help message of the update button.
Alexis de Lattre (alexis-via) wrote : | # |
@Graeme
I agree with your remarks about the fact that a fiscal position is not dependant on a product. But, as you say, implementing it without relying on the product is not really possible, because if you already had a fiscal position and you change to another fiscal position, that you can't use the mapping of the new fiscal position to update the taxes and accounts.
One solution would be to raise an error message, which would block the executing and prevent all lines from being updated. The second solution would be to display a warning, but AFAIK, it is not possible on a function executed by a button unfortunately.
@Ronald
About the on_change vs the update button : I don't have a strong opinion on this. The original author of the module (Mathieu Vatel) implemented it via an update button and I kept this approach. If there is a consensus to use an on_change, then I'm OK to use an on_change.
Mathieu Vatel - Julius Network Solutions (mathieu-julius) wrote : | # |
Hi everybody,
For me, pressing a button is the better solution. Of course this can be done by only changing the fiscal position using an on_change.
The thing is, if you've got more than 100-200 lines to invoice, and you just change "accidentally" the fiscal position, this will run the change on all lines, and can take some time. This is a "security" for me.
I've first developed this module with a button to avoid errors done by new users and with many many lines inside the invoice (~500-1000 lines).
We can use the on_change method, I'm OK to use it. But I think this should avoid many errors using a button.
Otherwise, I totally approve this module migration ! Thank you Alexis !
Ronald Portier (Therp) (rportier1962) wrote : | # |
Thanks Alexis for updating the module.
As for the question button or on_change: I have always been amazed (and annoyed) at the need to press the update button in order to have your taxes computed.
Having the user needing to press a button carries the possibility that he/she will forget this. With not computing taxes this error is very obvious. But with the change in fiscal position, I think the odds that users once in a while forget this are very high.
If it ever happens that a user changes a fiscal position by accident (and saves the form before realising his/her mistake), just changing back the fiscal position will easily revert taxes and accounts. And yes with a few hundred lines this might take a moment. But what are the odds that AND an invoice will have > 200 lines AND the user will change the fiscal position by mistake?
Raphaël Valyi - http://www.akretion.com (rvalyi) wrote : | # |
@Ronald,
"But what are the odds that AND an invoice will have > 200 lines AND the user will change the fiscal position by mistake?"
In our experience it's extremely slow (likes minutes) because OpenERP will trigger one of these computed fields cross fire. It's not that bad if adding 100 lines manually is slow because anyway user interaction will be the limiting factor, now having some Ajax change triggering an action that takes minutes really sucks.
In a project here were we needed the ability to re-apply the pricelist for say 100 items, we hacked the orm write method with a context key to enable a batch write (yes that 6, 0 cryptic API) and trigger the computed fields only at the very end.
Here is that patch for 6.1 https:/
We are migrating that customer to v7, do you think it makes sense to extract this patch and submit it to OCB or as a module?
In our case, with the Brazilian localization which adds up tons of complex stored fields, we could improve the speed from 20 minutes to 20 seconds with that patch.
Thoughts?
Raphaël Valyi - http://www.akretion.com (rvalyi) wrote : | # |
@Ronald,
on a later though, yes, recomputing invoice lines is certainly slow with the computed field chains as I just mentioned (write on lines recomputing invoice values which depends itself of the lines values, exploding exponentially) and the patch I presented can certainly help as it did in our case when it's too slow. But in fact, on the contrary doing it in an on_change shouldn't recompute the computed fields before saving, so unlike to what I said, doing it is an on_change is unlikely to make things any slower. So sorry, my objection was wrong.
Ronald Portier (Therp) (rportier1962) wrote : | # |
@Raphael,
Glad you don't see any extra problems with the on_change choice.
Even though not directly related to the problem at hand - I would be interested to know more about how you are using your code as is shown on github. Maybe there is some module or code that shows me how to use it?
@Others,
Any thoughts pro/contra button/on_change? Maybe I see it completely wrong?
Graeme Gellatly (gdgellatly) wrote : | # |
on_change
pros:
can add warning for non product lines
manages every use case except where maybe a fiscal position needs to be different on different lines (only one I can think is items shipped to 2 different locations with different tax regimes).
cons:
wastes user time if changes in error.
button:
cons:
can't add warning although can add confirmation dialogue but not in as much detail.
pros:
gives user full control on whether to update existing (also a con as Ronald points out)
faster - as there is no onscreen change, then write, then screen refresh
on balance I would slightly favour the onchange, simply because the button gives more room for error and unexpected behaviour for the user, one less thing for user to think about ond one less thing on screen. Besides I imagine after waiting a few minutes for an erroneous change that user behaviour would be reinforced.
But I am also fine with how it is.
- 26. By Alexis de Lattre
-
Move from the "button" approch to the on_change approch.
Alexis de Lattre (alexis-via) wrote : | # |
Thanks for all these comments !
I have started to implement the on_change approch, cf the code in this branch :
lp:~akretion-team/account-invoicing/70-invoice_fiscal_position_update-onchange
But, during the implementation, I have been confronted to the following problem :
In the code of the fiscal_
1) edit an invoice with fiscal position A
2) add an invoice line with product HDD1
3) change the fiscal position to B
4) click on "save"
=> the invoice line with product HDD1 will not be updated, because it is not "created" in the DB at the time of the execution of the on_change. The solution for this is to update the taxes and account via the 'value' key of the dict that is returned by the on_change, but I don't know if it's possible in OpenERP 7 to update the field of the invoice_lines (one2many) via an on_change of a field that belong to the invoice.
If this is possible in OpenERP 7, please explain me how to implement it and I will do it.
If this is not possible in OpenERP 7, I think it gives a significant advantage to the "button" approach.
Graeme Gellatly (gdgellatly) wrote : | # |
Hi Alexis,
It is, there is an ORM function self.resolve_
takes a field name and the argument that was passed (generally these
are the same, one a string, one a variable, but sometimes ids might be
appended to one and not the other). From there you can perform the
change to the lines without writing returning in value dict.
On Sat, Jan 4, 2014 at 11:38 AM, Alexis de Lattre <email address hidden> wrote:
> Thanks for all these comments !
>
> I have started to implement the on_change approch, cf the code in this branch :
>
> lp:~akretion-team/account-invoicing/70-invoice_fiscal_position_update-onchange
>
> But, during the implementation, I have been confronted to the following problem :
>
> In the code of the fiscal_
>
> 1) edit an invoice with fiscal position A
> 2) add an invoice line with product HDD1
> 3) change the fiscal position to B
> 4) click on "save"
>
> => the invoice line with product HDD1 will not be updated, because it is not "created" in the DB at the time of the execution of the on_change. The solution for this is to update the taxes and account via the 'value' key of the dict that is returned by the on_change, but I don't know if it's possible in OpenERP 7 to update the field of the invoice_lines (one2many) via an on_change of a field that belong to the invoice.
>
> If this is possible in OpenERP 7, please explain me how to implement it and I will do it.
>
> If this is not possible in OpenERP 7, I think it gives a significant advantage to the "button" approach.
> --
> https:/
> You are reviewing the proposed merge of lp:~akretion-team/account-invoicing/70-add-invoice_fiscal_position_update into lp:account-invoicing.
- 27. By Alexis de Lattre
-
Starting to use the ORM method resolve_
2many_commands as indicated by Graeme Gellatly.
Alexis de Lattre (alexis-via) wrote : | # |
@Graeme
Thanks for pointing me to resolve_
The current code is here : https:/
- 28. By Alexis de Lattre
-
It now works well with the on_change !
Update POT file and FR translation.
Alexis de Lattre (alexis-via) wrote : | # |
Dear OpenERP community friends,
Here it is, I manage to make the "on_change" solution work, thanks to the function "resolve_
It's quite a big change in the code and it's the first time that I use the function "resolve_
Enjoy,
Alexis
Ronald Portier (Therp) (rportier1962) wrote : | # |
Hello,
Good to know a function like resolve_
I tested the module and found it to work perfectly.
I checked:
- entering an invoice with a line, saving it and then changing the fiscal position
- change it back again
- add another invoice line, NOT save it and change the fiscal position
- then save it and change it back again
- and then some variations with and withouth pressing update on taxes in between.
- add an invoice line withouth a product. Changed the fiscal position. Got the warning that was expected.
Code also looks very nice.
Graeme Gellatly (gdgellatly) wrote : | # |
Hi,
Glad it worked for you.
I think this might be being a bit careful
+ # Reformat iline_dict so as to be compatible with what is
127 + # accepted in res['value']
128 + for key, value in line.items():
129 + if isinstance(value, tuple) and len(value) == 2:
130 + if (isinstance(
131 + and isinstance(
132 + line[key] = value[0]
You should only get a tuple if it matches those conditions anyway. Well I suppose it might be possible to get a long in pos[0], but then you would want that anyway. But the main point here is to prefer iteritems() rather than items(). Mainly for the memory.
also consider one more change to the warning if len(lines_
But both very minor so reapprove..
- 29. By Alexis de Lattre
-
use iteritems() instead of items()
- 30. By Alexis de Lattre
-
[FIX] Make it work when ids = [] i.e. when the invoice was never saved.
Adapt the error msg when 0 lines have products, as suggested by Graeme Gellatly on the MP.
Update translation template and FR translation. - 31. By Alexis de Lattre
-
Simplify reformatting of iline_dict as suggest by Graeme on the MP.
Alexis de Lattre (alexis-via) wrote : | # |
All remarks on the MP have been taken into account.
I have fixed a severe bug that I found during some new tests when changing the FP on an invoice that has never been saved (XML has been modified, you should do -u invoice_
So it should be ready to merge now.
I'll start working on sale_fiscal_
- 32. By Alexis de Lattre
-
Better FR translation.
Update variable name, for easier porting to sale/purchase.
Alexis de Lattre (alexis-via) wrote : | # |
Here is the module sale_fiscal_
https:/
It is independent from the module invoice_
Alexis de Lattre (alexis-via) wrote : | # |
Just a quick note about what I discovered while trying to backport the module to OpenERP 6.1 : the ORM function resolve_
But, unfortunately, when trying to use it, I often get :
File "/home/
"Only CREATE, UPDATE and LINK_TO commands are supported in resolver"
When you look at the code of this function in openerp 6.1 in openerp/osv/orm.py, you see that it only handles commands 0, 1 and 4 ; whereas the same code in OpenERP 7.0 handles 0, 1, 2, 3, 4, 5 and 6.
During my tests, I got a command "6", so I hit the assert and it crashes.
So, if you don't have a better idea, a backport to OpenERP 6.1 of this module would probably use the "update" button approach.
Graeme Gellatly (gdgellatly) wrote : | # |
The way I discovered this function was when reviewing account_voucher
code in 6.1 which manually implemented the resolve_2many functionality
but in 7.0 did not.
My better idea would be to cut and paste the v7 command, either using
an osv.orm.
function (i.e. make it an ORM method) or just making it an
account.invoice method and see if it works. I would be surprised if
it didn't just work for you with a straight cut and paste. Failing
that - revert to "update" approach, but it is not a major if you don't
want to.
On Wed, Jan 8, 2014 at 12:39 PM, Alexis de Lattre <email address hidden> wrote:
> Just a quick note about what I discovered while trying to backport the module to OpenERP 6.1 : the ORM function resolve_
>
> But, unfortunately, when trying to use it, I often get :
>
> File "/home/
> "Only CREATE, UPDATE and LINK_TO commands are supported in resolver"
>
> When you look at the code of this function in openerp 6.1 in openerp/osv/orm.py, you see that it only handles commands 0, 1 and 4 ; whereas the same code in OpenERP 7.0 handles 0, 1, 2, 3, 4, 5 and 6.
>
> During my tests, I got a command "6", so I hit the assert and it crashes.
>
> So, if you don't have a better idea, a backport to OpenERP 6.1 of this module would probably use the "update" button approach.
> --
> https:/
> You are reviewing the proposed merge of lp:~akretion-team/account-invoicing/70-add-invoice_fiscal_position_update into lp:account-invoicing.
Alexis de Lattre (alexis-via) wrote : | # |
By the way, here is the module purchase_
We now have the full set for OpenERP 7 : sale + purchase + invoice
Joël Grand-Guillaume @ camptocamp (jgrandguillaume-c2c) wrote : | # |
Hi Alexis,
Thanks you very much for this module. LGTM !
Regards,
Joël
Preview Diff
1 | === added directory 'invoice_fiscal_position_update' |
2 | === added file 'invoice_fiscal_position_update/__init__.py' |
3 | --- invoice_fiscal_position_update/__init__.py 1970-01-01 00:00:00 +0000 |
4 | +++ invoice_fiscal_position_update/__init__.py 2014-01-06 23:25:40 +0000 |
5 | @@ -0,0 +1,23 @@ |
6 | +# -*- coding: utf-8 -*- |
7 | +############################################################################## |
8 | +# |
9 | +# Invoice Fiscal Position Update module for OpenERP |
10 | +# Copyright (C) 2011-2014 Julius Network Solutions SARL <contact@julius.fr> |
11 | +# Copyright (C) 2014 Akretion (http://www.akretion.com) |
12 | +# |
13 | +# This program is free software: you can redistribute it and/or modify |
14 | +# it under the terms of the GNU Affero General Public License as |
15 | +# published by the Free Software Foundation, either version 3 of the |
16 | +# License, or (at your option) any later version. |
17 | +# |
18 | +# This program is distributed in the hope that it will be useful, |
19 | +# but WITHOUT ANY WARRANTY; without even the implied warranty of |
20 | +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the |
21 | +# GNU Affero General Public License for more details. |
22 | +# |
23 | +# You should have received a copy of the GNU Affero General Public License |
24 | +# along with this program. If not, see <http://www.gnu.org/licenses/>. |
25 | +# |
26 | +############################################################################## |
27 | + |
28 | +from . import account_invoice |
29 | |
30 | === added file 'invoice_fiscal_position_update/__openerp__.py' |
31 | --- invoice_fiscal_position_update/__openerp__.py 1970-01-01 00:00:00 +0000 |
32 | +++ invoice_fiscal_position_update/__openerp__.py 2014-01-06 23:25:40 +0000 |
33 | @@ -0,0 +1,40 @@ |
34 | +# -*- coding: utf-8 -*- |
35 | +############################################################################## |
36 | +# |
37 | +# Invoice Fiscal Position Update module for OpenERP |
38 | +# Copyright (C) 2011-2014 Julius Network Solutions SARL <contact@julius.fr> |
39 | +# Copyright (C) 2014 Akretion (http://www.akretion.com) |
40 | +# |
41 | +# This program is free software: you can redistribute it and/or modify |
42 | +# it under the terms of the GNU Affero General Public License as |
43 | +# published by the Free Software Foundation, either version 3 of the |
44 | +# License, or (at your option) any later version. |
45 | +# |
46 | +# This program is distributed in the hope that it will be useful, |
47 | +# but WITHOUT ANY WARRANTY; without even the implied warranty of |
48 | +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the |
49 | +# GNU Affero General Public License for more details. |
50 | +# |
51 | +# You should have received a copy of the GNU Affero General Public License |
52 | +# along with this program. If not, see <http://www.gnu.org/licenses/>. |
53 | +# |
54 | +############################################################################## |
55 | + |
56 | +{ |
57 | + 'name': 'Invoice Fiscal Position Update', |
58 | + 'version': '1.0', |
59 | + 'category': 'Accounting & Finance', |
60 | + 'license': 'AGPL-3', |
61 | + 'summary': 'Changing the fiscal position of an invoice will auto-update invoice lines', |
62 | + 'description': """ |
63 | +Invoice Fiscal Position Update |
64 | +============================== |
65 | + |
66 | +With this module, when a user changes the fiscal position of an invoice, the taxes and the accounts on all the invoice lines which have a product are automatically updated. The invoice lines without a product are not updated and a warning is displayed to the user in this case. |
67 | +""", |
68 | + 'author': 'Julius Network Solutions, Akretion', |
69 | + 'depends': ['account'], |
70 | + 'data': ['account_invoice_view.xml'], |
71 | + 'installable': True, |
72 | + 'active': False, |
73 | +} |
74 | |
75 | === added file 'invoice_fiscal_position_update/account_invoice.py' |
76 | --- invoice_fiscal_position_update/account_invoice.py 1970-01-01 00:00:00 +0000 |
77 | +++ invoice_fiscal_position_update/account_invoice.py 2014-01-06 23:25:40 +0000 |
78 | @@ -0,0 +1,103 @@ |
79 | +# -*- coding: utf-8 -*- |
80 | +############################################################################# |
81 | +# |
82 | +# Invoice Fiscal Position Update module for OpenERP |
83 | +# Copyright (C) 2011-2014 Julius Network Solutions SARL <contact@julius.fr> |
84 | +# Copyright (C) 2014 Akretion (http://www.akretion.com) |
85 | +# @author Mathieu Vatel <mathieu _at_ julius.fr> |
86 | +# @author Alexis de Lattre <alexis.delattre@akretion.com> |
87 | +# |
88 | +# This program is free software: you can redistribute it and/or modify |
89 | +# it under the terms of the GNU Affero General Public License as |
90 | +# published by the Free Software Foundation, either version 3 of the |
91 | +# License, or (at your option) any later version. |
92 | +# |
93 | +# This program is distributed in the hope that it will be useful, |
94 | +# but WITHOUT ANY WARRANTY; without even the implied warranty of |
95 | +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the |
96 | +# GNU Affero General Public License for more details. |
97 | +# |
98 | +# You should have received a copy of the GNU Affero General Public License |
99 | +# along with this program. If not, see <http://www.gnu.org/licenses/>. |
100 | +# |
101 | +############################################################################## |
102 | + |
103 | +from openerp.osv import orm |
104 | +from openerp.tools.translate import _ |
105 | + |
106 | + |
107 | +class account_invoice(orm.Model): |
108 | + _inherit = "account.invoice" |
109 | + |
110 | + def fiscal_position_change( |
111 | + self, cr, uid, ids, fiscal_position, type, invoice_line, |
112 | + context=None): |
113 | + '''Function executed by the on_change on the fiscal_position field |
114 | + of invoice ; it updates taxes and accounts on all invoice lines''' |
115 | + assert len(ids) in (0, 1), 'One ID max' |
116 | + fp_obj = self.pool['account.fiscal.position'] |
117 | + res = {} |
118 | + line_dict = self.resolve_2many_commands( |
119 | + cr, uid, 'invoice_line', invoice_line, context=context) |
120 | + lines_without_product = [] |
121 | + if fiscal_position: |
122 | + fp = fp_obj.browse(cr, uid, fiscal_position, context=context) |
123 | + else: |
124 | + fp = False |
125 | + for line in line_dict: |
126 | + # Reformat line_dict so as to be compatible with what is |
127 | + # accepted in res['value'] |
128 | + for key, value in line.iteritems(): |
129 | + if isinstance(value, tuple) and len(value) == 2: |
130 | + line[key] = value[0] |
131 | + if line.get('product_id'): |
132 | + product = self.pool['product.product'].browse( |
133 | + cr, uid, line.get('product_id'), context=context) |
134 | + if type in ('out_invoice', 'out_refund'): |
135 | + account_id = ( |
136 | + product.property_account_income.id or |
137 | + product.categ_id.property_account_income_categ.id) |
138 | + taxes = product.taxes_id |
139 | + else: |
140 | + account_id = ( |
141 | + product.property_account_expense.id or |
142 | + product.categ_id.property_account_expense_categ.id) |
143 | + taxes = product.supplier_taxes_id |
144 | + taxes = taxes or ( |
145 | + account_id |
146 | + and self.pool['account.account'].browse( |
147 | + cr, uid, account_id, context=context).tax_ids |
148 | + or False) |
149 | + account_id = fp_obj.map_account( |
150 | + cr, uid, fp, account_id, context=context) |
151 | + tax_ids = fp_obj.map_tax( |
152 | + cr, uid, fp, taxes, context=context) |
153 | + |
154 | + line.update({ |
155 | + 'invoice_line_tax_id': [(6, 0, tax_ids)], |
156 | + 'account_id': account_id, |
157 | + }) |
158 | + else: |
159 | + lines_without_product.append(line.get('name')) |
160 | + res['value'] = {} |
161 | + res['value']['invoice_line'] = line_dict |
162 | + |
163 | + if lines_without_product: |
164 | + res['warning'] = {'title': _('Warning')} |
165 | + if len(lines_without_product) == len(line_dict): |
166 | + res['warning']['message'] = _( |
167 | + "The invoice lines were not updated to the new " |
168 | + "Fiscal Position because they don't have products.\n" |
169 | + "You should update the Account and the Taxes of each " |
170 | + "invoice line manually.") |
171 | + else: |
172 | + display_line_names = '' |
173 | + for name in lines_without_product: |
174 | + display_line_names += "- %s\n" % name |
175 | + res['warning']['message'] = _( |
176 | + "The following invoice lines were not updated " |
177 | + "to the new Fiscal Position because they don't have a " |
178 | + "Product:\n %s\nYou should update the Account and the " |
179 | + "Taxes of these invoice lines manually." |
180 | + ) % display_line_names, |
181 | + return res |
182 | |
183 | === added file 'invoice_fiscal_position_update/account_invoice_view.xml' |
184 | --- invoice_fiscal_position_update/account_invoice_view.xml 1970-01-01 00:00:00 +0000 |
185 | +++ invoice_fiscal_position_update/account_invoice_view.xml 2014-01-06 23:25:40 +0000 |
186 | @@ -0,0 +1,28 @@ |
187 | +<?xml version="1.0" encoding="utf-8"?> |
188 | +<openerp> |
189 | +<data> |
190 | + |
191 | +<record id="invoice_form" model="ir.ui.view"> |
192 | + <field name="name">fiscal.position.update.invoice.form</field> |
193 | + <field name="model">account.invoice</field> |
194 | + <field name="inherit_id" ref="account.invoice_form"/> |
195 | + <field name="arch" type="xml"> |
196 | + <field name="fiscal_position" position="attributes"> |
197 | + <attribute name="on_change">fiscal_position_change(fiscal_position, type, invoice_line, context)</attribute> |
198 | + </field> |
199 | + </field> |
200 | +</record> |
201 | + |
202 | +<record id="invoice_supplier_form" model="ir.ui.view"> |
203 | + <field name="name">fiscal.position.update.invoice.supplier.form</field> |
204 | + <field name="model">account.invoice</field> |
205 | + <field name="inherit_id" ref="account.invoice_supplier_form"/> |
206 | + <field name="arch" type="xml"> |
207 | + <field name="fiscal_position" position="attributes"> |
208 | + <attribute name="on_change">fiscal_position_change(fiscal_position, type, invoice_line, context)</attribute> |
209 | + </field> |
210 | + </field> |
211 | +</record> |
212 | + |
213 | +</data> |
214 | +</openerp> |
215 | |
216 | === added directory 'invoice_fiscal_position_update/i18n' |
217 | === added file 'invoice_fiscal_position_update/i18n/fr.po' |
218 | --- invoice_fiscal_position_update/i18n/fr.po 1970-01-01 00:00:00 +0000 |
219 | +++ invoice_fiscal_position_update/i18n/fr.po 2014-01-06 23:25:40 +0000 |
220 | @@ -0,0 +1,51 @@ |
221 | +# Translation of OpenERP Server. |
222 | +# This file contains the translation of the following modules: |
223 | +# * invoice_fiscal_position_update |
224 | +# |
225 | +msgid "" |
226 | +msgstr "" |
227 | +"Project-Id-Version: OpenERP Server 7.0\n" |
228 | +"Report-Msgid-Bugs-To: \n" |
229 | +"POT-Creation-Date: 2014-01-06 22:34+0000\n" |
230 | +"PO-Revision-Date: 2014-01-06 22:34+0000\n" |
231 | +"Last-Translator: <>\n" |
232 | +"Language-Team: \n" |
233 | +"MIME-Version: 1.0\n" |
234 | +"Content-Type: text/plain; charset=UTF-8\n" |
235 | +"Content-Transfer-Encoding: \n" |
236 | +"Plural-Forms: \n" |
237 | + |
238 | +#. module: invoice_fiscal_position_update |
239 | +#: view:account.invoice:0 |
240 | +msgid "fiscal_position_change(fiscal_position, type, invoice_line, context)" |
241 | +msgstr "fiscal_position_change(fiscal_position, type, invoice_line, context)" |
242 | + |
243 | +#. module: invoice_fiscal_position_update |
244 | +#: code:addons/invoice_fiscal_position_update/account_invoice.py:88 |
245 | +#, python-format |
246 | +msgid "Warning" |
247 | +msgstr "Avertissement" |
248 | + |
249 | +#. module: invoice_fiscal_position_update |
250 | +#: code:addons/invoice_fiscal_position_update/account_invoice.py:99 |
251 | +#, python-format |
252 | +msgid "The following invoice lines were not updated to the new Fiscal Position because they don't have a Product:\n" |
253 | +" %s\n" |
254 | +"You should update the Account and the Taxes of these invoice lines manually." |
255 | +msgstr "Les lignes de facture suivantes n'ont pas été mise-à-jour suite au changement de la position fiscale car elle ne contiennent pas de produit :\n" |
256 | +" %s\n" |
257 | +"Vous devez mettre à jour manuellement le compte comptable et les taxes de ces lignes de facture." |
258 | + |
259 | +#. module: invoice_fiscal_position_update |
260 | +#: model:ir.model,name:invoice_fiscal_position_update.model_account_invoice |
261 | +msgid "Invoice" |
262 | +msgstr "Facture" |
263 | + |
264 | +#. module: invoice_fiscal_position_update |
265 | +#: code:addons/invoice_fiscal_position_update/account_invoice.py:90 |
266 | +#, python-format |
267 | +msgid "The invoice lines were not updated to the new Fiscal Position because they don't have products.\n" |
268 | +"You should update the Account and the Taxes of each invoice line manually." |
269 | +msgstr "Les lignes de facture n'ont pas été mise-à-jour suite au changement de la position fiscale car elle ne contiennent pas de produit.\n" |
270 | +"Vous devez mettre à jour manuellement le compte comptable et les taxes sur chaque ligne de facture." |
271 | + |
272 | |
273 | === added file 'invoice_fiscal_position_update/i18n/invoice_fiscal_position_update.pot' |
274 | --- invoice_fiscal_position_update/i18n/invoice_fiscal_position_update.pot 1970-01-01 00:00:00 +0000 |
275 | +++ invoice_fiscal_position_update/i18n/invoice_fiscal_position_update.pot 2014-01-06 23:25:40 +0000 |
276 | @@ -0,0 +1,48 @@ |
277 | +# Translation of OpenERP Server. |
278 | +# This file contains the translation of the following modules: |
279 | +# * invoice_fiscal_position_update |
280 | +# |
281 | +msgid "" |
282 | +msgstr "" |
283 | +"Project-Id-Version: OpenERP Server 7.0\n" |
284 | +"Report-Msgid-Bugs-To: \n" |
285 | +"POT-Creation-Date: 2014-01-06 22:33+0000\n" |
286 | +"PO-Revision-Date: 2014-01-06 22:33+0000\n" |
287 | +"Last-Translator: <>\n" |
288 | +"Language-Team: \n" |
289 | +"MIME-Version: 1.0\n" |
290 | +"Content-Type: text/plain; charset=UTF-8\n" |
291 | +"Content-Transfer-Encoding: \n" |
292 | +"Plural-Forms: \n" |
293 | + |
294 | +#. module: invoice_fiscal_position_update |
295 | +#: view:account.invoice:0 |
296 | +msgid "fiscal_position_change(fiscal_position, type, invoice_line, context)" |
297 | +msgstr "" |
298 | + |
299 | +#. module: invoice_fiscal_position_update |
300 | +#: code:addons/invoice_fiscal_position_update/account_invoice.py:88 |
301 | +#, python-format |
302 | +msgid "Warning" |
303 | +msgstr "" |
304 | + |
305 | +#. module: invoice_fiscal_position_update |
306 | +#: code:addons/invoice_fiscal_position_update/account_invoice.py:99 |
307 | +#, python-format |
308 | +msgid "The following invoice lines were not updated to the new Fiscal Position because they don't have a Product:\n" |
309 | +" %s\n" |
310 | +"You should update the Account and the Taxes of these invoice lines manually." |
311 | +msgstr "" |
312 | + |
313 | +#. module: invoice_fiscal_position_update |
314 | +#: model:ir.model,name:invoice_fiscal_position_update.model_account_invoice |
315 | +msgid "Invoice" |
316 | +msgstr "" |
317 | + |
318 | +#. module: invoice_fiscal_position_update |
319 | +#: code:addons/invoice_fiscal_position_update/account_invoice.py:90 |
320 | +#, python-format |
321 | +msgid "The invoice lines were not updated to the new Fiscal Position because they don't have products.\n" |
322 | +"You should update the Account and the Taxes of each invoice line manually." |
323 | +msgstr "" |
324 | + |
To the best of my knowledge a fiscal position is not dependent on a product and nor is an invoice line. It would be nice if this dependency wasn't there but recognise the difficulties in implementing consistently if an existing fiscal position has already remapped accounts and taxes before changing it. Also recognise that most invoices contain products.
So only comment would be to document the limitation or raise an error if none of the lines contain product_ids. Not sure how it would happen with a mix of both, but maybe it would pay to play it safe and raise an error if this case ever happens.
But otherwise LGTM.