Daniel Simoes

Tiago, Não há uma receita pronta... há várias maneiras de implementar o TEF... leia com atenção o manual e roteiro de integração... Estude em detalhes o Demo do ACBrTEFD e seus fontes... Veja os métodos: FinalizarCupom e ImprimirTransacoesPendentes

Que tipo de teste o homologador fez que falhou ? Pois o período de desbloqueio é mínimo e o cache de teclado é limpo antes do desbloqueio...

Alguns motivos que me levaram a não usar a DLL do fabricante no inicio do ACBrECF... - Incompatibilidade com Linux - Lentidão em algumas DLLs - Perda de controle da aplicação em algumas DLLs - Dificuldade de configuração de Porta e outros parâmetros (algumas DLLs usam .INI, outras .XML outras o Registry) - Incompatibilidade entre os comandos (similares) de algumas DLLs - DLL hell (as instruções de instalação da DLL nem sempre são claras e variam de acordo com o S.O.) A proposta de abolir os tipos complexos aumenta a compatibilidade, mas torna o uso do FrameWork mais difícil para as linguagens de alto nível... e quebraria todo o projeto atual.... A ideia é ter algo semelhante ao componente ACBrECF (do Pascal) nas linguagens que suportem o FrameWork ... Talvez você possa iniciar um novo projeto, usando apenas pchar como parâmetros e as DLLs dos Fabricantes... entretanto observe que atualmente o ACBrFrameWork suporta vários outros componentes do ACBr... ou seja, não é apenas usado para ECF...

Você está falando de Epson ou Bematech ?? A classe do ACBr, o protocolo e Sw.Básico do ECFs é completamente diferente... O que funciona para um pode não ser o mesmo para o outro...

Sua rotina de geração de SPED e Sintegra deve ter como origem o banco de dados... caso contrário você não passará na certificação PAF-ECF... O fisco também exige a entrega dos arquivos mesmo que o ECF tenha sido queimado ou roubado, por exemplo...

AutoEfetuarPagamento se tornou incompatível com a chegada do Cielo Premia, e NUNCA deve ser usado... É mantido apenas por motivos de compatibilidade...

Não dá pra comprender o seu problema... Você está usando ECF Daruma ou Bematech ? o código é completamente diferente... Provavelmente o problema é no seu código... "access violation" ocorre quando você tenta acessar um Objeto que não existe ou que já foi destruido

Realmente parece ser um problema do protocolo STX... Os fontes estão corretos... veja o manual de comunicação direta com STX em: https://acbr.svn.sourceforge.net/svnroo ... ols/Sweda/ (página 47) Verifique com o fabricante o que ocorre... porque o ECF se comporta de um jeito com STX e de outro com o ESC .

Carlos, Obrigado pela correção... enviado para o SVN...

Na verdade ele consulta o ECF sobre o número do cupom atual ou último cupom... não há persistência dessa informação no ACBrECF, isso é controlado pelo próprio ECF

Parece que o compilador não conseguiu se decidir pela versão que usa Inteiro ou String... Tente assim: FS := TFileStream.Create( String( ArqTXT ), IfThen( AppendIfExists and FileExists(String(ArqTXT)), Integer(fmOpenReadWrite), Integer(fmCreate)) or fmShareDenyWrite );[/code]

Isso só acontece na IDE... Desabilite na sua IDE: "Stop on Delphi Exception"

Apenas a Daruma retorna o Total do Item, logo após o comando de Venda de Item... Veja o Demo da Daruma em Projetos...

Código de Barras ou Imagens ? Se for Imagem é melhor usar o driver do Windows (através de FastReport, Rave ou algo parecido) Se for código de barras, você precisa ver no manual do equipamento qual a sequencia de comandos ESC/POS2

persistindo o problema favor anexar o LOG gerado pelo ACBrECF

Vc precisa saber qual é a configuração da Balança (no manual tem os valores Defaults) E ajustar em ACBrBAL.Device

Provavelmente ele está achando alguma BPL antiga... Observe que se este erro estivesse nos fontes do SVN todos usuários estariam com problemas

Faltou você reinstalar o package ACBrTEFD... (isso é necessário toda vez que uma nova propriedade "published", ou seja, que aparece no Object Instapector é introduzida)

Atualize corretamente todos os seus fontes do ACBr... (se necessário apague da sua pasta os fontes em conflito no SVN (ícone vermelho) )

Exato... na Daruma não há este retorno no DadosUltimaReducaoZ... No entanto você pode intuir o NumCOOInicial... ele seria igual o COO da Ultima ReducaoZ valida + 1 É mais eficiente usar: ACBrECF1.DadosReducaoZ instantes antes de comandar a Z

Só podemos nos basear nas informações retornadas pelo ECF... É necessário o LOG gerado pelo ACBrECF, (aba ECF)

Comece copiando aqui o LOG do trecho de comandos ...

Veja o que o ECF retorna: (Página 24) 140 1164 N Informações da última RZ Data do Movimento 8 Grande Total 18 Grande Total Inicial 18 Descontos ICMS 14 Descontos ISS 14 Cancelamentos ICMS 14 Cancelamentos ISS 14 Acréscimos ICMS 14 Acréscimos ISS 14 Tributados ICMS/ISS 224 F1 ICMS 14 F2 ICMS 14 I1 ICMS 14 I2 ICMS 14 N1 ICMS 14 N2 ICMS 14 F1 ISS 14 F2 ISS 14 I1 ISS 14 I2 ISS 14 N1 ISS 14 N2 ISS 14 Totalizadores NF 280 Descontos NF 14 Cancelamentos NF 14 Acréscimos NF 14 Alíquotas 80 CRO 4 CRZ 4 CRZ Restante 4 COO 6 GNF 6 CCF 6 CVC 6 GRG 6 CFD 6 CBP 6 NFC 4 CMV 4 CFC 4 CNC 4 CBC 4 NCN 4 CDC 4 CON 80 CER 80[/code]

Sim, mas nesse caso, o ACBrECF usará o ACBrECF.InfoRodapeCupom.MD5 "tomáticamente"

E emulador da MP3000 tem problemas... tanto é que foi removido da área de downloads... No Log você tem muitas falhas de Envio, o que não é normal... experimente outro Virtualizador de Portas Seriais, como por exemplo o com0com