Painel de líderes

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 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') const acbrlibCep = new ACBrLibCepMT(acbrlibPath, configPath, '') try { acbrlibCep.inicializar() acbrlibCep.configGravarValor('CEP','WebService','3') acbrlibCep.configGravar() const cep = acbrlibCep.buscarPorCep('18270170') console.log(cep) acbrlibCep.finalizar() } catch (error) { console.error(error) } 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, 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.

Boa tarde comunidade ACBr ! "Em relação às intercorrências apresentadas no grupo sobre o QRCode 3.0 offline (SP), informamos que recebemos retorno da Sefaz/SP hoje, a qual comunicou que foi disponibilizada uma correção em ambiente de homologação." Por favor façam novos testes ! Caso identifiquem algum erro, pedimos a gentileza de registrarem a ocorrência no portal da Sefaz/SP (Fale Conosco) !

Boa tarde ! Já esta disponível em nossa biblioteca a Nota Técnica 2019/001 versão 1.70 que trata sobre novas regras de validação. Publicada em agosto de 2025 A nova versão da NT 2019.001 traz atualizações importantes nas regras de validação da NF-e/NFC-e, com destaque para os estados de São Paulo (SP) e Santa Catarina (SC). Regras de validação: N12-85 – exigindo o código de benefício fiscal quando se utiliza um CST de benefício fiscal, a critério da unidade federadaCST exige código de benefício fiscal (cBenef) N12-86 – impedindo que se informe o código de benefício fiscal para CST de benefício fiscal, a critério da unidade federadaCST sem benefício fiscal não pode ter cBenef N12-90 - exigindo valor do ICMS desonerado e o motivo da desoneração, a critério da unidade federada N12-94 – exigindo que o CST corresponda ao tipo de código de benefício fiscal informado, a critério da unidade federada N12-97 – exigindo informações sobre o diferimento quando se utiliza um CST de diferimento, a critério da unidade federada. N12-98 – que verifica a existência do cBenef, a critério da unidade federada, exceto para Simples NacionalVerifica existência e vigência do cBenef N14a-10, N14a-20 - visando validar respectivamente a obrigatoriedade e o correto preenchimento do campo código de benefício fiscal de redução de BC do Grupo Tributação do ICMS= 51 (tag:ICMS51/cBenefRBC). I05h-10 – visando validar o correto preenchimento do campo código de crédito presumido (tag: cCredPresumido).Valida o campo cCredPresumido (Crédito Presumido) Regras de Validação para São Paulo (SP) Modelos aplicáveis: NF-e (55) e NFC-e (65) Datas: Homologação: 12/01/2026 Produção: 06/04/2026 Regras ativadas: N12-85, N12-86, N12-94, N12-97, N12-98 Regras não aplicadas: N12-90, N14a-10, N14a-20, I05h-10 Regras de Validação para Santa Catarina (SC) Modelos aplicáveis: NF-e (55) e NFC-e (65) Datas: Homologação: 02/12/2024 Produção: 03/11/2025: N12-85, N12-86, N12-94, N12-97, N12-98, I05h-10 Homologação: 03/11/2025 Produção: 06/04/2026 N14a-10, N14a-20 E como fica o ACBr? Por ser uma alteração nas regras de validação na SEFAZ, não se faz necessário nenhuma alteração no Componente, Lib ou Monitor.

Caso você não tenha se atentado como eu que deveria salvar o ID do boleto CORA e salvou apenas o Nosso Numero, segue um programinha simples para ler os Logs do AcbrBoleto onde fica salvo essas informações, minha sorte que não apaguei os Logs, rs rs rs. LerLogCora.rar

Olá pessoal! Foi publicada a versão 1.08a desta nota técnica. Alterações Esta versão não traz alterações de leiaute, ela apenas altera a redação de algumas regras de validação corrigindo obrigatoriedade da aplicação, campo a ser validado e cálculo. Datas Foram mantidas as mesmas datas da versão anterior. E como fica o ACBr? Modificações não são necessárias na solução ACBr, visto que não houve modificação de leiaute. Leia a versão 1.08a desta nota técnica na íntegra [AQUI]

