Painel de líderes

Olá comunidade ! No dia 04/02/2026 foi publicada a nota técnica 2026/001 para a NFCom trazendo informações sobre a vinculação de pagamentos ao DFe. Essa vinculação se faz necessária para que o processo de Split Payment Inteligente seja executado. É importante ressaltar que o vínculo indicado pelo contribuinte não necessariamente representa um pagamento efetuado e liquidado. Indica uma expectativa de pagamento que pode ou não se concretizar. Por exemplo: um boleto pode ser emitido e não pago. Alterações Adiciona na NFCom um "Grupo de informações da vinculação com a transação de pagamento" com a seguinte estrutura: <pgtoVinc> <pgto> <nPag></nPag> <idTransacao></idTransacao> <tpMeioPgto></tpMeioPgto> <CNPJReceb></CNPJReceb> <CNPJBasePSP></CNPJBasePSP> </pgto> </pgtoVinc> Cria o "evento de vinculação da transação de pagamento com o DFe - 110300" com estrutura semelhante ao grupo da vinculação e seu respectivo evento de cancelamento. Adiciona regras de validações para os novos campos e para o evento. Datas Implantação Homologação: 06/04/2026 Implantação Produção: 04/05/2026 E como fica o ACBr? Modificações no ACBr serão necessárias para atender a esta nota técnica. Foi criada a tarefa ACBR-8939 para a adequação das soluções ACBr. Leia a nota técnica na íntegra AQUI.

Olá comunidade ! No dia 04/02/2026 foi publicada a nota técnica 2026/001 para a NF3e trazendo informações sobre a vinculação de pagamentos ao DFe. Essa vinculação se faz necessária para que o processo de Split Payment Inteligente seja executado. É importante ressaltar que o vínculo indicado pelo contribuinte não necessariamente representa um pagamento efetuado e liquidado. Indica uma expectativa de pagamento que pode ou não se concretizar. Por exemplo: um boleto pode ser emitido e não pago. Alterações Adiciona na NF3e um "Grupo de informações da vinculação com a transação de pagamento" com a seguinte estrutura: <pgtoVinc> <pgto> <nPag></nPag> <idTransacao></idTransacao> <tpMeioPgto></tpMeioPgto> <CNPJReceb></CNPJReceb> <CNPJBasePSP></CNPJBasePSP> </pgto> </pgtoVinc> Cria o "evento de vinculação da transação de pagamento com o DFe - 110300" com estrutura semelhante ao grupo da vinculação e seu respectivo evento de cancelamento. Adiciona regras de validações para os novos campos e para o evento. Datas Implantação Homologação: 06/04/2026 Implantação Produção: 04/05/2026 E como fica o ACBr? Modificações no ACBr serão necessárias para atender a esta nota técnica. Foi criada a tarefa ACBR-8940 para a adequação das soluções ACBr. Leia a nota técnica na íntegra AQUI.

