This is a living document, and its contents may be updated often. Make sure that you have the latest version for use.
This document provides information about the new and enhanced functionality in Loan Servicing and Marketplace , General Availability (GA) release. You can access the release notes of the previous releases from the Q2 Customer Portal.
The contents of this document are applicable to all the customers who have installed the Loan Servicing and Marketplace Q2 Loan Servicing and Q2 Marketplace Summer'22 version (3.9001.58) for the first time or have upgraded from an earlier version.
This document provides information on the following for the release:
The audience of this document includes business users, implementers, and system administrators.
These release notes may be updated after the first release. Any changes to the contents of these release notes are listed in the Change Record section.
Contact your Q2 Professional Services team or the Customer Success team for information on the package dependency and installation order of the packages required to install and set up the latest version of Loan Servicing and Marketplace.
For information on the upgrade steps, see release-related steps in the Q2 Product Upgrade Guide.
To view the batch jobs performance statistics for Loan Servicing and Marketplace without customizations under test conditions, see the Q2 Performance Benchmarking Guide.
This section briefly describes the new features and enhancements added in the release of Loan Servicing and Marketplace.
Note
For a detailed description of the new features and enhancements, see the following guides published over the Q2 Customer Portal:
-
Loan Servicing and Marketplace User Guide
-
Loan Servicing and Marketplace Administration Guide
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?
-
Reduction of time for EMI calculation – The time that the system would take for calculation of EMI and returning the amortization schedule would be substantially reduced. Though it might sound ambitious, we are aiming to be able to generate EMI and amort schedule for a 30-year monthly payment loan contract to less than 2 sec.
-
You would be able to manage loans with loan tenor of up to 1500 terms without the system landing into CPU timeout
Note
Please note that this enhancement would be built in a period of 3 releases considering that all possible known use cases of Financial Calculator are handled with the new design.
Scope of Summer’22
As part of the Summer’22 release, the following use cases have been enhanced with respect to FinCalc 4.0:
-
Simple Loan EMI calculation for given Principal, Fixed Rate, and Contract Term.
-
For payment frequencies (Daily, Weekly, Bi-Weekly, Semi Monthly, Monthly, Bi-Monthly, Quarterly, Semi-Annual, Annual, Semi-Monthly, semimonthly PD).
-
For all Time Counting methods (360/360, 365/365, Actual/Actual, Actual/366)
-
-
Loan Contract with Holiday Setup at Business Hours (Weekly Holidays and Bank Holidays) for all payment frequencies and Time counting methods.
-
Loan Contract with repayment plan provided by the user for few terms (Only Equal Monthly Installments Payment Type).
-
Loan Contract with Rate Schedules defined by the user
-
Reschedule action on all the above case of contracts.
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).
Note
For more details on the mathematics behind calculations, please refer to the user guide.
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.
Note
In the Summer’22 release, the prepayment penalty works as of now only if you are creating the payment transaction from UI.
Supporting this via payment files would be provided in the subsequent patch on Summer’22.
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:
Object |
Scenario |
---|---|
Loan Account |
Active Good Standing |
Loan Account |
Active Bad Standing |
Interest Posting |
enabled including billing frequency |
Interest Capitalization |
disabled/enabled |
Repayment Plan |
Only EMI |
Minimum Interest |
|
Periodic Fee |
Included In Schedules = false, including Billing Frequency |
Periodic Fee |
Included in Dues = true and add fee to bill amount = true |
Periodic Fee |
Included in Schedules = true |
Other Charges |
Include in dues = false. Existing charges. |
Charge Capitalization |
enabled |
EOD Interest |
enabled with single payment |
Prepayment penalty Fee - Old |
Prepayment Penalty period = 5 months and Prepayment Penalty Value = 50 |
Payment Spread - Custom |
Example: Fee1, Fee2, Fee3, Interest, Principal |
Payment Spread - Standard |
Fees, Interest, Principal |
Payment Application Order |
Spread wise |
Payment Application Order |
Date wise |
Without amortization schedules |
Amounts fetched from RSS and compute due dates using business hours |
Master Facility |
|
Protect Rebate |
Part of final payoff amount. |
Payoff quote API |
New API |
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:
-
Rate schedule
-
Prepayment penalty
-
Additional Interest Component
-
Flexible repayment plan - All repayment models
-
Advance interest
-
Periodic fee - Include in schedule, with billing frequency
-
Late charge
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
-
Let us say you create a loan on 01/04/2020.
-
After a month, on 01/05/2020, the Bill was for 200 and an IPT of 125 also got posted.
-
On 02/05/2020, say, you created a backdated transaction of 100 for the value date “20/04/2020”, which would further lower down the principal outstanding as on 20th April.
-
This trigger would basically reverse the IPT of 01/05/2020, which was for 125 and instead create a new IPT of a lower amount say 110.
-
In this scenario, you would find Adjusted Interest Amount as “15” and Adjusted Interest Type as “Credit”.
Example of Debit Type
-
Let us say you create a loan on 01/04/2020.
-
You made an adhoc payment (LPT-1) of 100 on 20/04/2020
-
After a month on 01/05/2020, the bill was for 200 and an IPT of 110 also got posted.
-
On 02/05/2020, say, you reversed the LPT-1, which would increase the principal outstanding as on 20th Apr.
-
This trigger would basically reverse the IPT of 01/05/2020, which was for 110 and instead create a new IPT of a higher amount say 125.
-
In this scenario, you would find the Adjusted Interest Amount as “15” and Adjusted Interest Type as “Debit”.
This section describes the issues fixed in the Summer'22 release of Q2 Loan Servicing.
Pre-Paid Fees that are not set to be added to the Loan Amount are being added to the Loan Amount (Jira ID: PDRFF-534/ND-5457)
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.
Note
When an Interest Waiver is made, the system creates an LPT and an OLT for it.
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:
-
Include In Dues
-
Include In Schedules
-
Enable Fee Capitalization
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:
-
Include in Dues
-
Add Fee To Bill Amount
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.
Rescheduling on Loan Balance of Interest Only loans with Advance Interest enabled is resulting in a higher bill amount (Jira ID: PDRFF-913/ND- 5439)
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.
Bill generated for payoff amount instead of EMI when deposit amount is close to loan balance (Jira ID: PDRFF-924/ND-5484)
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.
Early termination fee with Time of Charge as Minimum Interest is not getting generated for protect-enabled loans (Jira ID: PDRFF-925/ND-5447)
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.
Early termination fee amount with the Time of Charge as Minimum interest is generated and charged incorrectly when the payment is made by creating multiple LPTs simultaneously for multiple contracts (Jira ID: PDRFF- 929/ND-5488)
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.
Interest Remaining is not getting calculated correctly for future dated quotes (Jira ID: PDRFF-936/ND-5443)
Issue Description
Interest Remaining amount and Interest posted amount for future dated calculation is not taking into account the following scenarios:
-
Scenario 1:
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:
Current System Date |
Future dated payoff quote on Payoff Date |
---|---|
February 8 |
February 15 |
February 10 |
February 15 |
-
Issue 1: Total Payoff Amount for the two quotes are not the same.
-
Issue 2: Interest Remaining is not getting calculated correctly for the second quote. It is considering only 5 days, from Transaction Date to Payoff Date. It should calculate the Interest from the Last Interest Posting Date to the Payoff Date.
-
Issue 3: The Total Payoff Amount is not getting calculated correctly for both the quotes.
-
Scenario 2: Created another Future dated Payoff Quote with Transaction Date as February 8 and Payoff Date as March 10 (Next Due Date = March 5, 2021)
-
Issue 1: Interest Remaining and Interest Posted are not getting updated if the entered Payoff Date is after the next billing cycle.
-
Scenario 3: Payoff quote Issues in a Master Facility loan contract
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.
-
Issue 1: Generate a quote with payoff date as April 11, 2021, which is before the Next Interest Posting Date in the first child loan.
-
Actual result: Payoff Date in quote is updated to April 12, 2021, even though the entered payoff date while creating quote was April 11, 2021, and ‘Interest Posted’ and ‘Interest Remaining’ values are not calculated correctly.
-
Expected result: Payoff quote should include principal, fee, interest and additional interest dues across all the child loans and Master Facility where ‘Interest Posted’ would be sum of unpaid previous interest posted amount and interest from last IPT date to next IPT date(future) across the child loans and ‘Interest Remaining’ in quote would be the interest from IPT till payoff date across child loans and then Additional Interest Remaining would be the sum of unpaid additional interest posted and interest amount from last IPT till payoff date.
-
Issue 2: Generate a quote with payoff date as April 12, 2021, which is on the ‘Next Interest Posting Date’ in the first child loan.
-
Actual Result: ‘Interest Posted’ and ‘Interest Remaining’ values are not calculated correctly.
-
Expected result: Payoff quote should include principal, fee, Interest & additional Interest dues across all the child loans and Master Facility where ‘Interest Posted’ would be sum of unpaid previous interest posted amount and interest from last IPT date to next IPT date(future) across the child loans and ‘Interest Remaining’ under quote would be the interest from IPT till payoff date across child loans and then Additional Interest Remaining would be the sum of unpaid additional interest posted and interest amount from last IPT till payoff date.
-
Issue 3: Generate a quote with payoff date as April 12, 2021, which falls after ‘Next Interest Posting Date’ in the first child loan.
-
Actual result: ‘Interest Posted’ and ‘Interest Remaining’ values are not calculated correctly.
-
Expected result: Payoff quote should include principal, fee, Interest & additional Interest dues across all the child loans and Master Facility where ‘Interest Posted’ would be sum of unpaid previous interest posted amount and interest from last IPT date to next IPT date(future) across the child loans and ‘Interest Remaining’ under quote would be the interest from IPT date till payoff date across child loans and then Additional Interest Remaining would be the sum of unpaid additional interest posted and interest amount from last IPT till payoff date.
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.
The total Interest Accrued and Interest Posted in a Master Facility after an early payoff are not the same (Jira ID: PDRFF-815/ND-5469)
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.
System is asking to pay the payoff tolerance amount while performing a manual loan closure of a revolving loan (Jira ID: PDRFF-879/ND-5479)
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.
Future dated payoff quotes for a capitalization-enabled contract are not getting generated correctly (Jira ID: PDRFF-941/ND-5445)
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.
The system is throwing an exception while trying to generate a Payoff Quote (Jira ID: PDRFF-812/ND-5448)
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:
Sequence |
Floating Rate Index |
Interest Rate |
Margin Rate |
Start Date |
---|---|---|---|---|
1 |
FRI1 |
6.00 |
0.00 |
2/2/2013 |
2 |
FRI1 |
7.00 |
0.00 |
3/1/2013 |
3 |
FRI2 |
8.00 |
0.00 |
3/1/2013 |
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:
Sequence |
Floating Rate Index |
Interest Rate |
Margin Rate |
Start Date |
---|---|---|---|---|
1 |
FRI1 |
6.00 |
0.00 |
2/2/2013 |
2 |
FRI1 |
7.00 |
0.00 |
3/1/2013 |
3 |
FRI2 |
7.50 |
0.00 |
3/1/2013 |
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.
The system is displaying an incorrect error message while rescheduling a loan with incorrect details in the Flexible Repayment Plan (Jira ID: PDRFF-391/ND- 5493/PD-1008)
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.”
Note
Min Financed Amount is the minimum Loan Amount that must be defined in a loan. This field is set while creating the lending product.
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:
-
Create AssignThreadNumToLoanContracts class in the ORG.
Deploy the following class from the UnmanagedCustomerScripts folder of v_2.7016_Pheonix_Patch_New_Branch in neon-1 repository:
-
AssignThreadNumToLoanContracts.cls (https://github.com/cloudlending/neon- 1/blob/v_2.7016_Pheonix_Patch_New_Branch/UnmanagedCustomerScripts/AssignThrea dNumToLoanContracts.cls)
-
Run the following script in the Developer Console:
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:
-
SELECT count(Id) FROM loan Loan_Account c where loan Thread_number c=1
-
SELECT count(Id) FROM loan Loan_Account c where loan Thread_number c=2
-
SELECT count(Id) FROM loan Loan_Account c where loan Thread_number c=3
-
SELECT count(Id) FROM loan Loan_Account c where loan Thread_number c=4
-
SELECT count(Id) FROM loan Loan_Account c where loan Thread_number c=5
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.
The system is displaying an incorrect Current Loan Balance on the LTS of Excess Payoff IPT after the final payoff (Jira ID: PDRFF-754/ND-5501)
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.
Note
When a payoff is made before the maturity date, the Excess Payoff IPTs are created for the accrued interest till the payoff date, and regular IPTs are created as per the schedule before the payoff date.
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.
Note
-
Current Loan Balance is the current loan balance after a transaction is made.
-
Consolidated Loan Balance is captured after the payoff transaction is made, and it is calculated as follows:
If the total deposit amount is not null and has some value, then Consolidated Loan Balance = Loan Balance – total deposit amount. Else, it is the same as Loan Balance.
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.
Note
As per the fix made, the values in the LTS record for Excess payoff IPT and Additional Interest Excess Payoff IPT are saved as per the state of the loan that is immediately before the Payoff LPT is created because from the user’s perspective, an IPT cannot be created on a zero Loan Balance. So, logically, Consolidated Loan Balance cannot have a zero value in the LTS of the Excess Payoff IPT. It must appear zero on the LTS of Payoff LPT only. Hence, this is the exception where values on LTS record will populate as per the business logic, not from LTS generic code perspective. As per LTS standard approach, we store the values after that particular transaction creation.
Maximum view state error message seen while previewing the rescheduling of a loan (Jira ID: PDRFF-834/PDRFF-662/ND-5519)
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.
-
First Page
-
Next Page
-
Previous Page
-
Last 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:
-
Next Page
-
Last Page
If the system is on the last page, then only the following buttons are visible on the page:
-
First Page
-
Previous 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.
The custom version of the internal EMI calculator is unable to come up with a payment amount when there is an additional payment schedule (Jira ID: PD-1009)
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.
Discrepancy in the Available Amount field value due to no lock on the object (Jira ID: PDRFF-669/ND-5516)
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:
-
Investor payout and its reversal
-
Investment order trigger (upon funding a loan application)
-
IFT Clearing trigger (upon deposit/withdrawal of funds)
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.
Note
Every object in Java has a unique lock. If a thread wants to execute a synchronized method on a given object, first it has to get a lock of that object. Once the thread has got the lock then it is allowed to execute any synchronized method on that object. Once the method execution completes, automatically, the thread releases the lock. In Apex, when an sObject record is locked, no other client or user is allowed to make updates either through code or the Salesforce user interface. The client locking the records can perform logic on the records and make updates with the guarantee that the locked records won’t be changed by another client during the lock period. In Apex, you can use the FOR UPDATE to lock sObject records, while they’re being updated, in order to prevent race conditions and other thread safety problems.
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.)
Note
When Maintain Delinquency flag is True, while rescheduling, the interest must be calculated on Schedule Balance, and not the Principal Balance because Principal Balance is higher.
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.
Note
The rate on deposit is the same as the contract interest rate.
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:
-
For non-delinquent loans, the sum of Interest Remaining and the interest from the LAD to rescheduling date is used to determine the Interest Accrued till Reschedule Date for present cycle.
-
For delinquent loans, the interest accrued till Reschedule Date is calculated on Schedule Balance.
Note
The term, Interest Accrued Till Reschedule Date, is basically the interest calculated till the rescheduling date for the current billing cycle.
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:
Date |
Actions and Remarks |
---|---|
March 1 |
Loan is delinquent |
March 8 |
Rate change from 10% to 12% |
March 10 |
Rescheduling |
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:
-
Interest of 10% calculated from 2nd March to 8th March on the Schedule Balance
-
Interest of 12% calculated from 9th March to 11th March on the Schedule Balance. When the loan is a non-IPT loan
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.
The Last Rate Change Date field is not getting updated with the floating index rate change (Jira ID: ND-5475)
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:
From Date |
To Date |
Interest Rate |
---|---|---|
March 2, 2013 |
March 15, 2013 |
5% |
March 16, 2013 |
March 30, 2013 |
6% |
March 31, 2013 |
April 15, 2013 |
7% |
April 16, 2013 |
NA |
8% |
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:
-
Payment Amount displayed for a contract does not include the additional interest billed under that contract.
-
For Master Facility loan contracts, payment amount is always populated as zero because the billed amount only includes additional interest for Master Facility contracts.
-
There is no option available to enter additional interest amount when Spread Manually is selected.
-
When the total amount is entered at account and saved, the system displays a message “The total amount has been adjusted to sum of all individual payments”, but payment transactions are not created under any contract.
-
The Posted checkbox for a contract is not getting selected even after payment is applied for that contract.
-
Payment reversal through Reverse button available in the Consolidated Loan Payment page is not working.
-
Payment amount is still displayed for a contract even after clearing the payments.
Resolution
Following are the fixes made in this patch:
-
Reversal is not supported on Consolidated Loan Payment page. Instead, the individual LPTs need be reversed. Thus, the reversal functionality in Consolidated Loan Payment is deprecated as part of this fix. Only reversal at individual LPT level is now supported.
-
UI now includes proper validations and warnings.
-
Posted flag is either removed or renamed based on the existing behavior.
-
Last unpaid due date is now displayed on the page and the contracts are sorted based on that date.
-
Field names like Payment Amount and Amount to Current are now renamed to Amount and Total Due Amount for better clarity.
-
Auto payment spread across contracts are now supported.
-
Cash in the Default Payment Mode is now renamed to Bank Transfer as consolidated payments are only through bank transfer.
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:
-
#IAND - Interest Accrued Not Due
-
#IPE - Interest Posting Enabled
-
#CE - Capitalization Enabled.
The system is not allowing to change the Additional Interest rate to 0% (Jira ID: PDRFF-1036/ND-5533)
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.
Maximum view state error message seen when the Manage Accounting Events page is getting loaded (Jira ID: PDRFF-1056/ND-5565)
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:
-
The following four buttons are added to each page:
-
First Page
-
Next Page
-
Previous Page
-
Last Page
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:
-
Next Page
-
Last Page
If the system is on the last page, then only the following buttons are visible on the page:
-
First Page
-
Previous Page
If the records are less than 20, then all the four buttons are not visible on the page.
-
A flexibility is added to move across pages by the addition of a field called Go To Page where you can enter the page number that you want to go to.
-
The following warning message is added 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.
-
A buffer wait time has been added after changing a record on a page to be able to retain that change. Otherwise, if, after making a change to a record, and then you immediately move to another record on the same page, then the change in the previous record would not be retained. This buffer wait time is provided with the help of a window that displays “Please Wait” till the system retains that change on that page.
Write-off recovery payment is not following the Default Write Off Recovery Spread (Jira ID: PDRFF-434/ND-5590)
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.
Note
When we create any write-off recovery payments, the Payment Spread does not depend on the loan's Payment Application Order (Date/spread) selected. It follows the Default Write Off Recovery Spread. For a written off loan, the payment is used to satisfy first the complete outstanding principal, and then the interest, and then the fees.
Example
Let us say there is a loan contract with the following bills and with the following payment split for each cycle:
Cycle |
Bill |
Due Amount Split |
||
---|---|---|---|---|
|
||||
1 |
B1 |
|
||
2 |
B2 |
|
||
3 |
B3 |
|
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.
Note
When you create an LPT for a write-off recovery payment, a Payment Type of Write-Off Recovery is created. The Write off Recovery Payment checkbox is selected if the payment is being recovered against a written off loan. For a written off loan, the payment is used to satisfy the outstanding principal first, and then the interest and then fees.
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.
Interest is not getting accrued for Single-Payment frequency in an FAMZ loan (Jira ID: PDRFF-934/ND-5587)
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.
Note
If the job is run with batch size 200, which means if we have a contract that is not a Single- Payment frequency in the InterestPostingAMZ scope, then the system is working fine.
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:
Contract Start Date |
October 27, 2021 |
First Payment Date |
November 27, 2021 |
Frequency and IPT Frequency |
Single-Payment |
Term |
1 |
Interest Period Calculation |
Include Start Date |
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.
Interest Per Diem on the Payoff Quote should be based on the Principal Balance owing on the day of payout when Pay Future Dues Timely is True (Jira ID: PDRFF-917/ND-5551)
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.
Bank accounts from all customers are available to select from while doing a refund for a reversed LPT (Jira ID: PDRFF-957/ND-5568)
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.
LPT is not getting created when the Deposit balance is greater than or equal to the Loan Balance (Jira ID: PDRFF-760/ND-5593)
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.
Note
Payoff amount calculation may or may not exclude the sum of Deposit amounts based on a flag named Adjust Deposit Amount in Payoff. If this flag is true, then the payoff amount is computed by reducing the deposit amount from the payoff amount. Payoff amount becomes zero if the deposit balance is enough to pay the loan.
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.
Loan Transaction Summary is not recording or displaying the correct balance (Jira ID: PDRFF-765/ND-5583)
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:
-
Loan Transaction Summaries enabled
-
Interest Posting enabled
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:
Daily Interest accrual Time |
EOD |
Accrual Type |
Accrual To Date |
Funding in Tranches |
False |
Interest Posting Frequency for Additional Interest |
Billing Frequency |
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.
-
The first bill amount does not include the Additional Interest Component amount.
-
The second bill amount reflect incorrect Additional Interest Component amount. Expected Result
-
The first Interest Posting Date for AIC should not fall on a holiday and should be in sync with the
regular interest when the frequency is same.
-
The AIC should reflect the correct amount in the bills generated.
Note
This issue does not occur on loans when Funding in Tranches is enabled.
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.
Note
Borrowers may specify a duration in the contract term where they pay only the interest, called the Interest Only period. The principal + interest payments start after this period.
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.
Interest part is missing in the Investor Loan Transactions when a payoff or a bulk payment is made (Jira ID: PDRFF-920/ND-5564)
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.
Note
This job is run independently. This accrues interest for all investment orders on daily basis. It chains Investor Payout Job to get executed as next job in chain. The Investor Payout Job separates the interest accrual from the payout job, and it is run independently. The interest and principal amounts are paid out to specific investors. Scheduling an Investment Order Interest Accrual Job explicitly is a prerequisite for this job.
Example
Let us say we perform the following steps:
-
Create a flexible AMZ loan with Interest Posting enabled.
-
Move the system date by a few days then generate a Payoff Quote.
-
Make a Payoff (or a bulk payment) and clear it.
-
Now run the Investor Payout Job.
-
Check the Principal and Interest amounts on the Investor Loan Transactions (ILTs) created for the LPT.
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.
Prepayment bill is getting generated upon partial payment within the Pre-Bill Days (Jira ID: PDRFF-923/ND-5645)
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.
Note
Prepayment bill is a type of bill which is generated if the user pays a future installment in FAMZ types of loans. For each future installment, there is a bill that gets 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:
-
Create an FAMZ loan contract on May 27, 2021, with the following values:
Field |
Value |
---|---|
Pre-Bill Days |
5 |
Loan Amount |
$5,000 |
Terms |
6 |
-
Disburse the loan.
-
Now move to June 24, 2021, (through SOD/EOD job) which falls within the Pre-Bill Days defined, so that a bill gets generated. Let us say the bill generated is of the amount $838.29.
Note
Pre-Bill Days is the number of working days before the due date when the bill is to be generated.
-
Now create a partial payment of $500 and provide the Installment date as Due date which is June 27, 2021.
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.)
-
Create another partial payment to satisfy the Due Amount. The Payment Satisfied flag of the bill generated is not getting marked as True even when the payment amount is greater than the Due Amount.
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.
Updating of charges is failing with an error in the Charge Trigger after accounting file is generated for the charges (Jira ID: ND-5458)
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:
-
Fees_Remaining_c
-
Total_Due_Chargesc
-
Pay_Off_Amount_As_Of_Todayc
-
Fees_Paid_c .
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:
-
Waive c
-
Original_Amount c
-
Total_Amount_Due c
-
Principal_Due c
-
Interest_Due c
-
Calculated_Interest3 c
-
Tax_Remaining c
PDF Download is not working for Amortization Schedule in the Loan Quick Menu (Jira ID: PDRFF-994/ND-5559)
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:
-
Open Google Chrome browser.
-
Click the three vertical dots menu and then click Settings.
-
On Chrome Settings, click Privacy and security in the left pane.
-
Click Site Settings.
-
Scroll down and expand Additional Content Settings
-
Click PDF Documents.
-
In the Default behavior, select Download PDFs.
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.
Note
The contract status Active - Marked for Closure is provided to identify Protect Enabled loans that are ready for closure or are being paid off. The Loan Closure job that runs as part of the Start Of Day job picks up these contracts and processes them for closure.
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.
Note
Additional Information:
There may be situations where a borrower repays the loan early or makes a single payment to pay-off the loan. In such cases, the contract is marked for closure based on the payment if:
-
The payment received from the borrower is equal to the payoff amount for that day, or,
-
The sum of the payment amount + any rebate offered to the borrower on the protect fee falls within the payoff tolerance specified for the contract.
-
If any of the conditions are met, when you save the payment transaction, the contract status changes to Active - Marked for Closure. In the next run of the SOD job, the Loan Closure job processes all such contracts and creates the following LPTs under Other Transactions:
-
Rebate LPT: This transaction calculates the rebate payable to investors as per the protect split defined for the contract, and if the Is Investor Rebated at Payoff, or the Is Investor Rebated On Refinance, as applicable, is selected. This transaction is created with the same payment mode as that of the last transaction on the contract, and with the Rebate Payment check box selected. When the Investor Payout job runs, investors are paid out based on their investment share, from this amount.
-
Closure LPT: This transaction is created to adjust the difference in the outstanding amount and the borrower payment, that is attributable to the payoff tolerance. This transaction is created with the same payment mode as that of the last transaction on the contract, and with the Closure Tolerance Payment check box selected.
Error when clicking Cancel/Stop ACH through Loan Quick Menu in the contract (Jira ID: PDRFF-1104/ND-5596)
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.
Upon rescheduling a loan by using the Reschedule button on the UI to change the Rate Schedule or change the Flexible Repayment Plan, the system is not updating the Amortization Schedule in the preview (Jira ID: PDRFF-1155/ND- 5605)
Issue Description
There are the following two issues observed while previewing the rescheduled loan after rescheduling it via the Reschedule button:
-
If a loan is rescheduled to change the Rate Schedule on the UI by clicking the Reschedule button in the CL Contract Details page, then on clicking Preview, the system is not considering the updated Rate Schedule and the Rate schedule is not changing to include the new rate schedule, and a new Amortization Schedule is not getting generated.
-
If a loan is rescheduled to add a Flexible Repayment Plan using the Reschedule button on the UI, then on clicking Preview, the system is not generating a new Amortization Schedule in the preview.
Example on Rate Schedule
Let us perform the following steps:
-
Create a Floating Rate Index with the following two Floating Rates:
Start Date |
End Date |
Interest Rate |
March 1, 2013 |
May 31, 2013 |
12% |
June 1, 2013 |
August 30, 2013 |
30% |
-
Then let us create a Loan product with Interest Type as Floating Rate.
-
Now, move the system date to March 1, 2013.
-
Create the loan contract with preceding loan product with Rate Schedule that consists of the first-rate schedule as the Floating Rate and second as Fixed Rate of Interest Rate 13% with Start Date as September 1, 2013.
-
Approve and disburse the loan.
-
Move the system to April 1, 2013, then May 1, 2013, then June 1, 2013.
-
Go to Reschedule page and change the Rate Schedule to add another fixed rate schedule from October 1, 2013, with Interest rate of 21%.
-
Click Preview.
The following results are expected:
-
The Rate Schedule should be changed to include the new rate schedule from October 1, 2013.
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.
Note
This issue is not seen while using the Reschedule API. It is only seen while using the UI.
Issue Description
Upon making a payment reversal or a backdated reversal, the following issues are seen:
-
Reversed flag in Interest Postings Transactions is not enabled; hence, accounting entry for Interest Reversal is not getting generated.
-
If Payoff Quotes are generated after Payment Reversal, calculations for the Interest Remaining and Additional Interest Remaining fields seem inaccurate.
-
The Payoff Amount in Payoff Quotes generated before making any payment and after reversal of that payment is different.
-
Payoff Amount in Today’s Payoff, Loan Payoff, and Payoff Quote is different on the day of Payment Reversal.
-
After the day of Payment Reversal, the Payoff Amount in Today’s Payoff and Payoff Quote is the same, although the Loan Payoff amount is different.
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.
This section briefly describes known issues known in the release of Loan Servicing and Marketplace.
Interest Posted amount is a negative value on the Payoff Quote when the Payoff Quote is created on a posting date with Pay Future Dues Timely flag as True (Jira ID: ND-5699)
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.
System is allowing user to save a loan contract with a Cap Reference Rate lower than the Interest Rate (Jira ID: ND-5711)
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.
Note
Cap Reference Rate is the maximum rate that is applied if the Floating Index Rate falls above the Cap Reference Rate. It is the maximum interest rate that a lender can charge a borrower when negotiating a loan.
While creating a loan contract, system is displaying a negative Interest Rate value when Floor and Cap Reference Rates are negative (Jira ID: ND-5704)
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.
Rescheduling to change the Cap and Floor Reference Rates is not supported for the Summer’22 release (Jira ID: ND-5707)
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.
Repayment schedule is generated with negative balances when Payment Frequency and Periodic Fee Frequency are different from each other (Jira ID: ND-5675)
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.
Billing Frequency is not supported for periodic fees that are to be included in schedules (Jira ID: ND-5681)
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.
This section briefly describes the new and modified objects in the release of Loan Servicing and Marketplace.
Note
For more details on the added and modified objects, see Loan Servicing and Marketplace Data Dictionaries Guide.
The following table describes the objects added in the release of Loan Servicing and Marketplace.
Object Name |
Description |
---|---|
Prepayment Penalty Configuration |
This object is added in the Summer'22 release as part of the Prepayment Penalty feature to configure a Fee of type Prepayment Penalty. This object stores the Prepayment Penalty Configurations for the Prepayment Penalty Fees. |
Prepayment Penalty Slab |
This object is added in the Summer'22 release as part of the Prepayment Penalty feature to configure a Fee of type Prepayment Penalty. This object stores the Prepayment Penalty Slabs for the Prepayment Penalty Configurations. |
The following table describes the objects modified in the release of Loan Servicing and Marketplace.
Object Name |
Field Name |
Description |
---|---|---|
Loan Transaction Summary |
Adjusted Interest Amount |
This new field stores the adjusted Interest during Recreation of IPTs. It displays the difference between the old IPT and new IPT being re-created because of backdated transaction or reversals. |
Adjusted Interest Type |
This new field stores the type of transaction during the recreation of IPTs. (Credit/Debit). It displays the following values: • Credit: if the New IPT amount is lesser than the old IPT amount. • Debit: if the New IPT amount is greater than the old IPT amount. |
|
Disbursal Transaction Distribution |
This new field maintains a look up to the respective DTD records of LDT for which LTS is created. |
|
CL Contract |
Cap Reference Rate |
This new field is intended for the user to define the agreed upper limit of the reference rate, on which the interest can be accrued on a loan. |
Floor Reference Rate |
This new field is intended for the user to define the agreed lower limit of the reference rate, on which the interest can be accrued on a loan. |
|
Financial Calculator Version |
This new field stores the calculator version to be used for calculations. The value of this field gets defaulted from the Lending Product, and it can be overridden at the contract level to call the specific calculator required. The values that you can enter are:
|
|
Lending Product |
Cap Reference Rate |
This new field is intended for the user to define the agreed upper limit of the reference rate, on which the interest can be accrued on a loan. |
Floor Reference Rate |
This new field is intended for the user to define the agreed lower limit of the reference rate, on which the interest can be accrued on a loan. |
|
Financial Calculator Version |
This new field stores the calculator version to be used for calculations. The value of this field gets defaulted from the Lending Product, and it can be overridden at the contract level to call the specific calculator required. The values that you can enter are:
Financial Calculator Version 4 is the new version introduced in the Summer'22 release. |
|
Fee |
Time of charge |
This field is updated to include a new picklist value named Prepayment Penalty. When this picklist value is selected, a Prepayment Penalty fee is automatically applied to a contract if a loan is paid off with partial or full payoff as per slabs defined at the product level based on the completed tenure of the deal. |
Prepayment Penalty Type |
This new field stores the type of Prepayment Penalty slab as per which the Prepayment Penalty fee is applied to the contract. The values of this picklist are:
|
|
Loan Payment Transaction |
Prepayment Penalty Amount |
This new field stores the Prepayment Penalty Amount charged as part of the transaction. This amount is included in the Transaction Amount. |
Holiday Treatment Setup |
Apply Holiday Treatment On |
This picklist field is updated to include a new picklist value named Rate Schedule. |
Periodic Fee Setup |
Include In Schedules |
This new picklist field indicates if the Periodic Fee should be applied only in the "Principal And Interest" payment period of the repayment schedule or all the periods of the schedule. The picklist values are:
|
Payoff Quote |
Loan Balance |
This new field stores the loan balance till the payoff date. |
Minimum Interest Amount |
This new field stores the minimum interest charge that will be created at the time of payoff. This is the remaining interest amount to charge. |
|
This section briefly describes the new and modified APIs in the release of Loan Servicing and Marketplace.
Note
For more details on the added or modified APIs, see Loan Servicing and Marketplace REST APIs Guide.
REST API |
Method Signature |
Description |
---|---|---|
v1/loanAccounts/payoff / |
/services/apexrest/platinum_pee r/v1/loanAccounts/payoff/id |
This API is enhanced to support future dated payoff quote by the addition of the following new parameters: • payoffQuoteName • applyFuturePayments • generateQuoteForEntireFacility |
This section briefly describes the global methods that are added or modified in the release of Loan Servicing and Marketplace.
Note
For more details on the added and modified global methods, see Loan Servicing and Marketplace Global Methods Guide.
Global Method Name |
Method Signature |
Method Parameter |
Description |
---|---|---|---|
previewPayoffQuote |
PayOff_Quote c previewPayoffQuote (PayOff_Quote c pq) |
payoffquote |
This API is used to preview the payoff quote amount. The payoff quote of the type of PayOff_Quote c object is passed as an input parameter to be previewed. |
Follow this section for the details on the issues fixed in the patches on the release.
The system is not generating a repayment schedule after disbursing a loan using a custom logic (Jira ID: PDRFF-3121/ND-8352)
Issue Description
The system is not generating a repayment schedule after a disbursing a loan using a custom logic and it is throwing the following error message in the logs: "System.DmlException: Update failed. First exception on row 0; first error: MISSING_ARGUMENT, Id not specified in an update call:"
This is because the user is using a custom logic for disbursement and creation of charge, due to which the Periodic Fee Setup was getting stored without providing a ID, which was causing the exception for a new Periodic Fee Setup.
Resolution
The issue is now resolved by upserting the Periodic Fee Setup field. Now, the system will create an ID for both new records and existing modified records.
On adding a pre-paid fee while disbursing a refinanced contract, the system is creating duplicate distribution of Refinanced Distribution Type (Jira ID: PDRFF-3269/ND-8334)
Issue Description
On adding a pre-paid fee while disbursing a refinanced contract, the system is creating duplicate distribution of Refinanced Distribution Type and is displaying the following error message:
Note
CL013435: Sum of distributions amount is not equal to disbursal transaction amount.
On regenerating distributions, the system is adding one more duplicate distribution of Refinanced Distribution Type to the list.
Example to understand the issue
-
Create a pre-paid fee with $0 amount and add it to the fee set.
-
Create a loan contract and run through one or two payment cycles.
-
Create a new refinanced contract with the additional loan amount of $5,000 and approve the same.
-
Now, while disbursing the contract, add the Pre-Paid Fees and add some value in the Amount field and then select Add prepaid Fee.
-
The system creates a duplicate distribution of Refinanced Distribution Type, which is not removable until the page is refreshed. On selecting Regenerate Distributions, the system is creating one more distribution of Refinanced Distribution Type.
-
On selecting validate, the system is displaying the following error message:
Note
CL013435: Sum of distributions amount is not equal to disbursal transaction amount.
Resolution
The issue is now fixed and the system is not is creating duplicate distribution of Refinanced Distribution Type.
On attempting to add a Periodic Fee to an existing loan contract, the system is displaying a query exception message (Jira ID: PDRFF-3127/ND-8327)
Issue Description
On attempting to add a periodic fee through the Periodic Fee Setup on an existing loan contract, the system is displaying a query exception message:
Note
Subject row was retrieved via SOQL without querying the requested field : loan_Loan_Accountc.loan_Pmt_Amt_Cur_c.
Note
If the Periodic Fee Setup is added while creating a new contract, the system is not displaying a Query exception message
Example to understand the issue
-
Select any contract with status Active-Good Standing or Active-Bad Standing.
-
Scroll down and select the Periodic Fee Setup.
-
Select Add and through look-up select Insurance Premium & Tax periodic fee.
-
The system displays the following Query exception message:
Note
Subject row was retrieved via SOQL without querying the requested field : loan_Loan_Accountc.loan_Pmt_Amt_Cur_c.
Resolution
The issue is now fixed by modifying the logic and on attempting to add a Periodic Fee to an existing loan contract the system is not displaying any Query exception message.
Note
Similar issue is also fixed for the following values of the Fee Calculation Method field:
-
Amount Calculated as % of Loan Amount
-
Amount Calculated as % of Payment amount
-
Amount Calculated as % of Disbursement Amount
-
Amount Calculated as % of Payoff Amount
-
Amount Calculated as % of Principal Balance
After a backdated payment on the Due Date, the system is not satisfying the bill and is reflecting the total payment in the Reserve Amount for Next Due field (Jira ID: PDRFF-3072/ND-8125)
Issue Description
After a backdated payment on the Due Date, the system is not satisfying the bill and the amount is incorrectly reflecting in the Reserve Amount for Next Due field to be used for the Next Due Date. Instead, after a backdated LPT with transaction date lesser than Bill's Due Date, the system must pay the bills immediately and only the unused amount must reside in Reserve Amount for Next Due field.
Example to understand the issue after the fix
-
Set the current system date to March 01, 2013, and create a loan contract with the following values:
-
Loan Amount = $10,000
-
Rate = 10%
-
Terms = 10
-
Payment Freq = Monthly
-
Interest Posting Freq = Billing Frequency
-
Capitalization = True
-
Time Counting Method = Month and Days
-
Payment Application Mode = Future Dues
-
Pre Bill Days = 0 (default)
-
-
Approve and disburse the loan.
-
Move current system date April 01, 2013. the values are updated as follows:
-
Bill-1is generated for the amount of $1,046.40
-
IPT-1 is created for the amount of $83.33.
-
-
Create a backdated LPT-1 of amount $2,046.40 for the transaction date of March 25, 2013. IPT-1 gets reversed and LPT1 is used to satisfy the Principal. The values are updated as follows:
-
Last Accrual Date = March 25, 2013
-
Interest Posted = $0
-
Interest Remaining = $66.67
-
Interest Accrued = $13.26
-
Loan Balance = $7953.60
-
-
Before the fix:
-
System updates the Reserve Amount for Next Due = $2,046.40
-
No amount is used to satisfy the Bill although there is a Bill generated for April 01, 2013.
After the fix:
-
The system uses the backdated LPT to satisfy the Bill-1 and unused amount is moved to Reserve Amount not Due field.
-
-
Move current system date to the Next Due Date, i.e, May 01, 2013, the values are updated as follows:
-
Interest Posted = $79.93
-
Loan Balance = $8,033.53
-
Principal Remaining = $7,953.60
-
Bill 2 receives Payment Amount of $1,000 from Reserve Amount for Next Due field.
-
Reserve Amount for Next Due is updated to $0.
-
-
The system is not generating IPT-2 and is updating the Next Interest Posting Date correctly as June 01, 2013.
Resolution
The issue is now fixed and the system is satisfying the Bill correctly for a backdated payment on the Due Date.
Loan Balance and other balances of the charge record are not matching with the balances in Loan Transaction Summary despite applying capitalization (Jira ID: PDRFF-2622/ND-7264)
Issue Description
When a charge is capitalized in a loan, the system is updating the loan balance and the payoff balance correctly in the charge records, but it is not updating the Current Loan Balance and the Current Payoff Balance correctly in the Loan Transaction Summary. The balances of the charge record and the Loan Transaction Summary must match.
Example to understand the issue
-
Create a Lending Product with the following values:
-
Is Fee Set = $100 (Fixed)
-
Enable Fee Capitalization = True
-
Add this Fee Set to product and set Create Summaries = True.
-
-
Set the Current System Date to March 01, 2013, and create a loan contract with the following values, and then approve and disburse the loan:
-
Loan Amount = $10,000
-
Interest Rate = 10%
-
Terms = 10
-
Time Counting Method = Month And Days
-
Payment Frequency = Monthly
-
Interest Posting Frequency = Monthly
-
Fee Capitalization = True
-
-
Move the Current System Date to April 1, 2013.
The system creates IPT-1 and Bill-1.
-
Move the Current System Date to April 2, 2013.
The system creates a charge with the following values:
-
Current Loan Balance = $10,183.33
-
Current Payoff Balance = $10,183.33
-
-
The values in Loan Transaction Summary are displayed as follows:
-
Current Loan Balance = $10,083.33 (Incorrect)
-
Current Payoff Balance = $10,083.33 (Incorrect)
-
Resolution
This issue is now fixed and the logic is modified such that the Current Loan Balance and the Current Payoff Balance are displayed correctly on the Loan Transaction Summary.
On rescheduling loan immediately after disbursal without modifying any parameter, the preview displays an incorrect Amortization schedule and an incorrect balloon payment (nth payment) amount incorrectly (Jira ID: PDRFF-3183/ND-8102)
Issue Description
On rescheduling loan immediately after disbursal without modifying any parameter, the preview displays an incorrect Amortization schedule and an incorrect balloon payment.
Example to understand the issue
-
Set the current system date to March 01, 2013, and create a loan contract with the following values:
-
Loan Amount = $1,00,000
-
Rate = 12%
-
Terms = 12
-
Time Counting Method = Actual Days
-
Interest Posting Frequency = Billing Frequency
-
Interest Calculation Method = Flexible Repayment
-
Balloon Payment Type = Balloon Amount Including Only Principal,
-
Balloon Payment = $10,000
-
Payment Application Mode = Current Dues
-
Delinquency Basis = Schedule Balance
-
Funding in Tranches = True
-
Revolving = True
-
Draw Billing Method = Interest Only
-
-
Approve and disburse the loan.
The Current Payment Amount = $8,099.10
In Amortization Schedule the values are updated as follows:
-
Last record has Due Date = March 01, 2014
-
Due Amount = $18,099.10
-
Due Principal = $17,934.07
-
Due Interest = $165.09
-
Due Fee = $0
-
Balance = $0
-
-
Go to the rescheduling page, and without modifying any value, select Preview. Since none of the parameters have changed on the rescheduling page the amortization schedule must not change while previewing.
Before the fix: In the preview of amortization schedule, the Current Payment Amount is incorrectly displayed as $7,460.28.
The last EMI record incorrectly displays the value:
-
Principal = $25,326.31
-
Interest = $233.14
-
Amount = $25,559.45
After the fix: The Amortization schedule is same as it was after the loan disbursal.
On the Amortization Schedule, the values are correctly displayed as follows:
-
Last record has Due Date = March 01, 2014
-
Due Amount = $18,099.10
-
Due Principal = $17,934.07
-
Due Interest = $165.09,
-
Due Fee = $0
-
Balance = $0
-
Resolution
The issue is now resolved and on previewing a rescheduling without changing any parameters immediately after disbursement, the system is calculating the balloon payment correctly and generating the amortization schedules also correctly in the preview.
The system is not reverting the value of the Reverse Amount for the Next Due field to the previous value after a Payoff LPT reversal (Jira ID: PDRFF-3036/ND-8033)
Issue Description
The system is not reverting the value of the Reverse Amount for the Next Due field to the previous value after a Payoff LPT reversal.
Example to understand the issue
-
Set the Current System Date to March 01, 2013 and create a loan contract with the following values:
-
Loan Amount =10,000
-
Rate = 10%
-
Terms = 10
-
Time Counting Method = Month and Days
-
Payment Frequency = Monthly
-
IPT Frequency = Monthly
-
-
Approve and disburse the loan.
-
Move the current system date to April 10, 2013.
The system creates Bill-1 and IPT-1.
-
Create an LPT for the amount of $3040.6 (Bill amount + $1,000) (LPT-1).
-
Reverse Amount for Next Due = $2,000
-
-
Move the current system date to April 10, 2013.
-
Create a loan payoff transaction to close the loan (LPT-2) with transaction amount of $7,054.53 and transaction date of April 10, 2013.
-
Reverse Amount for Next Due = $0
-
-
Reverse payoff LPT (LPT-2).
-
Reverse Amount for Next Due is not reverting back to $2,000. The system still displays it as $0.
-
Resolution
The issue is now fixed and the system is reverting back the value of the Reverse Amount for the Next Due field to the previous value after a Payoff LPT reversal.
When rescheduling the loan with a Flexible Repayment Plan, the new schedule is getting generated without considering the Balloon Amount for the last term (Jira ID: PDRFF-2882/PD-1743)
Issue Description
When a loan with a flexible repayment plan and the Balloon Type as Balloon amount including only principal, is rescheduled, the new schedule is getting generated without considering the Balloon Amount for the last term and thus calculating the due payments incorrectly.
Resolution
The issue is fixed. Now, on rescheduling the loan with a Flexible Repayment Plan, the new schedule is considering the Balloon Amount for the last term
Loan Balance and other balances of Charge Record are not updating correctly in Transaction Summary despite applying capitalization (Jira ID: PDRFF-2622/ND-7264)
Fixed Versions
The fix of this issue is available in the following version:
-
Q2 Loan Servicing Summer' 22 (3.9001.58)
Issue Description
Current Loan Balance and other balances of charge record are not updating correctly in the Transaction Summary even after applying capitalization.
Example to understand the issue
-
Create a Lending Product with the following values:
-
Fee Set = $100 (Fixed)
-
Fee Capitalization = True
-
Add this Fee Set to product and set Create Summaries = True.
-
-
Set the Current System Date to March 01, 2013, and create a loan contract with the following values, and then approve and disburse the loan:
-
Loan Amount = $10,000
-
Interest Rate = 10%
-
Terms = 10
-
Time Counting Method = Month And Days
-
Payment Frequency = Monthly
-
Interest Posting Frequency = Monthly
-
Fee Capitalization = True
-
-
Move the Current System Date to April 1, 2013.
The system creates IPT-1 and Bill-1.
-
Move the Current System Date to April 2, 2013.
The system creates a charge with the following values:
-
Current Loan Balance = $10,183.33
-
Current Payoff Balance = $10,183.33
-
-
The values in Loan Transaction Summary are displayed as follows:
-
Current Loan Balance = $10,083.33 (Incorrect)
-
Current Payoff Balance = $10,083.33 (Incorrect)
-
Resolution
This issue is now fixed and the logic is modified such that the Current Loan Balance and the Current Payoff Balance are displayed correctly on the Loan Transaction Summary.
The system is displaying an Apex CPU time limit exceeded error while creating a loan with Compound Interest on a Lending Product set to True and with Compounding Frequency set to Semi-Monthly (Jira ID: PDRFF-2316/PD-1718)
Issue Description
The system is displaying an Apex CPU time limit exceeded error while creating a loan with Compound Interest on a Lending Product set to True and if Compounding Frequency set to Semi-Monthly.
Resolution
The issue is fixed. The system is now not displaying any error while creating a Loan contract with Compound Interest on a Lending Product set to True and Compounding Frequency set to Semi-Monthly.
If Compounding Interest is set to true in a loan where there are multiple disbursements, the system is calculating the Due Interest incorrectly (Jira ID: PDRFF-2451/ND-7136)
Fixed Version
This issue has been fixed in the following version:
-
Q2 Loan Servicing Summer'22 (3.9001.55)
Issue Description
In a loan where Compounding Interest is set to true and the loan is disbursed in tranches, while calculating interest, the system is missing out on the interest calculated for one day. This is because during multiple disbursements, the system is not considering the total Interest Accrued on the previous balance and the extra interest is being overridden by the Interest Posted value.
Example to understand the issue
-
Create a Lending Product with the following values:
-
Funding in Tranches =True
-
Compounding = True
-
-
Set the Current System Date to April 1, 2013, and create a loan contract with the following values, and then approve and disburse the loan:
-
Loan Amount = $50,000
-
Terms = 10
-
Default Interest Rate =10%
-
Time Counting Method = Month and Days
-
Payment Frequency = Monthly
-
Interest Posting Frequency = Monthly
-
-
Create loan and disburse partially with Amount = $25,000.
-
Move the Current System Date to the Next Due Date May 1, 2013.
IPT is updated as $208.33.
-
Create an LPT of Transaction Amount = $2,616.01 to satisfy the Bill-1.
The values are updated as follows:
-
Principal Remaining = 22,592.32
-
Principal Paid = $2,407.68
-
-
Move the Current System Date to May 2, 2013.
The values are updated as follows:
-
Interest Accrued = $6.28
-
Disbursement remaining = $25000.
-
Interest Accrued of $6.28 till May 2, 2013, is not getting added to Due Interest of June 1, 2013.
Resolution
The issue fixed by adding logic to calculate the extra interest by a taking the sum of all the IPTs generated between the last due date and next due date, and the interest accrued and interest remaining.
Amortization Schedules are getting incorrectly generated with incorrect Due Dates when a loan has a Flexible Repayment Plan and Business Hours attached to it (Jira ID: PDRFF-2438/ND-7009/PD-1688)
Fixed Version
This issue has been fixed in the following versions:
-
Q2 Loan Servicing Summer’22 ( 3.9001.50)
-
CL Common Summer’22 (3.9001.14)
Note
If you install the above latest Q2 Loan Servicing Summer’22 ( 3.9001.50), then ensure that you install the above latest CL Common Summer’22 (3.9001.14) as well.
Issue Description
In a loan with a Flexible Repayment Plan and Business Hours, the system is generating schedules with incorrect Due Dates in the following scenarios:
-
When the Payment Start Date of a Flexible Repayment Plan falls on a holiday, the system shifts the Payment Start Date to a working day correctly. But the issue is that the system is also shifting the dues dates of the remaining terms of the Flexible Repayment Plan to that working day. For example, let us say the Payment Start Date of a Flexible Repayment Plan is January 14 and January 14 is a weekend. So the Flexible Repayment Plan start date correctly gets shifted to January 16. This is a correct behavior. But the issue is that the system is also pushing all other repayments out to the 16th of every month instead of the 14th of each month. The expected behavior is that only the Payment Start Date of the Flexible Repayment Plan must change to the January 16th, the rest of the due dates must go back to the 14th of each month.
-
When the Due Day field has a value of 31, the system is behaving incorrectly as explained in the following example:
Let's say we have a Due Day of 31, and February month has 29 days. In this case, let us say the payment has to start from June and we need the due date at the last date of every month. But as June has only 30 days, we are able to only select June 30 as the Payment Start Date from the calendar because of which the due dates of the rest of the terms of the Flexible Repayment Plan also start at 30th even when the Due Day field has a value of 31.
-
The system is creating two schedules in the same month as explained in the following example:
Let us say we have specified a Due Day of 28, and we have created a Flexible Repayment Plan for due dates to fall on 22nd of the month for 5 terms where we have a total term as 12. Then the first five schedules are getting generated on the 22nd of every month but after the first five terms, the schedules are getting generated on the basis of date mentioned in Due Day. And as the Due Day is 28, one more schedule is getting generated in the last month of the 5 terms with the due date falling on 28th.
For example, let's say we have the first Payment Start Date of the Flexible Repayment Plan as June 6, 2023 and the last of the five terms is on October 22, 2023. As we have Due Day as 28, after the first five terms of the Flexible Repayment Plan, there is an another schedule getting generated on October 28, 2023. This makes October have two schedules. This is an incorrect behavior. The next schedule after October 22, 2023, must be September 28, 2023.
Resolution
To fix this issue, the internal logic has been modified and the system now behaves as follows in different scenarios:
-
When you create a new contract, the system automatically considers the value of the contract's Due Day field when generating Amortization Schedules.
-
Unless otherwise specified, the system sets the value of the New Due Day field to the value of the contract's Due Day field upon rescheduling.
-
Regular repayment schedules consider the value in the New Due Day field when rescheduling to generate amortization schedules.
-
While rescheduling, in the Flexible Repayment Plan, the first schedule adheres to the Due Date of the Payment Start Date, while the subsequent schedules follow the value in the New Due Day field. For example, say we have the Payment Start Date for Flexible Repayment Plan as February 28 for 5 terms and New Due Day as 30. Then the system considers the first Due Date as February 28, followed by March 30, April 30, and so on.
-
If you change the Repayment Start Date while rescheduling, make sure to also change the New Due Day field so that all EMIs are created on the New Due Day of the month. Otherwise, the system would generate schedules with due dates that correspond to the Due Day specified in the contract.
Note
Any existing contracts, if rescheduled, will follow the preceding new behaviors. For example, before this fix, if a Flexible Repayment Plan falls on the Payment Start Date, then after this fix, the existing Flexible Repayment Plan schedules would fall on the Due Day field value. (The first term of a Flexible Repayment Plan would still fall on the Payment Start Date.) See the Example to understand the new behavior after the fix.
Note
Additional Scenarios
-
For loan payment frequencies like Daily, Weekly, Bi-weekly, Semi-Monthly, and Semi-Monthly-PD, the system follows the existing behavior for Due Date adjustments.
-
When using the old API, rescheduleALoan, it is recommended to switch to the latest API that supports LoanRescheduleParameters to follow the new behavior.
-
Following is the old API: rescheduleALoan(loanId, transactionDate, repaymentStartDate, interestRate, interestOnlyPeriod, frequencyOfPayment, noOfInstallments). This API does not take Due Day as a parameter.
Instead, you must use the latest API that takes LoanRescheduleParameters as a parameter, and provide Due Day field value in LoanRescheduleParameters.
Following is the latest API: rescheduleALoan(LoanRescheduleParameters rescheduleParams). For more information on the APIs, see the Q2 Loan Servicing Global Methods guide.
While using the latest API, if you provide the changed Payment Start Date, then you must also provide the value for the Due Day parameter.
-
When Move Across Months is set to true and the Schedule Adjustment Method is set to After, and if you need the first EMI to be scheduled at the beginning of the month, while remaining EMIs to be scheduled at the end of the month, then in the Flexible Repayment Plan, you must use one term for the first schedule and add another row starting at the end of the month. The reverse applies when the Schedule Adjustment Method is set to Before.
Note
-
The Payment Start Date marks the beginning of the borrower's repayment schedule.
-
Due Day is a field that stores the day of the month on which the payment is due when the contract was originally created. This field was originally created to specify a value of 31 in it so that all due dates fall on the month end. For example, if Due Day is 31, then due date for the month of February will fall on 28th February if February has 28 days, and the due date for the month of January will fall on 31st of January, and the due date for the month of April will fall on 30th of April because April only has 30 days.
-
If nothing is entered in the Due Day field on the loan contract, the system automatically updates it with the Payment Start Date day. For example, if Payment Start Date is January 15, and nothing is specified in the Due Day field, then it will automatically take the value as 15 and consider all due dates of the schedules to fall on 15th of every month. Thus, the Due Date in the amortization schedules are calculated either looking at the Payment Start Date, the Due Day, or the New Due Day.
-
Additionally, to account for holidays, the system requires the inclusion of Business Hours in the product or contract. Hence, you must add the Business Hours while creating a lending product or a contract if you need to account for any holidays. This ensures that the due dates align with the working schedule and accounts for non-working days such as public holidays.
Example of the system behavior after the fix
Let us see an example of Repayment schedules in a loan with Flexible Repayment Plan and where Due Day = 31, the Due Date falls on a holiday, and Move Across Months = false.
-
Create a lending product with the following values:
-
Interest Rate = 10%
-
Terms = 12
-
TCM = Month and Days
-
Is Interest Posting Enabled = true
-
Interest Posting Frequency = Monthly
-
Payment Frequency = Monthly
-
Move Across Months = false
-
Schedule Adjustment Method = After
-
-
Add Business Hours with Saturday and Sunday as holidays.
-
Move SOD to 1/31/2015.
-
Create a loan contract with the preceding lending product with the following values:
-
Due Day = 31
-
Loan Amount = $10,000
-
Payment Start Date = 2/28/2015
-
-
Go to Loan Quick Menu > Loan Actions > Reschedule and add the following Flexible Repayment Plan:
-
Approve and disburse the contract.
-
Verify the Amortization Schedule. It is as follows:
As seen in the preceding image:
-
The first schedule Due Date is 2/27/2015, as February 28 is a holiday (Saturday) according to the business hours attached and as the Move Across Months = false and Schedule Adjustment Method = After, if a Due Date on the month end falls on a holiday, then it must shift to the previous working day.
-
The first three schedules have $1,000 as the Due Amount and the fourth schedule has $1,000 as the Due Principal as per the Flexible Repayment Plan attached.
-
The fourth schedule Due Date is 5/29/2015. This is because 5/31/2015 is a Sunday and as the Move Across Months = false and Schedule Adjustment Method = After, the Due Date gets shifted to 5/29/2015 as it cannot move across the next month.
-
Known Issue
While using Interest Only Payments in Flexible Repayment Plan with Business Hours, the bills are getting generated incorrectly. This issue would be fixed in the forthcoming patches.
Loan UI Screen is displaying a pop up while entering the value in Amount field (Jira ID: PDRFF-2270/ND-6916)
Fixed versions
The fix of this issue is available in the following version:
-
Q2 Loan Servicing Summer’22 ( 3.9001.50)
Issue description
The customer is currently experiencing an issue when they attempt to input a value into the Transaction Amount field.
The problem arises when a pop-up message appears; it is expected to trigger only if the customer attempts to input more than the permitted number of values after the decimal point.
However, the issue lies in the fact that this alert is not exclusive to numbers after the decimal point. It occurs even when changes are made before the decimal point and the system displays the following message:
You are trying to enter more decimal places than what is permitted for this field.
Resolution
The user can now input the permitted number of digits before the decimal points.
The ACH payment is not getting applied when Index Rate change occurs on the APS Debit Date (JIRA ID: PDRFF-1825 /ND-6587)
Issue Description
In a loan with Interest Posting Frequency set to the Billing Frequency, when the Index Rate change occurs on the APS Debit Date, the ACH payment is not getting applied however the APS Debit Date is getting updated to the next due date.
Example to understand the issue
The issue is occurring when there is a floating index rate change on the same date as the billing and theAPS Debit Date.
Let us say that following is the floating rate and the loan configuration:
-
Interest Type = Floating
-
Interest Rate Change Method = Keep Same Payment Amount
-
Is Interest Posting Transaction Enabled = True
-
Is Capitalization Enabled = True
-
Interest Posting Frequency = Billing Frequency
-
Floating Rate Revision Frequency = Billing Frequency
-
Floating Rate Revision Date = January 15, 2022.
-
Floating Rate Revision Date Actual = January 15, 2022
-
Payment Mode = ACH
-
Amount Type = Last Billed Amount
Because of this configuration, the billing, floating index rate change and APS payment, all fall on the same date every time as they are at the Billing Frequency.
In the system, first the Billing Job runs followed by the Floating Rate Change Job(FloatingRateInterestRevisionDynamicJob) and then the payment creation job(LoanPaymentTransactionCreationDynamicJob).
This is explained as follows:
-
Billing job changes the Next Due Date to the next bill date as expected.
-
Floating rate change job (FloatingRateInterestRevisionDynamicJob) performs and index rate change and reschedules the contract. As part of this, the system updates the APS Debit Date to the Actual Next Installment Date.
-
When the payment creation job (LoanPaymentTransactionCreationDynamicJob) runs, the APS Debit Date would have already advanced to the Actual Next Installment Date, hence, the current due date's payment is not created.
Thus, the APS Debit Dates are updated to the Actual Next Installment Date on the contract when you reschedule a loan (because the billing frequency expects them to be in sync).
This is a correct behavior when you are changing the payment date on rescheduling, but this is not required in floating rate change job as we do not expect a payment date to change. The ACH payment must be applied to the contract. But the Floating rate change job performs index rate change and reschedules the contract.
As part of this, the system updates APS Debit Date to the Actual Next Installment Date.
Resolution
The issue is fixed now, and the ACH payment is getting applied correctly.
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:
" Aggregate query has too many rows for direct assignment, use FOR loop"
Resolution
This issue is fixed now, and the Floating Rate Revision job is running successfully without any error messages.
The global Index Rate changes are not getting reflected in the Loan Transaction Summary Detail section (Jira ID: PDRFF-1795 / ND-6516)
Issue Description
When the global Index Rate change is performed ,the system is not reflecting the rate changes in the Loan Transaction Summary Detail section.
Resolution
This issue is fixed now, and the Rate changes are getting reflected in the Loan Transaction Summary Detail section.
The system is facing layout issues while viewing in the Lightning Experience after the Summer'22 upgrade (Jira ID: PDRFF-1598 / ND-6339)
Issue Description
After the Summer'22 upgrade ,the header with CL Contract and LAI-XXXXXXX details on the CL Contracts page is appearing twice while viewing the application in the Lightning Experience.
Resolution
This issue is fixed now, and the header on the Contracts page is appearing correctly.
The principal balance is getting incorrectly calculated when a loan is delinquent (JIRA ID: PDRFF-1143 /ND-5935)
Issue Description
In a loan with additional interest component, when a contract is in delinquent status, the system is calculating a lower principal balance than expected.
Example to understand the issue
1. Let us create a loan contract with the following details and disburse it:
-
Contract Start Date = December 25, 2020
-
Loan Amount = $10,000
-
Interest Rate = 10%
-
Term = 10 Months
-
Periodic Fee Frequency = Monthly
-
Periodic Start Basis = Disbursal
-
Included in Dues = True
-
Included in Schedules = False
-
Fixed amount = $100
-
Add Fee Amount to bill = True
-
Delinquency Basis = Schedule Balance
-
AIC details:
-
Add Interest to Bill = True
-
Interest Calculation Method = Delinquent Amount
-
IPT frequency = Billing frequency
2. Let us go to January 25, 2021.
Since the billing cycle is monthly, the system generates a bill, and the values should be updated as follows:
-
Charge = $100
-
Interest Posted = $50
-
Principal = $1,000
-
Bill amount = $1,150
Let us not clear the bill. This makes the loan delinquent.
3. Let us go to February 25, 2021.
Since the billing cycle is monthly, the system generates a bill, and the values must be updated as follows:
-
Charge = $100
-
Interest posted = $52
-
AIC posted = $25
-
Principal = $1,003
-
Bill amount = $1,180
Let us not clear the bill.
But the system is calculating the principal and bill amount incorrectly as follows:
-
Principal = $903
-
Bill amount = $1,080
Resolution
This issue is fixed, and when a contract is in delinquent status the principal is getting calculated correctly.
The system is updating the Reserve Amount for Next Due field incorrectly when paid charge is involved (Jira ID:PDRFF-3320/ND-8545)
Issue Description
Payment created before the bill generation is getting incorrectly allocated to the Reserve Amount when the Include in Dues flag and the Add Fee Amount to Bill flag both are set to True and there exists an adhoc charge which is created and paid as well before the bill generation. Therefore, the Reserve Amount for Next Due field is getting updated such that it includes the fee paid.
Example to understand the issue
-
Create a loan contract with following values and with the given fee set:
-
Loan Amount = $10,000
-
Rate = 10%
-
Terms = 10
-
Time Counting Method = Month and Days
-
Payment Frequency = Monthly
-
IPT Frequency = Billing Frequency
-
Add Fee Amount to Bill = True
Fee Details:
-
Fee Type = Late Fee
-
Fee calculation Method= Fixed
-
Amount = 100
-
Include in Dues = True
-
Include in Schedule= False
-
Enable Capitalization = False
-
-
Move the current system date to March 10, 2013.
-
Create an adhoc charge on the loan of $100.
-
Move the current system date to next date March 11, 2013.
-
Create an LPT of $60 to pay the charge partially. The values are updated as follows:
-
Fee Paid = $60
-
Fee Remaining = $40
-
Reserve Amount for Next Due will be updated a $60 (incorrect)
-
-
Move the current system date to April 01, 2013.
-
Bill-2 is generated with Due Amount of $1086.40. Only Unpaid charge amount will get added to the bill, Payment Amount must be $60 on the bill.
But the Bill amount does not contain the $60 as it was paid towards fee. Hence, the system must not use the $60 displayed in Reserve to pay the bill.
Resolution
The issue is now fixed and the system is updating the Reserve Amount for Next Due field correctly when paid charge is involved.
Change Date |
Description of Change |
---|---|
September 1, 2022 |
Published release notes for General Availability release. |
March 15, 2023 |
Published the release notes for: Q2 Loan Servicing Summer'22 Issues fixed in Q2 Loan Servicing 3.9001.41 |
June 5, 2023 |
Published the release notes for: Q2 Loan Servicing Summer'22 Issues fixed in Q2 Loan Servicing 3.9001.43 |
June 26, 2023 |
Published the release notes for: Q2 Loan Servicing Summer'22 Issues fixed in Q2 Loan Servicing 3.9001.45 |
October 30, 2023 |
Published the release notes for: Q2 Loan Servicing Summer'22 Issues fixed in Q2 Loan Servicing 3.9001.50 |
October 30, 2023 |
Published the release notes for: Q2 Loan Servicing Summer'22 Issues fixed in Q2 Loan Servicing 3.9001.50/CL Common 3.9001.14 |
January 29, 2024 |
Published the release notes for: Q2 Loan Servicing Summer'22 Issues fixed in Q2 Loan Servicing 3.9001.55 |
January 29, 2024 |
Published the release notes for: CL Common Summer'22 Issues fixed CL Common 3.9001.15 |
March 11, 2024 |
Published the release notes for: Q2 Loan Servicing Summer'22 Issues fixed in Q2 Loan Servicing Summer' 22 (3.9001.58) |
April 01, 2024 |
Published the release notes for: CL Common Summer'22 Issues fixed in CL Common Summer'22 (3.9001.17) |
June 24, 2024 |
Published the release notes for: Q2 Loan Servicing Summer'22 Issues fixed in Q2 Loan Servicing 3.9001.60 |
July 15, 2024 |
Published the release notes for: Q2 Loan Servicing Summer'22 Issues fixed in Q2 Loan Servicing 3.9001.62 |
August 05, 2024 |
Published the release notes for: Q2 Loan Servicing Summer'22 Issues fixed in Q2 Loan Servicing 3.9001.64 |
August 26, 2024 |
Published the release notes for: Q2 Loan Servicing Summer'22 Issues fixed in Q2 Loan Servicing 3.9001.67 |
September 16, 2024 |
Added PDRFF-3121/ND-8352 to the Q2 Loan Servicing Summer'22 Issues fixed in Q2 Loan Servicing 3.9001.67 |
November 18, 2024 |
Published the release notes for: Q2 Loan Servicing Summer'22 Issues fixed in Q2 Loan Servicing 3.9001.71 patch |