Instâncias qualificadas: parceiros e segmentos repetidos (NAD+BY, MOA+203)

O que são instâncias qualificadas

Em EDIFACT/X12 o MESMO segmento se repete várias vezes, distinguido por um código (qualifier):

• NAD+BY = comprador · NAD+IV = faturado · NAD+PE = pagador · NAD+ST = entrega
• MOA+203 = valor da linha · MOA+77 = total da fatura
• RFF+ON = nº do pedido · DTM+137 = data da fatura

O Lefia gera essas instâncias automaticamente a partir do SAP. Você não precisa criar uma regra por parceiro à mão.

Parceiros (NAD) — vêm de um array no SAP

O SAP entrega os parceiros num array to_Partner[*], cada um com um PartnerFunction (AG = sold-to, RE = bill-to, RG = payer, WE = ship-to, LF = vendor). Ao clicar Sugerir IA, o Lefia lê esse array e cria:

• AG → NAD+BY (comprador) · RE → NAD+IV (faturado) · RG → NAD+PE (pagador) · WE → NAD+ST (entrega) · LF → NAD+SU (fornecedor)

Você reconhece uma regra qualificada pelo chip verde ⌖ (ex: ⌖ NAD+PE) ao lado da transformação. O mapa de códigos é editável (admin) caso sua empresa use funções de parceiro customizadas.

Itens (LIN) — cada linha com seus sub-segmentos

Cada linha de item pode ter os seus próprios segmentos repetidos: MOA+203 (valor da linha), QTY+47 (quantidade), RFF+ON (referência). O Lefia também gera isso por linha — você vê os sub-segmentos aninhados sob cada LIN no editor.

Mesmo grupo no cabeçalho e no resumo

Algumas mensagens têm o mesmo grupo duas vezes no mesmo nível: no INVOIC, o grupo de imposto (TAX com MOA) do cabeçalho e o do resumo, depois do UNS. No catálogo, o do resumo tem caminho próprio, com o número da ocorrência (TAX_2, ALC_2); no arquivo o segmento continua sendo TAX. O Sugerir IA põe o imposto do documento no TAX+7 do resumo (TAX+7 com MOA+124, a soma do imposto das linhas); o imposto de cada linha continua no TAX+7 da linha. Mapeamentos já publicados não mudam: o que escreve em TAX continua saindo no cabeçalho.

Na entrada (o arquivo do parceiro lido pelo Lefia), o grupo do resumo entra no mesmo caminho: TAX_2, ALC_2. O Sugerir IA lê o imposto do documento no resumo (TAX_2, uma linha por alíquota), com o do cabeçalho de reserva, e a linha sem imposto próprio herda o do documento. Um mapeamento publicado antes disso, que lê TAX e não conhece TAX_2, continua recebendo o imposto do resumo junto com o do cabeçalho, como antes — o documento que ele envia não muda até você gerar as regras de novo e publicar.

Com itens de alíquotas diferentes na mesma fatura, o resumo tem um TAX+7 com MOA+124 por alíquota: os itens são agrupados pelo código de imposto e pela alíquota que a origem informa por item, e cada grupo leva a soma do imposto dos seus itens. A alíquota sai no grupo quando a origem a informa por item; o tipo do imposto sai quando o código tem de-para cadastrado. Sem a alíquota e sem de-para do código, os grupos não teriam como se distinguir: sai um grupo só com a soma. Se algum item de uma alíquota vier sem o valor do imposto, o grupo dessa alíquota não sai (a soma seria parcial) e a mensagem traz o aviso; se algum item vier sem o código ou a alíquota que separa os grupos, o resumo não sai, também com o aviso. Fatura de uma alíquota só sai igual a antes, exceto quando o item informa a alíquota ou o código tem de-para cadastrado: aí o grupo único leva a alíquota ou o tipo do imposto.

⚠️ Faltou parceiro no resultado? (causa nº 1)

Se o EDIFACT saiu com só 1 NAD ou sem alguns parceiros, quase sempre é porque os parceiros não vieram do SAP — a query não expandiu o to_Partner.

O que fazer: rode o Teste de conexão da integração. Ele puxa o documento com todas as navegações expandidas ($expand=to_Partner), e a próxima mensagem traz os parceiros. Vale pra OData V2 e V4. Depois, rode Sugerir IA de novo — os NAD+BY/IV/PE aparecem.

Se o to_Partner já está no payload mas os NADs não saem, é a regra que falta: o Sugerir IA as gera; mensagens fora do padrão SAP podem precisar de ajuste manual no código do parceiro.

Grupo meio ativo

As regras de uma instância (o mesmo grupo, por exemplo TAX+7 ou ALC+A) saem juntas. Se um elemento obrigatório do segmento está inativo — o qualificador TAX01, o ALC01 — o segmento não pode sair. A obrigatoriedade vem do catálogo do destino.

• Salvar rascunho: o Lefia avisa quais grupos estão meio ativos; nada muda.
• Ativar: é recusado com a lista. O botão Inativar esses grupos inativa as outras regras daqueles segmentos (com a nota do motivo em cada regra) e ativa; o aviso diz quais grupos foram inativados.

Vale para todas as empresas, inclusive as de demonstração: a isenção de demonstração cobre só mapeamento incompleto, não defeito de integridade.

Ao Sugerir IA de novo, uma regra só herda a inatividade da versão anterior se for a mesma instância (mesma transformação e configuração).

Lista na origem

Uma lista da origem (as condições de preço de cada item, por exemplo) não entra num elemento que aceita poucas ocorrências sem uma agregação ou um filtro que escolha um elemento: a regra nasce inativa, com a nota. O Lefia decide o que é lista nesta ordem: o catálogo; onde o catálogo não diz nada, a base de conhecimento (conceitos que só existem dentro de listas, como a identidade da linha e a classe da condição de preço); e só então o exemplo da mensagem. Quando uma fonte discorda do catálogo, vale o catálogo e o Lefia avisa.

Ativado à força

Só um super admin pode ativar passando por cima desses portões. Fica registrado quem ativou e quais bloqueios foram pulados, e o mapeamento mostra o selo Ativado à força até a próxima ativação normal. O mesmo vale para restaurar uma versão, resolver um conflito ou importar do transporte: regra que não passa nos portões não fica ativa — é recusada ou entra como rascunho com o motivo.

Sugerir de novo

Ao pedir Sugerir IA num mapeamento que já existe:

• Uma instância que estava inteira inativa (todas as regras do grupo, por exemplo ALC+A ou o TAX+7 do cabeçalho) continua inativa, inclusive as regras novas que a sugestão trouxe para ela. O Lefia mostra quais foram mantidas e oferece Reativar; nada volta a ficar ativo sem alguém pedir.
• Uma instância ativa segue o que a sugestão decidiu agora.
• Uma regra da IA cuja origem a sugestão não gera mais sai do mapeamento, e o Lefia lista quais saíram. Regras feitas à mão ficam.
• O mesmo campo com e sem [*] é a mesma regra: fica uma só, com o caminho atual.
• Ao salvar, o que é lista vem do catálogo da mensagem: o endereço de um parceiro (um objeto só por parceiro) não vira lista, e o nome e a cidade do NAD saem dele. O código da função do parceiro é lido na língua do SAP de quem envia (SH/SP em inglês são o WE/AG internos), pela base de conhecimento.

O parceiro de cada linha (_Item._ItemPartner) vai para o NAD dentro da linha (LIN … NAD), com o qualificador pela função do parceiro. O NAD do cabeçalho vem dos parceiros do documento.

Id do parceiro

Num array de parceiros (_Partner, _Item._ItemPartner), o número da parte que vai para o NAD é o campo da lista aprovado como identificação do parceiro (party.identifier) na base de conhecimento. Um só por lista. Se nenhum estiver aprovado, ou mais de um, o Lefia não gera os segmentos de parceiro daquela lista e diz o motivo na sugestão.

Id do parceiro por função

Numa lista de parceiros do SAP, o número do parceiro fica num campo diferente conforme o tipo: cliente no campo de cliente, fornecedor no de fornecedor. O transportador da remessa (função SP) é um fornecedor. A base de conhecimento guarda o campo do id da lista e, quando uma função usa outro campo, essa exceção com a fonte. Assim o transportador sai no DESADV (NAD+CA) com o número dele, e os demais parceiros seguem com o id de sempre. O mesmo vale para o fornecedor (função LF, no campo de fornecedor) e para o vendedor e o funcionário responsável (VE/ZM, no campo de pessoal), e nos dois sentidos: na entrada, o fornecedor recebido no NAD+SU vai só para o campo de fornecedor do parceiro LF no SAP.