[ACBR-9238]Problema para chegar o XML da FSE no Pronim da Prefeitura de Ijuí - RS

[Alcindo de Almeida Neto]

Pessoal, tenho recorrido bastante a vocês aqui, e vocês tem ajudado. Algumas coisas evoluíram, mas ainda não estou conseguindo chegar a NFSE.

Estamos em uma situação bem delicada com o nosso cliente, e a coisa está dramática.

 

1) Revisei o cadastro do cliente na ACBR API, tudo certo!;
2) Entrei com contato com a prefeitura, conversei com o responsável do setor de tributação, e está tudo certo com o cadastro do cliente lá na Prefeitura de Ijuí. 
3) Testei várias combinações entre provedor "Nacional" e "Padrao";

4) Revisei as tags obrigatórias do JSON, tudo certo.

5) A NFSE é gerada pela ACBR API, conforme abaixo:

  "id": "nfs_3a2032a6f932487d9db73e66ed8af8a9",

  "created_at": "2026-03-23T18:32:48.018Z",

  "status": "processando",

  "ambiente": "producao",

  "referencia": "00000057",

  "DPS": {},

  "mensagens": []

6) Mas a NFSE não chega no ambiente do cliente lá no sistema da Pronim.

 

Não sei mais o que fazer, acabaram todas as minhas fichas.

Se pudessem fazer um teste por favor, o nosso client id é: TwcEx6YFxasbfq4R1U9Q

O Payload que pode ser usado é esse:
 

