Diego.Foliene

Bom dia! Conferindo nos fontes a adição do novo valor foi enviada na Rev-44662. No Discord, também foi reportado que você conseguiu gerar a nota com sucesso em produção: https://discord.com/channels/798697718800318484/800042186783588364/1467949862975963136

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.

Bom dia! @Nilson Sérgio enviei ajuste ao SVN para que IdentificacaoRps.Numero, IdentificacaoRps.Serie e Competencia só sejam sobrescritas com as informações lidas dos grupos DPS se o leitor encontrar alguma coisa. Se não achar nada, mantém o que lido do grupo RPS. Também alterei a leitura de cTribNac que antes sobrescrevia ItemListaServico e agora preenche CodigoServicoNacional conforme a rotina de geração do XML. @renemelo, enviado ao SVN correção da leitura da data. Sobre a questão do tcCompNFSe e CompNFSe, não tive problemas em meus testes usando o XML que foi fornecido pelo colega. A rotina da classe mãe busca tcCompNFSe, e se não encontrar, busca por NFSe direto, no teste que fiz, ele encontra o NFSe e lê as informações.

Apenas para informar, adicionamos a tarefa em nosso ciclo atual de desenvolvimento que se encerra no dia 06/02/2026. Assim que for disponibilizado no SVN avisaremos aqui neste tópico.

Olá pessoal! O membro de nossa comunidade @Felipe Mariano compartilhou conosco no canal #sefaz em nosso servidor do Discord essa resposta que recebeu do Fale Conosco confirmando que o problema está de fato no lado da Sefaz e está sendo averiguado.

Bom dia! Muito obrigado pelas informações e pela contribuição! Foi criada a tarefa ACBR-8908 para análise da contribuição e disponibilização da mesma no SVN. Assim que for disponibilizado avisamos aqui no tópico.

Olá comunidade ! No dia 02/02/2026, por volta das 08h36, começamos a receber múltiplos relatos de membros da nossa comunidade com problemas para autorizar determinadas notas fiscais junto a Sefaz Paraná. Todos os relatos tem em comum o mesmo retorno com a seguinte rejeição: Como é possível observar, esta rejeição costuma ocorrer quando é utilizado um CST e um cClassTrib que tem redução de alíquota, mas o percentual utilizado é inválido. No entanto, tudo indica ser um problema de rejeição sendo devolvida indevidamente, pois temos relatos de notas como esta do exemplo abaixo sendo rejeitadas: <IBSCBS> <CST>200</CST> <cClassTrib>200003</cClassTrib> <gIBSCBS> <vBC>100.00</vBC> <gIBSUF> <pIBSUF>0.1000</pIBSUF> <gRed> <pRedAliq>100.0000</pRedAliq> <pAliqEfet>0.0000</pAliqEfet> </gRed> <vIBSUF>0.00</vIBSUF> </gIBSUF> <gIBSMun> <pIBSMun>0.0000</pIBSMun> <gRed> <pRedAliq>100.0000</pRedAliq> <pAliqEfet>0.0000</pAliqEfet> </gRed> <vIBSMun>0.00</vIBSMun> </gIBSMun> <vIBS>0.00</vIBS> <gCBS> <pCBS>0.9000</pCBS> <gRed> <pRedAliq>100.0000</pRedAliq> <pAliqEfet>0.0000</pAliqEfet> </gRed> <vCBS>0.00</vCBS> </gCBS> </gIBSCBS> </IBSCBS> Essa estrutura está correta de acordo com o Validador da Conformidade Fácil e o valor utilizado nos percentuais de redução também estão corretos de acordo com o CST x cClassTrib, conforme a Tabela de Classificação Tributária. Caso esteja enfrentando esta rejeição, o recomendado é que abra um Fale Conosco junto a Sefaz do Paraná.

Olá comunidade ! Foi publicada a nota técnica Nº 006 estabelecendo a Nota Fiscal de Serviço eletrônica de Exploração de Via de padrão nacional (NFS-e Via). Esta publicação atende a Resolução CGNFSE Nº 9 que estabelece o novo modelo que faz parte da NFS-e no padrão nacional. Contando com leiaute próprio este as informações parametrizáveis serão disponibilizadas por concessionárias de exploração de vias ao invés das prefeituras. A nota técnica pode ser lida na íntegra AQUI. Foi criada a tarefa ACBR-8906 para análise do leiaute e implementação no ACBr.

Olá comunidade ! Foi publicada a versão 12 do leiaute da ECF vigente para o ano calendário de 2025 e situações especiais de 2026. A nova versão traz as seguintes atualizações: Registro Y730: Identificação de donatários/destinatários de deduções do IRPJ/CSLL - Entidades isentas e imunes, que forem do tipo Educação, Saúde ou Assistência social, e que tiverem CEBAS, deverão informar o número. Possibilidade de transmissão com CNPJ alfanumérico Novas regras Validação envolvendo P300 e Y570, similar ao lucro real. Alguns campos foram alterados de "Cálculo Alterável" para "Cálculo Não Alterável". O manual pode ser encontrado AQUI. Vale reforçar que uma nova atualização do manual para atender a Lei Complementar que estabelece a Reforma Tributária nas situações especiais de 2026 é esperada até 01/04/2026. Foi criada a tarefa ACBr-8905 para adequação do componente ACBrSPEDECF.

