B2B y EDI.
Un hub B2B único para todos tus trading partners.
Retail, logística, salud y automotriz operan con EDI desde hace décadas. En lugar de mantener integraciones bilaterales con cada partner, MuleSoft con Anypoint Partner Manager actúa como hub: recibe los documentos en X12, EDIFACT o el formato que sea, los traduce a tu modelo interno y los entrega al ERP. Onboarding de un partner nuevo en semanas, no meses.
¿Qué resuelve B2B y EDI con MuleSoft?
Las grandes cadenas de retail, los OEMs automotrices y las aseguradoras de salud imponen EDI. Sin un hub, cada partner termina siendo una integración bilateral frágil que duplica esfuerzo de operación y cobranza. MuleSoft actúa como hub B2B único: traduce entre estándares EDI, valida contra tu ERP, archiva y entrega los acknowledgments. Onboardear un partner nuevo se mide en semanas.
- Hub B2B único para todos los trading partners (retail, logística, salud, automotriz).
- Traducción entre EDI X12, EDIFACT, AS2, SFTP y modelo interno canónico.
- Acknowledgments automáticos (997, MDN), tracking de cada documento.
- Onboarding de partner nuevo en semanas, no meses.
Sistemas típicos involucrados
Las familias de sistemas que conviven en una operación B2B con múltiples partners.
Trading partners
Cadenas de retail, hubs EDI tradicionales (GXS / OpenText, IBM Sterling, SPS Commerce), partners logísticos y socios de la industria automotriz y de la salud.
ERP
SAP S/4HANA, SAP ECC, Oracle EBS, NetSuite y Microsoft Dynamics como sistema de registro al que se entregan los documentos traducidos.
WMS y TMS
Manhattan, JDA, Oracle TMS, BluJay, IBM Sterling para preparación de envíos y generación de ASN.
E-commerce
Vtex, Magento, Salesforce Commerce y otros canales digitales cuando hay drop-ship con marketplaces y partners.
Arquitectura objetivo
Anypoint Partner Manager como gateway B2B; flows EDI traducen al modelo canónico antes de tocar el ERP.
+----------------------------+
| Trading Partners |
| (retail, logistics, etc.) |
+--------------+-------------+
|
AS2 / SFTP / API
|
v
+----------------------------+
| B2B Gateway / Edge |
| (Anypoint Partner Mgr) |
| - Trading partner config|
| - Transport security |
| - Document tracking |
+--------------+-------------+
|
v
+----------------------------+
| EDI Translation Flows |
| (X12, EDIFACT modules) |
+--------------+-------------+
|
v
+----------------------------+
| Process APIs (B2B) |
| - Order intake |
| - ASN dispatch |
| - Invoice flow |
+--------------+-------------+
|
v
+----------------------------+
| System APIs (ERP, WMS) |
+----------------------------+System APIs
En B2B, las "System APIs" son partner adapters: por cada trading partner relevante hay configuración específica. Operaciones típicas: envío de PO, recepción de ASN, envío de invoice, recepción de 997.
Process APIs
b2b-order-intake-pa valida y crea sales order. b2b-shipment-dispatch-pa arma el ASN cuando despacha el WMS. b2b-invoice-pa transforma facturas del ERP a EDI 810 y dispatchea.
Experience APIs
Atípico en B2B porque los consumers son partners externos. Cuando el cliente ofrece API REST con OAuth a partners modernos además de EDI tradicional, esa REST es la Experience API.
Flujo paso a paso
Intake de un PO 850, creación de la sales order, dispatch del ASN y emisión del invoice.
- 1 El trading partner envía la orden de compra (PO 850) vía AS2 al endpoint del cliente.
- 2 Anypoint Partner Manager recibe el AS2, valida certificados, descomprime, descifra y devuelve el MDN como acuse técnico inmediato.
- 3 El gateway identifica al partner por el AS2-From y al document type por los headers ISA y GS del EDI.
- 4 Se dispara la Process API b2b-order-intake-pa, que parsea el EDI X12 850 y lo mapea a un objeto Order canónico interno.
- 5 La Process API valida que el cliente exista, que los productos existan, y que los precios coincidan con el contrato negociado en el catálogo del partner.
- 6 Si el resultado es OK, crea la sales order en el ERP vía sap-sd-sapi o equivalente, y devuelve el EDI 855 (PO Acknowledgment) al partner confirmando aceptación.
- 7 Si hay discrepancias (stock parcial, precio fuera de contrato), devuelve 855 con flag de excepción o rechazo según las reglas configuradas con cada partner.
- 8 Se devuelve el 997 (Functional Acknowledgment) confirmando que el documento se procesó correctamente en términos sintácticos.
- 9 Cuando el WMS confirma despacho, se dispara b2b-shipment-dispatch-pa, que arma el EDI 856 (ASN) y lo envía al partner.
- 10 Cuando el ERP genera factura, se dispara b2b-invoice-pa, que arma el EDI 810 (Invoice) y lo envía.
- 11 Cada documento queda archivado en el repositorio de auditoría con el control number, el timestamp y el estado de cada acknowledgment para cumplimiento regulatorio.
Patterns aplicados
Los patrones que sostienen la operación B2B en producción y bajo auditoría.
Pipes-and-filters
Receive → validate → translate → enrich → dispatch. Cada etapa es independiente y observable por separado.
Idempotency
Vía interchange control number: si llega el mismo ISA dos veces, se descarta el duplicado para no facturar dos veces.
Rejection y compensación
Si se acepta un PO y luego se descubre stock insuficiente, se emite EDI 860 (Purchase Order Change) con cancelación parcial.
Retry con backoff
Si el partner no responde a un AS2 de 856, se reintenta con espaciado creciente y, finalmente, alerta operacional.
Archive & quarantine
Archivos procesados van a /processed/, errores a /quarantine/ para review manual. La regulación EDI exige archivado por años.
Choreography
Cada socio emite eventos estandarizados, los demás reaccionan. Sin bus central rígido, con observabilidad cross-partner.
Cómo lo implementamos
Cinco fases del primer partner al onboarding masivo en semanas.
Inventario de partners y volúmenes
Mapeo de trading partners actuales y futuros, document types necesarios por cada uno (850, 855, 856, 810, 940, 997), volúmenes promedio y picos. Entregables: matriz de partners, business case.
Modelo canónico y configuración de partners
Diseño del modelo interno canónico (Order, Shipment, Invoice), mapping desde y hacia EDI X12 / EDIFACT, configuración de transports (AS2, SFTP, OFTP2 según industria), gestión de certificados.
Hub y onboarding del primer partner
Implementación del hub B2B sobre Anypoint Partner Manager o flows custom + módulo X12 / EDIFACT, primer partner en producción end-to-end con todos los document types acordados, tests con partner real en sandbox.
Go-live y onboarding por lotes
Go-live del primer partner con hypercare, incorporación de los siguientes partners en lotes de 3 a 5 con templates reutilizables. Plan de continuity para certificados AS2 vencidos.
Self-service de partners y CoE
Templates para incorporar partners nuevos en semanas, dashboard de salud por partner, capacitación del equipo del cliente para gestionar onboarding sin depender del partner externo.
Requisitos del proyecto
Lo que tiene que estar disponible del lado del cliente para arrancar.
Datos mínimos
Catálogo de productos con SKU y UPC, lista de precios negociados por partner, datos del partner (ISA ID, certificados AS2, contactos técnicos).
Licencias y capacidades
Anypoint Platform y Anypoint Partner Manager (recomendado para volumen alto), módulo X12 / EDIFACT, conectores al ERP y al WMS.
Integraciones típicas
ERP, WMS, TMS, e-commerce (cuando hay drop-ship), data warehouse para reporting B2B y dashboards de salud por partner.
Pre-requisitos organizacionales
Sponsor de B2B (típicamente supply chain o comercial), equipo de operaciones EDI, política de archivado y compliance regulatorio según país e industria.
KPIs operativos
Las métricas que típicamente se monitorean tras el go-live del hub B2B.
| KPI | Qué mide | Por qué importa |
|---|---|---|
| Documents per day per partner | Volumen de documentos procesados por trading partner por día. | Detecta caídas o picos anómalos de volumen que indican problemas en el partner o en el flujo. |
| Partner response time P95 | Tiempo desde el envío de un documento hasta la recepción del 997 del partner. | Indica salud del canal y permite alertar cuando un partner deja de responder. |
| Validation rejection rate | Porcentaje de documentos rechazados por validación de negocio o sintaxis. | Calidad de los partners y de los catálogos compartidos. Define fricción operativa. |
| Quarantine count | Cantidad de documentos en cuarentena pendientes de revisión manual. | Backlog operativo del equipo de B2B. Mide cuánto trabajo manual sobrevive. |
| Partner onboarding time | Semanas desde el kickoff con un partner nuevo hasta su primer documento productivo. | Diferencial competitivo: partners onboardeados rápido habilitan canales y revenue. |
| Certificate expiration risk | Días restantes hasta el vencimiento del próximo certificado AS2. | Evita la caída más común de los hubs B2B: un certificado vencido que rompe la operación con un partner crítico. |
Time-to-value: primer partner en producción tras 12 a 16 semanas. Los siguientes partners típicamente se incorporan en 4 a 6 semanas.
Cómo se mide: dashboard de salud por partner sobre Anypoint Monitoring, integrado con Splunk o Datadog para correlación con el ERP y WMS.
Preguntas frecuentes
Se puede sin, con flows custom más el módulo X12 o EDIFACT, pero el esfuerzo de mantenimiento es mayor. APM aporta gestión visual de trading partners, document types, mappings y monitoring listo para usar. La decisión depende del volumen de partners y de cuánto autoservicio quiere tener el equipo del cliente.
ANSI X12 (más común en EE. UU. y socios norteamericanos), EDIFACT (UE y muchos sectores en LATAM), TRADACOMS, y verticales como VDA, Odette y JAI para automotriz, HIPAA EDI 837 / 835 / 270 / 271 para salud. Los transports cubren AS2, SFTP, FTP / SSL, OFTP2, HTTPS y, cuando aún se usa, e-mail con attachment cifrado.
Diferenciamos por tipo. Un EDI mal formado se rechaza con 824 (Application Advice) o se loggea según política con cada partner. Una validación de negocio (SKU desconocido, precio fuera de contrato) se responde con 855 con código de excepción para que el partner pueda corregir. Los casos ambiguos van a quarantine para revisión humana.
Tras la primera implementación del hub, los siguientes partners se incorporan típicamente en 4 a 6 semanas, dependiendo del estándar EDI, del transport y de la calidad de la documentación que provee el partner. Los templates reutilizables y la configuración declarativa son lo que mueve la aguja.
Sí. El hub puede recibir y emitir documentos en JSON, CSV o XML sobre HTTPS / API REST cuando el partner es moderno y no quiere EDI. La traducción al modelo canónico interno es la misma. Lo que cambia es solo la capa de transport y el formato de la wire.
El dashboard de salud incluye un alertador de vencimiento con N días de antelación. La política recomendada es renovar y publicar el nuevo certificado al partner con al menos dos semanas de margen. Si un certificado vence sin previo aviso, los flows entran en error y se notifica al equipo de operaciones para coordinar el rollover con el partner.
Tu hub B2B, en producción cuando lo pide tu negocio.
Hablemos de tus partners y de los document types necesarios para arrancar.