Enforced CHE prefix in swiss uid and vat modules.

[jeffh92]

Currently, the modules for the Swiss UID and related VAT numbers enforce that the CHE prefix is part of the validated number.
But, wouldn't it be more in the spirit of how most other modules work to strip this prefix as part of the compactization?
The uid module also already uses the compact form, e.g. to check numbers with the Swiss Federal Statistical Office web service which also supports the compact forms.

We already adjusted this locally for our purposes as we store the compact forms to optimize searching.
So I will gladly make PR with the adjustment if this should be desired.

Kind regards.

[arthurdejong]

That does change the API of the module and users that relied on the old behaviour would be surprised. For example for users that stored the compact representation and used that in database searches. So we should only change this if the number is widely used without the CHE prefix.

I think originally the CHE part was considered a necessary part of the number and as such it wasn't stripped. For other countries the prefix is optional and is stripped.

[jeffh92]

Doesn't the current implementation complicate storing the compact representation as it enforces the CHE prefix to be present?
According to the number's documentation the purpose of the CHE prefix is to indicate its Swiss origin. So in that sense it falls in the same category as almost all other modules that do strip the country prefix.

In our use, the user selects a type of identification number and the validation then accepts various (un)formatted and (un)stripped number variations while always storing the compacted unstripped value in the database which optimizes both searching as formatting where needed. So in that sense enforcing the CHE prefix seems unnecessary because the user already gave context.

What we're proposing does not change the current validation or formatting of unstripped numbers, it will merely also accept stripped numbers to be valid and format both stripped as unstripped numbers with the CHE-prefix.
So any existing code would only fail it it relied on the module not accepting unstripped numbers.
But that's our angle offcourse, and we understand if that does not correspond with the vision of this library.

[arthurdejong]

What we're proposing does not change the current validation or formatting of unstripped numbers, it will merely also accept stripped numbers to be valid and format both stripped as unstripped numbers with the CHE-prefix.

Ah, OK. That should be fine. Changing the functionality of the validate() function to also accept numbers with a CHE prefix should be OK. What is important is that both the compact() and validate() functions do not change the return value of numbers with the CHE prefix. Also I'm not sure what would be the best return values for the compact() and validate() functions for numbers without the prefix. For consistency returning a number with the prefix is probably the nicest because it clearly indicates that the number with and without the prefix are actually the same.