EDI Proceda: guia de referência de NOTFIS, CONEMB, OCOREN, DOCCOB e PREFAT

O que é o EDI Proceda

EDI é a sigla de Electronic Data Interchange, a troca de dados estruturados entre sistemas de empresas diferentes. No transporte brasileiro, o padrão que se consolidou é o Proceda: um conjunto de layouts de arquivo texto, com campos de posição e tamanho fixos, que embarcadores e transportadoras usam para informar notas fiscais a transportar, conhecimentos emitidos, ocorrências de entrega e documentos de cobrança.

O padrão nasceu nos anos 1990 e continua sendo a exigência mais comum de indústrias e grandes varejistas na homologação de uma transportadora. Ele convive com integrações mais novas por API, mas não foi substituído: o sistema do embarcador já fala Proceda, e trocar isso custa mais do que exigir que a transportadora fale também.

Para uma transportadora, dominar o padrão é uma alavanca comercial. Cada embarcador que exige EDI é um cliente que a concorrência sem integração não consegue atender.

Os arquivos e o papel de cada um

O padrão define um arquivo para cada momento da relação entre embarcador e transportadora. O sentido do arquivo diz quem gera e quem consome.

Como o arquivo é estruturado

Cada arquivo é um texto com linhas de tamanho fixo. Cada linha é um registro identificado por um código numérico no início, e cada campo ocupa uma posição e um tamanho definidos no layout. Um arquivo começa por um cabeçalho de intercâmbio, que identifica remetente, destinatário e data, e segue com os registros do documento: cabeçalho do documento, dados das partes, notas ou conhecimentos, e um registro de totais quando o layout prevê.

As versões mais encontradas em produção são a 3.1 e a 5.0. A 5.0 amplia campos e prevê informações que a 3.1 não comporta, como chaves de acesso completas e dados adicionais de entrega. Na prática, quase todo embarcador usa uma variação própria: campos opcionais que ele torna obrigatórios, códigos de ocorrência proprietários, regras de agrupamento. Por isso o ponto de partida de qualquer implantação é o manual do embarcador, não o padrão genérico.

Códigos de ocorrência

O OCOREN é o arquivo que mais gera atrito, porque cada evento da rua precisa ser traduzido para o código que o embarcador espera. O padrão define uma tabela de ocorrências; os embarcadores costumam usar um subconjunto dela e acrescentar códigos próprios. Os primeiros códigos são estáveis entre as versões.

• Além desses, a tabela cobre famílias de eventos: recusa por divergência comercial ou de mercadoria, endereço não localizado ou incorreto, destinatário ausente ou estabelecimento fechado, falta de agendamento, avaria, extravio, devolução e reentrega programada.
• O código correto depende da versão e do manual do embarcador. Peça a tabela dele e mapeie cada motivo de insucesso que sua operação usa para um código válido. Motivo sem código vira ocorrência que nunca chega ao cliente.
• Data e hora da ocorrência devem refletir o momento do evento na rua, não o momento do envio do arquivo. Registros capturados sem conexão e sincronizados depois precisam preservar o horário original.

Os erros que derrubam uma integração EDI

A maior parte das falhas de EDI não é técnica no sentido de código. É cadastro, layout e rotina. Estes são os problemas que aparecem com mais frequência na implantação e nos primeiros meses de operação.

• Layout desatualizado: o embarcador mudou a versão ou um campo obrigatório e o manual em mãos é o antigo. Confirme a versão vigente e peça arquivos de exemplo recentes.
• Campos truncados: valores maiores que a posição prevista são cortados sem aviso. Nomes de destinatário e complementos de endereço são os casos mais comuns.
• Codificação de caracteres: acentos gerados em um padrão e lidos em outro corrompem o arquivo. Combine a codificação com o parceiro e valide com um arquivo real que contenha acentuação.
• Chave de vínculo divergente: o CONEMB ou o OCOREN referencia a nota com série ou número fora do formato que o embarcador usa no NOTFIS. O vínculo quebra e o cliente enxerga uma nota sem retorno.
• Duplicidade: o mesmo NOTFIS processado duas vezes gera remessas duplicadas. O sistema precisa reconhecer o arquivo ou a nota já recebida.
• Frequência sem dono: o OCOREN sai a cada hora, mas ninguém acompanha rejeições. O cliente descobre o problema na cobrança. Defina quem monitora e em quanto tempo uma rejeição é tratada.
• Ocorrência sem contexto: o código diz recusa, mas a observação do motorista não chega ao cliente. Quando o layout permitir, envie o complemento; quando não, tenha o registro disponível para o atendimento.

Checklist para colocar o EDI de um embarcador no ar

Uma implantação de EDI previsível segue uma sequência curta. O que costuma atrasar é a coleta de informação no início, não a configuração.

• Receber do embarcador: manual do layout com versão, arquivos de exemplo de cada tipo, tabela de códigos de ocorrência, frequência esperada e canal de troca (FTP, SFTP, e-mail, portal ou API).
• Definir no cadastro: regras de agrupamento de notas em remessa, tratamento de nota cancelada e duplicada, série e numeração usadas no vínculo.
• Mapear ocorrências: cada motivo de insucesso e cada evento da operação para um código válido do embarcador.
• Validar com arquivos reais: processar um NOTFIS de verdade em ambiente de teste, emitir o CT-e em homologação, registrar uma entrega e uma tentativa, gerar CONEMB e OCOREN e submeter ao embarcador para aceite.
• Combinar a operação: responsáveis por rejeições de cada lado, prazo de tratamento, o que fazer quando o canal de troca ficar indisponível.
• Acompanhar os primeiros dias com atenção: os erros de layout aparecem na primeira semana, os de rotina no primeiro fechamento de fatura.

Como a Lotriva atende o EDI Proceda

O TMS Elite recebe e gera os arquivos do padrão com layouts configurados por embarcador: o NOTFIS cria remessas e coletas, o CONEMB sai da emissão do CT-e, o OCOREN nasce dos eventos da operação e do LogDriver, e DOCCOB e PREFAT saem do faturamento. O LogConex é a frente que acompanha cada conexão: arquivos recebidos, rejeitados e pendentes de retorno, com responsáveis definidos.

Para avaliar o seu caso, traga o manual do embarcador, um NOTFIS de exemplo sem dados sensíveis e a tabela de ocorrências que ele exige. A equipe confirma o mapeamento, as variações do layout e o caminho de implantação.