Hi,

I am designing application for handling credit agreements (FB will be
used for database), and so - some of the requirements include that
program should compute and record the due interest payments and also -
if the actual credit payments are late - then compute and record
fines. So - I am considering now two approahces:
1) I can introduce the batch process which should be run at the end
of every day and in which one can compute all the necessary due
interest payments and fines which come into force in the next day.

The bad thing about this is - that batch process is required (and I
guess - there is no special triggers FB that can be fired in
predefined time points, and one should design scripts or service
application for running this batch process).
The good thing is that I can add the record for every due interest
payment and fine that comes into force in the next day and so -
although the number of such record can be large (one for every day
for every credit agreement which has not predefined payment plan, or
which is late and so - the fines should be computed for every late
day), the reports about the situation on some day and the
traceability of all the due payments and fines are excellent. And all
the reports about situation on some day or about the current
situation can be derived by simple select 'sum(...) from' those
records

2) Another approach is - to compute all the due payments and fines in
some stored procedures that can use the credit parameters. And all
the reports can be made from 'select * from' those procedure. The
system can record only the actual payments, but the system will not
be required to capture the event that some credit payment is due, or
that now the fine is for this alte day.

The good side of this approach is that there are not records for
payments that should be made, but there are only the records of
actual payments - so - database will be smaller. And there is no need
for batch process.
The bad side is - that making such stored procedures is somehow hard
(especially - if one is interested to see not only the current
situation, but the situation on some day in the past or in the
future), and it can be hard to maintain (error-prone), and the
queries for reports are not so straightforward. Even more - there are
requirements that credit payments plans can be changed (periods
extended, fines can be written off and so on) and so - those stored
procedures should have to know what the terms of the agreement was in
force in some day and so on. (If all the due payments and fines would
have been computed and recorded for every day, then reports would be
straightforward.)

Well - I guess, that the essence of this design is to make decision
wheterh the increase of due interest payment or fine (which comes
with the ending of every day) is or is not object and should I put
them into table at the end of every day or should I compute and use
these amount only when there is necessity for them.

I guess, that this is what Oracle EBS calls the 'aging'? I guess -
there should be some good advices how to compute those thing and even
more - how to test them (which should include simulation of moving
into time). How banking systems handle those issues?

Thanks for any suggestions, notes and ideas in advance