Roversi

Eu fiz um teste, trocando o componente TACBrNFeDANFCeFortes pelo TACBrNFCeDANFeFPDF, a fonte parece normalizada, porém o layout do relatório fica bem diferente da versão do Fortes. Usando o TACBrNFCeDANFeFPDF, o layout permanece o mesmo entre as versões LCL e Daemon Acredito que possa ser algum comportamento do Fortes quando o projeto não há parte visual

Nada ainda. Nessa imagem é como está sendo impresso a NFC-e utilizando o componente Fortes com escala padrão no modo Daemom. Reapare que as letras parecem se sobrepor. Nessa outra imagem, eu ajusto a escala para menos, 60, ainda utilizando o modo Daemon. Repare que ele de fato ajusta a escala, mas a fonte continua sobrepondo Da mesma forma, se eu aumento a escala (120, ainda com o modo Daemon), ele aplica corretamente, porem as fontes continua sobrepondo Agora utilizando o mesmo codebase, porem compilando com o projeto LCL, reparece como as fontes ficam corretas

Eu já habia tentado ajustar as propriedades : AlterarEscalaPadrao := True; NovaEscala := CalculateScale; // Aqui tentei diversos valores, maior ou menor que a escala padrão 96 Eu percebi o valor de Screen.PixelsPerInch no trecho a baixo, são diferentes em um projeto LCL para um projeto Daemon procedure TACBrNFeDANFCeFortes.ImprimirInterno(const Cancelado: Boolean; const DanfeResumido: Boolean; const AFiltro: TACBrNFeDANFCeFiltro; const AStream: TStream); var frACBrNFeDANFCeFortesFr: TACBrNFeDANFCeFortesFr; RLLayout: TRLReport; RLFiltro: TRLCustomSaveFilter; begin frACBrNFeDANFCeFortesFr := TACBrNFeDANFCeFortesFr.Create(Self); try with frACBrNFeDANFCeFortesFr do begin if AlterarEscalaPadrao then begin frACBrNFeDANFCeFortesFr.Scaled := False; frACBrNFeDANFCeFortesFr.ScaleBy(NovaEscala , Screen.PixelsPerInch); end; no LCL retorna 96 no Daemon retorna 72

Inicialmente suspeitei que o problema estivesse relacionado ao acesso às fontes do Windows. Para validar isso, configurei o serviço para rodar com um usuário específico, garantindo permissões adequadas. Porém o comportamento permaneceu o mesmo. Em seguida, fiz testes isolados fora do Fortes Report. Criei um TBitmap e renderizei textos utilizando diferentes fontes (Arial, Lucida Console, etc.), tamanhos e estilos (incluindo negrito). Nesses testes, o serviço conseguiu carregar e aplicar corretamente as fontes, sem problemas aparentes. No entanto, identifiquei que a escala de renderização é diferente entre os ambientes. Ao usar o seguinte código para obter o TextWidth, ele retorna tamanhos diferentes de texto da versão LCL para a versão Daemon. LBMP.Canvas.TextWidth Versão LCL: 93 Serviço (Daemon): 65 Acredito que isso impacta diretamente no Fortes ao montar o relatório

Estou desenvolvendo um serviço fiscal com lazarus. Eu tenho duas versões do mesmo projeto. A versão LCL (visual) que utilizo em desenvolvimento, facilitando o debug. E a versão Daemon, que é utilizado em produção e instalada como serviço do Windows. Sei que serviço do windows tem algumas limitações por não ter o contexto do usuário (eu não deleguei o usuário em LOGON do serviço). Porém estou com alguns problemas ao gerar o arquivo PDF da NFC-e. Na versão LCL, ele gera o arquivo normalmente, com as fontes tudo certo. Porém na versão Daemon, as fontes fica desporporcional. No print a seguir, a imagem da esquerda foi gerada pelo serviço, a da direita pela versão LCL. Estava utilizando o componente Fortes para a geração do PDF. Eu tentei trocar pelo componente TACBrNFCeDANFeFPDF. Aparentemente ajustatando a propriedade LarguraBobina desse novo componente, ele gera com fontes aceitavel. Porém o layout fica diferente do Fortes. Alguém ja passou por algo semelhante? Sei que o problema não está no ACBr em si. Mas existe algo que consiga configurar para corrigir o carregamento das fontes?

Obrigado pelo retorno. Mas cometi um erro, a impressora não estava no padrão ESCBEMA, alterei e ficou show! Desculpe, não verifiquei isso antes.

Boa tarde, estou fazendo um teste com o demo, na impressora MP4200th (Bematech), todos os comandos funcionam perfeitamente, o problema esta na tag </beep> que ao ser ativada, soa um barulho bem alto e por um longo tempo! Eu usei o UserSoftware do fabricante, e percebi que tem como ajustar o timer do beep, é possivel ajustar isso pelo acbr?

Deu certo! Na verdade eu comi bronha, eu tava passando o grupo exporta, mas ao invés de passar as tags [...]Saida[...] eu passei [...]Embarque[...]

Bom dia, tive esse problema no demo da NF-e, só consegui compilar deletando o .res No meu caso, como queria apenas validar alguns dados pelo demo, resolveu!

Um usuário meu está emitindo uma NF-e de venda de refeição para um cliente do exterior. Estamos passando os dados do destinatário no conforme, porem retorna Rejeição (355): Informar o local de saída do Pais no caso da exportação; Comparei com o XML gerado do antigo sistema do usuário e não contas o grupo <exporta>, que caso adicionado manualmente, a nota válida normal. Tentei adicionar pelo ACBr, porém não está criando, alguém sabe o que há de errado? Segue XML... CONFERENCIA DE XML 000000017.xml

RESOLVIDO! Atualizei as DLL da pasta DLLs\XMLSec

Nada! O problema ta na hora de validar, ele retornar esse erro na tag qrCode.

Pior que estão... Eu acabei de remover todo o ACBr, exclui o diretório, fiz o checkout e instalei novamente... Abri o NFeDemo, utilizei os schemas da própria pasta do ACBr, mas retorna o mesmo erro. Quando seleciono o veqr100 ele me retorna versão ('100') não é mais aceita, porem quando mudo para veqr200 me da esse erro. Esse é o XML gerado apos reinstalar o ACBr xml_acbr_demo.xml

Sim, acabei de testar no demo do acbr, da o mesmo problema Esse XML foi gerado pelo demo 35180909209500000102650020000000421000000584-nfe.xml

Bom dia, to com o seguinte erro: Eu removi o ACBr do Delphi, instalei a versão mais atual, peguei os esquemas atualizados mas mesmo assim nada. Testei em homologação no estado de SP e testei também em homologação e produção no AC, ambos retornam o mesmo erro. Ta configurado com a versão 4.00 e o qrCode 2.00