Alterações para Passar na homologação do SITEF

[Datacamp]

Bom dia @Daniel Simoes, essa sua implementação vai cobrir o caso do TLS e também a lógica de confirmação das transações pendentes após o código 130 ? Ou somente a um deles ?
Digo isso pois esses dois pontos com o componente nas ultimas revisões eu fui reprovado na pré-homologação e pretendia também alterar o componente, mas se já estiver sendo resolvido eu iria aguardar.

[rodrigoogioni]

13 horas atrás, Daniel Simoes disse:

Estou terminando uma possível implementação.. já mando aqui...

A hora que estiver pronto me passa as units alteradas que faço teste aqui.

Grato

[adriano.quintino]

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.

Editado 12 Setembro por adriano.quintino

[rodrigoogioni]

Bom dia!  Como esta em relação esse topico. Estou com desenvolvimento para referente ao SITEF. No primeiro arquivo que enviei, foi alterado apenas uma unit, e faz o tratamento de todas as transações pendentes. Não da pra servir como base?

Grato

[rodrigoogioni]

Bom dia @Daniel Simoes. @Juliomar Marchetti,  alguma novidade? Precisamos de uma resposta. Volto para a rotina que eu criei ou espero? Pq depois de todo esse tempo fica complicado.

Grato

[Daniel Simoes]

Se a sua rotina está funcionando, não vejo motivo para não continuar usando ela...

O ACBr adotara outra solução um pouco mais robusta... mas estamos com dificuldades para testar

[rodrigoogioni]

22 horas atrás, Daniel Simoes disse:

Se a sua rotina está funcionando, não vejo motivo para não continuar usando ela...

O ACBr adotara outra solução um pouco mais robusta... mas estamos com dificuldades para testar

e quando atualizar o ACBR, não dará problema?

[adriano.quintino]

Em 19/09/2024 at 18:45, Daniel Simoes disse:

Se a sua rotina está funcionando, não vejo motivo para não continuar usando ela...

O ACBr adotara outra solução um pouco mais robusta... mas estamos com dificuldades para testar

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

[rodrigoogioni]

@Daniel Simoes   Alguma novidade?

 

[adriano.quintino]

Em 24/09/2024 at 18:31, rodrigoogioni disse:

@Daniel Simoes   Alguma novidade?

 

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.

[rodrigoogioni]

20 horas atrás, adriano.quintino disse:

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.

Nada!  Abandonaram. Decepcionado

[Juliana Tamizou]

Bom dia pessoal
 @rodrigoogioni e @adriano.quintino esta questão não foi abandonada, porém ainda não esta no ponto que poderia ser enviada... 
Neste intervalor de tempo vcs poderiam seguir com a implementação do Rodrigo e havendo novidades deste caso, será enviado aqui.

 

At.

[adriano.quintino]

9 horas atrás, Juliana Tamizou disse:

Bom dia pessoal
 @rodrigoogioni e @adriano.quintino esta questão não foi abandonada, porém ainda não esta no ponto que poderia ser enviada... 
Neste intervalor de tempo vcs poderiam seguir com a implementação do Rodrigo e havendo novidades deste caso, será enviado aqui.

 

At.

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.

[Daniel Simoes]

Olá pessoal...

Com a aproximação do evento, tenho tido pouco tempo para focar em desenvolvimento... e estava com a fila de tarefas enorme...

@Juliomar Marchetti, segue o Patch com as modificações que apliquei

ACBrTEFD.patch

A ideia foi...

• Criar um novo método "CarregarRespostasPendentes" na Classe mãe (TACBrTEFAPIComumClass), para que possamos sobrescrever ele, nas classes que necessitarem, como por exemplo em "TACBrTEFAPIClassCliSiTef.CarregarRespostasPendentes"
  • Nesse método, podemos chamar o ADM 130, e ler do próprio SiTef, todas as transações pendentes
• Modificar o método "TACBrTEFAPIClassCliSiTef.FinalizarTransacao", para processar chamadas onde apenas o "CodigoFinalizacao" é informado, pois nesse caso, essa chamada veio de uma lista de respostas, que foi gerada pela chamada do comando ADM 130

 

