Daniel Simoes

Por favor leia as nstruções em ACBrTEFD-Change-Log.txt

Enviei uma possível correção para o SVN:

Tente com o Demo do ACBrECF... O ECFTeste... provavelmente seu sistema está fazendo carga estática de alguma DLL de fabricante, e ela está segurando a porta COM

Qual a mensagem de erro quando o arquivo inicial é copiado ? O que você edita no arquivo .INI para que ele funcione ? Qual método do ACBrECF você está usando para gerar a CAT52 ?

A mensagem diz.. "O arquivo já está sendo usado por outro processo"... Ou seja... a porta COM já está ocupada, provavelmente outro programa está mantendo a porta Aberta...

Preciso analisar os fontes... volto a postar...

Não creio que o problema seja a velocidade da porta... embora aumentar a velocidade seja ótimo pois reduz muito o tempo de captura... Primeiro vamos ter certeza de que a DLL está instalada corretamente... Para isso, recorrendo ao site e suporte do Fabricante, baixe as DLLs mais novas, siga as instruções de instalação do fabricante... Baixe no site do fabricante o "Exemplo em Delphi", e tente rodar o método que captura a CAT52 deste Programa exemplo... se nem assim funcionar... é necessário contactar o suporte do fabricante... - A DLL da Bematech depende de várias outras DLLs.. no meu DJPDV eu mantenho na mesma pasta do meu .EXE os arquivos: BemaFI32.dll BemaMFD.dll BemaMFD2.dll sign_bema.dll BemaMFD2_MP4000THFI.dll - A DLL pode não conseguir salvar arquivos nas pastas do sistema ou Raiz (certifique-se de que o Path para o arquivo é válido e todos podem gravar nele) - No Windows 64 o diretório de instalação para DLLs 32 bits é o: c:\Windows\SysWOW64

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

Eu optei por suportar apenas as MFDs

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

Você pode encontrar aqui: viewtopic.php?f=10&t=1418

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