[Componente ACBrTEFAPI - Modelo tefScopeAPI]

Ok. Entendi, vou verificar isso com o pessoal.

[Componente ACBrTEFAPI - Modelo tefScopeAPI]

Olá @Daniel Simoes

Certo, farei os testes.

Uma duvida, esses ajustes realizados agora permitem realizar o parcelamento também nas vendas de débito? Para mim a parte do crédito já estava requisitando o tipo de financiamento e a quantidade de parcelas.

[Componente ACBrTEFAPI - Modelo tefScopeAPI]

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?

[Componente ACBrTEFAPI - Modelo tefScopeAPI]

Perfeito, Obrigado pelo retorno @Daniel Simoes

Sim, pelo que testei os métodos criados no TEFAPI da Scope já conseguem enviar imagem para o PinPad sem utilizar o componente ACBrAbecsPinPad e também sem ocorrer problema de porta COM ocupada. O método ExibirQRCodePinPad indica ser a solução para isso.

[Componente ACBrTEFAPI - Modelo tefScopeAPI]

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.

[Componente ACBrTEFAPI - Modelo tefScopeAPI]

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!

[Componente ACBrTEFAPI - Modelo tefScopeAPI]

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?

[Componente ACBrTEFAPI - Modelo tefScopeAPI]

Olá @Daniel Simoes

Você implementou no componente TAcBrAbecsPinPad ou outro similar a possibilidade de enviar imagens para o visor do PIN PAD utilizando o TEF da Scope? 

 

[TACBrAbecsPinPad]

Obrigado pelo retorno @Daniel Simoes

Sem problemas, é mais para ter conhecimento sobre os possíveis recursos.

[TACBrAbecsPinPad]

Entendi @Daniel Simoes

Aproveitando tirar a duvida, no caso relacionado com o TEF Scope. Será permitido enviar imagens ao PIN PAD pelo componente TAcBrAbecsPinPad para quem utilizar tef SCOPE ou não tem relação com isso? 

[TACBrAbecsPinPad]

Olá @Daniel Simoes

Verifiquei que saiu uma nova versão do componente. Essa nova versão teve algum ajuste nessa funcionalidade de poder enviar imagem para o PIN PAD?

[Componente ACBrTEFAPI - Modelo tefScopeAPI]

Obrigado @Daniel Simoes

Quando vocês concluírem esse projeto da integração Scope, vocês irão emitir um comunicado?

[Componente ACBrTEFAPI - Modelo tefScopeAPI]

Obrigado pelo retorno @Daniel Simoes

Apenas uma duvida, verifiquei que existe nos fontes do ACBR o componente TEFDDialScopeGetcard que seria a comunicação por troca de arquivos. Poderia me informar se ele ainda está ativo e se consigo realizar transações PIX através do componente?

[Componente ACBrTEFAPI - Modelo tefScopeAPI]

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!

[TACBrAbecsPinPad]

Olá @Daniel Simoes

Segue o link do ticket:

https://dev.proj.setis.com.br/servicedesk/customer/portal/16/SCP-1184

Essa foi a última resposta:

[TACBrAbecsPinPad]

Bom dia @Daniel Simoes

Pelo Status da Setis, apareceu que foi modificado para "Não será feito". Pode me confirmar se essa funcionalidade realmente não será implementada?

[TACBrAbecsPinPad]

Olá!

A Setis respondeu que não será realizado isso esse ano. Por enquanto sem previsão de quando será implementado

[TACBrAbecsPinPad]

Obrigado pelo retorno @Daniel Simoes

Entendi. Vou acompanhar essa solução pelo Jira.

[TACBrAbecsPinPad]

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.

[Dúvida ao resgatar uma propriedade NSU BERGS para a adquirente VERO]

Ótimo! vou enviar o e-mail.

[Dúvida ao resgatar uma propriedade NSU BERGS para a adquirente VERO]

Na verdade eu não consegui fazer esse teste porque só pode ser feito em produção. O cliente reclamou porque viu que o campo estava em branco algumas vezes. 

Nesse caso, a melhor forma de contatar a VERO seria através do próprio cliente?

[Dúvida ao resgatar uma propriedade NSU BERGS para a adquirente VERO]

Daniel,

Verifique esse post que fiz acima, anexando os logs. Quando for uma transação do tipo crédito, sempre carrega. Nos casos quando for uma transação de Débito, em alguns momentos não carrega.

Não entendi a lógica desse caso. Existe algum motivo para isso?

Segue o post acima:

 

[Dúvida ao resgatar uma propriedade NSU BERGS para a adquirente VERO]

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

[Dúvida ao resgatar uma propriedade NSU BERGS para a adquirente VERO]

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

[Dúvida ao resgatar uma propriedade NSU BERGS para a adquirente VERO]

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.

adee361266c9e28345c457c914e55a1f.pdf34af7d2f04b0d563a17be5ec012c5f04.pdf