¿Puedo vincular el pasaporte de productos a mi sistema ERP o de inventario?
Un acoplamiento es técnicamente posible, pero no obligatorio ni prohibido legalmente
El ESPR no prescribe cómo un fabricante o importador suministra los datos del pasaporte digital de producto. El reglamento establece requisitos sobre el pasaporte en sí — qué datos debe contener, cómo debe ser accesible y con qué estándares técnicos debe funcionar — pero no especifica si esos datos se introducen manualmente, proceden de una hoja de cálculo u se obtienen automáticamente de un sistema ERP o de inventario. El acoplamiento entre un sistema interno y un servicio de pasaporte es, por lo tanto, cuestión no de lo que la ley permite, sino de lo que hacen posible la tecnología utilizada y el servicio ofrecido.
Para quién es relevante esto, y para qué no
Esta cuestión surge especialmente en empresas que ya trabajan con un sistema ERP o de inventario y no desean mantener los mismos datos de producto dos veces: una en el propio sistema y otra para el pasaporte. Se trata de una cuestión práctica, no jurídica. El ESPR no obliga a un fabricante a contar con un acoplamiento automatizado, ni tampoco lo prohíbe. Lo que el reglamento sí regula es la forma técnica que deben adoptar finalmente los datos del pasaporte, independientemente de cómo se suministren. Este tema no versa, pues, sobre obligaciones relativas al acoplamiento en sí, sino sobre los requisitos que deben cumplir los datos subyacentes, lo que a su vez determina si un acoplamiento es viable y funcional.
Fecha no fijada aún, pero ya definidos los marcos técnicos
El acto delegado que concreta la obligación de un pasaporte digital de producto para muebles aún no existe; el plan de trabajo ESPR 2025-2030 menciona 2028 como período previsto para su publicación. Mientras ese acto no se apruebe, tampoco está determinado qué datos específicos del grupo de productos son obligatorios ni en qué formato. Lo que sí está fijado ya son los requisitos técnicos generales del pasaporte recogidos en los artículos 10 y 11 del ESPR: estos se aplican a todos los productos sometidos a un acto delegado, luego también a los muebles en lo sucesivo. Esos marcos generales son conocidos ya y pueden utilizarse para reflexionar sobre la estructuración de los propios procesos de datos, aunque el contenido exacto del pasaporte de muebles aún no esté definido.
Cómo abordarlo en la práctica
Quien ahora se plantee un acoplamiento haría bien en examinar primero qué datos de producto ya están estructurados en el propio sistema ERP o de inventario: composición de materiales, origen de componentes, dimensiones, instrucciones de mantenimiento y similares. Esa es la base con la que se compone un pasaporte, ya sea manualmente o mediante acoplamiento. Después conviene averiguar en qué formato se registran esos datos y si ese formato se presta para intercambio con un sistema externo — piénsese en campos estructurados en lugar de texto libre. En esta plataforma el pasaporte se compone a partir de los datos que suministran el fabricante o importador; cómo discurre ese suministro exactamente y si hay disponible un acoplamiento automático para ello es una cuestión práctica que puede tratarse por separado. De cara al largo plazo, es prudente estructurar los datos de producto de modo que sean apropiados para un pasaporte digital sin grandes transformaciones, independientemente de que el suministro sea manual o se automatice posteriormente. Esto evita duplicar trabajo cuando entre en vigor la obligación para muebles.
Fundamento: artículos 10 y 11 del ESPR
El artículo 10 del ESPR (Reglamento (UE) 2024/1781) describe los requisitos que debe cumplir el pasaporte digital de productos, incluido el vínculo de datos a un número único de identificación del producto y la accesibilidad de esos datos durante la vida útil del producto. El artículo 11 del mismo reglamento se ocupa del diseño técnico y el funcionamiento del pasaporte, y contiene requisitos relativos a los estándares abiertos, la interoperabilidad y la legibilidad automática de los datos. Juntos, estos artículos no determinan cómo se proporcionan los datos, sino a qué forma técnica deben cumplir finalmente esos datos — y ese es precisamente el punto de partida para la pregunta de si y cómo es viable un vínculo con un sistema ERP o de inventario.
Qué puede hacer ahora
Mapee qué datos de productos ya existen en su propio sistema ERP o de inventario y en qué formato, y discuta con el proveedor del pasaporte — en este caso, esta plataforma — qué opciones de envío son prácticamente viables. Una vez que se publique el acto delegado para muebles, la fecha concreta y los requisitos exactos de datos aparecerán aquí; hasta entonces, lo más útil es preparar los datos propios de manera estructurada y transferible.
En qué se basa esto
- Reglamento (UE) 2024/1781 (ESPR), artículo 11 (diseño técnico y funcionamiento del pasaporte de producto digital)
- Reglamento (UE) 2024/1781 (ESPR), artículo 10 (requisitos para el pasaporte de producto digital)
El reglamento en sí está en EUR-Lex. Nos referimos a cada afirmación; no tiene que creernos.
Lo que debe hacer concretamente
Lo que se espera de usted
Una conexión entre su sistema ERP o de inventario y el pasaporte electrónico de productos es técnicamente a menudo posible y puede ahorrar mucho trabajo manual. El ESPR no prescribe cómo obtener sus datos o cómo gestionarlos internamente; el Reglamento establece requisitos para el pasaporte en sí, para lo que debe contener y cómo debe ser accesible. Esto significa que una conexión con un sistema propio no es un fin en sí mismo, sino un medio para cumplir esos requisitos.
El pasaporte debe cumplir con los requisitos técnicos, independientemente de la fuente de datos
El artículo 10 del ESPR (Reglamento (UE) 2024/1781) describe qué datos debe contener un pasaporte electrónico de productos y bajo qué condiciones debe cumplir, como exactitud e integridad. Para una empresa de 10 a 100 empleados, esto significa que el origen de los datos — ya sea que se introduzcan manualmente o que provengan automáticamente de un sistema ERP — no reduce lo que se espera del contenido. Una conexión, por lo tanto, no cambia la obligación; solo cambia cómo cumple prácticamente esa obligación.
El pasaporte debe cumplir con el diseño técnico que requiere el artículo 11
El artículo 11 del ESPR (Reglamento (UE) 2024/1781) trata sobre el diseño técnico y el funcionamiento del pasaporte electrónico de productos, incluida la forma en que se almacenan, intercambian y se ponen a disposición los datos a través del portador de datos. Para una conexión con un sistema propio, esto significa que la salida de esa conexión — los datos que finalmente llegan al pasaporte — debe encajar dentro del marco técnico que se aplica al pasaporte, como el modelo de datos utilizado y la forma de poner a disposición a través del código QR en el mueble. Un archivo de exportación de un paquete ERP rara vez es directamente un pasaporte; generalmente es una fuente que primero debe traducirse al formato correcto.
Cada conexión entrega datos que deben estar vinculados a un código de identificación único
Un sistema ERP o de inventario normalmente funciona con números de artículo internos o SKU. Estos no coinciden automáticamente con el código de identificación que requiere el pasaporte de producto. Al configurar una conexión, es importante determinar cómo cada producto recibe un código de identificación único y cómo se relaciona ese código con la codificación de artículos existente en su propio sistema. Sin esa traducción, existe el riesgo de que los números internos terminen accidentalmente en el pasaporte, o de que un pasaporte de producto no pueda identificarse correctamente con la línea de inventario correcta.
Dónde falla en la práctica
Sincronización automática sin punto de control. Una conexión que envía datos directamente del sistema ERP al pasaporte sin un paso intermedio parece eficiente, pero también significa que un error en el sistema de origen — un porcentaje de material introducido incorrectamente, un certificado vencido — se propaga automáticamente en un pasaporte publicado.
Confusión entre SKU interna y código de identificación público. Las empresas a veces utilizan el mismo número de artículo interno que código de identificación externo, sin verificar si ese número ya está en uso en otro lugar o si cumple con los requisitos. Esto ocurre especialmente en empresas que trabajan con GS1 Digital Link y deben alinear la conexión con él.
Ninguna conexión entre cambios de inventario y estado del pasaporte. Si un producto se retira de la producción o se reemplaza por una nueva variante, esto se registra a menudo en el sistema ERP, pero no conduce automáticamente a una actualización del pasaporte. La pregunta de si y cómo se pueden ajustar los datos después de la publicación se plantea entonces demasiado tarde, generalmente después de que un cliente o autoridad de vigilancia señala una discrepancia.
Insuficiente atención a los productos compuestos. Un sistema ERP generalmente registra piezas y variantes por separado, mientras que la pregunta de si el mueble en su conjunto o cada parte por separado necesita un pasaporte debe responderse por separado. Una conexión que se basa en la estructura del sistema de inventario corre entonces el riesgo de tomar la unidad incorrecta como punto de partida.
El acoplamiento se detiene cuando cambia el sistema o el proveedor. Cuando una empresa cambia de paquete ERP, modifica su proveedor de hosting, o deja de trabajar con un proveedor de TI determinado, no siempre se considera que el acoplamiento con el pasaporte debe volver a configurarse. Esto también afecta a la cuestión de qué sucede con el pasaporte si una empresa cesa sus actividades o cambia de forma jurídica.
Lo que puede documentar
- Un resumen de qué campos del sistema ERP o de inventario se adoptan automáticamente en el pasaporte, y qué campos se verifican siempre manualmente antes de la publicación.
- Una tabla de traducción documentada entre números de artículo internos y los códigos de identificación utilizados externamente, incluido el acuerdo sobre quién mantiene esta tabla actualizada.
- Un procedimiento para el momento en que un cambio en el sistema de origen — nuevo material, nuevo proveedor, composición modificada — justifique la revisión o actualización del pasaporte.
- Acuerdos con el proveedor de TI u hosting sobre qué sucede en caso de cambio de sistema, incluida la responsabilidad de transferir el acoplamiento.
- Un punto de control interno (por ejemplo, trimestral) en el que se verifique aleatoriamente si los datos del pasaporte publicado coinciden aún con el estado actual del sistema ERP.
- Documentación sobre el idioma o idiomas en que se suministran los datos desde el sistema ERP, en relación con la cuestión en qué idioma debe ofrecerse el pasaporte.
Ponemos a su disposición plantillas para varios de estos acuerdos, de modo que no sea necesario redactarlos desde cero para cada producto.
Esto no es asesoramiento jurídico. Esta página proporciona información general sobre la regulación de la que trata esta plataforma. No conocemos su situación. En caso de duda sobre su caso particular, consulte a un abogado o a la autoridad de supervisión competente.
Escrito con IA basado en las fuentes anteriores, revisado por una persona el 2026-08-22. ¿Hay algo que no sea correcto? Déjalo saber — las correcciones tienen prioridad.