Ir para conteúdo
  • Cadastre-se

WINDEL

Membros Pro
  • Total de ítens

    445
  • Registro em

  • Última visita

  • Days Won

    1

Posts postados por WINDEL

  1. Mais uma duvida @Daniel Simoes quanto ao TEF da Scope.

    Estou realizando os testes no pagamento de débito e percebi que existe uma diferença quanto ao pagamento do débito da Paygo. 

    Na Paygo quando não especifica o tipo de financiamento para o Débito, abre um menu para selecionar o tipo de financiamento: A vista, parcelado, etc.

    No TEF da Scope, quando seleciona a modalidade de pagamento Débito, mesmo não especificando a modalidade de financiamento, ele sempre seleciona a forma A vista. 

    Existe alguma forma ou parâmetro para que seja apresentado um menu com o tipo de financiamento na modalidade do Débito também?

  2. Certo @Daniel Simoes,

    Então ambas as rotinas enviam a imagem para o visor do PIN PAD através da Porta COM?

    Se for esse o caso, então pode ser que a mensagem de erro do "Acesso negado" significa que como a comunicação do PIN PAD ainda está aberta com o TEF, não é possível ativar uma nova comunicação com o componente ACBrAbecsPinPad para enviar a imagem?

    Estou apenas tentando entender as diferenças.

  3. Obrigado pelo retorno @Daniel Simoes e @Pedro Frayman!!

    Queria só trocar mais uma ideia rápida contigo @Daniel Simoes sobre o envio da imagem para o visor do PIN PAD utilizando o TEF da Scope.

    Verifiquei que no projeto TEFAPIDemo tem dois exemplos:

    1- O primeiro está usando o método "ACBrTEFAPI1.ExibirQRCodePinPad". Pelo que testei, esse método está funcionando corretamente, porém não faz o envio através de uma porta COM. Esse parece ser interessante porque não ocupa a porta COM do PIN PAD e assim é possível utilizar juntamente com transações de cartão TEF sem conflito.

    2- O outro método "btExibirImagemPinPadClick" também envia a imagem para o PIN PAD, porém utiliza a porta COM através do componente ACBrAbecsPinPad. Esse também funciona, mas precisa estar com o TEF desativado para utilizar a questão do envio da imagem. Pois, senão ocorre o erro de "Acesso negado" porque a porta já está ocupada.

    A minha duvida seria se posso usar qualquer um dos métodos que irá mostrar a imagem no PIN PAD. Pois, me parece mais prático utilizar o item 1 para quem utiliza o TEF juntamente com o envio de imagens. Só queria tirar a duvida se existe algum possível efeito colateral em utilizar ele juntamente com o TEF.

    Obrigado novamente pela atenção!

  4. Obrigado pelo retorno @Daniel Simoes

    Queria tirar apenas mais uma duvida contigo. Quanto a parte de exibição de imagens no TEF da Setis/Paygo. Esses foram implementados? Acompanhei um tempo atrás que eles até foram implementados, mas causava conflitos caso fossem utilizados juntamente com as transações de TEF. 

    Por enquanto a Setis ainda não implementou os métodos?

  5. Olá,

    Verifiquei através dos fontes do ACBr que está sendo desenvolvido um modelo denominado "tefScopeAPI" no componente ACBrTEFAPI, o que seria a comunicação do TEF via dll. Gostaria de tirar uma duvida, nesse caso o objetivo será criar uma parceria da ACBR com a SCOPE ou a ideia seria que esse modelo seja disponibilizado gratuitamente?

    Além disso, existe algum componente da ACBR que ainda utiliza o TEF de modo tef_dial por troca de arquivos?

    Obrigado pela atenção!

  6. Olá @Daniel Simoes

    Quando você tiver um tempo, conseguiria verificar se existe uma solução para esse meu report que fiz em 01/04?

    Testei essa função de capturar o cpf/cnpj via PIN PAD na versão 5.1.30.0 e funcionou corretamente em modo de homologação. Pedirei para os técnicos testarem em produção.

    Então faltaria apenas não apagar as respostas quando é desativado a comunicação do tef com a dll para poder utilizar o componente Abespinpad, pois o componente faz uma função muito importante para o uso do PIX com QRCode.

    Isso nos ajudaria bastante se esse componente pudesse ser utilizado.

    • Curtir 1
  7. Sim, mas mesmo assim nesse caso tem que informar o codigoautorizacaotransacao. Tem dois parametros, o NSU e codigo de autorização da transação. Você usa a propriedade TACBrTEFResp.NSU para ambos os casos??  Eu sempre utilizei a propriedade codigoautorizacaotransacao e sempre funcionou, exceto nesse exemplo da vero.

     function CancelarTransacao(
          const NSU, CodigoAutorizacaoTransacao: string;
          DataHoraTransacao: TDateTime;
          Valor: Double;
          const CodigoFinalizacao: string = '';     // Parâmetro Opcional
          const Rede: string = ''): Boolean;		// Parâmetro Opcional
  8. Daniel,

    Não sei se esse campo "NSU BERGS" seria o correspondente para o código de autorização da transação. Me parece que o correto seria o NSU BANDEIRA.

    Mas nesses casos que está em branco, parece que a Adquirente vero não está devolvendo o valor. Olhe o exemplo do NSU 00516804 que o código da autorização está vazio.

    TRANSACAO AUTORIZADA
    11:15:47:899 0x43=1
    11:15:47:899 0x44=5221
    11:15:47:899 0x45=00516804
    11:15:47:899 0x47=00
    11:15:47:899 0x4B=BANRICOMPRAS
    11:15:47:899 0x53= ------------ 1 via - loja -----------

    DATA: 01/06/2024          HORA: 11:15:00
    NSU BERGS: 00516804
    CARTAO: 1148               VALOR: 245,00
     

    E verifique o exemplo do NSU 00323709 que o código de autorização da transação está com o valor 017585

    TRANSACAO AUTORIZADA
    10:20:26:165 0x43=1
    10:20:26:165 0x44=5212
    10:20:26:165 0x45=00323709
    10:20:26:165 0x46=017585
    10:20:26:165 0x47=00
    10:20:26:165 0x4B=MASTERCARD
    10:20:26:165 0x53= ------------ 1 via - loja -----------

    DATA: 01/06/2024          HORA: 10:19:37
    NSU BERGS:00323709   NSU BANDEIRA:017585
    CARTAO: 6172                VALOR: 80,07

    Nesse caso, caso for preenchido o valor errado para o codigo de autorização da transação, não é possível efetuar o cancelamento da transação automático porque o parâmetro de cancelamento é informado incorretamente.

    Segue em anexo o arquivo de log com esse conteúdo

    comms_240601.log

  9. Mas nesse caso o valor da propriedade TACBrTEFResp.NSU seria o mesmo do NSU BERGS do comprovante? Conforme os e-mails informados pela equipe da ACBR (pdf em anexo), está sendo indicado para puxar esse valor do comprovante.

    Aproveito explicar o motivo que preciso gravar esse código de autorização da transação corretamente. Eu preciso dele principalmente para poder cancelar automaticamente a transação caso seja necessário. Para cancelar a transação de forma automática é necessário utilizar o seguinte comando, informando corretamente os parâmetros.

    FACBRTefAPI.CancelarTransacao(NSU, CodigoAutorizacaoTransacao, DataHoraTransacao, Valor, CodigoFinalizacao, Rede);

    Dessa forma, eu puxo os valores que salvei no banco de dados e quando o usuário clicar no botão cancelar, vou acionar o comando puxando os valores gravados no banco de dados. Isso evita que quando seja necessário cancelar a transação, o usuário tenha que pegar o comprovante, entrar no painel administrativo e informar manualmente os dados um a um, o que não é nada prático.

    Com isso, preciso gravar corretamente o valor do código de autorização da transação. Eu estava sempre utilizando a propriedade "RespostaTEF.CodigoAutorizacaoTransacao", porém para esse caso da VERO, nem sempre a propriedade está sendo carregada e o pessoal passou essa sugestão de utilizar esse outro campo como alternativa. 

    Note na imagem abaixo que algumas vezes a propriedade "CodigoAutorizacaoTransacao" vem com o valor informado, outras vezes não. Por isso foi passado essa sugestão pela equipe da ACBR.

    image.thumb.png.b83ef9152949c421b59ef8299ddc8882.png

    adee361266c9e28345c457c914e55a1f.pdf34af7d2f04b0d563a17be5ec012c5f04.pdf

     

×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.