Painel de líderes

Olá Pessoal, O inicio de 2026 vai ser muito conturbado para todos nós desenvolvedores. Se tratando de NFS-e prevejo um cenário muito caótico, por conta da falta de padronização. Temos por volta de 150 provedores (empresas contratadas pelas prefeituras) e não temos informações sobre o que cada um pretende fazer no quesito Reforma Tributária. E com certeza você não quer ter que fazer instalação nos seus vários clientes no dia 31/12 ou 01/01 para atender essas mudanças né? Visando auxiliar aos desenvolvedores que utilizam as soluções ACBr, criamos esse passo a passo a ser seguido para auxiliar nessa tarefa e para que sua aplicação de emissão de notas não pare no dia 01/01/2026! Antes de começar... Sabemos que os prazos estão apertados e todos precisam adequar suas aplicações. Mas antes de começar, precisamos entender como meu cliente vai ser afetado de fato. Isso vai ser importante para os passos mais a frente. Podemos dividir a mudança que vai ocorrer para um município em 3 possibilidades: Municípios que aderiram a emissão com o Padrão Nacional; Municípios que vão utilizar uma API ou Web Service próprios para recepcionar o arquivo XML no layout do Padrão Nacional; Municípios que vão manter o Web Service atual, apenas atualizando o layout que já é utilizado para conter novos campos; Então antes de realizar toda e qualquer modificação em sua solução, é preciso descobrir em qual das 3 situações se encaixa o seu cliente. A Lista de Municípios Aderentes é o lugar perfeito para encontrar essa informação. Se a cidade constar como aderente ao emissor nacional, então isso significa que ela aderiu ao Padrão Nacional na íntegra, fazendo a emissão por ele. Se encaixando então na primeira situação. Vamos a um exemplo prático, eu acessei a lista e abri a página do Power BI que centraliza as informações. Vejam que no canto inferior direito, temos uma seção que diz "Adesão ao Emissor Nacional da NFS-e. Agora, para exemplificar eu vou filtrar buscando a cidade de Adamantina/SP. Observem que na seção "Adesão ao Emissor Nacional da NFS-e" eu tenho o valor "Sim". Caso ela conste como aderente ao ambiente nacional, mas não aderente ao padrão nacional, isso significa que ela aderiu ao padrão nacional, mas na modalidade de compartilhamento. Se encaixando então na segunda ou terceira situação. Para demonstrar, filtramos a cidade de Aguaí-SP: Vejam que ela está ativa na plataforma, mas a informação de "Adesão ao Emissor Nacional da NFS-e" está em branco, indicando que ela não aderiu a emissão, somente a modalidade de compartilhamento. Nesses casos, é importante conferir se não existem avisos no portal da prefeitura ou se o cliente não recebeu algum aviso sobre mudança na emissão. Caso nenhuma informação seja encontrada, é preciso questionar a empresa que presta o serviço de manter o web service de emissão de notas para o município: "Quais alterações serão feitas para atender a Reforma Tributária?" "Vai continuar o mesmo layout da NFS-e?" "Se for continuar o mesmo layout de NFS-e, pedir a documentação das alterações para atualizar a integração e os novos arquivos de schema" "Se não for continuar o mesmo layout de NFS-e, pedir a URL da nova API ou web service para comunicação." Caso o Power BI não seja sua ferramenta de escolha ou a informação apresentada no mesmo não esteja condizente com a informação que você recebeu, existem mais duas formas de saber como o município aderiu ao Padrão Nacional melhor descritas neste tópico. Vamos começar! Agora que determinou em qual das situações seu cliente se encaixa, podemos começar o nosso passo a passo: 1) Fazendo a mudança das configurações dos provedores (URLs, versão, etc...) 2) Fazer a mudança na rotina de preenchimento do RPS/DPS. 3) Fazer a mudança na rotina da leitura do retorno

Dica Extra! É importante salientar que esse passo a passo tem o objetivo de auxiliar os desenvolvedores a se prepararem para que suas aplicações não deixem de emitir nota fiscal de serviço no dia 01/01/2026, uma vez que ele tenha sido executado e sua aplicação continue a emissão, ainda é muito importante que o desenvolvedor se aprofunde nos conceitos principais para entender melhor o seu funcionamento. Abaixo uma dica de leituras que podem auxiliar nesse entendimento: [FAQ] - NFSe e a Reforma Tributária NFSe e a Reforma Tributária: Um panorama da situação dos provedores que vão manter leiaute próprio. Rejeição E0160: No mês de competência da NFS-e, a opção de situação perante o Simples Nacional, do prestador, informada na DPS não está de acordo com o cadastro Simples Nacional. - Como resolver? Emissão de NFSe, eliminando todas as dúvidas. E0330: É obrigatório prestar informações de todos os campos relativos ao comércio exterior - Como resolver E0690: A alíquota do Cofins deve ser informada quando a base de cálculo deste imposto for informada - Como resolver E0536 : Não é permitido o preenchimento de informações relativas à benefício municipal para o prestador de serviço ME/EPP que não tenha o regime de apuração de tributos nesta NFS-e fora do Simples Nacional - Como resolver Rejeição E0160: No mês de competência da NFS-e, a opção de situação perante o Simples Nacional, do prestador, informada na DPS não está de acordo com o cadastro Simples Nacional. - Como resolver?

3) Considerar a mudança no modo de envio e no retorno. O terceiro e último passo é acertar o modo de envio e a tratativa do retorno. Atualmente os diversos provedores podem realizar o envio de forma síncrona permitindo um lote de RPS, o envio de forma síncrona permitindo somente 1 RPS e o envio de forma assíncrona permitindo um lote de RPS, onde cada modo de envio tem seu fluxo distinto. Agora com a adesão ao padrão nacional, isso muda e nós podemos ter 2 cenários, no primeiro cenário, temos aqueles em que foi adotado a emissão ao padrão nacional na íntegra ou foi criada uma API ou Web Service para recepcionar o XML no padrão nacional; Já no segundo cenário, temos os provedores que apenas modificaram seus layouts próprios. Cenário Se você usa o componente ACBrNFSeX nativo para Delphi e Lazarus: Use o método do componente chamado ACBrNFSeX.Emitir passando o parâmetro do modo de envio com o valor meAutomatico. O retorno será devolvido na classe ACBrNFSeX.WebService.Emite. Vamos a um exemplo: ACBrNFSeX1.NotasFiscais.Clear; Alimentar_Componente(vNumRPS, vNumLote); { O método Emitir possui os seguintes parâmetros: aNumLote (String) aModEnvio [meAutomatico, meLoteAssincrono, meLoteSincrono, meUnitario] aImprimir (Boolean) Valor Padrão = True, portanto imprime o DANFSE } // meUnitario: Ajusta o Emitir para enviar somente um Rps // No caso do Padrão Nacional o envio é sempre unitário ACBrNFSeX1.Emitir(vNumLote, meUnitario); ACBrNFSeX1.WebService.Emite.ModoEnvio; ACBrNFSeX1.WebService.Emite.NumeroLote; ACBrNFSeX1.WebService.Emite.Sucesso; ACBrNFSeX1.WebService.Emite.NumeroNota; ACBrNFSeX1.WebService.Emite.Link; Se você usa o ACBrMonitorPLUS: Utilize o valor correspondente ao modo de envio automático no parâmetro do modo de envio no comando NFSE.CriarEnviarRPS NFSe.CriarEnviarRPS("Conteúdo do arquivo INI", "Numero do Lote", 0) OU o comando NFSe.EnviarLoteRPS NFSe.EnviarLoteRPS("1",0) A resposta do ACBrMonitorPLUS é padronizada independente do modo de envio aplicado. Se você usa o ACBrLibNFSe: Utilize o método NFSE_Emitir, passando o valor correspondente ao modo de envio automático no parâmetro correspondente. Vamos a um exemplo em C#: var aLote = "1"; if (InputBox.Show("Emitir", "Número do Lote", ref aLote) != DialogResult.OK) return; var ret = ACBrNFSe.Emitir(aLote, 0, false); A resposta da ACBrLibNFSe é padronizada independente do modo de envio aplicado. Note que, independente da solução utilizada, eu não vou mais usar a consulta de situação de lote e nem a consulta de lote. Cenário Você continua utilizando os mesmos métodos que já utiliza atualmente. Com isso, concluímos nosso passo a passo. Mas se você chegou até aqui, não vá embora! Afinal não é porque acabou que chegamos ao fim. Veja a nossa Dica Extra!

