Important Instructions before Enabling this Configuration

What must you know before you enable this configuration?

Before you enable this configuration, it is important that you go through the following instructions:

• You must not enable this configuration without the Q2 Loan Servicing product team's knowledge as this may require reimplementation of the code if you have any customizations.

• Once you have enabled this configuration, you cannot disable it again.

• You must make the following changes if you have custom implementations:

  Caution:

  Please consult the Q2 Loan Servicing product team before you go ahead with the following changes.

  • If you have been querying amortization schedules in your custom code until now, then this needs to be replaced by using the following global methods or REST APIs that now access data from both sObject and big object:

    • Global methods:

      • LoanActionImpl3.getRepaymentSchedules();

      • RepaymentScheduleDataAccess.queryCurrentActiveSchedules(loanAccountIds)

      • RepaymentScheduleDataAccess.queryAllActiveSchedules(loanAccountIds)

      • RepaymentScheduleDataAccess.queryAllActiveSchedules(loanAccountIds, sortInASC)

      • RepaymentScheduleDataAccess.queryActiveSchedules(loanAccount, externalIds, fromDate, toDate)

      • RepaymentScheduleDataAccess.queryInactiveSchedules(loanAccount, externalIds)

      • RepaymentScheduleDataAccess.queryAllSchedules(loanIds)

      • RepaymentScheduleDataAccess.queryAllSchedules(loanIds, sortInASC)

    • REST APIs:

      • /services/apexrest/peer/v1/loanAccounts/getDetails/{loanId}

        Note: For the preceding endpoint, if the storage optimization of amortization schedules is enabled, then on making a request to these endpoints, the repayment schedules will be returned in the response object (of the returned HTTP response) instead of the content object.

      • /services/apexrest/peer/v1/loanAccounts/amzSchedule/{loanId}

    For more information on these, see the Q2 Loan Servicing Global Methods Guide and the Q2 Loan Servicing REST APIs Guide.

  • If you are using any third-party tools to fetch the amortization schedule data, you must replace it by using the product’s provided global methods instead.

  • If you are using any of the following fields just for viewing, then you will need to hide them. If you are using any of the following fields for calculations, then you must not use them and use your custom logic for the calculations instead.

    This is because the value of these fields are based on the amortization schedules and as some of the amortization schedules are in sObject while rest are in big object, there would be a discrepancy in the actual and the expected values of these fields.

    Note:

    If there are more fields like the following, such as more such custom fields, then do the same for these too.

    • Fields of the Loan Account object that are based on the schedules:

      • Repayment_Schedule_Count__c: This field gives the sum of schedules that are not archived. It is used in some areas to check whether schedules are generated or not for the respective contract.

      • Total_Interest_Amortization_Based__c: This field is the sum of the Due_Interest__c field of all un-archived schedules. It is not used anywhere in the code.

      • Number_Of_Past_Installments__c: This field gives the count of schedules where Schd.Past_Due_Date__c is true. It is not used anywhere in the code.

      These fields, if used, will not display the correct value on the contract anymore since only limited number of schedules are stored in the sObject.

    • Fields of the Repayment Schedule object that are based on the Due Fee and Paid Fee:

      • Total_Paid_Fees__c: This field is the sum of Paid_Fee_Amount__c field that is available on Paid Fee object. This is being queried in the multiple queries but not being used anywhere in the product code.

      • Total_Due_Fees__c: This field is the sum of Due_Fee_Amount__c field that is available on Due Fee object. This is being used in the VF page printRepaymentSchedule to render the data in the PDF.

      These fields, if used, will not display the correct value on the schedule after the enabling of the optimization.

    • Lookup fields of the following objects that lookup to the Repayment Schedule

      • Charge__c (no usage other than having lookup)

      • Interest_Posting_Transaction__c (For FAMZ contracts)

      • Loan_Payment_Collection__c (no usage)

      • Loan_Payment_Amz_Sched_Junction__c (for AMZ contracts)

      These fields are linked to the repayment schedules and so, once the old schedules are deleted from the sObject and moved to big object, they will lose the link since the sObject schedule records would not exist as they would be deleted.

  • There may be times when the system has problems and you may need to restore the previous data. To accomplish this, you must first generate a backup of your data. Also, you may have a large amount of data that has to be backed up for safety reasons. Salesforce also backs up the data that is stored in the sObject, but it does not have the capability to back up the data that is stored in the big object.

    For this reason, Q2 Loan Servicing has developed a system that allows you to successfully restore the data (amortization schedules) stored in the big object by introducing a field called External Id, which aids in tracing the amortization schedules of a contract. This Id is maintained in both the contract and the amortization schedule, forming a relationship between the two in the database. As a result, once the contract is restored, the system will use this Id to retrieve and restore the corresponding amortization schedules too.

    More on the External Id:

    All the schedules generated will have External Id generated and updated on the records. This is because during moving objects from big object to sObject and sObject to big object, the Salesforce generated Id will not be useful to map the schedules for the respective OLT, or any other external mapping if needed. So this External Id generated will be unique for a given record, whether it's stored in sObject or big object at any point of its life cycle, giving it a proper identification.

What is the fail-safe mechanism and what can you do if this fails?

The big objects database stores billions of records and is a distributed system that favors consistency over availability. The database is designed to ensure low-level consistency. When working with big data and writing batches of records using APIs or Apex, you may experience a partial batch failure where some records are written and others aren’t. Because the database is highly responsive and consistent at scale, this type of behavior is expected. Therefore, we need a fail-safe mechanism to avoid loss of data while inserting to and deleting from big objects. For this, Q2 Loan Servicing provides a fail-self mechanism.

The following steps are performed by the system as part of the fail-safe mechanism:

1. While inserting or deleting, if the records fail to get inserted or deleted, the system tries for a maximum of 5 times again to insert or delete.

2. If it fails even after that, the big object records are stored in the JSON format in a new object, Failed BigObject Dml.

3. Then the system marks the field, Repayment ScheduleBO Failure, of the Loan Parameters object, for the respective Loan Accounts, as true.

   This makes sure that operations like rescheduling are restricted for the contract till the task of insertion or deletion is completed.

4. Once the records in the Failed BigObject Dml are fixed, the system runs the job: RetryRepaymentScheduleBOOperationsJob.

5. This job retries the inserts of the failed records, and after the successful insertion or deletion, it marks the Repayment ScheduleBO Failure field as false.

   This job is a DAG-enabled job and hence, once added, can be automated to run.

   If this job fails, and if you need to perform some action such as a rescheduling on a particular contract, then you can run this job manually for that contract.

How are the various actions going to get impacted if you enable this configuration?

Before you enable this configuration, as this configuration impacts repayment schedules storage, you must know where the schedules are used and how are some functions or values impacted. This is explained in the following table: