Painel de líderes

Olá Pessoal, A partir de hoje (10/12/2025) o ambiente de homologação (produção restrita como eles chamam) passou a aceitar somente a versão 1.01 Se tentar enviar na versão 1.00 vai ocorrer um erro acusando que a versão 1.00 é invalida. Erro(s): Código : RNG6110 Mensagem: Falha Schema Xml Correção: The 'versao' attribute is invalid - The value '1.00' is invalid according to its datatype 'http://www.sped.fazenda.gov.br/nfse:TVerNFSe' - The Pattern constraint failed. Sendo assim ao configurar a propriedade LayoutNFSe do componente para as cidades que aderiram a emissão da NFS-e Padrão Nacional devemos usar a opção lnfsPadraoNacionalv101. Com a versão 1.01 vai ser possível realizar teste com os novos campos da Reforma Tributária. Essa configuração é para as cidades que aderiram a emissão da NFS-e Padrão Nacional. As cidades que vão continuar com os seus provedores devemos manter a propriedade LayoutNFSe com o valor lnfsProvedor.

Olá Pessoal, Essa é uma boa pergunta. E a resposta é muito simples esta pronto e não esta pronto. Como assim? Até o momento temos a NT 2025/004 que traz as alterações no layout da NFS-e Padrão Nacional para a Reforma Tributária, mas não temos Manuais dos provedores que seguem a versão 1 do layout da ABRASF nem dos que seguem a versão 2 e nem dos provedores que tem layout próprio. O que temos pronto no ACBrNFSeX? Implementação dos novos grupos e campos visando a Reforma Tributária para o Padrão Nacional. Sendo assim através do programa exemplo é possível gerar o XML do DPS (Declaração de Prestação de Serviço), mas ao fazer isso vai ocorrer erro de validação. O motivo do erro é que os Schemas que temos não contempla os novos grupos e campos da Reforma Tributária. E o ambiente de homologação que a Receita Federal chama de Produção Restrita não foi alterado para aceitar os novos grupos e campos. Resumindo. Já esta no SVN as alterações no componente ACBrNFSeX para gerar o XML do DPS (Padrão Nacional) com os novos campos. Não vai ser possível validar e nem enviar para o ambiente de homologação. Assim que tivermos mais noticias sobre a Reforma Tributária na NFS-e, vamos divulgar.

Olá comunidade ! É com grande alegria que informamos que os novos eventos relacionados a Reforma Tributária foram implementados no ACBrNFe! Ao todo, foram adicionados 15 novos eventos que cujo autor pode ser o emitente, o destinatário ou a empresa sucessora. Um agradecimento a todos os membros da comunidade que enviaram contribuições de implementação. Os programas de exemplo nativos tanto para Delphi quanto para Lazarus foram atualizados para exemplificar cada um dos exemplos. Eles podem ser encontrados: ..\trunk2\Exemplos\ACBrDFe\ACBrNFe\Delphi ..\trunk2\Exemplos\ACBrDFe\ACBrNFe\Lazarus Se você utiliza ACBrMonitorPLUS ou ACBrLib, não se preocupe! A documentação de ambos também foi atualizada adicionando exemplos de INI para cada um dos novos eventos: Exemplos de INI dos eventos da Reforma Tributária para ACBrLib Exemplos de INI dos eventos da Reforma Tributária para ACBrMonitorPLUS Vale reforçar que tanto o ACBrMonitorPLUS quanto a ACBrLib deverão ser de compilações posteriores a 24/11/2025 para englobar os eventos, portanto, é importante que você mantenha seu Monitor ou Lib atualizados!

Olá Pessoal, Com a Reforma Tributária temos novas opções de emissão de NF-e, vamos tentar entender como funciona essa tal de nota de Débito ou Crédito. Na Nota Técnica 2025/002 versão 1.20 no final da página 7 temos o item 4 que traz: 4. Finalidade Débito e Finalidade Crédito da NF-e Notas de Débito e Crédito são nomes de instrumentos utilizados mundialmente para documentar situações contábeis onde é necessário corrigir informações comerciais que foram registradas em um documento, que no Brasil é a Nota Fiscal. Esta Nota Técnica cria na NF-e modelo 55 as finalidades de emissões correspondentes. O sentido das palavras “débito” e “crédito” sempre se referem ao ponto de vista do emissor: • Uma nota de débito documenta uma situação na qual o emitente registra um aumento no imposto devido (consequentemente, uma redução no imposto devido pelo adquirente, que é o destinatário); • Uma nota de crédito documenta uma situação na qual o emitente registra uma redução no imposto devido (consequentemente, um aumento no imposto devido pelo adquirente, que é o destinatário); As finalidades de emissão “Nota de Ajuste” e “Nota Complementar”, já existentes, são casos especiais de Nota de Débito; uma nota de entrada emitida para documentar, por exemplo, a devolução de mercadoria que havia sido vendida a um consumidor final, é um caso especial de Nota de Crédito. A regulamentação do IBS disporá sobre a utilização de notas de crédito e notas de débito para lançamentos de ajuste, com a finalidade de instrumentalizar a preparação da declaração assistida a ser oferecida para os contribuintes, de maneira automatizada, a partir de documentos fiscais eletrônicos, em cumprimento ao que preconiza a LC 214/2025. A menos que ocorra alteração na regulamentação do ICMS e do IPI, notas de crédito e notas de débito não poderão ser utilizadas para ajustes relativos a estes tributos. O campo finNFe agora passa a ter as opções: 5=Nota de crédito; 6=Nota de débito; Portanto se a minha intenção é emitir uma NF-e de Crédito o valor de finNFe tem que ser 5, por outro lado se a intenção é emitir uma NF-e de Débito o valor de finNFe tem que ser 6. Temos agora que especificar o tipo da nota de Débito ou de Crédito através dos novos campos tpNFDebito e tpNFCredito. Devemos ter em mente que uma nota só pode ser de Débito ou de Crédito jamais vai ser de Débito e Crédito. Valores aceitos pelo campo tpNFDebito: 01=Transferência de créditos para Cooperativas; 02=Anulação de Crédito por Saídas Imunes/Isentas; 03=Débitos de notas fiscais não processadas na apuração; 04=Multa e juros; 05=Transferência de crédito de sucessão; 06 = Pagamento antecipado 07 = Perda em estoque Valores aceitos pelo campo tpNFCredito: 01 = Multa e juros 02 = Apropriação de crédito presumido de IBS sobre o saldo devedor na ZFM (art. 450, § 1º, LC 214/25) 03 = Retorno (regra de validação: B25-80) Uma nota de Débito ou Crédito não podem conter informações de: ICMS (tag: ICMS), ISSQN (tag: ISSQN), IPI (tag: IPI), II (tag: II), PIS (tag: PIS), PIS ST (tag: PISST), COFINS (tag: COFINS), COFINS ST (tag: COFINSST), ICMS UF Destino (tag: ICMSUFDest) ou Imposto Devolvido (tag: impostoDevol). Uma NFC-e (modelo 65) não permite nota de Débito ou Crédito, esses dois tipos de notas estão restritas ao modelo 55 ou seja NF-e. (regra de validação: UB106-31) Temos um novo gruo chamado gTransfCred que só deve ser gerado se a de nota de Débito tiver o tpNFDebito for 01 ou 05. O grupo gTransfCred só deve ser gerado se o CST / cClassTrib informado o permitir. (regra de validação: VC02-10) Se tpNFDebito for 03 ou 04 devemos gerar o novo grupo DFeReferenciado. (regra de validação: 3BA02-70) Uma nota de crédito de multa/juros, tpNFCredito igual a 01 ou 03 tem que referenciar uma NF-e autorizada e não pode estar cancelada. (regra de validação: B25-30) Se tpNFCredito for 01 ou 03 devemos gerar o novo grupo DFeReferenciado. A nota de Débito ou Crédito não é simples, possui muitas regras de validação, vai ser natural levarmos uma rejeição logo na primeira nota, mas de posse da NT em mãos para buscar um entendimento sobre a rejeição e sanar o problema vai ser o caminho. Tudo é muito novo para nós desenvolvedores e para os contadores, o jeito vai ser dar as mãos e tentarmos buscar a melhor implementação. Não sou contador, sou desenvolver, mas busco sempre as respostas nos Manuais, Notas Técnicas e longas conversas com os contadores. Espero que esse texto possa ajudar um pouco com esses dois tipos de notas.

Olá Pessoal, Tenho boas noticias para vocês que utilizam o componente ACBrNFSeX, o ACBrLibNFSe e o ACBrMonitor para emitir suas NFS-e. Hoje (02/03/2026) foi enviado para o SVN a implementação em Fortes Report para a impressão do DANFSE segundo o layout do Padrão Nacional. Foi também implementado uma nova propriedade de configuração para que possamos informar o caminho e o nome da imagem referente ao logo da NFS-e. Sendo assim temos as propriedades Logo para informar o caminho e o nome da imagem do logo da prefeitura e agora a propriedade LogoNFSe para o logo da NFS-e. Foi disponibilizado também na pasta Delphi e Lazarus dos programas exemplos o arquivo JPG referente ao Logo da NFS-e. Qual quer problema por favor crie um tópico no fórum relatando o problema encontrado. Detalhe importante, o XML a ser carregado para poder gerar o DANFSE no Padrão Nacional obrigatoriamente tem que estar no layout da NFS-e Padrão Nacional, caso contrario não vai funcionar. Como temos uma nova propriedade de configuração "LogoNFSe", ela vai ter que ser disponibilizada também na Lib e Monitor, sendo assim por favor aguarde uma nova versão dessas outras duas soluções ACBr.

Olá Pessoal, Os componentes ACBrCTe, ACBrNFe e ACBrMDFe possuem o método DistribuicaoDFePorNSU, DistribuicaoDFePorUltNSU e DistribuicaoDFePorChaveNFe (somente o ACBrNFe) deixam de usar as units: pcnDistDFeInt (responsável por montar o XML da consulta) e pcnRetDistDFeInt (responsável por ler o retorno) e passam a utilizar as novas units: ACBrDFeComum.DistDFeInt e ACBrDFeComum.RetDistDFeInt com a mesma finalidade das antigas, como uma diferença a nova unit responsável pela leitura do retorno se utiliza as rotinas do ACBrXmlDocument que já foi comprovado a sua velocidade em relação as rotinas do pcnLeitor. A priori vocês não vão precisar mudar nada nas suas aplicações, apenas atualizar todos os fontes de todas as pastas, reinstalar o ACBr com a opção de usar o ACBrXmlDocument marcada e por fim compilar a aplicação com a opção Build. Se por acaso na aplicação tiver uma linha semelhante a abaixo vai ter que fazer uma pequena alteração. Como esta hoje: ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.Leitor.CarregarArquivo(OpenDialog1.FileName); Como deve ficar a partir da atualização dos fontes: ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.CarregarArquivo(OpenDialog1.FileName); Como vocês podem ver basta remover o "Leitor." para que ocorra a compilação da aplicação.

Olá Pessoal, É com muita alegria que venho informa-los que o componente ACBrNFSeX na data de hoje (06/08/2025) atingiu a marca de 3847 cidades atendidas, isso equivale a 69,05 % de um total de 5571 cidades. Quero agradecer a todos os membros do Fórum e do Discord que nos ajudam diariamente com as suas contribuições nos informando as cidades que trocaram de provedor, que trocaram de URL e é claro as vinculações de cidades a provedores, permitindo assim a emissão de NFS-e para essas cidades. O meu muito obrigado a todos, desde aquele que contribui com apenas uma cidade até aquele que contribui com dezenas de cidades. Sem vocês não chegaríamos a essa marca. São vocês que fazem com que não só o componente ACBrNFSeX, mas também o ACBrLibNFSe e o ACBrMonitor Plus nos permitissem atender 69,05 % das cidades brasileiras. O crédito é todo de vocês, mais uma vez o meu muito obrigado. Estatística por UF e a quantidade de cidades que já adotaram o Padrão Nacional. AC: 021 de 022 ( 95,45 % ) AL: 034 de 102 ( 33,33 % ) AP: 007 de 016 ( 43,75 % ) AM: 012 de 062 ( 19,35 % ) BA: 238 de 417 ( 57,07 % ) CE: 050 de 184 ( 27,17 % ) DF: 001 de 001 ( 100,00 % ) ES: 076 de 078 ( 97,44 % ) GO: 223 de 246 ( 90,65 % ) MA: 084 de 217 ( 38,71 % ) MT: 117 de 142 ( 82,39 % ) MS: 063 de 079 ( 79,75 % ) MG: 709 de 853 ( 83,12 % ) PA: 087 de 144 ( 60,42 % ) PB: 098 de 223 ( 43,95 % ) PR: 312 de 400 ( 78,00 % ) PE: 095 de 185 ( 51,35 % ) PI: 065 de 224 ( 29,02 % ) RJ: 090 de 092 ( 97,83 % ) RN: 060 de 167 ( 35,93 % ) RS: 427 de 497 ( 85,92 % ) RO: 041 de 052 ( 78,85 % ) RR: 009 de 015 ( 60,00 % ) SC: 285 de 294 ( 96,94 % ) SP: 527 de 645 ( 81,71 % ) SE: 018 de 075 ( 24,00 % ) TO: 098 de 139 ( 70,50 % ) 0012 adotaram o Padrão Nacional Veja como você pode colaborar:

