Winter'22 Release Notes

Feature Description

Currently, the system does not allow for backdated payments to be made if subsequent transactions have occurred after the value date of the payment. From the Winter'22 release, this will be allowed in most cases. When a backdated transaction occurs, the system will automatically calculate the adjusted interest and adjust it against the next interest posting transaction. This feature can be enabled by enabling the following two flags on the CL Contract and the Lending Product objects:

Feature Description

Similar to allowing for backdated transactions, the system will also allow for the reversal of payments that are in the past with subsequent transactions present. The interest adjustment will occur as part of the next interest posting transaction.

Issue Description

During the Interest Only (IO) period, rescheduling an advance interest loan on the basis of Loan Balance, with interest posting enabled, without maintaining delinquency results in an additional IPT and bill when adjustment entry is enabled. All unpaid interest as of that date is combined and an IPT is generated with that combined value. Also, when such a loan is rescheduled, a new amortization schedule gets generated for the discarded interest amount, but the next due generation date remains the same, resulting in two bills being generated when the next due date arrives, one for the rescheduled date and one for the actual due date.

Resolution

This issue is fixed. The rescheduling of advance interest loans do not result in additional IPT and bill when adjustment entry is enabled. The system behavior for rescheduling of advance interest, adjustment entry-enabled loans without maintaining delinquency has been modified as follows.

Existing behavior in the following scenario with Maintain Delinquency set to false:

New behavior in the following scenarios for rescheduling of adjustment-entry-enabled loans with Maintain Delinquency set to false:

Issue Description

For IPT's that have a $0 Interest Posted and a non-zero Principal Posted, the system is not marking the Paid flag as True even after the IPT is paid off.

The loan can have zero interest posted for the following two reasons:

Example to Understand the issue

Resolution

The issue is now resolved and the system is correctly marking the Principal only IPTs as Paid after the IPT is paid off.

Issue Description

On attempting to reverse an LPT on a loan contract with an Additional Interest Component, which has either a regular IPT or an AIC IPT associated with it, either one of IPTs must have an Interest Paid value of $0, the system displays the following error message:

Resolution

The issue is now fixed and the system is not displaying an any error message on attempting to reverse an LPT on a loan contract with an Additional Interest Component.

Issue Description

During an Investment Order sale, the system is displaying the following error message even tho the Buying Price is less than the available funds:

The system must allow the purchase of the Investment Order if the Buying price is less than the available funds irrespective of whether the original investment amount is more or less than the available funds.

Resolution

The issue is now fixed and the system is not displaying and error message when the Buying Price is less than the available funds. Although, the system will display the following error message when the Buying Price is more than the available funds or the investment amount is more than the available funds:

Issue Description

While trying to upload a BPAY bank file on the Q2 Loan Servicing application, the upload is failing as the system is displaying the following error message:

"Apex heap size too large."

Root Cause

This issue was occurring because of a scenario wherein a lot of payments were getting processed through a BPAY file, leading to a high amount of bulk data being retrieved and loaded into the heap. Additionally, the system was not marking AIC IPTs (Additional Interest Component) (Interest Posting Transactions) with a zero amount as paid, resulting in a high volume of unnecessary data being pulled. Also, deposit records were consuming more heap space due to a higher number of child deposits. Marketplace global variables were also using high memory.

Resolution

This issue has been fixed.

As part of the fix, the logic has been updated such that the system now marks the AIC IPTs with a zero amount as paid.

Also, the code has been cleaned up and data has been optimized as follows:

Issue Description

After a contract is written-off and a Payoff Quote is generated for a future date, the Interest Remaining is getting calculated for the days from the Transaction Date to the Payoff Quote date.

Example

Let us say a contract is created, approved, and disbursed. Let us say two bills are generated and the first bill is paid. After this, let us say that the contract is written-off and a Payoff Quote is generated for a future date of 6/15/2022. The Transaction Date is 5/30/2022. The Principal Balance is $952.97, Interest Remaining is $46.34 and Interest Per Diem is $0.93. The number of days between the Transaction Date and the Payoff Quote date is 16 days.

Actual Result:

Total Payoff Amount = 952.97 + 46.34 + 0.93 * 16 = 1,014.14.

Expected Result:

Total Payoff Amount = 952.97 + 46.34 = 999.31

Reason

When a Payoff Quote is generated, the unpaid interest amount (Interest Remaining) was getting added to the Total Payoff Amount if the Payoff Quote date was greater than the Transaction Date irrespective of the loan Status.

Expectation

When the status is Closed-Written off, while generating the Payoff Quote with a payoff date greater than the Transaction Date, the unpaid interest (Interest Remaining) must not get added to the Total Payoff Amount and the unpaid interest field value must be zero.

Resolution

This issue is fixed, and now when the status is Closed-Written off, while generating the Payoff Quote with a payoff date greater than the Transaction Date, the unpaid interest (Interest Remaining) is not getting added to the Total Payoff Amount and the value of the Interest Remaining on the Payoff Quote is zero.

Issue Description

When a backdated reversal (backdated LPT reversal) is performed on two payments that are made on the same date, the adjusted interest transaction is not generated by the system and hence the Balance on the Loan Transaction Summary (LTS) is not the calculated correctly.

Example to understand the issue: Make a backdated payment of $1

Let us understand the issue with the help of an example as follows:

Let us say a loan is created with adjustment entry enabled. (Enable Adjustment Entry = true and Create Summaries = true)

On June 25, 2024, let us say the following occurs:

On June 27, 2024, let us:

The issue is that the system is calculating an incorrect balance on the LTS and an incorrect value of adjusted interest.

It is observed that after the reversal of LPT3, while LTS8 has right balance on it, the reversal action goes and updates the loan balance on LTS4, LTS6 and LTS7 bumping it to a higher value of exactly the same amount as the payment (LPT2) that is reversed.

Root cause

This issue occurs because when LTS is created for the LPT reversal, it is getting created before the unpaid capitalized charge is added back to the loan balance.

LTS for LPT reversal must be created after the unpaid capitalized charge is added back to the loan balance.

Resolution

This issue is fixed. LTS for LPT reversal is now created after the unpaid capitalized charge is added back to the loan balance. Hence, the balance on LTS is now calculated correctly. As part of this fix, if the adjusted amount is zero, the system does not create the Other Loan Transaction (OLT) and LTS for the LTP reversal.

Issue Description

When a payoff is made with an amount greater than the system-calculated payoff amount or a deposit to loan transfer of a very large value is made for a loan contract that has the Payment Application Mode set to deposit and the contract has moved to Closed Obligations Met, the system is moving the excess amount to Deposit instead of Excess even after the loan is closed. Additionally, when there is a negative Adjusted Interest Capitalized value due to a backdated payment, a payoff is made of an amount greater than the system-calculated payoff (or a payment of amount greater than the system-calculated payoff is made that goes to deposit, followed by an internal transfer from deposit to loan,) the system is moving the negative Adjusted Interest Capitalized value to Excess instead of moving the excess amount that is more than the payoff amount to Excess.

Expected Behavior

When a contract moves to Closed Obligations Met, the excess amount must move entirely to Excess field on contract instead of going to deposits. Deposit to loan transfer of a very large value must also move excess to Excess field. If the loan is not closed or not marked for closure, then the excess amount must go to Deposit when the loan is deposit-enabled.

Resolution

This issue is fixed. As part of the fix, any excess amount paid will not be applied towards Deposit in the following scenarios:

Additionally, the Excess will not get updated with the negative Adjusted Interest Capitalized value when there is a negative Adjusted Interest Capitalized value and a payoff is made of an amount greater than the system-calculated payoff (or a payment of amount greater than the system-calculated payoff is made that goes to deposit, followed by an internal transfer from deposit to loan.)

Issue Description

When a backdated transaction is posted in a loan where adjustment entry is enabled, there is way to refer to the Actual Deposit Balance on LTS (Loan Transaction Summary or Loan Transaction Statement) after a transaction.

LTS consists of the following two fields:

These two fields represent the deposit balance before the transaction. So, a formula field was created to add or subtract the actual transaction amount from LPT or OLT, which works in majority of the cases except for backdated payments or reversals. As a result, there must be a reference to Deposit or a field containing the value of the current Deposit balance after the transaction, including a rate change transaction. This is required to show accurate Offset balance when it is backdated.

Root cause

The Actual Deposit Amount field captures the current value of deposit amount aggregated across all deposits.

The Deposit Amount field captures the running balance of deposit amount aggregated across all deposits.

Consolidated Loan Balance derives its value by taking into account the value of this Deposit Amount field.

Following are the two issues faced in backdated deposit adjustments:

Resolution

This issue is fixed by introducing an upgrade script as follows.

Upgrade script

An upgrade script is written to populate values on LTS object fields, namely Actual Deposit Amount and Deposit Amount, to update them with values as per the new behavior as part of this fix.

Deployment Steps

Perform the following steps:

Algorithm used

The script works by calculating initial deposit amount from LTS > Actual Deposit Amount (which previously stored snapshot value of deposit) where LTS is the very first record in list. Subsequently, LTS are updated by considering previous LTS values and current LTS contribution towards deposits.

Deposit Amount is updated to running balances on deposits.

Actual Deposit Amount is updated to actual deposit amount that are not reversed.

Error Logging

Following error messages are logged in Batch Process Log (loan namespace) object:

Error Mitigation

First, consolidate all errors logged and take appropriate actions on such contracts. Once they are resolved, you may run this script for each contract by passing contract ID or bunch of contract IDs (a DAG feature).

Issue Description

When an index rate change occurs on contracts with Payment Application Mode as Deposit, the deposit rate also gets updated; however, when the index rate change OLT is reversed, an index rate change reversal OLT is generated, but the respective child deposit on the Deposit account for rate change is not marked as reversed, which impacts the value of interest accrual on deposits.

Example to understand the issue

Let us understand the issue with the help of an example as explained in the following steps:

Resolution

This issue is fixed. Parent ID on the related deposit index rate change OLT is updated when the index rate change is done.Now when the index rate change is reversed, the respective child deposit record is also getting reversed.

Issue Description

After doing a backdated payment, the system is calculating the value of the Adjusted Interest Capitalized field incorrectly. A similar issue is observed when multiple backdated payments are done in one go using BPAY wherein the system is calculating the value of Adjusted Interest Non-Capitalized field incorrectly.

The difference in the expected and the existing values of these fields is a few cents, and this difference is due to the incorrect usage and calculation of the accrued interest and rounding error in the calculations after a backdated payment.

Example 1 to understand the issue: Make a backdated payment of $1

Let us understand the issue with the help of an example as explained in the following steps:

It is observed that the system is calculating adjusted interest incorrectly as follows:

The expected value must be as follows:

Example 2 to understand the issue: Make multiple backdated payments at once using BPAY

Let us understand the issue with the help of an example as explained in the following steps:

It is observed that the system is calculating the adjusted interest improperly, with a few cents deviation from the expected numbers.

The expected values are:

Root Cause of the issue

The root cause of the issue are summarized in the following points:

Let us look at the following example to understand this better.

Example 3 to understand the cause of the issue

Let us say, that on March 1, Interest Posting Transaction (IPT) is generated by the system of an amount of $100 and the Interest Remaining (IR) is $0. Let us say that the Interest Rounding Error (IRE) at this time is -0.00256. On March 15, say there is a LAD changing event, such as a rate change. Then say the IR gets updated to $50 (this is the rounded value) and hence, the new IRE value gets updated to 0.00125. On March 20, say there is another rate change resulting in IR getting updated to $53 and IRE to -0.00147. This is depicted in the following table:

Now let us say today is March 20 and a backdated payment is made on March 18. Let us say that $1 is accrued till March 18 and $1.5 is accrued from March 18 to March 20. The system then considers the IRE as of today (March 20) for the internal calculations. By using the IRE as of today, the system is calculating incorrect adjusted interest values. This is explained in the following table that includes the backdated payment:

As seen in the preceding table, we observe the following issues:

Resolution

This issue is fixed.

As part of the fix, looking at the preceding Example 3, the IR today on March 20 will be calculated as follows:

computed interest(IR) + IRE as of the IPT date = 50.1 + (-0.00256) = 50.09744 = New computed IR

Where 50.1 is the accrued interest from March 1 to March 20. Hence, the IRE is added only once.

This new computed IR is then compared with the IR on the contract which is 53.

Then the Adjusted Interest Non-Capitalized = 50.09744 - 53 = -2.90256 = -2.9 (rounded value).

As Adjusted Interest Non-Capitalized = -2.90256, it is rounded to -2.9.

Hence, the new IRE = -2.9 - (-2.90256) = -0.00256.

Thus, the system does the following:

Thus, as part of the fix, the logic is updated such that the system uses the correct IRE which is the IRE as of the previous IPT date and the interest will be calculated from the last posting date to the current LAD. Thus resulting in the correct values of the Adjusted Interest Capitalized and the Adjusted Interest Non-Capitalized fields in the case of backdated payments. The current IRE on the contract will then be updated to a new value derived after rounding the adjusted interest (Adjusted Interest Capitalized or the Adjusted Interest Non-Capitalized) amount.

Issue Description

When the batch size is set to five or more, the InvestmentOrderInterestPostingDynamicJob is failing and the system is displaying the following error message:

Resolution

The issue is now fixed by modifying the logic and the InvestmentOrderInterestPostingDynamicJob is not failing.

The following issues are also fixed as part of Q2 Loan Servicing 4.1012.206 patch:

Issue Description

The Fee Amount Paid is getting distributed among the investors as per their share. The system is considering all the investors on the loan irrespective of their status. The system must consider only the active investors while distributing.

Fees Amount Paid must be distributed based on the investor percentage on the fee as well as investor share percentage on the loan as well. Let us consider four investors in a loan. Investor 1, Investor 2, Investor 3, Investor 4 and each investor has a 25% share in the loan.

Now, if Investor 1 and Investor 2 become inactive, then the $10,000 fee generated on the LPT must be distributed among the remaining two investors active investors only. As inactive investors must not be considered for the Fee Amount Paid calculations.

Since Investor 3 and Investor 4 have equal share on the Loan, the $10,000 fees gets equally divided among them, that is, Investor 3 is charged $5000 and Investor 4 is charged $5000. Instead, if the investor share for Investor 3 was 30% and share for investor 4 was 20% then the Fee Amount Paid must be $6000 and $4000 respectively.

Resolution

The issue is fixed. The system now distributes the Fee Amount Paid correctly among the active investors considering their share in the loan.

Issue Description

The system is calculating the value of the current bill incorrectly, when a backdated payment or payment towards the older bills is made in pre - billed days period for a loan contract that is delinquent and has an additional interest that is calculated on either the Delinquent Amount, Available Amount For Funding, or Custom, with Add Interest to Bill set to True.

Example to understand the issue after the fix

Resolution

The issue is now fixed. Now, when the Interest Bearing Principal field is set to Delinquent Amount, Available Amount For Funding, or Custom, the Bill generated is set to non-primary and the system generates a new Bill correctly and the interest amount billed in the AIC is updated back to previous value.

The following issues are also fixed as part of Q2 Loan Servicing 4.1012.200 patch:

Issue Description

The system is displaying the following error message during investor payout for contracts with 1000 plus active investors

Resolution

This issue is now fixed and the system is not displaying an error message during investor payout for contracts with 1000 plus active investors

The following issues are also fixed as part of Q2 Loan Servicing 4.1012.193 patch:

Issue Description

For a loan contract with Protect Enabled set to True and Protect Type set to Full, the system is updating the value of Today's Payoff on the loan incorrectly.

Example to understand the behavior after the fix

Resolution

The issue is now fixed and the system is correctly updating the value of Today's Payoff on the loan.

Enhancement Description

The reverseRescheduleActionOnId method is modified to incorporate the bulk record.

reverseRescheduleActionOnId

This method is used to reverse the reschedule action on the loan contract.

Method signature

Method parameters

Usage/How to Invoke

