TiagoTecchio

Boa tarde, Realizei alguns ajustes na classe TNFSeR_SigISS no arquivo SigISS.LerXml, para conseguir recarregar corretamente um RPS. Estavam faltando alguns campos, bem como tratamento de conversão. Obrigado. SigISS.LerXml.pas

Caí no mesmo problema que você: a API do Sicredi é bem inferior em termos de funcionalidade que a do BB, por exemplo. Na consulta de boletos abertos também tivemos que implementar uma pesquisa "um a um", o que considero inviável num cenário onde você tem milhares de boletos. A melhor solução neste caso é controlar o retorno por arquivo, como mencionou o Júlio Cavalcanti. Enfim, resta esperar a equipe do banco implementar novos endpoints - eu já enviei alguns e-mails pressionando eles, mas vamos aguardar sentados.

Olá, creio que agora deu certo: limpei o cache, aceitei os cookies e esperei o timer do popup fechar. Grato.

Olá BigWings. Testei agora, limpei o cache do browser, aceitei os cookies mas mesmo assim o banner é exibido a cada novo request. Uso o Firefox.

Boa tarde colegas, Este não é propriamente um assunto relacionado a algum problema, mas porque este banner fica aparecendo a cada página que abro no forum? Já tentei clicar nele, aguardar o timer fechar, e mesmo assim ele insiste em continuar aparecendo. Preciso ativar o adblocker? Obrigado.

Boa tarde, Você poderia tentar implementar e subir o ajuste. Afinal, este é um projeto open source. Abraço.

Juliomar, O problema que o colega refere-se é porque o endpoint do Sicredi não acata um intervalo de dias. É passado somente um dia. Conforme a função TBoletoW_Sicredi_APIV2.DefinirParametros na unit ACBrBoletoW_Sicredi_APIV2, é utilizado somente a propriedade DataInicio. A solução para ele (assim como a que adotei) é fazer um loop pelos dias e acionando a API diversas vezes.

Descobri a origem do problema: Tenho que setar a propriedade ACBrBoleto.Configuracoes.WebService.UseCertificateHTTP para true Obrigado.

Boa tarde, Após atualização mais recente dos fontes do Acbr, estou passando por problemas na autenticação da API do banco Itaú. Verifiquei que ocorreram mudanças no arquivo ACBrBoletoWS.Rest.OAuth, sendo que a versão que eu tinha (agosto/2024) funcionava perfeitamente. Eu testo com o exec do sistema antes da atualização de segunda, funciona corretamente, com a compilação de hoje não vai. Anexei o log do processo. A API está reclamando que o certificado não está sendo enviado junto a requisição. Tenho que modificar alguma propriedade? Obrigado. log-itau.txt

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.