Parece irónico que la promesa de transmisión electrónica de transacciones del sistema de una compañía a proveedores y clientes no se cumpla realmente en mi experiencia. A menudo, los grandes clientes insisten en que los fabricantes más pequeños se capaciten para EDI a un gran costo utilizando un "VAN" (intermediario para convertir el mensaje del formato del cliente a uno que el pequeño fabricante puede procesar). Los cargos VAN se producen por transacción más una suscripción mensual. Los beneficios no se logran realmente para el fabricante más pequeño, simplemente agrega costos.

Para mí, lo mejor de EDI sería si no se requiriera VAN. Es por esto que mi esfuerzo ha sido crear los mensajes estándar completos de EANCOM. La dificultad con los estándares de transacción electrónicos es que son enormes y se requiere un gran esfuerzo de codificación para crear una implementación completa. El foco de webERP ha sido la creación de facturas electrónicas para los clientes y también la recepción de pedidos de los clientes.

El objetivo es automatizar el proceso para crear un pedido de cliente en webERP para maximizar los beneficios del EDI; de lo contrario, unmensaje EDI posiblemente no sea tan bueno como un pedido de fax o correo electrónico. Tengo un 60-70% creando un lector para EANCOM 2002, basado principalmente en un subconjunto de EDIFACT D96A.

Actualmente solo tengo INVOIC creando messages.thetable

EDI_ORDERS_Segs

Contiene el formato del mensaje ÓRDENES según EANCOM 2002.

También estoy a punto de crear un comando llamado EDIProcessOrders.php (este comando está en la distribución) que lee el formato del mensaje ORDEN y analiza todos los pedidos EDI entrantes en el directorio entrante. Intenta cubrir todo el mensaje ORDERS del estándar EANCOM. No está completo aunque mucho más del 50%.

He escrito algunas notas en el manual extraído aquí para el beneficio de las personas interesadas.