Daniel Simoes

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...

A biblioteca synapse (usada pelo ACBrNFe) faz isso, usando vários plugins de bibliotecas de conexão segura (ex: OpenSSL) Veja um exemplo em: http://www.ararat.cz/synapse/doku.php/p ... 3samplessl

Oi Dirceu, Muito bacana essa sua iniciativa... Atualmente o ACBr é compatível apenas com ObjectPascal (Delphi / Lazarus)... Ha algum tempo atrás criou-se o JACBr... http://sourceforge.net/projects/jacbr/ O que seria o mais indicado para esses fontes... mas não sei como está o andamento do projeto... Também houvi dizer que o pessoal da T2TI estava traduzindo o ACBr para Java... (você poderia somar forças) http://www.t2ti.com/ Há ainda a possibilidade de criarmos uma área Java no ACBr atual... mas seria necessário um outro administrador (o que exige bastante dedicação), pois eu não conheço nada de Java

Carlos, Obrigado pela oferta... mas um componente deste não é o escopo do Projeto ACBr (Automação Comercial)... Outro problema para integra-lo com o ACBr é que um componente desses dificilmente será independente de IDE ou S.O. (o que quebra uma das premissas do ACBr)

Qual é a exata msg de erro ? A DLL e o ACBrECF não podem abrir a mesma porta ao mesmo tempo... vc precisa desativar o ACBrECF primeiro... veja os fontes de ACBrECFBematech.pas no método ArquivoMFD_DLL

Vc tm pode recorrer ao LOG de alterações de qualquer arquivo versionado, e comparar a versão atual com uma anterior... Use o botão direito do mouse sobre o arquivo... Tortoise SVN -> Show Log