El término “EDI” tiene casi 50 años. Nació en los años 70 para eliminar el papel entre los sistemas de mainframe de retailers americanos y sus proveedores. ANSI X12 en Norte América, EDIFACT en Europa — estándares de intercambio electrónico que definían con precisión quirúrgica cómo debía verse un pedido de compra, una factura, un aviso de despacho.
Funciona. En el contexto correcto, EDI es una de las integraciones más confiables de la cadena de suministro global. La razón es simple: ambas partes hablan exactamente el mismo protocolo. No hay ambigüedad.
Pero ese es también su supuesto fundamental — y su limitación más importante en América Latina.
El supuesto silencioso del EDI
Para que EDI funcione, el emisor necesita un sistema capaz de generar documentos estructurados en el formato correcto. Un pedido X12 EDI 850 tiene segmentos, elementos y qualifiers específicos. Para producirlo, el emisor necesita software de traducción EDI, un mapeador configurado con los requerimientos del receptor, y un VAN (Value Added Network) o conexión AS2/SFTP para la transmisión.
En EE.UU., los grandes retailers (Walmart, Target, Home Depot) tienen el poder de negociación para exigirle esto a cada proveedor que quiera hacer negocios con ellos. El proveedor invierte en certificación EDI o pierde el contrato. La adopción se fuerza desde arriba.
En Venezuela, Colombia o Bolivia, esa ecuación no funciona de la misma manera. Un laboratorio farmacéutico no puede exigirle certificación EDI a una droguería regional con 12 empleados. Una distribuidora de consumo masivo no puede condicionar sus ventas a que el bodeguero del pueblo adopte SAP.
El resultado: la mayoría de los pedidos B2B en la región llegan fuera de los canales estructurados. Email, WhatsApp, llamada telefónica, PDF con formato propio. El EDI clásico resuelve las excepciones; el volumen sigue siendo manual.
Definición de EDI Asimétrico
EDI Asimétrico es la capacidad de recibir un pedido en cualquier formato que el cliente elija usar — WhatsApp, PDF, email, Excel, formulario web, llamada transcrita — y producir como salida un documento equivalente estructurado, listo para ingresar al ERP receptor.
La asimetría está en los canales de entrada: el emisor no necesita ser estructuralmente simétrico al receptor. El laboratorio tiene SAP; la farmacia tiene un Excel. El distribuidor tiene Profit Plus; el supermercado regional manda un audio. En EDI Asimétrico, esa diferencia de sofisticación técnica deja de ser un problema operacional.
Lo que no cambia es el resultado: el pedido que llega al ERP es tan preciso y trazable como si hubiera venido por EDI clásico. Código de producto correcto, cantidad correcta, unidad de medida correcta, lista de precios aplicada, bodega asignada.
Los tres componentes técnicos
Una arquitectura de EDI Asimétrico tiene tres capas:
1. Capa de captura multicanal
Conectores específicos para cada canal de entrada:
- WhatsApp Business API: recibe mensajes de texto, audio (con transcripción automática) e imágenes.
- Email IMAP: monitorea bandejas de entrada, extrae adjuntos (PDF, Excel, Word) y lee el cuerpo del mensaje.
- Procesamiento de PDF: parsea documentos de orden de compra de formato variable, sin depender de una plantilla fija.
- Formularios web: interfaz estructurada para clientes que prefieren un canal guiado.
Cada conector entrega al motor central el contenido crudo del pedido en texto plano. Aquí no hay inteligencia todavía — solo extracción.
2. Motor de interpretación cognitiva
Esta es la capa diferenciadora. No son reglas rígidas del tipo “si la columna B dice ‘cantidad’ entonces es el campo X”. Son modelos entrenados para:
- Identificar entidades: qué texto en el documento es un código de producto, qué es una cantidad, qué es una unidad de medida, qué es una descripción libre.
- Resolver ambigüedades: “el ibuprofeno de 400” se mapea al SKU correcto usando el catálogo del cliente y el historial de pedidos del comprador.
- Detectar inconsistencias: una cantidad de 2000 unidades para un producto que este cliente normalmente compra en lotes de 50 genera una alerta, no un pedido silencioso.
- Aplicar reglas de negocio: si el producto A no tiene stock, la regla configurada para este cliente puede ser ofrecer el producto sustituto B, o frenar el pedido para revisión humana.
El resultado de esta capa es un pedido estructurado internamente, con confianza asignada a cada campo interpretado. Los campos con alta confianza pasan automáticamente; los de baja confianza se escalan a revisión humana con contexto completo.
3. Adaptador de ERP
Una vez que el pedido está estructurado, el adaptador lo convierte al formato exacto que consume el ERP destino y ejecuta la transacción:
- SAP Business One: usa la Service Layer (API REST nativa de SAP B1) para crear órdenes de venta, verificar stock y aplicar condiciones comerciales del cliente.
- Profit Plus: integración via API o capa de base de datos según la versión del cliente.
- Oracle NetSuite, Odoo: adaptadores configurables por esquema.
El adaptador conoce las reglas de negocio específicas del cliente: qué lista de precios asignar según el segmento del comprador, qué bodega usar según la región de despacho, cómo manejar productos que no existen en el catálogo.
Qué no es EDI Asimétrico
Tres confusiones frecuentes:
No es OCR genérico. Un OCR extrae texto de imágenes o PDFs, pero no interpreta ese texto en el contexto de un negocio específico. La diferencia entre OCR y EDI Asimétrico es la misma diferencia entre transcribir un audio y entender lo que dice.
No es un chatbot. Los chatbots son interfaces conversacionales. EDI Asimétrico es un motor de procesamiento de transacciones. No responde preguntas — procesa pedidos.
No es RPA. La Automatización Robótica de Procesos copia datos de pantalla en pantalla, replicando los movimientos de un humano. Es frágil (un cambio de interfaz rompe el robot), lenta (ejecuta paso a paso) y no interpreta. EDI Asimétrico trabaja con APIs y Service Layers del ERP, no con la interfaz gráfica.
El principio de Certeza B2B
En industrias como la farmacéutica, un pedido mal procesado tiene consecuencias que van más allá del costo financiero. Despachar el medicamento equivocado o en la dosis incorrecta es un problema de salud pública, no solo operacional.
Por eso en Greicodex aplicamos lo que llamamos Certeza B2B: el sistema garantiza que cada transacción que llega al ERP es correcta, o levanta una excepción trazable con contexto completo para revisión humana. No hay pedidos que “se procesaron de la mejor manera posible con la información disponible”. Hay pedidos confirmados o pedidos en revisión.
Eso implica que el motor de interpretación no maximiza el porcentaje de pedidos procesados automáticamente — maximiza el porcentaje de pedidos correctos. La tasa de automatización importa, pero la tasa de precisión es no negociable.
Todo el procesamiento es auditable. Cada decisión tomada por el sistema tiene un registro: qué texto llegó, cómo se interpretó, con qué nivel de confianza, qué regla de negocio se aplicó. Ese registro está disponible para el cliente en tiempo real. No hay caja negra.
Un caso concreto: Pharma Conecta
La arquitectura de EDI Asimétrico que describimos aquí no es teórica. Pharma Conecta es una implementación real de estos principios aplicados a un call center farmacéutico venezolano.
En ese caso específico, el canal de entrada no es el canal externo del cliente (el emisor del pedido es el operador del call center, no la droguería), pero el principio es el mismo: recibir información no completamente estructurada — una llamada telefónica — y producir una orden perfecta en el ERP, con verificación de stock, lista de precios y trazabilidad completa.
El artículo siguiente describe cómo funciona ese sistema en detalle.