¿puedo utilizar mi base de datos de productos existente para el pasaporte de producto

Lo que debe hacer concretamente

Lo que se espera de usted

Muchas empresas con 10 a 100 empleados ya cuentan con una base de datos de productos: un sistema ERP, un sistema PIM, o simplemente un archivo Excel extenso con números de artículo, materiales, dimensiones y datos de proveedores. La pregunta no es si esa base de datos es útil, sino si los datos que contiene cumplen con lo que el ESPR espera de un pasaporte digital de producto. Son dos cosas diferentes.

El contenido debe corresponder a lo solicitado por el acto delegado

El artículo 9 del ESPR (Reglamento (UE) 2024/1781) describe el pasaporte digital de producto como una colección de información de producto que es accesible a través de un soporte de datos. Qué información exacta debe ser esa se establece por grupo de productos en un acto delegado. Para muebles aún no se ha publicado. En términos prácticos, esto significa que una base de datos existente a menudo ya contiene parte de los datos solicitados — composición de materiales, origen, dimensiones — pero rara vez todo. La información sobre reparación, las instrucciones de reciclaje o los datos sobre capacidad de reciclaje típicamente no se encuentran en un sistema ERP que fue configurado para gestión de inventario y facturación.

Los datos deben estar estructuralmente vinculados a un soporte de datos

El artículo 11 del ESPR establece requisitos para el diseño técnico: el pasaporte debe ser accesible a través de un soporte de datos (como un código QR) y los datos deben presentarse de manera estructurada y legible por máquina. Una base de datos que solo se usa internamente y no está configurada para establecer un vínculo único y duradero por ejemplar o modelo de producto con un soporte de datos, no cumple automáticamente con eso. Para una empresa de este tamaño, esto generalmente significa que se necesita una capa adicional entre la base de datos existente y el mundo exterior: un sistema que extrae los datos correctos de la base de datos, los coloca en la forma correcta, y los vincula a un código QR que permanece accesible durante diez años.

La accesibilidad debe cumplir con los requisitos del artículo 10

El artículo 10 de la ESPR trata sobre quién puede ver qué datos y cuánto tiempo deben estar disponibles. Una base de datos interna generalmente no está diseñada para accesibilidad pública o parcialmente pública, y mucho menos para un período de retención que sea independiente de si la empresa sigue existiendo. Eso requiere una provisión separada además de la base de datos existente, no un reemplazo de ella.

Dónde falla en la práctica

Un fabricante asume que, dado que todas las especificaciones técnicas ya están en el sistema ERP, el pasaporte "sale automáticamente". En la práctica, precisamente faltan los campos que la ESPR probablemente pedirá, como información de reparación y desmontaje, y deben completarse manualmente.

Un importador trabaja con una base de datos del fabricante de un país fuera de la UE y asume que esos datos se pueden utilizar directamente. Los datos de origen a menudo no tienen la estructura o el idioma necesarios, e importador, en su condición de agente económico en la UE, tiene su propia responsabilidad por la exactitud de los datos que finalmente aparecen en el pasaporte.

Un proyectista tiene su propia base de datos de artículos por proyecto de cliente, pero no está vinculada a un portador de datos individual por producto. En una inspección, se demuestra que no existe un vínculo directo y estable entre un mueble vendido y los datos del pasaporte correspondiente.

Una empresa actualiza su propia base de datos regularmente, por ejemplo, ante un cambio de material, pero olvida que el pasaporte de los productos ya vendidos ya no coincide con el producto físico. La base de datos interna es un archivo "vivo", el pasaporte debe ser precisamente un registro confiable en el momento de la venta.

Una empresa con muchas variantes de color y tejido gestiona esas variantes como un campo separado dentro de un único código de producto, mientras que el pasaporte posiblemente requiere datos diferentes por variante — piense en un porcentaje de material diferente con una opción de tejido diferente. Quien se enfrenta a esto encontrará más información sobre esta complicación específica en ¿cómo creo pasaportes para una colección de muebles con muchas variantes de color y tela.

Lo que puede documentar

• Un resumen de qué datos ya existen en la base de datos actual y cuáles de ellos probablemente son relevantes para un pasaporte de producto — basado en lo que el artículo 9 y 10 de la ESPR (Reglamento (UE) 2024/1781) sugieren como orientación, aunque la lista exacta por grupo de productos aún no esté establecida.
• Una nota sobre la fuente y confiabilidad de cada dato: ¿se determinó internamente o se tomó de un proveedor o fabricante en otro punto de la cadena?
• Un procedimiento para registrar cambios en los datos del producto, para que esté claro qué versión de los datos corresponde a qué producto vendido.
• Acuerdos con proveedores sobre qué datos suministran y en qué formato, especialmente cuando la propia base de datos depende de su contribución.
• Un resumen de variantes de producto y los datos que pueden diferir por variante, especialmente en acabados de color y tejido.

Quien quiera estructurar esto ahora, aunque aún no esté el acto delegado, encontrará un enfoque en qué puedo hacer ya mientras las reglas aún no son definitivas. Y para quien quiera saber cómo este inventario encaja en el resto del proceso, hay una descripción general en cómo abordo el pasaporte de producto para muebles paso a paso.

Una base de datos de producto existente rara vez es, por lo tanto, inútil, pero tampoco rara vez es suficiente por sí sola. En la mayoría de los casos, forma un punto de partida útil: los datos básicos están ahí, la estructura y el vínculo con un portador de datos generalmente no. Es prudente evaluar estas dos cosas por separado — qué datos ya existen y qué se necesita aún para convertir esos datos en un pasaporte.