Central de AjudaVoltar ao app
Voltar para Central de ajuda
FT-EDI-INTERCHANGE-PROFILE· v1.9.1Integrações

Perfil de intercâmbio: quem envia e quem recebe no arquivo EDI

Todo arquivo EDIFACT, X12 ou IDoc leva no envelope a identificação do remetente e do destinatário e se é teste ou produção. Isso se cadastra na conexão de destino; sem o perfil, o Lefia não envia.

Atualizado em 05/10/2026

O que é



O envelope de um arquivo EDI diz ao parceiro quem enviou, para quem é e se o intercâmbio é de teste ou de produção. É por ele que o parceiro reconhece o arquivo — antes mesmo de ler o pedido ou a nota.

FormatoOnde entra no envelope
EDIFACTUNB: remetente (S002), destinatário (S003) e indicador de teste (0035 = 1)
X12ISA05–ISA08 e GS02/GS03; ISA15 = T (teste) ou P (produção)
IDocEDI_DC40: SNDPRT/SNDPRN, RCVPRT/RCVPRN e TEST = X em teste


Onde cadastrar



Na integração, no bloco Destino, logo abaixo do formato de destino — no assistente de nova integração, na criação manual e na edição. O bloco só aparece quando o formato de destino é EDIFACT, X12 ou IDoc.

  • Remetente e destinatário: o identificador (ex.: o GLN, o DUNS ou o código combinado com o parceiro) e o qualificador.
  • Uso: Teste ou Produção.


Qualificador: depende do formato



A lista de qualificadores é a da spec de cada formato:

  • EDIFACT (0007): opcional. 14 = GS1/EAN, ZZZ = combinado entre as partes, entre outros. Identificador até 35 caracteres.
  • X12 (ISA05/ISA07): obrigatório. 01 = DUNS, 08 = UCC EDI, 12 = telefone, ZZ = combinado entre as partes, entre outros. Identificador até 15 caracteres.
  • IDoc (SNDPRT/RCVPRT): obrigatório — o tipo de parceiro do SAP: LS (sistema lógico), KU (cliente), LI (fornecedor), B (banco), US (usuário). Identificador até 10 caracteres. Tem de casar com o perfil de parceiro (WE20) do lado SAP.


Sem perfil, não sai



Se a conexão de destino não tem perfil — ou ele está incompleto ou fora da lista do formato — a mensagem não é enviada: fica em erro Reprovado na spec e, em Entregue ao destino, o bloco Perfil de intercâmbio diz o que falta. Não existe valor padrão: o Lefia nunca inventa a identificação do parceiro.

Para liberar: cadastre o perfil na integração e reprocesse a mensagem.

Obrigatório para enviar. Com formato de destino EDI, a integração não é ativada sem remetente, destinatário e uso: o Concluir do assistente, a criação manual e a edição que mexe no destino pedem o perfil. Só o modo observabilidade, que não envia, dispensa. Uma integração que já existe e é salva sem mexer no destino continua como está.

Destinos JSON/REST não usam perfil.

No monitor



A lista de mensagens (e o detalhe, a busca, os filtros, os relatórios, o assistente e o MCP) mostra duas coisas separadas:

  • Sistema: a conexão de origem → a conexão de destino da integração (por exemplo, SAP S/4HANA Cloud → Webhook). Quando a plataforma cadastrada é "Outro", aparece o protocolo.
  • Parceiro: o remetente → o destinatário do documento. Passe o mouse em cada um para ver de onde veio: declarado na própria mensagem (por exemplo, o control record do IDoc ou o envelope do arquivo EDI); o que saiu no envelope da entrega (mensagens de saída); o perfil de intercâmbio da conexão de destino; ou o parceiro cadastrado na integração, do lado do parceiro (remetente nas integrações de entrada, destinatário nas de saída). Renomear o parceiro na integração muda a tela na hora. Sem nada disso, aparece sem perfil.


Se a integração tiver mais de uma conexão ativa do mesmo papel, o Lefia não escolhe uma: o sistema ou o parceiro aparece com um aviso ao lado. A direção é a da integração; em integração bidirecional a mensagem aparece com direção não definida.

Perfil trazido de outro ambiente



Quando o import ou o transporte aprovado cria a conexão de destino em outro ambiente, o perfil vem com o remetente e o destinatário da origem e com o uso do ambiente de destino (PRD = produção; DEV e QAS = teste), marcado a revisar. Enquanto estiver assim, o envio EDI fica bloqueado ("perfil trazido de … e ainda não confirmado"). Abra Editar na integração, confira o perfil e clique em Confirmar perfil (ou corrija os campos) e salve: o perfil é gravado sem a marca e o envio é liberado. Se a conexão já existia no destino, o transporte não mexe no perfil dela.

Imposto no documento: por linha ou no cabeçalho



Quando a mensagem de destino aceita o imposto nos dois lugares (no EDIFACT ORDERS, o TAX/MOA de cada linha e o TAX/MOA do documento), o perfil mostra o campo Imposto no documento:

  • Padrão da mensagem (em branco): vale o que a mensagem declara. No pedido (ORDERS), o imposto sai por linha, porque a origem o declara por item.
  • Por linha: cada linha leva o imposto que a origem declara para o item.
  • No cabeçalho: sai um imposto só, no documento, com a soma do que a origem declara nos itens.


Nunca saem os dois. O valor é sempre o que a origem declara; as condições de preço (pricing) só conferem — se a soma delas for diferente, o log da mensagem traz um aviso.

O campo só aparece quando a mensagem de destino declara a escolha.

No IDoc (ORDERS05) a escolha vale do mesmo jeito: por padrão o imposto sai em cada linha (E1EDP04 dentro do E1EDP01); pedindo o cabeçalho, sai um E1EDK04 com a soma dos itens e nenhum E1EDP04. O código de imposto acompanha o nível escolhido.

Caracteres de serviço (UNA)



No EDIFACT, o arquivo usa por padrão os caracteres de serviço da sintaxe: : entre componentes, + entre elementos, ? para liberar e ' no fim do segmento (UNA :+.? '). Se o parceiro exigir outros, informe no campo Caracteres de serviço (UNA) da conexão de destino os 6 caracteres na ordem do UNA — componente, elemento, decimal, liberação, reservado, terminador (ex.: !*.? ~). O decimal fica . e o reservado fica espaço; os separadores precisam ser diferentes entre si e não podem ser letra, dígito ou espaço. Campo vazio = padrão da sintaxe.

Com o acordo gravado, o arquivo sai com esses caracteres no UNA, no UNB e em todos os segmentos; um dado que contém um separador sai precedido do caractere de liberação. Ao salvar um mapping, o aviso de texto em elemento composto olha o separador de cada conexão de destino ativa que usa o mapping naquele ambiente.

Conferido no próprio arquivo



Além do cadastro, o Lefia lê o envelope do arquivo gerado: se o remetente ou o destinatário não estiverem nele (UNB S002/S003 no EDIFACT, ISA05–ISA08 e GS02/GS03 no X12, SNDPRT/SNDPRN/RCVPRT/RCVPRN no IDoc), o arquivo não é enviado e o bloco Perfil de intercâmbio diz qual dado faltou no envelope. A validação contra a spec também cobra todo elemento obrigatório do envelope.

Na "Ver saída" do mapeamento



O Ver saída do editor monta o arquivo com o perfil da conexão de destino da integração e mostra os mesmos controles do envio. Se o mapeamento não tiver integração com conexão de destino ativa no ambiente, ele avisa: o envelope sai sem remetente e destinatário.

Dados para o destinatário lançar o documento



Quando o parceiro lança o documento no sistema dele — por exemplo, a sua fatura entra no SAP do cliente como fatura de fornecedor —, ele precisa de partes e referências que o arquivo nem sempre leva: no INVOIC, o fornecedor (NAD+SU) e o número do pedido do comprador (RFF+ON). Marque Dados para o destinatário lançar o documento no perfil de intercâmbio do destino. A opção só aparece quando a mensagem declara o que o lançamento pede, e a dica mostra quais segmentos são.

  • O fornecedor sai com o ID do remetente deste perfil quando a origem não traz o fornecedor. Se a origem trouxer, vale o da origem.
  • As referências vêm da origem (no SAP, o pedido do cliente da fatura). Se a origem vier sem o valor, o segmento não sai e a mensagem registra um aviso dizendo qual campo veio vazio.
  • Não é preciso gerar o mapeamento de novo: a opção vale no próximo envio.


Desligada (o padrão), o arquivo sai exatamente como antes.

Reaproveitar um perfil da empresa (27/09/2026)



No destino EDI, a tela oferece os perfis que a empresa já usa em outros destinos deste ambiente (o uso teste/produção já é o do ambiente). Numa integração nova, o perfil do mesmo parceiro entra sozinho no campo vazio; os campos continuam editáveis. Na edição nada entra sozinho — você escolhe.

Documento alterado sai como substituição (04/10/2026)



Documento alterado sai como substituição. Quando um documento que o Lefia já entregou a este parceiro muda na origem e é enviado de novo, ele sai marcado como substituição (no EDIFACT, BGM 1225 = 5; no X12, o elemento de finalidade do documento, como o BEG01 do 850, = 05), não como um novo original — o parceiro atualiza em vez de criar outro. O primeiro envio não muda. O elemento e o código vêm da base de conhecimento da mensagem de destino; mensagem sem esse elemento sai como sempre e o monitor avisa. Se o primeiro envio falhou ou foi recusado pelo parceiro, o reenvio sai como original.

  • A opção fica no perfil de intercâmbio da conexão de destino. Numa conexão nova ela já vem ligada quando a mensagem de destino declara o elemento; numa conexão que já existe, nada muda até você ligar.
  • O mesmo documento é reconhecido pela chave de duplicata configurada, pelo número do documento que a base de conhecimento lê na origem ou pelo número da mensagem. No OData, a releitura do documento alterado é comparada pelo conteúdo.
  • Reprocessar o mesmo conteúdo repete o que saiu da primeira vez.
  • Em IDoc e arquivo, documentos entregues antes de ligar a opção não são reconhecidos como o mesmo documento: a primeira alteração deles sai como original.
  • Vale para o mapeamento gerado com a base de conhecimento atual: se o publicado é anterior, gere de novo e publique.
  • A fatura fica de fora: substituir uma fatura tem implicação fiscal (nota de crédito e fatura nova).
  • No monitor, a entrega mostra o selo Substituição com a data e a mensagem da entrega anterior.


Alteração como mensagem própria (05/10/2026)



Alteração como mensagem própria. Alguns parceiros pedem que a alteração de um pedido chegue numa mensagem separada — no EDIFACT, o ORDCHG em vez do ORDERS; no X12, o 860 em vez do 850 — e não como substituição dentro da mesma mensagem. Para eles, o perfil de intercâmbio da conexão de destino tem a opção Enviar a alteração como mensagem própria, logo abaixo de "Documento alterado sai como substituição".

  • A opção aparece quando a integração tem a mensagem de alteração com o mapeamento publicado: crie a mensagem (Nova Mensagem, com a mesma origem e o ORDCHG ou o 860 como destino), gere e publique o mapeamento dela.
  • Ligada, o reenvio de um documento já entregue e alterado na origem sai pela mensagem de alteração. O primeiro envio não muda.
  • Se o mapeamento da mensagem de alteração deixar de estar publicado, o reenvio volta a sair como substituição (ou como original, se a mensagem não tiver o elemento) e o log da mensagem diz por quê.
  • A mensagem de alteração não recebe documentos da origem: ela só é usada para os reenvios.
  • No monitor, a entrega mostra o selo Alteração com o formato e a entrega anterior.
  • O ORDCHG (EDIFACT D.01B) e o 860 (X12 005010) estão no catálogo, gerados da fonte oficial. O Sugerir do mapeamento da mensagem de alteração usa o que a base de conhecimento já sabe do pedido original: no ORDCHG o documento sai como pedido de alteração (BGM 230, função 4) e cada linha como alterada (LIN 3); no 860, com o código 04 no BCH e cada linha (POC) com RZ (substitui todos os valores).
  • O reenvio traz o documento inteiro: uma linha apagada na origem não sai como exclusão — o parceiro recebe as linhas que existem agora.

Histórico de versões

  • v1.9.1

    Correção no pedido X12 (850 e 860) gerado pelo Sugerir: o código do parceiro no N1 sai com o qualificador de quem o atribuiu (N103 = 91 vendedor, 92 comprador, pela origem declarada na base de conhecimento; sem origem declarada não sai e a entrega fica retida), o qualificador do produto idem (VP × IN), o tipo do pedido padrão do SAP (OR, TA) sai como pedido avulso (BEG02/BCH02 = SA) e o validador estrito passou a saber conferir as condições relacionais do X12 (P, R, E, C, L) em cada segmento, como o Stedi: um N104 sem o N103 reprova antes do envio (no 850 em produção, depois do sync do catálogo do release). Conferido no Stedi EDI Inspector: 850 e 860 do pedido de teste sem erro.

    05/10/2026 · updated

  • v1.10.0

    Enviar documento de teste pela tela da integração: cole ou edite o documento de origem (vem preenchido com o da última mensagem real) e envie pelo mesmo recebimento, no ambiente da integração. O número vem do documento: o mesmo número com conteúdo novo entra como nova revisão (e sai como alteração ou substituição, se o acordo do parceiro estiver ligado) e o conteúdo idêntico é reentrega exata. A tela mostra a mensagem, a entrega e o arquivo gerado; a mensagem fica marcada como teste e o envio vai para a trilha de auditoria. Destino de parceiro de verdade pede confirmação antes.

    05/10/2026 · updated

  • v1.9.0

    Documento alterado sai como mensagem de alteração própria: com "Enviar a alteração como mensagem própria" ligado no acordo do parceiro, um pedido que o Lefia já entregou e mudou na origem sai como EDIFACT ORDCHG (X12 860), e o primeiro envio continua ORDERS (850). A tela da integração abre sempre pelo tipo do documento, mesmo com a mensagem de alteração cadastrada, e Salvar nunca troca o tipo principal pela mensagem de alteração.

    05/10/2026 · updated

  • v1.8.0

    O catálogo passa a ter as mensagens de alteração de pedido: o ORDCHG (EDIFACT D.01B) e o 860 (X12 005010), gerados da fonte oficial. Com elas, a opção "Enviar a alteração como mensagem própria" do perfil de intercâmbio pode ser usada: crie na integração a mensagem com a mesma origem e o ORDCHG ou o 860 como destino, gere e publique o mapeamento. O "Sugerir" desse mapeamento usa o que a base de conhecimento já sabe do pedido original (ORDERS ou 850); no ORDCHG o documento sai como pedido de alteração (230, função 4) e cada linha como alterada (3); no 860, com o código de alteração 04 e cada linha com RZ (substitui todos os valores). Nada muda nas mensagens que já saem.

    05/10/2026 · updated

  • v1.7.0

    Preparação para o documento alterado sair como mensagem de alteração própria (no EDIFACT, o ORDCHG em vez do ORDERS; no X12, o 860 em vez do 850), para o parceiro que pede a alteração de um pedido numa mensagem separada. A base de conhecimento já associa o ORDCHG ao ORDERS e o 860 ao 850. A opção "Enviar a alteração como mensagem própria" fica disponível quando a mensagem de alteração estiver no catálogo; até lá nada muda: o documento alterado continua saindo como substituição, conforme o acordo do perfil de intercâmbio.

    05/10/2026 · updated

  • v1.6.0

    Documento alterado sai como substituição: quando um pedido, confirmação ou aviso de remessa que o Lefia já entregou a um parceiro muda na origem e é enviado de novo, o arquivo sai marcado como substituição (no EDIFACT, BGM 1225 = 5; no X12 850, BEG01 = 05) em vez de um novo original — o parceiro atualiza em vez de criar outro. O primeiro envio não muda. É um acordo no perfil de intercâmbio da conexão de destino: conexão nova nasce ligada quando a mensagem de destino declara o elemento na base de conhecimento; conexão existente continua como está até alguém ligar. Se o envio anterior falhou ou foi recusado pelo parceiro, o reenvio sai como original. A fatura fica de fora (substituir fatura tem implicação fiscal). O monitor mostra o selo "Substituição" com a data e a mensagem da entrega anterior.

    04/10/2026 · updated

  • v1.5.1

    "Ver saída" do editor de mapeamento passa a aplicar o mapeamento pela mesma função do envio real (com a conexão de destino resolvida): os acordos do perfil de intercâmbio da conexão — escolha de nível do imposto e "Dados para o destinatário lançar o documento" — agora aparecem na prévia. Nada muda no envio.

    27/09/2026 · updated

  • v1.5.0

    Nova opção no perfil de intercâmbio do destino: "Dados para o destinatário lançar o documento". Ligada, o arquivo leva o que a mensagem pede para o parceiro lançar o documento no sistema dele — no INVOIC, o fornecedor (NAD+SU) com o ID do remetente do perfil quando a origem não traz o fornecedor, e o número do pedido do comprador (RFF+ON) da origem. O que faltar na origem aparece como aviso na mensagem. Desligada (o padrão), o arquivo sai exatamente como antes.

    27/09/2026 · updated

  • v1.4.0

    O Lefia confere remetente e destinatário no próprio arquivo, não só no cadastro: um EDIFACT sem o remetente ou o destinatário no UNB, um X12 sem o ISA06/ISA08 ou um IDoc sem o parceiro no EDI_DC40 não é enviado, e a tela diz qual dado faltou no envelope. A validação contra a spec também passou a cobrar todo elemento obrigatório do envelope. E o "Ver saída" do editor de mapeamento mostra o arquivo como o envio o geraria — com o perfil de intercâmbio da conexão de destino e os mesmos controles — e avisa quando o mapeamento não tem conexão de destino.

    26/09/2026 · updated

  • v1.3.0

    Caracteres de serviço do EDIFACT no perfil de intercâmbio (#675): quando o parceiro exige separadores próprios, informe os 6 caracteres do UNA na conexão de destino. O arquivo sai com eles (UNA, UNB e todos os segmentos; dado que contém um separador sai com o caractere de liberação) e o aviso de texto em elemento composto, ao salvar o mapping, passa a olhar o separador de cada conexão de destino que usa o mapping. Sem acordo, os padrão da sintaxe — o arquivo de sempre.

    25/09/2026 · updated

  • v1.2.0

    Perfil trazido de outro ambiente pelo transporte: gravado com remetente/destinatário da origem, uso do ambiente de destino e a marca review (transported); checkInterchangeProfile acusa review_required e o validate-wire bloqueia até alguém confirmar na edição da integração ("Confirmar perfil"), que grava o perfil sem a marca.

    24/09/2026 · updated

  • v1.1.1

    Editar Integração abre o perfil de intercâmbio gravado; salvar sem mexer não o apaga; remoção explícita audita connection.interchange_profile_removed.

    24/09/2026 · updated

  • v1.1.0

    Parceiro e sistema da mensagem derivados numa regra só no banco (view mensagens_parceiros, 20260925_1320, junção de conjunto): remetente/destinatário = declarado pela mensagem → envelope que saiu na entrega → perfil da única conexão de destino ativa → partner_name da integração do lado do parceiro, com a fonte de cada lado; sistema = a conexão ativa de origem e a de destino. A escrita grava só o declarado. Monitor com as colunas Sistema e Parceiro (tooltip com a fonte, aviso de conexão ambígua), busca, filtros, relatórios (scorecard, visão geral, camada semântica), IA e MCP leem a view; catraca contra leitura de sndprn/rcvprn no TS, nos scripts e no SQL vigente. Cópias de parceiro em messages (NEXIO, SAP_<org>, EXTERNAL, SAP, partner_name e perfil copiados) zeradas pela assinatura de cada origem.

    24/09/2026 · updated

  • v1.0.0

    Perfil de intercâmbio na conexão, com direção e parceiros reais no monitor (EDI PR 3, PR #1066, release #1072).

    24/09/2026 · new