Se você trabalha com faturamento no Protheus, sabe como é: está tudo certo, pedido pronto, nota gerada… e quando vai transmitir, toma uma rejeição do nada.
E não é qualquer rejeição.
É aquela que trava tudo:
“1155 – Data de previsão de entrega anterior ao permitido”
E aí começa a correria.
Neste artigo, vou te mostrar de forma direta o que causa esse erro e, principalmente, 4 formas práticas de resolver — desde a mais simples até a mais automatizada.
O que é a rejeição 1155 no Protheus
A rejeição 1155 acontece quando a data de previsão de entrega da nota (F2_DTENTR) está menor que a data de emissão.
Ou seja, na prática:
Você está dizendo para a SEFAZ que a entrega aconteceu antes da nota existir.
E aí não passa mesmo.
A mensagem geralmente vem assim:
“014 – NFe não autorizada – Corrija o problema e retransmita as notas fiscais eletrônicas. 1155/Rejeição: Data de previsão de entrega anterior ao permitido”
Por que isso acontece (e por que é mais comum do que parece)
Esse problema normalmente não nasce na nota.
Ele vem do processo.
Na maioria dos casos, acontece porque:
- O pedido de venda foi criado com uma data antiga
- O pedido ficou parado e só foi faturado depois
- A data de entrega foi herdada automaticamente sem validação
- Ou simplesmente ninguém percebeu esse detalhe no fluxo
Ou seja, não é erro técnico.
É erro de processo.
Como corrigir a rejeição 1155 no Protheus
Agora vamos para o que interessa: como resolver.
Aqui vão 4 formas — da mais rápida até a mais estruturada.
Forma 1 – Aplicar atualização oficial da TOTVS
A própria TOTVS já identificou esse cenário e liberou um pacote de correção com orientações.
Se você quer seguir o caminho mais “by the book”, pode usar a documentação oficial:
Essa abordagem é ideal se você prefere manter tudo alinhado com o padrão TOTVS.
Mas na prática… nem sempre resolve rápido o problema do dia a dia.
Forma 2 – Corrigir manualmente (rápido e direto)
Se você precisa resolver agora, sem depender de patch:
- Exclua a nota fiscal gerada
- Faça o cancelamento, se necessário
- Volte no pedido de venda
- Ajuste a data de entrega:
- C5_FECENT (cabeçalho)
- C6_ENTREG (itens)
- Coloque uma data posterior à emissão
- Refature o pedido
- Transmita novamente
Simples. Funciona.
Mas não escala.
Se isso acontece com frequência, você vai ficar apagando incêndio.
Forma 3 – Automatizar via ponto de entrada (melhor abordagem)
Aqui começa o jogo profissional.
Em vez de corrigir na mão toda vez, você pode fazer o Protheus se proteger sozinho.
A ideia é simples:
Quando a nota for gerada, o sistema valida a data.
Se estiver inválida, ele ajusta automaticamente.
Você pode fazer isso usando o ponto de entrada SF2460I.
E aqui está o código (mantido exatamente como você trouxe):
//Bibliotecas
#Include 'Totvs.ch'
/*/{Protheus.doc} SF2460I
Ponto de entrada após inclusão de informações na SF2
@type user function
@author Atilio
@since 09/02/2026
@version 1.0
@see https://centraldeatendimento.totvs.com/hc/pt-br/articles/11814672801943-Cross-Segmento-TOTVS-Backoffice-Linha-Protheus-SIGAFAT-Ponto-de-Entrada-SF2460I
/*/
User Function SF2460I()
Local aArea := FWGetArea()
Local dDataAtu := Date()
//Se o tipo de frete for CIF, pelo Remetente ou Terceiros e se a previsão de entrega for menor que a data atual
// Dica do tipo de Frete enviada pelo Tiago Fonseca Lima de Morais
If SF2->F2_TPFRETE $ "C;R;T;".And. SF2->F2_DTENTR <= dDataAtu
//Atualiza a data de entrega, adicionando 7 dias, para ficar após que a emissão
RecLock("SF2", .F.)
SF2->F2_DTENTR := DaySum(dDataAtu, 7)
SF2->(MsUnlock())
EndIf
FWRestArea(aArea)
Return
O que esse código faz na prática
Ele intercepta a geração da nota e verifica:
- Se o tipo de frete é válido
- Se a data de entrega está no passado
Se estiver errado, ele corrige automaticamente adicionando 7 dias.
Resultado:
- Você evita rejeição
- Evita retrabalho
- Evita dor de cabeça no faturamento
Forma 4 – Ajustar o processo (o que realmente resolve de vez)
Agora o ponto que pouca gente fala.
Você pode corrigir no código.
Pode corrigir manual.
Pode aplicar patch.
Mas se o processo continuar errado… o problema volta.
Então o ideal é:
- Revisar como as datas são definidas no pedido
- Validar antes do faturamento
- Criar alertas ou bloqueios
- Treinar o time comercial / faturamento
Porque no final do dia, ERP não erra sozinho.
O que recomendamos aqui na Geeker
Se você quer uma recomendação prática:
- Use o ponto de entrada para evitar erro técnico
- Ajuste o processo para evitar erro operacional
Essa combinação resolve de verdade.
E mais importante: evita que seu faturamento pare por algo simples.
Conclusão
A rejeição 1155 não é complexa.
Mas ela é perigosa.
Porque normalmente aparece no pior momento:
quando a nota precisa sair.
Se você tratar só como erro técnico, vai continuar apagando incêndio.
Mas se tratar como processo + sistema… você elimina o problema.
Quer evitar esse tipo de problema no seu Protheus?
Aqui na Geeker, a gente não só resolve erro.
A gente evita que ele aconteça de novo.
Se você está lidando com retrabalho, rejeições ou processos inconsistentes no Protheus, talvez o problema não seja o sistema… e sim a forma como ele está sendo usado.
Fala com a gente.
