Todos los proveedores de DPP dicen «integración». Casi ninguno lo dice en serio.

La verdadera pregunta que se hacen los responsables de la toma de decisiones

Cuando un gerente de cumplimiento o un director de TI evalúa una plataforma de DPP, la conversación normalmente comienza con los requisitos de ESPR y termina en algún momento con una discusión sobre los protocolos de API. Ese es el nivel de abstracción incorrecto.

La pregunta que realmente importa es más sencilla: ¿su equipo tiene que introducir los datos del producto dos veces? ¿Una vez en su ERP y otra en la plataforma DPP?

Si la respuesta es afirmativa, se ha comprado un flujo de trabajo de cumplimiento que se ejecuta en paralelo a sus operaciones, y los sistemas paralelos divergen. Una composición del material que se actualiza en SAP pero que no se refleja en la DPP no es solo un inconveniente. Según el ESPR (Reglamento UE 2024/1781), el DPP debe reflejar el estado actual del producto, no su estado en el momento de la primera publicación. Si está desactualizado, estás incumpliendo las normas.

Esta es la razón por la que la arquitectura de integración de una plataforma DPP es más importante que su interfaz.

Qué significa realmente «integración»

El mercado tiene la costumbre de llamar a todo integración. Una plantilla CSV se denomina integración. Un conector de middleware de terceros se denomina integración. Un webhook que se activa una vez al día se denomina integración.

Hay una diferencia entre un complemento y una capa de plataforma.

Fluxy.One creó su conexión SAP como una capa nativa dentro de la plataforma, no como un conector externo que se encuentra entre dos sistemas, ni como una dependencia de middleware con sus propios modos de fallo y condiciones de licencia. La integración con SAP Business One ya está disponible: sincronización bidireccional de los datos maestros de los productos y los registros de lotes, sin pasos de exportación manuales y sin el desarrollo personalizado de ABAP por parte de SAP.

Para las empresas que utilizan SAP ECC (la versión más antigua y aún ampliamente implementada), la misma arquitectura llegará en el segundo trimestre de 2026 y funcionará a través de SAP Service Layer. Una vez más, no se requiere ningún desarrollo personalizado por ninguna de las partes. La plataforma absorbe la complejidad; su entorno de SAP permanece inalterado.

Odoo está en vivo. La importación de CSV y SFTP cubre cualquier ERP que pueda producir una exportación estándar, que es la mayoría de ellas, y para muchos fabricantes de tamaño mediano será la principal ruta de integración durante el primer o segundo año. Vale la pena tratarla con seriedad: una importación CSV bien estructurada con validación de campo e informes de errores es más fiable que una conexión de API mal implementada, y la importación masiva de Fluxy.One gestiona hasta 10 000 registros por lote con ambas.

La integración de Microsoft Dynamics está confirmada para julio de 2026, fecha que coincide con la fecha límite de certificación de proveedores de servicios DPP de la UE.

Qué significa realmente bidireccional en la práctica

Tomemos una situación concreta. Un fabricante actualiza la composición de un material en SAP: un proveedor cambia un componente, se revisa la lista de materiales y se guarda el registro. En una integración unidireccional, no ocurre nada por el lado del DPP. Alguien tiene que darse cuenta del cambio, iniciar sesión en la plataforma DPP, encontrar los SKU afectados y actualizarlos manualmente. En un catálogo de 300 modelos, se trata de una molestia manejable. En un catálogo de 1300 personas, se trata de un riesgo de cumplimiento, ya que la brecha entre lo que SAP sabe y lo que dice el DPP se ampliará cada vez que cambie un registro y nadie lo detecte.

La integración bidireccional cierra esa brecha estructuralmente, no mediante un proceso. Cuando el registro de un producto cambia en el ERP, la plataforma DPP lo detecta. Cuando un DPP se publica, valida, archiva o marca mediante una verificación de cumplimiento, el ERP refleja ese estado. El equipo de operaciones deja de mantener dos versiones del mismo producto.

Como Fluxy.One se basa en los estándares GS1 de forma nativa, no como una capa sobre un modelo de datos patentado, los cambios de estado se registran mediante EPCIS 2.0, el estándar GS1 para datos de eventos de la cadena de suministro. El EPCIS 2.0 (servicios electrónicos de información sobre códigos de productos) captura lo que le ocurrió a un producto, dónde, cuándo y por qué, en un formato que otros sistemas, autoridades aduaneras y organismos de vigilancia del mercado que cumplen con los requisitos del GS1 pueden leer directamente. Esto significa que el registro de eventos de un DPP que se publica, actualiza o archiva no es un registro específico de la plataforma. Es un flujo de eventos estandarizado e interoperable. Para las empresas que operan en varios mercados o socios comerciales, esa distinción es importante.

Esto es importante específicamente en el marco de la ESPR porque el reglamento exige que el DPP refleje el estado actual del producto, no su estado en el momento de la primera publicación. Un DPP que fue correcto en enero y erróneo en marzo no es un DPP que cumpla con las normas del mes de marzo. La sincronización bidireccional no es una función cómoda. Es la forma de mantener el registro actualizado sin añadir personal.

Un límite práctico que vale la pena mencionar: los sistemas ERP almacenan bien los datos maestros de los productos. Contienen la composición del material, los identificadores de lotes, los códigos de las instalaciones de producción y las estructuras de variantes. Lo que normalmente no contienen son datos específicos de DPP: los porcentajes de contenido reciclado en el formato que exige ESPR, los GLN (números de ubicación globales) de los proveedores tal como los define GS1 o los registros de eventos del ciclo de vida, como las reparaciones y la transferencia de propiedad. Estos datos deben añadirse a la capa de DPP por separado, normalmente durante la incorporación y la recopilación de datos de los proveedores. La integración automatiza lo que el ERP ya sabe. El resto es un enriquecimiento de una sola vez, no un ingreso manual continuo.

Los datos de DPP fluyen hacia fuera, no solo hacia

La mayoría de los fabricantes que piensan en la DPP se centran en el problema de la entrada: incluir los datos del producto en el pasaporte sin tener que reconstruir sus operaciones. Ese es el lugar correcto para empezar. Pero no es el panorama completo.

ESPR requiere recopilar datos estructurados y validados sobre cada producto de su catálogo: origen del material por lote, identificadores de proveedores, contenido reciclado, registros de las instalaciones de producción y eventos del ciclo de vida. Esos datos deben ser legibles por máquina, consultables y conservarse durante al menos diez años. Es una obligación de cumplimiento.

También es un conjunto de datos que la mayoría de las empresas no tienen actualmente en este formato: se almacena de forma centralizada, se valida según un esquema regulatorio y se vincula a SKU y lotes de producción individuales.

Un fabricante que construye esta infraestructura correctamente termina con algo útil más allá del código QR del producto. Composición de materiales en todo el catálogo, en un solo lugar. Origen del proveedor por lote, no enterrado en un sistema de compras. Los eventos del ciclo de vida (reparaciones, reventas, transferencias de propiedad) son agregados por actores autorizados a lo largo del tiempo y registrados como eventos EPCIS 2.0. Vale la pena hacer una pausa en este último punto: cada cambio de estado en la vida útil del producto se escribe en un registro de eventos estandarizado e inmutable que se almacena junto con el identificador del producto, no con la plataforma. Tanto un taller de reparación en Polonia como un reciclador en los Países Bajos pueden unirse a la misma cadena de eventos, en un formato que pueda leer cualquier sistema compatible con la GS1. Así es como luce la trazabilidad de la cadena de suministro cuando se basa en estándares abiertos y no en un esquema patentado por un proveedor.

Cómo se ve esto en la práctica hoy en día: Fluxy.One proporciona acceso a la capa de datos de DPP a través de las API estándar de Google. Las empresas que ya utilizan Looker Studio u otras herramientas del ecosistema de Google pueden conectarse sin necesidad de un desarrollo personalizado y crear sus propios informes a partir de datos de DPP en tiempo real. No se trata de un producto de análisis empaquetado, sino de un acceso mediante API a un conjunto de datos estructurado y validado, y lo que crees con él depende de las preguntas que te plantees.

Antes de finales de 2026, la plataforma añadirá una API de análisis dedicada y un entorno de pruebas para desarrolladores para la integración y las pruebas personalizadas. Es entonces cuando la capa de datos se puede programar correctamente para los equipos ajenos al ecosistema de Google.

Las empresas que tratan la DPP como una infraestructura de datos y no como una casilla de verificación de cumplimiento son las que obtienen algo a cambio del proceso. El reglamento obliga a recopilar los datos. Lo que hagas con ellos después de eso es opcional, pero la opción está ahí.

Cinco preguntas para cualquier proveedor de DPP sobre la integración

1 - ¿La conexión ERP está integrada en la plataforma o depende de un conector o middleware de terceros? Los conectores de terceros presentan sus propias consideraciones de confiabilidad, mantenimiento y licencia.

2 - ¿La sincronización es bidireccional o los datos solo fluyen en una dirección? La importación unidireccional significa que su ERP nunca sabrá lo que ocurre en el lado del DPP.

3 - ¿Qué ocurre cuando un registro de producto cambia en su ERP después de la publicación del DPP? ¿Existe una ruta de actualización automática o alguien tiene que activarla manualmente?

4 - ¿La integración está incluida en la suscripción o se trata de una tarifa de implementación independiente? Los alcances de integración personalizados tienen la costumbre de expandirse.

5 - ¿Puede acceder a la capa de datos de DPP para sus propios análisis o está bloqueada dentro de la propia interfaz de informes de la plataforma?

Las respuestas reducirán considerablemente el campo.

Descubra cómo Fluxy.One se conecta a su infraestructura ERP existente y qué puede hacer con los datos una vez que están allí. Obtenga una consulta gratuita.

Fluxy.One es una plataforma de pasaportes digitales de productos ESPR de la UE para fabricantes, importadores y distribuidores que se preparan para la normativa de productos de la UE. La plataforma cubre todo el ciclo de vida de la DPP, desde los datos maestros del producto y los códigos QR de GS1 Digital Link hasta la validación del cumplimiento normativo y la trazabilidad de la cadena de suministro, con integraciones nativas para SAP Business One, SAP ECC, Odoo y Microsoft Dynamics, y una capa de eventos EPCIS 2.0 nativa de GS1 para un registro estandarizado de los eventos de la cadena de suministro. Los clientes empresariales ya pueden conectar las herramientas de BI existentes a través de las API estándar de Google; para el cuarto trimestre de 2026 están programados una API de análisis dedicada y un entorno limitado para desarrolladores. Este artículo refleja la posición normativa y de la plataforma en mayo de 2026. Las leyes de implementación de la ESPR continúan desarrollándose; este artículo es de orientación, no de asesoramiento legal.