Rejeição 577: data do evento anterior à emissão da nota

A rejeição 577 indica uma incoerência cronológica: a data do evento ficou anterior à emissão da NF-e ou NFC-e vinculada, conforme o serviço utilizado. Para a empresa, o efeito imediato é a recusa daquele evento. O retorno não significa, por si só, que a nota anteriormente autorizada foi cancelada ou perdeu validade.

Antes de alterar qualquer configuração, identifique o evento rejeitado, a chave, o modelo, o ambiente e a mensagem completa. Cancelamento, manifestação do destinatário e EPEC têm finalidades e regras próprias. Um número exibido pelo ERP, desacompanhado do retorno da Sefaz, é insuficiente para decidir o procedimento.

Quais datas comparar

No XML do evento, dhEvento representa sua data e hora. No XML da nota, ide/dhEmi identifica a emissão. Já dhRecbto, no protocolo de autorização, pertence a outra etapa. No retorno do evento, dhRegEvento informa seu registro ou, quando rejeitado, o recebimento conforme o leiaute. Esses campos não são intercambiáveis.

Imagine uma nota emitida às 14h e um pedido de cancelamento gerado com dhEvento às 13h50, no mesmo dia e fuso. A sequência é incompatível com a comparação da rejeição 577. A investigação deve mostrar de onde vieram os dez minutos: relógio incorreto, conversão de horário, informação antiga reaproveitada ou vínculo com outra nota. Simplesmente trocar a data para um valor aceito esconde a origem do problema.

Compare instantes completos, incluindo o deslocamento de fuso. Por exemplo, 10h com -03:00 e 9h com -04:00 representam o mesmo instante. Remover o deslocamento ou comparar apenas os números do relógio pode produzir um diagnóstico falso. Confira o XML efetivamente transmitido, pois a tela e o banco de dados podem exibir horários convertidos.

Onde a regra aparece e quais limites preservar

No MOC 7.0, o cancelamento traz a comparação 2P13-10 entre evento e emissão. Ela é diferente de 2P13-14, associada ao código 579, que compara o evento com a autorização da nota emitida normalmente. A tolerância de cinco minutos descrita para essa segunda comparação não deve ser transferida para a 577. Também não se confunde com o prazo legal para cancelar. MOC 7.0, páginas 100–107.

Os demais contratos precisam ser identificados:

• Cancelamento por substituição: a NT 2018.004 documenta o evento 110112 para NFC-e e a comparação com a emissão. Isso não permite usar esse procedimento em qualquer nota ou substituir o cancelamento normal indiscriminadamente

• Manifestação do destinatário: a NT 2020.001 v1.60 mantém 2P13-10. O evento escolhido, o modelo e o tipo de emissão continuam sujeitos às demais validações; a tabela genérica de datas não concede disponibilidade universal

• EPEC: na NF-e, a NT 2014.001 v1.41 usa P23-30; na especificação NFC-e da NT 2014.003 v1.02, P23-20. A comparação envolve dhEmi informado no detalhe e dhEvento. Não se pressupõe uma autorização anterior, pois o evento é prévio à autorização da nota; tampouco se presume que EPEC NFC-e esteja disponível em toda UF

• Entrega, insucesso, ator interessado e ECONF: as respectivas NTs contêm 2P13-10. A conciliação financeira admite 55/65; entrega e insucesso são de NF-e 55. No ator interessado, a restrição antiga a 55 foi riscada, mantendo-se verificação 55/65; a nota (*1) da regra 577 limita essa checagem a tpAutor=1, empresa emitente

• Prorrogação de industrialização: a NT 2015.001 v1.30 diferencia pedido, cancelamento do pedido e resposta do Fisco. Além da emissão, existem comparações próprias com eventos anteriores, associadas a outro código, 641

• Visto Eletrônico do Fisco: o BT 2018.002 prevê 577 no evento do órgão. Seu cancelamento tem comparação própria com a data do evento cancelado, código 406. A empresa não pode assumir o papel do Fisco para corrigir o registro

A CC-e merece cuidado documental: fontes práticas associam a 577 a esse evento, e o MOC 6.0 traz a regra histórica G11. No MOC 7.0 consultado, a seção da CC-e remete às regras gerais sem repetir essa comparação. Se o retorno real trouxer 577, investigue a cronologia e peça ao fornecedor a identificação da regra aplicada. Isso não autoriza corrigir a emissão da nota por CC-e; NFC-e não admite CC-e.

PAA preserva dhEvento e acrescenta regras próprias de assinatura e autorização; não cria uma data alternativa. Sua especificação v1.02b impede modelo 65 na série PAA. Eventos RTC e vinculação de pagamento remetem à parte geral do MOC, mas essa remissão isolada não comprova 577 em todos eles. A NT 2026.006 tem cronogramas oficiais conflitantes: confirme a implantação do serviço antes de tratar seu evento como disponível.

Como corrigir com segurança

1. Guarde os XMLs enviados e recebidos, a chave, tpEvento, nSeqEvento, UF e ambiente. Verifique que o cStat 577 pertence ao evento, e não apenas a uma descrição interna do sistema

2. Recupere o documento correto e compare a emissão com dhEvento. Em EPEC, confira os dados efetivamente declarados no próprio evento, preservando a consistência com a nota correspondente

3. Peça ao suporte que localize a origem de dhEvento: ERP, integrador, servidor ou banco. Corrija relógio, sincronização ou conversão quando houver erro demonstrado, usando o fuso verdadeiro do instante

4. Regenere somente a solicitação rejeitada, com dados verdadeiros e assinatura válida, se ela ainda for cabível. Não edite o XML autorizado da nota nem invente uma data para contornar o retorno

5. Antes de retransmitir, reconcilie eventuais tentativas anteriores para evitar duplicidade. Depois, leia o resultado individual e arquive o protocolo correspondente; lote processado não significa evento aceito

Em entrega, dhEntrega; em insucesso, dhTentativaEntrega; e no ECONF, dPag descrevem fatos próprios. Copiar esses campos para dhEvento pode criar uma nova inconsistência. Se o erro estiver realmente na emissão de uma nota autorizada, encaminhe o caso ao responsável fiscal para definir o procedimento permitido, preservando o documento original.

Referências específicas: manifestação v1.60, ECONF v1.00 e ator interessado v1.40.

Fontes práticas e alcance da orientação

Foram lidos três editores independentes: TecnoSpeed, 577, TOTVS Logix, comparação dos XMLs e NDD, diagnóstico e relógio do servidor. Servem como apoio operacional, sem transformar exemplos de produto em leiaute oficial ou comprovação de todos os contratos. Base oficial preservada em 09/10/2026, relida em 10/10/2026; a disponibilidade efetiva depende do serviço e autorizador.