Italo Giurizzato Junior

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.

Carlos, Você não me respondeu se os XMLs que foram baixados da SEFAZ são do próprio emitente ou se são de fornecedores.

Bom dia Douglas, Vou novamente analisar a sua contribuição e fazer testes com o seu XML. Desde já muito obrigado.

Bom dia Carlos, Você anexou 2 XMLs completos o primeiro tem 7 Kbytes e o segundo tem apenas 5. Notei que ambos se referem a mesma nota, mas estão com SignatureValue e X509Certificate diferentes á no grupo Signature. Isso é muito estranho. Os XMLs que você baixou foram emitidos por outra empresa, por exemplo o Fornecedor? Se sim, você não deve carregar o XML e realizar uma consulta. Esse procedimento é realizado quando você emite uma nota e por algum motivo o XML da mesma ficou se o protocolo de autorização. Ai sim, devemos carregar o XML assinado e realizar a consulta para que o mesmo seja atualizado com o protocolo de autorização. Agora se você baixa o XML de um fornecedor e deseja saber se o mesmo consta como autorizado na SEFAZ e não acredita no protocolo que consta nele, então você consulta essa nota informando somente a chave. Não esqueça de salvar o XML do fornecedor em uma pasta que o ACBrMonitor não tenha acesso, pois se não me falha a memória, ao informar somente a chave e o Monitor encontrar o XML ele o carrega antes de realizar a consulta.

Bom dia, Faça uma cópias das units que você alterou e escreveu. Atualize todos os fontes de todas as pastas, reinstale a suíte ACBr usando o ACBrInstall_Trunk2 com a opção de apagar arquivos antigos marcada. Faça os testes usando o programa exemplo.

Bom dia Evandro, Favor atualizar todos os fones de todas as pastas, reinstale a suíte ACBr usando o ACBrInstall_Trunk2 com a opção de apagar arquivos antigos marcada. Faça testes usando o programa exemplo. Note que se faz necessário configurar o componente para a versão 1.5.1 Existem schemas para essa nova versão.

Bom dia Daniel, A cidade de Curitiba possui um webservice próprio que chamamos de provedor ISSCuritiba. O layout utilizado é a versão 1 da ABRASF. Sendo assim devemos utilizar o método Enviar para poder enviar um lote contendo de 1 até 50 Rps. Depois o método ConsultarSituacao para saber a situação do lote enviado. Por fim o método ConsultarLoteRps caso a situação seja 3 ou 4. Se a situação for 3 teremos como retorno a lista de rejeições, por outro lado se for 4 teremos como retorno o XML da(s) NFSe. A propriedade de configuração: ConsultaLoteAposEnvio permite automatizar todo o processo acima, para isso o seu valor tem que ser True. Como eu não tenho nenhum certificado digital de contribuinte de Curitiba não tenho condições de realizar testes. Alias os testes que realizei com o novo componente só obtive erros ao tentar enviar, consultar e cancelar, pois estou usando um certificado cuja empresa não é de Curitiba. Peço que faça testes usando o programa exemplo e não esqueça de atribuir o valor LT_TLSv1_2 ao campo SSLType, pois vários provedores estão exigindo essa configuração. Marque também a opção para salvar os arquivos soap. No programa exemplo execute os métodos de forma individual, temos um botão para cada um deles. Anexe os arquivos gerados aqui no fórum para que possamos analisar. Mas antes de realizar esses testes, por favor atualize todos os fontes de todas as pastas.

Boa tarde, Complementado o que o BigWings já colocou, no caso do CT-e não temos ainda o DistribuicaoDFePorChaveCTe, apenas do componente possuir o método, não temos esse serviço disponível no webservice do Ambiente Nacional.

Boa tarde Evandro, Se tudo der certo amanhã estarei enviado para o repositório uma contribuição de outro colega do fórum. Sessa contribuição se refere a nova versão e ao novo evento.

Ricardo, No meu entendimento se em ambiente de produção a regra só vai ser ativada em 01/09/2021 a tag <indIntermed> não precisa ser gerada. Mas o que custa gerar? Nada. É apenas uma linha a mais na sua rotina que alimenta o componente. Quanto ao tPag=17 (PIX) já fez testes no ambiente de homologação? A SEFAZ recusou? Conforme consta na NT esse novo valor para tPag é para ser aceito sim no ambiente de produção a partir do dia 05/04/2021.

Vou analisar o que você já fez.

Boa tarde, Você tem os schemas para validar esse novo evento? Ocorreu mudança da versão do Reinf por conta desse novo evento?