Transactions

Transactions are the core of our Financial Services Engine. Transactions can record values (you configure via Transaction Type Values), in multiple currencies, using your rules (configured via Transaction Codes), with automated GL Postings across multiple Ledgers, Entities and Currencies.
Transactions have Financial Dates, Cancel/Correct, and Allocation Path technology built in to them. You can configure whatever complex financial transactions you wish using our engine.

Transaction Features

Transactions are responsible for a lot of core functionality throughout the Financial Services Engine. At their simplest they allow you to record transactional values in multiple currencies against any instrument in the system. These Transactions can also create GL Posting entries against GL Accounts in multiple ledgers and currencies.

Core Concepts

A Transaction records values, that you can configure, in 3 different currencies against an Entity - normally a legal company. The Transaction occurs on a Transactions Date, but is also recorded with a Financial Date depending on the Period Closings against the Entity of the Transaction.

Every Transaction ever created in the system (including in Canvases) has a unique Reference number that auto-increments throughout the system. Even if you delete that Transaction, the reference number will never be used again. 

Transactions are different from our GL Posting entries. GL entries purely record a GL Account and its associated debit/credit amount, in 3 different currencies, against the Entity for the Financial Date and a specified Ledger. This makes for incredibly efficient and simple reporting - a key requirement of complex financial accounting.

GL Postings must always be created via a Transaction even if that transaction has no values being recorded.

Transaction Values

You can configure as many different values that transactions can track as you like. The platform (without an accelerator) doesn't come pre-configured with any transaction values so you can quickly create them specifically for your industry. For instance for asset management you could configure the following Transaction Type Values [more info]:

  • Portfolio
    • Current Cost
    • Cost Sold
    • Contingent Liability
    • Expense Accrual
    • Expense Payment
    • Income Accrual
    • Income Payment
    • etc...
  • Capital
    • Commitment
    • Expenses
    • Management Fee
    • Placement Fee
    • Investment Contribution
    • Tax
    • Distribution - ROC
    • Distribution - Gain
    • Distribution - Income
    • etc...

Once created these are available as values you can use in any Transaction you configure providing an easy mechanism to expand your transaction values as your business requirements evolve.

Multiple Currencies

The system ensures all Transactions, and any associated GL entries, are all recorded in up to 3 currencies. By using 3 currencies the system ensures the maximum number of currencies in play in any single transaction will always be recorded. These currencies are as follows:

  • Local Currency
    This is the local currency of the Transaction. Usually the currency of the Instrument the Transaction is operating against. If there isn't an Instrument it is the currency of the Entity of the Transaction
  • Functional Currency
    This is the currency of the legal Entity for this Transaction. 
  • Reporting Currency
    This is the currency of the whole Entity Set the legal Entity of the Transaction resides in. In other words this is the reporting currency for the group of entities in the entity structure as a whole. The one consistent currency across every transaction for reporting and consolidation.

The system automatically handles pulling in the Exchange Rates [see here for more info] between Local to Functional currency (Recorded as FX Rate) and between Local and Reporting Currency (Recorded as Reporting FX Rate).

When you enter amounts in a Local Currency the system will automatically handle translating this into Functional and Reporting amounts for you. Depending on the Transaction Code config you may be able to enter those amounts directly (usually for FX Transaction operations) or provide spot fx rates.

Multiple Dates

Transactions always have multiple dates associated with them to ensure they are used as effectively a possible. Those dates are:

  • Transaction Date
    The actual date of this Transaction
  • Financial Date
    The Financial Date for the G/L. Calculated from the closest Open Period for the legal Entity this Transaction is against. If the Transaction Date is in the closest Open Period the Financial Date will be the same. If it is not, it will be the 1st available date for the closest Open Period on that legal Entity
  • Settlement Date
    Optional date available on the Transaction if setup from the Transaction Code. This records the settlement date. The Financial Date for the GL entries can be calculated from the Financial Date of the Transaction (usually the same unless the Entity for the GL Posting is configured to be different than the entity of the Transaction) or from the Settlement Date of the Transaction
  • Last Updated Date
    Every record (not just a Transaction) in the system is fully audited [see here for more info] and as such has a Last Updated datetime stamp associated with every record change. This allows you to see prior versions of the Transaction "as of" any historic point in time
  • Effective Date
    The Transaction Allocation and GL Posting Allocation records can be transferred through a Transfer [more info] process. As such if these are records that are Transferred they will have an Effective Date populated indicating when the Transfer is effective from.

These dates ensure your Transaction, and GL Entries, can be reported on correctly throughout the system, and that the entries are processed in the correct manner.

