[6.1, account] Tax description should not have uniqueness constraint

[Stefan Rijnhart (Opener)]

Hi,

since a couple of days, the uniqueness constraint on the field 'name' on the Tax model (account.tax) has been swapped for a uniqueness constraint on the field 'description' (see [1]). I do not believe that this is correct, for the following two reasons:

- The description field is not a required field, and many localisations do not use it. To have a uniqueness constraint on such a field is meaningless.

- Other localisations such as the Dutch, German, Austrian and Canadian naturally use the same description as a shorthand for similar taxes that cannot occur together. In case of l10n_nl for instance, the same description reflects the tax type and percentage for both taxes payable and receivable. In the current state of the repository, it is not possible to configure a chart of accounts anymore according to any of these localisation modules.

Please revert the commit refered to in [1].

Cheers,
Stefan.

[1] http://bazaar.launchpad.net/~openerp/openobject-addons/trunk/revision/6488

[Antony Lesuisse (OpenERP) (al-openerp)]

description is used for Tax Code. The real question is: do we really need both a tax code and a tax name ? Also we have to consider the fact that in the future the many2many taxes will be displayed using an textextjs widget (showing only the name_get).

[Ronald Portier (Therp) (rportier1962)]

Maybe we do not need a description.

But this that take away from the fact the change breaks existing localizations for no apparent reason?

And what about the argument that a unique constraint is added to a non required field?

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

Heloo just a comment,
I check in our Brazilian localization: name and description are always
equal: so as for us we don't need a description field. Not sure how it is
for the others, may be worth asking officially.

Regards.

On Tue, Feb 7, 2012 at 8:00 PM, Ronald Portier (Therp) <email address hidden>wrote:

> Maybe we do not need a description.
>
> But this that take away from the fact the change breaks existing
> localizations for no apparent reason?
>
> And what about the argument that a unique constraint is added to a non
> required field?
>
> --
> You received this bug notification because you are a member of OpenERP
> Drivers, which is subscribed to OpenERP Addons.
> https://bugs.launchpad.net/bugs/928424
>
> Title:
> [6.1, account] Tax description should not have uniqueness constraint
>
> Status in OpenERP Addons (modules):
> New
>
> Bug description:
> Hi,
>
> since a couple of days, the uniqueness constraint on the field 'name'
> on the Tax model (account.tax) has been swapped for a uniqueness
> constraint on the field 'description' (see [1]). I do not believe that
> this is correct, for the following two reasons:
>
> - The description field is not a required field, and many
> localisations do not use it. To have a uniqueness constraint on such a
> field is meaningless.
>
> - Other localisations such as the Dutch, German, Austrian and Canadian
> naturally use the same description as a shorthand for similar taxes
> that cannot occur together. In case of l10n_nl for instance, the same
> description reflects the tax type and percentage for both taxes
> payable and receivable. In the current state of the repository, it is
> not possible to configure a chart of accounts anymore according to any
> of these localisation modules.
>
> Please revert the commit refered to in [1].
>
> Cheers,
> Stefan.
>
> [1] http://bazaar.launchpad.net/~openerp/openobject-
> addons/trunk/revision/6488
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openobject-addons/+bug/928424/+subscriptions
>

[Stefan Rijnhart (Opener) (stefan-opener)]

Hi Anthony,

to answer your question, the following bug report demonstrates that some localisations do use both fields for reporting purposes: the shorter code field is featured on the invoice line, and the tax overview below works as a legend for the various taxes: https://bugs.launchpad.net/openobject-addons/+bug/899417. We ourselves would like to use the tax code field as a shorthand in the invoice report and again, for our purposes the tax code it is emphatically not unique.

I will subscribe the accounting experts team to comment further on this discussion. In the mean time, let me ask you once again to revert this change for now, as it breaks at least four localization modules one week before the release of 6.1.

Cheers,
Stefan.

[Stefan Rijnhart (Opener) (stefan-opener)]

Hi,

on second thought, it seems subscribing the localization experts team is more appropriate.

Cheers,
Stefan.

[Stephane Wirtel (OpenERP) (stephane-openerp)]

Hi Stefan,

I'm sorry for this problem. In fact, there was a problem with the migration script and I think I pushed this patch by error.

I reverted the patch. Thank you so much for your useful feedback

Stephane

[Stefan Rijnhart (Opener) (stefan-opener)]

Hi Stéphane,

thanks for the fix! I can confirm that the Dutch chart of accounts can now be configured successfully again.

Cheers,
Stefan.

[Normunds (Alistek) (3pm)]

These constraints still cause problems in certain tax setups- resulting in broken company setup while setting up a new company.

Example:

Parent Tax 1 -> Child Tax Name 1
                            -> Child Tax X

Parent Tax 2 -> Child Tax Name 1 (We need there the same name and code, because this is the same tax)
                            -> Child Tax Y

In second example we should add the same tax again, because in the tax setup there is no possibility to link one tax to multiple parent taxes.

In conclusion: this sql constraint breaks Parent-Child functionality. Please remove this constraint.

Normunds
Alistek, Ltd