Jhoni Conzatti

Boa tarde Italo, você tem razão. Realmente a unit ACBrNFe.Inut.pas não estava com a alteração referente a xJust aplicada. Estava com alterações locais e tentei corrigir o conflito, mas devo ter feito algo errado na hora usar as alterações que vieram do remoto para esta unit. Isto está resolvido agora, muito obrigado

Bom dia, Acabei de atualizar os fontes e percebi que já aplicaram alguns dos ajustes que eu sugeri. Obrigado e parabéns pela rapidez Foi ajustado o bug na função para Ler XML de inutilização de número de NF quando já homologada pelo SEFAZ. No entanto, teve outro problema, referente a justificativa da inutilização que ainda permanece (se for contemplado depois, então pode ignorar):

Olá Daniel, inicialmente eu havia percebido esse problema de acentuação na DANFCe, mas logo vi que foi resolvido e atualizei meus fontes. As contribuições que sugeri acima não incluem o problema de acentuação, tratam-se de outros ajustes que achei necessário na impressão de DANFe e DANFCe com FPDF. Além disso, corrigi um bug na função para Ler XML de inutilização de número de NF quando já homologada pelo SEFAZ (XML de exemplo em anexo no post inicial). No post inicial, há em anexo um arquivo PDF detalhando os ajustes realizados bem como os fontes com os mesmos ajustes aplicados.

Bom dia pessoal, realizei alguns ajustes que julguei necessários para a impressão de DANFe e DANFCe com FPDF, bem como a correção de bugs na leitura de XML de inutilização homologada pelo SEFAZ. Em anexo estão as units modificadas, um xml de inutilização homologada pelo SEFAZ para testes e um documento PDF detalhando cada um dos problemas e respectiva solução. Att, Jhoni Conzatti, Desenvolvedor (Delphi, Go, Java), Blulojas Contribuições para ACBr 2024-07-02.pdf ACBrNFCeDANFeFPDF.pas ACBrNFe.Inut.pas ACBrNFe.RetInut.pas ACBrNFeUtilsFPDF.pas ACBrNFeDANFeFPDF.pas 42240352260100015255009000000847000000847-procInutNFe.xml

Boa tarde @softwareamigo Não estou seguro que seja esse formato que você mencionou, pois se não me engano esse valor "202310593339" era para ser o dia 10/10/2023 no extrato e não o dia 3/10/2023. Vou ver se consigo um arquivo OFX do extrato com mais algumas datas, bem como o extrato em um formato que pode ser facilmente lido por humanos para comparação (vou ver se consigo um PDF). Também li as especificações e os Schemas no site oficial da Financial Data Exchange (About-FDX - OFX Work Group (financialdataexchange.org)), mas não encontrei um formato de data e hora que fosse correspondente. Estou achando que o Santander está com alguma falha ou está usando algum padrão próprio muito específico para as datas nesse arquivo. Sobre o seu algoritmo, percebi que você divide xxxxxx por 3600 e por 24 o que teoricamente lhe dá um número de dias e depois subtrai por um número de horas. Nesse caso, acho que é inconsistente subtrair as três horas de UTC do numero de dias obtido, pois são unidades de medida diferentes (horas e dias). Talvez o mais correto seria dividir xxxxxx por 3600 para obter um numero de horas (hhhh = xxxxxx div 3600), subtrair de hhhh as 3 horas do UTC (uuuu = hhhhh - 3) e por fim dividir esse valor por 24 (dd = uuuu div 24) obtendo em dd o número de dias. No entanto, mesmo assim, a data obtida seria 6/10/2023, que acho que não é a data esperada, se não me engano, a data esperada deveria ser 10/10/2023 (vou confirmar quando possível para ter certeza). Muito obrigado

Olá pessoal, tudo bem com vocês? Estou utilizando o componente ACBrOFX para ler um arquivo OFX do Santander e estou recebendo este erro: "Invalid argument to date encode." O arquivo realmente contém datas em um formato estranho. Por exemplo: <DTSTART>202310593339[-3:GMT] Alguém reconhece esse formato de data? O erro acontece também no exemplo do ACBr para o componente ACBrOFX ao clicar em "Ler Arquivo" depois de selecionar o arquivo OFX que deixo em anexo. Qualquer informação que ajude a solucionar o problema será bem vinda Santander.ofx

Sim, já testei e o problema está resolvido

E-mail enviado! Muito obrigado pela atenção.

Entendi, no entanto estranhamente a PagBank usa esses valores em seu arquivo OFX.

ACBrOFX.pasBom dia pessoal Tive a necessidade de realizar uma pequena alteração no componente que acho que poderá ajudar outras pessoas que tiverem o mesmo problema que eu. Eu tive um problema com o arquivo OFX da PagBank, em que define os tipo do movimento na tag <TRNTYPE> com os valores In e Out para Crédito e Débito respectivamente. Esses valores não estavam tratados no componente ACBrOFX, quando o mesmo realizava a leitura do arquivo. Basicamente adicionei as condições InfLine(sLine) = 'IN' e InfLine(sLine) = 'OUT' nos devidos lugares. Além disso, eliminei a variável local LMemo que não estava sendo usada e apresentava um hint durante a compilação. As diferenças nos fontes podem ser observadas na imagem abaixo: ACBrOFX.pas