Daniel Simoes

Humm... parece que ele não foi capaz de abrir a porta serial... >> fnTentarAbrirSerial(1) 26/07/2013-12:42:09:840: G_stPortaSerial - INVALID_HANDLE_VALUE 26/07/2013-12:42:09:844: Criou o handle - fnTentarAbrirSerial 26/07/2013-12:42:09:849: G_stPortaSerial - D_RET_ERRO_ABRIR_RS232 26/07/2013-12:42:09:853: << fnTentarAbrirSerial - RETORNO NUMERO: -5 O estranho é que a rotina de abertura de porta pela DLL é a mesma para todas as chamadas do ACBrECF

O ACBrSMS foi desenvolvido pelo Regys, usando um Modem da Daruma (que gentilmente nos doou o equipamento) Portanto a garantia de compatibilidade do ACBrSMS com o modem da Daruma é melhor..

Parece que o arquivo swh.ini está corrompido, ou foi encriptado com outro CNPJ de Sw.House Experimente apaga-lo e configurar novamente os dados da Sw,.House... Evite gerar novas chaves... use sempre o SEU par de chaves... Salve as chaves geradas em um TXT simples (e guarde bem)

Em alguns casos o ACBr remove a assinatura do fabricante e aplica a do desenvolvedor... Porém é necessário corrigir esse problema da DLL da Bematech 2013-07-19 17:57:24:208 - Retorno Bematech_FI_GeraRegistroEAD: - Dll 'sign_bema.dll' nao encontrada Provavelmente a DLL não está na pasta correta... ou você tem outra Bemafi32 em outra pasta... Nossa recomendação é que todas as DLLs fiquem APENAS na pasta da aplicação que executa o ACBr... ou seja, na pasta do ACBrMonitor... e NAO na System32

Eu aprovo a ideia... mas não tenho a menor condição de organizar um evento.... Apenas por curiosidade... este ano foi a terceira a DJSystem esteve na AUTOCOM, representando o ACBr

O SAI.TXT está em UTF8 (sem BOM) enquanto o X.TXT está em ANSI Usei o NotePad++ para descobrir... você diz que o SAI.TXT foi gerado pelo ACBrMonitor e está sempre sendo gerado em UTF8 ?

O LOG não ajuda muito nesses casos, pois o controle é da DLL... O que significa -1 no retorno dessa função da DLL ?

Você não disse o valor do TimeOut.... tentou com 30 seg ??

Aumente o TimeOut

Tente pelo ECFTeste... (sem cupom aberto)... assim teremos um LOG de possível analise...

Pode ser que isso seja um requisito da Lei... Verifique com o fabricante

Esqueça o protocolo Epson... sua impressora é FiscNET.... (apenas o mecanismo impressor é Epson) Provavelmente é o Sw.Básico do ECF que está imprimindo a informação que você não quer... não ocorre o mesmo quando comandado pelo DemoLog2 ?

Realmente havia um Bug na rotina.. acabei de subir uma correção... favor atualizar e verificar

Por favor anexe o Log gerado pelo ACBrECF no momento da captura

Nesse caso não compreendi a linha: EnviaComando('ImprimeAutenticacao;TextoAutenticacao= 10,00'"') pois ela não está no protocolo da Epson... A impressora é Epson OEM ou FiscNET OEM ?? Qual o modelo do ACBrECF utilizado ?

Você está falando de uma Impressora Fiscal ou não Fiscal ??

Por favor anexe o LOG (zipado) gerado pelo ACBrECF

Sim, mas o que me estranha é como ele abre um gerencial sem fechar o CCD anterior... O que me leva a crer que no momento que o PulaLinhas está para ser executado, o CCD já estava fechado (por algum motivo desconhecido)... isso que eu gostaria que você verificasse...

O vinculado está sendo fechado antes de ocorrer o erro na chamada do PulaLinhas ? Notei que na sequencia ele abre um Gerencial, mas não fecha o vinculado anterior...

O processo de assinatura ainda não está definido... e o manual (PPS) não ajuda muito,... Envie uma string qualquer, desde que tenha 344 caracteres...

O ACBrMonitor CLX foi descontinuado, pois a CLX morreu... Com a versão Lazarus qualquer pessoa pode compilar se depender da compra de uma IDE, já que o Lazarus e FreePascal são de código aberto http://www.lazarus.freepascal.org/

Apliquei algumas correções na classe: Agora já consigo utilizar o protocolo ecfEscECF em meu PDV final... Uma coisa que esqueci de comentar nos meus posts anteriores... é que o ECF real, possui apenas porta USB, mas assim que instalado, ele cria uma porta Serial virtual no Windows, o que permitiu o acesso ao ACBr sem maiores complicações...

Pesquise sobre Esc/Pos ... É uma protocolo de impressão de linha , onde todos os comandos iniciam com ESC Usar um gerador de relatórios ( se isso for uma opção ) seria muito mais simples... Dominar o ESC/POS não é tarefa fácil

O GNF é controlado pelo Sw.Basico do ECF... e nao pelo sofrware de comunicação Acho que bastaria você escanear alguns comprovantes e demonstrar o problema

Se a impressora suportar ESC/POS Você pode usar comandos nativos da impressora para gerar os códigos de barras ... ( foi o que fizemos na impressão de cupom do ACBrSAT )