Anatomia do EDI logístico: NOTFIS, OCOREN, CONEMB e por que integrações quebram

Todo mundo que atende embarcador grande já ouviu a frase “vocês têm EDI?”. Já explicamos por que o embarcador exige EDI e o que está em jogo comercialmente. Este post desce um nível: o que existe dentro desses arquivos, por que eles quebram com tanta frequência e o que perguntar antes de contratar qualquer sistema.

A conversa importa porque o EDI logístico brasileiro não é uma API moderna. É um padrão de arquivos de texto dos anos 90, o PROCEDA, que segue sendo a língua franca entre embarcadores e transportadoras. Quem entende a anatomia dele para de tratar integração como caixa-preta.

O padrão PROCEDA: texto posicional trocado em lote

O PROCEDA é um conjunto de layouts de arquivo texto, documentação aberta do setor, que define como embarcador e transportadora trocam informações do ciclo de transporte. Não há requisição e resposta em tempo real: os arquivos são gerados em lote, depositados em um diretório (quase sempre FTP ou SFTP, às vezes VAN ou e-mail) e processados pelo outro lado quando chegam.

Cada arquivo é uma sequência de linhas, e cada linha é um registro identificado pelos primeiros caracteres. Dentro da linha, os campos não são separados por vírgula nem nomeados como em JSON: eles são posicionais. O campo existe porque começa na coluna X e tem tamanho Y, e pronto.

Um exemplo em texto corrido: num registro de nota fiscal, o CNPJ do emitente pode ocupar as posições 4 a 17, a série da nota as posições 18 a 20 e o número da nota as posições 21 a 28, com zeros à esquerda. Se o sistema escrever o número da nota uma coluna adiante, não dá erro de sintaxe: o arquivo continua “válido” e o dado vira lixo silencioso.

Os quatro documentos do ciclo: NOTFIS, CONEMB, OCOREN e DOCCOB

O PROCEDA não é um arquivo só, é uma família de documentos, cada um com um papel no ciclo da carga. Os quatro que sustentam a operação são estes:

• NOTFIS. O embarcador envia à transportadora a relação de notas fiscais a transportar: volumes, pesos, valores, remetente e destinatário. É o pedido de transporte em formato eletrônico, e é dele que nasce a coleta.
• CONEMB. O caminho de volta: a transportadora devolve os dados do conhecimento de transporte emitido para aquelas notas. Se você quer relembrar o documento fiscal em si, veja o que é CT-e; o CONEMB é a versão EDI dessa informação, amarrando cada nota ao conhecimento que a cobre.
• OCOREN. As ocorrências de entrega, com uma tabela de códigos padronizada: entrega realizada, recusa do destinatário, avaria, falta, reentrega agendada. É o documento que o embarcador mais monitora, porque é ele que diz se a carga chegou.
• DOCCOB. O fechamento financeiro: a transportadora envia os dados das faturas de cobrança dos fretes, e o embarcador concilia contra o que foi transportado antes de pagar.

O ciclo completo é elegante na teoria: NOTFIS entra, CONEMB responde, OCOREN narra a entrega, DOCCOB cobra. Na prática, cada elo dessa corrente é um ponto de falha, e é aí que a conversa fica interessante.

Esse formato posicional tem uma virtude real: é simples de gerar e de ler em qualquer tecnologia, de mainframe a planilha, sem depender de parser sofisticado nem de conexão estável. Foi isso que fez o padrão sobreviver trinta anos. A fragilidade é o verso da moeda: sem validação estrutural embutida, qualquer desvio de coluna produz um arquivo que parece certo e está errado, e o problema só aparece dias depois, na conciliação do embarcador.

Versões e dialetos: o detalhe cruel do “padrão”

O PROCEDA tem versões (3.0, 3.1, 5.0 são as mais citadas), com diferenças de campos e de tamanho de registro entre elas. Até aí, normal: padrão evolui. O detalhe cruel é outro: cada embarcador adota “o padrão” com dialeto próprio.

Um exige a versão 3.1 mas com um campo opcional tornado obrigatório. Outro usa a 5.0 mas mantém a tabela de ocorrências antiga. Um terceiro criou códigos de ocorrência próprios que não existem em tabela nenhuma. É exatamente por isso que existe homologação: não se “liga o EDI”, homologa-se a integração com aquele embarcador específico, arquivo de teste por arquivo de teste, até os dois lados aceitarem o que o outro produz.

Isso muda a régua de avaliação de qualquer sistema. A pergunta nunca é “seu TMS tem EDI?”, porque a resposta é sempre sim. A pergunta é: com quantos embarcadores esse EDI já foi homologado e opera em produção?

Por que as integrações quebram na vida real

Depois de acompanhar dezenas de homologações, os modos de falha se repetem com uma previsibilidade quase cômica. Os campeões são estes:

• Data e número em formato divergente. DDMMAAAA de um lado, AAAAMMDD do outro; decimal com vírgula implícita de um lado, explícita do outro. O arquivo passa, o valor fica 100 vezes maior.
• Encoding e acentuação. O nome do destinatário com “ç” vira caractere estranho, desloca a posição dos campos seguintes e corrompe a linha inteira.
• Código de ocorrência fora da tabela. O embarcador inventou o código 87 para um cenário interno dele; o sistema da transportadora rejeita ou, pior, ignora em silêncio.
• Arquivo duplicado ou fora de ordem. O OCOREN da entrega chega antes do CONEMB do conhecimento, ou o mesmo lote é depositado duas vezes e gera ocorrência em dobro.
• Mudança de layout sem aviso. O embarcador atualiza o sistema dele numa sexta-feira e o arquivo de segunda vem com dois campos a mais. Ninguém comunicou, tudo para.
• A fila parada que ninguém monitora. O FTP mudou de senha, o job travou, e os arquivos simplesmente pararam de sair. Nenhum erro aparece, porque nada está rodando.

O último item merece destaque, porque é o mais caro e o menos visível. No EDI em lote, o silêncio é o pior erro possível.

Se o OCOREN não sai, para o embarcador a entrega não aconteceu. Não importa que o canhoto esteja assinado no arquivo da filial: sem a ocorrência eletrônica, o indicador de nível de serviço cai e a fatura é glosada. A transportadora fez o serviço e não consegue provar no único canal que conta.

É por isso que EDI não é projeto de implantação, é operação contínua. Quem trata como “instalou, esqueceu” descobre o problema semanas depois, dentro do relatório de glosa, quando já virou dinheiro perdido e briga comercial num bid de frete futuro.

Como se diagnostica uma integração EDI

A boa notícia: o diagnóstico segue um roteiro conhecido. O primeiro instrumento é o log de troca, o registro de cada arquivo enviado e recebido, com data, hora e resultado do processamento. Sem esse log, qualquer discussão com o embarcador vira “eu enviei” contra “eu não recebi”.

O segundo é o arquivo de retorno ou de erro que muitos embarcadores devolvem apontando as linhas rejeitadas e o motivo. Ler esse retorno e agir sobre ele é metade do trabalho de manter a integração viva. O terceiro é o reprocessamento: corrigido o dado, o mesmo lote precisa poder ser gerado e reenviado sem duplicar o que já foi aceito.

E o quarto, o que separa operação madura de operação sortuda: o alerta de fila parada. Se um embarcador que recebe ocorrências todos os dias fica horas sem receber nada, alguém precisa ser avisado antes que o embarcador ligue. O insumo dessa fila, aliás, é a disciplina de registrar bem as ocorrências de viagem na operação: EDI bom não conserta apontamento ruim.

E a API moderna? O contraste, e por que o PROCEDA ainda manda

Integrações modernas via API com JSON invertem a lógica do lote: cada evento é validado na entrada e o erro aparece na hora para quem enviou, não como lixo silencioso descoberto na conciliação. Tecnicamente, não há comparação.

Só que a escolha do protocolo não é da transportadora. O ERP do embarcador grande fala PROCEDA há décadas, e trocar isso custa um projeto que ele não fará para agradar o fornecedor de frete. O legado do lado do embarcador manda: o caminho realista é um TMS que fale as duas línguas, PROCEDA para quem exige e API para quem já evoluiu.

A régua para avaliar fornecedor (e onde a Growth Log entra)

Se você chegou até aqui, já tem a régua pronta. Diante de qualquer sistema que prometa EDI, faça três perguntas: quantos embarcadores estão homologados e operando em produção, quem monitora a fila de arquivos no dia a dia, e quem corrige quando o layout muda sem aviso. Se a resposta para as duas últimas for “a sua equipe de TI”, o custo real do EDI acabou de dobrar.

Na Growth Log, a integração já nasce pronta: o embarcador homologa, as notas do NOTFIS entram como pedido de coleta, o CONEMB e o OCOREN saem no ritmo da operação e a fila é monitorada com alerta de silêncio, sem a sua equipe digitar nota ou vigiar FTP. Sua transportadora prova a entrega no canal que o embarcador aceita, e a fatura para de ser glosada por falha de arquivo. Agende uma demonstração.