Diego Foliene

Olá comunidade ! Foi publicada a versão 1.50 da nota técnica 2025/002 trazendo uma reformulação do layout da tributação monofásica de combustíveis e regras de validação. Alterações O grupo gIBSCBSMono, gMonoPadrao, gMonoRet e gMonoDif foram removidos. Agora os novos grupos dividem as informações em ad rem e ad valorem. A nova estrutura agora é: gIBSCBSMono gIBSMonoAdRem (CG) gMonoPadrao gMonoReten gMonoRet gpBioDiferenca gIBSMonoAdValorem (CG) gMonoPadrao gMonoReten gMonoRet gpBioDiferenca gCBSMonoAdRem (CG) gMonoPadrao gMonoReten gMonoRet gpBioDiferenca gCBSMonoAdValorem (CG) gMonoPadrao gMonoReten gMonoRet gpBioDiferenca Remove a regra de validação que devolvia a rejeição "1057 - Finalidade da NFe informada incorretamente para esta Classificação Tributária do IBS e da CBS". Adiciona novas regras de validação para os novos grupos de monofasia adicionados. Datas Implantação Teste: 01/09/2026 Implantação Produção: 03/11/2026 Vale ressaltar que apesar da publicação da NT e das datas definidas na mesma, até a publicação deste tópico ainda não foram disponibilizados novos schemas correspondentes as alterações de layout mencionadas. E como fica o ACBr? Alterações nas soluções ACBr serão necessárias. Foi criada a tarefa ACBR-9462 para adequar o componente. Qualquer novidade será divulgada neste tópico. Leia a versão 1.50 desta nota técnica na íntegra AQUI.

Bom dia! Por favor, o prestador de serviços era MEI ou Optante pelo Simples Nacional?

Foi publicada a versão 26.1.K das tabelas fornecidas pelo IBPT, às quais já se encontram também em nosso SVN. As novas tabelas tem a vigência de 20/05/2026 até 30/06/2026. Para cumprimento da Lei 12.741/12, também conhecida como "De Olho no Imposto", não se esqueça de realizar a atualização de seus clientes. Fonte: De Olho no Imposto

Boa tarde! Após uma pesquisa mais aprofundada foi possível averiguar que este município está utilizando o provedor Fiorilli em uma implementação que recepciona os arquivos XMLs no mesmo leiaute do Padrão Nacional. Veja mais sobre isso nesse tópico: Sendo assim, basta atualizarmos no arquivo ACBrNFSeXServicos.ini. No entanto, precisamos da URL do web service para fazer essa atualização e esta URL: Não está abrindo aqui em meu ambiente.

@Thais Guelf Complementando a resposta do colega acima, por favor, veja especificamente o "Usando a consulta disponibilizada pela própria API" do tópico abaixo: O PowerBI e a planilha mostram apenas a configuração correspondente no ambiente de produção. Faça a consulta de convênio nos dois ambientes. Existem múltiplos casos de cidades em que o a configuração foi feita somente no ambiente de produção e ai ao emitir no ambiente de homologação é devolvida essa mensagem, mesmo a cidade aparecendo como configurada no power BI.

Olá comunidade ! Foi publicada a Nota Técnica 2026/001 v1.00 para o MDF-e discorrendo sobre regra de validação para este documento. Alteração A nova NT não traz alterações no leiaute, ela apenas traz uma regra de validação que segue: Datas Implantação Homologação: 21/09/2026 Implantação Produção: 23/11/2026 Vale ressaltar que apesar das datas presentes na NT para a ativação da regra de validação, já existe Resolução que obriga o CIOT no MDF-e. E como fica o ACBr? Alterações no ACBr não são necessárias. Leia a nota técnica na íntegra AQUI.

Boa tarde! Isso é um erro de validação de schema. Você está enviando um valor maior do que 4 dígitos e por isso a API tenta formatar para você automaticamente no formato DD.DD.DD considerando que é um Código de Tributação nacional. Se conferirmos nos arquivos de schema, essa é a definição do elemento ItemListaServico: <xs:element name="ItemListaServico" type="xs:decimal" /> Observe que ele é definido como um tipo decimal, ou seja, ele só pode ter um ponto, no formato DD.DD significando que esse provedor requer que seja enviado a informação no LC116/03. Esse valor 1405 faz com que a informação seja gerada no formato correto para o campo no XML. Agora você não teve um problema de validação de schema. O problema agora foi o ambiente de homologação desse município que está fora, vide painel disponível em Município de Teutônia - Homologação:

Enquanto essa questão era debatida, um dos consultores levantou um ponto. Aqui é pedido que sejam emitidas notas em homologação antes de emitir em produção. Isso é uma exigência do município ou do provedor? Aqui é confirmado que os leiautes do ambiente de homologação e de produção são diferentes. Em homologação você precisa gerar o XML no leiaute do Padrão Nacional, mas em produção você precisa gerar o leiaute no padrão ABRASF. Os testes parecem (por falta de palavra melhor) "contra-producentes". Se você vai testar em um ambiente e leiaute para depois enviar em produção em outro ambiente e leituate completamente diferentes, os testes não parecem "testar algo" de fato. Vamos tentar um contato junto ao provedor para entender melhor isso, mas se possível, por favor, tente também entrar em contato com eles pedindo mais esclarecimentos.

Boa tarde! Hmm, isso complica um pouco a situação. O componente tem classes diferentes para trabalhar com ABRASF e para trabalhar com a API Própria do Padrão Nacional. Vamos verificar como podemos contornar essa questão e retornamos aqui o mais breve possível com novidades.

