Allan Wolski

Eu tenho um serviço de impressão de DF-e, onde manipulo propriedades como Title e EmbeddedFonts por exemplo. As quais não podem ser alteradas através das opções existentes de geração de PDF. var PDFExport: TfrxPDFExport; begin FStream.Clear; PDFExport := TfrxPDFExport.Create(Self); with PDFExport do begin ShowDialog := False; ShowProgress := False; Stream := FStream; EmbeddedFonts := FIncluirFonte; Title := FormatarTituloPDF; end; Result := Report.Export(PDFExport); end;

Boa tarde, @Victor H. Gonzales - Panda Poderia manter o método PreparedReport como público por favor? Pois esta alteração quebrou a compilação da minha aplicação. Esse método é público em todas as demais impressões com FastReport. Obrigado.

Atualizado e funcionando. Obrigado!

Bom dia, @Juliomar Marchetti Seguem algumas correções para avaliação. - Ajustes de indentação; - Remoção de campos não utilizados; - Adicionado propriedade PreparedReport; - Corrigido exibição do QRCode; - Corrigido erros de conversão de string para float; - Corrigido access violation ao atribuir os dados do Consumidor; Extrato SAT.fr3 ACBrSATExtratoFR.pas

Bom dia! Com certeza, com a contribuição do @Bruno Silva ficará bastante simples de implementarmos a impressão resumida e de cancelamento.

Talvez algum usuário com mais experiência em Fast Report possa nos ajudar. Mas acredito que para manter essa linha do ModifyPage teremos que modificar todos os FR3 para ajustar a largura das bandas para a largura da página.

Bom dia, @Juliomar Marchetti Era exatamente esta linha que causava o problema de desalinhamento na impressão. frxReport.PreviewPages.ModifyPage

A alteração motivada por este tópico foi revertida na rev. 20096, portanto o problema de desalinhamento voltará acontecer.

Acredito que precisamos encontrar uma solução para ambas as situações, sem precisar corrigir todos os .fr3. Eu não utilizo o DACTE_Retrato.fr3 do repositório, por isso não percebi este problema que você mencionou.

O problema que você estava vendo @BigWings ocorre com notas com mais de uma duplicata utilizando a correção enviada pelo @fefevilela. Eu já havia testado isso alterando diretamente no fr3, inclusive apliquei também essa correção nos eventos que enviei no tópico abaixo. A correção enviada pelo @Juliomar Marchetti funciona, inclusive eu já havia testado e enviado para o @EMBarbosa para avaliação.

Boa tarde, @Juliana Tamizou Segue arquivos de exemplo após as alterações. Também estou enviando uma correção no evento de MDF-e. Obrigado. Evento CT-e.pdf Evento MDF-e.pdf Evento NF-e.pdf EVENTOS_MDFE.fr3

Boa tarde! Fiz algumas melhorias e padronizei os layouts de eventos de NF-e, CT-e e MDF-e em FastReport. Estou enviando os arquivos em anexo para contribuir com o projeto. Atenciosamente, Allan DACTE_EVENTOS.fr3 EVENTOS_MDFE.fr3 EVENTOS.fr3

Resolvi o problema chamando a função SetDllDirectory, passando o local da DLL da minha aplicação para ser adicionado na lista de diretórios verificados pela função LoadLibrary. De acordo com a documentação da Microsoft, informar o caminho completo da DLL na chamada da LoadLibrary já seria o suficiente, porém isso não funcionou pra mim. https://docs.microsoft.com/pt-br/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibrarya https://docs.microsoft.com/pt-br/windows/win32/api/winbase/nf-winbase-setdlldirectorya

Sim, conforme descrevi acima eu testei com as DLLs da pasta ACBr\DLLs\LibXml2. Eu coloco as DLLs junto com a DLL da minha aplicação. Neste caso não tenho um EXE.

Bom dia, @Daniel Simoes Após atualizar os fontes para a rev. 19047 do SVN, comecei a ter problemas com o carregamento da libxml2.dll em uma aplicação ISAPI. Falha ao assinar o Envio de Evento: Erro ao inicializar a Biblioteca LibXML2 Aparentemente o problema ocorre porque o sistema tenta localizar a DLL no diretório do executável, que neste caso é C:\Windows\System32\inetsrv\w3wp.exe ou C:\Windows\SysWOW64\inetsrv\w3wp.exe, dependendo da versão do Windows. Tentei configurar a variável global LibXml2Path com o diretório da DLL, mas isso só funcionou em meu ambiente de testes com a DLL em anexo. Usando a DLL mais recente da pasta ACBr\DLLs\LibXml2 o erro voltava acontecer. LoadLibrary(PChar(LibXml2Path + Value)); Nesses casos o retorno da função LoadLib é sempre zero. Só consegui fazer funcionar em meu ambiente de produção revertendo os fontes para a revisão anterior. Alguma dica de como solucionar este problema? Obrigado. libxml2.dll

Muito obrigado, @Rafael Dias

Rafael, a alteração é para possibilitar o envio de requisições tipo GET com autenticação SSL/TLS.

Bom dia! Gostaria de saber se houve algum progresso na análise deste pedido. Pergunto pois aguardamos o envio para o repositório para então disponibilizar para os demais desenvolvedores. Obrigado.

Bom dia, Juliana! Obrigado pelo retorno, ficamos no aguardo.

Boa tarde, Everton! Sim, os CT-es OS são retornados juntamente com os CT-es no método DistribuicaoDFePorUltNSU. Você deve verificar se o schema do documento retornado é igual a schprocCTeOS. Atenciosamente, Allan

Boa tarde! Realizamos uma pequena alteração para possibilitar o envio de requisições GET com WinHTTP. A motivação desta alteração é acessar endereços HTTPS com autenticação SSL/TLS. Segue units alteradas para análise. Obrigado. ACBrWinHTTPReqResp.pas ACBrWinReqRespClass.pas

Solucionado nas revisões 17433 e 17435 pelo @Daniel Simoes Obrigado.

Bom dia, Ítalo! Posso informar a Chave de Acesso para consulta no Portal da Sefaz: 35190600882430000699550020005284271242415069 O problema ocorre na chamada da função HexToAscii após a limpeza e replace dos caracteres na função ReverterFiltroTextoXML.

Obrigado, @Juliana Tamizou Ficamos no aguardo.

A função HexToAscii da unit pcnAuxiliar apresenta um erro de conversão ao tentar converter uma string inválida. '$ 2' is not a valid integer value Este erro ocorre na impressão de notas com caracteres inválidos na tag infCpl. Segue possível correção para análise. pcnAuxiliar.pas