Erros Conhecidos Arquivo EDIFACT

Trabalhar com arquivos no formato EDIFACT pode ser um pouco complicado. 

Como falamos anteriormente aqui, cada parceiro pode enviar a mensagem do seu jeito.

E isso pode acarretar vários tipos de erros, que são difíceis de identificar.

Por isso resolvi aqui compilar os erros mais comuns, aos quais tive o prazer de pesquisar na internet pra tentar achar uma solução. #sqn 

Vamos lá:

[4] Invalid Segment Terminator

Causa: O UNA6 Sufix esta configurado para receber CR LF, (enter) e o arquivo veio somente com LF ou outro caracter.

Solução: Colocar no Edifact Delimeters do Pipeline para o Biztalk aceitar outro terminador alem do CR LF

0x3A, 0x2B, 0x2C, 0x3F, 0x20, 0x27, 0x0A sem CR (Configuração no Pipeline para parceiros que enviam somente o LF)

0x3A, 0x2B, 0x2C, 0x3F, 0x20, 0x27, 0x0d, 0x0a com CR e LF  (Configuração no Pipeline para parceiros que enviam  o CR LF)

----------------------

[21]: Invalid character found

Causa: Caracter especial não permitido.

No segmento UNB existe o enconding que o biztalk deve usar. O padrão é UNOA que não aceita caracteres especiais. O parceiro deve enviar UNOC no segmento UNB se realmente precisar enviar caracteres especiais como Ç ou Ã.

UNB+UNOC:1+PARCEIROA+MINHAEMPRESA+131104:2120+134457'

---------------------------

[26]: Duplicate transaction set detected

Causa: No segmento UNH, o mesmo número que identifica a mensagem, esta sendo usada em outra mensagem no mesmo arquivo. 

UNH+SN000000012190+CODECO:D:95B:UN'

-------------------------

[29] Invalid count specified at interchange, group or message level

Causa 1: Número total de segmentos errado. O Biztalk faz uma contagem entre o segmento UNH e o UNT. 

UNT+22+33999'

Causa 2: Número total de mensagens dentro do arquivo errado. No final do arquivo no segmento UNZ, é preciso colocar a quantidade certa de  mensagens dentro do arquivo.

UNZ+23+000000007'

------------------------

[33]: Invalid occurence outside message, package or group.

Causa: Falta colocar o CRLF como terminador no pipeline

0x0d, 0x0a

---------------------

[45]: Trailing separator found

Solução: Permitir no Agreement do Parceiro que venha com espaços.

---------------------

[71] Transaction Set or Group Control Number Mismatch.

Causa: Número de identificação da mensagem diferente entre os segmentos. O segmento UNH e o UNZ são segmentos de controle e devem ter um número que identifica a mensagem dentro do arquivo EDI.

UNH+33999+CODECO:D:95B:UM:ITG010'

UNT++33999'

----------------

[72]: Unrecognized segment ID

Causa: Arquivo com terminador inválido. Nesse caso, esse parceiro, envia o arquivo com o terminador de segmento sendo aspas simpes " ' " e tinha duas aspas simples, no meio do arquivo, como terminador ao invés de uma.

TDT+20++1+13+LAP:172:20+++9619440:::AAAA BBBB''

--------------------

[76]: Too few data elements

Causa: Faltando segmento obrigatório dentro do arquivo EDIFACT. No schema alguns segmentos estão configurados para serem obrigatórios e devem ser enviados.

--------------------

Leia mais »»

Setando Porta Dinamica - EDI

Olá Pessoal.

Hoje vou falar sobre setar porta dinamica para enviar uma mensagem EDI dentro da orchestration. Já postei aqui um pouco sobre o EDI.

Considerem o seguinte cenario:

1. FABRIKAM envia a mensagem EDIFACT para CONTOSO.
2. CONTOSO por sua vez recebe essa mensagem e faz algum processamento.
3. CONTOSO envia mensagem EDIFACT para diretório dinamico, para ser processada por sistema Interno.

Então eu estou usando uma porta dinamica comum dentro da orchestration e que poderia setar dessa forma.

port_Dynamic_EDIFACT(Microsoft.XLANGs.BaseTypes.Address) = @"file://"+strPath+\\%SourceFileName%;

Até aqui nenhuma novidade, o problema é que o sistema Interno só aceita EDIFACT, e dessa forma eu não estou usando os Agreements configurados no Console do Biztalk.

Então a mensagem não setava corretamente o parceiro, sendo gravada no diretório dinamico dessa maneira:


Notem o BTS-SENDER e o RECEIVE-PARTNER.

Isso quer dizer que o Biztalk não identificou o parceiro daquela mensagem, e jogou o parceiro padrão do sistema.

Para evitar isso devemos setar também o parceiro na mensagem. Segue:

   1:  msgOUT = msgIN;

   2:   

   3:  Port_2(Microsoft.XLANGs.BaseTypes.Address) = @"file://C:\\Ruth\\%SourceFileName%";

   4:   

   5:  msgOUT(EDI.DestinationPartySenderIdentifier) = "7654321";

   6:  msgOUT(EDI.DestinationPartySenderQualifier) = "";

   7:  msgOUT(EDI.DestinationPartyReceiverIdentifier) = "1234567";

   8:  msgOUT(EDI.DestinationPartyReceiverQualifier) = "";

Essas propriedades EDI para serem acessadas, é preciso adicionar a referencia Microsoft.BizTalk.Edi.BaseArtifacts.dll, ao projeto. Segue o caminho disponivel:

C:\Windows\assembly\GAC_MSIL\Microsoft.BizTalk.Edi.BaseArtifacts\3.0.1.0__31bf3856ad364e35\Microsoft.BizTalk.Edi.BaseArtifacts.dll

Segue a mensagem de saída com o parceiro configurado e garantido que está usando o Agreement.


Referencia: http://blogs.msdn.com/b/biztalkb2b/archive/2007/02/12/key-new-feature-in-february-ctp.aspx

É isso, Até a próxima.

E você? Já ajudou a comunidade hoje?

Leia mais »»