TiagoTecchio

https://www.projetoacbr.com.br/forum/topic/79801-api-boleto-itaú-movimento/?do=findComment&comment=516728&_rid=676

Também passei por esta situação, mas o banco até o momento não tem consulta (endpoint) por data de movimento. Tentei fazer algo semelhante ao que já tenho do BB, mas sem sucesso. Contatei o suporte deles e o endpoint está em desenvolvimento. Você só conseguirá consultar boleto por boleto ou por uma data de registro (ou seja, para o meu caso que tenho cliente que registra milhares de boletos não serve pra nada). Basta só aguardar. Espero ter ajudado.

Daniel, Segue unit ajustada. Fiz um teste em produção agora e não tive rejeições. ACBrBoletoW_Itau_API.pas

Bom dia Daniel, Obrigado pelo retorno. No print que você postou, o código refere-se a unit ACBrBoletoW_Itau, mas estou utilizando o registro via api, logo a montagem do JSON ocorre na unit ACBrBoletoW_Itau_API. Anexei um JSON que foi gerado agora com os fontes atualizados. Veja que não existe o campo data_limite_pagamento embora eu tenha preenchido a propriedade equivalente. registro.json

Boa tarde, Verificando a unit ACBrBoletoW_Itau_API percebi que a propriedade DataLimitePagto da classe TACBrBoleto não é utilizada para o registro inicial de boletos. Ela só é considerada para alterações posteriores. Porém a documentação da API contempla este campo de forma opcional (anexei a imagem) no payload inicial. Seria possível a implementação desta propriedade? Já utilizo a API do Banco do Brasil (unit ACBrBoletoW_BancoBrasil_API) e neste caso a propriedade DataLimitePagto é utilizada no método RequisicaoJson. Atualmente a única maneira de se informar uma data limite de pagamento no Itaú seria usando a propriedade Instrucao1 - combinando código de instrução e dias, algo como 8060 - (8-Baixar/Devolver após 60 dias).

Victor, vou tratar como resolvida esta questão mas não entendi a sua colocação. Obrigado pela ajuda.

Entendi. Desculpe a ignorância, então pelo ACBr.inc abaixo eu estou usando a LibXML2 ?

Victor, Como mencionei, no meu PC funciona OK, já debuguei até as entranhas do ACBr sem sucesso. Mas consegui achar o problema: DLLs. Adicionei os arquivos libexslt.dll, libiconv.dll, libxml2.dll, libxslt.dll e msvcr120.dll junto ao exec no servidor do cliente e magicamente funcionou. Só não entendi o motivo: estas DLLs são obrigatórias a partir de agora? Porque não eram até dias atrás.

Boa tarde. Estou enfrentando um problema estranho num cliente, estou completamente no escuro. Ao emitir uma NFC-e o componente AcbrNfe levanta uma exceção sem mensagem. Fiz um rastreio usando o MadExcept mas não me ajudou muito. O mais bizarro é que no meu computador, em desenvolvimento, funciona perfeitamente. Verificando os logs que o componente gera, os XMLs estão OK, assinados, o retorno veio OK da Sefaz informando a autorização. O problema parece na interpretação do retorno dentro do componente. Parece que algo mudou nas units da NFe entre os dias 13/05 (dia da minha última atualização do SVN) e 12/06, pois ao usar um exec anterior a 12/06 funciona perfeitamente. Minha config de assinatura é : acbrNFCE.Configuracoes.Geral.SSLCryptLib := ACBrDFeSSL.cryWinCrypt; acbrNFCE.Configuracoes.Geral.SSLHttpLib := ACBrDFeSSL.httpWinHttp; acbrNFCE.Configuracoes.Geral.SSLLib := ACBrDFeSSL.libWinCrypt; acbrNFCE.Configuracoes.Geral.SSLXmlSignLib := ACBrDFeSSL.xsMsXml; acbrNFCE.SSL.SSLType := blcksock.LT_TLSv1_2; Log: callstack crc : $594e6622, $fdd1279b, $fdd1279b exception number : 1 exception class : EACBrDFeException exception message : Unknown. main thread ($19b0): 016ce523 +08b prERP2.exe ACBrDFe 636 +10 TACBrDFe.GerarException 016d7397 +01b prERP2.exe ACBrDFeWebService 540 +1 TDFeWebService.GerarException 0179887d +08d prERP2.exe ACBrNFeWebServices 4029 +9 TWebServices.Envia 017a04e6 +0fa prERP2.exe ACBrNFe 731 +14 TACBrNFe.Enviar 017a03ba +042 prERP2.exe ACBrNFe 710 +1 TACBrNFe.Enviar 01bf9b5a +202 prERP2.exe ADMNfe 8418 +49 TDMNfe.EnviaNFCeLocal 02aea5f3 +5a7 prERP2.exe NfeMonitor 2365 +86 TFNfeMonitor.ProcessaAutoriza 02ae0137 +02b prERP2.exe NfeMonitor 578 +5 TFNfeMonitor.btGerarEnviarClick 005d1213 +06f prERP2.exe Vcl.Controls TControl.Click 005f49b6 +01e prERP2.exe Vcl.StdCtrls TCustomButton.Click 005f54bc +010 prERP2.exe Vcl.StdCtrls TCustomButton.CNCommand

Bom dia, Por que você não utiliza o MadExcept ou EurekaLog para saber onde exatamente está levantando a exceção? Ajuda bastante, pelo menos você não fica no escuro com uma mensagem de AV genérica.

Você chegou a verificar com o banco se o mesmo disponibiliza a documentação da API ? Se sim, você poderia ajudar na implementação, afinal este é um projeto open source.

OK, grato pelas informações. Usamos o Delphi XE6, que não tinha o FR como opção. Neste caso usamos uma versão do FR (a 4) adquirida uns anos antes.

Existem as opções, mas tentei desativar, ativar, enfim, combinei todas elas e não funciona. É um bug da versão e que foi resolvido nas versões posteriores.

Bom dia Victor, Grato pela resposta. Era isso mesmo que eu queria saber. Então a versão mais atualizado do FastReport resolve o problema que estou tendo com versão 4. Vamos providenciar a atualização durante o ano. Obrigado e um bom dia.

Bom dia, Para tentar exemplificar o problema, gerei dois PDFs. Tamanho da página é A4: 1 - gerado pela exportação padrão do FastReport (256 kbytes) 2 - outro gerado pelo SynPDF (4 kbytes) Anexei também o arquivo fp3, referente ao relatório em si. São apenas dois memos com um texto justificado, o primeiro com tags HTML para negritar, e outro sem. fast.fp3 gerado-pelo-fastreport.pdf gerado-pelo-synpdf.pdf

Olá Renato, Já tentei todas estas opções, combinações entre elas e infelizmente o PDF continua inchado.

Olá Alexandre, Grato pela dica. Já tinha verificado a implementação o FPDF que o Daniel criou, é bem interessante. Mas converter os nossos relatórios (ou pelo menos estes contratos) para uma nova engine está fora do radar, pois é muita coisa. Usamos o FastReport extensivamente, gosto bastante dele devido a flexibilidade e velocidade, só este problema do tamanho do PDF que está me incomodando.

Boa tarde colegas, Estou usando o FastReport 4 para gerar os relatórios no meu software e a exportação para PDF gera arquivos gigantes quando utilizo o recurso AllowHTMLTags do objeto TfrxMemoView. Acontece que preciso destacar algumas palavras em negrito pois trata-se de um contrato com múltiplas páginas. Uma vez gerado o PDF, percebe-se que o FastReport criou uma imagem da página contendo o texto formatado (não é possível selecionar o texto, por exemplo). Tentei utilizar a classe SynPDF (Synopse PDF Engine) como alternativa: ela até funciona, o PDF fica minúsculo e a qualidade é excelente porém a borda direita dos textos fica truncada (imagem anexada). Tentei entrar em contato com o desenvolvedor para ver uma possível solução mas fui solenemente ignorado A pergunta: as versões mais novas do FastReport resolvem este problema do tamanho?

Bom dia Victor, OK, sem problemas. Eu suspeitei que haveria algum efeito colateral. Vou adaptar para passar o sequencial com havia feito inicialmente. Grato pela atenção.

