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?

Boa tarde pessoal. Uma dúvida, como faço para gerar o arquivo remessa do banco Sicredi , com as informações do boleto híbrido no Registro detalhe (Tipo 1) campo 006 - 006 preenchido com 'H' e no Registro Híbrido (tipo conforme manual da SICREDI. Quais configurações do ACBrBoleto devo utilizar para gerar o arquivo remessa adequadamente para que o banco retorne com as informações do QRCode/Url para impressão do boleto Híbrido? sicredi-hibridoManual CNAB 400 2.4.pdf

Ao informar no título do Bradesco (cnab400) o campo DataBaixa = 30 dias após o vencimento em conjunto com o campo Instrucao1 = '18' (Decurso de Prazo), o arquivo remessa não está sendo gerado corretamente nas posições 157 a 158, pois está saindo com 00 onde deveria sair o código 18 da instrução de decurso de prazo. Olhei na unit ACBrBoleto.pas a função TACBrBancoClass.InstrucoesProtesto que gera a linha do arquivo remessa e percebi que ele está aguardando o código da instrução no campo Instrucao2. Outros bancos utilizam essa metodologia ou realmente está invertida a linha Result := PadLeft(trim(Instrucao2),2,'0') + IntToStrZero(DaysBetween(DataBaixa,Vencimento),2) que deveria olhar para Instrucao1? OBS.: O arquivo remessa sai com as informações corretas nas posições 157 a 158 quando informo no campo Instrucao2 o código da instrução 18 - Decurso de prazo.

Bom dia pessoal, estou com uma dúvida. Seguinte: fiz algumas simulações usando um mesmo serial POS no simulador (http://simuladorposceara.azurewebsites.net/Index). Exemplo: Faço uma venda usando POS com internet, informo a forma de pagamento com POS, seleciono o serial do POS cadastrado no sistema e envio a forma de pagamento (método EnviarPagamento). Na minha simulação, eu não registro o pagamento no simulador POS (apesar de já visualizar no site do simulador que o pagamento foi registrado normalmente) e disparo o método VerificarStatusValidador, como ele não encontra o pagamento efetivado eu abro uma tela para informação manual dos dados da operação realizada no POS, registro esses dados no AC e concluo a venda normalmente. Pergunta: Quando eu utilizo esse procedimento usando um mesmo serial POS, vejo que os pagamentos ficam pendentes no site do simulador. No ambiente de produção, como essas operações não "baixadas" se comportam junto as autorizadoras?

Ok Juliomar, vamos aguardar. Obrigado pela atenção.

Bom dia. Juliomar, estou usando o CliDTEF / Linx.

Juliomar, acho não me expressei direito. Ainda estou fazendo o teste na aplicação de exemplo do ACBR, não coloquei nada na minha aplicação. Apenas adicionei um botão e alguns edits na tela para chamar diretamente o método do cancelamento ACBrTEFD1.CNC(edRede.Text, edNSU.Text, edData.Date , edValor.AsFloat); passando os parâmetros, sem chamar a tela do ADM através do ACBrTEFD1.ADM(TACBrTEFDTipo(cbxGP1.ItemIndex )); Através da tela do ADM eu consigo cancelar normalmente, mas chamando o método CNC não (uso o mesmo componente ACBrTEFD1 nas duas rotinas).

Boa tarde Juliomar. Sim, inclusive é o mesmo componente que chamo no ADM e no método CNC. Utilizo como base o fonte do exemplo do ACBR para chamar o menu do ADM: procedure TForm1.bADMClick(Sender: TObject); var Finalizou: boolean; begin if estadoSimuladoEcf <> tpsLivre then raise Exception.Create('Estado do Simulador ECF deve ser Livre'); Finalizou := ACBrTEFD1.ADM(TACBrTEFDTipo(cbxGP1.ItemIndex )); MemoCupomTEF.Lines.Add('Administrativo TEF'); end; Para tentar cancelar usando o método CNC: procedure TForm1.Button1Click(Sender: TObject); var Cancelou: boolean; begin cancelou := ACBrTEFD1.CNC(edRede.Text, edNSU.Text, edData.Date , edValor.AsFloat); if Cancelou then ShowMessage('Cancelado com sucesso') else ShowMessage('Não foi cancelado com sucesso'); end;

Estou fazendo os testes para homologação do TEF Dedicado Linx utilizando a DLL DPOSDRV O que ocorre é que estou tentando realizar o cancelamento de um cartão depois da transação finalizada. Para isso utilizo o método ACBrTEFD1.CNC(rede, nsu, datahora, valor), passo os parâmetros normalmente, só que sempre mostra a mensagem 'Transação não efetuada.' Gostaria de um auxílio para identificar o que posso estar fazendo de errado, pois na aplicação de testes do ACBR consigo cancelar sem problemas usando o menu ADM.

Boa tarde Alexandre. Alterei como foi indicado por você mas estou recebendo somente o teCCe como resposta, mesmo já tendo enviado a confirmação ou Desconhecimento das NF geradas para o CNPJ que estou testando. Meu código ficou assim: case ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Items.resEvento.tpEvento of teCCe: qrRetornoSitConf.Value := 'CCe'; teManifDestConfirmacao: qrRetornoSitConf.Value := 'Confirmação'; teManifDestCiencia: qrRetornoSitConf.Value := 'Ciência'; teManifDestDesconhecimento: qrRetornoSitConf.Value := 'Desconhecimento'; teManifDestOperNaoRealizada: qrRetornoSitConf.Value := 'Operação não realizada'; end;

Boa tarde a todos. Até o dia 31/05/2017, para consultar as NFe emitidas contra a empresa, utilizávamos o comando ACBrNFe1.ConsultaNFeDest(CNPJ, IndicadorNFe, IndicadorEmissor, UltNSu) para realizar a consulta, onde de acordo com os parâmetros indicadorNFe e IndicadorEmissor o resultado da consulta poderia ser filtrado. Com o retorno processado, era utilizado o comando ACBrNFe1.WebServices.ConsNFeDest.retConsNFeDest.ret.Items.resNFe.cSitConf para pegar o status das NFe carregadas. Com a mudança do Web Service a partir do dia 01/06/2017, passamos a utilizar o ACBrNFe1.DistribuicaoDFePorUltNSU(uf, CNPJ, UltNSu), só que neste caso, não podemos mais filtrar o retorno da consulta por indicadores como feito anteriormente e também não há a informação sobre a situação da Manifestação. Temos somente: ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Items.resNFe.cSitNFe para trazer se a NFe foi Autorizada, Denegada, Cancelada ou Encerrada. Não temos o status para indicar se a NFe foi manifestada como Confirmada, Desconhecida, Operação Não Realizada, Ciência. Alguém saberia como obter essas informações no novo Webservice?