[Ajuda] Utilização do Módulo ACBrGNRe

[Compusis Informatica Ltda]

Boa tarde, estamos homologando o módulo ACBrGNRe e estamos enfrentando algumas dificuldades e precisamos de auxílio. Já utilizamos outros módulos como o NFe, NFSe, CTe, PosPrinter, MDFe e BAL e estes ja foram testados e somos muito gratos pelo resultado, mas no GNRe alguns métodos não estão funcionando como o esperado. Eis o detalhamento:

Todos os módulos que estamos usando são os arquivos .DLL e .SO multi-thread disponibilizados no fórum (já somos pro), a versão da GNRe baixada foi a de 15/12/2023 portando é a versão 0.1.0.173 emitida em 11/12/2023. Baixamos no seguinte link:

Utilizamos o projeto em java do repositório que está na pasta trunk2\Projetos\ACBrLib\Demos\Java\GNRe\Imports\ACBrLibGNReMT como base para a comunicação entre o java e os arquivos .DLL e .SO, os métodos como inicializar, finalizar, manipular o arquivo INI de configuração, gravar xml, obter xml e até mesmo o método enviar estão funcionando corretamente.

A primeira situação inesperada acontece no método CarregarXml, aparentemente ele só carrega Xmls da guia quando estão dentro de um lote e não quando começam com a tag TDadosGNRe como mostra na imagem seguinte.

Ao carregar o lote, conseguimos chamar o método ObterXml e GravarXml, se o arquivo INI de configuração está setado com a chave "VersaoDF" na sessão "GNRe" com o valor 0 para ve100 ou 1 para ve200 isso é indiferente pois o módulo retorna o Xml ajustado na versão correta. (Nos baseamos na documentação em https://acbr.sourceforge.io/ACBrLib/ConfiguracoesdaBiblioteca15.html)

Métodos como ImprimirPdf, Validar e Assinar (e subseqüentemente VerificarAssinatura) não estão com o retorno correto para nós, o método ImprimePdf não gera arquivo, o método Validar acusa a ausência do arquivo de Schema mesmo tendo sido setado corretamente no arquivo INI e os arquivos atualizados estando na pasta de destino. A assinatura não altera o Xml (seguido de ObterXml). A imagem seguinte exemplifica isso:

Dados pertinentes ao arquivo INI relacionados à estas funções são os que seguem:

GNRe.Ambiente = 1                // 0: Produção; 1:Homologação
GNRe.VersaoDF = 1                // 0: ve100; 1:ve200
GNRe.PathSalvar = 'C:\Arq\Teste1'
GNRe.PathSchemas = 'C:\Arq\Teste\Schemas\ACBrGNRe'
GNRe.IniServicos = 'C:\Aqr\Teste\Ini\ACBrGNREServicos.ini'
GNRe.PathGNRe = 'C:\Arq\Teste2'
GNRe.PathArqTxt = 'C:\Arq\Teste3'
GNRe.SalvarTXT = 1

Guia.PathPDF = 'C:\Arq\TestePdf'

No que diz respeito aos Xmls que estamos usando não tenho permissão para disponibilizá-los mas posso fazê-los sem dado algum para poder visualizar a estrutura utilizada, nos baseamos no portal GNRe para os dados, estes estão em anexo.

O que está acontecendo? Esquecemos de alguma configuração? Existe um bug no arquivo .DLL e .SO?

Desde já agradeço. Obrigado.

GNRe200 - Dados Removidos.xml LoteGNRe - Dados Removidos.xml

[Alexandre de Paula]

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Em 05/01/2024 at 17:53, Compusis Informatica Ltda disse:

versão 0.1.0.173

A Lib do GNRE está na versão 175 já, por favor atualize e faça novos testes para validarmos na mesma versão.
Obrigado.

[Compusis Informatica Ltda]

Olá Alexandre, obrigado pelo retorno, desculpe pelo flood. Trocamos para a última versão, 175. O comportamento persiste, até com xmls que encotramos na internet com dados irrelevantes, não está carregando com a estrutura normal mas em lotes está, isso para tentar forçar o erro de que o CNPJ do xml difere do certificado digital. Hoje tentamos fazer um teste trocando a chamada de Cdecl para SdtCall mas não resultou em nada.

[Diego Foliene]

Bom dia!

Estamos verificando seus relatos e realizando alguns testes em nosso ambiente.

Retornaremos aqui assim que descobrirmos algo.

[Compusis Informatica Ltda]

Agradeço. Não sei se é relevante mas notamos que no projeto que está em trunk2\Projetos\ACBrLib\Demos\Java\GNRe\Imports\ACBrLibGNReMT tem o método Enviar, este está recebendo parâmetros mas aparentemente a chamada à biblioteca não está os usando. A imagem que segue mostra isso em nosso código adaptado para testes, isso está correto?

[Diego Foliene]

Boa tarde!

Apenas fornecendo um parecer:

Em 05/01/2024 at 17:53, Compusis Informatica Ltda disse:

A primeira situação inesperada acontece no método CarregarXml, aparentemente ele só carrega Xmls da guia quando estão dentro de um lote e não quando começam com a tag TDadosGNRe como mostra na imagem seguinte.

Correto, ela utiliza o grupo <guias> como um ponto de partida para encontrar as informações.

Em 05/01/2024 at 17:53, Compusis Informatica Ltda disse:

Ao carregar o lote, conseguimos chamar o método ObterXml e GravarXml, se o arquivo INI de configuração está setado com a chave "VersaoDF" na sessão "GNRe" com o valor 0 para ve100 ou 1 para ve200 isso é indiferente pois o módulo retorna o Xml ajustado na versão correta. (Nos baseamos na documentação em https://acbr.sourceforge.io/ACBrLib/ConfiguracoesdaBiblioteca15.html)

Não sei se entendi bem esta aqui.

O parâmetro VersaoDF é útil e necessário para que a lib possa saber qual é a versão do GNRe será gerado o XML e para qual versão do web service será feito o envio.

A rotina de leitura do XML, consegue identificar e realizar a leitura por conta própria, independente desse parâmetro.

Em 05/01/2024 at 17:53, Compusis Informatica Ltda disse:

Métodos como ImprimirPdf, Validar e Assinar (e subseqüentemente VerificarAssinatura) não estão com o retorno correto para nós, o método ImprimePdf não gera arquivo, o método Validar acusa a ausência do arquivo de Schema mesmo tendo sido setado corretamente no arquivo INI e os arquivos atualizados estando na pasta de destino. A assinatura não altera o Xml (seguido de ObterXml).

Analisando os fontes, e a documentação, constatamos que o XML do GNRe na verdade não é assinado.

Logo o método Assinar e subsequentemente o VerificarAssinatura não estão cumprindo exatamente o que propõe.

Adicionada a #TK-4952 em nosso backlog para verificar a possibilidade de remoção destes métodos da Lib.

Para o método ImprimePDF, é importante que você entenda o contexto de uso do mesmo.

O XML que você está tentando carregar é o XML do GNRe.

O método espera receber o XML da Guia, que é o arquivo devolvido pelo web service quando o GNRe é aprovado.

São arquivos diferentes.

No que diz respeito ao método Validar, após alguns testes, descobrimos que o problema ocorre porque o método está buscando por um arquivo "GNRe_v2.00.xsd" e o mesmo está nomeado "dados_gnre_v2.00.xsd". Se você renomear o arquivo para GNRe_v2.00.xsd ele não vai mais acusar schema não definido.

No entanto, durante estes testes, constatamos que o método parece estar alterando o arquivo XML que é carregado para validação.

Foi criada a #TK-4953 para analisar esta questão.

[Compusis Informatica Ltda]

Com relação ao primeiro item: entendido, usaremos apenas lotes.

Com relação ao segundo item: não foi um problema ou queixa, o método ObterXml e o parâmetro estão funcionando perfeitamente. Era apenas para fornecer mais parâmetros homologados para ajudar.

Com relação à assinatura e validação da assinatura: Ok vamos desconsiderar os métodos.

Com relação à impressão: realmente achávamos que devíamos carregar o xml como o de uma NFe ou CTe, desculpe. Vamos usar o retorno.

Por fim com relação à validação: correto, trocar o nome do arquivo resolveu o problema.

 

Como foi constatado, aqui também ocorre de que o xml de origem é sobrescrito quando chama-se a validação e ainda o componente retira a guia de dentro do lote.

Obrigado pelo retorno rápido.