Boa tarde Alexandre, Anexei o arquivo ajustado. Conforme a regra da montagem do nosso número via API (https://apoio.developers.bb.com.br/referency/post/5f4fb7f5b71fb5001268ca44) ACBrBoletoW_BancoBrasil_API.pas

Bom dia, Gostaria de sugerir um ajuste no registro de boletos via API no Banco do Brasil. Nos prints anexados (método RequisicaoJson na unit ACBrBoletoW_BancoBrasil_API) o nosso número passado para o body JSON está sendo remontado pela função MontarCampoNossoNumero. Utilizo o AcbrBoleto somente realizar o registro e o meu sistema já montou o nosso número de 17 posições previamente, mas o componente está reformatando, o que me causou alguns transtornos. Para contornar tive que fazer um copy ao passar o nosso número para o componente TAcbrTitulo. var doc: TACBrTitulo; begin doc := acbrGerador.CriarTituloNaLista doc.NossoNumero := Copy(qrRec.FieldByName('NOSSONRO').AsString, 8, 10) A minha sugestão é caso a propriedade NossoNumero esteja preenchida, o componente utilize este valor para alimentar o campo JSON numeroTituloCliente ao invés de tentar remontar o nosso número utilizando o convênio. Seria possível? Ou causaria efeitos indesejados?

Bom dia, Grato pela dica. Fiz alguns testes usando o seu exemplo e consegui tratar/contornar o redirect do Cloudflare. Precisei ajustar esta parte: If sURLRedirect <> '' Then HTTP.HTTPMethod('POST', sURLRedirect); Para esta (recriando o objeto e adicionando os headers/body novamente): urlRedirect := Trim(objHttp.Headers.Values['Location']); if urlRedirect <> EMPTY_STR then begin objHttp.Free; objHttp := THTTPSend.Create; FH.StrParaStream(synHttp.Document, vs); objHttp.MimeType := 'application/json'; for tmp in LHeaders do objHttp.Headers.Add(tmp); Result := objHttp.HTTPMethod(pMetodo, urlRedirect); end;

Segue um exemplo de como utilizo. Neste caso eu criei uma classe para abstrair o Synapse, mas você pode utilizar diretamente o objeto THTTPSend. No código abaixo existem algumas referências a funções auxiliares para converter Streams e caracteres Unicode, mas acho que dá para entender o contexto geral. Uses: httpsend, synautil, synacode Para usar: Enviar('POST', 'https://endereco.da.api/v1/endpoint', '{"x": "2333232", "x1": "12", "dt": "xxxxx}', retorno); O seu header de requisição teria que ser inserido em uma lista do objeto LHeaders. function Enviar(const pMetodo, pURL, pDadosEnvio: string; var pRetorno: TRetRequisicao): Boolean; var synHttp: THTTPSend; mstr: TMemoryStream; stmResp, stmDados: TStringStream; vs: RawByteString; tmp: string; begin synHttp := THTTPSend.Create; mstr := TMemoryStream.Create; try vs := UTF8Encode(PDadosEnvio); FH.StrParaStream(synHttp.Document, vs); synHttp.MimeType := 'application/json'; //'application/x-www-form-urlencoded'; for tmp in LHeaders do synHttp.Headers.Add(tmp); Result := synHttp.HTTPMethod(pMetodo, pURL); if Result then begin mstr.CopyFrom(synHttp.Document, 0); pRetorno.Code := inttostr(synHttp.ResultCode); pRetorno.Response := FH.AjustaChrEspecial(FH.MemoryStreamParaString(mstr), True); end else begin pRetorno.Code := inttostr(synHttp.ResultCode); pRetorno.Response := FH.SeStrVazia(synHttp.Sock.LastErrorDesc, synHttp.ResultString); end; finally synHttp.Free; mstr.Free; end; end;

Eu utilizo o XE6 com o Synapse e atende perfeitamente 99% das situações. Tentou utilizar esta classe? É até mais simples que o Indy (o ACBr usa extensivamente o synapse).

Bom dia. Parece que o Indy do XE7 está desatualizado - e pelo que li as versões a partir de 2018 corrigiram diversos problemas em relação ao SSL (infelizmente não consegui mais achar o link do StackOverflow onde havia lido sobre isso). Desta forma a versão Alexandria está OK.