Jump to content
Notícias do ACBr

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

consultoria_sticker.png

Conteúdo para desenvolvedores
 ao vivo de terça a quinta!
Saiba mais

dev.png

logo_acbr_paygo.png

TEF ACBr PayGo
Seja um revendedor e ofereça uma solução completa para seu cliente.


Saiba mais

beneficios.png

Leonardo Fossati Silveira

Usuários SAC
  • Content Count

    14
  • Joined

  • Last visited

Community Reputation

2 Neutral

About Leonardo Fossati Silveira

  • Rank
    Novato

Contact Methods

  • Website URL
    http://www.intelsystems.com.br

Profile Information

  • Sexo
    Masculino
  • Location
    Pelotas

Recent Profile Visitors

455 profile views
  1. Ola, obrigado pelo retorno. Adicionei o parâmetro, mas mesmo assim o problema ocorre. Até mesmo se eu não chamar os métodos de imprimir texto, como no exemplo abaixo: ETQ.Ativar() ETQ.IniciarEtiqueta() ETQ.Imprimir(1) ETQ.FinalizarEtiqueta(1,0) ETQ.Desativar()
  2. Boa tarde, pessoal, estamos iniciando o uso da acbr. Nossos primeiros testes foram como MonitorPlus e comandos de etiquetas. O erro ue aparece é "ERRO: "" is an invalid integer" no comando ETQ.Imprimir(). Isto ocorre até mesmo com os exempos da documentação. Segue abaixo em anexo como configuramos o monitor.
  3. Certo, obrigado pela atenção. Vou entrar em contato com eles e qualquer coisa, reporto aqui.
  4. Sim, foi isto que pensei. Mas não é o que o roteiro solicita e por isso fiquei em dúvida. Pelo que entendi, eles querem que a transação seja RECUPERADA, já que ficou pendente mas foi aprovada e neste caso,bastaria finalizar e reimprimir. Faz sentido isso?
  5. Pessoal, estou implementando o roteiro de homologação TEF junto a Cappta, e estou com a seguinte dúvida: Na sequência 19, solicitam o desligamento do computador, ligar o pc e manter a impressora desligada e tentar enviar o comando "Finalizar" e posteriormente tentar reimprimir o cupom. Pelo que entendi, o objetivo do teste é tentar "recuperar" a transação abortada pelo desligamento. Entretanto, utilizando os componentes acbr, o mecanismo naturalmente chama o "cancelamento" da operação pendente (ao iniciar a aplicação e ativar o componente). A implementação que desenvolvi, seguiu
  6. Talvez possa ser alguma versão nova da Cappta, alguma configuração específica que eles fizeram no meu ambiente ou por ser um ambiente de testes. A alteração que fiz foi no arquivo ACBrTEFDClass.pas, linha 1341 (em anexo). Gostaria de saber se esta modificação está correta ou se pode quebrar alguma outra parte do código visto que ainda não domino todos os fontes. ACBrTEFDClass.pas
  7. Consegui descobrir, e acho que isso vai colaborar com todos: Imagino que o problema estava no padrão utilizado para a geração do arquivo intpos, pelo gerenciador padrão. Usamos a solução Cappta, que intermedia e encapsula os demais gerenciadores padrões. Talvez a forma como eles criaram este arquivo, não esteja sendo tratada pelas classes acbrtef. Vamos aos fatos: 1. Problema: o método "ImprimirRelatorio" não era chamado de forma alguma. Como o envio CNF está dentro do método "ImprimirRelatorio" então a transação também não estava sendo confirmada.; Veja o método ProcessarResposta (AC
  8. Sim, estou realizando os seguintes passos: 1. abro o programa TEFdemo.exe; 2. inicializo a impressora e o gerenciador padrão tefdial; 3. clico no botão "ADM"; 4. o gerenciador padrão é invocado na tela administrativa; 5. escolho a opção "Cancelamentos"; 6. informo senha, valor, n. controle e insiro e retiro o cartão; 7. neste momento, o gerenciador padrão abre uma tela informando que a transação foi aprovada e o metodo "OnExibeMensagem" é chamado. A mensagem é "APROVADA: 017503 IMPRIMINDO..."; 8. mensagem "adm executada com cesso"; 9. Neste momento, a tela do gerenciador padrão
  9. Sim. Porém em nenhum momento a operação CNF foi executada e, consequentemente a tela do gerenciador padrão não foi fechada, aguardando a confirmação. Não sei se o demo faz isso, mas sei que a função ImprimirRelatorio gera o comando para impressão e executa o CNF. No caso do cancelamento via ADM, nem a impressao nem o CNF são chamados. Na linha de código abaixo, a mensagem " APROVADA: 017503 IMPRIMINDO..." é invocada no código que está em vermelho (abaixo). Mesmo que a mensagem informe que está imprindo, nenhum comando de impressão é chamado e o processo finaliza ali. O demo imprime o cancelam
  10. -- 18/12 16:23:04:146 - TEF_DIAL Inicializado -- 18/12 16:23:04:148 - TEF_DIAL CancelarTransacoesPendentesClass -- 18/12 16:23:04:150 - TEF_DIAL IniciarRequisicao: ATV -- 18/12 16:23:04:154 - TEF_DIAL FinalizarRequisicao: ATV, Fechando arquivo: C:\TEF_DIAL\req\intpos.tmp -- 18/12 16:23:04:187 - TEF_DIAL FinalizarRequisicao: ATV, Renomeando: C:\TEF_DIAL\req\intpos.tmp para: C:\TEF_DIAL\req\intpos.001 -- 18/12 16:23:04:189 - TEF_DIAL FinalizarRequisicao: ATV, Aguardando: C:\TEF_DIAL\resp\intpos.sts -- 18/12 16:23:04:447 - TEF_DIAL FinalizarRequisicao: ATV, Fim da Espera de: C:\TEF_DIAL\resp\int
  11. Sim, os testes estão sendo feitos utilizando o demo do ACBrTEFD. O problema ocorre sim no demo. Informamos o tipo gpTEfDial.
  12. Pessoal, estamos iniciando os roteiros de homologação utilizando as classes acbr. Estamos nos baseando no exemplo TEFDemo para implementarmos a nossa solução. Ao realizarmos o item que fala do cancelamento através da ADM, tivemos o seguinte problema: 1. realizamos uma transação normal de débito e tudo ocorre perfeitamente; 2. acionamos a ADM do gerenciador padrão; 3. selecionamos a opção "Cancelamento"; 4. informamos o valor da transação a ser cancelada; 5. informamos o número de controle da transação a ser cancelada; 6. neste momento, a tela do gerenciador padrão não é finalizad
×
×
  • Create New...