Transaction Types
Transaction Types hold the core values that a Transaction is capable of recording. All the Transaction Values in the system belong to Transaction Types.
Transaction Type Features
Transaction Types hold all the fields that a Transaction can record in the system.
Transactions are built to be generically applicable across the whole of financial services, as such they don't come hard coded with particular columns for transaction values. Rather you can simply create the values that Transaction need to track.
For instance, from a capital perspective you can simply add Capital Contribution and Return Of Capital as two fields in Transactions. As simple as that you can now create, track and report on Transactions with Capital Contributions and Return Of Capital values.
Structure
Transaction Types are a simple way of grouping Transaction Values together should you have a lot of them. This makes reporting, configuration and many other processes easier.
A Transaction Type just has a user friendly name, the type (Capital or Portfolio) and a then a list of Transaction Type Values associated with it. All of these Values across all Transaction Types are the unique values that can be tracked by a Transaction.
When you create a Transaction Code it only allows Values to be recorded against a Transaction that belong to the same Transaction Type. Don't mix values across Types that need to be recorded in one Transaction.
Configuration
In many systems within financial services there is a need to configure values being tracked by transactions along with some standard values for that particular industry vertical.
Often this makes reporting complicated across two different Transaction tables. Also the configuration of Transaction Values is often solved by just pivoting a configurable Transaction table which provides vastly different performance and other issues.
With LemonEdge we have the one Transactions table, which makes reporting and other tasks vastly simpler and more efficient. Equally we don't pivot the table so reporting has the same performance as a normal hardcoded transactions table.
There is a limit for an individual Transaction of only recording a maximum of 20 values at once. However you can easily create a new sub-transaction to track the other values if you need to record more than 20 values in one Transaction.
This allows you to simply design the values you'd like on the Transactions table without having to worry about reporting, performance, or security. Whenever you need to track different values later you can simply add them with one-click.
GL Postings
Transaction Codes hold the configuration for how a Transaction behaves including any GL Postings to automatically generate.
However for certain Transaction Values it may be the case (particularly with Transactions recording Capital) that the GL Postings will always be the same. In these cases you can specify which GL Postings the system should automatically create when these Values are used in a Transaction. The Transaction Code configuration still needs to be marked to say to use those defaults or not, but it provides a quick mechanism for setting up GL Postings that should always happen for certain Transaction Values without having to recreate them for every Transaction Code.
Reporting
As you are creating all the values that are being tracked by Transactions in the system there needs to be a mechanism to include all these in our reporting tools.
There are 4 system SQL Wrappers that the system auto-generates to have all the Transaction Values you've created accessible from them. Using our reporting tools you can query these as you would any other entity in the system:
All of these queries report the Transaction Values you've created. For instance if you've created a Transaction Value called ReturnOfCapital (with a Code of ROC) In GetTransactions there will be 3 values returned for it; Local_ROC, Func_ROC, Reporting_ROC.
The same is true for every aspect of the system. For instance importing and exporting all include the Transaction Values you've created as real columns on the Transaction that can be exported and imported.
Views
Transaction Types have the following views:
