NFSe emitidas em duplicidade

Documentos Fiscais
1

Prezados,

Vou relatar um incidente ocorrido na madrugada do dia 10/09/2023 que requer nossa atenção.
Durante esse período, tivemos a emissão de notas de serviço ocorrendo três vezes consecutivas. No entanto, a API, respondia apenas com erro [Internal Server Error]. Nosso sistema interpretou essa resposta como um sinal de que a API estava indisponível e, consequentemente, manteve as notas na fila para posterior tentativa de autorização.

A questão crítica aqui é que, apesar do erro na API, as notas acabaram sendo emitidas com sucesso na prefeitura de São Bernardo 3 vezes cada. Surpreendentemente, não recebemos o ID da NFSe (Nota Fiscal de Serviços Eletrônica) correspondente a essas transações. Este incidente é de extrema gravidade, uma vez que, sem a intervenção de um de nossos clientes alertando-nos sobre a situação, estaríamos em risco de incorrer em prejuízos significativos devido a impostos a serem pagos.

O problema central reside no fato de que não fomos notificados de que as notas fiscais foram emitidas, apesar do erro na API, o que nos impediu de obter as chaves necessárias para consultar o status das NFSe.

Segue o que recebemos de log no dia:

ERRO: NFS-e ID 18320 Enviar RPS: Internal server error: bG0X-AMmz3WyTA90hG4WQQ
ERRO: NFS-e ID 18323 Enviar RPS: Internal server error: Rdqr0rnREiTPwxsv4MZ1Vw
ERRO: NFS-e ID 18342 Enviar RPS: Internal server error: VNPEbRh7FKbXDJsZ5nT5pA
ERRO: NFS-e ID 18285 Enviar RPS: Internal server error: jyS7QcNTRTieLnR0jaOOVA
ERRO: NFS-e ID 18304 Enviar RPS: Internal server error: iCiDgmzg5qp3bX2KSrIfMA
ERRO: NFS-e ID 18310 Enviar RPS: Internal server error: DKZ9FQsx4BygX4RqSm-ARA
ERRO: NFS-e ID 18320 Enviar RPS: Internal server error: GMCqjuWS4IICDZu5PyTQsA
ERRO: NFS-e ID 18323 Enviar RPS: Internal server error: gDFjU01kxzX9YoyOe7HoHw
ERRO: NFS-e ID 18342 Enviar RPS: Internal server error: u82NiV0AU84nWoX9MWXTMg
ERRO: NFS-e ID 18285 Enviar RPS: Internal server error: 5ppgfR2wb45WqA0c6cxv-Q
ERRO: NFS-e ID 18304 Enviar RPS: Internal server error: vB6BSfvU4VniaqbgiI9BDA
ERRO: NFS-e ID 18310 Enviar RPS: Internal server error: ZkJqutZXjkGbcK-jGDlxXA
ERRO: NFS-e ID 18320 Enviar RPS: Internal server error: -NEvjlGwT0SMcjkLrlOmHQ
ERRO: NFS-e ID 18323 Enviar RPS: Internal server error: tUoq0isPMB8weMNXhvPkbg
ERRO: NFS-e ID 18342 Enviar RPS: Internal server error: dhhIdIeLuQ9rqnUglcxG4w
ERRO: NFS-e ID 18285 Enviar RPS: Internal server error: H60JQ_c4a9kaB98E2ExR2g
ERRO: NFS-e ID 18304 Enviar RPS: Internal server error: k6c31SocqB8NMqLXXQerDg
ERRO: NFS-e ID 18310 Enviar RPS: Internal server error: bySgAKLq4YTZLS8rpi18AA

2

Olá Evandro,

Primeiramente, sinto muito pelo problemas que aconteceram e com os quais você está precisando lidar.

Segundo, obrigado pelos reports dos erros internos. Informamos que o problema que causou esses erros foi corrigido e esse tipo específico de erro não vai mais acontecer.

Terceiro, gostaria de esclarecer melhor o significado desses erros com “Internal server error”. Antes, é claro que o servidor pode ter problemas imprevistos.

Tudo pode acontecer: o servidor cair, a estrutura cloud que usamos também cair (no caso, usamos a AWS, uma das mais confiáveis do mundo, mas ela também está sujeito a isso), ou qualquer outro problema.

Porém, em muitos desses casos poderá vir uma mensagem de erro clara, e nem sempre isso é um “Internal server error”. Um “internal server error” é um erro cuja mensagem não é propagada ao cliente por questões de segurança. Tanto que, como você viu, há somente um código, que apenas a equipe da Nuvem consegue rastrear.

Também é um erro que jamais deve acontecer. Assim, se acontecer um internal server error, a recomendação é que você não pressuponha que algo aconteceu - ou não aconteceu… Ou seja, não assuma que a nota foi emitida, ou que não foi. Sim, o erro pode ser temporário, mas pode ser outra coisa. Entre em contato com nosso suporte e informe o código, se você precisa tomar uma decisão crítica quanto a isso.

Finalmente, uma humilde sugestão para tratar isso do seu lado e minimizar esse tipo de problema (que, ressalto, é raro, mas infelizmente aconteceu no seu caso): sempre envie uma referência sua ao emitir uma nota. Essa referência (preenchida no campo referencia do JSON) é inequivocamente associada a essa nota, e assim você sempre pode consultar o seu status, mesmo que o servidor da Nuvem não tenha enviado uma resposta.

Note que isso pode acontecer do seu lado também: você pode enviar uma nota para emissão na Nuvem Fiscal, ela ser processada, emitida, e no momento que a Nuvem estiver enviando a você a resposta da sua requisição, sua conexão cai exatamente nesse momento. O efeito é o mesmo desse internal server error: tudo ocorreu 100% correto do lado da Nuvem, a nota foi emitida, mas você não conseguiu receber a resposta por uma falha na sua rede.

Também é raro, mas é mais um exemplo de que pode acontecer, e mais um exemplo de que pra realmente minimizar esse problema, você precisa sempre conferir o que aconteceu com a sua requisição - caso não tenha recebido uma resposta - antes de fazer uma nova tentativa ou não.

Como sempre, estamos à disposição para esclarecer eventuais dúvidas.

3

Olá Wagner
Que bom que o problema foi resolvido. Entendo que erros podem acontecer e que sistemas são constantemente aperfeiçoados. Por isso, vou pontuar minhas considerações sobre sua resposta.

Sobre esse erro que não é propagado para o cliente final, precisaria ser melhor documentado na API para que possamos entender a gravidade e tratá-lo adequadamente do nosso lado. O que não considero certo é que, mesmo com erro, a API seguiu com a autorização da nota na prefeitura. Isso é a pior falha que pode acontecer, seguir com emissões sem que o sistema do nosso lado tenha qualquer retorno positivo. Sugiro que, na dúvida, não envie a nota para autorização e, se já estiver autorizada, envie o cancelamento. É melhor cancelar a nota do que mantê-la em duplicidade.

Como a Nuvem Fiscal ainda não tem um webhook para devolver o status da requisição, deveria considerar uma autorização de nota válida somente se houve com sucesso a consulta do status do nosso lado; caso contrário, cancelar a nota. O que de pior pode acontecer é ter notas duplicadas.

Sobre a sua sugestão de enviar nossa referência no JSON, já fazemos isso. Mas há um problema na API que, caso a nota seja rejeitada e corrigida para uma segunda tentativa de autorização na prefeitura, a Nuvem Fiscal não permite. Eu preciso trocar a referência para conseguir reenviar para autorização. Rejeições são normais; a prefeitura pode rejeitar, por exemplo, “valor retido inválido”, o cliente corrige e reenvia. Ainda é a mesma nota, não uma duplicata. E não há um endpoint para consulta de status pela minha referência, apenas pelo ID único da NFS-e gerado pela Nuvem Fiscal.

No caso das notas emitidas 3 vezes, não recebemos o ID único da NFS-e gerado pela Nuvem Fiscal. Não havia como realizar a consulta de status.

Outro ponto da sua resposta é “a recomendação é que você não pressuponha que algo aconteceu - ou não aconteceu”. Eu não tenho como explicar isso para o meu cliente, que o processo de autorização de suas notas é como jogar uma moeda para cima. Entendo que pode haver erro e situações adversas, mas não posso aceitar a incerteza como normal. Isso faz com que eu perca a confiança na API.

4

Olá Evandro,

Isso não é tecnicamente possível. Como eu mencionei no meu post anterior, é impossível que a Nuvem tenha certeza que você recebeu o “retorno positivo”, pois um problema pode acontecer em qualquer ponto da comunicação - inclusive do seu lado.

É o client que deve, na dúvida, verificar se a nota foi realmente emitida ou não - a nota ou qualquer outro processo de qualquer API, aqui não estamos mais falando nem da Nuvem Fiscal, mas de qualquer API, e de comunicação HTTP em geral.

A sugestão de web hooks é muito boa e está na nossa programação. Porém, de novo: mesmo o web hook não impede esse problema. Pode também haver problema de comunicação no web hook - a nota pode ter sido emitida, o web hook enviado, e você não receber.

Sim, o pior é ter notas duplicadas, e por isso você jamais deve tentar emitir uma segunda nota sem saber se o pedido anterior foi emitido ou recusado. Esse é o processo que você deve implementar.

Nesse caso específico, estou à disposição para discutir e esclarecer quaisquer dúvidas mais técnicas e de baixo nível que você tenha.

Isso era um comportamento projetado da API, para garantir unicidade em todas as requisições. Não era um problema, e não iria causar um problema nesse caso específico, pois a nota foi efetivamente emitida.

De qualquer forma, nós melhoramos esse ponto, e agora caso uma nota tenha sido rejeitada, você pode reutilizar a mesma referência para uma nova tentativa de emissão.

Sim, há, é o ListarNfse (para o caso de notas de serviço):

image
image1154×180 10 KB

Basta enviar o valor nesse parâmetro e a Nuvem irá retornar a nota correspondente a essa referência, e o seu status atual.

Você faria isso usando a referência conforme mencionado acima.
E, novamente: você também não receberia esses IDs se houvesse, por exemplo, um problema na sua conexão à internet. Como você resolveria esse caso?

Isso não é verdade. Por favor, releia acima o que expliquei, e caso tenha dúvidas específicas e técnicas quanto à comunicação e o fluxograma, é só perguntar.