Francis Silva

Prezados, eu li em outra thread bem antiga, aqui no fórum, que esse mesmo erro apareceu no passada, e foi resolvido com uma atualização. Desde a revisão 44360, todo e qualquer retorno de processamentos do componente ACBrNFSeX está apresentando o erro abaixo: Com isso, estou tendo problema em atualizar o status das transmissões, porque os retornos estão acusando que não houve sucesso no envio, mas as notas estão sendo autorizadas normalmente no ambiente nacional. Fiz o download e atualização dos fontes da revisão 44948 e o problema ainda persiste. Alguém mais está com esse mesmo problema? Grato. Francis Lay L. Silva.

Eu sempre passo a soma dos tributos, mas no nosso caso, quase sempre são zerados, só temos retenção de impostos quando o serviço é prestado para um órgão público ou de classe.

Então, quando eles forem analisar, tem mais uma situação: NEM SEMPRE remover totalmente a tag <totTrib> <indTotTrib>0</indTotTrib> </toTtrib> vai resolver o problema. No meu caso específico não resolveu. Isso porque somos IMUNES ao ISS de acordo com a constituição federal (atividade de jornais). Então nós precisamos informar essa imunidade na tributaçãp do serviço, conforme o exemplo abaixo: <tribMun> <tribISSQN>2</tribISSQN> <tpImunidade>4</tpImunidade> <tpRetISSQN>1</tpRetISSQN> </tribMun> Quando eu tenho qualquer tag de tributo gerada (tribMun, tribEst, tribFed), ele exige a presença do totalizador <totTrib>, e dentro desse totalizador, ele exige também o total de um dos 3 impostos (federal, estadual ou municipal). Como o ACBr só imprime os totais se pelo menos um deles for maior que zero, eu precisei de abrir mão de mais uma artimanha para resolver o meu problema: NFSe.Servico.Valores.totTrib.indTotTrib:= indSim; // Para OCULTAR o <indTotTrib>0</indTotTrib> quando os totais estiverem zerados NFSe.Servico.Valores.totTrib.vTotTribMun := 0.0000001; // Artimanha para o valor ser maior que zero, passar na validação, e depois ser arredondado para ZERO. Dessa forma, o ACBr gerou o XML, mantendo as informações da minha imunidade, e informando o total dos tributos todos zerados. E a nota fiscal foi autorizada com sucesso. <valores> <vServPrest> <vServ>559.50</vServ> </vServPrest> <trib> <tribMun> <tribISSQN>2</tribISSQN> <tpImunidade>4</tpImunidade> <tpRetISSQN>1</tpRetISSQN> </tribMun> <totTrib> <vTotTrib> <vTotTribFed>0.00</vTotTribFed> <vTotTribEst>0.00</vTotTribEst> <vTotTribMun>0.00</vTotTribMun> </vTotTrib> </totTrib> </trib> </valores>

Acabei de atualizar a revisão 44783 e o problema ainda existe. Realmente fizeram um ajuste no código, para só incluir se a soma dos tributos for maior que zero, mas o problema é justamente no último ELSE quando os tributos estão zerados: function TNFSeW_PadraoNacional.GerarXMLTotalTributos: TACBrXmlNode; begin Result := CreateElement('totTrib'); if (NFSe.Servico.Valores.totTrib.vTotTribFed > 0) or (NFSe.Servico.Valores.totTrib.vTotTribEst > 0) or (NFSe.Servico.Valores.totTrib.vTotTribMun > 0) then Result.AppendChild(GerarXMLValorTotalTributos) else begin if (NFSe.Servico.Valores.totTrib.pTotTribFed > 0) or (NFSe.Servico.Valores.totTrib.pTotTribEst > 0) or (NFSe.Servico.Valores.totTrib.pTotTribMun > 0) then Result.AppendChild(GerarXMLPercentualTotalTributos) else begin if NFSe.Servico.Valores.totTrib.pTotTribSN > 0 then Result.AppendChild(AddNode(tcDe2, '#1', 'pTotTribSN', 1, 5, 1, NFSe.Servico.Valores.totTrib.pTotTribSN, '')) else begin if NFSe.Servico.Valores.totTrib.indTotTrib <> indSim then Result.AppendChild(AddNode(tcStr, '#1', 'indTotTrib', 1, 1, 1, indTotTribToStr(NFSe.Servico.Valores.totTrib.indTotTrib), '')); end; end; end; end; É este trecho, do arquivo PadraoNacional.GravarXml.pas, que está causando o erro: else begin if NFSe.Servico.Valores.totTrib.indTotTrib <> indSim then Result.AppendChild(AddNode(tcStr, '#1', 'indTotTrib', 1, 1, 1, indTotTribToStr(NFSe.Servico.Valores.totTrib.indTotTrib), '')); end; ENTÃO a dica que deram aqui neste tópico, mesmo que pareça estranha, deve resolver o problema por enquanto: NFSe.Servico.Valores.totTrib.indTotTrib:= indSim;

Estou com o mesmo problema. Até ontem, 10/02/2026, as notas foram autorizadas com sucesso, mas hoje, 11/02/2026, o emissor Nacional deve ter atualizado alguma regra e passou a rejeitar. <totTrib> <indTotTrib>0</indTotTrib> </totTrib> Ë um comportamento que o ACBr apresenta desde que implementei esse tipo de nota, lá no final de 12/2025. Quanto existe algum tributo federal (como IR, PIS, COFINS, ou CSLL) ou municipal (ISS), esse grupo sai os totais federal. municipal ou estadual (conforme o caso) e sai o total dos tributos. Mas quando não existe nenhum tributo, em qualquer uma das 3 esferas, ele sempre saiu com apenas o total zerado, igual acima, e não dava erro até ontem. Agora passou a dar erro. Se não existir nenhum tributo federal, estadual ou municipal informado, esse grupo sequer deve constar no XML.

Boa noite. Estou com o mesmo problema, mas estou seguindo o exemplo que vem junto com o ACBrNFSeX: procedure TfrmACBrNFSe.btnEventoCancPorSubPNClick(Sender: TObject); var xTitulo, xChaveNFSe, xCodigo, xMotivoCanc, xChaveSub: String; InfEvento: TInfEvento; begin xTitulo := 'Evento de Cancelamento Por Substituição'; xChaveNFSe := ''; if not(InputQuery(xTitulo, 'Chave da NFS-e:', xChaveNFSe)) then exit; xCodigo := '1'; if not(InputQuery(xTitulo, 'Código de Cancelamento:', xCodigo)) then exit; xMotivoCanc := 'Motido do Cancelamento da nota'; if not(InputQuery(xTitulo, 'Motivo do Cancelamento:', xMotivoCanc)) then exit; xChaveSub := ''; if not(InputQuery(xTitulo, 'Chave da NFS-e Substitutiva:', xChaveSub)) then exit; InfEvento := TInfEvento.Create; try with InfEvento.pedRegEvento do begin tpAmb := ACBrNFSeX1.Configuracoes.WebServices.AmbienteCodigo; verAplic := 'ACBrNFSeX-1.0'; dhEvento := Now; chNFSe := xChaveNFSe; nPedRegEvento := 1; tpEvento := ACBrNFSeXConversao.teCancelamentoSubstituicao; cMotivo := StrToIntDef(xCodigo, 1); xMotivo := xMotivoCanc; chSubstituta := xChaveSub; end; ACBrNFSeX1.EnviarEvento(InfEvento); finally InfEvento.Free; end; ChecarResposta(tmEnviarEvento); end; Neste exemplo, em lugar algum ele preenche as tags de substituição, nem na nota de origem, nem na nota de destino, trabalha apenas com as duas chaves da nota fiscal. Por isso eu imagino que a substituição é feita lá no ambiente nacional, não por aqui. Será que esse exemplo está desatualizado? Quanto a questão de abrir suporte com o provedor nacional, tem um e-mail sim, que vai com cópia para a prefeitura local, mas já enviei mais de 5 mensagens para eles, e nunca recebi resposta de nenhum deles. E é um e-mail destinado exclusivamente a desenvolvedores, imagine se não fosse. Obrigado.

Bom dia. Aparentemente o problema era no ambiente nacional, produção restrita. Depois de 2 dias tentando, hoje tentei enviar novamente e as notas foram autorizadas, da forma que o ACBr gerou, não precisei alterar nada, deu tudo certo. Podem finalizar esse ticket, por favor, e desculpe pelo transtorno. Obrigado.

