Painel de líderes

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.

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

Olá, comunidade ! Informamos que foi efetuado o revert de algumas das modificações realizadas para adequar o ACBrNFe (e consequentemente o Monitor e a Lib) à versão 1.40 da Nota Técnica 2025/002 da Reforma Tributária. Foram revertidas as alterações visando atender à eliminação do evento "211120 - Destinação de item para consumo pessoal" e à alteração no leiaute do evento "211110 - Solicitação de Apropriação de crédito presumido". Essa decisão foi tomada com base em três fatores. O primeiro é que, até 09/07/2026, a Sefaz ainda não havia liberado novo arquivo de schema atualizando a estrutura do XML do evento 211110, acarretando erro de validação de schema ao gerar o XML com a estrutura atualizada. O segundo é que, mesmo editando o arquivo de schema manualmente ou desabilitando a validação de schema no componente, a própria Sefaz rejeita o XML informando que a nova estrutura está incorreta: O terceiro é que, mesmo tendo passado a data mencionada na NT, a Sefaz ainda está recepcionando e autorizando o evento 211120: Ressaltamos que: As alterações feitas previamente foram devidamente armazenadas, portanto, assim que for divulgado novo arquivo de schema e a Sefaz implementar as alterações previstas, o componente será atualizado novamente conforme orienta a NT. Somente as alterações relacionadas aos eventos foram revertidas e, portanto, as modificações feitas no leiaute da NF-e continuam como estavam.

Foram identificados casos de fraude em que, usando engenharia social, golpistas instalam um proxy na maquina do lojista (ou no servidor do PDV) capaz de interceptar a resposta dos endpoints de criação de cobranca Pix (`/cob` e `/cobv`). Com isso, conseguem manipular o campo "pixCopiaECola" devolvido pela API do PSP, substituindo por um código falso que aponta para a conta do fraudador. O resultado: o cliente escaneia o QR gerado pelo PDV, paga normalmente, mas o dinheiro vai para outra conta. O lojista não recebe nada e só percebe o problema depois. --- ## O que foi feito ### O componente ACBrPIXCD recebeu uma camada extra de validação que é executada automaticamente após a criação de cobrancas (`CriarCobrancaImediata` e `CriarCobranca`). A validação verifica a integridade e a coerência do `pixCopiaECola` devolvido pelo PSP antes que o código chegue ao PDV ou seja exibido ao cliente. Essa proteção se aplica apenas a PSPs que utilizam o padrão Bacen (campo `IsBacen = True`). --- ## Como desativar, se necessário ### A validação é controlada pela propriedade ValidarCopiaECola do componente TACBrPixCD. Por padrao ela vem **habilitada**. Se a validação estiver gerando falsos positivos no seu PSP (erro ao criar cobrança sem motivo aparente de fraude), você pode desliga-la: - No Object Inspector (design time) Localize o componente ACBrPixCD1 no formulário, expanda suas propriedades e defina: ValidarCopiaECola = False - Por codigo (run time) ACBrPixCD1.ValidarCopiaECola := False; * IMPORTANTE: Desative a propriedade apenas como medida temporária de diagnostico. Recomendamos que você informe o caso ao nosso suporte no DISCORD para que o problema de compatibilidade seja corrigido. Manter a validação ativa e a forma mais segura de proteger seus clientes. --- ## Como atualizar ## Basta atualizar o componente ACBrPIXCD pelo SVN(trunk2). --- ## Duvidas e problemas ## Abra um tópico no Fórum informando: - Nome do PSP utilizado - Anexe logs (nível mais alto) - A mensagem de erro recebida (se houver) Com essas informações conseguimos verificar se e um caso de incompatibilidade com o PSP ou se a validação detectou uma adulteração real.

Olá pessoal, Foi feita uma alteração no DANFSE em Fortes Report, mais precisamente no DANFSE do Padrão Nacional. Em breve teremos essa mesma alteração em Fast Report e FPDF. Agora o componente vai se utilizar de um dos dois logos oficiais que se encontram na documentação da NFS-e Padrão Nacional. Logos da NFS-e — Portal da Nota Fiscal de Serviço eletrônica Temos o Logo Horizontal e o Vertical, se o componente não for configurado ou a configuração estiver errada ele assume o Logo Horizontal. Como configurar o Logo da NFS-e? Delphi/Lazarus: // Utilize uma das 2 string: ACBrNFSeXLogoH; ACBrNFSeXLogoV ACBrNFSeX1.DANFSE.LogoNFSe := 'ACBrNFSeXLogoH'; ACBrLibNFSe: ACBrMonitor Plus:

