Alexandre.Paula

Boa tarde @Desenvolvimento Eagle e @arpa_sistemas, Por favor façam um teste com a unit anexa nessa mensagem. Salvem a que vocês estão usando, copiem essa, reinstale o ACBr e faça os testes. Adicionei as contribuições e ajustes alguns detalhes para manter o padrão e compatibilidade no lazarus. Aguardo validação para subir no SVN. Obrigado mais uma vez pela contribuição. ACBrIMendes.pas

tava vendo isso quando vc mandou a mensagem vou baixar a nova contribuição. Obrigado.

Veja que o Diego esclareceu acima. Usando ACBrAPI você vai conseguir emitir usando o ambiente de produção. Solicite ao seu cliente e caso queira testar é possivel emitir uma nota de baixo valor em produção e cancelar depois. Recomendamos entrar em contato com a prefeitura e com o provedor ISSNet para entender o ambiente deles e solicitar apoio e esclarecimentos.

Reforma Tributária na NF-e: ACBr aprimora a geração do grupo gPagAntecipado Quem emite NF-e sob as regras da Reforma Tributária e usa notas anteriores para abater parcelas de antecipação de pagamento já pode contar com uma geração de XML mais robusta no ACBr — evitando o envio de um grupo vazio que poderia comprometer a validação do documento. O grupo BB01 – gPagAntecipado, previsto na NT 2025/002 (versão 1.40), permite informar a(s) NF-e emitida(s) anteriormente referentes a pagamento antecipado, usada(s) para abater as parcelas correspondentes, conforme o Art. 10, §4º citado na própria norma. O ACBrNFe já conta com suporte a esse grupo desde a implementação das mudanças da Reforma Tributária no leiaute da NF-e. Uma correção recente no ACBrNFe.XmlWriter ajustou a geração para que o grupo só seja incluído no XML quando houver ao menos uma chave de referência (refNFe) cadastrada. A mudança evita a geração de um grupo gPagAntecipado vazio, o que poderia levar à rejeição do documento pela SEFAZ. Quem já utiliza o componente não precisa alterar nada na própria aplicação — basta seguir usando a mesma API para que o comportamento correto seja aplicado automaticamente. O que é o grupo gPagAntecipado Dentro das adequações trazidas pela Reforma Tributária ao leiaute da NF-e, a NT 2025/002 (versão 1.40) define o Grupo BB — Grupo de notas de antecipação de pagamento, dentro da tag Ide: ID Campo Ocorrência Tamanho Observação BB01 gPagAntecipado 0-1 — Informado para abater as parcelas de antecipação de pagamento, conforme Art. 10, §4º BB02 refNFe 1-99 44 Referência a uma NF-e (modelo 55) emitida anteriormente, referente a pagamento antecipado Ou seja: o grupo é opcional (ocorre 0 ou 1 vez), mas quando presente deve conter de 1 a 99 referências de chaves de acesso (refNFe), cada uma com 44 posições. É justamente essa regra — grupo presente exige ao menos uma referência — que motivou o ajuste no ACBr. O que foi corrigido A atualização mais recente no componente ACBrNFe ajustou a rotina responsável por montar esse trecho do XML: agora, o grupo gPagAntecipado só é criado quando a lista de referências (refNFe) contiver pelo menos um item. Antes dessa correção, o grupo podia ser gerado mesmo sem nenhuma chave informada — o que resultaria em uma tag sem o conteúdo obrigatório exigido pelo schema da NF-e, um cenário com risco real de rejeição no ambiente da SEFAZ. Esse tipo de ajuste é especialmente importante em componentes fiscais: pequenas inconsistências na geração de um grupo opcional podem gerar erros de validação difíceis de rastrear, principalmente em cenários de Reforma Tributária, onde o leiaute ainda está em consolidação. Como usar Quem já preenche os dados de identificação (Ide) da NF-e via ACBrNFe pode informar as referências de antecipação normalmente, adicionando um item à coleção para cada chave de acesso: with Ide.gPagAntecipado.refNFe.New do refDFEChave := '12345678901234567890123456789012345678901234'; with Ide.gPagAntecipado.refNFe.New do refDFEChave := '12345678901234567890123456789012345678904567'; Se nenhuma referência for adicionada à coleção refNFe, o grupo gPagAntecipado simplesmente não é gerado no XML — sem necessidade de nenhuma verificação manual por parte de quem integra o componente. Dica: esse mesmo trecho de código está disponível nos programas exemplo do ACBr (projeto ACBrNFe, arquivo Frm_ACBrNFe.pas, nas versões Delphi e Lazarus). Vale a pena consultar os exemplos sempre que for implementar um novo campo da Reforma Tributária — eles trazem casos de uso já testados e evitam retrabalho na hora de integrar o componente. Por que isso importa para quem emite NF-e Reduz o risco de rejeição do documento por inconsistência de schema em cenários de antecipação de pagamento. Mantém o componente alinhado à NT 2025/002 (versão 1.40), que segue sendo ajustada à medida que a Reforma Tributária avança. Preserva a simplicidade de uso: o desenvolvedor continua preenchendo apenas os dados que possui, sem precisar tratar manualmente o caso de lista vazia. Quem já utiliza o ACBrNFe para emissão de NF-e sob as regras da Reforma Tributária tem, portanto, mais um ponto de atenção resolvido pelo próprio componente — reforçando o papel do ecossistema ACBr como referência para adequação de sistemas fiscais em Delphi. Quer simplificar ainda mais a adequação do seu sistema às mudanças da Reforma Tributária na emissão de documentos fiscais? Conheça o ACBr PRO e conte com componentes sempre atualizados conforme as novas regras da NF-e. Fonte oficial: Nota Técnica 2025/002 (versão 1.40) da NF-e — Grupo BB (gPagAntecipado/refNFe); e changelog do componente ACBrNFe (registro de 30/06/2026) — correção em ACBrNFe.XmlWriter para geração condicional do grupo gPagAntecipado.

@xjonas117 você está usando os componentes, Lib ou ACBrAPI? Obrigado

Tarefa ACBR-8725. topico vinculado. Obrigado pela contribuição

Bom dia Alex, Obrigado pela observação e contribuição. A correção foi realizada. Apenas para informação estamos usando a função OnlyCPFCNPJAlphaNum para incluir a validação dos novos CNPJ alfanuméricos. At revision: 47168

Tarefa ACBR-9423 concluída e no SVN.

Tarefa ACBR-9423 já no SVN.

NFS-e Via: nova API permite consultar alíquotas de ISS por trecho e data A Secretaria-Executiva do Comitê Gestor da NFS-e ampliou as ferramentas de transparência do sistema NFS-e Via. Entenda o que muda para as Administrações Tributárias Municipais e onde a comunidade pode ajudar a levar essa novidade também para o ecossistema ACBr. Resumo da novidade: Foi publicada a versão 1.1 do Anexo V – Guia para Utilização das APIs, destinada às Administrações Tributárias Municipais do sistema NFS-e Via; A principal novidade é a API de consulta de alíquotas de ISS por trecho e data; Os municípios passam a acessar o histórico e a vigência das alíquotas aplicadas em trechos de concessões rodoviárias; A resposta traz percentual de participação de cada município, alíquota base, alíquota efetiva municipal e alíquota efetiva total do trecho; O objetivo declarado é aumentar a transparência e facilitar a validação do rateio do ISSQN entre os entes federados; A documentação técnica e os ambientes de teste já estão disponíveis para integração. O que mudou na NFS-e Via O NFS-e Via é a frente do sistema nacional da Nota Fiscal de Serviço eletrônica voltada às concessionárias de exploração de vias — o modelo usado para emitir a nota fiscal referente à cobrança de pedágio. Como o trecho de uma concessão costuma atravessar mais de um município, o ISS arrecadado precisa ser rateado entre eles, de acordo com a extensão da rodovia em cada território e a alíquota vigente em cada localidade. Até então, o Anexo V – Guia para Utilização das APIs descrevia apenas o método ObterDocumentos, usado pelos municípios para baixar os XMLs de NFS-e Via e de eventos de cancelamento por NSU, além da consulta de alíquotas por município. Com a versão 1.1, publicada em julho de 2026, o guia passa a contemplar também a consulta de alíquotas por trecho em uma data específica. Como funciona a nova consulta de alíquotas O novo endpoint, GetAliquotasTrecho, é acessado via GET /Aliquotas/trecho/{codigoTrecho}/dataReferencia/{dataReferencia} e retorna, para um trecho e uma data de referência informados, a lista completa de municípios envolvidos no rateio, com: extensão do trecho em cada município e o percentual correspondente; alíquota de ISS informada e a alíquota efetiva aplicada por município; a alíquota efetiva total do trecho, já consolidada. Essa informação se soma à consulta já existente por município (GetAliquotasMunicipioPorTrecho), que lista todos os trechos associados a um determinado código de município. Na prática, o município passa a poder conferir não só "quais trechos me afetam", mas também "qual era a alíquota vigente em uma data específica" — algo essencial para auditar cobranças passadas ou resolver divergências de repasse. Todas as comunicações continuam seguindo o padrão já estabelecido para o NFS-e Via: API REST síncrona, mensagens em JSON, documentos fiscais em XML 1.0/UTF-8, e autenticação mútua via certificado digital ICP-Brasil (TLS 1.0 a 1.2). Os ambientes de homologação, produção restrita e produção continuam disponíveis para testes de integração, com Swagger publicado para cada um deles. Por que isso importa para os municípios O rateio do ISS entre municípios cortados por uma mesma via é, por natureza, uma operação sensível: pequenas diferenças de alíquota ou de data de vigência mudam o valor final que cada prefeitura recebe. Ao expor essa informação via API — e não apenas em relatórios estáticos —, o Comitê Gestor da NFS-e permite que cada Administração Tributária Municipal audite o cálculo por conta própria, comparando o valor recebido com a alíquota que realmente estava vigente na data da cobrança do pedágio. Isso é particularmente relevante em disputas ou revisões de rateio: em vez de depender de uma consulta manual à concessionária, o município consulta diretamente o Ambiente Nacional da NFS-e Via e obtém o dado oficial. Onde ainda faltam ferramentas — um convite à comunidade Documentos fiscais eletrônicos como o NFS-e Via costumam ganhar, com o tempo, componentes prontos que facilitam a integração para quem desenvolve sistemas — é o caso de vários documentos já cobertos pelo ecossistema ACBr. Essa API específica de alíquotas do NFS-e Via, no entanto, ainda não tem um componente ACBr dedicado. A criação desse suporte está no roadmap do projeto, mas ainda sem previsão específica de entrega. É justamente aí que a comunidade pode fazer a diferença: quem já trabalha com integrações para concessionárias de vias ou tem interesse no tema pode contribuir com o desenvolvimento desse componente, ajudando a antecipar essa entrega para quem depende dela no dia a dia. Onde acessar a documentação A documentação técnica completa — incluindo os endpoints de obtenção de documentos e as duas consultas de alíquotas — está disponível no Anexo V – Guia para Utilização das APIs, com ambientes de homologação, produção restrita e produção liberados para testes de integração. Se você desenvolve integrações fiscais e quer ajudar a preencher essa lacuna no ecossistema ACBr — seja com o componente do NFS-e Via, seja com a consulta de alíquotas por trecho —, essa é uma boa oportunidade de contribuir com o projeto e com quem depende dele. Conheça as APIs do projeto ACBr e veja como participar do desenvolvimento junto com a comunidade. Fonte oficial: Secretaria-Executiva do Comitê Gestor da NFS-e — NFS-e Via: Publicada nova API para consulta de alíquotas do ISS, publicada em 10/07/2026.

DANFe Simplificado Tipo 2: Sefaz publica as Notas Técnicas 2026/002 e 2026/003 e muda a impressão de NF-e e NFC-e A Sefaz definiu o leiaute e as regras operacionais do novo DANFe Simplificado Tipo 2. Entenda o que muda, os prazos de implantação e por que o mercado ainda precisa ficar atento antes de sair adequando os sistemas. Atenção! Aqui vale um alerta importante: embora o desenvolvimento esteja avançando, há diversos relatos na comunidade de que os ambientes da Sefaz ainda não estão aceitando de forma consistente o novo modelo de impressão para emissão de notas fiscais. Isso é comum em mudanças de leiaute recém-publicadas — a homologação e o comportamento do ambiente de produção das Secretarias de Fazenda estaduais costumam levar um tempo para acompanhar a própria nota técnica. Na prática, isso significa que testar o novo layout agora não substitui o acompanhamento contínuo do assunto até que a aceitação esteja de fato estabilizada. Resumo rápido A Nota Técnica 2026/003 v1.00 define o leiaute técnico e operacional do DANFe Simplificado Tipo 2, instituído pelo Ajuste SINIEF nº 13, de 6 de abril de 2026. A Nota Técnica 2026/002 v1.00 trata das regras de uso desse novo DANFe em operações presenciais e não presenciais, atendendo aos Ajustes SINIEF nº 32/25 e nº 13/26. O novo documento passa a cobrir com NF-e operações que hoje tipicamente usam NFC-e — mas o XML continua sendo o documento fiscal válido; o DANFe é só a representação impressa. Implantação em teste a partir de 01/07/2026 e em produção a partir de 03/08/2026 para a maior parte das mudanças (algumas regras têm cronograma próprio — veja a tabela abaixo). A implementação nas soluções ACBr já está em andamento, mas relatos da comunidade indicam que o ambiente da Sefaz ainda não está aceitando de forma consistente o novo modelo de impressão — ou seja, calma antes de sair trocando tudo em produção. O que é o DANFe Simplificado Tipo 2? O DANFe Simplificado Tipo 2 é um novo documento fiscal auxiliar, criado para padronizar a emissão de NF-e em operações que normalmente seriam cobertas por NFC-e. Assim como os demais modelos de DANFe já conhecidos pelo mercado, ele segue algumas regras básicas: É apenas a representação simplificada da operação — o XML continua sendo o documento fiscal de fato. A impressão é feita pelo próprio sistema do contribuinte, em impressora comum (não fiscal), com base nos dados do XML. Ele não pode conter nenhuma informação que não esteja no XML da NF-e correspondente. O leiaute definido pela NT 2026/003 organiza o documento em blocos que vão desde o cabeçalho e os itens da nota até a consulta por chave de acesso ou QR Code, informações do consumidor, dados de autorização e as novas informações de IBS/CBS, além do aviso exigido pela Lei Federal nº 12.741/2012 (a "lei da transparência fiscal"). O que muda na prática com a NT 2026/002 Enquanto a NT 2026/003 cuida do layout, a NT 2026/002 regulamenta como e quando esse novo DANFe pode ser usado. Os principais pontos: Alerta em vez de rejeição: é criado o novo cStat 120 – "Autorizado o uso da NF-e com alerta". Ele permite que a Sefaz autorize o documento mesmo diante de alguma inconsistência, sinalizando o problema em vez de simplesmente rejeitar a nota. Por enquanto, esse cStat vale só para NFC-e. Alerta de CNPJ irregular: passa a haver um aviso na emissão de NFC-e quando o destinatário for identificado por CNPJ em situação irregular. Vedação de referência cruzada: NF-e de saída não pode mais referenciar NFC-e ou CF-e, exceto quando se tratar de NF-e complementar. Contingência off-line regulamentada para a NF-e emitida com DANFe Simplificado Tipo 2. Regras que hoje valem só para a NFC-e (modelo 65) passam a valer também para a NF-e (modelo 55) — por exemplo, verificação de data de entrada/saída, tipo de operação e se a operação é interestadual ou com o exterior. O limite de R$ 10.000,00 para emissão de NFC-e sem identificação do destinatário continua valendo por padrão, mas a Sefaz vai publicar uma tabela com valores específicos por UF. No campo técnico, a NT também altera valores de campos já conhecidos do leiaute: o tpImp ganha o valor 6 (DANFe Simplificado Tipo 2), o indPres tem a descrição do valor 4 ajustada, e o tpEmis tem a descrição do valor 9 atualizada para contemplar a contingência off-line desse novo modelo. Cronograma de implantação Mudança Teste Produção Leiaute do DANFe Simplificado Tipo 2 (NT 2026/003) 01/07/2026 03/08/2026 Regra de emissão de NFC-e sem identificação do destinatário 01/06/2026 15/06/2026 Regras de validação para NF-e e rejeição de referência aos modelos 65/59 01/07/2026 03/08/2026 Estrutura de autorização com alertas e demais regras de validação 01/09/2026 05/10/2026 Vale reparar que as datas não são únicas: a mudança chega em ondas, o que dá algum fôlego para adequação — mas também exige atenção redobrada, já que cada regra entra em vigor em um momento diferente. O ACBr já está pronto? E a Sefaz? Do lado do desenvolvimento, o novo leiaute já está sendo trabalhado nas soluções ACBr — a NT 2026/003 está sendo acompanhada internamente pela tarefa ACBR-9424, e as mudanças da NT 2026/002 pela tarefa ACBR-9423. Quem utiliza os componentes de NF-e e NFC-e do ACBr deve acompanhar essas atualizações, já que a implementação do DANFe Simplificado Tipo 2 tende a chegar como parte natural da evolução desses componentes. Como se preparar Acompanhe os tópicos oficiais da NT 2026/002 e da NT 2026/003 no fórum do ACBr para novidades sobre a implementação. Não migre sistemas para produção com o novo layout sem antes validar o comportamento no ambiente de testes da Sefaz do seu estado. Fique atento às datas de cada regra — a rejeição de NF-e referenciando modelos 65/59 e as novas regras de validação chegam em momentos diferentes do leiaute do DANFe em si. Se seu sistema opera perto do limite de R$ 10.000,00 para NFC-e sem identificação do destinatário, monitore a publicação da tabela de valores por UF. Revise processos de contingência off-line, já que a NT 2026/002 regulamenta especificamente esse cenário para o novo modelo. Fonte oficial Informações baseadas nas publicações da comunidade do Projeto ACBr no fórum "Notícias do ACBr": Nota Técnica 2026/003 v1.00 — DANFe Simplificado Tipo 2 (Ajuste SINIEF nº 13/2026): Publicada NT que define leiaute do DANFe Simplificado Tipo 2 Nota Técnica 2026/002 v1.00 — Operações presenciais e não presenciais com DANFe Simplificado Tipo 2 (Ajustes SINIEF nº 32/25 e nº 13/26): Publicada Nota Técnica que cria NF-e "sabor" NFC-e Quer se antecipar a essas mudanças fiscais? Ficar por dentro de cada nota técnica é só o primeiro passo — o desafio real é manter seu sistema emissor sempre atualizado sem virar um projeto interminável. Conheça o ACBr PRO e simplifique a adequação da emissão de NF-e, NFC-e e dos demais documentos fiscais eletrônicos do seu sistema.

ACBr ganha novo componente: chega o ACBrNFGas para emissão da Nota Fiscal de Gás O ecossistema ACBr acaba de incorporar o ACBrNFGas, componente dedicado à emissão do novo documento fiscal eletrônico do setor de distribuição de gás canalizado. O componente já está disponível no código-fonte do projeto — e a comunidade é convidada a ajudar a evoluí-lo. O projeto ACBr recebeu a doação do componente ACBrNFGas, responsável pela emissão da NFGas, novo documento fiscal eletrônico voltado a distribuidoras de gás. O componente já permite emitir, consultar, cancelar e verificar o status do serviço da NFGas junto ao ambiente nacional. A NFGas é processada de forma centralizada pela Sefaz Virtual do Rio Grande do Sul (SVRS), com portal oficial em dfe-portal.svrs.rs.gov.br/Nfgas. A impressão do DANFGas (representação gráfica da NFGas) ainda não está implementada — e é justamente aí que a comunidade ACBr pode contribuir. O código-fonte já está disponível no repositório do projeto, na pasta fontes\acbrdfe\acbrnfgas. O que é a NFGas e por que ela importa A NFGas é o mais recente integrante da família de documentos fiscais eletrônicos nacionais, ao lado de modelos como a NF3e (energia elétrica) e a NFAg (água). Ela foi criada para digitalizar a emissão de documentos fiscais por parte das distribuidoras de gás canalizado, seguindo o mesmo racional de centralização e padronização que já rege os demais DF-e do país. Assim como acontece com outros documentos desse grupo, a autorização da NFGas não fica a cargo da Sefaz de cada estado isoladamente: o processamento é concentrado no ambiente nacional operado pela Sefaz Virtual do Rio Grande do Sul (SVRS) — com a Sefaz Virtual do Amazonas (SVAN) atendendo estados específicos —, disponível no portal dfe-portal.svrs.rs.gov.br/Nfgas. O que o ACBrNFGas já entrega O novo componente segue a mesma arquitetura consolidada dos demais componentes de documentos fiscais do ACBr (como ACBrNFe, ACBrCTe e ACBrNFAg), o que reduz a curva de aprendizado para quem já utiliza o ecossistema. Na prática, o TACBrNFGas já expõe as operações essenciais do ciclo de vida do documento: Enviar — transmissão da NFGas para autorização (lote de 1 documento por envio, conforme regra do modelo); Consultar — consulta de situação da NFGas por chave de acesso; Cancelamento — cancelamento via evento, informando justificativa e protocolo de autorização; EnviarEvento — envio de eventos vinculados à NFGas (lote de até 20 eventos); StatusServico — verificação de disponibilidade do webservice antes da transmissão. Um exemplo básico de uso no componente: ACBrNFGas1.Configuracoes.WebServices.UF := 'RS'; ACBrNFGas1.Configuracoes.WebServices.Ambiente := taHomologacao; ACBrNFGas1.NotasFiscais.LoadFromFile('C:\NFGas\NFGas.xml'); ACBrNFGas1.Enviar('1'); if ACBrNFGas1.NotasFiscais.Items[0].Confirmada then ShowMessage('NFGas autorizada com sucesso!'); O que ainda falta: o DANFGas precisa da comunidade Diferente de componentes mais maduros do ACBr, o ACBrNFGas ainda não conta com uma implementação funcional do DANFGas — a representação gráfica simplificada da NFGas, equivalente ao DANFE da NF-e. A classe TACBrNFGasDANFGasClass já define toda a estrutura esperada (ImprimirDANFGas, ImprimirDANFGasPDF, ImprimirDANFGasResumido, ImprimirEVENTO, entre outros métodos), mas cada uma dessas rotinas hoje apenas sinaliza que não foi implementada. É exatamente essa lacuna que abre espaço para a colaboração da comunidade: quem já desenvolveu ou tem experiência com a geração de DANFEs em outros componentes ACBr pode contribuir criando a implementação concreta do DANFGas, seguindo a mesma classe abstrata já disponível no código-fonte. Assim como o restante do projeto, o ACBrNFGas é um componente open source, mantido pela comunidade que sustenta o ACBr desde sua criação. Como contribuir Se você desenvolve em Delphi e trabalha com documentos fiscais eletrônicos, esta é uma boa oportunidade para colocar a mão na massa em um componente recém-chegado ao ecossistema: Acesse o código-fonte do componente em fontes\acbrdfe\acbrnfgas no repositório do projeto ACBr; Estude a implementação de DANFGas de componentes semelhantes (como o DANFE da NF-e ou o DANFAg) como referência de estrutura; Implemente os métodos ainda pendentes em TACBrNFGasDANFGasClass; Envie sua contribuição para revisão pela comunidade do projeto. Conclusão O ACBrNFGas amplia a cobertura do ACBr sobre os documentos fiscais eletrônicos nacionais e já entrega o essencial para emissão, consulta e cancelamento da NFGas. A implementação do DANFGas é a peça que falta para o componente alcançar maturidade completa — e é uma oportunidade concreta para quem quer contribuir com o projeto que sustenta a automação fiscal de milhares de empresas no Brasil. Quer ter acesso a suporte prioritário, componentes fiscais sempre atualizados e previsibilidade para manter sua aplicação em conformidade com novos documentos como a NFGas? Conheça o ACBr PRO e simplifique a emissão dos seus documentos fiscais. Fonte: Portal Nacional da NFGas, operado pela Sefaz Virtual do Rio Grande do Sul (SVRS) — dfe-portal.svrs.rs.gov.br/Nfgas.

ACBrNFAg: novo componente do Projeto ACBr chega para a Nota Fiscal da Água e Saneamento Eletrônica — e a comunidade é convidada a desenvolver o DANFAg O ecossistema ACBr ganha um componente dedicado à NFAg, o documento fiscal eletrônico das prestadoras de água e saneamento. A emissão já funciona de ponta a ponta — mas o layout do documento auxiliar (DANFAg) ainda está em aberto, e o Projeto ACBr conta com a comunidade para completá-lo. Resumo ACBrNFAg é o novo componente do Projeto ACBr para emissão da NFAg — Nota Fiscal da Água e Saneamento Eletrônica, documento fiscal modelo 75. A NFAg tem base na Lei Complementar 227, de 13/01/2026, e no Ato Conjunto RFB/CGIBS nº 1, de 22/12/2025, sob coordenação técnica do ENCAT e da SEFAZ Virtual RS (SVRS). A primeira NFAg em produção foi autorizada em 02/01/2026; as regras de validação de IBS e CBS já estão disponíveis em homologação desde 06/07/2026. O componente já cobre emissão, consulta, cancelamento e envio por e-mail da NFAg. A classe responsável pelo documento auxiliar — a DANFAg — ainda é abstrata: todos os métodos de impressão existem, mas disparam "não implementado". O Projeto ACBr está convocando a comunidade para desenvolver o layout e a lógica de impressão do DANFAg, o próximo passo para o componente ficar completo. O que é a NFAg A NFAg (Nota Fiscal da Água e Saneamento Eletrônica) é o modelo nacional de documento fiscal eletrônico — modelo 75 — criado para substituir os sistemas de emissão de contas de água e saneamento hoje usados pelas prestadoras desse serviço. O documento segue a mesma lógica de validade jurídica das demais notas eletrônicas do país: assinatura digital e transmissão à SEFAZ, o que passa a permitir o acompanhamento fiscal em tempo real das operações do setor. O projeto está sob coordenação técnica do ENCAT, com a SEFAZ Virtual RS (SVRS) operando a infraestrutura, e tem como base normativa a Lei Complementar 227/2026 e o Ato Conjunto RFB/CGIBS nº 1/2025 — este último aguardando publicação definitiva, mas já orientando o layout e as regras de negócio disponíveis para homologação. A primeira NFAg em ambiente de produção foi autorizada em 02/01/2026, e desde 06/07/2026 o ambiente de homologação já valida as regras de IBS e CBS aplicáveis ao documento. O novo componente ACBrNFAg Para atender prestadoras de água e saneamento que precisam se adequar a essa obrigação, o Projeto ACBr incorporou o componente ACBrNFAg, seguindo o mesmo padrão de uso dos demais componentes de documentos fiscais eletrônicos do ecossistema (como os já conhecidos para NF-e e CT-e). O componente já entrega o ciclo completo de emissão: with ACBrNFAg1.NotasFiscais.Add.NFAg do begin // Identificação Ide.cUF := UFparaCodigoUF('RS'); Ide.tpAmb := taHomologacao; Ide.modelo := 75; Ide.serie := 1; Ide.nNF := 123; Ide.cNF := GerarCodigoDFe(Ide.nNF); Ide.dhEmi := Now; Ide.tpEmis := teNormal; Ide.finNFAg := fnNormal; Ide.verProc := '1.0.0.0'; // Emitente Emit.CNPJ := '00000000000000'; Emit.IE := '000000000'; Emit.xNome := 'Prestadora de Saneamento LTDA'; Emit.EnderEmit.xLgr := 'Rua Exemplo'; Emit.EnderEmit.Nro := '100'; Emit.EnderEmit.UF := 'RS'; end; ACBrNFAg1.NotasFiscais.GerarNFAg; ACBrNFAg1.Enviar('1'); Com poucas linhas, o componente monta o XML, assina e transmite a NFAg à SEFAZ — a mesma experiência de uso já consolidada nos demais componentes de documentos fiscais do ACBr. O que falta: o DANFAg ainda não tem implementação A emissão funciona, mas o Documento Auxiliar da NFAg (DANFAg) — o "recibo" impresso ou em PDF que a prestadora entrega ao consumidor — ainda não tem layout implementado. A classe já existe na estrutura do componente, mas está abstrata, aguardando quem vá desenhar o documento: procedure TACBrNFAgDANFAgClass.ImprimirDANFAg(NFAg: TNFAg = nil); begin ErroAbstract('ImprimirDANFAg'); end; Ou seja: hoje, ao chamar ImprimirDANFAg, ImprimirDANFAgPDF, ImprimirDANFAgResumido ou os demais métodos de impressão, o componente retorna o erro "não implementado em: TACBrNFAgDANFAgClass". É exatamente essa lacuna que o Projeto ACBr quer preencher com a ajuda da comunidade. Como contribuir com o DANFAg Se você trabalha com sistemas para prestadoras de água e saneamento, ou simplesmente tem experiência com os componentes de DANFE/DACTE do ACBr, essa é uma oportunidade concreta de colaborar com um componente que vai beneficiar todo o setor: O ponto de partida no código-fonte é a unit ACBrNFAgDANFAgClass, na pasta Fontes/ACBrDFe/ACBrNFAg/DANFAg. Use como referência o padrão já implementado nas classes de DANFE de outros componentes do ecossistema (estrutura de impressão, geração de PDF e impressão resumida). Envie sua contribuição como Pull Request no repositório oficial do Projeto ACBr no GitHub, ou discuta a proposta de layout no fórum da comunidade antes de codificar, para alinhar expectativas com o time. Toda ajuda é bem-vinda: da implementação completa a testes com XMLs reais de homologação. Quer acompanhar de perto o desenvolvimento de componentes fiscais como o ACBrNFAg, contribuir com o projeto ou simplificar a emissão dos seus documentos fiscais? Conheça o ACBr PRO e veja como o ecossistema ACBr pode acelerar a adequação do seu sistema a essas novas obrigações. Fonte oficial Portal Nacional da NFAg — SEFAZ Virtual RS (SVRS): dfe-portal.svrs.rs.gov.br/Nfag Lei Complementar nº 227, de 13/01/2026 Ato Conjunto RFB/CGIBS nº 1, de 22/12/2025

Contingência NFC-e: como manter as vendas no ar quando a SEFAZ cai! Quem migrou do SAT para a NFC-e ganhou um sistema mais moderno — mas também um novo risco que o SAT nunca teve: depender da internet e da disponibilidade da SEFAZ para autorizar cada venda. Entenda como funciona a contingência offline antes que o primeiro "fora do ar" pegue seu cliente de surpresa. Resumo rápido Desde 1º de janeiro de 2026, a emissão de CF-e pelo SAT está proibida em São Paulo (Portaria SRE nº 79/2024) — a NFC-e (modelo 65) passou a ser o único documento aceito no varejo paulista. Diferente do SAT, que operava com memória fiscal própria e resistia bem a quedas de internet, a NFC-e depende de autorização em tempo real da SEFAZ para cada venda. Quando a comunicação falha, a saída é a contingência offline: o sistema emite a NFC-e localmente (tpEmis = 9), imprime o DANFE com o aviso de contingência e transmite o XML depois. O prazo para regularizar a nota junto à SEFAZ é, na maioria dos estados, de até 24 horas após a emissão (alguns estados aceitam até o primeiro dia útil subsequente). Usar contingência com frequência excessiva pode gerar questionamento do Fisco — o mecanismo é para exceções, não para operação contínua. Software houses que só conheciam o modelo SAT (equipamento físico, sem essa lógica de "depois eu regularizo") precisam adaptar processos, treinar suporte e revisar o PDV antes que a primeira instabilidade real aconteça. O que muda para quem vem do SAT O SAT foi desenhado para funcionar mesmo sem internet: o equipamento assinava e armazenava o cupom fiscal localmente, e a transmissão para a SEFAZ-SP era, na prática, um processo em segundo plano. A NFC-e inverte essa lógica — a autorização em tempo real é a regra, e a operação sem conexão é a exceção. Isso significa que qualquer sistema que tenha migrado do SAT para a NFC-e (obrigatório em SP desde o fim de 2025) precisa ter, desde o primeiro dia, uma rotina de contingência bem implementada. Sem ela, uma queda de link ou uma instabilidade momentânea da SEFAZ paralisa o caixa — algo que praticamente não acontecia no mundo SAT. Como funciona a contingência offline na prática Tentativa normal — o PDV envia a NFC-e para autorização. Se não houver retorno em poucos segundos, considera-se falha de comunicação. Entrada em contingência — o sistema emite a nota localmente, marcando o campo tpEmis = 9 (contingência off-line) e, em alguns casos, avançando a numeração para uma série específica de contingência, evitando rejeição por duplicidade. Impressão do DANFE — o documento é impresso normalmente, mas precisa conter, de forma obrigatória, a expressão "NFC-e EMITIDA EM CONTINGÊNCIA", além da data e hora do início da contingência. Transmissão posterior — assim que a comunicação for restabelecida, o XML é enviado à SEFAZ mantendo a mesma chave de acesso e o mesmo código numérico da emissão original, dentro do prazo legal (geralmente 24 horas, podendo ser até o primeiro dia útil seguinte, dependendo do estado). Vale lembrar que a contingência offline não é aceita da mesma forma em todos os estados — a decisão de permitir esse modelo é de cada Unidade Federada, e alguns exigem outras formas de contingência específicas. Por isso, o sistema emissor precisa checar as regras estaduais antes de assumir que a offline está liberada para aquele contribuinte. Cuidados que fazem diferença na prática Não trate a contingência como modo padrão. A SEFAZ recomenda usá-la apenas quando realmente há falha técnica — uso recorrente ou em volume alto pode chamar atenção do Fisco. Cuidado com a numeração. Notas emitidas em contingência que não são transmitidas e autorizadas dentro do prazo geram saltos de numeração no SPED, o que pode virar dor de cabeça na hora da fiscalização. Sincronize o relógio dos servidores. Divergência de data/hora é uma das causas mais comuns de rejeição em notas de contingência. Monitore a disponibilidade da SEFAZ. O Portal Nacional da NF-e e serviços como o Downdetector ajudam a confirmar se o problema é geral (SEFAZ fora do ar) ou pontual (rede do cliente) — isso evita ativar contingência sem necessidade. Instabilidades pontuais acontecem, e o gráfico de relatos do Downdetector mostra bem esse comportamento: durante boa parte do dia os relatos de falha com a SEFAZ ficam numa faixa baixa (poucas dezenas no acumulado), mas em determinados períodos essa curva sobe de forma abrupta — de menos de 10 relatos por hora para perto de 90 em poucas horas. É exatamente nesse tipo de pico que a contingência offline deixa de ser teoria e se torna a única forma de manter o caixa funcionando. Em fevereiro de 2026, por exemplo, a SEFAZ de Goiás precisou manter a Sefaz Virtual de Contingência (SVC) ativa durante um fim de semana inteiro após uma falha no sistema de autorização de NF-e — o tipo de cenário para o qual toda software house precisa estar preparada. Automatize a transição de volta ao modo normal. Assim que a comunicação for restabelecida, o sistema deve parar de gerar notas em contingência — continuar nesse modo por comodidade é o erro mais comum e o mais arriscado fiscalmente. Checklist para quem migrou recentemente do SAT O PDV detecta automaticamente falha de autorização e ativa a contingência sem intervenção manual do operador de caixa? O DANFE gerado em contingência traz o aviso obrigatório e os dados de início da contingência? Existe rotina automática de retransmissão do XML assim que a conexão volta? A equipe de suporte sabe explicar para o cliente final o que é uma "nota em contingência" e por que ela é válida? O time de TI já testou o cenário de contingência em homologação, e não só em produção durante um incidente real? Fontes Portaria SRE nº 79/2024 (SEFAZ-SP), que determina o fim do CF-e-SAT a partir de 1º de janeiro de 2026. Manual de Orientação ao Contribuinte (MOC) da NFC-e e páginas de contingência das SEFAZ estaduais (regras de prazo, tpEmis e DANFE de contingência). Nota da Secretaria da Economia de Goiás sobre a instabilidade no sistema de NF-e e ativação da SVC em fevereiro de 2026. Gráfico de relatos de falha com a SEFAZ nas últimas 24 horas, Downdetector (consultado no momento da publicação — os números variam a cada dia e devem ser conferidos em tempo real em downdetector.com.br/fora-do-ar/sefaz). Oportunidade! Se a sua software house está adaptando o PDV para lidar com esses cenários de contingência, vale a pena não reinventar a roda: o Clube ACBr Pro inclui o curso NFC-e Contingência Offline, que ensina a implementar esse fluxo do zero — da automatização da entrada e saída da contingência à transmissão posterior — com os fontes do projeto disponíveis para Delphi 7 até a versão 13. Se sua equipe já é assinante Pro, o curso já está incluído no plano; se ainda não é, essa é uma boa porta de entrada para não deixar o cliente na mão na próxima instabilidade da SEFAZ.

Bom dia. temos a tarefa ACBR-9462 para essa implementação. vamos anexar sua contribuição.

Boa tarde, Criada a tarefa ACBR-9582 para avaliação. Obrigado pela contribuição.

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!

Adicionada documentação enviada pelo usuário no discord. Nota Fiscal de Serviços Eletrônica Integração.pdf

Bom dia, Criada a tarefa ACBR-9475 para avaliação. Obrigado pela contribuição!