adriano.quintino

Bom dia Daniel! Sim, testei em produção e ficou 100%. Talvez vocês não tenham relato porque os demais programadores atribuem manualmente o valor no campo "CodigoMora", onde "A" é pra Valor R$ e "B" pra %. Penso eu que seja desnecessário colocar a condição pra cada banco ao gerar a remessa, ex.: if Bradesco then "B" else if Sicredi then If ValorFixo then "A" else "B", etc. Então, creio que seria mais viável colocar dentro de cada classe de banco correspondente para automatizar, já que é possível fazer esta automatização.

Fiz correções pertinentes à cobrança de Juros e Multa no boleto do Sicredi e do Bradesco segundo o layout CNAB400 de ambos os bancos. Gostaria muito que analisassem e se possível, subir pro repositório. O componente do Boleto existe duas propriedades CodigoMulta e CodigoMoraJuros, onde programamos o tipo de juros e multa a ser cobrando, porém, o Bradesco por exemplo só aceita Multa em % e a multa só é permitida em R$ diário, então criei rotina para conver o valor de juros em valor diário. Ou seja, independente do parâmetro que o usuário selecionar na propriedade CodigoMoraJuros, o sistema irá converter o valor informado no campo "ValorMoraJuros" para valor diário. No boleto do Sicredi foi feito algo semelhante pra calcular a multa, porém, Sicredi aceita multa tanto em R$ quanto em %, mas a propriedade "CodigoMora" estava recebendo somente o valor "A" para multa em R$. Então coloquei uma rotina pra pegar o tipo de multa de acordo com o parâmetro CodigoMulta e os juros permite tanto R$ e % somente diariamente, então coloquei a rotina pra converter o valor informado no campo "ValorMoraJuros" para valor diário. ACBrBancoBradesco.pas ACBrBancoSicredi.pas

Bom dia! @Daniel Simoes agora o componente ficou perfeito! Valew, obrigado. Eu realmente não tinha me atentado ao "LimparRespostasTEF" e só estava faltando ele mesmo no meu código.

Ficou legal @Daniel Simoes, só tem um detalhe agora: Ao inicializar o componente, ele está cancelando a última transação efetuada com sucesso, mesmo que não tenha sido solicitado o cancelamento, pois ele verifica que existe um arquivo de backup na pasta TEF e chama o cancelamento da transação.

Até onde eu sei, segundo os manuais do SiTEF, devemos confirmar a transação anterior em caso de mais de uma forma de pagamento. E também, da forma que está o componente agora, ele só cancela a última transação pendente. Creio que deveria haver uma classe Lista em que o sistema armazenasse nesta Lista todas as transações pendentes, já que pode haver mais de uma transação pendente. O procedimento exigido pela SiTEF é primeiro cancelar as transações que ficaram pendentes de confirmação e posteriormente cancelar as transações vinculadas ao mesmo pedido de venda que foram confirmadas. Atualmente ele só está cancelando a transação pendente. Quando fui fazer minha homologação, eu estava sendo reprovado porque havia 5 transações pendentes, na forma que eu coloquei no fonte do ACBr consegui cancelar todas elas de uma só vez, porém, está ocorrendo memory leak quando entra em alguns códigos retornados da função 130.

Olá! Fiz a atualização do ACBr e realmente funcionou legal a questão da chamada da função 130 recuperando a última transação tef pendente, mas por algum motivo, ainda não tive tempo de olhar o código fonte a fundo, o componente não está mais cancelando transações que foram recém-confirmadas. Ex.: Faz uma venda com 2 ou mais cartões e ao tentar cancelar qualquer um dos cartões, o componente não está conseguindo cancelar. E também, quando houver queda de energia com mais de 1 cartão, a transação que estava pendente o sistema consegue cancelar pela função 130 ao iniciar o componente, já a transação que foi aprovada, ele não consegue mais cancelar. Algum dos colegas que puderem fazer mais testes pra verificar se realmente é uma falha geral ou se é apenas no meu ACBr, ficaremos gratos.

