Olá.
Comecei a implementação para emitir NFSe por aqui.
Vi dois endpoints: “/nfse” (deprecated) e “/nfse/dps”.
O endpoint “/nfse” permanece ativo? Caso esteja, qual previsão de desabilitar?
Olá, @rd1218.
O endpoint /nfse está disponível apenas para clientes antigos e ainda não temos uma data definida para sua definitiva desabilitação.
Entendo que a versão mais nova apresenta funcionalidades adicionais, mas para nossa necessidade o modelo anterior funcionaria bem.
Ademais, ele é bem mais simples, com propriedades melhor nomeadas e, portanto, mais fácil de navegar.
Solicito verificar se para minha empresa está disponível este endpoint “/nfse”.
Obrigado
Boa noite, @rd1218.
O endpoint mais novo (/nfse/dps) é baseado na NFS-e do Padrão Nacional e todas as propriedades estão documentadas.
A utilização do endpoint depreciado não é mais possível.
Entendo.
Mas de fato a versão mais recente (/nfse/dps) possui ainda alguns passos para amadurecer. Como exemplo, algumas propriedades estão descritas erroneamente, e vários mnemônicos adotados são piores do que eram na versão anterior (/nfse).
Quais propriedades?
Poderia dar exemplos?
Eu percorri as propriedades dos objetos para estudar e vi algumas descrições erradas. Desconfio também que a marcação required talvez esteja equivocada em alguns pontos. Entretanto, não anotei quais eram. Creio que a (grande) maioria prossiga com SDK, ou mesmo simplesmente baixe o swagger.json e siga adiante, de modo que não captam estes pontos.
Sobre os mnemônicos, entendo que quem trabalha com as chamadas da API é um desenvolvedor, tipicamente não familiarizado com os termos de uma NF. Assim, considero que “data_emissao” é melhor que “dhEmi”. Neste sentido, entendo que a versão anterior /nfse continha descrições mais amigáveis. Indo mais adiante no objeto, me parece que inclusive quem tem bagagem com NF precisa consultar várias vezes a documentação para entender as propriedades, e sendo um JSON com tantos sub-recursos, é trabalhoso de navegar.
@wlandgraf
Fiz uma correção em minha mensagem anterior, ao reler a mensagem percebi que havia me expressado equivocadamente.
Sem esse feedback não podemos saber a causa dos problemas e principalmente corrigi-los.
Nota que alguns campos podem ser required para alguns provedores, mas não para outros. Nesse caso, na API da Nuvem Fiscal obviamente eles não podem ser required.
O novo endpoint segue fielmente a nomenclatura dos serviços da NFS-e nacional. Portanto, consideramos o contrário do seu entendimento. O DTO do endpoint antigo tinha termos que foram “inventados” e precisavam ser entendidos dentro do contexto da API e de cada provedor.
O DTO do endpoint novo contém nomes “padronizados” e que foram definidos pela equipe do governo e da NFS-e nacional. Além de não existir ambiguidade, são termos cuja documentação e entendimento você pode obter não só na API da Nuvem Fiscal, mas também em outros sites. Ao fazer uma busca com um termo no Google por exemplo, você poderá encontrar informações sobre como preencher aquele campo em sites do governo ou qualquer outro site, pois usamos os mesmos nomes usados pelo webservice do governo.
Agradeço o retorno.
Acho que num exercício de revisão das propriedades vocês poderão identificar os casos de descrição equivocada ou required eventualmente inconsistente. Infelizmente não anotei e não tenho como repetir a operação, que é longa, de modo que não posso contribuir além de ter deixado aqui meu alerta.
Sobre os mnemônicos, entendi que antes (/nfse) havia um esforço adicionado na tentativa de melhorar o entendimento e que no novo endpoint (/nfse/dps) tal esforço foi descontinuado. Concordo com a premissa adotada. No entanto, sugiro avaliar a pertinência de citar na documentação que a terminologia segue o definido pelo Governo no webservice versão XYZ.
Este tópico foi fechado automaticamente 24 horas depois da última resposta. Novas respostas não são mais permitidas.