Painel de líderes

E0039: O município emissor informado na DPS deve estar parametrizado para utilizar os emissores públicos nacionais, conforme parametrização do município no Sistema Nacional NFS-e. - Como resolver? E0116: A IM deve ser informada para o emitente prestador do serviço na DPS, conforme informações complementares registradas no CNC NFS-e do município emissor informado na DPS. - Como resolver? 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? E0310: O código de tributação nacional informado não existe ou não está administrado pelo município de incidência do ISSQN na data de competência informada na DPS, conforme a lista de serviços nacional do Sistema Nacional NFS-e. - Como resolver? E0330: É obrigatório prestar informações de todos os campos relativos ao comércio exterior - 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 E0690: A alíquota do Cofins deve ser informada quando a base de cálculo deste imposto for informada - Como resolver

A partir de 2026 os contribuintes que já emitem documentos fiscais eletrônicos deverão destacar o IBS e a CBS nas notas sem que esses valores componham o total da operação. Esse destaque terá caráter exclusivamente informativo, desde que cumpridas as obrigações acessórias previstas na legislação, funcionando como etapa preparatória para a entrada em vigor plena do novo sistema. No caso específico da Nota Fiscal de Serviços eletrônica (NFS-e), o destaque do IBS e da CBS será inicialmente facultativo, de modo a permitir uma adaptação progressiva do setor. Com o objetivo de assegurar previsibilidade, facilitar o processo de transição e evitar penalizações indevidas durante a fase de adaptação, foi definido um período de dispensa da aplicação de penalidades relacionadas as novas obrigações acessórias. Durante esse período, eventuais falhas, omissões ou inconsistências no preenchimento das informações não ensejarão a aplicação de multas, desde que o contribuinte atue de boa-fé e avance de forma diligente no processo de adequação. Para as empresas optantes pelo Simples Nacional, não haverá qualquer alteração em 2026. Essas empresas somente passarão a destacar o IBS e a CBS em seus documentos fiscais a partir de 2027, preservando-se integralmente o regime simplificado no primeiro ano da transição. Este tópico foi construído com base em notícia originalmente publicada AQUI.

Informações relacionadas aos impostos da RTC devem ser disponibilizados ainda. A RFB não divulgou nenhum layout contendo estas informações, ou mesmo, qualquer informação acerca do tema. Provavelmente a imagem tenha sido criada sem observância às regras que ainda serão estabelecidas pela RFB. Portanto, parece estar no campo da especulação sem qualquer validade técnica.

De fato, já deveríamos ter o Ambiente de Homologação/Produção funcionando 100%. Mas Nota Control é Nota Control! Não tem o que discutir. Brasília não adotou na integra ao Padrão Nacional. Com isso, as NFS-e continuarão sendo enviadas pelo provedor ISSNet (Nota Control) e o mesmo será responsável por compartilhar as informações com o ADN. Por isso, quando você envia para o provedor Padrão Nacional ocorre a rejeição E0039. Você vai continuar utilizando o provedor ISSNet. Mas para isso acontecer, a Nota Control tem que finalizar o Ambiente de Homologação/Produção e o ACBrNFSeX tem que ajustar o provedor ISSNet para gerar o XML no Padrão Nacional com o grupo IBSCBS. Em resumo, ainda não é possível enviar NFS-e (Brasília-DF) no Padrão Nacional com as tags da RTC, temos que aguardar!

Gostaria de saber existe algum possibilidade de implementar a consulta de francesa utilizando a rota https://boleto.api.itau.com/extrato/v1/francesas ? Verifiquei que já existe a rota: https://boletos.cloud.itau.com.br/boletos/v3/francesas, mas eu uma reunião com a equipe técnica do Itau eles nos orientaram a utilizar a consulta pela rota: https://boleto.api.itau.com/extrato/v1/francesas. Caso não haja previsão, me ofereço para implementar essa rota. Gostaria de orientação quanto a isso.

@Italo Giurizzato Junior Tudo em paz, bom ano novo ai.. Pode avaliar? Segue correção para atender ao XML da versão 2.04 Pasta Provedores: VersaTecnologia.GravarXml.pas VersaTecnologia.Provider.pas VersaTecnologia.LerXml.pas Pasta ACBRNFSeX: Url no inis ACBrNFSeXServicos.ini ACBrNFSeXServicosRTC.ini -> executar compila bat Pasta: ACBrNFSeX\Base\Provedores: ACBrNFSeXProviderManager.pas Alterado case para 2.04 Pasta Exemplos\ACBrDFe\Schemas\NFSe\VersaTecnologia\2.04 colar os arquivos xmldsig-core-schema20020212.xsd e nfse_v204.xsd AcbrNFSeX_3169901_2.04.zip

Bom dia. implementado método de consulta situação DPS Betha.Provider.pas

Uma novidade interessante para os emissores de NFS-e em Goiânia. No final de 2025, Goiânia passou a utilizar o sistema da Nota Control, utilizando o padrão ABRASF 2.04. Agora, uma outra novidade ainda mais impactante. Como o padrão ABRASF não será evoluido para contemplar os novos campos da RTC, o pessoal da Nota Control, resolveu fazer um puxadinho, vão manter o padrão SOAP. Mas em vez do antigo envelope: <EnviarLoteRpsEnvio xmlns="http://www.abrasf.org.br/nfse.xsd"> <LoteRps Id="LOTE129" versao="2.04"> <NumeroLote>129</NumeroLote> <Prestador> <CpfCnpj> <Cnpj>99999999999</Cnpj> </CpfCnpj> <InscricaoMunicipal>9999999</InscricaoMunicipal> </Prestador> <QuantidadeRps>1</QuantidadeRps> <ListaRps> <Rps> // dados do RPS </Rps> </ListaRps> </LoteRps> </EnviarLoteRpsEnvio> Agora, o envelope será o seguinte: <EnviarLoteDpsEnvio xmlns="http://www.sped.fazenda.gov.br/nfse" xmlns:ns2="http://www.w3.org/2000/09/xmldsig#"> <LoteDps Id="Lote1" versao="1.01"> <NumeroLote>1</NumeroLote> <!-- Grupo de informações obrigatório. IDENTIFICAÇÃO DO PRESTADOR DE SERVIÇOS. --> <Prestador> <!-- Informação obrigatória. Informe CPF ou CNPJ do prestador. NÃO ENVIAR ESTAS TAGS SIMULTANEAMENTE. --> <CNPJ> ? </CNPJ> <CPF> ? </CPF> <!-- Informação obrigatória. Número de inscrição municipal do prestador do serviço. --> <IM> ? </IM> </Prestador> <!-- Informação obrigatória. Informe a quantidade de DPS do lote. --> <QuantidadeDps> ? </QuantidadeDps> <ListaDps> <!-- DECLARAÇÃO DA PRESTAÇÃO DO SERVIÇO - INFORMAÇÕES GERADAS PELO PRESTADOR DE SERVIÇOS--> <DPS versao="1.01"> <!-- Informação obrigatória. Informe no id: "DPS" + Cód.Mun (7) + Tipo de Inscrição Federal (1) + Inscrição Federal (14 - CPF completar com 000 à esquerda) + Série DPS (5)+ Núm. DPS (15). Complete com zeros à esquerda para completar os itens da composição até o tamanho exigido. --> <infDPS Id="DPS999999999999999999999999999999999999999999"> // Informação do DPS aqui, no mesmo formato da NFS-e Nacional </infDPS> </DPS> </ListaDps> </LoteDps> <!-- Assinatura digital do prestador de serviços ou de seu preposto para o Lote de DPS. --> </EnviarLoteDpsEnvio> https://www.notaeletronica.com.br/goiania/Login/Login_NFE.aspx https://www.notacontrol.com.br/download/nfse/Manual_integracao_v101.pdf Muita atenção a esta parte do comunicado: Ou seja, a partir do dia 01/02/2026, deverá ser consumido o webservice SOAP da Nota Control com o cabeçalho SOAP atualizado, mas o conteúdo do XML será o mesmo da NFS-e Padrão Nacional. Isso que eu chamo de gambiarra. E por fim, mas não penos importante, criaram um validador para nos ajudar: https://nfse.issnetonline.com.br/wsnfsenacional/homologacao/validarxml COMUNICADO - Reforma Tributária e Nota Fiscal de Serviço eletrônica – NFS-e.pdf schema_v101.xsd XML Exemplo - EnviarLoteDpsEnvio.xml

Até resolvi esse erro atualizando e usando novos schemas. Mas depois disso deu outro erro que não consegui solucionar... parece ser que o provedor ainda não aceita evento de cancelamento. OBS: Também recebo erro na consulta por chave (nesse caso parece ser erro do componente). Quando eu conseguir, passo o erro exato aqui, sobre a consulta e cancelamento.

flavioast, e Juliano D. Rosa obrigado pela atenção. Fiz algumas pesquisas e na lei e realmente no art 348 item III cita que para regime do simples não será aplicavel. Seção III Disposições Comuns ao IBS e à CBS em 2026 Art. 348. Em relação aos fatos geradores ocorridos de 1º de janeiro a 31 de dezembro de 2026: I - o montante recolhido do IBS e da CBS será compensado com o valor devido, no mesmo período de apuração, das contribuições previstas no art. 195, inciso I, alínea “b”, e inciso IV, e da contribuição para o PIS a que se refere o art. 239, ambos da Constituição Federal; II - caso o contribuinte não possua débitos suficientes para efetuar a compensação de que trata o inciso I, o valor recolhido poderá ser: a) compensado com qualquer outro tributo federal, nos termos da legislação; ou b) ressarcido em até 60 (sessenta) dias, mediante requerimento; III - as alíquotas do IBS e da CBS previstas nos arts. 343 e 346 desta Lei Complementar: a) serão aplicadas com a respectiva redução no caso das operações sujeitas a alíquota reduzida, no âmbito de regimes diferenciados de tributação; b) serão aplicadas em relação aos regimes específicos de que trata esta Lei Complementar, observadas as respectivas bases de cálculo, exceto em relação aos combustíveis e biocombustíveis de que tratam os arts. 172 a 180; c) não serão aplicadas em relação às operações dos contribuintes optantes pelo Simples Nacional. § 1º Fica dispensado o recolhimento do IBS e da CBS relativo aos fatos geradores ocorridos no período indicado no caput em relação aos sujeitos passivos que cumprirem as obrigações acessórias previstas na legislação. § 2º O sujeito passivo dispensado do recolhimento na forma do § 1º permanece obrigado ao pagamento integral das Contribuições previstas no art. 195, inciso I, alínea “b”, e inciso IV, e da contribuição para o Programa de Integração Social a que se refere o art. 239, ambos da Constituição Federal.

Em servico

Boa tarde a todos, recebi o seguinte comunicado. ATUALIZAÇÃO SOBRE O SISTEMA EMISSOR DE NOTA FISCAL DE SERVIÇO ELETRÔNICA (NFS-e) O Município de Blumenau, por intermédio da Secretaria da Fazenda (SEFAZ), informa que a empresa responsável pelo Sistema de Emissão de Notas Fiscais de Serviços Eletrônicas desta municipalidade está realizando os ajustes técnicos para normalizar a emissão de documentos fiscais em conformidade com as diretrizes nacionais. Por sua vez, destaca-se que a Nota Técnica n.º 004 (versão 2.0), expedida em 10/12/2025 pela Secretaria-Executiva do Comitê Gestor da Nota Fiscal de Serviço Eletrônica de Padrão Nacional (SE/CGNFS-e), contemplou a suspensão, neste início de 2026, das regras de validação de obrigatoriedade dos grupos IBS e CBS. Diante da matéria acima, o emissor de NFS-e de Blumenau (Notablu) passará a utilizar, num primeiro momento, o mesmo layout de emissão empregado até 31/12/2025. Esta medida visa facilitar o fluxo de emissões de notas fiscais até a ampla solução das instabilidades reportadas pelos contribuintes. Apesar do destaque do IBS e da CBS não ser obrigatório desde logo, as NFS-e emitidas com a utilização do modelo anterior serão devidamente recepcionadas pelo Ambiente de Dados Nacional (ADN), elemento ratificado não somente pela Nota Técnica já citada, mas também pelas informações extraídas do Ato Conjunto RFB/CGIBS n.º 1, emitido em 22/12/2025 pelo Secretário Especial da Receita Federal do Brasil e pelo Presidente do Comitê Gestor do IBS. Ademais, a leitura conjunta das comunicações oficiais já citadas revelam que o destaque obrigatório dos tributos debatidos está dispensado até o dia 1º de abril. Ressalta-se, ainda, que as recentes mudanças no sistema decorrem de imposições da Reforma Tributária do Consumo (RTC) e das atualizações de layout firmadas pela Secretaria-Executiva do Comitê Gestor da Nota Fiscal de Serviço Eletrônica de Padrão Nacional. Frisa-se, no ponto, que problemas na emissão de NFS-e estão sendo enfrentados por outros entes federados, inclusive por aqueles que optaram em migrar para o Emissor Nacional. O Município de Blumenau reconhece os desafios gerados pela brevidade das novas normas e reafirma seu compromisso em auxiliar os contribuintes nesta transição. Por fim, sublinha-se que a equipe técnica segue trabalhando para a implementação completa e estável do modelo definitivo, priorizando sempre a segurança jurídica e operacional. ---------------------------------------------------- Ou seja, eles voltaram atrais até segunda ordem, já fiz os testes e está emitindo normalmente (com um pouco de lentidão no retorno) com em 31/12/2025

