Ocorrências de entrega: como padronizar e tratar

Ocorrência de entrega é todo fato que impede a entrega ou muda o jeito como ela foi combinada: recebedor ausente, recusa, endereço não localizado, avaria, falta de volume, local fechado. Padronizar as ocorrências de entrega significa trocar o texto livre por uma lista fechada de códigos, em que cada código tem definição, evidência mínima, responsável pelo tratamento e prazo para encerrar.

Sem essa lista, o mesmo problema aparece com cinco nomes diferentes, ninguém sabe quem precisa agir e o relatório do fim do mês mistura atraso da transportadora com cliente que não estava no endereço. Este guia mostra como montar a tabela, quem trata cada caso e que registro a ocorrência precisa ter para servir de prova.

O que conta como ocorrência de entrega

Nem todo evento da viagem é ocorrência. Saída do armazém, chegada ao destino e entrega concluída são eventos normais: mostram que a operação andou como planejado. Ocorrência é a exceção, o momento em que alguém precisa decidir alguma coisa, seja reentregar, devolver, acionar o seguro ou falar com o embarcador.

Essa separação importa porque a ocorrência abre uma tarefa. Um evento normal só precisa ser registrado. Uma ocorrência precisa ter dono, prazo e desfecho. Quando a equipe trata os dois do mesmo jeito, a fila de pendências enche de avisos que não pedem ação e as exceções reais se perdem no meio.

O próprio CT-e reconhece a tentativa de entrega frustrada como um fato com registro fiscal. A Nota Técnica 2023.002 do projeto CT-e criou o evento Insucesso na Entrega do CT-e (código 110190), exclusivo da versão 4.00 e válido para o CT-e de Transporte de Cargas (modelo 57). Segundo a nota, o evento foi criado conforme o Ajuste SINIEF 50/2022, e o cronograma da própria NT indica implantação em produção em 07/2023. O autor do evento é o emissor do CT-e, ou seja, a transportadora.

A nota define quatro motivos para o insucesso:

• 1 - Recebedor não encontrado;
• 2 - Recusa do recebedor;
• 3 - Endereço inexistente;
• 4 - Outros, com justificativa obrigatória.

Esses quatro motivos são o mínimo que a tabela interna precisa conseguir representar. A operação real tem mais nuances, e é aí que entra a tabela própria da transportadora.

Como montar a tabela de códigos de ocorrência

A tabela boa é curta o suficiente para o motorista escolher o código certo em poucos segundos no aplicativo e detalhada o bastante para separar causas que pedem tratamentos diferentes. Na prática, isso significa agrupar por tipo de problema e ligar cada código ao motivo fiscal correspondente, quando houver.

A matriz abaixo é um ponto de partida montado pela TranspNet a partir dos motivos da NT 2023.002 e da rotina de uma transportadora de carga fracionada. Os códigos internos são exemplos: cada operação adapta nomes e prazos ao seu contrato.

Alguns cuidados evitam a maioria dos problemas com essa tabela. O primeiro é não ter um código "outros" interno sem justificativa: se o motivo 4 do CT-e exige texto, a tabela interna também deve exigir. O segundo é separar "endereço não localizado" de "endereço inexistente". O motorista que não achou a rua pode estar diante de um cadastro errado, e a torre deve confirmar com o embarcador antes de declarar que o endereço não existe. O terceiro é manter avaria e falta fora do insucesso quando a carga foi recebida com ressalva: houve entrega, só que com problema.

Muitos embarcadores também pedem as ocorrências por arquivo de EDI, cada um com a sua tabela de códigos. A saída é manter uma tabela interna única e um de-para por embarcador, em vez de obrigar o motorista a conhecer o código de cada cliente.

Quem trata a ocorrência e em quanto tempo

Código sem responsável vira só estatística. Cada tipo de ocorrência precisa de um dono definido antes de acontecer, não escolhido no improviso. Um fluxo simples, que funciona para a maioria das transportadoras, tem estas etapas:

1. Registro no ato: o motorista escolhe o código no aplicativo, tira a foto e confirma, ainda no local. Registro feito na volta ao armazém perde horário, localização e detalhe.
2. Triagem pela torre: o operador confirma se o código faz sentido com a localização e o horário, verifica quais outras entregas da rota serão afetadas e encaminha ao responsável.
3. Contato com quem decide: destinatário, para reagendar; embarcador, para autorizar devolução, reentrega ou correção de endereço.
4. Decisão registrada: reentrega com nova data, devolução ao remetente, armazenagem temporária ou indenização. A decisão fica gravada na própria ocorrência, não num e-mail paralelo.
5. Encerramento com causa: a ocorrência só fecha quando o desfecho estiver registrado e a causa confirmada, que pode ser diferente do código escolhido em campo.

