WINDEL

Ó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

Mais uma informação para poder indicar o local que o erro ocorre de forma mais detalhada. Validar Regras de Negócio: OK Validar Certificado: OK Validar Assinatura: OK O erro ocorre quando é acionado o botão "Validar XML", ou seja, quando aciona o comando "ACBrNFCom1.NotasFiscais.Validar" Segue em anexo, a imagem para relatar o problema.

Teste agora com o Demo do ACBR ACBrNFCom e também o ocorre o erro. No momento de validar o XML, estoura o seguinte erro: Exception: Falha na validação dos dados da nota: 1 Erro: Falha na validação dos dados da nota: 1 Erro Completo: Falha na validação dos dados da nota: 1 --> 1839 - Element '{http://www.portalfiscal.inf.br/nfcom}qrCodNFCom': [facet 'pattern'] The value 'https://dfe-portal.svrs.rs.gov.br/nfCom/qrCode?chNFCom=43240593146140000153620010000000011022040857&tpAmb=2' is not accepted by the pattern '((HTTPS?|https?)://.*\?chNFCom=[0-9]{44}&tpAmb=[1-2](&sign=[!-ÿ]{1}[ -ÿ]{0,}[!-ÿ]{1}|[!-ÿ]{1})?)'.

Estou realizando o envio de uma NFCom - Modelo 62 (Nota FIscal de Comunicação) e no momento da validação no ambiente de Homologação, está retornando o seguinte erro: 204 - Inconsistência de Informações no QR Code Falha na validação dos dados da nota: 1 --> 1824 - Element '{http://www.portalfiscal.inf.br/nfcom}qrCodNFCom': 'https://dfe-portal.svrs.rs.gov.br/nfCom/qrCode?chNFCom=43240593146140000153620010000000011019862922&tpAmb=2' is not a valid value of the local atomic type. Alguém sabe o que pode ser esse problema? Coloquei o xml em anexo. 43240593146140000153620010000000011093298903-NFCom.xml

Ao verificar o Demo do NFCOM do ACBR e realizar um teste de impressão com um XML básico de exemplo, percebi que ainda não existe o documento de impressão da NFCOM. Esse modelo de impressão é de fundamental importância, pois em breve será obrigatório a emissão da NFCOM, bem como o documento de impressão e também a impressão do modelo em formato PDF, pois alguns clientes irão optar por enviar o documento via e-mail. Existe alguma previsão para o desenvolvimento desse documento de Impressão? Esse modelo de impressão é bastante importante para a empresa.

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

Baixei os fontes, instalei novamente e com alguns testes que fiz rodando em modo Debug não ocorreu mais aquela exceção do componente. Foi realizado algum ajuste para tratar a exceção? Continuo usando o timeout de 20000

Sim, por isso que estou achando estranho essas exceções que estão sendo geradas. No caso configurei o timeout para o dobro do default. Tentei colocar o valor de 20000 (dobro) e mesmo assim está ocorrendo isso.

Segue as imagens das exceções que ocorrem. No memo está logando essa exceção como EACBrAbecsPinPadTimeout: Timeout reading Response Essas exceções "controladas" não podem resultar em algum crash se forem disparadas muitas vezes?

Quero apenas reforçar que para ver a exceção ocorrendo, é necessário rodar em modo debug, conforme o vídeo demonstra. Inclusive no memo foi logado que ocorreu a exceção. Pode ser que se rodar em modo normal sem ser por debug, a exceção não ocorra, mas porque ela esteja sendo mascarada. Meu receio quanto a isso é se depois de muitas vezes que rode o processo, o programa ir acumulando exceções mascaradas e assim possa acontecer de estourar e a aplicação se fechar sozinha devido a esse motivo.

Segue em anexo o vídeo e log. É necessário rodar em modo debug para visualizar a exceção levantada. Como o tamanho máximo para upload é de 2mb, compartilhei o vídeo no google drive. Segue o link para verificar o vídeo de simulação Vídeo: https://drive.google.com/file/d/1FWKW7mR4eHvlVqSEtm28QZDNJtPVNqiu/view?usp=sharing 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.

Sim, eu consegui simular com o Demo Pin Pad Test mesmo realizando os seguintes passos - Abrir o Aplicativo Teste ABECS Pin Pad - Clicar no Botão "Ativar" - Ir na Aba Multimedia e clicar no botão "Send to PinPad" - Ir na Aba Display e clicar no botão "Clear Display". - Voltar para a Aba Config e clicar no botão "Desativar" - Fechar a aplicação Repetir algumas vezes esse processo em modo debug para poder verificar a exceção levantada.

Estou utilizando o padrão TACBrAbecsPinPad.TimeOut = 10000. Vou aumentar para 20000 para verificar se pode ser esse o problema. Sei que para nesse momento porque no debug interrompe no comando " FACBrAbecsPinPad.DSI('QRCODPIX')" e capturo as seguintes mensagens de exceção (imagens em anexo). Estou constantemente usando esses comandos para ir enviando múltiplas vezes o QRCode. FACBrAbecsPinPad.LoadMedia('QRCODPIX', ms, mtPNG); FACBrAbecsPinPad.DSI('QRCODPIX'); Não preciso excluir a imagem antes de enviar novamente? Posso simplesmente sempre enviar direto o DSI pro pinpad?

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?