Entregue ao destino: o que o parceiro recebeu

Histórico de versões

• v1.27.0

  Correção no envio em lote. Quando o destino aceitava o lote e o banco estava sobrecarregado, a mensagem podia ficar como enviada e confirmada sem o registro da entrega, e a conferência não conseguia provar que os documentos chegaram. Agora o registro da entrega é gravado junto com a mudança para enviada: ou os dois ficam gravados, ou nenhum, e a nova tentativa grava os dois. A mesma tentativa repetida não cria registro em dobro.

  09/11/2026 · updated

• v1.26.0

  Destino em formato XML DECLARADO — cXML, XML genérico, mensagem XSD própria da empresa (pelo padrão declarado no catálogo, com qualquer código) e corpo dentro do envelope SOAP — passa a receber XML de verdade, com Content-Type application/xml; antes recebia o mapeado em JSON, na pré-visualização e no envio. Só o que está declarado decide o XML: o código ou um apelido IGUAIS aos de uma mensagem do catálogo (NFe, NFCe, NFe 4.00, cXML-PO), ou o padrão XML declarado na linha do catálogo da mensagem (só aí vale a versão abreviada, como NFE_V400 declarado nfe). Padrão declarado JSON, OData, EDIFACT ou FHIR nunca vira XML, e nome que só lembra um formato (NfeJson, Invoice, ORDER, NOTA, NFE_V400 sem declaração) continua como antes. Campos com @ viram atributos, listas repetem o elemento, caracteres especiais saem escapados, números saem na forma mais curta sem notação científica e, quando o catálogo declara casas decimais, com elas: casas a menos completam com zeros e casas a mais arredondam meio para cima (a mesma regra do X12, que agora também avisa), com aviso na validação da entrega; texto com vírgula decimal, separador de milhar ou notação científica em campo com casas é recusado com o motivo; .5, 5., +2 e espaços nas pontas são lidos como no X12. NF-e e NFC-e saem na raiz NFe com o namespace da SEFAZ, mas ficam TRAVADAS como destino até o Lefia escrever na ordem do XSD e assinar (XMLDSig): o seletor de formato avisa, o Quality Gate reprova o mapeamento e a entrega reprova com o motivo, sem enviar. Só no corpo XML, no REST e no webhook, o Content-Type declarado nos cabeçalhos da conexão vale quando é XML também (text/xml, por exemplo), sempre com charset UTF-8; incompatível, sai o do corpo, com aviso. Destinos JSON e EDI continuam com o mesmo cabeçalho de antes, byte a byte. O motivo da trava da NF-e ensina a liberar um destino que não é NF-e (por exemplo, uma API JSON chamada NotaFiscal): declarar o padrão json para a mensagem no catálogo. Sem raiz definida, com nome inválido, caractere que o XML não aceita ou corpo em lista (modo pacote), o envio para com o motivo — erro definitivo de mapeamento, sem novas tentativas automáticas; falha interna do Lefia continua como erro de sistema.

  29/10/2026 · updated

• v1.25.0

  Ao salvar um mapeamento depois do Sugerir, o nome e a cidade de cada parceiro (NAD) voltam a sair no aviso de despacho: o Lefia tratava o endereço do parceiro como uma lista e não o achava. Agora o catálogo da mensagem decide o que é lista. O código da função do parceiro já era lido na língua do SAP de quem envia. Mapeamentos publicados continuam iguais até serem sugeridos e publicados de novo.

  05/10/2026 · updated

• v1.24.0

  A entrega para um destino SAP por OData passa a criar o documento de verdade: o Lefia lê o $metadata do serviço, cria o documento na entidade certa (não mais no endereço do serviço), com o token de segurança (CSRF) e a sessão que o SAP exige, e guarda o número do documento criado — ele aparece no detalhe da mensagem. Antes, todo envio a um destino OData era recusado pelo SAP. Se o SAP recusar, o motivo dele (com os detalhes) aparece na mensagem e reprocessar envia de novo; se o envio ficar sem resposta, a mensagem para e pede para conferir no SAP, para não criar o documento duas vezes. Reprocessar uma mensagem já entregue não cria o documento de novo. Destinos de outros tipos, OData com atualização por chave e integrações em modo observação não mudam.

  05/10/2026 · updated

• v1.23.0

  Aviso de remessa (DESADV) com embalagens identificadas pelo SSCC: o mapeamento para a entrega de entrada do SAP passa a levar as unidades de manuseio, com o peso, o volume, as dimensões e a unidade de cada medida (tirada da mesma medida no arquivo). Como o SAP não aceita a unidade de manuseio junto com a entrega, o Lefia cria a entrega e, logo depois, cada unidade de manuseio ligada a ela. Se o SAP recusar uma unidade, a mensagem fica em erro com o número da entrega e o motivo; reprocessar cria só o que falta, sem criar a entrega de novo. Se o envio cair depois de a entrega sair e antes de o Lefia gravar a resposta do SAP, a mensagem para e pede para conferir no SAP antes de reprocessar.

  04/10/2026 · updated

