Intercâmbio eletrônico de dados

Intercâmbio eletrônico de dados (EDI) é o conceito de negócios que comunicam eletronicamente informações que eram tradicionalmente comunicadas em papel, como ordens de compra, avisos de remessa antecipada e faturas. Padrões técnicos para EDI existem para facilitar as partes que negociam tais instrumentos sem ter que fazer acordos especiais.

O EDI existe pelo menos desde o início dos anos 70, e existem muitos padrões de EDI (incluindo X12, EDIFACT, ODETTE, etc.), alguns dos quais atendem às necessidades de indústrias ou regiões específicas. Também se refere especificamente a uma família de normas. Em 1996, o Instituto Nacional de Padrões e Tecnologia definiu o intercâmbio eletrônico de dados como "o intercâmbio de computador para computador de um formato padronizado para troca de dados". EDI implica uma sequência de mensagens entre duas partes, qualquer uma das quais pode servir como originador ou destinatário. Os dados formatados que representam os documentos podem ser transmitidos do originador ao destinatário por meio de telecomunicações ou transportados fisicamente em mídia de armazenamento eletrônico." Distinguiu a mera comunicação eletrônica ou troca de dados, especificando que "no EDI, o processamento usual das mensagens recebidas é apenas por computador. A intervenção humana no processamento de uma mensagem recebida é normalmente destinada apenas para condições de erro, para revisão de qualidade e para situações especiais. Por exemplo, a transmissão de dados binários ou textuais não é EDI conforme definido aqui, a menos que os dados sejam tratados como um ou mais elementos de dados de uma mensagem EDI e não sejam normalmente destinados à interpretação humana como parte do processamento de dados online." Em suma, o EDI pode ser definido como a transferência de dados estruturados, por padrões de mensagem acordados, de um sistema de computador para outro sem intervenção humana.

História

Como muitas outras tecnologias de informação iniciais, o EDI foi inspirado por desenvolvimentos na logística militar. A complexidade do transporte aéreo de Berlim de 1948 exigiu o desenvolvimento de conceitos e métodos para trocar, às vezes mais de um modem de teletipo de 300 baud, grandes quantidades de dados e informações sobre mercadorias transportadas. Esses conceitos iniciais posteriormente moldaram os primeiros padrões TDCC (Transportation Data Coordinating Committee) nos EUA. Entre os primeiros sistemas integrados usando EDI estavam os Freight Control Systems. Um desses sistemas em tempo real foi o London Airport Cargo EDP Scheme (LACES) no Aeroporto de Heathrow, Londres, Reino Unido, em 1971. A implementação do método direct trader input (DTI) permitiu que os despachantes inserissem informações diretamente no sistema de processamento alfandegário., reduzindo o tempo de desembaraço. O aumento do tráfego marítimo e problemas alfandegários semelhantes aos do aeroporto de Heathrow levaram à implementação de sistemas DTI em portos individuais ou grupos de portos na década de 1980.

Padrões

EDI fornece uma base técnica para "conversas" comerciais automatizadas; entre duas entidades, internas ou externas. O termo EDI abrange todo o processo de intercâmbio eletrônico de dados, incluindo a transmissão, o fluxo de mensagens, o formato do documento e o software usado para interpretar os documentos. No entanto, os padrões EDI descrevem o formato rigoroso de documentos eletrônicos, e os padrões EDI foram projetados, inicialmente na indústria automotiva, para serem independentes das tecnologias de comunicação e software.

Os documentos EDI geralmente contêm as mesmas informações que normalmente seriam encontradas em um documento em papel usado para a mesma função organizacional. Por exemplo, um pedido de envio do armazém EDI 940 é usado por um fabricante para instruir um armazém a enviar um produto a um varejista. Ele normalmente tem um 'enviar para' endereço, um endereço de 'faturamento' endereço e uma lista de números de produtos (geralmente um UPC) e quantidades. Outro exemplo é o conjunto de mensagens entre vendedores e compradores, como solicitação de cotação (RFQ), lance em resposta à RFQ, pedido de compra, confirmação do pedido de compra, aviso de remessa, aviso de recebimento, fatura e aviso de pagamento. No entanto, o EDI não se limita apenas a dados de negócios relacionados ao comércio, mas abrange todos os campos, como medicina (por exemplo, registros de pacientes e resultados de laboratório), transporte (por exemplo, contêiner e informações modais), engenharia e construção, etc. Em alguns casos, O EDI será usado para criar um novo fluxo de informações de negócios (que antes não era um fluxo de papel). É o caso da Notificação Antecipada de Embarque (ASN), que foi criada para informar o destinatário sobre uma remessa, as mercadorias a serem recebidas e como as mercadorias são embaladas. Isso é ainda complementado com o uso da remessa das etiquetas de remessa contendo um código de barras GS1-128 referenciando o número de rastreamento da remessa.

Alguns conjuntos principais de padrões EDI:

• A UN/EDIFACT recomendada pela ONU é o único padrão internacional e é predominante fora da América do Norte.
• O padrão americano ANSI ASC X12 (X12) é predominante na América do Norte.
• O conjunto de normas GS1 EDI desenvolveu o predomínio GS1 na cadeia de abastecimento global
• O padrão TRADACOMS desenvolvido pela ANA (Associação de Número de Artigo agora conhecida como GS1 UK) é predominante na indústria de varejo do Reino Unido.
• O padrão ODETTE utilizado na indústria automotiva europeia
• O padrão VDA usado na indústria automotiva europeia principalmente na Alemanha
• HL7, um padrão de interoperabilidade semântica usado para dados de saúde.
• O HIPAA, O ACT de Portabilidade e Responsabilidade de Seguros de Saúde (HIPAA), requer milhões de entidades de saúde que transmitem eletronicamente dados para usar o EDI em um formato padrão HIPAA.
• IATA Cargo-IMP, IATA Cargo-IMP significa International Air Transport Association Cargo Interchange Message Procedimentos. É um padrão EDI baseado no EDIFACT criado para automatizar e padronizar a troca de dados entre companhias aéreas e outras partes.
• NCPDP Script, SCRIPT é um padrão desenvolvido e mantido pelo Conselho Nacional de Programas de Prescrição de Medicamentos (NCPDP). O padrão define documentos para transmissão eletrônica de prescrições médicas nos Estados Unidos.
• O padrão de Telecomunicações NCPDP inclui transações para verificação de elegibilidade, cobrança de pedidos e serviços, predeterminação de benefícios, autorização prévia e relatórios de informação, e é usado principalmente nos Estados Unidos.
• Edig@s (EDIGAS) é um padrão que lida com comércio, transporte (via pipeline ou recipiente) e armazenamento de gás.

Muitos desses padrões apareceu pela primeira vez em meados da década de 1980. Os padrões prescrevem os formatos, conjuntos de caracteres e elementos de dados usados na troca de documentos e formulários de negócios. A lista completa de documentos X12 inclui todos os principais documentos de negócios, incluindo ordens de compra e faturas.

O padrão EDI prescreve informações obrigatórias e opcionais para um documento específico e dá as regras para a estrutura do documento. Os padrões são como códigos de construção. Assim como duas cozinhas podem ser construídas "a código" mas parecem completamente diferentes, dois documentos EDI podem seguir o mesmo padrão e conter diferentes conjuntos de informações. Por exemplo, uma empresa de alimentos pode indicar a data de validade de um produto, enquanto um fabricante de roupas escolheria enviar informações de cor e tamanho.

Protocolos de transmissão

O EDI pode ser transmitido usando qualquer metodologia acordada entre o remetente e o destinatário, mas à medida que mais parceiros comerciais começaram a usar a Internet para transmissão, surgiram protocolos padronizados.

Isso inclui várias tecnologias, como:

• mModem (assíncrono e síncrono)
• FTP, SFTP e FTPS
• Email
• HTTP/HTTPS
• AS1
• AS2
• AS4
• OFTP (e OFTP2)
• EDI móvel

Quando algumas pessoas compararam os modems de protocolo sincronizado 2400 bits, dispositivos CLEO e redes de valor agregado usadas para transmitir documentos EDI para transmitir através da Internet, eles equiparam as tecnologias não-Internet com EDI e previram erroneamente que o próprio EDI seria substituído junto com as tecnologias não-Internet. Na maioria dos casos, esses métodos de transmissão não-internet estão simplesmente sendo substituídos por protocolos de Internet, como FTP, HTTP, telnet e e-mail, mas os próprios documentos EDI ainda permanecem.

Em 2002, o IETF publicou o RFC 3335, oferecendo um método seguro e padronizado de transferência de dados EDI via e-mail. Em 12 de julho de 2005, um grupo de trabalho da IETF ratificou a RFC4130 para transferências HTTP EDIINT (também conhecidas como AS2) baseadas em MIME, e a IETF preparou uma RFC semelhante para transferências FTP (também conhecidas como AS3). EDI via web services (também conhecido como AS4) também foi padronizado pelo corpo de padrões OASIS. Embora algumas transmissões EDI tenham mudado para esses protocolos mais recentes, os provedores de redes de valor agregado permanecem ativos.

