Daniel Simoes

Vários países tem impressora fiscal... Até nossos vizinhos argentinos tem... Más concordo que nenhuma deve ser tão complicada como a nossa... O novo ECF 09/09 é coisa de louco de complicado... Eu acho o ECF ótimo para a automação comercial.. Rápido e confiável... O problema é a aberração fiscal do PAF-ECF... O SAT será revolucionário, más pode trazer uma nova era de sonegação fiscal... Enquanto não houver cadeia para quem sonega, sempre seremos pressionados para fazer caixa 2 nos nossos sistemas... Cada um sabe o risco que quer correr, o duro é a concorrência desleal, que conta com a impunidade...

Bom, parece que nesse caso o ACBrECF está se comportando corretamente...

http://acbr.sourceforge.net/ACBrMonitor.htm Veja o Objeto: ECF.VendeItem

Alguém precisa avisar isso pros caras que escrevem o PAF-ECF... eles devem achar que o rodapé do Cupom tem linhas ilimitadas

Você não forneceu quase nenhuma informação... Qual Delphi ? Qual S.O. ? O que você está tentando fazer ? Já testou com o Demo do ACBr ? (Não existe ECF 400th fi)

Converse com o Contador do seu cliente e solicite uma explicação básica sobre o funcionamento do ICMS.... Não há como fazer um programa de Venda / Faturamento sem conhecer tributação de ICMS

Leia mais sobre ECF, parece que você está fazendo um uso equivocado de Operações não fiscais... Não há como remover Programação... apenas em Intervenção Técnica... e o limite de programação é de 16 a 30 itens...

O Cielo Premia é apenas um sistema de gestão de fidelidade... o Estabelecimento que determina as condições e os prêmios...

A homologação TEF precisará ser revista para o SAT... Já existe impressão de comprovante TEF em impressora comum... para alguns regimes especiais... Talvez as homologadoras possam dar mais informações Vale lembrar que no caso da NFCe o método de contingência é o próprio ECF...

Leia com atenção as mudanças relativas ao Cielo Premia em ACBrTEFD-Change-Log.txt

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

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