Olá comunidade ACBr, Este tópico tem o objetivo de auxiliar quem estiver com problemas nas integrações com o eFrete para geração do CIOT e demais métodos da integradora. Foram mapeados erros e documentadas dicas para solução. 1. Autenticação 1.1. Geral 1.1.1. Integrador não cadastrado * Integrador.Nao.Cadastrado * O HASH fornecido pelo eFrete não foi preenchido 1.1.2. Integrador de software não homologado para esta solicitação. * Preenchido HASH inválido 1.2. Método de Login 1.2.1. O retorno do método não gera token, mas não gera rejeição acusando o problema * Verificar se está preenchendo o Hash válido, mas usuário e/ou senha inválidos * Se for configurado certificado digital, este método não deve ser utizado, para geração de token deixar os dados de certificado sem preenchimento 1.2.2. Erro adicionando operação de transporte: Usuário não logado * Usuario.Nao.Logado * Consumo de qualquer método com um token antigo/encerrado 2. Adicionar Operação 2.1. Operação de transporte já cadastrada * IdCliente.Existente * Já existe um CIOT cadastrado, necessário encerrar a operação existente 2.2. '' não é um valor válido para TipoIndicadorPagamentoEnum * Nos dados de pagamentos, preencher a chave IndicadorPagamento com AVista ou APrazo 2.3. Código NCM deve se r entre 1 e 9999 * CodigoNCM.Fora.Da.Faixa * Preencher a chave CodigoNCMNaturezaCarga com o devido valor entre 1 e 9999 * Verificados locais informando que são os 4 primeiros dígitos do NCM do produto de maior valor da carga 2.4. Foi identificado pelo sistema diferentes valores para o campo TipoPagamento, verifique se foi informado o mesmo valor para o campo TipoPagamento na raiz da chamada, na raiz de Viagem e de Pagamento. * Caso não enviado algum campo o sistema assumirá a primeira posição dos itens que também pode não coincidir com o valor desejado. * Regra.Negocio * Preencher no cadastro do CIOT, Viagem e Pagamento, o mesmo valor nas chaves TipoPagamento > 1-TransferenciaBancaria, 2-eFRETE, 3-Parceiro, 4-Outros, 5-DepositoAgendado * Exemplo: TipoPagamento=1 2.5. Data de início da viagem deve ser maior ou igual à data atual * Data.Inicio.Viagem.Anterior.Ao.Dia.Atual * Preencher o valor correto na tag DataInicioViagem 2.6. Código do tipo de carga inválido. Deve ser maior que 0 e menor ou igual a 12 * Codigo.Tipo.Carga.Fora.Da.Faixa * Preencher a chave CodigoTipoCarga com valor entre 1 e 12: 0-tpNaoAplicavel, 1-tpGranelsolido, 2-tpGranelLiquido, 3-tpFrigorificada, 4-tpConteinerizada, 5-tpCargaGeral, 6-tpNeogranel, 7-tpPerigosaGranelSolido, 8-tpPerigosaGranelLiquido, 9-tpPerigosaCargaFrigorificada, 10-tpPerigosaConteinerizada, 11-tpPerigosaCargaGeral, 12-tpGranelPressurizada * Exemplo: CodigoTipoCarga=5 2.7. Erro validando Destinatário: Documento inválido(a) * Regra.Negocio * O mesmo ocorre para a seção Contratante * Preencher a chave CpfOuCnpj da respectiva seção com um documento válido 2.8. Erro validando Destinatário: Nome é obrigatório * Regra.Negocio * O mesmo ocorre para a seção Contratante * Preencher a chave NomeOuRazaoSocial da respectiva seção 2.9. Destinatario. Erro validando Destinatário: Rua não pode ser em branco - O mesmo para os demais campos de endereço * Regra.Negocio * O mesmo ocorre para a seção Contratante * Preencher as chaves de endereço na respectiva seção Bairro= Rua= Numero= Complemento= CEP= CodigoMunicipio= 2.10. Algum dos envolvidos na operação de transporte deve ser informado como o responsável pelo pagamento * Deve.Haver.Responsavel.Pelo.Pagamento * Preencher a chave ResponsavelPeloPagamento=1 em uma das seções: Contratante, SubContratante, Consignatario, TomadorServico, Remetente, ProprietarioCarga 2.11. Os dados bancários não foram informados, não são de uma conta válida ou estão em formato errado. [Formato Agencia: Numero-Digito (Se houver). Conta: Numero-Digito] * Conta.Bancaria.Invalida * Preencher as chaves a seguir nas seções Viagem e/ou Pagamento InstituicaoBancaria= Agencia= Conta= 2.12. Motorista não encontrado * Motorista.Nao.Encontrado * Preencher as chaves da seção Motorista, com valores válidos CpfOuCnpj= CNH= 2.13. Não foi encontrado nenhum transportador com CPF/CNPJ XXXXXXXXXXXXXXX e RNTRC XXXXXXXXX * Preencher com valores válidos as chaves a seguir da seção Contratado CpfOuCnpj= RNTRC= 2.14. Usuário não possui permissão na transportadora com CNPJ 04430502000103, ou permissão insuficiente * Usuario.Sem.Permissao.Na.Transportadora.Ou.Permissao.Insuficiente * Em HOMOLOGAÇÃO: Nos dados do CIOT, preencher as chaves a seguir com o CNPJ cadastrado na conta do portal dev MatrizCNPJ=XXXXXXXXXXXXXX FilialCNPJ=XXXXXXXXXXXXXX 2.14.1. Envio com token * As credenciais podem estar ativas logando com cpf ou e-mail, confirme as credenciais recebidas do suporte do e-frete * Mesmo gerando token válido, o usuário preenchido com cpf ou e-mail pode não ter permissão para emissão do CIOT * Validar o login com cpf ou e-mail e verificar se o token com uma das opções não cai na rejeição 2.15. O CNPJ do MatrizCNPJ deve ser igual do Contratado ou do Contratante * Matriz.Cnpj.Invalido * Preencher o mesmo CNPJ da chave MatrizCNPJ em CpfOuCnpj da seção Contratado ou Contratante 2.16. Veículo com placa: AAA1234 com RNTRC inválido * Veiculo.RNTRC.Invalido * Corrigir a chave Placa da seção Veículo 2.17. O valor do frete informado é menor do que o valor mínimo de frete estabelecido * Revisar as chaves de valores a seguir das seções Viagem e Pagamento * Viagem TotalOperacao= TotalViagem= TotalDeAdiantamento= TotalDeQuitacao= Combustivel= Pedagio= OutrosCreditos= Seguro= OutrosDebitos= * Pagamento Valor= 2.18. Operação de transporte já cadastrada * IdCliente.Existente * Mesmo IdOperacaoCliente já cadastrado em outro CIOT 3. Adicionar Viagem 3.1. Campo CepOrigem com o valor '' é inválido ou Campo CepDestino com o valor '' é inválido * Campo.Invalido * Preencher as chaves CepOrigem e CepDestino da seção Viagem 3.2. É obrigatório preencher os valores das viagens * Problema verificado em HOMOLOGAÇÃO, mas identificado o motivo * Viagem.Valores.Nulo * Revisar as chaves de valores a seguir da seção Viagem * Mesmo preenchendo todos os campos de valores, assim como feito na inclusão do CIOT, o problema persiste em HOMOLOGAÇÃO 4. Consultar Tipo de Carga * Este.Metodo.Foi.Desabilitado.Nao.Requerido.Emissa.oCiot * Método desabilitado pelo e-Frete 5. Erros em homologação que não acontecem em produção 5.1. Encerrar Operação 5.1.1. Erro 400 * Encerrar CIOT com DataInicioViagem futura * Erro ao enviar CIOT Código de erro: -10. Último retorno: Erro Interno: 0 * Erro HTTP: 400 * URL: https://dev.efrete.com.br/Services/PefServiceV2.asmx 5.2. Outros 5.2.1. A requisição não pode ser nula / Requisição inválida * Requisicao.Nao.Pode.Ser.Nula * Requisicao.Nula * Diversos métodos geram estas rejeições em Homologação, não foi identificado o motivo e não conseguimos suporte do efrete para identificação do problema * GravarAdicionarPagamentos, GravarAlterarDataLiberacaoPagamento, GravarCancelarPagamento, GravarRegistrarPagamentoQuitacao, GravarRegistrarQtdeMercadoriaDesembarque, GravarRetificarOperacao Contamos com a contribuição da comunidade: Caso encontrem a solução para algum dos erros acima ainda não identificados para atualizarmos este tópico e ajudar quem mais tiver problemas com essa integradora. Até mais!!!

