VEXCOM Sistemas - Valtair

Boa tarde. Ao emitir uma NFS-e via POST /nfse/dps para um município atendido pelo provedor IPM (Pinhalzinho/SC), o campo infDPS.serv.cServ.cNBS é informado corretamente no JSON da DPS, porém não aparece no XML de envio que a própria API gera para o provedor IPM. Consequentemente a prefeitura rejeita a nota com: 00366 - A Nomenclatura Brasileira de Serviço (NBS) é obrigatória e não foi informada Como a NBS é enviada no campo canônico previsto pela API (cServ.cNBS) e não há outro campo de entrada para a NBS, entendemos que a omissão ocorre na geração do XML de envio do padrão IPM (leiaute com Reforma Tributária / grupo IBSCBS). Corpo enviado em POST https://prod.acbr.api.br/nfse/dps (note o campo infDPS.serv.cServ.cNBS preenchido): Obs.: Dados sensíveis omitidos. { "provedor": "padrao", "ambiente": "producao", "referencia": "30584655000387_73230_15:09:28", "infDPS": { "dhEmi": "2026-05-20T14:50:53.109Z", "dCompet": "2026-05-20T00:00:00.000Z", "prest": { "CNPJ": "XXXXX", "regTrib": { "regEspTrib": 2 } }, "toma": { "xNome": "SILVEIRA XXXX", "end": { "endNac": { "cMun": "4211454", "CEP": "XXXX" }, "xLgr": "XXX", "nro": "XXX", "xBairro": "CENTRO" }, "fone": "4933270091", "CNPJ": "20375295000198" }, "serv": { "cServ": { "cTribNac": "140101", "xDescServ": "SERVICO DE MONTAGEM / BALANCEAMENTO - R$ 80,00", "cTribMun": "8253", "cNBS": "120013100" }, "infoCompl": { "xInfComp": "OS nº 13561 Modelo: DUCATO MINIBUS, Placa: XXXX KM: Ano/Modelo: 2012/2013Chassi:XXXXX" } }, "valores": { "vServPrest": { "vServ": 80 }, "trib": { "tribMun": { "tribISSQN": 1, "tpRetISSQN": 1, "cLocIncid": "4212908", "pAliq": 4 }, "totTrib": { "vTotTrib": { "vTotTribFed": 0, "vTotTribEst": 0, "vTotTribMun": 3.2 } } } }, "IBSCBS": { "finNFSe": 0, "indFinal": 0, "cIndOp": "050101", "indDest": 0, "valores": { "trib": { "gIBSCBS": { "CST": "000", "cClassTrib": "000001" } } } } } } Resposta imediata (200): { "id": "nfs_3a215d470c924a6aadad4ebaba06a65b", "created_at": "2026-05-20T18:14:29.107Z", "status": "processando", "ambiente": "producao", "referencia": "30584655000387_73230_15:09:28", "DPS": {}, "mensagens": [] } Ao consultar o resultado via GET https://prod.acbr.api.br/nfse/{id} retorna o erro: { "id": "nfs_3a215d470c924a6aadad4ebaba06a65b", "created_at": "2026-05-20T18:14:29.107Z", "status": "erro", "ambiente": "producao", "referencia": "30584655000387_73230_15:09:28", "DPS": { "serie": "1", "nDPS": "3971" }, "mensagens": [ { "codigo": "00366", "descricao": "A Nomenclatura Brasileira de Serviço (NBS) é obrigatória e não foi informada" } ] } (XML de envio gerado pela API (evidência) GET https://prod.acbr.api.br/nfse/{id}/xml/dps) XML retornado (padrão IPM). Observe o bloco <itens><lista>: não há nenhuma tag de NBS, embora o cNBS tenha sido enviado: <?xml version="1.0" encoding="UTF-8"?> <nfse Id="3971"> <identificador>nfse_3971.1</identificador> <rps> <nro_recibo_provisorio>3971</nro_recibo_provisorio> <serie_recibo_provisorio>1</serie_recibo_provisorio> <data_emissao_recibo_provisorio>20/05/2026</data_emissao_recibo_provisorio> <hora_emissao_recibo_provisorio>11:50:53</hora_emissao_recibo_provisorio> </rps> <nf> <data_fato_gerador>20/05/2026</data_fato_gerador> <valor_total>80,00</valor_total> <valor_ir>0,00</valor_ir> <observacao>OS n 13561 Modelo: DUCATO MINIBUS, Placa: ***** KM: Ano/Modelo: 2012/2013Chassi:*****</observacao> <IBSCBS> <pRedutor>0,00</pRedutor> <valores> <vBC>0,00</vBC> <uf><pIBSUF>0,00</pIBSUF><pRedAliqUF>0,00</pRedAliqUF><pAliqEfetUF>0,00</pAliqEfetUF></uf> <mun><pIBSMun>0,00</pIBSMun><pRedAliqMun>0,00</pRedAliqMun><pAliqEfetMun>0,00</pAliqEfetMun></mun> <fed><pCBS>0,00</pCBS><pRedAliqCBS>0,00</pRedAliqCBS><pAliqEfetCBS>0,00</pAliqEfetCBS></fed> </valores> <totCIBS> <vTotNF>0,00</vTotNF> <gIBS> <vIBSTot>0,00</vIBSTot> <gIBSCredPres><pCredPresIBS>0,00</pCredPresIBS><vCredPresIBS>0,00</vCredPresIBS></gIBSCredPres> <gIBSUFTot><vDifUF>0,00</vDifUF><vIBSUF>0,00</vIBSUF></gIBSUFTot> <gIBSMunTot><vDifMun>0,00</vDifMun><vIBSMun>0,00</vIBSMun></gIBSMunTot> </gIBS> <gCBS> <gCBSCredPres><pCredPresCBS>0,00</pCredPresCBS><vCredPresCBS>0,00</vCredPresCBS></gCBSCredPres> <vDifCBS>0,00</vDifCBS><vCBS>0,00</vCBS> </gCBS> </totCIBS> </IBSCBS> </nf> <prestador> <cpfcnpj>30584655000387</cpfcnpj> <cidade>8253</cidade> </prestador> <!-- Dados do tomador mascarados (não relevantes para a análise da NBS) --> <tomador> <endereco_informado>1</endereco_informado> <tipo>J</tipo> <cpfcnpj>**************</cpfcnpj> <ie></ie> <nome_razao_social>*** TOMADOR ***</nome_razao_social> <sobrenome_nome_fantasia></sobrenome_nome_fantasia> <logradouro>***</logradouro> <email></email> <numero_residencia>***</numero_residencia> <complemento></complemento> <ponto_referencia></ponto_referencia> <bairro>***</bairro> <cidade>5589</cidade> <cep>********</cep> <ddd_fone_comercial></ddd_fone_comercial> <fone_comercial>**********</fone_comercial> <ddd_fone_residencial></ddd_fone_residencial> <fone_residencial></fone_residencial> <ddd_fax></ddd_fax> <fone_fax></fone_fax> </tomador> <itens> <lista> <tributa_municipio_prestador>1</tributa_municipio_prestador> <codigo_local_prestacao_servico>8253</codigo_local_prestacao_servico> <unidade_codigo>1</unidade_codigo> <unidade_quantidade>1,0000000000</unidade_quantidade> <unidade_valor_unitario>80,0000000000</unidade_valor_unitario> <codigo_item_lista_servico>140101</codigo_item_lista_servico> <descritivo>SERVICO DE MONTAGEM / BALANCEAMENTO - R$ 80,00</descritivo> <aliquota_item_lista_servico>4,0000</aliquota_item_lista_servico> <situacao_tributaria>0</situacao_tributaria> <valor_tributavel>80,00</valor_tributavel> <!-- NÃO há tag de NBS aqui, apesar de cServ.cNBS ter sido enviado --> </lista> </itens> <IBSCBS> <finNFSe>0</finNFSe> <indFinal>0</indFinal> <cIndOp>050101</cIndOp> <valores> <trib><gIBSCBS><CST>000</CST><cClassTrib>000001</cClassTrib></gIBSCBS></trib> </valores> </IBSCBS> <forma_pagamento> <tipo_pagamento>1</tipo_pagamento> </forma_pagamento> </nfse> • No JSON enviado, a NBS está no campo previsto pela API: infDPS.serv.cServ.cNBS = "120013100". • No XML de envio gerado pela própria API para o padrão IPM, o item (<itens><lista>) não contém nenhuma tag de NBS (ex.: codigo_nbs). • A prefeitura (IPM) rejeita com 00366 — NBS obrigatória e não foi informada. • Demais campos derivados estão presentes corretamente no XML (ex.: <situacao_tributaria>, <codigo_item_lista_servico>, <aliquota_item_lista_servico>, grupos IBSCBS), o que indica que a conversão ocorre, apenas a NBS não é mapeada para o leiaute IPM. Perguntas: • No padrão IPM com leiaute de Reforma Tributária (grupo IBSCBS), o campo infDPS.serv.cServ.cNBS deveria ser transportado para a tag de NBS do XML de envio? Se sim, a omissão observada é um defeito na geração do XML? • Existe algum outro campo no corpo da DPS (NfseDpsPedidoEmissao) que precise ser preenchido para que a NBS chegue ao XML do provedor IPM? Em caso afirmativo, qual o caminho/nome do campo? • Há previsão/correção para que a rejeição 00366 deixe de ocorrer quando a NBS já é enviada via cServ.cNBS?

Bom dia! Alguma atualização a respeito?

Bom dia! Alguma atualização a respeito?

Boa tarde, Estou utilizando a ACBr API para emitir NFSe de um cliente em Pato Branco/PR, cujo provedor é o Pronim. A emissão funciona normalmente, mas ao tentar cancelar uma nota recebo o seguinte erro: "EACBrDFeException - Serviço Preparar Cancela NFSe não implementado para este provedor." Pelo visto o cancelamento ainda não foi implementado para o Pronim de Pato Branco. Gostaria de solicitar a implementação desse serviço, já que sem ele os clientes ficam obrigados a cancelar a nota direto no portal da prefeitura. Segue o payload que estou enviando para o cancelamento utilizando o método POST https://prod.acbr.api.br/nfse/{id}/cancelamento: { "codigo": "1", "motivo": "EMITIDO INCORRETAMENTE" } E o retorno da ACBr API: { "id": "nfs_3a2139dd77f646e89bb26643084845a9", "status": "erro", "mensagens": "EACBrDFeException - Serviço Preparar Cancela NFSe não implementado para este provedor.", "ambiente": "producao", ... } Ambiente: Produção Provedor: Pronim Município: Pato Branco/PR Se puderem validar e realizar a implantação do cancelamento na API, ficaria grato!