Aqui pra mim estava dando o mesmo erro com Windows 11 no cliente e na minha maquina com o certificado A3, e consegui resolver da seguinte forma: 1- Vá até o Painel de Controle do Windows. 2- Escolha a Opção "Opções da Internet"; 3- Vá até a aba “Avançadas”; 4- No bloco “Configurações”, vá até as últimas opções e deixe configurado como na imagem abaixo: 5- Vá em executar, digite certlm.msc para abrir a interface de certificados, caso esse comando não funcione, utilize o comando certmgr.msc. Remova estes certificados listados na imagem abaixo: 6- Execute como Administrador o InstaladorCadeias_1.0.2.0.exe, clique em Instalar e aguarde até que o processo seja finalizado. 7- Execute o FixCrypto_TLS1_2_Windows.reg. 8- Descompacte o CA.zip e execute o ac soluti ssl ev.cer e o Raiz-icp-brasil v10.cer. 9- Reinicie a máquina e teste novamente a comunicação com a Sefaz.

Boa noite. ADMS, Atualizei os fontes para gerar o PDF da segunda via do boleto, conforme minha necessidade, segue para avaliação. desculpa, pois não entendo bem do ACBR mas copie a mesma regra da Consultadetalhada, com o retorno do EndPoint pdfBoleto desta forma capturo o PDF atualizado. se puderem validar e subir no repositório seria bom assim na próxima atualização não preciso ter que refazer. testado aqui ok. Abraço.ACBrBoletoRet_Sicoob_V3.pasACBrBoletoW_Sicoob_V3.pas

Não, pode usar o layout 81 na API, usar o 810 com CNAB... Aqui eu passei a usar o 810 nos meus boletos, e uso API e CNAB ao mesmo tempo, na mesma carteira, os boletos antigos e os novos, tratando sem problema. A única coisa que precisei cuidar é não gerar em uma mesma remessa misturando os boletos antigos e os novos.

Boa tarde @BSSOFT e @maico.smaniotto, Já esta no SVN.

Boa tarde @Anderson Grolli, Já esta no SVN.

Boa tarde @Anderson Grolli, Já esta no SVN.

Juliomar, descobri o erro que ocorreu. Não era os schemas, mas sim um campo não informado, que me esclareceu foi o seu print. Desde já agradeço e muito a sua atenção. Obrigado

já enviei e-mail só que não tive retorno, e esse retorno só em homologação

o problema é questão do TLS 1.2 com o A1 tu configura wincrypt e vai no A3 ele tem que estar correto no windows diretamente além de cadeias de certificados então se seguiu o passo a passo de uns tópicos e desabilitou a restauração do sistema vai funcionar

Mas se iniciou com zero, o último NSU retornado vai ser 50 mesmo, pois ele traz lote de 50, não é isso?

Boa tarde, Teremos que compilar uma nova lib, avisaremos assim que estiver pronto ...

@Italo Giurizzato Junior, consegui dois xml de exemplo fornecidos pela prefeitura de Paranatinga-MT. Creio que deva ajudar voces a saberem o que precisa ser configurado ai no componente TACBrNFSeX para fazer com que os processos de emissão, cancelamento e afins possam funcionar corretamente. Segue em anexo. CancelarNfseEnvio.txt GerarNfseEnvio.txt @Juliomar Marchetti e @Italo Giurizzato Junior, , consegui dois xml de exemplo fornecidos pela prefeitura de Paranatinga-MT. Creio que deva ajudar voces a saberem o que precisa ser configurado ai no componente TACBrNFSeX para fazer com que os processos de emissão, cancelamento e afins possam funcionar corretamente. Segue em anexo.

