Platinum Release Notes

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 Q2 Loan Servicing and Marketplace, Platinum 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 Q2 Loan Servicing and MarketplacePlatinum version (3.6019.232) for the first time or have upgraded from an earlier version.

1.   Purpose of this Document

This document provides information on the following for the Platinum 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

1.1 Intended Audience

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

1.2 Prerequisites for Use

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

1.3 List of Abbreviations

2.   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 Record section.

3.   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 and Marketplace.

4.   Upgrade Considerations

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

5.   System Performance

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

6.   New Features and Enhancements

This section briefly describes the new features and enhancements added in the Platinum release of Q2 Loan Servicing and Marketplace.

6.1 Master Loan

Feature Description

Before Platinum

With the Oxygen release (3.6) of 02 Loan Servicing system, it was possible for lenders to book complex loan facilities, where each drawdown could have its own unique attributes like interest rate, amortization term, repayment profile, payment frequency, and other such parameters.

A new product type called Master Loan was introduced in the system, using which you could book a master parent loan, which is essentially an umbrella facility under which each disbursement or drawdown can be recorded as a separate child loan. Each child loan could have its own bills, and every child loan that is repaid ultimately updates the balances on the master.

All the attributes of such a facility agreement should be recorded on the master facility itself. The facility can be revolving in nature. The credit limit of the facility would get updated every time there is a repayment on any of the child loans.

In the Oxygen release (3.6), we provided you with the essential capabilities listed below, for you to be able to book and service loan contracts on such loan products that aligned to the structure of Master Facility.

• Creation of Master Facility loan product

• Creation of Child Loans (drawdowns)

• Disbursement of funds in a master facility

• Repayment of drawdowns

• Charging Non-Unutilized Fee on the undrawn balance of the facility (Additional Interest Component defined on the undrawn balance of master)

• Charging pre-paid fee on the drawdowns of a master facility

After Platinum

With the Platinum release, we have come up with a few enhancements that would help you to get a consolidated view of such facilities with many drawdowns.

6.1.1 Master facility - Consolidation of Principal Remaining on master loan (Jira ID: ND-4501)

Feature Description

As we know, that for every drawdown, you need to create a new child loan in a master facility. So, every drawdown has got its own principal balance that gets updated as and when the transactions ae done on the loan.

Till now, there was no way that you could see a consolidated principal remaining of the entire facility. With the Platinum release, you can now see the consolidated principal remaining of the master facility. This balance gets updated every time there is any transaction on any of the drawdowns that affects the principal balance of the loan, such as disbursement, capitalizations, repayments, and more.

6.1.2 Master facility- Consolidated repayment schedule (Jira ID: ND-4498)

Feature Description

We know that the entire master facility is nothing else but a loan with multiple drawdowns funded on different terms. Till now, there was no way that a user could see a consolidated schedule to give a view of total expected dues across the facility.

With the Platinum release, you would now be able to get a holistic view of the entire facility at any point of time to see the total expected principal dues, interest dues, or fee dues on a date in the consolidated schedule at the master facility. The pain of manually going to every child loan to refer to the schedule of that drawdown is reduced substantially. We also give you an option to be able to choose any of the drawdowns under that facility, whose schedule you wish to view.

6.1.3 Master facility- Consolidated Loan Transaction Statement (Jira ID: ND-4561)

Feature Description

You can now view and generate a consolidated transaction statement for the entire master facility. This would enable you to view all the transactions that have taken place in all the child loans (drawdowns) booked under a master facility.

We also give you the option of filtering out any particular child loan for which you want to see the transaction statement. This would save you the time to navigate through multiple loans in order to get the statements.

6.1.4 Master facility- Consolidated payoff quote (Jira ID: ND-4559)

Prior to Platinum, it was not possible for a lender to get a view of the redemption amount on a master facility as on a given date. It was only possible to generate such a quote independently at every child loan.

With Platinum, you would be able to get a consolidated payoff quote of a master facility, on any desired date that the borrower has asked for, which would include the principal remaining, interest dues, and any due charges across all the drawdowns in that master facility.

6.2 Principal adjustment enhancements

6.2.1 Redraw (JIRA ID: ND-4607)

Feature Description

For the term loan products that are not revolving in nature, ideally once the entire loan amount is disbursed to the borrower, there is no scope for customers to draw any amount further out of that facility for any unforeseen needs in future. So, there are lenders who give benefits on such loan facilities, where they are allowed to withdraw again an amount to the maximum limit of an amount by which they are ahead of their dues. What this means is that the borrower can redraw an amount "equal to or less than" the difference between the Loan Balance that would have been before the extra repayment and the Loan Balance after the repayment.

With the Platinum release, 02 Loan Servicing system allows you to withdraw (subsequent disbursal) from a loan an amount that can be equal to or less than the amount that has been paid extra over the minimum expected repayment on a loan as on a particular date. This action would result in a change in the principal amount without changing the repayment schedule. This is called redrawing.

There is a field on the loan contract named Reserve Amount for Next Due. It always gets updated whenever the borrower pays more than what is due on the loan at that point of time. The system would not allow you to withdraw an amount more than what is available to redraw in this field. The advantage of this feature is that because a borrower is not allowed to withdraw more than the redraw balance, there is no change in the future monthly repayment amounts, and the loan can continue as it is. Had the system allowed the borrower to redraw more than that on a loan, then the Loan Balance would increase more than what it originally would have been, shooting up the monthly repayments.

6.2.2 Top Up on loan (JIRA ID: ND-4615)

Feature Description

With the Platinum release, you would be able to top up a transaction on a loan.Top up action simply increases the Principal Balance of Loan. Because of Top up, schedule gets re-generated on the amount equal to Sum of New Loan Balance and Reserve Amount.

Redraw limit reduction (ND-4616)

Feature Description

You can also reduce the redraw limit on a loan now. Reducing the limit on a redraw means that the redraw balance on a loan is reduced and the loan is re-amortized on the new balance

6.3 User-based access to UI for buttons, tabs, and actions (JIRA ID: ND-4573)

Feature Description

Prior to Platinum, the loan contract page displayed all tabs, buttons, and quick actions without checking for the user's permissions. There was no way that we could restrict this differently for different users.

Now a system admin can set up permissions for access to these components to users of the system and on that basis, the rendering of tabs, buttons, and quick actions would occur by looking at the user's permission. If a certain user does not have permissions to a certain button, tab, or an action, it will not be visible on the UI to that user.

6.4 ACH Retry Interval to consider the holiday setup defined in an org (Jira ID: ND-4549)

Feature Description

In 02 loan servicing, we have a parameter in the org setup called ACH Retry Interval. Defining this basically makes the system to retry ACH payment in case the payment failed last time due to any reason like unavailability of funds in the borrower's account. So based on the number of days that you define in this parameter, the system will initiate a payment again. But this ACH setup considers by default calendar days, which leaves the lender in a lot of unexpected ambiguities where such retry might happen on holidays and ACH clearance might not happen on public holidays and bank holidays.

With the platinum release, the system would always consider the holiday setup provided in the org for controlling the logic of ACH Retry interval, so that in case if ACH fails on the destined date and the system does a retry based on the interval days set up in the system, it always does so on a working day and not on a holiday.

6.5 Ad hoc prepaid fee creation during the term of a loan (Jira ID: ND-4552)

Feature Description

Prior to the Platinum release, if you had to charge a prepaid fee, such as an arrangement fee, during the disbursement of a loan, it was essential that such fee was defined in the product of that loan. There was no way that you could charge such a fee on a loan, as it would not have inherited it from the product definition.

Although it is always advisable to define such fees in the product so that every loan booked on that product is drawn out on the same attribute of prepaid fee structure, there are times when the lender might want to charge a one-off fee on the disbursement of a loan, as agreed with the borrower, and which might not be a general feature of that product.

To cater to such cases, with the platinum release, while disbursing a loan, if you want to charge a prepaid fee on the loan and when there is no such fee defined in the product, you can straight away add any prepaid fee that is defined in the system, on the disbursement screen. The same would get charged (either net off from the disbursement amount or added to the amount) on the loan accordingly.

6.6 Floating Rate to be captured till five decimal places (Jira ID: ND-4556)

Feature Description

Prior to the Platinum release, the maximum decimal places that the interest rate fields in 02 Loan servicing could capture was two. Even if the user entered an index rate with more than two decimal places, the system still would round it off to two decimal places and do all the calculations based on that.

With the Platinum release, this has been enhanced to support till five decimal places. All the fields which are used to define any kind of rate will support it and the calculations will be done using the amount till five decimal places.

6.7 Defining contract term for single payment loans (Jira ID: ND-4557)

Feature Description

Earlier, both the contract term and the payment terms were the same. However, this did not work in cases of single payment loans where the tenure of the deal can be 36 months but there is only one payment expected on maturity. This required a solution where the payment terms can be different from the contract term.

With the Platinum release, to differentiate between the contract term and payment term, we have introduced a new parameter called Contract Tenure for cases when the Payment Frequency is Single­ Payment. This parameter would help to define the tenure of the loan, and the system would then automatically calculate the maturity date as per this tenure.

7.   Fixed Issues

This section describes the issues fixed in the Platinum release of 02 Loan Servicing and 02 Marketplace.

7.1 Guest user profile unable to access records (Jira ID: ND-4575)

Issue Description

With the Spring'21 release of Salesforce, when an application is getting converted to a loan by a guest user profile, the system is displaying the following error message: "Insert failed. First exception on row0; first error: CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY"

Resolution

This issue is fixed, as the sharing attribute is now removed from the disbursal trigger and repayment trigger as per the recommendation by Salesforce.

7.2 Loan does not close after a payoff (Jira ID: ND-4545)

Issue Description

While paying a loan off, the system is considering the payoff amount as an excess amount, and the loan is not getting closed.

Resolution

This issue is fixed as the system now does the necessary checks to ensure that the loan is closed when a payoff is made.

7.3 FloatingRatelnterestRevisionJob not updating rate schedule and the interest accrual with the new index rate (Jira ID: ND-4408)

Issue Description

When the system date falls on the floating rate revision date and if there is a loan in the system that has crossed the maturity date, the FloatingRatelnterestRevisionJob that is run as part of the SOD process is failing and not considering the updated index rates leading to an incorrect rate schedule and interest accrual.

Resolution

This issue is fixed, as now the FloatingRatelnterestRevisionJob is not considering the loan whose maturity date has passed.

7.4 FloatingRateLoanResetJob fails if there is a loan under processing whose maturity date has passed (Jira ID: ND-4034)

Issue Description

On clicking the Submit Reset Process button for updating the floating rate, the FloatingRateLoanResetJob is failing if there is a loan in the system whose maturity date has passed.

Resolution

This issue is fixed as now the FloatingRateLoanResetJob is not considering the loan whose maturity date has passed.

7.5 Rescheduling AP/ assigns an incorrect value to the second due date parameter (Jira ID: ND-4485)

Issue Description

When a loan is rescheduled with the help of the API and the value of payment frequency is set to Semi-Monthly-PD, a null value is getting incorrectly assigned to the second due date parameter irrespective of the value passed in it.

Resolution

This issue is fixed.

7.6 Incorrect fee capitalization after a manual rescheduling of loans (Jira ID: ND- 3368)

Issue Description

When a loan is manually rescheduled by selecting Maintain Delinquency as false and Reschedule Balance as Loan Balance, the payment made after the reschedule, satisfies the charges that were created before the reschedule, and hence the value of Fee Capitalization becomes negative.

Resolution

This issue is fixed.

7.7 Total interest in Accrual streams does not match the total interest in Cash streams (Jira ID: ND-4271)

Issue Description

When the final repayment date is falling on a day that is not the end of the month, but if the accruals are getting calculated at month-end, then the value of the total interest on the payment streams do not match the value of the total interest accrued over the life of the loan.

Resolution

This issue is fixed as an additional stream is now created at the maturity date for the interest and additional interest accrual streams.

7.8 Bills are not getting satisfied even though the payment amount is same as the due amount (Jira ID: ND-4612)

Issue Description

When a payment is made in a loan contract, it is not satisfying the bill even though the paid amount is same as the due amount.

Resolution

This issue is fixed.

7.9 Duplicate JOA bills getting generated with the same Due Date (Jira ID: ND- 4602)

Issue Description

If there is a partially satisfied bill on a contract, the system is generating duplicate I0A bills with the same Due Date.

Resolution

This issue is fixed.

7.10 System skipping the repayment schedule of March when loan is rescheduled in February (Jira ID: ND-4581)

Issue Description

If a loan has a repayment date at the end of the month and if it falls on a holiday, and when such a loan is rescheduled in February, then the system is skipping the repayment scheduled date of March and considering the repayment scheduled date of April as the next repayment date.

Resolution

This issue is fixed.

7.11 DynamicJobWrapper job failing with an error (Jira ID: ND-4565)

Issue Description

When the DynamicJobWrapper job is run, the records queried by the system are also including those records that are not required causing too many records to be queried resulting in the job failing with the following error: "First error: List of size 18727785 exceeds heap limit. Try a smaller batch size."

Resolution

This issue is fixed as the system now queries only those records that are required.

7.12 LoanDisbursalTxnSweepToACHJob is failing with a null pointer exception (Jira ID: ND-4525)

Issue Description

When the LoanDisbursalTxnSweepToACHJob job is run, it is failing with a null pointer exception.

Resolution

This issue is fixed.

7.13 AccrualEntryJob is failing with the heap size error (Jira ID: ND-4508)

Issue Description

On running the AccrualEntryJob job, it is failing with the following error message due to the system querying all the loan IDs instead of querying only those that are for the Line of Credit type of loans:

"Failed to process batch for class 'loan.AccrualEntryJob' for job id '7075m00000G2e8z' caused by: System.LimitException: Apex heap size too large: 12406471."

Resolution

This issue is fixed as the system now filters the loan IDs and passes only the required ones to the query.

7.14 Interest Remaining calculated incorrectly if payoff transaction is reversed (Jira ID: ND-4460)

Issue Description

If a payoff transaction is reversed in an FAMZ loan that has some accrued interest and Interest Posting enabled, then the Interest Remaining is calculated incorrectly.

Resolution

This issue is fixed.

7.15 Dynamicjobwrapper failing with an error (Jira ID: ND-4635)

Issue Description

When the DynamicJobWrapper job is run, the records queried by the system are also including those records that are not required causing too many records to be queried resulting in the job failing with one of the following errors:

• "First error: Apex heap size too large"

• "First error: Apex CPU time limit exceeded"

Resolution

This issue is fixed.

7.16 Error when clicking the Cancel/Stop ACH button in the contract (Jira ID: ND- 4654)

Issue Description

On clicking the Cancel/Stop ACH button in the contract, the following error message is getting displayed: "CL010101: Unexpected Exception SObject row was retrieved via SOOL without querying the requested field: loan_Loan_Accountc.loanloan_Product_Name_r at line 26"

Resolution

This issue is fixed.

7.17 System is creating duplicate IPTs (Jira ID: ND-4647)

Issue Description

On the Interest Posting due date, the system is creating the Interest Posting Transaction, but it is not updating the Next Interest Posting Date and other interest posting-related fields on the contract. Due to this, while clearing a payment that is made, it is creating another IPT with the same value resulting in an incorrect interest being charged for the payment.

Resolution

This issue is fixed.

7.18 Principal Adjustment - Subtract is increasing the deposit amount instead of decreasing the principal (Jira ID: ND-4637)

Issue Description

If a Principal Adjustment - Subtract is carried out in a loan contract that has the Payment Application Mode defined as Deposit, then instead of decreasing the principal amount, the system is increasing the deposit amount.

Resolution

This issue is fixed.

7.19 Oldest Unpaid Due Date not getting updated on rescheduling a loan (Jira ID: ND-4633)

Issue Description

If a contract is rescheduled to change the Repayment Start Date keeping the Maintain Delinquency flag checked, and if the last bill is paid, then the Oldest Unpaid Due Date is not getting updated.

Resolution

This issue is fixed as now the Oldest Unpaid Due Date is getting updated when the Repayment Start Date is changed.

7.20 Deposit Adjustment to reduce the Deposit Amount is resulting in an error (Jira ID: ND-4585)

Issue Description

If a Deposit Adjustment is made in a loan contract to reduce the Deposit Amount, it is failing, and the system is displaying the following error message incorrectly indicating that the effective deposit amount after reduction is less than the Minimum Deposit Balance defined in the contract even when it is greater than the Minimum Deposit Balance: "Withdrawal/Transfer not allowed."

Resolution

This issue is fixed.

7.21 System is updating the loan interest rate even when the Deposit rate is not changed (Jira ID: ND-4542)

Issue Description

If the system encounters an error with the Deposit rate change, then during the rate change process, the interest rate of the loan is getting updated even when the Deposit rate remains unchanged.

Resolution

This issue is fixed as now if the system encounters an error with the Deposit rate change, the system does not change the deposit rate and so the loan interest rate remains unaffected too.

7.22 IPT due dates are not getting updated correctly and system is generating duplicate bills after rescheduling (Jira ID: ND-4324, ND-4639)

Issue Description

On rescheduling a loan contract by updating the value in the New Due Day field, the due dates ofthe IPTs are not getting updated correctly resulting in system generating duplicate bills.

Resolution

This issue is fixed.

7.23 Loan payoff is increasing the deposit amount (Jira ID: ND-4646)

Issue Description

While paying off a loan that has a Deposit account, the system is increasing the Deposit amount by the payoff amount instead of paying off the loan.

Resolution

This issue is fixed.

7.24 Error while generating payoff quote using the AP/ (Jira ID: ND-4685)

Issue Description

While using the API to generate the payoff quote, the system is throwing the following exception:

"System.SObjectException: SObject row was retrieved via SOOL without querying the requested field: loan_Loan_Accountc.loanLoan_Parameters_r"

Resolution

The resolution includes the following:

• This issue can be resolved by updating the API to include the Loan Parameters in it.

• The NullPointerException is now handled to avoid any exceptions that may be thrown due to a null value that could be passed in the API.

7.25 Error when clicking the Cancel button in CL Contract page of 02 Marketplace (Jira ID: MD-452)

Issue Description

In the 02 Marketplace application, on the CL Contract page, when the Cancel button is clicked to cancel a loan, the system is displaying the following error message: "Page cancelLoan does not exist."

Resolution

This issue is fixed.

7.26 System is not allowing backdated interest waiver transactions to be created (Jira ID: ND-4669)

Issue Description

While trying to perform an interest Waiver Action, the Waiver window is not having the ability to specify a transaction date for a backdated interest waiver transaction.

Resolution

This issue is fixed.

7.27 Multiple Primary AMZ schedules getting generated after rescheduling a loan on multiple tabs or windows (Jira ID: ND-4651)

Issue Description

If the rescheduling page for a loan contract is opened on more than one tab or window, and if that loan is rescheduled on all those tabs and windows in the same way, then instead of marking all the AMZ schedules that are generated before the last rescheduled action as Archived, the system is marking all the AMZ schedules generated due to the rescheduling on each of the tabs and windows as Primary resulting in multiple active schedules for the loan.

Resolution

The issue is fixed, and now the system is allowing only the first rescheduling to take place if the rescheduling page of that loan contract is opened on more than one tab or window.

7.28 Principal Remaining option not getting displayed while rescheduling (Jira ID: ND-4619)

Issue Description

While rescheduling a loan, the system is not displaying the Principal Remaining option in the Reschedule Balance field.

Resolution

This issue is fixed.

7.29 Interest Waiver Action is adding the waived amount to the deposit account (Jira ID: ND-4641)

Issue Description

After reversing an LPT and then posting a new LPT of the same transaction amount but a different spread with an increased principal amount and a decreased interest amount, then on performing the interest Waiver Action for the remaining interest amount, the system is adding this remaining interest amount to the deposit account.

Resolution

This issue is fixed.

7.30 Rescheduling and Installment Payment is failing as the LAD is updated to a future date (Jira ID: ND-4708)

Issue Description

In an F-AMZ loan, when an Installment Payment is made with the Transaction Amount greater than the Threshold amount that is set on the contract, the contract is getting rescheduled with Reschedule Status updating to Pending and the LAD updating to the next due date. Due to the LAD date being a future date, the system is not allowing the user to reschedule the contract and make another Installment Payment.

Resolution

This issue is fixed, and now the system is allowing the user to make another Installment Payment even if the Reschedule Status is Pending or Failure.

7.31 Interest Remaining is incorrectly calculated in the Payoff Quote (Jira ID: ND- 4707)

Issue Description

In an F-AMZ loan where Pre Bill Days is defined, when an Installment Payment is made on the due generation date, a pending IPT is created with the Interest Posted amount as the Interest Remaining on the contract. Then if the Payoff Quote is generated on this same due generation date, then the LAD gets updated to the pending IPT Transaction Due Date. Now when the payoff quote is generated for this LAD date, the Interest Remaining in this second Payoff Quote is incorrectly getting calculated as double the amount of the Interest Remaining in the first Payoff Quote.

Resolution

This issue is fixed.

7.32 Rescheduling on Loan Balance and validating Interest Rate Schedule is displaying an error (Jira ID: ND-4693)

Issue Description

While rescheduling a loan with Reschedule Balance as Loan Balance and validating the Interest Rate Schedule, the system is throwing the following error message: "CL019432: Maintain delinquency flag must be unchecked to reschedule the loan on Loan Balance."

Resolution

This issue is fixed.

7.33 LateChargeCreatorJob is failing with an error (Jira ID: ND-4677)

Issue Description

Even if there are no loans with Late Fees in the Fee Set, the LateChargeCreatorJob is failing with the following error message: "Apex heap size too large."

Resolution

This issue is fixed, and now while running the LateChargeCreatorJob, the system is checking and processing only those loans that have the Late Fees.

7.34 Last Interest Rate Change Date field is not getting updated after clicking Submit Reset button (Jira ID: ND-4611)

Issue Description

On clicking the Submit Reset button to change to another rate schedule, the Last Rate Change Date is not getting updated.

Resolution

This issue is fixed.

7.35 Periodic fee charge is not getting generated for the last cycle if the charge generation date is same as current maturity date (Jira ID: ND-4686)

Issue Description

The periodic fee charge is not getting generated for the last cycle if the charge creation date falls on the same date as the current maturity date.

Resolution

This issue is fixed.

7.36 DynamicJobWrapper job failing with an error (Jira ID: ND-4740)

Issue Description

When the DynamicJobWrapper job is run, the records queried by the system are also including those records that are not required causing too many records to be queried resulting in the job failing with the following error: "First error: List of size 17607051 exceeds heap limit. Try a smaller batch size."

Resolution

This issue is fixed as the system now queries only those records that are required.

7.37 Incorrect Next Due Date calculation in Semi-Monthly-PD Payment Frequency loans (Jira ID: ND-4691)

Issue Description

If we select Semi-Monthly-PD as the Payment Frequency and select the Second Payment Date as the end of the month, then the value of the Next Due Date is changing to 31 for months with 31 days or the end of that month. For example, if we select 28, 29, or 30 as the Second Payment Date in a month where the maximum days are 28, 29, or 30, then for months with 31 days, it is changing the Next Due Date to 31 instead of 28, 29, or 30, which is the actual day selected.

Resolution

This issue is fixed as the system now considers the Next Due Date as the actual date as provided in the Second Payment Date unless the Second Due Day is given as 31 wherein the Next Due Date is calculated as the end of that month.

7.38 Second Payment Date is not reverting to the original date after reversing the rescheduling (Jira ID: ND-4750)

Issue Description

If a loan that has a Payment Frequency as Semi-Monthly-PD is rescheduled to update the New Second Due Day field to a different date, and then the rescheduling is reversed, then the Second Payment Date field displayed on the rescheduling page is not reverting to the original value.

Resolution

This issue is fixed as the Second Payment Date field is not required to be updated after the reversing and hence is now not displayed in the rescheduling page. However, the Second Due Day field is successfully updated to the original value after the reversing.

7.39 Rescheduling is failing with an error (Jira ID: ND-4729)

