Painel de líderes

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.

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.

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!!!

@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:

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.

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.

Olá pessoal! Reportando que o comportamento mencionado anteriormente ainda persiste testando depois das 17h do dia 16/07/2026

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á pessoal, Foram disponibilizados na Rev-47223 os programas de exemplo em PHP, Singlethread e Multithread utilizando a ACBrLibCIOT. ..\ACBr\Projetos\ACBrLib\Demos\PHP\CIOT\ACBrCIOTDemoST.php ..\ACBr\Projetos\ACBrLib\Demos\PHP\CIOT\ACBrCIOTDemoMT.php Lembrando que os programas de exemplo em php utilizam a ACBrComum.php que contém métodos em comum entre os modos (ST e MT) e para todas as libs. ..\ACBr\Projetos\ACBrLib\Demos\PHP\ACBrComum\ACBrComum.php Até mais!!!

ACBrBPe é atualizado: fim da dependência da PCN e novas units para a Reforma Tributária O componente ACBrBPe passou por mudanças estruturais importantes — a remoção da dependência das units da PCN e a adoção de units específicas da Reforma Tributária. Confira o que muda no seu código. Resumo da atualização: O ACBrBPe não depende mais de nenhuma unit da PCN Quatro tipos de propriedades foram renomeados (veja tabela abaixo) A função StrToTpAmb foi substituída por StrToTipoAmbiente Todos os novos tipos e funções de conversão agora estão centralizados em ACBrDFe.Conversao O componente passou a utilizar units específicas da Reforma Tributária, reduzindo a quantidade de código Um episódio do Papo PRO ACBr detalha essas novas units da Reforma Tributária O que mudou no ACBrBPe O componente ACBrBPe (Bilhete de Passagem Eletrônico) deixou de utilizar qualquer unit da PCN. Como consequência direta dessa mudança estrutural, alguns tipos de propriedades precisaram ser substituídos por equivalentes próprios do ACBr. Tipos e funções renomeados Se o seu projeto utiliza o ACBrBPe, é necessário ajustar as referências aos tipos abaixo: Antes Agora TpcnTpEvento TACBrTipoEvento TTipoEmissao TACBrTipoEmissao TpcnTipoAmbiente TACBrTipoAmbiente TpcnTipoImpressao TACBrTipoImpressao StrToTpAmb (função) StrToTipoAmbiente (função) Todos esses tipos e funções de conversão agora estão declarados na unit ACBrDFe.Conversao. Um exemplo de ajuste no código seria: uses ACBrDFe.Conversao; var TipoAmbiente: TACBrTipoAmbiente; begin TipoAmbiente := StrToTipoAmbiente('1'); end; Quem mantém código legado com os tipos antigos deve atualizar as referências antes de compilar novas versões do componente. Units específicas da Reforma Tributária Além da limpeza de dependências, o ACBrBPe passou a utilizar units específicas voltadas à Reforma Tributária, o que reduziu significativamente o código interno do componente. Essa é uma frente que o ACBr vem consolidando em diversos componentes fiscais, padronizando o tratamento de IBS, CBS e demais exigências da nova legislação tributária. Para entender em detalhes como essas novas units funcionam e o que elas representam para o ecossistema ACBr, o episódio do Papo PRO ACBr disponível no Spotify traz uma explicação completa sobre o tema. Encontrou algum problema? Alterações estruturais como essa podem impactar projetos em produção. Caso identifique qualquer inconsistência após a atualização do ACBrBPe, é fundamental abrir um tópico específico descrevendo o problema encontrado, para que a equipe possa avaliar e corrigir rapidamente. Ficar por dentro dessas mudanças é essencial para manter seus sistemas fiscais sempre compatíveis com as últimas exigências — inclusive as da Reforma Tributária. Quer contar com suporte especializado, atualizações prioritárias e acesso a conteúdos como o Papo PRO ACBr? Conheça o ACBr PRO e simplifique a manutenção dos seus componentes fiscais. Fonte oficial: Comunicado da equipe de desenvolvimento do projeto ACBr sobre a atualização do componente ACBrBPe. Saiba mais no episódio do Papo PRO ACBr:

Boa tarde Gostaria de solicitar a atualização do arquivo "PadraoNacional.GravarXml.pas", da pasta "\Fontes\ACBrDFe\ACBrNFSeX\Provedores", para o Trunk do projeto A mudança consiste em mover o bloco responsável pela escrita da tag "tpRetPisCofins", parte da hierarquia "NFSe/infNFSe/DPS/infDPS/valores/trib/tribFed/piscofins/" Para fora da condição "if not (NFSe.Servico.Valores.tribFed.CST in [cst00, cst08, cst09]) then", resultando em: Isso se deve em função de cenários específicos em que há PIS e COFINS retidos. Mais especificamente, são situações em que é preciso indicar o valor das retenções de PIS/COFINS/CSLL na tag "vRetCSLL" que como indicado na versão 1.03.00 do Anexo VI da NFSe, ele representa a soma das retenções de acordo com o indicado na tag "tpRetPisCofins". Por exemplo, quando utiliza-se o tipo "3 - PIS/COFINS/CSLL" retidos, torna-se necessário indicar a tag "tpRetPisCofins" com o valor "3" e o campo "CST" com o valor "00 - Nenhum" pois não há um valor de PIS e COFINS de apuração própria para ser usado o CST "01 - Operação Tributável com Alíquota Básica" e preenchidos os demais campos (vBCPisCofins, pAliqPis, pAliqCofins, vPis e vCofins) O entendimento de que os campos "vPis" e "vCofins" não devem ser usados em casos de retenção, vem do texto que faz parte da Nota Técnica SE/CGNFS-e nº 007 (https://www.gov.br/nfse/pt-br/biblioteca/documentacao-tecnica/rtc/nt-007-se-cgnfse-v1-0.pdf), transcrito abaixo e que indica claramente a distinção entre os valores de PIS e COFINS retidos e de apuração própria Então ao manter a geração da tag "pRetPisCofins" como parte da condição "if not (NFSe.Servico.Valores.tribFed.CST in [cst00, cst08, cst09]) then" isso impede que seja usada a retenção de PIS e COFINS com o CST "00 - Nenhum" para o PIS/COFINS Abaixo está a imagem do anexo VI da NFSe (versão 1.03.00 atualizado pela Nota Técnica SE/CGNFS-e nº 007) para facilitar a correlação com as tags que descrevi nos dois parágrafos acima Eu realizei essa alteração que descrevi e pude autorizar uma nota em ambiente de produção do serviço nacional, então posso confirmar que, no presente momento, ela é permitida. Em anexo está o arquivo fonte alterado a partir da revisão 47144, mas se preferir alterar manualmente, basta fazer a cópia da linha referente ao "tpRetPisCofins" que descrevi no começo do tópico PadraoNacional.GravarXml.pas

Boa tarde, Foi criada a tarefa ACBR-9637 para avaliação. Obrigada pela contribuição!

Muito obrigado @marcosvillatore... @Daniel InfoCotidiano, acho que você está com essa tarefa, correto ?

@leomcl Creio que o ideal seria aguardar os schemas atualizados, pois devem estar aptos aos cnpjs alfanuméricos. Vi que disponibilizaram dia 10/07, vou fazer um teste aqui. Att.

Tarefa ACBR-9423 concluída e no SVN.

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

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);

Atualizei vários métodos da IMendes, bem como o ambiente de homologação. Ajustado a inclusão de diversos atributos faltantes, atributos esses que retornam no JSON porém não se encontram no manual, ex: Baixa_Similaridade e retornados do método saneamento. Adicionado método remove devolvidos. Ajustado classe ACBrImendesProdutos para herdar de ACBrImendesProdutosID para reaproveitar em produtosDevolvidos. Esses produtos devolvidos são retornados na consulta do histórico. No histórico adicionei os produtosDevolvidos. ACBrImendesCliente adicionei: idSistema e TipoLicenca Iniciei o grupo de IS porém, esse ainda a IMendes não retorna, darei sequencia quando tiver resultados eficientes. fMunicipio da classe TACBrIMendesGrupoCaracTrib estava como Integer, porém a IMendes retorna o nome do município que é String. Adicionado em TACBrIMendesGrupo ProCodInterno para as consultas que não são por EAN, esses itens no saneamento retornam como Aguardando Analise e quando os mesmos são retornados retornam em outro grupo. No Saneamento adicionado os grupos: SemRetorno e BaixaSimilaridade. No método ConsultarDescricao adicionado o tipo da Consulta conforme manual. Adicionado RemoveDevolvidos conforme manual de integração. Em ValidarConfiguracao ajustei mensagem de erro incompatível: if EstaVazio(fCNPJ) then wErro.Add('- Email'); por if EstaVazio(fCNPJ) then wErro.Add('- CNPJ'); No método Autenticar a URL estava errada. SaneamentoGrades removido Warning de Value assigned but never used: Result := False; e nos demais métodos que iniciavam com isso, também ajustei. Adicionei o registrar log nas resposta para cumprir roteiro de homologação. ACBrIMendes.pas

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

