Nilson Sérgio

Olá, alguém poderia avaliar a alteração que sugeri para ver a possibilidade de adiciona-la ao svn. É uma alteração muito simples. Mudei apenas o componente txtNomeSacadoCarne: TRLLabel para mNomeSacadoCarne: TRLMemo para poder exibir o nome do cedente em duas linhas, nos casos em que o nome do cedente for extenso. Cordialmente, ACBrBoletoFCFortesFr.rar

Juliana, quando eu peguei esse arquivo percebi que ele estava no leiaute do SIGCB, contudo tive que mudar para SICOB porque o TACBrCaixaEconomica NÃO lê o nosso numero do boleto na posição indicada pelo leiaute. Veja abaixo: Linha 564 do arquivo ACBrCaixaEconomica: NossoNumero := Copy(Linha,40,11); ele sempre retorna '24000000000' o correto seria como no ACBrCaixaEconomicaSICOB que lê da posição: Linha 860 do arquivo ACBrCaixaEconomicaSICOB: NossoNumero := Copy(Copy(Linha,47,10), // sem o DV Length(Copy(Linha,47,10))-TamanhoMaximoNossoNum , TamanhoMaximoNossoNum);

segue arquivo de retorno. cordialmente, RET20121207104411473.rar

sendo assim, segue arquivo com a alteração. Cordialmente, ACBrBoletoFCFortesFr.rar

Olá, gostaria de sugerir uma alteração no modelo de boleto em carnê do Fortes Report. O campo txtNomeSacadoCarne poderia ser aumentado para caber até duas linhas de texto, o que seria util quando o nome do sacado fosse muito extenso. Para isso bastaria mudar o tipo do componente de TRLLabel para TRLMemo. Fiz aqui esta alteração e gostaria depropor como atualização para o projeto. O que acham??

Olá, estou com o seguinte problema na leitura do arquivo de retorno cnab 240 da caixa economica. Na linha 827 do arquivo ACBrCaixaEconomicaSICOB.pas existe o seguinte código: if (not LeCedenteRetorno) and ((rAgencia <> OnlyNumber(Cedente.Agencia)) or (rConta <> OnlyNumber(Cedente.Conta))) then raise Exception.Create(ACBrStr('Agencia\Conta do arquivo inválido'));[/code] acontece que a variavel rConta é lida na linha 791 da seguinte forma: [code] rConta := trim(Copy(ARetorno[0],59,12)); este campo no arquivo de retorno corresponde ao codigo do cedente não ao numero da conta. Alguém poderia me dizer se isso é um bug ou o meu arquivo de retorno está em outro leiaute? PS: segue arquivo de retorno testado.

Olá, mandei a alteração deste formulário no outro tópico que estava aberto. Grato

Olá, seguem compactados os 3 arquivos que eu alterei: 1) ACBrCaixaEconomica.pas: alterei a função FormataNossoNumero(const ACBrTitulo :TACBrTitulo): String para ela não truncar os últimos 2 dígitos do nosso número e alterei a leitura do arquivo retorno para ele ler os 4 digitos do ano do vencimento. 2) ACBrBoletoFCFortesFr.pas e ACBrBoletoFCFortesFr.dfm: alterei o tipo do componente txtNomeSacadoCarne: TRLLabel para mNomeSacadoCarne: TRLMemo para exibir quebra de linha quando os nomes forem extensos.ACBrBoleto_ArquivosAlterados.rar

Olá, desculpem ressuscitar este tópico, mas o problema na linha 559 do arquivo ACBrCaixaEconomica ainda persiste. A data de vencimento do arquivo retorno está formatada com 4 dígitos para o ano (yyddmmmm). O componentes está lendo apenas 2 dígitos para o ano. Alguém poderia corrigir e atualizar o repositório, por favor?

Caixa econômica. No arquivo de retorno leiaute 240 da caixa o nosso numero vem formatado com 17 digitos. O problema não é bem tamanho máximo do nosso número, pois este pode ser configurado. O problema é na função FormataNossoNumero, esta função só retorna 15 dígitos do nosso número.

Olá, estou com um problema na leitura do arquivo retorno leiaute 240 da classe TACBrCaixaEconomica. O TamanhoMaxNossoNumero padrão é 15, contudo o nosso numero no arquivo retorno utiliza 17 caracteres. Sendo assim, eu mudei o valor desse atributo para 17, pois estava dando erro na leitura do arquivo. Porém, com essa alteração surgiu outro problema no método FormatarNossoNumero, pois lá ele formata o tamanho nosso número com 15 caracteres truncando os últimos 2 caracteres do nosso número informado. Ex: tenho um titulo com o seguinte nosso numero 1121, quando eu seto o atributo TACBrTitulo.NossoNumero ele formata para 00000000000001121 (padrão 17 caracteres), porém a função FormatarNossoNumero retorna apenas 2400000000000011 (15 dígitos do nosso numero, somem os 2 últimos). Alguém poderia me dizer como resolver esse problema? Sds

Amigos, gostaria de compartilhar com vocês uma alteração que fiz no modelo de boleto carnê do fortes report. Eu alterei o tipo do componente txtNomeSacadoCarne: TRLLabel para mNomeSacadoCarne: TRLMemo, pois o componentes TRLLabel não possui o atributo WordBreak, não exibindo o nome de sacado muito extenso. Gostaria de saber se vocês poderiam incluir essa modificação no projeto principal? Sds