2) Fazer a mudança na rotina de preenchimento do RPS/DPS. O segundo passo se refere a alimentação dos dados para gerar o XML do RPS/DPS a ser enviado para a API própria ou para o novo Webservice do provedor - (a) Sabemos que alguns municípios estão encerrando seus contratos com seus provedores e portanto os prestadores de serviços vão passar a emitir suas notas pelo Portal da NFS-e Padrão Nacional ou pela API do SERPRO. Sabemos também que muitos municípios vão manter seus contratos com seus provedores. Nesse caso, (b) alguns optaram por adotar o layout do Padrão Nacional e (c) outros vão manter o layout atual fazendo ajustes para atender a Reforma Tributária. Veja abaixo o que fazer nessas 3 situações: Se você usa o componente ACBrNFSeX nativo para Delphi e Lazarus: (a) Situação onde o município aderiu a emissão da NFSe segundo o Padrão Nacional: a sua aplicação vai ter que passar a alimentar o componente visando o Padrão Nacional. No programa exemplo temos uma procedure chamada: Alimentar_Componente_layout_PadraoNacional. A partir de 2026 a sua aplicação vai ter que alimentar o componente com base nessa procedure. (b) Situação onde o provedor adotou o layout do Padrão Nacional, siga as orientações da situação (a). (c) Situação onde o provedor vai manter o layout em uso mas com alterações visando a Reforma Tributária, nesta situação a sua aplicação vai continuar alimentando o componente da mesma forma que alimenta hoje, mas com os novos campos. A titulo de exemplo você pode se basear nas procedures: Alimentar_Componente_layout_ABRASF (para os provedores que vão manter o layout ABRASF) ou Alimentar_Componente_layout_Proprio (para os provedores que vão manter o seu layout próprio). Ambas as rotinas possuem exemplo do preenchimento dos campos da Reforma Tributária, bastando conferir o que é preenchido dentro da condição if rgReformaTributaria.ItemIndex = 0 then dentro da respectiva procedure. Se você usa o ACBrMonitorPLUS: (a) Situação onde o município aderiu a emissão da NFSe segundo o Padrão Nacional: a sua aplicação deve alimentar o monitor com um arquivo INI criado aos moldes do modelo: NFSe Layout Padrão Nacional (Reforma Tributária). (b) Situação onde o provedor adotou o layout do Padrão Nacional, siga as orientações da situação (a). (c) Situação onde o provedor vai manter o layout em uso, mas com alterações visando a Reforma Tributária, nesta situação, a sua aplicação vai continuar alimentando o monitor com o arquivo INI que já utiliza, mas o arquivo deve ser atualizado, adicionando somente as seções em vermelho do NFSe Layout Padrão Nacional (Reforma Tributária) Se você usa a ACBrLibNFSe: (a) Situação onde o município aderiu a emissão da NFSe segundo o Padrão Nacional: a sua aplicação deve alimentar o monitor com um arquivo INI criado aos moldes do modelo: Modelo NFSe.INI - Padrão Nacional (Reforma Tributária). (b) Situação onde o provedor adotou o layout do Padrão Nacional, siga as orientações da situação (a). (c) Situação onde o provedor vai manter o layout em uso, mas com alterações visando a Reforma Tributária, nesta situação, a sua aplicação vai continuar alimentando o monitor com o arquivo INI que já utiliza, mas o arquivo deve ser atualizado, adicionando somente as seções em vermelho do Modelo NFSe.INI - Padrão Nacional (Reforma Tributária) Feito isso, podemos considerar esse item como concluído e ir para o próximo passo! Vamos agora Considerar a mudança no modo de envio e no retorno.

