Pesquisar na Comunidade

Bom dia pessoal, Temos um cliente que a um pouco mais de 2 meses, substituiu parte dos ECFs deles adquirindo 4 Daruma MACH 2. O caixa que o cliente mais reclamou está operando a 9.600 de baudrate e o software básico é a versão 01.00.00. Depois que subtituímos os ECFs pelos novos o cliente nos reportou que: 1) Os ECFs estão lentos em relação aos outros que não foram trocados, ou seja, o fechamento do cupom com venda normal é um pouco mais devagar e que quando ocorre emissão de fechamento com CCD o desempenho chega a ser crítico. 2) Quando efetua a emissão do espelho nos ECFs a numeração dos COO não sai em sequencial, pulando alguns. Os itens acima foram constatados pelo cliente que a princípio utilizava a DarumaFramewok 9.0.21(32 bits). Enviamos para manutenção um dos ECFs que não constatou problema. Efetuamos então alguns testes no cliente e o mesmo verificou que com a DarumaFramework 8.17.8(32 bits), a venda tinha uma performance melhor e a numeração do espelho ficava sequencial, não apresentando problema. Fomos informados pelo suporte que a DarumaFramework 9.0.21(32 bits) apresentava no espelho o problema de pular os COO e que eles já haviam solicitado uma correção. Fomos então orientados a utilizar a última versão DarumaFramework 10.5.1.0(32 bits). Esta última versão o cliente reportou que apresentou uma ligeira melhora na velocidade mas constatamos que ainda pulava a numeração do COO ao emitir o espelho. Por esta razão deixamos no cliente a versão DarumaFramework 8.17.8(32 bits). O suporte nos pediu um arquivo de auditoria para poder analisar este caso, habilitando as seguintes tags no arquivo DarumaFramework.xml: <START> <LocalArquivos>.\</LocalArquivos> .... <ECF> .... <Auditoria>1</Auditoria> E no caso da lentidão pediu para verificarmos a tag: <START> .... <Produto>ECF</Produto> ... <ECF> ... <PortaSerial>COM1</PortaSerial> .... <Velocidade>9600</Velocidade> Com isso seria gerado o arquivo Auditoria_ECF.txt que iríamos passar para o suporte deles para conseguirmos identificar o que está ocorrendo no cliente. Habilitamos no cliente, mas o arquivo em questão não é gerado. Os nossos questionamentos são: 1) O arquivo acima não está sendo gerado pelo fato de utilizarmos a biblioteca da ACBR? 2) Temos algum outro modo de passarmos esta informação para o suporte? 3) Alguém já enfrentou o problema de lentidão ou o fato de pular o COO na emissão do espelho conforme descrito acima? Desde já agradeço. Gostaríamos de saber a opinião de vocês.

Pessoal mais uma pergunta No ECF, tinhamos como capturar o numero COO,CCF, etc do ECF quando mandava para impressão, no SAT não localizei esse codigo e série, alguem pode dar uma dica obrigado

Bom dia pessoal, Estamos com uma dúvida em relação ao COO inicial retornado pelo ECF. O nosso sistema, no método do ACBrECF, antes da emissão da redução Z, grava no banco de dados as informações do anexo banco_dados.png. Para gravar os campos COOINICIAL e COOFINAL(Colunas da tabela acima), utilizamos: ecf.ACBrECF.DadosReducaoZ; //DadosReducaoStr := ecf.ACBrECF.DadosUltimaReducaoZ; ReducaoZAtual := ecf.ACBrECF.DadosReducaoZClass; COOInicial := ReducaoZAtual.NumeroCOOInicial; COOFinal := ecf.Acbrecf.NumCOO; Para gravar no banco de dados, enviamos: StrToCurr(COOInicial) StrToCurr(COOFinal) + 1 //Adicionamos +1 aqui para contar o COO da própria redução Z que será emitida em seguida No entanto, ao analisarmos os dados do banco de dados acima e o espelho do ECF do dia 22/07 e 23/07(Espelho.TXT), conforme em anexo, temos: + Dia 22/07: - COO FINAL: 019207 + Dia 23/07: - COO INICIAL: 019208 A dúvida seria a seguinte: O COO Inicial do dia 23/07 não seria 019208 ao invés de 019206? Uma vez que o 019206 seria um relatório gerencial emitido no dia 22/07 as 14:31:41 hrs ? Espelho.TXT

Boa tarde, Estou com um problema na geração do espelho MFD, quando eu gero por data funciona, porém quando eu gero por COO gera o seguinte erro: O que fazer?