Pesquisar na Comunidade

boa tarde, estou tentando enviar rps's para de um prestador da cidade de São Caetano do Sul/SP e não estou conseguindo identificar a falha no meu XML, já li e realizei testes com os outros fóruns fechados que envolvem o mesmo código de erro para o ginfes, e ainda não consegui corrigir, alguém consegue me ajudar a identificar aonde está o problema no XML anexado? NF53871-rps.xml

Olá comunidade ! Por volta das 10h do dia 03/06/2026, começamos a receber alguns relatos de membros da nossa comunidade de problemas ao emitir NFS-e para o provedor GISS da empresa EICON. Os relatos tinha em comum o mesmo retorno com a seguinte rejeição: Depois de entrar em contato com o suporte do provedor o membro de nossa comunidade @Luiz Ribeiro conseguiu o seguinte retorno confirmando que o problema ocorre do lado do web service e o provedor está se movimentando para providenciar uma correção.

Olá comunidade ! Foi publicada a Nota Técnica nº009 alterando o leiaute da NFS-e para adequação a Reforma Tributária sobre o consumo. Alterações Altera os campos que recebem a informação de CNPJ para o tipo carácter visando adequação ao CNPJ alfanumérico. Cria o grupo gIBSCBSAjuste para informar o IBS/CBS quando NFS-e de ajuste. Adiciona a possibilidade de gerar NFS-e de débito e crédito ao incluir os valor "1 - NFS-e de crédito" e "2 - NFS-e de débito" além de adicionar novos campos tpNFSeDebito e tpNFSeCredito no layout. Remove alguns valores possíveis do campo tpAjusteBC. Adiciona novo valor "4 - Optante Pendente" no campo opSimpNac. Renomeia alguns campos. Traz novamente o campo indFinal. Adiciona campos como o regApIBSCBSSN, vReceitaBrutaSN e o grupo gTribSN para informar IBS e CBS quando para os optantes do Simples Nacional com apuração de IBS e CBS. Cria um grupo para vincular pagamentos a NFS-e. Adiciona novos grupo para locação de bens imóveis. Datas Não há nenhuma informação explicita sobre as datas de implementação desta nota técnica. Mas estimamos que ainda vai haver um tempo antes dessas alterações entrarem em vigor. Estamos buscando informações mais detalhadas sobre isso e editaremos este tópico assim que tivermos mais detalhes. E como fica o ACBr? Modificações serão necessárias para adequar as soluções ACBr. Criada a tarefa ACBR-9463 para atualizações no componente. Qualquer novidade será divulgada aqui neste tópico. Leia essa nota técnica na íntegra AQUI.

Existem municípios que ainda não aderiram ao padrão nacional da NFS-e ou ainda não encerraram o processo de parametrização junto ao mesmo. Essas cidades estão em descumprimento do art. 62 da Lei Complementar Nº214/2025. Ainda de acordo com essa legislação, essas cidades já estão sujeitas as penalidades observadas, incluindo o bloqueio de transferências voluntárias. Por causa disso, a Secretaria Executiva do Comitê Gestor da Nota Fiscal de Serviço Eletrônica (SE/CGNFS-e) orienta aos municípios que ainda possuem pendências para que realizem a regularização o mais breve possível. A lista de municípios que ainda não aderiram podem ser baixada AQUI. Esse tópico foi criado com base em notícia originalmente publicada AQUI.

Olá, comunidade ! A Secretaria Municipal da Fazenda de São Paulo anunciou alterações na sistemática de emissão da NFS-e relacionadas à tributação federal, especialmente sobre PIS e COFINS, com o objetivo de adequar o sistema à Nota Técnica SE/CGNFS-e nº 007/2026, publicada pela Secretaria Executiva do Comitê Gestor da NFS-e. As mudanças passaram a valer em 14 de maio de 2026 e impactam diretamente a emissão de NFS-e nos leiautes 1 e 2. O que muda na emissão da NFS-e? A partir da nova regra: Os campos PIS/PASEP e COFINS deverão informar os valores totais da operação, correspondentes aos débitos de apuração própria; Valores de retenção de PIS, COFINS e/ou CSLL deverão ser somados e informados: no campo “Contribuições Sociais – Retidas” na emissão on-line; no campo “ValorCSLL” na emissão via WebService; Também passa a ser obrigatória a correta identificação do tipo de retenção conforme os códigos definidos pela Prefeitura Novos códigos de retenção Os códigos aceitos para identificação das retenções passam a ser: 0 – PIS/COFINS/CSLL não retidos; 3 – PIS/COFINS/CSLL retidos; 4 – PIS/COFINS retidos e CSLL não retido; 5 – PIS retido e COFINS/CSLL não retidos; 6 – COFINS retido e PIS/CSLL não retidos; 7 – PIS não retido e COFINS/CSLL retidos; 8 – PIS/COFINS não retidos e CSLL retido; 9 – COFINS não retido e PIS/CSLL retidos. Alterações adicionais Outra mudança importante é que o campo “INSS” passou a ser apresentado como “Contribuição Previdenciária – Retida” na emissão on-line. Além disso, o espelho da NFS-e foi atualizado para exibir os novos campos: “Contribuições Sociais – Retidas”; “Descrição Contribuições Sociais – Retidas”. A Prefeitura também informou que o campo “Pagamento Parcelado Antecipado”, utilizado no leiaute 2, deixa de ser obrigatório. Essas alterações exigem atenção das empresas e desenvolvedores que utilizam integração via WebService, garantindo que os sistemas estejam atualizados para evitar rejeições ou inconsistências na emissão fiscal. E como fica o ACBr? O ACBr já contempla essas alterações no componente! Para informar o tipo de retenção de PIS e COFINS, deve ser alimentado o seguinte campo: No componente: NFSe.Servico.Valores.tribFed.rpRetPisCofins // Valores possíveis do enumerado: trpiscofinscsllNaoRetido, trpiscofinscsllRetido, trpiscofinsRetidocsllNaoRetido, trPisRetidoCofinsCsllNaoRetido, trCofinsRetidoPisCsllNaoRetido, trCofinsCsllRetidoPisNaoRetido, trCsllRetidoPisCofinsNaoRetido, trPisCsllRetidoCofinsNaoRetido No ACBrMonitor e ACBrLib, estará disponível na próxima versão. Abaixo, um exemplo de preenchimento: // Valores possíveis: 0, 3, 4, 5, 6, 7, 8 e 9 [tribFederal] tpRetPisCofins= Fonte oficial Prefeitura de São Paulo – Alteração na emissão de NFS-e

Olá, comunidade ! Foi publicado hoje, 13/05/26, um comunicado informando que a Secretaria Executiva do Comitê Gestor da Nota Fiscal de Serviço eletrônica (SE/CGNFS-e), em conjunto com o GT Atendimento, anunciou uma importante mudança no fluxo de atendimento aos contribuintes da NFS-e de Padrão Nacional. A partir de agora, o e-mail [email protected] deixa de ser utilizado como canal direto de suporte aos contribuintes. Com a nova diretriz, dúvidas, solicitações e demais demandas relacionadas à emissão da NFS-e deverão ser encaminhadas inicialmente aos canais oficiais de atendimento de cada Município aderente ao padrão nacional. A medida reforça o papel dos Municípios na administração tributária e no relacionamento com os contribuintes, fortalecendo a governança municipal da NFS-e em todo o país. Segundo a SE/CGNFS-e, o novo modelo de atendimento tem como objetivo tornar o suporte mais eficiente, organizado e alinhado à estrutura federativa da NFS-e Nacional. Além disso, a descentralização do atendimento deve proporcionar maior agilidade na resolução das demandas e melhorar a comunicação entre contribuintes e administrações municipais. Nos casos em que houver necessidade de suporte técnico ou institucional da Secretaria Executiva do CGNFS-e, o contato deverá ser realizado diretamente pelo próprio Município junto à gestão da NFS-e. Os canais atualizados de atendimento e demais orientações podem ser consultados no Portal Nacional da NFS-e. Fonte: Portal da NFS-e da Receita Federal

Olá comunidade ! No dia 28/04/2026, foi publicada no Diário Oficial da União a Resolução CGSN nº 189/2026. Esta resolução estabelece que os prestadores de serviços enquadrados como Microempresa (ME) ou Empresa de Pequeno Porte (EPP), optantes pelo Simples Nacional, deverão emitir a Nota Fiscal de Serviços Eletrônica (NFS-e) por meio do Emissor Nacional da NFS-e, a partir de 01/09/2026. A obrigatoriedade também se aplica aos casos em que a opção pelo Simples Nacional estiver pendente de análise ou sob efeitos de impedimento previsto na legislação. A partir dessa data, sistemas emissores próprios ou municipais poderão deixar de ser utilizados para essas situações, sendo necessário utilizar o Emissor Nacional da NFS-e conforme definido na resolução.