1) Fazendo a mudança das configurações dos provedores (URLs, versão, etc...) Informação sobre o arquivo ACBrNFSeXServicos.ini O primeiro passo se refere as novas URLs e outras configurações dos provedores - O arquivo ACBrNFSeXServicos.ini já foi ajustado com as informações relacionadas a Reforma Tributária. Ou seja, já contém as novas URLs, configurações de versões dos provedores que implementaram uma API ou WebService próprios para recepcionar o arquivo XML no Padrão Nacional etc. Isso para a maioria dos provedores. As cidades que aderiram ao Padrão Nacional na íntegra para emissão também foram atualizadas, trocando a informação do provedor. Assim, sua aplicação pode continuar funcionando ao atualizar o arquivo ACBrNFSeXServicos.ini atual e apontar para esse arquivo para que pegue os dados atualizados. Ou mesmo apagando esse arquivo para que seja utilizado as configurações que vão embutidas no componente. Abaixo passamos exemplos e orientação específica para cada solução ACBr: O primeiro passo se refere as novas URLs e outras configurações dos provedores - Foi criado um novo arquivo INI chamado ACBrNFSeXServicosRTC.ini. Esse arquivo é um arquivo ACBrNFSeXServicos.ini já ajustado com as informações relacionadas a RTC. Ou seja, novas URLs, configurações de versões dos provedores que implementaram uma API ou WebService próprios para recepcionar o arquivo XML no Padrão Nacional, etc. As cidades que aderiram ao Padrão Nacional na íntegra para emissão também foram atualizadas, trocando a informação do provedor. Assim, sua aplicação pode continuar funcionando com o arquivo atual e no dia que quiser, apontar para esse novo arquivo pegando os dados atualizados. É claro que para isso, o novo arquivo deve ser distribuído junto a sua aplicação e atribuído a solução ACBr que estiver utilizando. Abaixo passamos exemplos e orientação específica para cada solução ACBr: Se você usa o componente ACBrNFSeX nativo para Delphi e Lazarus: Temos a propriedade de configuração: IniServicos, que fica em ACBrNFSeX1.Configuracoes.Arquivos. Veja um exemplo do que você pode fazer na sua aplicação Delphi/Lazarus: with ACBrNFSeX1.Configuracoes.Arquivos do begin (...) Ano2026 := (Now >= EncodeDate(2026, 1, 1)); if Ano2026 then IniServicos := xPathEXE + '\ACBrNFSeXServicosRTC.ini' else IniServicos := ''; end; Se você usa o componente ACBrNFSeX nativo para Delphi e Lazarus: Tendo os Fontes atualizados não é necessário apontar explicitamente para o arquivo ACBrNFSeXServicos.ini, já que ao compilar e distribuir seu executavel irá incluir o ACBrNFSeXServicos.res que contem as URLs atualizadas. Se você usa o ACBrMonitorPLUS: Tendo uma versão do ACBrMonitorPlus recente e atualizada o Monitor por padrão irá buscar pelo arquivo ACBrNFSeXServicos.ini na raiz de seu ACBrMonitor: Se você usa a ACBrLibNFSe: Tendo a versão do ACBrLibNFSe mais atualizada, aponte o caminho do arquivo ACBrNFSeXServicos.ini na chave IniServicos da seção [NFSe] do arquivo ACBrLib.ini utilizando respectivamente os métodos NFSE_ConfigGravarValor e NFSE_ConfigGravar. Caso não seja informado será utilizado o último ACBrNFSeXServicos.res compilado Vamos a um exemplo usando a linguagem C#: ACBrNFSe.Config.IniServicos = xPathEXE+"\ACBrNFSeXServicos.ini"; //OU ACBrNFSe.ConfigGravarValor(ACBrSessao.NFSe, "IniServicos", xPathEXE + "\ACBrNFSeXServicos.ini"); //E POR FIM ACBrNFSe.ConfigGravar(); Feito isso, podemos considerar este item como concluído Parada obrigatória para um esclarecimento importante! Notem que nas situações descritas lá na primeira postagem temos duas em que é mencionado o padrão nacional. Em uma delas é dito que a cidade pode ter aderido a emissão pelo padrão nacional e na outra é citado que o provedor pode ter criado uma API que recepciona o XML no mesmo layout do padrão nacional. Essa diferença é importante! Se o município está usando a emissão com o padrão nacional, você precisa alterar a configuração do LayoutNFSe para dizer isso a solução ACBr. No componente nativo para Delphi/Lazarus: ACBrNFSeX1.Configuracoes.Geral.LayoutNFSE := TLayoutNFSe.lnfsPadraoNacionalv101; No ACBrMonitorPLUS: NFSe.SetLayoutNFSe("2") Na ACBrLibNFSe: NFSE_ConfigGravarValor("NFSe", "LayoutNFSe", "2"); NFSE_ConfigGravar(); Essa configuração deve ser definida antes de prosseguir. Caso o município continue usando o provedor próprio, independente da forma que adotar, você não vai definir essa configuração. Agora sim podemos ir para o próximo passo que é Fazer a mudança na rotina de preenchimento do RPS/DPS.

Parece ser a mesma coisa...

Boa tarde, Criada a tarefa ACBR-8635 para avaliação. Obrigado pela contribuição.