Internet

À medida que mais organizações se conectavam à Internet, eventualmente a maior parte ou todo o EDI foi enviado para ela. Inicialmente, isso acontecia por meio de convenções ad hoc, como FTP não criptografado de arquivos de texto ASCII para uma determinada pasta em um determinado host, permitido apenas a partir de determinados endereços IP. No entanto, o IETF publicou vários documentos informativos (as "Declarações de aplicabilidade"; veja abaixo em Protocolos) descrevendo maneiras de usar protocolos padrão da Internet para EDI.

A partir de 2002, o Walmart empurrou AS2 para EDI. Devido à sua presença significativa na cadeia de abastecimento global, AS2 tornou-se uma abordagem comumente adotada para EDI.

Especificações

As organizações que enviam ou recebem documentos umas das outras são chamadas de "parceiros comerciais" na terminologia EDI. Os parceiros comerciais concordam com as informações específicas a serem transmitidas e como elas devem ser usadas. Isso é feito em especificações legíveis por humanos (também chamadas de Diretrizes de Implementação de Mensagens). Enquanto os padrões são análogos aos códigos de construção, as especificações são análogas aos projetos. (A especificação também pode ser chamada de "mapeamento", mas o termo mapeamento é normalmente reservado para instruções legíveis por máquina específicas dadas ao software de tradução.) "hubs" têm Diretrizes de Implementação de Mensagens existentes que espelham seus processos de negócios para processamento de EDI e geralmente não estão dispostos a modificar suas práticas de negócios de EDI para atender às necessidades de seus parceiros comerciais. Muitas vezes, em uma grande empresa, essas diretrizes de EDI serão escritas para serem genéricas o suficiente para serem usadas por diferentes filiais ou divisões e, portanto, conterão informações desnecessárias para uma troca de documentos de negócios específica. Para outras grandes empresas, eles podem criar diretrizes de EDI separadas para cada filial/divisão.

Transmissão: EDI direto e VANs

Os parceiros comerciais são livres para usar qualquer método para a transmissão de documentos (conforme descrito acima na seção Protocolos de transmissão). Além disso, eles podem interagir diretamente ou por meio de um intermediário.

EDI direto: ponto a ponto

Os parceiros comerciais podem se conectar diretamente entre si. Por exemplo, um fabricante de automóveis pode manter um pool de modems para o qual todas as suas centenas de fornecedores precisam discar para executar o EDI. No entanto, se um fornecedor fizer negócios com vários fabricantes, pode ser necessário adquirir um modem diferente (ou dispositivo VPN, etc.) e um software diferente para cada um.

Conforme o EDI e a tecnologia da Web evoluíram, novas tecnologias de software EDI surgiram para facilitar o EDI direto (também conhecido como ponto a ponto) entre parceiros comerciais. O software EDI moderno pode facilitar as trocas usando qualquer número de diferentes protocolos de transmissão de arquivos e padrões de documentos EDI, reduzindo custos e barreiras à entrada.

Redes de valor agregado

Para lidar com as limitações na adoção ponto a ponto de EDI, as VANs (redes de valor agregado) foram estabelecidas décadas atrás. Uma VAN atua como uma agência postal regional. Ele recebe transações, examina o 'de' e o 'para' informações e encaminha a transação para o destinatário final. As VANs podem fornecer uma série de serviços adicionais, por ex. retransmitir documentos, fornecer informações de auditoria de terceiros, atuar como um gateway para diferentes métodos de transmissão e lidar com o suporte de telecomunicações. Devido a esses e outros serviços fornecidos pelas VANs, as empresas frequentemente usam uma VAN, mesmo quando ambos os parceiros comerciais usam protocolos baseados na Internet. As câmaras de compensação de assistência médica executam muitas das mesmas funções de uma VAN, mas possuem restrições legais adicionais.

As VANs podem ser operadas por várias entidades:

• empresas de telecomunicações;
• consórcios de grupos industriais;
• uma grande empresa interagindo com seus fornecedores / fornecedores;
• prestadores de serviços gerenciados.

Custos, compensações e implementação

É importante observar que existem compensações importantes entre VANs e Direct EDI e, em muitos casos, as organizações que trocam documentos EDI podem, de fato, usar ambos em conjunto, para diferentes aspectos de suas implementações EDI. Por exemplo, nos EUA, a maioria das trocas de documentos EDI usa AS2, portanto, uma configuração EDI direta para AS2 pode fazer sentido para uma organização sediada nos EUA. Mas adicionar recursos OFTP2 para se comunicar com um parceiro europeu pode ser difícil, portanto, uma VAN pode fazer sentido para lidar com essas transações específicas, enquanto o EDI direto é usado para as transações AS2.

