Pesquisar na Comunidade

Cidade/UF: Santa Maria - RS Previsão de Mudança: 1º de janeiro de 2026 Tipo de Mudança: Continuar usando o provedor atual, com a modalidade de compartilhamento com o padrão nacional, modificando o leiaute do provedor. ---Comunicado – Emissão de Notas Fiscais (NFS-e) via Webservice--- Prezado Contribuinte, A Prefeitura de Santa Maria/RS informa que está disponibilizando o Manual de Integração destinado aos contribuintes que utilizam o serviço de integração via WebService para a emissão de Notas Fiscais de Serviço Eletrônicas (NFS-e). Esse novo modelo contempla a implementação do Imposto sobre Bens e Serviços (IBS), em conformidade com as diretrizes estabelecidas pela legislação federal. Com o objetivo de assegurar uma transição técnica segura e organizada, o cronograma de implantação seguirá as seguintes etapas: ➜ Segunda quinzena de novembro de 2025: disponibilização do ambiente de homologação (testes) para contribuintes que utilizam integração via WebService. ➜ Janeiro de 2026: início oficial da emissão da NFS-e conforme o padrão nacional, em atendimento às novas exigências legais e fiscais. O Manual de Integração Webservice apresenta, de forma detalhada, o modelo de referência para o desenvolvimento e a operação dos sistemas de emissão da NFS-e. O documento reúne as especificações técnicas, critérios de comunicação e orientações para o envio de lotes, oferecendo suporte completo à adaptação dos contribuintes ao novo formato nacional. A iniciativa reforça o compromisso da Administração Municipal em antecipar informações e orientações sobre as atualizações técnicas promovidas pela Receita Federal do Brasil, que impactarão diretamente na padronização nacional dos documentos fiscais eletrônicos e, consequentemente, no layout da NFS-e. O objetivo é garantir que todos os contribuintes estejam plenamente preparados e alinhados ao novo padrão nacional, fortalecendo a confiabilidade dos documentos fiscais eletrônicos em todo o território nacional. Faça o download do material, clicando nos títulos abaixo: 1 – O Manual de Integração Webservice (CLIQUE AQUI). (https://www.issnetonline.com.br/santamaria/online/Login/Login.aspx?getFile=1107) 2 – Informativo referente ao cronograma (CLIQUE AQUI). (https://www.issnetonline.com.br/santamaria/online/Login/Login.aspx?getFile=1058) 3 – Informativo técnico (CLIQUE AQUI). (https://www.issnetonline.com.br/santamaria/online/Login/Login.aspx?getFile=1108)

Olá Pessoal, O uso do Padrão Nacional é um movimento crescente, começando com sua obrigatoriedade para os MEIs em 2023, sua próxima obrigatoriedade para os prestadores enquadrados no Simples Nacional agora em 2026 (veja mais sobre isso aqui) e o fato de todos os 5.571 municípios terem se conveniado, seja para realizar a emissão direta ou via compartilhamento de informações. Diferente de situações anteriores, a prerrogativa de "padrão" implica em uma padronização única. Isso se aplica inclusive ao próprio leiaute do DANFSe. Onde anteriormente não havia nenhuma regulamentação ou orientação sobre como deve ser o leiaute do impresso, hoje existem definições explícitas com a publicação da Nota Técnica Nº008, estabelecendo parametrizações como o que pode constar no impresso, o que não pode e como as informações devem ser exibidas nele. A equipe do ACBr já adaptou o impresso em Fortes para atender a essas definições e está trabalhando arduamente para disponibilizar os impressos em Fast e em FPDF. Levando tudo isso em consideração, informamos que os esforços a partir de agora serão focados em manter o DANFSe atendendo à NT Nº008 ou qualquer publicação futura relacionada e, por isso, não serão feitas novas alterações no DANFSe utilizado para os provedores no leiaute da ABRASF e em leiautes próprios. Ressaltamos que, na conjuntura atual, mesmo os municípios que aderiram apenas ao compartilhamento e vão continuar utilizando provedores próprios já têm disponibilizado em seus arquivos XML e retornos do web service os meios para que o XML da NFS-e compartilhado no ambiente nacional seja acessado e, de posse desse XML, o DANFSe no leiaute estabelecido pela NT Nº008 pode ser utilizado. Agradecemos a compreensão de todos.

Olá, comunidade ! No dia 14/07/2026, por volta das 9h49, começamos a receber relatos de membros da nossa comunidade com problemas na emissão de notas fiscais de serviço para o município de São Paulo. Os relatos informavam que, ao tentar se comunicar com o web service, era devolvido timeout. Realizando testes, o timeout foi constatado mesmo com um valor de 60 segundos configurado na propriedade de timeout do componente. Ao acessar a URL diretamente pelo navegador, a URL também apresentou lentidão. Buscando mais informações sobre o problema, ao acessar a página da Nota Fiscal Paulistana, foi observado o seguinte aviso informando manutenção programada para hoje:

Olá, comunidade ! Como muitos devem saber, a partir de 01/09/2026, todos os prestadores de serviço optantes pelo Simples Nacional deverão emitir suas notas fiscais de serviço eletrônicas diretamente pelo emissor nacional — também conhecido como Padrão Nacional — independentemente do município ao qual pertençam. Se você não sabe do que se trata, veja este tópico. Recebemos a informação de que o município de Guarulhos adiantou essa migração para o dia 01/07/2026. Portanto, desde essa data, todos os prestadores de serviço optantes pelo Simples Nacional do município devem realizar a emissão de suas NFS-e diretamente no Padrão Nacional. Veja no tópico abaixo o que é preciso alterar no ACBr para fazer isso: Um agradecimento a todos os membros da comunidade que compartilharam essa informação conosco em nosso fórum.

Cidade/UF: Franca/SP Previsão de Mudança: 1º de janeiro de 2026 Tipo de Mudança: API própria (manterá provedor SIL Tecnologia) Fonte/Documentação: https://interface.siltecnologia.com.br/apidocs/franca/#tag/Nota-Fiscal-Nacional O município em questão optou por Emissor Próprio e assim, o fluxo de emissão será: 1. Contribuinte envia a nota para a sistema da prefeitura (link disponibilizado abaixo). 2. Prefeitura recepciona a nota e valida as condições municipais - exemplo: atividade pertence a empresa, dedução permitida para a atividade, questões de isenção e imunidade. Se tiver algo inconsistente, retorna com a rejeição municipal para o Contribuinte e a nota não é emitida. 3. Caso não haja rejeição municipal (atividade não permita, dedução indevida e etc - por exemplo), a prefeitura compartilha a nota com o Emissor Nacional. Se o Nacional rejeitar alguma informação, retorna a rejeição para o Contribuinte e a nota não é emitida. 4. Se a prefeitura e o Emissor Nacional aceitaram o XML enviado, a nota é gerada com sucesso e será retornado a chave de acesso gerada pela receita (código numérico de 50 posições). Em resumo, o XML a ser enviado no padrão nacional precisa ser aceito tanto pelo municipio emissor, quanto pela receita ou a nota não será gerada. Não será aceito envio via arquivo TXT, sendo disponível apenas via WebService. Não será aceito envio assíncrono, sendo aceito apenas envio síncrono - envia uma nota e aguarda a resposta, não pode enviar e consultar a situação depois. Não será aceito envio em lote, sendo aceito envio de nota a nota - envia uma nota, aguarda a resposta, envia a proxima. A documentação e orientações do novo modelo NF Nacional estão disponíveis no link: https://interface.siltecnologia.com.br/apidocs/franca/#tag/Nota-Fiscal-Nacional

Um elemento que faz parte do contexto da NFS-e é o link de impressão. Esse link é uma URL que, ao ser acessada, exibe o DANFSe correspondente à nota fiscal eletrônica autorizada, permitindo que o documento seja salvo ou impresso. Além disso, esse link também é utilizado pelas soluções ACBr para gerar o QR Code no DANFSe. Existem três maneiras de esse link ser gerado; Devolvida no XML da NFS-e A forma mais comum é quando o próprio web service do provedor gera o link e o devolve como parte do XML, seja em uma tag específica para essa finalidade — como, por exemplo, LinkNFSe, LINK, linkPdf, LinkImpressao ou Url —, seja dentro da tag OutrasInformacoes. Se o arquivo XML da sua NFS-e não possuir essa informação, isso quer dizer que ela não é gerada e devolvida a você pelo provedor e o link precisará ser gerado de outra maneira. URL base no arquivo ACBrNFSeXServicos.ini Alguns provedores disponibilizam uma URL base com query params que podem ser utilizados para gerar a URL correspondente à respectiva nota. Essas URLs ficam armazenadas nas chaves HomLinkURL, para o ambiente de homologação, e ProLinkURL, para o ambiente de produção. Por meio do método ACBrNFSeX.LinkNFSe, passando os parâmetros necessários, a solução ACBr constrói a URL completa. Alguns exemplos de HomLinkURL/ProLinkURL no arquivo ACBrNFSeXServicos.ini: [3550308] Nome=Sao Paulo UF=SP Provedor=ISSSaoPaulo ProLinkURL=https://nfe.prefeitura.sp.gov.br/nfe.aspx?ccm=%InscMunic%&nf=%NumeroNFSe%&cod=%CodVerif% HomLinkURL=https://nfe.prefeitura.sp.gov.br/nfe.aspx?ccm=%InscMunic%&nf=%NumeroNFSe%&cod=%CodVerif% [3552205] Nome=Sorocaba UF=SP Provedor=DSF Versao=2.03 ProLinkURL=https://notafiscal.sorocaba.sp.gov.br/notafiscal-ws/servico/notafiscal/autenticacao/cpfCnpj/%Cnpj%/inscricaoMunicipal/%InscMunic%/numeroNota/%NumeroNFSe%/codigoVerificacao/%CodVerif% HomLinkURL=https://homolsod.dsfweb.com.br/notafiscal-ws/servico/notafiscal/autenticacao/cpfCnpj/%Cnpj%/inscricaoMunicipal/%InscMunic%/numeroNota/%NumeroNFSe%/codigoVerificacao/%CodVerif% Se, ao consultar a cidade no arquivo ACBrNFSeXServicos.ini, ela não tiver nenhuma dessas chaves, então essa URL não é fornecida pelo provedor e o link precisará ser gerado de outra maneira. Utilizando o método de consulta A forma menos comum é quando o provedor disponibiliza em seu web service um endpoint de consulta que devolve o link diretamente. Nesse caso, utilize o método ACBrNFSeX.ConsultarLinkNFSe, passando os parâmetros necessários. A solução se comunicará com o web service do provedor e retornará a URL. Para verificar se o provedor permite esse tipo de consulta, consulte os métodos disponíveis para o provedor (veja como fazer isso neste tópico). Exemplo de caso em que o provedor permite a consulta de link: Importante Como já mencionado, o QR Code impresso no DANFSe é gerado a partir dessa URL. Portanto, se nenhuma das alternativas for possível para o provedor utilizado, o link de impressão não poderá ser gerado e o QR Code não será exibido no DANFSe.

Olá comunidade ! Informamos que o DANFSe no motor Fortes Report foi adequado com sucesso às definições da Nota Técnica nº 008, que define o leiaute do DANFSe. Antes: Depois: A situação atual do DANFSe no ACBr é: Motor de relatório Atualizado conforme NT? Fortes Report Sim Fast Report Não FPDF Não Fique de olho em nossa área de notícias para novidades quanto aos demais motores de relatório

Quando gera o DANFSe eke acaba registrando o valor do ISS pra 973,35 em vez do 9,73: O que era pra imprimir de valor: No XML a tag <valor_iss> vem 9.7335, e no SigISSWeb.LerXml.pas ele pega o conteúdo do valor_iss (9.7335) e transforma em string ('9.7335'), logo em seguida transforma em numero ('97335') e depois de stringdecimal pra float (973.35), o certo é usar a mesma funcionalidade do Aliquota em que faz corretamente a conversão: SigISSWeb.LerXml.pas

Bom dia pessoal, em relação ao provedor Equiplano, não estou conseguindo emitir notas no ambiente de homologação estava emitindo até dia 09/12, desde ontem começou a retornar: <?xml version="1.0" encoding="UTF-8"?><ns:return>org.hibernate.hql.internal.ast.QuerySyntaxException: Invalid path: 'servicoSubItem.servicoAeItem' [SELECT servico FROM es.nfs.model.NfsServicoAeEspecializacaoModel servico JOIN FETCH servico.servicoAeDesdobro servicoAeDesdobro JOIN FETCH servicoAeDesdobro.servicoAeSubItem servicoAeSubItem JOIN FETCH servicoSubItem.servicoAeItem servicoAeItem WHERE servico.entidade.idEntidade = :idEntidade AND servico.codServicoAeEspecializacao = :codServicoAeEspecializacao]</ns:return> Entrei em contato com o pessoal da prefeitura de Francisco Beltrão/PR, os mesmos responderam que tem que adequar a reforma tributária, mas não consegui identificar quais serão essas alterações para o provedor Equiplano. Vários municípios utilizam esse Provedor e tenho integração alguma informação sobre alterações desse provedor em relação a reforma tributária? esnfs_Equiplano_Homologacao11_2025_4 (1).pdf

Ao emitir uma DPS em homologação ou produção utilizando o layout XML como Padrão Nacional e não sendo MEI ou Simples Nacional a partir de 01/09/2026, caso ocorra a rejeição E0037 - O código do município emissor informado na DPS é inexistente no cadastro de convênio municipal do sistema nacional, como faço para saber se o município está aderido tanto ao ambiente de produção quanto homologação? 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 cLocEmi O código do município emissor informado na DPS deve existir no cadastro de convênio municipal do sistema nacional. Exceto quando o emitente da DPS for MEI na data de competência da emissão da NFS-e. E0037 O código do município emissor informado na DPS é inexistente no cadastro de convênio municipal do sistema nacional. Primeiro, acesse o Monitor de adesão dos municípios à NFSe Padrão Nacional neste link. Filtre pela cidade e confira se está marcado como Sim em Adesão ao Emissor Nacional NFSe*, conforme prints abaixo. Observação: no momento do teste a cidade de Rancharia/SP estava constando como habilitado o webservice de produção e homologação não, já a cidade de Governador Valadares está com os dois habilitados. Confirmando que o município está aderido a emissão a partir do Padrão Nacional, faça a consulta do Convênio a partir da Consulta de Parâmetros Municipais. Você pode utilizar o demo para conferir a informação clicando no botão Convênio que fica na guia Consulta de Parâmetros Municipais da guia Provedor Padrão Nacional. Para fazer no componente utilize o código abaixo: ACBrNFSeX1.ConsultarParametros(pmConvenio); No monitor: NFSe.ConsultarParametrosNFSe(2, "01.05", "19/06/2023", "12345") Na Lib: NFSE_ConsultarParametros(2, aCodigoServico, aCompetencia, aNumeroBeneficio, sResposta, esTamanho); Ao consultar teremos os seguintes retornos: Tanto para Governador Valadares/MG em Produção quanto em Homologação o retorno foi o mesmo: Já para a cidade de Rancharia/SP, em Produção o retorno foi: Já em Homologação para a cidade de Rancharia/SP foi: Tendo em vista estes retornos, a cidade de Rancharia/SP por exemplo não está ativa no ambiente de Homologação no Sistema Nacional, mas em Produção sim. Você não conseguirá emitir NFSe no ambiente de homologação, apenas produção. Você pode também entrar em contato com a prefeitura também e informar o fato para eles, solicitar que façam a adesão ao ambiente de homologação também. Observações sobre os testes que realizamos: Ao testar a emissão em homologação, foram apresentadas rejeições relacionadas a validação dos campos, mas ao corrigir ocorreu o erro E0037, portanto pode ser que ao testar em sua aplicação ou no seu demo, ocorra erros de validação como CPF/CNPJ do Tomador errado, mas após corrigir todos vai aparecer a rejeição E0037. É possível que o ambiente nacional só faça a validação se está mesmo aderido após realizar as outras validações. Referências:

Olá Pessoal, É com muita alegria que venho informar a todos que o componente ACBrNFSeX já esta pronto para atender o novo WebService do provedor Fiorilli que trabalha com o layout do Padrão Nacional, além disso existe também a particularidade da existência de algumas versões do webservice disponíveis nas prefeituras e cada uma decide quando se atualiza para algo mais recente, inclusive com versões que ainda não contemplam os campos da Reforma Tributária. Como o ACBrLibNFSe e o ACBrMonitor Plus se utilizam do componente ACBrNFSeX assim que for disponibilizado uma nova versão essas duas soluções ACBr também vão atender o novo WebService do provedor. Mudanças em sua Aplicação Configurações do componente ACBr ou ACBrMonitor/ACBrLib Não muda nada, pois tanto o componente quanto as soluções ACBrMonitor e ACBrLib se autoconfiguram conforme as informações existentes no arquivo ACBrNFSeXServicos.ini, o qual é atualizado pela equipe ACBr conforme recebemos as informações de mudanças. Alimentação dos componente ACBr ou ACBrMonitor/ACBrLib Se sua aplicação já atende clientes que se utilizam do layout do padrão nacional, seu software já deve estar adequado a este modelo, então nenhuma alteração será necessária em sua aplicação, porém se não for este o caso, será necessário a implementação do preenchimento dos dados considerando o padrão nacional para o componente ou envio das informações ao ACBrMonitor/ACBrLib conforme os modelos existentes em nossa documentação e exemplos. Importante Os dados passados para o componente ou para o arquivo INI (para quem usa a Lib ou o Monitor) mudam ao se utilizar o novo webservice da Fiorilli, sendo assim é importante observar os modelos citados acima. Nem todos os serviços disponíveis no webservice antigo estão disponíveis no novo, como por exemplo o ConsultarNFSeServicoPrestado, o ConsultarNFSeServicoTomado e o SubstituirNFSe, sendo assim ao obter o retorno Serviço não Implementado, se deve a este fator, ou seja a Fiorilli ainda não implementou o serviço em seu novo webservice. É importante lembrar que a Fiorilli continua com o seu webservice "antigo" que recepciona o XML segundo a versão 2.00 do layout da ABRASF, mas não sabemos quando eles o desativarão, sendo assim recomendamos iniciar a mudança assim que possível. E se uma cidade atendida pelo meu software mudou, o que fazer? Dado que as cidades estão em processo de atualização, é natural que ao longo do tempo seja preciso atualizar, sendo assim ao identificar essa mudança, seja por um relato de cliente ou da própria prefeitura, você pode abrir um tópico em nosso fórum e nos informar, mas se desejar já validar se realmente a mudança está funcional do lado da prefeitura e quiser nos ajudar, você pode também seguir o procedimento abaixo e realizar um teste em seu ambiente e em seguida nos enviar as mudanças. O provedor Fiorilli atende mais de 300 cidades, cotamos com a colaboração de todos vocês para nos informar qual cidade vocês testaram e com qual versão funcionou. O que mudar no arquivo ACBrNFSeXServicos.ini para que possamos realizar os testes e passar a utilizar o novo webservice? Descobrindo a versão correta a inserir no INI? Atualmente para identificar se deve-se configurar a versão 1.01 ou 1.00 , saberemos isso conforme os testes a seguir Se configurarmos no arquivo ACBrNFSeXServicos.ini que a cidade usa a versão 1.00 e enviarmos o DPS para o WebService, se ocorrer o erro abaixo significa que na verdade essa cidade já esta usando a versão 1.01 unexpected element (uri:"http://www.fiorilli.com.br/nfse-nacional", local:"DPS"). Expected elements are {http://www.sped.fazenda.gov.br/nfse}DPS Por outro lado se configurarmos no arquivo ACBrNFSeXServicos.ini que a cidade usa a versão 1.01 e enviarmos o DPS para o WebService, se ocorrer o erro abaixo significa que na verdade essa cidade esta usando a versão 1.00 unexpected element (uri:"http://www.sped.fazenda.gov.br/nfse", local:"DPS"). Expected elements are {http://www.fiorilli.com.br/nfse-nacional}DPS Resumindo, na versão 1.00 o namespace esperado tem que ser o da Fiorilli (http://www.fiorilli.com.br/nfse-nacional) e na versão 1.01 tem que ser o do Padrão Nacional (http://www.sped.fazenda.gov.br/nfse). Bom agora vocês já sabem o que tem que fazer quando aparecer esses erros, basta mudar a versão informada no campo Versao que se encontra na seção da cidade que vocês estão testando. Vamos agora para o arquivo ACBrNFSeXServicos.ini Primeiramente quero informar que nesse arquivo INI temos uma seção chamada [Fiorilli] que nela consta a URL de homologação para o novo WebService e o campo Versao com o valor 1.00, logo estamos supondo que todas as cidades estão usando essa versão. Após a alteração do arquivo ACBrNFSeXServicos.ini é importante seguir as orientações que se encontram no inicio dele, do contrário as alterações feitas não serão válidas. Como fica a seção das cidades atendidas pelo provedor que utilizam a versão 1.00 que já alteramos no arquivo INI: [1100122] Nome=Ji-Parana UF=RO Provedor=Fiorilli ProRecepcionar=https://nfse.ji-parana.ro.gov.br/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType ;Versao=2.00 ;ProRecepcionar=https://nfse.ji-parana.ro.gov.br/IssWeb-ejb/IssWebWS/IssWebWS ;ProLinkURL=http://177.124.184.59:5660/issweb/formGerarNF.jsf?nroNota=%NumeroNFSe%&codVerificacao=%CodVerif%&cnpj=%Cnpj%&hash=%ChaveAcesso% (...) [2104099] Nome=Formosa da Serra Negra UF=MA Provedor=Fiorilli ProRecepcionar=http://nfse.adtrcloud.com.br:8097/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType ;Versao=2.00 ;ProRecepcionar=http://nfse.adtrcloud.com.br:8097/IssWeb-ejb/IssWebWS/IssWebWS ;ProLinkURL=http://nfse.adtrcloud.com.br:8097/issweb/formGerarNF.jsf?nroNota=%NumeroNFSe%&codVerificacao=%CodVerif%&cnpj=%Cnpj%&hash=%ChaveAcesso% (...) [3504008] Nome=Assis UF=SP Provedor=Fiorilli ProRecepcionar=https://nfsews.assis.sp.gov.br/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType ;Versao=2.00 ;ProRecepcionar=https://nfsews.assis.sp.gov.br/IssWeb-ejb/IssWebWS/IssWebWS ;ProLinkURL=http://nfsews.assis.sp.gov.br/issweb/formGerarNF.jsf?nroNota=%NumeroNFSe%&codVerificacao=%CodVerif%&cnpj=%Cnpj%&hash=%ChaveAcesso% (...) [3537107] Nome=Pedreira UF=SP Provedor=Fiorilli ProRecepcionar=http://intranet.pedreira.sp.gov.br:5661/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType ;Versao=2.00 ;ProRecepcionar=http://intranet.pedreira.sp.gov.br:5661/IssWeb-ejb/IssWebWS/IssWebWS ;ProLinkURL=http://intranet.pedreira.sp.gov.br:5661/issweb/formGerarNF.jsf?nroNota=%NumeroNFSe%&codVerificacao=%CodVerif%&cnpj=%Cnpj%&hash=%ChaveAcesso% Notem que comentamos os campos: Versao=2.00 e os campos que tem a URL e o Link utilizados pelo WebService antigo que trabalha com a versão 2 do layout da ABRASF. Notem também que não foi informado que a versão é 1.00, pois por padrão ele vai pegar essa informação lá da seção do provedor. Como fica a seção das cidades atendidas pelo provedor que utilizam a versão 1.01 que já alteramos no arquivo INI: [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 ;Versao=2.00 ;ProRecepcionar=http://45.71.14.83:5661/IssWeb-ejb/IssWebWS/IssWebWS (...) [3526407] Nome=Laranjal Paulista UF=SP Provedor=Fiorilli Versao=1.01 Params=ServicosAPIPropria:ConsultarNFSeRps,ConsultarNFSePorChave| ProRecepcionar=http://pmlpta.ddns.com.br:6118/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType ProConsultarNFSePorChave=http://pmlpta.ddns.com.br:6118/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType ProConsultarNFSeRps=http://pmlpta.ddns.com.br:6118/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType ;Versao=2.00 ;ProRecepcionar=http://pmlpta.ddns.com.br:6118/IssWeb-ejb/IssWebWS/IssWebWS ;ProLinkURL=http://pmlpta.ddns.com.br:6118/issweb/formGerarNF.jsf?nroNota=%NumeroNFSe%&codVerificacao=%CodVerif%&cnpj=%Cnpj%&hash=%ChaveAcesso% Notem que comentamos os campos: Versao=2.00 e os campos que tem a URL e o Link utilizados pelo WebService antigo que trabalha com a versão 2 do layout da ABRASF. Notem também que foi informado que a versão é 1.01 e temos também o campo Params com os serviços: ConsultarNFSeRps e ConsultarNFSePorChave, pois nesta versão o webservice possui esses serviços, logo ele não se utiliza dos serviços disponibilizados pela API do Padrão Nacional. Um detalhe importante é que no final da linha do campo Params temos o caracter pipe "|", ele é obrigatório. Outra informação importante é as URLs para os referidos serviços destacados em Params. As cidades mostradas acima foram alteradas e testadas, mas desejo fazer testes com uma cidade do meu cliente como devo proceder? Vamos a um exemplo: [3519303] Nome=Ibate UF=SP Provedor=Fiorilli Versao=2.00 ProRecepcionar=http://200.205.131.110:5661/IssWeb-ejb/IssWebWS/IssWebWS ProLinkURL=http://200.205.131.110:5661/issweb/formGerarNF.jsf?nroNota=%NumeroNFSe%&codVerificacao=%CodVerif%&cnpj=%Cnpj%&hash=%ChaveAcesso% ; A URL abaixo deve ser utilizada a partir de 01/02/2026 quando o WebService novo vai passar a ser utilizado. ;ProRecepcionar=http://200.205.131.110:5661/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType A cidade de Ibaté/SP consta que usa a versão 2.00 e as URL se referem ao webservice antigo que usa o layout da ABRASF. A URL que esta comentada já é a URL do novo webservice que usa o layout do Padrão Nacional. Alteração supondo que o sistema instalado na prefeitura usa a versão 1.00 do Padrão Nacional: [3519303] Nome=Ibate UF=SP Provedor=Fiorilli ProRecepcionar=http://200.205.131.110:5661/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType ;Versao=2.00 ;ProRecepcionar=http://200.205.131.110:5661/IssWeb-ejb/IssWebWS/IssWebWS ;ProLinkURL=http://200.205.131.110:5661/issweb/formGerarNF.jsf?nroNota=%NumeroNFSe%&codVerificacao=%CodVerif%&cnpj=%Cnpj%&hash=%ChaveAcesso% Se não funcionar, ou seja, ocorrer o erro já mostrado acima temos que incluir o campo versão e params, pois certamente o sistema instalado na prefeitura é mais atual e trabalha com a versão 1.01 do Padrão Nacional: [3519303] Nome=Ibate UF=SP Provedor=Fiorilli Versao=1.01 Params=ServicosAPIPropria:ConsultarNFSeRps,ConsultarNFSePorChave| ProRecepcionar=http://200.205.131.110:5661/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType ;Versao=2.00 ;ProRecepcionar=http://200.205.131.110:5661/IssWeb-ejb/IssWebWS/IssWebWS ;ProLinkURL=http://200.205.131.110:5661/issweb/formGerarNF.jsf?nroNota=%NumeroNFSe%&codVerificacao=%CodVerif%&cnpj=%Cnpj%&hash=%ChaveAcesso% Lembre-se que após a alteração devemos: Após a alteração do arquivo ACBrNFSeXServicos.ini é importante seguir as orientações que se encontram no inicio dele, do contrário as alterações feitas não serão válidas. Observação: Não testamos a cidade de Ibaté/SP trata-se de um exemplo de como devemos alterar a seção da cidade para usar o novo webservice, sendo assim uma das duas alterações mostradas acima vai funcionar, qual delas, só testando. Tópico relacionado Um agradecimento especial ao nosso consultor @Diego Foliene e ao membro do fórum @Diego Reckziegel, pelos ajustes no código do componente.

Fiz os ajustes para o correto tratamento armazenando o retorno na coleção Resumos como em outros provedores. Essa é uma alteração válida? Como posso passar meu código para análise e possível aprovação?

Cliente situado no município supracitado me procurou informando que a prefeitura não vai mudar para o novo padrão da Pronim, a prefeitura informou que continuará usando o padrão ABRASF 2.02. Até consegui configurar o componente pra gerar nesse padrão, só que o código do 2.02 já está gerando tags como CodigoNbs, onde os schemas 2.02 da Pronim não aceitam. Não encontrei no site da prefeitura qualquer material explicativo de como usar seu serviço de emissão de NFS-e, só existe link para entrar no painel, só se lá dentro existam os materiais. Se alguém tem Cliente em Jaguarão e já está com isso resolvido dá um socorro. A prefeitura voltou a aceitar os rps no formato antigo por hora.

Atualmente estou usando apenas o componente ACBrNFSeX, antes usava apenas o ACBrNFSe, esse último está "marcado como deprecated", indicando utilizar o novo. No instalador quando seleciono o componente ACBrNFSe automaticamente todas as dependências são marcadas, mas se seleciono só o ACBrNFSeX somente ele fica marcado. Tentei instalar dessa forma, começou compilando synapse, comum, diversos... achei que era apenas bug visual e que iriam ser compiladas todas as dependências, mas não... Faltou o OpenSSL, marquei ele e repeti a instalação, faltou o DFeComum, esse quando marquei, marcou o Integrador e o TCP também, aí sim instalou o ACBrNFSeX. É um "defeito" pouco percebido, pois imagino que a maioria instala a suite toda, mas mapeei as dependências para instalar apenas o NFS-e novo, se alguém tiver o interesse de ver como corrigir o instalador vai poupar tempo de algum novato.

Já faz algum tempo que os municípios de São José dos Pinhais/PR e Dionisio Cerqueira/SC mudaram para PadraoNacional e toda vez que atualizo minha cópia dos fontes tenho que conferir e ambos ainda estão com valores anteriores, ISSSJP e Betha respectivamente. Imagino que outras cidades também mudaram e continuam sem atualização, mas essas são duas que tenho certeza que mudaram na prática mas não foram atualizadas no INI.

Não encontrei na versão mais atual do componente alguma opção para imprimir os dados do IBS e CBS na nota fiscal. Fiz o teste na prefeitura de São Paulo, que já migrou para a versão 2.00 e o envio com os novos campos correu sem problemas. O modelo baixado diretamente pelo sistema da prefeitura (através do qrcode da nota) inclui uma segunda página com os dados, conforme anexo.

Cidade/UF: Pedreira/SP Previsão de Mudança: 1º de janeiro de 2026 Tipo de Mudança: Continuar usando o provedor atual, com a modalidade de compartilhamento com o padrão nacional através de API própria do provedor Fonte/Documentação: http://intranet.pedreira.sp.gov.br:5661/issweb/home.jsf?formAtalho=formAtalho&javax.faces.ViewState=stateless

acbr_correcao_envio_apenas_do_Cofins.zip NFSe Nacional Estou submetendo para avaliação algumas alterações relacionadas ao envio das informações de PIS/COFINS, com o objetivo de permitir a transmissão de notas contendo apenas os valores de tributação de COFINS, quando aplicável. Esse cenário atende entidades, federações e cooperativas que apuram o PIS sobre a folha de pagamento e, por esse motivo, destacam em suas notas apenas o COFINS. 1) acbr\Exemplos\ACBrDFe\ACBrNFSeX\Delphi\Frm_ACBrNFSeX.pas Foram implementadas três procedures para facilitar o teste de diferentes variações de tributação de PIS/COFINS para empresas fora do Simples Nacional. A implementação foi realizada dentro do método TfrmACBrNFSe.Alimentar_Componente_layout_PadraoNacional, contemplando os seguintes cenários de teste: -Caso de teste #001 CST 01 – Operação Tributável com Alíquota Básica Cst01PisCofinsComTributacaoDePisCofins(vNFSe); -Caso de teste #002 CST 01 – Operação Tributável com Alíquota Básica Cst01PisCofinsComTributacaoApenasDeCofins(vNFSe); - Caso de teste #003 CST 08 – Operação sem Incidência da Contribuição de PIS e COFINS Cst08PisCofinsSemIncidenciaDePisCofins(vNFSe); 2) acbr\Fontes\ACBrDFe\ACBrNFSeX\Provedores\PadraoNacional.GravarXml.pas Foi ajustado o método TNFSeW_PadraoNacional.GerarXMLTributacaoOutrosPisCofins: TACBrXmlNode; O ajuste permite o correto preenchimento das informações de PIS/COFINS de acordo com o CST, contemplando cenários onde apenas o COFINS é informado, sem exigência indevida dos dados de PIS. ________________________________________ Fico à disposição para ajustes, sugestões ou adequações, caso entendam necessário.

Bom dia O municipio de Sertãozinho - SP aderiu ao ambiente nacional. Gostaria de solicitar a atualização do arquivo ACBrNFSeXServicos.ini [3551702] Nome=Sertaozinho UF=SP Provedor=PadraoNacional Obrigado

Ao imprimir o PDF, está cortando o código da classificação de serviços, em vez de imprimir "14.10.01" está imprimindo "14.10." O código da classificação de serviços do provedor SIGISSWEB ele vem com o código completo no retorno ao emitir a NFS-e: <id_codigo_servico>14.10.01</id_codigo_servico> Logo ao executar o ACBrNFse.NotasFiscais.ImprimirPDF, dentro do componente ACBrNFSeXDANFSeFR na linha 1316 o "LCDS.FieldByName('ItemListaServico').AsString := LServico.ItemListaServico" o "LServico.ItemListaServico" mostra código inteiro (14.10.01) enquanto no "LCDS.FieldByName('ItemListaServico').AsString" acaba armazenando os 6 primeiros caracteres (14.10.), por conta que no próprio ACBrNFSeXDANFSeFR na linha 508 : "cdsServicos.FieldDefs.Add('ItemListaServico', ftString, 6);" está setado como padrão 6 caracteres, pra corrigir isso percebi 2 soluções: Mudar o "cdsServicos.FieldDefs.Add('ItemListaServico', ftString, 6);" pra 8 pra imprimir o código por completo "14.10.01" ou Na linha "LCDS.FieldByName('ItemListaServico').AsString := LServico.ItemListaServico" ter uma função para extrair somente os números do LServico.ItemListaServico "141001"

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!

Olá comunidade ! Para atender a Reforma Tributária que começa em 2026, os 5.570 municípios do Brasil deverão escolher entre 3 caminhos: Migrar para o Padrão Nacional com a modalidade de emissão. Continuar usando o provedor atual, com a modalidade de compartilhamento com o padrão nacional através de API própria do provedor. Continuar usando o provedor atual, com a modalidade de compartilhamento com o padrão nacional, modificando o leiaute do provedor. Para garantir que o componente ACBrNFSeX continue robusto e atualizado, antecipando essas mudanças, contamos o apoio da nossa comunidade. Como você pode ajudar? Se você tem contato com a prefeitura ou provedor responsável por atender algum município, por favor, compartilhe conosco. Qualquer informação oficial sobre alterações previstas pode ajudar. Responda aqui mesmo neste tópico conforme o modelo: Cidade/UF: Previsão de Mudança: Tipo de Mudança: (Padrão Nacional/API Própria/Mudança de Leiaute) Fonte/Documentação: Acompanhe o tópico abaixo para saber qual é a situação atual do componente

Ao tentar executar o evento ObterDANFSE() do Padrão Nacional esta ocorrendo o erro acima. Esse passou a ocorrer de quinta feira para cá, pois na quarta eu baixei um PDF sem nenhum erro, na sexta atualizei meus fontes começou a dar erro. Na imagem acima comentei essas linhas destacadas na imagem, parou de dar o erro e gerou o PDF. Esta ocorrendo erro no comando TACBrJsonObject.Parse(Response.ArquivoRetorno), pois o Response.ArquivoRetorno não é mais um JSON, já é o próprio PDF. Precisamos da análise e correção adequada por parte da ACBr.

Boa tarde pessoal, a quanto tempo. Primeiramente queria agradecer e parabenizar pelo excelente trabalho no novo componente ACBrNFSeX. Gostei muito da separação de arquivos por provedor -> versao -> municipio -> ambiente. Tanto que resolvi utilizar exatamente dessa maneira para não ter problemas em maquinas que emitem para mais de um provedor ou para o mesmo com versão/cidade diferente (ex.: uma contabilidade que atende vários clientes de diversas cidades). E para deixar no storage para download tbm resolvi adotar esse modelo. Então para facilitar as coisas, gostaria de mover a função "GetSchemaPath" dos provedores (TACBrNFSeXProvider e seus descendentes) do protected para public. Existe algum impeditivo para isso? Ou posso mover sem problemas? Se sim, segue em anexo as units alteradas. Att. ACBrNFSeXInterface.pas ACBrNFSeXProviderBase.pas Actcon.Provider.pas fintelISS.Provider.pas ISSJoinville.Provider.pas VersaTecnologia.Provider.pas

Cidade/UF: Santa Bárbara D'Oeste Previsão de Mudança: 01/2026 Tipo de Mudança: API Própria (SIGISSWEB) Fonte/Documentação: No anexo abaixo. O de homologação pra teste dos novos campos é na URL https://wshml.sigissweb.com/rest/ MaterialParaIntegracaoCBSIBS.rar