
Datacamp
Membros Pro-
Total de ítens
39 -
Registro em
-
Última visita
Sobre Datacamp

Últimos Visitantes
O bloco dos últimos visitantes está desativado e não está sendo visualizado por outros usuários.
Datacamp's Achievements
-
Realmente, é uma opção, mas como os registros estão tipados com TDateTime acho que ainda pode acontecer esse problema nas comparações, justamente pela tipagem. (Suposição apenas, já tive alguns problemas com Delphi por conta disso e no fim do dia a lógica estava correta mas as variáveis continham valores "default" às vezes não inicializadas corretamente e causavam esses comportamentos anormais) Ainda acho válida a alteração, talvez não com a urgência mas seria -1 ponto de falha para o futuro.
-
Boa tarde, tem uma validação no bloco K para a escrita que está com um comportamento estranho. No arquivo ACBrEFDBloco_K_Class (função WriteRegistroK200) há o seguinte código (joguei em variáveis para visualização), onde mesmo as datas sendo iguais é acusado diferenças, e consequentemente dá erro. Porém, só acontece quando a data final não é o fim do mês. Ao alterar o código para usar o CompareDateTime da DateUtils o código já funciona "normalmente". Acredito que seja por conta do armazenamento de Double que causa uma diferença pela precisão, algo muito insignificante, mas que dispara a validação. Provavelmente tem mais locais no código que fazem esse tipo de comparação e pode levar a esses problemas. t1 := RegK100.RegistroK200.Items[intFor].DT_EST; t2 := RegK100.DT_FIN; teste := CompareDateTime(t1,t2); if teste <> EqualsValue then //Não retorna true raise Exception.Create('A data do estoque deve ser igual à data final do período de apuração – campo DT_FIN do Registro K100'); if t1 <> t2 then //Retorna true, dispara a Exception raise Exception.Create('A data do estoque deve ser igual à data final do período de apuração – campo DT_FIN do Registro K100'); É passível de correção nos fontes oficiais ?
-
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 ?
-
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
-
@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.