Olá comunidade ! Foi disponibilizado no dia 17/04/2026, no ambiente de produção restrita da NFS-e, o Módulo de Apuração Nacional (MAN) O MAN tem como objetivo: Possibilitar ao usuário do sistema nacional a seleção de múltiplas notas, registradas no modelo de NFS-e padrão nacional, que deverão ser pagas; Apurar o ISSQN devido das NFS-e selecionadas para pagamento em uma declaração de apuração padronizada nacionalmente; Emitir documento de arrecadação padronizado nacionalmente único para pagamento de todo o ISSQN apurado; Distribuir para cada município devido o valor do ISSQN apurado e pago no documento de arrecadação único, que for referente às NFS-e devidas ao município; e Possibilitar ao Município a vinculação de débitos e de créditos a contribuintes específicos. O guia de utilização do MAN pode ser encontrado AQUI.

Olá comunidade ! No dia 24/04/2026 houveram atualizações na API do Padrão Nacional modificando o código e a mensagem de algumas rejeições: Fonte: https://www.gov.br/nfse/pt-br/biblioteca/documentacao-tecnica/atualizacoes-e-implantacoes

Olá comunidade ! Por volta das 08h18 do dia 13/04/2026, começamos a receber diversos relatos em nossos canais de atendimento sobre falhas na emissão de NFS-e utilizando o provedor Giss. Todos os relatos apresentam a mesma mensagem de retorno: Codigo=E383 Correcao=Informe o codigo do pais. Descricao=Codigo do pais nao informado. Após contato com o suporte do provedor, um membro da comunidade compartilhou a informação de que a equipe do Giss confirmou que o problema está no lado do web service. Até o momento, não há previsão para a correção, mas o atendimento já foi priorizado pelo provedor.

Última atualização: 15/01/2026 Situação atual O provedor ISSNet implementou uma nova API para recepcionar os arquivos XML no leiaute do Padrão Nacional. Até o momento foi disponibilizado apenas a URL de homologação desta API. Essa URL é padrão para todos os municípios. As soluções ACBr conseguem se comunicar com essa API e o retorno recebido é: Erro(s): Código : E999 Mensagem: Operação GerarNfse está temporariamente indisponível. Serviço em construção. Correção: Considerando o retorno devolvido e a falta de uma URL de produção, podemos entender que a API ainda não está operacional. Por causa disso, se mantermos essa informação assim no arquivo ACBrNFSeXServicos.ini, os municípios atendidos por este provedor não conseguirão realizar a emissão de notas. Por causa disso todas as seções do ISSNet foram atualizadas para comunicar com os web services que já sabemos estarem operacionais. Como testar esse provedor com a Reforma Tributária? 1. Abra o arquivo ACBrNFSeXServicos.ini e localize a seção [ISSNet] no topo do arquivo. Ela vai estar comentada: ;[ISSNet] ;Params=APIPropria: ;Versao=1.01 ;HomRecepcionar=https://nfse.issnetonline.com.br/wsnfsenacional/homologacao/nfse.asmx Remove os ponto e vírgula do início de cada linha para retirar os comentários: [ISSNet] Params=APIPropria: Versao=1.01 HomRecepcionar=https://nfse.issnetonline.com.br/wsnfsenacional/homologacao/nfse.asmx 2. Localize o município que pretende utilizar em seus testes. Para este exemplo, vamos considerar a cidade de Oriximina/PA. [1505304] Nome=Oriximina UF=PA Provedor=ISSNet Versao=2.04 Params=NaoDividir100: ProRecepcionar=https://nfse.issnetonline.com.br/abrasf204/oriximina/nfse.asmx HomRecepcionar=https://www.issnetonline.com.br/homologaabrasf/webservicenfse204/nfse.asmx ; Excluir as 4 linhas acima, descomentar a linha abaixo e informar a URL de produção ; quando a API estiver funcionando ; ProRecepcionar= Comente as linhas que existem depois da chave Provedor: [1505304] Nome=Oriximina UF=PA Provedor=ISSNet ;Versao=2.04 ;Params=NaoDividir100: ;ProRecepcionar=https://nfse.issnetonline.com.br/abrasf204/oriximina/nfse.asmx ;HomRecepcionar=https://www.issnetonline.com.br/homologaabrasf/webservicenfse204/nfse.asmx ; Excluir as 4 linhas acima, descomentar a linha abaixo e informar a URL de produção ; quando a API estiver funcionando ProRecepcionar= 2.1 Caso tenha a informação da URL de produção e quiser testar também neste ambiente, pode atribuir a mesma na chave ProRecepcionar= que cujo comentário foi retirado. 3. Aponte o arquivo ACBrNFSeXServicos.ini modificado na propriedade ACBrNFSeX.Configuracoes.Arquivos.IniServicos := 'Caminho completo do Arquivo INI'; 3.1 Caso utilize o ACBrMonitorPLUS, utilize o comando NFSe.SetPathArquivoWebServices; 3.2 Caso utilize a ACBrLibNFSe, utilize em sequência os métodos NFSe_ConfigGravarValor e NFSe_ConfigGravar para apontar o arquivo ACBrNFSeXServicos.ini modificado na chave IniServicos da seção [NFSe] do arquivo ACBrLib.ini.

Preciso de uma ajuda para emissão de NFS-e. Estou com dificuldades para gerar a NFS-e de Mirassol/SP para o novo padrão. Alguém daqui do Fórum conseguiu gerar alguma NFS-e dessa cidade? Quando gero pelo layout Nacional, não comunica com a Prefeitura e dá o erro 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. Desde já, agradeço pela atenção.

Olá comunidade ! Foi adicionado no Portal da NFS-e Nacional uma nova área para centralizar as atualizações e implantações importantes que forem sendo feitas pela equipe responsável no ambiente nacional. Por enquanto existem informações apenas do dia 13/03/2026 com a menção do desligamento de algumas regras de validação e melhorias feitas no sistema. A nova área pode ser acessada AQUI.

Código: E160 Descrição: ERROR #5001: Tag principal do Lote nao encontrada no XML. Verifique a estrutura ou os Namespaces. - Arquivo enviado fora da estrutura do arquivo XML de entrada. Correção: Envie um arquivo dentro do schema do arquivo XML de entrada. Segue em anexo o arquivo xml dps do envio. Obs: Emitido com o demo em produção, creio que o demo deveria esta atualizado com as novas tags. NFS-e_Osacre.xml

Olá comunidade ! Com o advento da Reforma Tributária no inicio de 2026, os municípios do Brasil tiveram de fazer uma escolha: Aderir ao emissor nacional da NFS-e ou continuar utilizando o emissor próprio e compartilhando suas informações. Para atender a essa demanda de compartilhamento de informações, esses emissores próprias fizeram alterações em seus leiautes e alguns até mesmo chegaram ao ponto de criar um web service totalmente novo! Uma das cidades que optou por manter o emissor próprio criando um novo web service foi a cidade de São Paulo capital. Mas existe uma particularidade extra para esse município em especial. Até o momento, ele é o único município que está mantendo em produção dois web services ativos para regimes de tributação diferentes. Prestadores de serviço optantes pelo Simples Nacional deverão utilizar o web service: https://nfe.prefeitura.sp.gov.br/ws/lotenfe.asmx enquanto os demais serviços devem utilizar o web service: https://nfews.prefeitura.sp.gov.br/lotenfe.asmx Veja o tópico abaixo para entender como realizar essa configuração nas soluções ACBr:

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.

Ultima atualização: 18/03/2026 Situação Atual Os provedores Primax, Facundo, FGMaiss e Sam todos utilizam o mesmo leiaute do provedor WebFisco, portanto, as alterações são feitas no WebFisco e consequentemente refletidas nos demais. O provedor WebFisco atualizou seu leiaute a fim de atender a reforma tributária. O novo leiaute permite o envio de apenas um 1 item e remove algumas tags. Portanto, se o arquivo XML que estiver sendo gerado tiver tags como item2, f1n, f1d, f1v, val2 ou aliq2 ele está no leiaute antigo. Para atender a esse novo leiaute, as soluções ACBr criaram uma nova versão 1.01 do leiaute do WebFisco implementando essas modificações. O leiaute antigo na versão 1.00 ainda funciona, sendo recepcionado pelos web services, mas tivemos relatos de colegas da comunidade de que notas geradas nessa versão não foram sincronizadas posteriormente com o ambiente nacional. Como testar esse provedor com a Reforma Tributária? 1. Verifique se o município que pretende testar já está na versão 1.01, se estiver pode pular direto para a seção "Referência de Preenchimento". 2. Busque pela cidade que deseja testar e adicione as seguintes seções a ela conforme exemplos de acordo com o estado do município. (Aqui eu uso as URLs do Primax, mas para os demais provedores é a mesma lógica) Se for do estado de São Paulo: Versao=1.01 ProRecepcionar=* ProConsultarNFSeRps=https://www.primaxonline.com.br/issqn/wservice/wsnfeconsultaxmlpn.php ProConsultarNFSe=https://www.primaxonline.com.br/issqn/wservice/wsnfeconsultaxmlpn.php ProCancelarNFSe=https://www.primaxonline.com.br/issqn/wservice/wsnfecancelapn.php ProGerarNFSe=https://www.primaxonline.com.br/issqn/wservice/wsnfeenviapn.php HomRecepcionar=* HomGerarNFSe=https://www.primaxonline.com.br/issqn/wservice/wsnfe_teste_homologacaopn.php ProSoapAction=https://www.primaxonline.com.br/issqn/wservice/ HomSoapAction=https://www.primaxonline.com.br/issqn/wservice/ Se for do estado do Rio de Janeiro: Versao=1.01 ProRecepcionar=* ProConsultarNFSeRps=https://www1.primaxonline.com.br/issqn/wservice/wsnfeconsultaxmlpn.php ProConsultarNFSe=https://www1.primaxonline.com.br/issqn/wservice/wsnfeconsultaxmlpn.php ProCancelarNFSe=https://www1.primaxonline.com.br/issqn/wservice/wsnfecancelapn.php ProGerarNFSe=https://www1.primaxonline.com.br/issqn/wservice/wsnfeenviapn.php HomRecepcionar=* HomGerarNFSe=https://www.primaxonline.com.br/issqn/wservice/wsnfe_teste_homologacaopn.php ProSoapAction=https://www1.primaxonline.com.br/issqn/wservice/ HomSoapAction=https://www1.primaxonline.com.br/issqn/wservice/ 3. Aponte o arquivo ACBrNFSeXServicos.ini modificado na propriedade ACBrNFSeX.Configuracoes.Arquivos.IniServicos := 'Caminho completo do Arquivo INI'; 3.1 Caso utilize o ACBrMonitorPLUS, utilize o comando NFSe.SetPathArquivoWebServices; 3.2 Caso utilize a ACBrLibNFSe, utilize em sequência os métodos NFSe_ConfigGravarValor e NFSe_ConfigGravar para apontar o arquivo ACBrNFSeXServicos.ini modificado na chave IniServicos da seção [NFSe] do arquivo ACBrLib.ini. Referência de Preenchimento O novo leiaute remove alguns campos e adiciona outros novos, as referências abaixo mostram por tipo de solução qual é a propriedade ou informação do arquivo INI que gera a tag correspondente. Para quem utiliza componente nativo para Delphi/Lazarus, confira: ReferenciaArquivoXML.xml; Para quem utiliza ACBrMonitorPLUS ou ACBrLibNFSe, confira: ReferenciaArquivoINI.pdf (Em ReferenciaArquivoINI, os itens com -- são valores que não são definidos pelo arquivo INI usado para gerar a NFS-e)

Contextualizando Se você está tentando emitir uma nota fiscal de serviços eletrônica para o provedor Ginfes, um dos possíveis retornos que pode receber é: <Codigo>E160</Codigo> <Mensagem>Arquivo enviado fora da estrutura do arquivo XML de entrada.</Mensagem> <Correcao>Envie um arquivo dentro do schema do arquivo XML de entrada.</Correcao> A mensagem parece ser alto explicativa e indica que o arquivo que foi enviado está com erro na estrutura, certo? Infelizmente, não é tão simples assim. Os arquivos gerados pela solução ACBr estão de acordo com os schemas e o leiaute fornecido pelo provedor. Na verdade este erro parece ser devolvido pelo Ginfes não só para problemas de leiaute, mas também para "situações genéricas". Vejam alguns exemplos: Erro E160 - Arquivo enviado fora da estrutura do arquivo XML de entrada: Neste tópico um colega relata que resolveu o problema ao corrigir o número do lote que não estava alimentando no componente. Ginfes - Franca = Erro E160: Neste tópico um colega confirma que conseguiu resolver o problema ao corrigir os dados que preencheu no componente para geração da nota. Formatação do campo Aliquota da NFSe: Neste tópico o colega confirma que o CPF do tomador estava incorreto e após correção conseguiu emitir. Erro E160 - Arquivo enviado fora da estrutura do arquivo XML de entrada: Neste tópico um colega conseguiu superar este erro após corrigir um valor que estava indo negativo no XML. Erro ao emitir nota para Paulínia: Neste tópico um colega compartilha que conseguiu resolver o problema após corrigir o CNAE do cliente. Esse erro também pode ocorrer caso você não seja prestador da cidade que esteja fazendo testes, em vez do provedor retornar que o seu CNPJ não consta no cadastro deles, o retorno é esse erro E160 que acusa que o arquivo enviado esta fora da estrutura. Mas então o que eu posso fazer? Caso você tenha recebido este erro ao tentar emitir uma nota para uma cidade que é atendida pelo provedor Ginfes, revise todas as informações presentes no XML gerado. Se mesmo depois disso o problema persistir, entre em contato com o provedor e questione o por quê de estar recebendo esta rejeição. Ao fazer isso, o provedor pode apontar se alguma informação presente no XML está em desacordo com o cadastro da base de dados mantida pelo mesmo.

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.

Olá comunidade ! Foi publicada a Nota Técnica Nº 007 para NFS-e trazendo atualizações no leiaute do documento fiscal. Alterações Incluído o campo para receber o valor do "Indicador da operação de fornecimento favorecido com alíquota zero de CBS (conforme art. 451 e art. 466 da Lei Complementar nº 214/2025)" (tag indZFMALC no XML). Atualização do campo CST do grupo tribFed incluindo novos valores. Adição de novos valores para o campo tpRetPisCofins. Inclusão do campo "Valor Relativo às Retenções de Contribuições Sociais" (tag vRetCSLL no XML) Datas Temos relatos que levam a crer que os novos campos já foram implementados nos ambientes da API nacional. E como fica o ACBr? Os novos valores para tpRetPisCofins e o novo campo vRetCSLL já foram adicionados no leiaute. Assim que o campo indZFMALC estiver disponível notificaremos aqui neste tópico. Leia a Nota Técnica Nº 007 completa AQUI.

