Estamos fazendo as atualizações na nossa API para replicar as mudanças na Nuvem e finalmente conseguimos fazer a migração da NFS-e para a nova rota /dps, porém estamos tendo como retorno a mensagem:
A1 - Item da lista de serviço, código CNAE ou código de tributação informado para a operação não está cadastrado para o prestador de serviço
Acredito que possa ser algo do nosso lado aqui, porém não consegui localizar o erro, estamos enviando a princípio os mesmos códigos que usávamos na rota antiga, mas não conseguimos fazer com que a nota seja autorizada.
Vocês sabem o que pode ser?
Exemplo de nota autorizada pela rota antiga: nfs_3a0a592a471f44eeb64d710ac326566d
Exemplo de nota recusada pela rota nova: nfs_3a0acb66aecb4edfaeb1e801c74509ea
Uma coisa que pude notar é que, na rota DPS, apesar de estarmos enviando a tag infDPS.serv.cServ.cTribNac como 01.07 (com um ponto), no XML aparece sem esse ponto, porque acredito que seja o novo formato do padrão nacional, mas como a prefeitura ainda não aderiu ao padrão nacional, não sei se essa mudança pode estar causando a rejeição (no XML da nota autorizada, a tag ItemListaServico está formatada do jeito que estamos enviando, com o ponto).
O provedor dessa prefeitura, particularmente, tem um comportamento bastante peculiar. Para exemplificar, citarei dois que estão diretamente ligados ao seu caso:
O item da lista de serviços é enviado sem formatação mesmo. Porém, o XML da NFS-e que eles retornam (que foi o que usou como comparação) vem com formatação;
Caso seja enviado algum CNAE no XML do RPS, essa informação é omitida no XML retornado por eles.
E analisando o XML da nota autorizada, verifiquei que foi enviada a seguinte informação:
<CodigoCnae>9511800</CodigoCnae>
Portanto, creio que seja apenas isso que esteja faltando para conseguir autorizar a nota no novo endpoint. Para isso, basta você preencher a propriedade CNAE no JSON, conforme documentação:
Essa última nota que enviei e foi recusada de fato omiti o CNAE para ver se funcionava sem ele (já que estava como opcional e não encontrei essa informação no XML da nota autorizada).
Porém, esse CNPJ em específico teve uma alteração contratual e mudou o CNAE principal em Fevereiro, deixando de usar esse 9511800 e usando o 6202300. Mais cedo tinha tentado com ambos já e a rejeição era a mesma.
Fiz novamente alguns testes com os dois CNAEs e tive o mesmo retorno:
Verifiquei que a nota nfs_3a0acbd60a134b1aa3ce8750cf5b3fee, mesmo tendo sido enviada pelo endpoint antigo, retornou a mesma crítica. Sendo assim, não acha que deva ser algo relacionado ao cadastro da empresa junto à Prefeitura mesmo?
A sugestão retornada pelo provedor para corrigir a rejeição é:
“Verifique se o item ou código informado está correto. Se estiver, proceda a atualização cadastral junto à Prefeitura assim que possível, pois o item ou código informado não está cadastrado para a sua”
Você já tentou entrar no portal da prefeitura ou verificar com eles essa informação?
Então, fizemos um teste de emissão pela própria plataforma da prefeitura e a nota foi autorizada, ficamos um pouco perdidos porque de fato fizemos tentativas por ambos os CNAEs e por ambas as rotas hoje e tivemos o mesmo retorno em todos os casos.
A princípio, como esse CNPJ teve notas autorizadas na Nuvem no dia 07/04 e essa alteração de CNAE foi no dia 24/02, achei que não teria correlação.
Para utilizar a nova rota de DPS e das configurações, fizemos chamadas para as rotas de atualização da empresa e de configurações de NFS-e para esse CNPJ, acho que não deve estar relacionado, mas não custa perguntar: o fato de termos feito essas atualizações pode ter feito ativado algum modo diferente na Nuvem para que esse CNPJ utilize as rotinas/parâmetros mais atuais automaticamente, mesmo quando tentamos emitir pela rota antiga?
Para que eu possa investigar mais a fundo, favor me informar o id de uma nota autorizada pela rota antiga (de preferência antes de você ter iniciado os testes com os novos endpoints).
Parece que conseguimos identificar o problema, não tem nada a ver com a mensagem de erro retornada pela prefeitura, possivelmente é algum bug interno com a série do documento, havíamos tentado enviar em uma série diferente, para manter as notas de testes separadas das de produção, e isso fazia com que as notas fossem sempre rejeitadas com a mensagem de erro citada acima, ao tentar emitir o mesmo documento na série 1, foi autorizado.
Muito obrigado pela ajuda, Arimateia! Estou deixando a explicação aqui para caso alguém tenha esse mesmo problema no futuro.
