Summer'22 Release Notes

This document provides information on the following for the release:

The audience of this document includes business users, implementers, and system administrators.

This document assumes a basic knowledge of the product concepts, the product release, and the Salesforce platform.

Feature Description

With the Summer’22 release, Q2 Loan Servicing platform has enhanced the Financial Calculator to achieve better performance and output of EMI calculation. What does this mean?

Scope of Summer’22

As part of the Summer’22 release, the following use cases have been enhanced with respect to FinCalc 4.0:

How to enable FinCalc 4.0

As a new user/lender on Q2 Loan Servicing Platform, you can select the version of FinCalc that you want to use at the Org Parameters level as highlighted in the following image:

We would recommend that you switch to 4.0 only once all the calculation use cases are covered and delivered by Spring’23 version.

If you are an existing user on the platform, your FinCalc version continues to remain unchanged even if you upgrade to Summer’22 unless and until you explicitly change this at the org level.

In case you want to try out our new version for running a particular set of loans for better performance, we have given the provision at the loan product level to select the version of FinCalc for only that product. A new field 'Financial_Calculator_Version c’ has been added on the 'Loan Product' object where the new calculator version '4' can be mentioned (Old versions supported are 3 and 3.1).

Feature Description

For the lenders who charge a penalty / fee to their borrowers in case when they do a pre-payment or pre-closure of the loan, Q2 Loan Servicing will now let you define this fee with a new slab-based capability.

You can define the prepayment penalty type fee to the product and define the calculation logic that needs to be applied on the loan whenever there is a pre-payment done on the loan by the borrower. You can create time-based slabs for which you want to charge the borrower for any early payments and the amount of charge that must be paid by the borrower in that case.

The calculation logic can be both flat as well as percentage and the reference amount for calculation can be selected from a number of values like “prepayment amount”, “payoff amount”, and more. You can also custom define the reference amount

Like in the following example displayed, the scenario is basically when the borrower tries to make an early payoff on the loan. The time slab has been defined with 0 as the lower limit and 3 as the upper limit, value as 20. Calculation type is percentage and Calculation amount reference is Payoff amount.

What that means is that if the borrower tries to do a prepaid payoff within 0-3 years of opening the contract, the system will create a charge equal to 20% of the payoff amount at that point of time. And in case the payoff is done post 3 years, there would be no charge levied on the borrower. The lender can also add more slabs for subsequent periods with different rate as well.

Prepayment penalty calculation at the time of normal pre-payment

When there is a prepayment fee defined on the loan contract, and if you try to record a payment transaction that is more than what is due at that point of time, the system would immediately calculate the pre-payment charge that would be applied on that contract as highlighted in the following diagram.

As soon as the payment transaction is saved, the system would create charge of prepayment penalty type on the loan, in an unpaid state, which can be paid separately or with the next bill.

Prepayment penalty calculation during early payoff

If you try to record an early payoff transaction on a loan, on which prepayment penalty is defined, the system would show you the calculated prepayment penalty amount on the screen, which would have to be paid off along with the payoff amount. The system would not get closed unless and until this is paid as well.

Waiver of prepayment penalty charge

In case if you want to waive the charge that got created due to prepayment, you can always use the waive fee feature to do the same.

Feature Description

Payoff Quote has been quite a complex feature that touches several areas in the system for predicting the payoff amount as on a future date.

In the past releases, we have added a lot more to the scope of this calculation, as and when we came across new use cases from our customers. This had increased the complexities and occurrence of issues in various scenarios. We went back to the drawing board and revisited our design to optimize the feature and improve the performance of the same.

The use cases that we considered for performance improvement in Summer’22 is listed as follows:

The scenarios that are not yet supported would be enhanced in subsequent patch releases for Summer’22. What that means is, that in Summer’22 release, the following listed scenarios would not get included in the payoff quote calculation:

Feature Description

With the Summer’22 release, Q2 Loan Servicing allows you to define two new parameters “Reference Cap Rate” and “Reference Floor Rate” both at the loan product.

Reference Cap Rate: This is the upper limit of floating rate index. Let us say you define this rate to be

3.0 on the loan product and suppose that product is tagged to “LIBOR 3M” reference rate. Now let’s say that a loan contract that is drawn out on this product has a rate revision expected to occur today. What that would mean is the floating rate revision batch job would look for today’s rate of LIBOR 3M in the system and let’s say that today’s rate is 3.1, then in this case, the system would check for the cap rate and do a rate revision on 3.0 instead of 3.1.

Reference Floor Rate: Similar to Cap as explained in the preceding lines, you can define this rate, which would act as the lower limit of floating rate index. Let us say you define this rate to be 2.5 and for LIBOR 3M, if the rate for the day has gone down to 2.4 on the date of rate revision, then the system would automatically do the rate revision on 2.5.

Feature Description

With the Summer’22 release, you would be able to find all the distribution transactions of Loan Disbursement Transaction in the Loan Transaction Statement, as highlighted in the following image:

Feature Description

There are two new fields introduced on the Loan Transaction statement, which evidently show the type and amount of interest adjustment in case when an IPT is reversed and recreated due to creation of a backdated transaction.

The fields are “Adjusted Interest Amount” and “Adjusted Interest Type”.

Example of Credit type

Example of Debit Type

Issue Description

If a loan that is of the type of Simple Loan has the Revolving and the Funding in Tranches flags set to True, the Pre-Paid Fee amounts are getting added to the Loan Amount during the creation of a Loan Disbursal Transaction even if the Add Fee to Loan Amount flag is not set to True and hence, Pre-Paid Fees are not set to be added to the Loan Amount. Due to this, the system is funding an amount that is including the fees.

Resolution

This issue is fixed. Now the logic is updated such that, for a Simple Loan that has the Revolving and the Funding in Tranches flags set to True, the system is checking the status of the Add Fee to Loan Amount flag to know whether the Pre-Paid Fee must be added to the Loan Amount or not. If it finds that the value of the Add Fee to Loan Amount flag is true, then it adds the Pre-Paid Fee to the Loan Amount while disbursing. Else, it does not.

Issue Description

While trying to reverse the Interest Waiver on the Other Loan Transaction page, the system is throwing the following exception:

“System.LimitException: loan:Too many DML rows: 10001.”

This is because the LPT that was created when an Interest Waiver transaction was made is not existing in the system. This is because it was deleted.

Thus, the system must display an error message on trying to reverse an Interest Waiver OLT transaction is the corresponding LPT does not exist.

Resolution

This issue is fixed. Now, while trying to reverse an Interest Waiver OLT for which the LPT is deleted, the system is displaying the following error message:

“You cannot reverse this transaction. There is no Payment transaction related to this Waiver transaction.”

Issue Description

On trying to reverse the Charge Off type of OLT (Other Loan Transaction), the system is throwing the following exception:

“Attempt to de-reference a null object.”

The Charge Off reversal must work successfully and the loan status must change to Active - Bad Standing.

Resolution

This issue is fixed. Now, on trying to reverse the Charge Off type of OLT, the system is reversing it successfully.

Issue Description

In a flexible AMZ loan where the Create Summaries flag is set to True and where there are IPTs of both the types, regular and additional interest, and the additional interest IPT is not paid but the due date has passed, the InterestPostingAmzDynamicJob is failing with the following error message:

“Object row was retrieved via SOQL without querying the requested field: loan_Interest_Posting_Transactionc.loanExternal_Id_c.”

Resolution

This issue is fixed.

In a flexible AMZ loan where the Create Summaries flag is set to True and where there are IPTs of both the types, regular and additional interest, and the additional interest IPT is not paid but the due date has passed, the InterestPostingAmzDynamicJob is now running successfully without any error messages.

Issue Description

The last bill generated for a loan that has the following flags set to True is getting calculated incorrectly:

This is because, the system is including the extra fee amounts generated due to capitalization in the last bill amount. The last bill generation depends on the payoff amount that does not include the charges, but the capitalized charge is getting added to the payoff amount which gets added to the last bill amount.

Resolution

This issue is fixed. Now the logic has been corrected, and because the payoff amount without charges should not include charges, the charge capitalized is also not getting added to the bill. The charges are getting added to the bill only if the following flags are set to True:

Issue Description

Even if the fee is deactivated for some time by setting the Status of the fee to Inactive, the system is not considering this status and is creating a late charge for the inactive fee.

Resolution

This issue is fixed. Now the system checks the Status of the fee while creating the late charge. Thus, if the Status of the fee is set to Inactive, the system is not considering that fee to create the charges.

Issue Description

If an Interest Only loan with Advance Interest enabled is rescheduled on Loan Balance, the system is calculating a higher bill amount than expected.

This is because the system is including the reversed and discarded IPTs too in the bill amount after the loan is rescheduled with Loan Balance and Maintain Delinquency as False.

Resolution

This issue is fixed. The logic has been updated to include only the correct IPTs to generate a correct bill amount after rescheduling.

Issue Description

In a loan where there the Deposit amount is high and close to the Loan Balance and the Adjust Deposit to Payoff flag is set to True, the bill is getting generated for a lower payoff amount instead of the EMI amount.

This is because while generating the bill, due to the Adjust Deposit to Payoff flag being True, the system is considering the payoff amount of the loan, where the payoff amount of the loan = payoff amount – deposit amount. Thus, if the deposit amount is higher and close to the Loan Balance, the derived payoff amount is of a much lower value as the high deposit amount is deducted from the actual payoff amount (actual payoff amount is calculated using all the parameters of the loan such as the Interest Remaining and more) resulting in a lower payoff amount and hence the bill amount was getting generated of a lower value.

Resolution

This issue is fixed. Now during the generation of bill, the system is considering the payoff amount of the loan without deducting the deposit amount from it, and the bill is getting generated with the correct amount.

Issue Description

When a payment is made to pay off a Protect-enabled loan, and the loan status moves to Active- Marked for Closure, the Minimum Interest charge/fee for an early termination is not getting generated. Then on running the Loan Closure Job, this fee is getting charged, but the payment was not made against this fee. Hence, the fee remains unpaid and so the contract status remains in Active-Marked for Closure.

Expected behavior: While making a payoff, the early termination fee, with Time of Charge as Minimum Interest, should be charged automatically, and the balance should be paid off by the payment done.

The contract status should be changed to Active-Marked for Closure, and thereafter, on running the Loan Closure Job, the rebate payment should be created and thus the contract status should be changed to Closed - Obligations Met.

Resolution

This issue is fixed. Now, while making a payoff, the early termination fee is charged automatically, and the balance is paid off by the payment done. The contract status changes to Active-Marked for Closure, and thereafter, on running the Loan Closure Job, the rebate payment is created and thus the contract status changes to Closed - Obligations Met.

Issue Description

When a payment is made to pay off a loan by creating multiple LPTs simultaneously for multiple contracts, the Minimum Interest fee for early termination is getting charged with an incorrect amount and is considering the payment as excess for all of the contracts except the last contract. For the last contract, the early termination fee is getting charged with a correct amount.

Expected behavior: For all the contracts, while making the payoff, the early termination fee should be charged automatically, and the amount should be correct. The contract status should change to Closed- Obligations Met.

Resolution

This issue is fixed. Now when a payment is made to pay off a loan by creating multiple LPTs simultaneously for multiple contracts, the Minimum Interest fee for early termination is getting charged correctly for all the contracts.

Issue Description

Interest Remaining amount and Interest posted amount for future dated calculation is not taking into account the following scenarios:

Let us say there is a Master Facility FIT loan contract with Contract Start Date = January 5.

Then say, on the next due date when Bill and IPT are generated, click Details tab > Payoff Quotes > New Payoff Quote.

Let us say Next Due Date is February 8 and the Current System Date is February 8.

On different dates, create future dated payoff quotes for the same dates as explained in the following table:

Let us say we create a Master Facility contract with Monthly payment frequency and activate it.

Then let us create two child loans with different dates so that Interest Posting day in child loans will be different.

For example, create a Master Facility contract on January 5, 2021, and create first child loan on January 10, 2021, and 2nd child loan on January 15, 2021, then move system date till 2 IPT cycles, which is March 15, 2021, so that interest should be posted in child loans. Then the Next Interest Posting Date in Master Facility would be April 6, 2021, because April 5, 2021, is added as a holiday.

In the child loans, ‘Next Interest Posting Date’ is updated to April 12, 2021, (as April 10 and April 11 are holidays) and April 15, 2021, respectively.

Resolution

This issue is fixed, and the system is enhanced to take into account all the preceding scenarios while calculating the Interest Remaining and the Interest Posted amounts.

Issue Description

After making an early payoff for all the child loans and the corresponding Master Facility and then performing a Manual Closure, on running the Accrual Entry Job at the end of the month, the Interest Accrued in the Master Facility is not equal to the Interest Posted till the payoff date.

This is because after the payoff in the middle of the month, when the month-end accrual runs, the accrual is getting calculated till the month-end date instead of the payoff date. Hence, extra interest amount is getting accrued resulting in an incorrect Interest Accrued in the Master Facility.

Resolution

This issue is fixed. Now the accrual is correctly getting calculated only till the payoff date, and not the month-end date. Hence, the Interest Accrued and Interest Posted in a Master Facility after an early payoff are now same and correct.

Issue Description

While performing a Manual Closure of a revolving loan that is either a Master Facility or an EOD accrual enabled loan with Accrual Through Date or Accrual To Date type of accrual, the system is asking to pay the payoff tolerance amount in the Today’s Payoff field.

Resolution

This issue is fixed. Now while performing a Manual Closure of a revolving loan that is either a Master Facility or an EOD accrual enabled loan with Accrual Through Date or Accrual To Date type of accrual, if the payoff amount is less than the payoff tolerance amount, the system will close the contract and not ask the user to pay that payoff tolerance amount anymore.

Issue Description

On trying to generate a future dated payoff quote for a capitalized-enabled and an EOD enabled accrual loan with Accrual Through Date type of accrual, the Interest Remaining is getting calculated incorrectly.

Resolution

This issue is fixed. Now the future dated payoff quotes are getting generated correctly.

Issue Description

On clicking Payoff Quote to generate a payoff quote, the system is displaying the following error message:

“Aggregate query has too many rows for direct assignment, use FOR loop.”

This issue is occurring due to more than 200 child records of the type of repayment schedules being processed by the system.

Resolution

This issue is fixed as the internal logic has now been changed to use the FOR loop in the code.

Issue Description

In a loan where interest rate is floating, if you try to change the Floating Rate Index for the upcoming cycle or create a new Floating Rate Index in the Interest Rate Schedule by going to Loan Quick Menu > Loan Actions > Rate Change, the Interest Rate Schedule displays the updated values and the new amortization schedule is getting created, but the fields such as Floating Rate Index and the Current Interest Rate and Current Index Rate of the contract are not getting updated.

Example

Let us say we have a loan with the following Floating Rate Index:

Let us say that the current system date is 3/1/2013. Now let us go to Loan Quick Menu > Loan Actions > Rate Change, and then let us say we are updating the FRI2 as follows:

After updating the FRI2 for the upcoming cycle, the preceding Interest Rate Schedule and the amortization schedule are getting updated, but the fields such as Floating Rate Index, the Current Interest Rate, and Current Index Rate of the contract are still displaying the old values that are FR2, 8.00, and 8.00 respectively. The values on the contract must get updated to FRI2, 7.50, and 7.50 respectively.

Scenario 1:

Let us say a loan product has a Floating Rate Index associated with it, and the name is FRI1. Then after creating a contract, the same FRI1 is associated to the contract too.

Then, let us say, we change the rate of interest where we edit the existing rate change record and change the Floating Rate Index from FRI1 to FRI2.

This rate change action is generating new schedules, and the rate schedules are getting updated, but the fields such as Floating Rate Index, the Current Interest Rate, and Current Index Rate of the contract are not getting updated.

Scenario 2:

After updating the Floating Rate Index from FRI1 to FRI2 and moving the date to the one from which the FRI2 starts, then running the Submit Reset Job, the system is updating the schedules and all the fields except the Last Rate Change Date field of the contract.

Resolution

The internal logic has now been updated and all the fields are now getting updated correctly after updating a Floating Rate Index for the upcoming cycle.

Issue Description

On rescheduling a contract with incorrect details in the Flexible Repayment Plan, instead of displaying an appropriate message, the system is throwing the following technical error: “Divide by 0.”

To elaborate this. while rescheduling a contract with Repayment Procedure as Equal Monthly Installments, on updating the Flexible Repayment Plan in such a way that the total payment amount is getting calculated to a value greater than the Principal Remaining, then the values in the EMI are calculated as negative values, and if the value is negative, the system is changing the value to zero. Due to this, the system is displaying the following technical error: “Divide by 0.”

Resolution

This issue is fixed as the internal logic has been modified now to display an appropriate error message.

Now, while rescheduling a loan with Repayment Procedure as Equal Monthly Installments, and on updating the Flexible Repayment Plan in such a way that the total payment amount is getting calculated to a value greater than the Principal Remaining, the system is displaying an appropriate error message as follows: “The total computed payment amount must not be greater than the expected amounts for the respective selected Payment Types.”

Issue Description

The Additional Interest accruals are being included in Today’s Payoff but not in the Payoff Quote.

For example, if today’s Payoff = £20,199.19 and Additional Interest accrued = £5.82, then the Total Payoff Amount (in Payoff Quote) = £20,193.37.

Thus, as seen in the preceding example, while the Payoff is including the Additional Interest accrued, the Total Payoff Amount in Payoff Quote is not including it.

Resolution

This is fixed. Now, in cases where Additional Interest is to be calculated on the Delinquent Amount, the current dated Payoff Quote is including the Additional Interest accrued too.

Issue Description

On clicking Payoff Quote to generate a payoff quote for a future date, the system is displaying the following error message:

“Aggregate query has too many rows for direct assignment, use FOR loop.”

This issue is occurring due to more than 200 child records of the type of repayment schedules being processed by the system.

Resolution

This issue is fixed as the internal logic has now been changed to use the FOR loop in the code.

Issue Description

Following are the scenarios where Future Dated Payoff Quote inconsistency is observed:

Scenario 1: Future Dated Payoff Quote with minimum interest feature enabled

If we create a future dated Payoff Quote in a loan that includes the Minimum Interest calculations, the system is incorrectly considering both the minimum interest amount as well as the accrued interest that is calculated from the current system date to the Payoff Quote date if the Payoff Date is within the Minimum Interest Period.

Example

To understand the issue in this scenario, let us see an example. Let us say that Minimum Interest Period is defined as 180 days.

Now, let's assume the accrual start date is January 1, 2022, and the current system date is also January 1, 2022.

Then let us create a Payoff Quote on January 1, 2022, with a future Payoff Date such as January 10, 2022.

The system is calculating the Payoff Quote that is including the interest of the 180 days (as per minimum interest configuration) as well as the accrued interest of the 10 days (accrued interest from January 1, 2022, to January 10, 2022).

The system must include only the interest of the 180 days (as per minimum interest configuration), and not the accrued interest of the 10 days (accrued interest from January 1, 2022, to January 10, 2022) as this accrued interest is already considered in the minimum interest amount. (This is because the interest amount for 180 days is greater than the interest for 10 days so the interest amount for 180 days must only be considered for future dated Payoff Quote calculation when Payoff Date is within the Minimum Interest Period.)

Scenario 2: Future dated Payoff Quote with interest capitalization of a different frequency than the billing frequency

Example

To understand the issue in this scenario, let us see an example.

Let's assume the current system date January 1, 2022, and the IPT posting and capitalization date is January 5, 2022

Now let us say we create a Payoff Quote on January 1, 2022, with the Payoff Date as January 10, 2022.

