Intelliware

Bom dia pessoal, o conteúdo da variável ImagemComprovante.Text na procedure: procedure TdmVendaECF.TEFComandaECFImprimeVia(TipoRelatorio : TACBrTEFDTipoRelatorio; Via : Integer; ImagemComprovante: TStringList; var RetornoECF : Integer); É o seguinte: ' '#$D#$A'.....S.O.F.T.W.A.R.E.E.X.P.R.E.S.S....'#$D#$A'SI Rede 124'#$D#$A'MU Codigo transacao: 200'#$D#$A'LA Codigo operacao: 930030'#$D#$A'DO Valor: 5,89'#$D#$A'.....S...I...M...U...L...A...D...O....'#$D#$A'SI NSU SiTef: 10007'#$D#$A'MU 01/11/16 07:11'#$D#$A'LA ID PDV: SE000001'#$D#$A'DO Estab.: 000000000000001'#$D#$A'.....S...I...M...U...L...A...D...O....'#$D#$A'SI Host: 000010007'#$D#$A'MU Transacao Simulada Aprovada'#$D#$A' (SiTef)'#$D#$A O que fiz foi: 1) Retirar os seguintes caracteres do começo: ' '#$D#$A 2) Retirar os seguintes caracteres do final: #$D#$A 3) Após isso executei a função: ImagemComprovante.Text := StringReplace(ImagemComprovante.Text, '#$D#$A', '#10', [rfReplaceAll, rfIgnoreCase]); A princípio parece que resolveu, consigo agora imprimir 10 comprovantes seguidos sem problema algum. Será que o ECF não estava conseguindo interpretar algum caractere enviado no relatório gerencial?

Boa tarde pessoal, Estamos implementando correspondente bancário e pagamento de fatura SIGACRED no nosso PDV. Está acontecendo um fato estranho. No módulo da SIGACRED quando retorna o relatório gerencial para impressão, ocorre erro de impressão e o ECF mostra a mensagem para tentarmos novamente. Se escolhemos SIM, o processo tenta novamente, ocorre erro de impressão e entra em loop. Só sai se escolhemos a opção NÃO. Pelo que analisei, o problema ocorre na procedure: procedure TACBrECFSwedaSTX.LinhaRelatorioGerencial(Linha: AnsiString; IndiceBMP: Integer); Especificamente na linha: EnviaComando( '25|' + Buffer, Espera ) ; O valor da variável Espera está sendo 4 no caso. No log, temos a seguinte situação: -- 31/10 14:58:34:262 -- Ativando a porta: COM1 -- 31/10 14:58:34:263 LinhaRelatorioGerencial( " [LF].....S.O.F.T.W.A.R.E.E.X.P.R.E.S.S....[LF]SI Rede 124[LF]MU Codigo transacao: 200[LF]LA Codigo operacao: 930030[LF]DO Valor: 7,69[LF].....S...I...M...U...L...A...D...O....[LF]SI NSU SiTef: 310022[LF]MU 31/10/16 13:54[LF]LA ID PDV: SE000001[LF]DO Estab.: 000000000000001[LF].....S...I...M...U...L...A...D...O....[LF]SI Host: 000310022[LF]MU Transacao Simulada Aprovada[LF] (SiTef)[LF][CR][LF]", 0 ) -- 31/10 14:58:34:264 TX -> [STX][207]25| [LF].....S.O.F.T.W.A.R.E.E.X.P.R.E.S.S....[LF]SI Rede 124[LF]MU Codigo transacao: 200[LF]LA Codigo operacao: 930030[LF]DO Valor: 7,69[LF].....S...I...M...U...L...A...D...O....[LF]SI NSU SiTef: 310022[LF]MU 31/10/16 13:54[LF]LA ID PDV: SE000001[LF]DO Estab.: 000000000000001[LF].....S...I...M...U...L...A...D...O....[LF]SI Host: 000310022[LF]MU Transacao Simulada Aprovada[LF] (SiTef)[LF][LF][ETX][164] -- 31/10 14:58:34:829 14:58:34:829 RX <- ACK = 2 Falha: 0 -- 31/10 14:58:34:933 TX -> [STX][207]25| [LF].....S.O.F.T.W.A.R.E.E.X.P.R.E.S.S....[LF]SI Rede 124[LF]MU Codigo transacao: 200[LF]LA Codigo operacao: 930030[LF]DO Valor: 7,69[LF].....S...I...M...U...L...A...D...O....[LF]SI NSU SiTef: 310022[LF]MU 31/10/16 13:54[LF]LA ID PDV: SE000001[LF]DO Estab.: 000000000000001[LF].....S...I...M...U...L...A...D...O....[LF]SI Host: 000310022[LF]MU Transacao Simulada Aprovada[LF] (SiTef)[LF][LF][ETX][164] -- 31/10 14:58:35:498 14:58:35:498 RX <- ACK = 2 Falha: 1 -- 31/10 14:58:35:602 TX -> [STX][207]25| [LF].....S.O.F.T.W.A.R.E.E.X.P.R.E.S.S....[LF]SI Rede 124[LF]MU Codigo transacao: 200[LF]LA Codigo operacao: 930030[LF]DO Valor: 7,69[LF].....S...I...M...U...L...A...D...O....[LF]SI NSU SiTef: 310022[LF]MU 31/10/16 13:54[LF]LA ID PDV: SE000001[LF]DO Estab.: 000000000000001[LF].....S...I...M...U...L...A...D...O....[LF]SI Host: 000310022[LF]MU Transacao Simulada Aprovada[LF] (SiTef)[LF][LF][ETX][164] -- 31/10 14:58:36:186 14:58:36:186 RX <- ACK = 6 Falha: 2 -- 31/10 14:58:39:026 TimeOut estendido -- 31/10 14:58:39:027 Alteração de Estado: 0- -- 31/10 14:58:39:027 14:58:39:027 RX <- (Bloco) = [STX][207]00!0000AI[128][128][146][128][128][ETX]1 -- 31/10 14:58:39:027 TX -> ACK = 6 Falha: 0 -- 31/10 14:59:09:262 RespostaComando: -- 31/10 14:59:09:267 RX <- -- 31/10 14:59:09:267 -- Desativando a porta: COM1 -- 31/10 14:59:09:285 ----------------- ERRO ----------------- Impressora SwedaSTX não está respondendo ---------------------------------------- O estranho é que em testes com a Daruma FS600/FS700 e Bematech 2100 não tivemos problema e em alguns casos até mesmo na Sweda conseguimos imprimir, 1 em cada 8 tentativas. Gostaríamos da opinião de vocês para este caso. O log completo eu anexei abaixo. Desde já agradeço. 20161031.ecflog