Boa tarde, Estamos utilizando a ACBr API para emissão de NFS-e através do provedor "GissOnline" (município de Maceió/AL - código IBGE 2704302). Até então as emissões estavam ocorrendo normalmente, porém, do nada, todas as DPS enviadas passaram a retornar o mesmo erro: Código: E160 Descrição: Arquivo em desacordo com o XML Schema. Correção: Consulte o Manual da NFS-e para saber quais são as versões de XML Schema suportadas pelo sistema. Pontos relevantes: 1. Não houve nenhuma alteração no payload enviado para a API. 2. O JSON enviado segue o mesmo formato que vinha funcionando. 3. O XML gerado pela própria API (DPS assinada) está usando o namespace http://www.giss.com.br/tipos-v2_04.xsd 4. O retorno é sempre o mesmo E160, independente do tomador, valor ou tipo de serviço. 5. Estamos em ambiente de PRODUÇÃO. Segue abaixo o JSON enviado, a resposta da API e o XML DPS gerado para análise (com dados sensíveis omitidos). REQUISIÇÃO (POST /nfse/dps) { "provedor": "padrao", "ambiente": "producao", "referencia": "XXXXXXXXXXXXXX_XXXXX_XX:XX:XX", "infDPS": { "dhEmi": "2026-05-06T17:45:43.341Z", "dCompet": "2026-05-06", "prest": { "CNPJ": "XXXXXXXXXXXXXX", "regTrib": { "regEspTrib": 2 } }, "toma": { "xNome": "TOMADOR TESTE LTDA", "end": { "endNac": { "cMun": "2704302", "CEP": "XXXXXXXX" }, "xLgr": "RUA EXEMPLO", "nro": "000", "xBairro": "BAIRRO EXEMPLO" }, "fone": "XXXXXXXXXX", "email": "[email protected]", "IE": "XXXXXXXXX", "CNPJ": "XXXXXXXXXXXXXX" }, "serv": { "cServ": { "cTribNac": "1401", "xDescServ": "CARGA BATERIA - R$ 10,00", "cTribMun": "4543900", "CNAE": "4520001" }, "infoCompl": { "xInfComp": "DAV-OS: 0000000000" } }, "valores": { "vServPrest": { "vServ": 10 }, "trib": { "tribMun": { "tribISSQN": 1, "tpRetISSQN": 1, "cLocIncid": "2704302", "pAliq": 5 }, "totTrib": { "vTotTrib": { "vTotTribFed": 0, "vTotTribEst": 0, "vTotTribMun": 0 } } } } } } RESPOSTA INICIAL (POST /nfse/dps) { "id": "nfs_3a21197af52047fa952d33ac6515e333", "created_at": "2026-05-07T14:17:00.273Z", "status": "processando", "ambiente": "producao", "referencia": "23644363000165_31732_09:52:42", "DPS": {}, "mensagens": [] } RESPOSTA FINAL (GET /nfse/{id}) — ERRO { "id": "nfs_3a21197af52047fa952d33ac6515e333", "created_at": "2026-05-07T14:17:00.273Z", "status": "erro", "ambiente": "producao", "referencia": "23644363000165_31732_09:52:42", "DPS": { "serie": "1", "nDPS": "924" }, "mensagens": [ { "codigo": "E160", "descricao": "Arquivo em desacordo com o XML Schema.", "correcao": "Consulte o Manual da NFS-e para saber quais são as versões de XML Schema suportadas pelo sistema." } ] } XML DPS GERADO PELA API <?xml version="1.0" encoding="UTF-8"?> <Rps xmlns="http://www.giss.com.br/tipos-v2_04.xsd"> <InfDeclaracaoPrestacaoServico Id="Dec_9241"> <Rps> <IdentificacaoRps> <Numero>924</Numero> <Serie>1</Serie> <Tipo>1</Tipo> </IdentificacaoRps> <DataEmissao>2026-05-06</DataEmissao> <Status>1</Status> </Rps> <Competencia>2026-05-06</Competencia> <Servico> <Valores> <ValorServicos>10.00</ValorServicos> <ValorIss>0.50</ValorIss> <Aliquota>0.0500</Aliquota> </Valores> <IssRetido>2</IssRetido> <ItemListaServico>14.01</ItemListaServico> <CodigoCnae>4520001</CodigoCnae> <CodigoTributacaoMunicipio>4543900</CodigoTributacaoMunicipio> <Discriminacao>CARGA BATERIA - R$ 10,00</Discriminacao> <CodigoMunicipio>2704302</CodigoMunicipio> <CodigoPais>0076</CodigoPais> <ExigibilidadeISS>1</ExigibilidadeISS> <MunicipioIncidencia>2704302</MunicipioIncidencia> </Servico> <Prestador> <CpfCnpj><Cnpj>XXXXXXXXXXXXXX</Cnpj></CpfCnpj> <InscricaoMunicipal>XXXXXXXXX</InscricaoMunicipal> </Prestador> <TomadorServico> <IdentificacaoTomador> <CpfCnpj><Cnpj>XXXXXXXXXXXXXX</Cnpj></CpfCnpj> </IdentificacaoTomador> <RazaoSocial>TOMADOR TESTE LTDA</RazaoSocial> <Endereco> <Endereco>RUA EXEMPLO</Endereco> <Numero>000</Numero> <Bairro>BAIRRO EXEMPLO</Bairro> <CodigoMunicipio>2704302</CodigoMunicipio> <Uf>AL</Uf> <Cep>XXXXXXXX</Cep> </Endereco> <Contato> <Telefone>XXXXXXXXXX</Telefone> <Email>[email protected]</Email> </Contato> </TomadorServico> <RegimeEspecialTributacao>2</RegimeEspecialTributacao> <OptanteSimplesNacional>2</OptanteSimplesNacional> <IncentivoFiscal>2</IncentivoFiscal> </InfDeclaracaoPrestacaoServico> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <!-- assinatura digital presente (omitida) --> </Signature> </Rps> Solicito verificação: - Houve alguma mudança no schema do provedor GISS? - A versão tipos-v2_04.xsd ainda é a aceita pelo município? - Existe algum campo novo obrigatório que precise ser enviado no JSON? - Há alguma instabilidade conhecida no provedor neste momento?