This means that the system should have capitalized the interest on January 5, 2022, and then the capitalized interest should be added to the Principal Remaining for the Payoff Quote calculation. But the system is not doing this. It is not adding the capitalized interest to the Principal Remaining for the Payoff Quote calculation.

Thus, the system is calculating interest on the same initial Principal amount even after the capitalization date for a future dated payoff quote.

Resolution

This issue is fixed. Following are the resolutions in case of each scenario:

Scenario 1: Future Dated Payoff Quote with minimum interest feature enabled

The system is now calculating the future dated Payoff Quote correctly. It is including only the minimum interest amount (when Minimum Interest Period is defined) when the Payoff Date is within that period.

Scenario 2: Future dated Payoff Quote with interest capitalization of a different frequency than the billing frequency

The future dated payoff quote calculation logic has now been updated such that on every future capitalization day, the system will update the Principal Remaining and then calculate the interest on that updated amount.

Issue Description

If a there are two consecutive rescheduling transactions occurring on the same day or if a rescheduling is occurring on a Due Day, the Interest Rounding Error field is incorrectly updating to zero even when the value of the Interest Rounding Error is a non-zero amount.

Resolution

This issue is fixed as while rescheduling, the Interest Rounding Error is now not set to zero.

Issue Description

If a lending product is already created defining a Min Financed Amount, the system is not allowing the user to then increase the value of the Min Financed Amount, and is displaying the following error message:

“Invalid Minimum And Maximum Loan Amount.”

Example

Let us say we have created and saved a lending product with the Min Financed Amount defined as $1,000, and Max Financed Amount as $100,000.

Now let us say, we try to edit this lending product by updating the Min Financed Amount to $2,000. On clicking Save, the system is not saving such a configuration and displaying the following error message:

“Invalid Minimum And Maximum Loan Amount.”

Resolution

This issue is fixed. The logic in the system is now updated to allow the user to be able to increase the Min Financed Amount of a lending product, and the system is not displaying any error messages on saving such a configuration.

Issue Description

After configuring DAG to run the CL Loan batch jobs, the system is throwing the following error while running the Dynamic Wrapper (StartOfDayDynamicJob) (querying the eligible records and processing on multiple threads of 5):

“Apex CPU time limit exceeded exception.”

This is due to there being a high volume of data of around 180,000 contracts, and to increase the efficiency, a few jobs are being run on multiple threads.

The loan contract random generator is populating thread numbers at the time of contract creation, and hence the loan contracts are not getting segregated to the threads properly and the system is picking up the contracts randomly.

This issue is occurring for the batch jobs that are running on 5 threads, and with batch size 200.

Resolution

This issue is fixed. The internal logic has now been updated to enable the mapping of the job name with the thread API name so that the jobs are correctly distributed to the thread numbers resulting in an increase in efficiency. With this fix, the system is not throwing the exception while running the Dynamic Wrapper (StartOfDayDynamicJob).

Upgrade Script to modify the thread number

After upgrading to this patch, if the thread assignment is not proper, or, in other words, if loan contracts are not getting evenly distributed to the threads due to the random generator, you must perform the following steps to run the upgrade script:

Deploy the following class from the UnmanagedCustomerScripts folder of v_2.7016_Pheonix_Patch_New_Branch in neon-1 repository:

Database.executeBatch (new AssignThreadNumToLoanContracts(), 200);

To understand when to run the upgrade script, let us say, we have thousands of contracts. Now, say, out of them, 200 contracts are assigned to thread 1, 200 to thread 2, and so on, but only 10 contracts are assigned to thread 5, then this is not an equal assignment and so, you must run the upgrade script.

If there is equal assignment, then you do not need to run the upgrade script. However, if there is unequal assignment then you must run the upgrade script.

For example, if contracts are not getting created in bulk, but every day, say, one contract is getting created, then the customer may not face this problem of improper assignment of contracts.

However, to check the thread assignment, you can run the following queries:

After running the preceding queries, if the number of records in all the cases are almost same, then you do not need to run the script. However, if the difference in the number of records between any of the cases is huge, then you need to run the script.

Issue Description

When a final payoff is made before the maturity date, the system is creating an IPT of the type of Excess Payoff, but in the corresponding Loan Transaction Summary (LTS) record, the Current Loan Balance and Consolidate Loan Balance are displaying a value of 0. The value of the Current Loan Balance must be the sum of the balance and the excess payoff IPT amount.

This issue was occurring because the LTS stores the value obtained after the payoff is done. So, the Excess Payoff IPT in its LTS holds the value after the payoff. Due to this, the value of the Consolidated Loan Balance field is displaying a value of zero because after the payoff, the value of Loan balance becomes zero.

So, the Consolidated Loan Balance will have the value of 0, as we capture it after the payoff transaction. Also, the system does not capture the Excess Payoff IPT amount in the Loan Transaction Summary. The Excess Payoff IPT must be captured before the final payment is done so that the Consolidated Loan Balance field in the LTS holds a correct value.

Example explaining the issue

Let us say that the current system date is March 1, 2013, and a contract is created on this date and loan amount is disbursed.

Now, on a few days after the next due date, which is April 15, 2013, let us do a payoff after all the jobs are run. After this payoff, the system creates an Excess Payoff IPT. On checking the LTS, we see that the Consolidated Loan Balance fields holds a value of zero.

Resolution

This issue is fixed. After the fix, the LTS corresponding to the Excess Payoff IPT holds the value before the payoff is done. So, the Consolidated Loan Balance, Current Principal Remaining, and Current Loan Balance also hold the values that are calculated before the payoff and therefore are not zero. Also, for Excess Payoff IPT of AIC (Additional Interest Component), LTS gets created and holds the values that are calculated before the payoff.

Issue Description

On clicking the Preview while rescheduling the loan, from the Loan Quick Menu, to update the Flexible Repayment Plan, the system is displaying the following error message:

“Maximum view state size limit (170KB) 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 does not fit in 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 incorporate. 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 limited records on each page. This ensures that the records are displayed and distributed over multiple pages such that a page can only display 50 records. Thus, reducing the size of the list of records on one page. Thus, each of the Amortization Schedule and Repayment Schedule Summary will only display 50 records per view.

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.

Issue Description

Using the internal EMI calculator, some performance issues have been observed. For example, when a loan contract is created with 1040 terms using the internal EMI calculator, the system is throwing the following exception:

“Apex CPU time limit exceeded”. Other performance issues are being observed such as increase in iterations and the time taken to complete various computations.

Resolution

These performance issues are fixed with the introduction of a new custom version of the internal EMI calculator that is used to optimize the performance of the EMI calculator.

As part of the fix, the goal seek method to compute the EMI has been improved by using the binary search as opposed to the secant method. In the earlier secant method, the system was unable to compute the EMI amount as it was going through too many iterations. But, in binary search method, with less iterations, the system is now able to compute the EMI. However, the CPU time would still be large due to complications in interest computations for every payment term and iteration, and hence you may still encounter exceptions, but the fix would give you some extra CPU time to do post processing of data.

Issue Description

The custom version of the internal EMI calculator is unable to arrive at a payment amount when there is an additional payment schedule.

To understand this, let us say a loan contract is created for 10 years and the payment is to be made weekly. If the user wants to pay a fixed amount for the first six months on a weekly basis, then the calculator must compute the payment for the remaining 9 years and 6 months. But the calculator is unable to compute this payment amount as it is failing to get the correct value of the payment amount in the initial iteration. Because of this, the payment amount limit that is set by the calculator is throwing the computation off the track. For example, let us say that the actual payment amount is $10. In the goal seek method, let us say the initial estimation of the payment amount is around $50. Then a limit of 20% above and below this amount would be, say, around 40 to 60. The computation then tries to limit the payment amount within the range so it will never compute the correct payment amount because final payment amount would be out of this range.

Resolution

This issue is fixed as the internal logic for setting the payment amount limits is now corrected. Now the system is able to compute a payment amount even when there is an additional payment schedule included.

Issue Description

When two jobs are running in parallel, the Available Amount field of the Account object is updated simultaneously, causing data discrepancy. The data in the field needs to be updated synchronously.

This is because the following actions in the product are not locking the Account record:

Therefore, when Available Amount field is updated if the two jobs are running parallelly, then the value in the Available Amount field is incorrect. Due to this, there are discrepancies in the auditing jobs related to the Account object records.

Resolution

This issue is fixed as the FOR UPDATE statement is used in the queries where the Available Amount field is queried. Hence, the record lock occurs when a simultaneous update on the record happens.

Issue Description

In a current cycle, if there is any LAD event before rescheduling, then the schedules are generated incorrectly.

To understand the exact issue, let us say a loan is created on March 1 and we are rescheduling on March 11. Now in between March 1 and March 11, if there is any LAD event such as a payment, then the schedule is generating incorrectly.

This is because on the rescheduling date, the interest accrued till the rescheduling date for the current cycle is calculated on the Principal Balance when the rescheduling is done maintaining the delinquency (Maintain Delinquency flag is True.)

Let us understand the following case too where this issue was observed. Issue when an internal transfer from deposit to loan was made:

When an internal transfer from deposit to loan is made of a huge amount and then if the loan is rescheduled, it is observed that the first repayment schedule's interest is way less than what it should be. The EMI amount is also incorrect due to this issue.

To understand this, let us say, on January 21, 2022, we create a simple loan with Interest Posting enabled and deposit account set up with a zero amount. Let us say the Loan Amount is $450,000 and it is funded with an Interest Rate of 1.99%.

After a week, on January 28, 2022, an interest of $171.74 gets accrued on the contract. Let us say we add $175,000 to deposit.

After a week, on February 4, 2022, let us make an internal transfer of $165,000 from deposit to the loan account. Then the Loan Balance would become $285,000. On the same day, let us perform a simple rescheduling (by clicking on Reschedule > Preview > Save.)

We see that the very first repayment schedule's interest due is computed incorrectly and is $481.69 instead of $540.84.

Resolution

This issue is fixed as the rescheduling is generating a correct interest in the AMZ schedule after there is an LAD event.

As part of the fix:

Additionally, this issue is also fixed in the following cases:

When there is a rate change between the start of the current cycle and the rescheduling date To understand this case, let us say we have the following:

When the loan is delinquent, normally the interest is calculated on Schedule Balance from March 1 to 10. But the problem in this case is that you could have a rate change before rescheduling. Then, you cannot calculate interest from March 1 to March 10 on 12% because the rate from March 2 to March 8 is 10% and from March 9 to March 10 is 12%.

So, as a fix, on rescheduling, the interest is calculated in the following way:

In this case, when we make a payment, the interest accrued till the payment date is moved to Interest Remaining, and it reduces the principal. In non-IPT loans, there are no interest postings and so the Interest Remaining is calculated differently as follows:

If Interest Accrued = $10, and Interest Paid = $6, then Interest Remaining = $4.

Now, while rescheduling, the amount $4 is considered, and not $10, which was before the payment made.

This is fixed by storing the values in the loan snapshot before the payment is made and then considering the loan snapshot values while rescheduling to arrive at the correct amounts in the AMZ schedules.

Issue Description

If the flag, Enable Future Rate, in the Custom Setting is false, and on changing the floating index rate the system is not updating the Last Rate Change Date accordingly. To understand this issue, let us see the following example:

Let us say the FRI details are as follows:

Now let us create a lending product with above FRI and let us select the interest rate change frequency as daily/monthly.

Let us say the contract creation date is March 2, 2013. Here the Last Rate Change Date is set to March 2, 2013. Issue -1:

Let us go to the date March 16, 2013, and open the second floating rate index (March 16, 2013, to March 30, 2013 - 6 %), and then click the Submit Reset Process button.

On clicking the Submit Reset Process button, the Last Rate Change Date incorrectly remains as March 2, 2013, and does not get updated to March 16, 2013. The value of Last Rate Change Date must be updated to March 16, 2013.

Issue -2:

Let us go to the date March 17, 2013. We see that the Last Rate Change Date still incorrectly remains as March 2, 2013. The Last Rate Change Date must be updated to March 16, 2013.

Resolution

This issue is fixed. Now, if the flag, Enable Future Rate, in the Custom Setting is false, and if a rate change is made, the Last Rate Change Date is updated to a correct value.

Issue Description

The Consolidated Loan Payment page is not working as expected and consists of the following issues:

Resolution

Following are the fixes made in this patch:

Thus, the Consolidated Loan Payment page is modified to accommodate all the required changes.

Issue Description

While the system was running the Interest Posting Job, the snapshot for Interest Posting Transaction Snapshot field contained more than 255 characters due to which the job failed with the following error: “STRING_TOO_LONG, Interest Posting Transaction Snapshot: data value too large.”

Resolution

This issue is fixed as few fields were removed in the snapshot to reduce the size of the snapshot. The following parameters are no more present in the snapshot field:

Issue Description

If the business wants to stop charging additional interest on any contract during the term, system does is not allow this action, and it is throwing the following error message:

“CL016483: Interest rate value must be provided with a non-negative number”

Thus, the system is not allowing the users to change the Additional Interest rate to 0%.

The expectation is that the system should allow the changing of the rate of AIC to 0% both through the UI and through using the rate change API.

Resolution

This issue is fixed as the system is now allowing the user to perform a Rate Change for Additional Interest rate to 0% through UI and through using the API. Now the Additional Interest can be set to 0%, and after it is set to zero, the AIC IPTs are correctly displaying a value of 0 for the Interest Posted amount.