A receita federal, atendendo a pedido feito pelo Serpro sob a justificativa de melhor poder distribuir os procedimentos técnicos ao longo da implementação, divulgou uma antecipação do cronograma da implantação do CNPJ Alfanumérico. Das 21h do dia 23 de julho de 2026 (quinta-feira) até as 7h do dia 25 de julho de 2026 (sábado): A base de dados do CNPJ estará disponível apenas para consulta, sem a possibilidade de atualizações ou inclusões cadastrais. A partir das 7h do dia 25/07/2026 (sábado): A base ficará completamente indisponível. A partir das 7h do dia 27 de julho de 2026 (segunda-feira): Entrada em produção do sistema. Dia 31 de julho de 2026 (sexta-feira): Implementação do primeiro CNPJ alfanumérico. Mais informações podem ser encontradas no Portal do CNPJ Alfanumérico.

Olá Pessoal, O uso do Padrão Nacional é um movimento crescente, começando com sua obrigatoriedade para os MEIs em 2023, sua próxima obrigatoriedade para os prestadores enquadrados no Simples Nacional agora em 2026 (veja mais sobre isso aqui) e o fato de todos os 5.571 municípios terem se conveniado, seja para realizar a emissão direta ou via compartilhamento de informações. Diferente de situações anteriores, a prerrogativa de "padrão" implica em uma padronização única. Isso se aplica inclusive ao próprio leiaute do DANFSe. Onde anteriormente não havia nenhuma regulamentação ou orientação sobre como deve ser o leiaute do impresso, hoje existem definições explícitas com a publicação da Nota Técnica Nº008, estabelecendo parametrizações como o que pode constar no impresso, o que não pode e como as informações devem ser exibidas nele. A equipe do ACBr já adaptou o impresso em Fortes para atender a essas definições e está trabalhando arduamente para disponibilizar os impressos em Fast e em FPDF. Levando tudo isso em consideração, informamos que os esforços a partir de agora serão focados em manter o DANFSe atendendo à NT Nº008 ou qualquer publicação futura relacionada e, por isso, não serão feitas novas alterações no DANFSe utilizado para os provedores no leiaute da ABRASF e em leiautes próprios. Ressaltamos que, na conjuntura atual, mesmo os municípios que aderiram apenas ao compartilhamento e vão continuar utilizando provedores próprios já têm disponibilizado em seus arquivos XML e retornos do web service os meios para que o XML da NFS-e compartilhado no ambiente nacional seja acessado e, de posse desse XML, o DANFSe no leiaute estabelecido pela NT Nº008 pode ser utilizado. Agradecemos a compreensão de todos.

Olá comunidade ! Foi publicado no dia 30/06/2026 a versão 1.01 da Nota Técnica Nº008 que traz as especificações de como deve ser o DANFSe. A nova versão não traz alterações no leiaute do impresso. Ela prorroga a desativação do end-point existente no padrão nacional para obter o DANFS-e para o dia 15/07/2026, efetivamente dando mais 15 dias para que as soluções e aplicações possam adequar seus leiautes. A versão 1.01 desta nota técnica pode ser lida na íntegra AQUI. Vale reforçar que o impresso utilizando Fortes Report já foi adequado no ACBr conforme tópico abaixo e os impressos em Fast e FPDF estão em construção.

Olá, comunidade ! No dia 07/07/2026, por volta das 10h00 começamos a receber múltiplos relatos de membros da nossa comunidade informando problemas de lentidão e até mesmo erros apontando problemas na comunicação com a Sefaz de São Paulo. Os relatos de erro variam de "Erro não catalogado" à "The server is busy now. Try again later". O acesso direto aos portais também está apresentando lentidão e erros como "An unexpected error has occurred." Conferindo em ferramentas de monitoramento como o DownDetector, é possível observar que o volume de relatos de problemas subiu exponencialmente por volta desse mesmo horário: Não há até o momento aviso de contingência ativada para a NF-e no Portal Nacional. Para a emissão de NFC-e a contingência offline pode ser utilizada. Lembrando que os membros do ACBr PRO possuem acesso ao curso Implementando a contingência offline da NFC-e onde o processo é explicado e demonstrado na prática nas soluções ACBr.

Olá, comunidade ! Por volta das 8h27 do dia 01/07/2026, múltiplos membros de nossa comunidade começaram a relatar um atraso na disponibilização da nota autorizada no ambiente nacional. De acordo com os relatos, mesmo decorrido algum tempo após a emissão, ao consultar a respectiva nota no portal nacional, ela não era encontrada. Os relatos indicam tratar-se de um atraso na sincronização entre o ambiente nacional e o ambiente estadual. Isso foi confirmado pelo fato de que, ao consultar a nota via web service, por chave de acesso, é devolvida a informação de autorização — e a nota também consta normalmente no portal estadual.

Olá comunidade ! Como muitos devem saber, a partir de 01/09/2026, os prestadores de serviço optantes pelo Simples Nacional deverão obrigatoriamente emitir suas notas fiscais de serviço pelo padrão nacional, independentemente do município ao qual pertençam. (Se você não sabe do que se trata, confira este tópico). Essa obrigatoriedade é semelhante à que ocorreu em 2023 para os prestadores de serviço MEI. (Veja mais sobre isso neste tópico) Reforçamos que as soluções ACBr vêm atendendo a essa demanda dos prestadores MEI desde 2023 e a mesma configuração poderá ser utilizada pelos optantes pelo Simples Nacional quando a obrigatoriedade entrar em vigor. Trata-se da propriedade LayoutNFSe, que possui 3 valores válidos: lnfsProvedor: a solução ACBr se comunica com o web service do provedor que atende ao município. lnfsPadraoNacionalv1: a solução ACBr se comunica com o padrão nacional em sua versão 1.00, independentemente do provedor que atende ao município. Atenção: essa versão não aceita os campos da reforma tributária e por isso pode ser considerada "obsoleta". lnfsPadraoNacionalv101: a solução ACBr se comunica com o padrão nacional em sua versão 1.01, independentemente do provedor que atende ao município. Essa é a versão que aceita os campos da reforma tributária. Exemplo de configuração no ACBrNFSeX: ACBrNFSeX.Configuracoes.Geral.LayoutNFSe := lnfsPadraoNacionalv101; Exemplo de configuração no ACBrMonitorPLUS NFSe.SetLayoutNFSe(2) Ou via interface gráfica, no caminho DFe -> WebServices -> NFSe: Exemplo de configuração na ACBrLibNFSe NFSe_ConfigGravarValor("NFSe", "LayoutNFSe", "2"); NFSe_ConfigGravar(); Exemplo de configuração da ACBr API Envie o valor nacional na chave "provedor" do JSON do payload: {"provedor":"nacional",...}

