Spring'23 Release Notes – Symphonix

Preface

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 the Q2 Loan Servicing, Spring'23 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 Spring'23 version (4.2008) of Q2 Loan Servicing for the first time or have upgraded from an earlier version.

Purpose of this Document

This document provides information on the following for the Spring'23 release:

Installation Information
Upgrade Considerations
System Performance
New Features and Enhancements
Fixed Issues
Known Issues
New and Modified Objects
New and Modified APIs
Global Methods

Intended Audience

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

Prerequisites for Use

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

Introduction

These release notes may be updated after the first release. Any changes to the contents of these release notes are listed in the Change Recordsection.

Installation Information

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 Q2 Loan Servicing.

Upgrade Considerations

For information on the upgrade steps, see release-related steps in the Q2 Product Upgrade Guide.

System Performance

To view the SOD batch jobs performance statistics for Q2 Loan Servicing without customizations under test conditions, see the Q2 Performance Benchmarking Guide.

New Features and Enhancements

This section briefly describes the new features and enhancements added in the Spring'23 release of Q2 Loan Servicing.

Note: For a detailed description of the new features and enhancements, see the following guides published over the Q2 Customer Portal:

Q2 Loan Servicing User Guide for Simple Loans
Q2 Loan Servicing User Guide for Amortized Loans
Q2 Loan Servicing User Guide for Line of Credit Loans
Q2 Loan Servicing User Guide for Master Facility
Q2 Loan Administration Guide

Interest Adjustment for non Interest posting enabled loans (JIRA ID: ND-6065)

Feature Description

This feature enables the users to create payment reversal whose transaction dates are prior to existing transactions. And also allow backdated payment reversals for the non-IPT enabled loans.

Till now the adjustment entry feature was supported only for the IPT-enabled loans. From this release, it is supported for the non-IPT enabled loans also.

Interest Adjustment Transaction (JIRA ID: ND- 5771)

Feature Description

This feature enables the users to do manual interest adjustments. A user can use this feature for making any corrections in the existing interest value calculated on a loan. An FI can extend this as a benefit to its borrower.

A new quick action has been provided where the user can provide the interest amount that needs to be adjusted against the loan. There are two fields provided.

1. Adjusted Interest Capitalised: The interest adjustment that needs to be added to the capitalised amount (Interest adjustment till last IPT date)

2. Adjusted Interest Non-Capitalised: The non capitalised interest adjustment as of LAD Date

Delaying the change in payment amount due to rate change (JIRA ID: ND-5819)

Feature Description

This feature will assist users in configuring the period of time after which they would like the system to modify the payment amount as an impact of rate change rescheduling, allowing borrowers to plan for the payment amount change without being immediately impacted by the rate change.

Diagnostics and Alerts: Interest posted is different from expected amount as per amortization schedule (JIRA ID: ND-5838)

Feature Description

The interest diagnostics feature has been introduced to find out if the interest calculated on a loan is incorrect. This is done with the help of a batch process which can be run at any time. The interest discrepancy is logged in the Diagnostic Status object. A tolerance amount needs to be specified at the org level to determine the tolerance amount allowed as part of the diagnostics. This amount defines the amount limit above which the diagnostics process will alert on the discrepancy.

Diagnostics and Alerts: User alert when the actual outstanding balance is different from the schedule balance (JIRA ID: ND-5840)

Feature Description

Similar to the interest diagnostics feature, now we also have a principal diagnostics feature which finds out of if the Loan Balance/ Principal Remaining is not the expected amount. Again, any discrepancy will be logged in the Diagnostics Status object.

Waiver of Fees post payment of fees (Jira ID: ND- 6077)

Feature Description

We now have the ability to waive a fee that has already been paid. As part of the waiver action, the user now has the option to waive an already paid fees. As part of the action user will be able to select whether the extra amount that has been paid should be put into excess amount to be refunded to customer or adjusted against principal and decreasing the Principal payment.

Enhancements to Financial Calculator V4 (JIRA ID: ND-6204, ND-6205)

Feature Description

Version 4 of the financial calculator has been updated to handle the following scenarios:

Interest only period in advance
Capitalisation of interest before schedule due date
Inclusion of periodic fees in schedules
Calculation of Interest rate given a payment amount

Fixed Issues

For the details of the issues fixed in this release, see the Q2 Loan Servicing Patch Release Notes, 2023.

Known Issues

This section briefly describes the known issues in the Spring'23 release of Q2 Loan Servicing.

Issue ID	Description
ND-6359	Fincalc phase 3: While rescheduling the capitalization dates not considered before repayment start date
ND-6151	Running IPT job for Backdated LPT creation and reversal -only for Capitalization fee and NSF fee
ND-6118	Additional Bills are generating for daily contract
ND-6225	Latest Bill is not included in Repayment Schedule on Rescheduling loan with Maintain Delinquency=True
ND-6216	ARR-Allow to pass Transaction Date in Manual Bill creation API
ND-6172	Today's payoff is not getting updated to zero when Loan is in Closed Status
ND-6229	Lending Product Min Term not working
ND-6374	After moving to next IPT date and doing 2nd backdated LPT, payoff, loan balance and adj int cap is mismatching
ND-6361	Calc 3.1 issue: create contract with capitalization frequency less than the payment frequency, Interest calculation is wrong in schedule
ND-6363	Calc 4.0 issue: Create capitalized loan with Repayment plan (IO) period defined, the amortization schedule wrong
ND-6429	Remaining amount for funding on IO is not updated correctly after second disbursal with approval process in Non revolving loans
ND-6430	DML exception throwing while doing disbursal reversal that happen through approval process
ND-6433	Validation is not showing when doing Zero amount disbursal For Advance Interest loans
ND-6424	Apex heap size too large error is displaying while reversing payment
ND-6438	DML exception throwing while doing Loan Cancellation reversal
ND-6440	After doing Investor Rate change for IO AIC, New rate not getting reflected on the IO AIC
ND-6364	Spring'23 Performance: Apex CPU time limit exceeded exception observed for InterestAndBalanceDiagnosticsJob on both DAG & External batch
ND-6437	Maximum view state size limit while opening cash receipt
ND-6456	Bulk no of test cases are failing in payoff quote as late charges are included twice when applyFuturePayments=False

New and Modified Objects

This section briefly describes the new and modified objects in the Spring'23 release of Q2 Loan Servicing.

Note

For more details on the added and modified objects, see Q2 Loan Servicing Data Dictionary Guide.

New Objects

The following table describes the objects added in the Spring'23 release of Q2 Loan Servicing.

Object Name	Field Name	Field Description
Diagnostic Status	loan__Interest_Discrepancy_Found__c	This new field captures the results of diagnostics and links it to the contract record.
	loan__Loan_Balance_Discrepancy_Found__c	This new field is selected by the diagnostic job to indicate that the contract's principal amounts are not matching.
	loan__Loan_Account__c	This new field indicates the loan account for which the diagnostic status is generated.
Diagnostic Settings	loan__Interest_Amount_Tolerance__c	This new field indicates the tolerance value for Interest amount in a loan.

Modified Objects

The following table describes the objects modified in the Spring'23 release of Q2 Loan Servicing.

Modified Object Name	Added/Modified Field Name	Field Description
Loan Parameters	loan__Days_To_Payment_Amount_Change__c	This newly added field is an integer field used to provide the number of days for which the upcoming payments will remain constant after the rate change.
	loan__Enable_Delay_For_Manual_Rate_Change__c	This newly added field is a checkbox field used to indicate that the payment is delayed after the manual rate change.
	loan__Variable_Payment_Amt_Per_Rate_Schedule__c	This newly added field is a checkbox field used to indicate if amortization schedules with EMI is generated for different rate schedule.
Custom Hooks	Custom_Fixed_Schedules_Class__c	This newly added field is a text field that describes the custom class for Fixed schedules after a rate change.
Other Loan Transaction	loan__Adjusted_Interest_Capitalized__c	This newly added field is a number field that stores the capitalized portion of interest adjustment.
Other Loan Transaction	loan__Adjusted_Interest_Non_Cap__c	This newly added field is a number field that stores the non-capitalized portion of interest adjustment.
Diagnostic Log	loan__Loan_Account__c	This newly added field is a lookup field that stores the contract record for which this log is generated.
	loan__Actual_Capitalized_Interest__c	This newly added field is a number field that stores the contract's current value for capitalized interest.
	loan__Expected_Capitalized_Interest__c	This newly added field is a number field that stores the calculated value for capitalized interest computed by diagnostic job.
	loan_Actual_Non_Cap_Interest__c	This newly added field is a number field that stores the contract's current value for non-capitalized interest.
	loan__Expected_Non_Cap_Interest__c	This newly added field is a number field that stores the calculated value for non-capitalized interest computed by diagnostic job.

New and Modified APIs

This section briefly describes the APIs that are added or modified in the Spring'23 release of Q2 Loan Servicing.

Note

For more details on the added or modified APIs, see Q2 Loan Servicing REST APIs Guide.

New APIs

There are no new APIs added in the Spring'23 release of Q2 Loan Servicing.

Modified APIs

There are no APIs modified in the Spring'23 release of Q2 Loan Servicing.

Global Methods

This section briefly describes the global methods that are added or modified in the Spring'23 release of Q2 Loan Servicing.

Note

For more details on the added and modified global methods, see Q2 Loan Servicing Global Methods Guide.

New Global Methods

The following table describes the global methods added in the Spring'23 release of Q2 Loan Servicing:

Class Name	Global Method Name	Global Method Description
AbstractLoanActions	waivePaidCharge	This method is used to waive the paid charge component of loan.
AbstractLoanActions	interestAdjustmentAction	This method is used to do manual interest adjustment.
AbstractCustomOptionForFixedSchedule	getCustomNumberOfFixedSchedules	This method is used to get the number of schedules whose payment amount will not change after rate change in a loan contract.
AbstractCustomOptionForFixedSchedule	getEnableDelayForManualRateChangeFlag	This method is used to check if the delay in the Payment Amount functionality must be applied for the manual rate change from the Reschedule page or from Rate Change page.

Modified Global Methods

There are no global methods modified in the Spring'23 release of Q2 Loan Servicing.

Post GA Release

Follow this section for the details on the issues fixed in the patches on the Spring'23 release of the following packages:

Q2 Loan Servicing

Issues fixed in the 4.2008.83 patch

The system is incorrectly updating the Reserve Amount for Next Due field to a non zero value after the loan is paid off (Jira ID:PDRFF-3452/ND-8532)

Issue Description

When a user makes an overpayment, any amount exceeding the balance due as of the billing date is placed in a Reserve Amount for Next Due field. When the final bill is generated on the Maturity Date, the system applies this reserve to partially cover the remaining balance, and the Reserve Amount is updated to zero.

However, later if the customer makes a payment equal to the Today Payoff amount to payoff the loan, the system is closing the loan, but is incorrectly updating the reserve amount to a non-zero value.

Resolution

The issue is fixed now and the system is not updating the Reserve Amount for Next Due field to non zero after the loan is paidoff.

The system is applying multiple Motor Early Payoff Fees charges to a single loan for multiple payoff payments (Jira ID:PDRFF-3101/ND-8592)

Issue Description

The system is applying multiple Motor Early Payoff Fees charges to a single loan for multiple payoff payments. Instead once the payoff charge is applied on the loan contract, the payoff penalties must not be applied again.

Example to understand the behavior after the fix

Set the current system date to March 01, 2013, and create a loan contract with the following values and link it with the given fee set:
- Create a periodic charge with Amount = 400
- Payoff charge with Time of charge = Pay-Off Fees
- Prepayment Penalty Type = Tenor Based Slabs and add it to fee set
- Loan Amount = $10,000
- Rate = 5%
- Terms = 10
- Time Counting Method = Month and Days
- Payment Frequency = Monthly
- IPT Frequency = Billing Frequency
- Payoff Tolerance Amount = $100
Approve and disburse the loan.
Under Prepayment Penalty Details tab, create Prepayment Penalty Configuration for payoff charge. The values are updated as follows:
- Calculation Type= Fixed
- Tenor Slab Type = Term Based
- Calculation Amount Reference= None
- Tenor Slab Frequency = None
Add Sequence 1 (Prepayment Penalty Configuration) with following values:
- Lower Limit = 0
- Upper Limit = 5
- Value = 400
Move the current system date to March 10, 2013.
Go to LPT creation page, enter Transaction Amount as $10,400, click Save.

System must add a Payoff Charge of $400, Loan status is updated as Active-Marked for closure.
Manually change the status to Active-Good Standing.
Create an adhoc periodic charge for $400.
Pay the payoff charge completely if it is not paid. In this case it is $12.50.
Move the current system date to March 11, 2013(Next Day).
Create a payment with Transaction amount = 410.

Loan status is getting correctly updated to Closed-Obligations met.

Duplicate Payoff charge is not getting created.

Resolution

The issue is now resolved and the system is not charging multiple Motor Early Payoff Fees charges to a single loan for multiple payoff payments.

Issues fixed in Q2 Loan Servicing Spring'23 4.2008.79 patch

The system is incorrectly applying the Periodic Fee to the contract on the due date instead of applying the fee on the scheduled date (Jira ID: PDRFF-3219/ND-8333)

Issue Description

