Pesquisar na Comunidade

Resumo Na criação de recorrência do Pix Automático (POST /rec), o campo loc é serializado a partir de TACBrPIXRecSolicitadaBase.loc, que está declarado como Integer. Quando o PSP retorna um id de location maior que 2.147.483.647 (Int32), o valor é truncado para 32 bits e enviado negativo, fazendo o PSP recusar a requisição. O id de location do Itaú tem 19 dígitos (ex.: 7587166705779689739), então o problema é 100% reproduzível nesse PSP. Evidência Resposta do POST /locrec (id da location gerada pelo PSP): {"id":7587166705779689739,"location":"api.itau/rec/694b07eb-...","criacao":"2026-07-15T19:09:32.992Z","idRec":null} Corpo do POST /rec montado pelo ACBr logo em seguida: {"politicaRetentativa":"PERMITE_3R_7D","vinculo":{...},"calendario":{...},"loc":-1649719029} O loc foi de 7587166705779689739 para -1649719029, que é exatamente o truncamento para inteiro de 32 bits com sinal (os 32 bits baixos de 7587166705779689739 = -1649719029). O PSP então responde: HTTP/1.1 401 Unauthorized {"title":"Acesso Negado","status":401,"detail":"Não autorizado. Verifique se os parâmetros de acesso estão válidos..."} Como replicar Usar um PSP cujo /locrec retorne um id de location maior que Int32 (o Itaú sempre retorna, 19 dígitos). Chamar CriarLocation (epLocRec) e em seguida CriarRecorrencia (epRec) com RecorrenciaSolicitada.loc := LocationGerada.id. Observar no log (NivelLog alto) o Req.Body do /rec: o loc sai negativo. Causa Em ACBrPIXSchemasRec.pas, classe TACBrPIXRecSolicitadaBase: private fLoc: Integer; // <-- trunca ... property loc: Integer read fLoc write fLoc; // <-- trunca Há uma inconsistência interna: no ACBrPIXSchemasLocation.pas o campo id da location já é Int64 (leitura correta), mas o loc da recorrência (escrita) é Integer. Ou seja, o valor chega inteiro na leitura e é cortado ao ser atribuído/serializado na escrita. Correção sugerida Em ACBrPIXSchemasRec.pas, TACBrPIXRecSolicitadaBase: private fLoc: Int64; // era Integer ... property loc: Int64 read fLoc write fLoc; // era Integer Resultado após a correção Mesmo cenário, com o campo já como Int64 — loc vai íntegro (batendo com o id retornado no /locrec {"id":1570237648687511524,"location":"api.itau/rec/ea35652d-...","idRec":null} ... Req.Body: {"politicaRetentativa":"PERMITE_3R_7D","valor":{...},"vinculo":{...},"calendario":{...},"loc":1570237648687511524} A mudança é retrocompatível (Int64 comporta todo Integer) e alinha o tipo da escrita com o da leitura (TACBrPIXLocation.id).

Bom dia, ao gerar o boleto a resposta da API C6 (homolog e prod) devolve o nosso número: { "amount": 5, "due_date": "2025-06-05", "originator_id": "0000zzzzzzzzz", "our_number": "0244141180", "billing_scheme": "15", "billing_type": "3", "id": "01JWGSzzzzzzzzzzzzz", "bar_code": "336961103000000050000zzzzzzzzzzzzzzzzz", "digitable_line": "33690.zzzzz zzzzzzz zzzzzzz 6 zzzzzz000000500" } porém o retorno no ACBr não está sendo preenchido corretamente em FACBrBoleto.ListaRetornoWeb[idReg].DadosRet.TituloRet.FNossoNumero Paleativamente estamos reconsultando os boletos gerados para poder atualizar essa informação, porém isso não bom pois dentro do mesmo minuto pode estourar o limite de requests na API C6. Alguém tem alguma outra sugestão ou caminho que possa ser utilizado para obter o 'nosso número (our_number)' sem precisar reconsultar o boleto? At.te,

Bom dia, identifiquei um ponto para correção no arquivo de boleto do banco C6 ACBrBoletoW_C6.pas: Atual: if (ATitulo.ValorDesconto > 0) or (ATitulo.ValorDesconto > 0) or (ATitulo.ValorDesconto > 0) then Sugestão: if (ATitulo.ValorDesconto > 0) or (ATitulo.ValorDesconto2 > 0) or (ATitulo.ValorDesconto3 > 0) then

Na impressão utilizando o Componente ACBrCTeDACTeRLR, quando a situação tributária "90-ICMS devido à UF de origem da prestação quando diferente da UF do emitente." não tem espaço suficiente no campo para caber este texto, como no exemplo. Com isso, fiz a alteração no Componente ACBrCTeDACTeRLRRetrato, diminuindo as colunas (Base Calculo, Valor ICMS e % RED BC CALC), e também diminuindo a fonte texto da Situação Tributária, obtendo esse resultado.. Para fazer esse alteração, substitui os arquivos do componente ACBrCTeDACTeRLRetrato_New.rar para a pasta Componentes\ACBr\Fontes\ACBrDFe\ACBrCTe\DACTE\Fortes E Então copila o componente em Componentes\ACBr\Pacotes\Delphi\ACBrDFe\ACBrCTe\DACTE\Fortes\ACBr_CTeDacteRL.dproj Botão direito em cima do ACBr_CTeDacteRL.bpl ,compile e pronto!..

Boa tarde a todos! Um cliente está fazendo importação de dados pelo layout Sefaz "atualizado" para NFe4. As informações estão assim no arquivo: Exemplo: N07|1|51|3|0|447.83|18.00|80.61|33.33|26.87|53.74|||| O ACBR está importando outras notas da versão 4 sem problemas, mas não consegue autorizar com CST51. O retorno é que o valor calculado para vICMSOp (80,61) está zerado no arquivo enviado para a Sefaz. Estava olhando e vi que o LerTXT não faz a leitura dos campos CST51... por algum motivo, este trecho está comentado no código. Para voltar a funcionar basta incluir de volta? Tem uma ordem certa?