FT-CATALOG-SCHEMA-V3· V3.6Mappings & EDI Hub
Paths qualificados V3 — fim da ambiguidade C21201
Por que o catálogo destino agora mostra LIN.C212.C21201 em vez de C21201 plano, e como o mapping fica não-ambíguo.
Atualizado em 5/20/2026
O problema antes
O mesmo
name aparecia em múltiplos contextos:
- EDIFACT:
C21201em BGM (header) vs LIN (loop SG26) vs PIA — cardinalidades diferentes - X12:
REF02em ST.REF (header) vs PO1.REF (item) - IDoc:
BELNRem E1EDK01 (header) vs E1EDP01 (item)
Mapping dizia
destination_field: "C21201" — engine não sabia qual contexto. Output saía column-oriented em vez de row-oriented por loop. Validador externo (stedi.com, edifact-tools) rejeitava.Solução V3
Cada field do catálogo destino ganha 3 metadados novos:
qualifiedName— identificador único:LIN.C212.C21201≠BGM.C002.C00204segmentPath— ancestors (LIN.C212) pra UI agruparcompositePath— composite quando aplicável (C212,C002)
IA gerador, save-mapping, engine e serializer todos usam o path qualificado ponta-a-ponta. Output EDIFACT sai com
: correto entre composite sub-elements.O que muda pra você
- Tela de catálogo agrupa visualmente: header → loops → footer
- Mapping editor mostra paths como
LIN.C212.C21201(claros sobre contexto) - Detalhe da mensagem tem nova seção Output serializado pra copiar e validar em ferramenta externa
Histórico de versões
- V3.6
Perf: cache TTL 60s no loadAllStandards + findEffectiveFormat TARGETED (carrega só o formato pedido). Cold 3.5s→870ms; abrir/salvar/publicar mapping de ~20-25s → sub-segundo após warm.
6/9/2026 · updated
- V3.5
Catálogos OData SAP regenerados em V3 (7 mensagens: A_BillingDocument, A_BusinessPartner, A_OutbDeliveryHeader v1+v2, A_Product, A_PurchaseOrder, A_SalesOrder). Script reusável npm run migrate:sap-v3.
5/21/2026 · updated
- V3.0
Schema V3 do catálogo destino: qualifiedName + segmentPath + compositePath em cada field. 8226 fields × 5 standards × 100% qualified. Resolve ambiguidade C21201/REF02/BELNR.
5/21/2026 · new