When the Periodic Fee on the contract is set to Include in schedules and the Fee Type is set to Per Period Amount, the system is not updating the charges or the Next Recurring Fee Date field according to the pre-defined Next Recurring Fee Date. Instead, it is updating the charges or Next Recurring Fee Date field in accordance with the loan Due Date.

Example to understand the issue

Create a contract on May 15, 2021, with Periodic Fee Frequency field set to Monthly.
Approve and disburse the contract on May 15, 2021.
Set the Next Recurring Fee Date to June 01, 2021, Start Date to June 01, 2021, and move the current system date to June 01, 2021.
The system is setting the Next Recurring Fee Date incorrectly to July 15, 2021.

Expected:

The Next Recurring Fee Date should be July 01, 2021, since the Periodic Fee Frequency is set to Monthly.

Resolution

The issue is fixed now and the system is updating the Next Recurring Fee Date field according to the pre-defined Next Recurring Fee Date.

Issues fixed in Q2 Loan Servicing Spring'23 4.2008.78 patch

The system is displaying a NullPointerException error, when the investors have become inactive, and the user runs the Investor Payout Job (Jira ID: PDRFF-3316/ND-8324)

Issue Description

When the contract status is Closed-Obligation Met, all the investors have become inactive, and the user runs the Investor Payout Job, the system is displaying the following error message:

Note

Attempt to de-reference a null objectCause: nullStack: (loan)Line number: 484Type name: System.NullPointerExceptionStacktrace - Entering - execute() of MFiFlexBatchJobDelegate

Resolution

The issue is now fixed and the system is not displaying the error message.

On attempting to change the Fiscal Year Start Month on the Fiscal Year Information page, the system is displaying an exception error message (Jira ID: PDRFF-3246/ND-8278)

Issue Description

The system is displaying an exception error message when the user was trying to change the Fiscal Year Start Date on the Fiscal Year Information page from default January to some other month.

Example to understand the issue

Scenario 1

If there are no records in the FiscalYearSeetings object

Go to Setup > Quick Find > Fiscal Year > for Standard Fiscal Year select Fiscal Year Start Month and from the drop-down list select July.
Go to > Service Configuration > Under Batch select SOD/EOD Process.
On the SOD- EOD Process page change the Move System Date to (Future/Past) field to July 01, 2023.
Go to Apex Jobs page, the Status will be updated to Completed.
Go back to the SOD- EOD Process page on selecting Refresh the system is displaying the following error:

Note

Subscript is invalid because list is empty

Scenario 2

If there in the FiscalYearSeetings object

Go to Setup > Quick Find > Fiscal Year > for Standard Fiscal Year select Fiscal Year Start Month and from the drop-down list select July.
Select Save
Go to Setup > Developer Console > run the following queries:
- SELECT Id, StartDate, EndDate, Name, IsStandardYear, YearType FROM FiscalYearSettings
If the system does not display any records, query Period object using the following query:
- SELECT Id, FiscalYearSettingsId, Type, StartDate, EndDate FROM Period LIMIT 1
  
  Note
  
  Once the user has queried the Period object they will always be able to see the records and there is no need to querry the Period object every time
Then run the following query:
- loan_Day_Processc - SELECT Id, Name, Datec, Day_Startedc, Day_Endedc, Statusc FROM Day_Processc where Date_c > 2023-06-30
- loan_Month_Processc - SELECT Id, Last_Day_of_Monthc FROM Month_Processc where Last_Day_of_Month_c > 2023-06-30
Delete all future records.
Move the current system date to January 01, 2023 and then to June 30, 2023.
Move the current system date to the next date July 01, 2023.

The system is displaying the following error message:

Expected Result - The system must move the current system date to July 01, 2023.

Resolution

The issue is now fixed. Perform the below given step after applying the fix:

For Scenario 1

Move the current system date to June 30, 2023, without running batch jobs using script.
- Date sodDate = Date.newInstance(2023,6,30);
  
  loan.GlobalProcessFacade.moveSystemToDate(sodDate, false); //yyyy,mm,dd
Update the Start Date and the End Date in the Fiscal_Year__c object if user is updating Standard Fiscal Year Month to any month other than January. for example, Set Start Date to July 01, 2022, and End Date to July 30, 2023.
Delete all the future records.
Go to Setup > Developer Console > run the below code

List<loan__Fiscal_Year__c> fiscalYear = [SELECT id, loan__Fiscal_Year_Setting_Id__c,loan__Start_Date__c, Name

FROM loan__Fiscal_Year__c order By loan__Start_Date__c];

Organization org = [SELECT FiscalYearStartMonth,Id,UsesStartDateAsFiscalYearName

FROM Organization WITH SECURITY_ENFORCED];

