Amortization Schedules Storage Optimization Overview
What is amortization schedules storage optimization?
Amortization schedules, which detail the periodic loan payments, can consume significant storage space, especially when dealing with a large number of loans, lengthy terms, and many reschedules.
From the August 2024 release, Q2 Loan Servicing has been enhanced to provide you with an option of reducing the storage space used by amortization schedules. You can use of this feature by enabling it in your system.
An amortization schedule is a detailed table or chart that outlines the periodic payments on a loan over its term.
Why is the amortization schedule storage space optimization required?
To understand the need for storage optimization, let us look at the following image that depicts an amortization schedule of a contract in the Q2 Loan Servicing product:
To view a larger version of the preceding image, select this link: Image.
The preceding image displays 36 schedules, and there could be more number of schedules for different contracts based on the terms and conditions of each contract. For example, consider a loan contract with 360 terms. If there are many loans like this one, the amortization schedules will be huge, and the system may use a huge percentage of the organization's capacity to store these schedules, lowering storage space. Furthermore, when a parameter, such as the interest rate, changes and the loan is rescheduled, the amortization schedules are regenerated, requiring extra storage space in the Salesforce org.
An organization or org is the virtual space provided to an individual customer of Salesforce. Your organization includes all of your data and applications, and is separate from all other organizations. When a customer purchases Salesforce, they are provided with an org which acts as the container for all their data.
By optimizing the storage of these schedules, we can reduce the data footprint and expense. One technique to achieve this is by leveraging the space to store only those schedules in the sObject that are required, and the remaining be moved to a big object.
Amortization schedules are stored in sObject of the org. Only the schedules that are stored in sObject are displayed on the UI.
For example, when a loan gets rescheduled, and the amortization schedules get regenerated, the previous schedules are not required and are marked as archived. Such schedules are then moved to the big object.
sObject and big objects
In Salesforce, a sObject refers to any object type that can be stored in the Salesforce database. Each Salesforce sObject type corresponds to a specific entity, like a table in a database, and represents different business objects like Accounts, Contacts, Leads, Opportunities, and custom objects.
A Salesforce big object is outside the current org space. A big object provides consistent performance, whether you have 1 million records, 100 million, or even 1 billion. This scale gives a big object its power and defines its features. Whereas an sObject can store only up to few million and sObject storage is costly.
For more information on big objects, you can access the following Salesforce link: Big Objects.
On a regular basis, the batch job (The ScheduleExtractionDynamicJob) runs to pick up the schedules from the big object and put them into the sObject, and any previous schedules that fall before a specific time period, such as 6 months, are pushed back to the big object.
For example, let's say there is a contract of 360 month (30 years) and you want to store only 12 schedules of the future in the sObject and 6 schedules of the past. Let us say the contract is just created today. In this case, the system will only store 12 schedules of the future in the sObject and will hence display only 12 schedules.
Thus, at any given moment in the loan contract, for 360 months, the system can only store a maximum of 18 schedules in the sObject, which is 5% of the total number of schedules. Even if there are many reschedules, the storage space is reduced by more than half. As a result, a storage space of somewhere between 70% and 95% is saved. Based on the average number of contract lengths, it is estimated that this strategy minimizes the storage of schedules by 70% to 95%. (A 360-month contract saves up to 95% space, whilst a 60-month contract saves up to 70% space without rescheduling). Again, this is dependent on configuration.
These figures are based on the assumption that 18 schedules are configured to be saved on the sObject at any point in time.
Thus, implementing these strategies can lead to substantial storage savings, making it easier to manage large volumes of amortization schedules without sacrificing accessibility or detail.