[6.0] record rule for account.tax is incorrect

[Stéphane Bidoul (Acsone)]

Hello,

I noticed that the default record rule for account.tax is ['|',('company_id','=',False),('company_id','=',user.company_id.id)]

It should be ['|',('company_id','=',False),('company_id','child_of',user.company_id.id)] instead.

Best regards,

-sbi

[Amit Parik (amit-parik)]

Hello,

This issue has been already improved in trunk version but problem is already in stable version with rev no 4594.

So I am confirming this for stable version.

Thanks.

[Jay Vora (Serpent Consulting Services) (jayvora)]

Hello Stephane and Amit,

Thanks for information here.

But, this is not a bug or a forgotten line; but rather a really intended behavior.

As far as the taxes are concerned, men should be allowed to see only the taxes related to the current company used. This fix the problem of a product company neutral with several taxes defined (one for each existing company): previously the onchange was setting all the taxes on invoice/SO/PO/... lines instead of just the one for the current company.

So, stable version 6.0 behaves pretty normally. Instead, the fix on trunk would have some consequences, hence it should be fixed in trunk.
Refer to : http://bazaar.launchpad.net/~openerp/openobject-addons/trunk/revision/3164.118.592
Thanks.

[Stéphane Bidoul (Acsone) (sbi)]

Hi Jay,

I'm still rather new around here, so, pardon me if I'm wrong.

I find the approach you mention rather surprising, however. Indeed for all other objects, a user working on one company can see everything in the child companies (including accounts, tax codes, etc).

I'm not sure I understand the use case you mention.

In our situation, I want a user on the Parent company to be able to create Invoices on child companies. Therefore, I believe it is a bit strong to completely block all taxes of child companies at the level of a global record rule.

IMHO it would be preferable to address the situation you mention by applying the correct tax filters in the required forms (such as Invoices) to ensure consistency.

Best regards,

-sbi

[Jay Vora (Serpent Consulting Services) (jayvora)]

Hello Stéphane,

We had a discussion over this point and we tend to agree to you about the rule should be fixed and the desired behavior should be achieved as well.

As a part of the solution, we confirm this for stable 6.0 and we will post a solution at earliest.

More details will be posted after the detailed investigation.

Thanks.