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.

Olá, assim que possível irei atualizar o componente e fazer os testes. Obrigado.

Bom dia @Daniel Simoes, olhei o commit e aparentemente ela não vai funcionar corretamente (não testei), você usou como separador a vírgula mas na verdade deveria ser o ponto-e-vírgula, assim como os outros.

@Diego Foliene e @Daniel Simoes não fiz alterações referentes a esse tópico, apenas sugeri ali como poderia ser feito seguindo a lógica, como eu acabei alterando essa unit para outro tópico eu vou ficar devendo o arquivo completo. Mas é uma alteração muito pequena bem no começa do arquivo, apenas adicionar o valor 3988 nas duas constantes, dessa forma: CSITEF_RestricoesParcelaEstabelecimento = '27;3988'; CSITEF_RestricoesParcelaAministradora = '28;3988';

Bom dia, implementei esse método mas não tenho certeza quanto a padronização e operações relativas à finalização do processo TEF, fiz apenas com base nos meus estudos da DLL e ao que entendi do padrão usado no ACBr para o TEF. Como eu percebi que algumas coisas estavam bem amarradas ao PayGo na questão de herança, então possivelmente não utilizei da maneira 100% correta, porém está funcional. Se alguém mais experiente na ACBrTEFAPI conseguir revisar e melhorar o código para poder subir oficialmente seria muito bom. Minha chamada está dessa forma: AcbrTEF.LimparRespostasTEF(); //tamMin e tamMax estão como variáveis TACBrTEFAPIClassCliSiTef(AcbrTEF.TEF).ObterDadoPinPadAberto(dapDDD,tamMin,tamMax,0); showmessage(AcbrTEF.RespostasTEF.Items[0].DadoPinPad); AcbrTEF.FinalizarTransacao(tefstsSucessoAutomatico); Link da documentação dessa parte da CliSITEF: https://dev.softwareexpress.com.br/docs/clisitef-leitura-de-campo-aberto-no-pinpad/leitura_campos_abertos_pinpad_forma_nova ACBrTEFComum.pasACBrTEFCliSiTefComum.pasACBrTEFAPICliSiTef.pas

Confirmo que a solução da @Gisele Jesus é funcional, fiz da mesma forma.

Bom dia, hoje ao passar as configurações de "Parcelado emissor" ou "Parcelado administradora" para o componente são utilizados as constantes CSITEF_RestricoesParcelaEstabelecimento e CSITEF_RestricoesParcelaAministradora para filtrar os menus que irão aparecer, contudo aparece uma opção chamada "Menu Crediário", o que então força aparecer a tela de menu para selecionar (conforme imagem), há possibilidade de adicionar no componente a restrição para não aparece-lo ? Para resolver teria que adicionar o valor 3988 nas restrições de parcelamento para que ele fosse ocultado, dessa forma nas opções de parcelamento a DLL não necessita de mandar o comando 21 e exibir essa tela. Atualmente estou replicando o tratamento feito na unit ACBrTEFAPICliSiTef para tratar as restrições, uma vez que se eu apenas colocar apenas esse valor na fParamAdicFuncao antes de chamar o "EfetuaPagamento" ele não funciona corretamente.

Bom dia, atualizado os fontes para a revisão 33061 (27/03/2024) e realizado o procedimento conforme o exemplo do CTe. O evento de cancelamento foi transmitido corretamente, obrigado pela atenção!

Bom dia, agradeço a atenção @Italo Giurizzato Junior, não conseguirei testar prontamente essa semana, possivelmente semana que vem já devo conseguir realizar o teste e comento aqui no fórum o resultado.

Bom dia, tudo bem? É esse campo mesmo, pode passar valor que vai funcionar. <valor_tributavel> -> "Valor do item que servirá de base de cálculo para o imposto, com a dedução" - Layout da IPM

Está faltando você informar o novo campo <valor_tributavel>