Olá pessoal! Foram enviados ao SVN ajustes que adicionam uma nova funcionalidade ao componente ACBrNFe: a leitura e geração de arquivos JSON a partir dos dados de uma NFe, bem como a leitura de arquivos JSON contendo os dados de eventos. O JSON (JavaScript Object Notation) é um formato leve de troca de dados, bastante utilizado em APIs modernas pela sua simplicidade de leitura e facilidade de integração com diferentes linguagens e plataformas. A adição dessa funcionalidade no componente traz diversas vantagens, como maior flexibilidade para importar e exportar informações fiscais em um formato amplamente aceito, integração facilitada com sistemas externos (web, mobile ou nuvem) e apoio em testes e automações sem a necessidade de manipular apenas XML Essa nova funcionalidade está disponível por meio dos seguintes métodos: ACBrNFe.NotasFiscais.LoadFromJSON: Procedure que recebe como parâmetro um arquivo JSON contendo os dados que compõem a NFe/NFCe, ou o caminho para esse arquivo. ACBrNFe.NotasFiscais.GerarJSON: Function que retorna uma string em formato JSON com os dados de uma NFe/NFCe. ACBrNFe.EventoNFe.LerFromJSON: Procedure que recebe como parâmetro um arquivo JSON contendo os dados que compõem o evento, ou o caminho para esse arquivo. Visando trazer maior familiaridade para os desenvolvedores que utilizarem essas rotinas, os arquivos JSON gerados e lidos por elas foram construídos seguindo a mesma nomenclatura e estrutura do leiaute oficial da NFe e dos eventos. Dessa forma, quem já está habituado a trabalhar com os XMLs da NFe perceberá que a adaptação para o JSON é simples e direta. Tomemos este XML de uma NFCe gerado com dados fictícios, por exemplo: <NFe xmlns="http://www.portalfiscal.inf.br/nfe"> <infNFe Id="NFe35240892390477000149650010000000011919433382" versao="4"> <ide> <cUF>35</cUF> <cNF>91943338</cNF> <natOp>VENDA</natOp> <indPag>0</indPag> <mod>65</mod> <serie>1</serie> <nNF>1</nNF> <dhEmi>2024-08-14T16:54:00.000Z</dhEmi> <tpNF>1</tpNF> <idDest>1</idDest> <cMunFG>3505203</cMunFG> <tpImp>4</tpImp> <tpEmis>1</tpEmis> <cDV>2</cDV> <tpAmb>2</tpAmb> <finNFe>1</finNFe> <indFinal>1</indFinal> <indPres>1</indPres> <procEmi>0</procEmi> <verProc>ACBr-Monitor</verProc> </ide> <emit> <CNPJ>92390477000149</CNPJ> <xNome>RAZAO SOCIAL</xNome> <xFant>FANTASIA</xFant> <IE>449301071500</IE> <CRT>3</CRT> <enderEmit> <xLgr>LOGRADOURO</xLgr> <nro>1</nro> <xCpl>COMPLEMENTO</xCpl> <xBairro>BAIRRO</xBairro> <cMun>3505203</cMun> <xMun>BARIRI</xMun> <UF>SP</UF> <CEP>12345678</CEP> <cPais>1058</cPais> <xPais>BRASIL</xPais> <fone>11111111</fone> </enderEmit> </emit> <det nItem="1"> <prod> <cProd>123456</cProd> <cEAN>7896523206646</cEAN> <cBarra>ABC123456</cBarra> <xProd>NOTA FISCAL EMITIDA EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL</xProd> <NCM>94051010</NCM> <CEST>1111111</CEST> <CFOP>5101</CFOP> <uCom>UN</uCom> <qCom>1</qCom> <vUnCom>100</vUnCom> <vProd>100</vProd> <cEANTrib>7896523206646</cEANTrib> <cBarraTrib>ABC123456</cBarraTrib> <uTrib>UN</uTrib> <qTrib>1</qTrib> <vUnTrib>100</vUnTrib> <vFrete>0</vFrete> <vSeg>0</vSeg> <vDesc>0</vDesc> <vOutro>0</vOutro> <indTot>1</indTot> </prod> <imposto> <vTotTrib>0</vTotTrib> <ICMS> <ICMS00> <orig>0</orig> <CST>00</CST> <modBC>3</modBC> <vBC>100</vBC> <pICMS>18</pICMS> <vICMS>1800</vICMS> </ICMS00> </ICMS> <IPI> <IPITrib> <CST>00</CST> <vBC>0</vBC> <pIPI>0</pIPI> <vIPI>0</vIPI> </IPITrib> </IPI> <PIS> <PISOutr> <CST>99</CST> </PISOutr> </PIS> <COFINS> <COFINSOutr> <CST>99</CST> </COFINSOutr> </COFINS> </imposto> </det> <total> <ICMSTot> <vBC>100</vBC> <vICMS>1800</vICMS> <vProd>100</vProd> <vNF>100</vNF> <vTotTrib>0</vTotTrib> </ICMSTot> </total> <transp> <modFrete>9</modFrete> </transp> <pag> <detPag> <tPag>01</tPag> <vPag>100</vPag> </detPag> </pag> <infAdic> <obsCont> <xCampo>ObsCont</xCampo> <xTexto>Texto</xTexto> </obsCont> <obsFisco> <xCampo>ObsFisco</xCampo> <xTexto>Texto</xTexto> </obsFisco> </infAdic> </infNFe> <infNFeSupl> <qrCode>https://www.homologacao.nfce.fazenda.sp.gov.br/qrcode?p=|2|2|1|EA3AA74775103726161ECA855F5C17EDC996517A</qrCode> <urlChave>https://www.homologacao.nfce.fazenda.sp.gov.br/consulta</urlChave> </infNFeSupl> </NFe> Seu JSON equivalente seria: { "NFe": { "infNFe": { "Id": "NFe35240892390477000149650010000000011919433382", "versao": "4", "ide": { "cUF": 35, "cNF": 91943338, "natOp": "VENDA", "mod": 65, "serie": 1, "nNF": 1, "dhEmi": "2024-08-14T16:54:00.000Z", "tpNF": "1", "idDest": "1", "cMunFG": 3505203, "tpImp": "4", "tpEmis": "1", "cDV": 2, "tpAmb": "2", "finNFe": "1", "indFinal": "1", "indPres": "1", "procEmi": "0", "verProc": "ACBr-Monitor" }, "emit": { "CNPJ": "92390477000149", "xNome": "RAZAO SOCIAL", "xFant": "FANTASIA", "IE": "449301071500", "CRT": "3", "enderEmit": { "xLgr": "LOGRADOURO", "nro": "1", "xCpl": "COMPLEMENTO", "xBairro": "BAIRRO", "cMun": 3505203, "xMun": "BARIRI", "UF": "SP", "CEP": 12345678, "cPais": 1058, "xPais": "BRASIL", "fone": "11111111" } }, "det": [ { "nItem": 1, "prod": { "cProd": "123456", "cEAN": "7896523206646", "cBarra": "ABC123456", "xProd": "NOTA FISCAL EMITIDA EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL", "NCM": "94051010", "CEST": "1111111", "CFOP": "5101", "uCom": "UN", "qCom": 1, "vUnCom": 100, "vProd": 100, "cEANTrib": "7896523206646", "cBarraTrib": "ABC123456", "uTrib": "UN", "qTrib": 1, "vUnTrib": 100, "indTot": "1" }, "imposto": { "vTotTrib": 0, "ICMS": { "ICMS00": { "orig": "0", "CST": "00", "modBC": "3", "vBC": 100, "pICMS": 18, "vICMS": 1800 } }, "IPI": { "IPITrib": { "CST": "00", "vBC": 0, "pIPI": 0, "vIPI": 0 } }, "PIS": { "PISOutr": { "CST": "99" } }, "COFINS": { "COFINSOutr": { "CST": "99" } } } } ], "total": { "ICMSTot": { "vBC": 100, "vICMS": 1800, "vProd": 100, "vNF": 100, "vTotTrib": 0 } }, "transp": { "modFrete": "9" }, "pag": { "detPag": [ { "tPag": "01", "vPag": 100 } ] }, "infAdic": { "obsCont": [ { "xCampo": "ObsCont", "xTexto": "Texto" } ], "obsFisco": [ { "xCampo": "ObsFisco", "xTexto": "Texto" } ] } }, "infNFeSupl": { "qrCode": "https://www.homologacao.nfce.fazenda.sp.gov.br/qrcode?p=|2|2|1|EA3AA74775103726161ECA855F5C17EDC996517A", "urlChave": "https://www.homologacao.nfce.fazenda.sp.gov.br/consulta" } } } Observem que os nomes das chaves correspondem exatamente ao nome das tags e os níveis das tags foram representados de maneira semelhante no JSON. É a mesma coisa para os eventos, vejam um exemplo de JSON de um evento de cancelamento: { "envEvento": { "idLote": "123456789012345", "evento": [ { "versao": "1.00", "infEvento": { "cOrgao": "35", "tpAmb": "2", "CNPJ": "11111111000111", "chNFe": "35240111111111000111550010000001231000001234", "dhEvento": "2024-07-29T10:00:00-03:00", "tpEvento": "110111", "nSeqEvento": "1", "versaoEvento": "1.00", "detEvento": { "versao": "1.00", "descEvento": "Cancelamento", "nProt": "135240000000123", "xJust": "A operacao foi cancelada por motivos comerciais." } } } ] } } Se compararmos, essa estrutura é semelhante ao leiaute apresentado no MOC e ao XML de envio gerado. Vale reforçar que, apesar da nova funcionalidade, o XML é o documento fiscal eletrônico oficial e deve ser armazenado para fins fiscais. Contamos com a colaboração de todos para testar as rotinas e reportar quaisquer problemas encontrados. Sua participação é essencial para aprimorarmos as soluções para toda a comunidade. Até a próxima pessoal.

O Projeto ACBr acaba de dar mais um passo importante em sua trajetória de apoiar desenvolvedores de software em todo o Brasil: foram publicados os primeiros pacotes NPM oficiais das ACBrLib. O time ACBr agradece ao empenho e dedicação do consultor @danieloliveirasouza responsável por essa contribuição! A novidade permite que desenvolvedores Node.js utilizem de forma prática e direta as bibliotecas do ACBr em seus projetos, ampliando ainda mais as possibilidades de integração com soluções fiscais, comerciais e automação de processos. Os pacotes já estão disponíveis no NPM: Projeto ACBr no NPM Instale o pacote @projetoacbr/acbrlib-cep-node npm install @projetoacbr/acbrlib-cep-node Com poucos comandos, já é possível consumir as funcionalidades. Confira um exemplo utilizando a ACBrLibCEP (Este exemplo já está atualizado no nosso SVN): const path = require('path'); const os = require('os'); const ACBrLibCepMT = require('@projetoacbr/acbrlib-cep-node/dist/src').default const acbrlibPath = path.resolve(__dirname, os.platform() === 'win32' ? 'ACBrCEP64.dll' : 'libacbrcep64.so') const configPath = path.resolve(__dirname, 'config.ini') let acbrlibCep = new ACBrLibCepMT(acbrlibPath, configPath, '') let cep = '' try { acbrlibCep.inicializar() acbrlibCep.configGravarValor('CEP','WebService','3') acbrlibCep.configGravar() cep = acbrlibCep.buscarPorCep('18270170') console.log(cep) } catch (error) { console.error(error) } finally { if ( acbrlibCep) acbrlibCep.finalizar() } Esse lançamento marca o início de uma nova etapa para o ACBr, tornando suas bibliotecas ainda mais acessíveis e reforçando o compromisso do projeto em empoderar desenvolvedores com soluções robustas e confiáveis. Experimente agora mesmo e explore as possibilidades que os pacotes NPM do ACBr oferecem para seus projetos!

Olá pessoal, Por favor deem atenção. Como sabem estamos aos poucos saindo das units "pcn". E um dos passos para fazermos isso foi criar uma unit chamada ACBrDFe.Conversao.pas (Veja aqui sobre). Mas essa unit tinha alguns problemas e mudanças de comportamento indesejados então precisamos refazê-la. Isso pode quebrar o seu código e por isso precisamos de sua atenção. TL/DR: A unit ACBrDFe.Conversao.pas não é uma cópia da pcnConversao.pas com outro nome. A pcnConversao.pas ainda funciona, mas quando você for utilizar a ACBrDFe.Conversao.pas, vai precisar fazer ajustes! Ainda está aí? Beleza, agora vamos aos detalhes. Em primeiro lugar queremos deixar claro que ela vai continuar sendo parte da migração para fora das units "pcn*" em especial a pcnConversao.pas. Vamos resumir aqui no entanto algumas alterações que foram feitas: A constante LineBreak foi removida. Se você precisa dela no seu código, use a constante que já vem no Delphi/Lazarus SLineBreak. Diversos tipos foram renomeados. Listamos abaixo alguns: TpcnTipoCampo = TACBrTipoCampo; TpcnTagAssinatura = TACBrTagAssinatura; TpcnTipoImpressao = TACBrTipoImpressao; TpcnTipoEmissao = TACBrTipoEmissao; TpcnTipoAmbiente = TACBrTipoAmbiente; TpcnProcessoEmissao = TACBrProcessoEmissao; TpcnTpEvento = TACBrTipoEvento; TpcteModal = TModal; TpcnTipoNFe = TTipoNFe; TpcnOrigemMercadoria = TOrigemMercadoria; TpcnCSTIcms = TCSTIcms; TpcnCSOSNIcms = TCSOSNIcms; TpcnCstPis = TCSTPis; TpcnCstCofins = TCSTCofins; TpcteTipoRodado = TTipoRodado; TpcteTipoCarroceria = TTipoCarroceria; TpcnUnidTransp = TUnidTransp; TpcnUnidCarga = TUnidCarga; TpcteProp = TtpProp; TpcnindIEDest = TindIEDest; TpcnRegTribISSQN = TRegTribISSQN; TpcnindIncentivo = TindIncentivo; TpcnRegTrib = TRegTrib; TpcnindRatISSQN = TindRatISSQN; TpcnindRegra = TindRegra; TpcnCodigoMP = TCodigoMP; As funções de conversões de tipos enumerados foram refeitas para seguir o padrão "Try-Parse". Esse é um padrão comum em linguagens de programação (incluindo o Delphi com as funções TryStrToDate e StrToDate). A função que tem no nome o prefixo "Try" realiza a verificação de uma possível conversão sem lançar exceções, retornando um booleano para indicar se a conversão foi bem-sucedida e armazenando o resultado, em caso de sucesso, em um parâmetro de saída. A função que não tem esse prefixo, gera uma exception quando o tipo não puder ser convertido. Essa função que inicia com "Try" substitui a função anterior que tinha um parâmetro "ok". Um dos objetivos de usar esse padrão é porque muitas pessoas nem se dão conta que é preciso verificar o parâmetro "ok" antes de usar o resultado da função. Como sabemos disso? Bem, este tipo de uso é frequente em contribuições e até mesmo no código antigo do ACBr... Almejamos assim deixar o código mais claro. Por enquanto o seu código que usa a pcnConversao vai continuar funcionando. Mas vai retornar vários warnings. A ideia é que você possa ir corrigindo no seu tempo. Nós mesmo estamos usando e isso vai aumentar a quantidade de warnings gerados que você vê ao compilar os componentes ACBr ... Por outro lado, vamos modificar o código do ACBr para deixar de utilizar a unit pcnConversao internamente o quanto antes. Os hints/warnings estão sendo ajustados na unit pcnConversao.pas para refletir o que foi delineado aqui. E como sempre, fiquem a vontade para reportar quaisquer problemas, sugestões e melhorias. Obrigado pela atenção pessoal.

Em uma resposta simples e direta: SIM! Você deve enviar as informações do IBS e da CBS nas notas fiscais emitidas a partir de 2026. Isso é estabelecido na Lei Complementar 214/2025 que estabelece os preceitos da Reforma Tributária. Vide (grifo nosso): Mas e as notícias que eu vi? E quanto a nota técnica? É provável que você viu notícias com títulos como "Receita Federal prorroga IBS e CBS", "Prorrogada a obrigatoriedade do IBS e da CBS" ou até mesmo "Publicação desobriga o preenchimento do IBS e da CBS". Essas notícias costumam citar como fonte a publicação da Nota Técnica 2025/002 v1.33. Vamos conferir direto na fonte, o que diz a nota técnica: Observem que ela menciona (grifo nosso): "(...)não será exigido por regra de validação, porém permanece obrigatório conforme legislação vigente(...)". Quer dizer, não vai validar a presença desses campos por regra de validação, mas eles continuam sendo necessários e obrigatórios conforme a Lei Complementar 214/2025. Mas afinal, o que mudou então? A versão 1.33 da nota técnica definiu como implementação futura a regra de validação que obriga a presença do IBS e da CBS no XML no ambiente de produção. Na prática, isso significa que se em 2026, você não enviar essas informações no seu arquivo XML, você não vai receber como retorno a rejeição "cStat: 1115 Rejeição: IBS/CBS não informado". Mas isso não significa que o seu arquivo XML vai estar correto sem elas. Caso você já tenha adequado seu software e já esteja enviando as informações, as demais regras de validação relacionadas a reforma tributária que não estão definidas como "implementação futura" na NT serão aplicadas.

