ES

Inicio / Guía EDI / Integración EDI con el ERP

¿Cómo funciona la integración EDI con el ERP?

Para la integración EDI con el ERP hay tres vías habituales: una interfaz de programación (API), tablas de intercambio en una base de datos o el intercambio de ficheros. Cuál encaja lo decide normalmente el ERP: lo que ya ofrece casi siempre sale más barato que construir algo nuevo. Más importante que la vía técnica suele ser la correspondencia de los datos maestros, es decir, qué referencia de artículo, qué cliente y qué unidad se quieren decir en cada lado.

Actualizado 18 de octubre de 2026 · fokus it solutions, Jens Musleh

Dónde se sitúa la integración con el ERP en el flujo EDI

Una solución EDI tiene dos lados. Hacia fuera habla con el socio comercial, en su formato y por su canal de transmisión (vea Canales de transmisión). Hacia dentro habla con su ERP. En medio está el mapeo, que traduce un pedido EDIFACT a la estructura que entiende su ERP y, en sentido inverso, una factura del ERP al INVOIC del socio.

El socio no ve nada del lado del ERP. Para él solo cuenta que los mensajes lleguen a tiempo y completos. Para usted, el lado del ERP decide si los pedidos se dan de alta sin trabajo manual y si el aviso de expedición y la factura se generan automáticamente. Por eso algunos proveedores facturan la integración con el ERP por separado; el proveedor alemán EDI+EXPERTS, por ejemplo, indica para ello en su lista de precios un «individuelles Angebot» (presupuesto individual).

Tres vías para la integración EDI con el ERP

Por API o webhook

Muchos ERP recientes ofrecen una interfaz de programación sobre HTTP, a menudo como API REST. La solución EDI crea entonces el pedido directamente mediante una llamada, y el ERP responde al instante con éxito o error. Para el sentido contrario, el ERP puede disparar un webhook: ante un evento, como «entrega contabilizada», llama a una dirección del software EDI.

Es importante cómo se tratan las repeticiones. Si la conexión se corta después del envío, la solución EDI no sabe si el pedido se creó. Por eso la norma HTTP (RFC 9110) distingue métodos idempotentes, cuya repetición tiene el mismo efecto que una sola llamada. En la práctica significa que cada pedido necesita una clave única para que un segundo intento no genere un pedido duplicado.

Mediante tablas de intercambio (staging en base de datos)

Muchos ERP, sobre todo los más antiguos o los sectoriales, tienen tablas de importación propias. El software EDI escribe un pedido como registros en esas tablas, a menudo cabecera y líneas por separado, y rellena un campo de estado. Un programa del ERP recoge los registros, los valida, crea el pedido y escribe el resultado de vuelta.

La ventaja: el ERP conserva el control sobre sus reglas de validación, y el estado de cada registro es trazable. El inconveniente: la solución EDI necesita acceso a la base de datos, y el programa de recogida del ERP tiene que estar en marcha. No escriba nunca directamente en las tablas de pedidos propiamente dichas del ERP. Así se saltan sus validaciones, y una actualización del ERP puede romper la integración sin que nadie lo note.

Mediante ficheros

Casi cualquier ERP puede leer y generar ficheros, normalmente CSV, XML o JSON. El software EDI deja un fichero en una carpeta, en un servidor de ficheros o por SFTP, y el ERP lo importa de forma programada. En sentido contrario, el ERP exporta albaranes o facturas como fichero, que la solución EDI recoge.

Los ficheros son robustos y fáciles de revisar, porque se pueden abrir y leer. A cambio, la respuesta llega con retraso, y los errores de importación a menudo solo se ven en el registro del ERP. Por eso conviene acordar reglas fijas: nombres de fichero únicos, escribir con un nombre temporal y renombrar solo después, carpetas separadas para éxito y error.

IDoc como caso especial

En entornos SAP está muy extendido el IDoc (Intermediate Document). SAP lo describe como un contenedor para el intercambio de datos entre sistemas SAP y sistemas externos, compuesto por cabecera, segmentos de datos y registros de estado. Un IDoc es, por tanto, más un formato que una vía propia; según la configuración se transmite como fichero o mediante una interfaz.

Las tres vías comparadas

