Ok So it makes senses to me.
That’s the improvement we did on the new release. Make the code a SKU.
For EAN and other codes that should be validated there are the product identifiers.
This will produce data duplication. I think you should think the other way arround: If you need an optional code with other requirements just add a field which mets your requirements.
I beg to disagree.
An SKU is optional and must be unique. It is even recommended not to have one if not truly necessary.
One could always implement an SKU generator, if need be.
There is no real data duplication as, truly, an SKU is best when independent of enterprise, manufacturer or supplier product codes…
Please simply create an optional attribute ‘inventory code’ on product (which is what the SKU is) and don’t force the hand on internal business process decisions.
All of this statments are already implemented on Tryton.
Feel free to create any optional attributes you need on your customization modules.
What I disagree with is to use the product number (code) as an SKU when it most certainly is not one, forcing what is in effect retail or POS oriented kludges on those who neither want nor need that. Especially given that it is relatively simple to provide the SKU in a modular manner.
This is a very high impact change that we consider a regression.
This same issue is the reason we aborted using SAGE Gestion Commercial almost a decade ago.
In other words, if not using a modular approach by creating an inventory code (SKU) attribute and managing it separately following best practices (nomenclature, by warehouse and/or POS), at least make the constraint creation optional but configurable for those who consciously want to activate it.
Production (and materials) management is complex enough without artificially increasing the burden upon finite human resources.
The new product code system is nice and very flexible except unique code requirement, IMHO.
At first, there is backward compatibility problem. Some users who for some reasons used to use duplicate codes must not only rewrite codes in database but also must change their product coding system, retrain users, reprint leaflets etc.
At second, the strongest side of Tryton is the flexibility. If someone want to use duplicate codes, why not? For example, the record name “[White] IPhone 11” is more user and customer friendly than “[125468774455White] IPhone 11”, isn’t?
My dilettant’s idea - maybe it’s possible to add into tryton.config file a new key a la “we_dont_need_unique_code” and test it before creating product code constraint?
You can do that by creating a fake constraint with the same name. But I do not recommend it as other code may rely on this uniqueness.
Thank you, nice idea, I’ll try. The extendibility of Tryton still have many terre incognite for me.
May rely but may not rely. Or related code may be not need for us. As minimum we get some time for comfort life with duplicated codes.
Such code is certainly erroneous, once the product is selected in either sales or purchase or even a logistics reception of goods, it is forcibly the id (which is already unique because it is selected) that should be used and not the code.
Otherwise, as already indicated, if such a unique ‘code’ is needed as SKU, create that special unique attribute (e.g. inventory code or SKU).
Wouldn’t renaming this field solve the misunderstanding?
Of course the issue is that previously people did not use the code as the SKU, we would need to find something to solve this for them.
Wouldn’t it be much simpler (and more user friendly) to follow the proposal of risto3?
- revert this backward incomatible change
- create a new unique field SKU (or even better create the unique identifier SKU for products)
→ no renaming of the field needed, no upgrade worries, usage of identifiers for what they are meant
Maybe we can add a warning and a query to update the codes to make then unique. Something like:
update product_product set code = CONCAT(code, CONCAT('-', CAST(id as varchar))) where COALESCE(code, '') != '';
This is the easiest solution to solve de problem.
don’t change the codes that have been created for a reason (read: business use)
The code usage won’t be changed as we use the starting part when searching on codes. So if you have the code 123 duplicated, searching for this code will also return the same results after appling the query.
This will allow yo to add the constraint and also includes a separator (’-’) to be able to keep the original code if required.
This allows each company to fix the codes in a single maner depending on their business use. As we support all business we can not provide a single solution for all cases.
You have to look deper to see the light on the tunnel 
The code usage is changed. If there is an implementation that searches for code ‘=’, not code ‘ilke’ it will be broken.
Besides that this still breaks the original legitimate usage of the field. And doesn’t provide without further code changes a consistent creation of new codes.
You didn’t answer my proposal (see above). I would be glad to hear if I missed something. An SKU for me in fact is an identifier. For me it turns out that adding this constraint was a wrong concept in the first place and should be fixed. And it is still easy to fix with the next bugfix release so that users hit by the incompatible change can upgrade to a next version without breakage.
Please read again the following citation that describes the situation very well:
Hmm.
There will be not turning back on this (and we will add more missing unique constraint on code field). This change is 4 months old. It is pointless to come after the battle (if you care, be involved in the development process). Also this is the basis for upcoming new functionalities and solve existing issue.
Tryton is evolving on each release and so each one will keep introducing non-backward compatible changes. We already provided many ways to bypass this constraint. But the most obvious and general one is that if you do not like the usage of a standard field, create a new one.
I find only two references of ‘SKU’ here prior to falling across it as ‘fait accompli’ in release notes.
Couldn’t seem to find any references at all in years of mailing lists.
These two references were found in discussions of e-shop of which we have no business interest therefore never even took notice since we are not retailers… Weren’t solicited for comment either even though there is quite a history of product oriented activity…
Pity such a stance.
We can not request everyone to add comments in every new feature.
Having said that I think the current development process is quiet open:
- There is a lot of discussion that happens openly in this forum. You can receive a digest my mail if you do not want to be notified for each post.
- All the new features are linked to an issue on the tracker. You can subscribe to email to new issues to see all proposals and join on what you prefer.
- Anyone can post comments on the tracker or on the codereview tool.
- There is a list to get notified by each commit pushed. Normally this is to late to change things but at least you will now what it’s done
- The development sources are quite stable. You can try new features on a fresh database to try to fix things before there are relased.
- There is a feature freeze perios to fix bugs before the version is released.
But despite having such options there are always people complaining after the release 
I can understand the frustration of having an unexpected change on a new relase, but please also understand that is quite frustrating to get comments trying to force others to change some part of a base module after ignoring all the possible solutions that can appplied to adapt the system for your needs.
Open source project work when everyone puts it’s efforts to work for a common goal and takes care of reviewing new features before they are released.
Honestly, I will love to have more eyes reviewing features before they are commited and I do a big effort to review as much as possible. But for sure we need more people to work on it.
I again invite then to fix rapidly this high impact regression:
- change the name of code to sku (or inventory code) since it is no longer the product code
- add mpn or manufacturers product number to allow previous usage of code to continue normally
- add brand and possibly manufacturer, even model which are already missing
- fix all the uses, in purchasing at least, to search these fields (in fact, sku is normally just an optional merchant specific identifier, at best it may be the suppliers code for the mpn, but not always, we have more and more suppliers using the mpn now)
This is a new feature that should be discussed on a separate thread. BTW the brand can be represented as a product category