¿Puedo vincular la ficha de especificaciones del producto a mi sistema ERP o de inventario?
El acoplamiento se vuelve concreto solo cuando existe la norma técnica
En este momento no es posible un acoplamiento directo entre el pasaporte digital del producto y un sistema ERP o de inventario, porque aún no se han establecido las especificaciones técnicas para ello. El ESPR (Reglamento (UE) 2024/1781) establece la base en los artículos 10 y 11: el pasaporte debe ser interoperable, basado en normas abiertas y legible por máquina. Esto significa que el intercambio automatizado con sistemas empresariales es en última instancia el punto de partida, no una excepción. Pero cómo se verá ese intercambio en la práctica — qué formato de archivo, qué interfaz, qué derechos de acceso — resulta solo de actos delegados por grupo de productos. Para acero y hierro, ese acto aún no existe.
Para qué se aplica y para qué no
Se trata de la cuestión de si los sistemas podrán recuperar o escribir datos del pasaporte de forma automática en el futuro. Esto afecta a la estructura técnica del pasaporte en sí, tal como se describe en el reglamento: cómo está organizado, quién puede acceder a él y en qué forma están disponibles los datos. No se trata de si un paquete ERP específico es adecuado, ni tampoco de una API o formato de datos concretos — esas decisiones aún no se han tomado. Tampoco se trata de la obligación en sí de tener un pasaporte; ese es un tema separado que se desarrollará por grupo de productos. Lo que se describe aquí es únicamente el principio de que el pasaporte debe ser legible por máquina e interoperable — la forma en que ese principio se concreta técnicamente para acero y hierro sigue siendo abierta.
Aún sin fecha fija, aún sin norma técnica fija
No hay aún una fecha en la que una norma técnica de acoplamiento para acero y hierro entre en vigor, porque esa norma es parte del acto delegado que aún debe publicarse. Según el plan de trabajo del ESPR para el período 2025-2030, se espera el primer acto delegado en 2026, con obligaciones que tendrán un período de implementación de dieciocho meses. Mientras ese acto no exista, está claro que el pasaporte debe ser interoperable y legible por máquina (artículos 10 y 11), pero no cómo se implementará técnicamente. Hasta entonces, el pasaporte funciona en la práctica como un documento que debe ser consultado por un humano a través del portador de datos QR, no como un flujo de datos automatizado hacia un sistema externo.
Qué significa esto para el enfoque
Para quienes ya están pensando en el acoplamiento con su propio sistema, el orden es el siguiente. Primero: no hay nada que construir todavía, porque no hay una norma para implementar. Segundo: poner en orden los datos de productos propios es útil ahora, independientemente de la forma técnica final — un conjunto claro y consistente de datos por producto (origen, composición, certificados) es la base en la que se apoyará cualquier mecanismo de acoplamiento futuro. Tercero: una vez que se publique el acto delegado para acero y hierro, quedará claro qué formato y qué método de acceso se aplican, y solo entonces se puede diseñar un acoplamiento concreto. Cuarto: hasta entonces, el pasaporte sigue siendo consultable a través del código QR que se adjunta al producto, lo que para la mayoría de las operaciones diarias en el comercio de acero y la transformación de metales ya es suficiente — el acoplamiento con un sistema ERP es entonces un avance en eficiencia para después, no un requisito previo para poder trabajar ahora con el pasaporte.
De dónde resulta esto: 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 de producto digital, incluida la interoperabilidad y el uso de estándares abiertos. El artículo 11 trata del diseño técnico y el funcionamiento del pasaporte, como los registros, el acceso a datos y la forma en que funciona el pasaporte. Ambos artículos contienen el principio de que el pasaporte debe ser apto para el procesamiento automático, pero la concreción de esto — la especificación técnica real por grupo de productos — se deja a los actos delegados que aún deben aparecer. Para la formulación precisa, el texto oficial del Reglamento es determinante.
Si desea prepararse ahora, lo mejor es mantener ya los datos propios de los productos de forma estructurada y completa, de modo que cuando aparezca la norma técnica, se puedan conectar sin demasiados trámites a lo que entonces se establezca. Esta página se actualizará tan pronto como se publique el acto delegado para hierro y acero y se conozcan los detalles técnicos.
En qué se basa esto
- Reglamento (UE) 2024/1781 (ESPR), artículo 11 (diseño técnico y funcionamiento del digital product passport)
- Regulación (UE) 2024/1781 (ESPR), artículo 10 (requisitos para el pasaporte digital del producto)
La verordening en sí está en EUR-Lex. Nos referimos a cada afirmación; no tiene que creernos.
Lo que usted debe hacer concretamente
Lo que se espera de usted
Los datos deben ser legibles y transferibles para máquinas
El artículo 10 del ESPR (Reglamento (UE) 2024/1781) establece que los datos del pasaporte digital del producto deben estar disponibles en un formato estructurado y legible para máquinas. Este es precisamente el punto de partida para la integración con un sistema propio: los datos que son legibles para máquinas son, en principio, también adecuados para fluir automáticamente dentro o fuera de un sistema ERP o de inventario. Para una empresa de 10 a 100 empleados, esto significa principalmente que la pregunta "¿se puede integrar esto?" no es en primer lugar una cuestión jurídica, sino técnica: ¿qué formato utiliza el pasaporte y puede el propio software leer o escribir ese formato? Véase también la página sobre en qué formato debo facilitar los datos para el pasaporte de producto.
El pasaporte debe ajustarse a una estructura técnica uniforme
El artículo 11 del ESPR trata del diseño técnico y funcionamiento del pasaporte, y remite a especificaciones técnicas que la Comisión elaborará con mayor detalle. Para la práctica de la integración, esto significa que no se puede simplemente entregar o recuperar "un archivo propio": hay una estructura estandarizada subyacente, probablemente basada en sistemas de identificación existentes. Quienes ya trabajan con un sistema de codificación de artículos harían bien en verificar cómo se alinea con la forma en que se asignarán códigos de identificación únicos en el futuro — véase cómo le doy a cada producto un código de identificación único. Un sistema ERP que ya funciona con códigos de producto unívocos y estables está en mejor posición para la integración que un sistema en el que los códigos varían por pedido o por cliente.
La integración se realiza a través de un soporte de datos, no a través de una conexión de base de datos directa
El artículo 11 también describe que el pasaporte es accesible a través de un soporte de datos en el producto. Este es un punto importante para la expectativa que una empresa puede tener sobre "integración": no se trata de una conexión de base de datos directa entre dos empresas, sino de una cadena en la que el soporte de datos (generalmente un código QR) remite a un pasaporte almacenado. La integración con un sistema ERP o de inventario ocurre en dos puntos: en la entrega de datos de productos desde el propio sistema a la parte que compila el pasaporte, y en la lectura de datos del pasaporte (por ejemplo, en la compra de acero) en el propio sistema. Más información sobre este soporte se encuentra en la página cómo llega el código QR del pasaporte de producto a mi acero.
Los datos deben mantenerse actualizados mientras el pasaporte existe
Del artículo 10 también se deduce que los datos del pasaporte deben ser correctos y estar actualizados mientras el pasaporte existe. Para una integración con un sistema de inventario, esto significa que una única entrega generalmente no es suficiente: si las propiedades de un lote de acero cambian o si se detecta un error, debe haber una manera de comunicarlo al lugar donde se aloja el pasaporte. Las empresas que integren su sistema ERP harían bien en verificar también cuánto tiempo debe mantenerse esa actualidad — véase cuánto tiempo debe estar disponible un pasaporte de producto.
Dónde se producen problemas en la práctica
Los códigos de artículo internos se confunden con la identificación oficial del producto. Un sistema ERP conoce un producto bajo una SKU interna, mientras que el pasaporte requiere un código de identificación diferente y único. Sin una tabla de traducción entre ambos, surge confusión en la integración, especialmente si un código interno cubre múltiples lotes.
Los cambios en el inventario no se transfieren a los datos del pasaporte. Un sistema de inventario registra, por ejemplo, que un lote de acero ha sido refundido, dividido o combinado, pero ese cambio no llega automáticamente al pasaporte. Esto influye fuertemente en la pregunta de si el acero se registra por lote o por unidad — véase ¿registro el acero por lote o por unidad? — ya que la unidad de registro en el sistema ERP debe alinearse con la unidad en la que se basa el pasaporte.
Los archivos de exportación del sistema ERP no se ajustan al formato requerido. Muchos paquetes ERP exportan por defecto en Excel, CSV o una estructura XML propia. Sin coordinación previa, ese archivo no resulta compatible con el formato necesario para el pasaporte, lo que provoca retrasos y trabajo manual adicional.
Se presupone que la integración funciona también sin conexión a internet. Algunos sistemas de inventario en la planta de producción funcionan parcialmente sin conexión, por ejemplo en una terminal de almacén. Esto plantea la cuestión de si el propio pasaporte también debe ser consultable sin conexión; se trata de una cuestión independiente que está separada de la integración con el sistema ERP. Véase ¿debe funcionar el pasaporte de producto sin conexión a Internet.
Los derechos de acceso entre sistemas no se regulan. Una integración significa que los datos fluyen entre dos o más sistemas, a menudo a través de un tercero que aloja el pasaporte. Si no se establece quién puede ver, modificar o transmitir cada dato, surge confusión sobre la responsabilidad en caso de error —una cuestión que afecta a cómo se aseguran los datos en tránsito, véase cómo aseguro que los datos del pasaporte de producto estén protegidos.
Lo que usted puede documentar
- Un resumen de qué campos en el sistema ERP o de inventario se corresponden con qué campos en el pasaporte del producto, incluida una tabla de traducción entre códigos de artículo internos y el código de identificación único del producto.
- Una descripción del formato de exportación que utiliza el sistema propio, y una comparación con el formato necesario para el pasaporte.
- Acuerdos con la parte que elabora u hospeda el pasaporte sobre la frecuencia y forma del intercambio de datos: una única vez en la creación, o de forma continua en caso de cambios.
- Un procedimiento para comunicar cambios en el inventario, composición de lotes o propiedades del producto a los datos del pasaporte, incluida la parte responsable de ello.
- Un resumen de quién dentro de la empresa tiene acceso a la integración entre el sistema propio y el pasaporte, y qué derechos conlleva.
- Un acuerdo establecido sobre qué ocurre con la integración y el flujo de datos cuando el pasaporte de un producto se modifica, se retira o se sustituye.
Esto no es asesoramiento jurídico. Esta página proporciona información general sobre la regulación que cubre esta plataforma. No conocemos su situación. Si tiene dudas sobre su propio caso, consulte a un abogado o a la autoridad supervisora competente.
Escrito con IA basado en las fuentes anteriores, revisado por una persona el 2026-08-22. ¿Hay algo que no sea correcto? Háganoslo saber — las correcciones tienen prioridad.