Clipeus

Bom dia @Daniel Simoes Sim.. compreendo que pode ter efeitos colaterais, vou fazer um teste, porém, acredito que agora o componente não irá mais alterar automaticamente para o modo Debug conforme a compilação, vai depender sempre de colocarmos via código no sistema uma atribuição ao IsDebug, antes de inicializar o componente, tanto para ativar quanto para desativar o modo debug. Ex: Teremos que ter uma configuração para ativar/desativar o modo debug dentro dos aplicativos (ou uma outra forma qq de controlarmos isso), e, antes de inicializar o componente, fazer algo assim: ... //Assunindo que "VerParametro" retorna true/false e o aplicativo tenha alguma forma de configurar/identificar se está ou não no modo "debug" if (ACBrTEFAPI.TEF is TACBrTEFAPIClassPayGoWeb) then TACBrTEFAPIClassPayGoWeb(ACBrTEFAPITEF).TEFPayGoAPI.IsDebug:=VerParametro('ModoDebug'); ... ACBrTEFAPI.Inicializar; ... Do contrário, uma vez "ativado" o modo Debug, vai sempre continuar nele e somente após reiniciar o computador que o cliente da PayGo voltará para a pasta original. Na ausência do aplicativo ter algum tipo de configuração, dependerá sempre de alterarmos manualmente a variável de ambiente para ativar/desativar o modo debug... Está correto o meu entendimento?

@Daniel Simoes hoje notei que o componente não estava alterando novamente a variável para a pasta "DEBUG", e, após fazer alguns testes constatei o seguinte: No constructor da TACBrTEFPGWebAPI ( ACBrTEFPayGoWebComum.pas ), há a seguinte instrução: {$IfDef DEBUG} fIsDebug := True; {$Else} fIsDebug := False; {$EndIf} Aparentemente está certo, pois se identificar que está compilando em modo debug, a variável já é iniciada de forma correspondente. Porém, como está acessando diretamente a variável "fIsDebug", o método "SetIsDebug" não é executado, e, com isso, não ocorre a mudança no path da lib, que é feito apenas através do "SetIsDebug". Alterei o trecho para: {$IfDef DEBUG} IsDebug := True; {$Else} IsDebug := False; {$EndIf} E com isso passou a funcionar corretamente. Segue arquivo com a mudança que fiz. ACBrTEFPayGoWebComum.pas

Boa tarde! Fiz o teste com a unit e funcionou normalmente sim. Obrigado @Daniel Simoes

Legal, obrigado Daniel.

Conforme relatado no discord, ao configurar o componente TACBrTEFAPI para habilitar o modo Debug, através da propriedade "IsDebug", não é possível efetuar a inicialização do TEF. A inicialização só é possível se for editado manualmente a variável de ambiente "PathPGWebLib" para apontar também para a pasta "DEBUG". Segue arquivo de log com teste feito pelo Demo do ACBr LogTEF.txt

Conforme comentado no discod, estou fazendo um teste aqui com o cancelamento automático para fazer um estorno quando um cupom for cancelado no aplicativo. No meu caso, o aplicativo permite mais de um recebimento no TEF, então fiz um cupom que recebi metade no Pix e metade no Cartão, e depois de tudo confirmado/autorizado/impresso, fiz o cancelamento do cupom. Quando cancelo o cupom, o aplicativo verifica todos os recebimentos que envolveu o TEF e executa o TEF.CancelarTransacao() para cada recebimento (gravo no banco os dados necessários: NSU, REDE, etc). Ocorre tudo certo com os estornos e sai impresso os comprovantes do estorno, mas notei um comportamento diferente entre o cancelamento do Pix e o cancelamento do Cartão: No Cartão, depois que a transação é autorizada, é disparado primeiro o evento "QuandoFinalizarTransacao" e depois o "QuandoFinalizarOperacao" No Pix, depois que a transação é autorizada, é disparado apenas o evento "QuandoFinalizarOperacao" Segue anexo o log do componente, coloquei um breakpoint antes de executar o TEF.CancelarTransacao() e mudei o nome do arquivo do log para separar e visualizar melhor o que cada chamada registrou. DebugTEF-CancelaTransacaoCartao.txt DebugTEF-CancelaTransacaoPix.txt

Ok, obrigado Daniel, fiz o update aqui e está tudo certo!

Olá, estava analisando o código do TEF para verificar como é feita a validação do campo para o evento "QuandoPerguntarCampo", pois pretendo colocar todas as validações possíveis no formulário da própria aplicação, mas, encontrei algo no código que me parece estar errado.. Vou colocar um "print" que será mais fácil para explicar.... Na unit "ACBrTEFPayGoWebComum.pas", no trecho que selecionei, está indicando que é esperada uma validação de "MêsAno", mas, é utilizada uma função que valida o "DiaMês". Está correto isso?

