Daniel Simoes

Seus problema estão relacionados ao uso do Lazarus... pois nenhum desses packages é do ACBr... A solução indicada nesse mesmo post, acima, deveria resolver o seu problema... Se não o fizer, o ideal é procurar ajuda em uma lista de Lazarus, como por exemplo a Lazarus-BR

Pode ser que a impressora esteja com a alguma configuração de tamanho de etiqueta na memória... Experimente fazer um reset na mesma (no manual do equipamento explica como)

Se vc não informar a versão de Lazarus e FPC, que está usando... e qual é exatamente o problema, ou a mensagem de erro, fica difícil ajudar...

NAO.. mas vc pode recorrer ao LOG do SVN, e baixar uma revisão da sua escolha... Ou ainda recorrer aos seus Backups internos... O assunto foi amplamente discutido aqui... todos tiveram chance de opinar... Porque vc não distribui a DLL junto com o novo EXE em um ZIP ??? fácil, fácil, e o problema não ocorre mais

A orientação de coordenadas dos equipamentos EPL2 é inversa a dos equipamentos PPLA... Ou seja, não há como manter o mesmo código de etiqueta para os 2 modelos... Atualize os seus fontes pelo SVN e estude o Demo... O exemplo foi revisto para demonstrar a PPLA e EPL2

Finalmente consegui um tempo para analisar os fontes sugeridos e a melhor maneira de adiciona-los ao projeto... Aproveitei que apareceu uma Zebra aqui na empresa e consegui testar... Apliquei as seguintes modificações nos fontes sugeridos - Adicionei suporte a unidades de medida em Milímetros e Polegadas - Removi a necessidade de informar o tamanho da etiqueta no método Imprimir... pois li nos manuais que todos equipamentos compatíveis com EPL2, são dotados de sensores que detectam o "GAP" da etiqueta. - Modifiquei o método de impressão de caixa para ficar compatível com a assinatura atual No processo... acabei fazendo uma ampla reforma no ACBrETQ e em suas classes... as modificações estão detalhadas no aqruivo: ACBrSerial-change-log.txt

Notei que o "buraco é bem mais em baixo"... Foi necessário criar todo um tratamento para o Cupom NaoFiscal dentro ACBrTEFD... Estou comitando em breve... espero não ter "quebrado" algo nos fontes...

Aparentemente suas modificações estão corretas... Eu ainda não implementei o Recebimento não fiscal na minha aplicação... e por isso nunca precisei... Vou implementar as modificações sugeridas nos fontes do TEFD

Não é permitido o Relat.Gerencial, pois ele não gera entrada de Pagamento no ECF...

Não há como fazer isso dessa maneira... (DadoReducaoZ) Mas talvez usando a recuperação da MFD vc consiga...

O método "NaoFiscalCompleto" resolve a parada... A principal vantagem dele é que ele tenta abstrair as diferenças entre os ECFs no tratamento de Comprovantes Não Fiscais

Isso tb me incomodou.. Eu modifiquei o meu "engine" de TDI para respeitar os MaxConstrains do Form... assim ele não estica tanto Segue um ScreenShot atualizado:

O ACBrECF não depende de nenhuma DLL para operar... ele usa comunicação direta com a serial... O que me referia é conflitos de outro programa usando a DLL e bloqueando a porta seria... Isso ocorrerá por exemplo, se vc faz carga estática da DLL... Por favor teste primeiro com o ECFTeste... assim vc saberá se o problema não é nos seus fontes... Estude com atenção os fontes do demo.

Uso diariamente emulador de portas seriais em conjunto com vários emuladores de ECF, como por exemplo: Epson, Sweda, Bematech e FiscNET... e não tenho esse tipo de problema... por isso que desconfio que provavelmente os erros são algo no seu S.O.... ou ainda algum conflito do ACBrECF com alguma DLL de fabricantes de ECF

Em qual momento do Log acima, ocorreu o aviso de Pouco Papel ? Os erros de TimeOut podem indicar um problema no seu emulador de portas seriais... Não há problema desse tipo com o componente... centenas de desenvolvedores o utilizam com sucesso em diversos ECFs diferentes... Tente com um ECF real e verifique DICA: Primeiro estude e teste detalhadamente o exemplo do ACBrECF... o demo ECFTeste da pasta Exemplos

Nada de especial... criei um método próprio dentro do PDV... e devo sempre usa-lo ao invez de chamar os comandos diretos do ACBrECF... Exemplo, para leituraX temos: {-----------------------------------------------------------------------------} procedure TFrVenda.aLeituraXExecute(Sender: TObject); begin if errECFConfig in PDVErros then exit ; UIMemoProduto := '' ; { Grava o Documento no SQLite } Documento.Novo( StrToInt( ACBrECF1.NumCOO )+1, 'LX', Now, 'Leitura X' ); ACBrTEFD1.BloquearMouseTeclado( True ) ; try try ACBrECF1.LeituraX ; Documento.Finaliza( now ); dml.GravaAuditoria('PDV_ECF_LX','Leitura X') ; except { Se não imprimiu no ECF, Cancele tudo } Documento.Exclui ; raise ; end ; finally ACBrTEFD1.BloquearMouseTeclado( False ) ; end ; { Descarrega registros do SQLite para o FireBird... se houver conexão válida } dml.GravarArquivos ; end; [/code]

Apliquei uma possível correção que deve funcionar em todos os modelos... por favor verifique nos modelos que você possui... (já está no SVN)

E sempre haverá a possibilidade do ECF ser ligado em outro programa... (numa bancada de testes por exemplo)... e a aplicação ficará sem registrar esses documentos impressos... O governo nos "exige" algo quase impossível de cumprir... O que fiz foi centralizar todas as chamadas de métodos do ACBrECF em métodos internos/próprios, onde eu gravo adequadamente os dados...

Veja o Demo do novo componente ACBrEAD... Ele gera MD5, o EAD, a chave Privada/Publica., gera o XML para o eECFc... só não faz chover

Giuliano, Quais são os passos para a reprodução, usando o ECFTeste ? Notei que aparentemente já existe alguns IFs dentro do método TACBrECFFiscNET.FechaCupom para tratar essa situação...

Acredito que esse problema já foi corrigido... Hoje o ACBrECFBematech já é capaz de carregar alíquotas com zero (desde que não seja a última) Mas como foi dito aqui... Alíquota 0 é um erro... e em alguns casos pode levar o ECF a computar erroneamente os impostos

Pouco papel não é um erro... é um aviso... Falta de Papel sim, seria um erro

Sua sugestão está correta... este método está se comportando de forma diferente das demais classes.. Corrigi para: if DataHora = 0 then { Aparentemente a DataHora é obrigatória na Daruma } DataHora := TACBrECF(fpOwner).DataHora ;[/code] pois assim a solicitação de DataHora fica registrada no LOG

Apenas relembrando... É necessário re-instalar o Package ACBrSerial para que esses novos eventos apareçam no ObjectInspector

Pelo que notei na página: http://www.desenvolvedoresdaruma.com.br ... lphi_7.htm Todas as assinaturas de métodos mudaram... adeus compatibilidade...