Rejeição 579: confira a data do evento e a autorização da nota

A rejeição 579 indica que a data e a hora informadas no evento ficaram anteriores à autorização da nota, segundo a comparação prevista para aquele serviço. O primeiro cuidado é identificar qual evento foi enviado. A condição de emissão normal e a tolerância de horário aparecem em vários contratos, mas não podem ser aplicadas indistintamente a todos.

Para a empresa, o efeito imediato é a recusa daquele evento. A mensagem, sozinha, não informa que a NF-e perdeu a autorização nem autoriza alterar o documento fiscal. Em cancelamentos, manifestações ou registros logísticos, o trabalho começa pela conferência da sequência real dos fatos e dos horários enviados pelo sistema.

Recupere a resposta que realmente falhou

Peça ao responsável pelo emissor o retorno completo, com chave de acesso, modelo, ambiente, órgão receptor, tipo do evento, versão e sequência. Confira o código e a descrição dentro do resultado individual do evento. Um lote com cStat 128 foi processado; seus eventos ainda podem ter sido rejeitados.

Reúna três referências separadas: emissão da nota, autorização da nota e data/hora do evento. A 579 compara o evento com a autorização. A 577 compara com a emissão; a 578 verifica se o evento ficou à frente do processamento. Já a 580 trata da exigência de uma nota autorizada. Trocar esses diagnósticos leva a correções que não resolvem o retorno recebido.

Em quais eventos a regra foi documentada

A leitura dos contratos oficiais permite separar estes cenários:

• Cancelamento normal, evento 110111, para NF-e 55 e NFC-e 65; cancelamento por substituição, 110112, no alcance documentado para NFC-e 65. A NT 2018.004 v1.00 e o MOC 7.0 trazem a regra 2P13-14. Isso não libera a substituição para o modelo 55

• Manifestação do destinatário, eventos 210200, 210210, 210220 e 210240: a NT 2020.001 v1.60 inclui 2P13-14 no serviço destinado à NF-e 55. A menção genérica a 55/65 em uma validação da chave não comprova extensão da manifestação à NFC-e

• Comprovante de entrega, 110130, e seu cancelamento, 110131, na NT 2021.001 v1.01; insucesso na entrega, 110192, e seu cancelamento, 110193, na NT 2023.005 v1.02. Esses contratos são de NF-e 55 e verificam 2P13-14

• Ator interessado, 110150: a NT 2020.007 v1.40 mantém 2P13-14. Sua validação restrita ao modelo 55 está rasurada e a regra substituta admite 55/65. Esse alcance documental exige conferir o atendimento efetivo do serviço

• Conciliação financeira, ECONF 110750, e cancelamento 110751: a NT 2024.002 v1.00 traz 2P13-14 para 55/65. Para NF-e, o encaminhamento previsto é SVRS; para NFC-e, a NT distingue UFs atendidas pela SVRS das que possuem autorizador próprio

Nesses contratos, a comparação está condicionada à nota não emitida em contingência, identificada por tpEmis=1, e há tolerância específica de cinco minutos por sincronismo. Essa margem técnica não permite inventar a hora do evento ou mudar a modalidade de emissão.

Prorrogação e visto fiscal têm particularidades

Na NT 2015.001 v1.30, a regra P12 associada à 579 aparece nos pedidos de prorrogação 111500/111501, nos cancelamentos 111502/111503 e nas respostas do Fisco 411500 a 411503. O texto condiciona a comparação à existência da NF-e e à emissão fora de contingência. São operações do modelo 55.

Nessas linhas, a 579 não recebe tolerância expressa de cinco minutos. A tolerância escrita perto dela pertence à 578. Também existe uma comparação com a autorização de evento anterior, identificada pela 641, que não deve ser confundida com a autorização da nota.

A versão consultada informa adoção por São Paulo e Minas Gerais; a implementação completa introduzida na v1.30 tem cronograma somente para MG. Receber um pedido de prorrogação não equivale a deferi-lo: a decisão do Fisco segue processo próprio e regras estaduais.

Há ainda o Visto Eletrônico do Fisco, evento 400300, modelo 55. O BT 2018.002 v1.00 apresenta a 579 na regra 1P13-14 sem ressalva expressa de contingência ou tolerância. A geração é institucional, pelo Fisco. Seu cancelamento 400301 tem validações próprias, sem transposição automática dessa regra.

Como conferir o horário sem distorcer os fatos

Imagine uma nota autorizada às 14h20 e um evento enviado com 13h55, no mesmo fuso. A diferença exige investigação. Pode ter sido usado um horário antigo, o relógio de algum componente pode estar incorreto ou o sistema pode ter interpretado o fuso de maneira errada. O retorno não permite escolher uma dessas causas sem examinar os dados.

1. Compare o evento transmitido com o protocolo de autorização da mesma chave e do mesmo ambiente

2. Confira data, segundos e indicação de fuso. Dois horários escritos de forma diferente podem representar o mesmo instante

3. Peça ao suporte para verificar os relógios e a configuração de horário do emissor, servidor e integrações que participaram do envio

4. Confirme qual instante o sistema deveria registrar conforme o evento e os documentos da operação

5. Corrija uma configuração comprovadamente errada pelo procedimento suportado do emissor. Preserve os arquivos e registros originais

6. Antes de nova transmissão, confira se houve algum registro efetivo do evento e se o prazo legal continua atendido

7. Depois, valide o resultado individual e guarde o protocolo pertinente

Aguardar alguns minutos e reenviar um arquivo que continua com o mesmo horário incorreto pode repetir a rejeição. Corrigir o relógio também não altera automaticamente um evento já preparado. O suporte precisa verificar o que será efetivamente transmitido, sem editar manualmente um XML assinado.

Limites que evitam uma correção indevida

Não emita outra nota, troque a chave ou ajuste artificialmente a data para fazer o evento passar. Se os registros mostram que a ação ocorreu antes da condição exigida, encaminhe o caso ao responsável fiscal. Uma nova tentativa precisa representar a operação verdadeira e respeitar as regras do evento.

Guias práticos frequentemente citam carta de correção para explicar a 579. Há previsão em manuais antigos, mas o contrato de CC-e do MOC 7.0 não mantém essa regra nas validações examinadas. Um caso assim pede identificação da versão e do retorno, em vez de assumir vigência pela orientação genérica.

ECONF também não se confunde com a vinculação de pagamento 110300 da NT 2026.006. Esta não atribui automaticamente 579 ao novo evento e possui cronogramas divergentes entre cópias oficiais, além da ressalva preparatória para 2027. Nenhuma dessas datas comprova ativação universal.

Base consultada e limites

Cópias oficiais preservadas, consultadas em 10 de outubro de 2026, sem ensaio de produção por UF: MOC 7.0, NT 2015.001 v1.30, NT 2020.001 v1.60, NT 2020.007 v1.40, ECONF e demais contratos identificados no texto.

Foram lidos três editores práticos: TecnoSpeed, Alterdata e CTEC. Serviram para contextualizar conferência cronológica, configuração local/nuvem e acionamento do suporte. As recomendações genéricas de horário de verão, geração de nota e aplicação a qualquer evento não foram adotadas.