Reemissão e rastreio

Quando a prefeitura recusa uma nota, há dois caminhos para emitir a versão corrigida:

1. Pela API: reenvie o JSON corrigido com o mesmo idIntegracao (POST /nfse). Se a nota anterior comprovadamente não foi aceita, nasce uma nota nova ligada a ela (meta.reemissaoDeId). Detalhes em Emitir NFS-e.
2. Pelo portal: tela Corrigir e reemitir da nota, descrita abaixo.

Nos dois casos a nota recusada continua no histórico, ligada à nova, e a nova recebe novo número de RPS no mesmo ambiente da original.

Corrigir e reemitir (portal)

Rotas do portal do cliente (sessão do portal, não API key). Valem para os perfis que agem na nota (owner, admin, developer); o perfil somente consulta e a sessão "ver como o cliente" do suporte não reemitem.

Método	Rota	O que faz
GET	/portal/nfse/{id}/rascunho-reemissao	JSON base para edição (payload) e o que a prefeitura recusou (errosOriginais).
POST	/portal/nfse/{id}/validar-reemissao	Body { "payload": {...} }. Roda todas as validações da emissão sem emitir (200).
POST	/portal/nfse/{id}/reemitir	Body { "payload": {...} }. Emite pelo fluxo normal (202); devolve novaNfseId e reemissaoDeId.

• Nota fora do escopo do usuário (outra conta ou empresa não vinculada) → 404.
• Nota que pode ter sido autorizada sem resposta (sem prova de recusa) não é reemitida pelo portal (409): confira no portal da prefeitura e fale com o suporte.
• Credenciais e campos sensíveis da nota original ficam guardados mascarados (***). A tela avisa quais são e só libera reemitir depois que você preencher de novo: o *** nunca deve ir para a prefeitura.
• Se o idIntegracao já estiver em uso por uma nota aceita, a reemissão é recusada e a resposta aponta a nota existente.

Reemissão pelo suporte (admin)

O suporte da Notare usa o mesmo fluxo em nome do cliente, com as mesmas regras de validação, idempotência e registro:

Método	Rota	Quem
GET	/admin/nfse/{id}/rascunho-reemissao	suporte, operador, superadmin
POST	/admin/nfse/{id}/validar-reemissao	suporte, operador, superadmin
POST	/admin/nfse/{id}/reemitir	operador, superadmin

O reemitir do admin exige motivo (mínimo de 10 caracteres), que vai para o histórico da nota original. Toda leitura do payload e toda reemissão ficam na auditoria interna.

Tentativas recusadas antes do envio

Quando a API recusa uma emissão antes de criar a nota (JSON inválido, empresa não cadastrada, regra do município…), não existe id de NFS-e. Mesmo assim a tentativa fica registrada por 90 dias, com o JSON enviado (credenciais mascaradas) e os erros:

• Portal → Tentativas recusadas (GET /portal/tentativas-rejeitadas, filtros de, ate, idIntegracao, empresaId, ambiente);
• detalhe em GET /portal/tentativas-rejeitadas/{id}.

Se a sua nota "não aparece na lista", procure aqui pelo idIntegracao.

Rastrear uma chamada: x-request-id

Toda resposta traz o header x-request-id, e todo corpo de erro traz o mesmo valor em requestId:

HTTP/1.1 400 Bad Request
x-request-id: erp-pedido-30046339-a1

{ "status": "rejeitada_schema_dps", "codigo": "SCHEMA_DPS_INVALIDO", "erros": [ ... ], "requestId": "erp-pedido-30046339-a1" }

• Mande o seu próprio id (8 a 64 caracteres de A-Z a-z 0-9 _ -) para casar com o log do seu ERP; valor fora do formato é substituído por um gerado.
• O id fica gravado na nota e na tentativa recusada: informe-o ao suporte e a chamada é localizada mesmo sem número de nota.