Issue Description

When a loan is rescheduled using the rescheduleALoan API, it fails with the following error message: "SObject row was retrieved via SOOL without querying the requested field: loan Loan_account_Due_Details c.loan Remarks c"

Resolution

The issue is fixed as the missing field is now added to the bill query.

7.40 Creation of backdated payments is not regenerating /PT (Jira ID: ND-4725)

Issue Description

When a backdated payment is made, the Next Interest Posting Date is skipping a cycle and hence payment made for the skipped cycle is not satisfying the interest portion.

Resolution

This issue is fixed.

7.41 Interest is calculated incorrectly in 10 (Jira ID: ND-4702)

Issue Description

For loans with Investment Order (10), the InvInvestment Order Balance is not considering the capitalized additional interest resulting in an incorrect calculation of the interest in the Investment Order.

Resolution

This issue is fixed.

7.42 Investment Order Balance is not considering the already posted advance additional interest amount (Jira ID: ND-4695)

Issue Description

For an Investment Order with advance additional interest enabled, on the interest posting date, the Investment Order Balance is not considering the already posted advance additional interest amount and is only considering the interest posted amount on the current interest posting date.

Resolution

This issue is fixed as the Investment Order Balance now considers both the current and the already posted advance additional interest amounts.

7.43 I0 Interest Posting Job is not considering /O's Compounding Frequency (Jira ID: ND-4694)

Issue Description

In loans with IOs (Investment Order), the 10 Interest Posting Job is considering the loan contract's Compounding Frequency instead of the IO's Compounding Frequency resulting in an incorrect calculation for the Interest Posted for I0.

Resolution

This issue is fixed.

7.44 CL Contract page requires horizontal scrolling to view a large portion of the screen (Jira ID: ND-4700)

Issue Description

On the CL Contract page, when the page is rendered at 100%, extensive white space is getting displayed on the screen requiring scrolling to the right to view a large portion of the screen.

Resolution

This issue is fixed as now the system gives you an option to remove the tabs that you do not require from the CL Contract page resulting in fewer tabs to fit the screen to avoid the scrolling.

7.45 System displaying error after the rescheduling of the loan to change the New Second Due Day field (Jira ID: ND-4769)

Issue Description

After a loan is rescheduled to change the value of the New Second Due Day field, the system is displaying the following error message: "CL019401: The second installment date must be at least five days later than the payment start date."

Resolution

This issue is fixed.

7.46 System is updating incorrect Interest Only Period after rescheduling of a loan (Jira ID: ND-4767)

Issue Description

After a loan is rescheduled to change the value of the Margin Rate field, the system is updating incorrect Interest Only Period field value.

Resolution

This issue is fixed.

7.47 Error while downloading an account statement from a loan quick menu (Jira ID: ND-4315)

Issue Description

The system is throwing an error while downloading an account statement from Loan Quick Menu of a contract in Lightning.

Resolution

This issue is fixed.

7.48 Fee accrual continues even after a fee is waived off (Jira ID: ND-4534)

Issue Description

The Accrual job is continuing to accrue a fee even after the fee is waived off.

Resolution

This issue is fixed.

7.49 Future dated pay off quotes does not factor the interest postings and capitalizations until the payoff date (Jira ID: ND-4735)

Issue Description

Future dated pay off quotes does not factor the interest postings and capitalizations until the payoff date.
The system should factor in the interest capitalization amount and the additional interest being accrued because of the interest capitalization and then generate the quote.

Resolution

This issue is fixed.

7.50 Second Payment Date is not available for rescheduling of a loan (Jira ID: ND- 4776)

Issue Description

When rescheduling a contract to a Semi-Monthly PD Payment Frequency, the system is throwing the following error messages:

"Please specify the second installment date, as the payment frequency for this loan is Semi­ Monthly PD (Per Day)."

• "Unexpected Exception Attempt to de-reference a null object at line 158."

Resolution

This issue is fixed as the contract rescheduling page now displays the Second payment Date field for the second payment date to be specified.

7.51 The Floating Rate Percentage field does not allow negative values (Jira ID: ND-4804)

Issue Description

The Floating Rate Percentage field is not accepting an index rate lesser than zero.

Resolution

This issue is fixed.

7.52 Creation of backdated payments is not regenerating IPTs (Jira ID: ND-4795)

Issue Description

When a backdated payment is made, the Next Interest Posting Date is skipping a cycle and hence payment made for the skipped cycle is not satisfying the interest portion.

Resolution

This issue is fixed.

7.53 System is not updating loan Interest Remaining field after rescheduling of a loan (Jira ID: ND-4757)

Issue Description

When a loan is manually rescheduled and the Maintain Delinquency flag is set to false, the system is not updating the Interest Remaining field value and that is generating an incorrect payoff quote amount.

Resolution

This issue is fixed.

7.54 System is calculating an incorrect payoff amount on generating new payoff quote after a payoff transaction is reversed (Jira ID: ND-4746)

Issue Description

If a payoff transaction is reversed in an FAMZ loan that has some accrued interest and Interest Posting enabled, then the system is incorrectly updating the Interest Remaining and thus the payoff amount is calculated incorrectly on generating a new payoff quote.

Resolution

This issue is fixed.

7.55 System is not allowing to change the Transaction Date for a backdated Certificate Rate Change for an Investment Order (Jira ID: ND-4791)

Issue Description

On clicking Certificate Rate Change for an Investment Order, the system is not allowing to update the Transaction Date field to perform a backdated certificate rate change transaction.

Resolution

This issue is fixed as the Transaction Date field is now made editable in the Certificate Rate Change page.

7.56 Error on rescheduling a loan with an active one-time APS (Jira ID: ND-4751)

Issue Description

When a loan is set up with a one-time APS and is rescheduled with the Repayment Start Date as greater than the debit date of the APS, the following error message is displayed:

"CL010101: Unexpected Exception Attempt to de-reference a null object at line 3095"

Resolution

This issue is fixed as the system is now correctly handling the rescheduling with one-time APS setup.

7.57 Future-dated payoff quote for a Single Payment payment frequency is not considering the interest postings and capitalizations till the payoff date (Jira ID: ND-4735)

Issue Description

When a future-dated payoff quote is generated for a Single Payment payment frequency, the payoff amount does not include the interest capitalization amount and the additional interest accrued.

Resolution

This issue is fixed.

7.58 Price Per Share value in 10 sale with Transfer Income flag enabled is truncated to two decimal places on the UI (Jira ID: MD-457)

Issue Description

On clicking Sale to sell an 10 with Transfer Income flag enabled, if the Price Per Share value specified in the UI consists of more than two decimal places, the system is truncating it to two decimal places while calculating the Buying Price resulting in an inaccurate value.

Resolution

This issue is fixed.

7.59 FIT loan is generating a bill of the Due Amount equal to the interest posted on the loan (Jira ID: ND-4853)

Issue Description

If an FIT loan is created with the Interest only Period as zero and the Actual Interest Payments flag as true, then the system is generating the bill with the value of the Due Amount as the interest posted amount.

Resolution

This issue is fixed.

7.60 Transaction Summaries is displaying the Interest Posting creation date instead of the due date (Jira ID: ND-4854)

Issue Description

For the Interest Posting Transactions, the Transaction Summaries is displaying the creation date of the Interest Posting Transaction instead of the interest posting date in the Transaction Date column.

Resolution

This issue is fixed.

7.61 System is calculating an inaccurate Interest Posted value when a payment is made before the Due Date (Jira ID: ND-4788)

Issue Description

When a payment is made before the due date for a contract in which the Excess Threshold% for Reschedule is configured, the contract is getting rescheduled, but the system is updating an inaccurate value in the Interest Remaining field resulting in an incorrect Interest Posted value on the Due Date.

Resolution

This issue is fixed.

8.   Known Issues

This section briefly describes known issues known in the Platinum release of Q2 Loan Servicing and Marketplace.

8.1 EOD accrual calculation is not working for loan contracts and for additional interest components when Advance Interest is enabled (Jira ID: ND-4851)

Issue Description

The system is not using the EOD accrual calculation methods for loan contracts that have Advance Interest enabled and for additional interest components with Advance Interest enabled in them. EOD accrual calculation is not getting considered also when Collect Advance Interest on Disbursal is enabled for both loan contracts and additional interest components.

8.2 Interest Diagnostics script is generating incorrect results for loan with Redraw­ related transactions (Jira ID: ND-4908)

Issue Description

When a loan is Redraw-enabled, the interest diagnostics script is generating incorrect results for the Redraw-related transactions.

8.3 Using the View Consolidated Amortization Schedule menu is resulting in the screen to shake (Jira ID: ND-4893)

Issue Description

On clicking View Consolidated Amortization Schedule in a Master Loan, the screen starts shaking if one of the following actions is taken:

• Select the From Date and To Date and then click Search.

• Select Number of Records as 5 and then click Search.

8.4 After downloading the Loan Transaction Summary, the downloaded Account Statement is not displaying the Contract ID (Jira ID: ND-4903)

Issue Description

In the Loan Quick Menu, on clicking Download for Loan Transaction Summary, the downloaded Account Statement is not displaying the Contract ID for each transaction statement.

8.5 New button for creating a contract is missing in the Lightning view (Jira ID: ND-4884)

Issue Description

In the Lightning view of Q2 Loan Servicing, on clicking the CL Contracts tab, the system is not displaying the New button that is used to create a new contract.

8.6 System is not updating Current Reserve Amount of the Loan Transaction Summary object after redrawing (Jira ID: ND-4925)

Issue Description

When redrawing is done in a loan, the Reserve Amount for Next Due field on the loan contract is getting updated, but the Current Reserve Amount field of the Loan Transaction Summary object is not getting updated correctly.

9.   New and Modified Objects

This section briefly describes the new and modified objects in the Platinum release of Q2 Loan Servicing and Marketplace.

9.1 New Objects

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

9.2 Modified Objects

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

10.   New and Modified APIs

This section briefly describes the new and modified APIs in the Platinum release of Q2 Loan Servicing and Marketplace.

10.1 New APIs

There are no new APIs added in the Platinum release of Platinum.

10.2 Modified APIs

There are no APIs modified in the Platinum release of Q2 Loan Servicing and Marketplace.

11.   Global Methods

This section briefly describes the global methods that are added or modified in the Platinum release of Q2 Loan Servicing and Marketplace.

12.   Post GA Release

Follow this section for the details on the issues fixed in the patches on the Platinum release.

12.1 Issues fixed in the Q2 Loan Servicing 3.6019.235 patch

12.1.1 The system is generating bills with Due Amount as zero (Jira ID: PDRFF-1585/ND-7925)

Issue Description

The system is generating bills with Due Amount as zero when the amount in the Principal Remaining field is less than the Delinquent Amount. While a bill is getting generated, it must compare the Delinquent Amount with the sum of the Principal Remaining and the Fee Remaining amounts.

Example to understand the behavior after the fix

1. Set the Current System Date to March 01, 2013, and create a loan contract with the following values:

   • Loan Amount =$100,000

   • Rate = 10%

   • Terms = 12

   • Time Counting Method = Month and Days

   • Payment Frequency = Daily

   • Payment Start Date = January 15, 2020

   Add a fee with the following values:

   • Name = Disbursal Fee

   • Time of Charge = Time of disbursement

   • Fee Calculation Method = Fixed

   • Amount = $50,000

   • Include in dues = True

   • Include in Schedule = True

   • Add a fee set and link the fee to it

   • Add this fee set to product or link it with Contract before disbursal

2. Set the Current system date to January 15, 2020. Approve and disburse the loan.

3. A disbursal charge is created.

4. Reschedule the loan with the Interest Rate as zero, and Maintenance Delinquency set to True.

5. Move the current system date to February 15, 2020, to generate Bill-1.

6. Create LPT to pay the amount that is equal to the amount in Bill-1.

7. Move the current system date to the next due date and pay bill on the same day.

   Repeat this till February 22, 2020.

8. Move the current system date to May 23, 2020, without making any further payment reverse all the LPTs created above.

9. Now the Principal Remaining = Delinquent Amount.

10. Move the current system date to February 24, 2020.

    • Before the fix: On February 24, 2020, the system generated an incorrect Bill with Due Amount = $0.

    • After the fix: On February 24, 2020, the system is generating a correct Bill with Due Amount = $12,500.

    • Delinquent Amount = $112,500

    • Amount Due Till Current = $112,500

    • Days Past Due = 9

    • Principal Remaining = $100,000, Fee Remaining = $50,000

Resolution

The issue is now while generating the bills, the system is considering fee when comparing the Delinquent Amount with Principal Remaining and Fee. Therefore the bills are correctly generating according to the repayment schedule.

12.2 Issues fixed in the Q2 Loan Servicing 3.6019.234 patch

12.2.1 The system is calculating the last payment on the contract incorrectly (Jira ID: PDRFF-3069/ND-7863)

Issue Description

After a backdated LPT reversal during the Interest Only period, the system is reverting the value of the Next Due Date field but it is not reverting the value of the Actual Next Installment Date field. Due to this, for contracts with n-1 interest only periods (considering n as total number of terms) the system is not generating the second last bill and after the n-2 bill the system is directly generating the last bill. , the system is skipping one bill for such contracts.

Example to understand the behavior after the fix

1. 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 = 5

   • Interest Only Period = 4

   • Pre-bill Days = 5

   • Time Counting Method = Month and Days

   • Payment Frequency = Semi-Monthly

   • Payment Start Date = April 01, 2013

2. Approve and disburse the loan.

3. Move the Current System Date to April 01, 2013 (Next Due Date). Bill-1 for the value $83.33 is generated.

4. Create LPT-1 for the Bill-1's amount, that is, $83.33.

5. Move the Current System Date to April 16, 2013 (Next Due Date).

6. The system creates Bill-2.

7. Create LPT-2 for the Bill-2's amount, that is, $41.67.

8. Move the Current System Date to the Next Due Generation Date, that is. April 26, 2013.

9. The system creates Bill-3. The values are updated as follows:

   • Next Due Generation Date = May 11, 2013

   • Next Due Date = May 16, 2013

   • Actual Next Installment Date = May 16, 2013

   • Interest Accrued = $27.78

10. Reverse LPT-2 created above.

11. Bill-3 becomes non-primary, Bill-2 is unpaid, and the values are updated as follows:

    • Last Accrual Date = April 16, 2013

    • Interest Posted = $41.67

    • Interest Paid = $83.33

    • Interest Accrued = $27.78

    • Next Due Generation Date = April 26, 2013

    • Next Due Date = May 01, 2013

    • Actual Next Installment Date = May 01, 2013

      • Before the fix the system displayed, Actual Next Installment Date = May 16, 2013. (Incorrectly. As Actual Next Installment Date value was not getting reverted.)

Resolution

The issue is now fixed and after a backdated LPT reversal during the Interest Only period, the system is reverting the value of the Actual Next Installment Date field correctly.

12.3 Issues fixed in Q2 Loan Servicing 3.6019.233

12.3.1 On running the Periodic Charge job, the system is displaying a heap size error message (Jira ID: PDRFF-2858/ND-7681)

Fixed Version

This issue has been fixed in the following version:

• Q2 Loan Servicing Platinum (3.6019.233)

Issue Description

On running the Periodic Charge job, the system is displaying a heap size error on the Apex Jobs page and hence no periodic charge is getting created on the contracts.

Example to Understand the Issue

1. Create a loan contract on March 01, 2013, with the following values:

   • Add Periodic Fee for $100,

   • Include in Dues = True

   • Include in Schedule = True

     Add it to the fee set and link the contract or the fee set.

   • Loan Amount = $1,000

   • Rate = 12%

   • Terms = 1

   • Time Counting Method = Actual Days(366)

   • Payment Frequency = Single Payment

   • Payment Start Date = May 01, 2013

   • IPT Frequency = Monthly

2. Move the Current System Date to May 01, 2013 without batch jobs.

3. Run the Periodic Charge job using DAG.

   The system is displaying a heap size error on the Apex Jobs page and hence no periodic charge is getting created on the contract.

Resolution

The issue is now fixed and the system is generating a periodic charge on the contract without displaying any error message.

12.4 Issues fixed in Q2 Loan Servicing 3.6019.232

12.4.1 The system is creating an excess Payoff IPT on internal transfer of an LPT (Jira ID: PDRFF-2788/ND-7653)

Fixed Version

This issue has been fixed in the following version:

• Q2 Loan Servicing Platinum (3.6019.232)

Issue Description

During mid-cycle internal transfers or deposit to loan transfers, the system is creating excess payoff IPT. This is occurring when a payment of amount higher than the payoff balance amount is made toward the loan in the middle of the billing cycle.

In this scenario, the system is incorrectly identifying the internal transfer LPT as a payoff LPT, resulting in the generation of an additional IPT for the interest accrued up to the current date. Although the contract status remains in the active state, the surplus IPT is appearing on the statements.

An example explaining this issue

1. Create a loan contract with the following values on March 01, 2013:

   • Loan Amount = $140,000

   • Interest Rate = 10% (Fixed)

   • Terms = 10

   • Time Counting Method = Month And Days

   • IPT Frequency = Monthly

   • Payment Frequency = Monthly

   • Adjust Deposit Amount In Payoff = True

2. Create a Deposit record as follows:

   • Deposit Amount = $40,000

   • Deposit Rate = 10%

   • Priority = 1

3. Move the Current System Date to March 10, 2013.

   The values are updated as follows:

   • Interest Accrued = $250

   • Deposit Interest Accrued = $100

4. Create an LPT with the following values:

   • Payment Amount = $80,000

   • Payment Mode = Cash

   • PAM = Deposit

   • Transaction Date = March 10, 2013

5. Since loan is in Active - Good Standing status, the LPT amount is stored in Deposit field.

   The values are updated as follows:

   • Deposit Amount = $120,000

   • Today's Payoff (approx.) = $20,250

   • Loan Balance = $140,000

   • Principal Rem = $140,000

   • Reserve Amount for Next Due = 0

   • Interest Remaining = $250

   • Interest Accrued = Interest Posted = Interest Capitalized = $0

6. Create an internal transfer LPT using Quick Menu. Make a Deposit to Loan Transfer of amount $100,000.

   The system is creating an excess Payoff IPT of $250 although the Loan Balance is greater than Deposit Amount present. Last Interest Posting Date = March 10, 2013.

Resolution

The issue is fixed, now after the deposit-to-loan transfer, the deposit value is adjusted to reflect the transaction, ensuring that the correct comparison is made with the write-off amount.

12.5 Issues fixed in Q2 Loan Servicing 3.6019.229

12.5.1 Rejected and reversed LPTs are being considered by Loan Payment Filegen job (Jira ID: PDRFF-2111/ND-7253)

Fixed Version

This issue has been fixed in the following version:

• Q2 Loan Servicing Platinum (3.6019.229)

Issue Description

While processing the data, the Loan Payment Filegen job is considering the Rejected LPTs and Reversed LPTs. Since the system is considering these LPTs it creates an incorrect output while processing the NACHA file.

Example to understand the behavior after the fix

Let us consider an example where LoanPaymentFilegenDynamicJob is not considering the reversed LPTs while processing the data.

1. Create a loan contract with the following values on March 1, 2013:

• Loan Amount = $10,000

• Terms = 10

• Time Counting Method = Month And Days

• Payment Frequency = Monthly

• Interest Posting Transaction = Monthly

• Rate = 10%

2. Approve and disburse the loan.

3. Move the Current System Date to April 1, 2013, which is the Next Due Date.

4. Create an LPT of $1000 with the Payment Mode set to ACH.

5. Reverse this LPT.

6. Go to Servicing Configuration > RunDAG Jobs > select LoanPaymentFilegenDynamicJob and Record IDs = < Loan Account ID >. Run this job.

   On Apex Jobs, the Total Batches is 0 for LoanPaymentFilegenDynamicJob.

Resolution

This issue is now fixed. Since there are no batches processed, this indicates that the job is not considering the reversed and rejected LPTs.

12.6 Issues fixed in Q2 Loan Servicing 3.6019.228

12.6.1 The Last Due Date is getting updated incorrectly as null after the bill is paid (Jira ID: PDRFF-2569/ND-7108)

Fixed Version

This issue has been fixed in the following versions:

• Q2 Loan Servicing Platinum (3.6019.228)

Issue Description

When a loan is created (regular and deposit) the Last Due Date field value is getting deleted, due to which the bills are getting generated for higher values and there by causing issue with IPT’s and payments ultimately.

Example to understand the issue

1. Let us create a loan with the following details:

   • Loan Amount = $10,000

   • Interest Rate = 10%

   • Terms = 10

   • Time Calculating Method = Month And Days

   • Payment Frequency = Monthly

   • Interest Posting Transaction = Monthly

   • Deposit Offset Days = 0

   • Auto Change Deposit Rate = True

   • Payment Adjustment Mode = Deposits

2. Let us move to March 1, 2013, and create loan as per given precondition and a deposit record:

   • Deposit Amount = $6,000 and Rate =10%.

3. Let us go to the Last Due Date April 1, 2013.

4. Let us reschedule the loan with Maintain Delinquency = True and set Interest Only Period = 2.

5. Preview and Save .

6. Let us move to the next Due Date May 1, 2013.

   Now, the system updates the value of Last Due Date as NULL instead of May 1, 2013.

Resolution

This issue is fixed. Now, the system updates the Last Due Date as May 1, 2013 after the bill is paid.

Known Issues: System is generating an Interest Only bill for the Equal Monthly Installment cycle when a repayment plan is provided (Jira ID: ND-7122)

Known Issue Description

The system is generating bill of the Interest Posted amount for the Equal Monthly Installments cycle instead of generating a bill with both the principal and interest amounts as per the repayment plan.

Example to Understand the Issue

1. Let us create a loan with the following details:

   • Loan Amount = $10,000

   • Interest Rate = 10%

   • Terms = 10

Let us go to March 1, 2013. Create loan with the following repayment plan:

2. Approve and disburse the loan.

3. The system generates Amortization Schedule correctly as per the repayment plan.

4. Now, let us go to New Due Generation Date April 1, 2013.

The bill is generated with the amount of Interest Posted instead of Principal + Interest. Instead the system must generate a Principal + Interest bill according to the repayment plan or schedule.

12.6.2 Deposit Amount is getting calculated incorrectly when loan has multiple deposits with child records(Jira ID: PDRFF-2446/ND-7039)

Fixed Version

This issue has been fixed in the following versions:

• Q2 Loan Servicing Platinum (3.6019.228)

Issue Description

In a loan contract when there are multiple deposits and child deposits is created on different dates for various parent deposits the system is considering the cutoff date for the latest child deposit, neglecting other parent deposits and resulting in incorrect transaction amounts for new child deposit entries.

Example of the system behavior after the fix

1. Let us create a loan with the following details:

   • Loan Amount = $10,000

   • Interest Rate = 10%

   • Terms = 10

   • Time Calculating Method = Month And Days

   • Payment Frequency = Monthly

   • Interest Posting Transaction = Monthly

2. Let us go to March 1, 2013.

Create a loan with two deposit records with following values and then approve and disburse the loan:

• Deposit 1: $1,500, Rate=10%, and Priority = 1

• Deposit 2 : $0, Rate=10%, and Priority = 0

3. Let us move to March 8, 2013.

4. Let us make deposit transfer from Deposit 1 to Deposit 2 of $1,000.

5. Let us move to March 15, 2013.

6. Make a mid cycle payment of $100. It goes towards Deposit 1.

7. Now let us go to the next Due Date April 1, 2013 and allow LoanDepositPaymentCreationDynamicJob batch job to create the internal transfer.

The system is calculating the amount of Deposit 2 as negative.

Resolution

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

12.7 Issues fixed in Q2 Loan Servicing 3.6019.226

12.7.1 MarkFieldsAccessibleJob is giving access to custom objects too (Jira ID: PDRFF-2503/ND-7011)

Fixed versions

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

• Q2 Loan Servicing Platinum (3.6019.226)

Issue description

MarkFieldsAccessibleJob gives access to custom objects as well. Ideally, MarkFieldsAccessibleJob is supposed to give access only to product objects.

Example to understand the issue

1. Use the following steps to create a custom object from Quick Find>Objects page.

2. Go to Profiles and create a Custom Profile or pick any existing Custom Profile.

3. Select Object Settings hyperlink.

4. Search the object created above. Open that object and make sure that no 'Object Permissions' is given to the newly created custom object.

5. Run MarkFieldsAccessibleJob job.

   This job runs for all the custom object so wait for all the instances to complete on Apex Jobs page. This gives user access not only to product object but also to custom objects.

Resolution

The issue is now resolved and the job does not give permission (read, write, or edit) for any custom object.

12.7.2 User is unable to configure Contingency Status Code Rules (Jira ID: PDRFF-2136/ND-6998)

Fixed versions

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

• Q2 Loan Servicing Platinum (3.6019.226)

Issue description

User is employing the following steps to configure the Contingency Status Code rules, within the system:

1. Go to the Servicing Configuration section.

2. Accessing the Contingency Rules menu select Add Rules to initiate the rule creation process.

However, during this configuration attempt, they are unable to add rules and are receiving the following error message:

Attempt to de-reference a null object.

An unexpected error has occurred. Your solution provider has been notified. (clcommon)

Resolution

This issue is now fixed.

12.7.3 User is unable to create payments with future dues when Delinquency basis is set to Schedule Balance (Jira ID: PDRFF-2119/ND-6944)

Fixed versions

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

• Q2 Loan Servicing Platinum (3.6019.226)

Issue description

User is unable to create payments with future dues when Delinquency Basis is set to Schedule Balance.

Example to understand the issue

1. Let us create a loan with the following details and disburse it:

   • Loan Amount = $10,000

   • Interest Rate = 10%

   • Loan Terms = 10

   • Interest Only Terms = 4

   • Time Counting Method = Month and Days

   • Payment Frequency = Monthly

   • IPT Frequency = Billing

   • Capitalization = False

   • FIT = True

   • PAM = Deposit

   • Delinquency Basis = Schedule Balance

   • Adjust Deposit Amount In Payoff = True

2. Let us go to March 1, 2013 and create a LPT of amount $100 with Payment App Mode set to Future Dues.

System displays the following error:

Future Dues cannot be used if Delinquency basis is set to Schedule Balance.

Resolution

User is now able to create payments with future dues when Delinquency Basis is set to Schedule Balance.

12.8 Issues fixed in Q2 Loan Servicing 3.6019.223

12.8.1 The future bill is getting satisfied incorrectly when a backdated LPT is created (Jira ID: PDRFF-2246/ND- 6961)

Issue Description

In a loan contract with Payment Application Mode is Deposit, when a backdated LPT is created the amount is satisfying the future bill incorrectly and the LPT amount is not going towards the deposit.

Example to understand the issue

1. Let us create a loan with the following details:

   • Loan Amount = $10,000

   • Interest Rate = 10%

   • Term = 12

   • IPT Frequency = Billing Frequency

   • Time Counting Method = Month And Days

   • Payment Application Mode = Deposit

   • Is Interest Posting = True

   • Contract Start Date = March 1, 2013

   • Payment Frequency = Monthly

2. Let us add deposit of amount $500 , approve and disburse the contract.

3. Let us add an APS on the loan account with the following parameters:

   • Debit Date = April 1, 2013

   • Amount Type = Last Billed Amount

   • Frequency = Monthly

   • Payment Mode = ACH

4. Let us go to March 31, 2013, and create an LPT of amount $1,000, which is greater than the bill amount.

   The LPT is created with status as uncleared.

5. Now let us go to April 1, 2013, and clear the LPT.

LPT is marked as cleared and the values must be updated as follows:

• Bill must not get satisfied and must remain in unpaid status.

• After the LPT is cleared, the amount $1,000 must directly go to deposit.

However, the bill is getting satisfied incorrectly and the LPT amount is not going to deposit.

If an uncleared LPT is created before bill generation, and is cleared after bill generation, then the LPT amount must go to deposit.

Resolution

This issue is fixed now ,and the LPT amount is not satisfying the bill, and the LPT amount after bill generation is going to deposit correctly.

12.8.2 The interest is not getting posted on the contract when a backdated LPT is reversed using ACH (Jira ID: PDRFF-2244/ND-6792)

Issue Description

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

Example to understand the issue

1. Let us create a loan with the following details and disburse it:

   • Loan Amount = $10,000

   • Interest Rate = 10%

   • Term = 10

   • IPT Frequency = Billing Frequency

   • Time Counting Method = Month And Days

   • Enable Fee Capitalization = True

   • Contract Start Date = March 1, 2013

   • Payment Frequency = Monthly

2. Let us add a Fee component with the following parameters:

   • Fee Name = Periodic Fee

   • Fee Amount = $40

   • Enable Fee Capitalization = True

   • Periodic Fee Amount Type = Per period amount

   • Include in Dues = True

   • Include in Schedule = True

   • Periodic Charge Start Basis = First Payment Date

3. Let us go to March 5, 2013, and create an LPT-1 of amount $1,000.

   The values must be updated as follows:

   • Interest Remaining = $11.11

   • LAD = March 5, 2013

   • Loan Balance = $9000

4. Let us go to April 1, 2013.

   The bill is generated and the values must be updated as follows:

   • Interest Posted = $76.11

   • Bill-1 = $1,086.40

   • Periodic Charge = $40

   • LAD = April 1, 2013

   • Loan Balance = $9,116.11

5. Let us not clear the bill.

6. Now let us go to April 30, 2013, and reverse the LPT-1 created on March 5, 2013.

After reversal, the LAD gets updated to March 5, 2013, which is lesser than the New Interest Posting Date (April 1, 2013).

The values must be updated as follows:

• Interest Posted on April 1, 2013, gets reversed and a new IPT of amount $83.33 gets created.

• Next Interest Posting Date is updated to May 1, 2013.

• LAD = April 1, 2013.

• New Loan Balance = $10000+$40+$83.33 = $10,123.33 (Loan Balance + Periodic Charge + Interest Posted)

• Interest Accrued = ( Loan Balance*Rate*No of Days/360) (10123.33*10*29/360) = $81.55

• Delinquent Amount = $1,086.40

• Amount Due Till Current = $1,126.40

• Payment Amount on bill must be updated from $1,000 to $0.

6. Let us go to May 1, 2013, which is the Periodic Charge creation date.

The values must be updated as follows:

• Periodic Charge-2 gets created.

• Fee Capitalized = $80

• LAD = May 1, 2013.

• Next Interest Posting Date must be updated to June 1, 2013.

• Interest Accrued = ( Loan Balance*Rate*No of Days/360) (10123.33*10*30/360) = $84.36

• Interest Capitalized = $83.33 + $84.36 = $167.69

• Interest Posted = 167.69

• Loan Balance = $10,247.69

• Today's Payoff = 10,247.69

• Amount Due Till Current = $1,166.40

However, after the LPT is reversed and the Periodic Charge Job is run, the interest is not getting posted on the contract.

This is because for the contract with capitalized periodic charge, the LAD is occurring before the next interest posting date.

Resolution

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

12.9 Issues fixed in CL Common 3.6003.28

12.9.1 The system is displaying an error message while trying to create a new dynamic query on the CL Contract object (Jira ID: PDRFF-2160/ PD-1661)

Issue Description

While trying to create a new dynamic query, on selecting the CL Contract object to query on, the system is displaying the following error message:.

This issue is occurring because on selecting the CL Contract object to query, the system is unable to display all the fields on the page as the number of fields is exceeding the limit that the page can accommodate.

Resolution

This issue is now fixed, and the system is allowing user to create dynamic query on the CL Contract object without any error messages.

12.10 Issues fixed in Q2 Loan Servicing 3.6019.222

12.10.1 Excess Payoff IPT is getting created incorrectly when a payment that is more than the loan payoff amount is made and if the Adjust Deposit Amount in Payoff Flag is set to false (Jira ID: PDRFF-2036/ND-6893)

Issue Description

In a loan with Adjust Deposit Amount in Payoff Flag set to false, when a payment that is more than the loan payoff amount is made, the Excess Payoff IPT is getting created incorrectly.

The expected behavior is that if Adjust Deposit Amount in Payoff Flag is set to false and a payment that is more than the loan payoff amount is made, the Excess Payoff IPT must not get created and the amount must go to the deposit.

Example to understand the issue

1. Let us create a loan with the following details:

   • Loan Amount = $10,000

   • Interest Rate = 10%

   • Term = 10

   • IPT Frequency = Billing Frequency

   • Time Counting Method = Month And Days

   • Contract Start Date = March 1, 2013

   • Adjust Deposit Amount In Payoff = False

   • Payment Frequency = Monthly

2. Let us add deposit of amount $100 , approve and disburse the contract.

3. Let us go to March 10, 2013, and create an LPT of amount greater than the loan payoff quote amount with Payment Application Mode as Deposit.

The payment is cleared, and the values must get updated as follows:

• The LPT amount must be transferred to the deposit.

However, the values are updated as follows:

• Excess Payoff IPT is getting created incorrectly.

Resolution

This issue is fixed now, and a validation is added, where if a payment amount greater than the loan payoff amount is made and if the Adjust Deposit Amount In Payoff flag is set to false, then the amount goes to deposit correctly.

12.10.2 The Deposit Amount in the child deposit account is getting calculated incorrectly when an LPT is reversed (Jira ID: PDRFF-2207/ND-6877)

Issue Description

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

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

Example to understand the issue

1. Let us create a loan with the following details and disburse it:

   • Loan Amount = $10,000

   • Interest Rate = 10%

   • Term = 10

   • IPT Frequency = Billing Frequency

   • Time Counting Method = Month And Days

   • Contract Start Date = March 1, 2013

   • Payment Application Mode = Deposit

   • Auto change Deposit Rate = True

   • Payment Frequency = Monthly

2. Let us create a Deposit account on the existing contract with the following details and activate it:

   • Loan Amount = $0

   • Deposit Rate = 5%

   • Priority = 1

   • Deposit Offset Days = 0

3. Let us add an amount of $1,000 in the deposit account with Payment Application Mode as Deposit.

4. Let us go to March 15, 2013, and add an amount of $200 in the deposit account with Payment Application Mode as Deposit.

5. Let us go to March 17, 2013, and perform a Deposit Rate change through deposit adjustment.

6. Now let us go to March 31, 2013, and create an LPT of amount $200 with Payment Application Mode as Deposit.

   The Deposit Amount value must be updated to $1,700.

7. Let us go ahead and reverse the LPT created on March 31, 2013.

   The Deposit Amount must be updated to $1,500.

8. Now let us go to April 1, 2013. Since this is the second bill date, all internal jobs along with LoanDepositPaymentCreationJob is run.

The values must be updated as follows:

• A new child deposit record must be created.

• The deposit amount on the child deposit must be same as parent's current deposit amount.

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

Resolution

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

12.11 Issues fixed in Q2 Loan Servicing 3.6019.215

12.11.1 Changes made to support the two new Locale formats (Jira ID: PDRFF-2241/ND-6726)

Issue Description

The two locale format en_NZ and en_AU were not part of the system, and this was causing issues while performing transaction reversal.

Resolution

The issue is fixed now, and the two locale formats have been added to the system.

12.11.2 The rescheduling of a delinquent loan contract after principal adjustment is failing with an error message (Jira ID: PDRFF-2242/ND-6723)

Issue Description

When a delinquent loan contract with adjusted principal amount is rescheduled, the rescheduling is failing with the following error message:

'SObject row was retrieved via SOQL without querying the requested field: loan__Other_Transaction__c.loan__Interest_Rate__c'

Resolution

This issue is fixed, and delinquent loan contracts are getting rescheduled successfully.

12.11.3 Fees Remaining and Fees Capitalized are getting calculated with incorrect values (Jira ID: PDRFF-1941/ND- 6705)

Issue Description

In a loan that has two capitalized charges included, when a backdated payment is made after the reversal of an LPT, the system is calculating a negative value for Fees Remaining and an incorrect value for Fees Capitalized.

Example to understand the issue

1. 1. Let us create a loan contract with the following details and disburse it:

   • Is Interest Posting Transaction Enabled = True

   • Is Capitalization Enabled = True

   • Payment Frequency = Monthly

   • Contract Date = March 1, 2017

2. Let us add a fee set with the following fees:

   • Fee Name = Periodic fee

     • Fee Amount = $10

     • Include in Dues = True

     • Enable Fee Capitalization = True

     • Include in Schedules = True

     • Periodic Fee Amount Type = Per period amount

     • Frequency = Monthly

     • Time of Charge = Periodic

   • Fee Name = Other fee

     • Fee Amount = $5

     • Enable Fee Capitalization = True

     • Time of Charge = Other

3. Let us go to April 1, 2017.

   The values must be updated as follows:

   • Bill-1 and IPT are generated.

   • Periodic Fee of amount $10 is generated.

4. Let us go to April 2, 2017, and create an LPT-1 with Transaction Date as April 2, 2017.

5. Now let us create an ad-hoc charge, Other fee, of amount $5.

6. Let us go to April 7, 2017, and reverse the LPT-1.

   The values must be updated as follows:

   • Fees Remaining = $5

   • Fees Capitalized = $10

7. Now let us create a backdated LPT-2 with Transaction Date as April 2, 2017.

   The values must be updated as follows:

   • Fee Remaining = $0

   • Fee Capitalized = $5

8. Now let us go to April 9, 2017 and create a backdated LPT-3 with Transaction Date as April 5, 2017.

The values must be updated as follows:

• Fee Remaining = $0

• Fee Capitalized = $5

However, the values are updated as follows:

• Fee Remaining = -$5

• Fee Capitalized = $10

This issue is occurring because the system is not marking the Charge Capitalized flag as true for the charge created after the first backdated LPT on April 8, 2017. When another backdated payment is made , the system is recapitalizing the charges and thus calculating incorrect fee values.

Resolution

This issue is fixed as the internal logic has been changed such that the system is now capitalizing the charges correctly. Thus the Fees Remaining and Fee Capitalized values are getting calculated correctly.

12.12 Issues fixed in Q2 Loan Servicing 3.6019.215/ CL Common 3.6003.25

12.12.1 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-2035/ND-6579)

Issue Description

In a loan with a Flexible Repayment Plan and Business Hours, the system is generating schedules with incorrect Due Dates in the following scenarios:

• When the Payment Start Date of a Flexible Repayment Plan falls on a holiday, the system shifts the Payment Start Date to a working day correctly. But the issue is that the system is also shifting the dues dates of the remaining terms of the Flexible Repayment Plan to that working day.

  For example, let us say the Payment Start Date of a Flexible Repayment Plan is January 14 and January 14 is a weekend. So the Flexible Repayment Plan start date correctly gets shifted to January 16. This is a correct behavior. But the issue is that the system is also pushing all other repayments out to the 16th of every month instead of the 14th of each month. The expected behavior is that only the Payment Start Date of the Flexible Repayment Plan must change to the January 16th, the rest of the due dates must go back to the 14th of each month.

• When the Due Day field has a value of 31, the system is behaving incorrectly as explained in the following example:

Let's say we have a Due Day of 31, and February month has 29 days. In this case, let us say the payment has to start from June and we need the due date at the last date of every month. But as June has only 30 days, we are able to only select June 30 as the Payment Start Date from the calendar because of which the due dates of the rest of the terms of the Flexible Repayment Plan also start at 30th even when the Due Day field has a value of 31.

• The system is creating two schedules in the same month as explained in the following example:

Let us say we have specified a Due Day of 28, and we have created a Flexible Repayment Plan for due dates to fall on 22nd of the month for 5 terms where we have a total term as 12. Then the first five schedules are getting generated on the 22nd of every month but after the first five terms, the schedules are getting generated on the basis of date mentioned in Due Day. And as the Due Day is 28, one more schedule is getting generated in the last month of the 5 terms with the due date falling on 28th.

For example, let's say we have the first Payment Start Date of the Flexible Repayment Plan as June 6, 2023 and the last of the five terms is on October 22, 2023. As we have Due Day as 28, after the first five terms of the Flexible Repayment Plan, there is an another schedule getting generated on October 28, 2023. This makes October have two schedules. This is an incorrect behavior. The next schedule after October 22, 2023, must be September 28, 2023.

Resolution

To fix this issue, the internal logic has been modified and the system now behaves as follows in different scenarios:

• When you create a new contract, the system automatically considers the value of the contract's Due Day field when generating Amortization Schedules.

• Unless otherwise specified, the system sets the value of the New Due Day field to the value of the contract's Due Day field upon rescheduling.

12.13 Issues fixed in Q2 Loan Servicing 3.6019.210

12.13.1 The due date and the debit date are getting incorrectly reflected in semi monthly loans (JIRA ID: PDRFF-1966/ND-6631)

Issue Description

In a loan with payment frequency as semi-monthly, the system is creating due date and debit date incorrectly.

After March 2021, when a contract is created on the 29th day of the month with due dates as

the 14th day and the 29th day of every month, then the due dates are getting incorrectly updated to the 13th day and the 28th day of every month.

When a contract is created on 14th day of the month, the due dates are getting updated correctly.

Example to understand the issue

1. Let us create a loan contract with the following details and disburse it:

   • Contract Start Date = December 29, 2020

   • Payment Frequency = Semi monthly

2. Let us go to February 28, 2021.

The next due date must be updated to March 14, 2021.

However, the next due date is getting updated to March 13, 2021.

The repayment schedule remains the same.

Resolution

This issue is fixed, and the due date and debit date are getting updated correctly.

12.14 Issues fixed in Q2 Loan Servicing 3.6019.208/ CL Common 3.60003.22

12.14.1 The system is displaying Apex CPU time limit exceed error when the user is trying to preview the rescheduled data prior to rescheduling a loan (Jira ID: PDRFF-1901/PD-1612)

Issue Description

While previewing the rescheduled data by clicking the Preview button before the rescheduling of a loan, the user is unable to preview the rescheduled data and the system is displaying the Apex CPU time limit exceed error.

Example to understand the issue

1. 1. Let us create a loan with the following details:

   • Interest Type = Fixed

   • Term = 360

   • Payment Frequency = Monthly

   • Contract Date = March 1,2013

2. Let us go to April 1,2013.

   The system generates a bill.

3. Let us update the interest value to 12%.

4. Now let us go to the Flexible Repayment Plan page and update the payment plan.

5. Now let us click the Preview button.

The system must display schedules preview.

However, the system is displaying the Apex CPU time limit exceed error.

Resolution

This issue is fixed now, and the user is able to preview the rescheduled data successfully.

12.15 Issues fixed in Q2 Loan Servicing 3.6019.206

12.15.1 The system is throwing a null pointer exception in Interest Only loans when a backdated part principal payment is made(JIRA ID: PDRFF-2057/ ND-6589)

Issue Description

When a backdated payment is made in an Interest Only loans, the previous IPT gets reversed correctly and the existing bill gets discarded, but when the system is generating a new bill, it throws a null pointer exception.

Since the bill is for an Interest Only period, the due amount is only the interest component.

This interest component changes after the backdated payment as the principal amount is adjusted, and hence the expected behavior is that bills should be regenerated along with Interest Posting Transactions.

Reason

The null pointer exception is thrown because the billing job is unable to generate a bill for the one discarded as the Is Billed flag on the repayment schedules is not getting set to false after discarding the bill.

Example to understand the issue

1. Let us create a loan with the following details:

• Contract Date = October 22, 2014

• Payment Frequency = Monthly

• Delinquency Basis = Schedule Balance

• Product Type = Loan

• Interest Posting = Enabled

• Term = 24

• Interest Only Period = 12

• Actual Interest Only Payments = True

2. Let us go to November 9, 2014 and create a payment transaction of the due amount and clear it.

The amount is moved to the Deposit account.

3. Let us go to November 22, 2014.

The IPT and Bill gets generated.

4. Let us create a backdated payment transaction as of November 19, 2014.

The IPT that was created as of November 22, 2014 gets reversed, and the existing bill is getting marked as non-primary and gets discarded.

5. Now let us go to November 23, 2014.

A new IPT gets generated where the principal component is recorded in it. And when the system is trying to generate a new bill for the new IPT amount for interest only period, it is not able to generate, and the following null pointer exception gets thrown:

“Exception while processing Billing for LAI-00000059. Message: Attempt to de-reference a null object Cause: null.”

Resolution

This issue is fixed by fixing the logic where the Is Billed flag on the repayment schedule, for the respective discarded bill, is set to false.

Now when a backdated payment is made for an Interest Only Loan, the system is not throwing any null pointer exceptions and the bill is getting regenerated successfully

12.15.2 The system is calculating the repayment schedule incorrectly for loans with zero payment flexible repayment plan (JIRA ID: PDRFF-1614/ ND-6605/ND-6638/PD-1613)

Issue Description

For loans that have zero payment flexible repayment plan and periodic fee added to them, the repayment schedule is getting calculated incorrectly .

Example to understand the issue

1. Let us create a loan with the following details:

• Amount = $10,000

• Rate = 10%

• Terms = 10

• Time Calculating Method = Month and Days

• IPT Frequency = Monthly

• IPT = True

• Contract Date = May 30,2013

2. Let us add a fee set with the following details :

• Fee Amount = $100

• Include in Dues = True

• Include in Schedules = True

• Periodic Fee Amount Type = Per period amount

3. Let us add a flexible repayment plan with the following details:

• Payment Type = EMI

• Payment Amount = $0

• Number of Payments = 3

• Payment Start Date = June 30,2013

4. Let us approve and disburse the loan.

The values must be updated as follows:

• AMZ schedules must be generated.

• The first three schedules must be generated with zero Interest, zero Principal, zero due amount and Zero fees upto September 30, 2014.

• Normal EMI schedules must get generated after September 30,2013 without skipping any schedule.

• After the contract is created, the current payment amount must be updated to $0.

However, the zero amount EMI schedules are getting skipped for the first three schedules.

Resolution

This issue is fixed now, and the repayment schedule is getting calculated correctly .

12.15.3 The loan status is not getting updated to closed and the Excess Payoff IPT is not getting created when a loan payoff is done (JIRA ID: PDRFF-1592 /ND-6580)

Issue Description

For the loans that have Interest Remaining more than the deposit amount , when a loan payoff is done, the loan status is not getting updated to closed and the Excess Payoff IPT is not getting created.

Example to understand the issue

1. Let us create a loan product with the following details :

• Amount = $40,000

• Rate =10%

• Terms = 10

• Time Calculating Method = Month and Days

• Payment Frequency = Monthly

• IPT = True

• IPT Freq = Monthly

• Adjust Deposit Amount In Payoff = True

• Contract Date = March 1,2013

2. Let us add deposit of amount $100 , approve and disburse the contract.

3. Let us go to March 15, 2013 and reschedule the contract with Maintain Delinquency flag set to true.

4. Now let us create two charges manually of amount $50 and $150.

5. Let us generate a payoff quote.

6. Now let us create a payoff transaction with amount equal to payoff quote amount.

This should update the values as follows:

• The loan status is updated to Active-Marked for Closure.

• Excess payoff IPT of amount $1,666.25 is created.

• Paid Amount on IPT = $1,566.25

However the Excess Payoff Amount is not getting created.

7. Let us run the Loan Closure Job.

This should update the values as follows:

• The loan status should be updated to Closed-Obligations Met.

However, the loan status is still in Active-Good Standing.

Resolution

This issue is fixed now, and the Excess Payoff IPT is getting created and loan status is getting updated to closed.

12.16 Issues fixed in Q2 Loan Servicing 3.6019.204

12.16.1 The system is generating multiple interest rate schedules and Index Rate change transactions when loan contracts are rescheduled with a future date (Jira ID: PDRFF-1940 / ND-6548)

Issue Description

When loan contracts are rescheduled with a future date, the following issues are occurring:

• Multiple interest rate schedules are getting auto-created for the loan account.