Transaction Structure

A Transaction can have the following structure:

  • Transaction
    • Associated Values
      Optional a Transaction doesn't need to have Transaction values if purely recording GL Postings
    • GL Postings
      Optional a Transactions need not have any associated GL Posting entries
      • GL Posting Allocations
        A breakdown of the GL Posting amounts by each ultimate owner from the Transactions Allocation Path
    • Allocations
      • A breakdown of the Associated Values of the Transaction by each ultimate owner from an Allocation Path
    • Sub Transactions
      Optional. 

Transaction Sets

A Single Transaction can also be part of a Transaction Set, this can occur in one of two scenarios. The first being when the Transaction Code itself forces the creation of multiple related Transactions, in which case the Transaction looks like this:

  • Root Transaction
    • Child Transaction 1
    • Child Transaction 2
    • ... etc

The user will see the Root Transaction header information as normal. All these Child Transactions have the same ParentTransactionID set. They will also see a Transaction Set View that lets them navigate through the root and other related transactions like so:

  • Root Transaction
  • Child Transaction 1
  • Child Transaction 2
  • ... etc

All the child transaction views will respond to changes in the selection of the Transaction from the Transaction Set view.

The other area a Transaction Set comes into play is when all transactions are children of the same entity item. This can be an instance of any entity in the system, for instance Blend Transactions use the transaction set view where they are the parent item to the set of transactions they automatically create. These set of transactions are normal transactions in their own right but all have the same ParentItemID set. Here again you can see all the related transactions in one place and easily modify/view them.

If you create any new Transaction that also created child transactions (the first method of creating a Transaction Set) then the same Transaction Set View will now display both transactions that have the same parent item, and those that have the same parent transaction.

Sub Transactions are different in the sense that although they are transactions like those above, they weren't created by the user, they are only child Transactions of the Main transaction and the user can't change any of their Transaction properties. These are created to represent the transaction values moving through the structure with various different entities, and have IsHeader set to false. Only transactions that were created by the user (or custom transaction code processes) will have IsHeader set to true, appear in the Transaction Set and allow the user to modify the header values - such as selecting different Transaction Codes.

Transaction Relationships

Transactions have the following core relationships with the LemonEdge platform:

  • Transaction Code [more info]
    This specifies which Values should be recorded for this Transaction, and the rules around how the transaction behaves along with its processes. From a high level they configure the following:
    • The Ledger to use
    • Extra fields to use
    • Custom processes/rules/formulas
    • What values the transaction records
      • If users change the values recorded against the transaction
    • Any GL Postings to automatically create
      • The ledger/date/entity to use for the GL Postings
      • The value from the transaction to automatically use for the GL Posting 
      • If the user can manually create GL Postings
    • If the transaction requires an Allocation Path, or if it is dynamically calculated from the Instrument
    • If the system should record allocation breakdowns in the transaction (allowing user to change then), or if they should be determined dynamically through the Path on the Transactions
  • Entity
    The Entity this transaction is against. The Entity is any legal Entity that is part of an Entity Set, and thus can have transactions recorded against it.
    The Currency of the Entity determines the currency the system uses for the Functional currency.
    The Entity Set the Entity is a member of also has a currency, and that currency is used for the Reporting Currency of the Transaction.
  • Path
    If this Transactions isn't storing the breakdown of allocated amounts to ultimate owners, then this Path can indicate how the system should dynamically allocate these Transaction values. The requirement for a Path is determined from the Transaction Code settings, but if a Path isn't required then you must have an Instrument so the system can dynamically determine an Allocation Path from the Allocation Mapping for that Instrument.
  • Instrument
    The Instrument this Transaction is against. Instruments can be any financial instrument in your platform, for instance for Insurance they could be Policies, for Asset Management they could be Security Rounds - see Instrument for more information.
    The Instrument is also used to provide the Local Currency of the Transaction. If an Instrument isn't required and isn't specified then the Entity currency is used as the Local Currency as well.

Transaction Status

All Transactions (and anything in the API that is created inheriting from Transactions) operate using our Cancel/Correct logic. This works from any Transaction (and all child Transactions) having the following state:

  • InProgress
    This is the default state of any newly created Transaction.
    The system does not generate any GL Postings automatically when the Transaction is InProgress.
  • Committed
    When a Transaction is moved to Committed the system will automatically create associated GL Postings specified in the Transaction Code
  • Finalized
    When a Transaction is moved to Finalized the system records all the records as Locked preventing them from being updated again by any changes.
    Again any GL Postings will automatically be created according to the Transaction Code
  • Cancelled
    When a Transaction is cancelled it is also marked as Locked so the records can not be changed.
    Only a Finalized Transaction can be Cancelled.

