Italo Giurizzato Junior

Boa tarde Mario, Experimente usar o libOpenSSL em vez de libWinCrypt.

Boa tarde Edson, Você esta usando o componente ACBrNFSe ou ACBrNFSeX? Se esta usando o ACBrNFSe, lhe convido a iniciar os testes com o novo componente de emissão de NFS-e: ACBrNFSeX O componente antigo: ACBrNFSe não está mais tendo manutenção. Faça os testes usando o programa exemplo do novo componente. Manual de Migração https://www.projetoacbr.com.br/forum/topic/63017-manual-de-migração-para-o-novo-componente-de-emissão-de-nfs-e/

Boa tarde Icozeira, Vou lhe pedir mais um favor. Essa versão 2.03 devemos adotar para todas as cidades atendidas pelo provedor ou somente para a cidade em questão? Essa cidade que você esta testando qual é?

Boa tarde Edu, Chegou a ler esse tópico?

Olá Pessoal, Gostaríamos de anunciar que a integração do ACBrNFSeX para emissão da NFSe por API está concluída, utilizando todos os recursos existentes na API. Todos os serviços disponibilizados pela API da NFS-e Padrão Nacional foram testados e detalhados a seguir. O Enviar o DPS (Declaração de Prestação de Serviço) esta funcionando, temos como retorno o XML da NFS-e caso os dados estejam tudo OK. O Enviar Eventos (de cancelamento por exemplo) esta funcionando, temos como retorno o XML da efetivação do evento caso os dados do pedido estejam OK. O Consultar DPS por Chave esta funcionando, temos como retorno apenas a chave da NFS-e e mais nada. O Consultar NFS-e por Chave esta funcionando, temos como retorno o XML da NFS-e. O Consultar Evento nos permite realizar essa consulta de 3 formas diferentes: 1. Consultar Evento informando somente a chave da NFS-e esta funcionando, temos como retorno o XML do evento. 2. Consultar Evento informando a chave e o tipo de evento não esta funcionando, esta retornando o erro 404, esse problema já foi relatado a RFB. 3. Consultar Evento informando a chave, o tipo de evento e o numero sequencial esta funcionando, mas a API esta gerando o XML do evento codificado em base 64 duas vezes, esse problema já foi relado a RFB. O Consultar DFe nos permite realizar essa consulta de 2 formas diferentes: 1. Consultar DFe informando o NSU (Numero Sequencial Único) esta funcionando, temos como retorno os XMLs das notas e dos eventos. 2. Consultar DFe informando a chave da nota esta funcionado, temos como retorno o XML da nota e dos eventos vinculados a nota. O Obter o PDF da nota esta funcionando, mas o QR-Code esta incompleto não contem a URL e caso a nota esteja cancelada não aparece a Tarja Cancelado, esse problema já foi relatado a RFB. Uma coisa importante a ser dita é que todos os testes realizados foram feitos em ambiente de produção, pois o ambiente de homologação ainda apresentava alguma erros, como por exemplo: exigir que a cidade esteja conveniada para poder emitir a nota mesmo o contribuinte ser MEI. Vale também informar que tanto a API quanto ao Portal Nacional da NFS-e (para emitir a nota via web) estão com instabilidade gerando erros de timeout por exemplo. Foi detectado também no ambiente de produção que ao tentar consumir qualquer serviço ocorre o erro: network subsystem is unusable, mas ao tentar novamente consumir o serviço desejado funciona. Esse erro só esta ocorrendo em ambiente de produção no de homologação ele não ocorre, portanto é um problema na API de produção, esse problema já foi relatado a RFB. Esse é um resumo dos testes que eu realizei.

Bom dia Icozeira, Nem a tag NifTomador. Na versão 2.01 do layout da ABRASF não tem essa tag e não tem como informarmos o endereço exterior do tomador. A tag NifTomador surgiu na versão 2.03 do layout da ABRASF. E na versão 2.04 passamos a ter tanto a tag NifTomador quanto o grupo EnderecoExterior. Precisamos saber se para esta cidade a versão é 2.03 ou se eles modificação os schemas da 2.01 visando a possibilidade de gerar a tag NifTomador. Pois além dos schemas teremos que fazer mais algum ajuste no componente.

Bom dia Adilson, Vai ser necessário debugar para saber onde no Lazarus ocorre o AV, pois no Delphi não ocorre. Como você usa o Lazarus, vai ter que procurar também por DCU antigas do ACBr que estão em pastas que o Lazarus esta tendo acesso e com isso provocando o erro.

Bom dia Rafael, Você tem fontes com alterações locais? Verifica se não tem nenhuma unit do ACBr com uma bolinha vermelha em seu ícone, caso afirmativo delete a unit. Atualize todos os fontes de todas as pastas. Reinstale o ACBr com a opção de apagar arquivos antigos marcada. Compile a aplicação com a opção Build.

Bom dia Valdir, O programa exemplo salva os arquivos temp1.xml e temp2.xml independente dessa propriedade de configuração. Eu já lhe disse que o retorno da API da NFS-e Padrão Nacional retorna um json. O programa exemplo não esta preparado para mostrar na aba de Retorno o conteúdo do json. Isso explica esse erro. Como você consultou um evento, favor procurar na pasta que você configurou para salvar os XML. Ele deve ter criado uma pasta chamada: Eventos e salvo o XML do evento que foi retornado dentro dessa pasta.

Boa tarde, Realizei diversos testes. Se gera o XML sem vogais acentuas e cedilha o XML é assinado, enviado e o provedor não recusa por assinatura invalida. Por outro se incluir cedilha ou vogais acentuadas, o mesmo é recusado e o motivo é assinatura inválida. Peguei esse XML recusado pelo provedor e chequei a sua assinatura através do site: Receita Federal do Brasil - Validador de Assinaturas (fazenda.gov.br) Ele acusa que a assinatura é valida. Chego a conclusão que o problema é o webservice do provedor que deve fazer uma checagem diferente. Logo o componente esta gerando e assinando da forma correta. Não tem o que ser alterado nele.

Boa tarde Adilson, Alguma coisa esta errada na sua maquina, você deve ter cópias dos fontes do ACBr e o Delphi deve estar pegando essas cópias, pois descobri onde poderia ocorrer o erro de AV, foi corrigido e enviado para o SVN. Nos meus testes não tenho tido o erro de AV.

Boa tarde Marcos, Já esta no SVN.

Boa tarde João, Já esta no SVN.

Adilson, As configurações estão corretas. Experimente colocar dentro da pasta que esta o EXE as DLLs da pasta: ...\DLLs\OpenSSL\1.1.1.10\X86

Bom dia João, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-4481

Você tem fontes com alterações locais? Verifica se não tem nenhuma unit do ACBr com uma bolinha vermelha em seu ícone, caso afirmativo delete a unit. Atualize todos os fontes de todas as pastas. Reinstale o ACBr com a opção de apagar arquivos antigos marcada. Compile a aplicação com a opção Build.

Valdir, Mas nesse arquivo não tem nada mesmo. O Padrão Nacional retorna um Json, com meia dúzia de objetos, sendo que um deles é o XML do evento que pela documentação é para estar compactado e decodificado em base 64. Se você quer ver esse XML, precisa configurar o componente para salvar os arquivos em disco. Configuracoes.Arquivos.Salvar := True.

Bom dia Icozeira, Complementando o que o Diego já lhe passou. Atualize todos os fontes de todas as pastas, reinstale o ACBr e faça novos testes.

Adilson, Anexa um print da aba Certificado e WebService, quer ver a sua configuração.

Bom dia Adilson, Alguma coisa você esta fazendo de errado. Não basta atualizar os fontes e recompilar a sua aplicação, tem que reinstalar o ACBr também.

Bom dia @suporteatinfo, Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e faça novos testes.

Bom dia Valdir, O problema é o seguinte: O Consultar Evento existem 3 formas diferentes de realizar essa consulta. 1. Consultar informando somente a chave da NFS-e, esta consulta esta funcionando sem nenhum problema, retorna e salva o XML do evento. 2. Consultar informando a chave e o código do evento desejado, esta consulta não é realizada retornando um erro 404. 3. Consultar informando a chave, o código e o numero sequencial do evento, esta consulta esta funcionando em partes, pois quando o componente tenta descompactar o XML após ter sido decodificado em base 64 ocorre o erro de Data Error. Descobrimos que o XML foi codificado em base 64 duas vezes, note que existe uma linha comentada que chama a função DecodeBase64 duas vez, se você comentar a linha acima e descomentar a outra, vai ver que vai funcionar. Mas lembre-se que se fizer essa alteração a primeira forma de consulta vai parar de funcionar. Já reportei o problema para o pessoal que cuida da API, agora é aguardar eles fazerem as devidas correções.

Bom dia Everton, Apesar de no XML da NF3e constar o grupo autXML que tem como objetivo relacionar as pessoas (CNPJ ou CPF) autorizados a ter acesso ao XML, o componente já possuir o método para consumir o DistribuicaoDFe para obter os XML, a SEFAZ ainda não disponibilizou a URL de homologação e de produção para esse serviço. Isso explica a mensagem de erro.

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

Bom dia Sebastião, Exatamente, na versão 4 o grupo infCteComp passou a ser uma lista com até 10 ocorrências, sendo assim criamos uma nova classe chamada infCteComp10 que é uma lista.