EMBarbosa

Olá Ivan, Eu estive olhando suas alterações no ACBrBombas. Tinha pensado que você tinha feito um do zero, mas pelo que entendi, você aproveitou o anterior e foi modificando. Tenho algumas dúvidas: 1) Por que você comentou vários métodos que estavam no componente? (Ex.: PredeterminaAbastecimentoemValorBico, LeAbastecimentosPendentes, AjustaRelogio...) Algumas delas acredito que estavam funcionando no exemplo da CompanyTec. 2) O que está funcional? 3) Quais suas sugestões? O que acha que precisa ser feito?

Ou seja, não é uma "forma de pagamento vinculada". É "permite cupom não fiscal vinculado a essa forma de pagamento?". Posição é um índice utilizado pelo ECF para localizar a forma de pagamento. Alguns ECFs usam letras também. Se você estiver começando a mexer com ECFs agora, veja esse tópico:

Puxa!! Ivan, Eu gostaria de ver isso. Se puder e achar apropriado, anexa aí no fórum preferencialmente nesse tópico aqui: ou então em um dos que ele cita.

Está tudo bem. Bem vindo ao fórum.

Suas perguntas são das mais frequentes aqui no fórum. Ainda não tive tempo de fazer um post completo sobre elas para adicionar no FAQ, então vou responder. Mas seria bom que você pesquisasse antes de perguntar. Vamos lá: Se isso acontece enquanto você está debugando, então é normal. Você precisa responder rapidamente a mensagem para o Delphi continuar ou desabilitar esse tipo de exception. No entanto, todos os testes que fiz com o VSPE apresentaram problemas. Por isso eu passei a usar o com0com. Mas se o seu funciona bem, então não há problemas. Mas veja: Isso acontece pois o ACBrECF funciona de forma diferente de Dlls. Veja esse post: http://www.djsystem.com.br/acbr/forum/viewtopic.php?f=5&t=7800&p=42454&hilit=device.processmessages#p42351 Pesquise também por venda frenética, ou venda de itens em fila.

João, Entre em contato com a Epson e veja com eles qual o manual para programação de comunicação direta deve ser utilizado para esse ECF. Eles podem disponibilizar para você.

A primeira mensagem de erro (E2225) diz que é preciso recompilar o ACBr_NFe2. Você fez isso? Recompilou o ACBr_NFe2?

Que bom que resolveu. Obrigado pelo retorno. Assim a gente fica mais tranquilo, e outros usuários podem ficar atentos a esse problema também.

Desculpa, não fui claro ... Acho que o ACBr não possui a implementação do método cancelaItemVendidoParcial para o Ecf EPSON. Poderia confirmar isso pra gente? Não possui mesmo. Nem sei se suporta. Acho que só a Daruma tem esse método implementado.

Veja esse link:

Copie a base de dados do cliente pra sua máquina então e tente debugar. Verifique se o componente está passando dentro do método WriteRegistroC100 e adicionando as notas.

Se entendi bem sua pergunta: Pode sim.

Daniel, eu olhei o manual ontem antes de comentar. O código enviado é 13 casas mesmo. Aquele zero no final (logo antes da descrição) é um parâmetro parte da comunicação. Ele define que a descrição deve ter 20 caracteres. Não entendo muito de comunicação serial nem deste protocolo, mas pelo que eu vi, para o manual que temos o ACBrECF está enviando corretamente. O que me veio à mente é que esse ECF não seja compatível com os manuais que temos. Se eu entendi bem, os ECFs citados lá são ECF-2011 e ECFs com firmwares FCP-201 e FCP-500. EDIT: Não seria possível esse ECF ser um FiscNet?

Daniel, esse daí não é o valor do desconto? Veja aí: ComandoLOG := 'VendeItem( '+Codigo+' , '+Descricao+' , '+ AliquotaICMS+' , '+FloatToStr(Qtd)+' , '+ FloatToStr(ValorUnitario)+' , '+ FloatToStr(ValorDescontoAcrescimo)+' , '+Unidade+' , '+ TipoDescontoAcrescimo+' , '+DescontoAcrescimo+ ' , '+IntToStr(CodDepartamento)+' )';[/code]

Eu verifiquei o manual que temos no repositório do ACBr e o comando me pareceu que está OK. Qual é o modelo de seu ECF? Sabe se o protocolo é compatível com FCP-500 ou FCP-201?

Entendi. Mas tem mesmo que continuar analisando tudo... Daqui de longe fica difícil saber o que está acontecendo. Será que não é algum erro no SQL? O que você coloca como SQL do sqlVendas? Tem alguma condição que poderia estar eliminando algum registro?

Não. Essa informação você encontra nos Requisitos do PAF-ECF.

Verifique o método WriteRegistroC100 para ver se alguma restrição está barrando seus registros de serem gerados. Certifique-se que durante a execução ele passe também pelos métodos filhos C170, C190 etc...) Dúvidas: Você definiu algo no evento ACBrSPEDFiscal.onError? Por quê você não gera os registros C170? O que vem a ser o objeto P2 e o método P2.Refresh? Barra de progresso? Algum motivo especial para isso?

Acho que ficaria mais fácil de ajudar se você explicar os objetivos do seu cliente com esse cupom não fiscal. Como ele vai usar? Por que ele precisa disso? Assim como pareceu ao Daniel, a mim também parece que você está fazendo uso equivocado dos recursos do ECF.

Dependendo do estado onde estiver, acho que com um número menor já extrapola o limite. Em MG por exemplo tem o Minas Legal que é obrigatório e no final das contas, se não me engano, acaba ocupando uma linha inteira.

Pode ser. Não ficou claro a dúvida...

Se você ler o guia prático encontra a resposta. Existem os dois campos no registro C100.

Boa Daniel. Adicionei isso ao FAQ do Wiki.http://www.djsystem.com.br/acbr/wiki/index.php?title=ACBr:FAQ

Flavio, O que o Daniel quis dizer é que não adianta testar uma funcionalidade do ACBrECF de uma impressora em outra. Teste o uso desse ECF específico que está dando problema com a dll. Se não funcionar nem com a DLL da Bematech, o problema deve ser no ECF. Mas se funcionar, anexe aqui o log do ACBrECF como o Régys pediu.

Não está usando o emulador?