Rejeição 578: data do evento maior que a do processamento

A rejeição 578 ocorre quando a data e hora declaradas no evento ficam à frente do processamento, ultrapassando a tolerância do contrato aplicável. A empresa pode ter solicitado um cancelamento ou outra atualização legítima, mas o sistema apresentou esse evento como se tivesse ocorrido no futuro.

O primeiro passo é localizar o retorno individual da Sefaz e seu xMotivo. A rejeição do evento não prova cancelamento da nota, nem autoriza substituir uma NF-e já emitida. Também não basta a mensagem de que o lote foi processado: cada evento tem seu próprio resultado.

Verifique o horário certo no lugar certo

A informação enviada é dhEvento, dentro de infEvento. Ela representa a data e hora do evento. Não é ide/dhEmi, que identifica a emissão da nota, nem dhRecbto do protocolo de autorização. No retorno geral, dhRegEvento contém o registro do evento ou, se rejeitado, a data e hora de recebimento. Essa referência ajuda na investigação, respeitando o leiaute do serviço. MOC 7.0, páginas 100–103.

Exemplo: no mesmo fuso, o XML declara 10h12 e o retorno indica recebimento às 10h. Uma diferença assim exige examinar o relógio e a geração do evento. Não se deve subtrair minutos automaticamente do arquivo até que a transmissão passe. A correção precisa recuperar o horário verdadeiro e explicar a divergência.

Verifique o fuso junto com a hora: 10h em -03:00 equivale a 9h em -04:00. Um servidor pode armazenar UTC e a tela mostrar a hora local. A equipe técnica deve comparar os instantes com o deslocamento, sem retirar o fuso ou aplicá-lo duas vezes. Trocar apenas o sufixo do XML altera o instante declarado.

Há uma tolerância única para todos os casos?

Não se deve deduzi-la apenas do número 578. No MOC 7.0, P13-10 determina tolerância de até cinco minutos para a comparação entre evento e processamento. O cancelamento também a explicita. Na CC-e, a aplicação decorre da remissão às regras gerais; isso não muda a proibição de CC-e para NFC-e.

A mesma tolerância aparece nos contratos consultados de manifestação do destinatário, EPEC NF-e, EPEC NFC-e, ator interessado, comprovante de entrega, insucesso na entrega e ECONF. Na prorrogação de industrialização, as tabelas do pedido, cancelamento e resposta fiscal também a registram. Trata-se de margem de sincronismo desses contratos, não de autorização para informar um evento fictício ou prolongar o prazo legal de apresentação.

Na prática, identifique a família antes de agir:

• Cancelamento normal e por substituição: valide qual operação foi pedida, o modelo e o prazo próprio. A especificação original 110112 é de substituição de NFC-e; não converta um cancelamento comum nessa modalidade para escapar da rejeição

• Manifestação: confira o tipo de manifestação, o ambiente nacional e as restrições de modelo/tipo de emissão. A NT 2020.001 v1.60 mantém P13-10, sem dispensar as demais regras

• EPEC: a NF-e segue a NT 2014.001 v1.41; a especificação da NFC-e é a NT 2014.003 v1.02. O evento prévio não exige inventar uma autorização anterior; disponibilidade estadual e posterior conciliação precisam ser verificadas

• Entrega e insucesso: os contratos são de NF-e 55. No ator interessado, a versão 1.40 risca a antiga restrição a 55 e mantém verificação de chave 55/65; confira as condições do serviço, sem recolocar a limitação excluída

• ECONF: tanto a conciliação 110750 quanto seu cancelamento 110751 contêm P13-10 e contemplam 55/65. Data de pagamento e data do evento continuam sendo informações distintas

• Visto Eletrônico do Fisco: o BT 2018.002 prevê cinco minutos no visto e no cancelamento do visto. A correção de um evento de órgão deve ser encaminhada ao responsável por sua geração, não reproduzida pela empresa como se fosse sua autora

Nos eventos processados por PAA, dhEvento continua no leiaute: confirme qual componente o preenche. A NT 2026.001 v1.02b não cria uma nova tolerância de data e restringe o modelo 65 na série PAA. Eventos RTC da NT 2025.002 v1.52 remetem à parte geral; a equipe deve aplicar a versão e o evento efetivamente suportados.

A vinculação de pagamento 110300, NT 2026.006, também remete às regras gerais. Contudo, os PDFs oficiais preservados divergem no cronograma: um prevê homologação/produção em 03/08 e 05/10/2026; outro, em 05/10 e 03/11/2026. Ambas tratam o split payment como preparatório em 2026, com ativação prevista para 2027, e esclarecem que a vinculação não substitui o ECONF. Essa documentação não comprova operação universal em outubro. Confirme o ambiente, sem usar uma data prevista como prova de disponibilidade.

Procedimento seguro para a empresa

1. Preserve o XML transmitido, o retorno, a chave, tpEvento, nSeqEvento e os horários dos registros locais. Confira se todos pertencem à mesma tentativa e ao mesmo ambiente

2. Identifique quem escreveu dhEvento: ERP, integração, servidor de aplicação ou banco de dados. Um relógio correto no computador do usuário não garante que o servidor esteja correto

3. Compare hora e fuso do XML com a referência do retorno. Corrija sincronização e configuração verdadeira do ambiente, sob responsabilidade do suporte. Valide novamente o XML gerado, não apenas a tela

4. Confirme que a ação continua cabível e dentro das regras específicas. Só então regenere a solicitação rejeitada com dados reais e assinatura válida

5. Consulte ou reconcilie tentativas sem resposta antes de repetir o envio. Não avance a sequência para disfarçar duplicidade. Confirme o resultado individual e guarde o protocolo final

Não altere o XML autorizado da nota nem retroaja o evento. As instruções históricas de horário de verão nas fontes práticas não são orientações de configuração para 2026.

Datas de fatos e outros códigos

dhEntrega, dhTentativaEntrega e dPag não são substitutos de dhEvento: registram entrega, tentativa e pagamento. As regras correspondentes podem apontar outros códigos, como 821–824 ou 657. A rejeição 577 compara evento com emissão; a 579, em seus contratos, compara com autorização. A tolerância da 578 não deve ser transportada para essas situações. Corrigir uma comparação não elimina automaticamente todas as demais.

Referências específicas: ECONF v1.00, ator interessado v1.40 e NT 2026.006, cópia nacional.

Fontes práticas e limites

Foram efetivamente lidos TecnoSpeed, 578, TOTVS Datasul, origem dos horários e Invoisys, preenchimento de dhEvento. São referências operacionais contextualizadas. Não adote o atraso fixo sugerido pela Invoisys nem a recomendação TOTVS de deixar relógios menores que o da Sefaz: sincronize o horário verdadeiro. A grafia “dvEvento” e o exemplo de diferença exata de cinco minutos da Invoisys não definem campo ou tolerância normativa. PDFs oficiais preservados em 09/10/2026, relidos em 10/10/2026; não houve teste de transmissão nem certificação de implantação em todas as UFs.