Question

I am making a BI system for a bank-like institution. This system should manage credit contracts, invoices, payments, penalties and interest.

Now, I need to make a method that builds an invoice. I have to calculate how much the customer has to pay right now. He has a debt, which he has to pay for. He also has to pay for the interest. If he was ever late with due payment, penalties are applied for each day he’s late.

I thought there were 2 ways of doing this:

1. By having only 1 original state – the contract’s original state. And each time to compute the monthly payment which the customer has to make, consider the actual, made payments.
2. By constantly making intermediary states, going from the last intermediary state, and considering only the events that took place between the time of these 2 intermediary states. This means having a job that performs periodically (daily, monthly), that takes the last saved state, apply the changes (due payments, actual payments, changes in global constans like the penalty rate which is controlled by the Central Bank), and save the resulting state.

The benefits of the first variant:

• Always actual. If changes were made with a date from the past (a guy came with a paid invoice 5 days after he made the payment to the bank), they will be correctly reflected in the results.

The flaws of the first variant:

• Takes long to compute
• Documents printed with the current results may differ if the correct data changes due to operations entered with a back date.

The benefits of the second variant:

• Works fast, and aggregated data is always available for search and reports.
• Simpler to compute

The flaws of the second variant:

• Vulnerable to failed jobs.
• Errors in the past propagate until the end, to the final results.
• An intermediary result cannot be changed if new data from past transactions arrives (it can, but it’s hard, and with many implications, so I’d rather mark it as Tabu)
• Jobs cannot be performed successfully and without problems if an unfinished transaction exists (an issued invoice that wasn’t yet paid)

Is there any other way? Can I combine the benefits from these two? Which one is used in other similar systems you’ve encountered? Please share any experience.

Answer 1

Problems of this nature are always more complicated than they first appear. This
is a consequence of what I like to call the Rumsfeldian problem of the unknown unknown.
Basically, whatever you do now, be prepared to make adjustments for arbitrary future rules.

This is a tough proposition. some future possibilities that may have a significant impact on
your calculation model are back dated payments, adjustments and charges.
Forgiven interest periods may also become an issue (particularly if back dated). Requirements
to provide various point-in-time (PIT) calculations based on either what was “known” at
that PIT (past view of the past) or taking into account transactions occurring after the reference PIT that
were back dated to a PIT before the reference (current view of the past). Calculations of this nature can be
a real pain in the head.

My advice would be to calculate from “scratch” (ie. first variant). Implement optimizations (eg. second variant) only
when necessary to meet performance constraints. Doing calculations from the beginning is a compute intensive
model but is generally more flexible with respect to accommodating unexpected left turns.

If performance is a problem but the frequency of complicating factors (eg. back dated transactions)
is relatively low you could explore a hybrid model employing the best of both variants. Here you store the
current state and calculate forward
using only those transactions that posted since the last stored state to create a new current state. If you hit a
“complication” re-do the entire account from the
beginning to reestablish the current state.

Being able to accommodate the unexpected without triggering a re-write is probably more important in the long run
than shaving calculation time right now. Do not place restrictions on your computation model until you have to. Saving
current state often brings with it a number of built in assumptions and restrictions that reduce wiggle room for
accommodating future requirements.