Italo Giurizzato Junior

Boa tarde Orion, Você notou que nesse XML da revisão 23266 possui a tag <DigestValue> ? Pois bem em nenhum momento essa tag é incluída no XML dessa consulta a não ser que a mesma requer que o XML seja assinado, mas neste caso essa tag estaria dentro do grupo <Signature>. Favor verificar se você não tem nenhum fonte do ACBr com uma bolinha vermelha em seu ícone, caso afirmativo exclua e atualize novamente os fontes e faça novos testes.

Boa tarde Sandro, O problema que o retorno esta no formato Json. Favor verificar com o provedor se é possível que o retorno seja em XML?

Boa tarde Marcelo, Favor atualizar os fontes e faça novos testes usando o componente novo.

Boa tarde, Você não seleciona o provedor e sim a cidade para qual vai emitir a nota. Favor realizar testes usando o programa exemplo do novo componente: ACBrNFSeX.

Boa tarde Marcelo, Como não estamos mais dando manutenção no componente antigo: ACBrNFSe A correção foi aplicada somente no componente novo: ACBrNFSeX. Procure migrar assim que possível para o novo componente.

Bom dia Marcelo, Fiz vários testes e não conseguir fazer funcionar. Notei que ao enviar o Rps para o WebService este retorna o WSDL e não um XML de resposta. Favor entrar em contato com o provedor ou com a prefeitura e solicitar um XML de exemplo. Observação, não ser o XML do Rps, tem que ser o Envelope/Soap (vide o arquivo *-ger-nfse-soap.xml). Pois acredito que estou gerando o Envelope/Soap de forma errada. Tentei montar conforme o mostrado pelo SoapUI, mas mesmo assim não deu certo.

Bom dia Rogério, Favor entrar em contato com a prefeitura ou com o provedor e verificar qual é a versão do XML que eles estão utilizando bem como as URLs de produção e de homologação.

Bom dia Orion, Qual é o método que você esta testando? Favor anexar os XMLs gerados segundo a revisão 23077 e segundo a revisão 23266.

Bom dia Marcelo, Favor atualizar os fontes e faça novos testes.

Bom dia Marcelo, Favor atualizar os fontes e faça novos testes.

Bom dia Castilhos, Neste caso eu não sou a pessoal mais recomendada em lhe ajudar.

Você trabalha com qual linguagem?

Boa tarde João, O componente ACBrNFeDANFeRL possui uma propriedade de configuração chamada CasasDecimais e dentro desta encontramos as propriedades MaskqCom e MaskvUnCom destinados a mascara da quantidade e do valor, bem como as propriedades qCom e vUnCom onde definimos a quantidade de casas decimais.

Boa tarde Gabriel, Acredito ser no provedor que não esteja gerando a mensagem em UTF-8.

Boa tarde Marcelo, Já inclui na minha lista de tarefas para analisar o problema. TK- 2018

Gabriel, A intensão é o componente não gerar uma Excepcion e sim capturar o erro e colocar o mesmo em uma lista. No programa exemplo temos uma procedure que mostra como ler essa lista de erros.

Bom dia Castilhos, Você esta utilizando o componente ACBrNFSeX?

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia Gabriel, Faça o teste com a unit que anexei e me de um retorno. Se funcionar vou enviar ela para o SVN e lhe aviso.