PS: Não consegui testar o código, pois ainda não tenho o ambiente de testes do SiTef

[Daniel Simoes]

As alterações que estavam no PATCH acima, estão no SVN, com algumas correções... Commit [r35599]

[adriano.quintino]

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. 

[Juliomar Marchetti]

11 minutos atrás, adriano.quintino disse:

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. 

Veja senão está marcado para confirmar a transação a cada venda ao invés de bufferizar as vendas, pois lembro bem que o Paygo não consegue bufferizar e dai é confirmado a cada venda o cartão e só  sitef tinha essa possibilidade para dai cancelar ambos.

pois nesse caso tu tem que cancelar manualmente pois a venda já foi a confirmação

[Daniel Simoes]

Oi @adriano.quintino, obrigado pelo retorno...

Acho que faz sentido.. pois agora o com o novo método "CarregarRespostasPendentes" ele apenas considera as transações que são retornadas por eles... e as transações já confirmadas, não estão..

Vou tentar uma correção, para o método ainda varrer os arquivos de Backup, mas adicionar na lista, apenas as transações já confirmadas, para que elas possas ser processadas pelas rotinas subsequentes...

[rodrigoogioni]

Acredito que deva ser assim, fez o primeiro cartao, nao confirma a transação, deixa em aberto, fez o segundo cartao, nao confirma, deixa em aberto. Finalizou o cupom confirma todas em aberto, deu algum problema, cancela todas em aberto. Vamos supor que o micro desliga. E nao liga mais. O cliente desiste da compra e vai embora, ou passa em outro caixa, quando o micro voltar a ligar, tem que cancelar todas as pendentes.

 

Grato

[Juliomar Marchetti]

1 hora atrás, rodrigoogioni disse:

Acredito que deva ser assim, fez o primeiro cartao, nao confirma a transação, deixa em aberto, fez o segundo cartao, nao confirma, deixa em aberto. Finalizou o cupom confirma todas em aberto, deu algum problema, cancela todas em aberto. Vamos supor que o micro desliga. E nao liga mais. O cliente desiste da compra e vai embora, ou passa em outro caixa, quando o micro voltar a ligar, tem que cancelar todas as pendentes.

 

Grato

sim é isso mesmo. só o tratamento do ACBrTEFAPI é diferente do ACBrTEFD e não lembro ao certo se ele bufferiza. pois inicialmente ele é baseado no PayGo e lá não tem a bufferização

[adriano.quintino]

2 horas atrás, rodrigoogioni disse:

Acredito que deva ser assim, fez o primeiro cartao, nao confirma a transação, deixa em aberto, fez o segundo cartao, nao confirma, deixa em aberto. Finalizou o cupom confirma todas em aberto, deu algum problema, cancela todas em aberto. Vamos supor que o micro desliga. E nao liga mais. O cliente desiste da compra e vai embora, ou passa em outro caixa, quando o micro voltar a ligar, tem que cancelar todas as pendentes.

 

Grato

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. 

[Daniel Simoes]

Por favor, experimentem, com essa nova Unit

ACBrTEFAPICliSiTef.pas

[adriano.quintino]

1 hora atrás, Daniel Simoes disse:

Por favor, experimentem, com essa nova Unit

ACBrTEFAPICliSiTef.pas 44.38 kB · 0 downloads

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. 

Editado 16 Outubro por adriano.quintino

[Daniel Simoes]

@adriano.quintino,

Eu não consegui reproduzir o problema...

No Demo do ACBr, quando ele encerra a venda, já existia uma chamada para Limpar as Transações de backup

procedure TFormPrincipal.btOperacaoClick(Sender: TObject);
begin
  AdicionarLinhaLog('- btOperacaoClick');

  case TipoBotaoOperacao of
    bopLiberarCaixa:
    begin
      StatusVenda := stsLivre;
      ACBrTEFAPI1.LimparRespostasTEF;  // Limpa respostas TEF anteriores, e apaga Arqs Backup
    end;       

 

[adriano.quintino]

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.

Editado 18 Outubro por adriano.quintino