Inclusão do método SalvarPDF nas classes C# Olá comunidade! Visando manter a estabilidade e segurança das classes C# adicionaremos o método SalvarPDF Nossa recomendação para as classes MDFe, NFe e NFSe é a utilização do método SalvarPDF() ao invés do ImprimirPDF(Stream aStream); A motivação dessa mudança é que esse método utiliza operações assíncronas e pode causar Condição de Corrida. Além disso, mantém coerente a documentação da ACBrLib Se utiliza classes C# MT deve atualizar os pacotes o mais breve possível. Diferente de ImprimirPDF(Stream aStream), o SalvarPDF retorna uma String com o conteúdo do PDF em base64. Até a data da publicação desse tópico foram atualizados: Atualizado em 14/07/2026 NFe versão 1.0.37 MDFe versão 1.014 NFSe versão 1.0.17 CTe versão 1.0.14 Boleto versão 1.0.34 Exemplo de código antigo: // exemplo de código antigo Stream ms = new Stream() nfe.ImprimirPDF(ms); Código recomendado: string pdfStream = nfe.SalvarPDF(); Boleto: Código antigo // exemplo de código antigo usando Stream Stream ms = new Stream() boleto.GerarPDF(ms); // boleto indexado usando Stream Stream ms2 = new Stream(); boleto.GerarPdf(0, ms2); Código recomendado: // código atual string pdfStream = boleto.SalvarPDF(); string pdf = boleto.SalvarPDF(0);

Bom dia a todos. Abaixo um checklist do andamento da implementação das alterações para a versão 1.40 da NT. As tarefas estão avançadas, mas travadas na validação do XML gerado pois ainda não temos schemas atualizados para a atualização. Enquanto os schemas não forem liberados, as alterações não podem ser enviadas em produção.

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.

Olá, comunidade ! Ao acessar o Portal da Nota Fiscal Eletrônica, é possível observar que múltiplas UFs estão com contingência agendada para o dia 19/07/2026, com previsão de início às 06h30 e encerramento às 09h00 do mesmo dia. Para utilizar as soluções do ACBr em contingência siga as orientações do tópico abaixo: Um agradecimento ao membro de nossa comunidade @Felipe Mariano por compartilhar a informação no canal #sefaz em nosso servidor do Discord.

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.

Olá Pessoal, Foi implementado o provedor Agape que trabalha com a versão 2.03 do layout da ABRASF no momento temos somente a cidade de Boquim/SE configurada. Caso alguém saiba de mais cidades atendidas pelo referido provedor favor criar um tópico informando as URLs de produção e homologação.

A Receita Federal informa que a implantação do CNPJ alfanumérico ocorrerá a partir de 31/07/2026. Vale destacar que os CNPJs numéricos e alfanuméricos coexistirão e mesmo a geração de CNPJs puramente numéricos continuará a ocorrer tendo em vista que cerca de 69 milhões das 99.999.999 combinações possíveis foram utilizadas. Veja a notícia original na qual esse tópico se baseia AQUI. Veja mais sobre o CNPJ alfanumérico no tópico: Veja mais sobre a situação das soluções ACBr e o CNPJ alfanumérico no tópico:

Olá, comunidade ACBr! Ficamos felizes em anunciar o lançamento da ACBrLibCIOT! Baixe a ACBrLibCIOT: Na versão DEMO Na versão PRO Leia a documentação completa AQUI Até mais!!!

Olá, comunidade ! Ao acessar a lista de Atualizações e Implantações da Sefin Nacional da NFS-e, consta que no dia 01/07/2026 foram efetuados ajustes nas seguintes regras de validação: Cód. Erro Mensagem de Erro E1577 Alíquota efetiva da UF para IBS incorreta. E1549 Alíquota efetiva do Município para IBS incorreta. E1554 Alíquota efetiva da União para CBS incorreta. Havia uma divergência no cálculo e na validação dos campos pAliqEfetUF, pAliqEfetMun e pAliqEfetCBS. Eles são obrigatórios e devem ter o mesmo valor de pIBSUF, pIBSMun e pCBS, respectivamente quando não houver redutores.

Enviado para o SVN commit [r46981] com as adequações para a NT. Demos e manuais atualizados para gerar novos campos. Tivemos atualização dos schemas da NFe, então é importante atualizar os mesmos.

Olá comunidade ! A partir de 01/07/2026 entra em vigor no estado de São Paulo a Versão 20260626 da Tabela CST x cBENEF utilizada pelo estado. A principal alteração dessa versão é a desativação do código "SEM CBENEF". A tabela pode ser encontrada na íntegra nos formatos PDF, Excel e ODS neste link. Vale lembrar que essa tabela é única por UF, ou seja, a tabela utilizada por SP não é a mesma utilizada por GO.