{

  "provedor": "padrao",

  "ambiente": "producao",

  "referencia": "00000059",

  "infDPS": {

    "dhEmi": "2026-03-23T12:00:00-03:00",

    "dCompet": "2026-03-23T00:00:00-03:00",

    "prest": {

      "CPF": "10468617000",

      "regTrib": {

        "regEspTrib": 4

      }

    },

    "toma": {

      "CPF": "90825004004",

      "xNome": "ROBERTO PEREIRA MULLER",

      "end": {

        "endNac": {

          "cMun": "4310207",

          "CEP": "98700000"

        },

        "xLgr": "Sem denominação",

        "tpLgr": "Rua",

        "nro": "1",

        "xBairro": "INTERIOR"

      }

    },

    "serv": {

      "cServ": {

        "cTribNac": "210101",

        "cTribMun": "6912500",

        "CNAE": "9609299",

        "xDescServ": "De Inteiro Teor da Matrícula",

        "cNBS": "113040000",

        "cSitTrib": "0"

      }

    },

    "valores": {

      "vServPrest": {

        "vServ": 10.00

      },

 

 

 

 

[Alcindo de Almeida Neto]

Tentamos fazer mais um teste em um cliente do município de Catanduvas - PR que utiliza o mesmo sistema do município de Ijuí - RS (Pronim/Governança Brasil - GOVBR), e o erro foi exatamente o mesmo.
A NFSE foi gerada com sucesso pela ACBR API, mas o XML nem chega lá na Prefeitura de Catanduvas (no sistema da Pronim é possível consultar os arquivos recebidos e ver os logs).
Revisamos tudo aqui e é para estar tudo certo.

Um ponto importante é que localizamos esse ticket aqui e que nos pareceu ser exatamente o mesmo problema:

 

Parece que tem alguma coisa errada na hora de validar os dados enviados no momento da importação o sistema da prefeitura entre a ACBR API e o sistema PRONIM.
Eu estava lendo a documentação da Governança Brasil sobre o envio, uma situação que é colocada na documentação é que o envio dos dados (entre a ACBR API e a Prefeitura) deve seguir essa regra aqui:

"Cada XML (seja de uma DPS ou de um evento de cancelamento) deve ser assinado, compactado no padrão GZip, convertido para Base64 e, por fim, encapsulado dentro de um array num arquivo JSON (ex: {"LotexmlGZipB64": ["STRING_BASE_64", "STRING_BASE_64"]})"

Resolvi comentar isso por que vai que tem algo descoberto nesse processo.

[Diego Foliene]

Boa tarde!

2 horas atrás, Alcindo de Almeida Neto disse:

A NFSE foi gerada com sucesso pela ACBR API, mas o XML nem chega lá na Prefeitura de Catanduvas (no sistema da Pronim é possível consultar os arquivos recebidos e ver os logs).

Com a ACBr API você também consegue fazer isso.

Por favor, tente executar o end-point DebugHttpRequestContent e DebugHttpResponseContent passando como identificador os Ids correspondentes a essa tentativa na qual a nota não chegou ao sistema da Pronim.

Anexe aqui os valores que forem devolvidos.

Também vamos pedir ao pessoal se podem fazer um teste com os dados fornecidos.

[Alcindo de Almeida Neto]

1 hora atrás, Diego Foliene disse:

Boa tarde!

Com a ACBr API você também consegue fazer isso.

Por favor, tente executar o end-point DebugHttpRequestContent e DebugHttpResponseContent passando como identificador os Ids correspondentes a essa tentativa na qual a nota não chegou ao sistema da Pronim.

Anexe aqui os valores que forem devolvidos.

Também vamos pedir ao pessoal se podem fazer um teste com os dados fornecidos.

id: nfs_3a203841d1e445948c5185e721d1d8ab

 

ID da Requisição (rid): req_3a20379d0b6645b284c5c6bd8b20bee2
-----------------------------------------------------------------

>>> [ENVIO_LOTE] REQUEST CONTENT (ENVIADO PARA PREFEITURA):

{"loteXmlGZipB64":["H4sIAAAAAAAA/61XWZOiyBb+KxV1H41uFkVlgnYuuyCg7MIbArLIpiDbr7+JVlVX9/TEzNwYQ+DkyZPfWfOQEL/3efbShrc6KYtvr8hX+PUlLPwySIro26tpcF/Wr79vCOagvwDBov72GjdN9RsEdV33ta7C4OvZG8Mi8L5GZfv1dIOKcx2+PgC98oGHvG6IpDhPCELw7RU8F3MERuEVAsMwAi+W6yWygp8/BP7hNwdLm4rMTxuEgJ4EEcRsnmxQGF1+gedf0LmBoL/BMPiDIbgT0FOAABaQVZb4G88/3bwqIaAPDlGHtyScMJ8EUQCjNnMCejyJgC7zKmw+6QCgbzxgDkBvnvY8KMKXSn/S+OYVAb0ziOoW1kCAPnCbT34S0MQgBHmzQhEURwkIkMS5LMINhs3ncxTB0SUBPRhEmHtJtvEaEOEkD4um/O8tjJK6uZVJek+++mUOYk5ATzECzBm3BASprPQkrxTPnwz9PpgE2Lp6yCwI6NPoMXij3sxuytx7Go/DaxSD4QX4vxnfK2UebmRSo/f6i2QK+otsShKrEdBzhgD2Pm4Prb58Lz6FZxoRNHvY4Otn3gEoGAEv3uR7Kbpt9DB/CcKizJPC870SIE9coriVk0/Tg+gpL7kBQlAMVhP2k/Y3zgML3J8+gCy3GyIr/cPTsylBD3IC/jFv39kE9GmB/kDwpwBNFqIIqFRgxQeD6Jmwfkox4YtQNGFyK1+MsLy9BN6L7DW3xL9nHjDwQ47wFUrfIMh8iusUg8cYPJ6z0NPo1stKYAMgJvabOQ8alNTXaVn7Jv9ZoHkkcro/Yj0Rgq6ryqNsPwaglrWw+T7xffSUeq4tm2dZtMbPFBcGmzcbPnE+pllgyY/T7MP4t8GE/uP0Qx/0XQ/UfKeej49oQM+GsiH0JCq85n4Lf9GduvnX8hZBKIguBOMQEAjqJPrP63NVGAjFGaSZ9oqySHwvS0avAT1QDpu4DF7ILCpvSRPnv4I0tAkVgTSW/gJgv/jIovgyceA5ggF86Negn8z9O1p+Nhx01C917E39FPoJaENo4Tm8gcYdvpia8O31P/+0zRo3r6jP5S2vP9H/zL6waMOsBK+EL/W7dZOpH2h/G/gvw/sJEvpsOJNEoP7/n9i+x/Uzwjue5WX3cHM9784SF5VCnY7duAN98zRTlodL16vf3tc9JQnoIxlvmXqvtY+svUGOe/4yY8Pt8hSa15skz+ojjfnymNuJKkXC3iCv6ZBG7I2Shx1O0YF6YRb6VTdSnG7b2XLm4+nSsMPlwutAnySLkKegZqxULjEXymFHKuXxPAsXcovM2up6NTg1X+XUvWfyTIOHmVNvg3TOSdpiH8UnN8orBtr185uhc7uZbzlq0ojx6VJBzJY0bP+Q4m7v6H0Hszyy8IWqOhdug3VyB04LBjqrI4l0zot0kG/H+GraObvfx+slKkhQHaU7VJfnJ2FMPcbD3GCb3OD9Qpn5fbAITWuVr1w/aGbRVt/lA6aP3apjMqknbzR4oReaHTc5e5nVJgl5ScyeZsyulYwYW/AKVq1ciJtrfBoZKyP69u3T9njLyC4cnhk4YjDOeI33pOjw1iRnsE8b8DIThG2b0jTleRHZCRQZCYKt5DJGJ2xb1x2jOuKudIW49RVSZSVKJbsgZSWZvPAkYrJULNNqJvTsSGpUpFgUWRr0JWNMGqH9nBs9u+uVlISfc7UhWUrmzMUs4LnBs9nI5dnIzK3UtTPY0SnetbUMrKsFXmsFVhyco1KdaLIROJFXU9aTqeihl+xlTTXlyLxYrKZTosZaoqpTunYRum3sK3LqdLJBIrIhD3tGndsPnv8jL6WphfHPfOFG0nr3hUnlXhkFZG/4sMyQANtBwdUppMNYqiqxA2K4tjK4Ry328ywGPsXAj8xBrSoAfmu5dXGPoNRo6nIaqHcdkfT0o+cM0vjQNfmfUJlkKqqWUJRssKZMCQ+76V6WdqylgHjpqokxxnDpeYM8vq9lt27l8lbroPjdza3BtbEUxL4XGTJ5ysgGDwN1l8wAMaQtSxM1GDsYTNnLjIruGQf4CfxjaJrUhZ9rggI1wUQReyCnebWkAU2R0mFpBk6D8SHV6rxaoNdByazwbGPZ8dxFGgrL8MJrve1YjAgE5TgSKXk/hnKqR6MW5oliST6nIrQ9l+kWP7mqYKbsdrGtoaU5X1UaXUajcLJEDKZLO+T9a5euTk18yyoadeFZGp62M5wTdufI2FVxekfjxVbK40u6E61LfjlIOgshA21drXhHQbO1wdv3ArIgN02GbY0I2+VBELd06Nw7xKxsEUnxPSPe/WQ8WOJdPZW62ubocZnpeGobWi0k/ky4XSPrYsKVW1VLo/d6JGvLFSYpSUlD9Vmsrhc2UwX7zmPZlfIhVmRLakCgUWyZVKJd0BbziEfvh3nLjN6hNpfD2F/jA5zH5KIrYZMmO5YkvT1N3oUuiqRQptZTDQRCpzoy5ZHcoTLWONwpR8zEC7s7WhSMBMG21WYXmVw8ZJmOpaBOZcF+5xYM1U41sNVJ1mOoXOZVnsopmVQFyjUoT+YinqZrnlRNjgL9gbv0ZbDVun2ybv3c6k5zBdQyDvby+u5MtQ72r/e42Duot0bKxUFCuVQ6ihmowakOK+co5k6CX3xebn5cww1uLtx9XstlgUcfdmlrNvIWXeTVnbmktJKd8YYdw8GWXEoDDvYW1fpoBp/mYnUasHjqLR96dCw9ofDdKYTWseXGn/abnU0X2I9uIqF96idI7AzIH2wAOLXM6ZF5pdT4gv2Zz4OUc+lnXClX2pOOJX6C/wq3PfHKINm/igcGcLouOq0/xRvsLYEfQCxamTO/80eSji/Zv5WHX/rvM0Eic85POqt/LQ6/zEdBzh3Qk4sO9E8N1oDvR+C7GWk4ZbHWXmMzRTMx04BBfzQD0UQ03YCznWVe7iqMK9JF1Esm4il7ql+ZKum1IRks6M1+vzfUHvR+WEkj0KPBe2Dq13917ciQiqzIIFkGbC2L7eU/lS0p/10vX5ILg/mjTPDcZybLpaRJRdGNiliOUn2GjBxh1zmgj5pbslN/9c4F/RW8mynejgVq3O5K9ERpkAnNULNVcRdWofzcr1R/XRyEubQ4VuSST8H36bjVB6FkrVpSt/TZ3BfyVaW7K75lOabhYMs6nU2dhU9bCWtDbETYns+v22JQk3M0epDneWOz7ytON9HKcZZzepacUEiMEQQyLjS04r0l3TRNXY2uyFwvkOH7MENmgXrtdw1zcJftDHbprj0UbWqU2/S6G66+1IBMyQGf1MfqpNg0a1rHZX7WcKM7o6ZsCcEV0vx9TvK1GPtjH8GQjIgUxaBi7NGDv1xG+Do+8FABN3YW7J3iiO6oxFFMst177jXVcAeLTmVlePIR3KJjf7vM3PlquaLplZbAXh6rCTafXcP62kCpfDjFQtpIzpxyZbwM2m287VydLKPSvnCWeJS0OvVm5/FWRYHsaJSeXo3VTdbCCzy683aHC8tAM9pudd87it0eFhd6cOhlKITUYIjSwugcN96f51Wzrs7XTmKWehKSuoz63XAXLyk1Buu2WfaBMJPkRYEi1G5dr/ZNEtuja4mSm+6lCN41XixSfrlrFbwSfIqPmhS94nWnbodi5omntVIHDtTKdhl7Y2AcNReRTwUrYGtHmCE9cxgtiFvUBtLTOHQUT9LFMWsaAmex2QrvStblLmznFH61qjCIJZn5njqP+p1Tu3mkhabG1Ct1v+78lon7/ZHC5nfPqlv32O7sY57b6r0KZxG5Z5UeHDoI6OeT5pPzPIVCHyfT72fW6TMEfNv+D9nFQZ2aEwAA"]}

RESPONSE CONTENT (RETORNO DA PREFEITURA)
{"lote":[{"id":"DPS431020710001046861700000001000000000000003","chaveAcesso":null,"statusProcessamento":"ERRO","xmlGZipB64":null,"codAutenticidade":null,"erros":[{"codigo":"P9008","descricao":"Documento do Certificado Digital (14071941104686) enviado na requisição difere do documento do emitente da nota (10468617000)"}]}],"tipoAmbiente":"PRODUCAO","versaoAplicativo":"526.02.01.024","dataHoraProcessamento":"2026-03-24T14:40:03-03:00","protocolo":null,"processado":true}
-----------------------------------------------------------------

[Alcindo de Almeida Neto]

Fiz um teste de envio da NFSE para o município de Catanduvas - PR (mesmo sistema de Ijuí: Pronim/Governança Brasil), deu exatamente o mesmo erro:
[{"codigo":"P9008","descricao":"Documento do Certificado Digital (28111965575193) enviado na requisição difere do documento do emitente da nota (57519358968)"}]}]

[valterpatrick]

18 horas atrás, Alcindo de Almeida Neto disse:

Fiz um teste de envio da NFSE para o município de Catanduvas - PR (mesmo sistema de Ijuí: Pronim/Governança Brasil), deu exatamente o mesmo erro:
[{"codigo":"P9008","descricao":"Documento do Certificado Digital (28111965575193) enviado na requisição difere do documento do emitente da nota (57519358968)"}]}]

Tivemos o mesmo erro com o provedor pronim em outra cidade.
Recomendo você entrar em contato com o provedor e a cidade, por que pela análise do caso abaixo, pode ser algum erro no lado do provedor ou alguma alteração que implementaram.
Assim que conseguir um retorno, por favor nos informe.

 

[Alcindo de Almeida Neto]

Descobri onde está o problema (e é no sistema da PRONIM), olha só:
Na mensagem de erro está assim:

"erros":[{"codigo":"P9008","descricao":"Documento do Certificado Digital (14071941104686) enviado na requisição difere do documento do emitente da nota (10468617000)"}]"
 

Perguntei ao portador do certificado A1 CPF, se a data de nascimento era 14/07/1941. E a resposta foi SIM.

Se juntarmos a data de nascimento (14071941) com os 6 primeiros dígitos do CPF (104686), o resultado é: 14071941104686 (14 dígitos, igual a um CNPJ)

Ou seja, o sistema PRONIM está esperando necessariamente sempre por um CNPJ, ao pegar os metadados do certificado A1 CPF, ele está pegando os 14 primeiros dígitos dos metadados.

O sistema da PRONIM deveria primeiro ver o tipo do certificado, se é CPF ou CNPJ, e dependendo do tipo fazer a validação dos metadados com o CPF ou CNPJ do emissor da nota.

 

Editado 25 Março por Alcindo de Almeida Neto

[valterpatrick]

1 minuto atrás, Alcindo de Almeida Neto disse:

Descobri onde está o problema (e é no sistema da PRONIM), olha só:
Na mensagem de erro está assim:

"erros":[{"codigo":"P9008","descricao":"Documento do Certificado Digital (14071941104686) enviado na requisição difere do documento do emitente da nota (10468617000)"}]"
 

Perguntei ao portador do certificado A1 CPF, se a data de nascimento era 14/07/1941. E a resposta foi SIM.

Se juntarmos a data de nascimento (14071941) com os 6 primeiros dígitos do CPF (104686), o resultado é: 14071941104686 (14 dígitos, igual ao CNPJ)

Ou seja, o sistema PRONIM está esperando necessariamente sempre por um CNPJ, ao pegar os metadados do certificado A1 CPF, ele está pegando os 14 primeiros dígitos dos metadados.

O sistema da PRONIM deveria primeiro ver o tipo do certificado, se é CPF ou CNPJ, e dependendo do tipo fazer a validação dos metadados com o CPF ou CNPJ do emissor da nota.
 

Já chegou a entrar em contato com o Pronim a respeito deste problema?
Passe esta sua observação para eles e nos mantenha atualizados.

[Alcindo de Almeida Neto]

