Pesquisar na Comunidade

NFS-e Via: nova API permite consultar alíquotas de ISS por trecho e data A Secretaria-Executiva do Comitê Gestor da NFS-e ampliou as ferramentas de transparência do sistema NFS-e Via. Entenda o que muda para as Administrações Tributárias Municipais e onde a comunidade pode ajudar a levar essa novidade também para o ecossistema ACBr. Resumo da novidade: Foi publicada a versão 1.1 do Anexo V – Guia para Utilização das APIs, destinada às Administrações Tributárias Municipais do sistema NFS-e Via; A principal novidade é a API de consulta de alíquotas de ISS por trecho e data; Os municípios passam a acessar o histórico e a vigência das alíquotas aplicadas em trechos de concessões rodoviárias; A resposta traz percentual de participação de cada município, alíquota base, alíquota efetiva municipal e alíquota efetiva total do trecho; O objetivo declarado é aumentar a transparência e facilitar a validação do rateio do ISSQN entre os entes federados; A documentação técnica e os ambientes de teste já estão disponíveis para integração. O que mudou na NFS-e Via O NFS-e Via é a frente do sistema nacional da Nota Fiscal de Serviço eletrônica voltada às concessionárias de exploração de vias — o modelo usado para emitir a nota fiscal referente à cobrança de pedágio. Como o trecho de uma concessão costuma atravessar mais de um município, o ISS arrecadado precisa ser rateado entre eles, de acordo com a extensão da rodovia em cada território e a alíquota vigente em cada localidade. Até então, o Anexo V – Guia para Utilização das APIs descrevia apenas o método ObterDocumentos, usado pelos municípios para baixar os XMLs de NFS-e Via e de eventos de cancelamento por NSU, além da consulta de alíquotas por município. Com a versão 1.1, publicada em julho de 2026, o guia passa a contemplar também a consulta de alíquotas por trecho em uma data específica. Como funciona a nova consulta de alíquotas O novo endpoint, GetAliquotasTrecho, é acessado via GET /Aliquotas/trecho/{codigoTrecho}/dataReferencia/{dataReferencia} e retorna, para um trecho e uma data de referência informados, a lista completa de municípios envolvidos no rateio, com: extensão do trecho em cada município e o percentual correspondente; alíquota de ISS informada e a alíquota efetiva aplicada por município; a alíquota efetiva total do trecho, já consolidada. Essa informação se soma à consulta já existente por município (GetAliquotasMunicipioPorTrecho), que lista todos os trechos associados a um determinado código de município. Na prática, o município passa a poder conferir não só "quais trechos me afetam", mas também "qual era a alíquota vigente em uma data específica" — algo essencial para auditar cobranças passadas ou resolver divergências de repasse. Todas as comunicações continuam seguindo o padrão já estabelecido para o NFS-e Via: API REST síncrona, mensagens em JSON, documentos fiscais em XML 1.0/UTF-8, e autenticação mútua via certificado digital ICP-Brasil (TLS 1.0 a 1.2). Os ambientes de homologação, produção restrita e produção continuam disponíveis para testes de integração, com Swagger publicado para cada um deles. Por que isso importa para os municípios O rateio do ISS entre municípios cortados por uma mesma via é, por natureza, uma operação sensível: pequenas diferenças de alíquota ou de data de vigência mudam o valor final que cada prefeitura recebe. Ao expor essa informação via API — e não apenas em relatórios estáticos —, o Comitê Gestor da NFS-e permite que cada Administração Tributária Municipal audite o cálculo por conta própria, comparando o valor recebido com a alíquota que realmente estava vigente na data da cobrança do pedágio. Isso é particularmente relevante em disputas ou revisões de rateio: em vez de depender de uma consulta manual à concessionária, o município consulta diretamente o Ambiente Nacional da NFS-e Via e obtém o dado oficial. Onde ainda faltam ferramentas — um convite à comunidade Documentos fiscais eletrônicos como o NFS-e Via costumam ganhar, com o tempo, componentes prontos que facilitam a integração para quem desenvolve sistemas — é o caso de vários documentos já cobertos pelo ecossistema ACBr. Essa API específica de alíquotas do NFS-e Via, no entanto, ainda não tem um componente ACBr dedicado. A criação desse suporte está no roadmap do projeto, mas ainda sem previsão específica de entrega. É justamente aí que a comunidade pode fazer a diferença: quem já trabalha com integrações para concessionárias de vias ou tem interesse no tema pode contribuir com o desenvolvimento desse componente, ajudando a antecipar essa entrega para quem depende dela no dia a dia. Onde acessar a documentação A documentação técnica completa — incluindo os endpoints de obtenção de documentos e as duas consultas de alíquotas — está disponível no Anexo V – Guia para Utilização das APIs, com ambientes de homologação, produção restrita e produção liberados para testes de integração. Se você desenvolve integrações fiscais e quer ajudar a preencher essa lacuna no ecossistema ACBr — seja com o componente do NFS-e Via, seja com a consulta de alíquotas por trecho —, essa é uma boa oportunidade de contribuir com o projeto e com quem depende dele. Conheça as APIs do projeto ACBr e veja como participar do desenvolvimento junto com a comunidade. Fonte oficial: Secretaria-Executiva do Comitê Gestor da NFS-e — NFS-e Via: Publicada nova API para consulta de alíquotas do ISS, publicada em 10/07/2026.

