Acks funcionais (CONTRL / 997)
Confirme cada interchange EDI recebido com um CONTRL (EDIFACT) ou 997 (X12) e acompanhe os acks que o parceiro devolve pros seus envios.
O que são acks funcionais
No EDI B2B, o "200 OK" do transporte só diz que os bytes chegaram. O ack funcional (CONTRL no EDIFACT, 997 no X12) confirma que o interchange foi lido e aceito — é o que parceiros de verdade esperam.
Como ativar
Na edição da integração, seção Modo de operação, marque Acks funcionais (CONTRL / 997).
O que acontece com a flag ativada
Recebendo EDI (inbound):
- O Lefia valida o interchange contra a spec da mensagem (validador estrito, catálogo).
- Gera o CONTRL/997 referenciando o interchange (UNB/ISA) com o veredito:
- aceito com erros — violações de spec detectadas; o Lefia processa best-effort e o ack lista as mensagens com problema;
- rejeitado — interchange ilegível (também marca a mensagem em erro).
- O ack volta na própria resposta do webhook (campo
ack) e fica registrado na mensagem (card "Ack funcional" no monitor).
Enviando EDI (outbound):
- O envio registra as referências de envelope do documento (o que permite correlação).
- A mensagem fica "aguardando ack".
- Quando o parceiro devolve o CONTRL/997 (pelo mesmo webhook), o Lefia correlaciona automaticamente e atualiza o status do ack na mensagem enviada.
Onde ver
No Monitor, abra o detalhe da mensagem: o card "Ack funcional" mostra o status, a origem (gerado por nós / recebido do parceiro) e o documento do ack.
Quem assina o ack (25/09/2026)
O ack responde o intercâmbio recebido com as partes invertidas: nós somos o destinatário dele e o parceiro é o remetente, com os mesmos qualificadores. Se o recebido não traz UNB/ISA com remetente e destinatário — ou, no X12, sem o qualificador, que é obrigatório —, o ack não é gerado: o card do ack (no detalhe e no painel da mensagem) mostra bloqueado, o motivo e o que fazer: pedir ao parceiro que reenvie o intercâmbio com o envelope completo — o novo intercâmbio recebe a confirmação; reprocessar o mesmo não resolve. A mensagem original continua como erro ("confirmação ao parceiro bloqueada"), mesmo tendo sido entregue: é o desfecho correto, porque o parceiro nunca recebeu a confirmação dela. O Lefia não inventa identificação. A confirmação AS2 (MDN) segue a mesma regra: responde com o AS2-To e o AS2-From recebidos invertidos; sem eles, a resposta diz que a MDN não foi montada.
Duas confirmações na mesma mensagem (28/09/2026)
Uma mensagem pode ter duas confirmações, e o detalhe mostra um card para cada uma:
- Confirmação à origem — o CONTRL/997 que o Lefia devolve a quem mandou o intercâmbio: aceito, aceito com erros, rejeitado ou bloqueado (sem as partes no envelope recebido).
- Confirmação do destino — a que o destino devolve sobre o que o Lefia enviou: aguardando até chegar o CONTRL/997 do parceiro que recebe (ou a resposta da confirmação assíncrona), depois aceito ou rejeitado.
Numa integração EDI→EDI as duas existem. Uma não apaga a outra: se a confirmação à origem ficou bloqueada, a mensagem continua como erro mesmo depois de enviada e confirmada pelo destino — quem mandou o intercâmbio nunca recebeu a confirmação.
Intercâmbio recebido sem envelope: perfil da origem (30/09/2026)
Na conexão de origem (assistente, criação manual ou edição), o bloco Intercâmbio recebido (confirmação) guarda quem manda o intercâmbio por ela (remetente) e como o Lefia é identificado (destinatário). É opcional e só aparece para EDIFACT e X12. Ele só é usado quando o intercâmbio recebido não traz remetente e destinatário (ou, no X12, o qualificador): aí a confirmação sai endereçada pelo perfil, e o card do ack avisa que as partes vieram dele. Se o recebido trouxer uma parte diferente do perfil, a confirmação fica bloqueada — o Lefia não escolhe um dos dois. Integração que recebe por webhook não tem conexão de origem: nela o perfil fica guardado na própria integração (edição ou criação manual) e vale do mesmo jeito. Se a integração ganhar uma conexão de origem, passa a valer o perfil da conexão.
Histórico de versões
- v1.4.2
Correções na confirmação (CONTRL/997): o número de controle que o Lefia gera para um intercâmbio recebido passa a sair da parte aleatória do identificador da mensagem (com os identificadores novos, ordenados por tempo, dois intercâmbios da mesma fração de segundo receberiam o mesmo número); no 997 o número é numérico também no grupo (GS06/GE02), como a norma X12 pede, e uniforme entre 1 e 999.999.999 (aleatório: a chance de repetir é a mesma do envio de documentos). A confirmação que chega do parceiro só confirma mensagem enviada do MESMO ambiente (antes, uma confirmação de QAS podia marcar uma mensagem de PRD com a mesma referência). A procura ficou mais barata para o banco, em EDIFACT e X12.
15/10/2026 · updated
- v1.4.1
Corrige integração com conexão de origem INATIVA (ou de outro ambiente): o perfil do intercâmbio recebido, editado nela por engano, nunca era lido pelo ack (CONTRL/997), que ficava bloqueado sem aviso. Edição e leitura agora decidem "conexão de origem ativa" pela mesma regra.
26/09/2026 · updated
- v1.4.0
Integração que recebe por webhook (sem conexão de origem) passa a poder guardar o perfil do intercâmbio recebido — quem manda e como o Lefia é identificado. Com ele, a confirmação CONTRL/997 de um intercâmbio que chega sem remetente e destinatário no envelope sai endereçada pelo perfil, em vez de ficar bloqueada. Antes, a edição recusava o perfil nessas integrações.
25/09/2026 · updated
- v1.3.0
Confirmação (CONTRL/997) para intercâmbio recebido sem envelope completo: a conexão de origem pode ter o perfil do intercâmbio que chega (quem manda e como o Lefia é identificado). Ele só é usado quando o recebido não traz remetente e destinatário; se o recebido trouxer uma parte diferente do perfil, a confirmação fica bloqueada em vez de ir para o endereço errado. O monitor diz quando as partes vieram do perfil.
25/09/2026 · updated
- v1.2.1
Etapa 2 das duas confirmações (#101): ack_status passa a aceitar só a confirmação do DESTINO (pending, accepted, accepted_with_errors, rejected) — o bloqueio da confirmação ao parceiro de origem vive só em source_ack_status. Sai o gatilho de compatibilidade da janela do release; a cópia e a limpeza da etapa 1 foram repetidas para o que a janela deixou. Sem mudança visível: o detalhe da mensagem, os relatórios e o desfecho já liam as duas colunas desde a v1.2.0.
25/09/2026 · updated
- v1.2.0
Duas confirmações, duas colunas (#101): a que damos ao parceiro de ORIGEM (CONTRL/997 gerado ou bloqueado) fica em source_ack_status/source_ack; a do DESTINO (CONTRL/997 recebido do parceiro que recebe ou poll assíncrono) em ack_status/functional_ack. Numa integração EDI→EDI o envio gravava ack_status = pending por cima do blocked da entrada e a mensagem saía do erro; agora o bloqueio da entrada continua (desfecho error, error_category ack_blocked) seja qual for a confirmação do destino. O detalhe e o painel da mensagem mostram um card para cada confirmação; relatórios ganham o campo "Confirmação à origem" e o desfecho único (message_outcome, 4 argumentos) passa as duas em todo leitor. EDIFACT e X12.
25/09/2026 · updated
- v1.1.0
Partes do CONTRL/997 por regra única (resolveAckParties): só o intercâmbio recebido, invertido (UNB S002/S003, ISA06/08 e, no X12, ISA05/07); sem elas o ack não é gerado — ack_status blocked (desfecho error na mensagem entregue, message_outcome), error_category ack_blocked e functional_ack.direction blocked com o motivo; o detalhe e o modal mostram motivo e ação nos 3 idiomas (o novo intercâmbio recebe a confirmação). Sem "NEXIO"/"PARTNER"/"ZZ" inventados (catraca). MDN AS2 com AS2-From/AS2-To recebidos invertidos; sem eles, a resposta diz que a MDN não foi montada.
24/09/2026 · updated
- 1.0.0
Acks funcionais CONTRL/997 (#398): integração com a flag ativada confirma cada interchange EDI recebido com um CONTRL (EDIFACT) ou 997 (X12) gerado validando o documento contra a spec — devolvido na própria resposta do webhook. No sentido contrário, acks devolvidos pelo parceiro são correlacionados automaticamente com a mensagem enviada (status "aguardando ack" → aceito/aceito com erros/rejeitado), visível no monitor (card de ack no detalhe da mensagem, com o documento do ack pra download/inspeção).
12/06/2026 · new