Olá Pessoal, Quanto mais eu rezo mais assombração aparece. Lá vamos nós ler a versão 1.20 da NT 2025/002 referente a Reforma Tributária da NF-e/NFC-e. Vamos a um resumo dela: Consta que somente a partir de 2027 as empresas do Simples Nacional e MEI ao emitir suas notas vão ter que informar as informações do IBS e CBS. Em uma nova NT vai ser detalhado essa obrigatoriedade para as empresas do SN e MEI. O campo tpNFCredito passa a ter um novo valor: 03 - Retorno. O grupo gIBSCBS passa a ter o campo vIBS que é o resultado de vIBSUF mais vIBSMun. O grupo gIBSCBSMono continha muitos campos, só que agora os campos foram distribuídos dentro dos grupos: gMonoPadrao, gMonoReten, gMonoRet e gMonoDif. Varias regras de validação foram alteradas. Já estamos trabalhando para deixar o componente ACBrNFe, a DLL ACBrLibNFe e o ACBrMonitor em conformidade com essa Nota Técnica.

Olá, comunidade ! Foi liberada a API de consulta ao projeto conformidade fácil. Essa API vai permitir a consulta das tabelas de CST e cClassTrib aplicando filtro por CST. A autenticação será feita através de certificados ICP-Brasil. Recomenda-se que não seja feito muito mais do que um Get diário para obter as informações. Novos recursos serão adicionados gradativamente. O endpoint para comunicação com a API é: https://cff.svrs.rs.gov.br/api/v1/consultas/classTrib Veja a notícia completa em: https://dfe-portal.svrs.rs.gov.br/Cff/Noticias

Olá comunidade ! Foi publicado no dia 22/12/2025 o Ato Conjunto RFB/CGIBS Nº 1, de 22 de Dezembro de 2025 trazendo novas informações importantes relacionadas a Reforma Tributária. Art. 1 Estabelece os documentos fiscais afetados que terão IBS e CBS, além do prazo para observância em 2026. Art. 2 Define que aqueles sujeitos ao IBS e a CBS deverão emitir documento fiscal eletrônico. § 1º Serão recepcionados os seguintes documentos fiscais para registro das operações sujeitas ao IBS e a CBS: I - Nota Fiscal Eletrônica - NF-e, modelo 55; II - Nota Fiscal de Consumidor Eletrônica - NFC-e, modelo 65; III - Nota Fiscal de Serviços Eletrônica - NFS-e; IV - Conhecimento de Transporte Eletrônico - CT-e, modelo 57; V - Conhecimento de Transporte Eletrônico Para Outros Serviços - CT-e OS, modelo 67; VI - Bilhete de Passagem Eletrônico - BP-e, modelo 63; VII - Manifesto Eletrônico de Documentos Fiscais - MDF-e, modelo 58; VIII - Guia de Transporte de Valores Eletrônica - GTV-e, modelo 64; IX - Nota Fiscal de Energia Elétrica Eletrônica - NF3e, modelo 66; X - Nota Fiscal Fatura de Serviços de Comunicação Eletrônica - NFCom, modelo 62; XI - Declaração de Conteúdo Eletrônica - DC-e; e XII - Nota Fiscal de Serviço Eletrônica de Exploração de Via - NFS-e Via. § 2º Serão instituídos os seguintes documentos fiscais eletrônicos para registro das operações sujeitas ao IBS e a CBS: I - Nota Fiscal de Água e Saneamento Eletrônica - NFAg, modelo 75; II - Declaração de Regimes Específicos - DeRE; III - Nota Fiscal Eletrônica de Alienação de Bens Imóveis - NF-e ABI, modelo 77; e IV - Nota Fiscal Eletrônica do Gás - NFGas, modelo 76. § 3º Estabelece que deverá ser respeitado as competências dos comitês gestores: I - do Comitê Gestor da Nota Fiscal de Serviço Eletrônica de padrão nacional - CGNFS-e, conforme art. 62, § 4º, da Lei Complementar nº 214, de 16 de janeiro de 2025; e II - do Comitê Gestor do Simples Nacional - CGSN, conforme art. 26 da Lei Complementar nº 123, de 14 de dezembro de 2006. § 4º Serão criadas normas específicas para operações de comércio exterior. Art. 3º Até o primeiro dia do quarto mês subsequente ao da publicação da parte comum dos regulamentos do IBS e da CBS: I - não haverá aplicação de penalidades pela falta de registro dos campos do IBS e da CBS nos documentos fiscais a que se refere o art. 1º, §§ 1º e 2º; e II - será considerado atendido o requisito para a dispensa do recolhimento do IBS e da CBS, previsto no art. 348, § 1º, da Lei Complementar nº 214, de 16 de janeiro de 2025. Parágrafo único. Sem prejuízo do disposto no caput, a apuração do IBS e da CBS no ano de 2026 será realizada em caráter meramente informativo, sem efeitos tributários, desde que cumpridas as obrigações acessórias previstas na legislação. Art. 4º O disposto neste Ato Conjunto não prejudica a exigência dos documentos fiscais relativos aos demais tributos vigentes, previstos nas legislações de regência. Art. 5º Este ato será publicado no Diário Oficial da União e entrará em vigor em 01/01/2026.

Com o advento da reforma tributária, os municípios são deixados com uma escolha: Aderem ao padrão nacional na íntegra ou continuam usando provedor próprio no formato aderindo ao padrão nacional no formato de compartilhamento de informações. Se escolhida a segunda opção, dois caminhos podem ser seguidos: No caminho mais simples, o provedor cria uma API própria para recepcionar os arquivos XMLs segundo o leiaute do Padrão Nacional. Nesta abordagem, o leiaute utilizado é o já existente do padrão nacional, então basta saber qual é a URL da API para comunicação e os end-points. No caminho mais complexo, o provedor altera o leiaute que ele já usa, adicionando novos campos para receber as informações que ela vai compartilhar posteriormente com o padrão nacional. Padrão Nacional A quantidade de municípios que aderiram ao Padrão Nacional é cada vez maior e pode ser conferida em um Dashboard alimentado e atualizado em tempo real. Acesse o Dashboard AQUI. Lembrando que as soluções ACBr já atendem ao padrão nacional. Provedores com API Própria para atender o Padrão Nacional com a Reforma Tributária. Última atualização: 06/01/2026 Observação: Vale reforçar que devido a relação quantidade de provedores x prazo, o foco das implementações inicialmente tem sido os métodos de emissão da NFS-e. Provedor Requisito Cidade testada Cidades atendidas* Emissão funcionando ABase Informar o Token em WSChaveAcesso Boa Vista do Burica/MS 39 Em testes Betha Vai usar WebService Soap Dourados/MS 403 Envio OK Coplan Vai usar WebService Soap Barra do Garças/MT 31 Em testes Citta Enviar o XML da NFS-e São Valentim do Sul/RS 24 Envio OK Digifred Vai usar WebService Soap Ibirubá/RS 21 Envio OK EL Informar o Token em WSChaveAcesso Aracruz/PE 155 Envio OK Infisc - Campo Bom/RS 9 Envio OK ISSNet WS Soap/Permite Lote de DPS - 25 Aguardando as URLs de homologação Pronim Permite o envio de um lote de DPS Regente Feijó/SP 184 Envio OK RLZ - Barretos/SP 9 - SilTecnologia WS Soap/Enviar o XML da NFS-e Franca/SP 16 Retorno Vazio SimplISS - Blumenau/SC 27 Envio OK (Ainda não aceita os campos IBSCBS) Tiplan - Americana/SP 8 Envio OK * Estimativa aproximada Provedores que alteram o layout em uso para atender a Reforma Tributária. Última atualização: 06/01/2026 Provedor Requisito Cidades Atendidas* Emissão funcionando EloTech Versão 2.03 138 Envio OK FintelISS Versão 2.02 4 O webservice da prefeitura não aplicou o novo Schema GeisWeb Próprio 7 Envio OK Ginfes - 22 Giss - 18 Envio OK IPM - 188 Envio OK ISSBarueri - 1 ISSe - 1 Envio OK ISSSaoPaulo Versão 2.00 1 Envio OK Publica Versão 1.00 31 Envio OK SigISSWeb Próprio 11 Envio OK SpeedGov Versão 2.00 32 Tinus Versão 2.03 44 Envio OK WebISS Versão 2.02 87 Envio OK * Estimativa aproximada

Quem acompanha o Projeto ACBr sabe que sempre recomendamos usar certificados digitais no formato A1. Pois é... o certificado digital A3 ataca mais uma vez!!! Nos últimos dias temos recebido diversos relatos de usuários recebendo mensagens de erro como a mensagem abaixo: Erro Interno: -2146893815 Erro HTTP: 0 URL: https://nfe.svrs.rs.gov.br/ws/NfeStatusServico/NfeStatusServico4.asmx Erro: 2148073481 - E o que aconteceu? Sempre acontece com quem está usando certificado A3? A recomentadação quando usa A1 é configurar com OpenSSL e quando usa A3 com WinCrypt (veja esse tópico aqui para todos os detalhes!) e aí que está uma grande diferença. O A3 acaba dependendo diretamente das configurações, atualizações e permissões do sistema operacional windows. Nas últimas atualizações do windows estão sendo limitados os protocolos de comunicação permitidos e aí que acontece o erro... a sua comunicação acaba não funcionando. Não é um problema novo. Temos um tópico antigo já com orientações de como resolver o problema e quem deu a dica foi o usuário @Jhonatan. Também temos outro tópico que o @Diego Foliene explica tudo detalhadamente. Obrigado aos dois! Vou deixar o tópico do Diego aqui pra você resolver o seu problema!

Olá comunidade ! É com muita alegria que comunicamos a disponibilização do novo componente ACBrCalculadoraConsumo! Este componente pode ser utilizado para comunicar com os end-points da Calculadora da Reforma Tributária! O exemplo de uso do componente pode ser encontrado no caminho ..\trunk2\Exemplos\ACBrTCP\ACBrCalculadoraConsumo Um agradecimento ao Consultor @EliasCesar pelo desenvolvimento do componente e dos exemplos!

Olá Pessoal, Após a atualização dos fontes dos componentes do ACBr ao compilar as aplicações estão aparecendo uma quantidade enorme de Warning com mensagens indicando que um determinado Símbolo esta depreciado e orienta a usar um tipo ou método que se encontra em uma determinada Unit. Primeiro porque isso esta ocorrendo? A resposta é muito simples, estamos realizando um processo de migração, ou seja, estamos deixando de utilizar as units que se encontram na pasta PCNComum. Os componentes que emitem DF-e (por exemplo o ACBrNFe), deixaram de utilizar as units pcnGerador e pcnLeitor para realizar a escrita e a leitura do XML, eles agora se utilizam das units ACBrXmlWriter e ACBrXmlReader, estas ultimas se demonstraram ser mais velozes. Para vocês terem uma ideia um CT-e com 1800 NF-e vinculadas estava levando mais de 6 minutos para ser lido usando o pcnLeitor. Com o ACBrXmlReader ele foi lido em apenas 6 segundos. Chegou a vez de deixarmos de usar o pcnConversao e passar a utilizar o ACBrDFe.Conversao. Poderíamos simplesmente realizar a troca, mas essa atitude com certeza iria quebrar a compilação de suas aplicações e a solução seria abrir a unit da sua aplicação que não esta compilando e realizar a troca. Resolvemos então fazer alterações na unit pcnConversao para que os tipos e funções de conversão pudessem conviver com os tipos e funções de conversão da unit ACBrDFe.Conversao. E uma dessas alterações na unit pcnConversao visa gerar esses Warnings para alertar você desenvolvedor a realizar a troca. Notem que vários desses Warnings se referem as units dos próprios componente, esses nós vamos iniciar em breve a realizar as trocas. Por fim não menos importante Warnings não são erros e sim alertas, eles não impedem que a sua aplicação funcione corretamente.

A PGWebLib, é a biblioteca de TEF da PayGo, que permite integração da aplicação com TEF, de forma embarcada na Aplicação As últimas versões da PGWebLib.dll, foram modificadas para conter um componente de segurança, chamado de Warsaw Embora isso traga o benefício da segurança, muitas Sw.Houses nos reportaram problemas na instalação dessa versão, ou interferência do componente de segurança, no funcionamento da aplicação... Outro inconveniente da versão segura, é a necessidade de ter que rodar um instalador do Client PayGo, e com isso, perde-se a "leveza", e a possibilidade de embarcar a PGWebLib no instalador da sua aplicação Você pode ler mais sobre essa nova versão segura, nesse Post: Pensando em mitigar esses problemas, agora a Setis disponibilizou uma versão da PGWebLib 4.1.47.* (ou superior), onde não há o componente de segurança. Ou seja: Com a DLL sem a Proteção... Basta copiar a DLL, para a mesma pasta do seu .EXE que tudo estará pronto para funcionamento do TEF Abaixo o Link para download da PGWebLib sem o componente de proteção (Warsaw) Nota: use a versão 64 Bits, apenas se você compila a sua aplicação em 64 bits Editado.... Novo Link Oficial: https://paygodev.readme.io/docs/kit-de-integração-sem-proteção-warsaw

Olá, pessoal! Temos recebido diversos relatos de membros da nossa comunidade sobre problemas na transmissão de NF-e e NFC-e que contenham os novos campos incluídos pela Reforma Tributária. Os relatos têm em comum: Rejeições do tipo Falha no Schema ou mensagens de erro relacionadas ao schema. As mesmas UFs envolvidas. Indícios de que a tag vIBS, adicionada no grupo gIBSCBS na versão 1.20 da Nota Técnica 2025/002, está associada ao problema. Recebemos a informação de que as UFs de SP, MT, MS e PR ainda não estão aceitando as informações do IBS conforme a versão 1.20 da NT 2025/002. Por isso, todo o grupo de IBS deve ser suprimido no ambiente de homologação. Por outro lado, as UFs de RS e GO já estão validando as informações em homologação, ou seja, antecipando a implementação prevista na NT. Seguiremos atualizando este tópico à medida que novas informações forem sendo disponibilizadas.

