Ir para conteúdo
  • Cadastre-se

OlavoJr

Membros
  • Total de ítens

    40
  • Registro em

  • Última visita

Tudo que OlavoJr postou

  1. Na impressão do boleto carnê a informação com o endereço do cedente o objeto esta AutoSize=True e como o espaço é mais reduzido esta sobrepondo o texto mais a direita "Agência / Código Beneficiario". Somente setei a propriedade do objeto txtEndCedenteCarne para False. Segue o arquivo com alteração. P.S.: @Juliomar Marchetti Em lazarus não tem este objeto para o endereço do cedente, por isso não estou enviando o lfm, quando a implementar o objeto lá na verdade ainda estou entendendo como funciona o compartilhamento do mesmo.pas, por isso não fiz isso também. ACBrBoletoFCFortesFr.dfm
  2. Boa tarde! @Juliomar Marchetti e @Juliana Tamizou vi que foi liberado uma correção envolvendo os mesmos forms que eu havia alterado e gerou um CONFLITO, houve algum problema em aceitar esta alteração?
  3. Bom dia, @Juliomar Marchetti e @Juliana Tamizou referente a esta implementação, esta pedente algo? ou de alguma forma não foi aprovada? Algo mais que eu deva fazer para que seja postada no svn?
  4. Segue arquivos atualizados para o Delphi e Lazarus (como pediu Juliomar). Aproveito e peço uma dica, encontrei uma dificuldade em entender como é melhor fazer nestes casos quando é alterado o DESIGN, de qualquer objeto, que tenha o seu .PAS compartilhado (delphi e lazarus) como foi este caso, por que como mexi inicialmente somente no Delphi (apaguei e inseri alguns Draw e Label, no design), depois quando fui "fazer novamente" no Lazarus, puder perceber que senão fizer na "mesma ordem" visual que fiz no Delphi as nomeclaturas não batem, então minha pergunta como vocês procedem nestes casos, tipo fica as 2 IDEs aberta e joga um TRLDraw no delphi e ja vai no Lazarus e insere um tambem TRLDraw? Ou qualquer outra forma que seja mais produtiva. ACBrBoletoFCFortesFr.pas ACBrBoletoFCFortesFr.dfm ACBrBoletoFCFortesFr.lfm
  5. Segue em anexo implementação na impressão do boleto do tipo CARNÊ para o FORTES Report, foi criado os campos para impressão do Beneficiário o nome e o CPFCNPJ. Esta informação se faz necessário visto que o cliente fica somente com a parte "Recibo do Pagador" e antes não tinha as informações nome e CPFCNPJ do Beneficiário, muito necessária por exemplo em caso de informações para IRF, no meu caso é justamente uma escola e os pais precisam para preenchimento da declaração de imposto de renda. As alterações foram maiores no layout, no codigo praticamente foi somente a atribuição das novas informações. No layout usei os mesmo tipo de objetos que já havia para o Pagador, sendo o nome usado um TRLMemo = txtNomeCedenteCarne e o CPFCNPJ um TRLLabel = txtCNPJCPFCedenteCarne, foi necessário mudar o texto "Recibo do Pagador" para junto do Logo e pequenos ajuste de alturas das demais informações superiores. ACBrBoletoFCFortesFr.pas ACBrBoletoFCFortesFr.dfm
  6. Segue abaixo a unit, referente a impressão do boleto do tipo CARNE, no FORTES, para impressão do CNPJ do Beneficiário, nos demais tipos este campo do beneficiário já saem como: Cedente.Nome+ ' - '+TipoDoc + Cedente.CNPJCPF; foi seguido o mesmo padrão. Alteração foi em: procedure TACBrBoletoFCFortesFr.RLBand3BeforePrint Sendo a declaração da variavel: TipoDoc Seu valor como: case Cedente.TipoInscricao of pFisica : TipoDoc:= 'CPF: '; pJuridica : TipoDoc:= 'CNPJ: '; else TipoDoc := 'DOC.: '; end; E o valor do campo antes: txtNomeCedente.Caption := Cedente.Nome; Passa a ser: txtNomeCedente.Caption := Cedente.Nome+ ' - '+TipoDoc + Cedente.CNPJCPF; ACBrBoletoFCFortesFr.pas
  7. Notei que no header do Bradesco, foi feito uma alteraçao incorreta de acordo com a documentação que consta no svn do ACBR (svn://svn.code.sf.net/p/acbr/code/tools/Bancos) que é a versão 08, inclusive em anexo coloquei um versão mais nova que á 10 (de 12/08/2015), acredito ser útil! Se observarem em ambas, no Header de ambas as documentações, consta que o registro HEADER da posição 188 a 394 (277 posições) deve ser "Brancos", só que foi aberto um Tópico em ( ) aonde foi citado um problema no registro de TRANSAÇÃO TIPO 1 e o codigo postado era referente a esta alteração no HEADER que esta incoerente com a documentação. Resumindo, acredito que a procedure deva voltar de acordo como era antes, mais especificamente no arquivo ACBrBancoBradesco.pas na procedure GerarRegistroHeader400: Codigo ATUAL: procedure TACBrBancoBradesco.GerarRegistroHeader400(NumeroRemessa : Integer; ARemessa:TStringList); var wLinha, ATipoInscricao: String; begin with ACBrBanco.ACBrBoleto.Cedente do begin case TipoInscricao of pFisica : ATipoInscricao := '1'; pJuridica: ATipoInscricao := '2'; else ATipoInscricao := ''; end; wLinha:= '0' + // ID do Registro '1' + // ID do Arquivo( 1 - Remessa) 'REMESSA' + // Literal de Remessa '01' + // Código do Tipo de Serviço PadRight( 'COBRANCA', 15 ) + // Descrição do tipo de serviço PadLeft( CodigoCedente, 20, '0') + // Codigo da Empresa no Banco PadRight( Nome, 30) + // Nome da Empresa IntToStr( Numero )+ PadRight('BRADESCO', 15) + // Código e Nome do Banco(237 - Bradesco) FormatDateTime('ddmmyy',Now) + Space(08)+'MX' + // Data de geração do arquivo + brancos IntToStrZero(NumeroRemessa,7) + Space(101) + // Nr. Sequencial de Remessa + brancos ATipoInscricao + Space(175) + // Cedente é pessoa Física ou Júrdica IntToStrZero(1,6); // Nr. Sequencial de Remessa + brancos + Contador ARemessa.Text:= ARemessa.Text + UpperCase(wLinha); end; end; Codigo ANTERIOR: procedure TACBrBancoBradesco.GerarRegistroHeader400(NumeroRemessa : Integer; ARemessa:TStringList); var wLinha: String; begin with ACBrBanco.ACBrBoleto.Cedente do begin wLinha:= '0' + // ID do Registro '1' + // ID do Arquivo( 1 - Remessa) 'REMESSA' + // Literal de Remessa '01' + // Código do Tipo de Serviço PadRight( 'COBRANCA', 15 ) + // Descrição do tipo de serviço PadLeft( CodigoCedente, 20, '0') + // Codigo da Empresa no Banco PadRight( Nome, 30) + // Nome da Empresa IntToStr( Numero )+ PadRight('BRADESCO', 15) + // Código e Nome do Banco(237 - Bradesco) FormatDateTime('ddmmyy',Now) + Space(08)+'MX' + // Data de geração do arquivo + brancos IntToStrZero(NumeroRemessa,7) + Space(277) + // Nr. Sequencial de Remessa + brancos IntToStrZero(1,6); // Nr. Sequencial de Remessa + brancos + Contador ARemessa.Text:= ARemessa.Text + UpperCase(wLinha); end; end; LAYOUT 400 POSIÇÕES_Troca_de_Arquivos_Cobrança_Versao_Portugues.pdf ACBrBancoBradesco.pas ACBrBancoBradesco.pas
  8. Só por motivo de curiosidade "Graça", embore MEU gestão tenha o ACBr embutido, achei importante o que falou de "migração emergencial", talvez essa solução de módulos separados seja bem valida devido as necessidade que temos em termos de "compilador e objetos" e o ACBr tenhas as suas, então pergunto como é o funcionamento dos seus módulos (digo seu gestão e os módulos que desenvolveu somente para o ACBr) como eles se integram/conversam, para ter noção de um caso reald e uso nesta situação, se é que isso seja feito de forma transparente, ou seja, sem a ação do usuário?
  9. Conforme o guia do EFD para o PIS/COFINS o registro F600 a coluna IND_NAT_REC não é obrigatória e somente estou conseguindo validar estando esta coluna vazia, sendo assim proponho que no ACBrEPCBlocos.pas seja inserido o valor inrNenhum para o "Indicador da Natureza da Receita", conforme abaixo (inicia-se na linha 864 codigo atual): //Indicador da Natureza da Receita TACBrIndNatRec = ( inrNaoCumulativa = 0, // 0 // Receita de Natureza Não Cumulativa inrCumulativa = 1, // 1 // Receita de Natureza Cumulativa inrNenhum = 9 // 9 // Nenhum/Vazio ); E no ACBrEPCBloco_F_Class.pas na procedure WriteRegistroF600, seja considerado o teste abaixo (inicia-se na linha 1072 codigo atual): case IND_NAT_REC of inrNaoCumulativa : strIND_NAT_REC := '0' ; // 0 // Receita de Natureza Não Cumulativa inrCumulativa : strIND_NAT_REC := '1' ; // 1 // Receita de Natureza Cumulativa inrNenhum : strIND_NAT_REC := '' ; // Vazio end; As units com alterações expressadas estão em anexo. P.S.: No fonte da unit ACBrEPCBloco_F_Class.pas EM ANEXO, consta tambem a alteração discutida no post: http://www.projetoacbr.com.br/forum/topic/9139-erro-na-valida%C3%A7%C3%A3o-sped-contribui%C3%A7%C3%B5es/#comment-173320 que até o momento não houve resposta dos moderadores para upload ao svn e para mim tambem foi necessária para conseguir validar, se acharem por bem subir as duas no momento ou só esta se for o caso, fiquem a vontade. ACBrEPCBloco_F_Class.pas ACBrEPCBlocos.pas
  10. Tive o mesmo problema (para imobiliaria) e para resolver havia comentado a linha de geração do M205, mais a alteração no codigo proposta pelo @lsledo acredito ser a mais correta: Na unit ACBrEPCBloco_F_Class, procedure TBloco_F.WriteRegistroF200(RegF010: TRegistroF010), ficou desta forma: if (Bloco_0.Registro0001.Registro0110.COD_INC_TRIB <> codEscrOpIncCumulativo) then WriteRegistroF205( RegF010.RegistroF200.Items[intFor] ); Visto a explicação dada pelo @sempredrf: Comentei a respeito dos registros aqui com a contadora da imobiliária, segundo ela esse F205 seria apenas para o regime não-cumulativo (lucro real) e no caso estou enviando o arquivo como regime cumulativo(lucro presumido) .
  11. Sem a alteração acima proposta, como não é atribuido valor na "criação do objeto" a propriedade fpTamanhoCarteira fica 0 (zero). Na verdade o problema ocorre devido a classe base ACBRBoleto, para a propriedade Carteira ter o metodo de escrita chamando SetCarteira e o problema acontece dentro deste metodo exatamente na linha: fCarteira:= IntToStrZero(aCarteira,TamanhoCarteira); Chamando esta função como o parametro TamanhoCarteira = 0 o retorno vem vazio.
  12. Ao executar a função de "LerRetorno" para a CAIXA, a propriedade CARTEIRA não esta sendo preenchida devido na criação do objeto não ter sido definido a propriedade fpTamanhoCarteira, que fica com zero e perde o conteudo lido da linha do texto de retorno. Para correção é necessário na unit ACBrBancoCaixa no construtor do objeto atribuir o valor 2 a propriedade fpTamanhoCarteira, segue abaixo correção e em anexo unit com a implementação. constructor TACBrCaixaEconomica.create(AOwner: TACBrBanco); begin inherited create(AOwner); fpDigito := 0; fpNome := 'Caixa Economica Federal'; fpNumero:= 104; fpTamanhoAgencia := 5; fpTamanhoMaximoNossoNum := 15; fpTamanhoCarteira := 2; fValorTotalDocs:= 0; fpOrientacoesBanco.Clear; fpOrientacoesBanco.Add(ACBrStr( 'SAC CAIXA: 0800 726 0101 (informações, reclamações, sugestões e elogios) ' + sLineBreak + 'Para pessoas com deficiência auditiva ou de fala: 0800 726 2492 ' + sLineBreak + 'Ouvidoria: 0800 725 7474 (reclamações não solucionadas e denúncias) ') + sLineBreak + 'caixa.gov.br '); end; ACBrBancoCaixa.pas
  13. OlavoJr

    SICREDI - Erro remessa

    Na geração do SICREDI arquivo layout 400 no registro INFORMATIVO foi adicionado um tempo atrás uma condição para o atributo "wModalidade" e gerar o "nosso numero", com isso a posição 008 a 017 ficou em duplicidade por que "não foi removido a linha que já fazia isso de forma fixa", para correção é necessário remover a linha 430, abaixo esta o codigo mostrando a alteração e coloquei em anexo caso desejem subir no svn. ANTES: wLinha:= '5' + // 001 a 001 - Identificação do registro Informativo 'E' + // 002 a 002 - Tipo de informativo PadLeft( ACBrBanco.ACBrBoleto.Cedente.CodigoCedente, 5, '0')+ // 003 a 004 - Codigo do Cedente ifthen(wModalidade = 'A', PadRight(NumeroDocumento, 10), padLeft(wNossoNumeroCompleto,10,'0')) + // 008 a 017 - Seu numero PadRight( NumeroDocumento, 10) + // 008 a 017 - Seu numero Space(1) + // 018 a 018 - Filler wModalidade + // 019 a 019 - "A"-Com registro "C"-Sem registro TextoRegInfo + // 020 a 347 Space(47) + // 348 a 394 - Filler IntToStrZero( ARemessa.Count + 1, 6); // 395 a 400 - Número sequencial do registro ARemessa.Text:= ARemessa.Text + UpperCase(wLinha); DEPOIS: wLinha:= '5' + // 001 a 001 - Identificação do registro Informativo 'E' + // 002 a 002 - Tipo de informativo PadLeft( ACBrBanco.ACBrBoleto.Cedente.CodigoCedente, 5, '0')+ // 003 a 004 - Codigo do Cedente ifthen(wModalidade = 'A', PadRight(NumeroDocumento, 10), padLeft(wNossoNumeroCompleto,10,'0')) + // 008 a 017 - Seu numero Space(1) + // 018 a 018 - Filler wModalidade + // 019 a 019 - "A"-Com registro "C"-Sem registro TextoRegInfo + // 020 a 347 Space(47) + // 348 a 394 - Filler IntToStrZero( ARemessa.Count + 1, 6); // 395 a 400 - Número sequencial do registro ARemessa.Text:= ARemessa.Text + UpperCase(wLinha); ACBrBancoSicredi.pas
  14. Gostaria que minha aplicação pudesse imprimir a DANFE tanto pelo FAST REPORT como pelo FORTES REPORT, estou já com o trunk2 e os 2 componentes instalados e funcionando corretamente, desde que em design defina a propriedade DANFE do ACBeNFE ora para o FAST ora para o FORTES imprime sem problema, existe algum problema trocar no objeto ACBrNFe a propriedade DANFE em "runtime", tipo: ACBrNFeDANFEFR (objeto do FAST) ou ACBrNFeDANFeRL (objeto do FORTES)? Os objetos ficam logo no menu principal, primeiro formulário a ser criado e executado, sendo assim debugei e vi que logo que cria o objeto ACBrNFe já cria a DANFE que este configurada em "design", tentei trocar em runtime, confome codigo abaixo logo no OnShow, mais no momento da impressão (ACBrNFe.NotasFiscais.Imprimir;) deu a mensagem: Componente DANFE não associado, qual seria a forma correta de proceder neste caso? if g_GeradorRelatorioDANFE = 'FR' then begin ACBrNFe.DANFE := ACBrNFeDANFEFR; ACBrNFeEvento.DANFE := ACBrNFeDANFEFR; end else begin ACBrNFe.DANFE := ACBrNFeDANFeRL; ACBrNFeEvento.DANFE := ACBrNFeDANFeRL; end;
×
×
  • 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.