BRPI0618666A2

BRPI0618666A2 - especificação de xml para troca eletrÈnica de dados (edi)

Info

Publication number: BRPI0618666A2
Application number: BRPI0618666-1A
Authority: BR
Inventors: Surendra Machiraju; Suraj Gaurav
Original assignee: Microsoft Corp
Priority date: 2005-12-16
Filing date: 2006-11-17
Publication date: 2011-09-06
Also published as: CN101331511A; EP1969549A1; EP1969549A4; US7650353B2; WO2007075234A1; RU2419876C2; JP4805357B2; KR20080084971A; JP2009520267A; RU2008123796A; US20070143665A1; JP2011187077A

Abstract

ESPECIFICAçãO DE XML PARA TROCA ELETRÈNICA DE DADOS (EDI) Especificação de Linguagem de Marcação Extensível (XML) para transformar transações de troca eletrónica de dados (EDI) . Uma coletânea de dados de EDI é recebida em um lote. O lote de dados de EDI inclui uma pluralidade de documentos de EDI e cada um da pluralidade de documentos de EDI tem pelo menos uma transação de EDI que corresponde a um tipo de transação. As transações de EDI inclusas nos documentos de EDI são identificadas decodificando os dados de EDI recebidos de acordo com os padrões de EDI. Um documento de EDI consolidado é gerado dos documentos de EDI no lote de dados de EDI. O documento de EDI consolidado inclui as transações de EDI identificadas organizadas de acordo com o tipo de transação.

Description

"ESPECIFICAÇÃO DE XML PARA TROCA ELETRÔNICA DE DADOS (EDI)"

ANTECEDENTES

Na facilitação da manipulação de transações, as entidades empresariais com freqüência eletronicamente trans- mitem dados de transação empresariais em um formato rígido em redes de comunicações comuns. Por exemplo, a troca ele- trônica de dados (EDI) é um dos modos que as empresas comer- ciais tiram proveito do alcance em constante expansão de sistemas de computação automatizados.

Em EDI, dados empresariais são formatados de acor- do com um ou mais padrões conhecidos e aprovados, tais como ANSI X12 ou EDIFACT. Por exemplo, os dados de EDI represen- tando várias transações são transmitidos como um lote de do- cumentos delineados, e cada um dos documentos delineados é codificado de acordo com as regras de formatação rígida para assegurar que a aplicação de destino recebendo os documentos seja capaz, de forma bem sucedida, de analisar gramatical- mente e consumir a informação para processamento de fluxo.

Na análise gramatical e processamento das mensa- gens de EDI, os sistemas existentes transmitem os dados de EDI e incluem as regras ou esquemas de formatação em cada documento delineado durante a troca. Por exemplo, os dados de EDI que representam uma transação de ordem de compra in- cluem um esquema para a transação de ordem de compra. Como tal, cada documento de transação de EDI inclui tanto os da- dos de EDI como o esquema específico para a transação. Embo- ra este arranjo ou configuração facilite a análise gramati- cal dos dados de EDI, é estático e torna cada documento de transação grande em termos de tamanho de documento. Além disso, o esquema incluso não é compartilhável. Em outras pa- lavras, se houver dois documentos de transação de ordem de compra AeB, cada documento de transação de ordem de compra necessita incluir um esquema de ordem de compra embora o es- quema em cada documento seja idêntico. Também, transações de EDI são carregadas, entre outras coisas, de acordo com o nú- mero de linhas ou documentos, e a largura de banda necessá- ria para transmitir os dados de EDI. Como as entidades em- presariais transmitem milhões de transações diariamente u- sando EDI, estes documentos grandes de transação de EDI, que incluem informação duplicada do esquema, criam custos desne- cessários para se ter informação do esquema redundante.

Uma vez os documentos de transação de EDI são re- cebidos, a aplicação de destino tipicamente armazena os do- cumentos de transação de EDI em uma área da memória. A apli- cação de destino a seguir transmite um reconhecimento de re- cebimento à fonte indicando que as transações foram recebi- das. As transações de EDI armazenadas são depois disso vali- dadas através de aplicações para determinar se os dados de EDI inclusos nos documentos de transação obedecem às regras de formatação dos esquemas para os tipos de transação. Du- rante este tempo de validação, a fonte (por exemplo, um co- merciante ou um cliente) é requerida aguardar por um reco- nhecimento de validação para indicar que os dados de transa- ção conformam ao formato. Se for determinado que uma ou mais transações não estão formatadas corretamente, documentos de transação de EDI de substituição necessitam ser re- transmitidos para processamento. Esta demora de espera-para- validação também reduz a eficiência de processar as transa- ções de EDI.

SUMÁRIO

Modalidades da invenção superaram os déficits dos sistemas existentes em manipular transações de EDI transfor- mando os arquivos de transação de EDI em um documento de EDI com estruturas ou sub-documentos aninhados(as) que identifi- cara vários tipos de transação de EDI. Além disso, os aspec- tos da invenção permitem o documento de EDI referir esquemas tornando disponíveis as circunstâncias dos esquemas quando as transações de EDI são processadas no tempo de execução. Vantajosamente, as modalidades da invenção automaticamente reconhecem os esquemas associados aos tipos de transação e processam as transações de EDI à medida que as transações de EDI são recebidas. De acordo com outras modalidades da in- venção, as transações de EDI são validadas à medida que as transações de EDI são recebidas.

Em ainda outra modalidade da invenção, um meta- esquema unitário é definido para representar uma pluralidade de esquemas. O meta-esquema unitário é fornecido aos usuá- rios finais para modificar as propriedades dos esquemas.

Este sumário é fornecido para introduzir uma sele- ção de conceitos em uma forma simplificada que são também descritos abaixo na Descrição Detalhada. Este Sumário não é intencionado identificar características fundamentais ou ca- racterísticas essenciais do assunto reivindicado, nem é in- tencionado ser usado como uma ajuda em determinar o escopo do assunto reivindicado.

Outras características serão em parte evidentes e em parte apontadas doravante.

BREVE DESCRIÇÃO DOS DESENHOS

FIG. 1 é um diagrama de blocos ilustrando uma im- plementação de manipular transações de EDI.

FIGS. 2A a 2C são diagramas ilustrando estruturas de dados de transação usando troca eletrônica de dados (EDI) de acordo com uma modalidade da invenção.

FIG. 3 é um diagrama de blocos exemplar ilustrando um sistema para transformar transações de EDI de acordo com uma modalidade da invenção.

FIGS. 4A e 4B são diagramas de fluxo ilustrando transformação de transações de EDI de acordo com uma modali- dade da invenção.

FIG. 5A é um diagrama de blocos ilustrando aninha- mento de transação de EDI de acordo com uma modalidade da invenção.

FIGS. 5B e 5C são diagramas de blocos ilustrando seriar transações de EDI de acordo com uma modalidade da in- venção.

FIGS. 6A e 6B são capturas de tela ilustrando transações de EDI transformadas inclusas em um documento de EDI consolidado em formato de documento de Linguagem de Mar- cação Extensível (XML) de acordo com uma modalidade da in- venção.

FIGS. 7A a 7D são capturas de tela ilustrando es- quemas de EDI na identificação automática de acordo com uma modalidade da invenção.

FIG. 8A é um fluxograma ilustrando validação de transações de EDI de acordo com uma modalidade da invenção.

FIG. 8B é um diagrama ilustrando detectar erros em transações de EDI de acordo com uma modalidade da invenção.

FIGS. 9A e 9B são diagramas ilustrando estruturas de reconhecimento de validação de EDI de acordo com uma mo- dalidade da invenção.

FIG. 10 é uma captura de tela ilustrando um meta- esquema unitário para modificar uma pluralidade de esquemas de EDI de acordo com uma modalidade da invenção.

FIG. 10A é um fluxograma ilustrando um método para modificar uma pluralidade de esquemas de EDI usando um meta- esquema unitário de acordo com uma modalidade da invenção.

FIGS. 11A a IlD são diagramas de blocos ilustrando meios legíveis por computador exemplares nos quais os aspec- tos da invenção podem ser armazenados.

FIG. 12 é um diagrama de blocos ilustrando um e- xemplo de um ambiente de sistema de computação adequado no qual a invenção pode ser implementada.

Apêndice A descreve o esquema de XML mostrado na FIG. 10A em sua totalidade.

Apêndice B mostra um meta-esquema unitário exem- plar em formato XML que representa um esquema de ordem de compra.

Caracteres de referência correspondentes indicam partes correspondentes ao longo dos desenhos. DESCRIÇÃO DETALHADA

FIG. 1 é um diagrama de blocos ilustrando uma im- plementação de manipular transações de EDI. Inicialmente, como ilustrado na FIG. 1, uma fonte (por exemplo, um sócio empresarial) 102 transmite uma mensagem de EDI 106, que pode incluir uma fatura 202, para um destino (por exemplo, clien- te empresarial) 104 através de uma rede de comunicações co- mum 108.

A fonte 102 transmite a mensagem de EDI 106, in- cluindo os esquemas e os dados de transação de EDI, para o destino 104 por meio da rede de comunicações comum 108. Em um exemplo, a mensagem de EDI 106 inclui uma pluralidade de dados de transação de EDI em um lote para economizar custo de transmissão ou de largura de banda. Em outro exemplo, a rede de comunicações comum 108 pode ser uma rede privada, dedicada, tal como uma intranet, ou uma rede pública, tal como uma internet. Em outro exemplo, a rede de comunicações comum 108 inclui um ou mais protocolos de rede, tais como FTP, HTTP, Kermit, Xmodem, demora de estrutura, EDIINT, 3780 Bisync®, ou outros, para facilitar a transmissão de mensa- gens de EDI entre os sócios.

A fonte 102 inicia a transmissão de mensagem de EDI 106 abrindo uma sessão de conexão (por exemplo, uma ses- são de conexão de soquete presa) com o destino 104 por meio da rede de comunicações comum 108. Uma vez a sessão de cone- xão é aberta, a fonte 102 transmite a mensagem de EDI 106 para o destino 104. Um conjunto de sistemas de tradutor de EDI 110 no destino 104 recebe a mensagem de EDI 106, e os sistemas de tradutor de EDI 110 transmitem um reconhecimento de recebimento 112 para a fonte 102 por meio da rede de co- municações comum 108 que indica que a mensagem de EDI foi recebida. É comum que o reconhecimento de recebimento seja transmitido ou retornado à fonte 102 antes da fonte 102 ter- minar a sessão de conexão.

Uma vez a mensagem de EDI 106 é recebida, os dados de EDI associados às transações de EDI são analisados grama- ticalmente e processados pelos sistemas de tradutor de EDI 110. Como conhecido por aqueles versados na técnica, a aná- lise gramatical e/ou decodificação da transação de EDI en- volve uma ou mais etapas de identificar os vários padrões de EDI, as especificações do esquema, ou outros. Assim fazendo, os sistemas de tradutor de EDI 110 transmitem os dados de EDI analisados gramaticalmente ou decodificados para uma a- plicação de fluxo 114 para processar os dados de EDI anali- sados gramaticalmente ou decodificados. Por exemplo, a apli- cação de fluxo 114 pode ser uma aplicação de contabilidade para processar faturas ou software para manipular dados de ordem de compra. Como tal, a aplicação de fluxo 114 é capaz de validar se os dados de EDI recebidos, após analisar gra- maticalmente e decodificar, conformam às regras de formata- ção especificadas nos esquemas. Se os dados de EDI recebidos conformam às regras do esquema, a aplicação de fluxo 114 transmite um reconhecimento de validação 116 para a fonte 102. Por outro lado, se os dados de EDI recebidos incluirem erros ou forem inválidos, a aplicação de fluxo 114 pode transmitir uma notificação de erro à fonte que indica o erro dos dados de EDI recebidos.

0 reconhecimento de validação 116 usualmente é transmitido à fonte 102 com uma demora após a transmissão de reconhecimento de recebimento. Em outras implementações, os dados de EDI analisados gramaticalmente são armazenados em uma base de dados ou um armazenamento de dados (não mostrado) aguardando serem validados. Como tal, a fonte 102 freqüente- mente é solicitada aguardar pelo reconhecimento de validação 116 para averiguar que os dados de EDI podem ser processados corretamente pelo destino 104.

FIGS. 2A a 2C são diagramas ilustrando estruturas de dados de transação usando troca eletrônica de dados (EDI) de acordo com uma modalidade da invenção. FIG. 2A ilustram um exemplo de uma representação de um documento de transação de EDI de fatura 202 usando o Formato ANSI X12. Neste exem- plo, a fatura 202 inclui vários segmentos ou seções (vide FIG. 2C para uma visão geral de uma estrutura de troca de EDI de X12 218) tal como uma seção de grupo funcional 204 que pode incluir informação adicional da fatura 202. Por e- xemplo, em um setor de cadeia de provisão, é conhecido àque- les versados na técnica que a informação ou valores no grupo funcional 204 são idênticos à informação ou valores em uma seção de troca (por exemplo, cabeçalho de controle de troca), como mostrado na FIG. 2C. Em outro exemplo, a informação ou valores no grupo funcional 204 inclui valores ou identifica- dores para identificar uma unidade empresarial ou operacio- nal dentro de um empreendimento maior.

A fatura 202 também inclui uma porção de cabeçalho 206 que inclui informação tal como a informação do cliente empresarial. Neste exemplo, a porção de cabeçalho 206 inclui o nome do cliente empresarial "ABC Company" e endereço "0887 Sixth Street, Saint Louis, MO 63101". Em uma modalidade, a porção de cabeçalho 206 inclui informação de destino para receber reconhecimentos de validação, vide debates nas FIGS. 8, 9A e 9B abaixo. A fatura 202 também inclui uma seção de tabela de detalhe 208 mostrando um ou mais segmentos de da- dos 212 que são organizados em um ciclo 210. Por exemplo, o ciclo 210 inclui um grupo de segmentos de dados semantica- mente relacionados, e, para aqueles que são versados na téc- nica, estes segmentos ou podem ser limitados ou ilimitados de acordo com ANSI X12.6.

Tipos e seções de segmentos adicionais e informa- ção correspondente podem ser inclusos em um Documento de transação de EDI de acordo com o formato ANSI X12 ou EDIFACT sem divergir do escopo da invenção. Por exemplo, FIG. 2B i- lustram um ou mais tipos de transações incluídos na mesma mensagem de EDI 106 a ser processada para o destino 104. Do- cumentos de transação de EDI de uma fatura 214 e uma ordem de compra 216 estão sendo incluídos na mensagem de EDI 106 porque a fatura 214 e a ordem de compra 216 estão relaciona- das com o mesmo cliente, "ABC Company". Grupos adicionais de documentos de transações relacionados podem ser incluídos na troca como a mensagem de EDI 106. Em uma modalidade, os do- cumentos de EDI podem ser enviados para um destino ou clien- te em um lote.

É.também para ser entendido que cada um dos tipos de transação de EDI são requeridos para conformar ao esquema que está associado ao tipo de transação. Por exemplo, um es- quema de transação de fatura pode requerer, entre outras coisas, uma certa limitação no comprimento máximo ou mínimo de caracteres para o nome do comerciante ou do comprador. Um esquema de transação de ordem de compra pode requerer um nú- mero máximo de dígitos após o ponto decimal. Em outro exem- plo, o esquema pode especificar para vários tipos de transa- ção que um campo particular é obrigatório enquanto outros são opcionais.

Implementações existentes incluem os esquemas de transação nos documentos de transação de EDI ao transmitir as transações de EDI para o cliente, tal como um destino 104 Embora estas implementações facilitem a decodificação das transações de EDI, elas requerem dos projetistas de esquema gastar uma quantidade substancial de tempo projetando ou configurando os esquemas antes de transmitir as transações de EDI aos sócios empresariais. Também, modificações subse- qüentes são requeridas para os esquemas devido à modificação de acordos empresariais entre os sócios para reprojetar os esquemas.

Como tal, as modalidades da invenção superaram as deficiências de implementações existentes transformando a mensagem de EDI em um documento de EDI consolidado com es- truturas ou sub-documentos aninhados organizando uma ou mais transações de EDI de acordo com os tipos de transação. O do- cumento de EDI também inclui um uber-esquema para represen- tar uma pluralidade de esquemas associado aos tipos de tran- sação. Em outra modalidade, um mapa de esquema de tempo de execução está transformando a pluralidade de esquemas para processar no tempo de execução para o destino 104.

Referindo agora à FIG. 3, um diagrama de blocos ilustra um sistema 302 para transformar transações de EDI de acordo com uma modalidade da invenção. 0 sistema 302 inclui uma fonte 304 que pode ser um comerciante realizando transa- ções comerciais com um destino 306 ou um cliente. Por exem- plo, a fonte 304 pode ser uma comerciante tal como uma loja a varejo de eletrônicos de consumidor que vende quantidades grandes de bens a um cliente corporativo que compra equipa- mento de computação. Em outro exemplo, a fonte 304 pode ser provedor de cuidado médico, tal como um hospital ou uma far- mácia, e pode transmitir dados de EDI para uma companhia de seguros de cuidado médico ou uma câmara de compensação para submeter reivindicações ou complacência para com as provi- dências da Health Insurance Portability and Accountability Act (HIPAA).

Em uma modalidade, a fonte 304 e o destino 306 in- cluem um ou mais dispositivos de computação tais como um computador 130 na FIG. 12 para enviar os documentos de EDI em um lote. Inicialmente, a fonte 304 transmite uma mensagem de EDI 310 incluindo uma pluralidade de documentos de EDI. Cada um dos documentos de EDI inclui pelo menos uma transa- ção de EDI que corresponde a um tipo de transação (por exem- plo, fatura, ordem de compra, conta a pagar, ou outros).

Referindo também à FIG. 4A, um diagrama de fluxo ilustra transformação das transações de EDI de acordo com uma modalidade da invenção. Após a fonte 304 abrir uma ses- são de conexão na rede de comunicações 308 comunica com o destino 306, a fonte 304 transmite a mensagem de EDI 310 pa- ra a máquina de EDI 312 do destino 306. Em uma modalidade, a máquina de EDI 312 inclui um ou mais dispositivos de compu- tação (por exemplo, computador 130) executando instruções executáveis por computador, rotinas, ou funções. Em 402, a máquina de EDI 312 recebe a mensagem de EDI 310 incluindo a pluralidade de documentos de EDI. Em 404, a máquina de EDI 312 identifica as transações de EDI inclusas na pluralidade de documentos de EDI. Usando o exemplo acima de ANSI X12, a máquina de EDI 312 decodifica ou analisa gramaticalmente uma fatura de X12 identificando os vários cabeçalhos de dados e segmentos de dados (por exemplo, ISA, GS, ou outros) ilus- trados na FIG. 2C para determinar os dados de EDI nas tran- sações. Em outra modalidade, a máquina de EDI 312 também i- dentifica os vários esquemas incluídos na pluralidade de do- cumentos de EDI para determinar as regras de formatação es- pecíficas para os tipos de transação.

Em 406, a máquina de EDI 312 gera um documento de EDI consolidado 314 da pluralidade de documentos de EDI no lote. Em um exemplo, a máquina de EDI 312 gera o documento de EDI consolidado 314 como um documento de XML com marcado- res de remarcação de estrutura de XML em 410. Por exemplo, distintas das implementações existentes onde cada transação é organizada como um documento, as modalidades da invenção organizam as transações de EDI na pluralidade de documentos de EDI como um documento de XML que não só define os ajustes de transação individuais mas também define as trocas captu- rando todos os aspectos dos dados de EDI, incluindo segmen- tos, ciclos, campos, delimitadores, etc. Em um exemplo, a FIG. 6A ilustra um documento de XML consolidado exemplar in- cluindo uma ou mais transações de EDI, tais como "PO (ordem de compra)".

Em ainda outra modalidade, o documento de EDI con- solidado 314 inclui um uber-esquema que representa uma plu- ralidade de esquemas referidos pelas transações de EDI. Por exemplo, o uber-esquema é incluído nos ajustes de transação de EDI e é embutido ou emendado dentro dos grupos funcionais e segmentos de envelope de cada transação de EDI de modo que um usuário final não seja requerido criar um esquema especí- fico para cada conjunto de transações que é esperado estar incluído na mensagem de EDI 310. Como um exemplo, a FIG. 6B mostra uma captura de tela ilustrando um uber-esquema em formato XML no documento de EDI consolidado 314 de acordo com uma modalidade da invenção, Com tal projeto, a troca do documento de EDI consolidado 314 reduz a necessidade de in- cluir um ou mais esquemas cada um correspondendo a um tipo de transação nos documentos de EDI. Modalidades da invenção também reduzem o projeto de esquema e tempo de desenvolvi- mento antes da transmissão.

Em outra modalidade, em 412 na FIG. 4B, a máquina de EDI 312 transforma o documento de EDI consolidado com o mapa de esquema de tempo de execução ou um esquema de carga útil. Em 414, a máquina de EDI 312 cria sub-documentos ou estruturas aninhadas para a transação de EDI no documento de EDI consolidado 314 (vide Tabelas 1 e 2 para descrições adi- cionais) . Em uma modalidade alternativa, o documento de EDI consolidado 314 é transformado pelo esquema de carga útil (por exemplo, mapa de esquema de tempo de execução) e pode também ser estruturalmente transformado em 416. Alternativa- mente, o documento de EDI consolidado 314 pode ser transmi- tido para a aplicação de fluxo 316 para processar sem trans- formação estrutural em 418. Em 420, o documento de EDI con- solidado 314 com sub-documentos ou estrutura aninhada(os) é também transmitido para a aplicação de fluxo 316 para pro- cessamento .

É para ser entendido que formatos diferentes de XML para o documento de EDI consolidado 314 com marcadores de remarcação definindo e organizando as transações de EDI em estruturas identificáveis podem ser usados sem divergir do escopo da invenção.

Em outra modalidade, um meio legível por computa- dor 1102 (na FIG. 11A) nos quais os aspectos da invenção descritos acima podem ser armazenados. Por exemplo, um com- ponente de interface 1104, um componente de identificação 1106, e um componente de transformação 1108 podem ser inclu- ídos na máquina de EDI 312 que executa uma ou mais operações debatidas acima.

É também para ser entendido que o método ilustrado na FIG. 4A pode ser executado pela fonte 304 de modo que a fonte 304 reduziria o tamanho de troca antes da transmissão. Como tal, a estrutura aninhada ou sub-documentos do documen- to consolidado de EDI 314 reduz o número de linhas, que pode também reduzir o custo de transmitir os dados de EDI quando for carregado de acordo com o número de linhas.

Por exemplo, Tabela 1 ilustra três transações de EDI em uma estrutura aninhada no documento de EDI consolida- do e os três documentos de EDI originais correspondentes que cada um inclui uma das três transações de EDI.

<table>table see original document page 16</column></row><table> <table>table see original document page 17</column></row><table>

Tabela 1: Três transações de EDI em uma estrutura

aninhada (coluna esquerda) e em três documentos de EDI (co- luna direita)

Em operação, suponha-se que um patrocinador de cuidado médico, tal como um Empregador A, necessita enviar uma mensagem de EDI, tal como um documento de HIPAA 8 34, pa- ra um pagador, tal como um provedor B de cuidado médico. 0 esquema para tal troca requer que o Empregador A forneça de- talhes dos benefícios dos beneficiários/recipientes de cui- dado médico (por exemplo, empregados e seus dependentes). Como tal, o Empregador A tipicamente inclui informação de detalhe do patrocinador e do pagador. Esta informação deta- lhada do patrocinador e do pagador é comum a todos os bene- ficiários e é repetida para cada empregado ou dependente que estão recebendo o benefício patrocinado pelo Empregador A. Em vez de repetir a informação do patrocinador e do pagador idêntica repetida para milhares de empregados e dependentes como nas implementações de EDI existentes, as modalidades da invenção criam uma estrutura aninhada de modo que cada mem- bro pode ser criado junto com uma cópia da informação deta- lhada do patrocinador e do pagador em uma lógica parecida com ciclo em um documento de EDI.

FIG. 5A é um diagrama de blocos ilustrando aninha- mento de transação de EDI de acordo com uma modalidade da invenção. Por exemplo, em 502, a mensagem de EDI (por exem- pio, mensagem de EDI 310) é recebida de uma fonte (por exem- plo, a fonte 304) para um destino (por exemplo, destino 306) . Em 504, um documento de EDI consolidado é gerado com transa- ções de EDI incluídas em uma estrutura aninhada ou como sub- documentos. Em um exemplo, os segmentos de envelope/controle (por exemplo, Segmentos de ISA/GS/GE/IEA em formato ANSI X12) são tirados e o conjunto de transações (ST/SE) é analisado gramaticalmente pelo canal de recebimento para gerar múlti- plos sub-documentos de XML por conjunto de transações. Em uma modalidade, os sub-documentos de XML múltiplos são depo- sitados em uma caixa de mensagem. Em 506, o canal de recebi- mento no destino realiza a validação da troca entrante e ge- ra reconhecimento de validação apropriado (a ser debatido em detalhes nas FIGS. 8, 9A e 9B) . Em uma modalidade, o canal de recebimento também atualiza totais de somas de verifica- ção e negócios.

Como descrito acima, o documento de EDI consolida- do 314 pode ser processado pela aplicação de fluxo 316. Como tal, o documento de EDI consolidado é enviado para uma porta de envio, e, em 508, a porta de envio transmite as transa- ções de EDI em sub-documentos de EDI. Em uma modalidade, um canal de envio associado à porta de envio seria os sub- documentos de XML e libera vn' trocas com uma contagem dos segmentos que são atualizados no canal de envio.

Em uma modalidade, quando uma troca de EDI é rece- bida, é validada. Se não houver nenhum erro de validação, cada conjunto de transações é convertido em formato XML de acordo com seu esquema. Desse modo, uma troca de EDI pode conter ordens de compra e documentos de fatura. As ordens de compra seriam convertidas em XML que é complacente com o es- quema de ordem de compra. Igualmente, a fatura seria conver- tida em fatura XML.

FIG. 5B ilustra uma ordem de compra exemplar de uma troca de EDI em formato XML. Quando este documento de ordem de compra é processado pelo lado de envio na FIG. 5A, ele é convertido em um formato EDI 514 após processamento dos segmentos de envelope. FIG. 5C ilustra um documento e- xemplar produzido pela porta de envio do formato XML na FIG. 5B. Em uma modalidade, o formato EDI 514 inclui dois segmen- tos de envelope (por exemplo, linhas que iniciam com ISA e GS) . Similarmente, o formato EDI 514 inclui dois segmentos de envelope, GE e IEA, ao término do documento. Como ilus- trado, dados incluídos entre os segmentos ST e SE são os da- dos para o conjunto de transações originais.

No exemplo acima como ilustrado nas FIGS. 5B e 5C, o valor de SEOl (vide seta 512) é "14" e é computado dinami- camente pela porta de envio. Enquanto seriando um documento de EDI, o lado de envio da máquina de EDI (por exemplo, má- quina de EDI 312) mantém a trilha do número de segmentos presentes em um conjunto de transações. Com base neste valor, o valor de SEOl é determinado.

Onde a fonte 304 gera o documento de EDI consoli- dado 314 para incluir transações de EDI da pluralidade de documentos de EDI, as modalidades da invenção incluem orga- nizar as transações de EDI incluídas em uma estrutura ani- nhada. Em outro exemplo, as modalidades da invenção permitem o destino 306 que recebe o documento de EDI consolidado 314 da fonte restabelecer a pluralidade de documentos de EDI do documento de EDI consolidado 314 para compatibilidade inver- sa ou acomodar a aplicação de fluxo 316 que pode apenas pro- cessar documentos de EDI que apenas contenham uma transação por documento. Modalidades alternativas da invenção permitem o documento de EDI consolidado com transações de EDI em es- truturas aninhadas para rastrear ou correlatar com a plura- lidade original de documentos de EDI.

Por exemplo, Tabela 2 ilustra conversão de transa- ções de EDI do documento de EDI consolidado 314 para uma pluralidade de documentos de EDI.

<table>table see original document page 20</column></row><table> Tabela 2: Conversão de documento de EDI Consolidado.

No exemplo mostrado na Tabela 2, processamento de transações de EDI em uma estrutura aninhada começa identifi- cando um SubDocumentCreationBreakPoint predeterminado (por exemplo, um marcador que descreve onde um documento- filho começa dentro de um documento-pai) para gerar sub- documentos múltiplos.

De acordo com a Tabela 2, o documento de EDI con- solidado mostrado na coluna Al pode ser dividido em três transações de acordo com a fratura de criação de sub- documento definida no ciclo BB no esquema: BB1*1-BB2*1, BB1*2, e BB1*3-BB2*3. Na coluna A2, o conjunto de transações BB1*1-BB2*1 é organizado ou dividido (denotado pelo texto em negrito) em um documento separado, enquanto na coluna A3, a transação BB1*2 é organizado em um segundo documento (deno- tado pelo texto sublinhado). Similarmente, o conjunto de transações BB1*3-BB2*3 é organizado em um terceiro documento de EDI (denotado pelo texto em itálico) a ser processado pe- la aplicação de fluxo 316.

Transformando as transações de EDI incluídas na pluralidade de documentos de EDI para o documento de EDI consolidado 314, as modalidades da invenção permitem o des- tino 306 ou a fonte 304 eficientemente identificar a plura- lidade de esquemas incluídos em cada um dos documentos de EDI durante a transformação. Além disso, pelo menos um as- pecto da invenção permite o destino 306, após transformar o documento de EDI consolidado, gerar um reconhecimento de va- lidação a ser retornado para a fonte 304 durante o período de tempo quando a sessão de conexão ainda estiver aberta. Em outras palavras, os aspectos da invenção configuram o desti- no 306 para automaticamente identificar a pluralidade de es- quemas e validar as transações de EDI enquanto as transações de EDI são recebidas.

Referindo agora às FIGS. 7A-7D, uma série de cap- turas de tela ilustra identificar esquemas de EDI automati- camente de acordo com uma modalidade da invenção. FIG. IA mostra um esquema de ordem de compra de ANSI X12 típico. Um esquema é identificado por um Doctype associado. Um DocType é uma combinação de itens de configuração tais como um espa- ço de nome e um nome de nó de raiz. Como mostrado na FIG. 7A, uma coluna esquerda 702 da captura de tela indica uma estru- tura hierárquica de um esquema. Neste exemplo, a coluna es- querda 702 mostra uma estrutura de esquema. Uma coluna cen- tral 704 indica que o código de XML do esquema. Uma coluna direita 706 indica propriedades ou o espaço de nome alvo in- cluso no esquema.

Em uma modalidade, o Doctype tem um formato de: "Doctype = TargetNamespace RootNodeName" em formato X12 que será descrito abaixo em detalhes. É para ser entendido que embora um esquema de X12 seja descrito na FIG. 7A, ou- tros formatos de esquema podem ser usados, tais como esque- mas de EDIFACT, sem divergir do escopo da invenção.

Um nó de raiz do Doctype tem um dos formatos a se- guir em X12: "X12_{Version}_{TsId}". Neste exemplo, o valor do item de configuração "nó de raiz" é "X12_00401_850", como indicado pela caixa 708. Em outras palavras, "00401" é a versão do documento e é um pedaço dinâmico da informação que determina uma configuração ou circunstância durante o pro- cessamento do tempo de execução. Similarmente, "850" é TsId que é a identificação de transação (ID) do esquema que está sendo processado e é determinado da circunstância de entrada. Neste exemplo, a ID de transação de "850" representa uma or- dem de compra, como indicado por uma caixa 710. Também, o espaço de nome alvo é indicado por uma caixa 712 na coluna direita 706.

Em outro exemplo, para decodificar ou identificar esquemas em formato EDIFACT, os esquemas de EDIFACT corren- temente têm o formato a seguir:

"Efact_{Version}_{Tsid}". Em outras palavras, to- dos os esquemas de EDIFACT têm nome de nó de raiz que inicia vtEfact", e as definições de Versão e Tsid são iguais às do formato X12.

Usando FIG. 3 como um exemplo, quando o destino 306 receber os documentos de EDI da fonte 304, as transações de EDI podem incluir a ID de transação "850" com o documento. Porém, a informação de versão ou a informação de espaço de nome alvo é determinada no tempo de execução e os valores destes itens de configuração podem ser configurados em dife- rentes níveis. Como tal, após aplicar as regras de acordo com os padrões de EDI (por exemplo, X12 ou EDIFACT) para de- codificar as transações de EDI de acordo com os tipos de transação correspondentes (por exemplo, ordem de compra, fa- tura, ou outros) , a máquina de EDI 312 identifica os itens de configuração nas transações de EDI decodificadas. Em uma modalidade, a máquina de EDI 312 identifica os itens de con- figuração de um ou mais níveis de configuração, tais como nível de sócio e nível de aplicação de envio, nível global, nível de canal, ou um nível predefinido.

Por exemplo, FIG. 7B ilustra uma captura de tela exibindo os itens de configuração na configuração de nível de terceiro. Neste exemplo, a ID de transação 850 para o só- cio mostrado acima na FIG. 7A é configurada para usar o es- paço de nome alvo e a informação de versão como mostrado a- cima. Para todos os outros tipos de documento, valores pre- definidos seriam usados, uma vez que o flag ou parâmetro predefinido está ativado, como indicado por uma caixa 714. Em outro exemplo, outro sócio comercial pode ajustar outros itens de configuração específicos na configuração de nível de terceiro com base nos acordos empresariais estabelecidos entre os sócios comerciais empresariais. Em vez de estatica- mente determinar o valor dos itens de configuração, as moda- lidades da invenção, na identificação automática dos esque- mas, identifica os valores dos itens de configuração deter- minando os valores específicos que são determinados pelo só- cio comercial de um ou mais níveis de configuração.

Em uma modalidade, os valores dos itens de confi- guração podem ser configurados na configuração de nível de terceiro para valores diferentes daqueles mostrados em Doctype na FIG. 7A devido a uma combinação específica da Id de remetente e Id de Transação. Por exemplo, em X12, cada Id de remetente pode representar um certo departamento dentro de um empreendimento. Como tal, um ID de remetente em um em- preendimento pode se referir a um departamento de "mercado- ria de hardware" enquanto outra ID de remetente pode se re- ferir a um departamento de "mercadoria de software" dentro do mesmo empreendimento. Desse modo, modalidades da invenção reconhecem estas configurações diferentes e conseqüentemente identifica os esquemas. Como resultado, a mesma ordem de compra de um empreendimento pode sofrer processo de identi- ficação de esquema diferente de modo que dados de EDI apro- priados e diferentes são gerados em XML, por exemplo, no do- cumento de EDI consolidado 314 de acordo com os valores dos itens de configuração.

É também para ser entendido que um ou mais itens de configuração adicionais podem ser configurados ou ajusta- dos pelo sócio empresarial especifico sem divergir do escopo da invenção. Por exemplo, um sócio pode ajustar uma quanti- dade mínima de configuração enquanto outro sócio pode defi- nir itens de configuração detalhados em sua configuração de nível de terceiro.

Referindo agora à FIG. 7C, uma captura de tela i- lustra um esquema de EDIFACT com sua configuração de nível de terceiro. Neste exemplo, diferente dos esquemas de X12, o espaço de nome alvo pode ser configurado com base em uma combinação específica de ID de aplicação de remetente (op- cional) (tal como UNG2.1 em 716 e UNG2.2 em 718), uma versão 720 (UNG8), e uma ID do conjunto de transações 722. Em ou- tras palavras, é possível ter configurações múltiplas para um documento de EDI de fatura, cada com um único id de apli- cação. Nesta circunstância, o espaço de nome alvo que equi- para uma aplicação especifica seria usado no tempo de execu- ção. Na situação onde nenhum ID de aplicação de remetente é configurada, um valor de ID de aplicação de remetente seria equiparado junto a qualquer valor de registros existentes (por exemplo, arquivos de log) que carregam a mesma ID de transação. No caso de equiparações múltiplas serem encontra- das, um espaço de nome alvo predefinido é usado para assegu- rar que, quando houver ambigüidade, um valor predefinido a- dequado seja usado.

FIG. 7D é uma captura de tela ilustrando uma con- figuração de nivel global para um esquema de X12. Neste e- xemplo onde os itens de configuração, tais como espaço de nome alvo ou versão, não são especificados pelos sócios co- merciais, valores dos itens de configuração na configuração de nivel global seriam usados. Neste exemplo, uma caixa 724 indica que nenhum valor é configurado para versão e espaço de nome alvo. Como tal, os valores dos itens de configuração não seriam modificados no tempo de execução.

Na situação onde alguns dos itens de configuração perdidos no nivel global não são configurados, os valores para os itens de configuração em um nivel de canal ou confi- guração de nivel de tempo de execução seriam usados. Desse modo, se o espaço de nome alvo não for configurado no nivel global, o valor da configuração de nivel de canal seria usa- do. Em uma modalidade, os valores na configuração de nivel de canal podem ser ajustados pelo usuário.

Em outra modalidade, FIG. IlB ilustra um meio le- gível por computador 1110 nos quais os aspectos da invenção podem ser armazenados. Por exemplo, um componente de inter- face 1112 recebe os documentos de EDI em um lote de uma fon- te onde cada um dos documentos de EDI tem pelo menos uma transação de EDI que corresponde a um tipo de transação. Um componente de transação 1114 decodifica as transações de EDI de acordo com os tipos de transação correspondentes aplican- do regras de acordo com os padrões de EDI (por exemplo, X12 ou EDIFACT). Um componente de configuração 1116 identifica valores em um ou mais itens de configuração para cada tran- sação de EDI nas transações de EDI decodificadas. Um compo- nente de esquema 1118 determina um ou mais tipos de esquema com base nos valores dos itens de configuração.

Em uma modalidade alternativa, os valores dos i- tens de configuração descritos nas seções anteriores podem ser modificados no tempo de execução. Desse modo, os valores para os tipos de transação, espaço de nome alvo, versão po- dem ser modificados após a máquina de EDI 312 estar proces- sando os documentos de EDI (isto é, identificando os esque- mas automaticamente) . Em uma tal modalidade, as alterações refletiriam nos documentos subseqüentes que ainda estar para ser processadas. Tal implementação dinâmica da invenção per- mite os usuários no destino 306 configurar valores durante o tempo de execução, não durante o tempo de proje- to/configuração do esquema antes dos documentos de EDI fos- sem enviados da fonte 304.

Em operação, a identificação de esquema automática permite os sócios de EDI agilizar o processamento dos docu- mentos de EDI. Ao contrário da implementação existente onde uma conexão de recebimento e uma conexão de envio necessitam ser configuradas para cada sócio e para cada tipo de docu- mento, a máquina de EDI 312 permite identificação de esquema automática de modo que os valores dos itens de configuração são identificados e determinados durante o tempo de execução, tornando os sócios empresariais de EDI flexíveis na manipu- lação dos dados de EDI.

Recordando que pelo menos outro aspecto da inven- ção inclui gerar um reconhecimento de validação quando os dados de EDI forem recebidos, a FIG. 8A é um diagrama de fluxo ilustrando tal característica. Em 802, uma mensagem de EDI (por exemplo, mensagem de EDI 310) é transmitida de uma fonte (por exemplo, fonte 304) para um destino (por exemplo, destino 306). Em 804, a mensagem de EDI que inclui transa- ções de EDI é recebida no destino. É em seguida determinado se a transmissão de mensagem de EDI é válida em 806 determi- nando se a mensagem de EDI é intencionada para o recipiente apropriado. Se for determinado que a transmissão de mensagem de EDI é inválida, processamento da mensagem de EDI é sus- penso e um reconhecimento de falha de troca é gerado em 808. Se for determinado que a troca de mensagem de EDI é válida, é em seguida determinado se os grupos de transações de EDI incluem erros em 810.

Se os grupos incluírem erros, processamento dos grupos de transações de EDI é suspenso e um reconhecimento de falha funcional é gerado em 812. Por exemplo, uma especi- ficação de EDI pode definir vários erros que podem ser en- contrados nos níveis ajustados de grupo e transação. Tabela 3 fornece uma lista de erros comuns que são aplicáveis nas trocas de EDI de X12.

<table>table see original document page 29</column></row><table>

Tabela 3: Erros de grupos funcionais - erros rela-

cionados ao segmento de GS/GE

Por exemplo, a máquina de EDI 312 determina um er- ro, tal como um código de erro 4, "Número de controle de grupo no cabeçalho do grupo funcional e marca final não cor- responde", identificando o sexto valor de - GS de li- nha/segmento em uma mensagem de EDI. Na FIG. 8B, o sexto va- lor de linha GS 532 tem um valor de "9" (como indicado por uma caixa 528). Na validação da transação de EDI, as modali- dades da invenção determinam se o mesmo valor está também presente no segundo valor da linha GE 534. Como ilustrado na FIG. 8B, o segundo valor da linha GE 534 é "10" (como indi- cado por uma caixa 530). Com tal discrepância, é determinado que há um erro nesta mensagem de EDI.

Em outro exemplo, um código de erro 5, "Número de conjuntos de transações incluídos não equipara com nenhuma contagem atual", é detectado identificando os conjuntos de transação entre um segmento de GS-GE. Como ilustrado na FIG. 8Β, há um segmento de GS-GE enquanto o primeiro valor da li- nha de GE é "02", indicando há dois conjuntos de transação. Como tal, este grupo funcional está em erro.

Porém, se for determinado que não há nenhum erro nos grupos, é em seguida determinado se cada uma das transa- ções de EDI é válida em 814 avaliando as regras de formata- ção de acordo com o formato X12 ou EDIFACT e as regras de acordo com os esquemas inclusos nas transações de EDI. Se for determinado que uma transação de EDI é inválida, proces- samento das transações de EDI é suspenso e um reconhecimento de falha funcional é gerado em 816.

Por exemplo, Tabela 4 fornece uma lista de erros de transação comuns.

<table>table see original document page 30</column></row><table>

Tabela 4: Erros de ajuste de transação - erros re- lacionados aos dados dentro de ST e SE

Usando FIG. 8B como um exemplo, uma máquina de EDI (por exemplo, máquina de EDI 312) identifica um código de erro 4, "Número de segmentos incluídos não equipara com ne- nhuma contagem atual", avaliando o número de segmentos (li- nhas) entre ST e SE. Neste exemplo, o número é "12" enquanto o primeiro valor na linha de SE é 14. Como tal, há um erro neste conjunto de transações, e tal código de erro pode ser incluído no reconhecimento de falha funcional.

Em uma modalidade, uma máquina de EDI (por exemplo, máquina de EDI 312) pode referir-se ou ter conhecimento de várias condições de erro ou regras de transações de EDI. En- quanto processando um documento de EDI, a máquina de EDI 312 assegura que nenhuma das regras de formação de EDI sejam vi- oladas. Em qualquer violação, a máquina de EDI 312 relata apropriadamente na forma de reconhecimentos de troca ou de nível funcional.

Alternativamente, se as transações de EDI forem válidas, a máquina de EDI 312 no destino prossegue para pro- cessar as transações de EDI em 818. Em 820, um reconhecimen- to de validação é gerado em 820 indicando que as transações de EDI são válidas. Em uma modalidade, a máquina de EDI 312 pode conferir e gerar um reconhecimento de validação conso- lidado à medida que a mensagem de EDI, grupos de EDI, e/ou transações de EDI são recebidos e são validados. Em outra modalidade, a máquina de EDI gera o reconhecimento de vali- dação consolidado substancialmente de forma simultânea à me- dida que a mensagem de EDI, grupos de EDI, e/ou transações de EDI são recebidos.

Em 824, o reconhecimento de validação gerado é re- tornado à fonte que recebe o reconhecimento de validação em 826. Em uma modalidade, a fonte abre uma sessão de conexão para transmitir a mensagem de EDI e recebe o reconhecimento de validação antes da mesma sessão de conexão ser fechado. Como tal, nenhum acesso à base de dados ou ao armazenamento de dados ou disco E/S durante a validação de documento por- que o processo de validação é manipulado durante o tempo de execução ou durante o recebimento da transação de EDI, como mostrado pela seta 318 na FIG. 3. Em ainda outra modalidade, o processo de validação pode ser estendido por controladores de conexões no tempo de execução.

Em uma modalidade alternativa, os tipos de reco- nhecimento de validação diferentes podem ser gerados e transmitidos para localizações separadas (tal informação de localização pode ser encontrada na porção de cabeçalho 106) enquanto a mensagem de EDI/transações são recebidas. Como tal, as modalidades da invenção geram e transmitem o reco- nhecimento de validação em um ou mais estágios (por exemplo, após validar um aspecto da troca) ou em um estágio simples com reconhecimento consolidado. Em ainda outra modalidade, estes reconhecimentos podem ser configurados para liberação na mesma sessão de conexão de soquete, ou nova, para desti- nos diferentes, como indicado pela seta 320 na FIG. 3.

Por exemplo, suponha-se que os esquemas ou regras de formatação indiquem que um reconhecimento de validação para uma ordem de compra é configurado para ser enviado a um departamento de atendimento ao consumidor de um empreendi- mento enquanto um reconhecimento de validação de fatura é configurado para ser transmitido ao departamento de contabi- lidade do mesmo empreendimento. Aspectos da invenção permi- tem transmitir os respectivos reconhecimentos para o destino apropriado abrindo sessões de conexão novas. FIG. 9A ilustra um reconhecimento de validação para transações de EDI forma- tadas em X12 enquanto a FIG. 9B ilustra um reconhecimento de validação para transações de EDI formatadas, em EDIFACT.

Em outra modalidade, FIG. IlC ilustra um meio le- gível por computador 1120 no qual os aspectos da invenção podem ser armazenados. Por exemplo, um componente de inter- face 1122, um componente de reconhecimento 1124, e um compo- nente de validação 1126 podem ser incorporados e integrados na máquina de EDI 312 para executar uma ou mais etapas como descrito na FIG. 8A.

Aspectos adicionais da invenção permitem modifica- ção dos esquemas de EDI sem requerer dos usuários finais ser tão instruídos quanto um desenvolvedor de esquema de EDI. Por exemplo, suponha-se que um departamento novo seja esta- belecido dentro de um empreendimento, mas não há nenhum es- quema de EDI personalizado ou regra adotada para o departa- mento novo. Em vez de requerer um desenvolvedor de esquema de EDI que projetou um esquema de EDI específico para o de- partamento novo, as modalidades da invenção definem um meta- esquema para representar todos os esquemas de modo que as propriedades dos esquemas são apresentadas aos usuários fi- nais para modificação.

FIG. 10A é uma captura de tela ilustrando um meta- esquema unitário para modificar uma pluralidade de esquemas de EDI de acordo com uma modalidade da invenção. Em uma ja- nela 1002, a estrutura de um meta-esquema unitário é apre- sentada ao usuário final. Assim que o usuário final destacar uma propriedade (indicada pela caixa pontilhada que inclui "MaxOccurs", uma seção de código de propriedade correspon- dente é destacada em uma janela 1004, permitindo o usuário final modificar os valores das propriedades. Em uma modali- dade, o usuário final é provido com uma interface do usuário (UI) incorporando o aspecto da invenção como ilustrado na FIG. 10A. Apêndice A descreve o esquema de XML mostrado na FIG. 10A em sua totalidade.

FIG. 10B é um fluxograma ilustrando um método para modificar a pluralidade dos esquemas de EDI usando o meta- esquema unitário de acordo com uma modalidade da invenção. Em 1006, uma estrutura unitária que representa a pluralidade dos esquemas de EDI é identificada decodificando os dados na pluralidade de esquemas de EDI. Em um exemplo, a estrutura unitária, tal como uma estrutura de dados 1128 na FIG. 11D, representa a pluralidade de esquemas de EDI capturando um ou mais dos dados a seguir:

1. Cada esquema de EDI consiste em um elemento de raiz tendo um nome;

2. O elemento de raiz consiste em repetir blocos de dados que poderiam ser Ciclos ou Segmentos;

3. Cada Ciclo tem a estrutura a seguir

a. Name - Nome do ciclo

b. Block - Coletânea de elementos de dados

c. MinOccurs - Número mínimo de ocorrên- cias

d. MaxOccurs - Número máximo de ocorrên- cias

4. Cada Segmento tem várias propriedades a. Name - Nome do segmento

b. TagId - TagId do segmento

c. MinOccurs - Número mínimo de ocorrên- cias

d. MaxOccurs - número máximo de ocorrên- cias

e. Lista de Elementos de Dados

5. Cada elemento de dados consiste em uma coletâ- nea de elementos, cada um deste poderia ser um Elemento Com- posto ou um Elemento Simples

6. Cada SimpleElement tem várias propriedades

a. Name - Nome do elemento

b. MinOccurs - Número mínimo de ocorrên- cias

c. MaxOccurs - Número máximo de ocorrên- cias

d. MinLength - Comprimento mínimo de da- dos

e. MaxLength - Comprimento máximo de da- dos

f. DataType - Tipo de dados, os valores permitidos são A, AN, ID, R, N, Data, Tempo - um para cada tipo de dados de EDI

g. AllowedValues - Conjunto de valores permitidos, aplicável apenas quando um elemento for de tipo ID.

Por exemplo, a estrutura de dados 1128 inclui um primeiro campo de dados 1130 incluindo dados de raiz associ- ado a um elemento de raiz de cada um da pluralidade de es- quemas de EDI. A estrutura de dados também inclui um ou mais segundos campos de dados 1132 incluindo dados que represen- tam um ou mais blocos de dados de cada um da pluralidade de esquemas de EDI. Os dados no um ou mais segundos campos de dados são definidos como uma função dos dados de raiz no primeiro campo de dados 1130.

Em 1008, as propriedades a ser incluídas na estru- tura unitária são determinadas. As propriedades definem ca- racterísticas da pluralidade dos esquemas de EDI. Por exem- plo, um elemento de raiz com um valor de propriedade de "or- dem de compra" indica que as características da estrutura unitária correspondem a um esquema de ordem de compra, tal como um mostrado na FIG. 7A. Um meta-esquema unitário é de- finido para o usuário como uma função das características definidas e a estrutura unitária em 1010 com a estrutura u- nitária tendo valores de propriedade. 0 meta-esquema defini- do corresponde à pluralidade de esquemas de EDI. Em 1012, as determinadas propriedades no meta-esquema definido são for- necidas ao usuário final de forma que o usuário final é ca- paz de modificar as características de cada um da pluralida- de de esquemas de EDI, como ilustrado na FIG. 10A.

Apêndice B mostra um meta-esquema unitário exem- plar em formato XML que representa um esquema de ordem de compra com a estrutura a seguir: 1. Segmento de PurchaseOrderDetail;

2. Um Ciclo que consiste em segmento de LineItem e ShippingAddress;

3. Segmento de Notes.

FIG. 12 mostram um exemplo de um dispositivo de computação de propósito geral na forma de um computador 130. Em uma modalidade da invenção, um computador tal como o com- putador 130 é adequado para o uso nas outras figuras ilus- tradas e descritas aqui. Computador 130 tem um ou mais pro- cessadores ou unidades de processamento 132 e uma memória do sistema 134. Na modalidade ilustrada, um barramento do sis- tema 136 acopla vários componentes do sistema incluindo a memória do sistema 134 aos processadores 132. O barramento 136 representa um ou mais de quaisquer de vários tipos de estruturas de barramento, incluindo um barramento de memória ou controlador de memória, um barramento periférico, uma porta gráfica acelerada, e um processador ou barramento lo- cal usando qualquer uma de uma variedade de arquiteturas de barramento. Por via de exemplo, e não limitação, tais arqui- teturas incluem barramento de Arquitetura Padrão Industrial (ISA), barramento de Arquitetura de Micro Canal (MCA), bar- ramento de ISA Otimizada (EISA), barramento local da Associ- ação dos Padrões de Eletrônicos de Video (VESA), barramento de Interconexão de Componentes Periféricos (PCI) também co- nhecido como barramento de Mezanino.

O computador 130 tipicamente tem pelo menos alguma forma de meios legíveis por computador. Meios legíveis por computador, que incluem meios voláteis e não-voláteis, meios removíveis e não-removiveis, podem ser qualquer meio dispo- nível que possa ser acessado através do computador 130. Por via de exemplo e não limitação, meios legíveis por computa- dor compreendem meios de armazenamento de computador e meios de comunicação. Meios de armazenamento de computador incluem meios voláteis e não-voláteis, removíveis e não-removíveis, implementados em qualquer método ou tecnologia para armaze- namento de informação tal como instruções legíveis por com- putador, estruturas de dados, módulos de programa ou outros dados. Por exemplo, meios de armazenamento de computador in- cluem RAM, ROM, EEPROM, memória instantânea ou outra tecno- logia de memória, CD-ROM, discos versáteis digitais (DVD) ou outro armazenamento de disco óptico, cassetes magnéticos, fita magnética, armazenamento de disco magnético ou outros dispositivos de armazenamento magnético, ou qualquer outro meio que possa ser usado para armazenar a informação deseja- da e que possa ser acessado através do computador 130. Meios de comunicação tipicamente incorporam instruções legíveis por computador, estruturas de dados, módulos de programa, ou outros dados em um sinal de dados modulado tal como uma onda portadora ou outro mecanismo de transporte e incluem quais- quer meios de liberação de informação. Aqueles versados na técnica estão familiarizados com o sinal de dados modulados que tem um ou mais de suas características fixadas ou alte- radas em uma tal maneira a codificar a informação no sinal. Meios com fios, tais como uma rede com fios ou conexão dire- cionada com fios, e meios sem fios, tais como acústico, RF, infravermelho, e outros meios sem fios, são exemplos de mei- os de comunicação. Combinações de qualquer um dos acima está também inclusa dentro do escopo de meios legíveis por compu- tador .

A memória do sistema 134 inclui meios de armazena- mento de computador na forma de memória removível e/ou não- removível, volátil e/ou não-volátil. Na modalidade ilustrada, memória do sistema 134 inclui memória exclusiva de leitura (ROM) 138 e memória de acesso aleatório (RAM) 140. Um siste- ma básico de entrada/saída 142 (BIOS), contendo as rotinas básicas que ajudam a transferir informação entre os elemen- tos dentro do computador 130, tal como durante a inicializa- ção, é tipicamente armazenado na ROM 138. RAM 140 tipicamen- te contém dados e/ou módulos de programa que são imediata- mente acessíveis e/ou presentemente sendo operados através da unidade de processamento 132. Por via de exemplo, e não limitação, FIG. 12 ilustra sistema operacional 144, progra- mas de aplicação 146, outros módulos de programa 148, e da- dos de programa 150.

O computador 130 pode também incluir outros meios de armazenamento de computador removíveis/não-removíveis, voláteis/não-voláteis. Por exemplo, FIG. 12 ilustra uma uni- dade de disco rígido 154 que lê ou escreve em meios magnéti- cos não-removíveis, não-voláteis. FIG. 12 também mostra uma unidade de disco magnético 156 que lê ou escreve em um disco magnético removível, não-volátil 158, e uma unidade de disco óptico 160 que lê ou escreve em um disco óptico removível, não-volátil 162 tal como um CD-ROM ou outros meios ópticos. Outros meios de armazenamento de computador removíveis/não- removíveis, voláteis/não-voláteis que podem ser usados no ambiente operacional exemplar incluem, mas não são limitados a, cassetes de fita magnética, cartões de memória instantâ- nea, discos versáteis digitais, fita de vídeo digital, RAM de estado sólido, ROM de estado sólido, e outros. A unidade de disco rígido 154, e unidade de disco magnético 156 e uni- dade de disco óptico 160 são tipicamente conectadas ao bar- ramento do sistema 136 por uma interface de memória não- volátil, tal como interface 166.

As unidades ou outros dispositivos de armazenamen- to de massa e seus meios de armazenamento de computador as- sociados debatidos acima e ilustrados na FIG. 12, fornecem armazenamento de instruções legíveis por computador, estru- turas de dados, módulos de programa e outros dados para o computador 130. Na FIG. 12, por exemplo, a unidade de disco rígido 154 é ilustrada como armazenando o sistema operacio- nal 170, programas de aplicação 172, outros módulos de pro- grama 174, e dados de programa 17 6. Observe que estes compo- nentes ou podem ser iguais ou diferentes de sistema opera- cional 144, programas de aplicação 146, outros módulos de programa 148, e dados de programa 150. Sistema operacional 170, programas de aplicação 172, outros módulos de programa 174, e dados de programa 17 6 são números diferentes dado a- qui para ilustrar que, a um mínimo, eles são cópias diferentes.

Um usuário pode entrar os comandos e informação no computador 130 através de dispositivos de entrada ou dispo- sitivos de seleção de interface do usuário tais como um te- ciado 180 e um dispositivo de apontamento 182 (por exemplo, um mouse, trackball, caneta, ou mesa de toque) . Outros dis- positivos de entrada (não mostrados) podem incluir um micro- fone, joystick, acionador de jogo, disco satélite, escâner, ou outros. Estes e outros dispositivos de entrada são conec- tados à unidade de processamento 132 através de uma interfa- ce de entrada de usuário 184 que é acoplada ao barramento do sistema 136, mas podem ser conectados por outra interface e estruturas de barramento, tais como uma porta paralela, por- ta de jogo, ou um Barramento Serial Universal (USB) . Um mo- nitor 188 ou outro tipo de dispositivo de exibição é também conectado ao barramento do sistema 136 por meio de uma in- terface, tal como uma interface de video 190. Além do moni- tor 188, os computadores freqüentemente incluem outros dis- positivos de saida periféricos (não mostrados) tais como uma impressora e alto-falantes que podem ser conectados através de uma interface periférica de saida (não mostrada).

O computador 130 pode operar em um ambiente em re- de usando conexões lógicas a um ou mais computadores remotos, tais como um computador remoto 194. 0 computador remoto 194 pode ser um computador pessoal, um servidor, um roteador, um PC de rede, um dispositivo de ponto ou outro nó de rede co- mum, e tipicamente inclui muitos ou todos os elementos des- critos com relação ao computador 130 acima. As conexões ló- gicas descritas na FIG. 12 incluem uma rede de área local (LAN) 196 e uma rede de área ampla (WAN) 198, mas podem tam- bém incluir outras redes. LAN 136 e/ou WAN 138 pode (m) ser uma rede com fios, uma rede sem fios, uma combinação das mesmas, e assim por diante. Tais ambientes de gestão de re- des são comuns em escritórios, redes de computador de gran- des empresas, intranets, e redes de computadores globais (por exemplo, a Internet).

Quando usado em um ambiente de gestão de redes de área local, o computador 130 é conectado à LAN 196 através de uma interface ou adaptador de rede 186. Quando usado em um ambiente de gestão de redes de longa distância, o compu- tador 130 tipicamente inclui um modem 178 ou outros meios para estabelecer comunicações na WAN 198, tais como a Inter- net. O modem 178 que pode ser interno ou externo é conectado ao barramento do sistema 136 por meio da interface de entra- da de usuário 184, ou outro mecanismo apropriado. Em um am- biente em rede, os módulos de programa descritos com relação ao computador 130, ou porções dos mesmos, podem ser armaze- nados em um dispositivo de armazenamento de memória remoto (não mostrado). Por via de exemplo, e não limitação, FIG. 12 ilustra programas de aplicação 192 remotos como residindo no dispositivo de memória. As conexões de rede mostradas são exemplares e outros meios de estabelecer um vinculo de comu- nicações entre os computadores podem ser usados.

Em geral, os processadores de dados de computador 130 são programados por meio de instruções armazenadas em tempos diferentes nos vários meios de armazenamento legíveis por computador do computador. Programas e sistemas operacio- nais são tipicamente distribuídos, por exemplo, em discos flexíveis ou CD-ROMs. De lá, são instalados ou carregados para a memória secundária de um computador. Na execução, e- Ies estão carregados pelo menos parcialmente para a memória eletrônica primária do computador. Aspectos da invenção des- critos aqui incluem estes e outros vários tipos de meios de armazenamento legíveis por computador quando tais meios con- tiverem instruções ou programas para implementar as etapas descritas abaixo junto com um microprocessador ou outro pro- cessador de dados. Também, aspectos da invenção incluem o próprio computador quando programado de acordo com os méto- dos e técnicas descritas aqui.

Para propósitos de ilustração, programas e outros componentes de programa executável, tais como o sistema ope- racional, são ilustrados aqui como blocos distintos. Porém, é reconhecido que tais programas e componentes residem em vários tempos em componentes de armazenamento diferentes do computador, e são executados pelo processador(es) de dados do computador.

Embora descrito com relação a um ambiente de sis- tema de computação exemplar, incluindo o computador 130, as modalidades da invenção são operacionais com numerosos ou- tros ambientes de sistema de computação ou configurações de propósito geral ou propósito especial. Não é intencionado que o ambiente de sistema de computação sugira qualquer li- mitação sobre o escopo de uso ou funcionalidade de qualquer aspecto da invenção. Além disso, o ambiente de sistema de computação não deveria ser interpretado como tendo qualquer dependência ou requerimento relativo a qualquer um ou combi- nação de componentes ilustrados no ambiente operacional e- xemplar. Exemplos de sistemas de computação, ambientes, e/ou configurações bem conhecidos que podem ser adequados para o uso com os aspectos da invenção incluem, mas não são limitados acomputadores pessoais, computadores servidores, dispositivos portáteis ou laptops, sistemas de multiproces- sador, sistemas com base em microprocessador, dispositivos eletrônicos, eletrônicos programáveis pelo consumidor, tele- fones móveis, PCs de rede, minicomputadores, mainframes, am- bientes de computação distribuídos que incluem quaisquer sistemas ou dispositivos acima, e outros.

As modalidades da invenção podem ser descritas no contexto geral de instruções executáveis por computador, tais como módulos de programa, executados por um ou mais computadores ou outros dispositivos. Em geral, os módulos de programa incluem, mas não são limitados a, rotinas, progra- mas, objetos, componentes, e estruturas de dados que execu- tam tarefas particulares ou implementam tipos de dados de resumo particulares. Aspectos da invenção podem também ser praticados em ambientes de computação distribuídos onde as tarefas são executadas por dispositivos de processamento re- motos que estão ligados através de uma rede de comunicações. Em um ambiente de computação distribuído, módulos de progra- ma podem ser localizados em meios de armazenamento de compu- tador locais e remotos incluindo dispositivos de armazena- mento de memória.

A interface pode ser uma implementação síncrona firmemente acoplada, tal como na Java 2 Platform Enterprise Edition (J2EE), COM, ou exemplos COM distribuído (DCOM). Al- ternativamente ou além disso, a interface pode ser uma im- plementação assincrona livremente acoplada, tal como em um serviço de rede (por exemplo, usando o protocolo de acesso de objeto simples). Em geral, a interface inclui qualquer combinação das características a seguir: firmemente acoplada, livremente acoplada, síncrona, e assincrona. Também, a in- terface pode conformar a um protocolo padrão, um protocolo proprietário, ou qualquer combinação de protocolos padrão e proprietário.

As interfaces descritas aqui podem todas fazer parte de uma interface simples ou podem ser implementadas como interfaces separadas ou qualquer combinação. As inter- faces podem executar local ou remotamente para fornecer fun- cionalidade. Também, as interfaces podem incluir funcionali- dade adicional ou menos que ilustrado ou descrito aqui.

Em operação, o computador 130 executa instruções executáveis por computador tais como aquelas ilustradas nas figuras para implementar os aspectos da invenção.

A ordem de execução ou desempenho das operações nas modalidades da invenção ilustradas e descritas aqui não é essencial, a menos que do contrário especificado. Ou seja, as operações podem ser executadas em qualquer ordem, a menos que do contrário especificado, e as modalidades da invenção podem incluir operações adicionais ou menos que às reveladas aqui. Por exemplo, é contemplado que executando ou desempe- nhando uma operação particular antes, contemporaneamente, ou após outra operação está dentro do escopo dos aspectos da invenção. Modalidades da invenção podem ser implementadas com instruções executáveis por computador. As instruções e- xecutáveis por computador podem ser organizadas em um ou mais componentes ou módulos executáveis por computador. Os aspectos da invenção podem ser implementados com qualquer número e organização de tais componentes ou módulos. Por e- xemplo, aspectos da invenção não são limitados às instruções executáveis por computador especificas ou aos componentes ou módulos específicos ilustrados nas figuras e descritos aqui.

Outras modalidades da invenção podem incluir instruções exe- cutáveis por computador diferentes ou componentes tendo fun- cionalidade maior ou menor que ilustrada e descrita aqui.

Ao introduzir elementos dos aspectos da invenção ou as suas modalidades, os artigos "um", "uma", "o/a", e "dito(a)" são intencionados significar que há um ou mais dos elementos. Os termos "compreendendo", "incluindo", e "tendo" são intencionados ser inclusivos e significam que pode haver elementos adicionais diferentes dos elementos listados.

Visto que várias alterações poderiam ser feitas nas construções, produtos, e métodos acima sem divergir do escopo dos aspectos da invenção, é intencionado que todo o assunto contido na descrição acima e mostrado nos desenhos em anexo deva ser interpretado como ilustrativo e não em um sentido limitativo.

APÊNDICE A

Seção 1: Uma meta-esquema representando um esquema de EDI em formato XML: <?xml version="1.0" encoding="utf-16"?>

<xs:schema xmlns:b="http://schemas.company.com/B izApp/2003"

xmlns="http://schema.company.com/EdiClient/MetaSCHEMA"

targetNamespace="http://schema.company.com/EdiClient/MetaSCHEMA"

xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="EdiSchemaRoot">

<xs:complexType>

<xs:sequence>

<xs:element name="RootElementName" type="xs:string" />

<xs:element ref="Block" />

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="Block" type-"BlockType" />

<xs:element name-"Segment">

<xs:complexType>

<xs:sequence>

<xs:element name="Name"type="xs:string" />

<xs:element name="TagId"type="xs:string" />

<xs:element name="MinOccurs"type="xs:integer" />

<xs:element name="MaxOccurs"type="xs:integer" />

<xs:element name="DataElementList">

<xs:complexType>

<xs:sequence>

<xs:choice minOccurs="1" maxOccurs="unbounded">

<xs:element name=" CompositeElement">

<xs:complexType>

<xs:sequence> <xs:element name="Name" type="xs:striiig" /> <xs:element maxOccurs="unbounded" ref="SimpleElement" />

</xs:sequence> </xs:complexType> </xs:element>

<xs:element reí="SimpleElement" /> </xs:choice> </xs:sequence> </xs :complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element>

<xs:element name="SimpleEIement"> <xs: complexTyp e> <xs:sequence> <xs:element name="Name" type—'xs:string" /> <xs:element name="MinOccurs" type="xs:string" /> <xs:elementname="MaxOccurs" type="xs:string" /> <xs:element name="MinLength" type="xs:string" /> <xs:element name="MaxLength" type="xs:string" /> <xs:element name="DataT5φe"> <xs :simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="A" /> <xs:enumeration value="N" /> <xs:enumeratíon value="ID" /> <xs:enumeration value="R" /> <xs:enumeration value=="AN" /> <xs:enumeration value="Date" /> <xs:enumeration value="Time" /> </xs:restrictíon> </xs: simpleType> </xs:element>

<xs:element min0ccurs="0" maxOccurs="unbounded" . name="AllowedValues" type="xs:string" /> </xs:sequence> </xs :complexType> </xs:element>

<xs: coxnplexType name="BlockType"> <xs:sequence> <xs:choice min0ccurs="0" maxOcciors="unbounded"> <xs:element name="Loop"> <xs:complexType> <xs:sequence> <xs:element name="Name" type="xs:string" t> <xs:elementref="Block" t> <xs:element name="MinOccurs" type="xs:int" /> <xs:elementname="MaxOccurs" type="xs:int" /> </xs:sequence> </xs:complexType> </xs:element>

<xs:element ref="Segment" /> </xs:choice> </xs:sequence> </xs: compíexType>

</xs:schema> Seção 2: Esquema de ordem de compra de amostra vi- sando a estrutura unitária de meta-esquema:

<nsO:EdiSchemaRoot xmliis:nsO="http://schemaxompanyxoni/E(üCüent/MetaSCHEMA"> <RootElementN ame>Xl 2_0050 l_850</RootElementName> <Block> <Segment> <Name>Purchas eOrderD etail</Name> <TagId>PUR</TagId> <MinOccurs> 1 </MinOccurs> <MaxOccurs>l</MaxOccurs> <DataElementList> <SimpleElement> <Name>OriginatorId</Name> <MinOccurs> 1 </MinOccurs> <MaxOccurs> 1</Max0ccurs> <MinLength>4</MinLength> <MaxLength> 10</M axLength> <DataType>AN</DataType> </SimpleElement> <SimpleElement> <Name>FirstName</Name> <MinOccurs> 1 </MinOccurs> <MaxOccurs>I</MaxOccurs> <MinLength> 1 </MinLength> <MaxLength> 10</MaxLength> <DataType>AN</DataType> </SimpleElement> <SimpleElement> <Name>LastName</N ame> <MinOccurs>l</MinOccurs>

</SimpleElement> </DataElementList> </Segment>

<Loop>

<Name>LineItemLoop></Name> <MinOccurs> 1 </MinOccurs>

<MaxOccurs>imbounded</MaxOccurs> <Block>

<Name>LineItem</Name> <TagId>L]N</TagId> <MinOccurs> 1 </MinOccurs>

<Name>ItemId</Name> <MinOccurs> 1 </MinOccurs>

<Name>Quantity</Name> <MinOccurs> 1 </MinOccurs> <MaxOccurs>l</MaxOccurs> <MinLength> 1 </MinLength> <MaxLength>5</MaxLength> <DataType>N</DataType> </SimpleElement> </DataElementList>

</Segment> <Segment>

<Name>ShipTo</Name> <TagId>SHP</TagId> <MinOccuxs> 1 </MinOccurs> <MaxOccurs>l</MaxOccurs> <DataElementList>

<Namè>FirstName</Name> <MinOccurs>l</MinOccurs>

<Name>LastName</Name> <MinOccurs>l</MinOccurs>

<Name>Address</Name> <SimpleElement> <Name>StreetInfo</N ame> <MinOccurs>l</MinOccurs>

<MinLeng£h> l</MinLength> <MaxLength> 100</MaxLeng th>

<Name>State</Name> <MinOccurs> 1 </MinOccurs>

</Segment> </Block> </Loop> <Segment>

<Name>Notes</Name> <TagId>NTE</TagId> <MinOccurs>0</MinOccurs> <MaxOccurs>l</MaxOccurs> <DataElementList> <SimpleElement>

<Name>NoteLine 1 </N ame> <MinOccurs>0<MinC)ccurs>