• v1.22.0

  Integrações de entrada (EDI do parceiro → SAP): o parceiro de uma LINHA do pedido (entrega por linha, quando uma linha vai para outro recebedor) chega ao SAP como parceiro do item, com a função certa (o recebedor da mercadoria, WE), tanto no EDIFACT (NAD da linha) quanto no X12 (N1 da linha); a linha que repete o parceiro do cabeçalho não ganha parceiro próprio. No aviso de remessa (DESADV), o Lefia passa a reconhecer a embalagem: cada palete ou caixa identificada pelo SSCC, com peso, volume e dimensões. Como a criação da entrega de entrada do SAP não recebe as unidades de manuseio junto, elas ficam fora do documento enviado e o Sugerir avisa — o SAP não recebe nada que recusaria.

  04/10/2026 · updated

• v1.21.0

  Ao escolher o destino de uma integração, o Lefia não oferece mais o objeto do SAP que o próprio serviço declara que não aceita criar (como o Billing Document, que só lê faturas): o documento recebido sairia sem ser criado. Com a origem escolhida, a base de conhecimento sugere o destino que cria o documento (uma fatura recebida → Supplier Invoice), com o botão "Usar …". Integrações que já existem com um destino assim continuam como estão e mostram um aviso na tela da integração.

  04/10/2026 · updated

• v1.20.0

  Saída EDIFACT mais limpa e com o código do fornecedor. O NAD da linha só sai quando a parte da linha é diferente da do cabeçalho na mesma função (pedidos e faturas deixam de repetir comprador, entrega e faturado em cada item). No aviso de remessa (DESADV) e na fatura (INVOIC), quando o LIN leva o GTIN, o material do fornecedor sai também no PIA+5 com o tipo SA; sem GTIN, o LIN já leva o material e o PIA não o repete. Vale para mapeamentos novos ou gerados de novo pelo Sugerir; os publicados continuam enviando o mesmo arquivo.

  04/10/2026 · updated

• v1.19.0

  DESADV da remessa SAP (API_OUTBOUND_DELIVERY_SRV v0002): o GTIN do item (InternationalArticleNumber) entrou na base de conhecimento. Mapping novo gerado pelo Sugerir põe o GTIN no LIN com o tipo SRV; item sem GTIN segue com o material, sem SRV. Mappings publicados não mudam.

  28/09/2026 · updated

• v1.18.0

  Integração de entrada (EDI do parceiro → SAP): a empresa declara pela tela Padrões e conversões o que o SAP exige e a mensagem não traz — a empresa que lança (valor fixo), a data de lançamento pela data em que a mensagem chegou ou pela data do documento — e as conversões de código (tipo de documento, código de imposto, unidade). O Sugerir mostra o padrão e a prévia o preenche; com a conversão cadastrada, o código sai convertido; sem ela, o aviso continua. Quem não cadastra nada vê a mesma saída de antes.

  27/09/2026 · updated

• v1.17.0

  Integração de entrada (EDI do parceiro → SAP): a fatura do fornecedor (INVOIC) chega ao SAP com o fornecedor, o número dele, datas, moeda, valor bruto, imposto e os itens com o pedido de compra e o item do pedido; o aviso de despacho (DESADV) cria a entrega de entrada com o número do aviso, o fornecedor, a data prevista e os itens (material, quantidade, unidade e pedido), mesmo quando as linhas vêm dentro de embalagens. O pedido informado na linha vale para a linha; o do cabeçalho completa as que não trazem.

  27/09/2026 · updated

• v1.16.0

  Integração de entrada (EDI do parceiro → SAP): o texto da linha do pedido (a descrição do item) chega ao SAP; a unidade vem no campo do código ISO, que o SAP converte para a sua unidade; e o documento de criação não manda mais campos vazios como "null" — o que o parceiro não informou fica de fora.

  27/09/2026 · updated

• v1.15.0

  Integração de entrada (EDI do parceiro → SAP): o "Criar com Mapeamento IA" e o Sugerir montam o documento que o SAP aceita criar. Os parceiros saem com a função (AG, WE, RE…) pelo qualificador do NAD; o comprador, o contrato e as datas são lidos pelo qualificador certo e o salvar no editor não troca mais essa leitura pelo "primeiro"; campos que o SAP calcula (totais, valor e imposto da linha, status) e a chave do documento não recebem valor; um código da lista da origem (tipo de documento 220) só vai com a conversão cadastrada. O catálogo passa a saber, pelo $metadata, quais campos o servidor preenche.

  26/09/2026 · updated

• v1.14.0

  Todo elemento composto do EDIFACT sai na posição que a spec da mensagem define, com os elementos vazios antes dele — não só os mais usados. Um pacote (PAC) só com o tipo de embalagem, um local (LOC) com a relação ou uma medida (MEA) com o valor agora saem no lugar certo, e o arquivo gerado é lido de volta igual pelo próprio Lefia.

  26/09/2026 · updated

• v1.13.0

  O Lefia lê o arquivo EDI que o parceiro manda (EDIFACT, X12, IDoc em XML ou em arquivo plano) na estrutura da mensagem antes do mapeamento — as regras de entrada acham cada valor pelo seu segmento, grupo e posição, como na saída. Um arquivo com várias mensagens vira uma mensagem por documento, cada uma com o trecho exato do arquivo; arquivo fora da forma da spec fica em erro dizendo a linha e o segmento.

  26/09/2026 · updated

• v1.12.0

  O "Sugerir" monta integrações de entrada: o pedido ou a fatura que o parceiro manda em EDIFACT, X12 ou IDoc vira pedido ou fatura no SAP. Cada valor é lido pelo código que diz o que ele é: a data do pedido no DTM+137, a quantidade pedida no QTY+21, o comprador no NAD+BY (ou N1*BY, ou parceiro AG no IDoc), os totais pelo tipo de valor. Antes esses campos ficavam sem destino ou pegavam o valor errado da lista.

  26/09/2026 · updated

• v1.11.0

  A validação contra a spec avisa quando um campo de código sai com um código do próprio emissor, fora da lista oficial: pela spec está certo, mas muitos parceiros reprovam. É um aviso, não um erro, e só aparece quando o formato pede. A tela da validação (Ver saída e o envio no monitor) agora lista os avisos com o mesmo endereço dos erros — segmento, elemento, linha e valor.

  26/09/2026 · updated

• v1.10.0

  O aviso de remessa gerado da remessa do SAP sai com o nome do documento (aviso de despacho), a unidade em cada quantidade e, antes da saída de mercadoria, a data de despacho planejada. O aviso em IDoc (DESADV01) passa a sair com uma linha por item da remessa, com quantidade, unidade, número do item e material.

  26/09/2026 · updated

• v1.9.0

  Quando o destino recusa por excesso de requisições (HTTP 429), a mensagem aparece como "Limite de taxa do destino", com a ação recomendada, e a nova tentativa automática espera o tempo que o destino pediu, até o intervalo máximo de retry da integração (se o destino pedir mais, a linha do tempo da mensagem avisa). O motivo mostrado na mensagem passa a ser o da última tentativa.

  26/09/2026 · updated

• v1.8.0

  Quando a integração tem mais de um tipo de mensagem ativo, o Lefia reconhece o tipo pelo próprio conteúdo em todos os formatos — EDIFACT, X12, IDoc, NF-e, FHIR, OData V2 e V4 e JSON (neste, quando você declara o campo que identifica) — comparando com o catálogo, e não mais só pelo cabeçalho do EDI. Se mesmo assim não der para saber qual é, a chegada é recusada e você recebe um aviso com o link da integração, uma vez por configuração; o arquivo recusado fica na origem e não é baixado de novo até você ajustar os tipos.

  26/09/2026 · updated

• v1.7.0

  A validação contra a spec entende códigos de outra lista: quando o próprio segmento diz que o código é do vendedor ou do comprador (agência 91 ou 92), o Lefia não exige mais a lista da ONU para ele; com a agência da ONU ou sem agência, a lista continua valendo. E a checagem do "Sugerir" passa a montar o arquivo de teste na mesma ordem do arquivo real, então deixa de apontar erro de repetição em arquivo válido.

  26/09/2026 · updated

• v1.6.1

  Mensagem recebida (webhook, evento, API, arquivo, REST e Oracle) usa sempre o tipo de mensagem ATIVO da integração no ambiente dela — antes podia pegar um tipo desativado depois de uma troca de formato e sair sem o mapeamento novo. Se a integração tiver mais de um tipo ativo, vale o que a própria mensagem identifica (o tipo informado ou o cabeçalho do EDI); se nada identificar, a mensagem é recusada com erro claro em vez de seguir com um palpite. Ao criar um tipo de mensagem, o aviso de duplicado mostra o mapeamento em uso mesmo em integração clonada.

  26/09/2026 · updated

• v1.6.0

  O "Sugerir" decide sozinho quantas vezes cada segmento sai. Quando a origem tem um valor só e o destino tem um segmento que se repete (ou o contrário), o Lefia usa a base de conhecimento — se o dado é do documento, da parte ou da linha, e onde ele está na origem e no destino — para gerar a regra já decidida: uma ocorrência no cabeçalho, o mesmo valor em cada linha, soma da coleção ou a parte pelo papel. O que a base não permite decidir não vira regra ambígua: o campo fica sem destino e o aviso diz por quê. O aviso de remessa (DESADV) sai com um nível de embalagem e as linhas dentro dele. Também corrigido: a remessa de saída (API v0002) não usava as anotações da base e caía na sugestão antiga, com centenas de regras bloqueadas.

  26/09/2026 · updated

