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 — e por que violação estrutural bloqueia a ativação do mapping.
O que é
Além do smoke estrutural ("o mapping serializa?"), 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 — ocorrências respeitam o máximo da spec;
- Code lists — valores de elementos codificados pertencem à lista oficial (milhares de códigos UN/EDIFACT no catálogo);
- Formato — tamanhos (AN..35, N..18) e tipos numéricos;
- Obrigatórios — campos required (relativos ao composite pai) e os absolutamente obrigatórios da mensagem;
- Ordem — sequência segue a árvore canônica da spec.
Vale pra EDIFACT e X12 — os checks efetivos vêm do que o catálogo da mensagem declara; enriquecer o catálogo liga mais verificações automaticamente, sem código.
Extensões por agência (EANCOM/GS1)
Agências estendem as code lists UN com códigos próprios (ex.: EANCOM usa TU/CU/DU em descrição de item). Quando o interchange declara a associação (ex.: "EAN011" no envelope), o Lefia valida com a união lista UN + extensão da agência — sem afrouxar a spec UN pra quem não é da agência.
Onde aparece
No Quality Gate do mapping: violação estrita ESTRUTURAL bloqueia a ativação (código
STRICT_SPEC) — um mapping que emite fora da spec não ativa. Mensagem nova no catálogo é validável automaticamente.Nos acks funcionais (CONTRL/997): o veredito do ack devolvido ao parceiro vem desta validação.
Como confiamos nele
Provado nas duas direções contra um corpus de exemplos oficiais (EANCOM/GS1) e amostras X12: os exemplos reais passam com 0 erros (se reprovassem, o errado seria o validador) e violações injetadas são todas detectadas. Antes de bloquear ativação, a regra foi verificada contra todos os mappings ativos em produção — zero falso-positivo.
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).
6/12/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).
6/12/2026 · new