Prezados, Gostaria de solicitar apoio em relação a uma dificuldade no consumo do serviço de consulta de alíquotas da API ADN. Apesar de utilizarmos um certificado digital válido e seguirmos a documentação Swagger do ambiente de produção, as requisições retornam sistematicamente a mensagem: "Histórico de alíquotas não encontrado". Endereço do serviço: https://adn.nfse.gov.br/parametrizacao/docs/index.html#tag/Aliquotas/paths/~1{codigoMunicipio}~1{codigoServico}~1{competencia}~1aliquota/get Atualmente, estamos executando uma requisição GET para a seguinte URL: https://adn.nfse.gov.br/parametrizacao/4314902/10.10.11.100/2026-02-01/aliquota Utilizamos o código IBGE do município de Porto Alegre (4314902), o código de serviço NBS 10.10.11.100 e a competência no formato 2026-02-01. Recebemos como resposta um JSON com o campo de alíquotas nulo, o que nos gera dúvidas se o erro reside na formatação dos parâmetros de rota ou se é uma questão de ausência de dados cadastrados pelo município na base nacional. 1) Poderiam confirmar se a formatação dos parâmetros acima está correta? 2) O erro "Histórico não encontrado" refere-se a um erro de sintaxe na chamada ou significa que o município 4314902 efetivamente não carregou a tabela de alíquotas para este código NBS específico no ADN? 3) Poderiam fornecer um exemplo de URL (com município, serviço e competência válidos) que retorne sucesso? Como não obtivemos retorno pelos canais oficiais do governo, qualquer compartilhamento de experiência sobre essa implementação será de grande ajuda.

Olá pessoal! Foi publicado no dia 25/02/2025 o Informe Técnico 2023/003 em sua versão 1.03. A nova versão divulga atualização na Tabela de Alíquotas FCP, atualizando desde 01/01/2025 as alíquotas do estado do Amazonas para 1,2% e 2,0%, devendo ser aplicadas conforme legislação do estado. Leia a Informe Técnico na íntegra AQUI. A Tabela de Alíquotas FCP atualizada pode ser encontrada AQUI.

Bom dia, Estou tendo problemas ao obter as aliquotas da ECF SWEDA ST2500 utilizando o protocolo SwedaSTX, o ECF possui varias aliquotas como: 1700, 0700, 1200, 2500, 2900 Porém ao utilizar o objeto: AcbrGenECF.DadosUltimaReducaoZ (Após emitir a redução) A aliquota 2500 está sempre retornando o valor "0" (zerado) Ao verificar no LOG do ECF durante a emissão da redução Z o valor é exibido no LOG, porém no ACBR não é carregado: T1700000000000000298262 T0700000000000000025972 T2500000000000000022884 T1200000000000000015477 LOG ECF: -- 10/08 21:00:14:235 Registrador: H2 Retorno: [NUL][NUL][NUL][NUL][NUL]036[NUL]SSN[ETX][183][STX]v34+0000BA[132][128][130][128][128]H2 -- 10/08 21:00:14:235 NumLoja -- 10/08 21:00:14:235 TX -> [STX]w65|9999[ETX]G -- 10/08 21:00:14:313 21:00:14:313 RX <- ACK = 6 Falha: 0 -- 10/08 21:00:14:735 TimeOut estendido -- 10/08 21:00:14:735 21:00:14:735 RX <- (Bloco) = [STX]w65+0000BA[132][128][130][128][128]SWEDA[NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL]IF ST2500[NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL]ECF-IF[NUL][NUL]SW061000000000002165 [NUL]036MFDSW02000003706[NUL][NUL][NUL][NUL][NUL]0127.555.390/0001-12[NUL][NUL][NUL]080.774.88-1[NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL]R[NUL][NUL][NUL][NUL]S187810/08/2017[NUL]20:46:13[NUL][NUL]47341810/08/2017[NUL]4729580001[NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL]000000000000687145000000000000690035000000000000000000000000000000000000000000000000000000GT[NUL][NUL][NUL]000000002584584853VB[NUL][NUL][NUL]000000000000690035ON[NUL][NUL][NUL]000000000000000000CT[NUL][NUL][NUL]000000000000002890T1700000000000000298262T0700000000000000025972T2500000000000000022884T1200000000000000015477F1[NUL][NUL][NUL]000000000000275800I1[NUL][NUL][NUL]000000000000048750[ETX][129] -- 10/08 21:00:14:735 TX -> ACK = 6 Falha: 0 -- 10/08 21:00:14:844 RX <- [STX]w65+0000BA[132][128][130][128][128]SWEDA[NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL]IF ST2500[NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL]ECF-IF[NUL][NUL]SW061000000000002165 [NUL]036MFDSW02000003706[NUL][NUL][NUL][NUL][NUL]0127.555.390/0001-12[NUL][NUL][NUL]080.774.88-1[NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL]R[NUL][NUL][NUL][NUL]S187810/08/2017[NUL]20:46:13[NUL][NUL]47341810/08/2017[NUL]4729580001[NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL]000000000000687145000000000000690035000000000000000000000000000000000000000000000000000000GT[NUL][NUL][NUL]000000002584584853VB[NUL][NUL][NUL]000000000000690035ON[NUL][NUL][NUL]000000000000000000CT[NUL][NUL][NUL]000000000000002890T1700000000000000298262T0700000000000000025972T2500000000000000022884T1200000000000000015477F1[NUL][NUL][NUL]000000000000275800I1[NUL][NUL][NUL]000000000000048750[ETX][129] -- 10/08 21:00:15:000 CortaPapel Valores retornados pelo ACBR: Aliq: -> 1;0200;0,00 Aliq: -> 2;0300;0,00 Aliq: -> 3;0400;0,00 Aliq: -> 4;0700;259,72 Aliq: -> 5;1200;154,77 Aliq: -> 6;1700;2982,62 Aliq: -> 7;2500;0,00 Aliq: -> 8;2700;0,00 Aliq: -> 9;0000;0,00

Olá Pessoal Estou promovendo modificações em ACBrECFVirtual.pas, com o intuito de dar suporte as Alíquotas de Isenção do ISSQN, ou seja (FS1, NS1, IS1) Atualmente o ACBrECFVirtual, tem nas posições 0 a 2 alíquotas "FF", "II", "NN"... Elas foram criadas, quando iniciamos o desenvolvimento do ECF Virtual, emulando um ECF Bematech... Os problemas atuais são: - O Nome correto dessas alíquotas deveria ser "F1, I1, N1" - Não há suporte as alíquotas de Isenção do ISSQN, ou seja (FS1, NS1, IS1) O ECFVirtual, utiliza as primeiras posições da lista de Objetos de Alíquotas, para programas as alíquotas de Isenção. Essa programação é feita de maneira "hardcoded". Se inserirmos as novas alíquotas de Isenção de ISSQN, precisaremos "empurrar" as alíquotas existentes, para novos Índices. Ou seja, hoje a memória INI do ECFVirtual é salva como: [Aliquotas] 00=1|FF|0|T|0| 01=2|II|0|T|0| 02=3|NN|0|T|0| 03=4|04|18|T|1| 04=5|05|12|T|0| 05=6|06|5|S|0| passaria a ser: [Aliquotas] 00=1|F1|0|T|2| 01=2|I1|0|T|2| 02=3|N1|0|T|2| 03=4|FS1|0|S|2| 04=5|IS1|0|S|1| 05=6|NS1|0|S|3| 06=7|07|18|T|2| 07=8|08|12|T|1| 08=9|09|5|S|1| O ACBrECF já possui um código para interpretar a nomenclatura de alíquotas de Isenção. Exemplo: "NN" será interpretado como "N1", "FF", será interpretado como "F1", etc... O ACBrECF não terá problemas, se você busca as alíquotas pelo Valor e Tipo. Exemplos: "18", "5S", "17T" O problema ocorrerá apenas, se você busca a alíquota pelo índice. Exemplos: "T03", "T05", "S04" A Unit em anexo, já possui um código que verifica que a memoria do ECFVirtual, não possui suporte as alíquotas de isenção do ISSQN, e faz a atualização do arquivo .INI para o novo formato... (isso é executado apenas uma vez) Por favor analisem a questão, e o fonte em anexo.. e manifestem, se vocês consideram essa modificação ser um problema que poderá causar muito impacto nos usuários do ECFVirtual ACBrECFVirtual.pas PS: A Unit em anexo, ainda não foi enviada para o SVN