Saudações a todos. Peço a ajuda dos colegas, pois já venho quebrando a cabeça com isso a dias, e não encontro a solução. Somos uma empresa de Jornais impressos, então temos imunidade constitucional a diversos tributos, inclusive os da reforma tributária (IBS/CBS). Nossas notas fiscais são de SERVIÇO (NFS-e) e, apartir do dia 01/01/2026, a nossa prefeitura deixará de emitir notas e passará a adotar o emissor nacional. Eu já consegui configurar e enviar com sucesso diversas notas, para o provedor nacional, utilizando o ACBrNFSeX, mas me deparei com um problema quando tentei adicionar a tag IBSCBS ao XML (obrigatórias a partir de 01/2026). Como somos IMUNES, nosso CST=410, e o cClasTrib=410008. Só que o único lugar que encontrei para informar isso, foi em: ACBrNFSeX1.IBSCBS.Valores.trib.gIBSCBS.CST := TCSTIBSCBS.cst410; // Imunidade e não Incidência ACBrNFSeX1.IBSCBS.Valores.trib.gIBSCBS.cClassTrib := '410008'; Mas dessa forma o meu XML fica errado, porque o ACBr está levando as informações dentro do grupo gIBSCBS: <IBSCBS> <finNFSe>0</finNFSe> <indFinal>1</indFinal> <cIndOp>100101</cIndOp> <indDest>0</indDest> <valores> <trib> <gIBSCBS> <CST>410</CST> <cClassTrib>410008</cClassTrib> </gIBSCBS> </trib> </valores> </IBSCBS> A forma correta que ele deveria gerar, seria assim: <IBSCBS> <finNFSe>0</finNFSe> <indFinal>1</indFinal> <cIndOp>100101</cIndOp> <indDest>0</indDest> <valores> <trib> <CST>410</CST> <cClassTrib>410008</cClassTrib> </trib> </valores> </IBSCBS> Quando eu tento transmitir a nota para o provedor Nacional, utilizando a versão 1.01, se eu transmitir a nota com as tags da forma que é gerado no primeiro exemplo, depois de mais de 10 segundos (precisei aumentar muito o timeout para ter esse retorno), recebo a mensagem de erro "RNG9999 - Erro não catalogado". Se eu remover o grupo IBSCBS do XML, não parametrizar mais ele, e transmitir a nota, ela é processada com sucesso, então o problema está relacionado a esse grupo, e acredito que a causa seja o grupo gIBSCBS, que não deveria ser gerado nesse caso. Será que alguém pode me dar uma luz para elucidar esse problema? Pesquisei aqui no fórum que outra pessoa teve exatamente o mesmo problema, aí outro usuário postou apenas um print do XML dele sendo gerado da forma correta, e o post foi finalizado logo após isso, acreditando que o problema havia sido resolvido. Mas não foi dada nenhuma solução naquele post. Atenciosamente, Francis Lay L. Silva

Da mesma forma que seria feita com o Lazarus, que não tem nem ClientDataSet ou FireDac. Adaptar. No caso do Delphi, é bem mais simples, um #IFDEF resolve o caso, basta checar a versão do compilador. Para compiladores mais recente, poderia utilizar o FireDac sem acoplamento, para versões mais antigas permanece utilizando o ClientDataSet, mas corrigindo a clausula Uses para incluir a MidasLib. Mas se quiser simplesmente incluir a MidasLib na cláusula uses, não tem problema algum, vai atender todo mundo, e ninguém vai precisar ficar ajustando e recompilando o fonte a cada atualização. Só sugeri o FireDac porque o MidasLib realmente vai exigir a presença do midas.dll, senão vai dar erro em tempo de execução, e até que alguém se atente que o problema foi ocasionado por um relatório de boleto, quanto tempo vai perder nisso? Concorda?

Olá. Identifiquei um problema na unit ACBrBoletoFCFR.pas, a princípio com o Delphi 12 (não testei as versões anteriores), onde ao colocar o componente no formulário, é disparado o erro "Invalid Parameter". Analisando o arquivo fonte dessa unit, identifiquei que o erro ocorre em todas as linhas onde haja o comando <dataseXXXt>.CreateDataSet. O problema ocorre porque se faz necessário declarar a unit MidasLIb no uses do módulo. Fazendo isso, o componente volta a funcionar normalmente. ENTRETANTO, isso cria uma dependência enorme da distribuição da midas.dll. O componente TClientDataSet é utilizado aqui apenas para a criação de um dataset somente em memória, sem uma tabela física. Eu acredito que o TClientDataSet possa ser substituido pelo TFDMemTable, do Firedac, que não cria dependências externas. Peço então aos mantenedores do projeto, que deem uma atenção para esse assunto e, se possível, possam realizar a correção da unit incluindo o MidasLib na sua cláusula Uses, ou realizando a substituição do TClientDataSet pelo TFDMemTable. Desde já agradeço pela cordial atenção. Francis Lay L. Silva

Hoje, 15/01/2022, estou com o mesmo problema após fazer o download da build 24277 do repositório SVN. Ele abre o instalador, fala que o arquivo de parâmetros de instalação anterior é incompatível e pede permissão para excluir ele, exclui o arquivo, pede todos os parâmetros novamente, seleciona os pacotes, e no momento que vai começar a instalação já dá de cara esse mesmo erro. Não é a minha instalação do Delphi, porque se eu recompilar a minha build anterior, a 63271, ele compila normalmente. Delphi 10.4 Sydney.

Até o momento sim, com exceção do módulo que usa o Indy que foi preciso desativar no arquivo .inc. Fora isso tudo tranquilo.

Logo após ter postado o problema acima lembrei-me de um fato que ocorria sempre antigamente com os packages do Quickreport na época que eram utilizados no AcBr: sempre que lançavam uma versão nova NUNCA atualizavam os packages do Quickreport para a nova IDE. Então fui verificar os DPK para o FastReport e BINGO, lá estava o mesmo problema. Quem quiser resolver esse problema até que o Trunk seja atualizado basta acrescentar a linha abaixo no final de TODOS os DPK para o FastReport: {$IFDEF VER330} fs26, frx26, frxe26, frxDB26, dsnap, {$ENDIF} // Rio Problema resolvido. Se puderem conserta os packages para a próxima atualização ficamos tremendamente gratos. Obrigado.

Olá. Baixe a compilei a versão Rio do acBr2. A compilação e instalação dos packages é feita sem erros, mas quando abro o Delphi TODOS os packages de relatórios do fastreport dão os seguinte erros: Os outros dois packages restantes dão o mesmo erro 'Datasnap.Midas'. Alguém tem alguma ideia de qual seja o problema? Eu só utilizo o FR para relatórios. No Delphi 10.2 está normal. Grato.

O problema é com o Windows 7, ele não encontra as libs mesmo elas estando no path. A solução que encontrei e que funcionou foi copiar todos os BPLs depois de compilados para a pasta $(BDSCOMMONDIR)\BPL, aí funcionou e instalou todos os componentes normalmente. O único problema é lembrar de excluir as BPLs dessa pasta antes de compilar uma nova versão do trunk, e depois copiar novamente para ela.

2 anos desde a última resposta para esse problema e ele ainda continua um mistério. Estou montando uma máquina com o Windows 7 64-bits e está dando exatamente o mesmo erro. Tanto pelo instalador quanto pela compilação manual todos os packages são compilados sem nenhum erro, mas quando são adicionados ao Delphi todos eles sem exceção dão esse mesmo erro "o dispositivo não está pronto". Não são arquivos velhos (o HD é novo; primeira instalação), é a ultima versão atualmente no repositório (revisão 15894) e no Windows 10 instala normalmente. Só no Windows 7 que não. Afinal de contas, qual é realmente a origem do problema? Alguém já conseguiu identificar isso com certeza? Grato a todos.

Olá, existe algum exemplo de como pegar o retorno da Carta de Correção utilizando os eventos ? Não estou muito familiarizado com o acBr ainda.

Olá, atualizei o meu repositório para revisão 6840 e ao executar o ACBrInstall.exe percebi que o pacote "ACBr_SAT_Extrato_ESCPOS.dpk" não aparece na tela para ser selecionado e instalado. Abri os fontes do ACBrInstall e constatei que o pacote aparece normalmente no form. Compilei então o projeto e executei, e o pacote ficou disponível para instalação. Conclusão, falta apenas atualizar o executável do instalador para a próxima revisão. Obrigado.

Finalmente consegui encontrar os fontes, o download é feito através de SVN. Para quem não conhece o endereço do repositório (como eu não conhecia) é https://svn.code.sf.net/p/fortesreport/svn/

O problema é que não encontro os fontes do FortesReport, todos os arquivos que baixo do Source Forge ou do site do FortesReport vem já compilados, apenas as dcu's.

O único extrato disponível para o SAT foi feito utilizando o FortesReport, entretanto este componente parou de ser atualizado na versão XE3 do Delphi, não consigo encontrar uma versão para o XE5 e por isso não consigo compilar o componente de extrato do SAT. Existe alguma versão deste extrato para o FastReport ou QuickReport? Se não houver tem algum projeto para lançar estes componentes? Obrigado.

Obrigado pela informação, ficamos no aguardo então deste novo instalador.

Eu fiz a alteração no ACBrInstall para instalar os pacotes da GNRE, mas não tenho acesso a atualizar o repositório. Será que algum moderador pode validar a minha atualização e atualizar o repositório? Os arquivos estão em anexo. Obrigado.NewACBRInstall.rar

Saudações a todos. Fiz a atualização do meu repositório local dos fontes do ACBr para a revisão 6330 e percebi que novos fontes e packages foram adicionados na pasta chamada ACBrGNRE. Entretanto, apesar de existirem packages específicos para compilar estas novas rotinas, o instalador do ACBr não os compila e portanto não gera as suas BPL's. Estes novos pacotes são linkados automaticamente com outros pacotes já existentes ou eu devo compilá-los manualmente? Obrigado pela ajuda.

Muito obrigado.