Passo a passo para a integração Realize o pré-cadastrado no site Dev.eFrete. Após o preenchimento do e-mail, você vai receber um e-mail da eFrete que deve ser respondido com CNPJ da empresa e Nome fantasia do sistema, ERP ou TMS. Depois de enviar essas informações, você receberá as credências de acesso ao ambiente de homologação e os dados aceitos no ambiente. Obs: Devido ao aumento repentino no volume de integrações temos recebido relatos de que esse processo pode levar um tempo para ser concluído. Particularidades e dicas extras Operações com certificado x Login sem certificado Login sem certificado: Para qualquer operação sem o certificado digital no eFrete é preciso de um token de autenticação que é gerado ao realizar a operação de Login. A operação de Login é feita utilizando o hash, usuário, senha e não devem ser preenchidos os dados do certificado no componente, conforme exemplo: ACBrCIOT.Configuracoes.Certificados.ArquivoPFX := ''; ACBrCIOT.Configuracoes.Certificados.Senha := ''; ACBrCIOT.Configuracoes.Certificados.NumeroSerie := ''; // Atenção, desabilitar essa propriedade ACBrCIOT.SSL.UseCertificateHTTP := False; ACBrCIOT.Configuracoes.Geral.Usuario := 'usuario do eFrete'; ACBrCIOT.Configuracoes.Geral.Senha := 'senha do eFrete'; ACBrCIOT.Configuracoes.Geral.HashIntegrador := 'HashIntegrador do eFrete'; A operação de login irá gerar um token que deverá ser preenchido nas demais operações, conforme exemplo: with ACBrCIOT.Contratos.Add.CIOT do begin // Só é necessário se usar usuario e senha e não o certificado Integradora.Token := 'token recebido na operação de login'; end; Operações com certificado: Para as operações com o certificado digital no eFrete, o login não é necessário pois não será utilizado o token, bastando preencher os dados do certificado, conforme exemplo: // Não preencher o ArquivoPFX se preencher o NumeroSerie ACBrCIOT.Configuracoes.Certificados.ArquivoPFX := 'arquivo. pfx'; ACBrCIOT.Configuracoes.Certificados.Senha := 'senha do certificado'; // Não preencher o NumeroSerie se preencher o ArquivoPFX ACBrCIOT.Configuracoes.Certificados.NumeroSerie := 'número de série do certificado'; // Atenção, habilitar essa propriedade ACBrCIOT.SSL.UseCertificateHTTP := True; ACBrCIOT.Configuracoes.Geral.Usuario := ''; ACBrCIOT.Configuracoes.Geral.Senha := ''; ACBrCIOT.Configuracoes.Geral.HashIntegrador := ''; Campos de mesmo nome com valores diferentes Dada a relação com o MDF-e, alguns campos podem receber a mesma informação. É importante lembrar, no entanto, que cada documento tem seu próprio conjunto de valores aceitos. Um exemplo é o campo TipoRodado no eFrete e o campo tpRod no MDF-e. Ambos recebem a informação do tipo de rodado, mas cada documento aceita um conjunto de valores diferente: MDF-e: 01 - Truck; 02 - Toco; 03 - Cavalo Mecânico; 04 - VAN; 05 - Utilitário; 06 - Outros. eFrete: NaoAplicavel; Truck; Toco; Cavalo. Exemplo de preenchimento do tipo Rodado para o eFrete no ACBrCIOT: var lCIOT: TCIOT; begin lCIOT := ACBrCIOT.Contratos.Add.CIOT; lCIOT.Integradora.Operacao := opGravarVeiculo; //Valores válidos são trNaoAplicavel, trTruck, trToco, trCavalo lCIOT.GravarVeiculo.TipoRodado := trNaoAplicavel; //Demais informações... end; Valores e informações específicos para o ambiente de homologação O ambiente de homologação por padrão solicita o envio de um certificado digital, mas seu envio não é obrigatório. Em ambiente de homologação apenas os Integradores são cadastrados, informe seu próprio, CNPJ como MatrizCNPJ e como Contratante do Frete nas requisições relacionadas. Exemplo de preenchimento de MatrizCNPJ e Cnpj do contratente no ACBrCIOT para o eFrete: var lCIOT: TCIOT; begin lCIOT := ACBrCIOT.Contratos.Add.CIOT; lCIOT.Integradora.Operacao := opAdicionar; lCIOT.AdicionarOperacao.MatrizCNPJ := 'pseudoCNPJ'; lCIOT.AdicionarOperacao.Contratante.CpfOuCnpj := 'mesmopseudoCNPJ'; //Demais informações... end; Web Service Soap x API Rest A integradora eFrete disponibiliza tanto um web service SOAP que comunica com arquivos XMLs quanto uma API Rest que recebe arquivos JSON. O componente ACBrCIOT se comunica com o web service SOAP. Caso enfrente algum problema ou erro inesperado, é válido realizar um teste para a mesma operação na API Rest e conferir se o retorno diverge. Você pode utilizar uma ferramenta de IA para converter o XML gerado pelo componente no JSON correspondente e fazer o envio. Leia o manual do eFrete na integra AQUI.

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

Olá, comunidade ! Foi publicado no dia 15/07/2026 a versão 1.40 da Nota Técnica 2014/001 que traz definições sobre o Evento Prévio de Contingência (EPEC). Alterações Adiciona a seguinte rejeição relacionada ao PAA: Adiciona a seguinte regra de validação para barrar o uso do EPEC para os estados do PR e PB: De acordo com a NT, essa regra foi adicionada para atender ao Ajuste SINIEF Nº 25/2026. Datas Implantação Teste: 09/09/2026 Implantação Produção: 05/10/2026 E como fica o ACBr? Como a NT não traz nenhuma alteração de leiaute, não será necessário nenhuma modificação nos fontes do ACBr. Leia a versão 1.40 desta nota técnica na íntegra AQUI.

Conforme orientação do Juliomar, efetuei a abertura de um chamado na SEFA/PR e a resposta foi a seguinte. “Prezado(a) Sr(a), O sincronismo das notas, entre os ambientes estadual e nacional, ocorre através de um processo automatizado. Entretanto, esse processo teve problemas, no dia: 06/07/2026 e que já foi corrigido. Devido ao problema, acumulou-se uma fila (atraso) no processo automático - o que explica-se o fato da divergência entre os ambientes. Aos poucos, o processo automatizado, deverá consumir a fila. Entretanto, sem previsão para tal, devem aguardar Atenciosamente, Serviço de Atendimento ao Cidadão da Receita Estadual do Paraná”

Olá, comunidade ! No dia 14/07/2026, por volta das 9h49, começamos a receber relatos de membros da nossa comunidade com problemas na emissão de notas fiscais de serviço para o município de São Paulo. Os relatos informavam que, ao tentar se comunicar com o web service, era devolvido timeout. Realizando testes, o timeout foi constatado mesmo com um valor de 60 segundos configurado na propriedade de timeout do componente. Ao acessar a URL diretamente pelo navegador, a URL também apresentou lentidão. Buscando mais informações sobre o problema, ao acessar a página da Nota Fiscal Paulistana, foi observado o seguinte aviso informando manutenção programada para hoje:

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

Olá, comunidade ! Como muitos devem saber, a partir de 01/09/2026, todos os prestadores de serviço optantes pelo Simples Nacional deverão emitir suas notas fiscais de serviço eletrônicas diretamente pelo emissor nacional — também conhecido como Padrão Nacional — independentemente do município ao qual pertençam. Se você não sabe do que se trata, veja este tópico. Recebemos a informação de que o município de Guarulhos adiantou essa migração para o dia 01/07/2026. Portanto, desde essa data, todos os prestadores de serviço optantes pelo Simples Nacional do município devem realizar a emissão de suas NFS-e diretamente no Padrão Nacional. Veja no tópico abaixo o que é preciso alterar no ACBr para fazer isso: Um agradecimento a todos os membros da comunidade que compartilharam essa informação conosco em nosso fórum.

Foi adiado para 01/08/2026: Fonte: https://guarulhos.giss.com.br Atualização em 07/07/2026

Olá Pessoal, Foi implementado o provedor TaxTecnologia que trabalha com a versão 2.04 do layout da ABRASF no momento temos somente a cidade de Santa Izabel do Para/PA configurada. Caso alguém saiba de mais cidades atendidas pelo referido provedor favor criar um tópico informando as URLs de produção e homologação.

Olá, comunidade ! No dia 03/07/2026 foi publicada versão 1.40 da Nota Técnica 20214/002 que trata do serviço de DistribuiçãoDFe para a nota fiscal eletrônica. Alterações Essa versão adequa o serviço ao CNPJ alfanumérico alterando todas as ocorrências desse campo do tipo numérico para o tipo caracteres permitindo agora que o valor tenha além de números, letras também. Essa versão também adiciona o literal "transportador" no título da coluna que ilustra quais são os arquivos devolvidos para o participante identificado no evento de "Ator interessado" removendo assim quaisquer ambiguidades: Datas A implantação tanto em homologação quanto em produção ocorrerá na mesma data de 08/07/2026 E como fica o ACBr? As soluções ACBr já vem sendo adequadas ao CNPJ alfanumérico e o progresso desse processo pode ser conferido no tópico abaixo: Leia a versão 1.40 desta nota técnica na íntegra AQUI.

