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

@Juliana Tamizou, desconsidere o arquivo ACBrBancoBRGPactual.pas das postagens anteriores e considere esse último aqui, ok? Fiz alguns outros ajustes para seguir as configurações que encontrei em outros bancos nos fontes do ACBr. Obrigado! ACBrBancoBTGPactual.pas

Segue um ajuste para incluir os segmentos R e S no arquivo remessa (CNAB 240) ACBrBancoBTGPactual.pas

Precisei adicionar o banco BTG Pactual e estou enviando todos os arquivos que foram alterados para ficar compatível. Já está em produção, foi homologado arquivo remessa/retorno padrão CNAB240. Para os testes de homologação utilizei o próprio demo do ACBrBoleto, porém, notei que quando ele carrega as configurações que estão salvas no arquivo .ini os componentes em tela referente aos dados do Beneficiário não tinham os seus valores atualizados, e, sempre que gerava um novo .ini acabava perdendo todas essas configurações. Aproveitei e ajustei o demo em Delphi para recuperar essas informações do .ini também. O arquivo .zip está compactado com a estrutura de pastas que o ACBr utiliza e contém o kit de homologação que a BTG disponibiliza. Demo_ACBrBoleto.zip FontesBTGPactual.zip Manual_2.zip Manual fornecido pelo banco Manual_1.7z

Boa tarde Italo, Muito obrigado, já fiz o update aqui.

Olá! Passei a fazer o uso do componente ACBrNFSeX e, ao gerar o DANFSE, usando diretamente o método ImprimirPDF, identifiquei a seguinte situação: 1) Não estava respeitando o nome do arquivo que defini na propriedade NomeDocumento, e, o arquivo final ficava com um "-nfse.pdf" a mais. Ex: DANFSe1.NomeDocumento:='C:\Notas\NF_'+StrZero(NFSe.NotasFiscais.Items[I].NFSe.Numero.5)+'.pdf'; NFSe1.NotasFiscais.ImprimirPDF; Obs: Mesmo que eu não envie a extensão na propriedade NomeDocumento, o componente vai atribuir ".pdf" automaticamente (está no código do SetNomeDocumento). Nesse exemplo do código, quando executa o ImprimirPDF, o arquivo final está ficando como "C:\Notas\NF_00001.pdf-nfse.pdf" 2) Os labels/textos do DANFSE estão configurados com a fonte na cor clWindowsText, exceto os labels referente ao número da página que no .dfm já está na cor preta. Como no meu Windows estou usando um tema escuro, os textos do DANFSE estão todos na cor cinza quando exporta direto em PDF. Anexei apenas uma imagem com um recorte onde mostra que apenas os campos do número da página estão na cor preta. Também identifiquei que alguns textos fixos estavam avançando em cima de outros campos quando gerava o PDF e ajustei alterando deslocando um pouco esses campos para a direita. Para os dois casos a solução é muito simples e estou anexando os arquivos já corrigidos aqui para que possam ser analisados, mas, fiz esses ajustes apenas no Fortes, não sei se está ocorrendo essas mesmas situações no Fast. ACBrNFSeXDANFSeRLClass.pas ACBrNFSeXDANFSeRLRetrato.dfm

Essa era a minha preocupação mesmo... Acabei de atualizar os fontes e pelos testes está tudo certo agora. Muito obrigado pela atenção.

Alguns clientes passaram a relatar que está saindo no Danfe uma descrição da modalidade do frete errada, ex: '1 - DEST/REM', mesmo o XML sendo da versão 4.00. Identifiquei onde está o problema, mas não estou certo sobre a forma como deve ser corrigido, pois para isso teria que mudar o retorno da função GetVersaoStr. Vou então relatar o que está ocorrendo: 1) O problema é: A função StrToNumerado quando usada para identificar qual a versão da NFe está retornando como sendo a ve200 e não a ve400, com isso, a função modFreteToDesStr() está usando o conjunto errado para retornar a descrição. 2) Isso está ocorrendo pois a função GetVersaoStr retorna uma string concatenada resultando em "versao=4.00" e, com isso, a StrToEnumerado não encontra essa string no array para conversão, assumindo assim o primeiro elemento que é ve200 Segue as funções para explicar melhor: Arquivo PcnConversaoNfe.pas : function StrToVersaoDF(out ok: Boolean; const s: String): TpcnVersaoDF; begin Result := StrToEnumerado(ok, s, ['2.00', '3.00', '3.10', '4.00'], [ve200, ve300, ve310, ve400]); end; Arquivo PcnNFe.pas : function TinfNFe.GetVersaoStr: String; begin if FVersao <= 0 then Result := V2_00 else Result := 'versao="'+FloatToString(FVersao,'.','#0.00')+'"'; end; Arquivo ACBrNFeDANFeRLRetrato.pas ( idem para o modo paisagem): procedure TfrlDANFeRLRetrato.DefinirTransporte; var i, j: Integer; RLLabel, RLLabelModelo: TRLLabel; ok: Boolean; begin with fpNFe.Transp do begin rllTransModFrete.Caption := modFreteToDesStr(modFrete, StrToVersaoDF(ok, fpNFe.infNFe.VersaoStr)); with Transporta do begin rllTransCNPJ.Caption := FormatarCNPJouCPF(CNPJCPF); rllTransNome.Caption := XNome; rllTransIE.Caption := IE; rllTransEndereco.Caption := XEnder; rllTransCidade.Caption := XMun; rllTransUF.Caption := UF; end; end; .... 3) Possível solução: Basta alterar a função do arquivo PcnNFe.pas para não concatenar nada na versão da NFe e simplesmente converter para a string, passaria a retornar "4.00", como está sendo testado no StrToEnumerado, ficando assim: function TinfNFe.GetVersaoStr: String; begin if FVersao <= 0 then Result := V2_00 else Result := FloatToString(FVersao,'.','#0.00'); end; O problema é que não sei se foi proposital essa concatenação e qual o impacto de retirar isso para deixar como coloquei no passo (3)...

Obrigado pelas informações, não sabia também que a receita autorizava mesmo após as 24hs, de qq forma, pelo que vi do post que foi linkado, ficaria sujeito a multa também... Bom, aparentemente passou a funcionar no modo normal a NFCe, então nem precisei deixar ativo a contingência offline, já emitiu alguns cupons. ps: É complicado mesmo essas situações, só espero que a ENCAT não leve adiante essa "proposta"...

Até pensei nessa possibilidade, mas, nesse caso, as NFCe emitidas em offline precisam ser transmitidas para a receita no prazo máximo de 24 horas, não é? E aí teria um risco, pois não temos como saber se estará autorizando normalmente dentro de 24hs...

Para a NFCe basta essa mudança também ou precisa ser feito algo a mais? Pois configurei dessa forma e ao tentar emitir a NFCe aparece a mensagem: Sessão "NFCe_SVC-RS_P", não encontrada no arquivo "ACBrNFeServicos" Verifiquei no arquivo ACBrNFeServicos.ini e realmente não encontrei uma seção para a NFCe/SVCRS