Ir para conteúdo
  • Cadastre-se

Alexsander

Membros
  • Total de ítens

    383
  • Registro em

  • Última visita

  • Days Won

    2

Tudo que Alexsander postou

  1. #0 RESET(0x7ffff7fe6400) at ../../../Fontes/Terceiros/synalist/smtpsend.pas:484 #1 CLEAR(0x7ffff7eb1160) at ../../../Fontes/ACBrTCP/ACBrMail.pas:347 #2 DESTROY(0x7ffff7eb1160, 0x1) at ../../../Fontes/ACBrTCP/ACBrMail.pas:414 #3 CLASSES_TCOMPONENT_$__DESTROYCOMPONENTS at :0 #4 ?? at :0 #5 gtk_text_iter_get_type@plt at :0 #6 ?? at :0 #7 CLASSES_TCOMPONENT_$__DESTROY at :0 #8 ?? at :0 #9 gtk_text_iter_get_type@plt at :0 #10 ?? at :0 #11 ?? at :0
  2. Não comandei nada, apenas larguei o componente na tela, executei e mandei fechar via botão "X" do formulário. O fSMTP.Reset que trava está no código da TACBrMail.Clear, que é chamada pelo destrutor: destructor TACBrMail.Destroy; begin Clear; fAltBody.Free; fBody.Free; fBCC.Free; fReplyTo.Free; fMIMEMess.Free; fSMTP.Free; inherited Destroy; end; Comentei a linha do fSMTP.Reset e não travou, mas imagino que esse Reset seja necessário.
  3. Aquele comando fSMTP.Reset já entra na Synapse. O travamento ocorre na seguinte procedure: function TSMTPSend.ReadResult: Integer; var s: String; begin Result := 0; FFullResult.Clear; repeat s := FSock.RecvString(FTimeout); { <============= AQUI } FResultString := s; FFullResult.Add(s); if FSock.LastError <> 0 then Break; until Pos('-', s) <> 4; s := FFullResult[0]; if Length(s) >= 3 then Result := StrToIntDef(Copy(s, 1, 3), 0); FResultCode := Result; EnhancedCode(s); end;
  4. Fiz o teste no Linux (Ubuntu 64 Ubuntu 14.04.3 LTS), Lazarus 1.4.4 com ACBr trunk2 do SVN. Criei um novo projeto do zero Adicionei no form vazio o componente ACBrMail Pressionei F9 Veio o form vazio; ao clicar em fechar (botão X), TRAVOU. A tela não fecha e depois de um tempo fica cinza. Fiz um debug passo a passo, travou na seguinte linha de código: procedure TACBrMail.Clear; begin ClearAttachments; fSMTP.Reset; { <============= AQUI } fMIMEMess.Header.Clear; fMIMEMess.Clear; fReplyTo.Clear; fBCC.Clear; fSubject := ''; fBody.Clear; fAltBody.Clear; end;
  5. Segue unit ACBrBancoBrasil com a correção acima MAIS a correção abaixo, que usa a propriedade MultaValorFixo que criei anteriormente na unit ACBrBoleto. IfThen((PercentualMulta <> null) and (PercentualMulta > 0), IfThen(MultaValorFixo,'1','2'), '0') + // 66 - 66 1-Valor fixo / 2-Percentual / 0-Não cobrar multa ACBrBancoBrasil.pas
  6. Vamos enviar também o ACBrBancoBrasil.pas que usa essa nova propriedade. Colocaremos junto com as mudanças na LerRetorno240: http://www.projetoacbr.com.br/forum/topic/26159-acbrbancobrasil-lerretorno240-x-nosso-numero/
  7. Pelo que entendi, a procedure LerRetorno240 pressupõe que o NossoNumero foi gerado localmente e enviado na remessa. Nesse caso até faria sentido pegar somente o final e concatenar com o convênio. No entanto o cliente pode desejar que o BANCO gere o nosso número; nesse caso não ocorre essa concatenação e a numeração segue uma sequência do próprio banco, mudando quase todos os dígitos de um dia pro outro. Esse número, de 12 dígitos, começava com 04119XXXXXXX em 2009 e aumentou gradualmente, provavelmente para todos os clientes que usam essa modalidade. Atualmente os valores de NossoNumero gerados pelo BB começam com 04671XXXXXXX. Essa linha abaixo precisa ser corrigida, pois ela só pega os 10 últimos dígitos do NossoNumero que, segundo o manual, tem 20 dígitos: NossoNumero := copy(Linha, 45, 10); Uma possível correção seria: if ACBrBoleto.Cedente.ResponEmissao = tbBancoEmite then NossoNumero := copy(Linha, 38, 20) else NossoNumero := copy(Linha, 45, 10);
  8. Na unit ACBrBancoBrasil a procedure LerRetorno240() pega o Nosso Número na posição 45 (10 dígitos) do Segmento T, mas no manual (versão 09.1 de 19/10/2015) este campo está na posição 38 (20 dígitos). Está correto? Confesso que achei estranho, pois está assim nos dois trunks, mas revisamos aqui várias vezes e parece que está mesmo diferente. Temos um arquivo de retorno onde o nosso número está de fato na posição 38 com 20 posições (usando 12 posições incluindo um zero à esquerda). Alguém está processando o retorno Banco do Brasil, CNAB 240, com sucesso?
  9. Lembrando que postei acima um DIFF comparando meu código ao da revisão 10389. Foram incluídas três linhas e alteradas duas.
  10. Alguma objeção? Num outro post a Juliana lembrou que o nome da propriedade é PercentualMulta e pareceu ser contra a reutilização proposta. Se acharem melhor uma nova propriedade ValorMulta double ao invés da MultaValorFixo boolean que criei, avisem.
  11. Eu propus uma solução no post abaixo (que inclui uma ACBrBoleto.pas em anexo): A alternativa seria criar a propriedade "ValorMulta double" ao invés da "MultaValorFixo boolean" que criei no código em anexo lá no post.
  12. Como você resolveu isso? Acho que vai precisar mexer na classe ACBrBoleto, pois é lá que essa mensagem é montada.
  13. No Banco do Brasil (BB) há a opção de "multa fixa" que utiliza um valor ao invés de um percentual. Alguns clientes usam regras como "Acima de R$ 250 a multa é 2%, abaixo é R$ 5". Na posição 66 do segmento R há um campo onde o BB espera 1=Valor Fixo ou 2=Percentual. No entanto, a procedure TACBrBancoBrasil.GerarRegistroTransacao240 tem no segmento R o seguinte trecho de código: IfThen((PercentualMulta <> null) and (PercentualMulta > 0), '2', '0') + // 66 - 66 1-Cobrar Multa / 0-Não cobrar multa Além da discrepância entre o comentário e o código, aqui somente será passado o valor 2 (percentual), nunca 1 (valor fixo). Não existe suporte à multa por Valor Fixo? Imagino que poderia ser criada uma nova propriedade em TACBrTitulo para informar o tipo de multa (com default em percentual), talvez um MultaValorFixo boolean por exemplo, reusando a propriedade PercentualMulta como ValorMulta quando MultaValorFixo for true. Assim o código acima ficaria: IfThen((PercentualMulta <> null) and (PercentualMulta > 0), IfThen(MultaValorFixo,'1','2'), '0') + // 66 - 66 1=Valor Fixo; 2=Percentual Que tal? Segue em anexo o novo ACBrBoleto.pas e um diff dele com o trunk2 de hoje: alex@alex-desenvolvimento:~/fontes/ACBr/Fontes/ACBrBoleto$ svn diff ACBrBoleto.pas Index: ACBrBoleto.pas =================================================================== --- ACBrBoleto.pas (revisão 10389) +++ ACBrBoleto.pas (cópia de trabalho) @@ -794,6 +794,7 @@ fOcorrenciaOriginal: TACBrOcorrencia; fParcela : Integer; fPercentualMulta : Double; + fMultaValorFixo : Boolean; fSeuNumero : String; fTipoDiasProtesto: TACBrTipoDiasIntrucao; fTipoImpressao : TACBrTipoImpressao; @@ -908,6 +909,7 @@ property Versao : String read fVersao write fVersao; property SeuNumero : String read fSeuNumero write fSeuNumero; property PercentualMulta : Double read fPercentualMulta write fPercentualMulta; + property MultaValorFixo : Boolean read fMultaValorFixo write fMultaValorFixo; property ValorDescontoAntDia : Currency read fValorDescontoAntDia write fValorDescontoAntDia; property TextoLivre : String read fTextoLivre write fTextoLivre; property CodigoMora : String read fCodigoMora write SetCodigoMora; @@ -1334,6 +1336,7 @@ fValorRecebido := 0; fValorDescontoAntDia := 0; fPercentualMulta := 0; + fMultaValorFixo := false; fReferencia := ''; fVersao := ''; @@ -1604,8 +1607,8 @@ end; if PercentualMulta <> 0 then - AStringList.Add(ACBrStr('Cobrar Multa de ' + - FormatCurr('R$ #,##0.00',ValorDocumento*( 1+ PercentualMulta/100)-ValorDocumento) + + AStringList.Add(ACBrStr('Cobrar Multa de ' + FormatCurr('R$ #,##0.00', + IfThen(MultaValorFixo, PercentualMulta, ValorDocumento*( 1+ PercentualMulta/100)-ValorDocumento)) + ' após o vencimento.')); end; end; alex@alex-desenvolvimento:~/fontes/ACBr/Fontes/ACBrBoleto$ Desde já agradeço. ACBrBoleto.pas
  14. IfThen((PercentualMulta <> null) and (PercentualMulta > 0), '2', '0') + // 66 - 66 1-Cobrar Multa / 0-Não cobrar multa? Esta linha acima está no código. Está correto? Aparentemente está mandando apenas 0 ou 2 (quando deveria ser 1=Valor Fixo e 2=Valor Percentual, conforme o manual da Febraban, item G073).
  15. Continuando os testes: coloquei um componente ACBrPosPrinter manualmente (não no .lfm mas instanciando via código). FUNCIONOU em 64 bits. Então podemos concluir que o problema está no código relacionado ao design time?
  16. Eu já entendi o problema: conforme a discussão na lista de emails*, o problema está na ACBrOpenSSL em 64 bits no Linux (mais precisamente em algumas units do Libxml2-pascal, usado pela ACBrOpenSSL). Eu não usava este componente de SSL antes (no trunk) e por isso nunca tive problemas com o Linux 64 bits; no entanto, com o trunk2, a ACBrSerial (essa sim eu uso) passou a ter como dependência a ACBrOpenSSL que não funciona em 64 bits. * http://comments.gmane.org/gmane.comp.ide.lazarus.brazil/22775 Porque a ACBrSerial passou a depender da ACBrOpenSSL ?
  17. Pra constar, o erro é conhecido e está sendo discutido na lista de emails: http://comments.gmane.org/gmane.comp.ide.lazarus.brazil/22775
  18. Deixe eu ver se entendi: o ACBr trunk2 passou a ser "somente 32-bits", é isso? O ACBr trunk anterior funcionava no 64-bits - no Linux. Que tipo de alteração foi feita nos fontes pro ACBr deixar de funcionar com 64-bits no Linux? Por exemplo, o bug do FPC 2.6.x em Windows 64 está esclarecido e já foi corrigido* no FPC 2.7.x (que deve virar o FPC 3.0). * http://bugs.freepascal.org/view.php?id=12742
  19. Vocês estão confundindo com o Lazarus para Windows. Sim, é recomendado usar o Lazarus 32 mesmo no Windows 64 por conta de limitações do FPC no Windows. No Linux uso Lazarus 64 há anos (desde 2011), inclusive em um sistema com mais de 600.000 linhas. Só estou tendo problemas agora ao instalar o TRUNK2. Acredito que seja alguma outra coisa.
  20. Máquina de 64 bits. Consigo instalar, nesta ordem: laz_synapse.lpk ACBrComum.lpk ACBrDiversos.lpk Depois tento instalar o ACBrOpenSSL e dá um "Generic error while linking". Instalei a libsxmlsec1 via apt-get quando pediu. Alguém tem alguma dica?
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.