De muitas maneiras, uma VAN atua como um provedor de serviços, simplificando muito a configuração para organizações que desejam iniciar o EDI. Devido ao fato de que muitas organizações que estão começando com EDI geralmente o fazem para atender a um requisito de cliente ou parceiro e, portanto, carecem de experiência interna em EDI, uma VAN pode ser um recurso valioso.

No entanto, as VANs podem ter custos elevados. As VANs normalmente cobram uma taxa de transação por documento ou mesmo por item de linha para processar transações EDI como um serviço em nome de seus clientes. Esta é a razão predominante pela qual muitas organizações também implementam uma solução de software EDI ou eventualmente migram para uma para parte ou todo o seu EDI.

Por outro lado, a implementação de software EDI pode ser um processo desafiador, dependendo da complexidade do caso de uso, das tecnologias envolvidas e da disponibilidade de experiência em EDI. Além disso, há requisitos de manutenção contínua e atualizações a serem consideradas. Por exemplo, o mapeamento EDI é uma das tarefas de gerenciamento EDI mais desafiadoras. As empresas devem desenvolver e manter mapas EDI para cada um de seus parceiros comerciais (e, às vezes, vários mapas EDI para cada parceiro comercial com base em seus requisitos de atendimento de pedidos).

Interpretação de dados

O software de tradução EDI fornece a interface entre os sistemas internos e o formato EDI enviado/recebido. Para uma "entrada" documento, a solução EDI receberá o arquivo (por meio de uma rede de valor agregado ou diretamente usando protocolos como FTP ou AS2), pegará o arquivo EDI recebido (normalmente chamado de "envelope") e validar que o parceiro comercial que está enviando o arquivo é um parceiro comercial válido, que a estrutura do arquivo atende aos padrões EDI e que os campos individuais de informações estão em conformidade com os padrões acordados. Normalmente, o tradutor criará um arquivo de tamanho fixo, tamanho variável ou formato com tags XML ou "imprimir" o documento EDI recebido (para ambientes EDI não integrados). O próximo passo é converter/transformar o arquivo que o tradutor cria em um formato que pode ser importado para sistemas de back-end de negócios, aplicativos ou ERP de uma empresa. Isso pode ser feito usando um programa personalizado, um "mapeador" ou um "mapeador" gráfico integrado baseado em padrões; usando uma linguagem de transformação de dados padrão, como XSLT. A etapa final é importar o arquivo (ou banco de dados) transformado para o sistema back-end da empresa.

Para uma "saída" documento, o processo para EDI integrado é exportar um arquivo (ou ler um banco de dados) dos sistemas de informação de uma empresa e transformar o arquivo no formato adequado para o tradutor. O software de tradução então "validará" o arquivo EDI enviado para garantir que atenda ao padrão acordado pelos parceiros comerciais, converta o arquivo em "EDI" formato (adicionando os identificadores apropriados e estruturas de controle) e enviar o arquivo para o parceiro comercial (usando o protocolo de comunicação apropriado).

Outro componente crítico de qualquer software de tradução EDI é uma "auditoria" de todas as etapas para mover documentos comerciais entre parceiros comerciais. A auditoria garante que qualquer transação (que na realidade é um documento comercial) possa ser rastreada para garantir que não seja perdida. No caso de um varejista enviar um Pedido de Compra a um fornecedor, se o Pedido de Compra for "perdido" em qualquer parte do processo de negócios, o efeito é devastador para ambos os negócios. Para o fornecedor, não atende o pedido por não ter recebido, perdendo negócios e prejudicando a relação comercial com seu cliente varejista. Para o varejista, há uma falta de estoque e o efeito é perda de vendas, redução do atendimento ao cliente e, em última instância, lucros menores.

Na terminologia EDI, "entrada" e "saída" referem-se à direção de transmissão de um documento EDI em relação a um determinado sistema, não à direção de mercadorias, dinheiro ou outras coisas representadas pelo documento. Por exemplo, um documento EDI que diz a um depósito para realizar uma remessa de saída é um documento de entrada em relação ao sistema de computador do depósito. É um documento de saída em relação ao fabricante ou revendedor que transmitiu o documento.

Vantagens sobre os sistemas de papel

EDI e outras tecnologias semelhantes economizam o dinheiro da empresa, fornecendo uma alternativa ou substituindo fluxos de informações que exigem muita interação humana e documentos em papel. Mesmo quando os documentos em papel são mantidos em paralelo com a troca EDI, por ex. manifestos de remessa impressos, troca eletrônica e o uso de dados dessa troca reduzem os custos de manuseio de classificação, distribuição, organização e pesquisa de documentos em papel. EDI e tecnologias semelhantes permitem que uma empresa aproveite os benefícios de armazenar e manipular dados eletronicamente sem o custo de entrada manual. Outra vantagem do EDI é a oportunidade de reduzir ou eliminar erros de entrada manual de dados, como erros de remessa e cobrança, porque o EDI elimina a necessidade de redigitar documentos no destino. Uma vantagem muito importante do EDI em relação aos documentos em papel é a velocidade com que o parceiro comercial recebe e incorpora as informações em seu sistema, reduzindo consideravelmente os tempos de ciclo. Por esse motivo, o EDI pode ser um componente importante dos sistemas de produção just-in-time.

De acordo com o relatório de 2008 da Aberdeen "A Comparison of Supplier Enablement around the World", apenas 34% dos pedidos de compra são transmitidos eletronicamente na América do Norte. Na EMEA, 36% dos pedidos são transmitidos eletronicamente e na APAC, 41% dos pedidos são transmitidos eletronicamente. Eles também relatam que a requisição média de papel para fazer um pedido custa a uma empresa US$ 37,45 na América do Norte, US$ 42,90 na EMEA e $23,90 na APAC. Com uma requisição EDI para pedido, os custos são reduzidos para $23,83 na América do Norte, $34,05 na EMEA e US$ 14,78 na APAC.

Barreiras à implementação

Existem algumas barreiras para adotar o intercâmbio eletrônico de dados. Uma das barreiras mais significativas é a mudança de processo de negócios que acompanha. Os processos de negócios existentes construídos em torno do manuseio de papel podem não ser adequados para EDI e exigiriam mudanças para acomodar o processamento automatizado de documentos comerciais. Por exemplo, uma empresa pode receber a maior parte de suas mercadorias por remessa de 1 ou 2 dias e todas as suas faturas pelo correio. O processo existente pode, portanto, assumir que as mercadorias são normalmente recebidas antes da fatura. Com o EDI, a fatura normalmente será enviada no momento do embarque da mercadoria e, portanto, exigirá um processo que trate um grande número de faturas cujas mercadorias correspondentes ainda não foram recebidas.

Outra barreira significativa é o custo em tempo e dinheiro na configuração inicial. As despesas e o tempo preliminares decorrentes da implementação, customização e treinamento podem ser caros. É importante selecionar o nível correto de integração para corresponder ao requisito de negócios. Para uma empresa com relativamente poucas transações com parceiros baseados em EDI, pode fazer sentido para as empresas implementarem métodos de "rip and read" soluções, onde o formato EDI é impresso em formato legível por humanos e as pessoas - em vez de computadores - respondem à transação. Outra alternativa são as soluções de EDI terceirizadas fornecidas pelos EDI "Service Bureaus". Para outras empresas, a implementação de uma solução EDI integrada pode ser necessária, pois os aumentos nos volumes de negociação gerados pelo EDI os forçam a reimplementar seus processos de negócios de processamento de pedidos.

O principal obstáculo para uma implementação bem-sucedida do EDI é a percepção que muitas empresas têm da natureza do EDI. Muitos veem o EDI da perspectiva técnica de que o EDI é um formato de dados; seria mais correto assumir a visão de negócios de que o EDI é um sistema para trocar documentos comerciais com entidades externas e integrar os dados desses documentos nos sistemas internos da empresa. Implementações bem-sucedidas de EDI levam em consideração o efeito que as informações geradas externamente terão em seus sistemas internos e validam as informações comerciais recebidas. Por exemplo, permitir que um fornecedor atualize o sistema de contas a pagar de um varejista sem verificações e balanços apropriados colocaria a empresa em risco significativo. As empresas novas na implementação do EDI devem entender o processo de negócios subjacente e aplicar o julgamento adequado.

Agradecimento

Abaixo estão os reconhecimentos EDI comuns

• Estado de comunicação – Indicar a transmissão concluída
• MDN (Notificação de Disposição de Mensagens) – Somente no AS2, indique que a mensagem é legível
• Agradecimento funcional – tipicamente "997" em ANSI, ou "CONTRL" em EDIFACT, que indicam que o conteúdo da mensagem é verificado contra seu modelo, e dizer se a transação é postada no sistema eletrônico do receptor.
• Agradecimento de nível de negócio – o indicador final mostra se a transação é aceita pelo receptor ou não.