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.