O prazo de tratamento deve ser medido por tipo. Uma avaria precisa de abertura imediata, porque fotos e ressalvas só podem ser colhidas no momento da entrega. Um recebedor ausente precisa de solução antes de a próxima rota ser montada, senão a carga volta ao caminhão sem data. Acompanhar o tempo entre abertura e encerramento de cada código mostra onde a equipe está travando.

A evidência que a ocorrência precisa ter

Ocorrência sem evidência abre discussão com o embarcador e, muitas vezes, termina em glosa de frete. A referência mais objetiva do que registrar está no próprio leiaute do evento fiscal. A NT 2023.002 pede, entre outros campos:

• data e hora da tentativa de entrega;
• número da tentativa, campo opcional;
• motivo do insucesso e, para o motivo 4, uma justificativa de 25 a 250 caracteres;
• latitude e longitude do ponto, opcionais, detectadas pelo equipamento do transportador, como PDA, tablet ou celular;
• um hash da imagem capturada na tentativa, que pode ser assinatura eletrônica, digital do recebedor ou foto;
• o grupo com as chaves das NF-e com insucesso na tentativa de entrega, que a nota manda informar apenas para CT-e com tipo de serviço Normal e que se torna obrigatório quando esse CT-e tem o grupo infNFe preenchido.

Um ponto da nota afeta a rotina: segundo ela, a SEFAZ não tem nenhum controle sobre a informação do campo de hash, que é só o resumo da imagem. Por isso a TranspNet recomenda manter a foto original arquivada no sistema da transportadora, junto com a ocorrência, para ter o que mostrar se a entrega for contestada. Vale também manter no sistema da transportadora o histórico completo de tentativas, com hora, motivo e evidência de cada uma, porque é ele que sustenta a conversa com o embarcador quando a entrega atrasa.

Na análise da TranspNet, vale aplicar o mesmo padrão a ocorrências que não viram evento fiscal, como avaria e espera para descarga. Horário, localização e foto colhidos pelo aplicativo no momento do fato pesam muito mais do que uma descrição digitada horas depois.

Como a torre de controle organiza as ocorrências

A tabela de códigos e a matriz de responsáveis funcionam melhor quando todos olham para a mesma tela. É o papel de uma torre de controle logístico, da coleta ao comprovante de entrega: juntar o evento de campo, a carga, a rota e o prazo, e mostrar ao operador qual exceção precisa de atenção primeiro.

No SmartGT, a Torre de Controle fica no Dashboard SmartGT. Cada evento entra na linha do tempo da carga com data, hora, local e a origem da informação, se veio do GPS ou foi registrado pela operação, e a equipe pode registrar ou corrigir um evento. Geocercas e rotas-modelo transformam a posição do veículo em eventos sem digitação, e o motorista confirma a entrega pelo aplicativo com a foto do canhoto. A Torre é um módulo que exige treinamento e implantação com a equipe da TranspNet, e os códigos de ocorrência são definidos junto com a rotina de cada transportadora.

Com as ocorrências padronizadas, os indicadores passam a contar uma história coerente. A taxa de insucesso por motivo mostra se o problema está no cadastro de endereços, no agendamento com o destinatário ou na própria operação. E o tempo de tratamento por código mostra quem está segurando a fila.

Perguntas frequentes sobre ocorrências de entrega

Qual a diferença entre ocorrência de entrega e insucesso na entrega?

Ocorrência é qualquer exceção na entrega, inclusive avaria, falta de volume e espera para descarga, mesmo quando a carga é recebida. Insucesso é a tentativa que não terminou em recebimento. Para o CT-e, a NT 2023.002 criou o evento Insucesso na Entrega do CT-e (110190), com os motivos recebedor não encontrado, recusa do recebedor, endereço inexistente e outros.

Quantos códigos de ocorrência a transportadora deve ter?

Não existe número certo. A tabela deve ser curta o bastante para o motorista escolher no aplicativo sem dúvida e detalhada o bastante para separar causas com tratamentos diferentes. Se dois códigos sempre recebem o mesmo tratamento, eles podem virar um só.

Quem é o autor do evento de insucesso no CT-e?

Pela NT 2023.002, o autor do evento é o emissor do CT-e, e a mensagem é assinada com o certificado digital do CNPJ base desse emissor. Na prática, é a transportadora que registra o insucesso.

Quando uma ocorrência pode ser encerrada?

Quando o desfecho estiver registrado, seja reentrega concluída, devolução, armazenagem ou indenização, e a causa tiver sido confirmada. Fechar a ocorrência só porque o motorista seguiu viagem esconde o problema e distorce os indicadores.

Fontes e Referências

• Nota Técnica 2023.002 do CT-e: Evento Insucesso da Entrega, versão 1.01 (Portal DF-e SVRS)
• Documentos do CT-e: notas técnicas e datas de implantação (Portal DF-e SVRS)