Diego Foliene

Boa tarde! Por favor, como deu certo com a mesma URL, pode realizar um teste enviando para a versão 2.00 com o simples para ver se rejeição que obrigada os prestadores do regime do Simples Nacional a usar a versão 2.00 ainda persiste? Pode ser que eles tenham alterado lá e essa alteração da versão não seja mais necessária na verdade.

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.

Bom dia @Daniel Simoes. Por mais estranho que possa parecer, para o município de SP, infelizmente esse é o caso. Prestadores de serviço que se enquadram no Simples Nacional deve usar a versão 1.00 do web service do município para emissão de notas até o final de 2028, versão essa que não aceita os campos da reforma tributária e tem URL própria. Já os demais prestadores vão usar a versão 2.00 da API que aceita os campos da reforma e tem URL distintas. O @Juliomar Marchetti e o @Italo Giurizzato Junior fizeram uma alteração no componente para que isso possa ser feito sem precisar alterar o ACBrNFSeXServicos.ini. Ao alterar a configuração ACBrNFSeX.Configuracoes.Geral.Versao entre os valores ve100 e ve200 o componente automaticamente escolhe qual versão da API usar para a cidade. No entanto, transcrever esse comportamento para a Lib apresentou um problema ao qual estamos tentando resolver.

Olá comunidade ! No dia 04/02/2026 foi publicada a nota técnica 2026/001 para a NF3e trazendo informações sobre a vinculação de pagamentos ao DFe. Essa vinculação se faz necessária para que o processo de Split Payment Inteligente seja executado. É importante ressaltar que o vínculo indicado pelo contribuinte não necessariamente representa um pagamento efetuado e liquidado. Indica uma expectativa de pagamento que pode ou não se concretizar. Por exemplo: um boleto pode ser emitido e não pago. Alterações Adiciona na NF3e um "Grupo de informações da vinculação com a transação de pagamento" com a seguinte estrutura: <pgtoVinc> <pgto> <nPag></nPag> <idTransacao></idTransacao> <tpMeioPgto></tpMeioPgto> <CNPJReceb></CNPJReceb> <CNPJBasePSP></CNPJBasePSP> </pgto> </pgtoVinc> Cria o "evento de vinculação da transação de pagamento com o DFe - 110300" com estrutura semelhante ao grupo da vinculação e seu respectivo evento de cancelamento. Adiciona regras de validações para os novos campos e para o evento. Datas Implantação Homologação: 06/04/2026 Implantação Produção: 04/05/2026 E como fica o ACBr? Modificações no ACBr serão necessárias para atender a esta nota técnica. Foi criada a tarefa ACBR-8940 para a adequação das soluções ACBr. Leia a nota técnica na íntegra AQUI.

Olá comunidade ! No dia 04/02/2026 foi publicada a nota técnica 2026/001 para a NFCom trazendo informações sobre a vinculação de pagamentos ao DFe. Essa vinculação se faz necessária para que o processo de Split Payment Inteligente seja executado. É importante ressaltar que o vínculo indicado pelo contribuinte não necessariamente representa um pagamento efetuado e liquidado. Indica uma expectativa de pagamento que pode ou não se concretizar. Por exemplo: um boleto pode ser emitido e não pago. Alterações Adiciona na NFCom um "Grupo de informações da vinculação com a transação de pagamento" com a seguinte estrutura: <pgtoVinc> <pgto> <nPag></nPag> <idTransacao></idTransacao> <tpMeioPgto></tpMeioPgto> <CNPJReceb></CNPJReceb> <CNPJBasePSP></CNPJBasePSP> </pgto> </pgtoVinc> Cria o "evento de vinculação da transação de pagamento com o DFe - 110300" com estrutura semelhante ao grupo da vinculação e seu respectivo evento de cancelamento. Adiciona regras de validações para os novos campos e para o evento. Datas Implantação Homologação: 06/04/2026 Implantação Produção: 04/05/2026 E como fica o ACBr? Modificações no ACBr serão necessárias para atender a esta nota técnica. Foi criada a tarefa ACBR-8939 para a adequação das soluções ACBr. Leia a nota técnica na íntegra AQUI.

Olá comunidade ! No dia 04/02/2026 foi publicada a nota técnica 2026/001 para o CT-e trazendo informações sobre a vinculação de pagamentos ao DFe. Essa vinculação se faz necessária para que o processo de Split Payment Inteligente seja executado. É importante ressaltar que o vínculo indicado pelo contribuinte não necessariamente representa um pagamento efetuado e liquidado. Indica uma expectativa de pagamento que pode ou não se concretizar. Por exemplo: um boleto pode ser emitido e não pago. Alterações Adiciona no CT-e, CT-e OS e CT-e Simp um "Grupo de informações da vinculação com a transação de pagamento" com a seguinte estrutura: <pgtoVinc> <pgto> <nPag></nPag> <idTransacao></idTransacao> <tpMeioPgto></tpMeioPgto> <CNPJReceb></CNPJReceb> <CNPJBasePSP></CNPJBasePSP> </pgto> </pgtoVinc> Cria o "evento de vinculação da transação de pagamento com o DFe - 110300" com estrutura semelhante ao grupo da vinculação e seu respectivo evento de cancelamento. Adiciona regras de validações para os novos campos e para o evento. Datas Implantação Homologação: 06/04/2026 Implantação Produção: 04/05/2026 E como fica o ACBr? Modificações no ACBr serão necessárias para atender a esta nota técnica. Foi criada a tarefa ACBR-8938 para a adequação das soluções ACBr. Leia a nota técnica na íntegra AQUI.

@renemelo Fiz um teste de leitura forçando no retorno o conteúdo da resposta que você recebeu. Não tive problemas, a leitura foi feita normalmente com os fontes conforme o SVN. Veja os prints.

@renemelo, por favor, pode disponibilizar um arquivo XML que exemplifique essa situação? Se não quiser mandar por aqui, use o tópico que você tem na área privada do fórum:

Bom dia! Conferindo nos fontes a adição do novo valor foi enviada na Rev-44662. No Discord, também foi reportado que você conseguiu gerar a nota com sucesso em produção: https://discord.com/channels/798697718800318484/800042186783588364/1467949862975963136

Olá comunidade ! Foi publicado no dia 03/02/2026 a Nota Técnica Nº 011 2026 Orientativa para os contribuintes de PIS/COFINS. Essa nota técnica estabelece as orientações aos contribuintes em relação a EFD Contribuições no que diz respeito a Reforma Tributária. Conforme estabelecido pelo cronograma da Reforma, a partir de 2027, o PIS e o COFINS serão extintos, sendo substituídos em sua integralidade pela CBS. Devido a isso a NT estabelece que a EFD-Contribuições deixará de ser utilizada para apuração de novos fatos geradores de PIS e COFINS quando CBS passar a ser cobrada em sua alíquota plena. Vejam que "novos fatos" está destacado, pois é importante ressaltar que a EFD-Contribuições não será imediatamente descontinuada devido a necessidade de gerar saldos credores remanescentes e atender os prazos legais de fiscalização e retificação de informações. Manutenção da Escrituração para Fins de Controle A obrigação de manter, o direito de consultar e retificar a EFD-Contribuições persistirá pelo prazo mínimo de 5 (cinco) anos. Essa manutenção é crucial para a gestão dos saldos credores acumulados de PIS e COFINS gerados até 31 de dezembro de 2026. Tais créditos remanescentes devem ser devidamente escriturados para que possam ser utilizados em compensação com a CBS ou outros tributos federais. Ausência de Alteração de Leiaute para CBS Não haverá alterações no leiaute da EFD-Contribuições para escrituração dos valores da CBS, IBS e IS (Imposto Seletivo) nos documentos fiscais, relativo aos fatos geradores ocorridos em 2026. Ou seja, estes valores não devem ser somados aos valores dos itens ou dos documentos fiscais no ano de 2026. Novos documentos fiscais eletrônicos Enquanto a EFD não for atualizada para receber as informações dos novos documentos BPeTA, NFAg, NFGas, NFeABI, NFS-e Via e DeRe, como regra geral, as operações registradas nos novos documentos eletrônicos serão escrituradas nos mesmos registros que atualmente recepcionam estas operações. Quando o registro da EFD-Contribuições contiver o campo COD_MOD - Código do modelo do documento fiscal, o contribuinte deverá informar o código 55 – Nota Fiscal conforme tabela: Código Descrição Modelo Registro COD_MOD a ser utilizado 63 Bilhete de Passagem Eletrônico (BPeTA) – Modal Aéreo 63 Aquisição: D100 Fornecimento: D200 55 75 Nota Fiscal de Água e Serviços de Saneamento Eletrônica – NFAg 75 Aquisição: C500 Fornecimento: C600 55 76 Nota Fiscal Eletrônica do Gás - NFGas 76 Aquisição: C500 Fornecimento: C600 55 77 Nota Fiscal de Alienação de Bens Imóveis - NF-e ABI 77 F200* Não se aplica - Nota Fiscal de Serviço Eletrônica de Exploração de Vias - NFS-e Via - A100 ou F100** Não se aplica - Declaração dos Regimes Específicos – DeRE - Bloco I*** Não se aplica * A chave do documento fiscal deverá ser informada no campo 06 – NUM_CONT. ** A escrituração pode ser consolidada em F100, agregando o valor total diário das NFS-e, segregado por CST, alíquota e natureza da receita. A faixa de numeração dos documentos será escriturada no campo 19-DESC_DOC_OPER. *** Para os contribuintes sujeitos ao bloco I (Pessoas jurídicas referidas nos §§ 6º, 8º e 9º do art. 3º da Lei nº 9.718, de 1998). Para os demais contribuintes, de acordo com o tipo/modelo de documento fiscal emitido. Leia a nota técnica completa AQUI. Veja a notícia original AQUI.

