Created on 2021-05-04.09:23:16 by risto3, last changed 2 days ago by ced.
Not sure of the origin of 'unmodifiable' user input but the bad idea is allowing uncontroled modification/usage of relatively strict legal (read: fiscal) objects ... For example, it is erroneous to represent as two parties (tryton objects) a single legal (or juridical) person ... actually, same for a natural person too!
It is painful (and wrong) to permit fundamental changes to these parties which compromise their probity, such as uncontrolled address changes, legal identifier issues (lacking, incorrect or for an unknown party even duplicate of an existing one), and so forth.
Back to Spain, I'm curious about the prior and current forms of company for Sergi's customer (SL->SA?)
Did only the first letter and the check digit change for the CIF? That is, the 'number' remains the same?
Having an unmodifiable user input is a bad idea because it creates a lot of trouble if mistakes are made (and human make mistakes). So all the external identifier must be editable to be corrected.
About having a unique constraint on external identifier is also a bad idea because we can not rely about external following such constraint (we already had the case with the country codes). Also for the specific case of party, there is no real issue having duplicated identifier because duplicate inputs are not impossible to prevent. So for that Tryton is designed to deal with such duplicates and allow to merge them if necessary.
For all those reasons, I invalidate this request.
Yes, in Spain it's possible to change the identifier of the same company (one of my company customers did it).
For me it is not clear why we need to add this restriction and which is the benefit of adding it.
But for sure it is not a bug (everything is working well on Tryton) but a new feature request.
It will be great if you can explain why is this required.
If I understand correctly, you maintain that (in Spain?) transformation of a company form changes the unique identifier?
(seems that the 'replace' party function could work in this case, no?)
In France, changing the form of the société does not change the unique identifier (SIREN), nor the VAT number, and is expressly so!
Perhaps we should find out if one or the other approach is generalised, or perhaps whether a different unique identifier (LEI?) should/could be used whereupon national rules could be applied. https://www.esma.europa.eu/sites/default/files/library/esma70-145-238_lei_briefing_note.pdf
Given that LEI's appear to cost money, it may be a bit harse to force use.
I do not Agree with inmutable company identifier. It's not quite frequent but we had one customer who changed its tax identifiers without changing its name. This is because they change it's legal form and their identifier it should be updated.
We have a customer that did so and thanks to Tryton design it was very easy to do. Just create the new identifier and we keep the previous identifier for all invoices and used the new for the new ones.
For tax reporting you need to split the reports for each identifier which is already supported on Tryton (at least for Spain).
For duplicated VAT identifiers it's just a mater of replacing parties that have same identifier.
Indeed I do not see on your report any rational for your proposal, just "it should be".
In all countries, the unique company identifier is immutable. That is, once created, it cannot be changed.
A different company identifier means a different company (party).
In France, the SIREN is the unique company identifier, but it is not read-only (once set and validated). It should be.
The SIRET on companies registered addresses are too.
When setting the unique company identifier, the validation process should contain minimally the steps to control the identifier value itself, uniqueness in the database as well as perhaps even create and/or validate the primary (company HQ) address fields (which could be left to the country's accounting plan modules to provide).
For example, in France and other european countries, the validation process could also automatically setup the VAT identifier with VIES validation included, as these steps are currently disassociated and somewhat dysfunctional though to be formally correct they need to be.
There is probably some more modeling that needs to be done to better support the company view of an address as opposed to the pure geographical aspect, given real estate changes hands over time as well a do the occupants in the case of a lease.
|2021-05-05 15:47:59||ced||set||nosy: - ced|
|2021-05-05 15:09:22||risto3||set||messages: + msg67379|
nosy: + ced
status: chatting -> invalid
priority: bug -> feature
status: unread -> chatting
priority: feature -> bug
status: need-eg -> unread
nosy: + pokoli
priority: bug -> feature
status: unread -> need-eg
Showing 10 items. Show all history (warning: this could be VERY long)