Daniel Simoes

Uma analise nos fontes do TEFDDemo deve sanar as suas dúvidas...

São propriedades novas... para que a IDE reconheça as mesmas, você deve recompilar e instalar o package

A IDE não gostou de linhas comentadas nos fontes ??? Experimente apaga-las...

Isso é uma característica desse ECF -2 sempre será dinheiro nesse modelo... Consulte o manual do equipamento

Acabo de testar na Classe da Epson com o emulador... parece tudo OK... Após Registrar um Item Não Fiscal o ACBrECF.SubTotal retornou o valor total registrado

Pode ser um bug na Classe ACBrECFEpson... Tente usar o ECFTeste, e identificar se o mesmo ocorre com a Bamatech ou Sweda por exemplo... Você pode usar os emuladores de ECF que esses fabricantes disponibilizam...

Por favor poste um passo a passo de como reproduzir o problema... Observe que o Demo em Lazarus está bem mais completo que o Demo em Delphi

Não estou muito por dentro do Fluxo que o GwCel envia... vc pode postar um passo a passo usando o TEFDDemo ?

Não sei... cada impressora tem um chipset diferente...

Consegue reproduzir o problema no TEFDDemo ??

Sim, servirá para Impressoras não fiscais, SAT e CFe... Cada um será um novo package... Ainda é um trabalho em construção... vou tentar comitar essa semana alguma coisa...

Nossos testes se limitaram a impressoras da Epson, que gentilmente nos cedeu o hardware... Há relatos no fórum de usuários que tb conseguiram usar uma Bematech (desde que com o firmware atualizado) Em relação ao cancelamento... Abra um nóvo tópico para uma nova dúvida.. Leia as regras do forum

Fiz uma reforma nesse método (já no SVN)

Não consegui reproduzir o problema no emulador da Epson FBIII e não tenho o emulador da FBII... (também não encontrei o emulador antigo para download) Você poderia disponibilizar um link para download do Emulador TB81 FBII ?

Suas considerações parecem corretas... Fiz o teste no Emulador e percebi que realmente os valores estavam sendo "deslocados" uma posição... Enviei uma correção agora pouco para o SVN

Notei que os erros gerados por este LOG são causados porque (de alguma maneira) o ACBrECF montou o comando usando o separador de decimal como "." e não como ","... No trecho abaixo fica evidente o erro: Porém não vi como isso possa ocorrer, já que existe o método interno chamado: AjustaValor function TACBrECFSwedaSTX.AjustaValor( ADouble : Double; Decimais : Integer = 2 ) : String ; begin Result := FormatFloat('0.'+StringOfChar('0',Decimais) ,ADouble) ; Result := Trim(StringReplace(Result,DecimalSeparator,',',[])) ; end; Você está manipulando diretamente as Decimais do Preço Unitário ? ( Algo como: ACBrECF1.DecimaisPreco := 2 )

Por favor anexe a Unit toda ou gere um DIFF... é muito difícil comparar os fontes com um fragmento de código apenas...

Esse evento é disparado quando ocorre um "ERRO" de fim de papel... Ou seja, o último comando enviado não foi aceito...

Você está usando a DLL do fabricante... no ACBR usamos a comunicação direta pela Serial... Provavelmente o fabricante possa lhe ajudar... Tente o skype: "peps_suporte"

Anexe o Log gerado pelo ACBrTEFD... Vale lembrar que não é o TEFD que faz a impressão, ele apenas chama eventos para a sua aplicação fazer a impressão...

O ACBrETQ não suporta esse tipo de etiqueta... ele SEMPRE considera que a etiqueta tem o GAP Você poderia usar diretamente a linguagem PPLA/PPLB/EPL2 (conforme o equipamento) e programar o tamanho da etiqueta...

O ACBrETQ não suporta esse tipo de etiqueta... ele SEMPRE considera que a etiqueta tem o GAP Você poderia usar diretamente a linguagem PPLA/PPLB/EPL2 (conforme o equipamento) e programar o tamanho da etiqueta...

O protocolo descrito é idêntico ao formato de resposta B da Toledo: Protocolo B = [ ENQ ] [ STX ] [ PESO ] [ ETX ] Provavelmente você precisa ajustar corretamente as configurações da porta serial BaudRate, StopBits, Parity, etc... Verifique no manual do equipamento qual a configuração default usada pelo mesmo

Pelo que li no LOG as exceções são controladas... ou seja, elas não "vazam" para a aplicação... O que ocorre é que nos modelos FiscNet, não há como saber se a Forma de Pagamento existe, a não ser tentando lê-la... Podemos ver ainda no LOG que você não programou a posição 0 da tabela de Formas de Pagamento... O mesmo ocorre com a leitura de alíquotas... Veja no código de procedure TACBrECFFiscNET.CarregaFormasPagamento; que há um Try / Except que captura o erro "ErroCMDFormaPagamentoIndefinida"

Apliquei nos fontes do SVN uma possível correção baseado nas informações deste post e do LOG capturado... Obrigado a todos pelas analises e contribuições... Por favor atualizem os fontes e testem se está OK