Painel de líderes

Coordenação Técnica do ENCAT 16/06/2025 Consulta Tabelas CST, cClass e Credito Presumido para Reforma Tributária As notas técnicas que preveem a criação da estrutura de dados para alimentar a tributação relativa à Reforma Tributária do Consumo estão publicadas no portal e já existem prazos para a implantação desta versão no ambiente de homologação até do dia 28 de julho de 2025 para NFe, NFCe, BPe, CTe, NF3e e NFCom. Todas as Notas Técnicas apresentam regras de validação que fazem referências as tabelas de CST, Classificação Tributária e Crédito Presumido e seus indicadores (flags) que obrigam ou vedam o preenchimento dos diversos grupos de informações no XML do Documento Fiscal. Visando faciliar o entendimento da aplicação prática destas regras de validação, e sobretudo, trazer dados mais concretos de que forma os ambientes de autorização dos documentos fiscais trabalharão as validações, estamos publicando na forma de consulta deste portal o acesso visual a estas tabelas. Tabelas de CST e cClass: https://dfe-portal.svrs.rs.gov.br/DFE/TabelaClassificacaoTributaria Tabela de Crédito Presumido: https://dfe-portal.svrs.rs.gov.br/DFE/TabelaCreditoPresumido IMPORTANTE: O trabalho de levantamento de situações, aderência à legislação e prospecção de regras de validação, assim como a própria composição destas tabelas é um trabalho em constante revisão e aprimoramento, o que pode resultar em modificações nestas informações. Uma vantagem importante é que a estas tabelas estão acessando o motor de validação em banco de dados, o mesmo que o sistema de autorização da SVRS estará utilizando. Qualquer alteração nas tabelas refletirá imediatamente nas consultas do portal e na validação das regras dos documentos fiscais eletrônicos.

Olá Pessoal, Se encontra disponível desde 21/05/2025 a unit ACBrDFe.Conversao. Essa unit contem os tipos, enumerados e as funções de conversão utilizados pela Reforma Tributária. Sendo assim na unit da sua aplicação que se utiliza dos enumerados e das funções se faz necessário declarar a unit ACBrDFe.Conversao no uses.

Olá pessoal! Como sabem, os fontes do ACBr estão passando por um processo de migração, onde as units da pcn estão sendo substituídas pelas units baseadas nas classes ACBrXMLDocument que fazem uso da LibXML2 O tópico intitulado "ATENÇÃO: ACBr está adotando as classes baseadas em ACBrXMLDocument como padrão!" traz uma explicação mais detalhada, vinculando inclusive uma edição do Papo PRO ACBr que foi realizada tratando sobre a migração. Mas resumindo em poucas palavras, as novas classes trazem um ganho de performance considerável na leitura de arquivos XML que possuem um conteúdo muito extenso, o que de acordo com o leiaute de alguns DFes é uma possibilidade. Um exemplo bem simples é a NFe\NFCe que permite até 990 itens. Este processo está sendo feito por etapas: A primeira etapa foi a mudança das classes de escrita e leitura do arquivo XML, esta etapa foi concluída. A segunda etapa é a troca de algumas units da pcn, por units próprias do ACBr, esta etapa também foi concluída. Estamos entrando agora na próxima etapa que é a mudança dos tipos. Esta etapa envolve a mudança dos tipos TpcnXXX para os tipos TACBrXXXX O processo foi iniciado no MDFe com a alteração do TpcnTipoAmbiente presente na unit pcnConversao para TACBrTipoAmbiente presente na ACBrXmlBase. Acompanhe este tópico para ficar para se manter informado sobre esta mudança. Componentes de Documentos Fiscais Eletrônicos que serão afetados: ACBrBPe ACBrMDFe (Em processo de alteração) ACBrNFe ACBrCTe ACBrDCe ACBrGNRe ACBrGTIN ACBrNF3e ACBrNFCom

Olá pessoal, tivemos uma reunião com uma equipe de Boleto do Itau e vamos esclarecer alguns pontos: Itau existe 2 produtos distintos: “Boletos” – Boleto com linha digitável e código barras; “Bolecode” – Boleto com QrCODE, linha digitável e código barras (hibrido); Todos “Boletos” quando liquidados (linha digitável, código barras) , são listados na API de Consulta Liquidados com status de Liquidados; Todos “Bolecodes” quando liquidados através do qrcode, eles são *Cancelados e são listados na API de Consulta Baixados com status “BL” (Bolecode Liquidado). * (Bolecode Baixado) Isso para evitar que o mesmo boleto seja pago por outro meio. Nas consultas de LIQUIDADOS da solução ACBrBoleto, necessário realizar 02 (duas) consultas, mudando apenas a propriedade "IndicadorPIX": - Consulta Boletos Liquidados via Linha Digitável ou Código de Barras (independente se bolecode ou boleto comum): IndicadorSituacaoBoleto = isbBaixado e IndicadorPix = False - Consulta Boletos Liquidados via QrCode: IndicadorSituacaoBoleto = isbBaixado e IndicadorPIX = True Atenção, informação importante para quem usa Bolecode (Boleto Hibrido) API/CNAB Quando boleto é liquidado através do QrCODE até a presente data não devolve informações sobre pagamento, juros, multa, desconto. (não foi possível agrupar a consulta devida a paginação de repostas de cada endpoint)