Arquivo enviado. Obrigado!

Olá Fabiano, boa tarde! A única solução que consegui foi sobrescrever o método "DefinePosicaoNossoNumeroRetorno" no arquivo referente ao BTG. Vou anexar aqui o fonte que estou usando, não sei se é uma alteração válida para ser incluída no SVN do projeto @Victor H. Gonzales - Panda ACBrBancoBTGPactual.pas

Bom dia Victor! Obrigado e desculpe pela demora no retorno. Já atualizei aqui e pelos testes iniciais só está com algum problema ainda na leitura do nosso número no arquivo retorno, vou fazer novos testes com calma, mas pelo que entendi é pq no arquivo remessa o nosso número é enviado sem o dígito (e isso está correto), porém, no arquivo retorno o BTG retorna ele com o dígito de controle, daí quando o componente processa o arquivo retorno está sendo o nosso número lido está vindo com o dígito de controle.

Bom dia @Victor H. Gonzales - Panda Fiz os testes aqui com essa revisão: Arquivo remessa: Continua tudo ok! Linha digitável e código de barras: Continua tudo ok! Nosso número: Dígito calculado corretamente, porém, na impressão do boleto/geração do PDF, a formatação do campo não está igual à formatação que o banco utiliza. O banco utiliza a formatação "CCC/NNNNNNNNNNN-D", com essa última revisão o componente gerou a formatação "CC/NNNNNNNNNNN-D". Mas essa diferença está apenas no visual do boleto, não gerou nenhum problema com o código de barras ou linha digitável. Acho que pode continuar assim, sem maiores problemas. Arquivo retorno: Aqui tem o problema da data do pagamento que comentei antes, naquele arquivo retorno que eu tinha enviado por email, o boleto foi pago pelo cliente no dia 09/09/2022 mesmo (confirmei com ele via comprovante) e não no dia 12/09/2022. A única posição que consta essa data de 09/09/2022 no retorno é a C058. Em todas as outras veio como 12/09/2022, que é o dia que o crédito foi liberado na conta. Porém, importar o retorno dessa forma vai gerar vários problemas de pagamentos ocorridos após o vencimento, que não é o caso. Ex: No caso desse boleto específico que estava no arquivo retorno, o vencimento era dia 10/09, foi pago no dia 09/09 (antecipado), mas se importar usando o C056 como data do pagamento, vai registrar no sistema que o pagamento ocorreu em 12/09 (após o vencimento). Abraços!

Olá pessoal!! Já faz alguns dias que estou tentando acessar o site do gerenciamento do SAT de SP, com o perfil de "Software House" via certificado digital, mas não funciona (nem abre a janela para selecionar o certificado)...já tentei em outros micros/navegadores/redes/etc. Também já entrei em contato com a Sefaz mas não tive nenhum retorno concreto ainda. Por acaso alguém precisou acessar por esses dias e deu certo? Ou tem alguém de SP que consegue fazer um teste pra ver se é somente aqui comigo ou não?

Bom dia @Daniel InfoCotidiano Com relação à documentação, foi só a planilha mesmo, e mesmo assim após muita insistência aqui..rs Com relação ao arquivo retorno, vou ver se consigo e encaminho por email, ok? Abraços!

Boa tarde @Daniel InfoCotidiano e @Victor H. Gonzales - Panda Atualizei os fontes aqui e identifiquei alguns pontos com problemas. Segue o fonte com as correções. Resumo das alterações que fiz: 1-No arquivo retorno, o layout é praticamente o padrão do Febraban e que está implementado na classe "pai", mas, o BTG retorna na posição 158 do registro "U" a data da liberação e na posição 158 a data real em que foi feito o pagamento do boleto. Então, a única forma que encontrei de tratar isso foi fazendo o override do LerRetorno240. 2-Na geração do código de barras, é necessário considerar o dígito da conta no campo livre 3-No cálculo do dígito do nosso número há uma condição que deve ser utilizada a letra "P" como dígito, nesse caso, fiz um override da CalcularDigitoVerificador 4-No arquivo remessa estava ficando errado o sequencial do lote e a quantidade de registros ao final do lote/trailler tb, pois o registro tipo "S" é opcional. Não é possível usar a fórmula de "QtdTitulos * 2" As orientações para cálculo do dígito do nosso número não consta no manual que a BTG enviou, mas solicitei ao suporte e enviaram apenas uma planilha excel explicando e exemplificando o cálculo do nosso número. A planilha está em anexo, caso queira colocar junto com o manual no svn. Obrigado! ACBrBancoBTGPactual.pas BTG - Calculadora Código de Barras e Digito Nosso Numero.xlsx