/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 account (We take money out of the cardholder's account) | 20.00 | |
| ATM Network (We owe the money to the network now) | 20.00 |
(both liabilities as seen from an issuer perspective, fees not included here for simplicity)
Sounds very nice, but we have a problem, this transaction is still unsettled until we get a batch close or completion transaction, 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, when we get a pre-auth, we could post:
Pre Authorization
| Debit | Credit | Layer | |
|---|---|---|---|
| Cardholder's checking account (We take money out of the cardholder's account) | 20.00 | 1 | |
| ATM Network (We owe the money to the network now) | 20.00 | 1 |
(In this example, '1' would be the 'pending' layer).
Completion
| Debit | Credit | Layer | |
|---|---|---|---|
| Cardholder's checking account | -20.00 | 1 | |
| ATM Network | -20.00 | 1 | |
| Cardholder's checking account | 20.00 | 0 | |
| ATM Network | 20.00 | 0 |
(Now it´s confirmed, we "ground" it)
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).
The layer number is arbitrary to a given miniGL application. On multi-currency systems, we use the currency ISO number as the accounting layer for a given currency.
When you ask for a balance for a given account at a given journal, miniGL gives you the ability to get the balance for a set of layers. This comes very handy when computing accounting versus available balances in ATM and POS transactions. You ask getBalance(journal, account, 0) and you get the accounting balance. You ask for getBalance(journal, account, 1) and you get the pending transactions (still unsettled). But if you ask getBalance(journal, account, 0,1) miniGL combines both layers to give you the available balance. We also use a third layer for overdrafts (used in credit card applications), say layer '2', so on certain transactions that would allow an overdraft (i.e. POS purchases), we could check getBalance(journal, account, 0,1,2).
I just hope the guy in the mail stamp up there is not twisting in his crave ... :)