Bom dia, fiz alguns ajustes no Boleto Híbrido Bradesco utilizando a Api do Portal. Ajuste no percentual, para juros e multa, precisa ser com 5 casas decimais senão o banco não aceita; Adicionado Data Limite de Pagto; Instruções pela API de Cobrança com QR Code, alteração de Data, Conceder Abatimento, Cancelar Abatimento, Protestar e Remover Protesto. Segue o Arquivo. Obrigado ACBrBoletoW_Bradesco.pas

Boa noite, Criada a TK-7535 para avaliação. Obrigado pela contribuição.

Alguma novidade pessoal ?

Alexandre era o .ini de servicos que estava errado , mudei e foi aqui ! mas muito obrigado em !

Bom dia, Obrigado por reportar, iremos atualizar a documentação Sugiro que troque por ubuntu:noble, este foi testado e funcional

obrigado

Obrigado.

Olá pessoal! Foi publicada a versão 1.08a desta nota técnica. Alterações Esta versão não traz alterações de leiaute, ela apenas altera a redação de algumas regras de validação corrigindo obrigatoriedade da aplicação, campo a ser validado e cálculo. Datas Foram mantidas as mesmas datas da versão anterior. E como fica o ACBr? Modificações não são necessárias na solução ACBr, visto que não houve modificação de leiaute. Leia a versão 1.08a desta nota técnica na íntegra [AQUI]

Olá, pessoal! Acessando a página de serviços da NFe da Sefaz de São Paulo, consta aviso informando que no dia 17/08/2025 será realizada uma manutenção no ambiente autorizador de NFe, com início às 08h00 e término às 14h00 do mesmo dia. Conforme exibido no aviso, e confirmado ao conferir no Portal da NF-e, a Sefaz de São Paulo existe contingência agendada no mesmo dia com previsão de início às 06h00 e término às 16h00. Para utilizar as soluções ACBr em contingência durante esse período siga as orientações do tópico abaixo: Ao acessar a página de serviços da NFCe, também consta aviso informando sobre manutenção no ambiente autorizador. Vale reforçar que diferente da NFe, onde pode ser feito uso da contingência SVC, para a NFCe deverá ser usado EPEC ou contingência off-line.

Por padrão ele busca no diretório da aplicação, se não tiver, usa o que vai embutido no .exe quando foi compilado. Veja se está configurando a versão correta. ACBrNFe1.Configuracoes.Geral.VersaoDF := ve400; ACBrNFe1.Configuracoes.Geral.VersaoQRCode := veqr200;

Perfeito @Juliomar Marchetti resolvido. Muito obrigado! Obrigado @Alexandre de Paula pela ajuda.

Boa tarde @João Antônio, Já esta no SVN.

Esse método vai servir apenas para o XML da NFe, não dos eventos. Criada a TK-7517 para avaliar a possibilidade de implementação do método ObterEventoXML Assim que tivermos uma definição informamos aqui.

@Juliomar Marchetti Obrigado pela resposta, É verdade! A gente quer agradar o cliente mas tem certas coisas que são perda de tempo. Vou fazer um espelho aqui mas não vou fazer uma cópia de NF como a da imagem não. O uso do documento é por conta do cliente é claro, mas não quero dores de cabeça no futuro se é que me entende.

Oi Juliomar, obrigada pelo retorno! Sim, eles disponibilizaram exemplos de xml, encontrei no site deles, vou deixar aqui o link se vc puder verificar: https://iss.ajuda.betha.cloud/e-nota-cloud/ajuda/outros-conteudos/web-service, está na parte do layout da Betha sistema na versão 1.0. Coloquei aqui em anexo o arquivo deles de exemplo com mais de um item. Nele consta a informação que deve ir na tag <Discriminacao>: <Discriminacao>{[[DESCRICAO= SERVIÇO 1][ITEMSERVICO=0101][ALIQUOTA=0.03][QUANTIDADE=1][VALORUNITARIO=325.60][DEDUCOES=0.00][DESCONTOCONDICIONADO=0.00][DESCONTOINCONDICIONADO=0.00]][[DESCRICAO= SERVIÇO 2][ITEMSERVICO=0102][ALIQUOTA=0.02][QUANTIDADE=1][VALORUNITARIO=296.00][DEDUCOES=0.00][DESCONTOCONDICIONADO=0.00][DESCONTOINCONDICIONADO=0.00]]}</Discriminacao> Este é um caso especifico do provedor Betha, SubVersao:1, eu entendi que devemos adicionar tbm "[DEDUCOES=0.00]" para cada item. Conforme o teste que fiz enviando, o valor de deduções constou corretamente. 3 - RecepcionarLoteRpsPopulado (mais de um serviço no RPS).xml