Descrição do problema Foi identificado um problema recorrente na transmissão e recuperação de XML (e conteúdos textuais retornados, inclusive estruturas convertidas para XLS/relatórios) no NFSeX – Provedor Nacional, onde ocorre erro de acentuação e corrupção de caracteres. <infNFSe Id="NFS41282032204580454000130000000000002626012373413140"> <xLocEmi>Uni?o da Vit?ria</xLocEmi> <xLocPrestacao>Uni?o da Vit?ria</xLocPrestacao> <nNFSe>26</nNFSe> <infNFSe Id="NFS41282032204580454000130000000000002626012373413140"> <xLocEmi>Uni?o da Vit?ria</xLocEmi> <xLocPrestacao>Uni?o da Vit?ria</xLocPrestacao> <nNFSe>26</nNFSe> <xTribNac> Lubrifica??o, limpeza, lustra??o, revis?o, carga e recarga, conserto, restaura??o, blindagem, manuten??o e conserva??o de m?quinas, ve?culos, aparelhos, equipamentos, motores, elevadores ou de qualquer objeto (exceto pe?as e partes empregadas, que ficam sujeitas ao ICMS). </xTribNac> <xNBS>Servi?os de sistemas de seguran?a</xNBS> <verAplic>SefinNacional_1.5.0</verAplic> <ambGer>2</ambGer> <tpEmis>1</tpEmis> <procEmi>1</procEmi> <cStat>100</cStat> <dhProc>2026-01-12T19:56:19-03:00</dhProc> <nDFSe>53116</nDFSe> <emit> A causa principal está no fato de que, em diversos pontos do código do ACBr, existem conversões implícitas de tipos (string, AnsiString e UTF-8). Esse comportamento não gera erro aparente no Lazarus/FPC, pois nesse ambiente o tipo string já é UTF-8 por padrão. Entretanto, no Delphi 2009+ (Unicode), essas conversões implícitas passam a ser críticas, resultando em: UTF-8 interpretado como ANSI Dupla conversão de encoding Mojibake (acentuação quebrada) Perda de caracteres tanto no envio quanto no retorno do processamento Observação importante Esse problema já foi reportado diversas vezes pela comunidade. Historicamente, a solução sugerida tem sido habilitar a opção de “remover acentos” nos textos enviados. No entanto, essa não é uma solução correta. A acentuação em UTF-8 é plenamente aceita, não possui qualquer restrição no layout e é inclusive utilizada internamente pelo servidor da NFSe Nacional. Remover acentos apenas mascara o problema, elimina informação válida do texto e não resolve a causa real, que é o tratamento incorreto de charset no código. Portanto, o problema precisa ser resolvido na origem, com a correção adequada dos fontes e do fluxo de encoding. Esse cenário afeta diretamente: Envio do XML da NFSe Retorno das mensagens do webservice Textos livres (descrições, observações, mensagens de erro) Conteúdos recuperados e posteriormente exportados/visualizados (ex.: XML → XLS) Diante disso, tornou-se necessária a correção dos fontes, eliminando conversões implícitas e garantindo tratamento explícito de UTF-8. Adequação realizada Foi realizada uma adequação no código da NFSe – Padrão Nacional, com foco em Delphi 2009+, corrigindo problemas de acentuação e encoding decorrentes do uso incorreto de AnsiString em fluxos que exigem UTF8String. A correção é indispensável porque o servidor da NFSe Nacional exige que todo o conteúdo enviado esteja obrigatoriamente em UTF-8, incluindo: XML principal Mensagens de troca com o webservice Textos livres (descrições, observações, mensagens de erro, etc.) Antes do ajuste, parte do código realizava conversões implícitas ou indevidas entre string, AnsiString e UTF-8, ocasionando mojibake (conteúdo UTF-8 interpretado como ANSI), com impacto direto na acentuação tanto no envio quanto no retorno do processamento. O que foi corrigido Padronização do tratamento de dados textuais enviados ao webservice como UTF8String Eliminação de conversões implícitas que causavam dupla interpretação de encoding Correção de pontos críticos de: Compressão e descompressão Gravação e leitura de arquivos Manipulação de XML Comunicação HTTP Garantia de retorno correto dos caracteres acentuados após o processamento Correção dos dados recuperados, evitando erros de acentuação em exportações e visualizações (ex.: XML/XLS) Compatibilidade A solução mantém total compatibilidade com: Lazarus / FPC (onde string já é UTF-8) Delphi antigo (pré-Unicode) Delphi Unicode (2009+) Foram utilizadas diretivas de compilação para assegurar o comportamento correto em cada ambiente, sem impacto regressivo. Arquivos alterados Os seguintes arquivos foram modificados para aplicar a correção de encoding e eliminar problemas de mojibake: ACBrXmlDocument.pas PadraoNacional.Provider.pas ACBrNFSeXWebserviceBase.pas ACBrDFeXsLibXml2.pas ACBrDFe.pas ACBrUtil.XMLHTML.pas ACBrUtil.Strings.pas ACBrUtil.FilesIO.pas ACBrCompress.pas Estou disponibilizando os arquivos corrigidos, juntamente com o resultado do processamento após a correção, para validação técnica e compartilhamento com a comunidade. exemplo do funcionamento da correção Logs.7z

Bom dia @leonardo.gomes, Imagina não gerou transtorno nenhum. Muito obrigado pela colaboração.