Sobre o ACBr Somos autoridade em PIX, TEF e Meios de Pagamentos integrados na sua aplicação O ACBr é Distribuidor de Diversos Produtos Financeiros que podem ser integrados ao seu PDV Temos condições exclusivas para os usuários do ACBr Pro, Confira o nosso curso completo, sobre TEF e Meios de Pagamentos Tenha acesso ao nosso Suporte, Demos e Cursos, inscrevendo-se nas páginas https://projetoacbr.com.br/tef/ Conheça nossa oferta de PIX integrado ao seu PDV, como monetização por transação https://projetoacbr.com.br/pix/

Olá comunidade ! Ao acessar o Portal da NF-e, é possível observar que a Sefaz de Minas Gerais está com contingência ativada desde às 7h00 do dia 01/07/2026, com previsão de permanecer ativada até às 09h10 do dia 01/07/2026 Para utilizar as soluções ACBr em contingência durante esse período siga as orientações do tópico:

Resolvido! if NFe.Ide.gPagAntecipado.refNFe.Count > 0 then RESOLVEU :)

Olá comunidade ! Foi publicada a versão 3.2.3 do Guia Prático EFD ICMS IPI com vigência a partir de Janeiro de 2027. Além de alterações em algumas regras de validação e preenchimentos, essa versão também traz as seguintes alterações no leiaute e nos tipos de alguns campos: Alteração do tipo dos campos CNPJ de N para C a partir do leiaute 2026, nos seguintes registros: 0000, 0100, 0150, C115, C175 e 1320. Alteração do tipo dos campos Chave de documento eletrônico de N para C a partir do leiaute 2026, nos seguintes registros: B020, C100, C113, C116, C176, C181, C186, C465, C500, C800, D100, D700, E113, E240, E313, E531, G130, 1105, 1110, 1210 e 1923. Inclusão do campo 09 (IND_BENEFICIO) nos registros C197, C597, D197 e D737. Inclusão do campo 05 (IND_BENEFICIO) nos registros E111, E220 e 1921. 5. Inclusão do campo 12 (COD_PROD) no registro C180. Inclusão de novos Código da Situação de Documento (09 e 10) na subseção 1.3 do capítulo IV 11. Alteração nas orientações do registro C100. Inclusão da Exceção nº 12 no registro C10. Inclusão de valores válidos (09 e 10) no campo 06 (COD_SIT) no registro C100. E como fica o ACBr? Foi criada a tarefa ACBR-9565 para avaliar as alterações realizar quais alterações que possam vir a ser necessárias no componente. Assim que houver novidade será divulgado aqui neste tópico. Veja o guia prático completo AQUI.

Visando maior padronização cadastral, simplificação operacional e integração plena entre os sistemas, a reforma tributária incluiu a previsão de inscrição no CNPJ por pessoas físicas para emissão de documentos fiscais que exijam o IBS e a CBS. Com o objetivo de garantir a adaptação adequada desses contribuintes, está sendo desenvolvido um sistema de simplificado de inscrição no CNPJ inspirado no modelo adotado atualmente pelo MEI. Levanto tudo isso em consideração, a Receita Federal e o Comitê Gestor do IBS e CBS optaram por prorrogar o prazo para adesão ao CNPJ por pessoa física decidindo que até 1º de janeiro de 2027: permanece autorizada a utilização dos atuais mecanismos de identificação fiscal aplicáveis às pessoas físicas; serão disponibilizados gradualmente os novos sistemas e orientações operacionais; serão conduzidas ações de comunicação e capacitação dos contribuintes; serão publicados atos normativos complementares; haverá disponibilização do sistema simplificado de inscrição no CNPJ em (novembro de 2026); será aberto ambiente de testes (sandbox) para adaptação dos emissores de documentos fiscais; e, serão divulgados manuais técnicos e orientações ao contribuinte. Este tópico foi baseado em notícia originalmente publicada AQUI.

Olá, comunidade ! Uma das dúvidas mais frequentes entre os usuários é saber se determinado município é compatível com as soluções de NFS-e do ACBr. Para facilitar essa consulta, disponibilizamos uma página onde é possível verificar, de forma rápida e prática, se o seu município é atendido. Basta acessar o link abaixo e informar o nome da cidade desejada: Consulta de cidades compatíveis com ACBr NFS-e Exemplos: Cidade atendida: Cidade não atendida: Contribua com a comunidade! Se o município consultado ainda não for atendido e você souber qual é o provedor utilizado, bem como as URLs dos Web Services, crie um tópico em nosso fórum informando esses dados. Essas informações nos ajudam a avaliar e implementar o suporte ao município. Caso o município ainda não esteja integrado e você tenha interesse em utilizar o ACBr, recomendamos entrar em contato com a prefeitura para obter informações sobre o provedor de NFS-e, as URLs dos serviços e a documentação técnica. Com esses dados, será muito mais fácil viabilizar a implementação do suporte.

Oi @Daniel Simoes... Matou na hora... Funcionou certinho. Grato Deixo abaixo, como referência, trecho do ACBrLib.ini: [PosPrinter] ArqLog= Modelo=1 Porta=USB PaginaDeCodigo=2 Colunas=48 ColunasFonteNormal=48 CortaPapel=1 TraduzirTags=1 IgnorarTags=0 TipoCorte=1 [PosPrinter_Logo] IgnorarLogo=0 KeyCode1=1 KeyCode2=0 FatorX=1 FatorY=1

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

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.