• v1.5.1

  Trocar o formato de uma integração (por exemplo, de pedido para fatura) agora vale por inteiro: o arquivo sai no formato do mapeamento em uso na mensagem e é validado contra essa mesma spec. Antes, depois da troca, o arquivo podia sair no formato antigo e ser reprovado na spec antiga. Na edição da integração, o tipo de mensagem novo fica no ambiente da integração com a mesma direção do anterior, e o anterior é desativado (o mapeamento dele fica guardado); o formulário reabre com o tipo em uso.

  26/09/2026 · updated

• v1.5.0

  Texto maior que o tamanho do elemento na spec não trava mais a entrega EDIFACT e X12. Quando o elemento tem linhas de continuação (o nome do parceiro no NAD tem 5 linhas de 35, a rua 4, o texto livre do FTX 5; no X12, o N2 tem 2), o que passa do limite desce para a linha seguinte, quebrando no espaço e mantendo a ordem — o nome de 40 caracteres do SAP sai em duas linhas, sem perder nada. Se não houver linha livre, cada linha é cortada no limite e a entrega mostra o aviso com o tamanho original. Identificador, código e cidade nunca são cortados: acima do limite, o arquivo continua reprovado na spec e não sai. Vale também para as telas que mostram a saída.

  26/09/2026 · updated

• v1.4.0

  O arquivo EDIFACT entregue só declara a agência GS1 (NAD com 9) e o tipo GTIN (LIN com SRV) quando o identificador é mesmo um GLN/GTIN — tamanho certo e dígito verificador. Número interno do SAP (cliente, material) sai sem agência, em vez de ser anunciado como GLN/GTIN que não existe. A regra é a mesma que a conciliação da entrega confere, então o pedido que antes aparecia com divergência de identificador sai limpo, e em modo bloqueio volta a ser enviado. Vale para os mapeamentos já salvos, sem recompilar.

  25/09/2026 · updated

• v1.3.0

  Obrigatório do destino sem origem sai pelo valor padrão declarado. Alguns elementos obrigatórios não existem em nenhum sistema de origem — o propósito do pedido X12 850 (BEG01, "00" = original) é o caso. Antes o mapeamento gerado não o trazia e todo 850 novo era reprovado na validação até alguém preencher à mão. Agora o valor vem da base de conhecimento, com a fonte (a spec), e só entra onde nada da origem nem do operador escreve; a regra aparece no editor para revisão.

  25/09/2026 · updated

• v1.2.0

  X12: elementos vazios no fim do segmento não saem mais com o separador (ex.: BEG*00*SA*6**20160906 em vez de …20160906*), e elementos numéricos com casas implícitas (N2) são escalados pelo catálogo na escrita do arquivo.

  25/09/2026 · updated

• v1.1.0

  Serializador EDI pela sintaxe declarada: (1) separadores e caracteres de serviço padrão vêm do SERVICE_SYNTAX, sem cópia — no X12 o ISA16 passa a ser ">" (o que o catálogo e o tokenizador já declaravam; nenhuma integração X12 em produção); (2) ISO 9735: o separador de componente num DADO sai escapado com o release (ex.: "ACME?: Filial"); composto chega por componentes — objeto do engine, lista explícita na linha plana ou S009 do UNH — e texto é sempre dado; (3) identificador da mensagem (UNH S009) estruturado nas opções (tipo, versão, release, agência), com um parser único para a forma canônica "ORDERS:D:01B:UN" (UNH02, UNH2 ou S009 legados em texto passam por ele). Com separadores próprios do parceiro, o composto sai com o separador dele; (4) os acks CONTRL e 997 respondem com os caracteres de serviço do intercâmbio recebido (UNA / ISA, inclusive o ISA16), e com os padrão da sintaxe na falta deles; (5) ao salvar ou publicar, aviso quando uma regra grava texto com o separador de componente num elemento composto (constante, separador do concatenate, de-para, pad): o valor sai escapado, use componentes. Composto vem do catálogo do destino.

  25/09/2026 · updated

• v1.0.0

  O monitor mostra exatamente o artefato entregue ao destino: compileWireArtifact serializa uma vez com o envelope da família (EDIFACT/X12/IDoc/JSON), sem pretty-print no fio; message_deliveries grava corpo exato, sha256, content-type, headers mascarados, envelope e resposta do destino por tentativa; monitor, painel lateral e Comparar leem o registro em vez de re-serializar mapped_data.

  24/09/2026 · new