Olá Pessoal Os componentes ACBrBPe, ACBrCTe, ACBrDCe, ACBrMDFe, ACBrNF3e, ACBrNFCom e ACBrNFe passam a ter a seguinte assinatura no referido método: procedure EnviarEmail(const sPara, sAssunto: String; sMensagem: TStrings = nil; EnviaPDF: Boolean = True; sCC: TStrings = nil; Anexos: TStrings = nil; sReplyTo: TStrings = nil; ManterPDFSalvo: Boolean = True; sBCC: Tstrings = nil); Os novos parâmetros: ManterPDFSalvo: Se não informado assume o valor padrão True, neste caso o PDF do Documento Auxiliar anexado no e-mail vai ser salvo no disco. Caso você não deseja que o PDF seja salvo em disco, deve-se informar o valor False para esse parâmetro. sBCC: permite informar o endereço de e-mail para ser enviado com cópia oculta. O componente ACBrNFSeX já tem o parâmetro ManterPDFSalvo a um bom tempo, agora ele passa a ter o parâmetro sBCC, portanto a assinatura do método EnviarEmail passa ser padrão para todos os DF-e relacionados nessa postagem. A implementação dos novos parâmetros já se encontra no SVN.

Olá pessoal, Gostaria de informar que o PIX Automático já está disponível nos fontes do componente ACBrPIXCD! Com isso, as software houses que utilizam o ACBrPIXCD poderão implementar as jornadas do PIX Automático diretamente em suas aplicações, aproveitando os novos endpoints e recursos disponibilizados pelo BACEN. Sendo necessária apenas a disponibilização dessa funcionalidade na API de cada PSP. Informações Importantes Disponível APENAS para contas PJ (Empresas); É automático APENAS para o PAGADOR. Ou seja, o recebedor deverá gerar a cobrança(/cobr) à cada recorrência; Periodicidades disponíveis: Semanal, Mensal, Trimestral, Semestral e Anual. O BACEN definiu 5 jornadas diferentes, da seguinte forma: Dessas 5 jornadas, será possível utilizar o componente ACBrPIXCD nas 4 primeiras. Descritivo das Jornadas: 1ª Jornada - Ativação da recorrência através de notificação push Criar a recorrência: // Popular objeto ACBrPixCD1.PSP.epRec.RecorrenciaSolicitada ACBrPixCD1.PSP.epRec.CriarRecorrencia Disparar a solicitação da recorrência (notificação push): // Popular objeto ACBrPixCD1.PSP.epSolicRec.SolicitacaoSolicitada ACBrPixCD1.PSP.epSolicRec.CriarSolicitacaoConfirmacao 2ª Jornada - Ativação após pagamento de QR Code gerado na criação da Recorrência Criar o location: ACBrPixCD1.PSP.epLocRec.CriarLocation Criar a recorrência informando o location: // Popular objeto ACBrPixCD1.PSP.epRec.RecorrenciaSolicitada ACBrPixCD1.PSP.epRec.RecorrenciaSolicitada.loc := ID_Location; // IMPORTANTE ACBrPixCD1.PSP.epRec.CriarRecorrencia Consultar a recorrência para obter o “copia e cola”: ACBrPixCD1.PSP.epRec.ConsultarRecorrencia(IDRecorrencia); wQRCode_Gerado := ACBrPixCD1.PSP.epRec.RecorrenciaCompleta.dadosQR.pixCopiaECola; // CopiaECola gerado para pagamento e ativação da recorrência Observação: O QR Code gerado será válido enquanto a recorrência estiver ativa. 3ª Jornada – Ativação após pagamento de cobrança imediata (/cob) Criar a cobrança imediata: // Popular o objeto ACBrPixCD1.PSP.epCob.CobSolicitada ACBrPixCD1.PSP.epCob.CriarCobrancaImediata Criar a recorrência informando o txid da cobrança no objeto ativação: // Popular objeto ACBrPixCD1.PSP.epRec.RecorrenciaSolicitada ACBrPixCD1.PSP.epRec.RecorrenciaSolicitada.ativacao.dadosJornada.txid := txid_Cob; // IMPORTANTE ACBrPixCD1.PSP.epRec.CriarRecorrencia; Consultar a recorrência usando o idRec: ACBrPixCD1.PSP.epRec.ConsultarRecorrencia(IDRec); 4ª Jornada – Ativação após pagamento de cobrança com vencimento (/cobv) Criar a cobrança com vencimento: // Popular objeto ACBrPixCD1.PSP.epCobV.CobVSolicitada ACBrPixCD1.PSP.epCobV.CriarCobranca(txID); Criar a recorrência informando apenas o location (sem txid): // Popular objeto ACBrPixCD1.PSP.epRec.RecorrenciaSolicitada ACBrPixCD1.PSP.epRec.RecorrenciaSolicitada.loc := Loc_CobV; // IMPORTANTE ACBrPixCD1.PSP.epRec.CriarRecorrencia; Consultar a recorrência com idRec: ACBrPixCD1.PSP.epRec.ConsultarRecorrencia(IDRec); Como usar? Para utilizar as jornadas acima, basta atualizar os fontes do ACBr e consultar os novos métodos e propriedades disponíveis no componente ACBrPIXCD. As aplicações de demonstração do componente também já estão atualizadas com as novas funcionalidades. Qualquer dúvida ou sugestão, só comentar por aqui ou acessar nosso SERVIDOR NO DISCORD. Bons códigos a todos!

Pessoal, estou criando esse tópico para alertar sobre esse assunto. Parece que tem gente que ainda não sabe sobre essa situação e o tempo já vai acabando. Veja a notícia abaixo que é do ano passado: Se ainda não fez isso, comece logo a implementar a NFC-e. Lembre-se que ano que vem já entra também a Reforma Tributária. Os usuários ACBr PRO podem contar com a ajuda de nossos cursos como a Masterclass sobre o SAT, o curso Dominando NFC-e e também o curso NFC-e Offline.

Olá pessoal! A versão 3.0 do QrCode da NFCe foi introduzida na Nota Técnica 2025/001 (leia mais sobre ela AQUI), onde a data de implementação no ambiente de homologação é 02/06/2025. No entanto, mesmo tendo passado está data, temos recebido alguns relatos de membros da comunidade que receberam erro de falha no schema ao tentar gerar NFCe com o QrCode na versão 3.0 para estados como São Paulo ou Goias. Para o estado de Goias, o membro de nossa comunidade @Silvair L Soares compartilhou a seguinte informação de que a implementação está programada para 13/06/2025: Caso esteja enfrentando problemas junto a Sefaz de São Paulo, entre em contato com a mesma para questionar se também não houve atraso na implementação.

Olá comunidade do Projeto ACBr ! Agora é possível utilizar as classes de alto nível referente a reforma tributária. Realizamos uma atualização das classes, onde o mesmo já esta disponíveis em nosso SVN - Commit (39575, 39576). Commit At revision: 39575: -> Foram adicionadas novas classes referente a reforma tributária. Commit At revision: 39576: -> Atualização do programa exemplo, incluindo exemplo de preenchimento usando as novas classes da reforma tributária. Para utilizar as novas classes, é necessário atualizar ACBrLibNFe.aar para a versão disponível a partir de 10/06/2025, além de atualizar os fontes disponíveis no SVN. É necessário também atualizar a pasta Schemas da NFe pois a ultima versão disponível já contem os .xsds da a reforma tributária. Detalhe, a liberação do ambiente de homologação esta previsto para o dia 01/07/2025. O Projeto ACBr esta centralizando todas as informações no tópico abaixo: Aguardamos feedbacks. Até a próxima.

Olá Pessoal, A cidade de Araraquara/SP trocou de provedor, deixou de usar o Ginfes e passou a usar o Giap. O provedor Ginfes se utiliza da versão 1 do layout da ABRASF e o Giap possui um layout próprio. O provedor Giap já se encontra implementado a um bom tempo e é usado por exemplo pela cidade de São Carlos/SP. A principio foi feita a alteração no arquivo ACBrNFSeXServicos.ini visando a troca do provedor e as URL de homologação e produção. Mas isso não foi suficiente, pois o provedor Giap vai utilizar a versão 1 do layout da ABRASF para Araraquara/SP. Sendo assim foi necessário realizar alterações no código do componente, mais precisamente nas units referente ao provedor Giap para poder atender essa demanda. Quais foram as alterações que devemos prestar mais atenção? Quem costuma copiar o arquivo ACBrNFSeXServicos.ini para a maquina do emitente da nota, vai ter que atualizar. Temos uma nova pasta de esquemas: A pasta 1.00 contem os schemas do provedor Giap para o seu layout próprio. A pasta 1.01 contem os schemas para o provedor Giap validar o XML do RPS segundo a versão 1 do layout da ABRASF. Uma nova versão do ACBrLibNFSe e do ACBrMonitor Plus já esta sendo providenciada ainda para hoje 06/06/2025. Caso alguém tenha algum problema com os serviços disponibilizados pelo provedor favor criar um tópico aqui no fórum e relatar o problema. Por fim quero informa-los que o provedor Giap disponibiliza os serviços: Recepcionar um lote com até 50 RPS, Consultar NFSe por RPS e Cancelar NFS-e. Somente esses 3 serviços estão disponíveis no webservice do provedor.

Olá Pessoal, Vamos atualizar esse tópico. Já foi finalizado os ajustes nos componentes: ACBrBPe, ACBrCTe, ACBrNF3e, ACBrNFCom e ACBrNFe. Os fontes alterados bem como os Schemas e os programas exemplos dos 5 componentes mencionados acima já estão no SVN. Quero lembrar que ainda não é possível enviar o XML contendo os novos campos para a SEFAZ, uma vez que esta ainda não liberou o ambiente de homologação que esta previsto para 01/07/2025. Estamos trabalhando já no componente ACBrNFSeX, mas como dito anteriormente até a postagem desse tópico não foi publicado os Schemas. No que se refere a NFSe temos duas questões: 1. A NT publicada com as mudanças no layout referente a Reforma Tributária é no layout da NFS-e Padrão Nacional (não confundir com ABRASF). 2. Hoje o componente ACBrNFSeX atende 1848 cidades, algumas delas contrataram provedores que usam a versão 1 do layout da ABRASF, outras contrataram provedores que usam a versão 2 do layout da ABRASF e outras contrataram provedores que tem layout próprio. Não sabemos qual a atitude dos provedores que utilizam a versão 1 ou 2 do layout da ABRASF bem como os que tem o seu próprio layout no que se refere a Reforma Tributária. Eles vão alterar o layout que usam para adequar a Reforma ou vão abandonar o layout em uso e vão passar a usar o layout da NFS-e Padrão Nacional? Não temos a resposta para essa pergunta. Até a próxima pessoal.

Olá pessoal! A partir de 30/06/2025 o web service do e-Social vai implementar em seus servidores de recepção e consulta de lotes de eventos um novo certificado visando adotar um padrão de segurança mais robusto baseado algoritmo SHA-384 combinado com RSA. Aplicações que não suportem essa configuração poderão apresentar falhas de conexão. O ACBr está pronto para esta mudança? A equipe de consultores está analisando as informações disponibilizadas e avaliando os fontes para confirmar se existe necessidade de alguma alteração nos fontes do ACBr. Assim que houver novas informações este tópico será atualizado Este tópico foi baseado em notícia publicada originalmente AQUI.

Olá pessoal! Crio este tópico para alertar aqueles que não sabem e relembrar aqueles que possam ter esquecido, de que o envio de lote de NFe contendo somente um documento no lote já não pode ser feito de maneira assíncrona no ambiente de homologação desde 02/06/2025. Com previsão de ser abolido no ambiente de produção em 01/09/2025! O fim dessa forma de envio para esta situação específica foi decretado na Nota Técnica 2025/001: Aqueles que tentarem realizar o envio de um lote contendo somente 1 NFe de maneira assíncrona, depois dessas datas vão receber uma rejeição: Veja o tópico abaixo para uma explicação mais detalhada sobre a rejeição: Veja este tópico para uma orientação sobre como realizar o envio de forma síncrona e como ler o retorno, que é devolvido em outra classe quando envio síncrono, usando o componente:

Olá pessoal! Foi publicado no dia 11/06/2025 a Nota Técnica 02/2025 para o EFD-Reinf. A mesma traz alterações no evento R-1000 adicionando um novo campo opcional indPertIRRF para servir como indicador de pertencimento ao IRRF. O novo campo é de preenchimento exclusivo para o contribuinte cuja natureza jurídica seja igual a [126-0, 127-9, 129-5, 130-9]. E como fica o ACBr? Foi criada a #TK-7221 para adequação do componente adicionando o novo campo. Qualquer novidade será divulgada aqui neste tópico. Leia a nota técnica na íntegra AQUI ou em nosso Tools

Olá pessoal, Foram enviados, na Rev-39761, os ajustes necessários para atender à NT 02/2025. Foram atualizados também os schemas: http://sped.rfb.gov.br/arquivo/download/7813

Olá pessoal! Foi publicado no dia 11/06/2025 o Informe Técnico 2025.003 para divulgar o novo endereço de consulta da NFC-e para geração do QrCode que é impresso no DANFCe. Esta URL é utilizada para montar a string que é informada na tag qrCode do XML da NFC-e, devolvendo rejeição 395 - Endereço do site da UF da Consulta via QR-Code diverge do previsto caso esteja incorreta. UF URL Vigência GO Produção http://nfe.sefaz.go.gov.br/nfeweb/sites/nfce/danfeNFCe Até 30/08/2025 https://nfeweb.sefaz.go.gov.br/nfeweb/sites/nfce/danfeNFCe A partir de 16/06/2025 GO Homologação http://homolog.sefaz.go.gov.br/nfeweb/sites/nfce/danfeNFCe Até 30/06/2025 https://nfewebhomolog.sefaz.go.gov.br/nfeweb/sites/nfce/danfeNFCe A partir de 16/06/2025 E como fica o ACBr? Foi criada a #TK-7211 para atualização das URLs conforme cronograma definido no informe. Leia o Informe Técnico na íntegra AQUI.

Olá pessoal! Conferindo no painel Situação SVC-RS, é possível observar que a Sefaz de Goais ativou a contingência às 08h30 do dia 10/06/2025, com previsão de permanecer ativada até às 17h00 do mesmo dia. Para utilizar as soluções do ACBr em contingência durante este período siga as orientações do tópico abaixo:

Olá pessoal! Foi publicado o Correio Eletrônico Circular SEF/DIAT/Nº 10 / 2025 definindo o uso obrigatório da Nota Fiscal de Fatura de Serviços de Comunicação Eletrônica (NFCom) para o estado de Santa Catarina em 01/11/2025. Todas as empresas prestadoras de serviço de comunicação já estão credenciadas no ambiente de homologação podendo realizar seus testes. A solicitação de credenciamento voluntário no ambiente de produção (disponível desde 1º de dezembro de 2023) deverá ser feita pelo contabilista da empresa no Sistema de Administração Tributária-S@T, através da aplicação CEI – Gerenciamento de Autorização para Utilização de Processamento de Dados (AUPD), observando os artigos 2° e 7°-C, do Anexo 7 ao RICMS/SC, o ATO DIAT n° 31/2023, o ATO DIAT nº 32/2023, ATO DIAT 13/2025 e o ATO DIAT nº 44/2023. Vale lembrar que o ACBr possui o componente ACBrNFCom disponível para Delphi e Lazarus para emissão da NFCom. O exemplo do mesmo pode ser encontrado em ..\trunk2\Exemplos\ACBrDFe\ACBrNFCom

Olá pessoal! Foi compartilhado em nossa comunidade o seguinte comunicado relacionado ao município de São Jose do Rio Preto/SP: Portanto, se você estiver enfrentando algum problema para emitir NFSe para este município, é possível que seja devido a essa indisponibilidade.

Olá pessoal! Foi publicado no dia 02/06/2025, no Diário Oficial do Estado de São Paulo, a PORTARIA SRE 28, DE 30 DE MAIO DE 2025. Esta portaria estabelece o uso da Declaração de Conteúdo Eletrônica (DC-e), modelo 99 no estado, por pessoa física ou jurídica, não contribuinte de ICMS, para acobertar operações de transporte em hipótese que não é exigido documento fiscal, a partir de 01/10/2025. Vale mencionar que o ACBr já dispõe de componente para emissão da mesma, conforme tópico abaixo: E que também foi feita edição do Papo PRO ACBr tratando sobre o tema:

Olá pessoal! Se você não sabe do que se trata as classes baseadas em ACBrXMLDocument, o tópico abaixo tem mais detalhes: Mas em um resumo: São classes criadas de forma a utilizar as vantagens da LibXML para leitura e escrita dos arquivos XML. Elas são mais rápidas do que as classes baseadas na PCN. Elas foram criadas com o objetivo de substituir a PCN. Como podem ver no tópico indicado acima, desde antes de dezembro de 2024 essas novas classes já estão disponíveis e podem ser utilizadas pela comunidade através de opção no instalador. Agora, 6 meses depois, decidimos que a essas classes serão adotadas como padrão pelo ACBr, ou seja, ao invés de a opção vir desmarcada no instalador, ela vira selecionada por default. Por que estamos realizando esta mudança? Como é mencionado no tópico, consideramos que elas trazem vantagens em comparação com as classes da PCN. Depois de um período de 6 meses, com a comunidade já podendo utilizar elas e sem relatos recentes de problemas, consideramos que elas já estão maduras o suficiente para serem adotadas como padrão. Com o advento da Reforma Tributária, fica inviável manter a manutenção tanto nas classes PCN quanto nas classes ACBrXMLDocument, portanto, os novos campos relacionados a reforma foram adicionadas somente nas novas classes. Quais impactos essa mudança pode gerar? Como mencionado, essas novas classes precisam da LibXML para o correto funcionamento, portanto as dlls devem ser devidamente distribuídas junto ao executável ou estarem presentes no Path. Se você utiliza as units em sua aplicação, é provável que precise realizar a troca para evitar problemas de escopo. Por exemplo, substituir na seção uses da sua aplicação, onde tiver pcnNFeW por ACBrNFe.XmlWriter e onde tiver pcnNFeR por ACBrNFe.XmlReader.

Olá pessoal. Este post é apenas informativo. Acabei de testar o qrcode versão 3. Em SP, no ambiente de homologação, foi autorizado.

Olá pessoal! Ao acessar o Portal SPEDMG > NF3e, o seguinte aviso é exibido informando sobre a manutenção e indisponibilidade do ambiente de homologação da NF3e na Sefaz de Minas Gerais entre os dias 02 e 03 de Julho.

No caso você tem um site com algum plugin de ecommerce como o Wocommerce e tem o PagSeguro como gateway, nisto você quer fazer uma integração, mas qual o objetivo desta integração? Você quer pegar os pedidos feitos no site com os valores recebidos? Quer lançar pedidos a partir de um outro sistema? Poderia ser mais especifico em relação ao seu objetivo e as ferramentas utilizadas? Creio que o ACBr não teria uma solução para o que você quer, mas talvez alguém aqui tenha.

Bom dia, Queríamos informar que a TK-7191 está agora em testes de avaliação. Estamos trabalhando para identificar o problema e encontrar a solução o mais breve possível. Assim que tivermos novidades atualizaremos este tópico.

Olá pessoal! Foram publicados dois novos informe técnicos sobre as tabelas relacionadas a reforma tributária: IT 2025.001 v1.10: Informa sobre a atualização das Tabelas de CST e cClassTrib além da divulgação da Tabela de Crédito Presumido do IBS\CBS. Essas tabelas possuem informações importantes que deve ser utilizadas no preenchimento dos novos campos adicionados no leiaute da NFe\NFCe visando adequar o mesmo a Reforma Tributária. IT 2025.004 v1.00: Informa sobre a divulgação da Tabela de Código de Índice de Biodiesel do IBS e do CBS. Esta tabela visa atender ao artigo 179 da Lei Complementar nº 214/2025 que implementa novas regras de validação para garantir o correto preenchimento da informação e conta com os campos cProdANP, Descrição, pBio, Início de Vigência e Fim de Vigência. Ambos os informes técnicos mencionados podem ser encontrados no Portal da NFe e também em nossa biblioteca Tools. As tabelas mencionadas podem ser encontradas no Portal da NFe ou como mencionadas nesta notícia consultadas com uma exibição visual mais didática diretamente na Sefaz do Rio Grande do Sul. Um agradecimento ao membro de nossa comunidade @Felipe Mariano por compartilhar a divulgação dos informes técnicos no canal #sefaz em nossa comunidade do Discord.

Olá pessoal! Informamos aqueles que utilizam ACBrMonitorPLUS ou ACBrLibNFe, que foi disponibilizado ajuste visando sanar o erro: Portanto, se você estiver utilizando uma versão dessas soluções, de antes das 14h02 do dia 23/06/2025, atualize! A versão mais recente da ACBrLibNFe pode ser encontrada AQUI. As versões mais recentes do ACBrMonitorPLUS podem ser encontradas AQUI.

Correção no SVN.

Bom dia @Desenvolvimento.microline, Luis Fernando as URLs que estavam no arquivo ACBrNFSeXServicos.ini estavam desatualizadas. As que você informou são as mais atuais, muito obrigado pela colaboração. Já esta no SVN.

Olá pessoal! Foi publicado no dia 18/06/2025 a versão 2.13 do Manual de Integração do Contribuinte GNRe. Esta versão altera os campos de CNPJ para adequação ao CNPJ alfanumérico previsto para Julho de 2026. Como a propriedade já é do tipo string no componente, modificações não serão necessárias. A versão mais recente do manual pode ser encontrada direto no Portal do GNRe e também em nossa biblioteca Tools

senão me falha a memoria. acho que uma vez consultei um fiscal do sefaz. e mesmo disse que se precisa imprimir algo diferente da DANFCe. deve se gerar um comprovante posterior e imprimir, mas que o layout da DANFCe é que segue o manual, portanto não deve e não pode ser feito do jeito que desejar e só pode existir dados que tem no XML do documento

Bom dia, resolvido! @Renato Rubinho e @Alexandre de Paula Obrigado.

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! Foi publicada no dia 06/06/2025 a versão 1.05 desta nota técnica. Esta nova versão traz a adição de um novo grupo de compras governamentais e também ajustes em regras de validação. Alterações Foi adicionado um novo grupo para compras governamentais no IBSCBS chamado gTribCompraGov. O mesmo é composto pelos seguintes campos: pAliqIBSUF: Alíquota IBS da UF utilizada vTribBSUF: Valor do tributo do IBS da UF que seria devido sem aplicação do Art. 473 da LC 214/2025; pAliqIBSMun: Alíquota IBS do município utilizado. vTribIBSMun: Valor do tributo do IBS do município que seria devido sem aplicação do Art. 473 da LC 214/2025; pAliqCBS: Alíquota do CBS utilizada. vTribCBS: Valor da CBS Adiciona a seguinte exceção as regras de validação que validam a presença do grupo IBSCBS e seu respectivo CST: Se o CRT informado pelo emitente for 1 Simples Nacional ou 4 -MEI, o grupo gIBSCBS NÃO será exigido Adiciona regras de validação que verificam a presença ou a ausência do novo grupo gTribCompraGov e também a somatória do IBS e do CBS presentes no mesmo. Datas Implantação Homologação: Até 28/07/2025 Implantação Produção: 06/10/2025 E como fica o ACBr? Como foi adicionado um novo grupo no leiaute, modificações no componente respectivo serão necessárias. Criada a #TK-7190 para adequação do componente. Leia a versão 1.05 desta nota técnica na íntegra AQUI.

Olá pessoal! Foi publicada no dia 06/06/2025 a versão 1.05 desta nota técnica. Esta nova versão traz a adição de um novo grupo de compras governamentais e também ajustes em regras de validação. Alterações Foi adicionado um novo grupo para compras governamentais no IBSCBS chamado gTribCompraGov. O mesmo é composto pelos seguintes campos: pAliqIBSUF: Alíquota IBS da UF utilizada vTribBSUF: Valor do tributo do IBS da UF que seria devido sem aplicação do Art. 473 da LC 214/2025; pAliqIBSMun: Alíquota IBS do município utilizado. vTribIBSMun: Valor do tributo do IBS do município que seria devido sem aplicação do Art. 473 da LC 214/2025; pAliqCBS: Alíquota do CBS utilizada. vTribCBS: Valor da CBS Adiciona observação de que a mensagem de rejeição relacionada ao IBSCBS deverá devolver o item que ocasionou a rejeição. Adiciona a seguinte exceção as regras de validação que validam a presença do grupo IBSCBS e seu respectivo CST: Se o CRT informado pelo emitente for 1 Simples Nacional ou 4 -MEI, o grupo gIBSCBS NÃO será exigido Adiciona regras de validação que verificam a presença ou a ausência do novo grupo gTribCompraGov e também a somatória do IBS e do CBS presentes no mesmo. Adiciona a seguinte exceção na regra que devolve cStat 223 e a mensagem "NFCom Local informada deve ser da mesma UF da NFCom": Datas Implantação Homologação: Até 28/07/2025 Implantação Produção: 06/10/2025 E como fica o ACBr? Como foi adicionado um novo grupo no leiaute, modificações no componente respectivo serão necessárias. Criada a #TK-7189 para adequação do componente. Leia a versão 1.05 desta nota técnica na íntegra AQUI.

Olá pessoal! Foi publicada no dia 06/06/2025 a versão 1.05 desta nota técnica. Esta nova versão traz a adição de um novo grupo de compras governamentais e também ajustes em regras de validação. Alterações Foi adicionado um novo grupo para compras governamentais no IBSCBS chamado gTribCompraGov. O mesmo é composto pelos seguintes campos: pAliqIBSUF: Alíquota IBS da UF utilizada vTribBSUF: Valor do tributo do IBS da UF que seria devido sem aplicação do Art. 473 da LC 214/2025; pAliqIBSMun: Alíquota IBS do município utilizado. vTribIBSMun: Valor do tributo do IBS do município que seria devido sem aplicação do Art. 473 da LC 214/2025; pAliqCBS: Alíquota do CBS utilizada. vTribCBS: Valor da CBS Adiciona observação de que a mensagem de rejeição relacionada ao IBSCBS deverá devolver o item que ocasionou a rejeição. Adiciona a seguinte exceção as regras de validação que validam a presença do grupo IBSCBS e seu respectivo CST: Adiciona regras de validação que verificam a presença ou a ausência do novo grupo gTribCompraGov e também a somatória do IBS e do CBS presentes no mesmo. Datas Implantação Homologação: Até 28/07/2025 Implantação Produção: 06/10/2025 E como fica o ACBr? Como foi adicionado um novo grupo no leiaute, modificações no componente respectivo serão necessárias. Criada a #TK-7188 para adequação do componente. Leia a versão 1.05 desta nota técnica na íntegra AQUI.

Acabei de implementar os métodos Comuns de uso do ACBrLib.. que são os métodos de configuração, versão, nome e etc. Assim que eu finalizar implementação dos métodos de uso do Componente ACBrNFCom, devo anexar uma versão aqui para que você possa fazer um teste inicial, combinado ? Qual versão ACBrLib você utiliza ? x86, x64 ? stdcall, cdecl, Single Thread ou MultiThread ?

O codigo de tributação é o próprio codigo CNAE. Somente numeros

Eu já dei inicio a implementação Assim que eu finalizar as implementações e testes das classes alto nível da NFe para Android referente a reforma tributária, vou dar continuidade na implementação desta ACBrLib.

O @Alexandre de Paula pode nos passar um retorno de como está o andamento da tarefa...

Provavelmente os fontes do seu Acbr estão desatualizados. Estou conseguindo emitir notas normalmente pra essa cidade, sem nenhum problema desse tipo.

