Mapping editor — cards e métricas

O editor de mapeamento é organizado destino-first: o que o cliente recebe (INVOIC, 850, IDoc, NFe etc) vem antes do source SAP.

Os 6 cards do topo

Da esquerda pra direita:

1. Campos Destino (roxo) — total do catálogo destino. Tamanho da mensagem que vai sair.
2. Destino Coberto (verde) — quantos fields do destino já têm rule ativa (não-ignore). Métrica de cobertura.
3. Obrig. Sem Origem (vermelho) — gargalo principal. Quantos fields obrigatórios do destino estão sem source. Mensagem provavelmente não serializa enquanto > 0.
4. Mapeados por IA (cyan) — rules sugeridas pela IA com destino preenchido.
5. Mapeados Manual (verde) — rules criadas/editadas pelo operador.
6. Campos Origem (azul) — total do catálogo source. Sinal secundário (referência).

Clicar em qualquer card filtra a lista de regras abaixo. Card #3 (Obrig. Sem Origem) tem comportamento especial: lista fica vazia, banner aponta pra view Estrutura destino (esses fields vivem no catálogo, não em regras).

Banner de cobertura

• vermelho quando Obrig. Sem Origem > 0: "X campos obrigatórios do destino sem origem (Y/Z destino cobertos)"
• azul quando 0 obrigatórios faltando + cobertura < 100%: "X campos do destino cobertos (Y/Z)"
• some quando 100% coberto

Chips de filtro

Ordem destino-first:

Todos | Mapeados | Obrig. Sem Origem | Destino Sem Cobertura | IA | Manual | Dados Não Usados | [Conflitos]

• Mapeados — rules ativas com source+destino+não-ignore (sinal "está OK")
• Obrig. Sem Origem — filtro de alerta, mesmo comportamento do card vermelho
• Destino Sem Cobertura — fields destino sem rule (mostra rules com source mas sem dest)
• Dados Não Usados — source sem destino (informativo, não bloqueia)
• Conflitos — só aparece quando há 2+ rules pro mesmo destino

View estruturada

A view "Estrutura destino" mostra os fields do destino organizados em árvore (header + loops). A view "Estrutura origem" agora reconhece navs aninhadas corretamente — to_Item.to_PricingElement.X aparece como sub-árvore de to_Item[*], não como sibling top-level.

Por que destino-first

O Lefia entrega destino preenchido pro cliente/parceiro/sistema downstream. As métricas refletem isso: gargalos do destino (campos obrigatórios faltando) são alarmes; sobras do source ("dados não usados") são apenas informação.

Conflitos e regras órfãs (28/09/2026)

• Duas origens no mesmo campo: quando duas regras ativas escrevem o mesmo elemento de destino (na mesma instância, ex.: MOA+203 da linha com o valor bruto e o líquido), o valor dependeria da ordem das regras. Publicar é recusado com a lista do que conflita. Resolva em Resolver conflitos (fica a regra escolhida) ou deixe as outras como reserva (só preenchem o que a principal deixou vazio). A publicação não escolhe mais sozinha pela confiança da sugestão; só remove regras repetidas idênticas. O que já está publicado continua rodando como está. Restaurar uma versão antiga com conflito também pede a escolha; num incidente, o suporte da Lefia pode restaurar à força (fica registrado). Publicar ou restaurar à força mantém as duas origens ativas: o arquivo sai pela ordem das regras (no cabeçalho vale a primeira origem com valor; na linha e na instância, como o MOA+203, vale a última), e não por uma escolha. A confirmação do "à força" lista cada elemento em conflito, diz qual origem vence, a fila em que o motor tenta as outras se ela vier vazia e cada outro bloqueio que será ignorado junto (como o Quality Gate), e essa escolha fica registrada na trilha da ativação à força.
• Regras com destino fora do catálogo: aparecem num grupo próprio no topo da árvore, com Remapear (abre a regra para trocar o destino) e Remover. Antes contavam nos cards e não apareciam na árvore.

Ordem declarada entre origens (28/09/2026)

Quando o Sugerir (ou o Criar com Mapeamento IA) encontra duas origens para o mesmo campo, a ordem vem da base de conhecimento do Lefia, não da ordem das regras: por exemplo, no código do item (LIN) o GTIN é a principal e o material fica de reserva (só preenche quando o item não tem GTIN); no tipo do documento, o tipo da fatura vem antes da categoria; a unidade sai pelo código ISO. A reserva aparece marcada no editor e não conta como conflito. Se duas origens não têm ordem declarada, o conflito continua aparecendo para você escolher antes de publicar.

No aviso de remessa (DESADV) e na fatura (INVOIC), quando o LIN leva o GTIN, o material sai também no PIA+5 como número do artigo do fornecedor (tipo SA); sem GTIN, o LIN já leva o material e o PIA não o repete. Na saída EDIFACT, o NAD da linha só sai quando a parte da linha é diferente da do cabeçalho na mesma função; a igual fica só no cabeçalho. Isso vale para mapeamentos novos ou gerados de novo pelo Sugerir: os publicados continuam enviando o mesmo arquivo.