Datacamp

Boa tarde, fiz conforme o indicado e criei do lado da aplicação os controles, a princípio os testes deram certo, se não será incluído nos fontes pode encerrar o tópico. Obrigado pela atenção.

Bom dia, houve algum alteração em relação a esse caso ?

Bom dia @Daniel Simoes, realmente funciona somente para a SiTEF, porém fiz dessa forma pois foi a que consegui tornar o componente mais legível e compatível com o manual da SiTEF. A questão de modificar o fOperacaoCancelamento eu não adotei por me parecer um pouco "fora da linha", e não me lembro se teria que tornar ela uma propriedade pública (ou se ela já é) para ser chamada de fora, e o enumerável me pareceu tornar o código mais legível e organizado. Criei de forma geral (No ApiComum) para não ter um método específico para a SiTEF, já que outros métodos também continham coisas específicas da PayGo acreditei que tinha sido tomada essa decisão para manter as heranças. O enumerável e o parâmetro eu acho bastante relevante para facilitar as chamadas e a legibilidade do código, caso não queira afetar as outras units acredito que uma sobrecarga do método também resolveria.

Bom dia, sem problema, seguem os arquivos, estão na revisão 34957 que foi a última que considerei para fazer o processo de homologação. Mas pelo que vi das recentes implementações não deve dar conflito já que são novos métodos. TEF_Alteracao_ACBR_34957.rar

Boa tarde, como foi feito os patches referentes aos casos lá da homologação, essa alteração será feita também ?

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.

Bom dia, teve alguma alteração essa questão ?

Bom dia, atualizado os fontes para a última versão e realizados os testes no cancelamento, funcionou corretamente. Obrigado.

Boa tarde, durante o desenvolvimento da integração com a SiTEF afim de ocultar algumas telas ao usuário e permitir uma experiência melhor encontrei que é possível adiantar a modalidade do cancelamento a ser feito pela DLL. Passando para a função ao invés do código 200 - "Cancelamento Normal" passando códigos específicos como 210-"Cancelamento de venda com cartão de Crédito". Para isso criei um tipo novo para o cancelamento e inclui o mesmo como parâmetro na função de cancelamento, só consigo realizar testes na SiTEF mas assim como outros parâmetros exclusivos de outras TEF Houses ele foi criado com um DEFAULT e não vai afetar o funcionamento dos outros métodos. Seguem os arquivos com as alterações para análise. PS: Tive que anexar em .zip por conta que o arquivo da Elgin estava dando erro 200 durante o upload. Alteracao ACBR.zip ACBrTEFAPICliSiTef.pas ACBrTEFAPIComum.pas ACBrTEFAPIPayGoWeb.pas

Obrigado, assim que possível atualizo os fontes. Mas se foi o mesmo arquivo que enviei já testei aqui e funcionou para o cancelamento corretamente.

@Daniel Simoes, eu acho interessante a omissão nesses casos por conta de que já ocorreu a passagem de parâmetros. É interessante uma forma de "zerar" esses parâmetros, o default por exemplo passando sempre String vazia para que ele caia na condição e pergunte, se assim for especificado. Mas no caso de possuir o preenchimento desses valores eu tenho preferência por ocultar justamente para não prejudicar a experiência do usuário final, no seguinte raciocínio: "Se já possui valor, por que eu deveria confirmar ?", nesse caso acredito que fique redundante.

Bom dia, notei um pequeno problema com o cancelamento de um transação e vi que na verdade vai acontecer em outras também. No código do cancelamento está o seguinte: fRespostasPorTipo.ValueInfo[146] := ValorStr; fRespostasPorTipo.ValueInfo[147] := ValorStr; fRespostasPorTipo.ValueInfo[515] := FormatDateTime('DDMMYYYY',DataHoraTransacao) ; fRespostasPorTipo.ValueInfo[516] := NSU ; Esses valores deveriam ser usados para "ignorar" o evento QuandoPerguntarCampo do componente, porém o mesmo não ocorre, e continua sendo requisitado informar manualmente esses dados. Ao olhar o código da ContinuarRequisicaoSiTef da ACBrTEFAPICliSiTef notei que nos comandos 30,31,34,35 e 41 está sendo ignorado a resposta e solicitando novamente (Conforme código abaixo). Resposta := ''; Voltar := False; Digitado := True; if (fUltimoRetornoAPI = 10000) then begin if (TipoCampo > 0) then Resposta := fRespostasPorTipo.ValueInfo[TipoCampo]; //////////////////////////////// PREENCHIMENTO DA RESPOSTA /////////////////////////// ... case ProximoComando of 0: begin RespCliSiTef.GravaInformacao(TipoCampo, Mensagem); case TipoCampo of ... 31: begin DefinicaoCampo.TipoCampo := TipoCampo; DefinicaoCampo.TituloPergunta := ACBrStr(Mensagem); DefinicaoCampo.TipoDeEntrada := tedNumerico; DefinicaoCampo.TipoEntradaCodigoBarras := tbQualquer; DefinicaoCampo.TamanhoMaximo := TamanhoMaximo; DefinicaoCampo.TamanhoMinimo := TamanhoMinimo; Resposta := ''; ////////////////// ignora a resposta informada nas primeiras linhas ///////////////// Validado := True; TefAPI.QuandoPerguntarCampo(DefinicaoCampo, Resposta, Validado, Interromper); if Resposta = '-1' then Interromper := True else if Resposta = '-2' then Voltar := True else RespCliSiTef.GravaInformacao(TipoCampo, Resposta); end; Para resolver simplesmente tirei essa atribuição Resposta := ''; e passei a validar com base se ela está vazia antes de cada chamada do QuandoPerguntarCampo . Vou anexar o arquivo para conseguirem comparar as alterações. ACBrTEFAPICliSiTef.pas

@Daniel Simoes, testado a última atualização, funcionou corretamente, obrigado.

@Daniel Simoes, fiz o teste aqui de umas 4 opções e funcionou corretamente, obrigado. Único ponto que eu mudaria era para ter alguma forma mais fácil de identificar aqueles que não são suportados entre os TEFs. Entendo a questão da padronização e utilização da herança para não repetir código, mas acredito que tenha seus pontos negativos. Na minha implementação eu tinha colocado específico para a CliSiTEF por conta que ao testar o componente eu tinha que verificar 1 por 1 (olhando somente o código fonte) para ver quais eram suportados pela CliSiTEF, acredito que quem vá homologar com a PayGo vá ter a mesma sensação ao tentar utilizar um método que acaba pegando de um enumerável com muitas opções. Mas está funcional, novamente obrigado.

Acredito que agregue nesse POST, a NT 2023.004 veio com algumas resoluções sobre o PIX no sentido de preenchimento de código de autorização. Dentro da parte de cartões de crédito/débito foram alteradas as redações para incluir o PIX e outros pagamentos eletrônicos. Não sei se entra diretamente em confronto com o decreto mas como vai ser habilitado em ambiente nacional é possível que seja adotado esse campo.