• Multiple Index Rate change transactions are getting auto-created .

As a result of the above mentioned issues, the Transaction Summaries are getting created for multiple Index Rate Transactions, which are reflected in the customer transaction statements.

Resolution

This issue is fixed now, and the contracts are getting rescheduled with a future date successfully without any issues .

12.17 Issues fixed in Q2 Loan Servicing 3.6019.202

12.17.1 Too many query rows: 50001 error encountered when calling depositAmountTransferAction API (Jira ID: PDRFF-2025 / ND-6503)

Issue Description

When the depositAmountTransferAction API is called, the system is throwing the following error message: "Too many query rows: 50001."

Cause of the Issue

This issue is occurring because when the depositAmountTransferAction API is called, some aggregate queries are querying more than 50,000 rows that is more than the Salesforce Governor limit of 50,000 rows in this case.

Resolution

This issue is now fixed.

As a fix, the aggregate queries are now optimized.

12.18 Issues fixed in Q2 Loan Servicing 3.6019.199

12.18.1 The system is displaying maximum view state limit exceeded error message (Jira ID: PDRFF-1710 / ND- 6452)

Issue Description

While processing a file with more than 150 ACH records, the system is displaying the following error message:

“Maximum view state limit exceeded.”

Resolution

This issue is now fixed and files with more than 150 ACH records are getting processed successfully without any error messages.

12.19 Issues fixed in Q2 Loan Servicing 3.6019.197

12.19.1 The system is displaying an error message when a loan contract is rescheduled after a rate change (Jira ID: PDRFF-1625 / ND-6319)

Issue Description

When a contract is rescheduled after the following rate change scenarios:

• When there are two rate schedules defined for a date in the past and they have the same start date.

• When a loan has a defined rate schedule for current and future dates and is updated with a new rate, then the system is still considering the old rate schedule. the system is throwing the following error message:

“Error: After holiday treatment, the start date of Sequence ## is clashing with start date of Sequence ## in the Rate Schedule.”

Resolution

The issue is fixed now, and the loan contract is getting rescheduled without any error message.

The following conditions are the resolution for the preceding respective scenarios:

• The rate schedule is not considered for dates before last accrual date.

• When a new rate is chosen, the old rate schedule is updated with the same date for the present and future rate schedules.

12.20 Issues fixed in Q2 Loan Servicing 3.6019.192

12.20.1 The system is throwing an exception while running the SODAccountingJob and the BillingLocJob jobs (Jira ID: PDRFF-1144/ ND-6153)

Issue Description

For an existing loan contract, when the SODAccountingJob and the BillingLocJob jobs are run, the system is throwing the following exception for the following jobs respectively:

• SODAccountingJob “Failed to process batch for class 'loan.SODAccountingJob' for job id '7075i00000g08G8' caused by: System.DmlException: Update failed. First exception on row 0
  with id a0t0K000008Rv64QAC; first error: UNABLE_TO_LOCK_ROW, unable to obtain exclusive access to this record or 1 records: a0t0K000008Rv64QAC “

• BillingLocJob “Failed to process batch for class 'loan.BillingLocJob' for job id '7075i00000j4qVQ' caused by: System.DmlException: Update failed. First exception on row 0 with id a0t0K000008Rv6AQAS; first error: UNABLE_TO_LOCK_ROW, unable to obtain exclusive access to this record or 1 records: a0t0K000008Rv6AQAS”

Resolution

The issue is fixed and the SODAccountingJob and the BillingLocJob jobs are running successfully without any exceptions.

12.20.2 Manual capitalization of interest and fee is not supported when Reschedule Option on Excess Payment is undefined (Jira ID: PDRFF-1310/ ND-6127)

Issue Description

Currently, manual capitalization of fee and interest works only when Reschedule Option on Excess Payment field is defined in a loan. Due to this, there is no provision to make the rescheduling optional whenever a manual capitalization of a fee or interest is done.

Resolution

The issue is fixed by making the rescheduling of a loan optional. This means that even if Reschedule Option on Excess Payment is undefined while creating a contract, you can still reschedule the loan later while doing a manual capitalization.

12.21 Issues fixed in Q2 Loan Servicing 3.6019.189

12.21.1 The system is throwing an exception while running the SOD jobs (Jira ID: PDRFF-1517/ND-6011)

Issue Description

After an upgrade from Virgo to Platinum, when the SOD job is run, the system is throwing the following exception:

“Message: SOD process failed due to DMLException. Message: Update failed. First exception on row 0 with id a4E9r0000000UkTEAU; first error: CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY, loan.LoanAccountTrigger: execution of BeforeUpdate caused by: loan.LoanProcessingException: Draw period end date should not be greater than Maturity date of the contract…”

This is due to the following validation message displayed by the system whenever the Draw Period End Date is greater than Maturity Date of the loan contract: “Draw period end date should not be greater than Maturity date of the contract.” This message is blocking all the other non-related functionalities.

Resolution

To fix this issue, the validation message causing the issue is now removed.

Thus, the issue is fixed, and the system is not throwing the exception when the SOD job is run.

12.22 Issued fixed in Q2 Loan Servicing 3.6019.185

12.22.1 Additional interest is not getting included in the PayOff Amount upon loan cancellation (Jira ID: PDRFF-1324/ ND-5858)

Issue Description

While canceling the loan, the additional interest is not getting included in the PayOff Amount.

Reason

During the loan cancellation, the additional interest components are not being queried. Hence, the additional interest amounts are not being added to the PayOff Amount.

Steps to Recreate

1. Create a Simple Loan Product with the following configurations:

   • Daily Interest Accrual Time: EOD

   • Holiday Treatment Setup Applied on: Interest Capitalization Posting

   • Schedule Adjustment Method: After

   • Move Across Months: False

   • Accrual Type: Accrual To Date

   • Accrual Start Basis: Disbursal Date

   • Interest Type: Floating

   • Is Capitalization Enabled: False

   • Interest Posting Frequency: Billing Frequency

   • Funding in Tranches: True

   • Revolving: False

   • Additional Interest Component: Commitment Fee (1%)

   • Additional Interest Bearing Principle: Amount Not Funded

   • Additional Interest Posting Frequency: Billing Frequency

2. Create a contract for the newly created product and move the system date forward to the Next Interest Posting Date so that the Interest Posting Transactions should be created for regular and additional interest components.

3. Open the Loan Quick Menu and navigate to the Loan Actions and click Loan Cancellation.

Actual result: The PayOff Amount field in the Loan Cancellation window does not include the additional Interest Posted and any Additional Interest Remaining.

Expected result: The Payoff Amount must consider additional Interest Posted and Additional Interest Remaining, and after the loan is cancelled, the balance in the loan must be zero.

Resolution

This issue is fixed as the logic has been updated to query the additional interest components. Now, when a loan is getting cancelled, the PayOff Amount is also including the additional interest amount.

12.22.2 Multiple contracts are getting created while saving (Jira ID: PDRFF-1271/ ND-5890)

Issue Description

While saving the contract, multiple contracts are getting generated.

Reason

When the Save button is clicked, there is no loading or waiting window appearing on the screen, and the button is remaining in the enabled state resulting in multiple clicks, which is creating multiple contracts.

Resolution

This issue is fixed as clicking the Save button once is now causing the screen to freeze, prohibiting further actions on the contract page until the saving procedure is complete.

12.22.3 Incorrect amount is getting displayed on the Payoff Quote that is generated after the Current Maturity Date (Jira ID: PDRFF-1237/ ND-5809)

Issue Description

When a Payoff Quote is generated after the current Maturity Date, the Total Payoff Amount is getting calculated incorrectly. Thus, the system must provide the correct Total Payoff Amount so that the user can close the contract by making the correct payment.

Reason

• Scenario 1: If the last interest posting date is before the next billing date, the interest amount that is calculated from the LAD is added twice.

• Scenario 2: If the Next Interest Posting Date is falling after the Next Due Date, the interest amount from the last LAD date to the Next Payment Due Date is not getting added to the Interest Posted on the Payoff Quote.

Resolution

This issue is fixed as the logic in the code is updated. Now when a Payoff Quote is generated after the current Maturity Date, the Total Payoff Amount is getting calculated correctly.

12.22.4 The system is generating the LPTs with the Payment Mode as Excess while running the Loan Closure Job (Jira ID: PDRFF-1229/ ND-5929)

Issue Description

The system is generating LPTs of the Payment Mode as Excess for the value of 0.01 while running the Loan Closure Job every. This, in turn, produces IPTs for the 0 due amount.

In scenarios where the sum of Unpaid Interest Posted amounts of the IPTs and Interest Posted Amounts of the loan contract have a difference of 0.01 cent, due to unrounded Interest Paid amount updated during the Interest Waiver action, the Loan Balance has an extra 0.01 cent amount still remaining at the time of payoff, and due to this, even if all the IPTs are paid off, the 0.01 cent of the contract is considered as left unpaid. The 0.01 amount left to be thus paid by the LPT is considered as excess. Hence the contract is not getting closed and remains in the Active-Marked for Closure status. Now when the Loan Closure Job is run at the end of the day, it picks up the contracts with Active-Marked for Closure. When it picks this contract, it creates a new 0.01 cent LPT of type Excess to close the loan, but when trying to pay this Excess LPT towards an unpaid component, the system does not find any components of the loan unpaid. Thus, as no IPTs are left to be paid, the amount is going to excess again. Thus, the system keeps creating LPTs of the Payment Mode as Excess each time the Loan Closure Job is run.

Resolution

This issue is fixed as the internal logic is updated such that the system is now closing the loan if the amount remaining in the Loan Balance is less than Tolerance Amount and if all the components are completely paid off even though there is 0.01 cent left in the Loan Balance of the contract during the running of the Loan Closure Job.

the contract status is getting updated to Closed once all the loan components (IPT, Principle, Fees, and AICs) have been paid off and the remaining balance on the contract is less than the Tolerance Amount.

12.22.5 While restructuring a loan to add a new Interest Rate Schedule, the Start Date field is disabled (Jira ID: PDRFF-1377/ND-5910)

Issue Description

While rescheduling a loan to add a Rate schedule in the Interest Rate Schedules section, the Start Date field is not editable and displays a value which is one month ahead of the previous Rate Schedule’s Start Date.

Example:

Let us look at an example to understand the issue by performing the following steps:

1. Create a simple contract with a Payment Frequency as Monthly.

2. Let us say an Interest Rate Schedule with a Start Date of August 1, 2022 is added in the Rate Schedule.

3. Disburse the loan on August 1, 2022.

4. Move the SOD to September 1, 2022, and satisfy the bill.

5. Now, move the SOD to September 2, 2022, and try to reschedule the loan by adding a new Rate Schedule.

It is observed that while rescheduling, the Start Date field of the added new Rate Schedule is not editable and is populated with the date, September 1, 2022, which is one month after the Start Date of the previous schedule.

The issue is occurring because when the Add button is clicked during a rescheduling where the Transaction Date of the rescheduling is greater than the populated Start Date of the newly added Rate Schedule, the system is making the Start Date field disabled. Looking at the preceding example, as the rescheduling date, September 2, is greater than the populated Start Date, which is September 1, the field remains disabled preventing you from making any changes to it.

Resolution

This issue is fixed as the Start Date is now editable while rescheduling a loan to add a new Interest Rate Schedule.

12.23 Issues fixed in Q2 Loan Servicing 3.6019.182

12.23.1 Out of order reversal through ACH Return File is failing when the LPTs are created at the same time (Jira ID: PDRFF-1160/ND-5658)

Issue Description

When the ACH Return file is uploaded, the system is failing to reverse the LPTs that are created at the same time and leaves them as is, and the following error is seen in the logs:

“common.apex.runtime.impl.ExecutionException: You must reverse the last payment transaction. Please check the activity log of loan - LAI-00001014 in Other Transaction view.”

Example of the Issue

Let us look at an example by performing the following steps to understand this issue:

1. Set up an ACH payment.

2. In the Custom Settings > Org Parameters, define Event Reversal Count as 5.

3. Create a Simple loan lending product with the following:

• FIT = false

• Payment Frequency = Monthly.

4. Move SOD (Start Of Day) to March 1, 2013.

5. Create a Contract from the preceding Lending Product and define the following:

• Loan Amount = 10000

• Interest Rate = 10

• Payment Term = 10

• Contract Date = March 1, 2013

• Payment Start Date = April 1, 2013

6. Approve and disburse the contract.

7. In the Setup Automated Payment, define the following:

• Type = Recurring

• Amount Type = Fixed Amount

• Transaction amount = 200

• Frequency = Monthly

• Payment Mode = ACH

• Active = True

• Setup Date = March 1, 2013

• Debit Date = April 1, 2013

• Actual Date = April 1, 2013

• Bank Account = Search for BA in lookup and select any existing Bank Account

8. Define Setup Automated Payment again with the same values as in the preceding step 7.

9. Move SOD to April 1, 2013. Two ACH LPTs will get created at the same time due to defining the Setup Automated Payment twice.

10. Provide the LPT ID in the ACH Return File that needs to be reversed, for example, the first LPT ID (LPT1) created on Contract.

11. Specify the following in your URL: apex/uploadachreturn

12. Upload the ACH Return File and click on Process ACH Return. Ideally, both the LPTs must get reversed without any errors, and on processing the ACH Return File, the system must reverse the LPT2 and then LPT1, and then re-apply LPT2. Also, the LoanEventStackProcessingJob job must be a part of Apex jobs when we process the ACH Return. But the system is failing to reverse the LPTs and leaves them as is, and the following error is seen in the logs:

“common.apex.runtime.impl.ExecutionException: You must reverse the last payment transaction. Please check the activity log of loan - LAI-00001014 in Other Transaction view.”

Reason

This issue is occurring as both the LPTs are getting created at the same time. There exists one LPT just after the first one having the same Transaction Date and Created Date all the way to the milliseconds within the system. The system queries the payments in the order of descending Transaction Date and Created Date. But as both the LPTs have exact values of date and time, the first LPT is being reversed first, which is why it's failing with the exception.

Resolution

This issue is fixed as the internal logic has been updated such that the system is now able to determine the order based on the record name and not based on the time so that it can reverse the LPTs in the required order and then reapply the required ones.

12.23.2 LPT is not getting created and hence Principal repayments stop when the deposit balance is greater than or equal to the loan balance (Jira ID: PDRFF-1302/ND-5909/PDRFF-760/ND-5593)

Issue Description

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

Example

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

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

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

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

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

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

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

Resolution

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

12.23.3 LoanDepositPaymentCreationJob is failing with error (Jira ID: PDRFF-979/ND-5620)

Issue Description

In cases where there are 1500 active deposit loans, the LoanDepositPaymentCreationJob job is failing with the following error message in the log:

Reason

This issue is occurring due to the heap size limit getting exceeded because of too much data stored in the memory during processing.

Resolution

This issue is fixed by performing the following actions to reduce the heap size:

• Print statements with huge heap consumption are removed.

• Paid IPTs were queried and not being used. So an extra condition is added to the IPT query to include only unpaid IPTs. This is applicable to all types of loans.

• Calculating extra principal payments based on threshold was summing up the principal portion of all future repayment schedules. This is optimized to reduce heap size.

• All records related to Repayment Schedules and Deposits are fetched and stored in memory. Since queries are complex, more filter conditions cannot be added. Hence, the memory storage is optimized by adding to the collection only those records that are needed for processing.

12.23.4 Clicking PDF for Print for Amortization Schedule in the Quick Menu is throwing an error (Jira ID: ND-5556)

Issue Description

On clicking PDF for Print for Amortization Schedule in the Quick Menu is throwing the following error:

Example

Let us look at an example by performing the following steps to understand this issue:

1. Select a loan contract.

2. Go to Loan Actions > Repayment Schedule > View Amortization Schedule.

3. Click PDF for Print.

Reason for the Issue

This error is occurring because the system is not able to validate the access permission for the PDF for Print.

Resolution

This issue is fixed as the permission is now provided to print the PDF page.

12.24 Issues fixed in Q2 Loan Servicing 3.6019.176

12.24.1 Validating the Interest Rate Schedules while rescheduling a loan is failing with an error (Jira ID: PDRFF-1367/ND-5871)

Issue Description

While rescheduling of a loan contract, on validating the Rate Schedules, the system is throwing the following error:

“ CL010101: Unexpected Exception SObject row was retrieved via SOQL without querying the requested field: loan_Loan_Productc.loanHoliday_Treatment_Setup_c at line 362.”

The issue is seen when you click Validate in the Rate Schedules. This issue is not seen when you click Preview and Save.

Example to understand the Issue

Let us look at an example by performing the following steps to understand this issue:

1. Create a contract with Floating Rate interest type.

2. Go to Loan Actions > Reschedule.

3. In the Interest Rate Schedule section, click Add.

4. Add a Margin Rate.

5. Click Validate.

Resolution

This issue is fixed by making changes to the internal code. Now while validating the Interest Rate Schedules of a loan contract during rescheduling, the system is validating the Rate Schedules successfully without throwing any error.

12.25 Issues fixed in Q2 Loan Servicing 3.6019.172

12.25.1 The system is not allowing the rescheduling of a contract when the rescheduling is done to increase the Interest Only Period (Jira ID: PDRFF-1115/ND-5758)

Issue Description

The system is displaying an error message while trying to reschedule a loan by increasing the Interest Only Period and Number of installments. The error message is as follows:

Expected Behavior

The system must allow to reschedule a loan to increase the Interest Only period and Number of installments.

Reason for the issue

The system is validating the Interest Only Period term by comparing it with the old contract term, instead of comparing it with the modified contract term. Thus, when a loan is rescheduled to increase the Interest Only Period such that the new Interest Only Period is greater than the old Contract Term, then the system is rejecting such a rescheduling.

Example to understand the issue

Let us see the following example to understand this issue:

1. Create a term loan with Funding in Tranches set to False.

2. Provide the Interest Only Period as 11 and Contract Term as 12.

3. Activate the Contract.

4. Perform a rescheduling by increasing the Interest Only Period to 15 and the Number of Installments to 16.

5. Click on Preview. The system generates the Amortization Schedule as expected.

6. Save the rescheduling action to activate the rescheduling of the loan. The system displays an error message as follows:

Thus, the system is not allowing the rescheduling a loan when the rescheduling is done to increase the Interest Only Period and Number of installments as the new Interest Only Period of 15 is greater than the old Contract Term of 12.

Resolution

This issue is fixed as the validation is modified to compare the new Interest Only Period term with the new contract term after the rescheduling.

Thus, referring to the preceding example, the system now compares the new Interest Only Period of 15 with the modified terms of 16.

The system now allows the rescheduling of a loan by increasing the Interest Only Period and Number of installments.

12.25.2 Rate Schedule considers the Holiday Schedule and hence aligns with the Repayment Schedule (Jira ID: ND-4636)

Issue Description

Before the Platinum patch (3.6019.172), the Rate Schedule did not take into consideration the holiday schedule defined by the user.

To understand this, let us say that in a Repayment Schedule defined by the user, there is an Interest Only Period of 3 months. Now sometimes the lender intends to define a Rate Schedule on the loan that should be aligned to the Repayment Schedule in a way that as soon as the last repayment date of IO period gets over and it enters the P+I period, the loan should switch to the new rate defined on the Rate Schedule in the same way.

Before the Platinum patch (3.6019.172), if the last repayment date of the IO period fell on a holiday, the repayment date moved ahead automatically due to the holiday setup in place. But the rate switch date in the rate schedule did not automatically move ahead as it did not refer to the holiday schedule. This created a mismatch in the interest calculation expected by the lender or the borrower versus the system.

Example of the requirement

Let us say there is a loan that was disbursed on May 3, 2021, and the repayment date falls on the 3rd of each month.

The loan is supposed to have an IO period of 3 months as per the repayment schedule and thus on 3rd August 2021, the loan would switch over from IO to P+I period. As per the lender, the rate schedule defined is 10% for first 3 months and 12% after that in the P+I period.

But as per the holiday schedule defined by the user in the system, 3 August 2021 turns out to be a Holiday. The Repayment Date would currently automatically move to 4th of August 2021, but the new Rate of 12% would get applied from 3rd August, itself.

Expectation

The expectation was that the Rate Schedule Start Date should also move (back or ahead, as per the parameters) if it falls on Holiday.

Resolution

This expectation has now been met with the Platinum (3.6019.172) release and the Holiday Treatment is applied on rate schedules during loan creation, rate change, reschedule, floating rates, and investment orders.

12.26 Issues fixed in CL Common 3.6003.15/ Q2 Loan Servicing 3.6019.172

12.26.1 Incorrect interest calculation for a period that includes a transition from a leap year to a non-leap year (Jira ID: PDRFF-848/ND-5566)

Issue Description

For a leap year, when the system the accrues interest for the last day of that year, that is, December 31, it calculates the accrual considering a year of 365 days of a non-leap year instead of 366 days of a leap year.

This is because, for a interest calculation of period from a leap year to a non-leap year, the interest calculation for the last day of the leap year (December 31) is considered as part of the non-leap year interest calculations considering 365 days.

But since the system accrues interest for each day in a leap year, the system should consider 366 days when calculating the interest accrual of the last day of the leap year, that is, December 31.

Example of the issue

For example, let us say the system is calculating interest for days between 1/Jan/2016 and 2/Jan/2017. The issue is that when the system is calculating the interest, it is breaking this period into two periods incorrectly. The first period is calculated from 1/Jan/2016 to 30/12/2016, and the second period is calculated from 31/Dec/2016 to 2/Jan/2017. This results in the system calculating the days for interest calculation as follows:

Days considered for interest calculation = 365 /366 + 2/365.

Thus, it is observed that the leap year's interest (31/Dec/2016) is calculated for 365 days only, instead of calculating it for 366 days.

The correct division of the period for interest calculation should be as follows:

Days to be considered for interest calculation = 366/366 + 1/365.

Thus, the actual breakdown should be as follows:

• First period: From January 01, 2016 to December 31, 2016

• Second period: From January 01, 2017 to January 01, 2017

Resolution

This issue is fixed as the system is calculating interest correctly. Thus, the calculation of interest accrual of December 31 is being considered for a leap year instead of a non-leap year.

Thus, referring to the example, the system now considers the period for interest calculation correctly as follows:

• First period: From January 01, 2016 to December 31, 2016 (including)

• Second period: From January 01, 2017 to January 01, 2017

12.27 Issues fixed in Q2 Loan Servicing 3.6019.167

12.27.1 For a Written-Off loan, the Interest Remaining is getting added to the Total Payoff Amount for a PayOff Quote of a future date (Jira ID: PDRFF-1081/ND-5721)

Issue Description

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

Example

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

Actual Result:

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

Expected Result:

Total Payoff Amount = 952.97 + 46.34 = 999.31

Reason

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

Expectation

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

Resolution

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

12.27.2 Not able to generate reports for the Loan Payment Transaction Interface (Jira ID: PDRFF-1156/ND-5671)

Issue Description

While generating the reports for the Loan Payment Transaction Interface, records are not getting updated. From All tabs, go to Reports and then run the Unprocessed LPT - NACHA Preparation report. The reports are not getting generated.

Also, on clicking Servicing Configuration > Data Import, there is no result, and no action takes place.

Resolution

This issue is fixed as internal code has been changed, and now the system is able to generate reports for the Loan Payment Transaction Interface. The Data Import issue has also been fixed now. Before the fix, the UI was unresponsive when buttons were clicked. Now after the fix, the UI code is changed to make it responsive for the required action.

12.27.3 LPT reversal is not working when the value of Additional Interest is null (Jira ID: PDRFF-1241/ND-5755)

Issue Description

When the value of Additional Interest is null, while doing the reversal of an LPT, the system is throwing the following message: “CL010100: Unexpected DML Exception Insert failed. First exception on row 0; first error: FIELD_CUSTOM_VALIDATION_EXCEPTION, Rolling back the batch. Message - Argument cannot be null. - Cause null-1497: [] at line 20..”

Resolution

This issue is fixed as a null check has been added for a null value of the Additional Interest. Now the system does not throw any exception and the LPT reversal works successfully.

12.28 Issues fixed in Q2 Loan Servicing 3.6019.163

12.28.1 Upon rescheduling a loan by using the Reschedule button on the UI to change the Flexible Repayment Plan, the system is not updating the Amortization Schedule in the preview (Jira ID: PDRFF-1151/ND-5605)

Issue Description

If a loan is rescheduled to add a Flexible Repayment Plan using the Reschedule button on the UI, then on clicking Preview, the system is not generating a new Amortization Schedule in the preview.

Example

To understand the issue, let us perform the following steps:

1. Create a contract with the following details:

• Contract Date = October 10, 2017

• First Payment Date = November 10, 2017

• Frequency = Monthly

• Term = 5

• Interest Calculation Method = Declining Balance

• Interest Rate = 15.99%

• Record Type = Loan

2. Activate the contract.

3. Reschedule the contract by adding a new Flexible Repayment Plan with the following details:

• Payment Type = Equated Monthly Installments

• Payment Amount

• $1,002.00

• Number Of Payments =3

4. Validate the new Flexible repayment plan and then click Preview.

It is observed that the Amortization Schedule is not considering the new repayment plan in the contract.

Resolution

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

12.28.2 LPTs of the type, Closure-Tolerance Payment Type, are not getting cleared due to null object error (Jira ID: PDRFF-1148/ND-5701)

Issue Description

When a loan has some Tolerance Amount, LPTs are created by the system with Closure-Tolerance Payment Type. However, they are not getting cleared due to the following error:

Also, loans are not getting closed due to this issue.

We tried to run a Loanclosurejob in production and found that the LPTs were created and not cleared.

Example

Let us understand this issue with the help of an example. Let us perform the following steps:

1. Create a loan with Tolerance Amount of $10.

2. Payoff a loan with $998 (if payoff =1000, pay with 998 as payment Tolerance Amount is $10.)

3. Then move the date to the next day. An LPT would be created.

It is observed that the loan is marked for closure, but LPT is not cleared.

Resolution

This issue is fixed as the null pointer check has been added in the internal logic. Now when loan has some Tolerance Amount, LPTs are created by the system with Closure-Tolerance Payment Type and cleared without any errors.

12.28.3 The system is throwing an exception while reversing an LPT (Jira ID: PDRFF-1092/ND-5680)

Issue Description

While reversing an LPT, the system is displaying the following error message:

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

Resolution

This issue is fixed as the internal logic has now been changed to use the FOR loop in the code. Now, instead of direct assignment, we are iterating the child records in a FOR loop and then populating them into a new list.

12.29 Issues fixed in Q2 Loan Servicing 3.6019.157

12.29.1 Error when clicking Cancel/Stop ACH through Loan Quick Menu in the contract (Jira ID: PDRFF-1104/ND-5596)

Issue Description

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

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

Resolution

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

12.29.2 Upon rescheduling a loan by using the Reschedule button on the UI to change the Rate Schedule or change the Flexible Repayment Plan, the system is not updating the Amortization Schedule in the preview (Jira ID: PDRFF-1155/ND-5605)

Issue Description

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

• If a loan is rescheduled to change the Rate Schedule on the UI by clicking the Reschedule button in the CL Contract Details page, then on clicking Preview, the system is not considering the updated Rate Schedule and the Rate schedule is not changing to include the new rate schedule, and a new Amortization Schedule is not getting generated.

• If a loan is rescheduled to add a Flexible Repayment Plan using the Reschedule button on the UI, then on clicking Preview, the system is not generating a new Amortization Schedule in the preview.

Example on Rate Schedule

Let us perform the following steps:

1. Create a Floating Rate Index with the following two Floating Rates:

   • Start Date = March 1, 2013

   • End Date = May 31, 2013

   • Interest Rate = 12%

   • June 1, 2013

   • August 30, 2013

   • 30%

2. Then let us create a Loan product with Interest Type as Floating Rate.

3. Now, move the system date to March 1, 2013.

4. Create the loan contract with preceding loan product with Rate Schedule that consists of the first-rate schedule as the Floating Rate and second as Fixed Rate of Interest Rate 13% with Start Date as September 1, 2013.

5. Approve and disburse the loan.

6. Move the system to April 1, 2013, then May 1, 2013, then June 1, 2013.

7. Go to Reschedule page and change the Rate Schedule to add another fixed rate schedule from October 1, 2013, with Interest rate of 21%.

8. Click Preview.

The following results are expected:

• The Rate Schedule should be changed to include the new rate schedule from October 1, 2013.

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

Resolution

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

12.29.3 Payment reversal or backdated reversal issues seen in the loan (Jira ID: ND-5617)

Issue Description

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

• Reversed flag in Interest Postings Transactions is not enabled; hence, accounting entry for Interest Reversal is not getting generated.

• If Payoff Quotes are generated after Payment Reversal, calculations for the Interest Remaining and Additional Interest Remaining fields seem inaccurate.

• The Payoff Amount in Payoff Quotes generated before making any payment and after reversal of that payment is different.

• Payoff Amount in Today’s Payoff, Loan Payoff, and Payoff Quote is different on the day of Payment Reversal.

• After the day of Payment Reversal, the Payoff Amount in Today’s Payoff and Payoff Quote is the same, although the Loan Payoff amount is different.

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

Resolution

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

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

12.30 Issues fixed in Q2 Loan Servicing 3.6019.154

12.30.1 The first IPT date for Additional Interest is falling on a holiday (Jira ID: PDRFF-1039/ND-5592)

Issue Description

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

Example

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

   • Daily Interest accrual Time = EOD

   • Accrual Type

   • Accrual To Date

   • Funding in Tranches

   • False

   • Interest Posting Frequency for Additional Interest

   • Billing Frequency

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

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

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

Actual Results

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

• The first bill amount does not include the Additional Interest Component amount.

• The second bill amount reflect incorrect Additional Interest Component amount.

Expected Result

• The first Interest Posting Date for AIC should not fall on a holiday and should be in sync with the regular interest when the frequency is same.

• The AIC should reflect the correct amount in the bills generated.

Resolution

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

12.30.2 Rescheduling is adding Interest Only Period on non-Interest Only loans (Jira ID: ND-4104)

Issue Description

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

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

Example

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

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

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

Then let us reschedule the loan account again.

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

Resolution

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

12.31 Issues fixed in Q2 Loan Servicing 3.6019.151

12.31.1 Maximum view state error message seen when the Manage Accounting Events page is getting loaded (Jira ID: PDRFF-1056/ND-5565)

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

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

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

Resolution

This issue is fixed. To resolve this issue, the logic has been updated in the system to only display a limited number of records that the page can incorporate. The rest of the records that are not displayed are displayed on the pages after this. In other words, pagination has been now included in the system for the Manage Accounting Events page to display limited records on each page. This ensures that the records are displayed and distributed over multiple pages such that a page can only display 20 records. Thus, reducing the size of the list of records on one page.

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

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

• The following four buttons are added to each page:

  • First Page

  • Next Page

  • Previous Page

  • Last Page

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

• Next Page

• Last Page

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

• First Page

• Previous Page

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

• A flexibility is added to move across pages by the addition of a field called Go To Page where you can enter the page number that you want to go to.

• The following warning message is added on the page:

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

• A buffer wait time has been added after changing a record on a page to be able to retain that change. Otherwise, if, after making a change to a record, and then you immediately move to another record on the same page, then the change in the previous record would not be retained. This buffer wait time is provided with the help of a window that displays “Please Wait” till the system retains that change on that page.

12.32 Issues fixed in Q2 Loan Servicing 3.6019.149

12.32.1 Maximum view state error message seen while previewing the rescheduling of a loan (Jira ID: PDRFF-834/PDRFF-662/ND-5519)

Issue Description

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

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

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

Resolution

This issue is now fixed.

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

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

• First Page

• Next Page

• Previous Page

• Last Page

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

• Next Page

• Last Page

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

• First Page

• Previous Page

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

12.32.2 Rescheduling after an LAD event is generating incorrect schedules (Jira ID: PDRFF-932/ND-5523)

Issue Description

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

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

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

Note: When Maintain Delinquency flag is True, while rescheduling, the interest must be calculated on Schedule Balance, and not the Principal Balance because Principal Balance is higher.

Let us understand the following case too where this issue was observed.

Issue when an internal transfer from deposit to loan was made:

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

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

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

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

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

Note: The rate on deposit is the same as the contract interest rate.

Resolution

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

As part of the fix:

• For non-delinquent loans, the sum of Interest Remaining and the interest from the LAD to rescheduling date is used to determine the Interest Accrued till Reschedule Date for present cycle.

• For delinquent loans, the interest accrued till Reschedule Date is calculated on Schedule Balance. Note: The term, Interest Accrued Till Reschedule Date, is basically the interest calculated till the rescheduling date for the current billing cycle.

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

When there is a rate change between the start of the current cycle and the rescheduling date

To understand this case, let us say we have the following:

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

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

• Interest of 10% calculated from 2nd March to 8th March on the Schedule Balance

• Interest of 12% calculated from 9th March to 11th March on the Schedule Balance.

When the loan is a non-IPT loan

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

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

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

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

12.32.3 The Last Rate Change Date field is not getting updated with the floating index rate change (Jira ID: ND-5475)

Issue Description

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

Let us say the FRI details are as follows:

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

Let us say the contract creation date is March 2, 2013.

Here the Last Rate Change Date is set to March 2, 2013.

Issue -1:

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

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

Issue -2:

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

Resolution

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

12.32.4 Multiple issues in Consolidated Loan Payment page (Jira ID: PDRFF-1016/ND-5520)

Issue Description

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

• Payment Amount displayed for a contract does not include the additional interest billed under that contract.

• For Master Facility loan contracts, payment amount is always populated as zero because the billed amount only includes additional interest for Master Facility contracts.

• There is no option available to enter additional interest amount when Spread Manually is selected.

• When the total amount is entered at account and saved, the system displays a message “The total amount has been adjusted to sum of all individual payments”, but payment transactions are not created under any contract.

• The Posted checkbox for a contract is not getting selected even after payment is applied for that contract.

• Payment reversal through Reverse button available in the Consolidated Loan Payment page is not working.

• Payment amount is still displayed for a contract even after clearing the payments.

Resolution

Following are the fixes made in this patch:

• Reversal is not supported on Consolidated Loan Payment page. Instead, the individual LPTs need be reversed. Thus, the reversal functionality in Consolidated Loan Payment is deprecated as part of this fix. Only reversal at individual LPT level is now supported.

• UI now includes proper validations and warnings.

• Posted flag is either removed or renamed based on the existing behavior.

• Last unpaid due date is now displayed on the page and the contracts are sorted based on that date.

• Field names like Payment Amount and Amount to Current are now renamed to Amount and Total Due Amount for better clarity.

• Auto payment spread across contracts are now supported.

• Cash in the Default Payment Mode is now renamed to Bank Transfer as consolidated payments are only through bank transfer.

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

12.32.5 The system is not allowing to change the Additional Interest rate to 0% (Jira ID: PDRFF-1036/ND-5533)

Issue Description

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

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

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

Resolution

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

12.33 Issues fixed in Q2 Loan Servicing 3.6019.144

12.33.1 Updating API versions to 51 due to Salesforce retiring API versions from 7.0 to 20.0 and 21.0 to 30.0 (Jira ID: PDRFF-1037/ND-5524/ND-5498)

Issue Description

As of the Salesforce Summer’21 release, Salesforce has deprecated the Salesforce Platform API versions from 7.0 to 20.0 and these versions are no longer supported by Salesforce. You can continue to access these legacy API versions until Salesforce Summer '22 is released in your org, which is when these legacy versions will become retired and unavailable.

With the Salesforce Summer ’22 release, Salesforce will be deprecating the Salesforce Platform API versions from 21.0 to 30.0 and these versions will no longer be supported by Salesforce. You can continue to access these legacy API versions until Salesforce Summer '23 is released, which is when these legacy versions will become retired and unavailable.

Due to this, all the JavaScript files using Ajax toolkit, such as the apex.js and connection.js, would need to use the latest versions. If the latest versions are not used, then after the retirement of the versions 7.0 to 20.0 and from versions 21.0 to 30.0, the applications consuming these versions of the API will experience disruption as calls will fail and result in an error indicating that the requested endpoint is not found and unable to be processed by the platform.

For example, the Loan Quick Menu was not displaying in the Classic view of the Salesforce application as the JavaScript files such as apex.js and connection.js were of the versions 10.0 and 13.0 respectively.

Thus, the API versions such as those of the apex.js and connection.js have now been updated to 51.0.

12.34 Issues fixed in Q2 Loan Servicing 3.6019.141

12.34.1 The system is throwing an exception while trying to generate a Payoff Quote (Jira ID: PDRFF-812/ND-5448)

Issue Description

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

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

Resolution

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

12.34.2 AIC is not getting included in the Payoff Quote calculation (Jira ID: PDRFF-904/ND-5474)

Issue Description

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

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

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

Resolution

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

12.34.3 Payout Quote generation for a future date is not working (Jira ID: PDRFF-735/ND-5504)

Issue Description

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

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

Resolution

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

12.34.4 Interest Rounding Error field is updating to zero (Jira ID: PDRFF-501/ND-5321)

Issue Description

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

Resolution

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

Unable to increase the Min Financed Amount value of a Lending Product (Jira ID: PDRFF-536/ND-5341)

Issue Description

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

Example

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

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

“Invalid Minimum And Maximum Loan Amount.”

Resolution

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

12.35 Issues fixed in Q2 Loan Servicing 3.6019.135

12.35.1 Bill generated for payoff amount instead of EMI when deposit amount is close to loan balance (Jira ID: PDRFF-924/ND-5484)

Issue Description

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

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

Resolution

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

12.35.2 Interest Remaining is not getting calculated correctly for future dated quotes (Jira ID: PDRFF-936/ND-5443)

Issue Description

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

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

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

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

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

• Current System Date

• Future dated payoff quote on Payoff Date

• February 8

• February 15

• February 10

• February 15

Issue 1: Total Payoff Amount for the two quotes are not the same.

Issue 2: Interest Remaining is not getting calculated correctly for the second quote. It is considering only 5 days, from Transaction Date to Payoff Date. It should calculate the Interest from the Last Interest Posting Date to the Payoff Date.

• First Page

• Next Page

• Previous Page

• Last Page

The Total Payoff Amount is not getting calculated correctly for both the quotes.

Scenario 2: Created another Future dated Payoff Quote with Transaction Date as February 8 and Payoff Date as March 10 (Next Due Date = March 5, 2021)

• Issue 1: Interest Remaining and Interest Posted are not getting updated if the entered Payoff Date is after the next billing cycle.

Scenario 3: Payoff quote Issues in a Master Facility loan contract Let us say we create a Master Facility contract with Monthly payment frequency and activate it.

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

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

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

Issue 1: Generate a quote with payoff date as April 11, 2021, which is before the Next Interest Posting Date in the first child loan.

Actual result: Payoff Date in quote is updated to April 12, 2021, even though the entered payoff date while creating quote was April 11, 2021, and ‘Interest Posted’ and ‘Interest Remaining’ values are not calculated correctly.

Expected result: Payoff quote should include principal, fee, interest and additional interest dues across all the child loans and Master Facility where ‘Interest Posted’ would be sum of unpaid previous interest posted amount and interest from last IPT date to next IPT date(future) across the child loans and ‘Interest Remaining’ in quote would be the interest from IPT till payoff date across child loans and then Additional Interest Remaining would be the sum of unpaid additional interest posted and interest amount from last IPT till payoff date.

Issue 2: Generate a quote with payoff date as April 12, 2021, which is on the ‘Next Interest Posting Date’ in the first child loan.

Actual Result: ‘Interest Posted’ and ‘Interest Remaining’ values are not calculated correctly.

Expected result: Payoff quote should include principal, fee, Interest & additional Interest dues across all the child loans and Master Facility where ‘Interest Posted’ would be sum of unpaid previous interest posted amount and interest from last IPT date to next IPT date(future) across the child loans and ‘Interest Remaining’ under quote would be the interest from IPT till payoff date across child loans and then Additional Interest Remaining would be the sum of unpaid additional interest posted and interest amount from last IPT till payoff date.

Issue 3: Generate a quote with payoff date as April 12, 2021, which falls after ‘Next Interest Posting Date’ in the first child loan.

Actual result: ‘Interest Posted’ and ‘Interest Remaining’ values are not calculated correctly.

Expected result: Payoff quote should include principal, fee, Interest & additional Interest dues across all the child loans and Master Facility where ‘Interest Posted’ would be sum of unpaid previous interest posted amount and interest from last IPT date to next IPT date(future) across the child loans and ‘Interest Remaining’ under quote would be the interest from IPT date till payoff date across child loans and then Additional Interest Remaining would be the sum of unpaid additional interest posted and interest amount from last IPT till payoff date.

Resolution

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

12.35.3 The total Interest Accrued and Interest Posted in a Master Facility after an early payoff are not the same (Jira ID: PDRFF-815/ND-5469)

Issue Description

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

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

Resolution

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

12.35.4 System is asking to pay the payoff tolerance amount while performing a manual loan closure of a revolving loan (Jira ID: PDRFF-879/ND-5479)

Issue Description

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

Resolution

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

12.35.5 Future dated payoff quotes for a capitalization-enabled contract are not getting generated correctly (Jira ID: PDRFF-941/ND-5445)

Issue Description

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

Resolution

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

12.36 Issues fixed in Q2 Loan Servicing 3.6019.128

12.36.1 Event Reversal is not displaying the Principal Adjustment transactions as expected (Jira ID: PDRFF-830/ND-5435)

Issue Description

On clicking Event Reversal to reverse transactions, the system is not displaying the expected Principal Adjustment transactions. This is because internally the system is picking the ten oldest Principal Adjustment records instead of picking the ten latest Principal Adjustment records.

Expected Behavior

The system must display the latest ten Principal Adjustment transactions on clicking Event Reversal.

Resolution

This issue is now fixed. The system now displays the expected ten latest Principal Adjustment transactions on clicking Event Reversal.

12.36.2 Payment Term and Repayment Schedule are not updated after Term Extension is made in a loan contract (Jira ID: PDRFF-696/ND-5408)

Issue Description

If a loan term is extended by updating the Term after going to Loan Quick Menu > Loan Actions > Term Extensions, the Payment Term and the Repayment Schedule are not getting updated to the new values.

This is because the system does not allow the term extensions for loans other than the Line of Credit product type of loan.

Resolution

This issue is now fixed. For all loans except the LOC loans, the system is now not displaying the Term Extensions menu after going to Loan Quick Menu > Loan Actions. And for LOC loans, if the term is extended by going to Loan Quick Menu > Loan Actions > Term Extensions, the system is correctly updating the new values for the Payment Term and Repayment Schedules.

12.36.3 Repayment Schedule is not getting updated after changing the Due Day (Jira ID: PDRFF-715/ND-5408)

Issue Description

If the Due Day of a loan is changed by going to Loan Quick Menu > Loan Actions > Change Due Day, the system is not updating the Repayment Schedule.

This is because the system regenerates the repayment schedules only for AMZ loans.

Resolution

This issue is now fixed.

On clicking Change Due Day in Loan Quick Menu > Loan Actions for all loans except the AMZ loans, the system is correctly displaying a message implying that the repayment schedule would not be regenerated for the corresponding product type contract.

For AMZ loans, on clicking Loan Quick Menu > Loan Actions > Change Due Day and then changing the Due Day, the system is updating the Repayment Schedule with new values.

12.36.4 The system is validating the creation of a child loan based on the Maturity Date instead of the Current Maturity Date (Jira ID: PDRFF-940/ND-5442)

Issue Description

If holiday treatment is applied to a Master Facility loan contract, and if the Current Maturity Date is shifted to a previous date as per the adjusting parameters, the system is displaying the following error message while creating a child loan:

“Child loans maturity date should be less than or equal to parent loan maturity date.”

This is because the system is comparing the Maturity Date of the child loan with the Maturity Date of the parent Master Facility loan contract instead of comparing the Current Maturity Date of the child loan with the Current Maturity Date of the parent Master Facility loan contract.

The system must allow the user to create a child loan because the Current Maturity Date of a single tranche term loan would be the same as the Current Maturity Date of the Master Facility loan contract.

Example of the Issue

Let us say we have a Master Facility loan product and a child loan product where the FIT flag is set to False. Let us say in both the products, the following values are set:

• Schedule Adjustment Method = After

• Move Across Month = False

Now let us say we create a Master Facility loan contract on a month end, such as January 31, 2021, and select the Maturity Date in such a way that it falls on a holiday, such as on May 31, 2021, which is a holiday.

After activating such a contract, the system updates the Current Maturity Date of the Master Facility loan contract to a day before the month end, which is May 28, 2021, because the Move Across Month flag is set to False.

Now let us try to create a child loan of the defined Master Facility loan contract. The system is displaying the following error message:

Resolution

This issue is now fixed. The internal logic has now been modified such that the system is now comparing the Current Maturity Date of the child loan with that of the Master Facility loan.

Now the system is not displaying any error messages when a child loan is getting created if there is holiday treatment applied to the respective Master Facility loan contract.

12.36.5 InterestPostingDynamicJob is displaying an error message while running (Jira ID: PDRFF-910/ND-5436)

Issue Description

In a single tranche term loan product, when payment frequency is Single Payment and Interest Posting Frequency is Billing Frequency, on running the InterestPostingDynamicJob, the system is displaying the following status error message:

“First error: Apex heap size too large.”

Resolution

This issue is now fixed. The internal logic has now been updated and the InterestPostingDynamicJob is running successfully without any error messages.

12.36.6 The system is not applying the holiday treatment to the additional interest postings when the additional interest and regular interest frequencies are different (Jira ID: PDRFF-908/ND-5431)

Issue Description

When the Additional Interest Posting Frequency and the regular Interest Posting Frequency are different from each other, and if the Additional Interest Posting Date falls on a holiday, then the system is not moving it to a working date even when the holiday treatment is applied.

Example

Let us say we set up and activate a term loan contract with Additional Interest component on January 31, 2021.

Let the frequency of the additional interest posting and the regular interest posting be different.

The next IPD (Interest Posting Date) must fall on February 26, 2021, because February 27, 2021, and February 28, 2021, fall on a holiday.

Now after running the EOD DAG jobs one day before the IPD, the Interest Posting Date of the Additional Interest Component falls on February 28, 2021, which is a holiday.

The expected behavior is that the Interest Posting Date must fall on February 26, 2021, based on the Schedule Adjustment Method = After and Move Across Months = False.

Resolution

This issue is now fixed. If the additional interest frequency is greater than the Monthly frequency and even when it is not the same as the regular interest posting frequencies, the system is now applying the holiday treatment to the additional interest postings and the additional interest postings are not falling on a holiday.

12.37 Issues fixed in Q2 Loan Servicing 3.6019.128/ CL Common 3.6003.12

12.37.1 Repayment Schedules are not getting generated in a Single Payment frequency contract after activation (Jira ID: PDRFF-889/ND-5423)

Issue Description

When a contract that has payment frequency selected as a Single Payment frequency is activated, the system is not generating repayment schedules.

This is because on activating the contract, internally, the system is incorrectly assigning the next cycle date as the current contract date, and because the payment frequency is Single Payment frequency, the Maturity Date is getting the value of the same current contract date resulting in no repayment schedules getting generated.

Expected Behavior

When calculating the Maturity Date with Single Payment frequency, the system must consider the First Payment Date as the Maturity Date.

Resolution

This issue is now fixed. The system now considers the First Payment Date as the Maturity Date in a loan where payment frequency is selected as Single Payment.

12.38 Issues fixed in Q2 Loan Servicing 3.6019.118

12.38.1 Remaining Amount for Funding in a Master Facility loan is not considering the Pre-Paid Fee disbursed through its child loans (Jira ID: PDRFF-596/ND-5352)