Agora, valterpatrick disse:

Já chegou a entrar em contato com o Pronim a respeito deste problema?
Passe esta sua observação para eles e nos mantenha atualizados.

Mandei um email o setor de tributação da prefeitura de Ijuí-RS detalhando todo o problema. Em todos da Pronim deve ocorrer essa situação. NFSE emitidas por CPF. Eles vão precisar corrigir.

[valterpatrick]

Agora, Alcindo de Almeida Neto disse:

Mandei um email o setor de tributação da prefeitura de Ijuí-RS detalhando todo o problema. Em todos da Pronim deve ocorrer essa situação. NFSE emitidas por CPF. Eles vão precisar corrigir.

Obrigado por este retorno parcial, aguardamos novas atualizações

 

[Alcindo de Almeida Neto]

O pessoal da PRONIM/GOVERNANÇA BRASIL, respondeu ao ticket criado pela prefeitura de Ijuí:

"Apesar de não ter sido enviado/anexado ao chamado o arquivo json de retorno da API ao ser processado o XML/DPS. Foi feito a validação do XML enviado/anexado sendo sua assinatura invalida. Detalhes técnicos para construção, assinatura dos XML e sua validação junto a API, assim como esclarecimentos de dúvidas podem ser obtidas em:

https://reformatributaria.cidade360.cloud/NFSe.portal.teste/#"

 

Pelo que entendi da resposta, estaria tudo certo do lado deles e o problema seria na assinatura do XML

 

A minha dúvida é se o problema não estaria na geração da assinatura do XML gerado pela ACBR API?

 

Relembrando o caso:
"

Na mensagem de erro está assim:

"erros":[{"codigo":"P9008","descricao":"Documento do Certificado Digital (14071941104686) enviado na requisição difere do documento do emitente da nota (10468617000)"}]"
 

Perguntei ao portador do certificado A1 CPF, se a data de nascimento era 14/07/1941. E a resposta foi SIM.

Se juntarmos a data de nascimento (14071941) com os 6 primeiros dígitos do CPF (104686), o resultado é: 14071941104686 (14 dígitos, igual ao CNPJ)

Ou seja, o sistema PRONIM está esperando necessariamente sempre por um CNPJ, ao pegar os metadados do certificado A1 CPF, ele está pegando os 14 primeiros dígitos dos metadados.

O sistema da PRONIM deveria primeiro ver o tipo do certificado, se é CPF ou CNPJ, e dependendo do tipo fazer a validação dos metadados com o CPF ou CNPJ do emissor da nota."

 

Não poderia a ACBR API estar pegando os 14 primeiros dígitos dos metadados do certificado CPF e gerando o XML com uma assinatura inválida (como um "CNPJ": 14071941104686 )?

[Daniel InfoCotidiano]

Criado a tarefa ACBR-9238 para análise, assim que concluida reportamos aqui.

 

[Italo Giurizzato Junior]

Boa tarde @Alcindo de Almeida Neto,

No meu certificado o valor de CN é o meu nome espaço o meu CPF (completo) dois pontos e o meu CNPJ completo.

Qual é o valor de CN desse certificado que esta usando?

[giovani.l.erthal]

CN = NOME:CPF

Enfrento esse mesmo problema em vários de nossos clientes:

"Documento do Certificado Digital (DDDDDDDDCCCCCC) enviado na requisição difere do documento do emitente da nota (CCCCCCCCCCC) (P9008)."

onde DDDDDDDD parece ser a data de nascimento da pessoa vinculada ao certificado, e CCCCCC é seu CPF.

Em todos os XMLs a parte de documento do prestador e do emitente está preenchida com o CPF corretamente.

A assinatura também SEMPRE está sendo feita com o certificado com CPF igual ao preenchido.

Cerro Branco/RS
Bozano/RS
etc...

Editado 20 Abril por giovani.l.erthal
Complementar informações

[Victor H. Gonzales - Panda]

A API utiliza o certificado anexado no cadastro da empresa, verifique se realmente o certificado que está vinculado condiz com a realidade da empresa

[Alcindo de Almeida Neto]