Suporte a DANFSe v2.0 (NT 008 SE/CGNFS-e) no motor FPDF Contexto / Motivação O leiaute do DANFSe para o Sistema Nacional NFS-e (Ambiente de Dados Nacional) mudou com a NT 008/SE-CGNFS-e — a versão anterior do ACBr.DANFSeX.FPDFA4Retrato (leiaute municipal/ABRASF) não é compatível com o layout exigido para proPadraoNacional. Este PR adiciona um renderer dedicado, no mesmo motor de relatórios (ACBr_fpdf_report/ACBr_fpdf_ext), sem introduzir dependência de bibliotecas de terceiros. Escopo Arquivo novo: Componentes/ACBr/Fontes/ACBrDFe/ACBrNFSeX/DANFSE/FPDF/ACBr.DANFSeX.FPDFPadraoNacional.pas Nova classe TACBrDANFSeFPDFPadraoNacional = class(TFPDFReport), ~1600 linhas. Segue a mesma convenção arquitetural de TACBrDANFSeFPDFA4Retrato (construtor Create(ANFSe: TNFSe), SalvarPDF overloads), mas com um pipeline de bandas (AddBand) próprio, mapeado 1:1 ao Anexo I da NT 008. Arquivos alterados: ACBrNFSeXDANFSeFPDFClass.pas — ExecutaImpressaoPDFUmaNFSe passa a bifurcar por Configuracoes.Geral.Provedor = proPadraoNacional, delegando para o novo renderer; demais provedores continuam no TACBrDANFSeFPDFA4Retrato (comportamento preservado, zero mudança de rota para quem já usa o leiaute municipal). Pacotes/Delphi/ACBrDFe/ACBrNFSeX/DANFSE/FPDF/ACBr_NFSeXDanfseFPDF.dpk — adicionada a unit nova ao contains. Decisões de design relevantes para revisão 1. Grade de campos sem bordas verticais (fidelidade ao gerador oficial) O PDF gerado pelo Sefin Nacional não desenha grade por célula — só linhas horizontais nos limites de bloco (btPageHeader a btPageHeader) e preenchimento cinza claro (5% K) na célula-título, sem traço vertical algum entre colunas (validado extraindo os page.get_drawings() de um PDF de referência real via PyMuPDF: 22 operações vetoriais na página inteira). A implementação original deste PR desenhava uma TFPDF.Rect completa por campo (~800 operações/página). Foi refeita para reproduzir o padrão oficial: DesenharCampo não desenha borda nenhuma (só preenchimento quando Sombreado=True); um único DesenharLinhaSeparadora (uma PDF.Line horizontal) fecha cada bloco. Cuidado de ordem de desenho: a linha separadora é emitida depois do preenchimento cinza do título de bloco (não antes) — como ambos ocupam Y=0 do banda, desenhar a linha primeiro faz o fill cinza pintar por cima e apagá-la. Resultado final: 24 operações/página (a diferença de 2 vs. o oficial é só o modo de desenho do próprio QR Code, ver item 4). 2. Motor de bandas (TFPDFReport/AddBand) Confirmado por leitura de ACBr_fpdf_report.pas: a altura passada a AddBand é a declarada, não a real desenhada — usada pelo motor para posicionar a próxima banda (DrawBand). Cada CalcAltura* precisa bater exatamente com o que o Banda* correspondente desenha, senão sobra/falta espaço entre blocos. btPageFooter ancora sempre no rodapé da página independente do conteúdo acima (DrawLastBands) — por isso todos os blocos fluem em btPageHeader (sequencial) exceto Informações Complementares (btData, altura dinâmica = espaço livre) e Canhoto (btPageFooter, fixo no rodapé), replicando o comportamento observado no gerador oficial (Informações Complementares estica até o Canhoto). 3. Logomarca — sem asset embutido, seguindo convenção já usada no ACBr LogoNFSe: string (caminho de arquivo ou conteúdo binário bruto) — mesmo nome/tipo já declarado em TACBrNFSeXDANFSeClass.LogoNFSe e mesma semântica de TDFeReportFortes.CarregarLogo (usado por NFe/CTe/MDFe/NF3e/NFCom). Sem valor padrão embutido: se vazio, o espaço do cabeçalho fica em branco. 4. QR Code Conteúdo montado a partir de cURLConsultaPublica + ChaveDeAcesso — TNFSe.Link não é preenchido pelo parser do Padrão Nacional (PadraoNacional.LerXml.pas), então o gate de exibição usa infNFSe.ID/ChaveAcesso, não Link. Desenhado via PDF.QRCode (módulo a módulo, retângulos vetoriais pretos) — diferente do PDF oficial, que parece embutir o QR como imagem rasterizada única. Funcionalmente equivalente (QR válido, testado com leitor), mas gera ~700 operações vetoriais extras por página; não normalizado neste PR — encaminhar como possível otimização futura se ACBr_fpdf_ext ganhar suporte a inserir QR como imagem. 5. Mapeamento de fontes NT 008 item 2.4 exige Arial (labels) e Microsoft Sans Serif (conteúdo) — nenhuma é fonte core do FPDF. Mapeadas para 'Arial' (alias interno resolvido para Helvetica core) até que TTFs sejam embarcadas via AddFont. Sinalizar para revisão: isso é uma aproximação visual, não 100% NT-008-literal; embarcar as TTFs certas teria implicação de licenciamento a avaliar antes. 6. Campos dinâmicos por bloco (Tomador/Destinatário/Intermediário/Tributação Municipal) Cada bloco tem duas formas de renderização: grade completa (quando há dado) ou uma única linha "vazia" central (DesenharLinhaVazia, sem grade, mensagem fixa conforme NT 008 itens 2.3/2.5 — ex. TOMADOR/ADQUIRENTE DA OPERACAO NAO IDENTIFICADO NA NFS-e), replicando o padrão do gerador oficial para blocos suprimidos. Exemplo de uso: program ExemploDANFSeComLogo; {$APPTYPE CONSOLE} uses SysUtils, Classes, ACBrNFSeX, ACBrNFSeXConversao, ACBrNFSeXDANFSeFPDFClass, ACBrNFSeXClass; var iNFSe: TACBrNFSeX; DANFSeFPDF: TACBrNFSeXDANFSeFPDF; begin iNFSe := TACBrNFSeX.Create(nil); DANFSeFPDF := TACBrNFSeXDANFSeFPDF.Create(nil); try iNFSe.DANFSE := DANFSeFPDF; iNFSe.SetProvedor(proPadraoNacional); // LogoNFSe e' herdada de TACBrNFSeXDANFSeClass (mesma propriedade usada // por NFe/CTe/MDFe/etc via TDFeReportFortes.CarregarLogo) - aceita // caminho de arquivo... DANFSeFPDF.LogoNFSe := 'C:\CargoPro\Recursos\logo-nfse-horizontal.png'; // ...ou, se preferir nao depender de um arquivo solto no disco, o // conteudo binario da imagem direto na string (ver CarregarLogoNFSeBytes // em ACBr.DANFSeX.FPDFPadraoNacional.pas: se FileExists falhar, o valor // e' tratado como o proprio conteudo do arquivo, nao um caminho): // // var // LogoBytes: TBytes; // begin // TFile.ReadAllBytes(...) ou carregar de um resource (RCDATA) do exe; // DANFSeFPDF.LogoNFSe := TEncoding.ANSI.GetString(LogoBytes); // cuidado com encoding, ver nota abaixo iNFSe.NotasFiscais.Clear; iNFSe.NotasFiscais.LoadFromFile('C:\CargoPro\exemplos\nfse\minha-nota.xml'); DANFSeFPDF.PathPDF := 'C:\CargoPro\Saida'; DANFSeFPDF.Sistema := 'CargoPro'; DANFSeFPDF.ImprimirDANFSe; WriteLn('OK -> ', DANFSeFPDF.ArquivoPDF); finally DANFSeFPDF.Free; iNFSe.Free; end; end. ACBrNFSeXDANFSeFPDFClass.pas ACBr.DANFSeX.FPDFPadraoNacional.pas ACBr_NFSeXDanfseFPDF.dpk

