Painel de líderes

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:

está correta. é esse mesmo

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á, 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.

Pessoal, Durante uma análise de consumo de memória na carga de certificados PFX, identifiquei um possível memory leak (na prática, vazamento de handle de HCERTSTORE) no arquivo ACBrDFeWinCrypt.pas, no método TDFeWinCrypt.CarregarCertificadoDeDadosPFX. O problema ocorre porque o método chama OpenSystemStore, que abre uma store e atribui seu handle a FpStore. Em seguida, a chamada a PFXDataToCertContextWinApi sobrescreve esse mesmo handle (passado por var) com o retorno de PFXImportCertStore, sem que a store anteriormente aberta seja fechada. Com isso, a cada carga de um certificado PFX, um handle de store permanece aberto. Realizei a seguinte alteração para evitar o vazamento: procedure TDFeWinCrypt.CarregarCertificadoDeDadosPFX; begin - OpenSystemStore; + { Não abre mais a Store do sistema neste caminho: o handle aberto por + "OpenSystemStore" era sobrescrito por "PFXImportCertStore" dentro de + "PFXDataToCertContextWinApi" (parâmetro var) sem nunca ser fechado, + ocasionando vazamento de um handle de store por carga de certificado PFX. } + if Assigned(FpStore) then + begin + CertCloseStore(FpStore, CERT_CLOSE_STORE_CHECK_FLAG); + FpStore := Nil; + end; + PFXDataToCertContextWinApi( FpDFeSSL.DadosPFX, FpDFeSSL.Senha, FpStore, Pelos testes realizados, a alteração elimina o vazamento sem impactar o carregamento do certificado PFX, já que PFXDataToCertContextWinApi é responsável por importar e inicializar a store que será utilizada posteriormente. Deixei em anexo o arquivo atualizado para analise, mas pode ser que ele não esteja atualizado com a ultima versão do arquivo completo. Ms é possível verificar o trecho mencionado. Gostaria da avaliação da equipe para verificar se essa correção faz sentido e, caso esteja de acordo, possa ser incorporada ao projeto. ACBrDFeWinCrypt.pas

Bom Dia, @Alexandre de Paula, @Juliomar Marchetti Já peguei a alteração na revisão está ok, não tinha visto essa função OnlyCPFCNPJAlphaNum. Pode fechar a thread. Obrigado.

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:

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

muito obrigado, resolveu o erro então era realmente DLL desatualizada mas ainda tive um novo erro. vou continuar aqui para ver se descubro mas desde já muito obrigado pelo auxilio. O erro foi este baixo: Erro(s): Código : X999 Mensagem: Erro de Conexão: EndTag: '</' not found Correção: ---------

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

Prezado(a)s! Referente á Resolução CGSN nº 189/2026, publicada agora no dia 28/04/2026. A Resolução CGSN nº 189/2026 determina que, a partir de 01/09/2026, as Microempresas (ME) e Empresas de Pequeno Porte (EPP) optantes pelo Simples Nacional deverão emitir a NFS-e no padrão nacional, obrigatoriamente pelo Emissor Nacional, seja via portal web ou integração direta por API. Em consulta via e-mail à Prefeitura de Bauru, fui informado que essa mudança realmente ocorrerá a partir de 01/09/2026, conforme imagem abaixo, porém, o ambiente Nacional informa e rejeita notas de testes informando que a Prefeitura de Bauru não efetuou o seu credenciamento para emitir notas diretamente pelo Portal. A rejeição do Padrão Nacional é: Questionei novamente a Prefeitura de Bauru para saber se existe previsão disso, e na resposta obtida informaram que não possuem maiores informações. Gostaria de saber se alguma outra empresa de software está ciente disso e buscando as devidas soluções, qual seria o caminho a seguir nesse momento, pois estamos com pouco tempo disponível para testar e colocar isso em funcionamento antes da virada de 01/09/2026. @marcelorband , @andreegui, @gkenji, @ZANUTTO, @willians.wsac

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.