for(loan__Fiscal_Year__c fy : fiscalYear) {

Date startDate = Date.newInstance(fy.loan__Start_Date__c.year(), org.FiscalYearStartMonth, 1);

Date endDate = startDate.addYears(1).addDays(-1);

fy.loan__Start_Date__c = startDate;

fy.loan__End_Date__c = endDate;

if(org.UsesStartDateAsFiscalYearName) { //Name of the Fiscal Year record is depends on this condition

fy.Name = '' + startDate.year();

}

else {

fy.Name = '' + endDate.year();

}

loan.GlobalLoanUtilFacade facade = new loan.GlobalLoanUtilFacade();

Date sysDate = facade.getCurrentSystemDate();

if(sysDate >= startDate && sysDate <= endDate) {

fy.loan__Status__c = 'Open';

}

else {

fy.loan__Status__c = '';

}

update fiscalYear;

Move the current sequence date to July 01, 2023.
The system is updating the date successfully and Day_Process and Month_Process records are getting created successfully for the Fiscal Year July 01, 2023, to June 30, 2024..

For Scenario 2,

To update Start Date and End Date in the Fiscal_Year__c object if the user is updating Standard Fiscal Year Month to any month other than January.
Go to Setup > Developer Console > run the below code

List<loan__Fiscal_Year__c> fiscalYear = [SELECT id, loan__Fiscal_Year_Setting_Id__c,loan__Start_Date__c, Name

FROM loan__Fiscal_Year__c order By loan__Start_Date__c];

Organization org = [SELECT FiscalYearStartMonth,Id,UsesStartDateAsFiscalYearName

FROM Organization WITH SECURITY_ENFORCED];

for(loan__Fiscal_Year__c fy : fiscalYear) {

Date startDate = Date.newInstance(fy.loan__Start_Date__c.year(), org.FiscalYearStartMonth, 1);

Date endDate = startDate.addYears(1).addDays(-1);

fy.loan__Start_Date__c = startDate;

fy.loan__End_Date__c = endDate;

if(org.UsesStartDateAsFiscalYearName) { //Name of the Fiscal Year record is depends on this condition

fy.Name = '' + startDate.year();

}

else {

fy.Name = '' + endDate.year();

}

loan.GlobalLoanUtilFacade facade = new loan.GlobalLoanUtilFacade();

Date sysDate = facade.getCurrentSystemDate();

if(sysDate >= startDate && sysDate <= endDate) {

fy.loan__Status__c = 'Open';

}

else {

fy.loan__Status__c = '';

}

}

update fiscalYear;

Move the current system date to July 01, 2023.
The system is updating the date successfully and Day_Process and Month_Process records are getting created successfully for the Fiscal Year July 01, 2023, to June 30, 2024.

Issues fixed in CL Common Spring'23 4.2004.27 patch

The system is displaying an error message on invoking a custom code (Jira ID: PDRFF-3159/PD-1782)

Issue Description

Whenever the custom code is invoked, the system is executing the Account in CL-Common. If this Account is having over 50,000 Contact associated with it the system is displaying the following error message:

Note

Too many Query Row - 50001" exception

Resolution

The issue is now fixed by modifying the logic such that the system is not displaying any error message while accessing Accounts having over 50,000 Contact associated with it.

Issues fixed in Q2 Loan Servicing 4.2008.74 patch

The system is applying multiple Motor Early Payoff Fees charges to a single loan for multiple payoff payments (Jira ID: PDRFF-3101/ND-7899)

Issue Description

The system is applying multipleMotor Early Payoff Fees charges to a single loan for multiple payoff payments. Instead the system must apply the payoff penalties as follows:

Once the payoff charge is applied on the loan contract, it must not be applied again
Once the payoff charge is applied and a payoff is attempted, pre-payment penalty must not be applied again

Example to understand the issue

Scenario 1

Let us consider a scenario where the user creates an excess LPT to pay the payoff charge.

Set the current system date to March 01, 2013, and create a loan contract with the following values:
- Create a payoff charge and add it to fee set.
- Link fee set with product.
- Loan Amount = $10,000
- Rate = 10%
- Terms = 4
- Time Counting Method = Month and Days
- Interest Posting Transaction Frequency = Billing Frequency
Approve and disburse the loan.
Under the Prepayment Penalty Details tab, create Prepayment Penalty Configuration for payoff charge with the following values:
- Calculation Type = Fixed
- Tenor Slab Type = Term Based
- Add Seq 1 with Lower Limit = 0, Upper Limit = 3, Value = 400
Create LPT-1 of amount $10,000 (same as the payoff amount)
The system displays a warning message for the amount of $400.
Save page to create LPT.
The system creates a Payoff Charge-1 for the amount of $400.
Create an LPT-2 for the amount of $500.
Select Save.
Before the fix:
- The system displayed a warning message to create another Payoff Charge for the amount of $400.
- On selecting Save again, the system created one more payoff charge of the amount $400. This charge has a Total Amount Due of $300 and Paid Amount of $100.
After the fix:
- The system is not displaying a warning message and sub header to create payoff charge.
- Another payoff charge is not getting created.
- Payoff Charge-1 is getting paid.
- Loan status is updated to Closed - Obligations met
- After paying a charge amount of $400, remaining amount goes towards Excess. So, Excess field is updated to $100.

Scenario 2

Let us consider a scenario where the user creates an LPT of exact amount to pay the payoff charge.

Set the current system date to March 01, 2013, and create a loan contract with the following values:
- Create a payoff charge and add it to fee set.
- Link fee set with product.
- Loan Amount = $10,000
- Rate = 10%
- Terms = 4
- Time Counting Method = Month and Days
- Interest Posting Transaction Frequency = Billing Frequency
Approve and disburse the loan.
Under Prepayment Penalty Details tab, create Prepayment Penalty Configuration for payoff charge with the following values:
- Calculation Type = Fixed
- Tenor Slab Type = Term Based
- Add Seq 1 with Lower Limit = 0, Upper Limit = 3, Value = 400
Create an LPT-1 for the amount of $10,000
The system displays a warning message for the amount of $400
Save the page to create LPT.
The system creates a Payoff Charge-1 for the amount of $400.
Create an LPT2 for the amount of $400.
Select Save.
After the fix:
- The system is not displaying a warning message and sub header to create payoff charge.
- Another payoff charge is not getting created.
- Payoff Charge-1 is getting paid.
- Loan status is updated to Closed - Obligations Met.

Resolution

The issue is now resolved, and the system is not charging multiple Motor Early Payoff Fees charges to a single loan for multiple payoff payments.

Issues fixed in Q2 Loan Servicing 4.2008.73 patch

The system is not discarding the additional interest postings after performing a Rescheduling action on the Loan Balance (Jira ID: PDRFF-2911/ND-7718)

Issue Description

Upon rescheduling the loan on Loan Balance, the system is not discarding the Interest Posted of the additional interest components.

The following table describes the system behavior before and after the fix.

Capitalization on Loan	Capitalization on AIC	Behavior before the Fix	Behavior after the Fix
True	True	Regular IPTs are getting discarded. AIC's IPTs are not getting discarded(Incorrect)	Regular IPTs are getting discarded. AIC's IPTs are getting discarded. (correct)
True	False	Regular IPTs are getting discarded. AIC's IPTs are not getting discarded	Regular IPTs are getting discarded. AIC's IPTs are not getting discarded.
False	False	Regular IPTs are getting discarded. AIC's IPTs are not getting discarded.	Regular IPTs are getting discarded. AIC's IPTs are not getting discarded.

Resolution

The issue is now fixed, and the system is discarding the additional interest postings after a rescheduling on Loan Balance if the additional interest capitalization is enabled. The Additional Interest Postings after a rescheduling on Loan Balance, are not getting discarded if the additional interest capitalization is disabled.

If a Suspended Fee (frozen fee) is configured for the Payoff Fee, the system is not allowing to pay off the loan payment transactions on loan accounts (Jira ID: PDRFF-3114/ND-8020)

Issue Description

When a loan has a suspended fee (frozen fee) configuration for the payoff fees and the user is trying to do an early payoff within the suspended period (frozen period), the system is not allowing to clear such a payoff and is displaying the following error message:

Note

Rolling back the batch. Message - CL012016: Cannot apply charges. Loan account LAI-00006252 has active Frozen Fee Config FFC-15456 preventing charges on this account. - Cause null-38.

Resolution

The issue is now fixed, and the system is now clearing the payoff loan payment transactions on loan accounts with a suspended fee (frozen fee) configuration for payoff fees without an error message.

The system is not displaying the alert message on the Reschedule page, when the Disable Autocheck Maintain Delinquency flag is set to false (Jira ID: PDRFF-3279/ND-8199)

Issue Description

When a loan is rescheduled from the Reschedule page with the Disable Autocheck Maintain Delinquency flag set to false in the Org Parameters, the system is not displaying the following alert message and is, instead, incorrectly generating the preview.

Note

Rescheduling on Principal Balance. Maintain Delinquency is false. Do you want to proceed?

Resolution

The issue is now fixed and the system is displaying the alert message on the Reschedule page when the Disable Autocheck Maintain Delinquency flag is set to false in the Org Parameters.

The system is not displaying the batch details on the Process Interface Records page (Jira ID: PDRFF-3175/ND-8178)

Issue Description

Using the Salesforce Lightning Experience, go to Servicing Configuration > Batch Jobs > Data Import> View Batches and select the required batch. On the Process Interface Records page, although the system is displaying a record number in the Eligible Records, on selecting Show/Refresh records, the system is not displaying any records. This works fine in the Salesforce Classic view.

Resolution

This issue is now fixed, and the system is displaying the records from the data imports.

Issues fixed in Q2 Loan Servicing 4.2008.68 patch

The system is displaying an error message when the user is trying to reverse an LPT for a parent record with more than 200 child records assigned directly to a list (Jira ID: PDRFF-3065/ND-7861)

Issue Description

The system is displaying the following errors when the user is trying to reverse an LPT for a parent record with more than 200 child records assigned directly to a list:

Note

Error processing payment reversal for contract - LAI-00009787 - Aggregate query has too many rows for direct assignment, use FOR loop
CL010100: Unexpected DML Exception Insert failed. First exception on row 0; first error: FIELD_CUSTOM_VALIDATION_EXCEPTION, Error processing payment reversal for contract - LAI-00009787 - Aggregate query has too many rows for direct assignment, use FOR loop: [] at line 20

Resolution

The issue is now fixed by modifying the logic and the system is not displaying an error message when the user is trying to reverse an LPT for a parent record with more than 200 child records assigned directly to a list.

After a loan is rescheduled, the system is calculating the Principal Posted incorrectly on last due IPT (Jira ID: PDRFF-3099/ND-7926)

Issue Description

After a loan is rescheduled, on reducing the terms for the contract with Maintain Delinquency set to false and Reschedule Balance set to Loan Balance, the Principal Posted is not getting reduced for the discarded IPTs thus calculating the Principal Posted incorrectly.

Example to understand the behavior after the fix

Set up a Fee Set with periodic fee as follows:
- Fee Name = Periodic Fee Cap
- Fee Category = Loan
- Time of charge = Periodic Fees
- Include In Schedules=True
- Periodic Charge Start Basis = First Payment Date
- Periodic Fee Amount Type = Per Period Amount
- Include In Dues = Checked
- Enable Fee Capitalization = Checked
- Fee Calculation Method = Fixed
Set the Current System Date to March 01, 2013, and crate a loan contract with the following values:
- Loan Amount = $10,000
- Rate = 10%
- Terms = 4
- IPT and Capitalization = True
- IPT Frequency = Billing Frequency
- Payment Frequency = Monthly
- Time Counting Method = Month And Days
Move the Current System Date to April 01, 2013, and then May 01, 2013.
Reschedule the loan to set the values as follows:
- Interest Rate = 20%
- Reschedule Balance = Loan Balance
- Maintain Delinquency = False
IPT -1 and IPT-2 are discarded.

On the Loan details page, Principal/Advance Posted is updated to $0.

Before the fix, although both IPTs would be discarded, the system would incorrectly display Principal/Advance Posted as $4,937.16.
Move the Current System Date to the next Interest Posting Date, that is, June 01, 2013. The values are updated as follows:
- Principal/Advance Posted = $5,041.70
  - Previously (before the fix) posted incorrectly as $9,973.95
- Interest Posted and Capitalized = $169.80
- Fee Capitalized = $30
- Loan Balance = $10,367.24
Create LPT to pay all the Dues till Date for the Transaction amount of $5,241.50.
After paying all the Bills on the Due Date, move the Current System Date to the last Due Date.
IPT and bill are generated with the following values:
- Principal/Advance Posted = $10,167.44
- On the last IPT dated July 01, 2013, Principal Posted = $5,125.74
  - Before the fix the Principal Posted on the last IPT was $193.41 (incorrect)
Create LPT for Bill- 4 of the amount $5,211.17. The values are correctly updated as follows:
- Loan Status = Closed - Obligations met
- Excess = $0
- Principal/Advance Posted = 10,167.44

Resolution

This issue is now fixed and after a loan is rescheduled, the system is calculating the Principal Posted correctly on last due IPT generated.

During payment reversal, unpaid capitalized charge amount is getting added to the Fee Remaining field (Jira ID: PDRFF-2919/ND-7720)

Issue Description

If an unpaid capitalized charge is present on the contract, and an existing payment is reversed, Fees Remaining field is updated with this unpaid charge instead of updating the Fees Capitalized field.

This unpaid capitalized charge is not getting cleared from the Fees Remaining even after the charge is waived off.

Example to understand the behavior after the fix

Create a loan contract and associate with a fee set containing 2 capitalized fees with the following values:
- Fee Name 1
  - Fee Amount = $100 (Fixed)
  - Type=Other
- Fee Name 2
  - Fee Amount = $200 (fixed)
  - Type = Other
On March 01, 2013, 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
- Capitalization= True
- Fee Set = Fee set consisting of the above created fees
Move the Current System Date to few days after first due date and create a capitalized charge-1 (Fee Name 1). Make due payment which satisfies the charge. The values are as follows:
- Fee Paid = $100
- Fee Capitalized = $0
- Fee Remaining = $0
Add another charge (Fee Name 2) capitalized charge on the same day.
- Fee Capitalized = $200
Reverse the payment Fee Name 1.

Charge value that was paid earlier as part of the payment (Fee Name 1) now moves to Fees Capitalized and new unpaid charge value (Fee Name 2) of contract moves to Fees Remaining.
At this stage, waive the newly created charge on the contract. The values are updated as follows:
- Fee Remaining = $0
  - Before the fix the system displayed the Fee Remaining incorrectly as $200
- Fee Paid = $200
- OLT is created for Transaction Type = Charge Waive
- LPT is auto-created for the Transaction Amount = 200 (which is the paid charge created due to the Waiver action)
- Last Accrual Date = April 11, 2013
- Interest Remaining = $28.10

Resolution

The issue is now fixed and during payment reversal, the unpaid capitalized charge amount is getting added to the Fees Capitalized field correctly.

Issues fixed in CL Common Spring'23 4.2004.26

The system is displaying an error message when the user is trying to create a contract with the disbursal date and payment start date both falling on a business holiday (Jira ID: PDRFF-3084/PD-1766)

Issue Description

The system is displaying the following error message when a user is trying to create a contract with the disbursal date and payment start date both falling on a business holiday as per the Business Hours Holiday:

Note

Invalid input, schedules could not be generated

Example to understand the issue

On March 01, 2013, create a loan contract with the following values:
- Fincalc Version = 4.0 (under Additional Parameters section)
- Add a Business Hours with Saturday and Sunday as Off
- Loan Amount = $10,000
- Rate = 27%
- Terms = 364
- Is IPT Posting = True
- IPT Frequency = Billing Frequency
- Time Counting Method = Month and Days
- Payment Frequency = Monthly
Set Expected Disbursal Date as March 02, 2013 (a holiday as per Business Hours) and Payment Start Date as March 31, 2013 (a holiday as per Business Hours).
Select Save.

System displays the following error message:

Note

Invalid input, schedules could not be generated.

Resolution

The issue is now fixed, and the system is not displaying any error when the user creates a contract with the disbursal date and payment start date both falling on a business holiday.

Issues fixed in CL Common Spring'23 4.2004.25 and Q2 Loan Servicing 4.2008.64 patch

The system is displaying an apex CPU time limit exceeded error while creating a loan contract if the Compounding Frequency is set to Semi-Monthly (Jira ID: PDRFF-2891/PD-1756)

Issue Description

The system is displaying the following error message while creating and saving a loan contract with the Compounding Frequency set to Semi-Monthly:

Note

Apex CPU time limit exceeded

Example to understand issue

Create a loan contract with the following values:
- Payment Frequency = Semi-Monthly
- Is Interest Posting = True
- Capitalization = True
- Enable Compound Interest on the lending product
- Compounding Frequency = Semi-Monthly
Select Save.

The system is displaying a CPU time limit exceeded error.

Resolution

The issue is now fixed, and the system is not displaying is not displaying a CPU time limit exceeded error when the Compounding Frequency is set to Semi-Monthly.

Issues fixed in CL Common Spring'23 4.2004.25

The system is not updating the Current Term, Payment Term (Term), and the Current Maturity Date fields, when the loan is rescheduled and the Maturity Date on the contract is updated (Jira ID: PDRFF-3008/PD-1750)

Issue Description

The issue is with the Financial Calculator, where after we reschedule the loan and the Maturity Date is updated, the system is not updating the Current Term, Payment Term (Term), and the Current Maturity Date fields on the contract. The Amortization Schedule is also not getting generated.

Example to understand the behavior after the fix

Create a loan contract on March 01, 2013, with the following values:
- Loan Amount = $10,000
- Rate = 10%
- Terms = 10
- Payment Frequency = Monthly
- Interest Posting Frequency = Monthly
- Time Counting Method = Month and Days
- Fincalc Version = 4.00
Create a contract in the Partial Application status.
Then manually update the Maturity Date and the Current Maturity Date on the Contract. (Suppose the Maturity Date and Current Maturity Date are January 01, 2014, and the Term is 10.)

Now , we want to change the Maturity Date and Current Maturity Date to April 01, 2013 (without modifying the Payment Term field).
Then select the Regenerate Schedule button.

The expected result is as follows:
- Newly generated Amortization Schedule must have the last installment on April 01, 2013.
- Current Terms must be updated to 12.

Resolution

The system is now updating the Current Term, Payment Term (Term), and the Current Maturity Date fields correctly. The system is generating the Amortization Schedule too.

During a rescheduling action, the system is not considering Interest Only Payment Amount for the calculation of Interest Only Period (Jira ID: PDRFF-3038/PD-1760)

Issue Description

During a rescheduling action, when the Interest Only Payment Amount is defined for the Interest Only Period, the system is not displaying the predefined Interest Only Payment Amount under the Amount column in the Amortization schedule.

Example to understand the Issue

Create a loan contract on March 01, 2013, with the following values:
- Loan Amount = $1,00,000
- Rate = 12%
- Terms = 11
- Payment Frequency = Weekly
- Is Interest Posting = False
- Time Counting Method = Month & Days
- Actual Interest Only Payments = False
  
  Go to Custom Settings > Org Parameters > Interest Only Period Behavior and select Actual.
- Approve and disburse the complete amount.
- Go to the Reschedule page > set the Interest Only Period to 3 and Interest Only Payment Amount to $100.
- Select Preview.
  
  On the Amortization schedule, the Amount column incorrectly displays the following values for first three cycles instead of displaying the defined $100:
  - $1,021.98
  - $230.77
  - $230.77

Resolution

The issue is now fixed and the values are updated as follows:

The system is now correctly displaying the amount defined in Interest Only Payment Amount field for the Interest Only Period EMIs.
On the Amortization schedule preview, the Amount column is correctly displaying the amount as $100 for the first three cycles.
For fourth cycle on the Amortization schedule preview, Interest component correctly displays $1,414.29.

Enhancements in Q2 Loan Servicing 4.2008.64

The alert message on the reschedule page is updated (Jira ID: PDRFF-2973/ND-7739)

Enhancement Description

When a loan is rescheduled from the reschedule page with the following reschedule parameters:

Reschedule Balance = Principal Remaining (From the drop-down select Principal Remaining)
Maintain Delinquency = False (Make it False by unchecking the box)

The system currently displays the following alert message:

Note

Reschedule Balance is Principal Remaining. Maintain Delinquency is false.

The preceding alert message is now updated. Now, when a loan is rescheduled from the Reschedule page the system is displaying the following message:

Note

Rescheduling on Principal Balance. Maintain Delinquency is false. Do you want to proceed?

Issues fixed in Q2 Loan Servicing 4.2008.64

The Minimum Interest Amount is getting added again to the Payoff Amount incorrectly when the system date changes to a future date (Jira ID: PDRFF-2844/ND-7612)

Issue Description

In a loan where a minimum loan interest is defined, if the borrower makes a payment in the middle of the cycle such that the Principal Balance becomes zero and the Minimum Interest Amount is not paid off, the balance Minimum Interest charge is getting created and added to the payoff amount. This amount is getting added again to the Today's Payoff incorrectly when the system is moving to any future Date.

Example to understand the issue

Let us create a contract on March 1, 2013, with the following values:
- Amount = $10,000
- Rate = 10%
- Term = 1
- Pay Frequency = Single-Payment
- Interest Posting Frequency = Monthly
- Time Counting Method = Month and Days
- Minimum Interest Option = Minimum Interest Period
- Minimum Interest Period (in days) = 180
Approve and disburse the loan.
In the Additional Parameters section, verify that the value of Minimum Interest Amount is displayed as $491.67.
Move the Current System Date to May 10, 2013.

Since the Current System Date is moved by two cycles (monthly) the system creates two IPTs.

For the period between May 1, 2013, and May 10, 2013, the system updates the different parameter values as follows:
- Interest Accrued = $25
- Today's Payoff = $10,491.67
Let us create an LPT of amount $10,291.67.
The system creates Minimum Interest Charge of amount $300 which has the following values:
- Total Amount Due = $200
- Amount Paid = $100
- Today Payoff = $200
- Loan Balance = $0
- Principal Remaining = $0
Let us go to May 11, 2013.

The Loan Payoff must be $200. Since the Loan Balance is $0 no interest must be accrued, however, the system is adding a Minimum Interest Amount of $300 to today's payoff.
Let us move the current system date to June 1, 2013 the next Due Date.

System is not posting an IPT of $0 amount on June 1, 2013.

Resolution

The issue is fixed now and the Minimum Interest Charge is not getting added to the payoff again.

The system is not displaying the correct interest in the Interest field, during interest waive off using the percentage field on the Waiver Action page (Jira ID: PDRFF-2813/ND-7730)

Issue Description

During the interest waive off, on selecting 100% as waive percentage, the system is incorrectly displaying waive amount as the total regular interest posting amount + total additional interest posting amount, instead of displaying only the total regular interest posting amount.

After completion of the waiver action activity using the percentage field on the Waiver Action page, the regular interest is getting waived off but the system is still displaying the additional interest as the Excess on the loan.

Example to understand the issue

Create a loan contract on March 01, 2013, with the following values:
- Loan Amount = $10,000
- Rate = 10%
- Terms = 10
- Payment Frequency = Monthly
- Interest Posting Frequency = Monthly
- Time Counting Method = Month and Days
Add the following Additional Interest Component (AIC) details to the contract then approve and disburse the loan:
- Interest Type = Line Interest
- Interest Bearing Principal = Credit Limit
- Time Counting Method = Month and Days
- Interest Posting Frequency = Billing Frequency
- Interest Rate = 5.0%
Move the current system date to April 10, 2013.
On the AIC, the values of the interest posted is $41.67, but on the Loan Details page interest posted is $83.33.
Go to Quick Menu > Waiver Action > Waiver Type select Interest Waiver
- Waive Percentage = 100.00%
- Transaction Date = April 10, 2013.
The Waiver Amount is auto populated.
System incorrectly displays Waive Amount = $125 ($83.33 (Loan Interest Posted) + $41.67 (AIC's Interest Posted))

On Interest Waiver page, the system must display only the Waive Amount as $83.33.

Resolution

This issue is now fixed and the system is displaying only the total regular interest posting amount, after completion of the waiver action using the percentage field on the Waiver Action page.

The system is displaying an error when the user is trying to reverse an LPT for a parent record with more than 200 child records assigned directly to a list (Jira ID: PDRFF-3065/ND-7858)

Issue Description

The system is displaying the following errors when the user is trying to reverse an LPT for a parent record with more than 200 child records assigned directly to a list:

Note

Error processing payment reversal for contract - LAI-00009787 - Aggregate query has too many rows for direct assignment, use FOR loop
CL010100: Unexpected DML Exception Insert failed. First exception on row 0; first error: FIELD_CUSTOM_VALIDATION_EXCEPTION, Error processing payment reversal for contract - LAI-00009787 - Aggregate query has too many rows for direct assignment, use FOR loop: [] at line 20

Resolution

The issue is now fixed by modifying the logic and the system is not displaying an error when the user is trying to reverse an LPT for a parent record with more than 200 child records assigned directly to a list.

Issues fixed in Q2 Loan Servicing 4.2008.63

The system is not generating Loan Transaction Summary for Additional Interest - Excess Payoff type of transaction (Jira ID: PDRFF-2766/ND-7582)

Issue Description

If a payoff LPT transaction is created to payoff the loan on a non-billing date, the system calculates the regular interest and the additional interest components for the loan, but does not post them on a non-billing date. Then on the payoff date, the system generates the Interest Posting Excess-Payoff and Additional Interest Excess-Payoff and these components are paid off by the payoff amount.

The system is generating a Loan Transaction Summary for Interest Posting Excess-Payoff transaction but not for Additional Interest Excess-Payoff transaction.

Resolution

The issue is now fixed and the system is generating a Loan Transaction Summary both for the Additional Interest Excess-Payoff transaction and the Interest Posting Excess-Payoff transaction.

Issues fixed in Q2 Loan Servicing 4.2008.58

The system is not managing the Excess payments correctly, resulting in incorrect charge updates and issues regarding the waivers and adjustments (Jira ID: PDRFF-2729/ND-7583/ND-7453)

Fixed Versions

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

Q2 Loan Servicing Spring'23 (4.2008.58)

Issue Description

When processing extra payments, the system must add the excess amount to the existing balance. However, for the waiving of the paid charges, the system is resetting the excess amounts to zero incorrectly, which is resulting in updates instead of additions to the existing balance.

Additionally:

Reversing payment transactions for charges results in the creation of new charges instead of marking existing charges as unpaid.
During the waiver action selection for Paid Charge waivers, all charges, including those that are actually paid and those for which payment was reversed, are displayed by the system.
Selecting the adjustment type Excess and waiving any paid charge replaces the previous excess balance with the amount associated with the waived charge.

Resolution

This issue is now fixed, and the logic is modified such that the existing excess amount is added in the amount calculated after paid charge waiver excess amount.

When generating a future dated Payoff Quote, the system is displaying an error (Jira ID: PDRFF-2881/ND-7550)

Fixed Versions

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

Q2 Loan Servicing Spring'23 (4.2008.58)

Issue Description

When generating a future dated Payoff Quote, the system is displaying the following error.

Note

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

The issue is currently arising during the review of a contract, which includes over 100 LPTs, a repayment schedule, repayment schedule summary, bill, contract conditions, and more than 50 charges. Specifically, the error occurs when attempting a future dated payoff and selecting the Preview Payoff option.

Example to understand the issue

Create a loan contract with the following bulk records:
- Number of charges = 60
- Number of LPTs = 130
- Number of Bills = 60
- Number of IPTs = 90
Go to payoff quote page.
Enter a future date and select Preview Quote or Generate Quote.

The system displays the following error message:

Note

Aggregate query has too many rows error

Resolution

This issue is now fixed and the logic is modified such that Preview Quote or Generate Quote are working properly.

Enhancements made in the Q2 Loan Servicing 4.2008.51 patch

Calculation and application of payoff fees during a payoff quote and a payoff for pre-closure using the Pay-Off Fees as the Time of Charge in the prepayment penalty fee configuration (Jira ID: PDRFF-2665/ ND-7323)

Enhancement Description

With this patch release, Q2 Loan Servicing now provides you with the ability to charge pay off fees using a separate prepayment penalty configuration while making a payoff for pre-closure or while calculating a payof fee during generation of a payoff quote for pre-closure of a loan.

Earlier, the system provided you with the ability to charge fees for both pre-payment and pre-closure (payoff) in a single configuration where Time of Charge was Prepayment Penalty.

Now, the system has the ability to charge for the pre-payment and pre-closure (payoff) using separation configurations as follows:

Prepayment: These can be any unscheduled principal repayments where a fee is charged using the prepayment penalty fee configuration where Time of Charge is Prepayment Penalty.
Payoff for pre-closure: This is a complete payoff before the maturity of the contract where a fee is charged using the prepayment penalty fee configuration where Time of Charge is Pay-Off Fees.

To enable this enhancement, you must revert the changes made in Summer'22 (3.9001) by running the following script:

Note

This migration script reverses the pick list value migration of the Time of Charge field on the Fee object from "Prepayment Penalty" back to "Pay-Off Fees." Originally, during the Summer'22 release, "Pay-Off Fees" were consolidated into "Prepayment Penalty" due to system limitations. Now, with this patch release, the system supports both fee types, necessitating the rollback of the migrated data.

To migrate:

Open Developer Console.
Go to Query Editor.
Copy, paste and execute the following query and make a note of the count:

SELECT count(Id) FROM loan__Fee__c WHERE loan__Time_of_charge__c = 'Prepayment Penalty'
Go to Debug > Open Execute Anonymous Window.
Copy and paste the following code:

List<loan__Fee__c> ppFeeList = [

SELECT Id, Name,

loan__Time_of_charge__c,

loan__Prepayment_Penalty_Type__c

FROM loan__Fee__c

WHERE loan__Time_of_charge__c = 'Prepayment Penalty'

LIMIT 10000

];

if (!ppFeeList.isEmpty()) {

System.debug(LoggingLevel.ERROR, 'Number of Fees to be updated: ' + ppFeeList.size());

for (loan__Fee__c ppFee : ppFeeList) {

ppFee.loan__Time_of_charge__c = 'Pay-Off Fees';

}

Update ppFeeList;

}
Select Execute.
Go to Query Editor.
Copy, paste, and execute the following query and make a note of the count. If the count matches that in Step 3, then that means that the migration job has run successfully.

SELECT count(Id) from loan__Fee__c WHERE loan__Time_of_charge__c = 'Pay-Off Fees'

Issues fixed in CL Common Spring'23 4.2004.21

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-2695/ND-7450)

Fixed Version

This issue has been fixed in the following versions:

Q2 Loan Servicing Spring'23 (4.2008.51)
CL Common Spring'23 (4.2004.21)

Note

If you install the above latest Q2 Loan Servicing Platinum patch (3.6019.215), then ensure that you install the above latest CL Common Platinum patch (3.6003.25) 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 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.

Issues fixed in Q2 Loan Servicing 4.2008.51

Periodic Charge Dynamic Job is failing with an error message (Jira ID: PDRFF-2860/ND-7541)

Fixed Version

This issue has been fixed in the following version:

• Q2 Loan Servicing Spring'23 (4.1012.41)

Issue Description

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

Note

First error: Apex heap size too large: 13535833

Resolution

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

Issues fixed in Q2 Loan Servicing 4.2008.48

Add a pop-up message when the when Reschedule Balance is set to Principal Remaining and Maintain Delinquency is set to False (Jira ID: PDRFF-2428/ ND-7167)

Fixed Versions

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

Q2 Loan Servicing Spring'23 (4.2008.48)

Issue Description

The system is allowing for rescheduling to take place with the Reschedule Balance set at Principal Remaining. A pop- up message must be displayed only when the Reschedule Balance is set to Principal Remaining and Maintain Delinquency is set to False. The system must not display a pop-up message for any other combinations.

Resolution

This issue is fixed now and the system now displaying the required pop-up message.

Issues fixed in Q2 Loan Servicing 4.2008.44

The system is not displaying the last zero after the decimal point (Jira ID: PDRFF-2432/ND-7086)

Fixed Version

This issue has been fixed in the following version:

Q2 Loan Servicing Spring'23 (4.2008.44)

Issue Description

After an upgrade, the system is displaying the value in a different format than usual. Normally, the system displays two digits after the decimal point, for example, $77.10 or $77.00. However, it is currently only displaying one digit after the decimal point $77.1 or $77 and is ignoring the last zeros after the decimal point.

Resolution

This issue is now fixed. The system is now displaying the zeros after a decimal point.

The system is updating the Transaction Amount incorrectly after displaying an error message (Jira ID: PDRFF-2676/ND-7244)

Fixed Version

This issue has been fixed in the following version:

Q2 Loan Servicing Spring'23 (4.2008.44)

Issue Description

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

Note

You are trying to enter more than 2 decimal places, which is not permitted for this field. Given value will be rounded off to 2 decimal places while saving

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

Example to understand the issue

On Record a Payment page let us add a Transaction Amount which includes comma and has three or more digits after the decimal point.
- Transaction Amount= 1,234.567
Immediately after entering amount, the system displays the following message:

Note

You are trying to enter more than 2 decimal places, which is not permitted for this field. Given value will be rounded off to 2 decimal places while saving
On selecting OK, the system rounds off the value to upto two digits after the decimal point and updates the value as follows:
- Transaction Amount = 1,234,57 (Incorrect)

Resolution

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

The system is displaying an error message if the Interest Only Period field is saved without any value while rescheduling a contract (Jira ID: PDRFF-2678/ND-7263)

Fixed Version

This issue has been fixed in the following version:

Q2 Loan Servicing Spring'23 (4.2008.44)

Issue Description

The Interest Only period on Reschedule page is auto populated with a number greater than zero, and it keeps incrementing every time another rescheduling is performed on the loan. And upon clearing the Interest Only Period field value and saving the rescheduling, the system is displaying the following error message:

Note

Interest Only Period: Interest Only Period can't be negative

Example to understand the issue

Set the Current System Date to March 1, 2013. Create a loan contract with the following values then approve and disburse it:
- Loan Amount = $10000
- Terms = 60
- TCM = Actual Days
- Pay Frequency = Monthly
- IPT Frequency = Weekly
- Rate = 24.49%
Reschedule the loan to change Payment Frequency value from Monthly to Weekly.
Select Preview and then Save.
Again, go to the Reschedule page and check the value of Interest Only Period.

It is observed that the Interest Only period on Reschedule page is auto populated with a number greater than zero, and it keeps incrementing every time another rescheduling is performed on the loan. And upon clearing the Interest Only Period field value and saving the rescheduling, the system is displaying the following error message:

Note

Interest Only Period can't be negative

Resolution

This issue is fixed. The system now is not calculating the Interest Only Period correctly as Zero and hence the system does not display the exception error.

Issues fixed in CL Common 4.2004.20

User is unable to attach files in Notes and Attachments tab for CL Loan object (Jira ID: PDRFF-2581/PD-1694)

Fixed Version

This issue has been fixed in the following version:

CL Common Spring'23 (4.2004.20)

Issue Description

The system is not allowing to attach the files in Notes and Attachment tab for CL Contract because the extension types for some files are exceeding the 255 characters permitted in the Allow only these file types field in CL Platform settings.

Resolution

This issue is fixed now. As part of fix, the extension type value is assigned as per the Salesforce standard which is of a smaller length.

The following table explains the extension types of various files:

On File Systems	In salesforce
docx	WORD_X
doc	WORD
pptx	POWER_POINT_X
ppt	POWER_POINT
xlsx	EXCEL_X
xls	EXCEL

Issues fixed in Q2 Loan Servicing 4.2008.41

The Total Pre-Paid Fees is not getting added in the loan amount while a loan is converted from an application to a contract (Jira ID: PDRFF-2598/ND-7132)

Fixed Version

This issue has been fixed in the following version:

Q2 Loan Servicing Spring'23 (4.2008.41)

Issue Description

While converting a loan application to a loan contract using the contract creation API , the pre-paid fees is not getting added in the loan amount. Because of this after disbursal, the pre-paid fees is not getting added to the disbursal amount .

Resolution

This issue is fixed now, and the pre-paid fees is getting added in the loan amount successfully.

Interest is getting updated incorrectly in Amortization Schedule when a loan is rescheduled (Jira ID: PDRFF-2281/ND-7008)

Fixed Version

This issue has been fixed in the following version:

Q2 Loan Servicing Spring'23 (4.2008.41)

Issue Description

While rescheduling a non-delinquent loan, the interest amount of first month is getting added incorrectly to the interest component of next month. This results in an incorrect Amortization Schedule.

Example to Understand the Issue

Let us create a loan contract and verify the interest components in the Repayment Schedule.

Let us create a loan contract with the following values:
- Loan Account = $10,000
- Term = 10
- TCM = Month And Days
- Payment Frequency = Monthly
- IPT Frequency = Monthly
- Rate = 10%
- Interest Type= Fixed
- Maintain Delinquency = True
Move the Current System Date to March 1, 2013, approve and disburse the loan.
Move the Current System Date to April 1, 2013.
Go to the Reschedule page, keeping the pre-filled values unchanged, select Preview.

Since Maintain Delinquency is set to true while rescheduling, the interest posted till April 1, 2013 must not get added to second billing cycle. But the interest amount of first month is getting added to the interest component of second month after rescheduling.

Resolution

The issue is now fixed. The Amortization Schedule is now reflecting the correct interest amount.

The system is calculating incorrect Fees Remaining and Fees Capitalized (Jira ID: PDRFF-2578/ND-7127)

Fixed Version

This issue has been fixed in the following version:

Q2 Loan Servicing Spring'23 (4.2008.41)

Issue Description

The Fees Remaining field displays a negative value and the value of Fees Capitalized is incorrect.

Example to understand the issue

Let us see an example to understand this issue:

Let us create a contract with Is Interest Posting and Is Capitalization Enabled flags as True.

Note

Fee Set should contain a Periodic Fee with the following fields marked as True: Include In Dues, Include In Schedules and Enable Fee Capitalization.
Move the system's date to the Second Due Date.

Note

Do not create the first cycle payment.
Let us disburse the contract on June 3, 2017.
On the first due date, July 3, 2017, the bill and periodic fee gets created.
Move the system date to August 3, 2017.
- This creates the second bill and periodic fee.
- The Fee Capitalized is $20.
Create an LPT for the first due date and satisfy the bill.
- In the Contract History, we can see the following: “Fees Capitalized from 20 to 10."
Create an LPT for the second due date.
- Now on the contract history, the Fees Remaining is seen as -10.
- If we see the LPT snapshot for the second payment, the Fees Capitalized will still be 20 and Fees Remaining will be -10.

Resolution

The issue is observed when the second LPT is paid. At that time, a new IPT is generated where the charge is capitalized again, due to which the Fees Remaining is getting calculated to a negative value and the Fees Capitalized is increased from 10 to 20.

Issues fixed in Q2 Loan Servicing 4.2008.38

Interest Posting Transaction created by an LPT is not getting linked with that LPT (Jira ID: PDRFF-2529/ND-7110)

Fixed Version

This issue has been fixed in the following version:

Q2 Loan Servicing Spring'23 (4.2008.38)

Issue Description

When a payment is cleared by the LoanPaymentTxnClearingDynamicJob job, it must generate an Interest Posting Transaction and creates records for the related Interest Posting - Loan Payment (IPLP) if they are not already in the contract. However, when the job runs, it creates the IPLP record with no value getting displayed in the Interest Posting Transaction field of that record. This means that the IPT is not getting linked with that LPT, which ideally must be linked because it connects the LPT and the IPT objects.

Example to understand the issue

Let us create a loan with the following details:
- Loan Amount = $10,000
- Interest Rate = 10%
- Time Calculating Method = Month And Days
- Payment Frequency = Monthly
- Interest Posting Transaction = Billing Frequency
Let us go to March 1, 2013. Create, approve and disburse the loan.
Let us go to next due date without running batch jobs.
Run the Billing job.
Without running the IPT job, create an LPT of the bill's amount.
The system creates an IPT itself and marks it paid- Bill-1.
Let us go to LPT > Interest Posting - Loan Payment (related list) > Interest Posting - Loan Payment Details page.

It is observed that the Interest Posting Transaction field, in the Interest Posting - Loan Payment Details page, displays no value. It must display the IPT ID that is linked to the LPT.

This issue is occurring because when the Payment Application Mode is Date, and when an LPT is created, the system is unable to create a link between IPT and IPLP.

Resolution

The issue is fixed as the code has been updated to add the link between IPT and IPLP resulting in system now being able to display the relevant IPT ID in the Interest Posting Transaction field by the LoanPaymentTxnClearingDynamicJob job.

Issues fixed in Q2 Loan Servicing 4.2008.14

The Interest Remaining field is getting updated incorrectly when an Installment Payment is created on a delinquent contract (Jira ID: PDRFF-1379/ND-5996/ND-6306/ND-6307/ND-6380)

Issue Description

When an Installment Payment is created on a delinquent FAMZ loan contract, the Interest Remaining is getting calculated incorrectly as twice the expected value.

Note

Installment payment is the regularly scheduled payment that includes repayment of a portion of the principal amount borrowed, and also the payment of interest on the debt.

Note

From the Hydrogen release, borrowers can repay the future schedules in advance at any point in time in Flexible-AMZ type loans irrespective of the due date. This feature allows the lenders to collect payment for future installments including principal and interest. This is achieved by closing the interest posting transaction by calculating the extra interest expected to be posted from the current date to the installment date. Until the installment date, the loan account is locked and no other loan actions, such as rate change and term extension can be performed.

Note

For this option to be available, the Installment Payment flag must be enabled.

Example to Understand the Issue

Let us say today is January 18, 2022, and we create an FAMZ contract with the following details and disburse it:
- Loan Amount = $10,000
- Time Counting Method = Actual Days
- Pre Bill Days = 28 Days
- Contract Start Date = January 18, 2022
- Payment Frequency = Monthly
- First Payment Date = February 18, 2022
- Interest Posting Frequency = Monthly
- Term = 10 months
- Rate = 10%
- Interest Posting Enabled = True
Now, as we move on to February 18, 2022, the following two bills get generated:
- The February 18, 2022, bill
- The March 18, 2022, bill
  
  Note
  
  As the Pre Bill Days is defined as 28, bills get generated 28 days before the due date.
As we move on to February 21, 2022, let us create an Installment Payment that satisfies the delinquent bill.

This payment includes the February and March bill amounts. As the payment is an Installment Payment, the system accrues future interest till March 18 and saves it in the Interest Remaining field and the Interest Posting Transaction (IPT) gets closed.
Let us move on to March 18, 2022.

The system, internally, reopens the closed IPT, again accrues interest till March 18 and adds to the Interest Remaining.

This issue is occurring because the Interest Posting Transaction (IPT) that was closed is getting posted again leading to the IPT amount being twice the actual amount. Thus, due to the IPT amount being twice the actual value, the Interest Remaining is also getting calculated as twice the actual amount.

Resolution

This issue is fixed as the logic has been updated to restrict the reposting of the IPT that is already closed. Hence, the Interest Remaining is updated correctly after the Installment Payment.

Interest Remaining is getting updated incorrectly when an ad hoc payment is reversed that results in a loan restructure (Jira ID: PDRFF-1495/ND-6064/ND-6299/ND-6302)

Issue Description

In an FAMZ contract, when an ad hoc payment is reversed resulting in the contract getting restructured, the Interest Remaining is getting updated incorrectly.

Example to Understand the Issue

Let us perform the following steps to understand this issue:

Let us create an FAMZ Lending Product with the following details:
- Excess Threshold % for Reschedule = 1%.
  
  Note
  
  The Reschedule Status field is used to mark the loans that are to be rescheduled when an LPT amount is higher than the threshold defined in Excess Threshold % for Reschedule. All such loans will be rescheduled in EOD processing.
- Payment Application Mode = Future Dues
Now let us go to August 13, 2012.
Let us say we create a contract on August 3, 2012, with the following details, and disburse it:
- Loan Amount = $10,000.
- Interest Rate = 10%.
- Payment Frequency = Monthly.
This sets the First Payment Date to September 3, 2012, and the Amortization Schedule gets generated for the following dates: September 3, 2012, October 3, 2012, November 3, 2012, till August 3, 2013, and the Due Amount for each schedule is $879.19.

It is observed that the system accrues the interest from August 3, 2012, to August 13, 2012, and the value is as follows:
- Interest Accrued = $27.40. = 10,000 * 10/365 * 10/100.
Now let us create an ad hoc payment of $1,000 with the Transaction Date as August 13, 2012, and clear it.

The system updates the contract's Reschedule Status to Pending because of this payment.
Let us go to August 14, 2022.

It is seen that the system reschedules the contract successfully and updates the Interest Remaining field value. The system updates the contract fields as follows:
- Principal Remaining = $9,000
- Principal Paid = $1,000
- Last Accrual Date = August 13, 2012
- Interest Remaining = $27.40
- Interest Accrued = $2.46 (This is interest accrued for 1 day.)
- Reschedule Status = Success
- The Amortization Schedule also gets generated for the following dates: September 3, 2012, October 3, 2012, November 3, 2012, till August 3, 2013, and the Due Amount for each is $791.51.
Now let us go to August 26, 2012.

It is seen that the system accrues the interest from August 14, 2012, to August 26, 2012, as per the new schedule, and the values are as follows:
- Interest Remaining: $27.40
- Interest Accrued: $32.05
Now on August 26, 2012, let us reverse the ad hoc payment that was created in step 4.

This must update the values as follows:
- The Amortization Schedule should revert to the original one with the same following dates: September 3, 2012, October 3, 2012, November 3, 2012, till August 3, 2013, and the Due Amount for each schedule should be as the original one, which is $879.19.
- Interest Remaining = $0
- Interest Accrued = $63.01
- The interest is to be calculated on the original principal amount that is $10,000. (10,000 * 10/100 * 23/365, where days = Aug 26 - Aug 3 = 23 days.)
- Principal Remaining = $10,000
- Principal Paid = $0
Let us go to the next payment date, which is September 3, 2012.

The Interest Remaining must be updated to $84.93 ( = 10,000 * 10/100 * 31/365, as August has 31 days and the interest is calculated from August 3 to September 3), but this is not the case.

It is seen that the Interest Remaining field is getting updated with an incorrect value.

Resolution

The issue is fixed, and now when an ad hoc payment is reversed, the Interest Remaining field is getting updated correctly.

The Interest Remaining is incorrectly calculated when payments are skipped and loan is rescheduled (Jira ID: PDRFF-1586/ND-6097/ND-6314/ND-6315)

Issue Description

In an FAMZ contract, when payments are skipped and the loan is rescheduled, the interest amounts in the schedule are getting incorrectly calculated and hence the Interest Remaining is getting incorrectly updated too.

Example to Understand the Issue

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

Create a loan with the following details and then approve and disburse it:
- Amount = $100,000
- Contract Date = January 3, 2022
- Payment Frequency = Monthly
- First Payment Date = February 3, 2022
- Term = 60 Months
- Interest Rate = 8%
- Pre-Bill Days = 28
Let us go to February 3, 2022.

It is observed that the system generates a bill as per the schedule.

AMZ schedule amount is 2,027.64 (where Principal = 1,360.97 and Interest =666.67.)
Let us pay and satisfy the bill of $2,027.64.
Now let us go to February 7, 2022, and reschedule the loan to change the Repayment Start Date to August 3, 2022 by going to Loan Actions > Reschedule > Transaction Date = 2/7/2022, Repayment Start Date = 8/3/2022.

This way we are skipping months for payment to August 3.

Note

August and September are Interest only Payments.
Move the system date to August 3, 2022.
Create a payment transaction of amount 2,094.47.
Let us reschedule the loan to change the Repayment Start Date to September 3, 2022, by going to Loan Actions > Reschedule > Transaction Date = 8/3/2022, Repayment Start Date = 9/3/2022.
The following are observed:
- The system calculates the interest from February 3, 2022, to July 3, 2022 on the scheduled balance as follows = 98,639.03 * 8/100 * 150/360 = 3,287.98 and assigns it to the Interest Remaining. (where 98,639.03 = 100,000 - 1360.97.)
- This amount is more than the payment amount, which is $2,027.64. Hence, the system distributes the calculated Interest Remaining value in subsequent schedules by deducting the remaining interest amount to be paid from the due Amount in each schedule till there is no more interest left. Thus this interest of 3,287.98 must get split in the next schedules August 3, 2022, September 3, 2022, and October 3, 2022 schedules as 1436.88 + 1436.88 + 414.22 = 3287.98. You can refer to the following image.
After clicking Preview to preview the rescheduling:
- The interest of the September 3, 2022, schedule must have the interest = 2,094.47 as seen in the following schedule ( = 1436.88 + 657.59). But this is not the case, and so Interest Remaining is getting incorrectly calculated when moved to the next due date, which is September 3, 2022.
- The interest of the October 3, 2022, schedule must have the interest = 1,071.81 ( = 657.59 + 414.22). But this is not the case, and so Interest Remaining is getting incorrectly calculated when moved to the next due date, which is October 3, 2022.

Resolution

The issue is fixed now, and the system is calculating the interest amounts correctly after the rescheduling.

The Interest Remaining field value is getting incorrectly updated after the reversal of an ad hoc payment that had rescheduled the loan (Jira ID: PDRFF-1605/ND-6233/ND-6292/ND-6293)

Issue Description

In an FAMZ loan contract, when a loan is rescheduled due to an ad hoc payment and then the payment is reversed, the system is updating the Interest Remaining and other fields incorrectly.

Example to Understand the Issue

Let us create an FAMZ contract with the following details and disburse it:
- Loan Amount = $60,000
- Contract Start Date = August 27, 2012
- Payment Frequency = Monthly
- Term = 12 months
- Interest Rate = 16%
- Pre Bill Days=15
Let us go to September 3, 2012, and reschedule the contract by updating the Repayment Start Date as October 27, 2012.

The Interest Remaining and Last Accrual Date field values are updated to $160 and September 3, 2012, respectively, and the amortization schedules are accordingly generated.
Let us go to September 10, 2012, and create an LPT of $5,000 with the Transaction Date as September 10, 2012, and clear it.

Interest Accrued is updated to $186.67 for 7 days (from September 3 to September 7).

LAD is updated to September 10, 2012.

As the Rescheduled Threshold Crossed flag is set to true in LPT and it is an ad hoc payment, the complete payment goes towards the principal instead of going to Excess, and the Reschedule Status is updated to Pending.
Now let us go to September 12, 2012.

The SOD jobs run, and the contract is rescheduled.

Interest Remaining is updated to $346.67 and Interest Accrued is updated to $48.89.
Reverse the LPT of $5,000 created in step 3.

The expected behavior must be as follows:
- Interest Remaining = $160
- LAD must change from September 10, 2012, to September 3, 2012.
- Interest Accrued must be recalculated from September 3 to September 12 as $240.
- Old IPT must be discarded and a new IPT must be created in an Open status.
- LAD on new IPT must be set to September 9, 2012.
But the actual behavior observed is as follows:
- The LPT is reversed but the Interest Remaining is not getting updated correctly in the open IPT after the excess threshold LPT reversal. Interest Remaining remains unchanged as $346.67.
- LAD is not updated to September 3, 2012. It remains unchanged.
- Hence, many other fields are also getting incorrectly updated.
Now let us go to October 27, 2012.

As the billing frequency is monthly the second Interest Posting Transaction is created.

It is observed that the Interest Posted amount on the IPT and the Interest Remaining on the contract are not in sync.

Resolution

This issue is fixed, and the Interest Remaining and all others fields are now getting calculated correctly after reversing the ad hoc payment and the loan is rescheduled.

The required Interest Posting Transactions are not getting discarded after reversing the excess payments (Jira ID: ND-4887/ND-6506/ND-6508/ND-6509)

Issue Description

In an FAMZ loan contract, when an excess payment (that has crossed the excess threshold percentage) is reversed, the IPTs are not getting discarded and the IPT amount is getting added to the Interest Remaining.

Example to Understand the Issue

Let us create an FAMZ loan contract with the following details:
- Loan Amount = $10,000
- Contract Start Date = January 1, 2013
- Payment Start Date = February 1, 2013
- Payment Frequency = Monthly
- Interest Posting Frequency = Monthly
- Excess Threshold % for Reschedule = 5.00
- IPT enabled = True
- Pre-bill days = 5
- Interest Rate Change Method = Change Payment Amount
Let us approve and disburse the loan contract.

AMZ schedule gets created with EMI amount = $879.16.

Let us perform the actions on dates as described in the following table:

Step number	Current System Date	Actions	Results
1.	First bill date February 1, 2013	None	The system updates the values as follows: Interest Posted = 0.00 Interest Remaining = $83.33 Interest Accrued = $0.00 Principal/Advance Remaining = $10,000 Bill gets generated with amount = $879.16 Two IPTs get created: IPT1 with due date of February 1 is Closed of amount $83.33. IPT2 with due date of March 1 is Open.
2.	Second bill date March 1, 2013	None	The system updates the values as follows: Interest Posted = 0.00 Interest Remaining = $160.03 (= IPT1 + IPT2 = 83.33 + 76.70) Interest Accrued = $0.00 Principal/Advance Remaining = $10,000 Bill gets generated with amount = $879.16 Three IPTs get created: IPT1 with due date of February 1 is Closed of amount $83.33. IPT2 with due date of March 1 is Closed of amount $76.70. IPT3 with due date of April 1 is Open.
3.	On the same date, later	Make an excess payment of amount $3,000 (The excess amount must cross the excess threshold%).	This means that an LPT (Loan Payment Transaction) of an amount higher than the bill amount gets created and the bill gets paid. The system updates the values as follows: Reschedule Status = Pending Last Accrual Date (LAD) = March 1, 2013 Interest Posted = 0.00 Interest Remaining = 0 as the bill gets paid due to excess payment Interest Accrued = $0.00 Principal/Advance Remaining = $7160.03 Both the bills of February and March gets marked as Payment Satisfied LPT gets created and marked as cleared Following two IPTs that were Closed are marked as Paid: Closed IPT1 with due date of February 1 of amount $83.33 is marked Paid. Closed IPT2 with due date of March 1 of amount $76.70 is marked Paid. IPT3 with due date of April 1 remains Open with no change.
4.	The next day that is March 2, 2013	None	The system updates the values as follows: Reschedule Status = Success Last Accrual Date (LAD) = March 1, 2013 Interest Posted = 0.00 Interest Remaining = 0 Interest Accrued = $1.99 for one day Principal/Advance Remaining = $7,160.03 No change in the Bills No change in the LPT. Following two IPTs that were Closed are marked as Paid: Closed IPT1 with due date of February 1 of amount $83.33 is marked Paid. Closed IPT2 with due date of March 1 of amount $76.70 is marked Paid. IPT3 with due date of April 1 remains Open with no change. An Other Loan Transaction (OLT) with Transaction type as Reschedule gets created and a new schedule gets generated with the same amount $879.16.
5.	Third bill date of April 1, 2013	None	The system updates the values as follows: Last Accrual Date (LAD) = April 1, 2013 Interest Posted = 0.00 Interest Remaining = $59.67 Interest Accrued = 0 Principal/Advance Remaining = $7160.03 A bill of amount $879.16 gets generated Total 4 IPTS created 3-Closed (83.33 & 76.70,59.67) 1-Open (due date 5/1/2013 ) Following three IPTs are Closed: IPT1 with due date of February 1 of amount $83.33 is marked Paid. IPT2 with due date of March 1 of amount $76.70 is marked Paid. IPT3 with due date of April 1 of amount $59.67 is marked Paid. IPT4 is created with due date May 1, 2013, and is Open.
6.	Fourth bill date of May 1, 2013	None	The system updates the values as follows: Last Accrual Date (LAD) = May 1, 2013 Interest Posted = 0.00 Interest Remaining = $112.51 Interest Accrued = 0 Principal/Advance Remaining = $7160.03 Fourth bill of amount $879.16 gets generated Following four IPTs are Closed: IPT1 with due date of February 1 of amount $83.33 is marked Paid. IPT2 with due date of March 1 of amount $76.70 is marked Paid. IPT3 with due date of April 1 of amount $59.67 is marked Paid. IPT4 with due date of May 1 of amount $52.84 is marked Paid. IPT5 is created with due date June 1, 2013, and is Open.
7.	On the same date, later	Reverse the excess payment created on March 1, 2013 (mentioned in Step 3) by clicking Repayment Transaction Reversal on that LPT.	The system must updates the values as follows: Last Accrual Date (LAD) = March 1, 2013 Interest Posted = 0.00 Interest Remaining = $160.03 Interest Accrued = 0 All the IPTs till June 1 must get marked as unpaid. IPTs of due dates April 1, May 1, and June 1 must get discarded. (Once they are discarded, they get recreated later.) Following three IPTs must remain Closed: IPT1 with due date of February 1 of amount $83.33 must be marked Paid. IPT2 with due date of March 1 of amount $76.70 must be marked Paid. IPT3 with due date of April 1 of amount $59.67 must be marked Paid. IPT4 with due date of May 1 of amount $52.84 must remain Open. Bills with due dates April 1 and May 1 must get marked as non primary. Only bills with due dates of February 1 and March 1 must be marked primary. The amortization schedule must get back to its previous state. The excess LPT must get marked as reversed. The OLT with Transaction Type as Reschedule that was created earlier must get marked as reversed. Next Due Date must get updated to April 1, 2013 Next Due Generation must get updated to March 27, 2013 (because of pre bill days being 5) Interest Remaining must not include April and May Interest Posted amounts. However, the values are updated as follows: IPTs of due dates April 1, May 1, and June 1 are not getting discarded. Interest Remaining includes April and May Interest Posted amounts too.

Resolution

This issue is now fixed, the required IPTs are getting discarded successfully and the Interest Remaining is correctly calculated.

Excess principal payment is not triggering the automatic restructuring of the loan (Jira ID: ICAR-24/PDRFF-1899/ND-6469)

Issue Description

When an excess principal payment is made in an FAMZ loan contract, the loan is not getting automatically restructured and the Reschedule Status is not changing to Pending.

Example to Understand the Issue

Let us create an FAMZ loan contract with the following details:
- Payment Frequency = Monthly
- Interest Posting Frequency = Monthly
Move the system date by a few days ahead.
Make a payment for the contract with the Spread Manually Flag set to true such that the entire amount must go towards the principal component.
On saving this payment transaction, the LPT is cleared.

Note

The Reschedule Threshold Crossed is set to false.

The Reschedule Status on loan must change to Pending, but it is not changing to Pending. And hence, the subsequent restructuring of the loan is also not triggered.

Resolution

This issue is now fixed.

As part of the fix, the system now restricts the Manual Payment for FAMZ loans if the loan is not in Active Good Standing status.

If the loan is in Active Good Standing, only then the principal payment is allowed through the manual spread.

The Maturity Date is reflecting an incorrect value on the Reschedule OLT after an excess payment reschedules the loan (Jira ID: PDRFF-1891/ND-6455/ND-6490/ND-6491/ND-6492)

Issue Description

When an excess payment is made such that, the loan is automatically rescheduled, the Maturity Date field reflects an incorrect value on the OLT that is of the Transaction Type, Reschedule.

Example to Understand the Issue

Let us create an FAMZ loan contract with the following details:
- Contract Start Date = January 1, 2013
- Payment Frequency = Monthly
- Interest Posting Frequency = Monthly
- Default Interest Rate = 10%
- Reschedule Option on Excess Payment = Keep Same Payment Amount
- Excess Threshold % for Reschedule = 0.00
- Terms = 10
- Time Counting Method = Month And Days
- Loan Amount = $10,000
Let us approve and disburse the loan contract.
Now let us go to the first bill date February 1, 2013.

The system generates the following:
- Bill 1 of $1046.4
- IPT 1 of $83.33
Now let us create an LPT of $1,046.4 for the first bill.
Let us go to February 15, 2013, and make a payment (LPT) of $2,000, which is higher than the bill amount.

This updates the following:
- Interest Accrued = $35.14
- Interest Paid = $83.33
- Reschedule Status = Pending
Let us go to the next day, which is February 16, 2013, to run the SOD/EOD jobs for rescheduling. (Ensure that the LoanRescheduleDynamicJob or LoanRescheduleJob as part of the SOD/EOD Job is trigger the automatic reschedule.)

This updates the following:
- Reschedule Status = Success
- Reschedule transaction (OLT of the Transaction Type, Reschedule) gets created with the Maturity Date as blank, which is incorrect.

The Maturity Date must reflect the latest maturity date, which is September 1, 2013.

The Maturity Date is updating to null (or is blank) because when the system finds the value of the Reschedule Option On Excess Payment field selected as Keep Same Payment Amount, it does not update the Maturity Date to a new date internally and hence displays as blank on the OLT due to rescheduling.

Resolution

This issue is now fixed, and the Maturity Date field on the rescheduling transaction (OLT) is reflecting the correct value.

Amortization Schedule are not set back to the previous schedule after the payment is reversed (Jira ID: ICAR-55/PDRFF-2055/ND-6518)

Issue Description

In an FAMZ contract the Amortization Schedules are not set back to the previous schedules after the payment is reversed. This is because the system is allowing you to manually change the Reschedule Threshold Crossed on the LPT to false, which is an incorrect behavior.

Example to understand the issue

Let us create an FAMZ contract with the following details:
- Time Counting Method = Month and Days
- Default Interest Rate = 10
- Is Interest Posting = true
- Interest Posting Frequency = Monthly
- Excess Threshold % for Reschedule = 0
- Reschedule Option on Excess Payment = Keep Same Payment Amount
- Contract Start Date = March 1, 2022
- Loan Amount = 10,000
- Term = 10
- Interest Rate Change Method = Change Payment Amount
- Payment Frequency = Monthly
- Payment Start Date = February 3, 2022
Let us approve and disburse the loan contract.
Let us create an LPT with Transaction Amount = $200. (Reschedule Threshold Crossed on the LPT is true.)
Let us try to update Reschedule Threshold Crossed to false and save it.

The system must not allow you to change the value of this flag, but the system allows you to change this flag.
Let us go to the next day and reverse the LPT created.

The Amortization Schedules are not reverting back to the previous schedules as the Reschedule Threshold Crossed flag is set to true.

Resolution

This issue is now fixed. The system now restricts the manual changing of the Reschedule Threshold Crossed flag to false and it remains true when tried to change to false. Thus, the LPT reversal now leads to AMZ schedules reverting back to previous schedules as expected.

The Interest Remaining field is getting incorrectly calculated when the Interest Period Calculation is set to Include Start Date (Jira ID: ND-6386/ND-6445/ND-6446/ND-6447)

Issue Description

In an FAMZ contract with Interest Period Calculation set as Include Start Date, the Interest Remaining field is getting incorrectly calculated.

Example to understand the issue

Let us create an FAMZ contract with the following details:
- Contract Start Date = January 1, 2013
- Loan Amount = $10,000
- FIT = True
- Interest Rate = 5%
- Term = 10
- Interest Period Calculation = Include Start Date
- Is Interest Posting = True
- Payment Frequency = Monthly
- Accrual Start Basis = Disbursal Date
- Interest Rate Change Method = Change Payment Amount
- Interest Posting Frequency = Monthly
- Payment Start Date = February 2, 2013
Let us go to February 2, 2013, approve and disburse the loan contract.

The Interest Remaining must be = $1.39

However, Interest Remaining is getting calculated as twice the expected value = $2.78 (= 2 * 1.39.)

This is because when the Interest Period Calculation = Include Start Date, the system updates the Interest Remaining twice on disbursal in an FAMZ loan contract.

Resolution

This issue is now fixed, and the Interest Remaining value is getting calculated correctly.

Mismatch in interest values in the contract and accrual entries (Jira ID: PDRFF-1903/ND-6507/ND-6538/ND-6539/ND-6540)

Issue Description

In Flexible AMZ loans, when a payment is reversed, the values of the interest fields and accrual entries are not in sync with each other and with the interest values in the repayment schedule.

Example to Understand the Issue

Let us create an FAMZ loan contract with the following details:
- Contract Start Date = June 18, 2022
- Loan Amount = $10,000
- Interest Rate = 6%
- Term = 3
- Is Interest Posting = true
- Payment Frequency = Daily
- Interest Posting Frequency = Daily
- Payment Start Date = June 19, 2022
- Time Counting Method = Actual Days
- Accrual Start Basis = Disbursal Date
- Payment Application Mode = Current Dues
- Payment Application Order = Date
- Accrual Based Accounting = true
- Accrual Entry Frequency = Daily
- FIT = True
- Draw Billing Method = Interest Only
- Interest Rate Change Method = Keep Same Payment Amount
Let us approve and disburse the loan.

Let us perform the actions on dates as described in the following table:

Current System Date	Actions	Results
June 19, 2022	Run the Accrual Entry Job. Make a payment of the bill amount of $3,334.43.	Interest Paid = 10,000 * 6/100 * 1/365 = 1.64.
June 20, 2022	Run the Accrual Entry Job. Make a payment of the bill amount of $3,334.43.	Interest Paid = 10,000 * 6/100 * 1/365 = 1.64.
June 21, 2022 (This is the Maturity Date as Term = 3.)	Run the Accrual Entry Job.	Interest Accrued= 10,000 * 6/100 * 1/365 = 1.64. Next Accrual Entry Date must be December 31, 3000.
June 22, 2022	Reverse the latest LPT, and check the interest fields updated.	Next Accrual Entry Date must be December 31, 3000. We can observe that accrual entries are created for 3 terms.
On the same date later	Run the Accrual Entry Job.	Expected behavior: The expected values must be as follows: Next Accrual Entry Date = December 31, 3000. Accrual Amount Accounted For = 3.29 (no change) Interest Accrued = 0.55 Interest Remaining = 1.65 Interest Paid = 1.64 Next Accrual Entry Date = December 31, 3000 (no change) Thus, Sum of interest field values on the CL Contract (Sum of Interest Remaining, Interest Paid, and Interest Accrued) must be equal to Accrual Amount Accounted For (Sum of accrual amount of all accrual entries). Observed actual behavior: There is a mismatch observed between the interest on the contract and that of the accrual entries. The sum of the interest fields at the contract level differ from the sum of interest amounts in accrual entries and they both differ from the sum of the interests in the contract's repayment schedule. Thus, Sum of interest field values on the CL Contract (Sum of Interest Remaining, Interest Paid, and Interest Accrued) is not equal to Accrual Amount Accounted For (Sum of accrual amount of all accrual entries) that is also not equal to sum of interests as per repayment schedule.

Resolution

This issue is fixed. Now the sum of interest field values on the CL Contract (Sum of Interest Remaining, Interest Paid, and Interest Accrued) is equal to Accrual Amount Accounted For (Sum of accrual amount of all accrual entries), and they are also equal to the sum of interests in the repayment schedule.

Interest Remaining is getting updated incorrectly when a Loan Payoff transaction is reversed (Jira ID: ND- 4460)

Issue Description

When a payoff transaction is reversed in an FAMZ loan contract, Interest Accrued and Interest Remaining are getting incorrectly updated. This issue is caused by improper consideration of the loan balance during the reversal process.

Example to Understand the Issue

Let us create an FAMZ contract with the following details:
- Contract Start Date = January 1, 2013
- Loan Amount = $10,000
- Interest Rate = 10%
- Term = 10
- Is Interest Posting = True
- Payment Frequency = Monthly
- Interest Posting Frequency = Monthly
- Disbursal Date = February 1, 2013
- Payment Start Date = March 1, 2013
Let us go to February 1, 2013, and approve and disburse this contract.
Move a few days ahead so that the interest gets accrued. Let us say we have moved to February 25, 2013.

This updates the Interest Accrued to $66.67.
Make a Loan Payoff by creating a payoff transaction of $10066.67 and clear it.

Note

This issue can be replicated with a normal LPT as well.

The Interest Accrued of $66.67 is paid and hence Interest Accrued must be 0 and Interest Paid must be $66.67.
Reverse the payoff and verify Interest Accrued and Interest Remaining field values.

Expected behavior: After reversing the payoff, the Interest Remaining must reflect the correct amount based on the reversal and the Interest Accrued must get back to the previous state as follows:
- Interest Paid = 0
- Interest Accrued = $66.67
- Interest Remaining = 0
Observed behavior: After reversing the payoff, the Interest Accrued and the Interest Remaining are reflecting incorrect values because the system was considering the Loan Balance incorrectly during the reversal process.

Resolution

The code has been modified to correctly consider the Loan Balance when reversing a Loan Payoff transaction on FAMZ loans. This ensures that the Interest Remaining and Interest Accrued are updated accurately after the reversal.

Installment payment is not satisfying the bill and moving the interest to Excess (Jira ID: PDRFF-692/ND-5289)

Issue Description

When an Installment Payment is made between the Due Generation Date and the Due Date in a loan with Pre-bill days defined, the bill is not getting satisfied completely. Only the principal component of the bill is getting satisfied, and the interest component amount is getting moved to Excess. However, the system is marking the bill as paid. And an extra IPT of the type of Prepayment is also getting created in the system.

Example to Understand the Issue

Let us create a Flexible AMZ contract with the following details:
- Contract Start Date = August 29, 2021
- Pre Bill Days = 5
- Payment Start Date = September 29, 2021
- Next Due Generation Date = September 24, 2021
Let us move to the end of day of September 24, 2021 (You can move the EOD batch to September 24, 2021 to do this.)

The bill gets generated.
Let us create a payment transaction with Installment Payment flag set to true and the Installment Date as September 29, 2021, and clear that payment.

This amount is satisfying the principal part of the bill only and not the interest part, but the bill is still getting marked as satisfied and the interest component is getting considered as an Excess amount within the loan.

Resolution

This issue is fixed. The Installment Payment is now appropriately fulfilling the bill, and the system is correctly marking the existing IPT as closed and paid.

The system is clearing the Excess LPT amount incorrectly without comparing it with the Excess amount available on the contract (Jira ID: ND-6180)

Issue Description

When an Excess amount is already available on an FAMZ loan contract, the Loan Payment Transaction is getting incorrectly cleared without comparing the values correctly.

Example to Understand the Issue

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

Let us create an FAMZ loan contract with the following details and disburse it:
- Loan Amount = $10,000
- Interest Posting Frequency = Monthly
- Contract Start Date = March 21, 2013
- Terms = 10
- Interest Rate = 10%
- Time Counting Method = Month and Days
- Transaction Approval Configuration > Payments = true

Let us perform the actions on dates as described in the following table:

Current System Date	Actions	Results
March 21, 2013	Create an LPT-1 of amount $100.	The Excess field on the loan contract gets updated to $100 as there is no bill generated yet.
On the same date later	Create an additional LPT-2 of amount $100.	The Excess field on the contract is updated to $200.
On the same date later	Create one more LPT-3 with Payment Mode = Excess in an uncleared state. Note Transaction Amount will be non-editable for this.	Note The payment will be cleared only when it is manually cleared if it is approved as per the configuration set in Transaction Approval Configuration.
On the same date later	Reverse LPT-2 of $100.	Excess field on the contract is updated to $100.
On the same date later	Now mark the Excess LPT-3 as cleared.	The Excess LPT-3 gets cleared and the total Excess on the loan becomes $300, which is incorrect. The system must reject this action of clearing this LPT-3.

Expected behavior:

The system must check and compare the excess amounts before clearing. Before clearing the Excess LPT-3, the system must check the Excess amount present on the loan and compare it with the Excess LPT-3 to be cleared. If it's less than the Excess LPT-3 amount then the Excess LPT-3 must not be cleared and the system must reject the LPT-3 in order to avoid blocking the next LPTs to be cleared.

Also, after the LPT-2 reversal, the system must check and must reject any uncleared Excess LPTs present on the loan if the Excess LPT amount is greater than the actual Excess amount on the loan after the reversal action.

Resolution

This issue is fixed.

Now, while clearing the Excess LPT, the system compares the clearing Transaction Amount with the Excess amount present on the contract. If the clearing Transaction Amount is more than the Excess amount, the system displays the following error message:

"Error:Rolling back the batch. Message - You cannot process this transaction. The Transaction Amount is greater than the available Excess Amount in the Contract. - Cause null-104."

Also, the system will not allow to create any new LPT, say LPT-4, in cleared state if the Excess LPT-3 is still not cleared, and will display the following error message:

" Cannot clear transaction as there are previous uncleared transactions. Please clear or reject those transactions before clearing this payment."

Only after clearing or rejecting the Excess LPT-3, the system will allow to clear any additional new LPTs such as LPT-4.

Excess field is not getting updated after the reversal of the Excess LPT created by the ExcessForAmzLoansJob (Jira ID: ND-3212/ND-6462)

Issue Description

When an excess payment is made in an FAMZ loan contract, an LPT gets created of that excess amount and the Excess field on the loan contract gets updated with the excess amount. This excess amount satisfies the bill in the next cycle creating an Excess LPT of that excess amount and updating the Excess field on the loan contract to zero. After that, if the Excess LPT is reversed, the Excess field is not getting updated with the original excess amount.

This is because, internally, the Excess field is getting marked as zero before the creation of a snapshot while processing the Excess LPT.

Excess field must get marked as zero after the creation snapshot while processing the Excess LPT.

Note

Snapshots are fields that stores different field values temporarily for internal calculation purposes.

Example to Understand the Issue

Let us create a Flexible AMZ contract with the following details:
- Loan Amount = $10,000
- Terms = 3
- Rate = 10%
- Time Counting Method = Month & Days
- Payment Frequency = Monthly
- Interest Posting Frequency = Monthly
- Contract Start Date = January 1, 2022
Let us approve and disburse this contract.

Let us perform the actions on dates as described in the following table:

Current System Date	Actions	Results
February 1, 2022 (billing date)	Make a payment of the bill generated.	Bill is satisifed.
On the same date later February 1, 2022	Then make an additional payment of $500.	LPT of $500 gets created and as the bill is already satisfied, this amount goes toward the Excess. The Excess field on the contract is updated to $500.
March 1, 2022 (next billing date)	None	ExcessForAmzBasedLoansJob job runs as part of SOD. Excess LPT gets created of $500 and satisfies the bill. Excess field on the contract is updated to 0.
On the same date later	Reverse the Excess LPT created on March 1.	The amount in the Excess field on the contract must be reversed back to $500, but the issue is that it is not getting reversed and the value of the Excess field is remaining as zero.

Resolution

This issue is fixed. The internal code is modified such that the Excess field is now getting updated correctly after the reversal of the Excess LPT created by the ExcessForAmzLoansJob.

Rescheduling by adding or updating a Flexible Repayment Plan is failing with an error message (Jira ID: PDRFF-1973/ND-6476)

Issue Description

When an FAMZ loan contract is rescheduled to add or updated a Flexible Repayment Plan, the system is throwing the following exception:

"Error:

CL010101: Unexpected Exception SObject row was retrieved via SOQL without querying the requested field: loan_Loan_Accountc.loanRevolving_c at line 139"

Example to Understand the Issue

Let us create a Flexible AMZ contract with the following details:
- Billing Method = Declining balance
- Payment Frequency = Monthly
- Time Counting Method = Month and Days
- Accrual Start Basis = Contract Dates
- Payment Application Mode = Current Dues
- Payment Application Order = Date
- Default Term = 12
- Interest Type = Fixed
- Interest Rate Change Method = Change Payment Amount
- Default Interest Rate = 10%
- Repayment Procedure = EMI
- Is Interest Posting Enabled = true
- Interest Posting Frequency = Monthly
- Pre Bill Days = 5
- Excess Threshold % for Reschedule = 5.00
- Reschedule Option on Excess Payment = Keep Same Payment Amount
- Loan Amount = 10,000
- Payment Start Date = February 2, 2013
- Accrual Start Date =January 2, 2013

Let us add a Flexible Repayment Plan with the following details:

Sequence	Payment Type	Payment Amount	Number of Payments	Payment Start Date
1	Equal Monthly Installments	$900	3	February 2, 2013
2	Equal Monthly Installments	$879.16	3	May 2, 2013

This updates the amortization schedule in the following way:
- The first three terms display an amount of $900.
- The next three terms display an amount of $879.16.
- The other six terms display an amount of $868.07.
- The last schedule display the balance as zero.
Let us approve and disburse this contract.
Then, on the same day, let's reschedule the loan contract by updating the values as follows:
- Transaction Date = February 1, 2013
- Interest Only Period = 0
- Repayment Start Date = February 2, 2013
- Payment Frequency = Monthly
- Maintain Delinquency = true
Let us edit the first row of the Flexible Repayment Plan as follows and try to save this Rescheduling:

Sequence

Payment Type

Payment Amount

Number of Payments

Payment Start Date

1

Equal Monthly Installments

$1,000

3 (non-editable)

February 2, 2013 (non-editable)
The system is not able to reschedule and displays an error message as follows:

Note

CL010101: Unexpected Exception SObject row was retrieved via SOQL without querying the requested field: loan_Loan_Accountc.loanRevolving_c at line 139

Instead, the system must update the amortization schedule with the following values:
- The first three terms with an amount of $1,000.
- The next three terms with an amount of $879.16.
- The remaining terms with amount of $814.86.
Thus, the old schedule must get archived, and the new must be created.

Resolution

This issue is fixed. The code has been modified such that the system is now able to successfully reschedule the loan by updating the Flexible Repayment Plan.

Interest Remaining is getting updated incorrectly when Interest Period Calculation is set to Include Start Date (Jira ID: ND-6474/ND-6510/ND-6511)

Issue Description

In an FAMZ loan contract, if the Interest Period Calculation is set to Include Start Date of the calculation period, the Interest Remaining is getting calculated incorrectly and LAD (Last Accrual Date) is getting updated to a date before the Contract Start Date.

Example to Understand the Issue

Let us create a Flexible AMZ contract with the following details:
- Interest Rate = 10%
- Time Counting Method = Month and Days
- Is IPT Enabled = true
- Interest Posting Frequency = Single-Payment Frequency
- Interest Period Calculation = Include Start Date
- FIT = true
- Loan Amount = $10,000
- Term = 1
- Contract Start Date = September 22, 2013
- First Payment Date = October 22, 2013
Let us approve and disburse this contract.
Let us move two days ahead to September 24, 2013.

Expected behavior: The various fields on the loan contract must reflect the following values:
- LAD = September 22, 2013.
- Interest Remaining = $2.78.
  
  This is one day's interest = 10,000 * 10/100 * 1/360 = 2.78 as the interest calculation includes the start date of the calculation period.
Observed behavior: But the observed behavior is as follows:
- LAD = September 21, 2013.
- Interest Remaining = 0.
This same issue has been observed with a contract with 10 terms too.

Resolution

This issue is fixed. The code has been modified such that the system is now updating and calculating the Interest Remaining and the LAD correctly when the Interest Period Calculation is set to Include Start Date in an FAMZ loan contract.

Multiple excess LPTs are getting created every day due to older uncleared payment transactions (Jira ID: ND-5270)

Issue Description

In an FAMZ loan contract, excess payments are getting created every day as there is some amount remaining in the Excess field because there is a payment transaction with a Transaction Date prior to the excess payments that are uncleared.

Note that the excess LPTs are created when there is some amount remaining in the Excess field and there is an unpaid bill in the system. And the ExcessForAMZbasedLoans job runs everyday to create the excess LPTs.

The issue is that in a Flexible AMZ loan contract, if the sum of the uncleared LPTs and the excess amount is less than the due amount, then the system is creating an excess LPT every day when the job runs until the sum of the uncleared LPTs and the repetitive excess LPTs is greater than or equal to the due amount. Thus, the system keeps creating excess LPTs everyday due to earlier uncleared payment transactions.

Example to Understand the Issue

Let’s assume the following FAMZ contract is created:
- Current System Date = June 18
- Pre Bill Days = 5
- First Payment Date = July 18
- Next Due Generation Date = July 13

Current System Date	Actions	Results
June 18	None	Due Amount of $91.69 created.
July 13 (Due Generation Date)	None	Bill gets generated.
July 14	Ad hoc payment of $10 made.	Excess of $10 created in the system.
Same date later	Payment (LPT) of $41.72 made.	LPT of $41.72 not cleared.
July 18	None	Excess LPT of $10 created. Because the sum is not less than the due amount. This means: $41.72 < $91.69.
July 19	None	Excess LPT of $10 created. Because the sum is not less than due amount. This means: ($41.72 + $10) < $91.69.
Same date later	LPT updated to $71.71	None
July 20	None	No excess LPT created as sum is not less than due amount. This means: ($71.71 + $20) > $91.69
Same date later	LPT updated to $61.71	None
July 21	None	Excess LPT is created of the difference between due amount and sum of excess LPTs and payments, which is $9.97 This means: $91.69 - ($61.71 + $20)

Resolution

To resolve this issue, before creating an excess LPT, the system must check the earlier uncleared excess LPTs. It must create a new excess LPT only if the excess amount present in the contract (in the Excess field of the contract) is more than the total amount in all earlier uncleared excess LPTs.

For example, if the total amount in all earlier uncleared excess LPTs is $10 and if the excess amount is $15, then the system must create an excess LPT of only $5.

This issue is now resolved as the system does not create new excess LPTs if it exceeds the excess amount present in the contract in the Excess field.

If a backdated payment is attempted and the payment exceeds the threshold percentage, the system is not displaying an appropriate message (Jira ID: ND-6493)

Issue Description

If a back dated payment is attempted in an FAMZ loan contract and the payment exceeds the Excess Threshold % for Reschedule, the system is not displaying an appropriate message.

Example to Understand the Issue

Let us create a Flexible AMZ contract with the following details:
- Billing Method = Declining Balance
- Payment Frequency = Monthly
- Time Counting Method = Month and Days
- Accrual Start Basis = Contract Dates
- Payment Application Mode = Current Dues
- Payment Application Order = Date
- Default Term = 12
- Interest Type = Fixed
- Interest Rate Change Method = Change Payment Amount
- Default Interest Rate = 10%
- Repayment Procedure = EMI
- Is Interest Posting = True
- Interest Posting Frequency = Monthly
- Pre Bill Days = 5
- Excess Threshold % for Reschedule = 5.00
- Reschedule Option on Excess Payment = Keep Same Payment Amount
- Loan Amount = $10,000
- Current System Date = January 1, 2013
- Payment Start Date = February 1, 2013
- Accrual Start Basis = January 1, 2013
Let us approve and disburse this contract.

An AMZ schedule gets created with an EMI amount of $879.16.
Let us move to the fourth bill date of May 1, 2013.

The various parameters on a loan contract get updated as follows:
- LAD = May 1, 2013
- Interest Posted = 0.00
- Interest Remaining = $293.32
- Interest Accrued = 0.00
- Principal/Advance Remaining = $10,000
- Four bills get generated with an amount of $879.16 each(All bills are primary)
- Following five IPTs get created:
  - Four IPTs in the Closed status
  - One IPT in the Open status with due date of June 1, 2013.
Now let us create a back dated LPT with the following details:
- Transaction Date = March 1, 2013.
- Transaction Amount = $4,000 (This must cross the Excess Threshold % for Reschedule of 5% as defined earlier.)

Expected behavior: The system must not allow to create backdated LPT crossing the Excess Threshold % for Reschedule and while saving the LPT, the system must display an appropriate error message.

Observed behavior: While trying to save such a backdated LPT, the system is not displaying an appropriate message to say that such a backdated LPT cannot be created as it is crossing the Excess Threshold % for Reschedule.

Resolution

This issue is fixed.

The system now is not allowing to create a backdated LPT crossing the Excess Threshold % for Reschedule and while saving such an LPT, the system is displaying the following error message:

Note

Excess Backdated Payments are not allowed for flexi-Amz Loans.

During LPT clearing, the payment distribution is considering Interest Remaining instead of Interest Posted (Jira ID: ICAR-122/PDRFF-2022/ND-6496)

Issue Description

In an FAMZ loan contract, when a payment transaction (LPT) is created, during its clearing, if the Interest Remaining is less than the Interest Posted amount, the system only considers the Interest Remaining amount for the interest part within the LPT, even though the Interest Posted amount is more.

Resolution

This issue is fixed. The Payment Spread of the LPT is now considering the posted unpaid amount instead of the Interest Remaining amount.

Change Record

S.No	Change Date	Description of Change
1.	April 28, 2023	Published the Release Notes for Spring'23 General Availability release.
2.	June 5, 2023	Published the release notes for: Q2 Loan Servicing Issues fixed in Q2 Loan Servicing 4.2008.14
3.	November 20,2023	Published the release notes for: Q2 Loan Servicing 4.2008.38
4.	December 11,2023	Published the release notes for: Q2 Loan Servicing 4.2008.41
5.	January 08, 2024	Published the release notes for: CL Common 4.2004.20
6.	January 08, 2024	Published the release notes for: Q2 Loan Servicing 4.2008.44
7.	January 29, 2024	Published the release notes for: Q2 Loan Servicing 4.2004.48
8.	February 19, 2024	Published the release notes for: Q2 Loan Servicing 4.2008.51
9.	February 19, 2024	Published the release notes for: CL Common Spring'23 4.2004.21
10.	February 19, 2024	Enhancements made in the Q2 Loan Servicing 4.2008.51
11.	March 11, 2024	Published the release notes for: Q2 Loan Servicing 4.2008.58
12.	April 22, 2024	Published the release notes for: Q2 Loan Servicing 4.2008.63
13.	May 13, 2024	Published the release notes for: Q2 Loan Servicing 4.2008.64 Enhancements in Q2 Loan Servicing 4.2008.64 CL Common Spring'23 4.2004.25 Q2 Loan Servicing 4.2008.64 and CL Common Spring'23 4.2004.25
14.	June 03, 2024	Published the release notes for: Q2 Loan Servicing 4.2008.68 CL Common Spring'23 4.2004.26
15.	June 24, 2024	Added PDRFF-3065 to Q2 Loan Servicing 4.2008.68 section
16.	July 15, 2024	Published the release notes for: Q2 Loan Servicing Issues fixed in Q2 Loan Servicing 4.2008.73 patch
17.	August 05, 2024	Published the release notes for: Q2 Loan Servicing Issues fixed in Q2 Loan Servicing 4.2008.74 patch
18.	August 26, 2024	Published the release notes for: Q2 Loan Servicing Issues fixed in Q2 Loan Servicing Spring'23 4.2008.78 patch CL Common Spring'23 Issues fixed in CL Common Spring'23 4.2004.27 patch
19.	September 16, 2024	Published the release notes for Q2 Loan Servicing Issues fixed in Q2 Loan Servicing Spring'23 4.2008.79 patch
20.	November 18, 2024	Published the release notes for Q2 Loan Servicing Issues fixed in the 4.2008.83 patch