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?