EMBarbosa

\o/

Se e simplesmente desabilitar a FlushtoDisk usando a propriedade mencionada, por exemplo, a velocidade aumenta em cerca de 37%. Ou seja, no exemplo dado, o tempo gasto para 53 itens cai de 34,41 segundos para apenas 21,57. Isso em apenas um cupom talvez pareça pouco. Mas imagine em vários cupons com um número de itens talvez muito maior. É um tempo bem considerável. É mais ou menos o tempo gasto para fazer uma chamada adicional ao ECF a cada item vendido. Mas não sei se é recomendado fazer isso, pois não sei o motivo de terem incluído o FlushtoDisk. Quanto a ter que manter o Handle: acredito que possa-se passar os mesmos parâmetros toda vez que abrir o arquivo evitando o cache do SO.

Está rodando dentro do Debugger do Delphi?

Por favor sempre crie um tópico para dúvidas diferentes. E não crie tópicos repetidos.

O ACBrTeste tem telas de configurações e permite a comunicação pois como o nome já diz ele foi feito para.... teste... O ACBrMonitor é só um auxílio como já bem mencionado. Ele ter essas propriedades não significa que o PAF que vai utilizá-lo deva permitir uma ECF com GT diferente do que havia sido cadastrado, por exemplo.

Que coisa mais bizarra mesmo. Não lembro de nenhuma legislação que permita você fazer isso. E se alguém fizer uma mudança dessa propositalmente, achei que a ideia era o software não ajudar... Acho que perdi alguma coisa...

Não lance o tipo 75 para um produto se ele não saiu em nenhuma nota, cupom, venda ao consumidor, etc...

Não sei se poderia fazê-lo no seu caso, mas talvez o TeamViewer ou o LogMeIn podem resolver.

se você não responder aos posts que você mesmo criar, vai ficar difícil de instalar mesmo.

Até onde sabemos, o componente está 100%. Algumas coisas podem precisar de ajustes, como os novos blocos P e etc...

Você está fazendo os testes dentro do debugger do Delphi?

Acho que o ACBrNFE 1.0 foi removido do trunk. Você não deveria estar usando o 2.0?

Qual é o registro?

FiscalDPK? Que pacote é esse?

Esse tipo de informação se encontra no guia do gerenciador padrão. Depois de entendê-lo fica mais fácil de entender o DEMO do TEFD. Acho que ninguém nunca fez um passo a passo com o DEMO do ACBrTEFD por causa disso.

Olá pessoal, Gostaria de saber se algum de vocês chegaram a analisar a necessidade do FlushtoDisk. O motivo é que reparamos que há uma queda considerável na performance ao implementar os requisitos do Arquivo Auxiliar Criptografado(AAC). Veja a imagem como exemplo: Para 53 chamadas concluídas de TACBrECF.VendeItem temos um tempo gasto de 34,41 segundos. Sendo que desses, 10,35 foram gastos com a recuperação do GT e 14,14 foram gastos com a atualização do AAC. Essa perda para a recuperação do GT é realmente esperada e não acho que dê pra fazer nada sobre isso. Mas a com a atualização do AAC também é considerável. Então estamos tentando otimizar o tempo gasto com esse tipo de chamada. Analisando a chamada ACBRAAC.AtualizaValorGT, percebemos que o maior tempo, 12,84 segundos, é gasto com o método FlushToDisk. Tudo bem que 12,84 segundos não é muita coisa para 53 chamadas (dá 0,242 aproximadamente por chamada). Mas continua sendo 37% do tempo gasto com a venda de itens. E daí a questão foi levantada. Evidentemente não esperamos zerar isso, mas talvez reduzir para uns 15%? O que poderíamos fazer? 1. Nada e aceitar esse tempo até que as impressoras possam vender o item e retornar o valorGT só com uma chamada. 2. Eliminar a FlushToDisk sem fazer nada e ficar com a possibilidade de corromper o AAC... (não acho que seja recomendado) 3. Abrir o AAC de forma que não seja necessário o FlushToDisk. (http://stackoverflow.com/a/1636308) Não tive tempo hábil ainda de testar algumas dessas sugestões, e acredito que vocês talvez possam ter tido outras ideias. Gostaria de ouvir opiniões.

Então, se for isso mesmo, parece que o guia prático dessa vez está confundindo ao invés de ajudar. Ele menciona que existem 5 campos no registro. Até diz que o campo não precisa ser informado. Mas por todo o resto do Guia prático campo não informado é campo vazio e não campo inexistente. Ficou ambíguo. Agora toda vez que alguém disser que está com problema no campo 3 você vai ter que se perguntar qual o valor do campo 2 para saber quem é o campo 3.

Olá, Você poderia testar colocando os dados a partir de 01 de Julho de 2012?

Tente localizar onde está esse arquivo e adicionar o caminho dele no Path.

Rapaz, ainda não passei por esse problema... vou ter que verificar. Se alguém mais puder dar uma ajuda aí.

Gr@c@, Veja se é sobre isso aqui? Se for e puder dar um retorno mais detalhado lá... Vou verificar assim que puder. Obrigado.

Qual a versão do Windows? Como você tentou fazer até agora? Quais os erros encontrados? Você tentou usando a dica do Isaque? Quais os problemas? Você tentou usando o .bat? Quais os problemas? veja aqui

a ideia é essa. Nós agradecemos sua participação.

Procure onde está o arquivo DJCL60.bpl no seu computador e adicione o caminho ao path do Delphi 6. Se isso não resolver então acho que a dica do Daniel de usar um arquivo .bat talvez seja necessário para o seu Delphi 6. Eu mesmo dei essa dica do enviroment variables no fórum antigo, mas existe alguns casos específicos em que ela não funciona.

Não. Continua sendo melhor instalar o componente no Delphi 6.