Boa tarde @Diego Reckziegel, Já esta no SVN.

Olá pessoal, A partir de 01/01/2026 os prestadores de serviços devem obrigatoriamente emitirem suas notas através do portal nacional da NFS-e Padrão nacional ou através de uma aplicação que consuma a API do SERPRO que visa a emissão da NFS-e segundo o Padrão Nacional. Leia o comunicado da prefeitura através do link abaixo. NOTA CARIOCA - Nota Fiscal de Serviços Eletrônica - NFS-e - Prefeitura da Cidade do Rio de Janeiro

Atualizei ontem o acbr, estou implementando essas duas properties que mandei, e depois mando aqui.

Agora entendi, muito obrigado por mandar o exemplo. Só uma duvida então, essas propriedades aqui acbrNfe.WebServices.Retorno.NFeRetorno.ProtDFe.Count ela é referente somente ao retorno assincrono, certo ? Teria algo equivalente pra eu conseguir fazer o tratamento da mesma forma? Digo isso pois preciso fazer os tratamentos para qdo as notas forem rejeitadas. Quando era permitido enviar uma nota somente pelo modo assincrono eu fazia assim o tratamento: Olhando as classes do acbr vi que dentro do enviar da classes webservices, tem essas propriedades FNFeRetornoSincrono, mas elas não estão sendo lidas, entao não é possivel usa-las, Faltou a implementação delas, ou meu acbr está desatualizado ?

não, é o no trecho do código que tem enviar no exemplo do svn

ok, vou dar uma olhada

Abre o exemplo do svn e olha com atenção. tem lá um if not Sincrono

Pessoal aproveitando aqui, vi o topico para emissao de notas sincronas mas como eu faço para obter o número do recibo, não estou conseguindo de forma alguma, ainda em produção com a forma assincrona, enviando somente uma nota, consigo obter esse numero através do campo: if pAcbrNFe.WebServices.Retorno.NFeRetorno.ProtDFe.Count > 0 then begin pDtsNota['NfeOcorrencia'] := pAcbrNFe.WebServices.Retorno.NFeRetorno.ProtDFe.Items[0].cStat; pDtsNota['NfeMotivoOcorrencia'] := pAcbrNFe.WebServices.Retorno.NFeRetorno.ProtDFe.Items[0].xMotivo; pDtsNota['NfeRecibo'] := pAcbrNFe.WebServices.Retorno.Recibo; pDtsNota['NfeProtocolo'] := pAcbrNFe.WebServices.Retorno.NFeRetorno.ProtDFe.Items[0].nProt; pDtsNota['NfeDataHoraRecibo'] := pAcbrNFe.WebServices.Retorno.NFeRetorno.ProtDFe.Items[0].dhRecbto; end else atraves desse pAcbrNFe.WebServices.Retorno.Recibo; porém agora nenhum de nenhuma das formas nao vem esse numero mais, dessa forma tbm nao vai pAcbrNFe.WebServices.Enviar.Recibo

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.