Olá, comunidade! O arquivo ACBrNFSeXServicos.ini é de vital importância para o correto funcionamento do componente ACBrNFSeX, do ACBrMonitorPLUS e da ACBrLibNFSe. Ele centraliza as URLs dos web services utilizados pelos municípios, bem como as configurações e particularidades de cada cidade no que diz respeito à emissão de NFS-e. Essas particularidades podem ser definidas dentro da chave Params, que pode ser utilizada tanto na seção da cidade quanto na seção do provedor dentro do arquivo INI. A seguir, detalharemos os valores possíveis para essa chave e o efeito prático de cada um deles. AliasCidade Parâmetro considerado e utilizado atualmente pelos provedores DataSmart, GeisWeb, Horus e SiapSistemas. Sua finalidade é definir uma informação que vai ser utilizada dentro do arquivo XML. Exemplo Este é um exemplo de uso desse parâmetro: [3111101] ; Incluído em 09/06/2022 Nome=Campina Verde UF=MG Provedor=Horus Params=AliasCidade:campinaverde ProRecepcionar=http://campinaverde.horusdm.com.br/service O XML gerado usou o AliasCidade para definir um namespace: <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ser="http://campinaverde.horusdm.com.br/service?wsdl"> CodigoCidade Parâmetro considerado e utilizado atualmente pelos provedores eISS, Equiplano, ISSMap, PublicSoft e SmarAPD. Sua finalidade é identificar o município por um código próprio utilizado pelo provedor. Exemplo Este é um exemplo de uso desse parâmetro: [4100806] Nome=Alvorada do Sul UF=PR Provedor=Equiplano Params=CodigoCidade:350 O XML gerado usou essa informação para a tag idEntidade: <prestador> <nrCnpj>pseudoCNPJ</nrCnpj> <nrInscricaoMunicipal>pseudoIM</nrInscricaoMunicipal> <isOptanteSimplesNacional>1</isOptanteSimplesNacional> <idEntidade>350</idEntidade> </prestador> Assinar Parâmetro considerado e utilizado atualmente pelos provedores Fiorilli e IPM. Sua finalidade é identificar o XML de quais métodos serão assinados digitalmente e até mesmo aqueles que não precisam de assinatura. Seus valores válidos são: AssRps, AssLoteRps, AssConsultarSituacao, AssConsultarLote, AssConsultarNFSeRps, AssConsultarNFSe, AssCancelarNFSe, AssRpsGerarNFSe, AssLoteGerarNFSe, AssRpsSubstituirNFSe, AssSubstituirNFSe, AssAbrirSessao, AssFecharSessao, AssinarTudo e NaoAssinar. Pode ser utilizado em conjunto, por exemplo: "Params=Assinar:AssRpsGerarNFSe,AssCancelarNFSe" Exemplo [1301902] ; Incluído em 21/05/2024 Nome=Itacoatiara UF=AM Provedor=Fiorilli Versao=2.00 Params=Assinar:NaoAssinar ProRecepcionar=http://187.61.97.69:8080/IssWeb-ejb/IssWebWS/IssWebWS ProLinkURL=http://187.61.97.69:8080/issweb/formGerarNF.jsf?nroNota=%NumeroNFSe%&codVerificacao=%CodVerif%&cnpj=%Cnpj%&hash=%ChaveAcesso% O XML gerado não foi assinado: <EnviarLoteRpsSincronoEnvio> <LoteRps> <ListaRps> <Rps> <InfDeclaracaoPrestacaoServico> ... </InfDeclaracaoPrestacaoServico> </Rps> </ListaRps> </LoteRps> </EnviarLoteRpsSincronoEnvio> GerarTag Parâmetro considera e utilizado atualmente pelo provedor IPM. Sua finalidade é fazer com que uma tag que tenha cardinalidade opcional no XML passe a ter uma cardinalidade obrigatória sendo gerada sempre independente do valor informado. Exemplo [4101507] Nome=Arapongas UF=PR Provedor=IPM Versao=1.01 Params=GerarTag:codigo_atividade ProRecepcionar=https://ws-arapongas.atende.net/atende.php?pg=rest&service=WNERestServiceNFSe HomRecepcionar=https://ws-arapongas.atende.net/atende.php?pg=rest&service=WNERestServiceNFSe NaoGerarTag Parâmetro considerado e utilizado atualmente pelo provedor Agili. Sua finalidade é fazer com uma tag no XML assuma cardinalidade -1, não sendo gerada nunca, independente do valor informado. Exemplo [5105101] Nome=Juara UF=MT Provedor=Agili Params=NaoGerarTag:ItemLei116 VersaoArquivo Parâmetro considerado pelo provedor Governa. Nenhum município é atendido por este provedor e portanto esse parâmetro não está sendo utilizado atualmente no ACBrNFSeXServicos.ini Sua finalidade é indicar uma informação que pode ser utilizada em uma tag especifica do arquivo XML. Exemplo [5222203] Nome=Vila Boa UF=GO Provedor=Governa Params=VersaoArquivo:2| VersaoImpressao Parâmetro considerado pelo provedor Governa. Nenhum município é atendido por este provedor e portanto esse parâmetro não está sendo utilizado atualmente no ACBrNFSeXServicos.ini Sua finalidade é indicar uma informação que pode ser utilizada em uma tag especifica do arquivo XML. Exemplo [5222203] Nome=Vila Boa UF=GO Provedor=Governa Params=VersaoImpressao:2| DataEmissao Parâmetro considerado e utilizado pelo provedor Actcon. Seus valores válidos são Date e DateTime. Sua finalidade é definir se os campos de data no arquivo XML vão ser formatados de forma a considerar somente a data ou a data e a hora. Exemplo [3170057] Nome=Ubaporanga UF=MG Provedor=Actcon Versao=2.02 Params=DataEmissao:Date ProRecepcionar=https://nfse-mg-ubaporanga.portalfacil.com.br/nfseserv/webservice/servicos ProXMLNameSpace=http://nfse-mg-ubaporanga.portalfacil.com.br/nfseserv/schema/nfse_v202.xsd ProNameSpace=http://nfse-mg-ubaporanga.portalfacil.com.br/nfseserv/webservice/nfse.wsdl ProSoapAction=http://nfse-mg-ubaporanga.portalfacil.com.br/nfseserv/webservice/servicos# HomRecepcionar=https://nfse-mg-ubaporanga.portalfacil.com.br/homologacao/webservice/servicos HomXMLNameSpace=http://nfse-mg-ubaporanga.portalfacil.com.br/homologacao/schema/nfse_v202.xsd HomNameSpace=http://nfse-mg-ubaporanga.portalfacil.com.br/homologacao/webservice/nfse.wsdl HomSoapAction=http://nfse-mg-ubaporanga.portalfacil.com.br/homologacao/webservice/servicos# Aliquota4Casas Parâmetro considerado e utilizado atualmente pelos provedores Giap, RLZ e SimplISS. Sua finalidade é fazer com que o valor informado na tag Aliquota (ou correspondente) seja formatado possuindo 4 casas decimais independente do valor informado na propriedade. No momento esse parâmetro não é utilizado por nenhum dos municípios atendidos por este provedor. Exemplo [3505500] Nome=Barretos UF=SP Provedor=RLZ Params=Aliquota4Casas: ProRecepcionar=https://cidadaoonline.barretos.sp.gov.br/nota/nacional HomRecepcionar=https://barretos.prefeitura.rlz.com.br/nota/nacional Aliquota2Casas Parâmetro considerado e utilizado independente do provedor. Sua finalidade é fazer com que o valor informado na tag Aliquota (ou correspondente) seja formatado possuindo 2 casas decimais independente do valor informado na propriedade. No momento esse parâmetro não é utilizado por nenhum dos municípios atendidos por este provedor. [3505500] Nome=Barretos UF=SP Provedor=RLZ Params=Aliquota2Casas: ProRecepcionar=https://cidadaoonline.barretos.sp.gov.br/nota/nacional HomRecepcionar=https://barretos.prefeitura.rlz.com.br/nota/nacional TagAliquotaObrigSN Parâmetro considerado pelo provedor ISSNet. Sua finalidade é definir com que a cardinalidade da tag Aliquota seja obrigatório para prestadores de serviço optantes pelo simples nacional, fazendo com que a tag seja gerada independente do valor informado. No momento, nenhum município faz uso deste parâmetro. Exemplo [1501303] Nome=Barcarena UF=PA Provedor=ISSNet Params=TagAliquotaObrigSN: ProRecepcionar=https://abrasf.issnetonline.com.br/webserviceabrasf/barcarena/servicos.asmx TagValorISSObrigSN Parâmetro considerado pelo provedor ISSNet. Sua finalidade é definir com que a cardinalidade da tag ValorISS seja obrigatório para prestadores de serviço optantes pelo simples nacional, fazendo com que a tag seja gerada independente do valor informado. No momento, nenhum município faz uso deste parâmetro. Exemplo [1501303] Nome=Barcarena UF=PA Provedor=ISSNet Params=TagValorISSObrigSN: ProRecepcionar=https://abrasf.issnetonline.com.br/webserviceabrasf/barcarena/servicos.asmx NaoDividir100 Parâmetro considerado pelos provedores Abaco, Actcon, BHISS, EL, Giap, Ginfes, GovDigital, ISSIntel, ISSNet, MetropolisWEb, NFEletronica, Publica, Sudoeste, Thema e Tinus. Sua finalidade é fazer com que o valor informado para a tag Aliquota (ou equivalente) não seja dividido por 100 antes no momento de ser preenchido no arquivo XML. Exemplo [1501303] Nome=Barcarena UF=PA Provedor=ISSNet Params=NaoDividir100: ProRecepcionar=https://abrasf.issnetonline.com.br/webserviceabrasf/barcarena/servicos.asmx Foi informado o valor 2.00 na propriedade que alimenta a alíquota e o valor 2.00 foi gerado no XML: <tc:Aliquota>2.0000</tc:Aliquota> Dividir100 Parâmetro considerado e utilizado independente do provedor. Sua finalidade é fazer com que o valor informado para a tag Aliquota (ou equivalente) seja dividido por 100 antes no momento de ser preenchido no arquivo XML. Exemplo [1501303] Nome=Barcarena UF=PA Provedor=ISSNet Params=Dividir100: ProRecepcionar=https://abrasf.issnetonline.com.br/webserviceabrasf/barcarena/servicos.asmx Foi informado o valor 2.00 na propriedade que alimenta a alíquota e o valor 0.02 foi gerado no XML: <tc:Aliquota>0.0200</tc:Aliquota> SolicitarCancelamento Parâmetro considerado e utilizado pelo provedor IPM. Sua finalidade é fazer definir se o pedido de cancelamento deve ser enviado dentro de um elemento solicitacao_cancelamento ou não. Exemplo [3114204] Nome=Carmo do Cajuru UF=MG Provedor=IPM Versao=1.01 Params=SolicitarCancelamento: ProRecepcionar=https://carmodocajuru.atende.net/atende.php?pg=rest&service=WNERestServiceNFSe&cidade=padrao HomRecepcionar=https://carmodocajuru.atende.net/atende.php?pg=rest&service=WNERestServiceNFSe&cidade=padrao Com o parâmetro o XML gerado ficou dessa forma: <solicitacao_cancelamento> <prestador> <cpfcnpj>pseudoCNPJ</cpfcnpj> <cidade>4283</cidade> </prestador> <documentos> <nfse> <numero>1</numero> <serie>1</serie> <observacao>Motivo do Cancelamento</observacao> </nfse> </documentos> </solicitacao_cancelamento> Sem ele, o XML ficou conforme exemplo: <nfse> <nf> <numero>1</numero> <serie_nfse>1</serie_nfse> <situacao>C</situacao> <observacao>Motivo do Cancelamento</observacao> </nf> <prestador> <cpfcnpj>pseudoCNPJ</cpfcnpj> <cidade>4283</cidade> </prestador> </nfse> NaoSuprimirDecimais Parâmetro considerado e utilizado pelo provedor Pronim. No momento, nenhum município no ACBrNFSeXServicos.ini faz uso desse parâmetro. Sua finalidade é fazer com que valores decimais não sejam arredondados e suprimidos. Exemplo [5222203] Nome=Vila Boa UF=GO Provedor=Pronim Params=NaoSuprimirDecimais: SuprimirDecimais Parâmetro considerado e utilizado pelo provedor Pronim. No momento, nenhum município no ACBrNFSeXServicos.ini faz uso desse parâmetro. Sua finalidade é fazer com que valores decimais sejam arredondados e suprimidos. Exemplo [5222203] Nome=Vila Boa UF=GO Provedor=Pronim Params=SuprimirDecimais: NomeTagAtividadeEconomica Parâmetro considerado e utilizado pelo provedor Agili. Sua finalidade é definir o nome da tag que vai receber o valor da atividade econômica no arquivo XML. Exemplo [1505031] Nome=Novo Progresso UF=PA Provedor=Agili Params=NomeTagAtividadeEconomica:ItemLei116AtividadeEconomica| No arquivo XML gerado a tag assumiu o nome informado: <ItemLei116AtividadeEconomica>00.10.50</ItemLei116AtividadeEconomica> Se eu mudar para CodigoCnaeAtividadeEconomica essa alteração é refletida no arquivo gerado: <CodigoCnaeAtividadeEconomica>62.0.3-1.00</CodigoCnaeAtividadeEconomica> URLProducao Parâmetro considerado e utilizado pelo provedor VersaTecnologia. Sua finalidade é definir uma informação de namespace presente no arquivo XML quando configurado o ambiente de produção Exemplo [3171600] Nome=Virgem da Lapa UF=MG Provedor=VersaTecnologia Versao=2.04 Params=URLProducao:virgemdalapa.nfsebrasil.net.br| ProRecepcionar=http://virgemdalapa.nfsebrasil.net.br/webservices/2.04/servicos ProNameSpace=http://virgemdalapa.nfsebrasil.net.br/webservices/2.04/nfse_v204.xsd ProXMLNameSpace=http://virgemdalapa.nfsebrasil.net.br/webservices/2.04/nfse_v204.xsd No arquivo XML a informação ficou conforme exemplo: <EnviarLoteRpsSincronoEnvio xmlns="http://virgemdalapa.nfsebrasil.net.br/webservices/2.04/nfse_v204.xsd"> URLHomologacao Parâmetro considerado e utilizado pelo provedor VersaTecnologia. Sua finalidade é definir uma informação de namespace presente no arquivo XML quando configurado o ambiente de homologação Exemplo [3171600] Nome=Virgem da Lapa UF=MG Provedor=VersaTecnologia Versao=2.04 Params=URLHomologacao:homologacaovirgemdalapa.agilistecnologia.com.br ProRecepcionar=http://virgemdalapa.nfsebrasil.net.br/webservices/2.04/servicos ProNameSpace=http://virgemdalapa.nfsebrasil.net.br/webservices/2.04/nfse_v204.xsd ProXMLNameSpace=http://virgemdalapa.nfsebrasil.net.br/webservices/2.04/nfse_v204.xsd No arquivo XML a informação ficou conforme exemplo: <EnviarLoteRpsSincronoEnvio xmlns="http://homologacaovirgemdalapa.agilistecnologia.com.br/webservices/2.04/nfse_v204.xsd"> NaoGerarGrupoRps Parâmetro considerado e utilizado pelo provedor IPM. Sua finalidade é fazer com que não seja gerado o grupo <rps> no arquivo XML. Exemplo [4104204] Nome=Campo Largo UF=PR Provedor=IPM Versao=1.01 Params=NaoGerarGrupoRps: ProRecepcionar=https://ws-campolargo.atende.net/atende.php?pg=rest&service=WNERestServiceNFSe HomRecepcionar=https://ws-campolargo.atende.net/atende.php?pg=rest&service=WNERestServiceNFSe Sem a presença desse parâmetro este grupo é gerado no arquivo: <rps> <nro_recibo_provisorio>1</nro_recibo_provisorio> <serie_recibo_provisorio>85</serie_recibo_provisorio> <data_emissao_recibo_provisorio>02/06/2026</data_emissao_recibo_provisorio> <hora_emissao_recibo_provisorio>09:10:01</hora_emissao_recibo_provisorio> </rps> GerarGrupoRps Parâmetro considerado e utilizado pelo provedor SystemPro. Nenhum município é atendido por este provedor e portanto esse parâmetro não está sendo utilizado atualmente no ACBrNFSeXServicos.ini Sua finalidade é fazer com que o grupo RPS seja gerado no arquivo XML. Exemplo [5222203] Nome=Vila Boa UF=GO Provedor=SystemPro Params=GerarGrupoRps: NaoFormatarItemServico Parâmetro considerado e utilizado independente do provedor. Sua finalidade é fazer com que o valor informado para gerar a tag ItemListaServico (ou equivalente) seja formatado resultando na tag com somente os números sem considerar pontuação. Exemplo [3547809] Nome=Santo Andre UF=SP Provedor=Ginfes Params=NaoFormatarItemServico: ProLinkURL=http://santoandre.ginfes.com.br/report/consultarNota?__report=nfs_ver4&cdVerificacao=%CodVerif%&numNota=%NumeroNFSe%&cnpjPrestador=null HomLinkURL=http://santoandre.ginfesh.com.br/report/consultarNota?__report=nfs_ver4&cdVerificacao=%CodVerif%&numNota=%NumeroNFSe%&cnpjPrestador=null Ao alimentar na propriedade o valor 04.10 a tag é gerada no arquivo XML assim: <ns4:ItemListaServico>0410</ns4:ItemListaServico> NaoFormatarItemServicoSemZeroEsquerda Parâmetro considerado e utilizado independente do provedor. Sua finalidade é fazer com que o valor informado para gerar a tag ItemListaServico (ou equivalente) seja formatado de forma que no XML não seja considerado zeros a esquerda e pontuação. Exemplo [3547809] Nome=Santo Andre UF=SP Provedor=Ginfes Params=NaoFormatarItemServicoSemZeroEsquerda: ProLinkURL=http://santoandre.ginfes.com.br/report/consultarNota?__report=nfs_ver4&cdVerificacao=%CodVerif%&numNota=%NumeroNFSe%&cnpjPrestador=null HomLinkURL=http://santoandre.ginfesh.com.br/report/consultarNota?__report=nfs_ver4&cdVerificacao=%CodVerif%&numNota=%NumeroNFSe%&cnpjPrestador=null Ao alimentar o valor 04.10 a tag é gerada no arquivo XML assim: <ns4:ItemListaServico>410</ns4:ItemListaServico> FormatarItemServicoSemZeroEsquerda Parâmetro considerado e utilizado independente do provedor. Sua finalidade é fazer com que o valor informado para gerar a tag ItemListaServico (ou equivalente) seja formatado de forma que no XML não seja considerado zeros a esquerda, mas a pontuação seja considerada. Exemplo [3547809] Nome=Santo Andre UF=SP Provedor=Ginfes Params=FormatarItemServicoSemZeroEsquerda: ProLinkURL=http://santoandre.ginfes.com.br/report/consultarNota?__report=nfs_ver4&cdVerificacao=%CodVerif%&numNota=%NumeroNFSe%&cnpjPrestador=null HomLinkURL=http://santoandre.ginfesh.com.br/report/consultarNota?__report=nfs_ver4&cdVerificacao=%CodVerif%&numNota=%NumeroNFSe%&cnpjPrestador=null Ao alimentar o valor 04.10 a tag é gerada no arquivo XML assim: <ns4:ItemListaServico>4.10</ns4:ItemListaServico> FormatarItemServicoNaoSeAplica Parâmetro considerado e utilizado independente do provedor. Sua finalidade é fazer com que o componente não tente normatizar a informação alimentada para que se enquadre no formato comumente esperado pela LC116/003 ou pelos códigos de tributação nacionais. Exemplo [3547809] Nome=Santo Andre UF=SP Provedor=Ginfes Params=FormatarItemServicoNaoSeAplica: ProLinkURL=http://santoandre.ginfes.com.br/report/consultarNota?__report=nfs_ver4&cdVerificacao=%CodVerif%&numNota=%NumeroNFSe%&cnpjPrestador=null HomLinkURL=http://santoandre.ginfesh.com.br/report/consultarNota?__report=nfs_ver4&cdVerificacao=%CodVerif%&numNota=%NumeroNFSe%&cnpjPrestador=null Ao alimentar o valor 41 a tag é gerada no arquivo XML mantendo o mesmo valor: <ns4:ItemListaServico>41</ns4:ItemListaServico> ParametroExtra Parâmetro considerado e utilizado pelo provedor IPM. Sua finalidade é armazenar uma informação que é concatenada nas URLs das requisições para que o provedor devolva um arquivo XML no retorno ao invés de somente um HTML. Exemplo [4309605] Nome=Horizontina UF=RS Provedor=IPM Versao=1.01 Params=ParametroExtra:eletron=1| ProRecepcionar=https://horizontina.atende.net/?pg=rest&service=WNERestServiceNFSe HomRecepcionar=https://horizontina.atende.net/?pg=rest&service=WNERestServiceNFSe ProLinkURL=https://horizontina.atende.net/autoatendimento/servicos/consulta-de-autenticidade-de-nota-fiscal-eletronica-nfse/detalhar/1/identificador/%CodVerif% HomLinkURL=https://horizontina.atende.net/autoatendimento/servicos/consulta-de-autenticidade-de-nota-fiscal-eletronica-nfse/detalhar/1/identificador/%CodVerif% SubVersao Parâmetro considerado e utilizado pelos provedores Betha, SigCorp e SmarAPD. Ele deve ser utilizado para que o componente possa definir algumas informações de estrutura de arquivo específicas para alguns municípios que se utilizam do mesmo provedor, na mesma versão de leiaute, mas com uma estrutura de tags de envelope diferentes. Exemplo [2101202] Nome=Bacabal UF=MA Provedor=SigCorp Versao=2.04 Params=SubVersao:1| ProRecepcionar=https://abrasfbacabal.meumunicipio.online/ws/nfs HomRecepcionar=https://testebacabal.meumunicipio.online/abrasf/ws/nfs ProNameSpace=https://abrasfbacabal.meumunicipio.online/ws/nfs HomNameSpace=https://testebacabalabrasf.meumunicipio.online/ws/nfs ProSoapAction=nfs HomSoapAction=nfs Com esse parâmetro, a estrutura do envelope de requisição enviado é essa: <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ws="https://testebacabalabrasf.meumunicipio.online/ws/nfs"> <soapenv:Header/> <soapenv:Body> <ws:RecepcionarLoteRpsSincronoRequest> <nfseCabecMsg>&lt;...&gt;</nfseCabecMsg> <nfseDadosMsg>&lt;EnviarLoteRpsSincronoEnvio xmlns="http://www.abrasf.org.br/nfse.xsd"&gt;...&lt;/EnviarLoteRpsSincronoEnvio&gt;</nfseDadosMsg> </ws:RecepcionarLoteRpsSincronoRequest> </soapenv:Body> </soapenv:Envelope> E sem ele é essa: <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ws="https://testebacabalabrasf.meumunicipio.online/ws/nfs"> <soapenv:Header/> <soapenv:Body> <ws:RecepcionarLoteRpsSincrono> <xml><![CDATA[<EnviarLoteRpsSincronoEnvio xmlns="http://www.abrasf.org.br/nfse.xsd">...</EnviarLoteRpsSincronoEnvio>]]></xml> </ws:RecepcionarLoteRpsSincrono> </soapenv:Body> </soapenv:Envelope> APIPropria Parâmetro utilizado pelos provedores ABase, Betha, Citta, Coplan, DBSeller, Digifred, EL, Fiorilli, Infisc, ISSDigital, ISSNet, ModernizacaoPublica, Pronim, RLZ, SilTecnologia, SimplISS, SpeedGov e Tiplan. Sua finalidade é identificar que o provedor implementou uma nova API que recepciona os arquivos XMLs no mesmo leiaute do Padrão Nacional e fazer com que o componente utilize as classes correspondentes. Exemplo [SpeedGov] Params=APIPropria: Versao=1.01 HomRecepcionar=http://speedgov.com.br/wsmod/Nfes [2313500] Nome=Trairi UF=CE Provedor=SpeedGov Versao=1.00 ProRecepcionar=http://www.speedgov.com.br/wstra/Nfes Com ele ao selecionar o município, o componente automaticamente reconhece o leiaute do Padrão Nacional: Sem ele o componente reconhece e utiliza as classes do leiaute ABRASF: ServicosPadraoNacional Parâmetro utilizado pelos provedores ABase, Betha, Citta, Coplan, DBSeller, Digifred, EL, Fiorilli, Infisc, ISSDigital, ISSNet, ModernizacaoPublica, Pronim, RLZ, SilTecnologia, SimplISS, SpeedGov e Tiplan. Ele deve ser utilizado em par com o parâmetro APIPropria. Sua finalidade é fazer com que o componente automaticamente consuma os end-points da API do Padrão Nacional para os serviços mencionados nele e que não foram implementados na API própria do provedor. Exemplo [SpeedGov] Params=APIPropria:|ServicosPadraoNacional:ConsultarNFSeRps,ConsultarNFSePorChave,ConsultarEvento,ConsultarDFe,ConsultarParam,ObterDANFSE Versao=1.01 HomRecepcionar=http://speedgov.com.br/wsmod/Nfes [2313500] Nome=Trairi UF=CE Provedor=SpeedGov ProRecepcionar=http://www.speedgov.com.br/wstra/Nfes ServicosAPIPropria Parâmetro considerado e utilizado pelo provedor Fiorilli. Ele deve ser utilizado em conjunto com o parâmetro APIPropria. Sua finalidade é fazer com que o componente utiliza os end-points da API Propria implementada pelo provedor ao invés de usar os do padrão nacional. Exemplo [Fiorilli] Params=APIPropria:|ServicosPadraoNacional:ConsultarNFSeRps,ConsultarNFSePorChave,ConsultarEvento,ConsultarDFe,ConsultarParam,ObterDANFSE Versao=1.00 HomRecepcionar=http://fi1.fiorilli.com.br:5663/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType HomLinkURL=http://fi1.fiorilli.com.br:5663/issweb/formGerarNF.jsf?nroNota=%NumeroNFSe%&codVerificacao=%CodVerif%&cnpj=%Cnpj%&hash=%ChaveAcesso% [1100122] Nome=Ji-Parana UF=RO Provedor=Fiorilli ProRecepcionar=https://nfse.ji-parana.ro.gov.br/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType [3504404] Nome=Avanhandava UF=SP Provedor=Fiorilli Versao=1.01 Params=ServicosAPIPropria:ConsultarNFSeRps,ConsultarNFSePorChave| ProRecepcionar=http://45.71.14.83:5661/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType ProConsultarNFSePorChave=http://45.71.14.83:5661/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType ProConsultarNFSeRps=http://45.71.14.83:5661/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType Nesta situação, a cidade de Avanhandava/SP, vai usar end-points da API propria do Fiorilli para a consulta de NFSe por Chave, enquanto a cidade de Ji-Parana/RO, vai utilizar os end-points do Padrão Nacional para o mesmo serviço. Asterístico * Utilizado e considero independente do provedor. Sua finalidade é fazer com o que conteúdo da chave Params que consta na seção provedor seja ignorado e somente o da seção do município seja lido e considerado. Exemplo [SpeedGov] Params=APIPropria:|ServicosPadraoNacional:ConsultarNFSeRps,ConsultarNFSePorChave,ConsultarEvento,ConsultarDFe,ConsultarParam,ObterDANFSE Versao=1.01 HomRecepcionar=http://speedgov.com.br/wsmod/Nfes [2313609] Nome=Ubajara UF=CE Provedor=SpeedGov ProRecepcionar=https://tributario.speedgov.com.br/ubajara/api/v1/nfse [2313500] Nome=Trairi UF=CE Provedor=SpeedGov Params=* ProRecepcionar=http://www.speedgov.com.br/wstra/Nfes O asterístico faz com que o APIPropria que consta na seção [SpeedGov] seja ignorado para a cidade de Trairi/CE, enquanto ele ainda continua sendo lido para a cidade de Ubajara/CE