Olá, comunidade ! Conferindo em NFCePortal às 15h46, é possível observar que o EPEC se encontra ativado: Essa ativação é feita pela Sefaz e isso confirma que o problema está ocorrendo do lado da Sefaz de São Paulo. Veja o tópico abaixo para mais informações sobre o EPEC:

Foi publicada a versão 26.1.L das tabelas fornecidas pelo IBPT, às quais já se encontram também em nosso SVN. As novas tabelas tem a vigência de 20/06/2026 até 31/07/2026. Para cumprimento da Lei 12.741/12, também conhecida como "De Olho no Imposto", não se esqueça de realizar a atualização de seus clientes. Fonte: De Olho no Imposto

Ola pessoal. Atualizei os componentes e meu cliente veio questionar sobre impressão da DANFSe saindo em duas páginas(canhoto na segunda página). Não encontrei configurações para realizar ajustes Também encontrei alguns pontos que ao abrir o PDF estava ok, mas ao imprimir não respeitava os caracteres. E alguns campos não estavam bem alinhados. Realizei uma alteração no fonte, onde ajusto campo a campo o top, realizando o calculo. (Ajustar campo a campo na mão é muito difícil) Com o ajustes eu consegui imprimir um DANFSe com 4 linhas de serviço sem a necessidade de gerar a página 2. Anexo o fonte. Obrigado. ACBrNFSeXDANFSeRLPadraoNacional.pas

Olá pessoal, Uma pergunta que temos recebido muito é sobre se o ACBr já está preparado para o CNPJ alfanumérico. Nosso time esta atuando de forma a atualizar nossas soluções para este novo cenário, e alguns componentes já foram atualizados e outros estão em andamento. É importante salientar que ainda não temos CNPJs ativos neste novo formato, e que de forma geral, diversos setores que fazem parte deste processo seguem se ajustando para que de fato exista uma empresa ativa com CNPJ neste formato. Outro fator relevante é que nem todos os schemas atualizados foram disponibilizados pelas SEFAZ, oque impede a utilização desse novo formato para tais documentos. Seguiremos atualizando este artigo conforme as soluções forem ajustadas. Soluções já Atualizadas ACBrBPe ACBrBoleto ACBrCTe (Componente ajustado e DACTE em andamento) ACBrNFCom (Componente ajustado e DANFE-COM em andamento) ACBrValidador ACBrNFe / ACBrNFCe (Componente ajustado e DANFE em andamento) ACBrDCe (Componente ajustado e DANFE em andamento) ACBreSocial ACBrMDFe (Componente ajustado e DANFE em andamento) ACBrGNRe ACBrPixCD ACBrReinf ACBrANe ACBrCIOT ACBrDI ACBrONE As demais soluções serão tratadas conforme disponibilidade de agenda do nosso time, com foco em entregar o mais breve possível. "Após cada componente ser atualizado as ACBrLib correspondentes e o ACBrMonitor também estarão atualizados em sua próxima versão." Lembre-se que além das Soluções ACBr, os principais impactos do CNPJ Alfanumérico em sua aplicação pode ocorrem em: Telas de entrada de dados: campos e máscaras que aceitam apenas números. Banco de dados: campos definidos como numéricos e validações no banco. Validação de CNPJ: regras próprias, expressões regulares e bibliotecas de terceiros. (ACBrValidador já está adequado) Integrações: APIs, WebServices, arquivos TXT, CSV e XML que esperam apenas dígitos. Importação e exportação de dados: planilhas e processos de migração. Relatórios e documentos: campos formatados como número. Código-fonte: rotinas que utilizam conversões numéricas (StrToInt, IsNumeric, etc.).

Olá comunidade ! Foi publicada a versão 1.50 da nota técnica 2025/002 trazendo uma reformulação do layout da tributação monofásica de combustíveis e regras de validação. Alterações O grupo gIBSCBSMono, gMonoPadrao, gMonoRet e gMonoDif foram removidos. Agora os novos grupos dividem as informações em ad rem e ad valorem. A nova estrutura agora é: gIBSCBSMono gIBSMonoAdRem (CG) gMonoPadrao gMonoReten gMonoRet gpBioDiferenca gIBSMonoAdValorem (CG) gMonoPadrao gMonoReten gMonoRet gpBioDiferenca gCBSMonoAdRem (CG) gMonoPadrao gMonoReten gMonoRet gpBioDiferenca gCBSMonoAdValorem (CG) gMonoPadrao gMonoReten gMonoRet gpBioDiferenca Remove a regra de validação que devolvia a rejeição "1057 - Finalidade da NFe informada incorretamente para esta Classificação Tributária do IBS e da CBS". Adiciona novas regras de validação para os novos grupos de monofasia adicionados. Datas Implantação Teste: 01/09/2026 Implantação Produção: 03/11/2026 Vale ressaltar que apesar da publicação da NT e das datas definidas na mesma, até a publicação deste tópico ainda não foram disponibilizados novos schemas correspondentes as alterações de layout mencionadas. E como fica o ACBr? Alterações nas soluções ACBr serão necessárias. Foi criada a tarefa ACBR-9462 para adequar o componente. Qualquer novidade será divulgada neste tópico. Leia a versão 1.50 desta nota técnica na íntegra AQUI.

Bom dia. Implementado novo método para inativar produtos na IMendes. Para que serve? Vamos imaginar que você fez a consulta de alterados na IMendes, hoje a mesma retorna todas as vezes os alterados durante 45 dias, mas vamos imaginar que você não queira que eles fiquem retornando essa lista completa pois você já sincronizou esse status em seu sistema? Por isso solicitei a implementação desse método por parte de IMendes e já implementei no ACBr juntamente com as demais alterações acima citadas. Espero ter ajudado e no aguardo do merge para a versão oficial. Ps: Rodrigo Fruwhirth - Arpa Sistemas. ACBrIMendes.pas Respondendo ao amigo, assim que o ACBr fizer o merge dos fontes, todas as operações com a IMendes já estão implementas no componente. Caso não queira aguardar, pode pegar o fonte acima e substituir na pasta Fontes\ACBrTCP o arquivo em questão. Espero ter ajudado. Att: Rodrigo Fruhwirth - Arpa Sistemas. ACBrIMendes.pas

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