Compusis Informatica Ltda

Boa tarde, tudo bem? Estamos desenvolvendo nosso sistema com o componente ACBr NFSe. Quando fomos checar na documentação vimos que os links antigos que usamos para homologação estão lá mas não estão mais sendo referenciados em https://acbr.sourceforge.io/ACBrLib/ExemplodeINI6.html estes são os seguintes: https://acbr.sourceforge.io/ACBrLib/ModeloNFSeINI-UmServico.html https://acbr.sourceforge.io/ACBrLib/ModeloNFSeINI-MaisdeUmServico.html Estes modelos, especialmente o um serviço são mais completos do que os que estão listados atualmente. Estes ainda podem ser usados como guia ou devemos usar os que estão lá agora? Obrigado.

O bloco "ConstrucaoCivil" localizei apenas no layout Padrão Nacional nos exemplos de INI do ACBrLibNFse. Não localizei no padrão próprio nem no padrão Abrasf contudo no layout Padrão Abrasf oficial existe este Bloco... As informações de Exemplo dos registros INI do ACBrLibNFse estão desatualizadas ou não existem mesmo?

Bom dia, tudo bem? Estou postando este tópico em nome da Compusis Informática para saber se existe alguma previsão sobre o desenvolvimento das bibliotecas .so para linux em ambientes sem display. Sei que devo visitar o Discord para realizar esta pergunta mas não tenho mais permissão Pro apenas a credencial de meu superior tem. Em nosso ambiente de homologação conseguimos fazer funcionar perfeitamente no CentOS e no Ubuntu onde um dockerfile configurado com as nossas necessidades resolveu todas as nossas dependências e problemas. O sistema roda, as bibliotecas NFe, NFSe, CTe dentre outras realizam todas as suas funções sem problemas no linux. Tudo está funcionando. Porém, iremos dar um grande passo em projetos onde uma das escolhas principais envolve de que se a ACBr tem bibliotecas que rodam tanto no windows (que já foram homologadas) quanto no linux (também homologadas) e as segundas de preferência já estivéssem rodando sem a necessidade de ter um docker para emular o ambiente display. Portanto a minha pergunta: -> Existe uma previsão certa/sólida de que as bibliotecas .so dos módulos ACBr terão suas versões liberadas sem necessitar de ambiente display? Sem necessitar de um "contorno" com docker? Quando? Obrigado desde já. Tenha um bom dia.

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.

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?

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.

Bom dia, estamos com dificuldades ao trabalhar com o módulo GNRe e gostaríamos de receber alguma ajuda. Criamos um post mas este ficou no fórum aberto da ACBr no seguinte link Como não conseguimos mover para cá então estamos reenviando o pedido. Obrigado.

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

As chamadas foram executadas, diferente de antes que ao passar Date preenchido corretamente resultavam em Unsuported Type Exception. Porém ao revisar o Log em nível 4, vi que passando o tipo String com valores como "29/09/2023" o componente não estava interpretando os dados. Segue a imagem:

Boa tarde, estou reportando que no repositório Trunk2 seguindo o diretório: trunk2\Projetos\ACBrLib\Demos\Java\NFSe\Imports ambos os projetos single e multi thread estão com os tipos dos métodos de consulta incorretos. A classe interface foi escrita aguardando objetos do tipo java.util.Date mas o correto é String (imagem 1). Isso resulta em uma exception do tipo "Unsuported Argument Type". Ao alterá-la é preciso tratar os respectivos métodos (imagem 2)