Boa Tarde, Implementei a NFC-e no próprio PAF e configuro o ACBrECF para virtual, mas ao registrar item com alíquotas diferentes retorna o erro de alíquota não registrada, como faço nesse caso?. Tentei usar o ACBrECFVirtualNFCe, mas tive duvidas, tenho que conectar o ACBrNFe nele e preencher normalmente? ou tenho que utilizar o método vendeitem? Já olhei bastante os exemplos e li os manuais, mas se vocês tiverem mais material para me ajudar eu agradeceria muito. Desde já agradeço!

Boa tarde, após a atualização dos componentes Acbr, tive problemas com o método VendeItem da Unit ACBrECF. Minha rotina estava passando alíquota com o sulfixo e indice ("T01","S01" etc), mas agora o item é impresso na ecf, e logo depois gera uma exceção de alíquota não encontrada e cancela o item. Na nova unit ACBrECF, existem dois novos métodos, IniciaVendeItem() e FinalizaVendeItem(), essas duas passam por rotinas que verificam a aliquota e nesse ponto está meu problema... Passo a aliquota("T01") como parâmetro para o metodo VendeItem(), a rotina IniciaVendeItem() verifica minha aliquota pelo sufixo("T") e depois pelo indice("01"), ela salva o índice dentro da mesma variavel onde se encontrava a aliquota, perdendo assim o sufixo(ficando apenas "01"). Logo em seguida é impresso o item normalmente. E no final é executado o metodo FinalizaVendeItem() onde ele executa a mesma verificação de aliquota com a mesma variável, porém agora só está o indice("01"), gerando assim a exceção de aliquota não encontrada e cancelando o item que acabou de ser impresso. Desde já agradeço a atenção.

Bom dia senhores. Fazendo alguns testes, reparei que ao carregar as alíquotas utilizando o protocolo escECF, na propriedade "Total", está me retornando o total do imposto de determinada alíquota, diferente dos outros protocolos que me retornam o total vendido para aquela alíquota (Testei com a MP-2100). Posso fazer o cálculo para obter o total vendido na aplicação sem problema nenhum, porém, não seria interessante este cálculo já ser feito na unit ACBrECFEscECF, na função "CarregaAliquotas", assim retornando o valor total vendido, como é feito com os outros modelos? Nos retornos do comando pelo que vi, não há o valor total vendido, não sei se isso é algo do convênio 09/09 mesmo, que talvez não tenha este retorno... Abraço.

Bom dia! Estou com uma impressora Epson TM-T81 FBIII e não consigo imprimir as alíquotas no cupom fiscal. Estou enviando os dados exatamente como no executável de teste. Aliás, o executável de teste também não imprime as alíquotas. Existe alguma configuração necessária para isso? Obrigado.

Me tirem uma dúvida, estou querendo pegar o índice de uma alíquota, estou utilizando a função: AchaICMSAliquota que pede como parâmetro o Valor da Alíquota ou o Valor da Alíquota e o Tipo. Quero saber se dá certo com as alíquotas não tributadas. FF, II, NN, SF, SI e SN ? Exemplo: var Aliquota : TACBrECFAliquota; indice, tpali : String; begin Aliquota := TACBrECFAliquota.create; tpali := 'FF'; Aliquota := dmECF.ACBrECF.ECF.AchaICMSAliquota(tpali); indice := Aliquota.Indice; // Erro aqui. end; Não está dando certo, pois a variável Aliquota está Nil, e logicamente quando tentar pegar o índice dá erro Access Violation. Alguem já passou por isso? Help.