Em 20/04/2026 at 17:30, Italo Giurizzato Junior disse:

Boa tarde @Alcindo de Almeida Neto,

No meu certificado o valor de CN é o meu nome espaço o meu CPF (completo) dois pontos e o meu CNPJ completo.

Qual é o valor de CN desse certificado que esta usando?

Olá Ítalo, o CN está  nesse formato que você comentou acima: "Nome" + "CPF".
Mas me parece que o problema ocorre por conta do uso do OID do certificado para fazer a assinatura do XML, o conteúdo do OID do certificado fica na ordem: "Data de Nascimento + CPF + PIS (não obrigatório)+ RG (não obrigatório)".
Por conta disso, está sendo assinado o XML usando os primeiros 14 dígitos do OID, que seria a "data de nascimento" (8 posições) + "CPF" (as primeiras 6 posições).
Na hora de fazer a verificação da assinatura do XML, está sendo pego o CPF do certificado cadastrado, e ao comparar com os 11 primeiros dígitos do OID os valores não batem.

Por essa razão é que o XML assinado através de um CNPJ funciona corretamente, no OID do certificado A1 CNPJ os 14 primeiros dígitos são do número do CNPJ, não existe a Data de Nascimento no OID. 

[Diego Foliene]

Bom dia!

Estamos buscando mais informações sobre isso e reportamos assim que tivermos novidades.

Enquanto isso, por favor, tente novamente entrar em contato com o provedor para questionar sobre a assinatura.

Em 08/04/2026 at 20:10, Alcindo de Almeida Neto disse:

"Apesar de não ter sido enviado/anexado ao chamado o arquivo json de retorno da API ao ser processado o XML/DPS. Foi feito a validação do XML enviado/anexado sendo sua assinatura invalida. Detalhes técnicos para construção, assinatura dos XML e sua validação junto a API, assim como esclarecimentos de dúvidas podem ser obtidas em:

Eles mencionaram que a assinatura é inválida, no entanto se pegarmos o arquivo zipado que é enviado ao pronim na requisição:

Em 24/03/2026 at 14:47, Alcindo de Almeida Neto disse:

H4sIAAAAAAAA/61XWZOiyBb+KxV1H41uFkVlgnYuuyCg7MIbArLIpiDbr7+JVlVX9/TEzNwYQ+DkyZPfWfOQEL/3efbShrc6KYtvr8hX+PUlLPwySIro26tpcF/Wr79vCOagvwDBov72GjdN9RsEdV33ta7C4OvZG8Mi8L5GZfv1dIOKcx2+PgC98oGHvG6IpDhPCELw7RU8F3MERuEVAsMwAi+W6yWygp8/BP7hNwdLm4rMTxuEgJ4EEcRsnmxQGF1+gedf0LmBoL/BMPiDIbgT0FOAABaQVZb4G88/3bwqIaAPDlGHtyScMJ8EUQCjNnMCejyJgC7zKmw+6QCgbzxgDkBvnvY8KMKXSn/S+OYVAb0ziOoW1kCAPnCbT34S0MQgBHmzQhEURwkIkMS5LMINhs3ncxTB0SUBPRhEmHtJtvEaEOEkD4um/O8tjJK6uZVJek+++mUOYk5ATzECzBm3BASprPQkrxTPnwz9PpgE2Lp6yCwI6NPoMXij3sxuytx7Go/DaxSD4QX4vxnfK2UebmRSo/f6i2QK+otsShKrEdBzhgD2Pm4Prb58Lz6FZxoRNHvY4Otn3gEoGAEv3uR7Kbpt9DB/CcKizJPC870SIE9coriVk0/Tg+gpL7kBQlAMVhP2k/Y3zgML3J8+gCy3GyIr/cPTsylBD3IC/jFv39kE9GmB/kDwpwBNFqIIqFRgxQeD6Jmwfkox4YtQNGFyK1+MsLy9BN6L7DW3xL9nHjDwQ47wFUrfIMh8iusUg8cYPJ6z0NPo1stKYAMgJvabOQ8alNTXaVn7Jv9ZoHkkcro/Yj0Rgq6ryqNsPwaglrWw+T7xffSUeq4tm2dZtMbPFBcGmzcbPnE+pllgyY/T7MP4t8GE/uP0Qx/0XQ/UfKeej49oQM+GsiH0JCq85n4Lf9GduvnX8hZBKIguBOMQEAjqJPrP63NVGAjFGaSZ9oqySHwvS0avAT1QDpu4DF7ILCpvSRPnv4I0tAkVgTSW/gJgv/jIovgyceA5ggF86Negn8z9O1p+Nhx01C917E39FPoJaENo4Tm8gcYdvpia8O31P/+0zRo3r6jP5S2vP9H/zL6waMOsBK+EL/W7dZOpH2h/G/gvw/sJEvpsOJNEoP7/n9i+x/Uzwjue5WX3cHM9784SF5VCnY7duAN98zRTlodL16vf3tc9JQnoIxlvmXqvtY+svUGOe/4yY8Pt8hSa15skz+ojjfnymNuJKkXC3iCv6ZBG7I2Shx1O0YF6YRb6VTdSnG7b2XLm4+nSsMPlwutAnySLkKegZqxULjEXymFHKuXxPAsXcovM2up6NTg1X+XUvWfyTIOHmVNvg3TOSdpiH8UnN8orBtr185uhc7uZbzlq0ojx6VJBzJY0bP+Q4m7v6H0Hszyy8IWqOhdug3VyB04LBjqrI4l0zot0kG/H+GraObvfx+slKkhQHaU7VJfnJ2FMPcbD3GCb3OD9Qpn5fbAITWuVr1w/aGbRVt/lA6aP3apjMqknbzR4oReaHTc5e5nVJgl5ScyeZsyulYwYW/AKVq1ciJtrfBoZKyP69u3T9njLyC4cnhk4YjDOeI33pOjw1iRnsE8b8DIThG2b0jTleRHZCRQZCYKt5DJGJ2xb1x2jOuKudIW49RVSZSVKJbsgZSWZvPAkYrJULNNqJvTsSGpUpFgUWRr0JWNMGqH9nBs9u+uVlISfc7UhWUrmzMUs4LnBs9nI5dnIzK3UtTPY0SnetbUMrKsFXmsFVhyco1KdaLIROJFXU9aTqeihl+xlTTXlyLxYrKZTosZaoqpTunYRum3sK3LqdLJBIrIhD3tGndsPnv8jL6WphfHPfOFG0nr3hUnlXhkFZG/4sMyQANtBwdUppMNYqiqxA2K4tjK4Ry328ywGPsXAj8xBrSoAfmu5dXGPoNRo6nIaqHcdkfT0o+cM0vjQNfmfUJlkKqqWUJRssKZMCQ+76V6WdqylgHjpqokxxnDpeYM8vq9lt27l8lbroPjdza3BtbEUxL4XGTJ5ysgGDwN1l8wAMaQtSxM1GDsYTNnLjIruGQf4CfxjaJrUhZ9rggI1wUQReyCnebWkAU2R0mFpBk6D8SHV6rxaoNdByazwbGPZ8dxFGgrL8MJrve1YjAgE5TgSKXk/hnKqR6MW5oliST6nIrQ9l+kWP7mqYKbsdrGtoaU5X1UaXUajcLJEDKZLO+T9a5euTk18yyoadeFZGp62M5wTdufI2FVxekfjxVbK40u6E61LfjlIOgshA21drXhHQbO1wdv3ArIgN02GbY0I2+VBELd06Nw7xKxsEUnxPSPe/WQ8WOJdPZW62ubocZnpeGobWi0k/ky4XSPrYsKVW1VLo/d6JGvLFSYpSUlD9Vmsrhc2UwX7zmPZlfIhVmRLakCgUWyZVKJd0BbziEfvh3nLjN6hNpfD2F/jA5zH5KIrYZMmO5YkvT1N3oUuiqRQptZTDQRCpzoy5ZHcoTLWONwpR8zEC7s7WhSMBMG21WYXmVw8ZJmOpaBOZcF+5xYM1U41sNVJ1mOoXOZVnsopmVQFyjUoT+YinqZrnlRNjgL9gbv0ZbDVun2ybv3c6k5zBdQyDvby+u5MtQ72r/e42Duot0bKxUFCuVQ6ihmowakOK+co5k6CX3xebn5cww1uLtx9XstlgUcfdmlrNvIWXeTVnbmktJKd8YYdw8GWXEoDDvYW1fpoBp/mYnUasHjqLR96dCw9ofDdKYTWseXGn/abnU0X2I9uIqF96idI7AzIH2wAOLXM6ZF5pdT4gv2Zz4OUc+lnXClX2pOOJX6C/wq3PfHKINm/igcGcLouOq0/xRvsLYEfQCxamTO/80eSji/Zv5WHX/rvM0Eic85POqt/LQ6/zEdBzh3Qk4sO9E8N1oDvR+C7GWk4ZbHWXmMzRTMx04BBfzQD0UQ03YCznWVe7iqMK9JF1Esm4il7ql+ZKum1IRks6M1+vzfUHvR+WEkj0KPBe2Dq13917ciQiqzIIFkGbC2L7eU/lS0p/10vX5ILg/mjTPDcZybLpaRJRdGNiliOUn2GjBxh1zmgj5pbslN/9c4F/RW8mynejgVq3O5K9ERpkAnNULNVcRdWofzcr1R/XRyEubQ4VuSST8H36bjVB6FkrVpSt/TZ3BfyVaW7K75lOabhYMs6nU2dhU9bCWtDbETYns+v22JQk3M0epDneWOz7ytON9HKcZZzepacUEiMEQQyLjS04r0l3TRNXY2uyFwvkOH7MENmgXrtdw1zcJftDHbprj0UbWqU2/S6G66+1IBMyQGf1MfqpNg0a1rHZX7WcKM7o6ZsCcEV0vx9TvK1GPtjH8GQjIgUxaBi7NGDv1xG+Do+8FABN3YW7J3iiO6oxFFMst177jXVcAeLTmVlePIR3KJjf7vM3PlquaLplZbAXh6rCTafXcP62kCpfDjFQtpIzpxyZbwM2m287VydLKPSvnCWeJS0OvVm5/FWRYHsaJSeXo3VTdbCCzy683aHC8tAM9pudd87it0eFhd6cOhlKITUYIjSwugcN96f51Wzrs7XTmKWehKSuoz63XAXLyk1Buu2WfaBMJPkRYEi1G5dr/ZNEtuja4mSm+6lCN41XixSfrlrFbwSfIqPmhS94nWnbodi5omntVIHDtTKdhl7Y2AcNReRTwUrYGtHmCE9cxgtiFvUBtLTOHQUT9LFMWsaAmex2QrvStblLmznFH61qjCIJZn5njqP+p1Tu3mkhabG1Ct1v+78lon7/ZHC5nfPqlv32O7sY57b6r0KZxG5Z5UeHDoI6OeT5pPzPIVCHyfT72fW6TMEfNv+D9nFQZ2aEwAA"

