Distribución · EDI · ERP
EDI en distribución: automatizar pedidos y facturas sin perder control
Cómo pasar de ORDERS a INVOIC con validaciones, correspondencias, control de duplicados y trazabilidad hasta almacén, expedición, factura y cobro.

Cuando un cliente importante envía cientos de pedidos, volver a teclearlos deja de ser una tarea administrativa y se convierte en un riesgo operativo. Una referencia mal copiada, una tarifa incorrecta o un pedido importado dos veces puede afectar a stock, expedición, factura y cobro.
EDI permite que las aplicaciones intercambien documentos estructurados. El estándar UN/EDIFACT mantenido por Naciones Unidas incluye mensajes como ORDERS para pedidos e INVOIC para facturas. No se trata de cambiar un PDF por un fichero: el sistema receptor debe entender, validar y continuar el proceso.
El recorrido útil: del fichero al cobro
Recibir
Registrar origen, fecha, nombre y huella del fichero.
Resolver
Relacionar cliente, centro, artículos, unidades y precio.
Operar
Crear pedido y continuar con stock, picking y expedición.
Responder
Facturar, generar INVOIC y conservar la trazabilidad.
El valor aparece porque EDI no vive aislado. Alimenta ventas, almacén, logística, facturación, contabilidad y cobros. Si el intercambio termina en una carpeta y el equipo debe reconstruir el proceso, la automatización está incompleta.
Siete decisiones que hay que cerrar antes de programar
Documentos
Pedidos y facturas suelen ofrecer un retorno claro; avisos de expedición o inventario pueden añadirse después.
Interlocutores
Hay que identificar empresa, centros de entrega, almacenes y puntos operacionales.
Artículos
Se resuelven referencias del cliente, códigos de barras, variantes, cajas y unidades.
Precio
Debe acordarse si manda el mensaje, la tarifa ERP o una validación con tolerancias.
Incidencias
Una línea desconocida necesita estado, causa comprensible y cola de revisión.
Duplicados
Emisor, tipo y número documental deben impedir el reprocesado funcional.
Qué debe pasar cuando algo no encaja
| Situación | Respuesta incorrecta | Control recomendable |
|---|---|---|
| Referencia desconocida | Crear una línea incompleta o ignorarla. | Bloquear o enviar a revisión con motivo visible. |
| Pedido reenviado | Crear un segundo documento. | Reconocer la clave funcional y registrar el duplicado. |
| Precio diferente | Aceptar silenciosamente cualquier importe. | Aplicar la regla pactada y una tolerancia documentada. |
| Centro no resuelto | Usar una dirección genérica. | Detener el pedido y completar la correspondencia. |
| Fallo de salida | Perder la factura INVOIC. | Estado pendiente, registro del error y reintento seguro. |

El pedido EDI entra en un circuito real
Después de validarse, el documento continúa con cantidades pendientes, albaranes, preparación, expedición y facturación.
Pantalla real de ERTIA ERP.
Cómo medir si EDI funciona
Además del porcentaje automático, conviene medir incidencias por causa, tiempo desde la recepción hasta el pedido, líneas pendientes de correspondencia, diferencias de precio y conciliación entre documentos recibidos y facturas emitidas.
Un arranque prudente reduce el riesgo
Empieza con un cliente, un mensaje y un conjunto controlado de artículos. Prueba un pedido correcto, otro con una referencia desconocida y un reenvío duplicado. Compara los resultados y valida la factura de salida. Cuando el circuito sea estable se incorporan más centros, clientes y documentos.
ERTIA permite importar pedidos EDI, resolver cliente y punto operacional, controlar duplicados, utilizar el precio recibido o la tarifa correspondiente y conservar la traza de los archivos. En salida puede generar facturas INVOIC D93A/EAN007. El pedido continúa por el circuito normal del ERP.
EDI, API y portal: no resuelven exactamente lo mismo
| Canal | Cuándo encaja | Pregunta clave |
|---|---|---|
| EDI | Interlocutores que ya trabajan con mensajes y acuerdos normalizados. | ¿Qué versión, guía y reglas aplica cada cliente? |
| API | Integraciones más directas entre aplicaciones con servicios disponibles. | ¿Cómo se autentica, versiona y reintenta cada operación? |
| Portal | Clientes o proveedores que necesitan introducir o consultar información manualmente. | ¿Qué acciones puede hacer cada perfil y qué vuelve al ERP? |
| Archivo acordado | Volumen moderado o sistema heredado sin otras interfaces. | ¿Cómo se valida, identifica y archiva cada intercambio? |
La elección no debería basarse únicamente en la tecnología disponible. Hay que valorar número de interlocutores, volumen, frecuencia, criticidad, capacidad del receptor y coste de mantener las correspondencias. En muchos proyectos conviven varios canales y todos deben terminar en el mismo modelo de documentos del ERP.
Preguntas que revelan el alcance real
¿Quién resuelve una referencia nueva?
Debe existir un responsable y una pantalla o informe donde completar la equivalencia sin modificar código.
¿Cómo se concilia la salida?
No basta con crear INVOIC: conviene comparar facturas emitidas, ficheros generados, envíos realizados y respuestas recibidas.
¿Qué ve soporte?
Fecha, interlocutor, documento, estado, error y reintentos deben poder consultarse sin buscar en carpetas del servidor.
¿Qué cambia al añadir un cliente?
Las reglas reutilizables deben separarse de formatos y particularidades para que cada alta no sea un proyecto desde cero.