Entendendo o problema De acordo com a planilha ANEXO_I-SEFIN_ADN-DPS_NFSe-SNNFSe-v1.00-20251226 que contém o leiaute da NFS-e e as regras de validação aplicadas pela API do Padrão Nacional, está é a regra de validação que correspondente a esta rejeição: Campo Regra de Validação Código Rejeição IM Se o emitente for o prestador de serviço (tpEmit = 1) e, se houver registro complementar do contribuinte no CNC do município correspondente ao município emissor da DPS, então a IM deve ser informada na DPS. Utilizar o identificador federal (CNPJ ou CPF) do prestador de serviço e o codigo do município emissor (cLocEmi), ambos informados na DPS, para identificar as ocorrências no CNC NFS-e. Se houver pelo menos uma ocorrência, então o emitente da DPS deve informar o IM correspondente registrado no CNC NFS-e, que identifique unicamente o registro complementar. Exceto quando o emitente da DPS for MEI na data de competência da emissão da NFS-e. E0116 A IM deve ser informada para o emitente prestador do serviço na DPS, conforme informações complementares registradas no CNC NFS-e do município emissor informado na DPS. A rejeição parece ser alto explicativa, se você recebeu a mesma, então a API do Padrão Nacional não está encontrando a IM no grupo <prest> do seu arquivo XML. Mas existe uma "pegadinha", não foram poucos os que relataram estar recebendo esta rejeição, mesmo enviando a informação no arquivo XML corretamente. Como resolver? Se você está recebendo esta rejeição, a primeira coisa a verificar é se no XML do DPS que está sendo gerado e enviado, a informação da IM está sendo adicionada no grupo <prest> <prest> <CNPJ>XXXXXXXXXXXXXX</CNPJ> <IM>YYYYYYYYYYYYYYY</IM> </prest> Se a informação está presente no XML, então entramos na "pegadinha". Muitas IMs são valores numéricos variando de 6, 9 ou até 11 caracteres. Mas o tamanho do campo no XML do padrão nacional é 15! Vamos considerar como exemplo o valor 12345678 como exemplo. Se você está informando este valor e está recebendo a rejeição, faça um teste informando os zeros não significativos na esquerda até completar 15 caracteres enviando 000000012345678. Caso utilize ACBrNFSeX para Delphi e Lazarus: Alimente a IM na propriedade: NFSe.Prestador.IdentificacaoPrestador.InscricaoMunicipal := '000000012345678'; Caso utilize ACBrMonitorPLUS ou ACBrLibNFSe: Alimente a informação no arquivo INI preenchendo a seguinte propriedade: [Prestador] IM=000000012345678

@Nilson Sérgio, por favor, você tem um XML que exemplifique esta situação?

Entendendo o problema De acordo com a planilha ANEXO_I-SEFIN_ADN-DPS_NFSe-SNNFSe-v1.00-20251226 que contém o leiaute da NFS-e e as regras de validação aplicadas pela API do Padrão Nacional, está é a regra de validação que correspondente a esta rejeição: Campo Regra de Validação Código Rejeição cLocEmi O município emissor informado na DPS deve estar parametrizado para utilizar os emissores públicos nacionais, conforme parametrização do município no Sistema Nacional NFS-e. Exceto quando o emitente da DPS for MEI na data de competência da emissão da NFS-e. E0039 O município emissor informado na DPS deve estar parametrizado para utilizar os emissores públicos nacionais, conforme parametrização do município no Sistema Nacional NFS-e. Aqui precisamos dar alguns passos para trás e entender como um município pode aderir ao padrão nacional. Essa adesão pode ser feita de duas formas diferentes. Aderir ao Padrão Nacional e ao Emissor Nacional: Nessa modalidade, o município utilizará integralmente a estrutura federal, sendo a emissão das notas feita diretamente pela API oficial. Aderir ao Padrão sem o Emissor Nacional: O município mantém sua estrutura de emissão atual, mas deverá adaptá-la para comportar novos campos. Isso é necessário para que, após processar o RPS/DPS, o sistema local transmita as informações à API oficial. Portanto, se você está recebendo esta rejeição, significa que você está tentando comunicar diretamente com a API do emissor nacional enviando um cTribNac que na verdade deveria se comunicar com a API do município. Como resolver? Certifique-se de que você está se comunicando com a API correta. O arquivo ACBrNFSeXServicos.ini já foi atualizado para definir padrão nacional, portanto, exceto nos casos em que o prestador de serviços seja MEI, você não deve definir um valor diferente de lnfsProvedor para a configuração do LayoutNFSe. Caso utilize ACBrNFSeX para Delphi e Lazarus: Defina a seguinte configuração: ACBrNFSeX.Configuracoes.Geral.LayoutNFSe := lnfsProvedor; Caso utilize ACBrMonitorPLUS: Utilize o comando NFSe.SeLayoutNFSe definindo o valor 2: NFSe.SetLayoutNFSe(2) Caso utilize ACBrLibNFSe: Utilize os métodos NFSE_ConfigGravarValor seguido de NFSE_ConfigGravar para definir o valor 2 para a chave LayoutNFSe em seu arquivo ACBrLib.ini: NFSE_ConfigGravarValor("NFSe", "LayoutNFSe", "2"); NFSE_ConfigGravar(); É importante que independente da solução que estiver utilizando, garanta que tanto ela quanto o arquivo ACBrNFSeXServicos.ini respectivo estejam atualizados.