Olá Pessoal, É com muita alegria que venho informar a todos que o componente ACBrNFSeX já esta pronto para atender o novo WebService do provedor Fiorilli que trabalha com o layout do Padrão Nacional, além disso existe também a particularidade da existência de algumas versões do webservice disponíveis nas prefeituras e cada uma decide quando se atualiza para algo mais recente, inclusive com versões que ainda não contemplam os campos da Reforma Tributária. Como o ACBrLibNFSe e o ACBrMonitor Plus se utilizam do componente ACBrNFSeX assim que for disponibilizado uma nova versão essas duas soluções ACBr também vão atender o novo WebService do provedor. Mudanças em sua Aplicação Configurações do componente ACBr ou ACBrMonitor/ACBrLib Não muda nada, pois tanto o componente quanto as soluções ACBrMonitor e ACBrLib se autoconfiguram conforme as informações existentes no arquivo ACBrNFSeXServicos.ini, o qual é atualizado pela equipe ACBr conforme recebemos as informações de mudanças. Alimentação dos componente ACBr ou ACBrMonitor/ACBrLib Se sua aplicação já atende clientes que se utilizam do layout do padrão nacional, seu software já deve estar adequado a este modelo, então nenhuma alteração será necessária em sua aplicação, porém se não for este o caso, será necessário a implementação do preenchimento dos dados considerando o padrão nacional para o componente ou envio das informações ao ACBrMonitor/ACBrLib conforme os modelos existentes em nossa documentação e exemplos. Importante Os dados passados para o componente ou para o arquivo INI (para quem usa a Lib ou o Monitor) mudam ao se utilizar o novo webservice da Fiorilli, sendo assim é importante observar os modelos citados acima. Nem todos os serviços disponíveis no webservice antigo estão disponíveis no novo, como por exemplo o ConsultarNFSeServicoPrestado, o ConsultarNFSeServicoTomado e o SubstituirNFSe, sendo assim ao obter o retorno Serviço não Implementado, se deve a este fator, ou seja a Fiorilli ainda não implementou o serviço em seu novo webservice. É importante lembrar que a Fiorilli continua com o seu webservice "antigo" que recepciona o XML segundo a versão 2.00 do layout da ABRASF, mas não sabemos quando eles o desativarão, sendo assim recomendamos iniciar a mudança assim que possível. E se uma cidade atendida pelo meu software mudou, o que fazer? Dado que as cidades estão em processo de atualização, é natural que ao longo do tempo seja preciso atualizar, sendo assim ao identificar essa mudança, seja por um relato de cliente ou da própria prefeitura, você pode abrir um tópico em nosso fórum e nos informar, mas se desejar já validar se realmente a mudança está funcional do lado da prefeitura e quiser nos ajudar, você pode também seguir o procedimento abaixo e realizar um teste em seu ambiente e em seguida nos enviar as mudanças. O provedor Fiorilli atende mais de 300 cidades, cotamos com a colaboração de todos vocês para nos informar qual cidade vocês testaram e com qual versão funcionou. O que mudar no arquivo ACBrNFSeXServicos.ini para que possamos realizar os testes e passar a utilizar o novo webservice? Descobrindo a versão correta a inserir no INI? Atualmente para identificar se deve-se configurar a versão 1.01 ou 1.00 , saberemos isso conforme os testes a seguir Se configurarmos no arquivo ACBrNFSeXServicos.ini que a cidade usa a versão 1.00 e enviarmos o DPS para o WebService, se ocorrer o erro abaixo significa que na verdade essa cidade já esta usando a versão 1.01 unexpected element (uri:"http://www.fiorilli.com.br/nfse-nacional", local:"DPS"). Expected elements are {http://www.sped.fazenda.gov.br/nfse}DPS Por outro lado se configurarmos no arquivo ACBrNFSeXServicos.ini que a cidade usa a versão 1.01 e enviarmos o DPS para o WebService, se ocorrer o erro abaixo significa que na verdade essa cidade esta usando a versão 1.00 unexpected element (uri:"http://www.sped.fazenda.gov.br/nfse", local:"DPS"). Expected elements are {http://www.fiorilli.com.br/nfse-nacional}DPS Resumindo, na versão 1.00 o namespace esperado tem que ser o da Fiorilli (http://www.fiorilli.com.br/nfse-nacional) e na versão 1.01 tem que ser o do Padrão Nacional (http://www.sped.fazenda.gov.br/nfse). Bom agora vocês já sabem o que tem que fazer quando aparecer esses erros, basta mudar a versão informada no campo Versao que se encontra na seção da cidade que vocês estão testando. Vamos agora para o arquivo ACBrNFSeXServicos.ini Primeiramente quero informar que nesse arquivo INI temos uma seção chamada [Fiorilli] que nela consta a URL de homologação para o novo WebService e o campo Versao com o valor 1.00, logo estamos supondo que todas as cidades estão usando essa versão. Após a alteração do arquivo ACBrNFSeXServicos.ini é importante seguir as orientações que se encontram no inicio dele, do contrário as alterações feitas não serão válidas. Como fica a seção das cidades atendidas pelo provedor que utilizam a versão 1.00 que já alteramos no arquivo INI: [1100122] Nome=Ji-Parana UF=RO Provedor=Fiorilli ProRecepcionar=https://nfse.ji-parana.ro.gov.br/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType ;Versao=2.00 ;ProRecepcionar=https://nfse.ji-parana.ro.gov.br/IssWeb-ejb/IssWebWS/IssWebWS ;ProLinkURL=http://177.124.184.59:5660/issweb/formGerarNF.jsf?nroNota=%NumeroNFSe%&codVerificacao=%CodVerif%&cnpj=%Cnpj%&hash=%ChaveAcesso% (...) [2104099] Nome=Formosa da Serra Negra UF=MA Provedor=Fiorilli ProRecepcionar=http://nfse.adtrcloud.com.br:8097/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType ;Versao=2.00 ;ProRecepcionar=http://nfse.adtrcloud.com.br:8097/IssWeb-ejb/IssWebWS/IssWebWS ;ProLinkURL=http://nfse.adtrcloud.com.br:8097/issweb/formGerarNF.jsf?nroNota=%NumeroNFSe%&codVerificacao=%CodVerif%&cnpj=%Cnpj%&hash=%ChaveAcesso% (...) [3504008] Nome=Assis UF=SP Provedor=Fiorilli ProRecepcionar=https://nfsews.assis.sp.gov.br/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType ;Versao=2.00 ;ProRecepcionar=https://nfsews.assis.sp.gov.br/IssWeb-ejb/IssWebWS/IssWebWS ;ProLinkURL=http://nfsews.assis.sp.gov.br/issweb/formGerarNF.jsf?nroNota=%NumeroNFSe%&codVerificacao=%CodVerif%&cnpj=%Cnpj%&hash=%ChaveAcesso% (...) [3537107] Nome=Pedreira UF=SP Provedor=Fiorilli ProRecepcionar=http://intranet.pedreira.sp.gov.br:5661/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType ;Versao=2.00 ;ProRecepcionar=http://intranet.pedreira.sp.gov.br:5661/IssWeb-ejb/IssWebWS/IssWebWS ;ProLinkURL=http://intranet.pedreira.sp.gov.br:5661/issweb/formGerarNF.jsf?nroNota=%NumeroNFSe%&codVerificacao=%CodVerif%&cnpj=%Cnpj%&hash=%ChaveAcesso% Notem que comentamos os campos: Versao=2.00 e os campos que tem a URL e o Link utilizados pelo WebService antigo que trabalha com a versão 2 do layout da ABRASF. Notem também que não foi informado que a versão é 1.00, pois por padrão ele vai pegar essa informação lá da seção do provedor. Como fica a seção das cidades atendidas pelo provedor que utilizam a versão 1.01 que já alteramos no arquivo INI: [3504404] Nome=Avanhandava UF=SP Provedor=Fiorilli Versao=1.01 Params=ServicosAPIPropria:ConsultarNFSeRps,ConsultarNFSePorChave| ProRecepcionar=http://45.71.14.83:5661/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType ProConsultarNFSePorChave=http://45.71.14.83:5661/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType ProConsultarNFSeRps=http://45.71.14.83:5661/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType ;Versao=2.00 ;ProRecepcionar=http://45.71.14.83:5661/IssWeb-ejb/IssWebWS/IssWebWS (...) [3526407] Nome=Laranjal Paulista UF=SP Provedor=Fiorilli Versao=1.01 Params=ServicosAPIPropria:ConsultarNFSeRps,ConsultarNFSePorChave| ProRecepcionar=http://pmlpta.ddns.com.br:6118/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType ProConsultarNFSePorChave=http://pmlpta.ddns.com.br:6118/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType ProConsultarNFSeRps=http://pmlpta.ddns.com.br:6118/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType ;Versao=2.00 ;ProRecepcionar=http://pmlpta.ddns.com.br:6118/IssWeb-ejb/IssWebWS/IssWebWS ;ProLinkURL=http://pmlpta.ddns.com.br:6118/issweb/formGerarNF.jsf?nroNota=%NumeroNFSe%&codVerificacao=%CodVerif%&cnpj=%Cnpj%&hash=%ChaveAcesso% Notem que comentamos os campos: Versao=2.00 e os campos que tem a URL e o Link utilizados pelo WebService antigo que trabalha com a versão 2 do layout da ABRASF. Notem também que foi informado que a versão é 1.01 e temos também o campo Params com os serviços: ConsultarNFSeRps e ConsultarNFSePorChave, pois nesta versão o webservice possui esses serviços, logo ele não se utiliza dos serviços disponibilizados pela API do Padrão Nacional. Um detalhe importante é que no final da linha do campo Params temos o caracter pipe "|", ele é obrigatório. Outra informação importante é as URLs para os referidos serviços destacados em Params. As cidades mostradas acima foram alteradas e testadas, mas desejo fazer testes com uma cidade do meu cliente como devo proceder? Vamos a um exemplo: [3519303] Nome=Ibate UF=SP Provedor=Fiorilli Versao=2.00 ProRecepcionar=http://200.205.131.110:5661/IssWeb-ejb/IssWebWS/IssWebWS ProLinkURL=http://200.205.131.110:5661/issweb/formGerarNF.jsf?nroNota=%NumeroNFSe%&codVerificacao=%CodVerif%&cnpj=%Cnpj%&hash=%ChaveAcesso% ; A URL abaixo deve ser utilizada a partir de 01/02/2026 quando o WebService novo vai passar a ser utilizado. ;ProRecepcionar=http://200.205.131.110:5661/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType A cidade de Ibaté/SP consta que usa a versão 2.00 e as URL se referem ao webservice antigo que usa o layout da ABRASF. A URL que esta comentada já é a URL do novo webservice que usa o layout do Padrão Nacional. Alteração supondo que o sistema instalado na prefeitura usa a versão 1.00 do Padrão Nacional: [3519303] Nome=Ibate UF=SP Provedor=Fiorilli ProRecepcionar=http://200.205.131.110:5661/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType ;Versao=2.00 ;ProRecepcionar=http://200.205.131.110:5661/IssWeb-ejb/IssWebWS/IssWebWS ;ProLinkURL=http://200.205.131.110:5661/issweb/formGerarNF.jsf?nroNota=%NumeroNFSe%&codVerificacao=%CodVerif%&cnpj=%Cnpj%&hash=%ChaveAcesso% Se não funcionar, ou seja, ocorrer o erro já mostrado acima temos que incluir o campo versão e params, pois certamente o sistema instalado na prefeitura é mais atual e trabalha com a versão 1.01 do Padrão Nacional: [3519303] Nome=Ibate UF=SP Provedor=Fiorilli Versao=1.01 Params=ServicosAPIPropria:ConsultarNFSeRps,ConsultarNFSePorChave| ProRecepcionar=http://200.205.131.110:5661/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType ;Versao=2.00 ;ProRecepcionar=http://200.205.131.110:5661/IssWeb-ejb/IssWebWS/IssWebWS ;ProLinkURL=http://200.205.131.110:5661/issweb/formGerarNF.jsf?nroNota=%NumeroNFSe%&codVerificacao=%CodVerif%&cnpj=%Cnpj%&hash=%ChaveAcesso% Lembre-se que após a alteração devemos: Após a alteração do arquivo ACBrNFSeXServicos.ini é importante seguir as orientações que se encontram no inicio dele, do contrário as alterações feitas não serão válidas. Observação: Não testamos a cidade de Ibaté/SP trata-se de um exemplo de como devemos alterar a seção da cidade para usar o novo webservice, sendo assim uma das duas alterações mostradas acima vai funcionar, qual delas, só testando. Tópico relacionado Um agradecimento especial ao nosso consultor @Diego Foliene e ao membro do fórum @Diego Reckziegel, pelos ajustes no código do componente.

Olá comunidade ! Seguindo o proposto na Nota Técnica 2026.001, a Sefaz de SP disponibilizou dois novos web services para download dos arquivos XMLs da NFC-es emitidas no estado. São eles: NFCeListagemChaves: através de consulta, vai disponibilizar a lista de NFCe recebidas pela Sefaz num determinado período, para um determinado contribuinte; NFCeDownloadXML: através de consulta, vai disponibilizar o XML da NFC-e e dos eventos associados. Foi criado em nosso backlog a tarefa ACBR-9000 para integração dos novos web services as soluções ACBr. Assim que houver novidades será noticiado.

Olá comunidade ! Informamos que a propriedade CST da classe ISel responsável pela geração do grupo do Imposto Seletivo foi alterada de TCSTIS para string a partir da Rev-44138. Antes: TgIS = class(TObject) private FCSTIS: TCSTIS; //Demais propriedades... public procedure Assign(Source: TgIS); property CSTIS: TCSTIS read FCSTIS write FCSTIS; //Demais propriedades... end; Depois: TgIS = class(TObject) private FCSTIS: string; //Demais propriedades public procedure Assign(Source: TgIS); property CSTIS: string read FCSTIS write FCSTIS; //Demais propriedades... end; O motivo dessa mudança Foi constatado que o grupo de IS ainda não está sendo validado pelo webservice da Sefaz. Isso é esperado, visto que o Imposto Seletivo entra em vigor apenas em 2027. No entanto, devido à ausência dessa validação, arquivos XML estão sendo autorizados mesmo contendo quaisquer valores na faixa de 000 a 999 na tag CSTIS. Até a publicação de uma tabela oficial com os códigos válidos, tornou-se inviável manter essa informação como um enumerado (Enum). Por que? Se mantivéssemos o tipo enumerado, o componente falharia ao tentar ler e converter um XML que contivesse um valor numérico não previsto no código, gerando erros na leitura de documentos autorizados. O que muda para mim? Se você utiliza ACBrMonitorPLUS ou ACBrLib nenhuma mudança é necessária. Ambos vão ler o valor da string que for atribuído no arquivo INI. Caso utilize componente nativo para Delphi ou Lazarus, poderá se deparar com o seguinte erro ao tentar compilar sua aplicação: De um duplo clique na linha que aparece o erro e remova qualquer valor de enumerado atribuído substituindo pelo valor que deseja em um formato de string.

Olá Pessoal, O inicio de 2026 vai ser muito conturbado para todos nós desenvolvedores. Se tratando de NFS-e prevejo um cenário muito caótico, por conta da falta de padronização. Temos por volta de 150 provedores (empresas contratadas pelas prefeituras) e não temos informações sobre o que cada um pretende fazer no quesito Reforma Tributária. E com certeza você não quer ter que fazer instalação nos seus vários clientes no dia 31/12 ou 01/01 para atender essas mudanças né? Visando auxiliar aos desenvolvedores que utilizam as soluções ACBr, criamos esse passo a passo a ser seguido para auxiliar nessa tarefa e para que sua aplicação de emissão de notas não pare no dia 01/01/2026! Antes de começar... Sabemos que os prazos estão apertados e todos precisam adequar suas aplicações. Mas antes de começar, precisamos entender como meu cliente vai ser afetado de fato. Isso vai ser importante para os passos mais a frente. Podemos dividir a mudança que vai ocorrer para um município em 3 possibilidades: Municípios que aderiram a emissão com o Padrão Nacional; Municípios que vão utilizar uma API ou Web Service próprios para recepcionar o arquivo XML no layout do Padrão Nacional; Municípios que vão manter o Web Service atual, apenas atualizando o layout que já é utilizado para conter novos campos; Então antes de realizar toda e qualquer modificação em sua solução, é preciso descobrir em qual das 3 situações se encaixa o seu cliente. A Lista de Municípios Aderentes é o lugar perfeito para encontrar essa informação. Se a cidade constar como aderente ao emissor nacional, então isso significa que ela aderiu ao Padrão Nacional na íntegra, fazendo a emissão por ele. Se encaixando então na primeira situação. Vamos a um exemplo prático, eu acessei a lista e abri a página do Power BI que centraliza as informações. Vejam que no canto inferior direito, temos uma seção que diz "Adesão ao Emissor Nacional da NFS-e. Agora, para exemplificar eu vou filtrar buscando a cidade de Adamantina/SP. Observem que na seção "Adesão ao Emissor Nacional da NFS-e" eu tenho o valor "Sim". Caso ela conste como aderente ao ambiente nacional, mas não aderente ao padrão nacional, isso significa que ela aderiu ao padrão nacional, mas na modalidade de compartilhamento. Se encaixando então na segunda ou terceira situação. Para demonstrar, filtramos a cidade de Aguaí-SP: Vejam que ela está ativa na plataforma, mas a informação de "Adesão ao Emissor Nacional da NFS-e" está em branco, indicando que ela não aderiu a emissão, somente a modalidade de compartilhamento. Nesses casos, é importante conferir se não existem avisos no portal da prefeitura ou se o cliente não recebeu algum aviso sobre mudança na emissão. Caso nenhuma informação seja encontrada, é preciso questionar a empresa que presta o serviço de manter o web service de emissão de notas para o município: "Quais alterações serão feitas para atender a Reforma Tributária?" "Vai continuar o mesmo layout da NFS-e?" "Se for continuar o mesmo layout de NFS-e, pedir a documentação das alterações para atualizar a integração e os novos arquivos de schema" "Se não for continuar o mesmo layout de NFS-e, pedir a URL da nova API ou web service para comunicação." Caso o Power BI não seja sua ferramenta de escolha ou a informação apresentada no mesmo não esteja condizente com a informação que você recebeu, existem mais duas formas de saber como o município aderiu ao Padrão Nacional melhor descritas neste tópico. Vamos começar! Agora que determinou em qual das situações seu cliente se encaixa, podemos começar o nosso passo a passo: 1) Fazendo a mudança das configurações dos provedores (URLs, versão, etc...) 2) Fazer a mudança na rotina de preenchimento do RPS/DPS. 3) Fazer a mudança na rotina da leitura do retorno

Olá, pessoal. Temos o prazer de anunciar que o novo componente ACBrIMendes já está disponível no SVN! Sobre o ACBrIMendes: O componente ACBrIMendes oferece uma integração simplificada com a API Gestor Tributário 3.0. Ele automatiza o gerenciamento de dados fiscais da sua empresa, prevenindo cobranças de impostos indevidas e apontando riscos de prejuízos. Com isso, proporciona mais segurança tributária e uma melhora direta no fluxo de caixa. Disponível em: - Fonte: https://svn.code.sf.net/p/acbr/code/trunk2/Fontes/ACBrTCP/ACBrIMendes.pas - Programa exemplo: https://svn.code.sf.net/p/acbr/code/trunk2/Exemplos/ACBrTCP/ACBrIMendes/

Olá, comunidade ! Nos últimos dias temos recebidos diversos relatos em nosso Discord e em nosso Fórum de problemas com certificado A3. Todos os relatos tem em comum o mesmo erro: Tudo indica que este problema está relacionado a alguma atualização recente do Windows, visto que ele começou a ocorrer repentinamente. Como é explicado AQUI a configuração WinCrypt que é utilizada para certificados A3 faz uso da própria API do Windows. Alguns membros relataram ter sanado o problema ao desinstalar e instalar novamente o certificado. Um agradecimento ao membro de nossa comunidade @RicardoAGRO1 compartilhou no canal #sefaz em nosso servidor do Discord o link: Podem ocorrer problemas de autenticação do SmartCard com a atualização do Windows de outubro de 2025 com um passo a passo para a solução do problema.

Olá Pessoal, Estamos enviando para o SVN uma atualização nos fontes do componente ACBrNFe e consequentemente uma nova versão da DLL e do ACBrMonitor que vão estar disponíveis no dia 09/09/2025 visando atender a versão 1.20 da NT 2015/002. Segundo a referida NT o ambiente de homologação vai passar a aceitar esse novo layout a partir de 08/09/2025 e em produção a partir de 06/10/2025. O que vai mudar: 1 . Dentro do grupo gIBSCBS vamos ter o campo vIBS a ser gerado entre o grupo gIBSMun e gCBS. Esse novo campo vIBS vai conter a soma de vIBSUF e vIBSMun. Quando houver crédito presumido com indicador “IndDeduzCredPres=1”, o vCredPres deve ser abatido desse valor. 2. O grupo gIBSCBSMono que antes continha 21 campos, agora ele é composto pelos grupos: gMonoPadrao, gMonoReten, gMonoRet e gMonoDif e pelos campos: vTotIBSMonoItem e vTotCBSMonoItem. Os 19 campos agora estão distribuídos dentro dos 4 grupos mencionados acima. O grupo gIBSCBSMono só deve ser gerado para os Produtos que fazem parte da tributação monofásico, por exemplo combustível. Observação: Além de atualizar os fontes e reinstalar o ACBr, notem que foram atualizados os Schemas que se encontram na pasta: ...\Exemplos\ACBrDFe\Schemas\NFe. Para quem utiliza o componente: Como devemos escrever as linhas de código para alimentar esses campos: (...) IBSCBS.gIBSCBS.vIBS := 100; (...) // Informações do tributo: IBS / CBS em operações com imposto monofásico IBSCBS.gIBSCBSMono.gMonoPadrao.qBCMono := 1; IBSCBS.gIBSCBSMono.gMonoPadrao.adRemIBS := 5; IBSCBS.gIBSCBSMono.gMonoPadrao.adRemCBS := 5; IBSCBS.gIBSCBSMono.gMonoPadrao.vIBSMono := 100; IBSCBS.gIBSCBSMono.gMonoPadrao.vCBSMono := 100; IBSCBS.gIBSCBSMono.gMonoReten.qBCMonoReten := 1; IBSCBS.gIBSCBSMono.gMonoReten.adRemIBSReten := 5; IBSCBS.gIBSCBSMono.gMonoReten.vIBSMonoReten := 100; IBSCBS.gIBSCBSMono.gMonoReten.vCBSMonoReten := 100; IBSCBS.gIBSCBSMono.gMonoRet.qBCMonoRet := 1; IBSCBS.gIBSCBSMono.gMonoRet.adRemIBSRet := 5; IBSCBS.gIBSCBSMono.gMonoRet.vIBSMonoRet := 100; IBSCBS.gIBSCBSMono.gMonoRet.vCBSMonoRet := 100; IBSCBS.gIBSCBSMono.gMonoDif.pDifIBS := 5; IBSCBS.gIBSCBSMono.gMonoDif.vIBSMonoDif := 100; IBSCBS.gIBSCBSMono.gMonoDif.pDifCBS := 5; IBSCBS.gIBSCBSMono.gMonoDif.vCBSMonoDif := 100; IBSCBS.gIBSCBSMono.vTotIBSMonoItem := 100; IBSCBS.gIBSCBSMono.vTotCBSMonoItem := 100; (...) Para quem utiliza a DLL ou o ACBrMonitor a geração do arquivo INI fica da seguinte forma: (...) [gIBSCBS001] vBC=100 vIBS=100 (...) // Informações do tributo: IBS / CBS em operações com imposto monofásico [gIBSCBSMono001] vTotIBSMonoItem=100 vTotCBSMonoItem=100 [gMonoPadrao001] qBCMono=1 adRemIBS=5 adRemCBS=5 vIBSMono=100 vCBSMono=100 [gMonoReten001] qBCMonoReten=1 adRemIBSReten=5 vIBSMonoReten=100 adRemCBSReten=0 vCBSMonoReten=100 [gMonoRet001] qBCMonoRet=1 adRemIBSRet=5 vIBSMonoRet=100 adRemCBSRet=0 vCBSMonoRet=100 [gMonoDif001] pDifIBS=5 vIBSMonoDif=100 pDifCBS=5 vCBSMonoDif=100 (...) Os valores e percentuais contidos nos exemplos acima são fictícios não condizendo com a realidade.

Olá comunidade ! Foi publicada a Nota Técnica 2026/003 v1.00 que estabelece as especificações técnicas e operacionais do DANFe Simplificado Tipo 2 que foi instituído pelo Ajuste SINIEF nº 13, de 6 de abril de 2026. Introdução Esse novo modelo visa acobertar de forma padronizada, a emissão de NF-e em operações em que tipicamente é emitido NFC-e. Assim como os demais leiautes de DANFe, vale ressaltar que da mesma forma, o DANFE Simplificado Tipo 2: É um documento fiscal auxiliar que representa de forma padronizada e simplificada a transação. O XML continua sendo o documento fiscal de fato. A impressão do DANFE Simplificado Tipo 2 é efetuada diretamente pelo aplicativo do contribuinte em impressora comum (não fiscal) com base nas informações do XML. O DANFe Simplificado Tipo 2 não deve possuir informações que não estejam contidas no arquivo XML da NF-e a qual ele representa. Leiaute O DANFe Simplificado Tipo 2 é composto pelas divisões: I - Informações do Cabeçalho II - Informações de detalhes de produtos/serviços III - Informações de Totais do DANFE Simplificado Tipo 2 IIIA - Informações dos novos impostos IBS/CBS IV - Informações da consulta via chave de acesso V Informações da consulta via QR Code VI - Informações sobre o Consumidor VII- Informações de Identificação da NF-e e do Protocolo de Autorização VIII - Área de Mensagem Fiscal IX - Mensagem de Interesse do Contribuinte Informações exigidas pela Lei Federal nº 12.741/2012 Datas Implantação Teste: 01/07/2026 Implantação Produção: 03/08/2026 E como fica o ACBr? O novo leiaute será implementado nas soluções ACBr. Para acompanhar esta demanda foi criada a tarefa ACBR-9424. Quaisquer novidades serão divulgadas neste tópico ou diretamente em nossa área de notícias. Leia essa nota técnica completa AQUI. Um agradecimento ao membro de nossa comunidade @mateusjurado por compartilhar a informação no canal #sefaz em nosso servidor do Discord.

Atualização 2026/02/26 16:00: Recebemos notícias que foi normalizado a situação. Post Original abaixo: ----------- Olá pessoal, Queremos informar que estamos recebendo diversos relatos que o Emissor Nacional da NFSe está tendo problemas. A mensagem é a seguinte: Se receber a mensagem há apenas duas coisas a fazer: 1) Reportar o problema ao Emissor Nacional. Parece que o problema já foi reportado, mas quanto mais pessoas o fizerem talvez fique claro que é urgente. Não esqueça de informar em qual ambiente você está tentando emitir (produção ou produção restrita). O seguinte link pode ser usado para isso: https://www.gov.br/nfse/pt-br/canais_atendimento/contact-info 2) Ter paciência, aguardar e continuar testando. A qualquer momento pode ser que seja resolvido. Mas não temos como fazer nada do nosso lado. Informe seus clientes para que eles fiquem mais tranquilos ao saber que o problema não é com vocês. Bom trabalho pessoal.

Projeto ACBr está refatorando as classes ACBrLib C# Olá comunidade ! O Projeto ACBr iniciou a refatoração das classes de alto nível em C#, mantendo a compatibilidade com o .NET 4.5 As mudanças ocorrerão ao longo do ano de 2026. Principais mudanças Desacoplamento usando interfaces: agora cada classe de alto nível terá sua interface (IACBrLibCEP, IACBrLibNFe, ...); Uso da interface IACBrLibBase; Substituição da classe ACBrLibHandle por ACBrLibBase; ACBrLibHandle será depreciada e removida Remoção do selamento das classes ACBrLib Programas exemplo: Os demos terão pastas de build (output) próprias para ST e MT; Serão atualizados para .NET. 4.8. Exemplo: // Pasta de saída para demo MT trunk2\Projetos\ACBrLib\Demos\C#\Mail\Demo\ACBrLibMail.Demo\bin\MT\Debug // Pasta de saída para demo ST trunk2\Projetos\ACBrLib\Demos\C#\Mail\Demo\ACBrLibMail.Demo\bin\ST\Debug Fases da refatoração Obs.: Até a presente data, 02/03/2026 concluímos a fase II Fase I Refatoração da ACBrLib.Core com inclusão da classe ACBrLibBase e da interface IACBrLibBase. Além disso, foram expostos os métodos `Inicializar`,`Finalizar` e `OpenSSLInfo` nas classes ST e MT. Nessa fase, foi adicionada uma camada de compatibilidade entre as classes filhas de ACBrLibHandle e ACBrLibBase. Fase II Classes filhas de ACBrLibHandleBase carregarão a ACBrLib em modo thread safe. Refatoração das classes MT mais usadas; Inclusão das interfaces IACBrLib. Lista atualizada em 02/03/2026 Já foram atualizados: ACBrNFe; ACBrNFSe; ACBrCEP; ACBrMDFe; ACBrPIXCD; ACBrPosPrinter; ACBrBAL; ACBrBoleto; ACBrConsultaCNPJ; ACBrCTe; ACBrGTIN; ACBrETQ; ACBrIBGE; ACBrReinf; ACBrNCMs; ACBrMail; PIXMatera; Sedex. ACBrPosPrinter Agora, o método Inicializar é responsável por instanciar o componente! Método usado para preparar o buffer para impressão agora é InicializarPos(). Essa alteração visa corrigir a ambiguidade causada pelos argumentos opcionais do método Inicializar(): public interface IACBrLibBase { // permite a chamada sem argumentos, exemplo: Inicializar(); void Inicializar(string eArquivoConfig = "", string eChaveCrypt= ""); } Exemplo: //versões anteriores a 1.0.9 ACBrPosPrinter pos = new ACBrPosPrinter("[Memory]", ""); pos.Inicializar(); // metódo antigo (inicializar buffer) // ACBrLib.PosPrinter >=v1.0.9 ACBrPosPrinter pos = new ACBrPosPrinter("[Memory]", ""); pos.InicializarPos(); ACBrReinf Outra modificação importante aconteceu em ACBrReinf, na interface IACBrLibReinf o método para configurar o TipoContribuinte é SetTipoContribuinte. Exemplo: // versões anteriores a 1.0.8 ACBrReinf reinf = new ACBrReinf("",""); reinf.TipoContribuinte(cmbTipoContribuinte.SelectedIndex); IACBrLibReinf reinf = new ACBrReinf("",""); reinf.SetTipoContribuinte(cmbTipoContribuinte.SelectedIndex); // >= 1.0.8 Depreciados ACBrSAT e ACBrSATMT foram depreciados. O código fonte e o programa exemplo dessa classe serão removidos na fase V. Exemplo: // exemplo de uso IACBrLibCEP cep = new ACBrLibCEP("[Memory]", ""); Fase III Atualização da interface IACBrLibBase para incluir os métodos Nome(), Versao() e UltimoRetorno(). Nessa fase, serão removidos os campos ( fields / properties ) `Nome` e `Versao` das classes ST Exemplo: ACBrNFe nfe = new ACBrNFe("[Memory]", ""); Console.WriteLine(nfe.Nome); // Removido // Novo método: IACBrLibNFe nfe = new ACBrNFe("[Memory]", ""); Console.WriteLine(nfe.Nome()); Fase IV Descontinuação da classe ACBrLibHandle. Fase V Separação dos pacotes ACBrLibX.Common com recursos compartilhados em ST e MT, incluindo a interface IACBrLibX; Nessa fase, os pacotes serão publicados com a versão 2.0.0; Recursos compartilhados, como interfaces, classes de resposta e de notas fiscais, terão seu próprio pacote; A chamada do método `Inicializar` será obrigatória após instanciar a ACBrLib. Exemplo: using ACBrLib.NFe; using ACBrLib.NFe.Common; IACBrLibNFe nfe = new ACBrNFe("[Memory]", ""); try { nfe.Inicializar(); } catch (Exception e) { // tratamento de erro } Exemplo de recurso compartilhado: using ACBrLib.Core; namespace ACBrLib.NFe.Common { public interface IACBrLibNFe : IACBrLibBase { ACBrNFeConfig Config { get; } void CarregarNota(NotaFiscal nfe); } }