Reports and system processes only look at Finalized (and in some cases Cancelled too) transactions, they do not look at In Progress or Committed. You can configure reports to look at InProgress/Committed specifically should you need to.

Before a Transaction is Finalized it can just be deleted as it isn't locked from any changes yet. When a Transaction is Finalized you can no longer delete it, if you want to remove it you need to Cancel the Transaction. 

Logic

The system implements Cancel/Correct logic as part of the core Transaction Process. Whenever you mark a Finalized Transaction as Cancelled the system performs the following process:

  • Marks the Transaction as Cancelled from Finalized along with all Transaction Allocations, GL Postings, GL Posting Allocations and sub Transaction records.
    This is the only change that is allowed to a record when it locked. i.e. it can change from Finalized to Cancelled, but otherwise the system throws an error. Finalized transactions are locked and can not be changed.
  • Creates a new Transaction (which receives a new auto-incremented Transaction Reference number) that is exactly the same as the original (now Cancelled) Transaction along with all associated Transaction Allocations, GL Postings, GL Posting Allocations and sub Transactions.
    • Calculates a new Financial Date for this new Transaction, and associated records, depending on the Entity of the Transaction, it's Transaction Date and the latest Period Closing on that Entity. See Period Closings for more information. 
      This Financial Date maybe the same as the original if it doesn't need to be pushed into a new financial period
    • Ensures that all values on the new Transaction, Transaction Allocations, GL Postings, GL Posting Allocations and sub Transactions have the equal, but opposite values to the original. 
    • Set this new Transaction and associated records as all having a status of Cancelled too, and marks the records as having Cancelled the original records

This way not only is the Transaction cancelled, thus excluding it from default Transaction views, reports, etc, but the system has created an equal and opposite cancelled transaction so the total nets to 0 even if the Cancelled transactions were included in reports, processes, etc.

The equal and opposite cancelled transaction maybe in a different financial period depending on Period Closings, and the Transaction Date.

Cancel/Correct

If you need to change a Finalized transaction, instead of having to create a copy of it, modify it Finalize it and Cancel the original manually we include Cancel/Correct technology that automates all these steps for you.

If you need to modify a Finalized Transaction, you can Unlock it (See Transaction View) make your changes, process them, and Save your changes. The system will the perform the following steps:

  • Takes all the changes you made against the Finalized Transaction (and it's associated records) and stores them in memory while reverting them all against the actual Finalized Transaction (as Finalized Transactions are Locked and cannot be changed)
  • Performs the above Cancelling Logic on the original Transaction
    • Marks the original Transaction (The Finalized Transaction you unlocked and were modifying), and all it's associated records, as Cancelled.
    • Creates a new Transaction (and associated records) that is the same as the original records but containing equal and opposite values
    • Marks this new transaction as Cancelled, and ensures it has the right Financial Date
  • Creates a new Transaction, along with the associated Transaction Allocations, GL Postings, GL Posting Allocations, and sub Transactions, that are exact copies of the original Transaction
  • Applies all the modifications that were previously stored in memory to the new transaction and associated records
  • Determines the new Financial Date for the transaction.
  • Runs the Transaction processing logic to process the new transaction changes
  • Marks this transaction as Finalized and as having cancelled the original Transaction.
  • Marks the Original Transaction as having been Corrected by this new Transaction.
  • Marks the Cancelling Transaction as being Corrected by this new Transaction and as Cancelling the original

This process ensures Cancelling and modifying Finalized Transactions is an easy, transparent, traceable process that is processed and accounted for correctly by the system. Most importantly it is also an automatic process baked into the core transaction processing logic meaning if you update a finalized transaction via importing, or any other mechanism, it still performs a cancel/correct.

Allocations (Capital vs Non-Capital Accounting)

Any Transaction records the required configured Transaction Values according to the Transaction Code. The same goes for any GL Postings created from those Transaction Values.

All Transactions (and GL Postings) in the system can be allocated to the ultimate owners of any of those Transactions through your entity structure.

If you don't need to track ownership allocations you can simply creating a simple Allocation Rule of 100% to a Placeholder Owner, along with a simple Allocation Path that uses that Rule, and a Mapping that maps every instrument to that Rule. This ensures everything is just allocated 100% to the one Placeholder Owner. Obviously you can change this to cater for as complex an ownership structure as you require.

The methods in which the system dynamically allocates Transaction Values is as follows:

  • Allocation Path 
    If an Allocation Path is set against a Transaction it uses this to allocate the values to the ultimate owning entites through the entity structure
  • Instrument
    If an Allocation Path is not set the system dynamically loads the Mappings to determine which Path this instrument is mapped to. It then uses that Path to allocate the values to the ultimate owning entities through the entity structure.

Sometimes you don't want to allocate the Transaction Values dynamically to determine the allocated values for the ultimate owners. This is typically the case when creating Capital Transactions for the ultimate owners on the root entities in the entity structure. In these cases you can specify that the Transaction records the Values as normal, but that it also records a hardcoded breakdown of those amounts by ultimate owner. This allows you to specify precisely the allocation amounts to the ultimate owning entities as well as the total amounts against the transaction. 

In these cases the system doesn't need to allocate the Transaction, and GL Posting, amounts via any Path, instead you've already provided the breakdowns as part of the Transaction, or GL Posting, itself.

The Transaction Allocation records can be populated dynamically from a Path. i.e. If a Path is selected for the Transaction and you enter 1000 for a Transaction Value it will use the Path to create the Transaction Allocation records breaking that 1000 down by all owning entities from the Allocation Path itself. Alternatively the Transaction Allocation records can be added, or altered from the allocation, manually for each ultimate owning entity.

This provides a mechanism for every Transaction, and GL Posting, in the system to have their actual values and to have that broken down by ultimate owning entity using Transaction Allocations and GL Posting Allocations, or for the system to record just the Transaction and GL Posting values and to dynamically allocate them when required from the associated Allocation Path.

From a reporting perspective this is also vastly simplified from other systems. To report you need only access the following tables:

  • Transactions
    This holds all Transactions and all their values in the system. An easy table to query and doesn't require combining multiple queries from capital, portfolio and other tables together in complicated ways.
  • GL Postings
    This holds all GL Postings and all their amounts in the system. Again one table to easily query, made even easier with our GL Rollups.
  • Transaction Allocations
    To get any Transactions values allocated to their ultimate owners you can join to this table if they are hardcoded values, if there are no entries you can simply multiply the amounts by the associated Allocation Path for this transaction and instantly get the values too.
  • GL Posting Allocations
    To get any GL Posting values allocated to their ultimate owners you can join to this table if they are hardcoded values, if there are no entries you can simply multiply the amounts by the associated Allocation Path for this transaction and instantly get the values too.

Reporting

All transactions can easily be queried using our Datasets, and other, reporting tools. The system has 4 automatically-configured SQL Wrappers that provide access to all Transactions with your configured Transaction Values. These are:

You can query these using Datasets, or any of our other reporting tools, to instantly analyse all your transactions across the entire system including all the values you've configured using Transaction Type Values [more info].

The GL can be reported like any other entity in the system using Datasets, and any of our other reporting tools. It doesn't need specific helper functions like Transactions as it doesn't have any configured fields unlike Transactions. It just stores the debit/credit amount in 3 different currencies for the specified GL account.

You can however take advantage of our hierarchical inbuilt GL reporting using GL Account Classifications [more info] and GL Rollups [more info]. This provides an easy mechanism to create consolidated standard GL reports such as Trial Balance, Capital Account Statements, etc.

Base Transactions

Base Transactions are designed to provide a common framework of functionality for all items that need to exhibit Transactional functionality. This isn't just Transactions themselves. Other features that require base transaction behaviour are:

This ensures all items that act in a transaction like manner all share the same set of functionality in a consistent, performant and easy to use way.

Transactions inherit the following functionality from Base Transactions:

  • Transaction Status
  • Unique Auto-Increment Reference Number
  • Transaction Date
  • Cancel/Correct Logic

Any Base Transaction typically has associated processing which can take time depending on the complexity of the algorithm, or the volume of data to process. As such Base Transactions have several features associated with running processes:

  • Any processing can occur at real time as users update entries
  • Long running processing can be done on save only
    • Save only processing will occur on the web service itself and not on the end client (unless directly connected to the database)
  • Processes can also be made to run as a task instead of running as part of the save, and thus can be processed by a task service without slowing the save down.

This means that a lot of the useful functionality exhibited in Transactions such as having a Status, being able to Cancel/Correct them, process them on save (or on a task service), etc are available to other system processes such as Transfers. This way a Transfer (and other processes) actually inherit the same core Transactional functionality providing a coherent approach for the end user, and a simple method to provide complex transaction behaviour to custom processes in the API.

Views

Transactions are managed through the following views:

© 2020 LemonTree Software.