Testei aqui e está tudo 100% agora, emitindo normalmente. Agradeço pela atenção.

Boa tarde! Algum retorno sobre esta situação?

Boa tarde! Realizando novas validações vimos que o erro de XSD deixou de ocorrer, pelo método POST https://prod.acbr.api.br/nfse/dps passou corretamente e gerou o ID. Porém, estou recebendo esses retornos ao consultar a ID da NFSe gerada no método GET https://prod.acbr.api.br/nfse/nfs_3a20c3a823ba4d4095588e4c42ee6f66: { "id": "nfs_3a20c3a823ba4d4095588e4c42ee6f66", "created_at": "2026-04-20T19:19:00.763Z", "status": "erro", "ambiente": "producao", "referencia": "45402907000115_504_08:31:34", "DPS": { "serie": "1", "nDPS": "330" }, "mensagens": [ { "codigo": "E327", "descricao": "O regime de tributação informado difere do registrado na Prefeitura." }, { "codigo": "E337", "descricao": "A Retenção informada no xml(nfse:IssRetido) não é compatível com a regra do município." }, { "codigo": "E292", "descricao": "País do tomador do serviço indevido" } ] } O payload de emissão seria este abaixo: { "provedor": "padrao", "ambiente": "producao", "referencia": "45402907000115_504_08:31:34", "infDPS": { "tpAmb": 1, "dhEmi": "2026-04-20T08:14:33Z", "verAplic": "acbrapi", "dCompet": "2026-04-20", "prest": { "CNPJ": "45402907000115", "regTrib": { "regEspTrib": 1 } }, "toma": { "CNPJ": "30201806000109", "IE": "xxx", "xNome": "SELLER TINTAS LTDA", "end": { "endNac": { "cMun": "4111407", "CEP": "84460000" }, "xLgr": "INDUSTRIAL DA LINHA GONCALVES JUNIOR", "tpLgr": "Rua", "nro": "1", "xBairro": "LINHA GONCALVES JUNIOR" }, "fone": "4232471285", "email": "[email protected]" }, "serv": { "cServ": { "cTribNac": "140101", "CNAE": "4520001", "xDescServ": "DIAGNOSTICO COMPUTADORIZADO - R$ 10,00\nMÃO DE OBRA - R$ 10,00" }, "infoCompl": { "xInfComp": "OS nº 234 Modelo: OROCH 16 EXP42 Placa: xxx KM: 121135 Ano/Modelo: 2016/2017 Chassi:xxx" } }, "valores": { "vServPrest": { "vServ": 10 }, "trib": { "tribMun": { "tribISSQN": 1, "tpRetISSQN": 1, "cLocIncid": "4111407" }, "totTrib": { "vTotTrib": { "vTotTribFed": 0, "vTotTribEst": 0, "vTotTribMun": 0 } } } } } } Acredito que o erro de regime de tributação ocorra por conta dos outros dois erros, pois tentamos emitir com todas as opções disponíveis de regime de tributação e o retorno sempre foi o mesmo Sobre a retenção e o país, mesmo preenchendo o payload corretamente, é retornado que não está sendo preenchido o país do tomador e que a retenção informada não é compatível com a regra. Porém mesmo mudando o tipo de retenção e tentando adicionar o bloco "endExt" o mesmo erro é retornado, provavelmente algum ajuste que falta na comunicação. Poderia validar?

Abaixo o retorno do método https://prod.acbr.api.br/debug/http-requests/req_3a20a9eacee54a09abf382b579795f05/request-content comprovando que o XML enviado não está levando o campo "cLocPrestacao" corretamente <?xml version="1.0" encoding="UTF-8"?> <DPS xmlns="http://www.sped.fazenda.gov.br/nfse" versao="1.01"> <infDPS Id="DPS411850127773955500018400001000000000004752"> <tpAmb>1</tpAmb> <dhEmi>2026-04-15T15:24:32+00:00</dhEmi> <verAplic>acbrapi</verAplic> <serie>1</serie> <nDPS>4752</nDPS> <dCompet>2026-04-15</dCompet> <tpEmit>1</tpEmit> <cLocEmi>4118501</cLocEmi> <prest> <CNPJ>77739555000184</CNPJ> <IM>163800</IM> <fone>4632241381</fone> <email>[email protected]</email> <regTrib> <opSimpNac>3</opSimpNac> <regApTribSN>1</regApTribSN> <regEspTrib>0</regEspTrib> </regTrib> </prest> <toma> <CPF>05320026951</CPF> <xNome>ELUIR PARIZOTTO</xNome> <end> <endNac> <cMun>4118501</cMun> <CEP>89990000</CEP> </endNac> <xLgr>MONTE CASTELO</xLgr> <nro>256</nro> <xBairro>SANTA CATARINA</xBairro> </end> </toma> <serv> <locPrest> <cLocPrestacao>0</cLocPrestacao> -- Problema de cLocPrestacao ocorre aqui </locPrest> <cServ> <cTribNac>140101</cTribNac> <xDescServ>\nLIMPEZA QUIMICA VARETAMENTO RD AGUA + DESCARBONIZACAO+ CONSERTO INTERCOOLER - R$ 850,00</xDescServ> </cServ> </serv> <valores> <vServPrest> <vServ>850.00</vServ> </vServPrest> <trib> <tribMun> <tribISSQN>1</tribISSQN> <tpRetISSQN>1</tpRetISSQN> <pAliq>2.00</pAliq> </tribMun> <totTrib> <pTotTribSN>0.00</pTotTribSN> </totTrib> </trib> </valores> </infDPS> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI="#DPS411850127773955500018400001000000000004752"> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>yG8Fm50ErTmKM89AJvrE8=</DigestValue> </Reference> </SignedInfo> <SignatureValue>4FZPQccaBMmouuw5IFbGzNKOmOplS9I3V+8A==</SignatureValue> <KeyInfo> <X509Data> <X509Certificate>ZuwpxX1zoBM943UpYCjJCS7jN1TI64rA9qyW6bIzEhBRsphfGZOcUAAN4jRrhXED1yL4KgJQJN2wA==</X509Certificate> </X509Data> </KeyInfo> </Signature> </DPS> Olá! Para a ACBr API o erro ainda persiste, alguma atualização a respeito da validação da API?

Entendi, vou entrar em contato com a prefeitura via e-mail para verificar a respeito do retorno. Sobre o outro ponto: quando eu recebo este retorno, o lote demora cerca de 2/3 minutos para ser processado e aparecer corretamente na prefeitura e no ambiente nacional. No ambiente nacional é gerado sem erros, tudo certinho. Sobre o cancelamento, seria algo da API?

Realizei os testes e o problema do "Serviço Consultar NFSe Por Faixa não implementado para este provedor" foi resolvido. No entanto, identificamos duas situações que ainda precisam de atenção: 1. Emissão da NFSe — Erro E9992 Ao emitir uma nota, recebemos o seguinte retorno: Vale destacar que, apesar da mensagem de erro, a nota é gerada e pode ser consultada/impressa normalmente após alguns minutos utilizando o método de consulta de NFSe. O erro parece ser um falso positivo, pois a emissão ocorre com sucesso. Gostaríamos de entender se é possível tratar esse comportamento para que o erro não seja retornado quando a emissão for bem-sucedida. 2. Cancelamento da NFSe — Campos obrigatórios não identificados Ao tentar cancelar uma NFSe emitida, recebemos a seguinte resposta: { "id": "3a20b330-c7dd-497d-9833-36142950895e", "status": "rejeitado", "codigo": "1", "motivo": "NOTA EMITIDA EM TESTES", "data_hora": "2026-04-17T17:34:43.490Z", "mensagens": [ { "codigo": "E999", "descricao": "Chave ou cMotivo ou xMotivo nao informada para cancelamento", "correcao": "Informe a chave de acesso ADN no campo ADNChave" }, { "codigo": "X209", "descricao": "Retorno do Cancelamento não encontrado." } ] } Se puderem verificar se é possível suprimir ou tratar o retorno de erro quando a nota for emitida com sucesso para não ocorrer "E9992 - RPS rejeitado pela ADN!" e a respeito do cancelamento rejeitado, verificar sobre como o campo ADNChave está sendo preenchido para que o cancelamento seja processado.

