Diego Foliene

Olá comunidade ! Na data de 30/12/2025 começamos a receber múltiplos relatos de problemas ao realizar o envio de um evento de cancelamento de NFS-e junto ao Padrão Nacional. Após investigação foi constatado que houve uma atualização dos schemas no dia 26/12/2025, trazendo alterações que impactaram no envio dos eventos. Visando sanar o problema no cancelamento da NFS-e, foram enviadas ao SVN alterações nas Revisions 43956 e 43957 fazendo as correções necessárias para que o cancelamento possa ser realizado com sucesso. Portanto se você utiliza componente nativo para Delphi ou Lazarus atualize seus fontes e reinstale o ACBr. Caso utilize ACBrLibNFSe, faça o download da versão mais recente da mesma disponível no fórum: Aqueles que utilizam ACBrMonitorPLUS também precisam atualizar: É importante que além da solução ACBr, também sejam atualizados os arquivos de schema. As demais alterações trazidas pelos schemas serão revisadas na tarefa #ACBR-8678 e serão atualizadas neste tópico a medida que houverem novidades. As modificações com a atualização dos schemas que foram relacionadas são: tiposComplexos_v1.00.xsd: Elimina o grupo para exploração rodoviária; => Vai ficar na NFS-e Via agora. Elimina o grupo para locação de dutos; => Vai ficar na NFS-e Via agora. xOutInf sai do grupo valores e sobe um nível. tiposEventos.xsd: Elimina o campo nPedRegEvento.(Resolvido nas revisions 43956 e 43957) Altera a descrição dos eventos permitindo acentos e adicionando "Manifestação de NFS-e" nos eventos de manifestação. No evento TE202205 os elementos de infRej sobem de nível e o grupo deixa de existir. No evento TE203206 os elementos de infRej sobem de nível e o grupo deixa de existir. No evento TE204207 os elementos de infRej sobem de nível e o grupo deixa de existir. No evento TE205208 os elementos de infRej sobem de nível e o grupo deixa de existir. No evento TE305102 os elementos xMotivo e codEvento invertem a ordem em que aparecem no arquivo. Elimina o tipo complexo TCListaEventos tiposSimples.xsd: Elemento TSSerieDPS ganha um regex para limitar os valores possíveis no campo. TStat ganha novos valores possíveis. Elimina os eventos e907202 e e967203 Elemento TSIdPedRegEvt muda. (Resolvido nas revisions 43956 e 43957)

Entendendo o problema A Nota Técnica 2025/002 é a publicação mais recente que menciona esta rejeição. Vejam que ela identifica 3 campos diferentes: W07: Equivale ao elemento vProd do grupo ICMSTot que compõe o total da nota. I11: Equivale ao elemento vProd do grupo prod que recebe as informações do item. I17b: Equivale ao elemento indTot do grupo prod que recebe as informações do item. Sabendo disso, podemos entender que ao devolver esta rejeição, o web service da Sefaz esta nos dizendo que no arquivo XML que enviamos o valor de vProd no total na nota não coincide com a somatória dos valores de vProd dos itens em que indTot tenha valor 1. Como resolver? Revise o arquivo XML fazendo a somatória de todos os vProd dos itens cujo valor de indTot esteja preenchido como 1. <prod> ... <vProd>100.00</vProd> <indTot>1</indTot> ... </prod> ... <ICMSTot> ... <vProd>100.00</vProd> ... </ICMSTot> Verifique se os valores coincidem. Quem utiliza componente nativo para Delphi ou Lazarus, pode colocar um break-point no local indicado no print e ao usar o método ACBrNFe.NotasFiscais.ValidarRegrasDeNegocio pode conferir no debug qual é o valor esperado e qual foi a soma:

Boa tarde! Foi enviado ajuste ao SVN adicionando a leitura dessas informações no arquivo INI. Versões da LibNFSe compiladas depois de 29/12/2025 deverão englobar o ajuste. As informações serão lidas em uma seção: [IBSCBSValores] IbsMunicipal= ValorIbsMunicipal= IbsEstadual= ValorIbsEstadual= Cbs= ValorCbs=

Por favor, veja se não está ocorrendo a situação da solução 3 descrita neste tópico:

Boa tarde! Ao avaliar o arquivo de schema disponibilizado, comparando o mesmo com o schema já presente no SVN e também com exemplos de XML disponíveis na documentação, notei algumas incongruências. Por essa razão, optei por atualizar o schema existente no SVN ao invés de simplesmente substituir o mesmo. Alterações enviadas ao SVN. Por favor, queira atualizar seus fontes, reinstalar o ACBr com a opção "Apagar Arquivos Antigos" marcada no instalador para realizar novos testes e reportar qualquer problema.

Boa tarde! Por favor, os arquivos XML de envio e resposta que você menciona de fato são esses? Pergunto, pois eles são os arquivos correspondentes a uma consulta de status de serviço. Se for isso mesmo, fiz um teste utilizando as IDEs que eu tenho disponíveis, sendo elas: - Delphi 13: - Delphi 11.2: - Lazarus: - Delphi 7: E não tive nenhum problema. Por favor, se for isso mesmo: Verifique se você não tem nenhuma alteração local em seus fontes. Veja se você não tem nenhum .dcu ou .bpl do ACBr perdido em seu ambiente em local diferente do esperado (geralmente os .dcus e .bpls perdidos costumam aparecer em C:\Users\Public\Documents\Embarcadero\Studio\VersaoDoSeuDelphi Confirme se você está usando as configurações de Web Service recomendadas por tipo de certificado. (elas influenciam). Faça um teste usando as dlls da LibXML presentes AQUI. (Coloque elas na mesma pasta do seu .EXE escolhendo de acordo com a arquitetura que você compila sua aplicação e não a do SO)

Entendendo o problema De acordo com a planilha ANEXO_I-SEFIN_ADN-DPS_NFSe-SNNFSe-v1.00-20251216 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 indTotTrib Se a situação do emitente da DPS perante o Simples Nacional na data de competência informada for ME/EPP, o choice indTotTrib nunca poderá ser informado. E0712 Para ME/EPP indTotTrib nunca poderá ser informado. Ainda de acordo com o mesmo leiaute, a tag indTotTrib faz parte de um "elemento escolha" junto dos grupos vTotTrib, pTotTrib e pTotTribSN. Ou seja, o arquivo XML só vai poder ter o vTotTrib ou o pTotTrib ou o indTotTrib ou o pTotTribSN, mas nunca mais de um deles. Se você está recebendo essa rejeição, isso significa que seu arquivo está sendo enviado com o elemento indTotTrib, quando deveria ser com um dos outros 3. Como resolver? No momento de geração do XML, uma lógica é aplicada para definir qual é o grupo que vai ser gerado. Verifica se foram preenchidos os valores que compõe vTotTrib. Se forem maiores do que zero, gera o grupo vTotTrib; Se não foi gerado o grupo no passo anterior, verifica se foram preenchidos os valores que compõe pTotTrib. Se forem maiores do que zero, gera o grupo pTotTrib. Se não foi gerado o grupo no passo anterior, verifica se o valor de pTotTribSN é maior do que zero. Se for, gera o grupo pTotTribSN. Se não foi gerado o grupo no passo anterior, verifica se o valor de indTotTrib é zero, se for, gera o grupo indTotTrib. Considerando isso, é preciso preencher as informações de modo que o indTotTrib não seja gerado. Caso utilize ACBrNFSeX para Delphi e Lazarus Para gerar o vTotTrib preencha: NFSe.Servico.Valores.totTrib.vTotTribFed := NFSe.Servico.Valores.totTrib.vTotTribEst := NFSe.Servico.Valores.totTrib.vTotTribMun := NFSe.Servico.Valores.totTrib.indTotTrib := TindTotTrib.indSim; Para gerar o pTotTrib preencha: NFSe.Servico.Valores.totTrib.pTotTribFed := NFSe.Servico.Valores.totTrib.pTotTribEst := NFSe.Servico.Valores.totTrib.pTotTribMun := NFSe.Servico.Valores.totTrib.indTotTrib := TindTotTrib.indSim; Para gerar o pTotTribSN preencha: NFSe.Servico.Valores.totTrib.pTotTribSN := NFSe.Servico.Valores.totTrib.indTotTrib := TindTotTrib.indSim; Caso utilize ACBrMonitorPLUS ou ACBrLib Para gerar o vTotTrib preencha: [totTrib] vTotTribFed= vTotTribEst= vTotTribMun= indTotTrib=1 Para gerar o pTotTrib preencha: [totTrib] pTotTribFed= pTotTribEst= pTotTribMun= indTotTrib=1 Para gerar o pTotTribSN preencha: [totTrib] pTotTribSN= indTotTrib=1

Olá comunidade ! Com a adesão cada vez maior dos municípios ao Padrão Nacional de emissão da NFS-e, é imprescindível realizar a adequação de seus softwares. Parte desse processo envolve a homologação realizando o envio de notas no ambiente de testes. Neste tópico vamos orientar como vocês podem realizar esses testes utilizando o componente nativo para Delphi/Lazarus, ACBrMonitorPLUS e ACBrLibNFSe. Antes de prosseguir, é importante ressaltar que essas orientações são para testes com os municípios que aderiram ao padrão nacional como emissor. Para cidades que vão manter o provedor atual veja os este tópico Para ilustração, vamos utilizar um caso bem interessante, o município de Coxim/MS cuja informação no arquivo ACBrNFSeXServicos.ini se encontra assim: [5003306] Nome=Coxim UF=MS Provedor= Ao executar o programa exemplo, se selecionarmos este município e tentarmos salvar as configurações, devido o fato de não termos a informação de qual é o provedor que atende a este município, vamos receber a seguinte mensagem: Mas lembrem-se, nós queremos testar a emissão com o Padrão Nacional. Para isso, vamos até a aba Geral: Observem que a configuração Layout da NFS-e está definida com o valor lnfsProvedor. Como queremos usar o padrão nacional, precisamos mudar ela. Para isso temos duas opções: A opção lnfsPadraoNacionalv1 vai fazer com que o XML seja gerado e enviado com a identificação de versão 1.00. Nesta versão, o layout do padrão nacional não comporta os novos campos da reforma tributária. Já a versão lnfsPadraoNacionalv101 vai fazer com que o XML seja gerado e enviado com a identificação de versão 1.01. Nesta versão o layout do padrão nacional comporta os novos campos da reforma tributária. É ele que vamos usar. Eu selecionei a opção lnfsPadraoNacionalv101 e cliquei no botão "Salvar Configurações". Via código nativo do ACBrNFSeX, usando Delphi ou Lazarus, isso é o equivalente a fazer: //Últimas linhas da rotina que configura o componente. ACBrNFSeX1.Configuracoes.Geral.LayoutNFSE := TLayoutNFSe.lnfsPadraoNacionalv101; ACBrNFSeX1.Configuracoes.Geral.CodigoMunicipio := 5003306; Via ACBrMonitorPLUS, isso é o equivalente a enviar os comandos NFSe.SetLayoutNFSe e NFSe.SetCodigoMunicipio. NFSE.SetLayoutNFSe("2") NFSE.SetCodigoMunicipio("5003306") Via ACBrLibNFSe, isso é o equivalente a usar os métodos NFSE_ConfigGravarValor e NFSE_ConfigGravar. NFSE_ConfigGravarValor("NFSe", "LayoutNFSe", "2") NFSE_ConfigGravarValor("NFSe", "CodigoMunicipio", "5003306") NFSE_ConfigGravar() Vejam que a interface do meu programa exemplo mudou: Agora eu vou conferir se a cidade realmente aderiu ao padrão nacional para emissão ou não. Para isso eu vou usar o botão "Convênio" da aba "Consultar Parâmetros Municipais". Via código nativo para ACBrNFSeX, usando Delphi ou Lazarus, isso é equivalente a fazer: ACBrNFSeX1.ConsultarParametros(pmConvenio); Via ACBrMonitorPLUS, isso é o equivalente a enviar os comando NFSe.ConsultarParametrosNFSe: NFSE.ConsultarParametrosNFSe("2") Via ACBrLibNFSe, isso é o equivalente a utilizar o método NFSE_ConsultarParametros: NFSE_ConsultarParametros(2,"",0,"") Observem que no retorno que me foi devolvido consta a informação de que o município aderiu ao emissor nacional. Então eu posso realizar meus testes em homologação sem problemas.

Olá comunidade ! Foi publicado no dia 22/12/2025 o Ato Conjunto RFB/CGIBS Nº 1, de 22 de Dezembro de 2025 trazendo novas informações importantes relacionadas a Reforma Tributária. Art. 1 Estabelece os documentos fiscais afetados que terão IBS e CBS, além do prazo para observância em 2026. Art. 2 Define que aqueles sujeitos ao IBS e a CBS deverão emitir documento fiscal eletrônico. § 1º Serão recepcionados os seguintes documentos fiscais para registro das operações sujeitas ao IBS e a CBS: I - Nota Fiscal Eletrônica - NF-e, modelo 55; II - Nota Fiscal de Consumidor Eletrônica - NFC-e, modelo 65; III - Nota Fiscal de Serviços Eletrônica - NFS-e; IV - Conhecimento de Transporte Eletrônico - CT-e, modelo 57; V - Conhecimento de Transporte Eletrônico Para Outros Serviços - CT-e OS, modelo 67; VI - Bilhete de Passagem Eletrônico - BP-e, modelo 63; VII - Manifesto Eletrônico de Documentos Fiscais - MDF-e, modelo 58; VIII - Guia de Transporte de Valores Eletrônica - GTV-e, modelo 64; IX - Nota Fiscal de Energia Elétrica Eletrônica - NF3e, modelo 66; X - Nota Fiscal Fatura de Serviços de Comunicação Eletrônica - NFCom, modelo 62; XI - Declaração de Conteúdo Eletrônica - DC-e; e XII - Nota Fiscal de Serviço Eletrônica de Exploração de Via - NFS-e Via. § 2º Serão instituídos os seguintes documentos fiscais eletrônicos para registro das operações sujeitas ao IBS e a CBS: I - Nota Fiscal de Água e Saneamento Eletrônica - NFAg, modelo 75; II - Declaração de Regimes Específicos - DeRE; III - Nota Fiscal Eletrônica de Alienação de Bens Imóveis - NF-e ABI, modelo 77; e IV - Nota Fiscal Eletrônica do Gás - NFGas, modelo 76. § 3º Estabelece que deverá ser respeitado as competências dos comitês gestores: I - do Comitê Gestor da Nota Fiscal de Serviço Eletrônica de padrão nacional - CGNFS-e, conforme art. 62, § 4º, da Lei Complementar nº 214, de 16 de janeiro de 2025; e II - do Comitê Gestor do Simples Nacional - CGSN, conforme art. 26 da Lei Complementar nº 123, de 14 de dezembro de 2006. § 4º Serão criadas normas específicas para operações de comércio exterior. Art. 3º Até o primeiro dia do quarto mês subsequente ao da publicação da parte comum dos regulamentos do IBS e da CBS: I - não haverá aplicação de penalidades pela falta de registro dos campos do IBS e da CBS nos documentos fiscais a que se refere o art. 1º, §§ 1º e 2º; e II - será considerado atendido o requisito para a dispensa do recolhimento do IBS e da CBS, previsto no art. 348, § 1º, da Lei Complementar nº 214, de 16 de janeiro de 2025. Parágrafo único. Sem prejuízo do disposto no caput, a apuração do IBS e da CBS no ano de 2026 será realizada em caráter meramente informativo, sem efeitos tributários, desde que cumpridas as obrigações acessórias previstas na legislação. Art. 4º O disposto neste Ato Conjunto não prejudica a exigência dos documentos fiscais relativos aos demais tributos vigentes, previstos nas legislações de regência. Art. 5º Este ato será publicado no Diário Oficial da União e entrará em vigor em 01/01/2026.

Olá comunidade ! Com o advento da Reforma Tributária, a partir de 2026 os municípios devem escolher se aderem ao Padrão Nacional, seja na íntegra ou apenas na modalidade de compartilhamento de informações. Por causa disso, é importante sabermos quais maneiras existem para obtermos essa informação. Usando o Power BI do Monitoramento da Adesão dos Municípios à NFS-e Ao acessar o Monitoramento das Adesões à NFS-e, e descer a página, vemos um botão em destaque como este da imagem: Ao clicar no mesmo, somos levados a uma página criada utilizando o Power BI. Ela possui o seguinte leiaute: Para demonstração, vamos filtrar a cidade de Adamantina/SP e observar o resultado: Eu destaquei duas informações importantes. Na coluna Status, temos os dizeres "Ativo operacional", isso significa que este município aderiu ao padrão nacional. No quadro "Adesão ao Emissor Nacional da NFS-e", temos um item com o valor "Sim", isso significa que o município em questão aderiu ao padrão nacional como emissor. Ou seja, para o município de Adamantina/SP, a emissão será feita seguindo o layout do Padrão Nacional e enviada para a API do Padrão Nacional. Vamos agora filtrar o município de Aguaí/SP e destacar as mesmas partes: Na coluna Status, temos os dizeres "Ativo operacional", isso significa que este município aderiu ao padrão nacional. Observem que o quadro "Adesão ao Emissor Nacional da NFS-e" está em branco. Isso significa que essa cidade não aderiu ao Padrão Nacional como emissor. Ou seja, para este município, será utilizada a modalidade de compartilhamento de informações. Usando o Excel do Monitoramento da Adesão de Municípios à NFS-e. Na mesma página que pode ser encontrado o Power BI, se rolarmos a página temos uma opção para realizar o download do Excel. Ao exportar essa planilha para o Excel temos a seguinte exibição: Observem que os títulos das colunas tem uma espécie de "seta", ao clicar nela podemos aplicar um filtro na coluna. Vamos filtrar os mesmos municípios, começando por Adamantina/SP: Observem que a cidade tem o valor "Sim" para ambas as colunas "AderenteAmbienteNacional" e "AderenteEmissorNacional". Agora vamos filtrar pela cidade de Aguaí/SP: Observem que a cidade tem o valor "Sim" para a coluna "AderenetAmbienteNacional", mas o valor "Não" para a coluna "AderenteEmissorNacional". Usando a consulta disponibilizada pela própria API A própria API do Padrão Nacional disponibiliza um método para realizar a consulta. Para ilustração, vamos utilizar o programa exemplo nativo para Delphi e filtrar as mesmas cidades, também começando por Adamantina/SP: Vejam que foi devolvido o valor Sim para Aderente ao Ambiente Nacional e também para Aderente ao Emissor Nacional. Vamos ver Aguaí/SP agora para ver a diferença: O código utilizado no clique desse botão do exemplo é: ACBrNFSeX1.ConsultarParametros(pmConvenio); No ACBrMonitorPLUS é o comando: NFSe.ConsultarParametrosNFSe; Na ACBrLibNFSe é o método: NFSE_ConsultarParametros

Boa tarde! Foi enviado um ajuste adicionando na resposta da LibNFSe para o método novas propriedades que refletem cancelamento e substituição. Versões da LibNFSe compiladas após 22/12/2025 deverão englobar a alteração.

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.

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

Boa tarde! Muito obrigado pela contribuição! Toda e qualquer colaboração é e sempre será mais do que bem vinda! Foi enviado ao SVN na Rev-43720 um ajuste que visa resolver essa questão. Por favor, queira atualizar seus fontes, reinstalar o ACBr com a opção "Apagar Arquivos Antigos" marcada no instalador para que possa realizar novos testes e reportar qualquer problema.

Boa tarde! Mais uma vez muito obrigado pela contribuição! Aproveitei a ideia, mas fiz um pequeno ajuste nela. Enviado ao SVN na Rev-43720. Por favor, queira atualizar seus fontes, reinstalar o ACBr com a opção "Apagar Arquivos Antigos" marcada no instalador para que possa realizar novos testes e reportar qualquer problema.

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.

Olá comunidade ! Por volta das 08h13, começamos a receber múltiplos relatos de problemas ao comunicar com a Sefaz de São Paulo para emissão de NFe e NFCe. Ao conferir no DownDetector, foi possível observar que o volume de relatos de problemas aumentou exponencialmente durante esse período: Também recebemos relatos de problemas de comunicação com a Sefaz Bahia e instabilidade na Sefaz Parana. Após maiores investigações, foi encontrada a informação de que a própria Cloud Flare está passando por problemas, justificando assim essas instabilidades: Vale lembrar que a Cloud Flare é uma ferramenta utilizada por uma grande parcela de sites na internet (incluindo o próprio fórum do Projeto ACBr) para segurança e robustez, protegendo os mesmos de ataques DDOS, por exemplo. Portanto, essa instabilidade pode impactar diversos serviços de emissão, seja diretamente com a própria Sefaz usando ou indiretamente quando a sefaz não utiliza, mas a certificadora, por exemplo sim. Acompanhe o status da Cloud Flare por AQUI.

Bom dia! Muito obrigado pela contribuição! Criada a tarefa ACBr-8597 para análise da mesma e disponibilização no SVN.

Uma das premissas desse novo sistema é a integração à REDESIM e atendimento aos seus critérios, viabilizando a simplificação através da automatização dos pedidos de inscrição e demais mutações cadastrais, notificações e também da análise das solicitações das empresas que não exercerem atividades sujeitas a procedimento especial pela fiscalização do ICMS. As mudanças ocasionadas devido a adoção o e-CCE são: Em primeiro momento, o novo sistema será destinado a atender todos os contribuintes (pessoa jurídica) do Comércio, Industria e Serviço (CCIS), cuja geração de nova inscrição será iniciada com o dígito 50, sem alteração do número das inscrições antigas; O atual sistema será mantido para atender todos os contribuintes (pessoa física e jurídica) no Cadastro da Agropecuária (CAP), sendo que tanto as inscrições antigas assim como os novos inscritos no Cadastro de Agricultura e Pecuária (CAP) serão iniciadas com dígito 28; Em todos os casos (CCIS ou CAP, início com dígito 28 ou 50) não haverá atribuição de intervalos (range) para identificar o tipo de cadastro. Atualmente já existe um campo identificador para o tipo de contribuinte e o mesmo permanecerá no e-CCE; A manutenção dos dois sistemas simultâneos será transitória, até que seja definido o tratamento que será dado aos produtores rurais após o início da Reforma Tributária; Extinção dos cadastros específicos para Transportadores Autônomos de Cargas (TAC Pessoa Física) e de artesãos pessoas físicas (Cadastro Especial de Artesão-CEA), passando a exigir cadastramento no CNPJ dos mesmos; Harmonização das situações cadastrais com as demais Unidades Federativas e Receita Federal (ativa, suspensa, baixada, inapta e nula), sendo que as situações do CNPJ refletirão automaticamente na situação da inscrição estadual conforme definido pela área de negócio; A situação BAIXA NÃO HOMOLOGADA será inativada e substituída pelo indicador “Pendente de Verificação Fiscal” a fim de identificar as empresas que ainda não foram auditadas após a baixa; A situação CANCELADO será inativada e substituída pela INAPTA, mantendo-se os mesmos motivos e acrescentando-se os importados da REDESIM; A situação PROVISÓRIA será inativada e substituída pelo indicador “Fase Pré Operacional” a fim de identificar as empresas que estão em fase de construção e montagem; Será utilizada apenas a tabela de Classificação Nacional de Atividades Econômicas (CNAE), que é um sistema de padronização nacional, e não mais o CAE como identificador da atividade do contribuinte; A lista de atividades marcadas como de interesse do ICMS foi definida com base na CNAE e conforme as seguintes premissas: Atividades não incluídas na lista de serviços anexa à LC 116/2003 serão tratadas como de interesse e serão geradas solicitações de inscrição automaticamente; b) Atividades incluídas na lista de serviços de competência dos municípios que a LC 116/2003 excetua a aplicação de partes e peças, serão tratadas como de não interesse (Exemplo: Manutenção, reparação e instalação de máquinas e equipamentos descritos na divisão 33). Empresas que se enquadrarem nesta hipótese e optar por se inscrever no Estado deverá incluir no seu objeto CNAE de comércio; Adoção do Cadastro de Pessoa (física e jurídica) como base principal para os demais cadastros; Não exigência de documentos e/ou dados já constantes na base de dados do Estado ou órgãos conveniados para comprovação das informações relativas à pessoa, ao endereço, ao quadro societário, ao Profissional da Contabilidade ou ao estabelecimento; Recadastramento de todas as empresas e microempreendedores no Cadastro de Contribuintes do Comércio, Indústria e Serviços (CCIS), o qual será de forma automática, necessitando apenas que empresários e Profissionais da Contabilidade acessem o módulo “Meus Cadastros” para finalizar a atualização do CCIS. Foi criada a tarefa ACBR-8586 para atualização do ACBrValidador para contemplar as novas IEs que podem iniciar em 50. Um agradecimento ao membro de nossa comunidade @Jonas RCK por compartilhar a informação em nosso Discord. A notícia original pode ser encontrada AQUI.