O município de São Paulo /SP está como NÃO na parte de adesão(emissão direta pelo padrão), como havia lhe perguntado antes.. Para esse município, você Irá continuar emitindo com o layout de provedor, só precisa passar os campos da Reforma Tributária igual, se os schemas do seu provedor já estiverem adequados a isso. De novo... Para esse município, você precisa continuar enviando a NFSe pelo provedor. Deverá somente preencher as tags NFSe.IBSCBS

Bom dia, qual município está querendo emitir a NFSe? Enquanto o municípo não estitiver na condição a baixo, vai precisar emitir sempre como o provedor. Somente funciona emitir nfse pelo padrão nacional se o municipio já estiver cadastrado completamente lá. Seu municipio vai continuar recebendo as nfse e eles transmitindo para o padrão nacional ? Se for o caso, você vai continuar a emitir pelo provedor, só precisa passar os campos que a prefeitura necessitar Segue link para verificar como está os status do municipios em relação a emissão direta pelo padrão nacional: https://app.powerbi.com/view?r=eyJrIjoiNGQ4YTcxNmMtMzdhNC00Mzc5LTllM2EtMjY1MTM3NWQyZDgyIiwidCI6IjZmNDlhYTQzLTgyMmEtNGMyMC05NjcwLWRiNzcwMGJmMWViMCJ9&pageName=608609c2e0a53d7a3c6e Se na aba "Adesão ao emissor Nacional da NFSe*" Estiver aparecendo SIM este municipio pode comunicar diretamente com o padrão nacional(eu estou configurando da seguinte forma): ACBrNFSeX1.Configuracoes.Geral.LayoutNFSe := lnfsPadraoNacionalv101; ACBrNFSeX1.Configuracoes.Geral.Versao := ve101; ACBrNFSeX1.Configuracoes.Geral.CodigoMunicipio := CodIBGE; Se na aba estiver NÃO então precisa emitir via Provedor, como antigamente.. a própria ACBR passa/pega o provedor necessário, de acordo com o municipio do emitente: ACBrNFSeX1.Configuracoes.Geral.LayoutNFSe := lnfsProvedor; ACBrNFSeX1.Configuracoes.Geral.CodigoMunicipio := CodIBGE;

Muito obrigado pela contribuição @Leonardo Gregianin @Alexandre de Paula, creio que já temos uma tarefa para essa finalidade... Essa contribuição irá nos ajudar muito

A Origem do problema está nessa função Correção em Azul: function TNFeXmlReader.ObterConteudo(const ANode: TACBrXmlNode; const Tipo: TACBrTipoCampo): variant; begin Result := inherited ObterConteudo(ANode, Tipo); if Tipo in [tcStr] then Result := ParseText(Result) else if Tipo in [tcEsp, tcStrOrig] then Result := ParseText(Result, False); end;

Olá comunidade ! Foi publicado no dia 14/07/2026 a versão 1.02 da Nota Técnica Nº008 trazendo novas alterações no leiaute do DANFSe e prorrogando novamente o prazo. Alterações Foi adicionada uma observação informando que para os casos que o conteúdo do campo seja maior do que o tamanho definido, pode ser utilizado reticências para identificar continuidade do conteúdo. Adiciona na seção que recebe as informações da tributação federal as novas informações: CONTRIBUIÇÕES SOCIAIS - RETIDAS PIS - DÉBITO APURAÇÃO PRÓPRIA COFINS - DÉBITO APURAÇÃO PRÓPRIA Datas A API do ambiente nacional que gera o PDF do DANFSe será desativada no dia 03/08/2026. E como fica o ACBr? As alterações propostas já foram adotadas no leiaute do Fortes Report e serão aplicadas nos demais assim que possível. Leia a versão 1.02 desta nota técnica na íntegra AQUI.

Olá comunidade ! Ao acessar a página da documentação da NFS-e Nacional, no dia 15/07/2026, haviam novas observações detalhando um pouco mais o cronograma dessa NT:

Boa tarde. Só para registro, segue resposta da SEFAZ no chamado que eu havia criado semana passada, onde confirmam que o problema era do lado deles. att, Leandro

Li só o título, não vi a qual grupo se referia

Sim muito bom esta padronização, valeu por compartilhar. Este inclusive é um topico bem antigo, você pode encerrar até, hoje por exemplo já nem estou usando nenhum tipo de impressão mais customizada, todas que estou usando é a que vocês disponibilizaram no padrão nacional, mesmo sendo ainda provedor proprio digamos.

está correta. é esse mesmo

Olá, pessoal! Apenas reportando que, em testes realizados no dia 14/07/2026 após as 15h19, o comportamento reportado na primeira postagem ainda permanece: A Sefaz ainda está autorizando o evento 211120, que deveria ter sido removido. A Sefaz ainda está autorizando o evento 211110 no leiaute antigo. A Sefaz está rejeitando o novo leiaute proposto pela NT 2025/002 v1.40, apontando estrutura de XML inválida com o elemento gCredPresOper.

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

pode me chamar no whatsapp 51985175256

Bom dia, @ANDERSSON CARLOS CANDIDO! No momento, não temos uma previsão. A tarefa está no backlog e, em breve, deve ser adicionada a alguma sprint para ser analisada.

Bom dia, Eu não utilizo o AcbrMonitor, então inspeciono o retorno do provedor. Se a tag <DescricaoProcesso> presente no XML de retorno (prop <acbrNfseX>.WebService.Emite.XmlRetorno) contém "Requisicao finalizada. Favor aguardar o retorno da Sefin/ADN para impressao da NFS-e: xxxx" presumo que foi autorizada. O provedor demanda alguns segundos (ou minutos) para integrar com o Ambiente Nacional, e somente uma consulta posterior para obter o XML completo, contendo número e chave da NFSe Nacional.

Tarefa ACBR-9423 já no SVN.

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

Ainda não foi disponibilizado .está sendo implementado e testado

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.

Olá, bom dia! Conferi na Planilha do leiaute de Padrão Nacional "RN DPS - RTC_IBSCBS"... certo, não há tags de alíquotas e valores. De acordo com essa definição e aplicação em leiaute, subentende-se que neste ano teste 2026 as tags de DPS não levarão grupo/tags referente a alíquotas e valores pois estão definidas fixas (IBS 0,1% & CBS 0,9%). Levantando um questionamento, não encontrei material sobre... A partir de 2027, quando as alíquotas serão alteradas e ajustadas conforme novas definições e poderão ser diferentes entre Estados e/ou Municípios (se tratando de IBS) poderão ser implementadas novas tags de alíquotas e valores a serem configurados pelos usuários em seus sistemas, ou se manterão fixos de acordo com as localidades preenchidos/calculados pelo XML de retorno/aprovação?

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.

Erro: Uma chamada para a função PInvoke desbalanceou a pilha. Possível causa do problema: As bibliotecas ACBrLib além de versões Single Thread e Multi Thread também são compiladas considerando a convenção de chamada da linguagem que vai utiliza-lá. Está convenções de chamada são StdCall e Cdecl. Este erro ocorre quando você está utilizando uma ACBrLib com a convenção de chamada diferente das utilizadas pelas classes. Como resolver: Quando você faz o download da ACBrLib, você vai encontrar as convenções de chamada diferentes: Por padrão, os exemplos do C#, Java e VB6 fazem uso da convenção Cdecl: Certifique-se de que esteja utilizando a dll da convenção de chamada correta. Neste exemplo eu devo utilizar a Cdecl ou alterar na classe para que use StdCall como convenção de chamada para que possa usar a dll correspondente.