Merge lp:~akretion-team/account-invoicing/70-add-invoice_fiscal_position_update into lp:~account-core-editors/account-invoicing/7.0

Proposed by Alexis de Lattre
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
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

Description of the change

Add the module invoice_fiscal_position_update. Here is the description :

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.

To post a comment you must log in.
Revision history for this message
Graeme Gellatly (gdgellatly) wrote :

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.

review: Approve ((code review, no test))
Revision history for this message
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.

review: Abstain
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.

Revision history for this message
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.

Revision history for this message
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 !

review: Approve
Revision history for this message
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?

Revision history for this message
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://gist.github.com/rvalyi/8238688
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?

Revision history for this message
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.

Revision history for this message
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?

Revision history for this message
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.

Revision history for this message
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_position_change function, I do a "write" on all the invoice lines to update the taxes and account. But this is a problem in the following scenario :

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.

Revision history for this message
Graeme Gellatly (gdgellatly) wrote :

Hi Alexis,

It is, there is an ORM function self.resolve_2many_commands which
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_position_change function, I do a "write" on all the invoice lines to update the taxes and account. But this is a problem in the following scenario :
>
> 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://code.launchpad.net/~akretion-team/account-invoicing/70-add-invoice_fiscal_position_update/+merge/200358
> 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.

Revision history for this message
Alexis de Lattre (alexis-via) wrote :

@Graeme

Thanks for pointing me to resolve_2many_commands. I managed to make the on_change work in the interface (the tax and account fields are properly updated), but I get a crash when I save... so it's not usable for the moment.

The current code is here : https://code.launchpad.net/~akretion-team/account-invoicing/70-invoice_fiscal_position_update-onchange

28. By Alexis de Lattre

It now works well with the on_change !
Update POT file and FR translation.

Revision history for this message
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_2many_commands" pointed out by Graeme. I tested it and it seems to work well in all scenarios (at least all the scenarios that I tested ! :). Please test and report issues if you find some.

It's quite a big change in the code and it's the first time that I use the function "resolve_2many_commands", so tell me what you think of the new code.

Enjoy,

Alexis

Revision history for this message
Ronald Portier (Therp) (rportier1962) wrote :

Hello,

Good to know a function like resolve_2many_commands exists. By the way I could only find one place where it is used in the official addons, that is in account/account_move_line.py.

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.

review: Approve (code review and test)
Revision history for this message
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(value[0], int)
131 + and isinstance(value[1], (str, unicode))):
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_without_product) == len(iline_dict): raise a different warning. Something like "This invoice does not contain any products so existing lines have not been updated. You should update the accounts and taxes manually" - On a non product invoice that would make more sense.

But both very minor so reapprove..

review: Approve ((code review, no test))
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.

Revision history for this message
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_fiscal_position_update)

So it should be ready to merge now.

I'll start working on sale_fiscal_position_update and purchase_fiscal_position_update :)

32. By Alexis de Lattre

Better FR translation.
Update variable name, for easier porting to sale/purchase.

Revision history for this message
Alexis de Lattre (alexis-via) wrote :

Here is the module sale_fiscal_position_update

https://code.launchpad.net/~akretion-team/sale-wkfl/70-add-sale_fiscal_position_update/+merge/200611

It is independent from the module invoice_fiscal_position_update, so they don't share any code. I thought about adding a dependency and sharing code, but I don't think that the advantage is worth the dependency and the added code complexity.

Revision history for this message
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_2many_commands exists in OpenERP 6.1 under a different name : resolve_o2m_commands_to_record_dicts

But, unfortunately, when trying to use it, I often get :

File "/home/alexis/new_boite/dev/server-61/openerp/osv/orm.py", line 4975, in resolve_o2m_commands_to_record_dicts
    "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.

Revision history for this message
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.resolve2many = statement for the previously defined
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_2many_commands exists in OpenERP 6.1 under a different name : resolve_o2m_commands_to_record_dicts
>
> But, unfortunately, when trying to use it, I often get :
>
> File "/home/alexis/new_boite/dev/server-61/openerp/osv/orm.py", line 4975, in resolve_o2m_commands_to_record_dicts
> "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://code.launchpad.net/~akretion-team/account-invoicing/70-add-invoice_fiscal_position_update/+merge/200358
> You are reviewing the proposed merge of lp:~akretion-team/account-invoicing/70-add-invoice_fiscal_position_update into lp:account-invoicing.

Revision history for this message
Alexis de Lattre (alexis-via) wrote :

By the way, here is the module purchase_fiscal_position_update :

https://code.launchpad.net/~akretion-team/purchase-wkfl/70-add-purchase_fiscal_position_update/+merge/201115

We now have the full set for OpenERP 7 : sale + purchase + invoice

Revision history for this message
Joël Grand-Guillaume @ camptocamp (jgrandguillaume-c2c) wrote :

Hi Alexis,

Thanks you very much for this module. LGTM !

Regards,

Joël

review: Approve (code review, no tests)

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
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+

Subscribers

People subscribed via source and target branches