Olá comunidade ! No dia 04/02/2026 foi publicada a nota técnica 2026/001 para o CT-e trazendo informações sobre a vinculação de pagamentos ao DFe. Essa vinculação se faz necessária para que o processo de Split Payment Inteligente seja executado. É importante ressaltar que o vínculo indicado pelo contribuinte não necessariamente representa um pagamento efetuado e liquidado. Indica uma expectativa de pagamento que pode ou não se concretizar. Por exemplo: um boleto pode ser emitido e não pago. Alterações Adiciona no CT-e, CT-e OS e CT-e Simp um "Grupo de informações da vinculação com a transação de pagamento" com a seguinte estrutura: <pgtoVinc> <pgto> <nPag></nPag> <idTransacao></idTransacao> <tpMeioPgto></tpMeioPgto> <CNPJReceb></CNPJReceb> <CNPJBasePSP></CNPJBasePSP> </pgto> </pgtoVinc> Cria o "evento de vinculação da transação de pagamento com o DFe - 110300" com estrutura semelhante ao grupo da vinculação e seu respectivo evento de cancelamento. Adiciona regras de validações para os novos campos e para o evento. Datas Implantação Homologação: 06/04/2026 Implantação Produção: 04/05/2026 E como fica o ACBr? Modificações no ACBr serão necessárias para atender a esta nota técnica. Foi criada a tarefa ACBR-8938 para a adequação das soluções ACBr. Leia a nota técnica na íntegra AQUI.

Eu mantive assim: Result.AppendChild(AddNode(tcStr, '#32', 'CodigoNbs', 1, 12, NrOcorrCodigoNBS, PadLeft(NFSe.Servico.CodigoNBS, 12, '0'), DSC_CMUN)); O código NBS pode até ser 9 digitos, mas tem de seguir o padrão do xsd que é de 12 números. Eu não emiti uma nota por não ter certificado digital de alguém da cidade que tem o provedor, mas não deu erro de schemas xml: Código : Mensagem: Inscrição informada é inválida. Correção: Você precisa colocar para o nbs gerar com 12 digitos, além de recompilar o ACBr após alteração das units.

Arredondamento segundo normas da ABNT... (Ele é diferente do arredondamento bancário) Sim.. todos os Documentos Eletrônicos Brasileiros, usam o arredondamento segundo ABNT

Boa noite, Sr. Utilizo a ferramenta supracitada, que realiza o "download da NFC-e". Entretanto, conforme mencionado por nosso colega @Juliomar Marchetti, o arquivo obtido não é o original. Comparei as assinaturas digitais de ambos os arquivos e constatei que são divergentes. Dessa forma, suponho que seja realizado um processo de scraping na consulta pública, com a remontagem do XML com base nos dados da consulta, utilizando a cópia da assinatura de um documento válido previamente enviado para o site. Estou à procura de colegas interessados no desenvolvimento de uma ferramenta semelhante ao Jettax e ao Sittax, utilizando as consultas do SERPRO e, se houver disponibilidade, também das SEFAZ estaduais. Os interessados podem entrar em contato. PS: Não vou disponibilizar os XMLs para comparação em razão da LGPD, pois os dados pertencem aos meus clientes (emitentes). Caso haja interesse, posso demonstrar em tela por acesso remoto ou meio similar.

Acabei de testar enviando 62 caracteres no id e funcionou para Blumenau. Ao menos em homologação.

Boa tarde Ficou faltando atualizar o arquivo nfse.xsd na pasta do provedor no SVN.....

no svn At revision: 44671

