wrong tax calculation after invoice duplication and changing partner with other fiscal position

Bug #1212281 reported by Ferdinand
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Odoo Addons (MOVED TO GITHUB)
Confirmed
Low
OpenERP R&D Addons Team 3

Bug Description

to reproduce

European Union:
create an invoice with normal domestic tax
service 100
tax 10
total 110

validate

duplicate
change partner to EU-partner - no tax should be computed

remark: the tax is only computed on change of the general account.

it seems mandatory to recompute tax on validate to avoid such errors.

Revision history for this message
Amit Parik (amit-parik) wrote :

Hello,

Have you try with update button for compute taxes?

Thank you!

Changed in openobject-addons:
status: New → Incomplete
Revision history for this message
Ferdinand (office-chricar) wrote :

Hello Amit

1) in standard v7 there is no "update tax" button
2) AFAICS onchange_account_id is only called on form level AFTER changing the account in invoice lines
unless there is a code duplication which I missed - duplication of invoice will never call this

Changed in openobject-addons:
status: Incomplete → New
Revision history for this message
Ferdinand (office-chricar) wrote :

users copy the invoices and just change the partner

Revision history for this message
Ferdinand (office-chricar) wrote :

Hmm
I think we need a
* on_change_fiscalposotion
* on_change_pricelist
* ...?
in invoice header (and probably sale/purchase too)

which recalculates for each existing line
* on_change_account_id
* on_chane_product_id
* ....

to deal correctly with duplication and other changes of the "header" after lineshave been inserted

Revision history for this message
Raphaël Valyi - http://www.akretion.com (rvalyi) wrote : Re: [Bug 1212281] Re: wrong tax calculation after invoice duplication and changing partner with other fiscal position

Hello Ferdinand, I just released that today I found a very similar bug as
what you just reported here with purchase orders (it's not a duplicate
though) https://bugs.launchpad.net/openobject-addons/+bug/1215578 By
inspecting a production database, I could find not less that 40 corrupted
purchase orders over the last year (may be 5%) which certainly ins't an
acceptable threshold.

So yes, this reminds us OpenERP doesn't really support changing
order/invoice information once it has some lines. Will v8 fix this with the
depends API? Or else wouldn't it be just better to warn the user when
changing the partner and propose him to re type all the lines? Probably not
ideal, but still better than silently corrupted data. Ideas?

On Fri, Aug 23, 2013 at 12:38 AM, Ferdinand @ Camptocamp <
<email address hidden>> wrote:

> Hmm
> I think we need a
> * on_change_fiscalposotion
> * on_change_pricelist
> * ...?
> in invoice header (and probably sale/purchase too)
>
> which recalculates for each existing line
> * on_change_account_id
> * on_chane_product_id
> * ....
>
> to deal correctly with duplication and other changes of the "header"
> after lineshave been inserted
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Addons.
> https://bugs.launchpad.net/bugs/1212281
>
> Title:
> wrong tax calculation after invoice duplication and changing partner
> with other fiscal position
>
> Status in OpenERP Addons (modules):
> New
>
> Bug description:
> to reproduce
>
> European Union:
> create an invoice with normal domestic tax
> service 100
> tax 10
> total 110
>
> validate
>
> duplicate
> change partner to EU-partner - no tax should be computed
>
> remark: the tax is only computed on change of the general account.
>
> it seems mandatory to recompute tax on validate to avoid such errors.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openobject-addons/+bug/1212281/+subscriptions
>

Revision history for this message
Ferdinand (office-chricar) wrote :

IMHO this is a basic (mis) conception of OpenERP
If the user does everything "right" = the way OpenERP has conceived the workflow/logic, OpenERP works very well, if the user is "off road" and makes mistakes whatsoever, there is often no way back.
you might be interested in the various "reopen" modules in
http://bazaar.launchpad.net/~camptocamp/c2c-rd-addons/7.0/files
which I wrote to keep the eyes of users dry.

BUT - what I learned in my software live is:
everything what is not forbidden (prohibited by code) will be done - there is absolutely no point in issuing warnings - user will ignore it because
* many warnings are not helpful
* users will not understand the consequences
* users are in stress to get their work done.

BTW - as you know - the duplication issue described in #4 can be solved in 1-2 hour.

Revision history for this message
Amit Parik (amit-parik) wrote :

Hello Ferdiand,

For the 1st point , "Update" taxes button is there beside of the tax field. You can see it on editable mode.
When v7 was released at that time it was not there but after this we have again put the "Update" button same as "Compute taxes" button functionality.

2nd Point: Agreed, we have to put on_change on fiscal position and check that taxes and replace it because your given scenario is find. We need to resolve it.

Thanks for the reporting!

Revision history for this message
Ferdinand (office-chricar) wrote :

please think also of on change of price list!

Revision history for this message
Amit Parik (amit-parik) wrote :

Pricelist for sale order and purchase order?

Revision history for this message
Ferdinand (office-chricar) wrote :

both obviously

Revision history for this message
Amit Parik (amit-parik) wrote :

As per my "Opinion" we have to use "Apply" button for all this 3 places (pricelist for SO and PO, Fiscal position for Invoice) same we have already user for "Currency" then applied the currency via applied button.

Thank you!

Changed in openobject-addons:
assignee: nobody → OpenERP R&D Addons Team 3 (openerp-dev-addons3)
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
Ferdinand (office-chricar) wrote :

I never understand that such issues are classified as "low" - users create wrong data without realizing ....

Revision history for this message
Amit Parik (amit-parik) wrote :

Hello,

*"Low"* because of this is complete new improvement, this is the good feature that's why I am considering this as a low not as a "Wishlist"

One more thing, If everything setup good then there is no possibility to faced any issue or bug here, the problem comes on such spacial kind of case.

Hope you will agree!

tags: added: fiscalposition pricelist taxes
Revision history for this message
Ferdinand (office-chricar) wrote :

please see comment #5

Revision history for this message
Rafael C. Delgado (gp-rafaelc) wrote :

Can't install.. Following error.

ValidateError

Error occurred while validating the field(s) arch: Invalid XML for View Architecture!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.