Ultima atualização: 04/05/2026 Situação atual O provedor Fiorilli disponibilizou uma nova API para recepcionar os arquivos XML usando o mesmo leiaute do Padrão Nacional. No geral, essa API pode ser dividida em duas versões que no componente ACBrNFSeX são identificadas por TACBrNFSeProviderFiorilliAPIPropria e TACBrNFSeProviderFiorilliAPIPropria101 . E no arquivo ACBrNFSeXServicos.ini são identificadas pelas chaves Versao com o valor 1.00 e 1.01. Isso acontece de acordo com a versão da API da Fiorilli. A relação de versões para poder preencher o arquivo ACBrNFSeXServicos.ini é a que segue: Versão no ACBrNFSeXServicos.ini Versão no Sistema da Prefeitura 1.00 Da versão 3.8.1 até a versão 3.8.9 Da versão 4.11.1 até a versão 4.11.9 1.01 Versão 3.9.0 e superiores Versão 4.12.0 e superiores Para saber qual é a versão que a prefeitura está utilizando, é necessário conferir qual é a versão no rodapé da página de emissão de notas fiscais. Por exemplo, no momento em que este tópico foi escrito, o rodapé na página da cidade de Assis/SP está assim: Diferenças técnicas entre as versões Versão 1.00 Não aceita os campos da reforma tributária. O algoritmo de canonicalização utilizado é o exclusivo ao invés do inclusivo. Implementa o envio do DPS unitário, envio de lote assíncrono, envio de lote síncrono e consulta de lote de DPS. Versão 1.01 Aceita os campos da reforma tributária. O algoritmo de canonicalização utilizado é o inclusivo. Implementa o envio do DPS unitário, envio de lote assíncrono, envio de lote síncrono, consulta de lote de DPS e a consulta de NFS-e por número e série da DPS, chave da DPS e chave da NFS-e. Como testar esse provedor com a Reforma Tributária? O próprio componente já abstrai todas essas diferenças, bastando apenas configurar a versão correta no arquivo ACBrNFSeXServicos.ini. 1. Abra o arquivo ACBrNFSeXServicos.ini e localize a seção [Fiorilli] no topo do arquivo. Ela vai estar comentada: [Fiorilli] ;Params=APIPropria:|ServicosPadraoNacional:ConsultarNFSeRps,ConsultarNFSePorChave,ConsultarEvento,ConsultarDFe,ConsultarParam,ObterDANFSE ;Versao=1.00 ;HomRecepcionar=http://fi1.fiorilli.com.br:5663/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType ; A URL abaixo é utilizada pelo WebService "antigo" que recepciona o XML segundo o layout da ABRASF. HomRecepcionar=http://fi1.fiorilli.com.br:5663/IssWeb-ejb/IssWebWS/IssWebWS HomLinkURL=http://fi1.fiorilli.com.br:5663/issweb/formGerarNF.jsf?nroNota=%NumeroNFSe%&codVerificacao=%CodVerif%&cnpj=%Cnpj%&hash=%ChaveAcesso% Remove os ponto e vírgula do início de cada linha para retirar os comentários: [Fiorilli] Params=APIPropria:|ServicosPadraoNacional:ConsultarNFSeRps,ConsultarNFSePorChave,ConsultarEvento,ConsultarDFe,ConsultarParam,ObterDANFSE Versao=1.00 HomRecepcionar=http://fi1.fiorilli.com.br:5663/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType ; A URL abaixo é utilizada pelo WebService "antigo" que recepciona o XML segundo o layout da ABRASF. ;HomRecepcionar=http://fi1.fiorilli.com.br:5663/IssWeb-ejb/IssWebWS/IssWebWS HomLinkURL=http://fi1.fiorilli.com.br:5663/issweb/formGerarNF.jsf?nroNota=%NumeroNFSe%&codVerificacao=%CodVerif%&cnpj=%Cnpj%&hash=%ChaveAcesso% 2. Localize o município que pretende utilizar em seus testes. [3551900] Nome=Severinia UF=SP Provedor=Fiorilli Versao=2.00 ProRecepcionar=http://170.246.217.252:8089/IssWeb-ejb/IssWebWS/IssWebWS ; A URL abaixo deve ser utilizada a partir de 01/02/2026 quando o WebSercice novo vai passar a ser utilizado. ;ProRecepcionar=http://170.246.217.252:8089/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType Se a cidade for atendida pela versão 1.00, a seção do município precisa ficar assim [3551900] Nome=Severinia UF=SP Provedor=Fiorilli ;Versao=2.00 ;ProRecepcionar=http://170.246.217.252:8089/IssWeb-ejb/IssWebWS/IssWebWS ; A URL abaixo deve ser utilizada a partir de 01/02/2026 quando o WebSercice novo vai passar a ser utilizado. ProRecepcionar=http://170.246.217.252:8089/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType Caso a cidade seja atendida pela versão 1.01, a seção da cidade precisa ficar assim: [3551900] Nome=Severinia UF=SP Provedor=Fiorilli Versao=1.01 Params=ServicosAPIPropria:ConsultarNFSeRps,ConsultarNFSePorChave| ;Versao=2.00 ;ProRecepcionar=http://170.246.217.252:8089/IssWeb-ejb/IssWebWS/IssWebWS ; A URL abaixo deve ser utilizada a partir de 01/02/2026 quando o WebSercice novo vai passar a ser utilizado. ProRecepcionar=http://170.246.217.252:8089/IssWeb-ejb/IssWebWSNacional/IssWebWSNacionalPortType As linhas Versao=1.01 e Params=ServicosAPIPropria:ConsultarNFSeRps,ConsultarNFSePorChave| são necessárias apenas para esta versão. 3. Aponte o arquivo ACBrNFSeXServicos.ini modificado na propriedade ACBrNFSeX.Configuracoes.Arquivos.IniServicos := 'Caminho completo do Arquivo INI'; 3.1 Caso utilize o ACBrMonitorPLUS, utilize o comando NFSe.SetPathArquivoWebServices; 3.2 Caso utilize a ACBrLibNFSe, utilize em sequência os métodos NFSe_ConfigGravarValor e NFSe_ConfigGravar para apontar o arquivo ACBrNFSeXServicos.ini modificado na chave IniServicos da seção [NFSe] do arquivo ACBrLib.ini.

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 IM Se o emitente for o prestador de serviço (tpEmit = 1) e, se houver registro complementar do contribuinte no CNC do município correspondente ao município emissor da DPS, então a IM deve ser informada na DPS. Utilizar o identificador federal (CNPJ ou CPF) do prestador de serviço e o codigo do município emissor (cLocEmi), ambos informados na DPS, para identificar as ocorrências no CNC NFS-e. Se houver pelo menos uma ocorrência, então o emitente da DPS deve informar o IM correspondente registrado no CNC NFS-e, que identifique unicamente o registro complementar. Exceto quando o emitente da DPS for MEI na data de competência da emissão da NFS-e. 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. A rejeição parece ser alto explicativa, se você recebeu a mesma, então a API do Padrão Nacional não está encontrando a IM no grupo <prest> do seu arquivo XML. Mas existe uma "pegadinha", não foram poucos os que relataram estar recebendo esta rejeição, mesmo enviando a informação no arquivo XML corretamente. Como resolver? Se você está recebendo esta rejeição, a primeira coisa a verificar é se no XML do DPS que está sendo gerado e enviado, a informação da IM está sendo adicionada no grupo <prest> <prest> <CNPJ>XXXXXXXXXXXXXX</CNPJ> <IM>YYYYYYYYYYYYYYY</IM> </prest> Se a informação está presente no XML, então entramos na "pegadinha". Muitas IMs são valores numéricos variando de 6, 9 ou até 11 caracteres. Mas o tamanho do campo no XML do padrão nacional é 15! Vamos considerar como exemplo o valor 12345678 como exemplo. Se você está informando este valor e está recebendo a rejeição, faça um teste informando os zeros não significativos na esquerda até completar 15 caracteres enviando 000000012345678. Caso utilize ACBrNFSeX para Delphi e Lazarus: Alimente a IM na propriedade: NFSe.Prestador.IdentificacaoPrestador.InscricaoMunicipal := '000000012345678'; Caso utilize ACBrMonitorPLUS ou ACBrLibNFSe: Alimente a informação no arquivo INI preenchendo a seguinte propriedade: [Prestador] IM=000000012345678

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 cLocEmi 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. Exceto quando o emitente da DPS for MEI na data de competência da emissão da NFS-e. 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. Aqui precisamos dar alguns passos para trás e entender como um município pode aderir ao padrão nacional. Essa adesão pode ser feita de duas formas diferentes. Aderir ao Padrão Nacional e ao Emissor Nacional: Nessa modalidade, o município utilizará integralmente a estrutura federal, sendo a emissão das notas feita diretamente pela API oficial. Aderir ao Padrão sem o Emissor Nacional: O município mantém sua estrutura de emissão atual, mas deverá adaptá-la para comportar novos campos. Isso é necessário para que, após processar o RPS/DPS, o sistema local transmita as informações à API oficial. Portanto, se você está recebendo esta rejeição, significa que você está tentando comunicar diretamente com a API do emissor nacional enviando um cTribNac que na verdade deveria se comunicar com a API do município. Como resolver? Certifique-se de que você está se comunicando com a API correta. O arquivo ACBrNFSeXServicos.ini já foi atualizado para definir padrão nacional, portanto, exceto nos casos em que o prestador de serviços seja MEI, você não deve definir um valor diferente de lnfsProvedor para a configuração do LayoutNFSe. Caso utilize ACBrNFSeX para Delphi e Lazarus: Defina a seguinte configuração: ACBrNFSeX.Configuracoes.Geral.LayoutNFSe := lnfsProvedor; Caso utilize ACBrMonitorPLUS: Utilize o comando NFSe.SeLayoutNFSe definindo o valor 2: NFSe.SetLayoutNFSe(2) Caso utilize ACBrLibNFSe: Utilize os métodos NFSE_ConfigGravarValor seguido de NFSE_ConfigGravar para definir o valor 2 para a chave LayoutNFSe em seu arquivo ACBrLib.ini: NFSE_ConfigGravarValor("NFSe", "LayoutNFSe", "2"); NFSE_ConfigGravar(); É importante que independente da solução que estiver utilizando, garanta que tanto ela quanto o arquivo ACBrNFSeXServicos.ini respectivo estejam atualizados.

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

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