Como Corrigir a rejeição 1155 Data de previsão de entrega anterior ao permitido

No artigo de hoje, vamos abordar em como corrigir a rejeição 1155 ao tentar transmitir um documento na tela do NFe Sefaz no Protheus.

Se você, tentou transmitir o documento e se deparou com a seguinte mensagem:

“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”

Isso significa que por algum motivo, a informação de data de entrega da NF (F2_DTENTR) ficou anterior à emissão, pode ter sido algum pedido que ficou a informação, e só depois que foi faturado que perceberam.

Abaixo um exemplo da mensagem de erro:

Mensagem de rejeição da nota

Mensagem de rejeição da nota

Nesse artigo vamos abordar então, 4 formas de corrigir o problema.

Forma 1 – Atualizando conforme documentação da TOTVS

Enquanto eu montava esse artigo (no começo de fevereiro), subiram um link no dia 04 de Fevereiro com um pacote de atualização e um procedimento com patch.

Então você pode se basear nessa forma, nesse link: https://centraldeatendimento.totvs.com/hc/pt-br/articles/38098324411159-Cross-Segmentos-Backoffice-Protheus-Doc-Eletr%C3%B4nicos-NFE-Reforma-Tribut%C3%A1ria-Rejei%C3%A7%C3%A3o-1155-Data-de-previs%C3%A3o-de-entrega-anterior-ao-permitido

Forma 2 – Refazendo o processo manualmente

  1. Exclua a nota fiscal, e transmita o cancelamento
  2. Vá no pedido de venda, e altere a data de previsão de entrega, campo C5_FECENT ou C6_ENTREG, coloque para alguns dias após a data que será faturado
  3. Fature novamente o pedido e faça a transmissão

Forma 3 – Via ponto de entrada

  1. Nesse ponto de entrada, quando a nota for ser faturada, vai ser validado a data
  2. Se a data atual for maior que a previsão de entrega, ela vai ser atualizada automaticamente

3. Então basta compilar a função abaixo e para as novas notas irá funcionar

//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

Obs.: Pessoal, existe um p.e. que é melhor para o cenário, que é o MT46DTEN, citado pelo Divair na parte de comentários dessa página. Mas esse p.e. só vai funcionar se o sistema estiver atualizado (conforme descrito na Forma 1).

Forma 4 – Atualizando direto na SF2

Ah Daniel, mas e se for algo urgente e eu não conseguir refazer a forma 1 ou 2 ou fazer o ponto de entrada da forma 3?

Tem como você atualizar os dados direto no banco, seja via APSDU ou via UPDATE, ressaltando que não é o processo recomendado, mas em casos de urgência.

Então para o cenário, onde:

  • Filial: 01
  • Número da Nota: 000123456
  • Série: 1
  • Cliente: 000987
  • Loja: 01
  • Data de Emissão: 09/02/2026
  • Data de Entrega: 05/02/2026

Vamos atualizar a data de entrega, colocando ela para o dia 15/02/2026, então a query vai ficar da seguinte forma:

UPDATE
    SF2010
SET
    F2_DTENTR = '20260215'
WHERE
    F2_FILIAL = '01'
    AND F2_DOC = '000123456'
    AND F2_SERIE = '1  '
    AND F2_CLIENTE = '000987'
    AND F2_LOJA = '01'
    AND D_E_L_E_T_ = ' '

Bom pessoal, por hoje é só.

Abraços e até a próxima.

Dan (Daniel Atilio)
Cristão de ramificação protestante. Especialista em Engenharia de Software pela FIB, graduado em Banco de Dados pela FATEC Bauru e técnico em informática pelo CTI da Unesp. Entusiasta de soluções Open Source e blogueiro nas horas vagas. Autor e mantenedor do portal Terminal de Informação.

6 Responses

    • Bom dia Divair, tudo joia?

      É uma excelente dúvida. Sim, ele é melhor que o SF2460I.

      Desde que, seja aplicado junto com a forma 1 explicado nesse artigo, pois se o cliente estiver com o ambiente desatualizado, e não tiver como atualizar o backoffice ou as patchs pontuas, esse p.e. não irá existir, ai por consequência mesmo criando a user function, ela não será acionada.

      Mas depois irei revisar o artigo, ai eu atualizo o texto também para não causar confusão na leitura.

      Tenha um ótimo e abençoado fim de semana.

      Um forte abraço.

  1. Eduardo Souza Melo disse:

    Boa noite Daniel!
    Tenho uma dúvida sobre as rejeições 391 e 392 que falam da não informação de pagamentos.
    Pelo modulo Faturamento SIGAFAT é possível gerar as tags YA de cartão de crédito, débito e Pix?
    Procurei documentação na TOTVS e não achei algo sobre.

    • Bom dia Eduardo, tudo joia?

      Pelo SIGALOJA já vi, mas pelo SIGAFAT normal, não me recordo de ter visto, tipo pegar uma forma de pagamento e gerar as tags.

      Tentei procurar no TDN, mas não encontrei páginas sobre.

      O que você pode fazer é abrir um chamado na TOTVS, algo como:

      “Bom dia.

      Temos a necessidade de informar as tags de forma de pagamento (cartão de crédito, débito ou pix) no nfesefaz.prw , para não acontecer as rejeições 391 e 392.

      Acontece que usamos o SIGAFAT (não estamos usando o SIGALOJA no momento).

      Existe alguma documentação sobre o assunto? Se sim poderiam nos enviar (sobre as rejeições e como tratar elas para quem só usa o SIGAFAT).

      Caso não tenha a documentação sobre as rejeições, poderiam nos orientar, em quais tabelas devemos gravar as informações, para que no fonte nfesefaz, ele monte essas tags?

      Agradecemos desde já.”

  2. Gildeir disse:

    Boa tarde Daniel, tudo bem? Há a possibilidade de usar o ponto de entrada PE01NFESEFAZ para manipular a data de entrega no momento da transmissão da nota, pode haver casos onde o pedido é gerado e um dia e transmitido em outro, sendo assim, a data de entrega não ficaria precisa.

    Dentro do P.E possuímos uma serie de informações, mas não encontrei a localização exata dessa informação entre os array disponíveis:

    User Function PE01NFESEFAZ()

    Local aRet := PARAMIXB
    Local aProd := PARAMIXB[1]
    Local cMensCli := PARAMIXB[2]
    Local cMensFis := PARAMIXB[3]
    Local aDest := PARAMIXB[4]
    Local aNota := PARAMIXB[5]
    Local aInfoItem := PARAMIXB[6]
    Local aDupl := PARAMIXB[7]
    Local aTransp := PARAMIXB[8]
    Local aEntrega := PARAMIXB[9]
    Local aRetirada := PARAMIXB[10]
    Local aVeiculo := PARAMIXB[11]
    Local aReboque := PARAMIXB[12]
    Local aNfVincRur:= PARAMIXB[13]
    Local aEspVol := PARAMIXB[14]
    Local aNfVinc := PARAMIXB[15]
    Local AdetPag := PARAMIXB[16]
    Local aObsCont := PARAMIXB[17]
    Local aProcRef := PARAMIXB[18]
    Local aMed := PARAMIXB[19]
    Local aLote := PARAMIXB[20]

    • Bom dia Gildeir, tudo joia?

      No caso então, vocês faturam em um dia (geram a SF2) e transmitem em outro, seria isso?

      É que o ponto de entrada no exemplo do artigo, ele serve na hora que está gerando a SF2.

      Mas enfim, se quiser tratar direto no PE01NFESEFAZ, olhando aqui o nfesefaz.prw, a informação de data de entrega fica dentro do aNota, acho que é a décima posição (baixei o rdmake mais atual do portal da TOTVS e olhei pela variável dPrevEntrega).

      Ai no ponto de entrada, tenta manipular esse aNota.

      Tenha uma ótima e abençoada sexta feira.

      Um forte abraço.

Deixe uma resposta

Terminal de Informação