Realmente Daniel, Observamos, por exemplo, que a Daruma FS700 quando efetuamos Sangria e Suprimento não totaliza esses valores no meio de pagamento DINHEIRO. A Sweda ST120 e a Bematech MP-2100 não computam a sangria no meio de pagamento DINHEIRO, mas em contrapartida o suprimento é computado. A idéia que tive ao ver os índices de entrada e saída de recurso era que o comprovante ESTORNO não fosse computado no meio de pagamento ou até mesmo ter seu valor abatido do mesmo, mas em conversa com o pessoal da Daruma não é possível. Agradeço a resposta.

Bom dia pessoal, Fizemos no nosso sistema o tratamento para pagamento de fatura de cartão da SIGACRED e da CONDUCTOR além do correspondente bancário. Até neste ponto perfeito. Foi realizado também uma implementação para caso o operador efetue um cancelamento de pagamento ou estorno de pagamento de conta, sendo emitido um comprovante não-fiscal que foi chamado de ESTORNO. Na Daruma, temos um source que efetua a seguinte validação: ecfDaruma : if not InputQuery('Comprovantes NAO Fiscal '+ACBrECF1.ModeloStr, 'Entre com a String do parametro "Tipo".'+sLineBreak+ 'V Comprovante Vinculado'+sLineBreak+ '+ Entrada de Recursos'+sLineBreak+ '- Saida de Recursos'+sLineBreak+sLineBreak+ 'Se vazio assume Default = "V"'+sLineBreak+ 'Informe Apenas uma das Opçoes', cTipo ) then exit ; Programamos utilizando a opção '- Saída de Recursos', mas em debug observei que a variável 'fpMFD' entra como TRUE no procedimento, logo entrando no bloco abaixo: else if fpMFD then begin if AchaCNFDescricao(Descricao, True) <> nil then raise EACBrECFERRO.Create(ACBrStr('Comprovante não fiscal ('+Descricao+') já existe.')) ; if (ProxIndice < 3) or (ProxIndice > 20) then { Indice passado é válido ? } begin For ProxIndice := 3 to 20 do { Procurando Lacuna } begin if AchaCNFIndice(IntToStrZero(ProxIndice,2)) = nil then break ; end ; end ; if ProxIndice > 20 then raise EACBrECFERRO.create(ACBrStr('Não há espaço para programar novas CNFs')); EnviaComando( FS + 'C' + #204 + IntToStrZero(ProxIndice,2) + PadRight(Descricao,15) ) ; CarregaComprovantesNaoFiscais ; end Com isso, o valor(-) que digitei é desconsiderado. Na Bematech não temos esta opção e é incrementado o valor do comprovante na forma de pagamento de qualquer modo. A Sweda leva em consideração o tipo, conforme o bloco: procedure TACBrECFSwedaSTX.ProgramaComprovanteNaoFiscal(var Descricao : String; Tipo: String; Posicao : String); begin { Argumento(s): sinal: Ascii Dec Sinal + 43 Positivo - 45 Negativo Opcional, se omitido é assumido o valor padrão do sinal: + operação Denominação da operação não-fiscal. Alfanumérico - Extensão máxima: 15 caracteres Poderão ser cadastradas, em um único comando, um conjunto de até 30 operações. Nota(s): Operações com sinal negativo não admitem os seguintes registros: - Pagamento; - Identificação do consumidor; - Acréscimo; - Desconto. } EnviaComando('37|'+Tipo+Descricao); end; A dúvida seria: Este indicador de entrada ou saída de recurso quando setado indica se o valor referido no comprovante não-fiscal será acumulado ou não no meio de pagamento utilizado no mesmo? Ou seja, qual seria o impacto deste indicador no meio de pagamento utilizado no comprovante não-fiscal? Ou estou interpretando de maneira equivocada os mesmos? Desde já agradeço a todos.

Bom dia pessoal, No site da SEFAZ existe o seguinte texto referente a atualização da versão 0.07: ATENÇÃO – INSTRUÇÕES PARA ATUALIZAÇÃO DO SOFTWARE BASICO DO SAT (...) Observar o prazo fornecido pela SEFAZ para a realização da atualização após o qual a mesma será realizada de ofício a qualquer momento. Vocês sabem me informar que prazo seria este? Procurei em vários lugares mas não encontrei até quando posso ainda utilizar o layout 0.06.

Bom dia, nos testes que fizemos em debug e posteriormente guardando em tabela os valores do SAT não encontramos divergência. Basicamente, utilizamos o rateio da forma que o ECF executa para desconto ou acréscimo. Segue um link para você ter uma base: https://www.totvs.com/mktfiles/tdiportais/helponlineprotheus/portuguese/loja701_rateio_de_desconto.htm

Show Elias. Ajudou bastante aqui. Clareou em termos técnicos de programação. Agradeço imensamente.

Eu recebi esta documentação deles na página 3 fala sobre o fluxo seguido pelo ACBrTEFD, depois não encontrei mais nada a respeito de como efetuar o pagamento. Algo que percebi é que na tabela está no final "Retorna os serviços: D, I, H e Z.", não sei se ajuda em algo. Interface PDV_SigaCred.doc

Exato. Então, no caso, eu faço este procedimento acima normal e me é impresso o comprovante. Em seguida, por exemplo, eu executaria a função 313 informando o número do documento da transação acima para efetuar a vinculação entre a fatura e o pagamento?

No caso, no fluxo enviamos as informações da identificação do cartão e da fatura que queremos pagar da SIGACRED. Em seguida, de acordo com um contato com a Software Express, após o procedimento do fluxo teríamos que informar a forma de recebimento em que foi efetuado este pagamento de fatura. Por exemplo, no fluxo acima, inserimos um cartão SIGACRED e informamos o número da fatura do mesmo. Em seguida, em algum momento teríamos que informar a forma de recebimento utilizada no caixa(no caso do PDV) para controle financeiro nosso. No TipoCampo 100, que seria a forma utilizada por nós para quitar a fatura, está indo sempre 9900, ou seja, 'Outro tipo de Cartão' e 'Á vista', mas em nenhum momento no fluxo, foi perguntado para inserirmos estes dados.

Daniel, um dos nossos clientes pediu para pagar fatura do cartão SIGACRED pelo PDV, conforme a abertura do chamado no fórum, entramos na opção de "Pagamento de Fatura SigaCred" e seguimos o fluxo do TEF, conforme o ACBrTEFD nos informa. O pessoal da Software Express insiste que o pagamento é desvinculado e temos que informar em separado, estamos nessa faz uma semana. Pelo fluxo que nos é passado, temos: - Informa Valor Total - Tipo do Cartão(Magnético/Digitado) -> Seria um cartão SIGACRED - Opção do menu "Pagamento de Fatura" - Número da fatura referente ao cartão SIGACRED que foi identificado acima Só que assim que informamos o número da fatura, já entra no processo: Aguarde, em processamento...(35) Em seguida: Transacao OK E já temos a impressão dos relatórios gerenciais referentes ao código 121 e 122 e a transação é CONFIRMADA. Pelo log, analisamos que a forma em que foi paga a fatura, foi: -- 09/09 09:37:51:345 - ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 0 TipoCampo = 100 Buffer = 9900 Tam.Min = 0 Tam.Max = 0 -- 09/09 09:37:51:345 - ContinuaFuncaoSiTefInterativo, Chamando: Continua = 0 Buffer = -- 09/09 09:37:51:347 - ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 0 TipoCampo = 101 Buffer = Outro Tam.Min = 0 Tam.Max = 0 -- 09/09 09:37:51:347 - ContinuaFuncaoSiTefInterativo, Chamando: Continua = 0 Buffer = -- 09/09 09:37:51:349 - ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 0 TipoCampo = 102 Buffer = Outro Tam.Min = 0 Tam.Max = 0 Só que em nenhum momento do fluxo, informamos ou até mesmo foi pedido a forma de recebimento do PDV em que foi recebida esta fatura. Estou anexando o log completo do fluxo e também o arquivo da transação pendente. Se puder nos ajudar em alguma sugestão, seria de grande auxílio. Desde já agradeço. Teste-Implantação-SIGACRED.TXT TEF-Dados-SIGACRED.TXT

Realmente, verifiquei aqui ontem, obtive pelo campo: with ACBrTEFD.TEFCliSiTef do begin ... DocumentoFiscal := Resp.DocumentoVinculado; DataHoraFiscal := Resp.DataHoraTransacaoLocal; end;

Daniel, bom dia. Estava debugando os dados de entrada para a função citada acima: xIniciaFuncaoSiTefInterativo Eu tenho que enviar no caso o mesmo número do documento para que o TEF associe com os dados da fatura, no caso o terceiro parâmetro de entrada. Não estou encontrando onde o mesmo é guardado para eu poder capturar e ao abrir o próximo fluxo informar novamente o mesmo Documento. with ACBrTEFD.TEFCliSiTef do begin OperacaoADM := 313; //Pagamento de conta genérico with ParametrosAdicionais do begin Clear; Add('1:3000;'); end; ADM; end; Estou tentando efetuar um teste simples em dinheiro de R$ 30,00.

Blz Daniel, vou tentar aqui.

Boa tarde pessoal, Estamos tentando implementar o recebimento de fatura do cartão SigaCred no nosso PDV com o módulo da SigaCred disponibilizado pela Software Express. Instalamos o módulo e adicionamos as configurações adicionais e entramos no fluxo do TEF. Conseguimos enviar todos os dados da referida fatura. Mas não é pedido no fluxo as informações do pagamento. Em contato desde hoje de manhã com a Software Express, conseguimos a informação de que a maneira como este pagamento é realizado é desvinculado do fluxo da fatura, ou seja, temos que efetuar uma nova chamada para a função 'IniciaFuncaoSiTefInterativo' com os mesmos dados que obtivemos os dados da fatura, informando o código da forma de pagamento que escolhemos para finalizar corretamente a transação(Acredito que a função 1/2/3 - Especificação Técnica - Página 10- Versão 127). Estive analisando o source da unit 'ACBrTEFDCliSiTef', e na chamada da função 'FazerRequisicao' temos o source com os respectivos dados que precisamos enviar com um código de função diferente no caso: Result := xIniciaFuncaoSiTefInterativo( Funcao, PAnsiChar( ValorStr ), PAnsiChar( Documento ), PAnsiChar( DataStr ), PAnsiChar( HoraStr ), PAnsiChar( fOperador ), PAnsiChar( ListaRestricoes ) ) ; Mas desconheço o modo de efetuar esta chamada, utilizando o componente ACBrTEFD. Gostaria da ajuda de vocês. Desde já agradeço.

Só retornando, conforme até um esclarecimento que recebemos da própria Sweda, a carta se refere ao fato de que caso o horário esteja errado, pode ser que alguns cupons pelo problema descrito, não envie os CF-e dentro dos 10 dias previstos na especificação, invalidando os mesmos. É somente uma informação de alerta.

Boa tarde pessoal, Um dos nossos clientes recebeu exatamente a mesma carta descrita acima. Não temos problema com nenhuma restrição para protocolo NTP. Segundo o suporte da Bematech, teríamos que fazer um levantamento dos cupons que foram rejeitados com erro 241 para passar para o contador os XMLs para que o mesmo emitisse uma justificativa junto a SEFAZ. Acessamos o SGR-SAT pelo menu (Consulta CFe com Erro -> Filtro: Erro: 241) e não retorna nenhum resultado. Testamos com intervalos de 30 dias começando 5 meses atrás. Segundo o nosso banco de dados, apenas um CF-e teve uma diferença superior a 5 minutos entre o horário que aparece na chave do CFe e o horário do computador, mas isto foi dia 04/07/2016. Entramos em contato com a SEFAZ de SP pelo 0800 que ela disponibiliza no site. Segundo eles, temos que pedir ao contribuinte para levar a carta até a receita da cidade para receber maiores instruções e no caso de uma pergunta mais técnica, temos que perguntar pelo correio eletrônico disponibilizado no próprio site. No nosso caso, a carta foi emitida dia 17/08/2016 e nos foi passado hoje o problema(24/08/2016). Pela própria carta, temos 10 dias para efetuar a correção. Alguém conseguiu alguma informação adicional a respeito deste assunto? Estamos tentando identificar corretamente qual poderia ser o problema para tratarmos. Desde já agradeço.

Daniel, analisando o log aqui, se não estou enganado, parece que este problema ocorre quando eu chamo na minha aplicação o comando 'DadosUltimaReducaoZ'. Segue: -- 02/08 13:39:55:265 -- Ativando a porta: COM1 -- 02/08 13:39:55:265 DadosUltimaReducaoZ -- 02/08 13:39:55:265 TX -> {101;LeData;NomeData="Data";27} -- 02/08 13:39:55:468 RX <- {101;0;ValorData=#02/08/2016#;29} -- 02/08 13:39:55:468 -- Desativando a porta: COM1 Pois acredito que se fosse decorrente da emissão da redução Z 'normal'(Sem ler os dados da última redução emitida), outro colaborador já teria manifestado o problema com a DataRegis. Como o ECF foi para intervenção vou aguardar para fazer um teste omitindo esta chamada.

Daniel, Estava verificando aqui com o pessoal do suporte e é a primeira vez que é utilizado o ECF para emissão da Redução Z. No caso, o cliente possui dois caixas e o outro é uma Bematech. O cliente instalou o sistema nos dois caixas, mas só utilizou o da Bematech. Agora que ele utilizou este ECF e está tentando emitir a Redução Z. Liguei para a DataRegis, e o pessoal do suporte não soube passar nenhuma informação a respeito de desenvolvimento, parece que no momento eles estão só com a parte de suporte a hardware. Fui instruído a pedir para o cliente, na intervenção, pedir para efetuar um teste de venda e um de Redução Z. Vou aguardar e qualquer novidade reporto para você.

Entendi. Será que se eu fizer esta modificação na minha cópia da ACBr só pra fazermos um teste poderia resolver? Segue: function TACBrECFFiscNET.GetTotalDescontosISSQN: Double; begin Result := IfThen(pos(fsModeloECF,'3202DT') > 0, 0, LeMoeda( 'TotalDiaDescontosISSQN' )); end; Será que este problema de não retornar este registrador seria a versão do firmware do ECF do cliente?

Boa tarde pessoal, Temos um cliente que possui um ECF DataRegis 3202DT v01.00.73 e quando o cliente foi emitir a redução Z hoje, aconteceu o seguinte erro: -- 02/08 15:19:13:765 -- Ativando a porta: COM1 -- 02/08 15:19:13:765 TotalDescontosISSQN -- 02/08 15:19:13:765 TX -> {2;LeMoeda;NomeDadoMonetario="TotalDiaDescontosISSQN";53} -- 02/08 15:19:13:999 RX <- {2;11011;NomeErro="ErroProtNomeRegistrador" Circunstancia="Parametro NomeDadoMonetario contem nome de registrador inexistente";126} -- 02/08 15:19:13:999 -- Desativando a porta: COM1 -- 02/08 15:19:14:015 ----------------- ERRO ----------------- Erro retornado pela Impressora: FiscNET: DATAREGIS - 3202DT Erro: 11011 - ErroProtNomeRegistrador Parametro NomeDadoMonetario contem nome de registrador inexistente ---------------------------------------- -- 02/08 15:19:14:015 -- Ativando a porta: COM1 -- 02/08 15:19:14:015 Estado -- 02/08 15:19:14:015 TX -> {3;LeInteiro;NomeInteiro="EstadoFiscal";39} -- 02/08 15:19:14:218 RX <- {3;0;ValorInteiro=1;19} -- 02/08 15:19:14:218 -- Desativando a porta: COM1 Com isso, o nosso sistema disparou o erro abaixo não emitindo a Redução Z: [02/08/2016 15:19:14] Problema na emissão da Redução Z! Impossível continuar o procedimento. + ERRO: Erro retornado pela Impressora: FiscNET: DATAREGIS - 3202DT Erro: 11011 - ErroProtNomeRegistrador Parametro NomeDadoMonetario contem nome de registrador inexistente - MARCA DO ECF: FISCNET: DATAREGIS - 3202DT - MODELO DO ECF: 3202DT O mais estranho é que pelo log, acredito que no mesmo fluxo da redução Z, segundos antes, ocorreu outro erro mas não impediu que continuasse o processo: -- 02/08 15:18:44:374 -- Ativando a porta: COM1 -- 02/08 15:18:44:374 -- 02/08 15:18:44:374 TX -> {219;LeMeioPagamento;CodMeioPagamentoProgram=14;47} -- 02/08 15:18:44:562 RX <- {219;8014;NomeErro="ErroCMDFormaPagamentoIndefinida" Circunstancia="Meio de pagamento nao carregado";100} -- 02/08 15:18:44:562 -- Desativando a porta: COM1 -- 02/08 15:18:44:577 ----------------- ERRO ----------------- Erro retornado pela Impressora: FiscNET: DATAREGIS - 3202DT Erro: 8014 - ErroCMDFormaPagamentoIndefinida Meio de pagamento nao carregado ---------------------------------------- -- 02/08 15:18:44:577 -- Ativando a porta: COM1 -- 02/08 15:18:44:577 LerTotaisFormaPagamento -- 02/08 15:18:44:577 TX -> {220;LeMoeda;NomeDadoMonetario="TotalDiaDinheiro";49} -- 02/08 15:18:44:796 RX <- {220;0;ValorMoeda=0,0000;24} -- 02/08 15:18:44:796 -- Desativando a porta: COM1 Estou anexando o log do ECF referente a este problema. Será que é algum tratamento que deveríamos fazer ou o ECF está retornando algo inesperado? Gostaríamos da opinião de vocês a respeito deste caso. Desde já agradeço. 20160802.log

Boa tarde, Ainda dentro do correspondente bancário, observei o Daniel reportando em outro tópico que ao informar o código de barras, temos que utilizar o 0 ou 1, na frente do mesmo ao enviar para o fluxo do TEF. Pelo que li nos manuais, seria 0 para indicar que foi digitado e 1 para indicar que foi utilizado um scanner para ler a informação. Infelizmente não entendi, qual seria a utilidade da distinção deste tipo de processo. Nos meus testes estou utilizando 0 sempre. Enviei um e-mail para a Software Express e ainda não recebi retorno. Estou dando continuidade dentro deste tópico, caso seja necessário abro outro. Desde já agradeço.

Entendi. Vou ler o manual e verificar aqui a implementação. Agradeço a atenção Daniel e Elias.

Exato Daniel, estou utilizando a seguinte instrução para habilitar o correspondente: ACBrTEFD.TEFCliSiTef.OperacaoADM := 310; Vou verificar no log se temos algum campo que retorne o troco neste caso. Agradeço.

Boa tarde, no caso de passarmos um valor acima que o valor a ser pago, exemplo: Boleto: R$80,00 Recebido: R$100,00 Troco:R$20,00 Pelo debug verifiquei que na unit 'ACBrTEFDCliSiTef.pas' na linha 1304, no source: 22 : begin if Mensagem = '' then Mensagem := CACBrTEFD_CliSiTef_PressioneEnter; DoExibeMsg( opmOK, Mensagem ); end ; Temos o retorno 'Troco: 20,00' exibido em tela. Haveria algum modo de disponibilizar este valor para a aplicação para ser posteriormente guardado no banco de dados?