Issue Description

On trying to open the Manage Accounting Events page by going to Servicing Configuration > Accounting Setup, the system is throwing the following error message when the page is trying to load:

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

This is because, the system is trying to fetch and display more than 150 records on a page, which is more than what the system can fetch and display on a page.

Resolution

This issue is 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 incorporate. 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 Manage Accounting Events page to display limited records on each page. This ensures that the records are displayed and distributed over multiple pages such that a page can only display 20 records. Thus, reducing the size of the list of records on one page.

Also, flexibility to move across pages is provided as part of this fix. Now more than 500 records are allowed to display as the records are divided into pages.

Additionally, following changes are also made as part of the fix:

If the system is on the first page, and if the records are more than 20, 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 20, then all the four buttons are not visible on the page.

“Please save your changes before moving to other pages. On changing the page, records modified on this page will not be auto saved.”

This means that the records modified on any page must be saved on the same page. If you make changes on a page and then move to another page without saving it, then the changes would not be saved on the previous page.

Issue Description

If an FAMZ loan is written off and then the payments are made, then first the interest components are getting satisfied for all the unpaid bills and then the principal. This is because the system is not considering the Default Write Off Recovery Spread.

Example

Let us say there is a loan contract with the following bills and with the following payment split for each cycle:

Now, if, after the FAMZ loan is written off, a payment is made, then all the interest component is getting satisfied first and then the principal components. Thus, $10+ $10+$10 = $30 is satisfied first and then $90 + $90 + $90 = $270 is satisfied.

Expected Behavior

When a transaction amount is equal to the bill amount for a payment of a written-off loan, the payment must follow the Default Write Off Recovery Spread and it must be used to satisfy the complete outstanding principal first, and then the interest and then fees.

Actual Behavior

When a transaction amount is equal to the bill amount for a payment of a written-off loan, the interest components of all the unpaid bills is getting satisfied first before the principal amount of the first bill.

Resolution

This issue is fixed. After a FAMZ loan is written off, when a recovery payment is made, the system is now considering the Default Write Off Recovery Spread and satisfying the outstanding principal first before the interest and the fees.

Issue Description

LPT is getting satisfied over and above the principal component of a bill despite the bill having interest component as well to be satisfied.

Example

Let us say we have a loan contract where Interest Posting is enabled and there is a deposit account in it.

Let us set the deposit offset to 1 day.

Now let us set up automated payment on this loan contract for the LAST BILLED AMOUNT.

Then create a manual LPT one day before the billing date with amount greater than the bill amount and make sure the same is not cleared until billing date.

Once the bill is generated on the loan contract, clear the previous day LPT that was created and check how the LPT is clearing the bill. It is only satisfying the principal component of the bill.

Expected Behavior

LPT should not satisfy the bill as LPT created is a backdated one and should put the entire LPT amount into deposit account.

Actual Behavior

LPT instead is clearing the bill that is created on future date. future bill was getting satisfied by backdated LPT

Resolution

This issue is fixed. The internal logic has now been updated to restrict the bill satisfaction by backdated LPT in normal scenario.

Issue Description

In a Flexi-AMZ loan product with Single-Payment frequency, the InterestPostingAmzDynamicJob is not calculating accruals if it is run with batch size 1.

Example

Let us say that the current system date is October 27, 2021, and we create a loan contract with the following terms and conditions:

On activating the contract and moving to October 28, 2021, today's payoff quote amount was updated correctly, but the Current Interest Accrued in IPT and Interest Accrued in the Contract Details section were not updated.

If we create a payoff quote as of October 28, 2021, it has the correct value in the Interest Remaining field. Thus, we see that the contract is not getting processed correctly.

This is because, in FAMZ loans, for accruals, the schedules were not fetched correctly.

Expected Behavior

Even if the job is run with batch size 1, the interest should get accrued.

Resolution

This issue is fixed. Now interest is getting accrued correctly for Single-Payment frequency in an FAMZ loan.

Issue Description

The value of Interest Per Diem on the Payoff Quote was not based on the Principal Balance owing on the day of payout when Pay Future Dues Timely is True. This is because for Pay Future Dues Timely- enabled Payoff Quote, the Interest Per Diem was getting calculated based on the Current Principal Remaining.

Resolution

This issue is fixed. Now, for Pay Future Dues Timely-enabled Payoff Quote, the Interest Per Diem is getting calculated based on the future Principal Remaining.

Issue Description

If you reverse a loan payment transaction (LPT), you have the option to refund the reversed LPT amount to the borrower. When you select the Refund to Borrower checkbox, you can select a bank account of the borrower. However, the system is providing all the bank accounts of all the customers to select from, instead of providing the bank accounts of the borrower of that loan.

Resolution

This issue is fixed. Now while refunding and selecting a bank account, the system displays only the active bank accounts related to the borrower. Additionally, fields such as the Account, Payment Mode, and Transaction Amount are also added on the Payment Reversal page.

Issue Description

When the balance in the Deposit increases such that, it exceeds or is equal to the Loan Balance and if the Adjust Deposit Amount in Payoff flag is true, then the LPT is not getting created.

Example

Let us create a loan contract with a loan amount of $50,000 and frequency as Monthly and let us say that the loan is disbursed on January 13. Let us set up APS on the contract. Then the first payment date is February 13.

Let us also assume that Deposit Payment Offset Days is Null and Adjust Deposit Amount in Payoff flag is true.

Now, after disbursal, let us perform a deposit Adjustment (addition) transaction of $40,000.

On February 13, after the IPT gets posted, let us do a payment of the bill amount. Then, let us say the new Loan Balance becomes $40,193.65.

Let us move the date to March 5. This will accrue some interest on the contract.

Let us now update the Deposit amount to $40,200. This amount is more than the Loan Balance and hence the system stops accruing interest.

Now let us move the system date to the second due date, which is March 13. Then, we see that LPT is not getting generated.

Resolution

This issue is fixed. Now, the IPT is getting generated with the scheduled amount even when the Deposit balance exceeds or is equal to the Loan Balance.

Issue Description

Loan Transaction Summary (LTS) is not recording or displaying the correct Balance. Example

Let us create a loan contract with the following details:

Now let us move a few days ahead such that IPT and bill are created. Now, in the middle of the month, let us create a payment transaction such that it closes the loan. This creates one IPT of the type of Excess PayOff. The Balance on the Excess PayOff type IPT is the balance amount before clearing the LPT, but the corresponding LTS record is displaying a zero Current Loan Balance.

The LTS Balance should hold the same value as the Balance in the IPT record.

This issue is occurring due to LTS for excess IPT being created after all the loan balances getting updated to zero after payoff. This is reflecting incorrect balance details on the LTS.

Resolution

This issue is fixed. Now the LTS for excess IPT is created first before the LTS for the payoff IPT. In this way, the Current Loan Balance on the LTS is now displaying a non-zero value and the payoff LTS is displaying a zero Balance on its LTS.

Issue Description

For a loan with Funding in Tranches disabled, accrual time being EOD accrual, and Accrual Type as Accrual To Date, the first Interest Posting Date of the Additional Interest Component (AIC) is falling on a holiday when the IPT frequency of the AIC is set as Billing Frequency.

Example

Let us set up and activate a loan with the following terms and conditions:

Let us set the Contract Start Date as January 29, 2021, so that the Next Interest Posting Date is February 26, 2021, which is a Friday. But the Interest Posting Date for the Additional Interest Component is displaying as February 28, 2021, which is a Sunday, and this date is not in sync with the regular interest.

Now, let us move the system date to the Next Due Generation Date in February. The additional interest billed is getting displayed as zero.

Now let us move the system date to the Next Due Generation Date in March. Then the Additional Interest billed is getting displayed as an incorrect amount.

Actual Results

The first Interest Posting Date for AIC is falling on a holiday and is not in sync with the regular interest.

Resolution

This issue is fixed. Now the holiday treatment is applied to the Next Interest Posting date once it is updated, and hence the first IPT date for Additional Interest is not falling on a holiday.

Issue Description

When a loan is rescheduled with Interest Only Period defined as null and with the Last Transaction Type as Reschedule, the system is rescheduling it incorrectly by adding an Interest Only Period to the reschedule.

This means that if a loan account is rescheduled after a last rescheduled transaction, then the system is adding one Interest Only Period to the loan account.

Example

Let us create a loan account where IPT is enabled and there is a floating interest rate.

Now, while rescheduling, on the Reschedule screen, let us define an Interest Only Period as null.

Then let us reschedule the loan account and move the system date three days ahead ensuring that there are no other transactions done on that loan account and the Last Transaction Type is Reschedule.

Then let us reschedule the loan account again.

If you look at loan account now, you will see that the system is adding one Interest Only Period even though the loan account does not have an Interest Only Period. If you do another reschedule, the system will add one more Interest Only Period. Thus, it will keep adding an Interest Only period for each reschedule.

Resolution

This issue is fixed. Now, when a loan is rescheduled with Interest Only Period specified as null and with the Last Transaction Type as Reschedule, the system is rescheduling the loan correctly without adding any Interest Only Period to the rescheduling.

Issue Description

When a payoff is made in a flexible AMZ loan, after the Investor Payout Job is run, the Investor Loan Transactions generated are not including the interest amount within them.

This is because the LPT of the Payoff type is not including the interest portion because, in flexible AMZ loans, the system does not post the interest at the time of payout as the interest is already getting posted for the investor in the IO Interest Accrual Job.

Example

Let us say we perform the following steps:

It is seen that the interest amount is missing on these ILTs.

Resolution

This issue is fixed. Now if a flexible AMZ loan is closed or refinanced, the system is including the interest accrued portion as part of the ILTs and is reducing that amount from the Interest Accrued field and Interest Remaining field of the Investment Order (IO). This same amount is also considered as paid.

Issue Description

In an FAMZ (Flexible Amortized) loan, if a partial payment is made within the Pre-Bill Days, a prepayment bill is getting generated.

Also, when a payment of amount greater than the Due Amount is made, the Payment Satisfied flag in the bill is not getting updated to true.

Example

Let us perform the following steps:

Upon clearing the LPT, a prepayment bill is getting generated with the same Due Date as that of the regular primary bill. A Prepayment bill must not get generated as the payment was made within the Pre-Bill Days where a bill was already generated. (A Prepayment Bill must not get generated if there is already a bill present with the Due Date.)

This is because, after doing a partial payment between the Pre-Bill Days and the Due Date, an extra bill of Prepayment type and an extra IPT of the Prepayment type is getting generated.

Resolution

This issue is fixed. Now, after doing a partial payment, an extra bill of Prepayment type is not getting generated and an Open type IPT is holding the Interest Posted and Principal Posted amounts. Thus, on making a partial payment within the Pre-Bill Days, the system is not generating a Prepayment bill. The Payment Satisfied is also now getting marked as true in the bill when the payment amount is greater than the Due Amount.

Issue Description

After the generation of the accounting file for charges, the system is trying to update the records via Bulk v2 API, but the update is failing in the ChargeTrigger with the following error:

“CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY:loan.ChargeTrigger: System.LimitException: Apex CPU time limit exceeded”.

Internally, the Charge Trigger updates a few product fields on the CL Contract, due to which the triggers on loan also get executed, and thus the time taken to update a record is greater. There is no change in the contents of the product fields when the product trigger executes, but the update operation causes the trigger to be executed, causing the CPU-consumption.

Following are the product fields on the CL Contract object that get calculated by default via Charge Trigger because of which loan triggers get called:

Basically, the flow is as follows:

ChargeTrigger -> ChargeTriggerHandler.beforeUpdateHandler -> ChargeUtil.updateLoanRemoveCharge and ChargeUtil.updateLoanAddCharge -> ChargeTriggerHandler.beforeUpdateHandler (the update happens here)

Resolution

This issue is fixed. The Charge Trigger update functionality is now being skipped if the required fields in the trigger do not change during a Charge update.

Also, after the fix, Charge Trigger will get called only when any of the following product fields get updated:

Issue Description

Upon clicking Loan Quick Menu > Repayment Schedule > View Amortization Schedule > PDF for Print button and then clicking the Download arrow to download the PDF, the system is not displaying the option to save the PDF, and by default it is saving it as HTML.

This is because unlike other browsers, some browsers such as Chrome use the default built-in PDF viewer. Due to this, the system is unable to provide the option to save in some browsers whereas in other browsers such as Firefox, you can save the PDF.

Resolution

This issue is fixed.

Earlier the PDF was opening in the same tab and not getting downloaded, but now the PDF is opening in a new tab and is automatically getting downloaded in Chrome.

While using Chrome, the following steps can be followed to download PDF:

Upon doing this, you will always find that Google Chrome is downloading the PDF files instead of opening them directly in the browser window.

Issue Description

Upon making a payoff less than the Payoff Quote for a Protect Enabled, non-FIT, Interest Posting- enabled loan and then running the Loan Closure Job to close this loan, the system is not closing the loan and the status of the loan remains as Active – Marked For Closure.

The Loan must get closed with a Rebate LPT and a Closure Tolerance LPT.

This issue is occurring because the interest is getting posted but not paid. To understand this, let us say that before the interest is posted, you are making a payoff. In this case, the payment should not satisfy the interest part and should go to excess. So, during loan closure, the system creates an excess IPT to consider the interest part not paid. And then that IPT amount is to be satisfied from the payoff LPT. However, the excess IPT was not getting paid, so the interest was not considered paid, and the loan was not getting closed.

Example

Let us perform the following steps:

1. Create a Protect Enabled contract with a defined value for the Payoff Tolerance Amount.

2. Generate a Payoff Quote.

3. Make a manual payment for the contract with a Payoff amount that is lesser than the Payoff Quote but is within the tolerance value. (Payment Date should not fall on Interest Posting Date)

4. Run the Loan Closure Job.

Expected Result

Loan must get closed with a Rebate LPT and a Closure Tolerance LPT.

Actual Result

Loan is stuck in the Active Marked for Closure status. Rebate LPT is getting created fine, but the Closure Tolerance LPT is not getting applied to the pending Interest Posted.

Resolution

This issue is fixed. Now the system is successfully closing the loan with a Rebate LPT and a Closure Tolerance LPT when a payoff of the amount lesser than Payoff Quote is made and the Loan Closure Job is run.

Issue Description

While canceling or stopping payments via ACH, on clicking Loan Quick Menu > Loan Actions > Cancel/Stop ACH in the contract, the following error message is getting displayed: “CL010101: Unexpected Exception SObject row was retrieved via SOQL without querying the requested field: loan_Loan_Accountc.loanLoan_Product_Name_r at line 26”

This is because internally the field specified in the preceding error message was not getting queried within the code logic.

Resolution

This issue is fixed as the required field is now queried. Now when clicking Loan Quick Menu > Loan Actions > Cancel/Stop ACH in the contract, the system is not displaying any error messages.

Issue Description

On running the Investor Payout Job, the system is throwing the following exception: “Investor Payout Job failed due to unknown exception.

Message: CL019783: Unable to Payout For Investment Order ILID-0000001439.A Investment Order Payment exists after Transaction Date 2022-05-20.”

To understand when this exception is thrown, let us say that an LPT1 is created to pay only the interest at 5pm on August 2. Now at 5:20 pm on August 2, let us say that another LPT2 is created to pay only the fees. Now when the Investor Payout Job is run on the next day, on August 3, the system creates ILT1 for LPT1 and marks the Paid to Investor flag true on LPT1. But the same flag on LPT2 is not set to true.

Now say, on September 2, there is another LPT3 for payment of interest. Then when the Investor Payout Job is run on September 3, the job picks the LPT for which the Paid to Investor flag is not true. Hence it picks LPT2 but finds that there is already an ILT1 existing after that and hence throws an exception indicating that there is already an ILT existing after August 2.

This occurs if the Investor Payout Batch size is 1 and because the system compares LPT transaction date with ILT transaction date and not the time of the respective LPT. The system must compare the current processing LPT's transaction date with the LPT transaction time rather than ILT transaction date.

Resolution

This issue is fixed by changing the logic in the Investor Payout Job to consider the transaction time of the LPT rather than maximum ILT date at the investor side to compare for processing the job. Now the system is not throwing an exception when the Investor Payout Job is run.

Issue Description

There are the following two issues observed while previewing the rescheduled loan after rescheduling it via the Reschedule button:

Example on Rate Schedule

Let us perform the following steps:

The following results are expected:

However, on previewing the rescheduling, the system was not updating the Amortization Schedule to reflect the new rate schedule from October 1, 2013, in the preview.

Resolution

This issue is fixed. Now when a loan is rescheduled by clicking Reschedule on the UI to update the Rate Schedule or the Flexible Repayment Plan, and then on clicking Preview, the system is correctly including all the changes and is considering the newly updated Rate Schedule or the Flexible Repayment Plan for the loan and displays a correct Amortization Schedule in the preview.

Issue Description

Upon making a payment reversal or a backdated reversal, the following issues are seen:

This is because in the AIC component, Interest Accrued field was not getting updated in case of payment reversal.

Resolution

The first issue is not an issue, it is a product behavior, wherein when IPT is created before LPT, the system must not change the Reversed Flag to True on the IPTs.

Other issues are now fixed. In the AIC component, the Interest Accrued field is now getting updated in case of payment reversal, and Payoff Quotes are also same in all the cases.

Issue Description

When a Payoff Quote is created on an Interest Posting Date for a loan where Daily Interest Accrual Time is EOD, Accrual Type = Accrual Through Date, and Pay Future Dues Timely flag is true, the system is calculating an incorrect negative Interest Posted amount on the Payoff Quote.

Also, for a current dated Payoff Quote, if the Pay Future Dues Timely flag is True, the value of Payoff Quote generated is calculated by the system assuming Pay Future Dues Timely flag as False.

Issue Description

In the Partial Application State of a loan contract where a Cap Reference Rate is defined, the system is allowing user to save a contract after changing the Cap Reference Rate to a value lower than the Interest Rate.

The system must not allow to save such a configuration and must display a message indicating that the Interest Rate is higher than Cap Reference Rate and that it needs to be changed.

Issue Description

While creating a loan contract that has negative Floor and Cap Reference Rates, the system is displaying a negative Interest Rate. After saving such a contract, however, the system is displaying a correct value of the Interest Rate.

The Floor or Cap Reference Rate can have a negative value, but the calculated Interest Rate on the loan must not display a negative value while creating the loan. It must display a value as zero if the calculated Interest Rate is a negative value.

Issue Description

When a loan is rescheduled to change the Cap Reference Rate or the Floor Reference Rate to a new value, the system will not change the Cap Reference Rate to the new value. For the Summer’22 release, the modification of Cap and Floor Reference Rates is not supported. However, these can be modified at the contract level when the contract is in the Partial Application status.

Issue Description

In a loan with Periodic Fees charged where Include In Schedules flag is True and Include in Dues flag is True, and where the Periodic Fee Frequency is different from the Payment Frequency (billing frequency), the system is generating incorrect schedules.

Only fees with Periodic Fee Amount Type as "Per Period Amount" can be used when Payment Frequency is different from Periodic Frequency. "Total Amount" can be used only when Periodic fees Frequency is same as the Billing Frequency.

Issue Description

When a loan contract has Periodic Fees with Include in Schedules flag as True, Periodic Fee Frequency as Billing frequency, Include in Dues flag as False, Add Fee to Bill Amount flag as True, then the system is displaying the following error message: “Billing Frequency is not supported for periodic fees to be included in schedules.” Such a contract should be saved, and schedules should show periodic fees on the same dates as billing dates.

The following table describes the objects added in the release of Loan Servicing and Marketplace.

The following table describes the objects modified in the release of Loan Servicing and Marketplace.