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

[Ferdinand]

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.

[Amit Parik (amit-parik)]

Hello,

Have you try with update button for compute taxes?

Thank you!

[Ferdinand (office-chricar)]

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

[Ferdinand (office-chricar)]

users copy the invoices and just change the partner

[Ferdinand (office-chricar)]

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

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

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
>

[Ferdinand (office-chricar)]

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.

[Amit Parik (amit-parik)]

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!

[Ferdinand (office-chricar)]

please think also of on change of price list!

[Amit Parik (amit-parik)]

Pricelist for sale order and purchase order?

[Ferdinand (office-chricar)]

both obviously

[Amit Parik (amit-parik)]

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!

[Ferdinand (office-chricar)]

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

[Amit Parik (amit-parik)]

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!

[Ferdinand (office-chricar)]

please see comment #5

[Rafael C. Delgado (gp-rafaelc)]

Can't install.. Following error.

ValidateError

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