Daniel Simoes

Acho que seja algum problema no Cliente... Não notei mais ninguém reclamando de lentidão a um bom tempo... Analise o LOG do ACBrECF, os tempos de resposta do componente estão descritos lá...

Li (não lembro aonde) que a MikeySoft está encerrando o suporte a CAPICOM, e mantendo apenas a API de criptografia em .NET... Pode ser que essas DLL realmente não sejam compatíveis com Windows 8

Bom saber disso... Acho que não acusa erro não... mas não deve passar direto por aquela maravilhosa tela de seleção das redes do G.P. Você pode baixar o G.P. padrão em: http://www.softwareexpress.com.br/ArqCli/TefDiscado/Simulado/tefdial.htm http://www.sevenpdv.com.br/new/conteudo/downloads.htm

Você está usando o ACBrRFD associado ao ACBrECF ? Se SIM, o ACBrRFD faz a criação deste arquivo... Você pode remover a associação do ACBrRFD com o ACBrECF, ou configura-lo para IgnorarECFsComMFD

Pode ser que o Índice que seja programando não seja o que você está enviando... alias: StrToIntDef('1', 0) é igual a 1 sempre... Use AchaRGDescricao.. RelGer := ACBrECF1.AchaRGDescricao(NomeRel); if RelGer <> nil then Indice := StrToIntDef( RelGer.Indice, 0) ; Estude o exemplo a cima e outros no código fonte do Projeto ECFTeste.dpr

É claro que o relatório gerencial já deve existir... Você pode programar um novo com: ACBrECF1.ProgramaRelatoriosGerenciais( cDescricao ); Se você não especificar um Índice o ACBrECF tentará com índice default, que pode variar de acordo com o modelo.. repare que na FiscNET ele usou índice 1

Pode ser que esteja faltando copiar as DLLs do OpenSSL para a pasta da aplicação... Vc pode encontra-las em: https://acbr.svn.sourceforge.net/svnroot/acbr/trunk/DLLs/OpenSSL/

Não um comando para detectar o protocolo... o ECF escolherá o protocolo de acordo com a primeira sequencia de instruções que será enviada... o TimeOut sempre ocorre na inicialização ? em qual comando ? Tem um LOG para analise ?

Não tem como... não se trata de algo que precise ou possa ser corrigido... Veja: o Chip da USB do ECF, é na maioria das vezes, um emulador de USB-Serial... quando você desliga o ECF, ele perde a alimentação, e morre, é como se você tivesse removido o cabo USB do PC... No caso de um adaptador USB-Serial, a alimentação do dispositivo é feita pela USB do PC, por isso ele não morre quando o ECF for desligado... Faça o mesmo teste usando a DLL do fabricante

Se observamos como o fisco agiu no passado... o PAF-ECF não será extinto mas sim termos uma super homologação exigindo: PAF-ECF-SAT-NFCe... Até hoje o SINTEGRA é obrigatório, sendo que todas as informações dele estão no SPED, NFe, NFP, etc... É difícil o fisco "desmontar" o aparato que foi montado para o PAF-ECF... ( O que ele irá fazer com todos esses pobres funcionários ? )

Você não confirmou se está ou não usando USB... então continuo adivinhando... Simples... NAO use a porta USB no dia da homologação... (Se vc só possui portas USB no PC, use um adaptador USB <-> Serial)

Obrigado por reportar a correção... Penso que o componente poderia cuidar dos espaços desnecessários (Trim), ou na atribuição (Set) da propriedade, ou quando for usá-la em algum arquivo ou Rotina

Parece que a resposta está no seu próprio post: "NSU: 150001 ou NSU não foi gerado"

O modelo ecfNaoFiscal NUNCA deve ser usado em produção ou clientes finais... Você pode estar cometendo crime de sonegação fiscal...

A propriedade DadosReducaoZClass só conterá informações após você chamar os métodos "DadosReducaoZ" e "DadosUltimaReducaoZ"... ECF.CarregaAliquotas não irá alimentar as informações de DadosReducaoZClass e sim de ECF.Aliquotas

Na verdade apenas a Epson suporta isso... Estou tentando implementar na Bematech... No entanto, o ACBrECF usa métodos básicos da DLL apenas para enviar o comando e ler a resposta... ele mesmo cuida da montagem dos pacotes no protocolo do fabricante... Ou seja.. não é utilizado os métodos de comandos da DLL do fabricante, como Fabricante_AbreCupom, Fabricante_LeituraX, etc... Utilizamos apenas um método específico (e geralmente não documentado) que permite o envio e leitura usando o canal da USB, pela DLL

Invés de usar um cabo, você poderia usar um emulador de portas serias "null modem"... assim como o com0com

Você está usando porta USB ? Se SIM, este é o problema... quando vc desliga o ECF a porta serial emulada, que é gerada pelo driver USB do ECF, simplesmente some... A mensagem de erro indica que a porta que vc está tentando abrir não existe...

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

Helio, Primeiro, Vamos verificar se DLL está OK... Use o exemplo em Delphi do Fabricante, e copie a DLL nova para a pasta desta aplicação... Rode o exemplo e tente efetuar a leitura... Se funcionar usando o exemplo em Delphi, temos grandes chances de que funcione no ACBrMonitor..

Uma outra coisa é ser tentada, se a impressora estiver com a valocidade muito alta, ou usando USB emulada em COM é diminuir o Buffer de Entrada e Saida

Por favor abra um novo tópico para um novo problema...

Humm.. resta saber se a Indy10 roda corretamente no D7... O ideal seria remover a dependecia da Indy, usando apenas o ACBrTCPServer (que encapsula a Synapse), assim como ocorreu no ACBrMonitor

Se ela retorna via DLL é pq ela está lendo a Hora do ECF... apenas a Daruma preve esse retorno em seu protocolo básico.... Descomplique... leia a hora do ECF e grave no seu BD...

Existem os métodos EspelhoMFD_DLL (que depende da DLL) e o LeituraMFDSerial (que só funciona em alguns modelos) Entretanto o uso de ambos é extremamente lento e difícil... é melhor vc gerar uma cópia com informações do seu BD