Compusis Informatica Ltda

a principio esta funcionando lucro real, esta dando problema com o simples , o que precisa ? tambem estou enrolado com cachoeira do sul (4303004) esta dando erro na url que esta no acbr

boa tarde , a cidade é 4316808, esta usando o autorizador nacional eu gero o xml , pois achamos mais facil gerar o xml que identificar as informações dos inis, então gero o xml, e carrego no componente e manda emitr. o acbr deve estar validando e gerando um novo xml, dai vem o problema da data e da tag que nao pode ter quando a empresa e do simples. se voce pegar o meu ini enviado e o xml enviado carregar e tentar autorizar deve dar o problema. ate mais

o xml que esta em anexo é de uma empresa do simples e nao tem essas tag, mas no xml que o acbr envia tem

bom dia, sim, ele coloca uma data errada, cfe. mostra os xml. coma data errada a prefeitura da erro. Outro problema que tem, o acbr esta colocando a tag abaixo, para empresa do simples a receita diz que nao pode ter essa tag <totTrib> <indTotTrib>0</indTotTrib> </totTrib>

segue o ini da conf Ininfse.txt

olha o xml gerado pelo acbr, trou a data de emissao <?xml version="1.0" encoding="UTF-8"?> <DPS xmlns="http://www.sped.fazenda.gov.br/nfse" versao="1.01"> <infDPS Id="DPS431680825029373100014000001000000000000006"> <tpAmb>1</tpAmb> <dhEmi>1899-12-30T00:00:00-03:00</dhEmi> <verAplic>26.01.30</verAplic> <serie>1</serie> <nDPS>6</nDPS> <dCompet>2026-01-19</dCompet> <tpEmit>1</tpEmit> <cLocEmi>4316808</cLocEmi> dai da erro de validacao de data

estou gerando o xml da nfse cfe. o manual do ambiente nacional, segue o xml em anexo, o acbr esta validando e dando erro na data de emissao, mas a data esta correta cfe. a documentação da nfse RetEnvio NFSe.txt XmlGerado.xml

Boa tarde. Nós estamos montando o XML da NFSe de Santa Cruz do Sul - RS para a NFSe, ao utilizar a biblioteca X64 multi-thread da semana passada tanto a DLL quanto a SO encontramos algumas divergências com o que criamos com o que está sendo enviado. Ao utilizar a lib chamamos o ConfigInicializar, o ConfigCarregarXml("Passando o Xml em formato String"), Enviar(), ConfigFinalizar(). Tudo ocorre bem, mas o retorno diz o seguinte: { "tipoAmbiente": 1, "versaoAplicativo": "SefinNacional_1.5.0", "dataHoraProcessamento": "2026-01-16T11:44:30.9403356-03:00", "idDPS": "DPS431680825029373100014000001000000000000005", "erros": [ { "Codigo": "E0712", "Descricao": "Para ME/EPP indTotTrib nunca poderá ser informado." } ] } Em anexo estão os XMLs que nós estamos carregando na biblioteca e o XML que ela está efetivamente enviando (pegamos do xml de envio e regredimos do GZip base64 para obtê-lo). Tomei a liberdade de comentar os elementos que estão diferindo como o regApTribSN e totTrib/indTotTrib que foram adicionados e o cPaisPrestacao que foi removido pela biblioteca. Poderiam esclarecer porque a biblioteca está fazendo estas alterações em nosso XML? Muito obrigado. XML_GeradoCompusis.xml XML_EnviadoPelaACBrLib.xml

mas em qual bloco no arquivo ini da nfse deve ser colocado ?

estou usando esse exemplo https://acbr.sourceforge.io/ACBrLib/ModeloNFSeINI-PadraoNacionalRefo.html nao é isso me parece que falta informação nesse ini esse e um exemplo cTribNac nao consigo preencher no xml, estamos quase abandonando o acbr, muito enrolado, as tag do ini deveria ser as mesmas ou serem bem documentadas

mas estou usando o modelo nacional segei o ini e o xml gerado 1824 - Element '{http://www.sped.fazenda.gov.br/nfse}cTribMun': '59' is not a valid value of the atomic type '{http://www.sped.fazenda.gov.br/nfse}TCCodTribMun' Ini_nfse.txt 4121-rps.xml

onde deve ser enviada a informação no ini, nao encontrei na documentação , e estamos com problema para autorizacao de nfse

Onde exporto no ini o conteudo do atributo cTribNac do padrão nacional estamos com todas as emissoes de nfse paradas, pelo jeito comecaram a validar isso hoje

Bom dia, desculpe a demora, não, é só isso mesmo. Muito obrigado.

Boa tarde, para reportar, funcionou. A documentação pode estar com dois parâmetros a mais ou a lib está esperando dois parâmetros a menos. Antes nosso código estava com a interface assim: int NFCom_Enviar(Pointer libHandler, int ALote, boolean AImprimir, boolean ASincrono, boolean AZipado, ByteBuffer buffer, IntByReference bufferSize); agora está assim: int NFCom_Enviar(Pointer libHandler, int ALote, boolean AImprimir, ByteBuffer buffer, IntByReference bufferSize); O segundo está funcionando. Poderiam fornecer um retorno indicando como estará na biblioteca em sua versão final? Então já deixo pronto no código aqui. Muito obrigado.

Ok, com relação ao access violation vou aguardar pelas próximas libs. Segundo a classe fornecida por @marcoprodata nós estamos invocando o método enviar com mais parâmetros do que devia. Peço que corrijam na documentação em https://acbr.sourceforge.io/ACBrLib/NFCom_Enviar.html, pois foi o que usamos como referência. Desculpe não sabia que o gFat e o gFatCentral eram mútuamente exclusivas, vou corrigir. Acho que isso é tudo. Show de bola. Obrigado.

Bom dia @Eric Bortoleto, estamos programando em JAVA com o Bellsoft's Liberica 21, foi criada uma lib no IntelliJ para consumir a DLL e/ou o SO e expôr os métodos. O método enviar está declarado assim na interface: No método exposto está assim: Esta biblioteca JAVA foi criada usando a documentação da ACBr e outros exemplos que já fizemos como NFe, NFSe, CTe etc. Ao invocar o método a DFe já deve estar carregada, apenas passamos o índice 0. Nós não iremos carregar o DFe de arquivo, será passado o INI processado no formato string. Notei que no seu exemplo apenas três parâmetros estão sendo usados no método enviar(1, false, false), nós nos baseamos em https://acbr.sourceforge.io/ACBrLib/NFCom_Enviar.html para desenvolver. Este método foi exposto com sobrecarca? Seria esse o nosso erro? Outra coisa que notei o índice está com 1, ele geralmente não começa com 0? (Tentei com o índice 1 e resultou no mesmo access violation). Obrigado pelo retorno.

Bom dia, estamos encerrando por hora as validações da lib NFCom 1.1.1.8 e gostaria de deixar reportado aqui o que encontramos para ajudar no desenvolvimento: -> Ainda não conseguimos utilizar o método enviar, até então tem retornado o erro SetRetorno(-10, Access violation), não importa a combinação de DFes que usamos ou configurações da lib. Como nenhuma outra lib gerou este erro tentamos variações de configuração sem sucesso. Vamos aguardar por hora. -> O grupo gFatCentral quando presente no INI do DFe gera o erro: 1871 - Element '{http://www.portalfiscal.inf.br/nfcom}gFatCentral': This element is not expected. Expected is one of ( {http://www.portalfiscal.inf.br/nfcom}autXML, {http://www.portalfiscal.inf.br/nfcom}infAdic, {http://www.portalfiscal.inf.br/nfcom}gRespTec ). No momento estamos deixando este grupo de fora da validação. Caso seja de algum interesse anexamos o nosso último teste (lembrando que este DFe é apenas teste de parametrização os testes de validação de dados vem depois). -> Como já foi reportado préviamente estamos deixando de fora o grupo IBSCSB por conta do CST não estar sendo reconhecido no CarregaINI, os subgrupos não foram validados. -> Em nosso primeiro post foi mencionado o layout do pdf parecia fora do padrão (meio torto), continuamos com os testes e ele permanece igual. -> Segundo a nota técnica de 30/09/2025 os campos gIBSCredPres e gCBSCredPres serão removidos do subgupo IBSCSB -> gIBSCBS e o mesmo vale no grupo total -> IBSCBSTot. Nós validamos mas por hora vamos deixar de fora. -> Também na nota técnica será incluído o grupo gEstornoCred no grupo IBSCSB, o mesmo vale para o IBSCBSTot. Por hora estamos desconsiderando. -> Não validamos a biblioteca no linux. -> Detalhe menor: no link https://acbr.sourceforge.io/ACBrLib/ModeloNFComINIReformaTributaria.html o exemplo tem o grupo do FUNTTEL mas está faltando o FUST. Nada sério. Acredito que isso é tudo, fora os métodos Enviar e Cancelar a lib parece estar 100% no Windows. Muito obrigado pela atenção e até mais. Último teste.txt Desculpe o bloco FUST está lá, favor desconsiderar.

Boa tarde, acredito ter encontrado outro problema na biblioteca NFCom na importação do DFe em modo Ini onde chamamos o método carregaIni. -> O parâmetro CST - código da situação tributária do IBS/CBS não está lendo. O retorno da lib é -10 - Houve erro ao ler o arquivo XML. - Valor string inválido para TCSTIBSCBS: 0. Estamos validando o preenchimento do DFe neste modo antes de passar para a lib, tentamos com vários valores seguindo a tabela definida em https://dfe-portal.svrs.rs.gov.br/Cff/ClassificacaoTributaria sem sucesso. Em anexo está um de nossos testes com o valor 400 para o CST e 0000001 para o cClassTrib (sim está incorreto mas com os valores corretos também não passa). Tentamos de várias formas, realmente parece ser na lib. Muito obrigado. ArquivoIniDFe.txt ACBrLibNFCom-20251014.log

Bom dia, desculpe a demora pelo retorno. Em anexo o log da ACBrLibNFCom, nós estamos chamando os seguintes métodos: 1. ConfigInicializar em modo memória 2. ConfigImportar 3. ConfigGravaValor para a senha do certificado 4. CarregarIni para importar o DFe para a lib. 5. Assinar 6. VerificarAssinatura 7. Validar 8. ValidarRegrasdeNegocios 9. Enviar <- onde ocorre o erro durante a geração do PDF. Outra pergunta surgiu enquanto estou desenvolvendo o nosso sistema com a ACBrLib. Estou utilizando o arquivo MOC_NFCOM_Anexo I_Leiaute e Regras de Validacao_v1.00a.pdf como base e o arquivo NFCom_Nota_Tecnica_2025_001_RTC_v1.10.pdf para os ajustes relacionados a reforma tributária. O arquivo ini na documentação em https://acbr.sourceforge.io/ACBrLib/ModeloNFComINIReformaTributaria.html indica que o crédito presumido está sendo esperado pela lib mas a nota técnica indica que será removido. Com relação a ACBrLib, o que devo fazer ao gerar o ini do DFe? Deixar ou remover estes campos? Obrigado. ACBrLibNFCom-20251013.log MOC_NFCOM_Anexo I_Leiaute e Regras de Validacao_v1.00a.pdf NFCom_Nota_Tecnica_2025_001_RTC_v1.10.pdf

Boa tarde. Estou apenas a reportar o que encontrei ao homologar a Lib da NFCom recentemente criada que estamos adicionando em nosso sistema. Ao homologar o método Enviar estou recebendo o erro EAccessViolation quando a Lib tenta gerar o relatório da NFCom (DANFCom). Na versão 1.1.1.6 da lib do dia 30 de setembro o ImprimirPDF também estava gerando esse erro mas na versão 1.1.1.7 de hoje foi corrigida, o PDF gerado está em anexo (ele está correto com este layout? O Adobe abre acusando um erro ao abrir). Originalmente pensei que o problema era no arquivo ini de configuração ou do DFe carregado mas como o ImprimirPDF foi corrigido da 1.1.1.6 para 1.1.1.7 estou concluindo que o erro está na biblioteca visto que ela é nova. O SalvarPDF está gerando erro -2 Houve falhas na finalização da biblioteca quando encerra-se as operações com o ConfigFinalizar (o próprio método SalvarPDF está OK). Praticamente todos os métodos até então estão ok. A biblioteca não foi testada em Linux. O trabalho de vocês está muito bom as bibliotecas estão sendo de grande ajuda fico no aguardo para os ajustes da NFCom. Obrigado. TesteNFCom.pdf

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)