Using Subtotal GLTRANS Postings

yellowbox

  • If set to 'True' (default), then, when GLTRANS records are created, all the GL transactions in the audit/register run are grouped/summed together by GL account and date (one lump figure per combination).

  • If set to 'False', then the figures are grouped by GL account, date, and source transaction ID.

There are pros and cons to each setting…​

The advantage of setting the config to 'True' is that fewer GLTRANS records are generated and hence the performance of any SELECT on GLTRANS is better. A good example of this is summing GLTRANS amounts by period when printing financial statements.

The advantages of setting the config to 'False' are that more info is available in GLTRANS and the more granular amounts allow for easier reconciliation (both for the GL Reconciliation application and for reconciliation of sub-ledgers to the GL).

Furthermore, when the config is 'False', the existing columns REFERENCE and DESCRIPTION are populated for most registers (with the config 'True', they are left null for all registers other than GJU.EXE).

As well, the new integer column SRC_ID is populated, allowing a relational join back to the originating sub-ledger transaction, allowing crystal reports to pull more info and allowing easier sub-ledger to GL ledger comparisons. The table/column that SRC_ID represents depends on the register type and is documented in the static reference table GL_REGISTER.

Because companies might want more detailed information from some, but not all, registers, a separate config is provided for each register, allowing a company to only change the ones they need from True to False. This allows a compromise so as minimize the effect on performance (if only a single config were created, it would have been an all or nothing change, causing a substantial performance change).