Italo Giurizzato Junior

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 Daniel, Como a Consulta a Situação do Lote é realizada varias vezes até que tenhamos a Situação igual a 3 ou 4, acredito que o tempo entre uma consulta e outra esta sendo curto em relação ao tempo que o servidor esta levando para liberar o arquivo para uma nova escrita.

Bom dia, Visitando o site da prefeitura Nova Lima/MG notei que o provedor Abaco criou um novo webservice. Até então sabíamos que o provedor Abaco seguia a versão 1 do layout da ABRASF, mas para a cidade em questão foi implementando um webservice que segue a versão 2.04 do layout da ABRASF. Baixei o Manual que se encontra no site da prefeitura, mas não encontrei os Schemas (arquivos XSD) que o provedor vai se utilizar para validar o XML antes do seu envio. Favor entrar em contato com a prefeitura ou com o provedor solicitando os Schemas.

Boa tarde Daniel, Vamos as configurações; Configuracoes.WebServices. AguardarConsultaRet por padrão esta com o valor zero se colocar 1000 ele vai aguardar 1 segundo para consultar o retorno Tentativas por padrão esta com o valor 5, isso indica que ele vai fazer até 5 tentativas de consulta a situação do lote. IntervaloTentativas por padrão esta com o valor 1000 se colocar 2000 ele vai aguardar 2 segundos entre uma tentativa e outra. TimeOut por padrão esta com o valor 5000 se colocar 30000 o componente vai aguardar até 30 segundos para levantar um erro. Detalhe importante é que o TimeOut não congela a aplicação, pois se a resposta chegar em 1 segundo ele segue em frente. Já o AguardarConsultaRet e IntervaloTentativas congela a aplicação. Aconselho colocar no máximo uns 2 segundos para o AguardarConsultaRet e para o IntervaloTentativas e aumentar também a quantidade de tentativas para umas 10 ou 15.

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

Marco, Muito obrigado pela contribuição, já inclui na minha lista de tarefas.

Muito obrigado pelas correções. Fiz mais algumas em outras Units. Por favor atualize novamente os fones e faça novos testes.

Boa tarde, Anexe a Unit que você fez a correção, vou tentar descobrir o problema.

Boa tarde Vinícius, Esta enviando a nota para o ambiente de homologação ou produção? Lembre-se que só a partir de 05/04/2021 o ambiente de produção vai aceitar essa nova tag.

Boa tarde Marco, Favor atualizar os fontes.

Boa tarde Alfredo, Muito obrigado pela contribuição, já inclui na minha lista de tarefas.

Verifique se não tem algum arquivo que compõe a suíte ACBr (arquivos INI, Schemas, fontes) com uma bolinha vermelha no ícone. Isso significa que ele foi alterado por você de forma acidental ou proposital e neste caso ao atualizar os fontes eles não são atualizados. Faça uma cópia desses arquivos caso tenha feita alteração proposital e deleta eles das pastas onde se encontram. Por fim atualize novamente para que todos os arquivos de todas as pastas sejam os mesmos que se encontram no repositório. Compare o arquivo original com o alterado e aplique novamente a alteração caso elas sejam realmente necessárias. Dependendo dessas alterações seria interessante você anexar a Unit aqui no fórum em uma outra postagem para que possamos analisar e quem sabe enviar para o repositório.

Boa tarde Rodrigo, Se não ocorreu atualização dos fontes do componente e nem da sua aplicação, pode ser que o provedor não esteja mais retornando a string do QR-Code que o componente pega para gerar o mesmo. Seria interessante você anexar um XML da NFS-e antigo que é impresso o QR-Code e um novo para podermos analisar.

Boa tarde Evandro, Até onde sei não temos nada pronto, caso queira colaborar fique a vontade.

Abra o arquivo INI do provedor e verifica se o valor do campo URI é 1 (sessão Assinar)? Se estiver diferente de 1 isso significa que os seus fontes estão desatualizados. Atualize tudo e faça um novo teste se der erro referente a assinatura altere o campo NameSpace da sessão XML. De: NameSpace=http://www.abrasf.org.br/ para: NameSpace=http://www.abrasf.org.br/nfse.xsd e repita o teste.

Boa tarde, Qual é o provedor?

Boa tarde @rlmariz A diferenças entre os métodos são: Enviar - > Envia um lote com até 50 Rps no modo assíncrono, esse método esta disponível para todos os provedores que seguem a versão 1 do layout da ABRASF e esta documentado no manual versão 2 do layout da ABRASF, mas isso não significa que esta disponível para todos os provedores que seguem a versão 2, pois tem provedor que segue essa versão e não disponibilizou em seu webservice. EnviarSincrono - > Envia um lote com até 50 Rps no modo síncrono, esse método esta documentado no manual versão 2 do layout da ABRASF, mas isso não significa que esta disponível para todos os provedores que seguem a versão 2, pois tem provedor que segue essa versão e não disponibilizou em seu webservice. Gerar- > Envia um Rps por vez no modo síncrono, esse método esta documentado no manual versão 2 do layout da ABRASF, mas isso não significa que esta disponível para todos os provedores que seguem a versão 2, pois tem provedor que segue essa versão e não disponibilizou em seu webservice.

Daniel, Vamos tentar fazer o seguinte: Primeiro você testa cada método separadamente conforme lhe orientei e anexa os XML aqui no fórum para que eu possa analisar. Se eu conseguir descobrir o problema, ótimo, caso contrario vejamos essa questão do certificado.

Bom dia, Desculpe, mas não concordo com isso. Entendo perfeitamente que o provedor não segue a risca o layout da ABRASF, mas neste caso devemos na Unit ABRASFv2 contornar esses problemas. No novo componente de emissão de NFS-e os arquivos INI dos provedores se tornaram Units e é nessas Units que serão tratadas as particularidades caso tenham. Vou analisar as units alteradas, mas para o componente atual a Unit exclusiva para o provedor Elotech não concordo.

Carlos, Vamos lá. Primeiro você deve orientar o funcionário que nunca se deve enviar novamente uma nota pelo simples fato de ter ocorrido um erro de conexão. Quando ocorre erro de conexão e o XML da nota fica sem o protocolo de autorização o procedimento correto é: 1. Carregar o XML (tem que estar assinado); 2. Consultar Desta forma se o erro de conexão ocorreu no retorno e se a nota foi autorizada ao executar o procedimento acima o XML será atualizado com o protocolo de autorização, ficando pronto para ser impresso o DANFE. Por outro lado se o erro ocorreu no envio, ao realizar a consulta a SEFAZ vai acusar que a nota não existe na sua base de dados, ai sim devemos enviar ela novamente. Outra coisa importante se você ativou a opção de só salvar o XML de notas confirmadas (autorizadas) desmarque. Pois essa opção só salva o XML em disco caso não ocorra nenhum erro de conexão. Se ocorrer algum erro você vai perder o XML assinado que é necessário para o procedimento que apresentei para você. Agora não entendo o porque de realizar uma consulta após baixar o XML da SEFAZ. Se você conseguir baixar o XML de uma nota do site da SEFAZ é obvio que o mesma esta autorizada ou denegada. Mas estamos analisando o código do ACBrMonitor para tentar entender o porque a opção de consulta esta ferrando o XML baixado.

Bom dia Rodrigo, Não ficou claro para mim. Antes através do componente ACBrNFSe ao imprimir o DANFSE constava o QR-Code no mesmo e agora não consta mais, correto? E isso passou ocorre após atualização dos fontes? A cidade mudou de provedor?

Bom dia, Por favor anexe o XML de envio de Lote gerado pelo executável antigo e outro pelo novo.

Bom dia Wendell, Muito obrigado pela colaboração, vou incluir na minha lista de tarefas.

Bom dia André, Comparando o XML gerado e enviado para o webservice com os schemas não encontrei nada que apontasse estar errado. O jeito mesmo vai ser entrar em contato com eles.