Rejeição 506: confira a ordem entre emissão e saída da NF-e

A rejeição 506 aponta uma inversão entre a saída da mercadoria e a emissão da NF-e. A regra B10-40 do MOC verifica o campo de entrada/saída quando ele foi informado em uma NF-e de saída, identificada por tpNF=1. Se a data de saída for menor que a de emissão, o documento pode ser rejeitado por essa regra.

O caminho mais seguro é conferir os dados efetivamente transmitidos e a movimentação que deveriam representar. Uma data herdada do pedido, um preenchimento automático ou uma alteração posterior no faturamento pode deixar os campos incoerentes. Mudar a saída para um horário qualquer ou retroagir a emissão não resolve a causa e pode produzir informação falsa.

A condição que diferencia a 506

A B10-40 está no grupo de autorização da NF-e modelo 55 e tem aplicação facultativa. Seu recorte inclui expressamente tpNF=1. Portanto, não é correto afirmar que toda NF-e de entrada deve obedecer à mesma comparação apenas porque usa o campo dhSaiEnt. Entrada e saída têm naturezas diferentes; classifique o documento conforme a operação real. MOC 7, página 76.

A publicação da SEFAZ de São Paulo consultada em 10/10/2026 lista B10-40 como ativa. Isso não transforma a regra facultativa em implantação comprovada para todas as UFs. Para uma ocorrência concreta, confirme modelo, ambiente, autorizador, mensagem e o XML daquela tentativa. Regras facultativas de São Paulo.

A comparação da 506 também é diferente das rejeições 504 e 505. Estas tratam dos limites posterior e anterior em relação à autorização. Na 506, o contraponto é a emissão, representada em dhEmi. Uma nota estar dentro de 30 dias da autorização não demonstra que a ordem entre emissão e saída esteja correta.

Data no nome da mensagem, data e hora no XML

O leiaute chama dhEmi de data e hora de emissão e dhSaiEnt de data e hora de saída ou entrada. Ambos incluem indicação de fuso. A linha da B10-40 usa a palavra “data” e ainda apresenta a grafia dSaiEnt em sua comparação, embora sua condição identifique dhSaiEnt. Essa redação não é motivo para criar uma tag antiga no XML nem desprezar automaticamente as horas do arquivo atual. Leiaute do MOC, página 9.

Para o diagnóstico, leia os valores completos. Se a emissão está em 12 de outubro e a saída em 11 de outubro, no mesmo fuso, a inversão é clara. Quando ambas aparecem no mesmo dia, confira também horários, conversões e a implementação do contrato utilizado. A B10-40 não documenta uma margem de cinco minutos nem detalha nessa linha um algoritmo universal de comparação em segundos. Seu gatilho é uma data menor, não simplesmente igual; isso tampouco garante autorização por todas as outras regras.

Por exemplo, emissão às 15h e saída preenchida às 9h no mesmo dia merecem conferência, especialmente se o ERP reutilizou a hora de criação do pedido. Não transforme o exemplo em autorização para somar minutos à saída. O valor correto depende dos fatos e da forma de emissão aplicável, não da tentativa de satisfazer uma desigualdade.

Encontre quem preencheu a informação

Peça à equipe que compare três registros: a tela do documento, o XML rejeitado e a origem da data no processo comercial ou logístico. Se a tela já foi corrigida, mas o arquivo continua antigo, pode haver uma etapa de geração pendente ou outra rotina sobrescrevendo a informação.

A documentação da TOTVS Datasul explica que a data de saída pode ser produzida por atualização automática do estabelecimento ou preenchimento manual nas informações adicionais. Esse é um exemplo concreto de por que não se deve presumir erro de digitação do operador. Os programas e parâmetros citados são específicos dessa linha do produto. TOTVS Datasul, diagnóstico da 506.

A Omie mostra o campo de data/hora de saída nos detalhes do pedido e o procedimento de reenvio. A Alterdata Shop apresenta uma opção que preenche o momento atual. Esses caminhos ajudam a localizar controles, mas só devem produzir valores verdadeiros para a operação. A referência da Omie que aproxima emissão da autorização não deve substituir dhEmi como campo comparado pela B10-40. Guia Omie e guia Alterdata Shop.

Um procedimento de correção rastreável

1. Preserve o XML e o retorno rejeitados. Confirme que o código é fiscal, ligado à autorização, e não uma mensagem de outro serviço.

2. Confira tpNF, dhEmi e dhSaiEnt, além do tipo de emissão e formato do DANFE. Investigue uma classificação de operação incorreta sem trocá-la apenas para desativar a regra.

3. Compare os dados com os registros disponíveis de faturamento e expedição. Descubra se a inconsistência é cadastral, automática ou corresponde a uma situação real que exige tratamento fiscal.

4. Se houver erro comprovado, corrija a origem no emissor e gere novamente o XML. Verifique data, hora e fuso sem editar manualmente um arquivo já assinado.

5. Reenvie e acompanhe a resposta. Guarde a evidência da correção e o resultado final; salvar a tela ou desaparecer o aviso não comprova autorização.

Se a mercadoria realmente saiu antes da emissão registrada, preserve os fatos e encaminhe a situação à área fiscal. Não altere a emissão para trás, não invente nova saída e não exclua o campo como estratégia de aprovação. A opcionalidade estrutural de dhSaiEnt não decide, sozinha, o preenchimento adequado à operação.

Contingência e outros formatos

A B10-40 não contém uma exceção geral para contingência. Prazos de transmissão, autorização fora de prazo e a data de um evento de contingência são controles distintos. A observação da rejeição 505 sobre certos tipos de emissão não pode ser transportada para a 506 sem fundamento específico.

NFC-e modelo 65 possui regra própria sobre a presença de data de entrada/saída. A NT 2026.002 v1.11 documenta essa vedação também para NF-e com DANFE Simplificado Tipo 2, tpImp=6, na B10-10/705. Verifique a versão e o contrato efetivamente implantados, sem presumir abrangência operacional nacional. NT 2026.002 v1.11, cópia oficial consultada de 09/10/2026.

Uma prevenção útil é testar como o ERP preserva a saída quando o faturamento é recalculado ou um pedido antigo é retomado. A validação interna deve respeitar modelo, operação e contrato, apontando a incoerência antes do envio sem substituir automaticamente informações reais.