Bom dia a todos! Temos recebido multiplos relatos de problemas dos nossos usuários ao tentar emitir notas fiscais de serviço usando o Ambiente Nacional! Os usuários estão recebendo o erro: O erro E9999 normalmente indica um erro não identificado do lado do servidor dos serviços. Nesses casos a orientação é registrar um fale conosco diretamente com o Ambiente Nacional através dos canais formais de atendimento: https://www.gov.br/nfse/pt-br Também foi divulgado na comunidade um email [email protected] para contato. Assim que tivermos mais informações sobre as ocorrencias vamos atualizar este tópico.

A partir de 2026 os contribuintes que já emitem documentos fiscais eletrônicos deverão destacar o IBS e a CBS nas notas sem que esses valores componham o total da operação. Esse destaque terá caráter exclusivamente informativo, desde que cumpridas as obrigações acessórias previstas na legislação, funcionando como etapa preparatória para a entrada em vigor plena do novo sistema. No caso específico da Nota Fiscal de Serviços eletrônica (NFS-e), o destaque do IBS e da CBS será inicialmente facultativo, de modo a permitir uma adaptação progressiva do setor. Com o objetivo de assegurar previsibilidade, facilitar o processo de transição e evitar penalizações indevidas durante a fase de adaptação, foi definido um período de dispensa da aplicação de penalidades relacionadas as novas obrigações acessórias. Durante esse período, eventuais falhas, omissões ou inconsistências no preenchimento das informações não ensejarão a aplicação de multas, desde que o contribuinte atue de boa-fé e avance de forma diligente no processo de adequação. Para as empresas optantes pelo Simples Nacional, não haverá qualquer alteração em 2026. Essas empresas somente passarão a destacar o IBS e a CBS em seus documentos fiscais a partir de 2027, preservando-se integralmente o regime simplificado no primeiro ano da transição. Este tópico foi construído com base em notícia originalmente publicada AQUI.

Olá comunidade ! Foi publicado no 02/12/2025, pelo comitê gestor do IBS, o Comunicado Conjunto CGIBS/RFB 01/2025 trazendo diversas orientações e esclarecimentos sobre as obrigatoriedades para o início de 2026 além de outros pontos. Obrigações a partir de 2026 A partir de 1º de janeiro de 2026, os contribuintes estarão obrigados a: Emitir documentos fiscais eletrônicos com destaque da CBS e do IBS, individualizados por operação, conforme as regras e leiautes definidos em Notas Técnicas específicas de cada documento; Apresentar, quando disponibilizadas, as Declarações dos Regimes Específicos – DeRE, conforme as regras e leiautes definidos em Documento Técnico específico de cada documento; Apresentar, quando disponibilizadas, as declarações e/ou documentos fiscais de plataformas digitais, conforme as regras e leiautes definidos em Documento Técnico específico de cada documento; A partir de julho de 2026: As pessoas físicas que sejam contribuintes da CBS e do IBS, deverão se inscrever no CNPJ. A inscrição no CNPJ não transforma a pessoa física em jurídica, servindo apenas para facilitar a apuração do IBS e da CBS. Obrigações Acessórias A partir de Janeiro de 2026 os seguintes documentos fiscais eletrônicos deverão ser emitidos com destaque da CBS e do IBS: Nota Fiscal Eletrônica - NF-e; Nota Fiscal de Consumidor Eletrônica - NFC-e; Conhecimento de Transporte Eletrônico - CT-e; Conhecimento de Transporte Eletrônico - Outros Serviços - CT-e OS; Nota Fiscal de Serviço Eletrônica - NFS-e; Nota Fiscal de Serviço Eletrônica de Exploração de Via - NFS-e Via; Nota Fiscal Fatura de Serviços de Comunicação Eletrônica - NFCom; Nota Fiscal de Energia Elétrica Eletrônica - NF3e; Bilhete de Passagem Eletrônico - BP-e; e Bilhete de Passagem Eletrônico Transporte Metropolitano - BP-e TM; Leiautes definidos sem data de vigência determinada NF-ABI (Nota Fiscal de Alienação de Bens Imóveis); NFAg (Nota Fiscal de Água e Saneamento); BP-e Aéreo (Bilhete de Passagem Aéreo); A data de vigência será definida em ato conjunto ou documento técnico a ser publicado. Leiautes em construção A NF-e Gás (Nota Fiscal de Gás); A Declaração dos Regimes Específicos - DeRE, em construção para os regimes de Instituições Financeiras, Planos de Assistência à Saúde, Concurso de Prognóstico, Administração de Consórcio, Seguro e Previdência; Dispensa do recolhimento em 2026 mediante cumprimento das obrigações acessórias Considerando que o ano de 2026 será o ano de teste da CBS e do IBS, o contribuinte que emitir documentos fiscais ou declaração de regimes específicos observando as normas e notas vigentes, conforme item 3, estará dispensado de recolhimento do IBS e da CBS. Também estarão dispensados de recolhimento do IBS e da CBS os contribuintes para os quais não haja obrigação acessória definida. Fundos de Compensação de Benefícios Fiscais A partir de janeiro de 2026, os titulares de benefícios onerosos relativos ao ICMS poderão apresentar requerimentos para os procedimentos de habilitação a futuros direitos de compensações de que trata o art. 384 da Lei Complementar nº 214, de 2025, por meio do e-CAC, preenchendo formulário eletrônico que estará disponível no SISEN, conforme ato normativo a ser emitido. Deverão ser preenchidos tantos requerimentos quantos forem os benefícios passíveis de compensação usufruídos pelo requerente em cada programa de concessão de benefícios onerosos.

Olá Pessoal, O que devemos fazer ao saber que o Município XYZ já aderiu a emissão da NFS-e Padrão Nacional este ano de 2025? Resposta: Configurar o componente para usar o Layout do Padrão Nacional versão 1.00 O que devemos fazer ao saber que o Município XYZ vai aderir a emissão da NFS-e Padrão Nacional em 2026? Resposta: Configurar o componente para usar o Layout do Padrão Nacional versão 1.01 Qual é a diferença entre essas duas versões? Resposta: A versão 1.01 contempla os novos campos referente a Reforma Tributária e a versão 1.00 não contempla. O que devemos fazer ao saber que o Município XYZ vai aderir o compartilhamento da NFS-e Padrão Nacional em 2026? Resposta: Precisamos saber se o provedor que atende o Município XYZ vai ou já implementou uma API própria que recepciona o XML segundo o Padrão Nacional ou se o ele vai fazer alterações no layout em uso para atender a Reforma Tributária. Se vai ou se já implementou uma API própria precisamos saber quais são as URLs de homologação e produção para que possamos alterar o arquivo ACBrNFSeXServicos.ini, agora se o provedor vai alterar o layout em uso, precisamos do Manual, Schemas e das URLs (caso sejam alteradas) para que possamos não só alterar o arquivo INI, mas também alterar as units do componente do provedor. Toda ajuda da comunidade ACBr sempre foi, é e sempre será bem vida.

Olá comunidade ! Foi publicado no dia 03/10/2025 a versão 1.30 desta nota técnica trazendo novos campos, novas regras de validação, alteração no cronograma e ajustes diversos. Alterações Novos campos e novos valores Adiciona no leiaute da NFe\NFCe os campos: dPrevEntrega, tpCredPresIBSZFM e indDoacao. Adiciona novos valores válidos para os campos tpNFDebito e tpNFCredito. Novos grupos Remove os grupos de gIBSCredPres, gCBSCredPres e gCredPresIBSZFM de dentro dos respectivos impostos e os adiciona em um novo grupo específico chamado gCredPresOper. Adiciona os novos grupos gAjusteCompet e gEstornoCred. Regras de validação Adiciona novas regras de validação para tratar os novos campos e grupos que foram incluídos. Altera a observação de algumas regras para considerar os novos valores possíveis para os campos já existentes. Substitui algumas regras de validação. Datas¹ O cronograma foi alterado postergando a entrada dos campos. Entrada dos schemas, das regras de validação (com exceção de algumas regras em específicas) e dos eventos: Implantação Homologação: Até 29/10/2025 Implantação Produção: 10/11/2025 Entrada das regras de validação (B10a-10, B10a-20, B10a-30, B10a-40, B10a-50, B25-110, B25-120, I05k-10, I05k-20, UB112-10, UB112-20, UB112-30, UB116-10, UB116-20, UB116-30, UB120-10, UB120-20, UB122-10, UB123-10, UB123-20, UB125-10, UB126-10, UB127-10, UB127-20, UB129-10, UB130-10, UB131-10, UB131-20, UB131-30, UB131-40, UB131-50, UB132-10, UB133-10, W59f-10, W59g-10): Implantação Homologação: Até 24/11/2025 Implantação Produção: 02/02/2026 Inicio da obrigatoriedade dos novos tributos: Implantação Homologação: Implementação futura Implantação Produção: 05/01/2025 Detalhamento Outubro/2025: Homologação: Preenchimento dos campos IBS/CBS é facultativo. Se preenchidos, as RV serão aplicadas. Produção: Preenchimento dos campos IBS/CBS é facultativo. Se preenchidos, as RV serão aplicadas. Sem valor jurídico para os novos tributos. Janeiro/2026: Homologação: Preenchimento dos campos IBS/CBS é facultativo. Se preenchidos, as RV serão aplicadas Produção: Preenchimento dos campos IBS/CBS passa a ser obrigatório conforme legislação. Para as NF-e e NFCe com IBS/CBS as RV serão aplicadas. Com valor jurídico para os novos tributos a partir de 01/01/2026. ¹ As datas foram reproduzidas no tópico conforme constam na Nota Técnica, no entanto, membros de nossa comunidade já relataram divergências nas datas estabelecidas na NT. Aguardemos novas informações. E como fica o ACBr? Esta versão traz modificações no leiaute e portanto modificações nas soluções do ACBr serão necessárias. Foi criada a tarefa ACBR-8146 para centralizar e registrar essas mudanças. Qualquer novidade será divulgada neste tópico ou em nossa área de notícias. Um agradecimento a todos os membros de nossa comunidade que compartilharam a informação da divulgação desta nova versão em nosso servidor do Discord. Leia a versão 1.30 dessa nota técnica completa AQUI.

Olá Pessoal, Depois de analises junto com a comunidade ACBr, decidimos que os campos referente ao Código de Classificação Tributária (cClassTribIS, cClassTribReg e cClassTrib) deve ser do tipo string em vez de um tipo enumerado. A motivação para essa mudança é que esses códigos podem no decorrer do tempo alguns podem deixar de existir, outros podem ser adicionados e outros códigos podem ser alterados mas mantendo a sua finalidade original, exatamente o que ocorre com os NCM dos produtos. Com essa mudança basta o desenvolver atualizar a sua tabela de códigos no banco de dados sem a necessidade de atualização da aplicação. Vale também ressaltar que no Portal da SEFAZ-Virtual do RS temos as tabelas de CST e cClassTrib e é possível baixa-las no formato CSV, Excel e Json. Esperamos contar com a compreensão de todos. Os fontes dos componentes afetados com essa mudança vão ser enviados para o SVN na data de 19/08/2025. Componentes afetados com essa mudança: ACBrBPe, ACBrCTe, ACBrNF3e, ACBrNFCom, ACBrNFe e ACBrNFSeX e consequentemente as Libs e o ACBrMonitor. Na minha aplicação o que eu devo mudar? Se você atribui diretamente o enumerado aos campos cClassTrib mencionados vai ter que fazer essa alteração: ==> Se você usa as funções de conversão para converter de string para o enumerado uma vez que no seu banco de dados o código esta como string, basta remover as funções de conversão e atribuir diretamente o conteúdo do campo do banco de dados ao campo do componente. Para quem utiliza as Lib ou o Monitor não vai precisar se preocupar com essa mudança.

O que é o CIOT? CIOT é a sigla para Código Identificador da Operação de Transporte. Esse é um código gerado para registrar operações de transporte rodoviário remunerado de cargas junto à ANTT (Agência Nacional de Transportes Terrestres). Ele é obrigatório para o controle e rastreabilidade dessas operações no território nacional. Atualmente a regulamentação mais recente relacionada a ele sendo a Resolução nº 6.078, de 24 de março de 2026. O CIOT é uma novidade? Não. O CIOT já existe desde 2011. No entanto, quando foi estabelecido, seu uso era obrigatório apenas em operações de transporte muito específicas. Esse cenário mudou em 2026 com a Resolução nº 6.078, de 24 de março de 2026, que efetivamente tornou o CIOT obrigatório em praticamente todas as operações de transporte rodoviário remunerado de cargas. Veja abaixo a evolução da legislação: Quem deve gerar o CIOT? A Resolução nº 6.078/2026 estabeleceu em seu Art. 1º-A que toda operação remunerada de transporte rodoviário de cargas deverá ser registrada por meio de um CIOT, delegando a responsabilidade pela sua geração conforme a tabela abaixo: Operação de Transporte Responsável pelo CIOT Quando há contratação de TAC ou TAC Equiparado Contratante/Subcontratante Quando NÃO há contratação de TAC ou TAC Equiparado A própria ETC O que significam os termos TAC, TAC Equiparado e ETC mencionados acima? TAC é a sigla para Transportador Autônomo de Cargas. É a pessoa física que realiza o transporte rodoviário de cargas como atividade profissional. ETC é a sigla para Empresa de Transporte Rodoviário de Cargas. É a pessoa jurídica que tem como atividade principal o transporte rodoviário de cargas. TAC Equiparado é a denominação dada à ETC que possui em sua frota até 3 veículos registrados junto ao Registro Nacional de Transportadores Rodoviários de Cargas (RNTRC), bem como às Cooperativas de Transporte de Cargas, que também se enquadram nessa categoria. TAC Agregado é o Transportador Autônomo de Cargas que coloca veículo de sua propriedade ou posse — conduzido por ele mesmo ou por um preposto — a serviço de um contratante em regime de exclusividade, mediante remuneração previamente acordada. IPEF é a sigla para Instituição de Pagamento Eletrônico de Frete. É a instituição regulamentada pela ANTT responsável por realizar o pagamento eletrônico do frete e vinculá-lo à operação de transporte remunerado correspondente. Além disso, a IPEF participa do arranjo de pagamentos instantâneos instituído pelo Banco Central do Brasil, o que na prática significa que o pagamento do frete pode ser realizado via Pix. Devo gerar o CIOT quando a empresa possui frota própria e motoristas empregados? Sim, quando a empresa presta transporte rodoviário remunerado de cargas para terceiros. Ter frota própria e motoristas empregados não caracteriza, por si só, a operação como transporte de carga própria. Se a empresa transporta cargas ou encomendas de terceiros mediante remuneração, trata-se de uma operação de transporte por conta de terceiros, e o CIOT deve ser gerado conforme a regulamentação vigente. Por outro lado, se a carga transportada é da própria empresa, sem prestar serviço a terceiros e sem recebimento de frete, a geração do CIOT não é necessária. Como faço para gerar o CIOT? A geração do CIOT é feita de formas distintas dependendo de quem é o responsável pela operação. Se houve contratação de TAC ou TAC Equiparado, o CIOT deve ser gerado por uma das IPEFs habilitadas pela ANTT, por meio de portal próprio ou integração direta via web service disponibilizado pela própria IPEF. Caso a ETC seja a responsável, ela pode utilizar o sistema disponibilizado pela ANTT por meio do programa CIOT para Todos. Para que servem a DLL e o executável encontrados no programa CIOT para Todos? Não para uso rotineiro. A geração do CIOT por meio do programa CIOT para Todos deve ser feita via integração com o web service disponibilizado pela própria ANTT. A DLL e o executável são destinados exclusivamente ao uso em contingência, ou seja, situações em que a integração com o web service não está disponível. Nesses casos, eles permitem gerar o número do CIOT sem todos os dados da operação, funcionando como solução temporária. No entanto, em até 168 horas, o CIOT deverá ser regularizado pelos meios adequados, conforme o fluxograma abaixo. Existe alguma solução no ACBr para me ajudar a gerar o CIOT? Atualmente o ACBr conta com o componente desenvolvido nativamente para Delphi e Lazarus denominado ACBrCIOT, que realiza a integração com a IPEF eFrete. A integração com novas IPEFs, bem como a disponibilização do CIOT no ACBrMonitorPLUS e na ACBrLib, estão previstas em nosso planejamento para implementação futura. O programa de exemplo do componente ACBrCIOT pode ser encontrado no caminho: ..\trunk2\Exemplos\ACBrDFe\ACBrCIOT onde estão disponíveis versões tanto para Delphi quanto para Lazarus. Onde posso encontrar os manuais das IPEFs? Os manuais de cada IPEF podem ser encontrados no portal respectivo de cada uma. Além disso, nós também os centralizamos em nosso biblioteca do Tools em ...\tools\DFe\CIOT Onde devo preencher o CIOT? O CIOT deve ser informado no Manifesto Eletrônico de Documentos Fiscais (MDF-e), no elemento CIOT, que faz parte do grupo infCIOT presente nas informações da ANTT. A estrutura do XML com essa informação é semelhante a este exemplo: <rodo> <infANTT> <infCIOT> <CIOT>pseudoCIOT</CIOT> <CNPJ>pseudoCNPJ</CNPJ> </infCIOT> </infANTT> </rodo> O campo <CNPJ> ou <CPF> deve ser preenchido com a identificação do responsável pela geração do CIOT. Como preencher o CIOT no MDF-e utilizando o componente ACBrMDFe? Caso utilize componente nativo para Delphi/Lazarus, alimente as propriedades: var lMDFe: TMDFe; lRodo: Trodo; linfCIOT: TinfCIOTCollectionItem; begin lMDFe := ACBrMDFe1.Manifestos.Add.MDFe; lRodo := lMDFe.rodo; linfCIOT := lRodo.infANTT.infCIOT.New; linfCIOT.CIOT := 'pseudoCIOT'; linfCIOT.CNPJCPF := 'pseudoCNPJ'; //Demais informações... end; Caso utilize ACBrMonitorPLUS ou ACBrLibMDFe, alimente em seu arquivo INI: [infCIOT001] CNPJCPF=pseudoCNPJ CIOT=pseudoCIOT O CIOT é exibido no DAMDFe? Não! De acordo com o Manual MDFe Anexo II DAMDFE v3.00a, não há previsão de que o CIOT seja exibido no DAMDFe, portanto sua ausência não indica nenhum problema. Links Úteis e Referências RESOLUÇÃO Nº 3.658, DE 19 DE ABRIL DE 2011 RESOLUÇÃO Nº 5.862, DE 17 DE DEZEMBRO DE 2019 RESOLUÇÃO ANTT Nº 6.078, DE 24 DE MARÇO DE 2026 Lei nº 11.442 de 05 de janeiro de 2007 Perguntas Frequentes - CIOT

Olá comunidade ! No dia 28/04/2026, foi publicada no Diário Oficial da União a Resolução CGSN nº 189/2026. Esta resolução estabelece que os prestadores de serviços enquadrados como Microempresa (ME) ou Empresa de Pequeno Porte (EPP), optantes pelo Simples Nacional, deverão emitir a Nota Fiscal de Serviços Eletrônica (NFS-e) por meio do Emissor Nacional da NFS-e, a partir de 01/09/2026. A obrigatoriedade também se aplica aos casos em que a opção pelo Simples Nacional estiver pendente de análise ou sob efeitos de impedimento previsto na legislação. A partir dessa data, sistemas emissores próprios ou municipais poderão deixar de ser utilizados para essas situações, sendo necessário utilizar o Emissor Nacional da NFS-e conforme definido na resolução.

Olá comunidade ! Foi publicado no Diário Oficial da União o DESPACHO Nº 33, DE 8 DE OUTUBRO DE 2025, efetivamente postergando a entrada em vigor do fim da NFCe para CNPJ para 05/01/2026. Fazem parte deste Despacho, dentre outros, os Ajustes Sinief relacionados abaixo. O Ajuste SINIEF Nº 28, de 3 de Outubro de 2025 altera o Ajuste SINIEF Nº 12 de 29 de Abril que definiu as modificações feitas na NFe para ser usada no lugar da NFCe para CNPJ, efetivamente mudando sua cláusula que define sua entrada em vigor para: O Ajuste SINIEF Nº 30, de 3 de Outubro de 2025 altera o Ajuste SINIEF Nº 11 de 29 de Abril que definiu a proibição da NFCe para CNPJ, efetivamente mudando sua cláusula que define sua entrada em vigor para:

Olá comunidade ! Foi publicada a Resolução ANTT nº 6.078/2026, que altera a Resolução ANTT nº 5.862/2019, responsável por regulamentar o cadastro da Operação de Transporte necessário para a geração do Código Identificador da Operação de Transporte (CIOT). Com essa publicação, a partir de 24/05/2026, passa a ser obrigatória a geração e vinculação do CIOT ao MDF-e em todas as operações de transporte, exceto quando o valor do frete estiver em desacordo com o piso mínimo aplicável. Detalhando melhor, a nova norma é composta por quatro artigos, trazendo alterações de redação, revogações e definição de datas de vigência. Entre os pontos mais relevantes, destaca-se a nova redação incluída pelo Art. 1º, que estabelece: Outras disposições Art. 2º: estabelece valores de multas para determinadas infrações. Art. 3º: revoga o § 1º do art. 5º e o art. 8º da Resolução ANTT nº 5.862/2019. Art. 4º: define que a resolução entra em vigor em 24/05/2026.

Olá Pessoal, Tenho boas noticias para vocês que utilizam o componente ACBrNFSeX com Fast Report. Hoje (06/04/2026) foi enviado para o SVN a implementação em Fast Report para a impressão do DANFSE segundo o layout do Padrão Nacional. Lembrando da nova propriedade de configuração para que possamos informar o caminho e o nome da imagem referente ao logo da NFS-e. Sendo assim temos as propriedades Logo para informar o caminho e o nome da imagem do logo da prefeitura e agora a propriedade LogoNFSe para o logo da NFS-e. Foi disponibilizado também na pasta Delphi e Lazarus dos programas exemplos o arquivo PNG referente ao Logo da NFS-e. O fr3 a ser usado será DANFSEPadraoNacional.fr3 O mesmo está compatível com versões mais básicas do fast report. também temos um exemplo para testar caso venha a ter erros ao abrir ele basta excluir o arquivo NFSe.dproj e abrir NFSe.dpr Ele também deve funcionar com versões 7 ao 13.1 e fast report 3,4,5,6, 2024,2025 e 2026 no modelos Embarcadero Edition, Standard, Professional e Enterprise Qualquer problema por favor crie um tópico no fórum relatando o problema encontrado. Detalhe importante, o XML a ser carregado para poder gerar o DANFSE no Padrão Nacional obrigatoriamente tem que estar no layout da NFS-e Padrão Nacional, caso contrario não vai funcionar. Atenção e somente lembrança para quem já usa : Deve se informar o fr3 no path ACBrNFSeXDANFSeFR1.FastFile := 'seupath\DANFSEPadraoNacional.fr3';

Olá comunidade ! Foi publicada a versão 1.30 da nota técnica 2022/002. Esta versão traz alterações no leiaute e também nas regras de validação da Sefaz visando flexibilização. Alterações Adiciona os novos valores válidos para o "motivo da desoneração do ICMS" (tag motDesICMS no arquivo XML). O grupo de Partilha de ICMS entre a UF de Origem e a UF de Destino (tag ICMSPart no arquivo XML) agora também pode receber o CST 20. Adiciona uma tag cBenefRBC para receber o "Código de Benefício Fiscal na UF aplicado ao item quando houver RBC". O grupo de ICMS20 ganhou campos para informação de valores de diferimento e diferimento do FCP. O grupo de ICMSPart ganhou campos para receber as informações de desoneração. As regras de validação E03a-10, E12-10, E14-10 e E16a-20 que verificam operação com o exterior ganharam uma exceção para não serem aplicadas quando CFOP for igual a 7552 ou 7501. A regra BA02a-10 que permite referenciar chave de acesso com o código numérico zerado foi atualizada para permitir também quando a nota for de ajuste. Datas Implantação Teste: Até 30/03/2026 Implantação Produção: Até 06/04/2026 E como fica o ACBr? Como a nota técnica traz alterações no leiaute, modificações nas soluções ACBr serão necessárias. Foi criada a tarefa ACBR-9067 para esta finalidade. Leia a versão 1.30 desta nota técnica na íntegra AQUI. Um agradecimento ao membro de nossa comunidade @Felipe Mariano por compartilhar a informação no canal #sefaz em nosso servidor do Discord.

Olá comunidade ! Foi publicado o Decreto Nº 49.127 de 14 Novembro de 2025 no estado de Minas Gerais determinando a obrigatoriedade do credenciamento das empresas desenvolvedoras do software de emissão de NFe e NFCe junto a Secretaria Estadual da Fazenda (SEF). O decreto também menciona que a obrigatoriedade da informação do Responsável Técnico na emissão de NFe e NFCe será definida em portaria posterior. É importante ressaltar que apesar dessa publicação, ainda não foi disponibilizado link para que as software houses possam realizar o cadastro. Até o momento foi publicado apenas a portaria determinando a obrigatoriedade, mas é esperado que uma normativa detalhando o processo e os prazos seja publicada posteriormente. Vale relembrar que os membros de nossa comunidade que são ACBr PRO e ACBr Corporativo tem acesso ao curso: Responsável Técnico na NFe. Onde o conceito de responsável técnico é explicado e a forma de preencher essa informação nas soluções ACBr é demonstrada na prática.

Coordenação Técnica do ENCAT 02/09/2025 Lançamento do Portal da Conformidade Fácil A partir de agora, o projeto Conformidade Fácil conta com uma área temática exclusiva no portal dos Documentos Fiscais Eletrônicos da SVRS. Neste espaço serão disponibilizados de forma mais direta os serviços e consultas, assim como, os materiais e novidades em relação a esta importante iniciativa do ENCAT, SVRS e PROCERGS. Link para acessar o Portal: Portal da Conformidade Fácil

Olá, comunidade! Passando para avisar que o Fortes Report recebeu uma atualização importante! O gerador de relatórios agora conta com um novo padrão de código de barras: o Code 128 Automático. O que mudou? Anteriormente, era necessário escolher manualmente entre os padrões 128 A (letras maiúsculas), 128 B (letras minúsculas) ou 128 C (apenas números). Com o novo modelo Automático, o próprio componente identifica o tipo de caractere no conteúdo e alterna para o padrão mais eficiente de forma inteligente. Por que essa atualização é crucial? Essa melhoria nasceu principalmente para atender às futuras implementações dos DANFes (e outros documentos fiscais), que precisarão ser compatibilizados com os novos CNPJs alfanuméricos. Como atualizar? Você pode baixar a versão mais recente direto no repositório oficial do GitHub e utilizar o instalador disponível: GitHub - Fortes Report CE Mantenham seus ambientes atualizados para evitar surpresas nas próximas regras fiscais!

Olá comunidade ! Foi publicada a Nota Técnica 2026/002 em sua versão 1.00 para o CTe trazendo evoluções em relação a NT2025/001. (Veja o tópico dela aqui). Alterações Adiciona nos grupos gDevTrib o campo pDevTrib para receber o percentual da devolução do tributo. Inclui um grupo gALCZFMCBS para receber as informações de operações em áreas incentivadas pela ALC\ZFM. Adiciona um novo campo ISUFEmit para receber a inscrição SUFRAMA do emitente. Insere novos campos para informações de pagamento antecipado. Acrescenta novas regras de validação para os campos adicionados. Datas Obrigatoriedade do preenchimento dos campos da RTC. Implantação Homologação: 01/07/2026 Implantação Produção: 03/08/2026 Novos campos e regras Implantação Homologação: 03/08/2026 Implantação Produção: 31/08/2026 E como fica o ACBr? Como é possível observar, a NT traz alterações de leiaute e por isso, modificações serão necessárias. Foi criada a tarefa ACBR-9485 para adequação. Assim que houver novidades será divulgado em nossa área de notícias. Leia a versão 1.00 desta nota técnica na íntegra AQUI. Um agradecimento ao membro de nossa comunidade @Mateus Jurado por divulgar a informação no canal #sefaz em nosso servidor do Discord.

Olá comunidade ! Para atender a Reforma Tributária que começa em 2026, os 5.570 municípios do Brasil deverão escolher entre 3 caminhos: Migrar para o Padrão Nacional com a modalidade de emissão. Continuar usando o provedor atual, com a modalidade de compartilhamento com o padrão nacional através de API própria do provedor. Continuar usando o provedor atual, com a modalidade de compartilhamento com o padrão nacional, modificando o leiaute do provedor. Para garantir que o componente ACBrNFSeX continue robusto e atualizado, antecipando essas mudanças, contamos o apoio da nossa comunidade. Como você pode ajudar? Se você tem contato com a prefeitura ou provedor responsável por atender algum município, por favor, compartilhe conosco. Qualquer informação oficial sobre alterações previstas pode ajudar. Responda aqui mesmo neste tópico conforme o modelo: Cidade/UF: Previsão de Mudança: Tipo de Mudança: (Padrão Nacional/API Própria/Mudança de Leiaute) Fonte/Documentação: Acompanhe o tópico abaixo para saber qual é a situação atual do componente

Olá Pessoal, Em nossa biblioteca encontra-se uma planilha em Excel que contem a correlação NBS o IndOp e o cClassTrib. Para quem emite NFS-e deve conferir essa planilha. Ela esta com o seguinte nome: AnexoVIII-CorrelacaoItemNBSIndOpCClassTrib_IBSCBS_V1.00.00 Link para acessar a pasta onde esta a referida planilha: p/acbr/code - Revision 41764: /tools/DFe/NFSe_Nacional/NT/2025

Envio Para enviar uma NFe de forma síncrona usando o componente ACBrNFe nativo para Delphi e Lazarus faça conforme exemplo: //Para imprimir o DANFe automaticamente se autorizado... ACBrNFe.Enviar(NumLote, True, True); //Para NÃO imprimir o DANFe automaticamente se autorizado... ACBrNFe.Enviar(NumLote, False, True); Se você utiliza ACBrMonitor, use os comandos NFe.CriarEnviarNFe ou NFe.EnviarNFe: //Para imprimir o DANFe automaticamente depois de autorizado... NFe.CriarEnviarNFe(cIniNFe,nLote,1,1) //Para NÃO imprimir o DANFe automaticamente depois de autorizado... NFe.CriarEnviarNFe(cIniNFe,nLote,0,1) //Para imprimir o DANFe automaticamente depois de autorizado... NFe.EnviarNFe(cArqXML,nLote,,1,,1) //Para NÃO imprimir o DANFe automaticamente depois de autorizado... NFe.EnviarNFe(cArqXML,nLote,,0,,1) Se você utiliza ACBrLib, use o método NFe_Enviar: //Para imprimir o DANFe automaticamente depois de autorizado... NFE_Enviar(nLote, True, True, True); //Para NÃO imprimir o DANFe automaticamente depois de autorizado... NFE_Enviar(nLote, False, True, True); Retorno Para ler as informações de retorno de uma NFe emitida de forma síncrona usando o componente ACBrNFe nativo para Delphi e Lazarus leia as seguintes propriedades: //Informações de retorno relacionadas ao web service... ACBrNFe.WebServices.Enviar.tpAmb; ACBrNFe.WebServices.Enviar.verAplic; ACBrNFe.WebServices.Enviar.cStat; ACBrNFe.WebServices.Enviar.cUF; ACBrNFe.WebServices.Enviar.xMotivo; ACBrNFe.WebServices.Enviar.Protocolo; //Informações de retorno específicas a NFe... ACBrNFe.NotasFiscais[0].NFe.procNFe.tpAmb ACBrNFe.NotasFiscais[0].NFe.procNFe.verAplic ACBrNFe.NotasFiscais[0].NFe.procNFe.chNFe ACBrNFe.NotasFiscais[0].NFe.procNFe.dhRecbto ACBrNFe.NotasFiscais[0].NFe.procNFe.nProt ACBrNFe.NotasFiscais[0].NFe.procNFe.cStat ACBrNFe.NotasFiscais[0].NFe.procNFe.xMotivo Se você utiliza ACBrMonitorPlus ou ACBrLib: [Envio] CStat=100 CUF=13 DhRecbto=08...8 Msg=Autorizado o uso da NF-e NProt=1...0 NRec= TMed=0 VerAplic=AM4.00-NAC Versao=4.00 XMotivo=Autorizado o uso da NF-e tpAmb=2 [NFe1] Id=ID11...0 NomeArq=C:\ACBrMonitorPLUS\Arqs\DFes\... XML=<protNFe versao="4.00"><infProt>... cStat=100 chDFe=13...05 dhRecbto=08/07/2025 14:13:48 digVal=Q...= nProt=1...0 tpAmb=2 verAplic=AM4.00-NAC xMotivo=Autorizado o uso da NF-e Expandindo o conhecimento Veja o tópico Como funciona os modos de envio Assíncrono e Síncrono para uma explicação mais detalhada sobre os modos de envio síncrono e assíncrono, as principais diferenças entre eles e quais documentos fiscais usam cada modo.

O que é a Reforma Tributária? A reforma tributária é um processo de reformulação do sistema tributário brasileiro, tendo como objetivo final a sua simplificação. Em discussão desde 2023, com seu marco fundamental sendo a Emenda Constitucional nº 132, de 20 de dezembro de 2023, e sua consolidação na Lei Complementar nº 214, de 16 de janeiro de 2025, o processo, que afeta todo o Brasil foi amplamente discutido e avaliado por diversos comitês gestores. Dada a complexidade e a extensão do atual sistema tributário, ainda existem alguns fatores que estão sendo avaliados e estudados. No entanto, com a publicação da Lei Complementar, é inegável que a Reforma Tributária já é uma realidade e preparar seu o software é uma obrigação, não uma opção. Alguns conceitos essenciais. Com a quantidade de informações envolvidas, não é de se estranhar que alguns conceitos possam causar confusão. No entanto, o correto entendimento deles é importante para acompanhar as novidades e se adequar às mudanças propostas: LC nº 214/2025: é a lei que consolida a Reforma Tributária como um todo. Todas as informações, análises de comitê gestor, notas técnicas e demais documentos produzidos têm como base o objetivo de atender o que é proposto nela. Imposto sobre Operações relativas à Circulação de Mercadorias e sobre Prestações de Serviços de Transporte Interestadual e Intermunicipal e de Comunicação (ICMS): é um tributo de competência estadual, existente no regime tributário atual, utilizado para acobertar operações de circulação de mercadorias, prestações de serviços de transporte interestadual e intermunicipal, e de comunicação. Sua extinção está prevista para o fim da Reforma Tributária. Imposto sobre Serviços de Qualquer Natureza (ISS): é um tributo de competência municipal, existente no regime tributário atual, utilizado para acobertar prestações de serviços em geral. Sua extinção está prevista para o fim da Reforma Tributária. Imposto sobre Bens e Serviços (IBS): é um novo tributo proposto pela Reforma Tributária, a ser adotado gradativamente na emissão dos documentos fiscais eletrônicos, de competência municipal e estadual, com o objetivo final de substituir o ICMS e o ISS. PIS: é um tributo de competência federal, existente no regime tributário atual, que incide sobre diversas operações e cuja finalidade é contribuir com a seguridade social. Sua extinção está prevista para o fim da Reforma Tributária. COFINS: é um tributo de competência federal, existente no regime tributário atual, que incide sobre diversas operações e cuja finalidade é contribuir com a seguridade social. Sua extinção está prevista para o fim da Reforma Tributária. Contribuição Social sobre Bens e Serviços (CBS): é um novo tributo proposto pela Reforma Tributária, a ser adotado gradativamente na emissão dos documentos fiscais eletrônicos, de competência federal, com o objetivo final de substituir o PIS e a Cofins. Imposto Seletivo (IS): é um novo tributo proposto pela Reforma Tributária. Conhecido pela alcunha de "imposto do pecado", sua aplicação será voltada a mercadorias e serviços considerados danosos ou prejudiciais à saúde e ao meio ambiente. Split Payment (Recolhimento na Liquidação Financeira): é uma solução estrutural proposta pela Reforma Tributária, com o objetivo de automatizar o recolhimento dos tributos no momento da liquidação financeira de uma operação, facilitando a vida do contribuinte e reduzindo a inadimplência. Nota de Débito e Nota de Crédito: são duas novas finalidades de emissão adicionadas à Nota Fiscal Eletrônica modelo 55, destinadas a serem utilizadas para ajustes de lançamentos do IBS e da CBS. Qual é o cronograma da Reforma Tributária? Alterar um sistema tributário deve ser uma operação muito bem pensada e analisada. Por isso, a Reforma Tributária é um processo longo, com início das mudanças em 2026 e término previsto para 2033. 2026 Ano de Testes 2027-2028 Início da Cobrança e Alíquotas Iniciais 2029-2032 Transição Progressiva e Conclusão 2033 Reforma Tributária em Pleno funcionamento Alíquota de testes para o IBS e para o CBS. Soma das alíquotas não pode passar de 1%. Sem IS. Sem cobrança efetiva dos impostos desde que as obrigações acessórias estejam em ordem. Início da cobrança efetiva do CBS com alíquota fixada pela LC. Extinção do PIS e do COFINS. Alíquota de IBS estadual e municipal em 0,05%. Começo do IS. Zera a alíquota de IPI. Transição do ICMS e do ISS para o IBS. Redução gradativa das alíquotas de ICMS e ISS até zerar. IBS, CBS e IS em pleno funcionamento. Fim do ICMS, ISS, PIS e COFINS. Conforme mencionado anteriormente, a Reforma Tributária é um projeto com legislação já aprovada tanto na Câmara dos Deputados quanto no Senado, e com regramentos complementares sendo discutidos e publicados por diversos entes fiscais e regulatórios. Trata-se de uma iniciativa robusta, com um grande número de profissionais e instituições trabalhando para que ela seja implementada da forma correta. Por isso, a possibilidade de adiamento ou retrocesso torna-se cada vez mais remota — e, portanto, não é prudente apostar em prorrogações ou revisões drásticas. Qual é a vantagem da Reforma Tributária? Ao final da reforma, haverá a simplificação do sistema tributário, com a redução da quantidade de impostos. Outro ponto importante é a mudança de paradigma trazida pela reforma: os novos tributos propõem o cálculo “por fora”, diferentemente do que é feito atualmente. Isso trará total transparência para a sociedade e para o contribuinte. Como isso vai impactar meu cliente? Seu cliente precisará enviar as informações dos novos tributos nos respectivos documentos fiscais eletrônicos, em paralelo aos impostos já existentes, durante o período de transição. Caso contrário, ele não conseguirá emitir seus documentos fiscais. Concluído o processo de adequação à reforma, seu cliente passará a enviar apenas os novos tributos. A adequação não é uma opção — é uma obrigatoriedade. Como eu devo adequar meu software? Apesar de a LC nº 214/2025 consolidar a Reforma Tributária como um todo, seu conteúdo precisa ser "traduzido" tecnicamente em orientações sobre modificações nos documentos fiscais eletrônicos, de modo a atender ao que é estabelecido na lei. O instrumento utilizado para isso é a publicação de Notas Técnicas: Nota Técnica 2025/002 - NFe-/NFC-e - Reforma Tributária do Consumo. Nota Técnica 2025/001 - CT-e/GTVe/CTeOS - Reforma Tributária do Consumo. Nota Técnica 2025/001 - NF3e - Reforma Tributária do Consumo. Nota Técnica 2025/001 - NFCom - Reforma Tributária do Consumo. Nota Técnica 2025/001 - BP-e - Reforma Tributária do Consumo. Portanto, você deve seguir o que é estabelecido nessas notas técnicas para adequar seu software. O ACBr está de acordo com as alterações propostas por essas notas técnicas? Sim, os respectivos componentes já foram adequados às alterações propostas pelas Notas Técnicas mencionadas acima. Basta atualizar seus fontes e reinstalar o ACBr com a opção “Usar ACBrXMLDocument” selecionada no instalador, para que seja possível realizar os testes. A mesma lógica se aplica para quem utiliza o ACBrMonitorPLUS e a ACBrLib. Como conferir o que mudou no ACBr? Se você utiliza os componentes nativos para Delphi/Lazarus, ao abrir o programa exemplo, foi adicionada uma nova opção de configuração para que sejam alimentadas as propriedades relacionadas a Reforma Tributária. Basta pesquisar nos fontes do programa exemplo respectivo por "Reforma Tributária" para encontrar os trechos que trazem exemplo de preenchimento. O mesmo vale para a ACBrLib e para o ACBrMonitor, com exemplos específicos para Reforma na documentação de ambos. Como identificar se um XML possui os dados da Reforma Tributária? Pode haver pequenas variações ou particularidades de acordo com o tipo de documento fiscal eletrônico, mas a presença do elemento <IBSCBS> pode ser considerada um indicativo de que o XML contém campos relacionados à Reforma Tributária. Veja a seguir um exemplo da estrutura do elemento <IBSCBS> em um XML de uma NF-e: <IBSCBS> <CST>000</CST> <cClassTrib>000001</cClassTrib> <gIBSCBS> ... </gIBSCBS> <gCredPresIBSZFM> ... </gCredPresIBSZFM> </IBSCBS> Já li, agora quero escutar quem entende. Considerando a complexidade e a relevância da Reforma Tributária, foram realizadas edições do Papo PRO ACBr dedicadas a discutir o tema, trazendo especialistas e perspectivas práticas para ajudar na compreensão e preparação para as mudanças. A lista abaixo apresenta as edições já publicadas, em ordem da mais antiga para a mais recente: A Reforma Tributária está chegando... Descubra como ela impactará seu Software! Arquitetura Fiscal: Reforma Tributária para Software Houses A Reforma Tributária e a Tecnologia, como está o preparo da sua SH? Reforma Tributária Comece já a adequação de seu software! Adeus a Velha NFe? Prepare o seu ACBr! Adeus a Velha NFe? Prepare o seu ACBr! - Parte 2 Reforma Tributária não é só a NFe! Entenda todos os documentos alterados pela Reforma Tributária! Links importantes Emenda Constitucional nº 132, de 20 de dezembro de 2023 Lei Complementar nº 214, de 16 de janeiro de 2025 Projeto Conformidade Fácil: o validador das Notas Técnicas da Reforma Tributária do Consumo. Implantação das Notas Técnicas Reforma Tributária na SVRS