Olá comunidade ! Foi publica a versão 1.13 desta nota técnica. Alterações Esta versão adiciona uma regra de validação para obrigar o preenchimento da tag vTotDFe quando houver o grupo IBSCBS no XML. Não houveram alterações de leiaute. Datas Implantação Homologação: 03/02/2026 Implantação Produção: 02/03/2026 O que muda no ACBr? Não serão necessárias modificações no ACBr visto que não houve alterações de leiaute. Leia a versão 1.13 desta nota técnica na íntegra AQUI.

Olá comunidade ! Foi disponibilizado pelo Comitê Gestor do IBS o 2º volume da Cartilha Orientativa da Apuração do Imposto sobre Bens e Serviços. Enquanto o 1º volume focou em trazer orientações sobre a estrutura dos documentos fiscais eletrônicos, a nova publicação tem o foco voltado a utilização do Sistema de Apuração Assistida do IBS. O novo volume é composto por 38 páginas trazendo orientações diversas desde os primeiros passos até o funcionamento do sistema de apuração. Sua leitura é recomendada para todos os contribuintes, contadores e desenvolvedores que desejam entender a lógica do sistema de apuração assistida, independente de os mesmos fazerem parte do grupo de empresas piloto. A cartilha pode ser lida na íntegra AQUI.

Olá comunidade ! Ao acessar o painel Situação SVC, é possível observar que a Sefaz da Bahia se encontra com contingência agendada para o dia 01/02/2026, com previsão de inicio às 00h00 e término às 06h00 do mesmo dia. Um agradecimento ao membro de nossa comunidade @Felipe Mariano por compartilhar a informação no canal #sefaz em nosso Discord. Para utilizar as soluções ACBr em contingência durante esse período siga as orientações do tópico abaixo:

Boa tarde @Gustavo-Pires. Você está enfrentando esses problemas usando o ACBr? Caso esteja usando, por favor, certifique-se de que está com os fontes atualizados e em dia com o SVN.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Olá comunidade ! Foram enviados ao SVN os demais ajustes visando compatibilização com os arquivos de schema mais recentes do Padrão Nacional. Em suma as alterações englobam: Alterações para tiposEventos.xsd: Alterado as units PadraoNacional.Provider, Pronim.Provider e Digifred.Provier para emissão dos eventos conforme novos schemas removendo o infRej. Alterado a unit ACBrNFSeXConversao para devolver a descrição dos eventos conforme novos schemas. Alterações para tiposSimples.xsd: Adicionado valor 9 profissional parceiro para o tpDedRed. Alterações tiposComplexos.xsd: Adicionada leitura do elemento xOutrInf fora do grupo valores ao ler o XML da NFS-e. É importante ressaltar que os arquivos de schema mencionados também foram atualizados!

Boa tarde @renemelo. Por favor, disponibilize as units alteradas para validação e disponibilização no SVN.

Obrigado pela contribuição, em breve será validada para possível inclusão ao svn ACBR-8887

Bom dia! No geral contexto geral, para maioria dos provedores que implementou nova API que recepciona o XML no leiaute do padrão nacional ou no próprio padrão nacional o DPS substitui o RPS. Ou seja, você deixa de enviar um para enviar o outro. Por causa disso, visando evitar ambiguidade, as propriedades foram reaproveitadas, então no momento de gerar o XML do DPS, a série dele, vai ser a propriedade que antes preenchia a série do RPS, o número dele vai ser a propriedade que antes preenchida o número da DPS e assim por diante. Mesmo para os provedores que alteraram seu leiaute para enviar informações do padrão nacional e da reforma tributária, é raro um que peça para enviar os dados de identificação do RPS e também os do DPS (o SpeedGov é o único até o momento). Por favor, você tem um XML de exemplo de uma nota autorizada que pelo SpeeGov que exemplifique uma situação em que os dados de identificação do RPS são diferentes dos dados de identificação do DPS? Se sim, por favor, pode disponibilizar o mesmo? Você está enfrentando algum erro? Se sim, qual? Pode disponibilizar um print do erro e os envelopes da requisição da consulta?