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.

Situação 2: vCBS No XML que a ACBR manda para a Elotech, o grupo <gCBS> está sendo enviado desta forma: <gCBS> <vCBS>0.00</vCBS> </gCBS> Porém, pelo que vimos no XSD da Elotech, a estrutura do grupo <gCBS> precisaria ir da seguinte forma: <gCBS> <gCBSCredPres>   <vCBS>0.00</vCBS> </gCBSCredPres> </gCBS> Solução: Adicionar o subgrupo <gCBSCredPres> no XML que vai para a Elotech. Situação 3: <CidadeNome> Pelo que observamos no XSD da Elotech, verificado através do link: http://shad.elotech.com.br/schemas/iss/nfse_v2_03.xsd O campo <CidadeNome>Pitanga</CidadeNome> que fica dentro do grupo: <Tomador> <Endereco>, não existe no XSD. Solução: remover essa tag <CidadeNome> do XML que enviado pela ACBR para a Elotech. TODAS ESSAS 3 SITUAÇÕES ACIMA FORAM VALIDADAS ATRAVÉS DO XSD da Elotech e disponibilizada por ela mesma pelo link acima.

Olá, pelo que observamos em um teste feito sexta-feira (22/05/2026) a tag <CodigoPais> ainda não foi adicionada no XML que vai da ACBR para a Elotech. Poderiam fazer essa verificação por gentileza? Notamos também mais alguns ajustes que serão necessários no XML, são 3 situações e vamos adicioná-las uma a uma, separadamente. Situação 1: Está sendo enviado no XML que vai da ACBR para a Elotech o campo <ValorIss>0.33</ValorIss>. Ocorre que o sistema da Elotech em Pitanga – PR, o valor do ISS é calculado pelo sistema da prefeitura, e se enviamos o valor do ISS no XML, retorna o seguinte erro vindo do sistema da Elotech: Solução: Não enviar valor nessa TAG, deixar vazio, pois o valor é calculado posteriormente pelo sistema da Elotech.

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

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.

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.

Joia, vamos aguardar o novo build da ACBR API. Consegue verificar, por gentiliza, quando está prevista a geração de uma nova build da API?

{"provedor":"padrao","ambiente":"producao","referencia":"20000002","infDPS":{"dhEmi":"2026-04-16T10:41:19.7985964-03:00","dCompet":"2026-04-16T00:00:00-03:00","prest":{"CNPJ":"02773166000176","regTrib":{"regEspTrib":4}},"toma":{"orgaoPublico":false,"CPF":"09646279147","xNome":"DHARA ANDRADE SIMÕES DE ALMEIDA","end":{"endNac":{"cMun":"1705508","CEP":"77760000"},"xLgr":"Joel Camilo da Silva","tpLgr":"Avenida","nro":"1399","xBairro":"Centro"}},"serv":{"cServ":{"cTribNac":"210101","cTribMun":"001","CNAE":"6912500","xDescServ":"Pedido de certidão nº 32639: Inteiro teor (Texto) (1) ; \r\nEmolumentos R$ 31,53; Funcivil R$ 16,16; ISSQN R$ 1,58; Selo R$ 2,80; Taxa Judiciária R$ 12,74; TOTAL R$ 64,81","cNBS":"113040000","cSitTrib":"0"}},"valores":{"vServPrest":{"vReceb":0.0,"vServ":31.53},"trib":{"tribMun":{"tribISSQN":1,"pAliq":5.0,"vBC":31.53,"vISSQN":1.58},"tribFed":{"piscofins":{"CST":"08","vBCPisCofins":0.0,"pAliqPis":0.0,"pAliqCofins":0.0,"vPis":0.0,"vCofins":0.0,"tpRetPisCofins":2},"vRetCP":0.0,"vRetIRRF":0.0,"vRetCSLL":0.0}}}}}

Olá, Ao emitir uma NFS-e via ACBr API para municípios que utilizam o provedor Megasoft, o XML gerado pela API apresenta erro de validação contra o Schema (XSD). A API não está incluindo a tag <Exigibilidade> dentro do grupo <Servico>, causando a rejeição E160. Erro retornado: "Invalid content was found starting with element : '{NumeroNbs}'. One of : '{Exigibilidade}' is expected." O XSD do provedor exige que a tag <Exigibilidade> esteja posicionada entre <CodigoTributacaoMunicipio> e <NumeroNbs>. No XML gerado pela API (conforme ), a tag é saltada, resultando em uma estrutura inválida. Exemplo do modo que está sendo gerado o XML atualmente (com erro): <Servico> <Valores>...</Valores> <IssRetido>2</IssRetido> <CodigoMunicipio>1705508</CodigoMunicipio> <CodigoTributacaoMunicipio>001</CodigoTributacaoMunicipio> <NumeroNbs>113040000</NumeroNbs> <Discriminacao>...</Discriminacao> </Servico> XML com a estrutura correta: <Servico> <Valores> <ValorServicos>31.53</ValorServicos> <Aliquota>5.0000</Aliquota> </Valores> <IssRetido>2</IssRetido> <CodigoMunicipio>1705508</CodigoMunicipio> <CodigoTributacaoMunicipio>001</CodigoTributacaoMunicipio> <Exigibilidade>1</Exigibilidade> <NumeroNbs>113040000</NumeroNbs> <Discriminacao>......</Discriminacao> </Servico> Poderiam verificar por gentileza essa problema?

