Validação estrita contra a spec (catálogo)
Como o Lefia verifica que a saída EDI (EDIFACT e X12) segue a spec real da mensagem — no mapping (quality gate) e em cada envio, antes do arquivo sair.
O que é
O Lefia valida a saída EDI contra a spec real da mensagem no catálogo — verificações derivadas 100% do catálogo:
- Segmento desconhecido — todo segmento emitido existe na mensagem;
- Cardinalidade por grupo — cada segmento e cada grupo (loop) é contado dentro da ocorrência do grupo pai e comparado com o máximo da spec (ex.: o grupo TAX do cabeçalho do ORDERS D01B aceita no máximo 5);
- Code lists — valores de elementos codificados pertencem à lista oficial;
- Formato — tamanhos (AN..35, N..18) e tipos numéricos;
- Obrigatórios — campos obrigatórios de cada segmento emitido (relativos ao composite pai) e os absolutamente obrigatórios da mensagem;
- Ordem — sequência segue a árvore canônica da spec;
- Envelope — contagem e referência de UNH/UNT e UNB/UNZ (EDIFACT) e ST/SE, GS/GE, ISA/IEA (X12).
Vale para EDIFACT e X12. Enriquecer o catálogo liga mais verificações automaticamente, sem código.
Onde aparece
- Antes de cada envio: o arquivo que vai ao parceiro é validado por completo. Reprovou, não sai — a mensagem fica "Reprovado na spec" com a lista de erros (segmento, elemento, ocorrência e linha). Veja o artigo "Mensagem Reprovado na spec". Não há isenção para empresa de demonstração.
- No Quality Gate do mapping: a mesma validação, sobre uma amostra, bloqueia a ativação de um mapping que emite fora da spec (código
STRICT_SPEC). Na amostra não se olham valores, mas obrigatório ausente, cardinalidade e ordem valem. - Nos acks funcionais (CONTRL/997): o veredito devolvido ao parceiro vem desta validação.
Extensões por agência (EANCOM/GS1)
Agências estendem as code lists UN com códigos próprios. Quando o interchange declara a associação (ex.: "EAN011" no UNH), o Lefia valida com a união lista UN + extensão da agência.
Como confiamos nele
Provado nas duas direções: exemplos oficiais (EANCOM/GS1) e amostras X12 passam, e violações injetadas são detectadas. O caso real de uma SalesOrder do sandbox SAP convertida em ORDERS D01B é teste permanente: o Lefia acusa os mesmos erros que o validador externo acusou.
Código de outra lista (agência do vendedor ou do comprador)
Alguns elementos codificados vêm acompanhados, no mesmo grupo de dados, da agência responsável pela lista (elemento 3055). Quando ela é a ONU (6) ou não vem, o código tem de estar na lista publicada da spec. Quando é outra — 91 (lista do vendedor) ou 92 (lista do comprador) — o código é dessa outra lista, e a validação não exige a lista da ONU para ele. A validação aceita esses códigos pela spec, mas avisa (veja abaixo). A própria agência continua sendo validada.
A checagem do "Sugerir" usa o arquivo real
A validação estrita feita ao sugerir monta o arquivo de teste na mesma ordem e com os mesmos segmentos de serviço (UNS) do arquivo que o parceiro recebe. Antes, ela podia apontar repetição de segmento num arquivo válido.
Agência válida, agência de extensão e quem decide a agência
A lista da spec só deixa de valer para o código quando a agência informada existe na lista de agências (elemento 3055) — agência inexistente não libera nada. Com a agência 9 (GS1) a lista oficial continua valendo, somada à extensão EANCOM. Na geração, a agência sai só para o código cujo conceito declara quem o atribui (ex.: a chave da condição de pagamento é do vendedor →
91); outro valor na mesma posição continua preso à lista da spec.Código do emissor em campo de código: aviso de interoperabilidade
Quando um campo de código sai com um código da lista do próprio vendedor ou comprador (agência 91 ou 92) e esse código não está na lista oficial, a spec aceita — mas a maioria dos parceiros valida só a lista oficial e reprova o arquivo. Nesses casos a validação mostra um aviso (não um erro) com o segmento, o elemento, a linha e o valor. O aviso aparece em Ver saída e no envio do monitor.
Por isso a chave da condição de pagamento do SAP (por exemplo 0004) sai como texto: no EDIFACT em
FTX+AAB+++0004 (texto das condições de pagamento), no X12 no ITD12 e no IDoc no ZTERM. A condição de pagamento (PAT+1) só sai quando a origem tem o número de dias; o desconto por pagamento antecipado (PAT+22) continua como antes. As notas do documento e da linha saem como FTX+AAI (informação geral).Histórico de versões
- 1.1.0
Validação estrita agora cobre x12 além de EDIFACT (mesmos checks derivados do catálogo — o ack 997 passa a refletir validação real do interchange) e entende extensões de code list por agência: interchanges EANCOM/GS1 (declarados no envelope) validam com a união das listas UN + códigos EAN (TU/CU/DU, 33E, 45E…), sem afrouxar a spec UN pra quem não é da agência. Violações estritas estruturais agora BLOQUEIAM a ativação do mapping no Quality Gate (antes eram aviso) — promoção feita após verificação contra todos os mappings ativos em produção (zero falso-positivo).
12/06/2026 · updated
- 1.0.0
Validador estrutural ESTRITO spec-driven (#396): toda saída EDIFACT agora pode ser verificada contra a spec REAL do catálogo — 6 checks derivados 100% do catálogo (segmento desconhecido, cardinalidade, code lists, formato/tamanho, obrigatórios relativos e absolutos, ordem canônica). Provado nas duas direções com exemplo EANCOM oficial (0 erros) e violações injetadas (todas detectadas). Integrado ao Quality Gate do mapping como aviso informativo (STRICT_SPEC). Corpus de goldens reais congela o comportamento (#370).
12/06/2026 · new