Olá comunidade ! Foi publicado no dia 03/02/2026 a Nota Técnica Nº 011 2026 Orientativa para os contribuintes de PIS/COFINS. Essa nota técnica estabelece as orientações aos contribuintes em relação a EFD Contribuições no que diz respeito a Reforma Tributária. Conforme estabelecido pelo cronograma da Reforma, a partir de 2027, o PIS e o COFINS serão extintos, sendo substituídos em sua integralidade pela CBS. Devido a isso a NT estabelece que a EFD-Contribuições deixará de ser utilizada para apuração de novos fatos geradores de PIS e COFINS quando CBS passar a ser cobrada em sua alíquota plena. Vejam que "novos fatos" está destacado, pois é importante ressaltar que a EFD-Contribuições não será imediatamente descontinuada devido a necessidade de gerar saldos credores remanescentes e atender os prazos legais de fiscalização e retificação de informações. Manutenção da Escrituração para Fins de Controle A obrigação de manter, o direito de consultar e retificar a EFD-Contribuições persistirá pelo prazo mínimo de 5 (cinco) anos. Essa manutenção é crucial para a gestão dos saldos credores acumulados de PIS e COFINS gerados até 31 de dezembro de 2026. Tais créditos remanescentes devem ser devidamente escriturados para que possam ser utilizados em compensação com a CBS ou outros tributos federais. Ausência de Alteração de Leiaute para CBS Não haverá alterações no leiaute da EFD-Contribuições para escrituração dos valores da CBS, IBS e IS (Imposto Seletivo) nos documentos fiscais, relativo aos fatos geradores ocorridos em 2026. Ou seja, estes valores não devem ser somados aos valores dos itens ou dos documentos fiscais no ano de 2026. Novos documentos fiscais eletrônicos Enquanto a EFD não for atualizada para receber as informações dos novos documentos BPeTA, NFAg, NFGas, NFeABI, NFS-e Via e DeRe, como regra geral, as operações registradas nos novos documentos eletrônicos serão escrituradas nos mesmos registros que atualmente recepcionam estas operações. Quando o registro da EFD-Contribuições contiver o campo COD_MOD - Código do modelo do documento fiscal, o contribuinte deverá informar o código 55 – Nota Fiscal conforme tabela: Código Descrição Modelo Registro COD_MOD a ser utilizado 63 Bilhete de Passagem Eletrônico (BPeTA) – Modal Aéreo 63 Aquisição: D100 Fornecimento: D200 55 75 Nota Fiscal de Água e Serviços de Saneamento Eletrônica – NFAg 75 Aquisição: C500 Fornecimento: C600 55 76 Nota Fiscal Eletrônica do Gás - NFGas 76 Aquisição: C500 Fornecimento: C600 55 77 Nota Fiscal de Alienação de Bens Imóveis - NF-e ABI 77 F200* Não se aplica - Nota Fiscal de Serviço Eletrônica de Exploração de Vias - NFS-e Via - A100 ou F100** Não se aplica - Declaração dos Regimes Específicos – DeRE - Bloco I*** Não se aplica * A chave do documento fiscal deverá ser informada no campo 06 – NUM_CONT. ** A escrituração pode ser consolidada em F100, agregando o valor total diário das NFS-e, segregado por CST, alíquota e natureza da receita. A faixa de numeração dos documentos será escriturada no campo 19-DESC_DOC_OPER. *** Para os contribuintes sujeitos ao bloco I (Pessoas jurídicas referidas nos §§ 6º, 8º e 9º do art. 3º da Lei nº 9.718, de 1998). Para os demais contribuintes, de acordo com o tipo/modelo de documento fiscal emitido. Leia a nota técnica completa AQUI. Veja a notícia original AQUI.

ISSSaoPaulo - Particularidades Veja nesse artigo algumas particularidades desse provedor. 1. Como realizar emissões de teste? O ISSSaoPaulo não disponibiliza um ambiente de homologação separado. Em vez disso, permite realizar testes através de um modo de envio específico. Acesse o link abaixo para verificar como realizar esse procedimento em detalhes: Ambiente de testes/homologação (clique aqui) 2. Novo leiaute para Reforma Tributária do Consumo: No momento, o provedor da cidade de São Paulo (ISSSaoPaulo) suporta dois leiautes: um para atender a Reforma Tributária do Consumo (RTC) e outro que não atende. As empresas que são Simples Nacional não precisam lançar os dados da RTC por enquanto e, por isso, devem continuar usando o leiaute 1.00 (ve100). Isso vai continuar para todas emissões com fato gerador até 31/12/2028. Já as demais empresas, precisam informar os dados da RTC como IBS/CBS e por isso precisam utilizar já hoje a versão 2.00 (ve200). 2.1 Como você pode atender a esses dois leiautes usando as soluções do ACBr para emissão de NFSe? Sempre que você alterar a configuração nas soluções do ACBr para o município de SP, você precisa também definir a versão que será utilizada. 2.1.1 No componente ACBrNFSeX // pseudo código ajuste conforme sua rotina ACBrNFSeX1.Configuracoes.Geral.CodigoMunicipio := xxx; if codmunicipio = codIBGESaoPaulo then begin if Empresa.OptanteSimplesNacional then begin ACBrNFSeX1.Configuracoes.Geral.Versao := ve100; end else begin ACBrNFSeX1.Configuracoes.Geral.Versao := ve200; end; end; 2.1.2 Na ACBrLibNFSe Utilize o método NFSE_SetVersaoDF: // pseudo código ajuste conforme sua rotina NFSE_ConfigGravarValor("NFSE", "CodigoMunicipio", codmunicipio) if codmunicipio = codIBGESaoPaulo then begin if Empresa.OptanteSimplesNacional then begin NFSE_SetVersaoDF("1.00") end else begin NFSE_SetVersaoDF("2.00") end; end; 2.1.3 No ACBrMonitor Plus Utilize o comando NFSE.SetVersaoDF: // pseudo código ajuste conforme sua rotina NFSE.SetCodigoMunicipio(codmunicipio) if codmunicipio = codIBGESaoPaulo then begin if Empresa.OptanteSimplesNacional then begin NFSE.SetVersaoDF("1.00") end else begin NFSE.SetVersaoDF("2.00") end; end; 2.2 Mais informações da implementação Independente da solução utilizada, o arquivo ACBrNFSeXServicos.ini deve ter a seção correspondente a São Paulo conforme o exemplo abaixo: Para os demais município, a informação da versão já vem do arquivo ACBrNFSeXServicos.ini, então você não precisa se preocupar em definir essa informação. Você deve sempre definir a versão quando for configurar o município de São Paulo pela primeira vez. Schemas devem ser atualizados!

Verifique sua classtrib. Quando Preencher (tpCredPresIBSZFM) Preencha este campo nas seguintes situações: Venda para ZFM/Áreas de Livre Comércio: Quando sua empresa está emitindo uma NF-e de saída para um cliente localizado na Zona Franca de Manaus ou áreas com benefícios fiscais similares (Suframa), onde o adquirente tem direito ao crédito presumido. Nota Técnica 2025.002: O campo faz parte dos novos leiautes de IBS e CBS, sendo exigido quando o cClassTrib (Código de Classificação Tributária) indicar uma operação com crédito presumido ou benefício fiscal na ZFM. Condição Suspensiva: O campo é preenchido especificamente para situações de cCredPres (Código de Crédito Presumido) que possuam indicação de condição suspensiva.

Movi o tópico para a área aberta. Queremos que ele alcance maior parte da comunidade. Em vista de nosso backlog, gostaríamos de que outras pessoas pudessem verificar sua necessidade e se possível contribuir com a implementação.

Olá comunidade ! Foi publicado o a versão 1.40 do Informe Técnico 2025/002 que divulga atualizações nas tabelas de CST, Classificação Tributária e Crédito Presumido. Todas informações utilizadas na Reforma Tributária. A versão mais recente traz as seguintes alterações: - Tabela CST Altera a descrição do CST 810 para "Tributação em documento específico"; - Tabela de Classificação Tributária Classificação Tributária 200001: desabilita o indicador de DFe para NF-e e habilita para CT-e OS; Classificação Tributária 200044: desabilita o indicador de DFe para NF-e/NFC-e; Classificação Tributária 200043 e 200044: habilita o indicador DFe para NFCom; Classificação Tributária 410027: habilita o indicador DFe para NFe; Efetivamente alterando o uso desses cClassTrib para esses documentos proibindo ou permitindo seu uso por modelo. Leia a versão 1.40 deste Informe Técnico na íntegra AQUI

Bom dia! Estou desenvolvendo a comunicao do TEF atraves da clisitef.so em android, já consegui fazer a comunição com o SITDEMO e o pinpad USB usando JJCliSiTefI = interface; // br.com.softwareexpress.sitef.JCliSiTefI gostaria se saber se alguem que entende um pouco mais do que eu em android tem interesse em me ajudar a desenvolver o restante?