Blz, Caio ? Agora (1), sim, pode haver ( e acontece direto = ) lançamentos retroativos, seja por necessidade ou por erro (como um lançamento feito com data errada, ex., numero do mês digitado errado, teria que ser excluído de um ponto/data do extrato para ser inserido em outro. Agora (2), sim, imagine que sempre terá vários - infinitos - lançamentos anteriores, e, sim, precisará recalculá-los, pode preparar rotinas para isso. Sentiu na pele a (dor) dos analistas dos Conta Corrente dos bancos ? Não tem mágica = ). Complexo, sim. Complicado, não. Tenha um conceito em mente que facilita. Imagine como faria isso no papel primeiro. Como nossos pais e avós fizeram por muito tempo antes dos computadores. Lembro do meu pai me contar que o gerente olhava o SALDO um um BLOCO com 5 dedos de altura de FORMULÁRIO CONTINUO, e só havia UM SALDO POR DIA para toda uma agencia bancária ! Pira = ) Então, pense num livro para cada conta sua. Pense num linha para cada movimento/lançamento de credito ou débito. Livros contábeis são assim: uma linha para cada lançamento, uma 1a primeira coluna para valor crédito, uma 2a segunda coluna para valor débito, e uma 3a terceira coluna para SALDO DO DIA (pode ser ZERO, positivo ou negativo só naquele dia), e uma 4a coluna para SALDO GERAL ou ACUMULADO, que - este sim - leva em conta o SALDO DO DIA ANTERIOR. Pense que, no fim de cada dia ( = fim do expediente bancário ), para cada Conta/Livro-Caixa, VOCÊ, o Hércules ( trampo hercúleo = ), gerente dessa agência, (passa a régua) abaixo da última linha do dia, e faz uma linha de totais: 1a coluna: soma créditos, 2a coluna: soma débitos, 3a coluna: CRED + DEB = movimento do dia, 4a coluna: valor 3a coluna de HOJE, SOMADA com a 4a coluna do dia ANTERIOR. Simule isso numa planilha do MS-Excel ou OpenOffice-Calc (sou do tempo do Lotus-1-2-3 = ), Creio que durante e depois desse exercício conceitual as rotinas/procs/metodos java vao surgindo sozinhas na sua cabeça. Faça primeiro o calculo de saldo diário e confira. Depois simule um lançamento errado (errar é humano, mas um sistema que não facilita a correção do erro é desumano = ), onde um dado movimento (CRED ou DEB) vai MUDAR DE DATA, isto é, excluir da uma data, RECALCULAR saldos, e incluir em outra - que pode ser ANTES OU DEPOIS dessa, atenção nesse detalhe - e RECALCULAR saldos de novo. Sugestão: crie duas funções: ( incluirMovimento( dataYYYYmmDDHHMMSS, valor (com 2 decimais para lidar com grana$), operaçãoCredDeb ) ] e outra [ excluirMovimento( dataYYYYmmDDHHMMSS, valor, operaçãoCredDeb) ]. Assitiu filmes de viagem no tempo, alteração de passado, reflexo no futuro ? Bem isso = ] Divirta-se ! Se conseguir fazer isso, terá um sistema redondinho. Veja que ter as somas parciais prontas para cada dia na 3a coluna vai economizar esforço de não recalcular todos os dias, recalculando apenas os dias onde o movimento foi excluído ou inserido, e depois recalculando a 4a coluna desse dia em diante, até o presente. Quando abrir seu próprio banco quero uma conta com isenção de tarifas, ok ? Pergunte de novo se algo ficou confuso. Tive que fazer esse sistema recentemente para um controle de pontuação. Sugestão: Uma tabela MovimentoPorDataPorConta (alias MOV), uma tabela TotalPorDiaPorConta (alias TOTDIA), uma tabela SaldoDoDiaPorConta (alias SALDODIA). PROIBIDO USAR UPDATE NA TABELA MOVIMENTO ! A cada insert/delete de movimento, independente do diaYYYYmmDD, A coluna Saldo da tabela TotalPorDiaPorConta sera (re)construida com SUM ( (+)MOV.ColunaCredito (-)MOV.ColunaDebito) GROUP BY diaSemHoraYYYYmmDD, numeroConta, numeroAgenciaSeTiver. A coluna Saldo da tabela SaldoDoDiaPorConta = SUM( TOTDIA.Saldo ) GROUP BY dataYYYYmmDD, numeroConta; Resumo: Soma Movimentos e obtem SaldosPorDia, Soma SaldosPorDia e obtem SaldoAtual. Na prática, a cada movimento se recalcula (quase) tudo ! Não se esqueça de me dar isenção de tarifa no seu banco, Sr Banqueiro = ) [ ]´s
