Risco de duplicidade na emissão em municípios atendidos pelo Provedor IssDigital

Identificamos uma lacuna crítica na validação de dados durante o processo de emissão de NFSe em municípios atendidos pelo provedor IssDigital.

Cenário Técnico

O webservice do provedor IssDigital não valida a unicidade do número do DPS (Declaração de Prestação de Serviço) enviado no XML.

Isso significa que o sistema da prefeitura/provedor não impede o reprocessamento da mesma requisição. Caso o mesmo número de DPS seja enviado mais de uma vez, o provedor aceitará ambos como novos.

Essa característica expõe a integração aos seguintes riscos:

  • Envio duplicado: O envio da mesma nota, em duas requisições distintas contendo o mesmo número de DPS resultará na autorização de duas notas fiscais diferentes.
  • Falhas de comunicação (Timeouts): Caso o provedor receba a requisição mas a conexão falhe antes de retornar a resposta (timeout), uma tentativa automática de reenvio por parte da API gerará uma segunda nota fiscal, duplicando o faturamento.

Evidências

Testes confirmam que múltiplos envios com o mesmo número de DPS resultam em:

  • Números de NFSe distintos;
  • Chaves de acesso distintas.

Isso comprova que a prefeitura interpreta cada requisição como uma transação fiscal inédita, ignorando que o número do DPS já foi utilizado anteriormente.

Status da API da Focus NFe

A API da Focus NFe opera corretamente, transmitindo os dados conforme as especificações do provedor.

Como a validação de unicidade é uma responsabilidade da regra de negócio do provedor municipal (que não a executa), a nossa API não consegue impedir que a prefeitura aceite a duplicidade.

Recomendações

Devido a essa instabilidade do provedor, é imprescindível que o desenvolvedor implemente controles rígidos na aplicação cliente (seu software):

  1. Evite reenvios automáticos sem verificação prévia de status.
  2. Antes de reenviar uma nota em caso de timeout ou falta de resposta, verifique se a nota já não foi autorizada no painel da prefeitura ou via consulta.
  3. Garanta que sua aplicação trate esse provedor com regras de exceção para evitar prejuízos tributários por duplicidade.