List<Id> rescheduleTxnList= new List<Id>{<<list of rescheduled other transacitons ids>>};

loan.LoanActionFactory lAFactory = new loan.LoanActionFactory();

loan.AbstractLoanActions loanActions = lAFactory.getLoanActionsAPI();

loanActions.reverseRescheduleActionOnId(rescheduleTxnList);

Issue Description

After posting an LPT or reversing an LPT, the system is calculating the Current Loan Balance and the Consolidated Loan Balance values on the Loan Transaction Summary of the bills incorrectly.

Example to understand the behavior after the fix

Resolution

The system is now updating the Current Loan Balance and the Consolidated Loan Balance on the Loan Transaction Summary section of the bills correctly.

Issue Description

In a loan contract where fees are capitalized, if the backdated LPTs are reversed using ACH and then the Periodic Charge Job is run, the interest is not getting posted.

Example to understand the issue

Resolution

This issue is now fixed. As part of fix, if LAD is occurring before the next interest posting date, then the Periodic Charge Job of SOD batch triggers IPT Job internally so that the next interest posting date occurs before the LAD. This regenerates the pending IPTs, and the SOD batch's IPT Job generates the future IPTs for the next interest posting date without any issues.

Issue Description

If a payment is reversed in a loan that has adjustment entry enabled in it, then during the execution of the IPT job, the Last Accrual Date (LAD) gets updated incorrectly to the Interest Posting Transaction (IPT) date.

Example to Understand the Issue

To understand the issue, perform the following steps:

Resolution

This issue is fixed. The LAD now does not get updated to an incorrect date after a payment reversal.

Issue Description

It is observed that there is a difference between the conditions checked before reposting IPTs for backdated LPT reversal and backdated payments as follows:

The system actually behaves in the following way:

The reason is while creating and reversing backdated LPTs, IPT are reversed, however the system expects IPT to be generated the following day in the IPT job while the start of the day (SOD) job runs.

Resolution

This issue is fixed.

As a result of the resolve, the system now behaves as follows:

Issue Description

If a backdated payment and a payment reversal is made in such a way that the Adjusted Interest Capitalized value is negative, then when a payment is made, it satisfies the negative adjusted interest resulting in the balance issues in the Loan Transaction Summary (LTS).

Example to Understand the Issue

To understand the issue, perform the following steps:

Resolution

This issue is fixed as the logic is updated such that interest adjusted value is considered as part of the payment LPT only when there is a positive interest adjustment on the loan.

Issue Description

Currently, the Interest Remaining on the Payoff Quote is inclusive of the Interest Accrued amount and Minimum Interest amount. The system must have a different field to display only the Minimum Interest amount.

Resolution

The issue is fixed by adding the Interest Accrued amount in the Accrued Interest field and Minimum Interest in Minimum Interest field.

Issue Description

When an additional interest component is waived and the InvestorPayoutJob is run, the system is adding the waived additional interest amount to the Interest Paid field instead of the Interest Waived field.

Example of the system behavior after the fix

Resolution

This issue is now fixed as the internal logic is modified such that the Interest Waived field of Investment Order IC is getting updated correctly in case of an additional interest waiver.

Issue Description

While performing a rate change, the system is displaying the following error message and is failing to change the rate:

Example to understand the issue

Upon saving, it is seen that the rate change is failing with the following error message:

Resolution

This issue is fixed as the internal code is updated and the system is not displaying any error messages while performing a rate change and the rate is changed successfully.

Issue Description

After running the MarkFieldsAccessibleJob, it is observed that in addition to providing permissions to the managed (product) objects of the Q2 Loan Servicing packages, the job is also providing permissions to the custom objects, which is incorrect. The job must not provide permissions to custom objects or fields.

Example to understand the issue

Let us understand this issue with an example by performing the following steps:

It is observed that this job runs for all the custom objects. Once all the instances are completed, as seen on the Apex Jobs page, on checking the permissions given to the preceding custom object created, it is seen that the job gives read, write, and edit permissions to the newly created custom object too. The job must not do that.

Resolution

This issue is fixed as the internal logic has now been updated to only give permissions to the managed objects and not the custom objects whenever the MarkFieldsAccessibleJob is run.

Issue Description

While creating an LPT, if you enter a value for the Transaction Amount with a comma and with number of digits after the decimal point that are greater than the defined number in the org, then the system is displaying the following error message and upon selecting OK, the system is rounding the value up to two decimal digits correctly, but it then removes the decimal point from the value altogether displaying a whole number.

The system must round off the value to two decimal points and then display that amount after selecting Validate.

Example to understand the issue

Resolution

This issue is fixed. Now, if you enter an amount with a comma and with number of digits after the decimal point that are greater than the defined number in the org, the system is displaying an error message and then updating the value in the Transaction Amount field correctly.

Issue Description

While running the LoanPaymentTransactionCreationJob for a batch size of 20, it is failing with the following error message:

Resolution

This issue is fixed. Now, while running the LoanPaymentTransactionCreationJob even for a batch size of 200, the system is not displaying any error messages and the job is running successfully.

Issue Description

The issue is seen in a loan contract with Payment Application Mode as Deposit and with multiple deposits and child deposits for different parent deposit created on different dates.

Example to understand the issue

Resolution

This issue is fixed. The latest child record of Deposit 2 calculates Deposit Amount of $553.6. The system is now querying the latest child deposit before the transaction date for each parent deposit, ensuring that accurate child deposit records are created. The system queries the latest child deposit before the transaction date for each parent deposit. This is to consider minimum deposits with respect to transaction date for each parent deposit. Hence, ensuring that accurate child deposit records are created.

Issue Description

When a Loan Payment Transaction in a loan with Payment Application Mode as Deposit is reversed, the system is calculating a negative value for deposit amount in the child deposit account.

In other words, there is an inconsistency seen between the values of the deposit amounts displayed in the child deposit account and the Current Deposit Amount of the parent deposit.

Example to understand the issue

The values must be updated as follows:

However, the deposit amount of new child deposit is getting calculated as a negative amount.

Resolution

This issue is fixed now, and the deposit amount of the new child deposit is getting calculated correctly.

Issue Description

After a successful execution of the DAGs, no confirmation email is received at the registered email ID.

Resolution

This issue is fixed as a confirmation email is now successfully received at the registered email ID upon successful execution of the DAGs.

Issue Description

When an additional interest component is waived and the InvestorPayoutJob is run, the system is adding the waived additional interest amount to the Interest Paid field instead of the Interest Waived field.

Example of the system behavior after the fix

Resolution

This issue is now fixed as the internal logic is modified such that the Interest Waived field of Investment Order IC is getting updated correctly in case of an additional interest waiver.

Fixed Versions

The fix of this issue is available in the following version:

Issue Description

When the Fee Capitalization is set to true for the early termination fee it is leading to negative amount in Fees Remaining and is displaying an amount in Loan Balance even when the contract is closed.

Example to understand the issue

Resolution

This issue is fixed. The system is now calculating the Fee Remaining and the Loan Balance correctly. For the preceding example the values are getting calculated as follows:

Issue Description

The system is not considering the change in calculation of Timezones due to the shift in daylight saving thus generating a CPU time out error.

Example to understand the issue

Resolution

The issue is now fixed. The system is now saving the contract without generating any errors and the Amortization Schedule is starting from the correct date, which is April 8, 2024, as per the preceding example.

Issue Description

Selecting the Reset button for a newly added rate schedule on the Interest Rate Schedule section, without saving, triggers a null pointer exception error. The system must clear the entered values for the rate schedule instead of displaying any errors.

Resolution

The issue is now fixed. For an unsaved newly added rate schedule on the Interest Rate Schedule section, the system clears the entry without displaying an error.

The following interest adjustment issues related to backdated payment and payoff are fixed as part of the Q2 Loan Servicing 4.1012.149 patch:

Issue Description

When a loan contract with interest type as floating is rescheduled, the Deposit Rate is getting updated incorrectly.

Example to understand the issue

Resolution

This issue is fixed now, and the Deposit Rate is getting updated automatically after the loan is rescheduled.

Issue Description

When the Floating Rate Revision job is run to perform the floating rate change for a loan, it is

failing with the following error message:

Resolution

This issue is fixed now, and the Floating Rate Revision job is running successfully without any error messages.

Issue Description

When an Interest Only loan with flexible repayment plan is rescheduled, the amortization schedule is getting generated incorrectly.

Example to understand the issue

Resolution

This issue is fixed now, and the amortization schedule is getting generated correctly.

Issue Description

While previewing the rescheduling of a loan by clicking the Preview button, the system is displaying the following error message:

“Maximum view state size limit (170 KB) exceeded. Actual view state size for this page was...”

This is because the rescheduling results in a lot of records on the Reschedule page that do not fit within the page size.

Resolution

This issue is now fixed. To resolve this issue, the logic has been updated in the system to only display a limited number of records that the page can accommodate. The rest of the records that are not displayed are displayed on the pages after this. In other words, pagination has been now included in the system for the Amortization Schedule and the Repayment Schedule Summary to display 50 records on each page. This ensures that the records are displayed and distributed over multiple pages such that a page displays 50 records.

Additionally, following four buttons are also added to each page:

If the system is on the first page, and if the records are more than 50, then only the following buttons are visible on the page:

If the system is on the last page, then only the following buttons are visible on the page:

If the records are less than 50, then all the four buttons are not visible on the page.

Fixed Version

This issue has been fixed in the following version:

Issue Description

The system is not displaying any confirmation message upon making a successful payoff. The system must display a confirmation message indicating that the payoff is successful.

To reproduce the issue perform the following steps:

Resolution

The issue is fixed, the system now displays a success message when the payoff is successful. An example of a confirmation message upon a successful payoff:

Fixed Version

This issue has been fixed in the following version:

Issue Description

When there is a last but one bill that is unpaid and the loan has reached its maturity, the system is generating the last bill at the maturity date, but it is not generating the transaction summary for the last bill, and hence the last bill transaction summary is not appearing in the Loan Transaction summary.

Resolution

This issue is now fixed. The system is now generating the transaction summary of the last bill and hence the transaction details of the last bill are now visible in the Loan Transaction Summary.

Fixed Version

This issue has been fixed in the following versions:

Issue Description

In a loan contract where the Interest Type is Floating, after a payment is made before the Maturity Date such that the Principal/Advance Remaining becomes zero and there is still some Interest Accrued that is not yet posted, the system is not allowing to perform a Rate Change and is throwing an error message.

Example to understand the issue

Resolution

This issue is fixed. All Index Rate Changes are now updated and the values are as follows:

The system is now allowing you to reschedule the loan successfully.

Fixed Version

This issue has been fixed in the following version:

Issue Description

When a payment including Additional Interest Component (AIC) is made in a loan that has Interest Bearing Principal (for calculating AIC) as Delinquent Amount, and when the Investor Payout Job is run, the system is considering the AIC in the calculations while creating Investor Loan Transaction (ILTID) for the investor, but it is not considering the AIC while updating the Available Funds in the Account of that investor.

Example to understand the issue

The system generates a bill.

Let us not clear the bill 1. This makes the loan delinquent.

The system generates a bill.

An amount equal to the ILTID is added to the investor's Available Funds, which is Principal + Interest - Total Service Charge + AIC.

However, AIC is not getting included when the Available Funds in the Investor Account is updated. If AIC is not included, the investor's Available Funds is getting updated with the value as Principal + Interest - Total Service Charge.

Resolution

This issue is fixed now, and the AIC component is being considered while calculating the investor's Available Funds for investor payment.

Fixed Versions

The fix of this issue is available in the following version:

Issue Description

Example to Understand the Issue

Let us go to Setup > Go to Custom settings > Org Parameters > and ensure that the Daily Interest Accrual Time is set to EOD.

Resolution

Fixed Versions

The fix of this issue is available in the following version:

Issue Description

When the loan balance is less than the tolerance specified, the contract status should get updated as 'Active - Marked for closure'. Instead the system is generating another Minimum Interest Charge which is impacting the loan balance and overall payoff and the loan status is not updating to 'Active - Marked for closure'.

Example to Understand the Issue

Resolution

The issue is now fixed and the loan status is updated to 'Active - Marked for closure' when the loan balance is less than the tolerance specified.

Issue Description

When a loan contract is rescheduled after the upgrade from Lithium (3.5054.150) to Winter'22 (4.1012.41), the system is displaying the following error message:

Also, while performing a rate change for the above loan contracts, the system is displaying the following error message:

Resolution

This issue is now fixed. The loan contracts are getting rescheduled, and rate change is performed successfully for those contracts without any error messages.

Issue Description

After the upgrade from Lithium (3.3030.121) to Winter'22 (4.1012.25), when the FloatingRateInterestRevisionDynamicJob is run to perform the global Rate change for a loan, the system is displaying the following error message:

Resolution

This issue is fixed now, and the FloatingRateInterestRevisionDynamicJob is running successfully without any error messages.

This section explains the known issues that are fixed as part of the Winter'22 patch (4.1012.25) release.

Issue Description

In an ARR-enabled loan, when a backdated payment is made for a date before two or more IPTs (before two or more cycles), the system is not calculating the newly generated IPTs and the Bills correctly.

Example to understand the issue

Let us perform the following steps:

Resolution

This issue is fixed as the internal logic has been updated to reflect correct IPTs and Bills even if the backdated payment is made more than one cycle earlier.

Issue Description

In an FAMZ contract that has the Interest posting for the Investment Order flag set to true, the interest accrued on the investment as mentioned in the Investment Order is not getting paid out to the investors. The payouts to the investors are made through the Investment Payout job.

Example

Let us try to understand this issue with the help of an example.

Resolution

The issue is fixed by adding a validation that prevents the users from setting the Interest Posting for Investment Order flag in the FAMZ loan contracts to True. So, now, if the users try to set this flag to true, the system displays the following error message:

“Enable Interest Posting for IO is not allowed for this product type.”

As a resolution to this issue, the interest mentioned in the Investment Order is getting paid out after the Investor Payout Job is successfully run.

Issue Description

When the Interest Posting Dynamic Job is run for the single payment loans that have the interest posting frequency set to the billing frequency, the system displays the following error message:

Resolution

This issue is now fixed, and the Interest Posting Dynamic Job is running successfully without any error messages.

Issue Description

For an FAMZ single payment loan, if the Maintain Delinquency flag is set to false, the reversal of the rescheduled loan is failing with the following error message:

“CL019443: DML Exception in Bulk Reschedule Reversal Transaction. Duplicate id in list: a813t000000gZ5JAUU.”

Example

Let us try to understand this issue with the help of an example.

Resolution

While performing a reschedule reversal certain Interest Posting Transactions are discarded, these discarded Interest Posting Transactions are again considered for delinquency due to which same Interest Posting Transaction is added twice, causing duplicate Id exception.

This issue is now fixed by adding a conditional check to not consider the discarded Interest Posting Transactions. The Reschedule Reversal is working fine even when Maintain Delinquency is set as False.

Issue Description

When a bill is paid for a cycle and the Pay Future Dues Timely flag is set to false, the system is creating incorrect late charges in the payoff quote. Late charge is getting created for the last bill which has already been paid.

Example

Let us try to understand this issue with the help of an example.

Resolution

The issue is fixed now. The late charge is not getting calculated for the bill which is paid on time.

Issue Description

On doing a backdated loan payoff, after the loan closure, the loan Balance field value is getting calculated in negative and also the Adjusted Interest Capitalized field is not getting updated to zero.

Example

Let us try to understand this issue with the help of an example.

Resolution

The issue is fixed now. When a backdated Payoff is done and the loan is closed, Adjusted Interest Capitalized value is added to the excess and the loan balance is getting updated correctly.

Issue Description

The Prepayment Penalty amount is getting incorrectly calculated when the fee amount is calculated as a percentage of the Principal Balance and when the Pay Future Dues Timely flag is set to true.

Example

Let us try to understand this issue with the help of an example.

Resolution

The issue is fixed now. The prepayment penalty amount is getting calculated correctly when the fee amount is calculated as a percentage of the principal balance and when the Pay Future Dues Timely flag is set to true.

Issue Description

When the Data Mapper Dynamic Job is run for 300k records, it is failing with the following null pointer exception: “Attempt to de-reference a null object.”

Resolution

When the external batch for Data Mapper Dynamic Job was null, it was throwing the null pointer exception. As a solution to it, the null check was added.

The issue is fixed now and the Data Mapper Dynamic Job is running successfully.

Issue Description

When a loan payment transaction is done for loan accounts created before the upgrade from Lithium (3.3030.121) to Winter'22(4.1012.25), the system is displaying the following error message:

"Rolling back the batch. Message - Argument cannot be null. CL010100: Unexpected DML Exception Insert failed. First exception on row 0; first error: FIELD_CUSTOM_ VALIDATION_EXCEPTION, Rolling back the batch. Message - Argument cannot be null".

However, LPTs are getting created for loan accounts created after the upgrade without any issues.

Resolution

The issue is fixed now, and the LPTs are getting created without any issues.

There is a new field called loan_Adjusted_Interest_c introduced in the Summer'22 release. Due to this field, the system is displaying the 'Argument cannot be null' error while creating LPTs as this value is Null for all loan contracts before the upgrade.

As a fix, the field loan_Adjusted_Interest_c is updated to '0' instead of Null for all the loan contracts before the upgrade.

Issue Description

When an existing loan contract is rescheduled after the upgrade from Lithium (3.3005) to Winter'22 (4.1014.10), the system is displaying the following null point error message:

Resolution

The issue is fixed now, and the loan contracts are getting rescheduled without any issues.

There is a new field called Due Additional Interest for existing loan_Repayment_ Schedule_c under the loan contract introduced in the Platinum release. Due to this field, the system is displaying the 'Argument cannot be null' error while rescheduling, as this value is Null for all loan contracts after the upgrade.

As a fix, the field Due Additional Interest is getting updated to '0' instead of Null for all the loan contracts after the upgrade.

Issue Description

When the Periodic Charge Dynamic Job is run for loans, the system is displaying the following error message:

Resolution

The issue is fixed now, and the Periodic Charge Dynamic Job is running successfully without any error messages.

Issue Description

The Interest Accrued and the Interest Remaining fields are getting updated incorrectly after manually clearing the backdated payment because of the Index Rate Change OLT, that exists after the LPT creation Date.

Example to understand the issue

Resolution

This issue is fixed as a validation has been added to block any backdated payments before the Index Rate change.

Issue Description

When a future dated payoff quote is generated after the current maturity date, the future IPTs are not getting considered in the payoff quote.

Example to understand the issue

The Interest Posted value is getting updated incorrectly.

Resolution

This issue is now fixed, and the interest values are getting updated in the future dated payoff quote.

Enhancement Description

Earlier, Q2 Loan Servicing and Q2 Marketplace did not have an API for payment creation and clearing. Now, with the Winter’22 patch release, you can use the following API for payment creation and clearing in Q2 Loan Servicing and Q2 Marketplace applications:

createLoanPaymentTransactions()

When a payment is created, and if the Loan Payment flag in the Transaction Approval Configuration is set to True, then the payment will not be cleared unless it is approved. Hence, this API can be used for the creation and the clearing of the payment.

Within the Q2 Loan Servicing application, this API can be used directly for any payment creation and clearing.

Within Q2 Marketplace, this API is internally called by the system when you are creating a payment through the Upload Bank Statement UI in the Q2 Marketplace application. However, for the Upload Bank Statement with the API to work successfully, ensure that you manually install the following Winter’22 patch version of Q2 Loan Servicing: 4.1012.25. This is because this API is created in the Q2 Loan Servicing package and not in the Q2 Marketplace package.

Enhancement Description

Before the Winter'22 patch release, Q2 Loan Servicing was enhanced to give you the ability to select external interest rates. This was done by internally calling an external calculator.

With the Winter'22 patch release, Q2 Loan Servicing gives you the option to specify an external interest amount manually. You can do this with the help of a UI or an API.

With the help of the UI, to be able to manually specify an interest amount in the system, you have to create a manual OLT where you have to specify a bill amount. This bill amount would then be considered as the Interest Remaining amount for an Interest Only loan

in an ARR-enabled loan contract. To create a manual OLT, you have to select the Manual Billing option from the Loan Actions of the L oan Quick Menu.

You can also use the following API to create a manual bill to specify an interest amount: createBill(). You can reverse a manual bill with the help of the following API: reverseManualBill()

Enhancement Description

Earlier, the future-dated payoff quotes were able to calculate a payoff quote considering the following future events:

After the Winter’22 patch release, the future dated payoff quote will now include the late charges too.

Enhancement Description

Earlier, Q2 Loan Servicing and Q2 Marketplace did not have an API for payment creation and clearing. Now, with the Winter’22 patch release, you can use the following API for payment creation and clearing in Q2 Loan Servicing and Q2 Marketplace applications:

When a payment is created, and if the Loan Payment flag in the Transaction Approval Configuration is set to True, then the payment will not be cleared unless it is approved. Hence, this API can be used for the creation and the clearing of the payment.

Within the Q2 Loan Servicing application, this API can be used directly for any payment creation and clearing.