Boa tarde @Vinicius Telles dos Santos, Foi escrito um tópico que passa todas as orientações de como usar esse novo arquivo. Mas vou lhe responder. Ele é uma cópia do ACBrNFSeXServicos.ini, portanto tem todas as cidades e suas respectivas configurações, ou seja, Provedor, Versao e URLs de Produção e Homologação. Esse novo arquivo ACBrNFSeXServicosRTC.ini contem alterações visando atender as mudanças realizadas pelos provedores que trocaram de layout e ou URLs para atender a Reforma Tributária, bem como as cidades que aderiram a emissão da nota pelo Padrão Nacional. Por favor leia o tópico:

boa tarde Pode usar ACBr API.. https://dev.acbr.api.br/docs/

Boa tarde @antonio.carlos Cheguei a dar uma olhada no exemplo e bem básico ainda. Mas já é um começo! Pretendo criar uma API para emissão de NF´s.

De acordo com a NT 2025/002, o CRT 2 também está dispensado de informar IBS/CBS em 2026.

377 e abaixo: Não gera as tag's da Reforma Tributaria (testado) 378 a 384: não sei dizer 385: ok (testado)

Olá, Estava tendo esse mesmo problema. Descobri que era devido à geração incorreta do arquivo INI. Poste seu arquivo INI para que possamos analizar.

Bom dia Pessoal, Esse tópico esta ficando com muitas páginas e da forma que esta vai ficar complicado olhar as inúmeras colaborações que estão nele. Vou fechar o tópico. Por favor criem um tópico para cada cidade que tenha aderido a emissão da NFS-e segundo o Padrão Nacional ou cujo provedor implementou uma API própria ou um novo Webservice para atender a Reforma Tributária. Desde já muito obrigado pela colaboração e compreensão de todos.

Bom dia! Sim, mas pela modalidade de compartilhamento de acordo com as informações que você disponibilizou. O componente e consequentemente a Lib já está em vias de adequação. Por favor, você consegue confirmar junto ao provedor se a URL vai permanecer a mesma ou se será uma nova URL para comunicar com o web service deles para estes novos métodos relacionados a reforma tributária? Atualmente essas são as URLs que solução ACBr comunica: Produção=https://nfse.issnetonline.com.br/abrasf204/ribeiraopreto/nfse.asmx Homologação=https://www.issnetonline.com.br/homologaabrasf/webservicenfse204/nfse.asmx De posse dessa informação, podemos ter um norte para que possa começar a testar. Você pode utilizar o mesmo modelo que já utiliza, mas agora vai adicionar as seções correspondentes a Reforma Tributária que existem nesse MODELO.

Pessoal bom dia, já estamos emitindo, em homologação, NF-e e NFC-e nas regras de reforma tributária, utilizando CBS\IBS, notas de crédito, notas de venda a órgãos governamentais, quem tirar interesse em consultaria a respeito, estamos a disposição, com exemplos, XML autorizados e também re-factoring de fontes. Para quem irá precisar se aquedar ao Sped, também fazemos a emissão do mesmo, quem precisar de consultoria na geração do Sped Fiscal e Contábil, estamos a disposição, obrigado !!!

Não, você não leu errado o título da notícia. A sefaz de São Paulo está dando adeus ao SAT! Foi publicado no dia 31/10/2024 a Portaria SRE 79, DE 31 DE OUTUBRO DE 2024 que modifica a Portaria CAT147/12(responsável pela definição do SAT), acrescentando na mesma os seguintes artigos: Efetivamente impedindo a ativação de novos equipamentos SAT para quem ainda não o tinha o aparelho e estipulando a data de 01/01/2026 para o fim do SAT como um todo. Mas se eu uso o SAT o que eu vou fazer agora? A NFC-e é o documento fiscal que deverá ser utilizado no lugar do CF-e. A muito tempo, esses documentos são "intercambiáveis", com o contribuinte podendo escolher se emite uma NFC-e ou um CF-e através do SAT para acobertar a mesma operação. Eu estou um pouquinho enferrujado, mas o SAT não era a contingência da NFC-e? Não mais! A Sefaz já havia publicado previamente uma portaria autorizando o uso da contingência off-line para NFC-e no estado. Veja mais aqui:

Eu acho que o problema vai ser no layout 1.0 do próprio padrão nacional, pq esses problemas que eu tive foram todos em produção utilizando esse modelo, porém agora testando no layout 1.01 (em homologação, pq em produção ainda não está ativo) funcionou normalmente

Boa noite @Diego Foliene vou fazer as implementações e testes... Obrigado pelo retorno!