API o webhook Tablas de intercambio Fichero
Respuesta inmediata en cuanto el ERP ha procesado el registro con retraso, a menudo mediante registro
Búsqueda de errores mediante códigos de respuesta y registros estado por registro en la tabla leer el fichero, carpeta de errores
Requisito en el ERP API documentada tablas de importación y programa de recogida función de importación y exportación
Acceso del software EDI red y credenciales de la API acceso a la base de datos, a ser posible solo a esas tablas carpeta o cuenta SFTP
Evitar pedidos duplicados clave única por operación clave única en la tabla nombres de fichero únicos, archivado tras la importación
Adecuado para ERP modernos, ERP en la nube ERP con tablas de importación existentes casi cualquier ERP, también antiguos

El mapeo de datos maestros es el trabajo de verdad

La mayoría de los errores en la integración EDI con el ERP no surgen en la técnica, sino en la correspondencia de números y unidades.

  • Referencias de artículo: el socio pide con su número de material o con el GTIN; su ERP conoce su propia referencia de artículo. GS1 describe el GTIN como el número con el que una empresa identifica de forma inequívoca sus unidades comerciales. Necesita una tabla de correspondencias mantenida, en el ERP o en la solución EDI.
  • Socios y puntos de entrega: el socio indica comprador, punto de entrega y destinatario de la factura normalmente mediante GLN. Su ERP trabaja con números de cliente y direcciones de entrega. Cada GLN debe estar asignado a un registro; si no, la mercancía acaba en el lugar equivocado. Más información en GLN y otros identificadores.
  • Unidades: el socio pide en unidades sueltas y su ERP gestiona el artículo en cajas de doce. Sin conversión, no cuadran ni cantidades ni precios.
  • Precios y condiciones: si el precio del pedido difiere del precio del ERP, debe estar claro cuál prevalece y a quién se avisa.

Gestión de errores y pruebas

Prevea una vía para cada error. Un pedido con una referencia de artículo desconocida no puede desaparecer ni crearse a medias. Debe ir a una lista de errores con el fichero original y un mensaje en lenguaje claro, para que alguien pueda corregirlo y volver a cargarlo. Quién recibe cada aviso debe estar decidido antes del arranque.

Pruebe la integración primero contra una empresa de pruebas o un entorno de pruebas del ERP. Ejecute allí ejemplos reales de la guía de implementación EDI del socio, también los incómodos: anulaciones, entregas parciales, artículos desconocidos, mensajes duplicados. Solo cuando estos casos funcionen bien, la integración pasa a la empresa productiva. Qué puntos de la guía importan para ello lo muestra la lista de comprobación de la guía EDI.

Qué ofrece edi-service.eu en el lado del ERP

edi-service.eu conecta su ERP mediante tres adaptadores genéricos: un adaptador REST y webhook, tablas de intercambio en una base de datos y un adaptador de ficheros para CSV, XML o JSON. Un adaptador listo para un producto ERP concreto no forma parte del alcance, ni tampoco las adaptaciones en el propio ERP. La IA configura las correspondencias primero en modo TEST, y pasan a producción solo después de su aprobación. Lo que incluye el precio fijo está en Precio. Si quiere aclarar si su ERP ofrece una de las tres vías, puede enviar una solicitud.

Preguntas frecuentes

¿Qué interfaz necesita mi ERP para el EDI?

Su ERP necesita una forma de recibir pedidos y de emitir entregas o facturas: una API, tablas de importación o una interfaz de ficheros. Casi cualquier ERP ofrece al menos la importación de ficheros. Qué vías existen lo indica la documentación del ERP o lo sabe la persona que se ocupa de su ERP.

¿Tiene que entender el ERP el formato EDIFACT?

No. La traducción entre EDIFACT o VDA y el formato del ERP la hace el software EDI. El ERP solo ve su propia estructura, por ejemplo un fichero CSV o una llamada a la API.

¿Qué es el staging en base de datos?

Staging en base de datos significa que los mensajes se entregan a través de tablas intermedias en la base de datos. La solución EDI escribe en ellas, y un programa del ERP lee, valida y contabiliza. Así siguen vigentes las reglas de validación del ERP.

¿Cómo evito pedidos duplicados?

Cada mensaje necesita una clave única, por ejemplo socio más número de pedido. El software EDI y el ERP comprueban antes de crear el pedido si esa clave ya existe. Esto también protege cuando un socio envía el mismo pedido dos veces.

Fuentes

Enviar una solicitud · Preguntas frecuentes · Todos los artículos de la guía