Boa tarde!

Olá comunidade ! Informamos que as classes de auto nível disponíveis em C# para auxiliar na geração do arquivo INI que é passado para a LibNFe (também chamado por alguns de SDK). Foram atualizadas e estão de acordo com a versão 1.30 da Nota Técnica! As alterações foram enviadas na ACBrLib.Core e na ACBrLib.NFe respectivamente nas revisions 43592 e 43593. O programa exemplo em C# também foi atualizado! Caso utilize os pacotes Nuget do ACBr ao invés das classes diretamente do SVN, a versão 1.2.33 do pacote ACBrLib.Core, a versão 1.0.24 do pacote ACBrLib.NFeMT e a versão 1.0.26 do pacote ACBrLib.NFe englobam as atualizações.

Entendendo o problema De acordo com a planilha ANEXO_I-SEFIN_ADN-DPS_NFSe-SNNFSe.xlsx 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 opSimpNac Opção de situação perante o Simples Nacional do prestador, informada na DPS, não está de acordo com o cadastro Simples Nacional na data de competência informada na DPS. Se CNPJ do prestador não consta no cadastro então opSimpNac é igual a 1; 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. Ainda de acordo com o mesmo arquivo, esses são os valores válidos para este campo: Portanto, se você está recebendo esta rejeição, o valor enviado na tag opSimpNac está incorreto de acordo com as informações cadastrais internas que a API possui sobre o prestador de serviços. Como resolver? Certifique-se de que o valor correto foi enviado na tag opSimpNac. Em caso de dúvidas sobre qual é a situação do prestador de serviços, confirme junto ao mesmo. Consultar o CNPJ também pode ajudar. Caso utilize ACBrNFSeX para Delphi e Lazarus, a propriedade que alimenta a tag no arquivo XML é: NFSE.OptanteSN; Ela é do tipo TOptanteSN e pode receber os valores osnNaoOptante, osnOptanteMEI ou osnOptanteMEEPP. Certifique-se de alimentar a propriedade com o valor correto e correspondente. Caso utilize ACBrMonitorPLUS ou ACBrLib Defina o valor na chave opSimpNac da seção [Prestador] no arquivo INI que estiver utilizando para gerar a NFSe. Não confundir com a chave OptanteSN