daniel.simoes

Acredito que o problema seja o Virtualizador de Porta serial utilizado... Tente usar o com0com Apesar do LOG reportar falha no item repetido Isso não significa que o ACBrECF enviou o comando 2x... ele apenas tentou LER 2x.. Veja em ACBrECFBematech.pas -> TACBrECFBematech.EnviaComando_ECF

Regys, A rotina ainda pode cair nos seguintes Bugs... - Se CRZIni e CRZFim forem iguais ela não achará o CRZFim - Se o COO estiver em coluna diferente de 13 ela pode truncar o valor... No exemplo que achei na internet o COO está iniciando na 12 http://www.bematech.com.br/suporte/tuto ... ml?lmf.htm

Não aplicarei essa modificação no SVN.. preciso saber se a rotina acima funciona para o seu caso... ela que será aplicada...

Veja o LOG... se no LOG do ACBrECF constar duas vezes o mesmo comando de Venda de Item, é porque você realmente está enviando-o duas vezes

Tente substituir a Função CRZtoCOO por esta abaixo: procedure TACBrECFBematech.CRZToCOO(const ACRZIni, ACRZFim: Integer; var ACOOIni, ACOOFim: Integer); var Retorno: TStringList; CRZi, CRZf: string; Linha: string; I, PosCOO: Integer; begin Retorno := TStringList.Create; try Self.LeituraMemoriaFiscalSerial(ACRZIni, ACRZFim, Retorno); PosCOO := 0; ACOOIni := 0; ACOOFim := 0; CRZi := IntToStrZero(ACRZIni,4)+' '; CRZf := IntToStrZero(ACRZFim,4)+' '; I := 0 ; while (I begin Linha := Retorno[I]; if PosCOO = 0 then // Já achou o cabeçalho ? begin if (pos('CRZ ',Linha) = 1) then PosCOO := pos('COO ', Linha); end else begin if Copy(Linha, 1, 6) = CRZi then ACOOIni := StrToIntDef(Copy(Linha, PosCOO, 6), 0) ; if Copy(Linha, 1, 6) = CRZf then ACOOFim := StrToIntDef(Copy(Linha, PosCOO, 6), 0) ; end ; Inc( I ) ; end ; ACOOIni := max(ACOOIni,1); ACOOFim := max(ACOOFim,ACOOIni); finally Retorno.Free; end; end; [/code]

Você não testou isso antes de ir para a homologação ?? Fica muito difícil corrigir isso "na correria"... Lembre-se que o ACBr é mantido por voluntários... e que todos trabalham no seu tempo livre...

Acabei de subir mais uma tentativa... Por favor teste todos os comandos possíveis, pois posso ter introduzido novos bugs acidentalmente...

O ACBr é código aberto... Abra os fontes e verifique...

Use CancelaCupom... ele detecta que o ultimo documento é CCD e cancela-o antes do Cupom

É o que está sendo feito hoje... O ECF retorna uma "Mensagem" com o código 228 - e do jeito que está o ACBrECF entende que "Tudo bem, resposta recebida" Quando receber o '!' temos que verificar qual foi a mensagem, e tentar deduzir se após a mensagem virá ou não mais informações...

Não para leitura de Cod.Barras é utilizado o ACBrLCB

O Fix acabou se revelando pior que o Bug Acho que vou ter que tratar todos os retornos do Tipo '!' individualmente... pelo que percebi no manual, eles estão na tabela de Erros porém como "Mensagem"... algumas podem ser consideradas como resposta final do ECF... e outras, como esse código "228" da Leitura devem fazer o ACBrECF ignorar este retorno e aguardar o próximo

TEF e ECF são duas coisas totalmente distintas... Observe no roteiro do TEF, que eles sempre solicitam para cancelar a Operação TEF... isso não significa cancelar o Cupom no ECF... (mas vc pode faze-lo se quiser) Lembre-se porém que em algumas situações o ECF estará desligado ou até danificado... e a transação TEF deve ser cancelada mesmo assim... O que os homologadores tb querem, é que a aplicação seja capaz de detectar que há um documento incompleto e trata-lo, antes do inicio de uma nova venda

Enviei uma pequena modificação... por favor atualize e teste... ( o difícil é simular o problema )

Pelo que notei... o ECF está apenas informando uma mudança de estado... ou seja: No Bloco: [sTX]K01!0040AA[128][128][146][128][128][ETX][170] o 0040 está sendo interpretado pelo ACBrECF como ERRO... mas o sinal de Tipo do Bloco é '!' e não '-'... Vou modificar para ele procurar por erros apenas se o sinal for '-'

Por favor copie e cole aqui um PrintScreen com a tela do erro

O cancelamento da transação TEF irá gerar um relatório gerencial .... Não há como cancelar o cupom após a impressão do mesmo

O erro é outro ... Ao que parece. a Sweda possui um estado ecfRequerX. Precisamos saber como detecta-lo

Provavelmente vc tem dois ACBr instalados em sua máquina... e seu Delphi não está usando o atualizado... Esses métodos já existe no ACBr a mais de ano

A maioria dos ECFs suporta o cancelamento de Cupom após a impressão de Vinculado (ou CCD)... Use o comando CancelarCupom do ACBrECF, ele próprio detecta que há Vinculados após o cupom e faz o cancelamento deles...

Sim é interessante... Se desejar doar algum código com o componente ficaremos muito agradecidos

Provavelmente seus fontes estão muito desatualizados...

Acho que consegui corrigir... Realmente o Parâmetro "PathBin" deve ficar vazio quando a Faixa especificada é em COO... Adicionei no ACBrMonitor suporte aos novos métodos do ACBr: PAFMF_* por favor veja o histórico de mudanças (e a assinatura dos novos métodos) em ACBrMonitor.chm Mudanças já estão no SVN... Aproveitei e atualize o instalador do ACBrMonitor para 0.9.5 no S.F.

Não há como mudar isso... a redução Z é obrigatória... isso é feito pelo Sw.Básico do ECF... O que existe em alguns equipamentos é a Redução Z automática... Que quando ativada, é emitida as 2:00hs do dia seguinte ou assim que o ECF for ligado...

Pelos meus testes o Download da MFD na Bematech não funciona no Emulador e também não consegui fazer funcionar usando adaptador USB-Serial