Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>An age-old problem that has never been elegantly resolved.</p> <p>All the banking packages I've worked with store the balance with the account entity. Calculating it on the fly from movement history is unthinkable.</p> <p>The right way is:</p> <ul> <li>The movement table has an 'opening balance' transaction for each and every account. You'll need this in a few year's time when you need to move old movements out of the active movement table to a history table.</li> <li>The account entity has a balance field</li> <li>There is a trigger on the movement table which updates the account balances for the credited and debited accounts. Obviously, it has commitment control. If you can't have a trigger, then there needs to be a <strong>unique</strong> module which writes movements under commitment control </li> <li>You have a 'safety net' program you can run offline, which re-calculates all the balances and displays (and optionally corrects) erroneous balances. This is very useful for testing.</li> </ul> <p>Some systems store all movements as positive numbers, and express the credit/debit by inverting the from/to fields or with a flag. Personally, I prefer a credit field, a debit field and a signed amount, this makes reversals much easier to follow.</p> <p>Notice that these methods applies both to cash and securities. </p> <p>Securities transactions can be much trickier, especially for corporate actions, you will need to accommodate a single transaction that updates one or more buyer and seller cash balances, their security position balances and possibly the broker/depository.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload