Transfers
Transfers allow you to transfer allocations, and associated transaction history, from one ultimate owning entity to another. This is a very powerful and efficient mechanism for transferring a portion, or all, of an owner entities position to one, or more, other owning entities.
Transfer Features
Transfers are hooked into Transactions, GL Postings and Allocations. When processing a Transfer the system updates all relevant Transaction Allocations, GL Posting Allocations, and Allocation Amounts to reflect the changes in the source and target entities of the transfer.
Core Concepts
A Transfer effectively transfers every record that can be transferred by creating a new record to transfer the amount from the source entity, and another set of new records that transfers that amount to the target entity, or entities.
Every record that can be transferred by the Transfer process, has the following properties:
- Has an EffectiveDate that will hold the date any Transferring records are effective from (Usually the Transaction Date of the Transfer)
- Has a TransferID that will link to the Transfer that created these records
- Has an EntityID that holds the entity amounts are being moved from or to
Note
This way all records can be viewed as normal, but they can also be viewed as of an EffectiveDate meaning you may or may not see the effects of a transfer depending what date you use. For instance looking at Transaction Allocation records with an EffectiveDate before a Transfer will mean you wont see any effects of that Transfer. Viewing it with an EffectiveDate on or after the Transfer will mean you then do see the effects.
Base Transaction Functionality
The Transfer process is itself a Transactional process. In other words it inherits the Base Transactions functionality that Transactions themselves use. See Transactions for more information. This means the Transfer process has all the following functionality:
- All Transfers have a Status
- All Transfers have a unique auto-incremented reference number
- All Transfers have a Transaction Date
- All Transfers implement the Cancel/Correct logic
This provides a huge range of beneficial functionality for Transfers ensuring they behave as Transactional items in a consistent and easy to use manner.
Transferred Records
A Transfer process is responsible for moving a percentage amount from a source ultimate owning entity and transferring it to one or more other ultimate owning entities.
Records in the LemonEdge Platform that are transferred by this process are as follows:
- Transaction Allocations of a Transaction
This is because the Transaction Allocation records hold the actual amounts allocated to an ultimate owning entity. Therefore they need to be transferred from/to the entities involved to make sure the new situation is reflected after the Transfer - GL Posting Allocations of a GL Posting
This is because the GL Posting Allocation records hold the actual amounts allocated to an ultimate owning entity. Therefore they need to be transferred from/to the entities involved to make sure the new situation is reflected after the Transfer - Allocation Amounts of an Allocation Rule
All Transactions and GL Postings that don't have specific Transaction Allocation or GL Posting Allocation records, have those amounts for the ultimate owning entities determined dynamically by multiplying the values of each through the Allocation Path for those records.
Therefore the Transfer process transfers the Allocation Amounts that form part of the Allocation Path calculation when being dynamically multiplied against Transactions or GL Postings. This way when using a Path (effective from the Transfer date or after) it will automatically include the affects of the Transfer.
By simply updating these 3 types of records, a transfer across the entire system can be efficiently, and quickly calculated in a matter of seconds.
Transfer Process
When processing a Transfer operation the system goes through the following steps for each of the above transferring record types:
- Identify all records that have the same EntityID as the Source Entity of the Transfer itself.
- This process also takes into account other matching criteria contained in the Transfer setup which may further filter the resulting records
- For each record create a new one that moves the percentage amount to transfer off that record for the Source Entity of the Transfer with an Effective Date of the Transfer Transaction Date
- For instance if we are moving 50% off the Source Entity in the Transfer and an Allocation Amount record matches holding amounts A and B of 100, 200 respectively then this would create a new record for the same Source Entity with amounts A and B of -50 and -100
- For the same set of records create a new record that moves the percentage amount to transfer to the Target Entity, or Entities, of the Transfer with an Effective Date of the Transfer Transaction Date
- For instance, using the above Allocation Amount example, if we are moving the 50% to two target Entities, A getting 40% and B getting 60%, then we would create the following two new records:
- One record for Entity A getting amounts A of 20 (40% * 40), and B of 40 (40% * 100)
- The other record for Entity B getting amounts A of 30 (60% * 50), and B of 60 (60% * 100)
- For instance, using the above Allocation Amount example, if we are moving the 50% to two target Entities, A getting 40% and B getting 60%, then we would create the following two new records:
- Process any rounding
The Transfer process itself is quite simple and powerful, and made more flexible through its own Base Transaction capabilities of Cancel/Correct and more, along with the ability to add any other custom entity type into the Transfer process itself.
Transfer Process Extender
The Transfer process itself can be extended through our API to update any custom Entities you've created according to your own rules of how they should be modified during a Transfer.
You can update this by inheriting the following class and implementing your custom logic for it:
LemonEdge.API.Processors.Transactional.TransferProcessorExtender
See our API for more details.
Period End Process Integration
The Transfer process itself is also adhered to during the Period End Process calculation. The calculation itself utilises the CreateCapitalAccountDataItems SQL Wrapper [see here for more information].
Throughout this calculation it has to pay attention to any Transfers. The system wants to mark records for the period end that occurred due to a transfer as being either a Transfer In, or a Transfer Out rather than as a Period End type. Equally it caters for Opening Balance amounts by marking the components of those that were from a Transfer In or Out.
The Transfer Up To Capital Date is an important time saving feature of the Transfer process. The Transfer operation itself is unaffected in the sense that all records are still transferred that occur prior to the Transaction Date (or Transfer Up To Capital Date if it is greater). However when the Period End calculation processes any records between the Transaction Date and the Transfer Capital Up To Date that were transferred bu the Transfer process it does not mark them as Transferred In or Out, instead it marks them as Period End as if they actually occurred like that without any transfer having taking place of those records.
Important
This is because by default a Transfer occurs on the Transaction Date, when using Transfer Capital Up To Date it is a short way of saying the Transfer still occurs up to the Transaction Date, however we have posted transactions in the system after this date that also need to be transferred. We'd rather the transfer process did this for us, but marked those as records that would have actually occurred "as is" and not due to a transfer (which is what would have happened had we taken the time to cancel them, process the transfer, and then recreate them correctly using the new rules). In other words it is a huge time saving mechanism when you are processing on-going transactions and haven't been given the finalized date of the transfer.
Reporting
You can see the effect of a transfer on Allocation Rules, and thus Allocation Paths immediately by running the GetPathInfo SQL Wrapper. The query itself always takes an effective date, if you run it with a date before the Transfer you won't see any affect, if you run it with an Effective Date equal to or greater than the Transfer Transaction Date you will see the movements on the Source/Target Entities of the Transfer/
Likewise if you run Dataset reports against Transaction Allocations, or GL Posting Allocations, you would see the effects of the Transfer. This also holds true for any custom records you've created and hooked into the Transfer process using a TransferExtender in the API.
Views
Transfers are managed through the following views:
