Daniel Simoes

O componente já faz isso... No discado não existe venda de Cartão seguida de Dinheiro... O correto seria Dinheiro seguido de cartão...

joselobinho, Notei que apesar da mensagem informar .DLL o carregamento da DarumaFramework.so está correto no Linux... não sendo necessária nenhuma modificação nos fontes... As instruções de instalação do Pacote da Daruma são nulas, segue algumas dicas: - Copie (como ROOT) os arquivos .so do pacote para uma pasta do seu LibPath como por exemplo /usr/lib - Verifique as permissões dos arquivos .SO recém copiados: se necessário use o comando: chmod a+rx /usr/lib/NomedaLib.so Após esta configuração, consigo fazer o programa ECFTeste funcionar com os .SO (use ele nos seus testes inicialmente (é mais rápido)) cd /opt/ACBrMonitor ./ECFTeste Ao solicitar uma recuperação da MFD, o ECF bipa, porém recebo um erro 0, e mais nenhuma outra pista... Tentei executar o Demo da Daruma (multiplataforma em QT) porém o mesmo nem encontrou a DarumaFramework.so Acho que agora é entrar em contato com o suporte deles (Daruma), e solicitar mais informações sobre o uso do DarumaFramework.so, pois os TXTs com instruções que acompanham os ZIPs são pífios Um possível problema, é a forma como o ACBr configura os parâmetros para o DarumaFramework.so, ele usa o método: xregAlterarValor_Daruma. Como sabemos não há Registry no Linux, e o Help On-Line da DLL não dá a menor dica de como esse método se comportará no Linux, ou se é compatível...

Pelo que notei a mensagem de erro não provem dos fontes do ACBr, e sim da própria .DLL (.so)... Ou seja, pode ser que o Bug seja da própria DLL, ou que as DLLs complementares precisem estar instaladas em alguma pasta do LibPath do Linux Estou montando um laboratório para testar o comando... volto a postar...

Seu tópico é muito incompleto... Qual componente ? Qual Delphi ? O que você está tentando fazer ?

Acho que a função seria válida se puder existir alguma validação sobre o documento... Poderia-se verificar por exemplo se a placa é composta de 3 letras seguida de 4 números...

Mas o COD-PRO é um outro número ? Pelo que li é um relatório com vários outros documentos, como CPF, Insc.Estadual, etc...

Verifique no Log do ACBrTEFD se você está enviando o valor correto... Se SIM, ligue na SevenPDV e verifique se esse módulo realmente possui essa característica.

Olá joselobinho, Vou tentar achar os .SO para a Daruma e verificar... Volto a postar...

Leitura da MFD não funciona com emulador

Acho que o seu problema não tem nada a ver com o tópico... pois falávamos sobre arredondamento em Venda de Item... Por favor abra um novo tópico, e detalhe bem o seu problema, e o ambiente que ele ocorre..

Ricardo, Vou fazer uns testes aqui, para tentar reproduzir o problema de "comer linhas" do TXT de Entrada... Qual é o ambiente que o problema ocorre ? (Sistema Operacional)

Desabilite as propriedades do ACBrECF ACBrECF1.BloqueiaMouseTeclado ACBrECF1.ExibeMensagem ACBrECF1.Retentar

O estranho é que não temos Bug report semelhante...e isso afetaria muitos usuários Pode ser difícil de diagnosticar o que pode estar acontecendo... Se vc tiver uma mini-aplicação de testes que apenas crie os arquivos, e reproduza o problrma, ajuda muito Como você cria o arquivo de entrada ? Lembre-se de criar o arquivo sempre em um temporário primeiro... e só depois disso renomear para ENT.TXT... Caso contrário o ACBrMonitor pode ler um arquivo incompleto ou o arquivo ENT.TXT ainda estar travado pela aplicação criadora...

Notei que você trabalha com Cobol, o exemplo que acompanha o ACBrMonitor, não ajuda ? Pelo que notei ele permitiria você usar Sockets, que é infinitamente mais seguro e rápido que a troca de TXT

Pelo que notei nesse logo, não chegou o comando de Venda de Item Veja: Preciso saber como sua rotina atua para saber se devo investigar para o caso do ACBrMonitor estar realmente "comendo" algumas linhas Em todo caso, é muito importante verificar o retorno de cada comando enviado... (E se acaba o papel, por exemplo)

Ricardo, Sua rotina lê a resposta do ACBrMonitor ? O ACBrMonitore está informando erros na execução dos comando... porém você continua enviando novos comandos, como se os erros não existissem... Veja: Você cria um TXT com todos os comandos ? (não recomendado) Ou envia um a um e testa os retornos ?

Funciona normalmente, uso isso no meu dia a dia... Aparentemente você não instalou a DLL corretamente, veja instruções no próprio pacote da DLL

Esse arquivo é da Bematech... consulte o fabricante...

Resposta completa... Ainda há muito o que escrever nesse manual... Abra a Unit DoECFUnit.pas e leia os comandos que já foram mapeados

http://acbr.sourceforge.net/ACBrMonitor.htm

Use as DLLs da Pasta "ACBr\DLLs\ECF"

Apenas as matriciais fazem isso... Mas no ACBrECF temos um "workaround" para isso... Quando você procura pela Descrição da Forma de Pagamento, se ele não encontrar, ele cadastra, e já retorna o novo Índice... (apenas nas Matriciais) Ou seja, se você tiver uma rotina que verifica a existência das Formas de Pagamento pela descrição, no Inicio da aplicação, o ACBrECF irá cadastra-las

Ricardo, Por eliminação só me resta desconfiar da sua rotina de envio de comandos... Tente criar um LOG de saida, paralelo para ela... assim podemos comparar com Log do ACBrMonitor

Ricardo, Este log é gerado pelo ACBrMonitor, precisaria do LOG gerado pelo ACBrECF (aba ECF) Acho pouco provável que a aplicação tenha enviado o comando de abertura de Vinculador... pois ele não consta no LOG... uma das primeiras coisas que o ACBrMonitor faz ao receber o comando é gravar no LOG... E se ele estivesse "comendo" algumas linhas, veríamos isso ocorrer em outras ocasiões, e de forma randômica... Por favor reveja os seus fontes de envio, deve haver algo que esteja caindo nessa situação do não envio do comando...

Você poderia anexar o LOG ? No caso da Bematech, se nenhum índice for informado, O ACBrECF tenta usar um comando antigo (em modo de compatibilidade)