Peça para o pessoal do fiscal ler a nota da RFB: https://www.gov.br/receitafederal/pt-br/acesso-a-informacao/acoes-e-programas/programas-e-atividades/reforma-consumo/orientacoes-2026 "Considerando que o ano de 2026 será o ano de teste da CBS e do IBS, o contribuinte que emitir documentos fiscais ou declaração de regimes específicos observando as normas e notas vigentes, estará dispensado de recolhimento do IBS e da CBS." No MOC não há definição para o DANF-e: https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=f NhsSn3/5M=

Boa tarde a todos, Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e faça os testes. As alterações de URL foram feitas no arquivo ACBrNFSeXServicosRTC.ini

@Michel Abrão Esta sim diferente o regime tributário nas impressões entre a prefeitura e o governo, vou enviar um email para eles para ver se tenho algum retorno. esse é do site da prefeitura esse é da consulta do governo

Boa tarde, atualizei monitor e schemas agora e consegui cancelar.

Fiz um teste agora. LayoutNFSe := lnfsPadraoNacionalv101; //Versao := ve101; comentei essa linha no meu codigo. Consegui cancelar a NFSE, ou seja parece que usou a versão 1.00 no padrao nacional. Mas dai não valida a NFSe, pra validar a NFSe tive que setar: LayoutNFSe := lnfsPadraoNacionalv101; Versao := ve101;

Testei isso e aparentemente, não está obrigatório. A nota enviou normalmente.

Boa tarde @Jeferson S Lima, Já esta no SVN.

Bom dia a todos! Testes finais de emissão de NFS-e em balneário... [4202008] ; Atualizado em 01/10/2025 Nome=Balneario Camboriu UF=SC Provedor=PadraoNacional ;ProRecepcionar=http://nfse1.publica.inf.br/balneariocamboriu_nfse_integracao/Services O arquivo ini precisa estar assim... o do ACBR no SVN ainda esta incorreto... ajustando ele (Fiz no RTC) as notas autorizaram sem problemas.

Fiz um teste no componente... Alterei o código desta forma: Assim é possível emitir as notas... @Italo Giurizzato Junior.. Como podemos resolver esta questão?

Entendendo o problema. De acordo com a planilha ANEXO_I-SEFIN_ADN-DPS_NFSe-SNNFSe-v1.00-20251226 que contém o leiaute da NFS-e e as regras de validação aplicadas pela API do Padrão Nacional, está é a regra de validação que correspondente a esta rejeição: Campo Regra de Validação Código Rejeição cTribNac Verificar se o código de tributação nacional informado existe e está administrado pelo município de incidência do ISSQN na data de competência informada na DPS, conforme a lista de serviços nacional do Sistema Nacional NFS-e. E0310 O código de tributação nacional informado não existe ou não está administrado pelo município de incidência do ISSQN na data de competência informada na DPS, conforme a lista de serviços nacional do Sistema Nacional NFS-e. Não há muito o que expandir nesse caso, essa rejeição indica que o valor informado em cTribNac está incorreto ou é inválido. Como resolver? O cTribNac corresponde ao Código de tributação nacional do ISSQN, ou seja, ele é uma informação de âmbito nacional, comum para todos os prestadores em todos os municípios. Acesse o ANEXO_B-NBS2-LISTA_SERVICO_NACIONAL-SNNFSe-v1.00-20251210.xlsx para conferir quais são os valores válidos para o campo cTribNac e certifique-se de que a informação foi preenchida corretamente. Caso utilize ACBrNFSeX para Delphi e Lazarus: Para que a tag seja gerada no XML, a propriedade a ser alimentada é: ACBrNFSeX.NotasFiscais[0].NFSe.Servico.ItemListaServico; Caso utilize ACBrMonitorPLUS ou ACBrLib: Para que a tag seja gerada no XML, a informação a ser alimentada é: [Servico] ItemListaServico=

@Italo Giurizzato Junior Poderia nos ajudar com essa questão da série?

do tpAmb, pode fazer esse ajuste no Siltecnologia.GerarXml.pas procedure TNFSeW_SilTecnologiaAPIPropria.Configuracao; begin inherited Configuracao; NrOcorrtpAmb := -1; end;

Bom dia a todos. Não uso o ACBr, mas aqui estou conseguindo fazer a transmissão das notas para a prefeitura de Bauru. Cancelamento e impressão somente pelo site, inclusive a impressão tenho preferencia por usar o portal nacional. O complicado é ter que convencer os clientes que o cancelamento e a impressão não estão prontas por causa da prefeitura ou provedor e não dos nossos sistemas. Um grande abraço para @Michel Abrão , foi professor meu na anhanguera na turma de 2012.

Juliomar, creio que deve ter sido um problema na SEFAZ pois agora consegui transmitir o CTE com os dados certinho. Muito obrigado pela atenção.

obrigado @BigWings Fiz a atualização da forma que vc sugeriu e as danfes foram geradas corretamente!

Notas de débito ou crédito, ou notas de pagamento em operação governamental, não devem destacar os impostos "antigos" (ICMS, ISS, PIS, COFINS, IPI, II), de acordo com a regra de validação B25-80. Com exceção para a nota de crédito do tipo 03-Retorno.

Emissões não estão mais funcionando, segue log da tentativa de emissão: [Envio] CodigoVerificacao= Data= Link= Lote=987 MaxRps=50 ModoEnvio=Enviar Lote Síncrono NumeroNota= Protocolo= Situacao= Sucesso=0 XmlEnvio=<EnviarLoteRpsSincronoEnvio xmlns="http://www.abrasf.org.br/nfse.xsd"><LoteRps Id="Lote_987" versao="2.04"><NumeroLote>987</NumeroLote>[...]</EnviarLoteRpsSincronoEnvio> XmlRetorno=<EnviarLoteRpsSincronoResposta xmlns="http://www.abrasf.org.br/nfse.xsd"> <ListaMensagemRetornoLote> <MensagemRetorno> <IdentificacaoRps> <Numero>1</Numero> <Serie>1</Serie> <Tipo>1</Tipo> </IdentificacaoRps> <Codigo>SCH1</Codigo> <Mensagem>TAG 'Servico': Faltando TAG(s) filha(s). O Esperado é um dos ( NumeroProcesso, cNBS ). - CODE: 1</Mensagem> </MensagemRetorno> <MensagemRetorno> <IdentificacaoRps> <Numero>1</Numero> <Serie>1</Serie> <Tipo>1</Tipo> </IdentificacaoRps> <Codigo>E160</Codigo> <Mensagem>Arquivo em desacordo com o XML Schema. - CODE: 1</Mensagem> </MensagemRetorno> </ListaMensagemRetornoLote></EnviarLoteRpsSincronoResposta> [Erro1] Codigo=SCH1 Correcao= Descricao=TAG 'Servico': Faltando TAG(s) filha(s). O Esperado é um dos ( NumeroProcesso, cNBS ). - CODE: 1 [Erro2] Codigo=E160 Correcao= Descricao=Arquivo em desacordo com o XML Schema. - CODE: 1 [Erro3] Codigo=X202 Correcao= Descricao=Lista de NFSe nâo encontrada! (ListaNfse)

Pessoal erro meu tinha esquecido de atualizar o schema!

Olá, pessoal! Se você está implementando a NFSe no Padrão Nacional e está encontrando dificuldades para obter o XML da nota após o envio, este guia foi feito para você. Muitas vezes, a confusão acontece porque o fluxo do Padrão Nacional exige a distinção clara entre o DPS e a NFSe. Abaixo, detalhamos o fluxo correto para consultar e baixar o XML definitivo. O Fluxo de Consulta Correto Diferente de outros provedores, no Padrão Nacional, o ideal é realizar uma "ponte" entre a Chave do DPS e a Chave da NFSe. 1. Consulta pela Chave do DPS (42 dígitos) O segredo para o sucesso é utilizar a Chave do DPS. Essa chave possui 42 dígitos e o ideal é que você a tenha armazenado em seu banco de dados no momento da emissão. Delphi/Lazarus // LIdDPS deve conter a chave de 42 dígitos do DPS ACBrNFSeX.ConsultarDPSPorChave(LIdDPS); 2. Obtenção da NFSe através do retorno Se a consulta do DPS for bem-sucedida, o componente receberá o ID da Nota Fiscal. Com esse ID, fazemos a consulta final para obter o XML completo da NFSe: Delphi/Lazarus if ACBrNFSeX.WebService.ConsultaNFSeporRps.Sucesso then begin // Agora consultamos pela Chave da Nota retornada, e não mais pelo DPS ACBrNFSeX.ConsultarNFSePorChave(ACBrNFSeX.WebService.ConsultaNFSeporRps.idNota); // O XML da NFSe estará disponível aqui: ShowMessage(ACBrNFSeX.NotasFiscais.Items[0].XmlNfse); end; Caso esteja validando um processo de emissão que foi interrompido e a consulta do DPS não foi realizada com sucesso você pode entender que o DPS não foi recebido e a nota não existe. Observações Importantes Diferença de Chaves: Não confunda a Chave do DPS (enviada) com a Chave da NFSe (gerada pelo governo). Ambas são importantes, mas para baixar o XML final, a consulta por chave de nota é a mais precisa. Persistência de Dados: Salve sempre a chave de 42 dígitos do DPS no seu banco de dados. Ela é o seu "passaporte" para localizar a nota caso haja uma queda de conexão ou timeout. Provedor Nacional: Este fluxo é o padrão esperado para prefeituras que aderiram ao convênio da NFSe Nacional via Ambiente de Dados Nacional (ADN). Conclusão Seguindo esses passos, você garante que sua aplicação consiga recuperar o XML da NFSe de forma consistente, evitando erros de "Nota não encontrada" ou retornos vazios. A chave é entender que o processo é uma escada: Dados do DPS -> Consulta Chave DPS -> Consulta Chave NFSe -> XML Final. Esperamos que esta dica ajude a agilizar as implementações de vocês! Créditos à comunidade ACBr e ao amigo @icozeira pelo compartilhamento de experiências!

Galera, depois de bater muito a cabeça consegui fazer funcionar. <IBSCBS> <CST>200</CST> <cClassTrib>200022</cClassTrib> <gIBSCBS> <vBC>41.70</vBC> <gIBSUF> <pIBSUF>0.0000</pIBSUF> <gRed> <pRedAliq>100.0000</pRedAliq> <pAliqEfet>0.0000</pAliqEfet> </gRed> <vIBSUF>0.00</vIBSUF> </gIBSUF> <gIBSMun> <pIBSMun>0.0000</pIBSMun> <gRed> <pRedAliq>100.0000</pRedAliq> <pAliqEfet>0.0000</pAliqEfet> </gRed> <vIBSMun>0.00</vIBSMun> </gIBSMun> <vIBS>0.00</vIBS> <gCBS> <pCBS>0.0000</pCBS> <gRed> <pRedAliq>100.0000</pRedAliq> <pAliqEfet>0.0000</pAliqEfet> </gRed> <vCBS>0.00</vCBS> </gCBS> <gTribRegular> <CSTReg>200</CSTReg> <cClassTribReg>200022</cClassTribReg> <pAliqEfetRegIBSUF>0.1000</pAliqEfetRegIBSUF> <vTribRegIBSUF>0.04</vTribRegIBSUF> <pAliqEfetRegIBSMun>0.0000</pAliqEfetRegIBSMun> <vTribRegIBSMun>0.00</vTribRegIBSMun> <pAliqEfetRegCBS>0.9000</pAliqEfetRegCBS> <vTribRegCBS>0.38</vTribRegCBS> </gTribRegular> </gIBSCBS> </IBSCBS> Obrigado a ajuda de todos.

Boa tarde. Recebi uma informação referente à base legal de que o § 2º do art. 12 da LC nº 214/2025 estabelece que os impostos ICMS, PIS e COFINS não compõem a base de cálculo do IBS e da CBS. No entanto, estou recebendo orientações divergentes por parte de contabilidades: algumas informam que o cálculo deveria ser realizado conforme esse entendimento, enquanto outras orientam que a base de cálculo do IBS/CBS seria o valor total do produto. Diante disso, poderia, por gentileza, me ajudar confirmando qual é a interpretação correta? Caso a exclusão dos tributos seja aplicável, poderiam também confirmar se, para fins de cálculo do IBS/CBS, a base deve ser formada pelo valor do produto subtraído do ICMS destacado, do PIS e do COFINS, conforme o exemplo abaixo: Base do IBS/CBS = valor do produto – valor do ICMS – valor do PIS – valor do COFINS Exemplo (XML): <vProd> = 48,90 <vICMS> (ICMS51) = 1,96 <vPIS> = 0,81 <vCOFINS> = 3,72 <vBaseIBSCBS> = 42,41 Cálculo sugerido: 48,90 – 1,96 – 0,81 – 3,72 = 42,41 Ou seja, a base de cálculo do IBS/CBS seria 42,41, e não o valor total do produto (48,90).

Boa tarde @Gustavo Totta, Já esta no SVN.

A base de cálculo da CBS e do IBS está descrita na NT. O que pode mudar a partir de 2027 é a base de cálculo do ICMS.

Olá comunidade ! Nos últimos dias temos recebido múltiplos relatos de problemas com o retorno que devolve um PDF do DANFSe no leiaute do Padrão Nacional. No componente: ACBrNFSeX1.ObterDANFSE(xChaveNFSe); No ACBrMonitorPLUS: NFSe.ObterDANFSE; Na ACBrLib: NFSE_ObterDANFSE; Todos os relatos tem em comum o mesmo comportamento, o PDF salvo é um arquivo com somente 1 kb e ao consultar o JSON que foi devolvido pela API do Padrão Nacional com a string que gera o PDF, seu varia entre: { "tipoAmbiente": "", "versaoAplicativo": "", "dataHoraProcessamento": "", "idDps": "", "chaveAcesso": "", "nfseXmlGZipB64": "", "erros": [ { "mensagem": "", "codigo": "E9999", "descricao": "<html><body><h1>503 Service Unavailable</h1>\nNo server is available to handle this request.\n</body></html>\n", "complemento": "" } ] } OU { "tipoAmbiente": "", "versaoAplicativo": "", "dataHoraProcessamento": "", "idDps": "", "chaveAcesso": "", "nfseXmlGZipB64": "", "erros": [ { "mensagem": "", "codigo": "E9999", "descricao": "<html><body><h1>502 Bad Gateway</h1>\nThe server returned an invalid or incomplete response.\n</body></html>\n", "complemento": "" } ] } Tudo indica ser um problema no próprio end-point /danfse/{chaveAcesso} na API. Buscando informações a respeito, uma justificativa encontrada no Fórum da NFSe é a de que muitos robôs que estão baixando o DANFSe em massa estão tornando o end-point instável.