<Name>NoteLine2</Name> <MinOccurs>0</MinOccurs>

<Name>NoteLine3</Name> <MinOccurs>0</MinOccurs>

Claims

1. Método implementado pelo menos em parte por um dispositivo de computação para transformar transações de troca eletrônica de dados (EDI), CARACTERIZADO pelo fato de que o dito método compreende: receber dados de EDI em um lote, o dito lote de dados de EDI incluindo uma pluralidade de documentos de EDI, cada um tendo pelo menos uma transação de EDI que correspon- de a um tipo de transação; identificar as transações de EDI inclusas nos do- cumentos de EDI decodificando os dados de EDI recebidos- de acordo com os padrões de EDI; e gerar um documento de EDI consolidado da plurali- dade de documentos de EDI no lote, o dito documento de EDI consolidado incluindo dados de EDI das transações de EDI i- dentificadas e organizadas de acordo com o tipo de transação

2. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que o documento de EDI consolida- do é um documento de linguagem de marcação extensível (XML).

3. Método, de acordo com a reivindicação 2, CARACTERIZADO pelo fato de que adicionalmente compreende or- ganizar as transações de EDI inclusas no documento de EDI consolidado através de marcadores de XML, em que os marcado- res de XML indicam os tipos de transação das transações de EDI.

4. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que o documento de EDI consolida- do inclui um uber-esquema, o dito uber-esquema representando uma pluralidade de esquemas referidos pelas transações de EDI.

5. Método, de acordo com a reivindicação 4, CARACTERIZADO pelo fato de que adicionalmente compreende de- finir um mapa de esquema de tempo de execução para transfor- mar a pluralidade de esquemas para processamento durante o tempo de execução.

6. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que adicionalmente compreende or- ganizar as transações de EDI no documento de EDI consolidado como sub-documentos de acordo com uma ou mais informações inclusas nas transações de EDI, e em que as transações de EDI nos sub-documentos correlatam com as transações de EDI na pluralidade de documentos de EDI.

7. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que um ou mais meios legíveis por computador têm instruções executáveis por computador para executar o método da reivindicação 1.

8. Sistema para transformar transações de troca eletrônica de dados (EDI) entre uma fonte transmissora e um dispositivo de recepção, CARACTERIZADO pelo fato de que o dito sistema compreende: uma fonte transmissora para transmitir dados de EDI em um lote, o dito lote de dados de EDI incluindo uma pluralidade de documentos de EDI, cada um tendo pelo menos uma transação de EDI que corresponde a um tipo de transação; uma interface para receber dados de EDI no lote; um processador para executar instruções executá- veis por computador para: identificar as transações de EDI inclu- sas na pluralidade de documentos de EDI decodificando os da- dos de EDI recebidos de acordo com os padrões de EDI; e definir um documento de EDI consolidado da pluralidade de documentos de EDI no lote de dados de EDI, o dito documento de EDI consolidado incluindo as transações de EDI identificadas organizadas de acordo com o tipo de transação.

9. Sistema, de acordo com a reivindicação 8, CARACTERIZADO pelo fato de que o documento de EDI consolida- do é um documento de linguagem de marcação extensível (XML).

10. Sistema, de acordo com a reivindicação 9, CARACTERIZADO pelo fato de que o processador é também confi- gurado para organizar as transações de EDI inclusas no docu- mento de EDI consolidado através de marcadores de XML, em que os marcadores de XML indicam os tipos de transação das transações de EDI.

11. Sistema, de acordo com a reivindicação 8, CARACTERIZADO pelo fato de que o documento de EDI consolida- do inclui um uber-esquema, o dito uber-esquema representando uma pluralidade de esquemas referidos pelas transações de EDI.

12. Sistema, de acordo com a reivindicação 11, CARACTERIZADO pelo fato de que a interface adicionalmente recebe um mapa de esquema de tempo de execução para trans- formar a pluralidade de esquemas para processamento pelo processador.

13. Sistema, de acordo com a reivindicação 12, CARACTERIZADO pelo fato de que o processador é configurado para aplicar o mapa de esquema de tempo de execução para equi- parar a pluralidade de esquemas durante o tempo de execução.

14. Sistema, de acordo com a reivindicação 8, CARACTERIZADO pelo fato de que o processador é também confi- qurado para orqanizar transações de EDI no documento de EDI consolidado como sub-documentos de acordo com uma ou mais informações inclusas nas transações de EDI, e em que as transações de EDI nos sub-documentos correlatam com as tran- sações de EDI na pluralidade de documentos de EDI.

15. Meio legível por computador tendo componentes executáveis por computador para transformar as transações de troca eletrônica de dados (EDI), CARACTERIZADO pelo fato de que os ditos componentes executáveis por computador compre- endem: um componente de interface para receber dados de EDI em um lote de uma fonte transmissora e transmitir os da- dos de EDI recebidos a um recipiente, o dito lote de dados de EDI incluindo uma pluralidade de documentos de EDI, cada um tendo pelo menos uma transação de EDI que corresponde a um tipo de transação; um componente de identificação para identificar as transações de EDI inclusas na pluralidade de documentos de EDI decodificando os dados de EDI recebidos de acordo com os padrões de EDI; e um componente de transformação para definir um do- cumento de EDI consolidado da pluralidade de documentos de EDI no lote de dados de EDI, o dito documento de EDI conso- lidado incluindo as transações de EDI identificadas e orga- nizadas de acordo com o tipo de transação.

16. Meio legível por computador, de acordo com a reivindicação 15, CARACTERIZADO pelo fato de que o documento de EDI consolidado é um documento de linguagem de marcação extensível (XML).

17. Meio legível por computador, de acordo com a reivindicação 16, CARACTERIZADO pelo fato de que adicional- mente compreende um componente de documento para organizar as transações de EDI inclusas no documento de EDI consolida- do através de marcadores de XML, em que os marcadores de XML indicam os tipos de transação das transações de EDI.

18. Meio legível por. computador, de acordo com a reivindicação 17, CARACTERIZADO pelo fato de que o componen- te de documento também organiza transações de EDI no docu- mento de EDI consolidado como sub-documentos de acordo com uma ou mais informações inclusas nas transações de EDI, e em que as transações de EDI nos sub-documentos correlatam com as transações de EDI na pluralidade de documentos de EDI.

19. Meio legível por computador, de acordo com a reivindicação 15, CARACTERIZADO pelo fato de que o documento de EDI consolidado inclui um uber-esquema, o dito uber- esquema representando uma pluralidade de esquemas referidos pelas transações de EDI.

20. Meio legível por computador, de acordo com a reivindicação 15, CARACTERIZADO pelo fato de que o componen- te de interface adicionalmente recebe um mapa de esquema de tempo de execução para transformar a pluralidade de esquemas para processamento pelo processador no tempo de execução.