Olá Pessoal, Foi publicado a versão 1.10 da Nota Técnica 2014/002 (publicada em 15/10/2021), nessa nova versão consta algumas mudanças no processamento das requisições de Distribuição a partir do NSU informado, mais precisamente quando informamos o ultNSU. Umas das coisas que não mudou apenas foi reforçado nessa NT é que os documentos recepcionados pelo Ambiente Nacional vão ficar disponíveis por no máximo 3 meses, ou seja, 90 dias. Vamos as mudanças: 1. O Ambiente Nacional vai passar ter um controle de acesso de cada usuário do serviço, ou seja, com esse controle o AN vai saber se o usuário utiliza o serviço de forma continua ou esporádica. 2. Os usuário que já utilizam o serviço de forma continua não vai notar nenhuma diferença, tudo vai ocorrer normalmente. 3. Para os novos usuários do serviço, bem como aqueles que por algum motivo deixaram de utilizar o serviço por um período de 60 dias ou mais, ao realizar o primeiro acesso será retornado o status 137 (Nenhum documento localizado), neste caso o usuário deverá aguardar por 1 hora para cumprir as regras do uso indevido. Cumprido o prazo poderá acessar novamente e caso tenha documentos, estes serão retornados. Essas mudanças vão entrar em vigor a partir de 01/11/2021 no ambiente de homologação e 08/11/2021 no ambiente de produção. Recomendações Para Evitar o Uso Indevido A análise do comportamento atual das aplicações das empresas (“aplicação cliente”) permite identificar algumas situações de “uso indevido” nos ambientes autorizadores. Como exemplo maior do mau uso do ambiente, ressalta-se a falta de controle de algumas aplicações que entram em “loop”, consumindo recursos de forma indevida, sobrecarregando principalmente o canal de comunicação com a Internet. Para este Web Service serão mantidos controles para identificar as situações de uso indevido de sucessivas tentativas de busca de registros já disponibilizados anteriormente, quando utilizada a tag: distNSU. As novas tentativas serão rejeitadas com o erro “656–Rejeição: Consumo Indevido”. O uso indevido relativo ao Web Service NFeDistribuicaoDFe na consulta com tag:distNSU é baseado nos critérios descritos abaixo: 1) Não há mais documentos a distribuir e usuário continua consultando: Se não existir mais documentos a serem retornados (cStat=137) o usuário deve aguardar uma hora para realizar nova consulta. A realização de novas consultas em 1h, após receber a mensagem cStat137, pode gerar o uso indevido, retornando cStat=656. Nesse caso, o CNPJ é bloqueado por 1 hora, sendo impedido de realizar novas consultas nesse intervalo. Decorrido o intervalo de tempo, o desbloqueio será automático. O campo xMotivo traz a seguinte descrição para ajudar o usuário a entender o que está causando o uso indevido: “Rejeição: Consumo Indevido. Deve ser aguardado 1 hora para efetuar nova solicitação caso não existam mais documentos a serem pesquisados. Tente após 1 hora”. 2) Usuário não está consultando os NSU de forma sequencial: O usuário deve sempre realizar a consulta baseada no ultNsu retornado na consulta anterior, ou seja, deve usar os valores do ultNSU retornados pelo serviço nas chamadas subsequentes. O valor do ultNSU corresponde ao ponto de onde a leitura dos blocos de documentos deve continuar. Quando ultNSU for igual ao valor do maxNSU retornado pelo serviço, quer dizer que não existem mais documentos para serem recuperados. Neste caso, para não haver bloqueio por uso indevido, deve-se aguardar 1 hora para realização de novas consultas. Se consultar fora da sequência, poderá ser bloqueado. Decorrido o intervalo de tempo, o desbloqueio será automático. O campo xMotivo traz a seguinte mensagem: “Rejeição: Consumo Indevido. Deve ser utilizado o ultNSU nas solicitações subsequentes. Tente após 1 hora” Atenção: Se diversas aplicações do mesmo ator (emitente ou destinatário ou transportador na NF-e ou indicado no campo autxml) da NF-e efetuarem consultas por NSU para o mesmo CNPJ (14 dígitos – informado na requisição xml), essas devem seguir a mesma sequência de numeração ordenada e de forma ascendente. Caso contrário, enquadrar-se-ão na categoria de uso indevido. Link para baixar a NT: Portal da Nota Fiscal Eletrônica (fazenda.gov.br)

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Marcelo, Tente nos dois ambientes, homologação e produção.