O problema foi resolvido com a nova build da ACBRAPI. Porém apareceu uma nova situação que reportarei em outro tópico. Podemos fechar esse tópico aqui, caso resolvido.

Acabamos de testar, não deu certo.

Opa Daniel, acredito que esteja desatualizado também o change log, pelo que eu vi ali a última data tarefas está de 27/09/2025.

Gostaria de dar uma sugestão: Diferentemente da ACBRLIB/ACBRNFSeX que pode ser atualizada e compilada de forma independente pelas empresas integradoras, a ACBrAPI precisa ser necessariamente gerada por vocês e as empresas integradoras (nós) não possuem autonomia para qualquer ajuste. Sinto falta de dois pontos muito importantes: 1) De ter um tópico fixo "Data estimada de geração de nova build da ACBRAPI", e nesse tópico colocar uma estimativa (mesmo que rudimentar), "Nova build entre 17/04/2026 e 18/04/2026", pq atualmente não temos nenhuma noção de quando as builds podem ser geradas, e por conseguinte não consigamos passar orientações ou mesmo contornar situações mais difíceis com os clientes; 2) Ter um tópico com o histórico das alterações e ajustes de cada build. Atualmente a única informação que temos é a desse link: https://dev.acbr.api.br/docs/changelog onde a última informação é do dia 04/02/2026, então todos os pequenos ajustes que são feitos na API acabamos não sabendo. Obrigado!

Olá, bom dia. Existe alguma previsão de quando seria gerado um novo build da ACBrAPI?

Estamos tentando gerar a NFSE pela ACBR API para o município de Colinas - TO, provedor MEGASOFT, e está dando exatamente o mesmo erro reportado nesse tópico: No XML gerado pela ACBR API o nome da tag está "tsNumerNfse" e acredito que o correto seria "tsNumeroNfse", estaria faltando a letra "o". Me parece que foi corrigido na ACBRNFSeX, mas na ACBR API continua o problema. Poderiam verificar por gentileza?

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 )?

A emissão da NFSE deu certo para Salto do Jacuí - RS. Podemos encerrar o tópico.

Ótimo, vamos aguardar. Espero que logo fique disponível. Obrigado.

Olá Italo, O estranho é que o "cPais" só existe dentro do grupo "endExt" (endereço no exterior do tomador), e dai se eu informo o valor para "cPais" é exigido os demais campos "cEndPost", "xCidade" e "xEstProvReg". Ao meu ver, se o tomador reside no Brasil, a ACBR API deveria ou ignorar a exigência de preenchimento do "cPais" ou informar "BR" ou "1058" no XML que iria para o sistema da Elotech (caso seja um campo obrigatório).

Olá Italo, Eu não cheguei a testar o envio da NFSE pela ACBR API para a cidade de SALTO DO JACUÍ - RS, eu fiz uma consulta pela API das cidades atendidas e não retornou SALTO DO JACUÍ como atendida pela ACBR API, por essa razão fiz a solicitação aqui. Queria aproveitar o tema e perguntar o seguinte: Se o município adotou o Portal Nacional de Emissão da NFSE (que é o caso de SALTO DO JACUÍ - RS), todos esse municípios que adotaram o Portal Nacional estão contemplados já na ACBR API ou é necessário vocês fazerem a inclusão individual daqueles que não estão na lista de cidades atendidas pela API?

Gostaria de solicitar a inclusão do município de Salto do Jacuí - RS na ACBR API. O município de Salto de Jacuí - RS já é contemplado na ACBRNFSeX e utiliza o PADRÃO NACIONAL (Portal Nacional de Emissão) para a emissão da NFSE. Muito obrigado!

Estamos com problema para gerar a NFSE na cidade de Pitanga - PR, que utiliza o sistema da Elotech. O erro ocorre ao tentar processar o JSON ainda no ambiente da ACBR API. 1871 - Element '{http://shad.elotech.com.br/schemas/iss/nfse_v2_03.xsd}Cep': This element is not expected. Expected is ( {http://shad.elotech.com.br/schemas/iss/nfse_v2_03.xsd}CodigoPais ). X800 - Erro de Validação: --> 1871 - Element '{http://shad.elotech.com.br/schemas/iss/nfse_v2_03.xsd}Cep': This element is not expected. Expected is ( {http://shad.elotech.com.br/schemas/iss/nfse_v2_03.xsd}CodigoPais ). Vi que o mesmo problema da Elotech na cidade de Ponta Grossa - PR foi resolvido na pendência ACBR-9127 e atualizado no SVN, mas testei há pouco aqui na ACBR API e ainda continua o erro. Poderiam verificar por gentileza?

Estamos com o mesmo problema para a cidade de Pitanga-PR, que usa o sistema da Elotech. Porém esse nosso problema é na ACBR API, esse ajuste ACBR-9127 vai contemplar também na ACBR API? Caso seja necessário posso criar um tópico no fórum específico lá da ACBR API.

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.

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.