Within Q2 Marketplace, this API is internally called by the system when you are creating a payment through the Upload Bank Statement UI in the Q2 Marketplace application. However, for the Upload Bank Statement with the API to work successfully, ensure that you manually install the following Winter’22 patch version of Q2 Loan Servicing: 4.1012.13. This is because this API is created in the Q2 Loan Servicing package and not in the Q2 Marketplace package.

Enhancement Description

Before the Winter'22 patch release, Q2 Loan Servicing was enhanced to give you the ability to select external interest rates. This was done by internally calling the external calculator.

With the Winter'22 patch release, Q2 Loan Servicing gives you the option to specify an external interest amount manually. You can do this with the help of a UI or an API.

With the help of the UI, to be able to manually specify an interest amount in the system, you have to create a manual OLT where you have to specify a bill amount. This bill amount would then be considered as the Interest Posted amount for an Interest Only (IO) loan in an ARR-enabled loan contract.

To create a manual OLT, you have to select the Manual Billing option from the Loan Actions of the Loan Quick Menu.

You can also use the following API to create a manual bill to specify an interest amount: createBill().

You can reverse a manual bill with the help of the following API: reverseManualBill()

Enhancement Description

Earlier future dated payoff quotes were able to calculate a payoff quote considering the following future events:

After the Winter’22 patch release, the future dated payoff quote will now include the late charges too.

Issue Description

In an ARR-enabled loan, when a backdated payment is made for a date before two or more IPTs (before two or more cycles), the system is not calculating the newly generated IPTs and the Bills correctly.

Example to understand the issue

Let us perform the following steps:

But the bill amount in Bill-4 is incorrect due to an incorrect interest in IPT-4.

Resolution

This issue is fixed as the internal logic has been updated to reflect correct IPTs and Bills even if the backdated payment is made more than one cycles earlier.

Issue Description

In an FAMZ contract that has the Interest posting for Investment Order flag set to true, the interest accrued on the investment as mentioned in the Investment Order is not getting paid out to the investors. The payouts to the investors are made through the Investment Payout job.

Example

Let us try to understand this issue with the help of an example.

As part of the Investor Payout, the principal and interest should get paid out, however the interest as mentioned in the Investment Order is not getting paid even when the Investment Order flag is set to true.

Resolution

The issue is fixed by adding a validation that prevents the users from setting the Interest Posting for Investment Order flag in the FAMZ loan contracts to True. So, now, if the users try to set this flag to true, the system displays the following error message: “Enable Interest Posting for IO is not allowed for this product type.”

As a resolution to this issue, the interest mentioned in the Investment Order is getting paid out after the Investor Payout Job is successfully run.

Issue Description

When the Interest Posting Dynamic Job is run for the single payment loans that have the interest posting frequency set to the billing frequency, the system displays the following error message: ” First error: Apex heap size too large.”

Resolution

This issue is now fixed, and the Interest Posting Dynamic Job is running successfully without any error messages.

Issue Description

For an FAMZ single payment loan, if the Maintain Delinquency flag is set to false, the reversal of the rescheduled loan is failing with the following error message: “CL019443: DML Exception in Bulk Reschedule Reversal Transaction. Duplicate id in list: a813t000000gZ5JAUU.”

Example

Let us try to understand this issue with the help of an example.

The reversal of a rescheduled FAMZ single payment loan should work without any exception however, it is not working if the Maintain Delinquency is set to False.

Resolution

While performing a reschedule reversal certain Interest Posting Transactions are discarded, these discarded Interest Posting Transactions are again considered for delinquency due to which same Interest Posting Transaction is added twice, causing duplicate Id exception.

This issue is now fixed by adding a conditional check to not consider the discarded Interest Posting Transactions. The Reschedule Reversal is working fine even when Maintain Delinquency is set as False.

Issue Description

When a bill is paid for a cycle and the Pay Future Dues Timely flag is set to false, the system is creating incorrect late charges in the payoff quote. Late charge is getting created for the last bill which has already been paid.

Example

Let us try to understand this issue with the help of an example.

Resolution

The issue is fixed now. The late charge is not getting calculated for the bill which is paid on time.

Issue Description

On doing a backdated loan payoff, after the loan closure, the loan Balance field value is getting calculated in negative and also the Adjusted Interest Capitalized field is not getting updated to zero.

Example

Let us try to understand this issue with the help of an example.

The loan status should be updated to Closed – Obligations Met. The Adjusted Interest Capitalized should be non-zero as the loan is closed and the loan balance should be positive after the backdated payment.

But the loan balance is getting calculated as a negative value and the Adjusted Interest Capitalized field is not getting updated to zero after the loan closure.

Resolution

The issue is fixed now. When a backdated Payoff is done and the loan is closed, Adjusted Interest Capitalized value is added to the excess and loan balance is getting updated correctly.

Issue Description

The Prepayment Penalty amount is getting incorrectly calculated when the fee amount is calculated as a percentage of the Principal Balance and when the Pay Future Dues Timely flag is set to true.

Example

Let us try to understand this issue with the help of an example.

Resolution

The issue is fixed now. The prepayment penalty amount is getting calculated correctly when the fee amount is calculated as a percentage of the principal balance and when the Pay Future Dues Timely flag is set to true.

Issue Description

When the Data Mapper Dynamic Job is run for 300k records, it is failing with the following null pointer exception:

Resolution

When the external batch for Data Mapper Dynamic Job was null, it was throwing the null pointer exception.

As a solution to it, the null check was added. The issue is fixed now and the Data Mapper Dynamic Job is running successfully.