WINDEL

Ok. Entendi, vou verificar isso com o pessoal.

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.

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?

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.

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.

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!

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?

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?

Obrigado pelo retorno @Daniel Simoes Sem problemas, é mais para ter conhecimento sobre os possíveis recursos.

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?

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?

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

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?

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!

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:

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?

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

Obrigado pelo retorno @Daniel Simoes Entendi. Vou acompanhar essa solução pelo Jira.

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.

Ótimo! vou enviar o e-mail.

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?

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:

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

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

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