Olá! Na tarde de hoje, um de nossos clientes que utiliza a API ACBr para emissão de NFSe reportou que as notas passaram a retornar o seguinte erro: P9020 - Erro de validação do XML: The 'http://www.sped.fazenda.gov.br/nfse:cLocPrestacao' element is invalid - The value '0' is invalid according to its datatype 'http://www.sped.fazenda.gov.br/nfse:TSCodMunIBGE' - The Pattern constraint failed. Consultando o cadastro do município via GET /nfse/cidades/4118501, o retorno indica o provedor Pronim para Pato Branco/PR. { "codigo_ibge": "4118501", "uf": "PR", "municipio": "Pato Branco", "provedor": "Pronim", "ambientes": [ "producao", "homologacao" ], "credenciais": [ "certificado" ] } No payload enviado ao endpoint POST /nfse/dps, o campo cLocPrestacao está corretamente preenchido com o código IBGE "4118501": Abaixo o payload enviado para o métogo POST /nfse/dps para entar emitir a NFSe: { "provedor": "padrao", "ambiente": "producao", "referencia": "77739555000184_3858_15:54:59", "infDPS": { "tpAmb": 1, "dhEmi": "2026-04-15T15:24:32.011Z", "verAplic": "acbrapi", "dCompet": "2026-04-15", "prest": { "CNPJ": "77739555000184", "regTrib": { "regEspTrib": 0 } }, "toma": { "CPF": "xxx", "xNome": "ELUIR PARIZOTTO", "end": { "endNac": { "cMun": "4211108", "CEP": "89990000" }, "xLgr": "MONTE CASTELO", "nro": "xxx", "xBairro": "SANTA CATARINA" } }, "serv": { "locPrest": { "cLocPrestacao": "4118501", "cPaisPrestacao": "BR" }, "cServ": { "cTribNac": "140101", "cTribMun": "042", "CNAE": "4520001", "xDescServ": "LIMPEZA QUIMICA VARETAMENTO RD AGUA + DESCARBONIZAÇÃO+ CONSERTO INTERCOOLER - R$ 850,00" }, "infoCompl": { "xInfComp": "OS nº 2412 Modelo: Placa: KM: Ano/Modelo: 2026/2026Chassi:" } }, "valores": { "vServPrest": { "vServ": 850 }, "trib": { "tribMun": { "tribISSQN": 1, "tpRetISSQN": 1, "pAliq": 2, "cLocIncid": "4118501" }, "totTrib": { "vTotTrib": { "vTotTribFed": 0, "vTotTribEst": 0, "vTotTribMun": 17 } } } } } } No entanto, a resposta retornada pelo endpoint GET /http-request/{req_id}/response-content indica que o campo está sendo enviado com o valor "0" ao provedor, como se o dado original estivesse sendo descartado ou sobrescrito internamente antes do envio. O retorno completo do erro foi: { "lote": [ { "id": null, "chaveAcesso": null, "statusProcessamento": "ERRO", "xmlGZipB64": null, "codAutenticidade": null, "erros": [ { "codigo": "P9020", "descricao": "Erro de validação do XML: The 'http://www.sped.fazenda.gov.br/nfse:cLocPrestacao' element is invalid - The value '0' is invalid according to its datatype 'http://www.sped.fazenda.gov.br/nfse:TSCodMunIBGE' - The Pattern constraint failed." } ] } ], "tipoAmbiente": "PRODUCAO", "versaoAplicativo": "526.02.01.028", "dataHoraProcessamento": "2026-04-15T16:21:42-03:00", "protocolo": null, "processado": true } Considerando que o payload está montado corretamente conforme a especificação da ACBr API, a hipótese é que o problema esteja na integração com o provedor Pronim, possivelmente um mapeamento incorreto ou ausente do campo cLocPrestacao para esse provedor específico. Poderiam verificar se há alguma tratativa especial para o Pronim (Pato Branco/PR) que esteja zerando esse campo, ou se trata-se de um bug na versão atual? Aguardo retorno. Desde já, obrigado! Abaixo o retorno do método https://prod.acbr.api.br/debug/http-requests/req_3a20a9eacee54a09abf382b579795f05/request-content comprovando que o XML enviado não está levando o campo "cLocPrestacao" corretamente <?xml version="1.0" encoding="UTF-8"?> <DPS xmlns="http://www.sped.fazenda.gov.br/nfse" versao="1.01"> <infDPS Id="DPS411850127773955500018400001000000000004752"> <tpAmb>1</tpAmb> <dhEmi>2026-04-15T15:24:32+00:00</dhEmi> <verAplic>acbrapi</verAplic> <serie>1</serie> <nDPS>4752</nDPS> <dCompet>2026-04-15</dCompet> <tpEmit>1</tpEmit> <cLocEmi>4118501</cLocEmi> <prest> <CNPJ>77739555000184</CNPJ> <IM>163800</IM> <fone>4632241381</fone> <email>[email protected]</email> <regTrib> <opSimpNac>3</opSimpNac> <regApTribSN>1</regApTribSN> <regEspTrib>0</regEspTrib> </regTrib> </prest> <toma> <CPF>05320026951</CPF> <xNome>ELUIR PARIZOTTO</xNome> <end> <endNac> <cMun>4118501</cMun> <CEP>89990000</CEP> </endNac> <xLgr>MONTE CASTELO</xLgr> <nro>256</nro> <xBairro>SANTA CATARINA</xBairro> </end> </toma> <serv> <locPrest> <cLocPrestacao>0</cLocPrestacao> -- Problema de cLocPrestacao ocorre aqui </locPrest> <cServ> <cTribNac>140101</cTribNac> <xDescServ>\nLIMPEZA QUIMICA VARETAMENTO RD AGUA + DESCARBONIZACAO+ CONSERTO INTERCOOLER - R$ 850,00</xDescServ> </cServ> </serv> <valores> <vServPrest> <vServ>850.00</vServ> </vServPrest> <trib> <tribMun> <tribISSQN>1</tribISSQN> <tpRetISSQN>1</tpRetISSQN> <pAliq>2.00</pAliq> </tribMun> <totTrib> <pTotTribSN>0.00</pTotTribSN> </totTrib> </trib> </valores> </infDPS> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI="#DPS411850127773955500018400001000000000004752"> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>yG8Fm50ErTmKM89AJvrE8=</DigestValue> </Reference> </SignedInfo> <SignatureValue>4FZPQccaBMmouuw5IFbGzNKOmOplS9I3V+8A==</SignatureValue> <KeyInfo> <X509Data> <X509Certificate>ZuwpxX1zoBM943UpYCjJCS7jN1TI64rA9qyW6bIzEhBRsphfGZOcUAAN4jRrhXED1yL4KgJQJN2wA==</X509Certificate> </X509Data> </KeyInfo> </Signature> </DPS>

Claro, amanhã na primeira hora realizaremos o teste e retornaremos por aqui. Agradeço pela atenção.

Para resolver, foi necessário realizar o envio do payload com provedor = nacional, mesmo possuindo provedor próprio, por conta do cliente ser optante MEI. Agradeço também pela resolução do Console, que também funcionou

Olá! Pelo que analisei, não está sendo possível obter esses retornos. Os métodos de consulta exigem o ID da NFS-e para validação, porém esse ID só é gerado quando o payload consegue passar pelo método POST /nfse/dps. Como, neste caso, o envio inicial já retorna erro de XSD, a requisição não é processada e, consequentemente, nenhum ID é gerado. Sem esse identificador, não é possível utilizar os métodos de debug ou consulta para obter mais detalhes, o problema está logo no início do processo.