Compreendo. Meu questionamento foi porque o @Daniel Simoes disse que estava tendo dificuldades nos testes, então eu me disponibilizei pra realizar testes, caso quisesse.

Oi @rodrigoogioni te informaram de alguma novidade ? Gostaria que o @Daniel Simoesme enviasse o código que foi alterado pra eu poder fazer os testes, mas até o momento não me enviaram nada também.

Bom dia! @Daniel Simoes nos encaminha as units modificadas que podemos realizar os testes.

Boa tarde! Também estou ancioso para fazer os testes neste código. Gostei da ideia de criar uma classe pra receber as transações pendentes na execução da função 130 e posteriormente cancelar ou aprová-las (conforme a configuração do componente) fazendo uma varredura na classe criada com as pendências sem a necessidade de se criar arquivos de backup das transações pendentes. Quanto ao memory leak mencionado pelo @Daniel Simoes está ocorrendo porque ao descomentar a parte do código dos tipo de campos pra retorno de pendências, alguns códigos daqueles são retornados em transações de vendas e o sistema acaba entrando lá e como o objeto estava sendo criado apenas no retorno 160, gerava exceção de acessó de memória, objeto não criado, por isso eu tive a necessidade de verificar se o objeto já estava instanciado, caso não estivesse, ele seria destruído, porém, o sistema só libera da memória no 1319 que só é chamado na função 130. Separar a função 130 pra uma função própria onde executa, armazena em uma classe de pendentes e em seguida executa a finalização delas, é muito interessante, conforme o @EMBarbosacomentou.

Boa tarde @Daniel Simoes Dê uma olhada na página 18, item 9.1 - Exemplo 1 ou exemplo 2. CliSiTef - Projeto TLS - 1.05.pdf

Eu só não coloquei os parâmetros para proxy porque eu não utilizo, mas caso queiram acrescentar estes parâmetros também é possível. Um detalhe é que estes parâmetros são exigidos nos testes de homologação, pelo menos o Token e o TLSGWP.

Segundo o manual do TLS, temos que passar estes parâmetros ao chamar a função ConfiguraIntSiTefInterativoEx em ParametrosAdicionais

Oi @EMBarbosa. É verdade, pode remover ele. Acabei me esquecendo de retirá-lo. Eu estava utilizando ele pra fazer o loop de cancelamento conforme fosse recebendo os registros pendentes. Daí eu fiz as correções depois e acabei me esquecendo de remover este parâmetro. Segue a correção em anexo ACBrTEFAPICliSiTef.pas

Bom dia @rodrigoogioni Tudo bem ? No caso, estávamos tratando apenas de homologação SiTEF, eu não tratei código de PayGoWeb.

Oi @rodrigoogioni. Sim, eles estão anexados na mensagem logo acima.

Teste realizados junto à SiTEF e finalmente estou homologado. Obrigado a todos! Em especial a @Juliana Tamizou@EMBarbosa@Juliomar Marchetti e @Daniel Simoes pelo brilhante trabalho no código do ACBrTEFAPI e demais componentes, e a toda equipe ACBr. Agora quero homologar no PayGOWeb.

Na classe TACBrTEFAPIDadosTerminal da unit ACBrTEFAPIComum, acrescentei a propriedade TokenRegistro para receber o valor que a SiTEF passar para a empresa. Coloquei apenas pra me atender na homologação. Então, é algo que não precisam levar em consideração, ou então dá pra fazer alguns ajustes, tipo, colocar uma propriedade TipoComunicacaoExterna para receber o valor TLSGWP, como é um valor fixo, eu já deixei no próprio código. Daria pra acrescentar também o proxy, como não é algo que eu uso, não coloquei nada a respeito de proxy. Obrigado @EMBarbosa, aqui funcionou 100%

