NF-e
Rejeição 1157: confira previsão de entrega e modalidade real de frete
Quando a NF-e recebe o código 1157, compare a data prevista de entrega com a modalidade de frete informada. A condição documentada envolve uma combinação proibida. A solução depende de descobrir qual informação foi enviada indevidamente: a data, o código do frete ou a configuração que gerou esses campos. Acordo…
Quando a NF-e recebe o código 1157, compare a data prevista de entrega com a modalidade de frete informada. A condição documentada envolve uma combinação proibida. A solução depende de descobrir qual informação foi enviada indevidamente: a data, o código do frete ou a configuração que gerou esses campos. Acordo comercial, pedido e XML precisam contar a mesma história.
A mensagem oficial é “Rejeição: Data de previsão de entrega não permitida para a modalidade de frete informada”. O contexto deste artigo é a autorização da NF-e, modelo 55, regra B10a-50 da NT 2025.002-RTC v1.52, página 31. A regra não é uma validação genérica da impressão do DANFE nem uma falha de certificado. [1]
Quais combinações provocam a rejeição
A B10a-50 proíbe o preenchimento de ide/dPrevEntrega quando transp/modFrete tem um destes valores: 1, contratação do frete por conta do destinatário, FOB; 4, transporte próprio por conta do destinatário; ou 9, sem ocorrência de transporte. É necessário conferir o número exportado, além da descrição apresentada na tela. [1]
Essas três situações não são sinônimas. No frete 1 há contratação por conta do destinatário; no 4, transporte próprio por conta dele; no 9, declara-se ausência de transporte. A retirada pelo cliente deve ser analisada conforme o fato real, e não automaticamente classificada como “sem transporte”. O responsável fiscal e a equipe logística devem esclarecer a modalidade aplicável antes da correção.
Não troque o frete para uma opção que aceite a data apenas para eliminar o 1157. Se o cliente é responsável pelo transporte, mudar o código para dizer que a responsabilidade é do emitente pode produzir uma nota tecnicamente diferente da operação.
Preserve o retorno e confira a origem dos campos
Guarde o XML efetivamente transmitido e a resposta completa. Registre chave, série, número, horário, UF, autorizador e ambiente. Confira se a mensagem veio da autorização em produção, de uma tentativa em homologação ou de uma validação interna do emissor. Isso impede comparar arquivos de testes com documentos reais ou atribuir uma resposta a outra versão da nota.
Localize dPrevEntrega e modFrete no XML. A data do pedido, a data de saída e a previsão de entrega não devem ser tratadas automaticamente como o mesmo campo. Verifique também se o frete veio do cadastro do cliente, da transportadora, do pedido ou de um padrão definido para todas as notas.
Compare esses valores com a contratação de transporte e com a forma prevista de movimentar a mercadoria. Se a tela parece correta, peça a comparação com o arquivo enviado. A falha pode estar na integração, no documento copiado ou em uma geração anterior que ainda ficou pendente de transmissão.
Como corrigir em cada cenário
O frete 1, 4 ou 9 representa corretamente a operação
Retire a previsão do campo fiscal dPrevEntrega pelo fluxo do emissor. A informação logística pode continuar preservada no pedido e nos controles internos adequados. Essa separação mantém o histórico comercial sem enviar a tag vedada para a modalidade confirmada.
Depois de salvar, gere novamente o XML e verifique se a tag foi realmente omitida. Limpar a data em uma tela não resolve se outra etapa a recupera do pedido ou da configuração padrão. Corrija essa origem para o mesmo cenário; não elimine indiscriminadamente previsões de todas as notas da empresa.
A modalidade foi importada ou cadastrada de forma errada
Se os documentos mostram outra responsabilidade pelo transporte, corrija modFrete para a modalidade verdadeira. Revise a configuração que selecionou o valor e os demais dados de transporte relacionados à operação. A alteração deve ser explicável pelas evidências, não pelo desejo de conservar uma data no XML.
Se a modalidade correta não for 1, 4 ou 9, a proibição específica da B10a-50 não se aplica. Isso não significa autorização automática para qualquer previsão: a finalidade da NF-e e os limites da data continuam sujeitos a outras regras. Confira o conjunto antes de transmitir novamente.
A rejeição persiste apesar de os campos estarem coerentes
Confira se a resposta corresponde à mesma chave e ao mesmo XML examinado. Procure versões armazenadas, filas de envio e transformações posteriores. Se o arquivo enviado não contém a previsão ou não possui uma das modalidades da regra, reúna a divergência para o suporte e, quando necessário, para o autorizador.
Não edite manualmente o XML assinado, não crie uma segunda nota para esconder o problema e não repita o mesmo envio indefinidamente. A correção precisa passar pelo processo de geração e assinatura do emissor. Dúvidas sobre a forma correta de documentar o transporte devem ser resolvidas com a contabilidade.
Exemplo hipotético
Num exemplo fictício, uma loja vende equipamentos a um cliente que contratou a transportadora por sua conta. O pedido registra uma previsão comercial. Na geração da NF-e, modFrete=1 é combinado com a data em dPrevEntrega, situação descrita na 1157. Não se trata de um envio ou resultado real.
A equipe confirma que o frete por conta do destinatário está correto. Mantém o código 1, retira a previsão da tag fiscal e preserva o prazo combinado no pedido. O suporte ajusta a cópia automática para que o mesmo tipo de operação não volte a exportar a data. Um novo XML é conferido e transmitido. A equipe lê seu resultado e somente considera a emissão concluída quando há o retorno correspondente, sem presumir autorização pelo desaparecimento da primeira mensagem.
Verifique o resultado completo
Compare antes e depois: a correção deve ser localizada, justificada e fiel à operação. Confira que a modalidade não mudou sem fundamento, que a previsão não reapareceu e que os dados restantes do documento continuam corretos. Se autorizado, preserve XML e protocolo e confira o vínculo com o pedido. Se vier outro código, abra um diagnóstico para a nova condição.
A NFC-e modelo 65 não usa a B10a-50 como permissão condicionada ao frete: a presença de previsão de entrega tem regra própria, B10a-10, rejeição 1153. Na NF-e 55, o 1156 trata da finalidade; 1154 e 1155 tratam dos limites de data. Identificar qual comparação falhou evita corrigir o campo errado. [1]
Cronograma e quando pedir ajuda
Esta redação de 13/10/2026 usa a v1.52 salva na pesquisa compartilhada de 10/10. A listagem oficial capturada registra publicação em 01/10. O aviso ENCAT de 05/10 trata das atualizações enumeradas com homologação prevista para 05/out, postergadas para 26/out em homologação e 16/nov em produção. Esse calendário não demonstra ativação individual da B10a-50 ou suspensão de regras herdadas. [2][3]
O histórico da NT salva já lista B10a-50 na versão 1.30. Na linha da página 31 não há restrição própria de UF ou observação de implementação futura; isso não comprova aplicação uniforme. Nesta elaboração houve leitura local e inspeção do PNG documental existente, sem HTTP novo, render, emissão ou validação XSD. Não se recuperou uma consulta ou revisão individual antiga.
Procure o suporte se cadastro, geração e retorno divergirem; envolva o responsável fiscal quando a responsabilidade pelo transporte estiver indefinida. Apresente XML, resposta, ambiente e evidências da contratação por canal apropriado, preservando credenciais. A análise deve manter a modalidade e os demais fatos verdadeiros, sem fabricar uma data ou mudar o transporte para obter aceitação.
Fontes
Nova redação e primeira documentação de fontes por IA em 13/10/2026, a partir de material salvo. Capturas online compartilhadas são de 10/10; a releitura e a inspeção desta elaboração são locais. Atos individuais antigos de consulta ou revisão não foram recuperados. Própria e cruzada da v2 ainda não realizadas; sem aprovação ou certificação fiscal humana nesta etapa.
NT 2025.002-RTC v1.52, página 31, B10a-50/modelo 55; página 15 para dPrevEntrega; página 30 e continuação na 31 somente para distinguir as regras de data/finalidade. TXT salvo cotejado e PNG existente 31 inspecionado, sem render novo.
SVRS, documentos oficiais, corpo capturado em 10/10 e relido localmente em 13/10: publicação de 01/10 e v1.52. Não demonstra a versão mais recente em 13/10.
SVRS, aviso ENCAT de 05/10, captura compartilhada de 10/10 e releitura local em 13/10; não calendário individual da 1157.
TecnoSpeed, panorama RTC, corpo salvo da captura compartilhada de 10/10 e relido nesta elaboração: menciona o campo de previsão, como apoio adjacente. Não demonstra diagnóstico específico da 1157 ou três tutoriais independentes.
As referências CTEC e Aidera do artigo.v1 não foram recuperadas como corpos rastreáveis no material consultado. Permanecem registradas como históricas e inativas em fontes.v1.json; seus procedimentos, comparações ou menções não fundamentam esta redação. Não há afirmação de ausência universal ou resultado de pesquisa online nova.