Pesquisar na Comunidade

Bom dia a todos, Alguém poderia me ajudar em relação ao seguinte erro retornado ao tentar gerar o espelho MFD de um impressora Bematech? Erro ao carregar a função:Bematech_FI_GeraRegistrosSpedCompleto de: Bemafi32.dll Saberiam me dizer o motivo do erro e como corrigi-lo? Isso apenas ocorre com impressora/emuladores bematech

ola nao sei alguem ja fez isso preciso inverter um relatorio tipo efeito espelho para sair certo na impressao ao contrario

Estou tentando usar a função ACBrECF1.PafMF_MFD_Espelho(edtDtInicial.Date, edtDtFinal.Date, PathArquivo), mas o processo nunca finaliza, ou seja, o arquivo MFD é gerado na pasta informada porem o ACBr não consegue gerar o .TXT com a Assinatura EAD. Estou anexando o log gerado pelo ECFTeste.exe. Ambiente : Bematech MP-2100 Porta COM3, Virtualizada via USB (BematechVirtualSerialPort_x64_v3.0.2.0) Observação: usando o programa (WinITFI) conectada na mesma porta (COM3) eu consigo gerar o Espelho MFD. Att, Edson acbrlog.txt

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.

Tive um problema com a Elgin K Fiscal, quando eu executei a função espelho MFD com o ECFTeste ele me retorna o erro em anexo: acbrlog erro espelho mfd.txt 929bytes 2 Downloads Usando meu sistema retorna o erro "0" que no manual diz que não houve erro, kkkk. Pense num negócio estranho, no manual da Elgin K tem: TABELAS DE ERRO, e o primeiro erro catalogado é o "0" (zero) que significa que não houve erro. kkkk

Prezados, boa noite. Estou testando o acbrMonitor com o próprio ECFTeste. Achei fantástico, imprimi documentos fiscais, não fiscais, muitas outras opções e tudo ok. Minha impressora é uma Bematech 2100 serial com um adaptador USB COM. Estou tendo uma dificuldade no seguinte: Quando tento Relatórios->Leitura MDF serial-> por periodo, tudo ok. mas por COO ele dá erro. Olhem o log No comando enviado: [sTX][19][0][28]>EC0026000026021e[ETX] Na resposta: Ativar - + - + - + - + - + - + - + - + - + - + - + - Erro retornado pela Impressora: Bematech Número de parâmetro inválido A[1][ETX][0] - + - + - + - + - + - + - + - + - + - + - + - Tentando também espelho mfd dll tanto por data quanto por COO tenho erros ACK que variam (120, 124, 116) resposta: Erro. Resposta da Impressora Bematech inválida (ACK = 120) - + - + - + - + - + - + - + - + - + - + - + - E mesmo erro com Arquivo mfd dll por periodo ou COO resposta Erro. Resposta da Impressora Bematech inválida (ACK = 116) - + - + - + - + - + - + - + - + - + - + - + - O resto inteiro tudo ok, somente os espelhos mfd citados dando problema. estou na versao do ECFTeste 3.00 ACBR 0.9.0a compilado com Lazarus 0.9.29 beta O AcbrMonitor é a versão 0.10.2.3 O pacote de dll é o mais atual do site da bematech Cheguei a aumentar o timeout para 60 segundos, mas não é tempo de resposta, pois o erro vem praticamente com 2 segundos. Alguem dá alguma luz? Obrigado Aproveito e lanço um acbrlog.txt criado justamente antes de dar o ok para um espelho MFD DLL por periodo Desativando ACBrECF xBematech_FI_AbrePortaSerial xBematech_FI_FechaPortaSerial Ativar ACBr: SIM -------------------------------------------------------------------------------- ATIVAR - 12/06/14 22:50:15:590 - Modelo: Bematech - Porta: COM1 - TimeOut: 60 Device: BAUD=9600 DATA=8 PARITY=N STOP=1 HANDSHAKE=RTS/CTS HARDFLOW MAXBANDWIDTH=0 -------------------------------------------------------------------------------- -- 22:50:15:598 EspelhoMFD_DLL( 01/06/2014 , 12/06/2014 , teste.txt ) TX -> [sTX][4][NUL][FS][19]/[NUL] 22:50:16:700 RX <- [233][208]||t{{zx|td{zx|td{zx|td{zx|td{z -- 22:50:16:705 TX -> [sTX][ENQ][NUL][FS]#)h[NUL] Bematech EnviaComando_ECF: ACK = 123 Falha: 1 TX -> [sTX][ENQ][NUL][FS]#)h[NUL] Bematech EnviaComando_ECF: ACK = 124 Falha: 2 TX -> [sTX][ENQ][NUL][FS]#)h[NUL] Bematech EnviaComando_ECF: ACK = 116 Falha: 3 22:50:16:963 RX <- ----------------- ERRO ----------------- Erro. Resposta da Impressora Bematech inválida (ACK = 116) ---------------------------------------- -- 22:50:16:966 TX -> [sTX][ENQ][NUL][FS]#[sOH]@[NUL] Bematech EnviaComando_ECF: ACK = 122 Falha: 1 TX -> [sTX][ENQ][NUL][FS]#[sOH]@[NUL] Bematech EnviaComando_ECF: ACK = 124 Falha: 2 TX -> [sTX][ENQ][NUL][FS]#[sOH]@[NUL] Bematech EnviaComando_ECF: ACK = 123 Falha: 3 22:50:17:234 RX <- ----------------- ERRO ----------------- Erro. Resposta da Impressora Bematech inválida (ACK = 123) ----------------------------------------

Olá, sou novo aqui no fórum e não encontrei nada a respeito. Gostaria de saber se existe alguma forma de NÃO assinar EAD os arquivos gerados pelas funções PAF. Poderia ser dada esta opção para o desenvolvedor como nos exemplos abaixo. EXEMPLOS: ECF.PafMF_LMFC_Espelho( nCRZInicial , nCRZFinal, cPathArquivo ) <- Função Atual ECF.PafMF_LMFC_Espelho( nCRZInicial , nCRZFinal, cPathArquivo, bNaoAssinar ) <- Sujestão ECF.PafMF_LMFC_Cotepe1704(dDataInicial, dDataFinal, cPathArquivo) <- Função Atual ECF.PafMF_LMFC_Cotepe1704(dDataInicial, dDataFinal, cPathArquivo, bNaoAssinar) <- Sujestão Obrigado!