Daniel Simoes

Por favor faça um teste com o ECFTeste no ambiente do seu cliente... Após configurar e Ativar o ECF, entre em: Variaveis, Mapa Resumo, Totais ISSQN e escolha o que deseja... Isso irá gerar um LOG mais preciso, e comprovará se o componente funciona corretamente

O Hardware é outro, mas provavelmente o funcionamento é o mesmo... Veja esse post:

ACBrTEFD1.GPAtual := gpTefDial; ACBrTEFD1.CRT() ACBrTEFD1.GPAtual := gpConvCard; ACBrTEFD1.CRT()

Verifique no Log do ACBrTEFD se ele realmente está devolvendo várias vezes a mesma via... Tente com o TEFDDemo e veja se ocorre o mesmo problema Nota: Observe pelos posts aqui desse forum, que o SiTEF modular tem problemas de compatibilidade com o ACBrTEFD referente ao Cielo Premia... Provavelmente será necessário criar uma nova classe para ele

Favor postar o Log gerado pelo ACBrTEFD...

Verifique se o Demo não está imprimindo os dados do Cliente nas linhas do Rodapé... isso não identificará o Cliente nos arquivos de cidadania (conforme descrevi acima)... Você pode verificar isso, gerando um arquivo AtoCotepe17/04 e verificando se o CPF está presente...

http://partners.bematech.com.br/2013/12/virtual-serial-port-para-a-comunicacao-com-a-usb-nos-ecfs-mp-2100-th-fi-e-mp-4000-th-fi/

Pelo que li dos Logs, notei que tem um ACK ou chr(6) nas linhas de impressão do vinculado... e isso está causando o erro na impressão da Linha do vinculado... Verifique se o ACK está sendo enviado pelo SiTEF ou pela sua aplicação... Já tive problemas com o emulador do SiTEF onde era enviado um "FF" (chr(12)), e o ECF Epson acusava um Erro.... Até mesmo subi para o SVN, uma alteração para a classe ACBrECFEpson para esse caso... Porém relatei o problema a Sw.Express, e os mesmos me informaram que era um Bug do Emulador que já estava corrigido na versão mais atual...

Você também receberá o Desconto no evento: ACBrTEFD.OnComandaECFSubtotaliza(DescAcre: Double; var RetornoECF: Integer); Onde você precisa somar o seu desconto (se houver)...

Em teoria não é necessário usar o ACBrECF para usar o ACBrTEFD... Observe que o Pacote do TEFD não tem dependência do ACBrSerial... Sempre que o TEFD precisa de alguma informação ou comandar algo no ECF, ele dispara algum evento, e nunca chama o ACBrECF diretamente... Pode ser que dê algum trabalho para achar equivalência dos comandos do ACBrECF para os da DLL do fabricante... mas na minha opinião, SIM, é possível usar o ACBrTEFD com as DLLs dos fabricantes...

No Log que você postou, fica claro que o SiTEF não enviou mensagem para ser exibida... e encerrou o loop com o erro -43 Se você verificar no manual: SiTef - Interface Simplificada com a aplicação(VRS-133).pdf o erro -43 é descrito como: Problema na execução de alguma das rotinas no pinpad. Provavelmente você não copiou as DLLs que manipulam o PinPad (libemv.dll e libseppemv.dll) na mesma pasta onde está a CliSiTef32I.dll

Não existe mais o antigo TEF discado... Mas se você não quer migrar para um TEF dedicado (Ex: SiTef) pode usar produtos que são compatíveis com a arquitetura dele... como o já citado Pay&Go... mesmo a Sw.Express tem o "Client Modular" (que não é 100% compatível com o antigo discado)

Acho que seria melhor voltar ao problema original... Você diz que não aparece a mensagem de retentar padrão do TEF e sim um Exception ? Poderia postar o LOG gerado pelo ACBrTEFD ? Se SIM, pode reproduzir o problema e descrever um passo a passo usando o TEFDDemo ? (por favor descreva como configura-lo) Veja que muitas pessoas já homologaram com ACBrTEFD e Bematech (eu mesmo sou uma delas)... então acho difícil a probabilidade de erros nos fontes... Entretanto se conseguirmos reproduzir o problema no TEFDDemo, então temos algo para investigar e tentar corrigir..

O problema é que a CliSiteTef Modular tenta emular o G.P. discado... e nele, não é possível ter mais de uma transação pendente por cupom... Ou seja, a primeira transação precisa ser confirmada (mesmo antes da impressão), para poder processar a segunda solicitação.... Para Cancelar tudo, é preciso enviar um NCN (não confirmação) para a transação em aberto, e um CNC (Cancelamento) para a transação já confirmada... O CNC (cancelamento) irá fazer várias perguntas e solicitar novamente o cartão, e imprimir um comprovante de Cancelamento em um Rel.Gerencial... Esse é um dos principais motivos, de que não vale a pena, usar Gerenciadores Padrão que emulam o discado...

Perfeito... O Saque aparecerá como TROCO no cupom fiscal

Nada é padrão no CNAB... o Tamanho da conta varia por Banco e até mesmo por Carteira do mesmo Banco em alguns casos...

O comando acima está correto... O que o ACBrECF faz nesse bloco, é verificar se o ECF tem a capacidade de identificar o consumidor no rodapé... A Bematech por exemplo, não permite, porém como esse post mesmo diz... a SwedaSTX consegue fazer isso... Se o ECF não suportar a identificação do consumidor no rodapé, o ACBrECF a fim de minimizar a perda de informações, adiciona as informações do consumidor no Rodapé do Cupom... Porém vale lembrar que isso NÃO ATENDE OS PROGRAMAS DE CIDADANIA (Ex: Nota Fiscal Paulista)... Pois o CPF não foi impresso em área específica para identificação do consumidor... Ou seja, o texto do Cliente impresso nas 8 linhas de Rodapé, não irá gerar o arquivo com o CPF do cliente corretamente Veja o FechaCupom da SwedaSTX procedure TACBrECFSwedaSTX.FechaCupom(Observacao: AnsiString; IndiceBMP : Integer); begin if not Consumidor.Enviado and (Trim(Consumidor.Documento) <> '') then { Tem Docto ? } begin EnviaComando('12|'+LeftStr(Consumidor.Documento ,20)+'|'+ LeftStr(Consumidor.Nome ,30)+'|'+ LeftStr(Consumidor.Endereco ,79)+'|1') ; Consumidor.Enviado := True ; end ; AguardaImpressao := True ; EnviaComando( '07|' + LeftStr( Observacao,800) ) ; end; Ou seja, o Cliente será identificado, com o comando correto, (12) e não irá consumir as 8 linhas do Rodapé do Cupom O mesmo ocorre da Daruma... onde será usado o comando 201 para identificar o cliente... Observe ainda que esse comando foi enviado no seu Log Certeza que o consumidor não está sendo impresso ? Se realmente não... tente com o Demo do fabricante...

Leu o link indicado no post anterior ??? A resposta está nele....

Não tenho a menor ideia... como já respondi antes, não tenho esse equipamento nem o manual dele...

Na ACBrUtil existe o método: function TiraAcentos( const AString : String ) : String ;

Obrigado por compartilhar a solução...

Se você modificar nesse ponto, pode quebrar o código de todas as classes de ECF... Você pode chamar: ACBrECF.ArquivoMFD_DLL diretamente, com os parâmetros que achar necessário...

use o modelo ecfSwedaSTX

Anexe o LOG gerado pelo ACBrECF... Aparentemente você está omitindo um campo obrigatório, como por exemplo o código do produto