Rejeição 637: idPedido inválido na resposta do Fisco

A rejeição 637 significa “ID do evento (idPedido) inválido” no contrato da resposta fiscal aos pedidos de prorrogação da suspensão do ICMS. O identificador questionado aponta para o pedido do contribuinte que originou essa resposta. A primeira providência é localizar qual mensagem recebeu o código, pois a correção pode pertencer ao sistema da administração tributária, não ao emissor da empresa.

A regra P19 está na seção do evento Fisco – Prorrogação ICMS da NT 2015.001 v1.30. Ela se refere à NF-e modelo 55 e não constitui rejeição geral da autorização de NF-e/NFC-e. Também não informa, por si só, que a prorrogação foi indeferida. NT, páginas 50 e 55.

Quem produz a mensagem envolvida

O contribuinte apresenta pedidos de primeiro e segundo prazo com os tipos 111500 e 111501. Quando pretende cancelá-los, utiliza 111502 e 111503, conforme o prazo envolvido.

O posicionamento fiscal é registrado por outro autor. As respostas usam 411500 e 411501 para prorrogações, e 411502 e 411503 para seus cancelamentos. A NT exige assinatura da Fazenda responsável. Portanto, a empresa não deve tentar produzir um evento 411500 para corrigir uma resposta ausente ou rejeitada. A própria especificação prevê 808 para evento do Fisco emitido por contribuinte.

Essa família também não se confunde com Visto Eletrônico do Fisco, manifestação do destinatário ou cancelamento comum da NF-e. A coincidência de termos como “evento” e “Fisco” em uma tela não torna seus contratos intercambiáveis.

O que é idPedido

No detalhe da resposta fiscal, idPedido identifica o evento anterior que está sendo respondido. O leiaute consultado estabelece 54 caracteres: a literal ID, o tpEvento do pedido ou cancelamento original, a chave da NF-e e a sequência daquele evento. O valor corresponde ao atributo Id do registro 111500, 111501, 111502 ou 111503.

Não é o identificador da própria resposta 411500–411503. Não é apenas a chave de 44 posições, o número do protocolo, o idLote ou uma referência interna do ERP. Usar qualquer um desses dados no lugar errado pode romper a ligação entre solicitação e resposta.

Por exemplo, ao responder a um pedido 111500, o sistema fiscal deve referenciar o Id daquele pedido em idPedido. O Id da nova resposta terá sua própria identificação e sequência. Dois campos com nomes parecidos cumprem funções diferentes e precisam ser armazenados separadamente.

Diferencie validade, existência e correspondência

A leitura do retorno completo evita correções que atingem o campo errado:

• 637: verifica a validade de idPedido na resposta do Fisco

• 572: verifica a formação do atributo Id do evento que está sendo enviado

• 640: no cancelamento de prorrogação, verifica idPedidoCancelado; esse número também possui significado próprio em distribuição de documentos

• 809: trata da localização do pedido ou cancelamento na base e da condição adicional relativa a pedido deferido, conforme a versão 1.30

• 810: verifica se o tipo da resposta fiscal corresponde ao tipo do pedido ou cancelamento referenciado

Assim, a 637 não é simplesmente um sinônimo de “pedido inexistente”. Um identificador precisa primeiro atender ao contrato e, em verificações próprias, corresponder ao registro e ao tipo pertinentes. NT, páginas 46, 54–55 e 58.

O que a empresa consegue conferir

1. Solicite o XML e o retorno que deram origem ao aviso. Confira se o 637 veio efetivamente da Sefaz ou se é uma tradução interna da aplicação

2. Identifique serviço, UF, ambiente, chave e tpEvento. Se a mensagem for uma resposta 411500–411503, registre que sua autoria é fiscal

3. Recupere o pedido original protocolado e seu histórico. Separe Id, tipo, sequência, protocolo e data de registro

4. Peça ao suporte que compare a referência da resposta com o pedido real, sem editar documentos já registrados. Investigue truncamento, troca de pedido, uso de protocolo no lugar de Id e associação entre ambientes

5. Encaminhe o conjunto ao responsável pela geração da mensagem. Se a origem for o sistema fiscal, a apuração deve seguir o atendimento oficial da UF, com apoio do fornecedor para explicar a integração

Preserve os arquivos completos em canal protegido. Não envie senha, certificado com chave privada ou credenciais para demonstrar a falha. Uma captura de tela pode ajudar, mas não substitui a relação entre os XMLs envolvidos.

Acompanhe a decisão, não apenas o registro

O registro do pedido do contribuinte é síncrono. Receber 128 para o lote e 135 para o evento registrado e vinculado não significa que a Fazenda já deferiu a prorrogação. O posicionamento fiscal chega posteriormente e pode depender de análise humana.

Quando a resposta válida estiver disponível, confira o pedido a que se refere e os campos que expressam deferimento ou indeferimento. Na prorrogação, a NT utiliza statPedido por item; no cancelamento, statCancPedido. A forma parcial ou completa adotada pela UF influencia o alcance da decisão, sem mudar quem é responsável por produzi-la.

A NT admite respostas fiscais posteriores para o mesmo pedido; prevalece a resposta do Fisco com maior nSeqEvento para o mesmo idPedido, e não o último arquivo que o usuário abriu. Mantenha o histórico em vez de sobrescrever a primeira resposta com um texto avulso.

Onde buscar o retorno e quando escalar

O compartilhamento por NFeDistribuicaoDFe permite ao emitente receber as respostas fiscais de interesse, dentro das regras do serviço. Isso exige conciliar a consulta e o armazenamento pelo integrador. A ausência de um arquivo na tela não comprova indeferimento, nem autoriza fazer outra solicitação com identificador inventado.

Não estenda o acesso automaticamente a transportadores ou terceiros: a matriz específica desses eventos distingue os participantes. Também não reaproveite prazos de consulta como prazos legais da suspensão. Se o vencimento se aproxima e a resposta não está regularizada, envolva o responsável fiscal e o atendimento da UF. Uma falha técnica não concede extensão automática do prazo. NT 2014.002 v1.40, página 5.

Fontes práticas e limites

Foram lidos TOTVS, histórico e resposta fiscal, FlexDocs, distribuição de DF-e e ACBr, diferenças estaduais da prorrogação. São referências contextuais, não tutoriais específicos da 637. Listas amplas de participantes e exemplos antigos não prevalecem sobre o contrato oficial. NT preservada em 09/10/2026, relida em 10/10/2026; não houve tentativa de gerar evento de autoridade fiscal.