Allowing tax identifier non validated by python-stdnum

Feature Ideas
1

One of our customers is selling goods to IRAN. He has the IRANI fiscal number but this is not available as Tryton tax identifier (neither it is available on python-stdnum).

Altought this can be entered as other type on the party form, this has the drawback that the tax identifier is not automatically selected when issuing the invoice so the user needs to manually check that the field is filled before posting the invoice, causing some problems as they sometimes forget about it.

I’m wondering if it will be a good idea to have a “Other tax identifier” selection option in the types of identifiers which is not validated by python-stdnum but is considered a tax identifier.

Tougths?

2

I do not see the point. You can add any extra type on identifier (as long as it does not contain _ it will not be tested with python-stdnum). And you can add this identifier to the tax identifier types list.

3

Well the point is basically that:

  • A developer (like me) can add the extra type on the identifier without any issue
  • But a user can not add the type by himself.

So having a extra type will allow the user to add the tax identifier by himself without requesting developer help.

P.S: Is also a little bit anoying to add the tax identifier one by one each time the company is issuing a new invoice to a diferent country.

4

But it will not help python-stdnum to grow.

Just add all of them.

5

Then why not adding all of them in Tryton?

Of course, the library will grow just when somebody wants to validate the identifier of such country.

6

I’ve digging a little bit and I just found that there is VATIN which is supported by python-stdnum which may be a good addition to Tryton.

However, that does not fix the case of Iran. I also found that United Arab Emirates and Saudi Arabia are also missing.

7

Indeed it is a new feature.

Better to add them to python-stdnum, for me it is a small cost for those countries to use Tryton.

8

The main point is not for such countries to use Tryton but for companies currently using Tryton that are selling goods/services to such countries.

So in such case, we need to wait for a new python-stdnum release and then wait for a Tryton relase which is a minimum of 6 month timeframe just for issuing an invoice.

9

I’ve filled Add VATIN tax identifier (#11784) · Issues · Tryton / Tryton · GitLab to implement such feature.

10

That the same.

Well the tax identifier is not very important when doing international trading because there is no taxes to deduce.
Also user can fill the number in the description for example and if they want to be rid of this they will just add it to python-stdnum.

Globally I dislike the idea of adding a carryall tax identifier because it will be misused (for example to skip validation).

11

Maybe if we make filling such non-validated tax identifier hard enough it will not be misused. For example we could raise a warning when created or modified. Also we could check that it is not a valid VATIN and so we reject it.