Hola, David,

Uf, veo muchos puntos laterales derivados de tu pregunta, pero primero yendo a ella, el tema es que Odoo va refinando cada vez más la integridad de los datos versión a versión, y que haya la limitación de un solo código de barras es por una buena razón. Es un identificador único, y tener más de uno hace que pierda su razón de ser, ya que cuando se busque por él y aparezcan varias coincidencias, ¿qué se hace entonces?

Razones para tener el mismo más de una vez en la BD:

- Productos antiguos. En los mismos se debería vaciar el código de barras, y solo dejarlo en el actual vigente.

- Mismo producto y código de barras en múltiples compañías. Se debería tener un único producto, compartido por todas las compañías.

Entonces, la solución debe pasar por limpiar esos datos en lugar de intentar desfigurar la nueva versión para seguir manteniendo esa inconsistencia.

Luego, al margen de la pregunta, hablas de migrar de v8 a v14, pero en realidad eso no es una migración, si no una importación de datos (y presumo que solo los datos maestros), y el tema es que hacer eso en lugar de realmente migrar la base de datos con por ejemplo OpenUpgrade es perder mucha cantidad de información valiosa que va a quedar en la versión 8, y que obliga a mantenerla como consulta y que sea también un lastre tecnológico.

Por otro lado, ¿por qué v14 cuando ya está la v16 fuera? Es empezar con una versión con más de 2 años en la espalda.

Buenos días,

No sé si con "sin tener que tocar el código de odoo 14" te refieres también a no añadir nada de código, si es así, diría que es imposible.

Tienes que crear un módulo en el que heredes product.product y modifiques la restricción añadiendo:

_sql_constraints = [

('barcode_uniq', 'CHECK(1=1)', "A barcode can only be assigned to one product !"),

]

Independientemente de la tipología de migración, lo cual sería bueno analizar, Coincido en no eliminar esa constraint. Más, teniendo en cuenta que comentas que nos estás familiarizado con la parte técnica.

No tiene sentido que haya 2 productos con mismo EAN si no es por las casuísticas que comenta Pedro, o por alguna similar (al fin y al cabo errores de procesos). Hay que optar por aprovechar la migración (o traspaso de datos maestros) para hacer limpieza y replantear aquello que no merece la pena mantener. Digamos que, a nivel de código, "todo se puede hacer". ¿Es recomendable hacerlo y tiene sentido? Es lo que deberíais valorar antes.

Si quitas la limitación ahora, tendrás que mantener esa customización en las nuevas versiones y sucesivamente. Si empiezas a utilizar códigos de barras, etiquetas, etc. tendrás incompatibilidades, etc.

Saludos.

Buenos días Carlos,

me imaginaba que tenía que optar al final por crear un módulo, tendré que mirar como se hace porque no tengo ni idea sobre este tema...

Aún así darte las gracias por la respuesta e intentare hacerlo de esa forma, que aun siendo complicado para mí, parece ser la "única y sencilla" forma de hacerlo.

Un saludo y gracias de nuevo.