WINDEL

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

comms_240607.log Segue um exemplo de log: VERO - MASTERCARD VENDA CREDITO A VISTA CONFEITARIA CNPJ: 91.814.558/0001-66 CAXIAS DO SUL 041135200600000 00650348 DATA: 07/06/2024 HORA: 08:04:18 NSU BERGS:00092453 NSU BANDEIRA:040051 CARTAO: 8196 VALOR: 64,94 Esse retorno está vindo da PAYGO.

Estou verificando uma situação em que o código da autorização às vezes não é preenchido quando faço transações com a rede VERO. O suporte entrou em contato com a ACBR e foi informado para utilizar o campo "NSU BERGS" ao invés do Código de Autorização. Porém, estou verificando os campos da resposta tef e não existe esse campo para que salvar a informação no meu banco de dados. Qual seria o campo correspondente do "RespostaTEF.CodigoAutorizacaoTransacao" que estou utilizando atualmente? Estou puxando esses dados no evento "ACBrTEFAPIQuandoFinalizarTransacao". Temos a propriedade "RespostaTEF.ImagemComprovante1aVia" que mostra todo o comprovante em uma Stringlist, porém terei que percorrer a lista e utilizar o comando copy e pos, o que não seria algo muito interessante para fazer. Existe alguma solução mais correta para esse caso? Segue na sequência o conteúdo do campo que preciso puxar a informação: 083-000 = ------------ 1 via - loja -----------\x0D\x0A\x0D\x0AVERO - ELO \x0D\x0AVENDA CREDITO A VISTA\x0D\x0A\x0D\x0ACONFEITARIA \x0D\x0ACNPJ: 91.814.558/0001-66\x0D\x0ACAXIAS DO SUL\x0D\x0A\x0D\x0A041135200600000 00650348\x0D\x0A\x0D\x0ADATA: 07/06/2024 HORA: 14:19:25\x0D\x0ANSU BERGS:00950720 NSU BANDEIRA:692633\x0D\x0ACARTAO: 7103 VALOR: 88,40\x0D\x0A\x0D\x0A\x0D\x0ACREDITO\x0D\x0A02-0009-77B53AB3B38046B9\x0D\x0AA000000494101001 \x0D\x0A\x0D\x0A--------------------------------------\x0D\x0A6037097 EC:0000730637 REF:0000005338 084-000 = ----------- 2 via - Cliente ---------\x0D\x0A\x0D\x0AVERO - ELO \x0D\x0AVENDA CREDITO A VISTA\x0D\x0A\x0D\x0ACONFEITARIA \x0D\x0ACNPJ: 91.814.558/0001-66\x0D\x0ACAXIAS DO SUL\x0D\x0A\x0D\x0A041135200600000 00650348\x0D\x0A\x0D\x0ADATA: 07/06/2024 HORA: 14:19:25\x0D\x0ANSU BERGS:00950720 NSU BANDEIRA:692633\x0D\x0ACARTAO: 7103 VALOR: 88,40\x0D\x0A\x0D\x0ACREDITO\x0D\x0A02-0009-77B53AB3B38046B9\x0D\x0AA000000494101001 \x0D\x0A\x0D\x0A--------------------------------------\x0D\x0A6037097 EC:0000730637 REF:0000005338

Ok! Sim, isso realmente está acontecendo mesmo. Quando utilizo a função de obter dados do pin pad para capturar o valor do cpf/cnpj que o cliente digitou, ocorre uma mensagem de erro no visor com o conteúdo "Processando.." ou dependendo da ocasião até trava o sistema e tem que finalizar pelo gerenciador de tarefas. Certo, vou aguardar primeiramente essa solução que é mais importante e urgente.

Olá Daniel, Tem alguma notícia sobre essa informação do TEF não apagar as respostas quando é desativado a comunicação com a dll?

Obrigado pelo retorno Daniel. Acredito que isso seria a única pendência que falta para que funcione o TEF junto com o Abecs. Fico no aguardo.

Olá Daniel, Fiz alguns testes com a nova dll e utilizando os comandos acima de DesInicializar e Inicializar e não ocorreu mais o erro de "Acesso Negado". Porém, quando utilizo mais de uma transação tef, apenas imprime a última transação. Segue os passos que simulei e o log do componente ACBR em anexo. - Realizei uma transação de tef de 1,00 (comprovante aparece no log) - Acionei o comando de DesInicializar. - Mostrei o QRCode no visor do Pin Pad (sem utilizar o tef). - Acionei o comando de Inicializar. - Realizei mais uma transação de crédito de 0,50 (comprovante aparece no log) - Utilizei o comando "ImprimirTodosComprovantes" e percebi que o array "RespostasTEF" contém apenas 1 resposta (a última). A anterior foi desprezada e assim consigo imprimir apenas o último comprovante. Seria possível ter uma forma de não apagar a resposta anterior? log.txt

Isso marcelo, entendi o seu exemplo que a intenção era mostrar que dessa forma liberava o pin pad para utilização de outros comandos. Mas para produção não é possível utilizar dessa forma. vou primeiramente atualizar a nova versão do tef PGWebLib que o Daniel comentou acima para ver se dessa forma possa resolver esse problema de acesso negado por motivo da porta continuar em uso.

Estou realizando esses testes de utilizar a comunicação com o TEF juntamente com o componente TACBrAbecsPinPad e para mim também está aparecendo essa mensagem do acesso negado no momento que tento ativar a comunicação com o componente TACBrAbecsPinPad, através do comando "ACBrAbecsPinPad1.IsEnabled := true". Essa parte de utilizar transações tef e pix simultâneas é muito comum. Por isso tentei fazer o teste de antes mesmo de criar o componente TACBrAbecsPinPad na minha aplicação, utilizar o comando TEFPayGoAPI.DesInicializar para tentar liberar a utilização do pin pad, mas mesmo assim ocorre a mensagem de "acesso negado". Fiz o teste utilizando esses comandos acima: tefapi.EfetuarAdministrativa(tefopTesteComunicacao, ''); // dar um tempo para operação administrativa terminar tefapi.DesInicializar; TACBrAbecsPinPad.IsEnabled := true; No caso funcionou, mas infelizmente não é viável a cada transação de tef fazer uma operação administrativa de teste de comunicação com tef (demora em torno de 10 segundos cada vez que chama essa operação) e chamando o comando "tefapi.DesInicializar" vai apagar todos os comprovantes de resposta que foram emitidos. Daniel, caso tiver alguma novidade sobre a Setis, pode nos avisar?

Bom dia. De onde veio esse e-book?

Não é pra enviar na cAut o código do pix. No outro tópico referente ao assunto, está sendo falado sobre a forma "correta" de envio.

Na verdade, acredito que estamos com as units desatualizadas. Vamos atualizar e testar. Se já existe o add aí para vocês, já deve funcionar normalmente.