Com o advento da reforma tributária, os municípios são deixados com uma escolha: Aderem ao padrão nacional na íntegra ou continuam usando provedor próprio no formato aderindo ao padrão nacional no formato de compartilhamento de informações. Se escolhida a segunda opção, dois caminhos podem ser seguidos: No caminho mais simples, o provedor cria uma API própria para recepcionar os arquivos XMLs segundo o leiaute do Padrão Nacional. Nesta abordagem, o leiaute utilizado é o já existente do padrão nacional, então basta saber qual é a URL da API para comunicação e os end-points. No caminho mais complexo, o provedor altera o leiaute que ele já usa, adicionando novos campos para receber as informações que ela vai compartilhar posteriormente com o padrão nacional. Padrão Nacional A quantidade de municípios que aderiram ao Padrão Nacional é cada vez maior e pode ser conferida em um Dashboard alimentado e atualizado em tempo real. Acesse o Dashboard AQUI. Lembrando que as soluções ACBr já atendem ao padrão nacional. Provedores com API Própria para atender o Padrão Nacional com a Reforma Tributária. Última atualização: 06/01/2026 Observação: Vale reforçar que devido a relação quantidade de provedores x prazo, o foco das implementações inicialmente tem sido os métodos de emissão da NFS-e. Provedor Requisito Cidade testada Cidades atendidas* Emissão funcionando ABase Informar o Token em WSChaveAcesso Boa Vista do Burica/MS 39 Em testes Betha Vai usar WebService Soap Dourados/MS 403 Envio OK Coplan Vai usar WebService Soap Barra do Garças/MT 31 Em testes Citta Enviar o XML da NFS-e São Valentim do Sul/RS 24 Envio OK Digifred Vai usar WebService Soap Ibirubá/RS 21 Envio OK EL Informar o Token em WSChaveAcesso Aracruz/PE 155 Envio OK Infisc - Campo Bom/RS 9 Envio OK ISSNet WS Soap/Permite Lote de DPS - 25 Aguardando as URLs de homologação Pronim Permite o envio de um lote de DPS Regente Feijó/SP 184 Envio OK RLZ - Barretos/SP 9 - SilTecnologia WS Soap/Enviar o XML da NFS-e Franca/SP 16 Retorno Vazio SimplISS - Blumenau/SC 27 Envio OK (Ainda não aceita os campos IBSCBS) Tiplan - Americana/SP 8 Envio OK * Estimativa aproximada Provedores que alteram o layout em uso para atender a Reforma Tributária. Última atualização: 06/01/2026 Provedor Requisito Cidades Atendidas* Emissão funcionando EloTech Versão 2.03 138 Envio OK FintelISS Versão 2.02 4 O webservice da prefeitura não aplicou o novo Schema GeisWeb Próprio 7 Envio OK Ginfes - 22 Giss - 18 Envio OK IPM - 188 Envio OK ISSBarueri - 1 ISSe - 1 Envio OK ISSSaoPaulo Versão 2.00 1 Envio OK Publica Versão 1.00 31 Envio OK SigISSWeb Próprio 11 Envio OK SpeedGov Versão 2.00 32 Tinus Versão 2.03 44 Envio OK WebISS Versão 2.02 87 Envio OK * Estimativa aproximada

aproveitei essa dica e implementei no acbrmail no teste a funcionalidade ficou perfeito, autentica, pega o refleshtoken valida e envia sem nem uma mudança no componente.

Olá pessoal! Seguem abaixo os passos que segui para configurar o ACBr via Maven para usar com Eclipse ou IntelliJ. Os passos foram relativamente simples Buildar o Ac Br Commons, exporar um jar (1.0.0) Pega esse Jar e instalar no seu Maven Repository mvn install:install-file -Dfile="C:\projetos\AcBr\boleto-service\src\main\resources\lib\ACBr Common.jar" -DgroupId="br.com.acbr" -DartifactId="acbr" -Dversion="1.0.0" -Dpackaging="jar" E adicionar no projeto as dependencias: <dependency> <groupId>net.java.dev.jna</groupId> <artifactId>jna</artifactId> <version>5.9.0</version></dependency> <dependency> <groupId>net.java.dev.jna</groupId> <artifactId>jna-platform</artifactId> <version>5.9.0</version> </dependency> <dependency> <groupId>br.com.acbr</groupId> <artifactId>acbr</artifactId> <version>1.0.0</version> </dependency> Trouxe para cá pois isso pode ajudar outra pessoa a fazer essa configuraçao, pois pouca gente usa o NetBeans.... maioria usar o Eclipse ou o IntelliJ... e com essa configuração via Maven, essa dependencida do Netbeans mostrada nos videos não é mais necessária, se torna opcional.

Encontramos o problema. Fui fazer um teste com o exemplo do AcBr e funcionou corretamente. Na comparação entre os dois projetos, encontramos o problema: Essa configuração (Record Field Aligment) estava como Byte (padrão em nossos projetos desde sempre). Ao alterarmos para Quad Word tudo funcionou corretamente. Fica a dica caso alguém tenha esse mesmo problema. Abraço a todos, fiquem a vontade para fechar esse topico.