O descompactarmos e desconverter para o base 64, temos como resultado este XML DPSPronim.xml  que se passarmos tanto pelo Validador de Assinaturas do ITI quanto pelo Validador de Assinaturas da Receita ambos acusam a assinatura como válida.

A rotina de assinatura utilizada é a mesma para os demais documentos fiscais e também para o ambiente nacional e por enquanto apenas o Pronim apresentou o problema.

Se possível, por favor, questione qual é o validador que eles utilizaram e se existe alguma particularidade no processo de assinatura que deve ser utilizado para eles.

[Alcindo de Almeida Neto]

Fazendo uma análise aqui no erro que retorna do Pronim:

 

 

Acho que o problema está no Pronim mesmo. 

Me parece que ocorre o seguinte:
1) O CPF do prestador que está no XML é lido pelo Pronim;
2) O Pronim busca no sistema deles o certificado do CPF que está vinculado no XML;
3) Lê os dados do OID do certificado, pegando as 14 primeiras posições, lendo a data de nascimento e a parte do CPF).

(sendo que o correto acessar o OID do certificado a partir da 9ª posição (deixando a data de nascimento de fora) e ler os próximos 11 caracteres (o CPF).


Vou fazer mais uma tentativa lá com o pessoal do Pronim, demoram, mas devem responder.

[Victor H. Gonzales - Panda]

esse problema só ocorre quando o prestador é pessoa física ou tambem ocorre para pessoa juridica?

[giovani.l.erthal]

Somente quando é pessoa física.

[Victor H. Gonzales - Panda]

1 hora atrás, giovani.l.erthal disse:

Somente quando é pessoa física.

entre em contato com o provedor, e verifica o que ocorre no caso. por favor

[Alcindo de Almeida Neto]

2 horas atrás, Victor H. Gonzales - Panda disse:

entre em contato com o provedor, e verifica o que ocorre no caso. por favor

Consegui abrir um chamado lá na Pronim/Governança Brasil através da Prefeitura de Ijuí-RS. Vamos aguardar.

[giovani.l.erthal]

Em contato com a prefeitura de Esmeralda/RS, fomos informados que o sistema (Pronim) foi atualizado.

A emissão via CPF funcinou.

[Alcindo de Almeida Neto]

Sim, foi resolvido mesmo. Conseguimos avançar essa etapa aqui. Agora com o avanço apareceram mais umas coisas, mas dai abro outro tópico específico.

[valterpatrick]

Obrigado por reportar.

Fechando. Para novas dúvidas, criar um novo tópico.