Warquia

Muito obrigado! É uma honra poder contribuir com a comunidade.

Vou deixar um melhor entendimento do problema. O que está acontecendo: Atualmente, estamos preenchendo manualmente os campos NSU, CNPJ e demais informações de cada transação. No entanto, ao enviar a venda através do método ACBrECF.FechaCupom, o componente volta a preencher automaticamente as formas de pagamento, sobrescrevendo os dados de transação que já haviam sido informados. Nossa proposta: Implementar uma opção que permita desativar esse comportamento automático, possibilitando que os dados da transação sejam mantidos conforme preenchidos pelo nosso software. Essa opção é especialmente importante em integrações com SmartPOS via API, pois, nesses casos, não existe uma integração direta como ocorre em um TEF capturado via ACBrTEF, tornando necessário preservar as informações enviadas pela aplicação. Obrigado a todos

Realmente, Dani! Estamos trabalhando na implementação do PagBank no componente, por isso ainda não está na versão mais recente dos fontes. Assim que concluirmos, farei um update e enviarei as novas implementações. TMJ!

@Daniel Simoes, Revisando aqui, acredito que esteja com as últimas modificações que fiz, incluindo o Commit [r37062]. De qualquer forma, estou enviando novamente, junto com o Elgin IDH android. Fico à disposição para qualquer coisa. \º/ ACBrTEFD-Android.zip

@EMBarbosa Muito obrigado. Infelizmente, não pude colaborar mais com o caso, pois estou participando de diversos eventos nesses meses fora da minha base de trabalho.

@EMBarbosa @Italo Giurizzato Junior Bom dia pessoal descobrir como gerar o erro. O problema ocorre em configurações que optaram pelo uso do xsMsXml (legado) e em PCs independentes da versão do sistema operacional que não possuem o libxml2 no Windows. No ambiente Delphi\debug, o erro não acontece porque, com a instalação do ACBrInstall, as DLLs necessárias são copiadas para o PC. No entanto, ao definir o xsMsXml, o componente tenta carregar o libxml2 internamente. Por isso, ao reverter para a versão anterior do ACBr, tudo funciona corretamente. Acredito que o uso do xsMsXml deveria ser respeitado ou, pelo menos, essa opção deveria ser removida para que, na próxima compilação, o desenvolvimento seja forçado a utilizar o padrão atualizado da DLL. Dessa forma, evitamos erros difíceis de identificar.

@Dércio Luis Zanatta segue as classes com 2 novas opções seguindo o manual atualizado tokenRegistroTls e timeoutColeta. Ps: não consegui testar a opção tokenRegistroTls porque não a obtive a tempo via Software Express. Classes e Demo MSitef.rar

Boa tarde, @Dércio Luis Zanatta, estou no momento homologando o Cielo no componente, mas vou fazer um esforço de olhar isso na próxima quarta-feira(10/07).

Boa noite, pessoal. Esse campo não existia na época do desenvolvimento do MSitef no ACBR. Portanto, será necessária a implementação dessa funcionalidade. No momento, não tenho disponibilidade na agenda para validar as novas especificações.

Bom dia @Renan S, de imediato não. Estamos tentando desenvolver uma avulsa junto com um arduino, mais ainda não avançamos. Segue abaixo o link onde adquirimos uma avulsa para teste(assim que tiver uma solução posto o resultado) https://pt.aliexpress.com/item/4000386522400.html?spm=a2g0o.order_list.order_list_main.4.2763caa4Sh3ouO&gatewayAdapt=glo2bra

Boa tarde @Daniel InfoCotidiano, creio que não fui claro rsrsr, quis dizer que eu alterei. Por isso enviei ela para pode ser avaliada e disponibilizada nos fontes do ACBr

Segue conforme combinado com algumas observações: 1º Digito verificador nosso número no ACBrBancoSantander.pas: @Daniel InfoCotidiano foi modificado a classe para não ser gerado o dígito verificador quando for via api VersaoDF = 'V1' @Jéter Rabelo Ferreira favor valíde no seu sistema porque possívelmente esteja queimando uma faixa de número quando for api, Ex: nosso número = 4 quando foi preenchido o boleto para visualização a linha digitável ficou diferente com o que foi gerado no banco. Nesse exemplo ficando 43 dentro da linha digitável ou seja (4 nosso número + 3 dígito verificador), logo você não vai conseguir utilizar o nosso número somente com o 43. Segue print do email trocado com o banco 2º @Jéter Rabelo Ferreira Na última classe enviado por você, especificamente TBoletoW_Santander_API.GerarPagador existe o seguinte linha: JsonDadosPagador.Add('neighborhood').Value.AsString := Copy(OnlyAlphaNum(Sacado.Bairro), 1, 30); Foi removida a chamada da funcão OnlyAlphaNum motivo: A funcão remove espaços da string Ex: "CIDADE JARDIM" tornando dentro do banco "CIDADEJARDIM" e o banco aceita espacos deixei a critério da sua automação fazer a limpeza dos campos. Ps: caso necessite posso enviar a função pois ela deve ser tratada não somente no bairro mas em cedente, endereço, cidade e etc.. 3º Não foi implementado ainda a consulta de boletos pois o mesmo só possui endpoint para consultar individualmente boleto pelo Nosso número, foi solicitado ao banco consulta em lista com mais filtros ex: data de recebimento, data de processamento etc, conforme outro bancos, e o mesmo respondeu que já estão trabalhando nisso, segue print da conversa. ps: por falta de tempo não implementei a consulta índividual, mas pretendo assim que o banco liberar a consulta em lista ACBrBoletoSantander.zip

@Daniel InfoCotidiano vou fazer uma análise dos últimos arquivos enviados pelo @Jéter Rabelo Ferreira e retorno com o resultado.

Boa noite @Jéter Rabelo Ferreira , Sim o componente está utilizando sua classe ACBrBoletoW_Santander_API que é baseada em REST, mas para ela ser utilizada devemos passar no componente ACBrBoleto.Configuracoes.WebService.VersaoDF := 'V1'; Caso contrário realmente ele vai utilizar o padrão Soap, segunda sem falta vou postar o código com algumas melhorias em cima da sua classe para você nós ajudar na análise. TMJ

@Daniel InfoCotidiano creio que amanhã envio as classes com algumas correções Att,