Heriberto Carvalho

Entendi. Para não travar os clientes, também tive que fazer uma alteração para remover esses caracteres no preenchimento das informações do boleto enquanto não sai a correção.

Acredito que pode ser o mesmo problema que está ocorrendo ao montar as informações no envio dos boletos para registro via API da SICREDI. E no log do svn pudemos verificar que foram realizadas correções em vários componentes que apresentavam esse problema.

Ao passar informações com acentos para o ACBrBoleto e tentar efetuar o registro do boleto pela API da SICREDI em ambiente de homologação e em produção, estou recebendo o erro abaixo: JSON={"timestamp":"2024-03-26T20:37:41.949+0000","error":"BAD_REQUEST","code":"400","message":"400 BAD_REQUEST \"Failed to read HTTP message\"; nested exception is org.springframework.core.codec.DecodingException: JSON decoding error: Invalid UTF-8 middle byte 0x4f; nested exception is com.fasterxml.jackson.databind.JsonMappingException: Invalid UTF-8 middle byte 0x4f\n at [Source: (io.netty.buffer.ByteBufInputStream); line: 1, column: 375] (through reference chain: io.sicredi.ecomm.api.business.dto.request.BoletoHibridoRequest[\"pagador\"]->io.sicredi.ecomm.api.business.dto.request.Pagador[\"cidade\"])"} Neste caso utilizei a cidade de "JOÃO CÂMARA - RN", mas isso ocorre para diversas informações, como as mensagens (por exemplo "NÃO RECEBER APÓS VENCIMENTO"), endereço, etc.. Testei em homologação pelo postman passando os mesmos dados e o erro não ocorre. Segue em anexo o print do registro. Alguém saberia como slucionar essa situação?

Sim, em produção funcionou. Solução meia-boca da SICREDI, se é pra retornar sempre o mesmo qrCode, que fosse pelo menos um válido. O que passei a ter agora foi problemas com caractes inválidos JSON={"timestamp":"2024-03-26T20:20:31.640+0000","error":"BAD_REQUEST","code":"400","message":"400 BAD_REQUEST \"Failed to read HTTP message\"; nested exception is org.springframework.core.codec.DecodingException: JSON decoding error: Invalid UTF-8 middle byte 0x4f; nested exception is com.fasterxml.jackson.databind.JsonMappingException: Invalid UTF-8 middle byte 0x4f\n at [Source: (io.netty.buffer.ByteBufInputStream); line: 1, column: 450] (through reference chain: io.sicredi.ecomm.api.business.dto.request.BoletoHibridoRequest[\"mensagens\"]->java.util.ArrayList[0])"} Quando coloquei por exemplo na mensagem "NÃO RECEBER APÓS VENCIMENTO", sendo que pelo postman isso passa. Vou abrir um novo tópico para este assunto, podemos encerrar este. Obrigado Juliomar.

O problema foi que em homologação o qrCode retornado é incompleto, mesmo fazendo o registro do boleto pelo postman como mostrado na imagem em anexo, o retorno tem conteúdo ao igual ao do ACBr que por sua vez é igual ao que vi em outros posts do forum de 1 ano atrás. Como por exemplo no post abaixo Conseguimos um cliente para testar em produção, o problema não se repetiu.

Segue o boleto gerado. boleto.pdf

Não, testei com BB, NuBank e Caixa, nenhum conseguiu ler o qrCode e Copia e Cola. Segue as configurações do .ini AcbrBoletoDemo.ini

Bom dia a todos. Atualizei os fontes do ACBr para a versão 33042 do svn e estou tendo problemas com o QRCode e Linha Copia e Cola ao registrar os boletos SICREDI pela V2 da API em homologação. Utilizei as configurações conforme o manual, onde o boleto é registrado normalmente, mas o qrcode e a linha copia e cola retornados não estão sendo lidos pelos aplicativos bancários. Segue abaixo o retorno da API JSON={"txid":"445488181811848","qrCode":"00020126930014br.gov.bcb.pix2571pix-qrcode-h.sicredi.com.br/qr/v2/cobv/528520acdd5f4740b63b9b643ca2bcf99999999999999999999BR5903PIX6006Cidade62070503***630441AC\n\n","linhaDigitavel":"74891121150039736789903123451001187340000000050","codigoBarras":"74897937700000099891122224595067890312345109","cooperativa":"6789","posto":"03","nossoNumero":"242003482"} Quando utilizo o site https://pix.nascent.com.br/ para validar o qrcode erro exibido é: Error parsing qrcode string: invalid length @104 Alguém teria uma ideia da causa do problema?

Bom dia a todos, conseguimos resolver o problema mudando para wincrypt. Como foi um problema que ocorreu somente em uma máquina específica, acabamos criando um parâmetro no software para que possamos utilizar openssl ou wincrypt. Obrigado a todos pelos esclerecimentos.

Bom dia. Estamos utilizando o certificado digital via carregamento do banco de dados através de um campo blob, onde realizamos a leitura da seguinte forma: Arquivo := qrCertificados.FieldByName('arquivo').AsAnsiString; E a configuração dele no ACBr está conforme abaixo: ACBr.Configuracoes.Geral.SSLLib := libOpenSSL; ACBr.Configuracoes.Certificados.DadosPFX := Arquivo; ACBr.Configuracoes.Certificados.Senha := 'xxxxx'; O problema é que após atualizarmos a versão do ACBr para a 32.963 do svn, a consulta do status dos serviços da nf-e/nfc-e deixou de funcionar, sendo mostrada a mensagem abaixo: --------------------------- O seguinte erro aconteceu: WebService Consulta Status serviço: - Inativo ou Inoperante tente novamente. Erro ao ler informações do Certificado. Provavelmente a senha está errada Error: 310378599 - error:12800067:DSO support routines::could not load the shared library --------------------------- Se eu utilizar esse mesmo certificado instalando-o na máquina e fazendo a alteração pra ele carregar do windows, a consulta do status funciona normalmente. O que poderia causar esse problema visto que a senha está correta? Seria questão de atualizar DLL´s (quais)? Agradeço antecipadamente.

Resolvido. O problema se deu por não preencher adequadamente a propriedade AcbrBoleto1.Configuracoes.WebService.Ambiente com taHomologacao/taProducao No meu caso estava utilizando as credenciais de produção mas informando o ambiente de homologação.

Boa tarde a todos. Também estou com o mesmo código de erro 403 para registrar o boleto. Conseguiu resolver?

Boa noite. Conseguiram algum progresso na nova API do SICREDI?

Bom dia. Alguém que conseguiu baixar, poderia disponibilizar?

Boa tarde. Estou enfrentando o mesmo problema, encontraram a solução?