Issue Description

The Remaining Amount For Funding in a Master Facility loan is not considering the Pre-Paid Fee disbursed though its child loans.

Example

Let us say there is a Master Facility loan, and it has two child Simple Loans created as follows:

As observed, the Remaining Amount For Funding of the Master Facility loan contract should consider the Pre-Paid Fee amount with the disbursed amount of each of the two child loans and hence reduce ($9500 + $500) of each of the two child loans from the Loan Amount of the Master Facility loan contract. Thus the system should reduce 2 * (9500+ 500) = 2 * (10,000) = $20,000 from the Loan Amount. Hence, the Remaining Amount For Funding should reduce to = $50,000 - $20,000 = $30,000.

And thus, the additional interest on the Available Amount For Funding of $30,000 should be calculated as follows:

$30,000 * (10/100) * (31/365) = $254.79.

However, the issue is that the Remaining Amount for Funding of the Master Facility is not taking into account the pre-paid fee disbursed across the child loans in its calculation, and hence the additional Interest Component with Interest Bearing Principal as Available Amount For Funding is also calculated incorrectly.

This is because internally, the Remaining Amount For Funding is formula field that takes its funded value from the Disbursed Amount field, which includes only the Financed Amount excluding the pre-paid fees amount.

Resolution

This issue is fixed. Now, for the Master Facility loan, the system is updating the Disbursed Amount field to include the pre-paid fee amount disbursed for child contracts as well so that the Remaining Amount For Funding field is getting calculated including the pre-paid fee amount. Hence, the additional interest is also getting calculated correctly.

12.38.2 Available Amount for Next Funding in a refinanced child loan contract is not considering the principal outstanding of the consolidated child loan (Jira ID: PDRFF-737/ND-5375)

Issue Description

The Available Amount for Next Funding in a refinanced child loan contract is not considering the principal outstanding of the consolidated child loan.

After settling the child loans and then performing a disbursement in the consolidated child loan, the Available Amount for Next Funding in the consolidated loan remained the same.

The Available Amount for Next Funding and Current Credit Limit fields in the refinanced loan should be reduced by considering the consolidated principal amount of the consolidated loan.

This is because, on disbursement of a refinanced child loan, the system is not reducing the Current Credit Limit of the Master Facility loan contract that was increased during the payoff of the refinanced child loans.

Resolution

This issue is fixed. Now, the Current Credit limit field is getting updated correctly to include the refinanced amount also as part of the calculation, and hence the Available Amount For Next Funding is getting calculated correctly.

12.38.3 Prepayment Fee is not getting included in the Total Payoff Amount of future-dated Payoff Quote (Jira ID: PDRFF-716/ND-5361)

Issue Description

Prepayment penalty field is not getting updated during future-dated payoff, and it is not getting included in the Total payoff amount.

Resolution

This issue is fixed. The internal logic has been updated such that the prepayment penalty fee is now getting updated during the future-dated payoff and getting included in the Total Payoff Amount.

12.38.4 Interest posted amount is not getting updated in a future-dated payoff quote (Jira ID: PDRFF-722/ND-5362)

Issue Description

While generating a future-dated payoff quote for a date less than the Next Due Date, the Interest Posted and the Interest Remaining fields are not displaying the updated values.

Resolution

This issue is fixed. The internal logic has now been updated to display the correct updated values of the Interest Posted and Interest Remaining while generating a future-dated payoff at a date less than the Next Due Date.

12.38.5 Interest accrual is getting calculated from the Contract Start Date instead of first disbursal date (Jira ID: PDRFF-665/ND-5368)

Issue Description

For a loan with Funding in Tranches flag set as False and Is Interest Posting flag set as True, even when the Accrual Start Basis is selected as Disbursement Date in the lending product of the loan contract, the system is calculating the interest accrual from the Contract Start Date instead of the disbursal date.

Resolution

This issue is fixed. The system is now calculating the interest accrual from the first disbursal date when Accrual Start Basis is the Disbursement Date, the Is Interest Posting flag is true, and Funding in Tranches flag is false.

12.38.6 Inactive Bank Accounts are accepted while making disbursements (Jira ID: PDRFF-668/ND-5364)

Issue Description

While making a loan disbursal, the system is allowing to select inactive Bank Accounts and make the disbursements. The system must not allow the user to do a disbursement to a bank account which is currently not active.

Expected Behavior

Only the bank accounts which are marked as active should be available in the Bank Account look up field in the Loan Disbursal Transaction.

Resolution

This issue is fixed. Now, if a user tries to save a disbursal transaction where an inactive Bank Account is selected, the system is throwing the following error message and not allowing to save such a disbursement:

12.38.7 Incorrect Principal Posted in an IPT in Accrual To Date type of accrual in an EOD-accrual-enabled loans (Jira ID: PDRFF-874/ND-5370)

Issue Description

In an Accrual To Date type of EOD-accrual-enabled loans that have charges to be included in bills, the Principal Posted in an IPT is not equal to the Principal Due of the Repayment Schedule and Bill. And when a payment is made, only the principal balance is cleared and not the billed fee.

Expected Behavior

The Principal Posted must be equal to the Principal Due as per the Repayment Schedule and Bill. And when a payment is made, both the billed principal and fee dues must be cleared.

RCA

This is because, in an Accrual To Date type of EOD-accrual-enabled loans, the IPTs get generated a day before the EOD, and the system considers the bills that have due dates less than the bill date on which the IPT needs to be created. This is resulting in no bills getting selected. When no bills are selected, the system is looking at the last bill. From the last bill amount, the system subtracts the interest amount and considers the rest as the principal amount as there is no way of knowing the fee amount in the last bill. Thus, the principal posted tends to be higher and thus, incorrect. Thus, the Fees Paid Amount is getting considered as zero.

Resolution

This issue is fixed as the internal logic has now been updated to consider bills with a Due Date that is one more than today so that tomorrow’s bills are considered and posted correctly. Then the Principal Posted amount is calculated as a correct amount.

12.38.8 APS payment creation is not considering only working days when Days In Advance To Create File is defined (Jira ID: PDRFF-816/ND-5376)

Issue Description

The LPT for Automatic Payment Setup is not getting created at the correct date when Days in Advance To Create File is defined.

In Custom Settings > ACH Parameters, let us say that the Days in Advance To Create File is set to 3, then the Loan Payment Transaction (LPT) is not getting created three working days before the Due Date. It is instead getting created three calendar days before the Due Date.

Resolution

To resolve this issue, when you create the Business Hours in the Setup, you must ensure that they are created in the name of BANK so that the ACH can follow these Business Hours and consider only working days for the payment creation. If the Business Hours are not created with the name as BANK, the ACH will consider it as normal calendar days to create the payment creation.

12.38.9 APS payment clearing is not considering working days when Lock Period is defined (Jira ID: PDRFF-821/ND-5376)

Issue Description

The LPT for Automatic Payment Setup is not getting cleared at the correct date when Lock Period is defined.

Let us say that Lock Period is set to 3, then the LPT is not getting cleared after three working days after the payment creation. It is instead getting cleared three calendar days after the payment creation.

This is because in the existing scenario, while clearing, the system is trying to find the Payment Mode that has the name as ACH. If it is not finding the name ACH, it is considering calendar days instead of considering business days only. Thus, for applying the holiday treatment, the system is not finding the Business Hours with the specific required Payment Mode name.

Also, every customer may have a different name assigned for the Payment Mode, so assigning one specific name to the Payment Mode of each Business Hours may also not work for all the customers as some customers may want to maintain only one Business Hours.

Resolution

This issue is resolved by ensuring that the customers create a Business Hours named BANK. This makes the process simpler because if the system does not find the Payment Mode with the name ACH, it tries to find the Business Hours with the name as BANK. If it does not find the Business Hours names BANK, it will not apply the holiday treatment to the days to be considered for the Lock Period. Hence, if the system finds the Business Hours named BANK, then the payment is cleared three working days after the creation.

12.38.10 Direct debit/APS payment generated is not considering the Additional Interest billed in a Master Facility loan contract (Jira ID: PDRFF-873/ND-5380)

Issue Description

In a Master Facility loan contract where the APS frequency is Billing Frequency and Amount Type is Last Billed Amount, the payment amount of an APS is not considering the Additional Interest billed, and hence the APS payment amount calculated is not the same as the billed amount.

This is because, when APS Amount Type is Last Billed Amount, it is considering only the last bill. The Master Facility consists only of additional interest, but the payoff considers Principal and Interest. While creating an LPT as the APS Amount Type is Last Billed Amount, the system compares the payoff amount and the last billed amount, and it considers the lesser of the two to generate a debit payment. When it does that, it finds that the payoff is zero for the Master Facility as Master Facility only has additional interest. So, it considers the payoff amount to be debited, which is zero, as it is the lesser amount, and hence no LPT is generated.

Resolution

This issue is fixed as the system is now considering the additional interest too while calculating the Payoff Amount for a Master Facility loan so that the payoff amount cannot be zero when there is an additional interest existing on the Master Facility loan and it can be compared with the Last Billed Amount, and then whichever is lesser is used to generate the APS payment.

12.38.11 While creating a child loan, the system is throwing an error if the Maturity Date of the child loan is greater than the Maturity Date of the Master Facility loan contract (Jira ID: PDRFF-777/ND-5390)

Issue Description

In a Master Facility, when holiday treatment is applied, the system is not allowing to create a child loan with Maturity Date greater than that of the Master Facility loan and lesser than the Current Maturity Date of the facility. While creating a child loan with Maturity Date greater than that of the Master Facility and lesser than the Current Maturity Date of the Master Facility, the system is throwing the following error message:

Example

Let us that a Master Facility loan contract has a Maturity Date on Saturday and as Saturday is a holiday and if holiday treatment is applied such that the date has to be moved after, then the new or the Current Maturity Date of the Master Facility becomes Monday. Now while creating a child loan with Maturity Date as Sunday, the system is throwing the following error message as it is seeing that Maturity Date of the child loan (Sunday) is greater than the Maturity Date of the Master Facility loan (Saturday):

Expected Behavior

Referring to the preceding example, the system must see if the Maturity Date of the child loan (Sunday) is greater than the Current Maturity Date of the Master Facility loan (Monday).

Resolution

This issue is fixed as the system is now checking whether the Maturity Date of the child loan is greater than the Current Maturity Date of the Master Facility or not. If the Maturity Date of the child loan is greater than the Current Maturity Date of the Master Facility, the system is throwing the preceding error message.

12.38.12 Interest Capitalization Posting on business days only (Jira ID: PDRFF-325/ND-4558/ND-5178/PDRFF-788)

Enhancement Description

It is a standard practice in some of the commercial lending markets to post interest capitalizations only on business days. So, if the capitalization is enabled in a loan and if the interest posting date falls on a non-working day, the system must move it to post it on a previous or the next working day.

For example, in a capitalization-enabled loan, say the holiday treatment is defined such that the interest posting date is to be moved to a previous date (Schedule Adjustment Method = Before) in case of a holiday and the interest posting frequency is monthly with the due date on every month as 25. Let us say that for a particular month, the 25th day turns out to be a holiday. In this case, the system should automatically post the interest on the immediate previous working day, which can be the 24th or the 23rd whichever is a working day.

To incorporate such a requirement, with the Platinum patch (3.6019.118) release, the Q2 Loan Servicing has been enhanced to post the interest capitalizations on business days only. This can be done by configuring the Holiday Treatment Setup for the Interest Capitalization Posting.

12.39 Issues fixed in Q2 Loan Servicing 3.6019.109

12.39.1 The system is rescheduling the loan on Principal Remaining only when Reschedule Balance is selected as Principal Remaining (Jira ID: PDRFF-511/ND-5335)

Issue Description

In a loan contract where redraw is enabled, if the loan contract is rescheduled using Reschedule Balance as Principal Remaining, the contract is getting rescheduled only on the Principal Remaining.

Expectation

Even if the Reschedule Balance is selected as Principal Remaining, the loan contract must be rescheduled on the following amount = Loan Balance + Reserve Amount Not Due (redraw amount).

Resolution

This issue is resolved. Now, for redraw-enabled loans, internally, the system is rescheduling the loan on the following amount:

Minimum of (Schedule Balance and (Loan Balance + Reserve Amount Not Due))

This applies to both automatic and manual rescheduling.

12.39.2 Issue with the clearance of charge when the charge is part of a bill and schedule (Jira ID: PDRFF-525/ND-5240)

Issue Description

In a simple loan contract where the Include in Dues and Include in Schedules is enabled for the Periodic Fee, if the Periodic Fee accrual date is before the billing date and if the customer pays the bill amount on the charge due date before the bill gets generated, then the charge gets paid and when the bill gets generated later it gets underpaid by the periodic charge amount.

Example

Let's assume there is a loan contract with payment frequency as monthly and where the periodic fee is getting accrued on first of the month and the bill is getting due on the fifth of the month.

Let us assume the following:

• Charge accrual date = January 1

• Bill due date = January 5

• Charge = $10

• Bill amount is $100.

Say if we pay $100 on January 1, then the amount should go to the Reserve Amount Not Due as it is not yet the Due Date, and then on due date, the system should automatically take the $100 and satisfy the bill. However, this is not how the system is behaving. What the system does is, it only moves the $90 to the Reserve Amount Not Due, and then on the due date, the bill is satisfied for only $90, and the remaining $10 is still remaining as due.

Resolution

This issue is fixed and now the system is correctly clearing the charges, the bill gets paid, and the loan is not becoming delinquent too.

This issue is fixed when Periodic Fee Amount Type is Per-Period Amount. If the Periodic Fee Amount Type is Total amount or null, the system displays the following error message if the start date of the Periodic Fee is different from the Due Date:

“Start date cannot be modified for Periodic Fee Amount type - Total Amount or Null.”

12.40 Issues fixed in Q2 Loan Servicing 3.6019.106

12.40.1 Maturity Date is getting updated if it falls on a holiday for loans with Funding in Tranches set as False (Jira ID: PDRFF-542/ND-5323)

Issue Description

While booking a contract with Funding in Tranches set as False, the Maturity Date is getting updated to the next working day on the repayment schedule.

However, when a contract is booked with Funding in Tranches is set to True, the Maturity date provided by the user is not updated to the next working day.

Expected Behavior

Maturity date should not move to the next working day if it falls on a holiday while booking a contract with Funding in Tranches set as False. The system should retain the date provided by the user in the Maturity Date field and the Current Maturity Date should move to a working day based on the values selected in the Move Across Month and the Schedule Adjustment Method fields.

The system should display a consistent behavior when a contract is booked with Funding in Tranches set to True or False.

Example of the Issue

Let us say we are creating a loan contract with Funding in Tranches set to False and with the Maturity Date as February 26, 2022.

Note that Saturdays and Sundays are marked as Holiday as per the Business Hours.

When the contract status moves to Partial Application, the Maturity Date gets updated to February 28, 2022.

Resolution

This issue is now fixed as the system is now successfully retaining the value in the Maturity Date field as provided by the user. If the Maturity Date falls on a holiday, the system correctly updates the Current Maturity Date to a working date based on the Move Across Month and the Schedule Adjustment Method field values.

12.40.2 Current Maturity Date is not following the Holiday Treatment Setup (Jira ID: PDRFF-560/ND-5323)

Issue Description

When a Master Facility loan contract is created with Maturity Date that falls on a holiday, then the system is not applying the Holiday Treatment to the Current Maturity Date. This means that even when the system finds that the Current Maturity Date falls on a holiday, it is not moving the Current Maturity Date to a working date based on the Move Across Months and Schedule Adjustment Method.

Example of the Issue

Let us say we have created a Master Facility contract, and the Maturity Date provided by the user is falling on holiday. Let us not provide any Payment Terms.

On activating this contract, the Current Maturity Date is the same as the Maturity Date, which is a holiday. The system is not applying the Holiday Treatment on the Current Maturity Date.

Resolution

This issue is now fixed as the system is now applying the Holiday Treatment on the Current Maturity Date if it falls on a holiday and moves it to a working date based on the values specified in the Move Across Months and Schedule Adjustment Method fields.

12.40.3 The system is unable to create child loans if Maturity Date of a Master Facility loan falls on a holiday (Jira ID: PDRFF-604/ND-5323)

Issue Description

When a Master Facility is created with the Maturity Date falling on a holiday, the Current Maturity Date is not moving to the next working day. Due to this, while creating a child loan, the system is displaying the following error and is not allowing to create child loans:

This is because, while the child loan is getting created, the Current Maturity Date of the child loan moves to the next working day, which is greater than the Master Facility loan as the Current Maturity Date on the parent Master Facility is not getting updated and remains the same.

Resolution

This issue is now fixed. The system is successfully able to create child loans without errors if the Maturity Date of a parent Master Facility loan contract falls on a holiday as now the system is successfully moving the Current Maturity Date of the Master Facility loan contract if it falls on a holiday based on the values specified in the Move Across Months and Schedule Adjustment Method fields.

12.40.4 First Payment Date is not following the Holiday Treatment even when the Scheduled Adjustment Method is defined (Jira ID: PDRFF-547/ND-5327)

Issue Description

Even if Scheduled Adjustment Method is defined in a loan, the system is not moving the First Payment Date to a working date. However, the system is correctly moving the Next Due Date to a working date if it falls on a holiday. Due to this, the First Payment Date and the Next Due Date do not have the same values.

Example

Let us say a simple loan is created with the following terms and conditions:

Let us say that the scheduled Due Date falls on February 5, 2022, which is a Saturday.

The issue is that the First Payment Date is updated to the scheduled Due Date of February 5, 2022, even though it is a non-working day, whereas the Next Due Date is moved to a working date, which is February 7, 2022, Monday. Hence the Next Due Date and the First Payment Date do not have the same values.

The First Payment Date must be moved to a working date so that it is same as the Due Date to which the Holiday Treatment is applied.

Resolution

This issue is now fixed as the system is successfully moving the First Payment Date to a working date based on the Holiday Treatment parameters defined.

12.40.5 The system is not adjusting the Charge Accrued if charge is completely or partially waived (Jira ID: ND-4847)

Issue Description

If a fee is accrued over a period of time and then if a user is waiving off the fee completely or partially during the life of a contract, then either there would be no income out of that fee or there would be an income which is less than the accrued amount.

But, in such scenarios, the system is not updating the accrued amount and is not posting a reversal accrual (negative accrual) entry.

The system should update the Charge Accrued field and should post a reversal accrual entry to the excess amount which is accrued.

Example

Let us say we have set up a fee with the following values and a loan is created with the following fee set:

Now let us move the system date and run the fee accrual job, so that a part of the fee is accrued.

Then let us waive the fee completely or partially such that it is greater than the remaining amount for accrual. Now on moving the system date and then running the accrual job, we see that the system is not updating the accrued amount and is not posting a reversal accrual (negative accrual) entry

Resolution

This issue is now fixed. An additional check is introduced in the Fee Accrual Job such that when this job runs, it would check if the charge has been accrued more than the waived amount. If the job finds such a charge, then it will generate a negative accrual entry for the difference amount. That means the system will now create a negative entry for an amount equal to (amount waived - amount accrued).

12.40.6 The system is throwing an error while performing a loan payoff transaction (Jira ID: PDRFF-622/ND-5291)

Issue Description

In a Master Facility loan, after paying off all the child loans, when the user is trying to make a complete payoff, the system is displaying the following error message:

Resolution

This issue is now fixed as the system is allowing the user to perform a payoff on the Master Facility contract without any errors.

12.40.7 Billed fees are not getting cleared on making a payment of the bill amount on the Due Date (Jira ID: PDRFF-761/ND-5334)

Issue Description

For a term loan contract that has the Payment Application Order set as Date, and that has a specific fee type, on making a payment of the billed amount for such a contract on the Due Date, the system is not clearing the due fees included in the bill and instead the system is clearing the payment against the principal amount.

The system should clear all the fees that are due and included in the bill when the payment amount is the billed amount.

Resolution

This issue is now fixed as the system is correctly clearing the payment of the specific fee type against that fee due. This means that now when a billed amount is paid, the system is successfully clearing the required payment against the fees included in the bill amount too.

12.40.8 Payment is not getting cleared against the applied spread if the spread only consists of the additional interest component (Jira ID: PDRFF-764/ND-5334)

Issue Description

In a Master Facility loan contract, if the payment spread is defined to consider only the additional Interest Component, then the system is not clearing the payment against that additional interest, but instead is considering it as an excess amount.

Resolution

This issue is now fixed as the system is successfully clearing the payment against the interest component mentioned in the applied spread in a Master Facility loan contract.

12.40.9 The system is not waiving the charge of the required fee type (Jira ID: PDRFF-776/ND-5334)

Issue Description

On waiving of a charge of a specified fee type, the system is waiving the fee type of the earliest found charge in the loan contract.

Resolution

This issue is now fixed as the system is waiving the correct fee type of the charge as specified by the user.

12.40.10 The Balloon Payment in the repayment schedule is considering only the disbursed amount that does not include the pre-paid fee (Jira ID: PDRFF-783/ND-5330)

Issue Description

While creating a simple loan contract where Balloon Payment is specified, if a disbursement of less than the Balloon Payment is made, then while calculating the balloon payment ratio, the system is not including the pre-paid fee in the disbursed amount.

This is because the prepaid fee amount is also deducted from the loan amount, and then this loan amount is considered in calculating the prorated balloon amount calculation because the disbursed amount consists only of the actual disbursed amount.

Example

Say if a loan contract is created with the following details:

• Loan Amount = $10,000

• Balloon Payment = $5,000

• Disbursed amount = $4,000 Total disbursed amount = $4,000 + $1,000 (Prepaid fee) = $5,000.

After disbursing, while calculating a balloon payment, in the repayment schedule, the system is not considering the principal amount disbursed and the pre-paid fee provided.

Thus, the balloon payment is incorrectly calculated as per the previous formula as follows:

($4,000/$9,000) * $5,000.

This formula is not including the prepaid fees.

Resolution

To resolve this, the Balloon payment amount that the internal calculator has to use is calculated using the following updated formula:

(1- (Remaining Amount / Loan Amount)) * Balloon Payment

= (1-(5,000/10,000)) * 5,000.

This means that the system is now correctly calculating the balloon payment including the prepaid fees too.

12.40.11 Incorrect Interest Posting Day updated when Interest Posting Frequency is set to Billing Frequency (Jira ID: PDRFF-565/ND-5318)

Issue Description

When Interest Posting Frequency is set to Billing Frequency, the Interest Posting Day is incorrectly updated.

Example

Let us say that the Contract Start Date is January 31. The Interest Posting Day of the contract is then expected to be as 31. However, when Interest Posting Frequency is Billing Frequency, the next IPT date is set to February 28, as February has only 28 days and the Interest Posting Day is updated looking at the IPT date which is 28.

The Interest Posting Day should be updated to 31 because the contract is activated on month end.

Resolution

This issue is resolved by updating the Interest Posting Day looking at the contract due day, and not the IPT date, as the IPT frequency is Billing Frequency.

12.40.12 Floating Rate Revision to occur only on business days (Jira ID: PDRFF-378/ND-5331)

Enhancement Description

It is a standard practice in the commercial lending market to perform floating rate revisions only on business days as the new rates are released by most indices or agencies only on a working day.

In the Q2 Loan Servicing system, if the floating rate revision date falls on a non-working day, the system should be able to post it on the next working day. Hence, there needs to be a configuration that can provide this added flexibility, and the user should be able to configure the floating rate revision date logic in the system. The user should be able to define if the floating rate revision should be moved to the previous date or the next date in case of a holiday.

To address this, the Q2 Loan Servicing has been enhanced to include the Floating Rate Revision parameter in the Holiday Treatment Setup.

Note: Holiday Treatment Setup is used to set up Holiday Treatment on a set of parameters. Holiday Treatment is a configuration based on which the system moves a date to a working date if it falls on a holiday.

Upgrade Step

To be able to add Floating Rate Revision to the Holiday Treatment Setup, ensure that the picklist value Floating Rate Revision is added in the Holiday Treatment Setup object. Also ensure that the picklist value Quarterly is added to the Floating Rate Revision Frequency picklist field of the CL Contract object. Note: For more information on adding Floating Rate Revision picklist value in the Holiday Treatment Setup and Quarterly picklist value in CL Contract, see the Latest Oxygen patch (3.5054.xx) to latest Platinum patch (3.6019.104) upgrade steps in the Q2 Loan Servicing (CL Loan) and Marketplace Upgrade Steps section of the Q2 Product Upgrade Guide.

Example

Let us say that a Floating Rate Index is defined as follows:

Let us say that Business Hours are created with Saturday and Sunday as holidays, and the Floating rate Revision Frequency is Monthly.

Let us say that the Contract Start Date is March 3 (Wednesday), 2021, then on April 3 (Saturday), 2021, the rate does not change as it is a Saturday.

On April 5 (Monday), 2021, we see that the Current Interest Rate is 15% and the Floating Rate Revision Date is May 3 (Monday), 2021.

On May 3, 2021, the Current Interest Rate is 19%, and the Floating Rate Revision Date is June 3 (Thursday), 2021.

12.41 Issues fixed in Q2 Loan Servicing 3.6019.99

12.41.1 Too many query rows exception observed while doing disbursals (Jira ID: PDRFF-695)

Issue Description

While doing disbursals, the system is throwing the following exception: “Too many query rows: 50001.”

This is because, internally, if, in a single execution, the system already has 50,000 records to be fetched, which may not necessarily contain records for the disbursals but may have records including payments, disbursals, rate changes, and more, then when an additional transaction like a disbursal is made, the number of records to be fetched becomes more than 50,000 resulting in the system not able to process it further and throw an exception.

Resolution

This issue is now fixed as the logic is updated to not throw the preceding exception when you are trying to do a refund on a loan that is not closed. This allows the system to perform a partial refund on the loan.

Now if an excess payment is made and if you click Refund for a loan that is not closed, the system successfully processes such a refund for the borrower.

12.41.2 Maximum view state error message seen while previewing the rescheduling of the loan (Jira ID: PDRFF-662/ND-5304)

Issue Description

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

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

Resolution

This issue is now fixed.

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

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

• First Page

• Next Page

• Previous Page

• Last Page

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

• Next Page

• Last Page

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

• First Page

• Previous Page

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

12.41.3 Next Deposit Payment Date is not getting updated on rescheduling (Jira ID: PDRFF-651/ND-5288)

Issue Description

While rescheduling a loan or while doing a Due Day Change, the system is not updating the Next Deposit Payment Date.

Resolution

This issue is fixed. The system is now updating the Next Deposit Payment Date when a loan is being rescheduled or a Due Day Change has been performed.

12.42 Issues fixed in Q2 Loan Servicing 3.6019.92

12.42.1 Error while rescheduling a Master Facility loan (Jira ID: PDRFF-581/ND-5278)

Issue Description

When a Master Facility type of loan is being rescheduled to change the Repayment Start Date, the Due Day, or the Maturity Date, the system is displaying the following error: “This loan does not have any remaining principal balance.”

This is because for loans that are not of the Master Facility type, the system should not allow rescheduling if the Principal Remaining is zero. However, for a Master Facility type of loan, the Principal Remaining is always zero as a Master Facility type of loan is never disbursed. So, as the system is seeing the Principal Remaining as zero, it is not allowing the rescheduling and displaying an error message.

Resolution

This issue is fixed as the system is now allowing the rescheduling of a Master Facility loan without any error messages.

Additionally, now the system is not allowing a rescheduling before the last LAD for the Master Facility loan and its child loans.

For a Master Facility loan, the following can be changed as part of the rescheduling:

• Repayment Start Date

• New Due day

• Maturity Date

• Frequency of Loan Payment

• Second Payment Date

• New second due day

• Interest Rate

• AIC Rate

12.42.2 The system is not creating an LPT for the tolerance amount when a payoff is made for a loan with capitalization not enabled (Jira ID: PDRFF-638/ND-5276)

Issue Description

The system is not creating a Loan Payment Transaction (LPT) for the tolerance amount when a payoff is made for a loan where capitalization is not enabled and where a tolerance amount has been defined, but the status is getting updated to Closed-Obligations Met.

The ideal scenario is that if a loan is created with some tolerance amount, then when a payoff is done with amount that does not include the tolerance amount, the system must perform the steps in the following order:

1. Principal Remaining on the loan must get updated to zero.

2. Interest Posted must be added to Loan Balance.

3. Loan status must get updated to Active-Marked for Closure.

4. LPT for the tolerance amount with the transaction type as Closure-Tolerance must be created in the system.

5. The loan status must be set to Closed-Obligations Met.

However, when a payoff is done in a loan where capitalization is not enabled, the Loan status is not getting updated to Active-Marked for Closure as per the preceding steps, and hence the loan status is directly getting updated to Closed-Obligations Met without creating any LPT for the tolerance amount.

This issue is not seen for loans where capitalization is enabled.

Resolution

This issue is fixed, and if capitalization is not enabled on loans where there is some tolerance amount defined, when a payoff is made with the amount that does not include the tolerance amount, the system is now following the correct steps as in the following order:

1. Principal Remaining on the loan must get updated to zero.

2. Interest Posted must be added to Loan Balance.

3. Loan status must get updated to Active-Marked for Closure.

4. LPT for the tolerance amount with the transaction type as Closure-Tolerance must be created in the system.

5. The loan status must be set to Closed-Obligations Met.

12.43 Issues fixed in Q2 Loan Servicing 3.6019.87

12.43.1 Amount To Current is reducing incorrectly after making the LPT payment when Include in Dues on fee is true (Jira ID: PDRFF-396/ND-5107)

Issue Description

After making a payment in a loan where Include in Dues flag is enabled for the fee, the formula field, Amount To Current, is displaying an incorrect value.

Note: The issue was reported observing the Amount To Current field. However, the correct field to refer to is Amount Due Till Current.

Amount Due Till Current is the sum of delinquent amount and unpaid fee.

If Include In Dues flag is enabled at the fee level for a charge, then it's considered as part of the bill. But as we are adding it again as unpaid fee, the Amount Due Till Current is displaying a higher value than expected.

Example

1. Let us say we have a loan contract with the following configurations:

   • Add Fee Amount To Bill = False (at the Contract Level)

   • Include in Dues = True (at the Fee level)

   • Status of the contract = Active-Bad Standing with the following IPT, Bill, and Charges

     • IPT = $58.33

     • Bill = $865.27 (Principal = $806.94, and Interest = $58.33)

     • Charges = $200

2. This results in the following:

   • Delinquent Amount = $865.27

   • Amount Due Till Current = $1065.27 (Delinquent Amount + Unpaid Charges)

Now if we make a payment (LPT) of $220, then $200 is accounted for charges and $20 is accounted for Interest.

The system then behaves as follows:

As the Include in Dues flag is true at the Fee level, the system considers charges to already be included in the bill, that is in $865.27, and the system deducts ($200 + $20) from the delinquent amount resulting in:

$865.27 - $200 - $20 = $645.27.

Thus, Amount Due Till Current = $645.27 + 0 (as charges are paid) = $645.27.

Due to this, the difference between Amount Due Till Current before and after Payment (LPT) appears to be $420 ($1065.27 – $645.27) even though the payment was only $220.

Resolution

This issue is fixed by updating the logic in such a way that if Include in Dues flag is true, then the Amount Due Till Current is not including the charges before the payment.

Thus, referring to the preceding example, now the Amount Due Till Current before the payment is calculated as follows: $865.27 (not adding $200 to it.)

12.43.2 Generation of the Repayment Schedule is failing if the disbursed amount is less than Balloon Payment amount (Jira ID: PDRFF-517/ND-5263)

Issue Description

While creating a simple loan contract where Balloon Payment is specified, if a disbursement of less than the Balloon Payment is made, then the status of the contract changes to Active – Good Standing, but the Repayment Schedule is not getting generated.

This is because the internal calculator used by Q2 Loan Servicing is not able to generate a schedule when the payment expected in the Balloon Payment amount is more than the amount that is disbursed as the principal to be paid, which in this case is the Balloon Payment, cannot be more than what is disbursed.

Example

Say if a loan contract is created with the following details:

• Loan Amount = $10,000

• Balloon Payment = $5,000

• Disbursed amount = $1,000

Then the system is not generating the Repayment Schedule, as the disbursed amount of $1,000 is less than the Balloon Payment of $5,000.

Resolution

To resolve this, the Balloon payment amount that the internal calculator has to use is prorated to the ratio of total loan amount disbursed to the total Loan Amount of the contract.

This means that the system is now calculating the balloon payment for the last schedule as follows:

Balloon payment for the last schedule = (total disbursed amount/total Loan Amount) * Balloon Payment amount on the contract.

Considering the preceding example, the balloon payment for the last schedule will be calculated as follows = (1,000/10,000) * 5,000 = $500.

So, in the repayment schedules, the balloon payment will be as per the amount disbursed, and so, only on full disbursal, the complete balloon payment will be considered to calculate the expected payment amount in the schedules.

Hence, when a full disbursal is made, the balloon payment for the last schedule is calculated as follows = (10,000/10,000) * 5,000 = $5,000.

12.43.3 System is not allowing backdated waiving of fee and additional interest component (Jira ID: PDRFF-586/ND-5277)

Issue Description

Backdated waiving of fee and additional interest component is one of the actions that is required for various scenarios related to accrual in Q2 Loan Servicing. However, the system is not capable of allowing that. The Transaction Date field on the UI for waiving charge and additional interest component is not editable and hence you cannot specify a backdated date for waiving of fee and additional interest component respectively.

Resolution

This issue is fixed as the Transaction Date field on the UI for fee and additional interest component is now made editable so that you can specify a backdated date for waiving fee and additional interest component respectively.

The value of the Transaction Date is also checked by the system to ensure that the date specified is not before the Last Accrual Date of the loan contract.

12.43.4 System is allowing the user to specify Interest Only Period to be more than Payment Term (Jira ID: PDRFF-513/ND-5279)

Issue Description

While creating a simple loan contract with Interest Posting Frequency as Billing Frequency, Payment Frequency as Monthly, and Accrual Type as Accrual To Date, if we specify the Interest Only Period as more than the Payment Term and then do a disbursement, then the status of the contract changes to Active – Good Standing, but the Repayment Schedule is not getting generated.

Resolution

This issue is fixed as now the system displays the following error message if the user specifies the Interest Only Period more than the Payment Term:

The system now does not allow the user to proceed with creating such a contract by displaying the preceding message while saving the contract.

12.43.5 System is allowing disbursements after the Maturity Date (Jira ID: PDRFF-577/ND-5264)

Issue Description

In a loan contract that is a Simple Loan Product Type, if the Funding In Tranches flag is enabled, the system is allowing the disbursements even after the Maturity Date, resulting in an increase in the Loan Balance.

The system should not allow disbursements on or after the Maturity Date as it serves no purpose to allow disbursement on or after the loan has matured.

Example

Resolution

This issue is resolved as the disbursement on or after the loan maturity is now restricted, and the system is displaying the following message when you try to do a disbursement on or after the Maturity Date:

12.43.6 Flexible Repayment Plan is allowing a Principal Only payment amount that is more than Loan Amount (Jira ID: PDRFF-580/ND-5266)

Issue Description

In a Flexible Repayment Plan, if a Principal Only payment plan is created with a Payment Amount more than the Loan Amount, then the system is not restricting such a configuration.

A single Principal Only payment plan or a sum of all the Principal Only payment plans in a Flexible Repayment Plan must not be more than the Loan Amount.

Resolution

This issue is resolved as the system is now displaying the following validation message whenever a single Principal Only payment plan or the sum of all the Principal Only payment plans in a Flexible Repayment Plan crosses the Loan Amount:

12.43.7 Payment Term is not populated in a Master Facility loan contract after the contract’s activation (Jira ID: PDRFF-561/ND-5280)

Issue Description

While creating a Master Facility loan contract, if a Maturity Date and the Payment Frequency is provided, then on activating such a contract, the system is not updating the Payment Term automatically.

Payment Term should be calculated and displayed based on the Contract Start Date, Maturity Date, and the Payment Frequency.

Resolution

This issue is resolved as now the Payment Term is calculated and displayed based on the Contract Start Date, Maturity Date and Payment Frequency defined.

12.43.8 System is not allowing to set up a contract when Payment Application Order is date wise (Jira ID: PDRFF-425/ND-5155)

Issue Description

While trying to set up a loan contract where interest accrual is an EOD process, if the Payment Application Order is selected as Date with the Interest Posting Frequency as Billing Frequency and Payment Frequency as Monthly, then the system is displaying the following error message:

Resolution

This issue is resolved as the error message has been now removed and the billing job is now run as part of the EOD process.

Therefore, now the system is allowing to set up a contract with Payment Application Order as Date when a loan has an Interest Posting Frequency set as Billing Frequency and Payment Frequency as Monthly.

For more information on why the billing job is run as part of the EOD process, see the following note.

12.43.9 Interest Posting Transaction is created on the billing date for an EOD accrual process where accrual type is Accrual To Date (Jira ID: PDRFF-429)

Issue Description

In a loan where the interest accrual is an EOD process and the Accrual Type is Accrual To Date, if the Interest Posting Frequency is Billing Frequency and Payment Frequency is Monthly, it is observed that the system is creating the Interest Posting Transaction on the billing date (due date) instead of creating it on the day before the billing date.

Resolution

This issue is fixed as the billing job is now run as part of the EOD process and the Interest Posting Transaction for an Accrual To Date type of an accrual in an EOD accrual process is now correctly created on the previous day of the billing date (due date).

12.44 Issues fixed in Q2 Loan Servicing 3.6019.78

12.44.1 Cash Receipt reversals are not working as expected (Jira ID: PDRFF-463/ND-5186/PD-817)

Issue Description

When Cash Receipts are reversed, the status of the Cash Receipt is getting updated to Reversal Started instead of Created, and the status of the Payment Application is not getting updated to Reversed and incorrectly remains as Applied. Also, the Unapplied Amount of the Cash Receipt is not getting updated to the original Receipt Amount.

Resolution

The logic to reverse the Cash Receipt has now been updated and the Cash Receipt reversal now works correctly where, after a cash receipt is reversed, the status of the Cash Receipt and the Payment Application are getting updated correctly to Created and Reversed respectively, and the Unapplied Amount of the Cash Receipt is also getting correctly updated to the Receipt Amount.

12.44.2 Too many query rows exception observed while doing disbursals (Jira ID: PDRFF-388)

Issue Description

When doing disbursals, the system is throwing the following exception: “Too many query rows: 50001.”

This is because, internally, if, in a single execution, the system already has 50,000 records to be fetched, which may not necessarily contain records for the disbursals but may have records including payments, disbursals, rate changes, and more, then when an additional transaction like a disbursal is made, the number of records to be fetched becomes more than 50,000 resulting in the system not able to process it further and throw an exception.

A single execution can have many queries that can fetch many records. Now, if, in an execution, there are a total of more than 50,000 records getting fetched by multiple queries then the system is throwing the following exception: “Too many query rows: 50001.”

To understand this, let us say there are two queries: one on LPT and one on disbursal. If the query on LPTs returns 50,000 records, then when a query is run for disbursals, the system is throwing the exception. Thus, the exception is thrown not because of the 50,000 records getting fetched per query, but because of 50,000 records fetched overall in one execution. In one execution, you can only fetch 50,000 records.

Also, while doing disbursal transactions, it is not necessary that all the queries have to be run for all contracts. Let us say in one contract there are 1000 repayment schedules, and, in another contractor, there are only five repayment schedules. This would mean that not all records may need to be fetched.

For example, a query may not have a Where clause which can filter out the records for a particular contract. That means that this could query all contracts, and it could fetch 49524 DTD records.

Now say there is another query that fetches some more records making the total records more than 50,000. Then the system is throwing this exception as follows: “Too many query rows: 50001.”

This means that the queries may be taking the entire org’s data.

Resolution

This is fixed by adding the following conditions in the queries to filter the records correctly:

• Adding a condition in the Where clause of the query to filter the records by the ID. Only those contracts that are getting through in the execution logic are filtered. Only those DTDs (Disbursal Transaction Distributions) are queried that have advance interest enabled for the loan or for the AIC (additional Interest Component).

• Adding two more conditions to conditionally query the records further.

Thus, the fix helps in preventing the code from always querying without a Where clause, which, hence, helps in not querying the entire database.

12.45 Issues fixed in Q2 Loan Servicing 3.6019.76

12.45.1 Too many query rows exception observed while doing disbursals (Jira ID: ND-5160)

Issue Description

While doing disbursals, the system is throwing the following exception: “Too many query rows: 50001.”

This is because, internally, if, in a single execution, the system already has 50,000 records to be fetched, which may not necessarily contain records for the disbursals but may have records including payments, disbursals, rate changes, and more, then when an additional transaction like a disbursal is made, the number of records to be fetched becomes more than 50,000 resulting in the system not able to process it further and throw an exception.

A single execution can have many queries that can fetch many records. Now, if, in an execution, there are a total of more than 50,000 records getting fetched by multiple queries then the system is throwing the following exception: “Too many query rows: 50001.”

To understand this, let us say there are two queries: one on LPT and one on disbursal. If the query on LPTs returns 50,000 records, then when a query is run for disbursals, the system is throwing the exception. Thus, the exception is thrown not because of the 50,000 records getting fetched per query, but because of 50,000 records fetched overall in one execution. In one execution, you can only fetch 50,000 records.

Also, while doing disbursal transactions, it is not necessary that all the queries have to be run for all contracts. Let us say in one contract there are 1000 repayment schedules, and, in another contractor, there are only five repayment schedules. This would mean that not all records may need to be fetched.

For example, a query may not have a Where clause which can filter out the records for a particular contract. That means that this could query all contracts, and it could fetch 49524 DTD records.

Now say there is another query that fetches some more records making the total records more than 50,000. Then the system is throwing this exception as follows: “Too many query rows: 50001.”

This means that the queries may be taking the entire org’s data.

Resolution

This is fixed by adding the following conditions in the queries to filter the records correctly:

• Adding a condition in the Where clause of the query to filter the records by the ID. Only those contracts that are getting through in the execution logic are filtered.

• Adding two more conditions to conditionally query the records further.

Thus, the fix helps in preventing the code from always querying without a Where clause, which, hence, helps in not querying the entire database.

12.45.2 System is throwing an exception while reversing LPTs and disbursal transactions (Jira ID: PDRFF-601)

Issue Description

While carrying out the reversal of the LPTs or disbursal transactions, the system is throwing the following exception: "Aggregate query has too many rows for direct assignment, use FOR loop."

This is because to reverse the LPT, the system first queries the existing LPTs to check if they are there in that particular contract. Then if the LPTs are queried using the size() function, the system is throwing an exception.

Hence, the issue is not due to the contract having more than 200 LPTs, but because of the way those 200+ LPTs are accessed, and that is resulting in the exception.

Example

Reversing LPTs

When we are querying the 200+ LPTs with the existing logic that uses the size() function, the logic fails.

Now, when this line of code, lAcc.Loan_Payment_Transactions__r.size(), is executed, the code fetches this list and puts it into some local variable. Then it iterates with each LPT and hence gets the count of total LPTs with the help of the size() function. The assigning to that local variable works only if the count is less than 200. Otherwise, the system throws this exception where Salesforce suggests using the For loop.

Reversing Disbursal Transactions

Additionally, a similar issue is also seen while reversing a disbursal transaction.

For example, say if we are assigning the list of 200 records into this variable, lptTxns, then this action fails if the count is more than 200.

Resolution

Reversing LPTs

The issue is fixed by replacing the existing logic of using the size() function with the For loop as suggested by Salesforce.

The system then takes the recent transaction and then breaks from there. Hence, as per this new logic, for every LPT, it iterates in the For loop and executes the code written in the For loop and then comes out of it. This resolves the issue when the LPT count > 200.

Reversing Disbursal Transactions

This issue is also fixed by placing the existing logic in a For loop as suggested by Salesforce.

Thus, the system takes each record one by one and checks the condition given in the For loop.

Thus, the logic of direct assignment of 200+ records is now converted into For loop to fix this issue.

12.46 Issues fixed in CL Common 3.6003.10

12.46.1 Unable to reschedule a loan with a very small Payment Amount (Jira ID: PD-814/PDRFF-428)

Issue Description

On trying to reschedule a loan by changing the Payment Amount to a very small amount and enabling the Keep Same Payment flag, the system is not displaying the schedule on clicking the Preview button and the Number of Installments remains the same. Also, on clicking the Save button to save this rescheduling configuration, the system is throwing the following exception: “CL010101: Unexpected Exception List index out of bounds: 0 at line 1660.”

This is because on changing the Payment Amount to a very small amount, the system is computing the Number of Installments of the loan to a very large number of more than 1000, which is causing the system to reset the Number of Installments to the earlier value before the rescheduling, and not displaying the schedule on clicking the Preview button.

This issue also occurs while using the rescheduleALoan API to reschedule a loan with a very small value for the Payment Amount and keeping the payment amount same.

Resolution

Now on rescheduling a loan, if the Payment Amount is very small and the term of the loan is computed to be more than 1000, the system does not reschedule the loan and displays the following message on clicking the Preview button: “Unexpected Exception Failed to compute term. Payment amount is too low.”

Also, on clicking the Save button to save such a rescheduling configuration, the system displays the following error message: “Please preview your changes before saving.”

Workaround

As a workaround to proceed with the rescheduling, you can specify the terms as 1000 instead of providing a minimum Payment Amount. This will help in calculating a minimum Payment

12.47 Issues fixed in Q2 Loan Servicing 3.6019.65

12.47.1 Repayment amount in the schedule generated for an EOD-enabled loan, which considers the start date of the interest calculation period, includes the Due Date’s interest too (Jira ID: ND-5175/PDRFF-426)

Issue Description

In an EOD-enabled loan, if the interest must include the start date of the interest calculation period and if the Accrual Type is selected as Accrual To Date, then the repayment amount in the repayment schedule is including the interest of the Due Date or the billing date too.

This means that:

The repayment amount must not include the Due Date or the billing date’s interest.

Resolution

This issue is resolved by ensuring that either the EOD accrual process is enabled, or the Interest Calculation Period is selected as Include Start Date, and not both for the same loan. This means that the system does not allow the creation of a lending product or a loan contract if Include Start Date is selected for the Interest Calculation Period when EOD is enabled in the Custom Settings. Interest Calculation Period must be selected as None whenever EOD is enabled. This ensures that the repayment amount does not include the Due Date or the billing date’s interest.

If you select Include Start Date for the interest calculation of an EOD-enabled loan and then try to save the lending product or the loan contract, the system displays an error message. This is depicted in the following table:

12.47.2 Future dated pay off quotes does not factor the interest postings and capitalizations until the payoff date in an EOD-enabled configuration (Jira ID: ND-5056)

Issue Description

The future dated pay off quote calculation does not consider the interest postings and capitalizations until the payoff date in an EOD-enabled configuration.

This means that the principal considered in the payoff amount for a future date is not including any interest that would have been expected to be capitalized between the current system date and payoff date.

For example, if the Loan Amount is $10,000, and if we are calculating the Total Payoff Amount for the month of February, then

Interest Remaining for the Payoff Quote should be calculated as follows: 10,052.60 * 6 * 27/36500 = $44.62.

Where:

• Contract Start Date = January 10, 2021

• Current System Date = IPT date = February 10, 2021 (Hence, number of days considered are 27 because of the EOD configuration enabled.)

• Payoff Date = March 10, 2021

• Interest Rate = 6%

• Interest Posted on February 10, 2021, = $52.60

• Capitalized Interest = $52.60

• Pay Future Dues Timely = False

And the Total Payoff Amount should be calculated as follows: 10052.60 + 44.62 = $10097.22.

