jPOS.org

/by apr/

As a follow-up to the recent post about miniGL layers we have removed support for foreign amounts at the transaction.entry level, foreign currencies are now handled in their own layer.

That means that if you have a checking account and a savings account (we usually figure out the account type based on the content of the processing code field) in multiple currencies, you don´t need a separate set of accounts (one per type), the same account can hold transactions in multiple currencies.

As mentioned in the previous post, we use layers to deal with pending versus real transactions (think pre-auth/completion) and we found an easy way to add multi-currency support by defining a PENDING_OFFSET constant.

We are still working in the layers plan for our jCard system, but as an initial take, we have defined the PENDING_OFFSET=1000 and we store transactions in their corresponding layer using the iso4217 currency code, so e.g.: we store real dollars in 840 and pending dollars in 1840 (same goes for other currencies).

So far the new setup looks extremely simple and straightforward.

A close friend and CPA has contributed a very nice idea to the mix, conversion layers. I´m still not sure if we want to handle them with the existing database schema or we want some supporting tables for that, it has been good food for thought for now.

here is a very nice article by Andy about implementing an ISOPackager. Highly recommended if you are new to jPOS and you are trying to figure out how to connect to a remote host.

/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:

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.:

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 …