Boa tarde a todos! Com a ajuda do @EMBarbosa, fiz alguns ajustes nestes arquivos abaixo, porém, as propriedades (TratamentoTransacaoInicializacao e TratamentoTransacaoPendente) do componente ACBrTEFAPI devem estar setado da seguinte maneira (tefopiCancelarOuEstornar e tefpenEstornar) respectivamente para solucionar quedas de energias quando houver 2 ou mais cartões e o problema ocorrer depois de ter sido aprovado pelo menos 1 transação. Assim como está, caso haja uma transação aprovada, o sistema cria o arquivo de backup que deverá ser incluido na lista de Respostas na inicialização do SiTEF e as transações que estão pendentes não irão sobrescrever o backup já criado. Para isso, tive a necessidade de fazer a chamada TefAPI.CarregarRespostasDoDiretorioTrabalho na procedure Inicializar do CliSiTEF, linha 413. Tive a necessidade de criar a propriedade 899-105 para armazenar a informação da propriedade "Confirmar" nos retornos de transações pendentes para o componente dar continuidade nos cancelamentos. ACBrTEFAPICliSiTef.pas ACBrTEFAPIComum.pas ACBrTEFCliSiTefComum.pas ACBrTEFComum.pas

Boa tarde Daniel, conforme solicitado, o teste é este aqui: Roteiro de pré-homologação, seq.19: - Realizar uma transação com cartão de Crédito chip. - Selecionar a opção à vista - Quando receber o retorno de aprovação, de forma rápida precisa encerrar a aplicação, para poder simular a transação pendente de forma correta. - Na sequência, iniciar novamente a aplicação e tratar a transação pendente pelas funções IniciaFuncaoSiTefInterativo modalidade 130 ou pela função ObtemQuantidadeTransaçõesPendentes - Após obter os resultadosdas funções acima, enviar função“Finaliza” confirmando ou desfazendo a transação, dependendo da sua regra de negócio. OBS: Por boas práticas com a CliSiTef, orientamos o cliente a sempre cancelar a transação.

Eu até poderia retornar pro ACBrTEFD, porém, ele também não está atendendo o teste 19 do roteiro de pré-homologação porque ele não chama a função IniciaFuncaoSiTefInterativo modalidade 130 nem a função ObtemQuantidadeTransaçõesPendente. Este foi o motivo pelo qual mudei pro componente ACBrTEDAPI, que ao meu ver, está muito próximo de ficar perfeito 100%.

Oi Juliomar, conforme está descrito na unit, pra inserirmos um break point, eu o fiz, porém, a procedure onde está a parada só é chamada quando se retira o cartão do pinpad, ou seja, se o consumidor demorar a remover o cartão e neste intervalo de tempo em que a transação foi aprovada e a retirada do cartão, o computador vier a desligar, teremos problemas porque a aplicação não vai conseguir recuperar a transação que estava pendente pois o arquivo .tef ainda não tinha sido criado pelo componente. No componente ACBrTEFD, este procedimento ocorre perfeitamente criando o arquivo .tef no mesmo instante em que se obtém o retorno AUTORIZADO mesmo que o cartão ainda não tenha sido removido do pinpad.

Oi Juliomar! Eu olhei no código e não encontrei estes pontos de parada a qual você se refere.

Encontrei o problema, mas não encontrei a solução. O problema é porque o ACBrTEFAPI só cria o arquivo de retorno na pasta tef ao retirar o cartão do Pinpad, mas ele deveria criar o arquivo ao obter o retorno "APROVADO", antes mesmo de remover o cartão. Da forma que está atualmente, o teste 19 exige que finalizemos a transação após o "APROVADO", com isso, ao fechar e abrir novamente o sistema, o componente não encontra o arquivo na pasta tef e não detecta que há transações que ficaram pendentes.

Eu fiz um teste utilizando o próprio TefAPIDemo.exe e ao solicitar pra retirar o cartão, eu finalizo a aplicação, porém, de qualquer forma que já tentei, ao iniciar o sistema, ele não autoriza a transação SiTEF