Pular para o conteúdo
Fiscal ProBiblioteca
Rejeição 878 · Regra ZX03-20

Rejeição 878: URL de consulta por chave da NFC-e — ZX03-20

Revisão editorial em 16 de out. de 2026. Confira as versões e condições das regras nas fontes do artigo.

A Rejeição 878, regra ZX03-20, verifica o endereço de consulta por chave de acesso informado na NFC-e, modelo 65. O alvo é infNFeSupl/urlChave, na estrutura suplementar do XML da nota. Embora esta página esteja no agrupamento de eventos do catálogo, a regra documentada não valida um pedido de evento nem o endereço de recepção de eventos.

Três endereços que não devem ser confundidos

Informação Função
infNFeSupl/urlChave Endereço de consulta pública por chave de acesso da UF. É o alvo da ZX03-20.
infNFeSupl/qrCode URL e conteúdo da consulta por QR-Code, com composição própria.
Endereço do serviço autorizador ou de eventos Destino técnico da comunicação entre emissor e SEFAZ. Não substitui a URL pública de consulta.

O MOC 7.0, Anexo I, p. 133 descreve a divergência entre o endereço de consulta por chave da UF e o previsto. A aplicação é facultativa por UF, com vigência indicada a partir de 01/04/2019. Essa data é da validação; não significa que todo endereço publicado em 2019 continue atual.

O Manual DANFE NFC-e e QR-Code 6.0 trata a consulta por chave e a consulta por QR-Code como jornadas distintas. Atualizar a versão do QR-Code não determina automaticamente a URL de urlChave.

Como conferir o endereço correto

A fonte da regra remete à relação de consultas públicas das UFs no portal da NFC-e. Compare o endereço previsto para a UF e para o ambiente pertinente com o texto efetivamente serializado em urlChave. Preserve domínio, caminho e demais componentes conforme a publicação oficial; não monte um endereço por analogia com outra UF.

Para localizar a publicação, entre no portal oficial da SEFAZ da UF do documento, abra a área NFC-e e procure a relação de consultas públicas ou WebServices. Selecione o ambiente real e a consulta por chave de acesso. Não use automaticamente o endereço de autorização, de eventos ou do QR-Code.

Como exemplo limitado a São Paulo, a página SEFAZ-SP — NFC-e — WebServices separa homologação e produção. Em cada ambiente, distingue o item 2. URL QR Code do item 3. URL Consulta Pública ou Consulta Pública. Essa separação ajuda a localizar a finalidade correta do endereço; não estabelece uma URL para outra UF. Se houver mais de um endereço publicado ou divergência com o retorno, preserve a publicação e confirme com a SEFAZ qual endereço é esperado no contexto do documento.

Um link abrir no navegador não prova que corresponda à URL prevista pelo autorizador. Pode haver redirecionamento, endereço antigo ainda acessível ou uma página inicial que não é o serviço esperado. Se a fonte e o retorno divergirem, registre ambos e peça esclarecimento sobre a configuração vigente, sem supor que qualquer URL funcional seja aceita.

Exemplo: empresa trocada, configuração antiga mantida

Um emissor passou a gerar NFC-e de uma empresa em outra UF, mas conservou a URL pública da configuração anterior. O XML contém modelo 65 e dados da empresa correta, enquanto urlChave aponta para a consulta da UF antiga. A comparação entre a UF real do documento, a configuração carregada e o XML permite localizar o vazamento de configuração. A correção é atualizar a seleção da URL da empresa e do ambiente corretos, depois de confirmada a fonte oficial; não mudar a UF do documento para combinar com o link.

Outro cenário é trocar em urlChave a URL da consulta por aquela usada no QR-Code ou no serviço de autorização. Os três endereços podem ser oficiais e ainda assim cumprir funções diferentes. Identificar o campo alvo evita corrigir o canal técnico errado.

O exemplo é textual porque a URL concreta depende da UF e do ambiente da operação. Não se inventa endpoint, chave ou XML para transmissão; um link sintético não provaria a configuração prevista.

Ausência de URL e divergência não são o mesmo teste

A ZX03-20 descreve divergência do endereço. A história da NT 2016.002 v1.61, pp. 4 e 73 registra a retirada de ZX03-10, antiga regra de ausência, e a reinclusão de ZX03-20, que havia sido excluída indevidamente na versão 1.60. Não conclua que a remoção de uma verificação de ausência libera um endereço incorreto ou elimina requisitos estruturais do leiaute.

Preserve XML enviado, retorno, ambiente, horário e versão do emissor. Confirme que 878 corresponde a ZX03-20 e localize urlChave no mesmo documento. Corrija a configuração comprovadamente incorreta na origem e confira o novo XML antes de qualquer transmissão autorizada. Não edite documento assinado ou autorizado e esclareça uma tentativa de resultado incerto antes de novo envio.