Intercambio electrónico de datos
EDI existe al menos desde principios de los 70 y existen muchos estándares EDI (incluidos X12, EDIFACT, ODETTE, etc.), algunos de los cuales abordan las necesidades de industrias o regiones específicas. También se refiere específicamente a una familia de normas. En 1996, el Instituto Nacional de Estándares y Tecnología definió el intercambio electrónico de datos como "el intercambio de computadora a computadora de un formato estandarizado para el intercambio de datos". EDI implica una secuencia de mensajes entre dos partes, cualquiera de las cuales puede servir como emisor o receptor. Los datos formateados que representan los documentos pueden transmitirse del autor al destinatario a través de telecomunicaciones o transportarse físicamente en medios de almacenamiento electrónico." Distinguió la mera comunicación electrónica o el intercambio de datos, especificando que 'en EDI, el procesamiento habitual de los mensajes recibidos es solo por computadora. La intervención humana en el procesamiento de un mensaje recibido generalmente está destinada solo para condiciones de error, para revisión de calidad y para situaciones especiales. Por ejemplo, la transmisión de datos binarios o textuales no es EDI según se define aquí, a menos que los datos se traten como uno o más elementos de datos de un mensaje EDI y normalmente no están destinados a la interpretación humana como parte del procesamiento de datos en línea." En resumen, EDI se puede definir como la transferencia de datos estructurados, mediante estándares de mensajes acordados, de un sistema informático a otro sin intervención humana.
Historia
Al igual que muchas otras tecnologías de la información tempranas, EDI se inspiró en los desarrollos de la logística militar. La complejidad del puente aéreo de Berlín de 1948 requirió el desarrollo de conceptos y métodos para intercambiar, a veces a través de un módem de teletipo de 300 baudios, grandes cantidades de datos e información sobre los bienes transportados. Estos conceptos iniciales luego dieron forma a los primeros estándares del TDCC (Comité de Coordinación de Datos de Transporte) en los EE. UU. Entre los primeros sistemas integrados que utilizaron EDI se encuentran Freight Control Systems. Uno de esos sistemas en tiempo real fue el esquema EDP de carga del aeropuerto de Londres (LACES) en el aeropuerto de Heathrow, Londres, Reino Unido, en 1971. Al implementar el método de entrada directa del comerciante (DTI), permitió a los agentes de carga ingresar información directamente en el sistema de procesamiento de aduanas., reduciendo el tiempo de despacho. El aumento del tráfico marítimo y problemas en las aduanas similares a los experimentados en el aeropuerto de Heathrow llevaron a la implementación de sistemas DTI en puertos individuales o grupos de puertos en la década de 1980.
Estándares
EDI proporciona una base técnica para "conversaciones" comerciales automatizadas; entre dos entidades, ya sean internas o externas. El término EDI abarca todo el proceso de intercambio electrónico de datos, incluida la transmisión, el flujo de mensajes, el formato del documento y el software utilizado para interpretar los documentos. Sin embargo, los estándares EDI describen el formato riguroso de los documentos electrónicos y los estándares EDI se diseñaron, inicialmente en la industria automotriz, para ser independientes de las tecnologías de comunicación y software.
Los documentos EDI generalmente contienen la misma información que normalmente se encontraría en un documento en papel utilizado para la misma función organizacional. Por ejemplo, un fabricante utiliza una orden de envío desde el almacén EDI 940 para indicarle a un almacén que envíe un producto a un minorista. Por lo general, tiene un 'envío a' dirección, un 'facturar a' dirección y una lista de números de productos (generalmente un UPC) y cantidades. Otro ejemplo es el conjunto de mensajes entre vendedores y compradores, como solicitud de cotización (RFQ), oferta en respuesta a RFQ, pedido de compra, confirmación de pedido de compra, aviso de envío, aviso de recepción, factura y aviso de pago. Sin embargo, EDI no se limita solo a los datos comerciales relacionados con el comercio, sino que abarca todos los campos, como la medicina (p. ej., registros de pacientes y resultados de laboratorio), transporte (p. ej., información de contenedores y modal), ingeniería y construcción, etc. En algunos casos, EDI se utilizará para crear un nuevo flujo de información comercial (que antes no era un flujo de papel). Este es el caso de la Notificación Anticipada de Envío (ASN) que fue diseñada para informar al destinatario de un envío, los bienes que se recibirán y cómo se empaquetan los bienes. Esto se complementa aún más con el uso por parte del envío de las etiquetas de envío que contienen un código de barras GS1-128 que hace referencia al número de seguimiento del envío.
Algunos conjuntos importantes de estándares EDI:
- El UN/EDIFACT recomendado por las Naciones Unidas es el único estándar internacional y predomina fuera de América del Norte.
- El estándar estadounidense ANSI ASC X12 (X12) es predominante en América del Norte.
- GS1 EDI set of standards developed the GS1 predominant in global supply chain
- El estándar TRADACOMS desarrollado por el ANA (Asociación Número de Artículo ahora conocida como GS1 UK) es predominante en la industria minorista del Reino Unido.
- El estándar ODETTE utilizado dentro de la industria automotriz europea
- El estándar VDA utilizado en la industria automotriz europea principalmente en Alemania
- HL7, un estándar de interoperabilidad semántica utilizado para datos sanitarios.
- HIPAA, The Health Insurance Portability and Accountability ACT (HIPAA), requiere millones de entidades sanitarias que transmiten electrónicamente datos para utilizar EDI en un formato estándar HIPAA.
- IATA Cargo-IMP, IATA Cargo-IMP representa a la Asociación Internacional de Transporte Aéreo Procedimientos de Cambio de Cargo. Es un estándar EDI basado en EDIFACT creado para automatizar y estandarizar el intercambio de datos entre aerolíneas y otras partes.
- NCPDP Script, SCRIPT is a standard developed and maintained by the National Council for Prescription Drug Programs (NCPDP). La norma define documentos para la transmisión electrónica de recetas médicas en los Estados Unidos.
- The NCPDP Telecommunications standard includes transactions for eligibility verification, claim and service billing, predetermination of benefits, prior authorization, and information reporting, and is used primarily in the United States.
- Edig@s (EDIGAS) es un estándar que se ocupa del comercio, el transporte (vía gasoducto o contenedor) y el almacenamiento de gas.
Muchos de estos estándares aparecieron por primera vez entre principios y mediados de la década de 1980. Los estándares prescriben los formatos, conjuntos de caracteres y elementos de datos utilizados en el intercambio de documentos y formularios comerciales. La lista completa de documentos X12 incluye todos los principales documentos comerciales, incluidas las órdenes de compra y las facturas.
El estándar EDI prescribe información obligatoria y opcional para un documento en particular y brinda las reglas para la estructura del documento. Los estándares son como códigos de construcción. Así como se pueden construir dos cocinas "a código" pero se ven completamente diferentes, dos documentos EDI pueden seguir el mismo estándar y contener diferentes conjuntos de información. Por ejemplo, una empresa de alimentos puede indicar la fecha de caducidad de un producto, mientras que un fabricante de ropa optaría por enviar información sobre el color y la talla.
Protocolos de transmisión
EDI se puede transmitir usando cualquier metodología acordada por el remitente y el destinatario, pero a medida que más socios comerciales comenzaron a usar Internet para la transmisión, surgieron protocolos estandarizados.
Esto incluye varias tecnologías como:
- mModem (sincrónico y sincronizado)
- FTP, SFTP y FTPS
- HTTP/HTTPS
- AS1
- AS2
- AS4
- OFTP (y OFTP2)
- Mobile EDI
Cuando algunas personas compararon los módems de protocolo síncrono de 2400 bit/s, los dispositivos CLEO y las redes de valor agregado utilizadas para transmitir documentos EDI con la transmisión a través de Internet, equipararon las tecnologías que no son de Internet con EDI y predijeron erróneamente que EDI en sí mismo sería reemplazada junto con las tecnologías que no son de Internet. En la mayoría de los casos, estos métodos de transmisión ajenos a Internet simplemente están siendo reemplazados por protocolos de Internet, como FTP, HTTP, telnet y correo electrónico, pero los documentos EDI aún permanecen.
En 2002, el IETF publicó RFC 3335, que ofrece un método estandarizado y seguro para transferir datos EDI por correo electrónico. El 12 de julio de 2005, un grupo de trabajo de la IETF ratificó la RFC4130 para transferencias HTTP EDIINT (también conocidas como AS2) basadas en MIME, y la IETF preparó una RFC similar para transferencias FTP (también conocidas como AS3). EDI a través de servicios web (también conocido como AS4) también ha sido estandarizado por el organismo de estándares OASIS. Si bien parte de la transmisión EDI se ha trasladado a estos protocolos más nuevos, los proveedores de redes de valor agregado permanecen activos.
Internet
A medida que más organizaciones se conectaban a Internet, con el tiempo la mayoría o todo el EDI se introdujo en él. Inicialmente, esto fue a través de convenciones ad hoc, como FTP sin cifrar de archivos de texto ASCII a una determinada carpeta en un determinado host, permitido solo desde ciertas direcciones IP. Sin embargo, el IETF ha publicado varios documentos informativos (las "Declaraciones de aplicabilidad"; consulte a continuación en Protocolos) que describen formas de utilizar los protocolos estándar de Internet para EDI.
A partir de 2002, Walmart ha impulsado AS2 para EDI. Debido a su importante presencia en la cadena de suministro global, AS2 se ha convertido en un enfoque comúnmente adoptado para EDI.
Especificaciones
Las organizaciones que envían o reciben documentos entre sí se denominan "socios comerciales" en terminología EDI. Los socios comerciales acuerdan la información específica que se transmitirá y cómo se debe utilizar. Esto se hace en especificaciones legibles por humanos (también llamadas Directrices de implementación de mensajes). Mientras que los estándares son análogos a los códigos de construcción, las especificaciones son análogas a los planos. (La especificación también puede llamarse "mapeo", pero el término mapeo generalmente se reserva para instrucciones específicas legibles por máquina que se le dan al software de traducción). tienen pautas de implementación de mensajes existentes que reflejan sus procesos comerciales para procesar EDI y, por lo general, no están dispuestos a modificar sus prácticas comerciales EDI para satisfacer las necesidades de sus socios comerciales. A menudo, en una empresa grande, estas pautas de EDI se redactarán de manera que sean lo suficientemente genéricas para que las utilicen diferentes sucursales o divisiones y, por lo tanto, contendrán información que no se necesita para un intercambio de documentos comerciales en particular. Para otras grandes empresas, pueden crear pautas EDI separadas para cada sucursal/división.
Transmisión: EDI Directo y VANs
Los socios comerciales son libres de utilizar cualquier método para la transmisión de documentos (como se describe anteriormente en la sección Protocolos de transmisión). Además, pueden interactuar directamente oa través de un intermediario.
EDI directo: punto a punto
Los socios comerciales pueden conectarse directamente entre sí. Por ejemplo, un fabricante de automóviles podría mantener un grupo de módems al que todos sus cientos de proveedores deben marcar para realizar EDI. Sin embargo, si un proveedor hace negocios con varios fabricantes, es posible que deba adquirir un módem diferente (o dispositivo VPN, etc.) y un software diferente para cada uno.
A medida que la tecnología web y EDI han evolucionado, han surgido nuevas tecnologías de software EDI para facilitar la EDI directa (también conocida como punto a punto) entre socios comerciales. El software EDI moderno puede facilitar los intercambios utilizando cualquier número de diferentes protocolos de transmisión de archivos y estándares de documentos EDI, lo que reduce los costos y las barreras de entrada.
Redes de valor añadido
Para abordar las limitaciones en la adopción de EDI entre pares, hace décadas se establecieron VAN (redes de valor agregado). Una VAN actúa como una oficina de correos regional. Recibe transacciones, examina el 'desde' y el 'a' información y dirige la transacción al destinatario final. Las VAN pueden proporcionar una serie de servicios adicionales, p. retransmitir documentos, proporcionar información de auditoría de terceros, actuar como puerta de enlace para diferentes métodos de transmisión y manejar el soporte de telecomunicaciones. Debido a estos y otros servicios que brindan las VAN, las empresas usan con frecuencia una VAN incluso cuando ambos socios comerciales usan protocolos basados en Internet. Las cámaras de compensación de atención médica realizan muchas de las mismas funciones que una VAN, pero tienen restricciones legales adicionales.
Las VAN pueden ser operadas por varias entidades:
- empresas de telecomunicaciones;
- grupo industrial consorcios;
- a large company interacting with its providers/vendors;
- proveedores de servicios gestionados.
Costos, compensaciones e implementación
Es importante tener en cuenta que existen ventajas y desventajas clave entre las VAN y el EDI directo y, en muchos casos, las organizaciones que intercambian documentos EDI pueden, de hecho, usar ambos en conjunto, para diferentes aspectos de sus implementaciones EDI. Por ejemplo, en EE. UU., la mayoría de los intercambios de documentos EDI utilizan AS2, por lo que una configuración de EDI directa para AS2 puede tener sentido para una organización con sede en EE. UU. Pero agregar capacidades OFTP2 para comunicarse con un socio europeo puede ser difícil, por lo que una VAN podría tener sentido para manejar esas transacciones específicas, mientras que EDI directo se usa para las transacciones AS2.
En muchos sentidos, una VAN actúa como un proveedor de servicios, lo que simplifica gran parte de la configuración para las organizaciones que buscan iniciar EDI. Debido al hecho de que muchas organizaciones que comienzan con EDI a menudo lo hacen para cumplir con los requisitos de un cliente o socio y, por lo tanto, carecen de experiencia interna en EDI, una VAN puede ser un activo valioso.
Sin embargo, las VAN pueden tener costos elevados. Las VAN suelen cobrar una tarifa de transacción por documento o incluso por artículo de línea para procesar transacciones EDI como un servicio en nombre de sus clientes. Esta es la razón principal por la que muchas organizaciones también implementan una solución de software EDI o eventualmente migran a una para parte o la totalidad de su EDI.
Por otro lado, implementar software EDI puede ser un proceso desafiante, según la complejidad del caso de uso, las tecnologías involucradas y la disponibilidad de experiencia en EDI. Además, hay requisitos de mantenimiento continuo y actualizaciones a considerar. Por ejemplo, el mapeo de EDI es una de las tareas de administración de EDI más desafiantes. Las empresas deben desarrollar y mantener mapas EDI para cada uno de sus socios comerciales (y, a veces, múltiples mapas EDI para cada socio comercial en función de los requisitos de cumplimiento de pedidos).
Interpretación de datos
El software de traducción EDI proporciona la interfaz entre los sistemas internos y el formato EDI enviado/recibido. Para un "entrante" documento, la solución EDI recibirá el archivo (ya sea a través de una red de valor agregado o directamente usando protocolos como FTP o AS2), tomará el archivo EDI recibido (comúnmente conocido como "sobre"), y validar que el socio comercial que envía el archivo es un socio comercial válido, que la estructura del archivo cumple con los estándares EDI y que los campos de información individuales se ajustan a los estándares acordados. Por lo general, el traductor creará un archivo de longitud fija, longitud variable o formato de etiqueta XML o "imprimir" el documento EDI recibido (para entornos EDI no integrados). El siguiente paso es convertir/transformar el archivo que crea el traductor a un formato que se pueda importar a los sistemas comerciales, aplicaciones o ERP de back-end de una empresa. Esto se puede lograr mediante el uso de un programa personalizado, un "mapeador" o un "mapeador gráfico integrado basado en estándares" utilizando un lenguaje de transformación de datos estándar como XSLT. El paso final es importar el archivo transformado (o la base de datos) al sistema back-end de la empresa.
Para un "saliente" documento, el proceso para EDI integrado es exportar un archivo (o leer una base de datos) de los sistemas de información de una empresa y transformar el archivo al formato apropiado para el traductor. A continuación, el software de traducción "validará" el archivo EDI enviado para asegurarse de que cumple con el estándar acordado por los socios comerciales, convierta el archivo a "EDI" formato (agregando los identificadores apropiados y las estructuras de control) y envíe el archivo al socio comercial (usando el protocolo de comunicaciones apropiado).
Otro componente crítico de cualquier software de traducción EDI es una "auditoría" de todos los pasos para mover documentos comerciales entre socios comerciales. La auditoría garantiza que se pueda rastrear cualquier transacción (que en realidad es un documento comercial) para garantizar que no se pierda. En el caso de que un minorista envíe una Orden de compra a un proveedor, si la Orden de compra se "pierde" en cualquier parte del proceso empresarial, el efecto es devastador para ambas empresas. Para el proveedor, no cumple con el pedido ya que no lo ha recibido, por lo que pierde negocios y daña la relación comercial con su cliente minorista. Para el minorista, tienen un corte de existencias y el efecto es pérdida de ventas, servicio al cliente reducido y, en última instancia, menores ganancias.
En terminología EDI, "entrante" y "saliente" se refieren a la dirección de transmisión de un documento EDI en relación con un sistema en particular, no a la dirección de mercancías, dinero u otras cosas representadas por el documento. Por ejemplo, un documento EDI que le indica a un almacén que realice un envío de salida es un documento de entrada en relación con el sistema informático del almacén. Es un documento de salida en relación con el fabricante o distribuidor que transmitió el documento.
Ventajas sobre los sistemas en papel
EDI y otras tecnologías similares ahorran dinero a la empresa al proporcionar una alternativa o reemplazar los flujos de información que requieren una gran cantidad de interacción humana y documentos en papel. Incluso cuando los documentos en papel se mantienen en paralelo con el intercambio EDI, p. los manifiestos de envío impresos, el intercambio electrónico y el uso de datos de ese intercambio reducen los costos de manejo de clasificación, distribución, organización y búsqueda de documentos en papel. EDI y tecnologías similares permiten que una empresa aproveche los beneficios de almacenar y manipular datos electrónicamente sin el costo de la entrada manual. Otra ventaja de EDI es la oportunidad de reducir o eliminar los errores de entrada manual de datos, como los errores de envío y facturación, porque EDI elimina la necesidad de volver a teclear los documentos en el lado de destino. Una ventaja muy importante de EDI sobre los documentos en papel es la velocidad con la que el socio comercial recibe e incorpora la información en su sistema, lo que reduce considerablemente los tiempos de ciclo. Por esta razón, EDI puede ser un componente importante de los sistemas de producción justo a tiempo.
Según el informe de Aberdeen de 2008 "Una comparación de la habilitación de proveedores en todo el mundo", solo el 34 % de las órdenes de compra se transmiten electrónicamente en América del Norte. En EMEA, el 36% de los pedidos se transmiten electrónicamente y en APAC, el 41% de los pedidos se transmiten electrónicamente. También informan que la solicitud de papel promedio para ordenar le cuesta a una empresa $37.45 en América del Norte, $42.90 en EMEA y $23.90 en APAC. Con una solicitud EDI a pedido, los costos se reducen a $23.83 en América del Norte, $34.05 en EMEA y $14.78 en APAC.
Barreras para la implementación
Existen algunas barreras para adoptar el intercambio electrónico de datos. Una de las barreras más significativas es el cambio del proceso comercial que lo acompaña. Es posible que los procesos comerciales existentes creados en torno al manejo de papel no sean adecuados para EDI y requieran cambios para adaptarse al procesamiento automatizado de documentos comerciales. Por ejemplo, una empresa puede recibir la mayor parte de sus productos por envío de 1 o 2 días y todas sus facturas por correo. Por lo tanto, el proceso existente puede suponer que los bienes se reciben normalmente antes de la factura. Con EDI, la factura generalmente se enviará cuando se envíen los bienes y, por lo tanto, requerirá un proceso que maneje una gran cantidad de facturas cuyos bienes correspondientes aún no se han recibido.
Otra barrera importante es el costo en tiempo y dinero en la configuración inicial. Los gastos preliminares y el tiempo que surgen de la implementación, personalización y capacitación pueden ser costosos. Es importante seleccionar el nivel correcto de integración para que coincida con los requisitos del negocio. Para una empresa con relativamente pocas transacciones con socios basados en EDI, puede tener sentido implementar "extraer y leer" soluciones, donde el formato EDI se imprime en forma legible por humanos, y las personas, en lugar de las computadoras, responden a la transacción. Otra alternativa son las soluciones EDI subcontratadas proporcionadas por las "Oficinas de servicios" de EDI. Para otras empresas, la implementación de una solución EDI integrada puede ser necesaria, ya que los aumentos en los volúmenes comerciales provocados por EDI los obligan a volver a implementar sus procesos comerciales de procesamiento de pedidos.
El principal obstáculo para una implementación exitosa de EDI es la percepción que muchas empresas tienen de la naturaleza de EDI. Muchos ven EDI desde la perspectiva técnica de que EDI es un formato de datos; sería más exacto adoptar la visión comercial de que EDI es un sistema para intercambiar documentos comerciales con entidades externas e integrar los datos de esos documentos en los sistemas internos de la empresa. Las implementaciones exitosas de EDI toman en cuenta el efecto que la información generada externamente tendrá en sus sistemas internos y validan la información comercial recibida. Por ejemplo, permitir que un proveedor actualice el sistema de cuentas por pagar de un minorista sin los controles y balances adecuados pondría a la empresa en un riesgo significativo. Las empresas nuevas en la implementación de EDI deben comprender el proceso comercial subyacente y aplicar el criterio adecuado.
Reconocimiento
A continuación se encuentran los acuses de recibo EDI comunes
- Estado de la comunicación – Indicar la transmisión completa
- MDN (Message Disposition Notification) – En AS2 solamente, indicar el mensaje es legible
- Reconocimiento funcional – típicamente "997" en ANSI, o "CONTRL" en EDIFACT, que indican que el contenido del mensaje se verifica contra su plantilla, y decir si la transacción se publica en el sistema electrónico del receptor.
- Reconocimiento del nivel de negocio – el indicador final muestra si la transacción es aceptada por el receptor o no.