O que é o QR Code? A tag do QR Code é um elemento presente no leiaute da Nota Fiscal de Consumidor Eletrônica – NFC-e, modelo 65. Ela é composta por uma URL específica e por informações que identificam a NFC-e. Seu conteúdo é utilizado para gerar a imagem do QR Code no DANFE NFC-e. Quando escaneado pelos consumidores, o código permite a conferência das informações da nota fiscal autorizada. O que é o QR Code 3.0 ? A criação da tag do QR Code deve seguir um formato pré-estabelecido no Manual de Orientação ao Contribuinte, disponibilizado pela Sefaz. A versão 3.0 é a versão mais recente desse formato, trazendo alterações em relação à versão 2.0, utilizada anteriormente. Por que a versão 3.0 do QR Code foi criada? A principal novidade desta versão se encontra no fato de ela não fazer uso do Código de Segurança do Contribuinte (CSC), portanto, a mesma traz diversas vantagens tanto para as empresas quanto para a Sefaz no que diz respeito à organização e gerenciamento dessa informação. Vantagens para as empresas: Elimina a necessidade de manutenção de CSC. Reduz a complexidade de gerenciar CSCs por filial. Elimina controle de manter somente 2 CSCs ativos por UF. Vantagens para a Sefaz: Elimina a complexidade de mantar página da web para geração de CSC. Elimina a necessidade de manter web service de sincronismo com a Sefaz Virtual para UFs participantes desse tipo de ambiente autorizador. Permite a adoção deste controle de segurança sobre a emissão do QR-Code para todas as UF, considerando que atualmente algumas UF não mantém o controle do CSC no seu Portal de atendimento ao Contribuinte. Quais melhorias ou diferenças em relação a versão 2.0? A principal mudança entre as versões se encontra no fato de que a versão 3.0 não vai mais fazer uso do CSC, então está informação não faz mais parte da composição do QR Code. O tamanho do QR Code também foi alterado com a versão 3.0 permitindo agora tamanho mínimo de 60 caracteres e tamanho máximo de até 1000 caracteres. Em comparação com a versão 2.0, a versão 3.0 é mais simples. QR Code 2.0 x QR Code 3.0 Versão 2.0 – parâmetros do QR Code na emissão on-line: Chave de acesso da NFCe Versão do QR Code Tipo de ambiente Id CSC Hash gerado pela concatenação dos parâmetros anteriores com o CSC aplicando SHA-1 e convertido para hex Versão 3.0 – parâmetros do QR Code na emissão on-line: Chave de acesso da NFCe Versão do QR Code. Tipo de ambiente. Versão 2.0 - parâmetros do QR Code na emissão off-line: Chave de acesso da NFCe Versão do QR Code Tipo de ambiente Dia da data de emissão Valor total da NFCe Digest Value correspondente ao Hexadecimal do SHA-1 do conteúdo do XML Id CSC Hash gerado pela concatenação dos parâmetros anteriores com o CSC aplicando SHA-1 e convertido para hex Versão 3.0 – parâmetros do QR Code na emissão off-line: Chave de acesso da NFCe Versão do QR Code Tipo de Ambiente Dia da data de emissão Valor total da NFCE Tipo de Destinatário(1=CNPJ|2=CPF|3=IdEstrangeiro Identificação do Destinatário(CNPJ,CPF ou IdEstrangeiro. Assinatura formada pela concatenação dos parâmetros anteriores aplicado SHA-1 e convertidos para base 64. Como implementar no ACBr? O próprio componente ACBrNFe se encarrega de montar a string do QR Code no arquivo XML, portanto, para utilizar a versão 3.0, basta alterar a propriedade: ACBrNFe.Configuracoes.Geral.VersaoQRCode := veqr300; Caso utilize ACBrMonitorPLUS é preciso definir a configuração em tela no caminho DFe > WebServices: Caso utiliza a ACBrLibNFe, será preciso alterar o valor na configuração da biblioteca definindo o valor correspondente: Qual UF já está usando a versão 3.0? A nota técnica 2025/001, que detalha o QR Code 3.0, estabelece a data máxima de até 02/06/2025 para implementação do mesmo no ambiente de homologação. No entanto, recebemos relatos de que, mesmo após esta data, algumas UFs ainda apresentam problemas para recepcionar NFCe geradas com o QR Code nesta versão. Até o momento, recebemos a informação de que a Sefaz de Minas Gerais e do Mato Grosso do Sul estão aceitando a versão 3.0. Quando entra em vigor a versão 3.0 do QR Code? Os prazos estabelecidos pela nota técnica 2025/001 são: Implantação Teste: Até 02/06/2025 Implantação Produção: Até 01/09/2025 Como reconhecer um XML com QR Code 3.0? O QR Code gerado na versão 3.0 não requer mais o uso do CData. Outra forma é procurar pelo parâmetro correspondente a versão do QR Code que tanto na 2.0 quanto na 3.0 ocupam a mesma posição. Exemplo de QR Code gerado na versão 2.0 em emissão normal: Exemplo de QR Code gerado na versão 3.0 em emissão normal: A versão 3.0 do QR Code deve ser usada somente em contingência? Não! A versão 3.0 pode e deve ser utilizada tanto na emissão normal quanto na emissão em contingência de maneira semelhante a sua antecessora. Com a chegada da versão 3.0 é o fim da versão 2.0? Não! A versão 2.0 ainda continua valendo sem data prevista para ser descontinuada. Quem deve usar a versão 3.0? Até o momento, é recomendado que a versão 3.0 seja utilizada por produtores rurais pessoa física, eliminando a necessidade de gerenciar CSCs para pessoa física por UF (exceto para o PR). Pessoa jurídica pode escolher entre a versão 2.0 ou a versão 3.0

Olá pessoal! Informamos que o componente ACBrNFe foi compatibilizado com a versão 1.10 desta nota técnica na review 39718. Versões do ACBrMonitorPLUS e da ACBrLibNFe compiladas depois das 11/06/2025 deverão engloba as modificações.

Olá pessoal! Foi publicado no dia 09/06/2025 a versão 1.10 desta nota técnica. Alterações Informações Esta versão reforça que as informações de tributação do IS, CBS e IS serão opcionais em 2025, mas serão validadas caso informadas no ambiente de produção. Enquanto que em homologação os campos serão obrigatórios em 2025 e as regras de validação serão aplicadas conforme previsto nas datas de implementação da NT. É ressaltado que a tabela de cClassTrib pode sofrer alterações visando aperfeiçoamentos ou adequações a novidades estabelecidas. Leiaute Adiciona para o tipo de nota de débito os novos valores: 06 - Pagamento antecipado 07- Perda em estoque Define os valores para o tipo de nota de crédito, sendo eles: 01 - Multa e juros 02 - Apropriação de crédito presumido de IBS sobre o saldo devedor na ZFM. Adiciona no grupo para compras governamentais (gCompraGov) um campo para definir o tipo de operação com o ente governamental (tpOperGov) com os possíveis valores: 1 - Fornecimento 2 - Recebimento do pagamento conforme fato gerador do IBS/CBS Inclui o grupo gPagAntecipado para referenciar notas de antecipação de pagamento. Incorpora no grupo de produtos e serviços o indicador de fornecimento de bem móvel usado (indBemMovelUsado). Acrescenta novo grupo de informações da composição do valor do IBS e da CBS em compras governamentais (gTribCompraGov). Adiciona novo grupo para transferências de crédito (gTransfCred). Inclui novo grupo para informações do crédito presumido de IBS para ZFM (gCredPresIBSZFM). Regras de validação Adiciona novas regras para verificar e validar os novos campos adicionados nesta versão. Incrementa a mensagem de algumas regras de validação estabelecidas em versão anterior para trazer o número do item que ocasionou a rejeição. Atualiza observação de algumas regras de validação adicionando como devem ser os cálculos dos valores. Eventos Esclarece que os eventos serão recepcionados pela Sefaz do Virtual do Rio Grande do Sul - SVRS. Adiciona os eventos: 112120 - Importação em ALC/ZFM não convertida em isenção. 112130 - Perecimento, perda, roubo ou furto durante o transporte contratado pelo fornecedor. 112140 - Não ocorrência de fornecimento com pagamento antecipado. 211124 - Perecimento, perda, roubo ou furto durante o transporte contratado pelo adquirente. Remove o evento 211124 - Perecimento, perda, roubo ou furto. Datas Implantação de novo schema com os campos para apuração do IBS, CBS e IS com preenchimento opcional²³: Implantação Teste: De 07/07/2025 até 28/07/2025¹ Implantação Produção: 06/10/2025 Aplicação das regras de validação²³: Implantação Teste: De 07/07/2025 até 11/08/2025¹ Implantação Produção: 06/10/2025 Inicio da obrigatoriedade da informação dos novos tributos²³: Implantação Teste: 06/10/2025 Implantação Produção: 05/01/2026 Implantação dos eventos para utilização na apuração do IBS, CBS e IS: Implantação Teste: 04/08/2025 Implantação Produção: 06/10/2025 ¹ Implantação em teste pode variar de acordo com a UF. ² As regras de validação para o IBS, CBS e IS serão aplicadas somente se os valores forem preenchidos no arquivo XML. ³ A validade jurídica se dará conforme datas previstas na legislação. Detalhamento Julho/2025: Homologação: Preenchimento dos campos IBS/CBS é facultativo. Se preenchidos, as RV serão aplicadas. Produção: Campos do IBS/CBS ainda não implantados. Caso informados, ocasionará erro de schema. Outubro/2025: Homologação: Preenchimento dos campos IBS/CBS passa a ser obrigatório para as NF-e com data de emissão maior ou igual a 06/10/2025 e 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 passa a ser obrigatório para as NF-e com data de emissão maior ou igual a 06/10/2025 e as RV serão aplicadas. Produção: Preenchimento dos campos IBS/CBS passa a ser obrigatório para as NF-e com data de emissão maior ou igual a 05/01/2026 e as RV serão aplicadas. Com valor jurídico para os novos tributos a partir de 01/01/2026. E como fica o ACBr? O componente ACBrNFe já está passando por processo de adequação as modificações propostas por esta versão portanto assim que concluídas e disponibilizadas as alterações, será avisado neste tópico. Leia a versão 1.10 desta nota técnica na íntegra AQUI.

Olá Pessoal, É com grande alegria que informo a todos que o componente ACBrNFe já esta em conformidade com a NT 2025/002 versão 1.01 referente a Reforma Tributária. Já se encontra no SVN os fontes, os Schemas e o programa exemplo em Delphi que exemplifica como alimentar os novos campos. Quero deixar bem claro que o ambiente de homologação só vai estar liberado em 01/07/2025 para recepcionar os XML com os novos campos referente a Reforma Tributária. Portanto nem adianta tentar enviar que o XML vai ser rejeitado.

Olá pessoal! Foi publicada a versão 1.01 desta nota técnica. Alterações Padrões de numeração A nova versão traz mais detalhes sobre a modificação do tamanho do campo cStat. Nela é explicado que o sistema da nota fiscal está atingindo alguns limites e por isso foi necessária a ampliação dos campos do código de status de resposta (cStat) e do número do protocolo de autorização (nProt). O cStat foi aumentado para comportar até 4 posições, com essa faixa sendo utilizada para as rejeições exclusivas dos novos impostos IBS, CBS e IS. O número de protocolo de autorização é composto pelos seguintes elementos: 1 dígito para Tipo Autorizador; 2 dígitos para o código da UF; 2 dígitos para o ano; 10 dígitos para o número sequencial dos documentos autorizados para o mesmo modelo de DF-e; Como algumas UFs estão próximas de atingir o limite dos 10 dígitos sequenciais para NFC-e, o campo foi aumentado podendo ter 12 posições, fazendo com que o número do protocolo possa ter agora até 17 caracteres. Mudanças no leiaute do documento fiscal No grupo gCompraGov o elemento tpCompraGov foi renomeado para tpEnteGov. A observação dos campos CSTIS e cClassTribIS foi alterada para deixar explicito que utilize tabela própria para cada campo respectivo. O tamanho do campo vBC do grupo gIBSCBS foi alterado de 3v2-4 para 13v2 efetivamente permitindo agora um valor de até 15 dígitos com 2 casas decimais. Remove o campo vTribOp do grupo gIBSUF. Remove o grupo gTribRegular do dos grupos gIBSUF e gIBSMun e adiciona no grupo gIBSCBS. Altera o grupo que totaliza as informações dividindo em um totalizador somente para o IS e um somente para o IBSCBS. Regras de Validação Adiciona regras de validação para: Validar o IBS/CBS não informado. Validar IBS/CBS Monofásico preenchido. Validar se os valores das alíquotas do IBS/CBS e IS estão corretos. Impedir o uso do crédito presumido para NFC-e. Validar os totais do IBS/CBS monofásico. Validar se o item referenciando quando nota de débito está correto. Validar informações relacionadas ao IS. Eventos Adiciona no evento "Solicitação de Apropriação de crédito presumido" grupo para as informalões do gCBS. Deixa explícito que o evento "Perecimento, perda, roubo ou furto" é relacionado as mercadorias em estoque e não relacionadas ao trânsito. Datas Aplicação das regras de Validação. Implantação Teste: 01/07/2025 Implantação Produção: 01/2026 E como fica o ACBr? As soluções do ACBr, sejam componentes nativos, ACBrMonitorPLUS e ACBrLib estão sendo revistos e serão adequados as alterações propostas em tempo hábil para que possam realizar seus testes em homologação. Leia a versão 1.01 desta nota técnica na íntegra AQUI.

Olá pessoal! Em uma demonstração do movimento para a adoção do Padrão Nacional como padrão único para NFS-e. Temos um Projeto de Emenda Constitucional ao Projeto de Lei Complementar Nº68/2024 que institui os novos grupos de impostos do CBS e do IBS criados para o Projeto da Reforma Tributária. Está Emenda propõe adicionar os §§ 8º e 9º ao art. 61 do PLP68/2024. Destaca-se o inciso 8º: E também a justificativa da emenda: O Projeto de Emenda Constitucional pode ser lido na íntegra AQUI.

Olá a todos, Procurei no fórum e não encontrei uma solução para o problema, então decidi compartilhar minha contribuição. Abaixo, você encontrará a rotina que desenvolvi para identificar se um certificado está instalado no Windows. Espero que seja útil para quem precisa! function IsCertificateInstalled(const SerialNumber: string): Boolean; var i: Integer; CertificateFound: Boolean; begin Result := False; CertificateFound := False; try // Tenta carregar os certificados disponíveis ACBrNFSeX1.SSL.LerCertificadosStore; // Itera sobre a lista de certificados carregados for i := 0 to ACBrNFSeX1.SSL.ListaCertificados.Count - 1 do begin // Verifica se o número de série do certificado atual é igual ao procurado if ACBrNFSeX1.SSL.ListaCertificados[i].NumeroSerie = SerialNumber then begin CertificateFound := True; Break; // Certificado encontrado, interrompe a busca end; end; // Define o resultado final Result := CertificateFound; except on E: Exception do begin // Log de erro ou tratamento específico pode ser adicionado aqui // Por exemplo: LogError('Erro ao verificar certificados: ' + E.Message); Result := False; // Em caso de erro, o certificado não foi encontrado end; end; end; como chamar: CertifInstalado := IsCertificateInstalled('NUMERO DO CERTIFICADO'); if CertifInstalado then ShowMessage ('Certificado encontrado!') else ShowMessage ('Certificado não encontrado.'); espero que seja util.

Edição do Papo PRO relacionada ao tema: