Pesquisar na Comunidade

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.

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.

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.

Olá pessoal! Foi publicado o AJUSTE SINIEF Nº 2, DE 11 DE ABRIL DE 2025 que aumenta o prazo em que o fisco deve guardar os documentos fiscais eletrônicos emitidos. Em outras palavras, agora o fisco deve guardar o XML da NF-e, CT-e, MDF-e, NFC-e, BP-e, NF3e, CTe-OS, GTV-e, DC-e, NFCom e todos os seus eventos vinculados por um período de 11 anos. O ajuste entra em vigor na data de sua publicação e produz efeitos a partir do primeiro dia do mês subsequente. Vale mencionar: O prazo de guarda desses documentos pelos contribuintes permanece inalterado conforme artigo 174 da Lei N° 5.172, de Outubro de 1996: Em outras palavras, a Sefaz precisa guardar os XMLs por 11 anos e o contribuinte precisa guardar o XML por 5 anos.

Olá pessoal! Ao acessar o Portal SPED MG o seguinte aviso é exibido informando sobre possível instabilidade nos serviços de documentos fiscais eletrônicos entre às 08h00 e 18h00:

Boa noite a todos, Quais são os documentos fiscais que o ACBR Monitor "PLUS" para assinantes emite? Grato,