miniGL Layers

/by apr/

I´ve added a new feature to miniGL:   Layers.

This new feature is designed to support multiple balances for a single account, such as available versus accounting balance. We could use some flags for unsettled transactions, or pre-auths waiting for completion, but with this new layers support everything gets more simple, reusable and IMO elegant.

Imagine a simple ATM withdrawal transaction:

Debit Credit
Cardholder´s checking acount 20.00 (We take the money out of the cardholder´s account)
ATM Network 20.00 (we will owe the money to the network)
(both liabilities as seen from an issuer perspective, fees not included here for simplicity’s sake)

Sounds very nice, but we have a problem, this transaction is still unsettled until we get a batch close, so if we don´t have this new layers feature, we would end up having either some kind of flag or duplicating accounts, i.e:

  • Cardholder´s checking account
  • Cardholder´s checking account (pending)
  • ATM Network account
  • ATM Network account (pending)

With our new layered approach, we post real transactions to layer zero (ground) and pending transactions to say layer one. When the transaction gets settled at the end of the day, we just reverse the effect of the transaction in layer one (blue) and post it to layer zero (black), e.g.:

Debit Credit
Cardholder´s checking acount 20.00 (Now it´s confirmed, we “ground” it)
ATM Network 20.00 (reverse effect on the “pending” layer)
ATM Network 20.00 (Now it´s confirmed, we “ground” it)
Cardholder´s checking acount 20.00 (we take it off the “pending” layer)

I´ve modified the existing rule implementations in order to support this new layers feature, e.g. the DoubleEntry rule (that verifies that debits equals credits in the reporting currency for a given GLTransaction) now accepts a list of layers to check, so we can be very strict in some layers (such as the ground layer aka the real deal) while more relaxed in other ones. minigl.dtd has been modified in order to support a new <layers> element in rule definitions.

Some other uses for this include data-entry application where a junior clerk could post transactions to a given layer for later verification, then someone else with enough karma to authorize the transaction would “ground” it. We can use this feature to track “budgets”, “cost centers” or just to ease some rule implementations (e.g.: we can have minimum balances layer, a max balances layer, and so on).

This new feature is in our internal lab repository (PEP eyes only) but will hit the miniGL repository (both trunk and branches/h3) asap.

I just hope the guy in the mail stamp up there is not twisting in his crave … :)

Printed from: http://jpos.org/blog/2006/09/minigl-layers/ .
© 2010.