Hi,
Odoo doesn’t enforce the Internal Reference (default_code) field as required or unique out of the box.
Many small retail shops, service-based companies, or businesses without complex inventory needs don’t require SKUs. Making default_code mandatory by default could confuse users who don’t maintain part numbering systems.
Odoo doesn’t assume how SKUs should be generated or formatted. Many users might prefer to use vendor part numbers, group-based sequences, or manual codes. To support that flexibility, Odoo leaves generation and enforcement up to the implementer.
If you do need default_code to be required or unique, there are solid options:
OCA Module
* https://odoo-community.org/shop/product-internal-reference-as-required-3926?search=product_code_mandatory#attr=941330
You can define server actions or extend models with Python constraints to prevent duplicates.
@api.constrains('default_code')
def _check_unique_sku(self):
if self.default_code:
duplicates = self.env['product.template'].search([('id','!=',self.id),
('default_code','=',self.default_code)])
if duplicates:
raise ValidationError("Duplicate internal reference not allowed")
Hope it helps
This app - https://apps.odoo.com/apps/modules/18.0/product_dynamic_code - might be a solution for this case. It lets you generate automatic codes based on any product field. Thus, internal references will not be empty and might be forced to be unique. If needed, it is possible always to switch to manual codes.
Thank you for your response.
I am aware of the subset of customers that will not have this requirement and the reasoning for why Odoo may have not done this out of the box. On the other side of the coin you will have a lot of businesses that will have this requirement. They will effectively have to individually do this modification internally. I will have to agree with you that not everyone at Harvard or Oxford is a professor, but everyone has a student or employee ID :-)
I am in the process of analysing the system and gathering as much information as possible so I can have the correct approach at the later stages of implementation.
The first advice I received from the very beginning was to try and keep things stock as much as possible in order to provide seamless upgrades in the future.
With this in mind my first approach was to do the change in the Base Properties of that Field, but this is not allowed for Base Fields, so it will need to be done in code.
This leads me to my main concern without deep diving into this aspect, how would future upgrades be affected by these types of customisations?
Thank you @faOtools, I will make a note of this. Is there any rating system that allows us to judge if a particular App is reliable?
Odoo has a built-in rating system, although most apps do not yet have such ratings. For this specific app, you may request a demo database and test the features in a testing environment before purchasing.