Bom dia! @Nilson Sérgio enviei ajuste ao SVN para que IdentificacaoRps.Numero, IdentificacaoRps.Serie e Competencia só sejam sobrescritas com as informações lidas dos grupos DPS se o leitor encontrar alguma coisa. Se não achar nada, mantém o que lido do grupo RPS. Também alterei a leitura de cTribNac que antes sobrescrevia ItemListaServico e agora preenche CodigoServicoNacional conforme a rotina de geração do XML. @renemelo, enviado ao SVN correção da leitura da data. Sobre a questão do tcCompNFSe e CompNFSe, não tive problemas em meus testes usando o XML que foi fornecido pelo colega. A rotina da classe mãe busca tcCompNFSe, e se não encontrar, busca por NFSe direto, no teste que fiz, ele encontra o NFSe e lê as informações.

Apenas para informar, adicionamos a tarefa em nosso ciclo atual de desenvolvimento que se encerra no dia 06/02/2026. Assim que for disponibilizado no SVN avisaremos aqui neste tópico.

Olá pessoal! O membro de nossa comunidade @Felipe Mariano compartilhou conosco no canal #sefaz em nosso servidor do Discord essa resposta que recebeu do Fale Conosco confirmando que o problema está de fato no lado da Sefaz e está sendo averiguado.

Bom dia! Muito obrigado pelas informações e pela contribuição! Foi criada a tarefa ACBR-8908 para análise da contribuição e disponibilização da mesma no SVN. Assim que for disponibilizado avisamos aqui no tópico.

Olá comunidade ! No dia 02/02/2026, por volta das 08h36, começamos a receber múltiplos relatos de membros da nossa comunidade com problemas para autorizar determinadas notas fiscais junto a Sefaz Paraná. Todos os relatos tem em comum o mesmo retorno com a seguinte rejeição: Como é possível observar, esta rejeição costuma ocorrer quando é utilizado um CST e um cClassTrib que tem redução de alíquota, mas o percentual utilizado é inválido. No entanto, tudo indica ser um problema de rejeição sendo devolvida indevidamente, pois temos relatos de notas como esta do exemplo abaixo sendo rejeitadas: <IBSCBS> <CST>200</CST> <cClassTrib>200003</cClassTrib> <gIBSCBS> <vBC>100.00</vBC> <gIBSUF> <pIBSUF>0.1000</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.9000</pCBS> <gRed> <pRedAliq>100.0000</pRedAliq> <pAliqEfet>0.0000</pAliqEfet> </gRed> <vCBS>0.00</vCBS> </gCBS> </gIBSCBS> </IBSCBS> Essa estrutura está correta de acordo com o Validador da Conformidade Fácil e o valor utilizado nos percentuais de redução também estão corretos de acordo com o CST x cClassTrib, conforme a Tabela de Classificação Tributária. Caso esteja enfrentando esta rejeição, o recomendado é que abra um Fale Conosco junto a Sefaz do Paraná.

Olá comunidade ! Foi publicada a nota técnica Nº 006 estabelecendo a Nota Fiscal de Serviço eletrônica de Exploração de Via de padrão nacional (NFS-e Via). Esta publicação atende a Resolução CGNFSE Nº 9 que estabelece o novo modelo que faz parte da NFS-e no padrão nacional. Contando com leiaute próprio este as informações parametrizáveis serão disponibilizadas por concessionárias de exploração de vias ao invés das prefeituras. A nota técnica pode ser lida na íntegra AQUI. Foi criada a tarefa ACBR-8906 para análise do leiaute e implementação no ACBr.

Olá comunidade ! Foi publicada a versão 12 do leiaute da ECF vigente para o ano calendário de 2025 e situações especiais de 2026. A nova versão traz as seguintes atualizações: Registro Y730: Identificação de donatários/destinatários de deduções do IRPJ/CSLL - Entidades isentas e imunes, que forem do tipo Educação, Saúde ou Assistência social, e que tiverem CEBAS, deverão informar o número. Possibilidade de transmissão com CNPJ alfanumérico Novas regras Validação envolvendo P300 e Y570, similar ao lucro real. Alguns campos foram alterados de "Cálculo Alterável" para "Cálculo Não Alterável". O manual pode ser encontrado AQUI. Vale reforçar que uma nova atualização do manual para atender a Lei Complementar que estabelece a Reforma Tributária nas situações especiais de 2026 é esperada até 01/04/2026. Foi criada a tarefa ACBr-8905 para adequação do componente ACBrSPEDECF.

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

@Nilson Sérgio, por favor, você tem um XML que exemplifique esta situaçã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 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.