Olá, acabei de atualizar meu fonte e percebi que alteraram o trecho que formata a alíquota retornada pela RZ, no entanto o código fonte se encontra dessa forma: ACBrFiscNET.pas, linha 3276 if ( Aliquotas[ nAux2 ].Aliquota = nIcms ) then begin Result := Result + FormatFloat('00', nAux+1 ) + padL( Aliquotas[ nAux2 ].Indice, 2, '0' ) + Aliquotas[ nAux2 ].Tipo + IntToStrZero( Trunc( Aliquotas[ nAux2 ].Aliquota * 100 ), 4 ) + ' = '+ FloatToStr( nVal ) + sLineBreak ; VBruta := VBruta + nVal ; break ; end; No momento, não tenho impressora para testar, mas acredito que o resultado dessa formatação será algo como: 0101T1700. Estou certo?

Olá, removi o arquivo, atualizei e funcionou. Caso resolvido!!!

Olá amigos, encontrei um problema no método GetDadosUltimaReducaoZ da classe TACBrECFFiscNET. O formato da aliquota de ICMS está retornando 0 T1700, 1 T2500 (o correto seria 01T1700, 02T2500). Tenho duas opções: 1 - alterar esse método para ele formatar as alíquotas corretamente; ou 2 - fazer uso do método MontaDadosReducaoZ. Para isso precisaria preencher o objeto fpDadosReducaoZClass. Acho a segunda opção mais viável, pois dá mais uniformidade na geração do arquivo .ini contendo as informações da redução Z, uma vez que nas demais impressoras esse método é utilizado.

Conferido, atualizei meu ACBr e continua do mesmo jeito, acho q esta alteração só existe no seus fontes.

Minha unit não está dessa forma. Vou atualizar meu acbr pra ver.

Boa tarde, Desculpe, mas não encontrei essa atribuição no ACBrBoleto.pas. Estou com a versão atualizada.

Olá, fiz o seguinte: sobrescrevi o método montar linha digital e antes de invoca o inherited eu adicionei a linha fpModulo.MultiplicadorAtual := 2. Ficou assim: function TACBrCaixaEconomica.MontarLinhaDigitavel(const CodigoBarras: String): String; begin fpModulo.MultiplicadorAtual := 2; Result := inherited MontarLinhaDigitavel(CodigoBarras); end;

Olá amigo, acredito que para fazer isso basta você mesmo informar na inicialização do componente o caminho, pois o mesmo já possui o atributo DirArqRemessa. Por exemplo: ACBrBoleto.DirArqRemessa := {PastaDoSeuAplicativo} + '\' + FormatDateTime('mm/yy', Now); Espero que isto lhe ajude.

Olá amigos, estava fazendo testes com o ACBrBoleto e encontrei alguns problemas no trato do boleto da CEF (SIGCB), mais especificamente na geração da linha digitável e na leitura do arquivo retorno. Posto abaixo alguns ajustes que precisei fazer para que ambos os procedimentos funcionassem. 1 - ACBrBoleto.pas (linha 1835) de acordo com o manual da caixa, para calcular o digito verificador o multiplicador inicial é 2, depois 1 e assim sucessivamente. No meu código fonte estava ao contrário (primeiro 1, depois 2). O que fiz foi exatamente trocar os valores dos multiplicadores inicial e final. ficando assim: fpModulo.MultiplicadorInicial := 2; fpModulo.MultiplicadorFinal := 1; 2 - ACBrCaixaEconomica (linha 550) na leitura do arquivo retorno padrão 240 o componente estava lendo o vencimento com apenas 2 digitos no ano (ddmmyy), sendo que o arquivo retorna o vencimento com 4 digitos (ddmmyyyy). Alterei a linha citada para que fossem lidos os 4 digitos, como segue: Vencimento := StringToDateTimeDef( Copy(Linha,74,2)+'/'+ Copy(Linha,76,2)+'/'+ Copy(Linha,78,4),0, 'DD/MM/YY' );

Olá, amigos! Gostaria de notificá-los de um erro que surgiu nas últimas atualização do ACBrECF. As alíquotas do método TACBrECFDaruma.GetDataUltimaReducaoZ estão retornando zeradas. Já conferi no código. O ECF retorna o valor correto, mas no momento de preencher as Aliquotas os totais não estão sendo preenchidos. Fiz uma correção aqui para que funcionasse. Cordialmente, Nilson Sérgio

Difícil é convencer outro homologador disso dai. Será que todo mundo homologou assim? Acho q terei que alterar minha copia de trabalho.

Caros, encontrei um problema durante minha homologação e gostaria de esclarecer aqui. As informações de DAV e PV costumavam sair no rodapé do cupom fiscal com quebra de linha. Ex: MD5:89019820928029820298029820928 PVXXXXXXXXXX DAVXXXXXXXXXX Nas ultimas atualização a mensagem de rodapé está saindo sem quebra de linhas. Ex: MD5:89019820928029820298029820928PVXXXXXXXXXXDAVXXXXXXXXXX Observando o código notei que tiraram o caractere #10 do texto. Alguém sabe explicar por que? Meu homologador exigiu q houvesse a quebra de linhas entre uma informação e outra. Cordialmente, Nilson Sérgio

Olá pessoal! acho que encontrei um possível bug na classe TRegistroD3. A propriedade RegistroValido foi criada mas não está sendo utilizada no momento de gerar o arquivo dos davs emitidos. Acredito q ela deveria ser verificada para que aparecesse o caractere "?" no lugar da descrição do produto, quando o registro fosse inválido. Alguem confirma isso pra mim por favor.