12.47.3 Unable to generate a payoff quote when Payoff Date is beyond Maturity Date in an EOD-enabled loan configuration (Jira ID: ND-5058)

Issue Description

When a payoff quote is generated for a date that is greater than the Maturity Date in an EOD-enabled loan configuration, the system is displaying the following error message: “Given Payoff date should not be greater than Maturity date."

For example, if the Maturity Date is January 10, 2021, and the Payoff Date, for which the payoff quote is to be generated, is January 12, 2021, then the system displays an error message.

Resolution

This issue is now resolved as the system allows to generate a payoff quote for a date greater than the Maturity Date of the loan in an EOD-enabled loan configuration.

12.47.4 Incorrect Total Payoff Amount in the Payoff Quote if quote is generated for Payoff Date that is same as the contract Maturity Date in an EOD-enabled loan configuration (Jira ID: ND-5111)

Issue Description

When a payoff quote is generated for a date that is same as the Maturity Date, the system is calculating an incorrect Total Payoff Amount by including the capitalized interest twice.

For example, let us say that:

• Principal Balance = $36,000

• Interest Remaining = $586.46

• Unpaid Charges = $1,600

• Capitalized Interest = $1,001.96

• Payoff Date = January 4, 2021

• Maturity Date = January 4, 2021

Then the Total Payoff Amount is incorrectly calculated as follows: 36,000 + 586.46 + 1600 +1,001.96 + 1,001.96 = $40.190.38.

Resolution

This issue is now fixed as the calculation for the Total Payoff Amount in an EOD-enabled loan configuration is corrected to include the value of capitalized interest only once.

Thus, considering the preceding example, now the Total Payoff Amount is correctly calculated as follows: 36,000 + 586.46 + 1600 +1,001.96 = $39,188.42.

12.47.5 System is not posting the IPT for accrued interest in case of an early payoff in an FAMZ IOA-enabled loan and the IOA posted amount is not getting reversed on the payoff reversal (Jira ID: ND-5168)

Issue Description

If an early payoff is made in an FAMZ Interest-On-Arrears (IOA)-enabled loan where the due payment is not made and an accrued interest exists in the system, then the Interest Posted for that accrued interest is not getting calculated and the system creates an IPT of zero amount with the status as Open.

For example, consider a loan where we are not making a due payment on the due date. In such a case, the loan accrues some IOA. Now, let us consider a date that is five days after the due date. There will be some interest accrued on this day. And let us say that we make a payoff on this day before the Maturity Date. In this case, the system is posting the IOA accrued, but is not posting the accrued interest and so the accrued interest is not getting paid as part of the payoff.

On reversing this payoff transaction, the system is also not reversing the IOA posted amount.

Resolution

This issue is resolved by ensuring that all the open IPTs, including both the regular type and the IOA type, are now calculated and satisfied by the payoff and hence, marked paid.

Also, the reversal of the payoff reopens the IPTs (regular IPT and IOA IPT) that were closed after the payoff and the IOA posted amount and other values that were updated due to the payoff are now reversed.

12.47.6 System is not updating the IPT status and the Last Interest Posting Date on posting the accrued interest during mid cycle early payoff in an FAMZ loan (Jira ID: ND-5169)

Issue Description

If an early payoff is made at the mid of the cycle in an FAMZ loan, then the Status field of the IPT for accrued interest is not getting updated to Closed, and the Last Interest Posting Date is not getting updated to the date on which the amount is posted for the payoff.

For example, consider a loan where we are not making a due payment on the due date, and let us consider a date that is five days after the due date. There will be some interest accrued on this day. Now let us say that we make a payoff on this day before the Maturity Date. In this case, the system is posting the accrued interest, but the status of that IPT is not getting Closed and the Last Interest Posting Date is not getting updated to this posting date.

Resolution

This issue is fixed, and the system is now updating the status of the IPT to Closed when the accrued interest is posted as part of the payoff and the Last Interest Posting Date is correctly getting updated to the date on which the accrued interest is posted.

Additionally, on reversing the early payoff, the system now reopens the IPT that was closed due to the payoff, and its values are restored back. All the field values of the loan contract are also restored to the original values that existed before the payoff.

12.48 Issues fixed in Q2 Loan Servicing 3.6019.59

12.48.1 Interest only payment plan is reduced by one month if transaction date and next repayment date are in the same month (Jira ID: ND-5166/PDRFF-433)

Issue Description

If a loan has a repayment plan with Interest Only period, and if the rescheduling date falls before the next instalment date with both the dates within the same month, the system reduces the Interest Only term by one month.

Suppose there is a loan that was disbursed on March 5, 2020, and the first payment start date was on March 22, 2020, with Interest only payment plan of six months.

Now if you reschedule the loan on June 17 with the next repayment date again on June 22 as expected, then it was observed that the Interest only term got reduced by one month and the schedule got generated for only five months, instead of six months.

Resolution

The calculation logic has been corrected, and the rescheduling now returns the expected terms of Interest Only period.

12.48.2 The Next Due Date of a Master Facility is falling on a holiday even when there is holiday treatment applied (Jira ID: ND-5135)

Issue Description

In a Master Facility loan, if the Due Day is set such that the Next Due Date would fall on a holiday and if the Schedule Adjustment Method is set to After in the holiday treatment configuration, then the system still sets the Next Due Date on that holiday instead of setting it on a date after the holiday as per the Schedule Adjustment Method defined. This is because the system was not considering the configured holiday treatment for a Master Facility.

The configuration is based on the following two factors:

• Schedule Adjustment Method: This determines which way the due date should move if it falls on a holiday, to the previous working day or the next.

• Move Across Months flag: This determines if the scheduled due date can be moved to the next or the previous month in case it falls on the last day or the first day of the month.

Resolution

The system now considers the holiday treatment applied for a Master Facility, and hence the Next Due Date does not fall on a holiday.

12.48.3 Next Accrual Entry Date updated incorrectly if a contract is activated on a month end when EOD is enabled (Jira ID: ND-5105)

Issue Description

For an EOD-enabled loan contract, if the contract is activated on a month end and the Accrual Entry Frequency is Month-end, then the system is updating the Next Accrual Entry Date to the next month-end date as it was not considering the EOD accrual settings in the loan contract.

Resolution

The system is now considering the EOD accrual logic and hence the Next Accrual Entry Date is correctly updated to the same month-end date instead of the next.

12.48.4 Previewing a reschedule by changing the due day gives an error (Jira ID: ND-4994)

Issue Description

Upon previewing a due day change, the system is displaying the following error: "CL010101: Unexpected Exception Payment start date cannot be less than transaction date/disbursal date. at line 305."

The issue occurs only if the Current Due Day field on the contract is such that the previous month's due date falls on a non-working day (non-business hours according to the Business Hours defined in the system).

For example, consider the following values:

• Current Due Day = 15

• First payment date = July 15, 2021

• Second payment date = August 16, 2021, as August 15 is a Sunday

• Schedule Adjustment Method = After

• Business Hours are defined in the product with Saturdays and Sundays as holidays

• Move Across Months = True

Now, let us say that the August bill is generated on August 31, 2021. Let us say after this bill is generated, if you try performing a due day change by updating the New Due Day to 14, and then clicking Preview, you will see the following error: "CL010101: Unexpected Exception Payment start date cannot be less than transaction date/disbursal date. at line 305." This was because the system was calculating the Last Due Date by subtracting a month from the current due date.

Resolution

The logic to calculate the correct Last Due Date has been updated in the system. Now the system is calculating the Last Due Date by looking at the oldest due date ensuring that there is no error after clicking Preview, and you can preview the new schedule successfully.

12.48.5 Rescheduling due to Principal Adjustment addition is generating an incorrect interest in the upcoming cycle of the schedule (Jira ID: ND-4982)

Issue Description

When Principal Adjustment addition is performed on a loan, then after the schedules are regenerated, the upcoming due date's schedule has an incorrect value in the interest component. This is because the system is considering an incorrect principal amount for calculating the interest component. It is considering the principal amount as the added amount for the duration between the LAD and the date on which the loan is rescheduled.

Resolution

Now the system is calculating interest on the correct principal amount. The principal amount considered is the sum of the amount that was before the Principal Adjustment action and the Principal Remaining amount that includes the Principal Adjustment transaction amount. Hence, the interest component in the schedules after the Principal Adjustment action is now correct.

For example, let us say the following events are taking place in a loan with interest rate 15%:

• On April 1, a loan is disbursed with amount $10,000.

• On April 15, a payment of $1,000 is made. This makes the principal amount as $9,000.

• On April 20, a Principal Adjustment Add of $1,000 is made. This makes the principal amount back to $10,000.

  Then the interest is calculated as follows:

• Interest from April 1 to April 15 for 15 days= 10,000 * (15/100) * (15/360) = $62.5

• Interest from April 16 to April 20 for 5 days = 9,000 * (15/100) * (5/360) = $18.75. Note: Here the correct principal amount of $9,000 is being considered. Before this fix, the principal amount that was considered was $1,000.

• Interest from April 20 to April 30 for 10 days = 10,000 * (15/100) * (10/360) = $41.66

Consider the loan with due date at the end of the month.

Then the total interest in the first schedule of the repayment schedule is correctly calculated as = 62.5 + 18.75 + 41.66 = $122.91.

12.48.6 Rescheduling an Active-Bad Standing loan contract is resulting in a negative interest accrual entry being calculated (Jira ID: ND-5173/PDRFF-383)

Issue Description

After rescheduling an Active-Bad Standing loan by selecting Reschedule Balance as Loan Balance and Maintain Delinquency as false, and on the Next Accrual Entry Date, when the Accrual Entry Job runs, the Accrual Entry for the cycle is not including the interest capitalized on loan till that date due to which a lesser interest amount is accounted. This is because the value of Interest Capitalized is added to the Principal Remaining and is set to zero as the system is not maintaining delinquency.

Resolution

The system is now modified to allow rescheduling of an Active-Bad Standing loan without maintaining delinquency to be done on Principal Remaining. This retains the capitalized interest on loan and hence the Interest Capitalized will not be set to zero resulting in the interest accrual entry to be a correct amount.

In the accrual entry process, the system keeps a track of a cumulative accrual interest amount in a field named Accrual Amount Accounted For on loan account. Whenever a new Accrual Entry has to be made, this amount is subtracted from the complete interest of loan till accrual date to get the accrual amount for that particular cycle.

Thus, the interest accrual amount is calculated as:

(Interest accrued from LAD till date+ interest remaining + interest paid + interest posted) - Accrual Amount Accounted For

12.48.7 The Loan Transaction Statement seems to display inconsistent values in the Balance and Principal Remaining columns when both backdated payment and backdated reversal fall on the same transaction date (Jira ID: ND-5080)

Issue Description

If a backdated reversal and backdated payment fall on the same transaction date in a Loan Transaction Statement, then the values in the Principal Remaining, Balance, and the Payoff columns seem to look inconsistent even when they are logically correct.

Resolution

The issue has been fixed as now the values in the Principal Remaining, Balance, and the Payoff columns of a Loan Transaction Statement are looking consistent with each other.

12.49 Issues fixed in Q2 Loan Servicing 3.6019.54

12.49.1 Upgrade script to run MarkFieldsAccessibleJob is failing with exceptions (Jira ID: ND-5087)

Issue Description

While running the upgrade script with the MarkFieldsAccessibleJob, the system is throwing the following exceptions:

• Exception 1: Apex CPU time limit exceeded Reason: This exception is due to there being too many objects and fields to add permissions that is not fitting in the governor limits

• Exception 2: first error: FIELD_INTEGRITY_EXCEPTION, Permission Read ints_Account_Detailsc depends on permission(s): Read intsMicrobilt_Information_c: [] OR first error: FIELD_INTEGRITY_EXCEPTION, Permission Read clcommon_Actorsc depends on permission(s): Read clcommonNavigationStructure_c: [] Reason: This exception is due to the child object permission being inserted before the master object permission.

12.49.2 Upgrade script to run MarkFieldsAccessibleJob is not adding Read permissions to objects in a permission set (Jira ID: ND-5159)

Issue Description

While running the upgrade script with the MarkFieldsAccessibleJob, the system is not adding the Read permissions to objects of a permission set.

Resolution

This issue is fixed as the job is now modified to accept permission set to add the Read permissions to.

12.50 Issues fixed in Q2 Loan Servicing 3.6019.51

12.50.1 Incorrect IPT amount and incorrect billing on Master Facility if a child loan is disbursed after the bill generation (Jira ID: ND-5081)

Issue Description

In a Master Facility with an Additional Interest Component, if a child loan is disbursed after the bill generation, then the system is calculating an incorrect IPT amount and generating an incorrect bill next.

Resolution

This issue is fixed.

12.50.2 Contracts with Active - Marked for Closure status are not getting closed as system is ignoring the excess IPTs (Jira IDs: ND-5071)

Issue Description

When the Loan Closure Job runs, it is unable to close the loan that has excess payoff IPTs created due to the excess amount existing in the contract. These excess payoff IPTs are not considered during the payment split process due to which the LPT amount for closure goes to the excess instead of satisfying the loan resulting in the loan not getting closed and remaining in Active-Marked for Closure.

Resolution

This issue is fixed.

12.50.3 Interest posting day is getting updated incorrectly (Jira ID: ND-5023)

Issue Description

For Monthly and Quarterly Interest Posting Frequencies, when a contract is updated on a month-end date, the Interest Posting Day incorrectly updates to the month-end date of the next month resulting in the Next Interest Posting Date getting updated to an incorrect date.

For example, if a contract is activated on January 31, 2021, the Interest Posting Day is getting updated to 28, because of which the interest is posted on 28th of every month. And if the contract is activated on March 31, 2020, the Interest Posting Day is getting updated to 30, due to which the future IPT dates are falling on 30th of every month.

Resolution

This issue is fixed as the loan contract Details page now displays the Interest Posting Day field that you can select to get the correct Next Interest Posting Date.

This means that when you specify the Interest Posting Day as 31, the system updates the Next Interest Posting Date to the last day of the respective month. However, if you specify the Interest Posting Day as any day other than 31, then the system updates the Next Interest Posting Date to that precise date every month.

However, for February, if the Interest Posting Day is greater than 28 for a non-leap year or greater than 29 for a leap year, then the system updates the Next Interest Posting Date as the last day of February.

12.50.4 System is not allowing to make a disbursement for a child loan for an amount less than the revolving Master Facility current credit limit (Jira ID: ND-5014)

Issue Description

For a revolving Master Facility, the system is not allowing to make the disbursement for a child loan even though the amount to be disbursed is less than the Current Credit Limit of the revolving Master Facility parent loan.

Resolution

This issue is fixed as now the system is checking the Current Credit Limit field to validate if the amount getting disbursed is not more than the credit limit on the Master Facility if the Master Facility loan is revolving.

12.50.5 System is not posting the IPT for accrued interest in case of an early payoff in an FAMZ loan (Jira ID: ND-5116)

Issue Description

If an early payoff is made in an FAMZ loan, then the IPT for accrued interest is not getting posted and the system creates an open IPT of zero amount.

Resolution

This issue is fixed.

12.51 Issues fixed in Q2 Loan Servicing 3.6019.46

12.51.1 IOA IPTs are getting deleted when a backdated reversal of a payment is made (Jira ID: ND-5104)

Issue Description

In a FAMZ loan, when a backdated reversal of a payment is made, the Interest on Arrears (IOA) IPTs are getting deleted.

Resolution

This issue is fixed.

12.52 Issues fixed in CL Marketplace 3.6001.4

12.52.1 ILT with Funding Pending status not getting created while funding from the Marketplace application after the upgrade (Jira ID: MD-462)

Issue Description

After the upgrade, when a loan is funded from the Marketplace application, the system is not creating an ILT with Funding Pending status, and the user is unable to see the investor split in the LDT.

Resolution

This issue is fixed.

12.53 Issues fixed in Q2 Loan Servicing 3.6019.41

12.53.1 System is creating an IPT with amount zero when a payment, which is made after a backdated payment on the same day, is reversed (Jira ID: ND-4975)

Issue Description

When a backdated payment is made before the last Interest Posting Transaction (LPT), the system correctly reverses the Interest Posting Transaction (IPT). Now, if a payment is made on the current system date, an IPT is getting created as part of the payment because the last IPT was reversed. However, if this payment is reversed, then the system is incorrectly reversing the created IPT resulting in the Interest Remaining to be updated as zero, due to which, when the Interest Posting Job next runs, the system is creating an IPT with amount as zero.

Resolution

This issue is fixed as the IPT that is created as part of the LPT creation and has a transaction Due Date lesser than the LPT Transaction Date is not getting reversed now when the LPT is reversed by the user.

12.53.2 The payoff amount is not satisfying the default spread and the loan status is getting updated to Active-Marked for Closure (Jira ID: ND-5043)

Issue Description

When a payoff is made in a loan where a payment spread is defined as principal and interest only, the payoff amount is only satisfying the principal amount and the interest amount instead of satisfying the default spread, and the remaining of the payoff amount is saved as excess resulting in the loan status updating to Active-Marked for Closure instead of Closed-Obligations Met.

Resolution

This issue is fixed as the system is now considering the default spread instead of the product-level payment spread for the payoff and the loan status is thus changing to Closed-Obligations Met after satisfying all the parameters of the default spread.

12.54 Issues fixed in Q2 Loan Servicing 3.6019.38

12.54.1 Maximum view state size limit exceeded error while viewing the contract (Jira ID: ND-4961)

Issue Description

When multiple Principal Adjustments are made on a non-FIT contract, and on trying to view that contract, the system is displaying the following error: “Maximum view state size limit exceeded.”

Resolution

This issue is fixed.

12.54.2 AccrualEntryJob is throwing an error (Jira ID: ND-5037)

Issue Description

When the status of a loan contract is changed from Approved to Active-Good Standing manually, the Last Accrual Date stores a null value and because of that when the Accrual Entry Job runs, the system is throwing the following exception and creating accrual entries again leading to duplicate accrual entries: “Accrual Entry job can not be performed for a8H5e000000mj9gEAA, Last Accrual Date is null.”

Resolution

This issue is resolved as the Accrual Entry Job is now skipping the contract that has a null value in the Last Accrual Date throwing the following exception:” Accrual Entry job can not be performed for a8H5e000000mj9gEAA, Last Accrual Date is null.” After this, the job is successfully processing the other loan contracts that do not have a null value in the Last Accrual Date.

12.55 Issues fixed in CL Marketplace 3.6001.3

12.55.1 REST APIs modified to accept the Accrual Type parameter (Jira ID: MD-461)

The following two REST APIs of the Q2 Marketplace package are modified by adding two parameters to each:

12.56 Issues fixed in CL Common 3.6003.5

12.56.1 CL Platform changes for EOD schedules (Jira ID: PD-760)

Enhancement Description

The CL Platform has been enhanced to generate EOD schedules by passing the Accrual_Type_c parameter. The clcommon.LoanCalculator_v3.LoanCalculatorInput global inner class of the LoanCalculator_v3 global class accepts this new parameter to be passed to its global constructor method.

12.57 Issues fixed in Q2 Loan Servicing 3.6019.33

12.57.1 FinCalc to calculate interest considering the Accrual Type parameter (Jira ID: ND-4958)

Enhancement Description

Earlier, the FinCalc loan calculator up till now calculated considering the normal interest calculations. However, with the Platinum++ patch release, Q2 Loan Servicing now has enhanced the FinCalc to calculate interest considering the Accrual Type parameter defined on the contract so that the schedule depicts the expected dues or payments as per the number of days for which the interest accrued has to be included in a cycle. The number of days may vary as per the value selected in the Accrual Type parameter.

12.58 Issues fixed in CL Marketplace 3.6001.3

12.58.1 Investment Amount on Investment Booking is incorrectly getting updated to the Commitment Amount preventing zero disbursals (Jira ID: MD-460)

Issue Description

If a new Investment Booking in the Bazaar loan application is created for a zero amount disbursal where Investment Amount is set to zero, then on funding such a loan application, the value of Investment Amount is incorrectly getting updated to the Commitment Amount.

Resolution

This issue is fixed as the Investment Amount now remains zero aiding in zero disbursals.

12.59 Issues fixed in Q2 Loan Servicing 3.6019.21/ CL Common 3.6001.2

12.59.1 System is throwing an exception while disbursing through the Marketplace application (Jira ID: ND-4832)

Issue Description

When Approval Transaction Config is enabled for Loan Disbursal, while disbursing in a Marketplace application, the system is throwing an exception.

Resolution

This issue is fixed.

12.60 Issues fixed in Q2 Loan Servicing 3.6019.17

12.60.1 Incorrect Interest Posting Day getting displayed after rescheduling a loan to change the New Due Day (Jira ID: ND-4896)

Issue Description

If a loan is rescheduled by updating the New Due Day, the system is displaying an incorrect Interest Posting Day in the Details page.

Resolution

This issue is fixed.

12.60.2 Investor Payout Job failing due to a NullPointerException (Jira ID: ND-4861)

Issue Description

On running the Investor Payout Job in an FIT loan that has an additional interest component, the job is failing with a NullPointerException.

Resolution

This issue is fixed.

12.60.3 End of Day Interest accrual in CL Loan (Jira ID: 4546)

Enhancement Description

Currently the interest accruals occur as part of the SOD process after the date change on the opening balance of the loan. This approach ignores any disbursements and repayments done on any given day for that day’s accruals. This also means that any accruals of the last day of the month are posted to the next month due to which, in the accounting terms, income is posted to the wrong accounting period.

To address this issue, Q2 Loan Servicing has been enhanced to provide you with an option to configure the interest accruals to be part of the EOD batch process so that the system can accrue interest for one day based on the closing balance of the day.

12.60.4 Interest Posting Job to be an EOD job (Jira ID: ND-4822)

Enhancement Description

With the Platinum patch release, the Interest Posting Job is now a part of the EOD Job. This means that the interest is posted after calculating the interest on the closing balance of the outstanding principal at the end of the day in the EOD

12.60.5 Fee Accrual Job can be an EOD process (Jira ID: ND-4830)

Enhancement Description

With the Platinum patch release, Q2 Loan Servicing provides you with an option to choose the fee accrual process to be a part of the end of the day process. This is achieved by enabling the system to run the Fee Accrual Job as a part of the EOD process.

This means that the fee accrual transaction gets recorded at the end of the day on the same day of the fee accrual instead of the current process where it gets recorded on the next date SOD.

12.60.6 New parameter Accrual Type is introduced to decide the inclusion of due day in interest calculation (Jira ID: ND-4823)

Enhancement Description

For an EOD interest accrual type of loan, the Interest Posting Job is now part of the EOD process and there are two ways in which the interest must be accrued for interest posting:

• If today is the interest posting date, then the interest that is posted today includes interest accrued till the previous day only.

• If today is the interest posting date, then the interest that is posted today includes the sum of interest accrued till the previous day and the interest accrued for today that is the posting date’s interest.

To support these two scenarios, a new parameter called Accrual Type is introduced in the system at the product level as well as contract level that consists of the following two options: Accrual To Date and Accrual Through Date.

12.60.7 New UI for Redraw Reversal, Redraw Balance Reduction, and Redraw Balance Reduction Reversal (Jira ID: ND-4918)

Enhancement Description

Earlier, reversals of redraw and redraw balance reduction were done only using an API. With the Platinum patch release, Q2 Loan Servicing has now added two new buttons on the UI called Redraw Reversal and Redraw Balance Reduction Reversal to reverse the Redraw and the Redraw Balance Reduction actions from the UI. A new menu option called Redraw Balance Reduction is also added in the Loan Quick Menu with this patch release.

12.61 Issues fixed in CL Common 3.6003.1

12.61.1 Too many SOQL queries exception on the External Batch Jobs tab (Jira ID: PD-706)

Issue Description

When multiple DAGs are created in the DAG Schedules and then externalized, then on clicking the External Batch Jobs tab, the following error is getting displayed: “clcommon: Too many SOQL queries: 101.”

Resolution

This issue is fixed.

13.   Change Record