Olá pessoal! Além das cidades mencionadas pelo @Italo Giurizzato Junior e os provedores, também foi divulgado recentemente uma lista dos municípios que ainda não fizeram a adesão ao ambiente nacional, seja através do emissor ou via compartilhamento de informações. Veja mais no tópico:

O que é o CIOT? CIOT é a sigla para Código Identificador da Operação de Transporte. Esse é um código gerado para registrar operações de transporte rodoviário remunerado de cargas junto à ANTT (Agência Nacional de Transportes Terrestres). Ele é obrigatório para o controle e rastreabilidade dessas operações no território nacional. Atualmente a regulamentação mais recente relacionada a ele sendo a Resolução nº 6.078, de 24 de março de 2026. O CIOT é uma novidade? Não. O CIOT já existe desde 2011. No entanto, quando foi estabelecido, seu uso era obrigatório apenas em operações de transporte muito específicas. Esse cenário mudou em 2026 com a Resolução nº 6.078, de 24 de março de 2026, que efetivamente tornou o CIOT obrigatório em praticamente todas as operações de transporte rodoviário remunerado de cargas. Veja abaixo a evolução da legislação: Quem deve gerar o CIOT? A Resolução nº 6.078/2026 estabeleceu em seu Art. 1º-A que toda operação remunerada de transporte rodoviário de cargas deverá ser registrada por meio de um CIOT, delegando a responsabilidade pela sua geração conforme a tabela abaixo: Operação de Transporte Responsável pelo CIOT Quando há contratação de TAC ou TAC Equiparado Contratante/Subcontratante Quando NÃO há contratação de TAC ou TAC Equiparado A própria ETC O que significam os termos TAC, TAC Equiparado e ETC mencionados acima? TAC é a sigla para Transportador Autônomo de Cargas. É a pessoa física que realiza o transporte rodoviário de cargas como atividade profissional. ETC é a sigla para Empresa de Transporte Rodoviário de Cargas. É a pessoa jurídica que tem como atividade principal o transporte rodoviário de cargas. TAC Equiparado é a denominação dada à ETC que possui em sua frota até 3 veículos registrados junto ao Registro Nacional de Transportadores Rodoviários de Cargas (RNTRC), bem como às Cooperativas de Transporte de Cargas, que também se enquadram nessa categoria. TAC Agregado é o Transportador Autônomo de Cargas que coloca veículo de sua propriedade ou posse — conduzido por ele mesmo ou por um preposto — a serviço de um contratante em regime de exclusividade, mediante remuneração previamente acordada. IPEF é a sigla para Instituição de Pagamento Eletrônico de Frete. É a instituição regulamentada pela ANTT responsável por realizar o pagamento eletrônico do frete e vinculá-lo à operação de transporte remunerado correspondente. Além disso, a IPEF participa do arranjo de pagamentos instantâneos instituído pelo Banco Central do Brasil, o que na prática significa que o pagamento do frete pode ser realizado via Pix. Devo gerar o CIOT quando a empresa possui frota própria e motoristas empregados? Sim, quando a empresa presta transporte rodoviário remunerado de cargas para terceiros. Ter frota própria e motoristas empregados não caracteriza, por si só, a operação como transporte de carga própria. Se a empresa transporta cargas ou encomendas de terceiros mediante remuneração, trata-se de uma operação de transporte por conta de terceiros, e o CIOT deve ser gerado conforme a regulamentação vigente. Por outro lado, se a carga transportada é da própria empresa, sem prestar serviço a terceiros e sem recebimento de frete, a geração do CIOT não é necessária. Como faço para gerar o CIOT? A geração do CIOT é feita de formas distintas dependendo de quem é o responsável pela operação. Se houve contratação de TAC ou TAC Equiparado, o CIOT deve ser gerado por uma das IPEFs habilitadas pela ANTT, por meio de portal próprio ou integração direta via web service disponibilizado pela própria IPEF. Caso a ETC seja a responsável, ela pode utilizar o sistema disponibilizado pela ANTT por meio do programa CIOT para Todos. Para que servem a DLL e o executável encontrados no programa CIOT para Todos? Não para uso rotineiro. A geração do CIOT por meio do programa CIOT para Todos deve ser feita via integração com o web service disponibilizado pela própria ANTT. A DLL e o executável são destinados exclusivamente ao uso em contingência, ou seja, situações em que a integração com o web service não está disponível. Nesses casos, eles permitem gerar o número do CIOT sem todos os dados da operação, funcionando como solução temporária. No entanto, em até 168 horas, o CIOT deverá ser regularizado pelos meios adequados, conforme o fluxograma abaixo. Existe alguma solução no ACBr para me ajudar a gerar o CIOT? Atualmente o ACBr conta com o componente desenvolvido nativamente para Delphi e Lazarus denominado ACBrCIOT, que realiza a integração com a IPEF eFrete. A integração com novas IPEFs, bem como a disponibilização do CIOT no ACBrMonitorPLUS e na ACBrLib, estão previstas em nosso planejamento para implementação futura. O programa de exemplo do componente ACBrCIOT pode ser encontrado no caminho: ..\trunk2\Exemplos\ACBrDFe\ACBrCIOT onde estão disponíveis versões tanto para Delphi quanto para Lazarus. Onde posso encontrar os manuais das IPEFs? Os manuais de cada IPEF podem ser encontrados no portal respectivo de cada uma. Além disso, nós também os centralizamos em nosso biblioteca do Tools em ...\tools\DFe\CIOT Onde devo preencher o CIOT? O CIOT deve ser informado no Manifesto Eletrônico de Documentos Fiscais (MDF-e), no elemento CIOT, que faz parte do grupo infCIOT presente nas informações da ANTT. A estrutura do XML com essa informação é semelhante a este exemplo: <rodo> <infANTT> <infCIOT> <CIOT>pseudoCIOT</CIOT> <CNPJ>pseudoCNPJ</CNPJ> </infCIOT> </infANTT> </rodo> O campo <CNPJ> ou <CPF> deve ser preenchido com a identificação do responsável pela geração do CIOT. Como preencher o CIOT no MDF-e utilizando o componente ACBrMDFe? Caso utilize componente nativo para Delphi/Lazarus, alimente as propriedades: var lMDFe: TMDFe; lRodo: Trodo; linfCIOT: TinfCIOTCollectionItem; begin lMDFe := ACBrMDFe1.Manifestos.Add.MDFe; lRodo := lMDFe.rodo; linfCIOT := lRodo.infANTT.infCIOT.New; linfCIOT.CIOT := 'pseudoCIOT'; linfCIOT.CNPJCPF := 'pseudoCNPJ'; //Demais informações... end; Caso utilize ACBrMonitorPLUS ou ACBrLibMDFe, alimente em seu arquivo INI: [infCIOT001] CNPJCPF=pseudoCNPJ CIOT=pseudoCIOT O CIOT é exibido no DAMDFe? Não! De acordo com o Manual MDFe Anexo II DAMDFE v3.00a, não há previsão de que o CIOT seja exibido no DAMDFe, portanto sua ausência não indica nenhum problema. Links Úteis e Referências RESOLUÇÃO Nº 3.658, DE 19 DE ABRIL DE 2011 RESOLUÇÃO Nº 5.862, DE 17 DE DEZEMBRO DE 2019 RESOLUÇÃO ANTT Nº 6.078, DE 24 DE MARÇO DE 2026 Lei nº 11.442 de 05 de janeiro de 2007 Perguntas Frequentes - CIOT

Bom dia! Por favor, pode disponibilizar o arquivo XML correspondente a essa tentativa de envio? Para recuperar o mesmo, utilize o end-point BaixarXmlDps. Por favor, como você está enviando a informação em seu payload? Conferindo na documentação, o elemento vISSQN não é obrigatório. Se já não o estiver fazendo, por gentileza, faça um teste sem enviar esse elemento ou enviando ele com o valor 0 ou null. Para que essa informação seja gerada, por gentileza, faça um teste enviando o valor neste elemento do payload da requisição: "gIBSCBS": { "CST": "string", "cClassTrib": "string", "cCredPres": "string", "gTribRegular": { "CSTReg": "string", "cClassTribReg": "string" } Essa campo foi adicionado a partir de um relato de um membro de nossa comunidade no Discord. De acordo com o mesmo o campo é necessário. Ela é preenchida automaticamente usando o valor enviado nesse elemento: "toma": { "orgaoPublico": false, "CNPJ": "string", "CPF": "string", "NIF": "string", "cNaoNIF": 0, "CAEPF": "string", "IM": "string", "IE": "string", "xNome": "string", "end": { "endNac": { "cMun": "string", "CEP": "string" }, Por favor, qual é o erro que você está recebendo por causa desse campo? É possível realizar um teste sem enviar essa informação do cMun para conferir se o erro persiste?

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

Boa tarde! Precisamos saber qual é a URL de produção do novo web service do ISSNet para podermos acertar o ACBrNFSeXServicos.ini e consequentemente a ACBrAPI. Se possível, por favor, entre em contato com o provedor para questionar se eles podem disponibilizar essa nova URL.

Olá comunidade ! Foi publicada a Nota Técnica 2026/003 v1.00 que estabelece as especificações técnicas e operacionais do DANFe Simplificado Tipo 2 que foi instituído pelo Ajuste SINIEF nº 13, de 6 de abril de 2026. Introdução Esse novo modelo visa acobertar de forma padronizada, a emissão de NF-e em operações em que tipicamente é emitido NFC-e. Assim como os demais leiautes de DANFe, vale ressaltar que da mesma forma, o DANFE Simplificado Tipo 2: É um documento fiscal auxiliar que representa de forma padronizada e simplificada a transação. O XML continua sendo o documento fiscal de fato. A impressão do DANFE Simplificado Tipo 2 é efetuada diretamente pelo aplicativo do contribuinte em impressora comum (não fiscal) com base nas informações do XML. O DANFe Simplificado Tipo 2 não deve possuir informações que não estejam contidas no arquivo XML da NF-e a qual ele representa. Leiaute O DANFe Simplificado Tipo 2 é composto pelas divisões: I - Informações do Cabeçalho II - Informações de detalhes de produtos/serviços III - Informações de Totais do DANFE Simplificado Tipo 2 IIIA - Informações dos novos impostos IBS/CBS IV - Informações da consulta via chave de acesso V Informações da consulta via QR Code VI - Informações sobre o Consumidor VII- Informações de Identificação da NF-e e do Protocolo de Autorização VIII - Área de Mensagem Fiscal IX - Mensagem de Interesse do Contribuinte Informações exigidas pela Lei Federal nº 12.741/2012 Datas Implantação Teste: 01/07/2026 Implantação Produção: 03/08/2026 E como fica o ACBr? O novo leiaute será implementado nas soluções ACBr. Para acompanhar esta demanda foi criada a tarefa ACBR-9424. Quaisquer novidades serão divulgadas neste tópico ou diretamente em nossa área de notícias. Leia essa nota técnica completa AQUI. Um agradecimento ao membro de nossa comunidade @mateusjurado por compartilhar a informação no canal #sefaz em nosso servidor do Discord.

Olá comunidade ! Foi publicada a Nota Técnica 2026/002 v1.00 que tratando das operações presenciais e não presenciais com o uso do DANFe Simplificado Tipo 2. Introdução Visando atender as determinações estabelecidas nos Ajustes SINIEF nº 32/25 e nº 13/26 essa NT contempla entre outros aspectos: O uso de NF-e em operações presenciais e não presenciais com o DANFe Simplificado Tipo 2. O uso do DANFe Simplificado Tipo 2 nas operações previstas no Ajuste SINIEF Um alerta na emissão de NFC-e quando o destinatário for identificado por CNPJ e estiver em situação irregular. Vedação de NF-e de saída que faça referência NFC-e ou CF-e, exceto na emissão de NF-e complementar. Regulamentação do uso de contingência off-line para NF-e quando DANFE Simplificado Tipo 2; Alterações Autorização de uso com alerta Esta nota técnica introduz um novo cStat para autorizar a NF-e com um alerta: Ao receber esse novo cStat, a mensagem de alerta detalhada será devolvida em campo específico adicionado junto da estrutura protNFe no XML. O objetivo dessa nova informação é alertar ao emissor de alguma inconsistência que deve ser verificada, mas que não é motivo suficiente para provocar rejeição. Por enquanto, esse novo cStat será disponibilizado apenas para NFC-e. Leiaute da NF-e/NFC-e. Adiciona no campo tpImp o novo valor "6=DANFE Simplificado Tipo 2 (nas condições do Ajuste SINIEF 13/26)." Altera a descrição do valor 4 no campo indPres para "4=Operações não presenciais com NFC-e e NFe com DANFE Simplificado Tipo 2 (com entrega);" Altera a descrição do valor 9 do campo tpEmis para "9=Contingência off-line da NFC-e e da NF-e com DANFE Simplificado Tipo 2". Regra de validação Algumas regras de validação anteriormente aplicadas somente para a NFC-e modelo 65 também passam a ser aplicadas para a NF-e modelo 55, a citar alguns exemplos: Regra que verifica data de entrada e saída Regra que verifica operação de entrada. Regra que verifica operação interestadual ou com o exterior. Altera a regra que verifica o limite máximo que permite a emissão de NFC-e sem identificação do destinatário Será criada uma tabela pela Sefaz com os valores por UF e na ausência de uma definição, mantem-se o limite de R$ 10.000,00. Cria regras de validação que verificam a necessidade e proibição da informação do local de entrega e também a correta referenciação de outros documentos na nota. Datas Alteração da regra de validação que permite a emissão da NFC-e sem a identificação do destinatário Implantação Teste: 01/06/2026 Implantação Produção: 15/06/2026 Aplicação das regras de validação para NF-e e criação da regra de validação que rejeita NF-e de saída referenciando modelo 65 e 59. Implantação Teste: 01/07/2026 Implantação Produção: 03/08/2026 Estrutura que devolve autorização com alertas e demais regras de validação. Implantação Teste: 01/09/2026 Implantação Produção: 05/10/2026 E como fica o ACBr? Modificações serão necessárias nas soluções ACBr. Para esta finalidade, foi criada a tarefa ACBR-9423. Qualquer novidade a respeito será divulgado neste tópico ou diretamente em nossa área de notícias. Leia a versão completa desta nota técnica AQUI. Um agradecimento ao membro de nossa comunidade @mateusjurado por compartilhar a informação no canal #sefaz em nossa comunidade do Discord.

Olá comunidade ! Foi publicada a versão 1.01 desta nota técnica trazendo controles para emitente CPF e ajustes em regras de validação. Alterações A faixa de série 970-979 anteriormente reservada para emissor CNPJ utilizando PAA foi alterada. Agora a nova disposição é: 970-979: Faixa reservada para o PAA utilizando CPF do emitente. 980-989: Faixa reservada para o PAA utilizando CNPJ do emitente. Foram criadas novas regras de validação para: Impedir emissão em lote na SV-RS. Impedir emissão de NFC-e. Impedir emissão em ambiente diferente da SV-RS quando emitido por PAA. Impedir uso de série incorreta. Datas Implantação Teste: 03/08/2026 Implantação Produção: 08/09/2026 E como fica o ACBr? Essa versão não requer alterações nas soluções ACBr. Um agradecimento ao membro de nossa comunidade @mateusjurado por compartilhar a informação no canal #sefaz em nossa comunidade do Discord.

Conforme cronograma estabelecido no ATO CONJUNTO RFB/CGIBS Nº 1, DE 22 DE DEZEMBRO DE 2025, a partir de 01/08/2026 o destaque da CBS e do IBS nas notas fiscais torna-se obrigatório. Todos os documentos deverão ter os novos campos com as informações incluindo as alíquotas de teste do IBS e da CBS. Vale ressaltar que desde que as obrigações acessórias previstas na legislação estejam sendo cumpridas, a apuração desses tributos será feita em caráter meramente informativo, sem efeitos tributários. Esse tópico foi criado com base em notícia originalmente publicada AQUI.

As empresas do Simples Nacional presentes no estado do Rio Grande do Sul já podem realizar o recadastramento anual junto a Receita Estadual. Esse processo tem previsão de encerramento em 30/09/2026 e espera-se que 206,3 mil empresas optantes por este regime façam o procedimento. O processo também é uma oportunidade de conferir a existência de contabilista registrado pela escritura fiscal do contribuinte conforme detalhado no Decreto 58.777/26. Quem precisa fazer o recadastramento? O procedimento é exigido de todos os estabelecimentos inscritos no Cadastro Geral de Contribuintes (CGC/TE) até o final de 2025. Empresas do Simples Nacional: prazo de 1º de maio a 30 de setembro. Empresas do regime Geral: prazo de 1º de agosto a 30 de setembro. Microempreendedores individuais (MEIs): não estão sujeitos à obrigação. Esse tópico foi baseado em notícia originalmente publicada AQUI.