Analisando a documentação, realmente a url de homologação deve ser alterada. Também comitei a inclusão dos certificado/chave no body da autenticação. Disponível no SVN, rev: 39531 -- ACBrPIXPSPAilos -- [*] Alteração da URL de homologação. [*] Ajuste no body da autenticação para incluir o certificado e chave. por: Eduardo Frota Vicentini

É sim, Daniel. Porém tivemos um relato de um usuário no discord comentando que foi necessário apenas fazer o procedimento de envio do certificado da SW para a Ailos: Aparentemente não é necessário fazer alterações no componente.

Bom dia @DanielOliver, Na pasta: ...\Exemplos\ACBrDFe\ACBrNFe\Android temos um programa exemplo feito pelo o @Daniel Simoes para a NF-e. Acredito que com base nesse exemplo você consiga fazer um para o BP-e.

Olá pessoal! Esta rejeição foi introduzida pela Nota Técnica 2025/001 e sua regra de validação é como segue: Como descrito na regra e na rejeição, está mensagem é devolvida quando é feito o envio de forma assíncrona de um lote de NF-e contendo apenas uma nota em seu conteúdo. Portanto, para evitar esta rejeição, sua aplicação precisa fazer o envio de forma síncrona caso haja apenas uma NF-e no lote ou fazer o envio de forma assíncrona com um lote contendo no mínimo duas notas. Veja mais sobre os envios síncrono e assíncrono no tópico abaixo:

Você pode achar as DLLs da LibXML2, no SVN do ACBr... https://svn.code.sf.net/p/acbr/code/trunk2/DLLs/LibXml2/ Lembrando... use a versão x86, se você compila seu .EXE em 32 bits... (independente do Windows ser 64 bits) Copie todas as DLLs do link acima, na mesma pasta do seu .EXE O quanto a implementação usando a LibXML2 é mais rápida que as antigas Units do PCN ? Confira nesse vídeo:

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 publicado ontem (28/03/2025) Notas Técnicas especificas para cada modelo de Documento Fiscal Eletrônico referente a Reforma Tributária. Notas Técnicas publicadas para o BP-e, CT-e, NF3-e e NF-e/NFC-e, esta faltando a publicação da NT referente a NFCom. Em uma leitura rápida não ocorreu grandes alterações. Somente a NF-e/NFC-e que trazia um grupo referente a Compras Governamentais, este grupo agora esta presente nos demais DF-e. Outro ponto a se destacar é quanto aos prazos de liberação dos ambientes de homologação e produção. Ambiente de homologação que antes estava previsto para 01/09/2025 passou para 01/07/2025. E o ambiente de produção estava previsto para 31/10/225 passou para 01/10/2025. Com essa alteração de datas os desenvolvedores passaram a ter 3 meses em vez de 2 para adequar suas aplicações e fazerem os testes. No que se refere a NFS-e também foi publicado uma nova NT que traz algumas modificações no layout sendo que uma delas é a inclusão do grupo de Compras Governamentais. Infelizmente essa NT não traz datas de inicio do ambiente de homologação (produção restrita como eles chamam) e do ambiente de produção. A única informação que consta é que em janeiro/2026 as NFS-e devem já atender a reforma tributária, ou seja, já deve constar os novos grupos e campos. Com essas novas modificações nos layouts dos DF-e vamos ter que rever tudo o que foi feito e fazer as alterações necessárias. Pessoal, agora mais do que nunca devemos manter os fontes do ACBr atualizados e reinstalados se possível diariamente. Vamos fazer novos Papo Pro no Discord relatando as mudanças e em qual etapa estamos na adequação dos componentes. Não percam os Papo Pro eles são de extrema importância para que vocês fiquem informados.

Pessoal, A etapa 1 que visa implementar nas classes os novos grupos e campos, foi totalmente implementada em todos os componentes mencionados na postagem anterior. Vamos agora partir para a etapa 2.

Olá pessoal! Como muitos sabem, o time do ACBr está constantemente buscando trazer novas soluções e melhorias com o objetivo de facilitar e melhorar o dia a dia dos desenvolvedores. Com isso em mente, as rotinas dos componentes de DFe estão passando por um processo de migração das units do pcn para units baseadas na classe ACBrXMLDocument. Certo, mas como isso vai ajudar os desenvolvedores? Sabemos que os leiautes dos documentos fiscais podem conter uma quantidade considerável de informações, gerando assim arquivos XML de tamanho considerável. As rotinas de geração e de leitura de arquivos XML utilizando ACBrXMLDocument trazem um ganho de performance considerável em comparação ao pcn, com primeiro sendo até 60 vezes mais rápida em comparação. Ouçam esta edição do Papo PRO ACBr para mais detalhes sobre as razões para esta mudança e as vantagens da mesma: Para que você possa utilizar estas novas classes, ao instalar o ACBr, é preciso selecionar no instalador a opção em destaque no print. Convidamos aos membros da comunidade ACBr para que testem as novas classes e aguardamos um feedback. Até a próxima pessoal!