qué intercambio funciona electronico ejemplos datos cómo como beneficios edi

edi - funciona - intercambio electronico de datos pdf



¿Por qué se sigue utilizando el EDI y cómo lidiar con él? (18)

"Si no está roto, no lo arregles".

La mayoría de estas organizaciones están procesando grandes cantidades de datos usando EDI, y no están dispuestos a cambiar a algo más moderno sin un motivo convincente. Y hacer las cosas más fáciles para los desarrolladores de terceros no suele calificar, es triste decirlo.

¿Por qué este formato arcaico todavía se usa frente a las tecnologías más fáciles de usar? ¿Proporciona algún beneficio que no estoy viendo? Parece que una gran cantidad de proveedores aún proporcionan datos solo en este formato, en lugar de algo más manejable y fácil de usar como XML; al menos, tendría sentido para mí ofrecer ambos formatos.

Además, ¿cuáles son algunas buenas formas de tratar y utilizar EDI cuando no tienes más remedio que usarlo? Algo como BizTalk está fuera de cuestión, ya que es demasiado caro. ¿Existen aplicaciones gratuitas / de código abierto que faciliten el trabajo con EDI?

EDI es prolífico en muchas industrias. Sería prohibitivamente costoso reemplazar una tecnología que ya funcionaba por una más nueva.

Considere esto, Walmart usa EDI para comunicarse con sus proveedores, tiendas, cadena de distribución, etc. Supongo que lidian con miles de proveedores. Cada uno de ellos ha invertido miles de dólares en tecnología EDI. Si Walmart decidió cambiarse a XML, es una decisión que afecta a miles de empresas, no solo a Walmart.

Esto es cierto para cualquier usuario de EDI. Después de todo, es un estándar utilizado entre los socios comerciales.

Estoy de acuerdo, EDI es un dolor para trabajar. Pero "de vuelta en el día", eso es todo lo que teníamos.

EDI es un formato muy compacto y se usa a menudo para mantener el uso del ancho de banda en el intercambio de datos lo más pequeño posible. Las aduanas alemanas, por ejemplo, lo utilizan en su sistema ATLAS para intercambiar un volumen muy elevado de datos todos los días.

Es difícil de analizar y difícil de leer, pero si el tamaño de los datos resultantes importa, puede ser una buena opción y es compatible con la mayoría de las aplicaciones empresariales más grandes.

EDI ha existido desde antes de XML. Además del hecho de que dos partes pueden prenegociar el formato EDI que funciona para ambos, también debe considerar la parte de la VAN (red de valor agregado).

En algunos casos, la VAN realiza la validación del mensaje, o incluso lee el mensaje y realiza acciones en él, como copiarlo a terceros en función de su contenido.

La única razón para usar EDI es porque "así es como siempre se ha hecho" y, por lo tanto, hay una gran cantidad de infraestructura existente para respaldarlo. ¿Por qué cambiar a XML cuando no es necesario? ¿Y cómo decir que XML no será reemplazado por JSON, que luego será reemplazado por otra cosa?

EDI no es tan difícil de entender una vez que te familiarizas con los delimitadores que utiliza. También podría preguntarse por qué alguien todavía estaría utilizando CSV o datos delimitados por tabuladores.

La respuesta es, probablemente, que esos formatos son "lenguajes específicos del dominio" definidos por el comité y estandarizados en una determinada industria, y que ya se ha invertido una gran cantidad de dinero para respaldar esos formatos. ¿Dónde está el caso de negocios para tirar todo de nuevo?

Soporte heredado

Tuve que usar EDI también y estoy de acuerdo. Usamos BizTalk para mapearlo, que funcionó bien. Muchos sistemas están basados ​​en EDI (mucho antes de XML).

Un poco de información para todos los interesados. EDI es básicamente un diseño por comité de formato de intercambio de datos que no solo establece reglas para el formato de datos (como XML), sino que también establece para definir cada documento que posiblemente pueda enviarse entre 2 compañías. Entonces, para cualquier dato que pudiera intercambiarse entre compañías, se les ocurrió una definición exacta de lo que se suponía que debía ser en cada uno de estos documentos. Por supuesto, nadie podía prever todos los datos que querían intercambiar 2 empresas. Así que terminas con compañías que usan campos que fueron definidos por una cosa, que se usan para otra información.

Con lo que terminó, es un formato de datos extremadamente intrincado, en el que muchas personas que lo usan no siguen los estándares, ya que necesitan enviar información personalizada, que el estándar no tiene en cuenta. Por lo tanto, al final, aún necesita hablar con cada compañía con la que desea tratar y descubrir todas las pequeñas idiosincrasias de su implementación, tal como lo haría si visitara a alguien con una interfaz XML personalizada. Excepto que en el caso de EDI, el formato es difícil de analizar y aún más difícil de escribir, por lo que terminas haciendo un montón de trabajo solo para enviar un documento, al hacer el mismo tipo de pensamiento con una solución XML personalizada habría dado lugar a muchas veces menos problemas.

Una palabra, Inercia. El desarrollo de los formatos EDI por comité entre varias empresas y organizaciones con diferentes agendas fue una pesadilla (es triste decir que he estado allí).

Pidiéndoles que los abandonen con otra ronda de comités que acuerden estándares de API de servicios web, va a tomar más tiempo, ¿cómo vendes la idea de reemplazar un formato electrónico por otro a un consejo no técnico? ¿Qué posible ventaja de buses les da? Originalmente, los beneficios del intercambio electrónico eran claros, pero reemplazar uno con otro no lo es. Estamos hablando de compañías realmente grandes aquí.

Una solución, aunque le cueste, es ir a una empresa como ADX , que tiene herramientas que puede usar para convertir formatos EDI a formatos más agradables como CSV. Dependiendo del volumen y tipo de transacciones que esté haciendo, esto puede ser a la vez asequible y mucho menos estresante. He usado sus productos en el pasado, y aunque les queda un poco de trabajo por configurar, funcionan bien y son muy estables. Debido a la historia de EDI, probablemente pueda encontrar cientos de otras compañías que ofrecen servicios similares.

Y cambiar a XML le daría qué: ¿un formato de línea ligeramente más fácil de depurar?

Generalmente lo configura y lo deja, no hay mucha necesidad de jugar con el feed EDI sin procesar, ciertamente no lo suficiente como para abandonar el estándar y comenzar de nuevo.
Hay muchos estándares, como FAX, que podrían hacerse más legibles, pero no hay necesidad urgente de cambiarlos.

Otra razón es que se trata de mensajes comerciales como el orden. facturas, notas de crédito, etc., hay mucho valor financiero en las transacciones y deben ser seguros, pero quizás lo más importante es que necesitan una validación y verificación de extremo a extremo, así como no repudio.

Por ejemplo, le envío un pedido por valor de medio millón de euros, me envía los productos, luego "pierdo" la información del pedido y le digo que no estoy pagando. La combinación de los estándares y los VANS hacen que esto sea casi imposible o al menos con un seguimiento de auditoría tal que se puedan rastrear los problemas. Esta es la razón por la cual el "Oh, dejen de usar xml e Internet en lugar de EDIFACT y VANS" tienden a fallar. Como alguien respondió, Inercia, pero es una inercia fundada en un sistema estable, eficaz, seguro, confiable y bien entendido.

Hacerlo a bajo precio no siempre es una opción.

Si me sirve de consuelo la primera vez que implementé EDI en el ''87, prácticamente no existía ningún software, así que obtuve las tablas de Interbridge y escribí mi propio analizador para el estándar TRADACOMS del Reino Unido utilizando el software Cognos y HP Mini, y funcionó bien. Suponiendo que está comerciando con otros socios EDI, el costo probablemente llegue al punto de necesitar usar una VAN.

En mi humilde opinión, hay varios problemas con EDIFACT.

  1. No es fácil analizar o generar un modelo de objeto a partir de él. Probablemente este no sea un gran problema ya que ahora hay un buen sistema que lo hace por usted eg smooks.org
  2. No es fácil de leer. Te acostumbras, pero XML es mucho más fácil de leer
  3. La validación no es tan fácil (comparar eso con la validación de XML)
  4. Hay demasiadas versiones y sabores diferentes, D95B, D96B, D00A, D00B, etc.
  5. Pero creo que el mayor problema es que todos están usando los estándares de manera diferente. Usan el mismo ''formato'' pero los campos se definen de manera diferente. Usamos EDIFACT para enviar y recibir mensajes desde Container Terminals y todos tienen pequeñas diferencias. Por ejemplo, todos usarían un CODECO D95B, pero para algunos terminales un cierto segmento es obligatorio mientras que para otros es opcional o incluso no está permitido que esté allí. Luego tiene segmentos que se usan de la misma manera pero el contenido es diferente.

Entonces para resumirlo: es un dolor en el cuello.

Edifact es uno de los mejores estándares cuando se trata de intercambio de documentos. La mayoría de los problemas provienen de socios comerciales que envían documentos no estandarizados.

Sí, es un formato un poco extraño y es tedioso trabajar con él si no conoce los pormenores, pero eso también se aplica a XML.

¿Realmente quieres XML sobre Edifact? Mire las normas XML hinchadas y difíciles de leer en las que peppol (compras públicas paneuropeas en línea) está trabajando.

Sí, está funcionando muy bien si no tienes ningún error en los sistemas, solucionar problemas de edfacts es mucho más fácil una vez que te acostumbras al formato que solucionar problemas con los documentos UBL.

¿Dice que tiene $ 0.00 para usar en el proyecto? Realmente debe considerar la cantidad de trabajo manual realizado en su empresa y el ahorro de costes que EDI puede ofrecer, un análisis de costo beneficio puede ser muy útil.

Porque es un estándar formalmente establecido (de hecho, un conjunto de estándares muy amplio e integral). Y ese es uno de los beneficios de un estándar: no necesitará cambiar nada durante mucho tiempo.

Y para cambiarlo, se necesita un acuerdo entre dos o más (a menudo miles y miles más) socios comerciales (incluidos quizás todos sus competidores) para aceptar.

Los formatos EDI tienen una relación señal-ruido mucho más alta (porque fueron diseñados cuando se consideró importante). Alguien que conoce y entiende EDI mirará su XML y dirá "¿Dónde está la carne de res (datos)?"

Muy pocos desarrolladores escriben sus propios analizadores. Hay muchos buenos mapeadores disponibles (y muchas aplicaciones heredadas y empresariales vienen con ellos integrados). Por lo tanto, hay mucho alivio disponible para su dolor (incluida al menos una aplicación de código abierto en SourceForge).

¿Qué tipo de información se puede intercambiar a través de EDI?

Una variedad de tipos de intercambio de información comercial está disponible a través de EDI, que incluye:

-•Infomación sobre reservas

- • Información del conocimiento de embarque

-•Facturación

-•Transferencia Electrónica de Fondos

- • Información del aviso de llegada

- • Información del estado del envío

¿Cómo beneficiaría EDI a mi empresa? - • Agiliza el proceso de comunicación entre usted y APL

- • Elimina la necesidad de volver a introducir datos en las claves, eliminando así los errores y la necesidad de volver a verificar la información

- • Elimina el manejo del papel y la necesidad de almacenamiento de documentos

- • Mejora el tiempo de turno y la precisión de sus datos

- • Elimina la necesidad de enviar faxes

Utilicé EDI (ANSI X12 y EDIFACT) en 2 proyectos sobre Logística de transporte marítimo y encontré que son muy útiles ya que la mayoría de los operadores marítimos y socios comerciales los aceptan como la forma estándar de comunicación entre sus diferentes sistemas.

Por lo tanto, el formato EDI se sigue utilizando y se seguirá utilizando, ya que es un estándar establecido y miles de empresas han desarrollado sistemas a su alrededor, y reemplazarlas es realmente un gran problema.