Oxygen Release Notes

1.   Preface

This is a living document, and its contents may be updated often. Make sure that you have the latest version for use.

This document provides information about the new and enhanced functionality in Q2 Loan Servicing and Q2 Marketplace, **Oxygen 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 Q2 Marketplace**Oxygen version (3.5054.212) for the first time or have upgraded from an earlier version.

1.1 Purpose of this Document

This document provides information on the following for the **Oxygen release:

• Installation Information

• Upgrade Considerations

• System Performance

• New Features and Enhancements

• Fixed Issues

• Known Issues

• New and Modified Objects

• Preface

• Global Methods

1.2 Intended Audience

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

1.3 Prerequisites for Use

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

1.4 List of Abbreviations

1.5 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.

2.   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 Q2 Marketplace.

3.   Upgrade Considerations

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

4.   System Performance

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

5.   New Features and Enhancements

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

5.1 Master Loan

With the Oxygen release of CL Loan, now it would be possible for commercial lenders to book complex loan facilities, where each drawdown can 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 has been introduced in the system, using which you can 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 can 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.

5.1.1 Master facility - Creation (Jira ID: ND-4375)

Feature Description

A master facility can be created using the master loan product. Whenever there is a drawdown to be done on such a facility, you would have to create child loans (which are essentially normal loans) and link the same to the parent master facility.

5.1.2 Master facility- Disbursement (Jira ID: ND-4376)

Feature Description

A master facility loan cannot be disbursed in itself. Whenever there is a drawdown to be done, the child loans, mentioned in the previous sections, would have to be created and disbursed. The disbursement is only possible if there is an undrawn balance available at the master facility.

5.1.3 Master facility- Repayment (Jira ID: ND-4378)

Feature Description

You can record payment of bills separately at each drawdown level. Every drawdown would have its own dues and the payments can be done individually.

We are working to facilitate the consolidation of bills at the master facility level as well as easing out a consolidated payment, which eventually would apportion across all drawdowns. This feature would be available in future releases.

5.1.4 Master facility-Additional interest (for unutilized balance) (Jira ID: ND-4379)

Feature Description

For the lenders who want to charge periodic non-utilization fee on the drawn balance of the facility, the master facility allows you to define additional interest on the unutilized balance of the facility. The rate of accrual can be defined by you.

5.1.5 Master facility- Pre-paid fee (Jira ID: ND-4380)

Feature Description

The master facility allows you to define a prepaid type of fee. This would help you to charge any arrangement fee on the customers. You can choose the type of application of this fee if it has to be charged only on first drawdown or all drawdowns. Depending on this attribute, the fee would get applied.

5.1.6 Master facility- Closure (Jira ID: ND-4382)

Feature Description

A master facility cannot be closed unless and until all the child loans (drawdowns) are paid off and closed. Once all the drawdowns are closed, the master facility can be closed, depending on if there are no outstanding dues or charges on the facility level.

5.2 Collateral Management

5.2.1 Collateral management - Removal and addition of assets (Jira ID: ND-4263)

Feature Description

With this feature, you would be able to define desired priority of a collateral lien while associating it to a loan.
Also, if you want to remove or dissociate a collateral from a loan contract, you can now choose to pay off the loan as a part of this operation.

5.3 Amortization Schedule

5.3.1 Amortization schedule to be made optional to help save storage problems (Jira ID: ND- 4143)

Feature Description

A flag has been introduced in the loan product in Additional Parameters that says skip amortization schedule generation. This flag is also there at the contract-level in the Additional Parameters. This feature would help you to save storage expenses, if desired.

5.4 Transactions and Accounting

5.4.1 Reversal of accounting entries during cancellation (Jira ID: ND-4102)

Feature Description

On cancellation of loans, all disbursement transactions and accrual transactions would be marked as reversed. This is to enable reverse accounting for the disbursement transactions and accrual transactions.

5.4.2 Reversal of deposit amount if the corresponding LPT is getting reversed using adjustment entry (Jira ID: ND-3876)

Feature Description

This solution has been implemented to resolve an existing issue. Now, if there was a payment transaction (LPT) paid against a deposit and later if you would reverse the payment using adjustment entry, the corresponding deposit amount would be reversed too.

5.5 Interest Rate

5.5.1 Negative index rates should be possible (Jira ID: ND-3952)

Feature Description

In order to support possibility of a reference index going negative in future, CL Loan would now be able to support negative index rates.

5.5.2 Discount rates and loyalty bonus (Jira ID: ND-3609)

Feature Description

The lenders who offer seasonal promotions, loyalty bonus offers, or discounts on interest rates would be pleased to know that CL loan now supports configuring discount rates in the system. With this feature, now you would be able to record such discounts in the system for fixed periods on selected products, and any contracts booked in the system on those products would automatically reschedule the interest calculations for those rates.

5.5.3 Default interest rate (Jira ID: ND-3571)

Feature Description

This enhancement would now allow you to define a default (penalty) interest rate in the system, to accrue interest on the delinquent amount (arrears), which could be different from the normal interest rate of the loan.

5.6 Statements

5.6.1 Future and back dated payoff quote generation (Jira ID: ND-3364)

Feature Description

A new flag has been brought in to control a desired payoff quote. Now the user would be able to generate a tentative payoff quote for a particular date in the past or a particular future date considering if the bills would get paid or not get paid timely between the system date and that date.

5.7 Loan Closure

5.7.1 Option of manual closure (Jira ID: ND-3307)

Feature Description

In order to provide flexibility to the lender to decide whether the system should automatically close the loan, or the user should manually close the loan once the outstanding amount has been paid off, there is a new flag introduced in the system that can be used to define this behavior.

5.8 Disbursement

5.8.1 Zero disbursement loans with periodic fees (Jira ID: ND-4266)

Feature Description

Some of our existing lenders wanted to support insurance product use case within CL loan in which there is a periodic fee to be charged to the customer. So basically, there is no loan disbursement in such cases, but just periodic charges to be generated in the system. To support such a use case, with the Oxygen release, the user can achieve this by creating a zero-amount loan. A zero-amount loan can be created by disbursing zero amount and charging a periodic fee that can be added to the bill.

5.9 Business Hours

5.9.1 Business hours at contract level (Jira ID: ND-4267)

Feature Description

With this enhancement, instead of defining business hours in the system at org level, you would be able to define business hours per contract. Also contract servicing such as billing, reschedule, payment creation, AMZ schedules, and more, would support multiple time zones.

5.10 Payment in Kind

5.10.1 Payment in kind (Capitalization of interest or fee to increase principal outstanding) (Jira ID: ND-3885)

Feature Description

CL Loan allows you to capitalize interest and fee both via loan actions on loan contract UI as well as via API. The capitalization operation automatically increases the principal outstanding.

5.11 Global AP/ for Out of Order Payment Reversal

5.11.1 Addition of global API for out of order payment reversal (Jira ID: ND-4446)

Feature Description

In the previous release, if, as part of the ACH return file for the out of order reversal feature, a payment prior to another payment has to be reversed in the UI, the system automatically takes care of reversing and reapplying the subsequent payments. Now, with the addition of the global API for out of order payment reversal, CL Loan also allows you to do this using the global API.

5.12 API Version Update

5.12.1 Updating the API version to 48 for CL Loan (Jira ID: ND-4288)

Feature Description

If a class needs to use the latest features of Salesforce, then the API version needs to be updated. To implement the Salesforce security recommendations, as part of the Oxygen release, the API version of the apex classes in CL Loan are now updated to 48.0. With the API version updated to 48, you will be able to add the Field Level Security (FLS) to queries without changing it to dynamic query.

6.   Fixed Issues

This section describes the issues fixed in the Oxygen release of CL Loan and CL Marketplace.

6.1 Prepaid fees showing incorrectly on disbursement, affecting the distribution (Jira ID: ND-4298)

Issue Description

When the amount is to be disbursed, on the New Loan Disbursal Transaction page, the value of the total prepaid fees is incorrectly calculated and displayed. This results in an incorrect Distribution Amount for Disbursement.

Resolution

This issue is fixed.

6.2 Negative principal adjustment causing errors (Jira ID: ND-4225)

Issue Description

During a negative principal adjustment, an error is displayed due to the total investor share incorrectly exceeding 100 percent.

Resolution

This issue is fixed by bypassing the incorrect recalculation of the share amount for the investors during a negative principal adjustment.

6.3 Enabling capitalization after the contract is live, capitalizes the paid charges too (Jira ID: ND-4331)

Issue Description

When the capitalization is enabled after the contract has gone live the following issues are observed:

• The uncapitalized charges that are already paid are incorrectly capitalized.

• Upon reversal of the payments that were made before enabling the capitalization, the Fees Remaining and the Fees Capitalized do not have the updated capitalized values.

Resolution

The issue is now fixed.

6.4 Rescheduling not able to account for interest only terms (Jira ID: ND-4210)

Issue Description

If an IPT-enabled loan is rescheduled with a payment plan that has some Interest Only terms, the bills generated are incorrect when the loan is in the Interest Only period.

Resolution

The issue is fixed now.

6.5 Partially paid bill is marked non-primary after rescheduling with Maintain Delinquency= False (Jira ID: ND-4237)

Issue Description

When a loan is rescheduled without maintaining delinquency, the bill that is partially paid is incorrectly marked non-primary.

Resolution

The issue is fixed now.

6.6 Payment plan is reduced by one month if transaction date and next repayment date are in same month (Jira ID: ND-4185)

Issue Description

If a loan has a repayment plan with Interest Only period, and if the rescheduling date falls before the next installment date with both the dates within the same month, the system reduces the Interest Only term by one month.

Resolution

The issue is fixed now.

6.7 Batch job/s fail when batch instances try to update the Day process object records at the same time (Jira ID: ND-3008)

Issue Description

When multiple instances of the StartOfDay job update the records of the Day process object at the same time in the finish method, the batch job(s) fail with a record locking error.

Resolution

This issue is fixed by updating the finish method in the StartOfDayJob, BillingJob, and CreditBureauPaymentHistoryJob jobs, by updating the query that queries the Day process object to get only those records that are not yet updated, and by recording the error in the batch process log instead of throwing the error.

6.8 Duplicate bills generated due to system archiving AMZ schedule but not marking the bill nonprimary (Jira ID: ND-4377)

Issue Description

During the prebill days, when a loan with bills generated is rescheduled, the system archives the AMZ schedule, but does not discard the bill.

Resolution

This issue is resolved by ensuring that when a loan is rescheduled during the prebill days, if the repayment start date is an immediate due date, the newly created repayment schedules are marked billed as the primary bill exists on its due date.

6.9 GL Accounting Event Error: Collection size 1,091 exceeds maximum size of 1,000 (Jira ID: ND-4343)

Issue Description

Upon clicking Create New Accounting Event in Servicing Configuration > Accounting Setup, the system throws the following error:

Resolution

The issue is fixed now.

6.10 Fee waiver satisfying the bills in normal spread (Jira ID: ND-3777)

Issue Description

When a fee of the Include in Dues type is waived, the unpaid bills corresponding to the same are incorrectly satisfied.

Resolution

A check is now added to skip the processing of the bill for the Include in Dues type fee when it is waived.

6.11 Fee accrual job gives 'Divide by O' exception in batch processing (Jira ID: ND- 4398)

Issue Description

If there are multiple fees or charges created for the same fee name on a loan contract and Accrual Required is set to true, the accrual process fails while deriving the remaining term for accrual, and the fee accrual job throws the following error:

Resolution

The issue is fixed by using the Straight Line accrual method for calculating the remaining terms, and thus removing the dependency on accrual entries generated till that date.

6.12 Duplicate payments being created after enabling concurrency (Jira ID: ND- 4270)

Issue Description

Upon enabling concurrency, the system created duplicate Excess payments.

Resolution

The issue is fixed now.

6.13 Include in Schedules fees not working for F-AMZ loans (Jira ID: ND-4363)

Issue Description

For an F-AMZ loan with a periodic fee with the Include in Dues flag and Include in Schedules flags enabled, the system throws a null pointer exception when trying to make a payment for the bill.

Resolution

The issue is fixed by handling the null pointer exception.

6.14 Reversing the threshold-crossed payment transactions does not generate new bills (Jira ID: ND-4341)

Issue Description

Upon making a payment for a flexible AMZ loan, if the reschedule threshold is crossed causing a rescheduling of the loan, then upon reversing this payment, the system does not regenerate the bills and the IPTs.

Resolution

Upon reversing the threshold-crossed payment transaction, the bills and IPTs are now regenerated, and the Interest Remaining field is updated such that it no more holds the value of the Interest Posted amount corresponding to the discarded IPTs.

6.15 System allows to create a backdated payment which causes reversal issues (Jira ID: ND-4356)

Issue Description

If an LPT is to be reversed, the system first checks whether an LPT already exists after the intended LPT based on the transaction time of the LPTs. This results in incorrect account balances.

Resolution

If an LPT is to be reversed, the system now checks whether an LPT already exists after the intended LPT based on the transaction date and the name of the LPT instead of the transaction time ensuring correct account balances.

6.16 While performing a User-Company Assignment the system displays an error message (Jira ID: ND-4427)

Issue Description

While performing a User-Company Assignment in the Servicing Configuration, the system is displaying the following error message due to the number of queries exceeding the Salesforce govern limit:

Resolution

This issue is fixed.

6.17 Multiple UI issues on the loan cancellation confirmation page (Jira ID: MD-442)

Issue Description

When a loan is getting canceled, the following issues have been seen on the loan cancelation confirmation page:

• The loan cancellation confirmation message is displaying an Error icon instead of a Success icon.

• Upon clicking the Cancel or the Close button, the system is not redirecting the user to the corresponding CL Contract page.

Resolution

This issue is fixed, and the following changes have been made:

• The Error icon in the loan cancellation confirmation message has now been changed to the Success icon after the successful cancellation of a contract.

• The Cancel button has now been removed, and the Close button has been retained on the loan cancellation confirmation page as both serve the same purpose.

• Upon clicking the Close button, the system is now redirecting the user to the corresponding CL Contract page.

6.18 Contracts not becoming delinquent (Jira ID: ND-4367)

Issue Description

When a payment is reversed, the Unpaid flag on the bills is getting disabled, resulting in the contract becoming non-delinquent.

Resolution

This issue is fixed as the Unpaid flag on the bill is now getting updated correctly based on the unpaid bills.

6.19 Error while running the Investor Payout Reversal job (Jira ID: ND-4334)

Issue Description

When an Investor Payout Reversal job is run, it is fetching a lot of unnecessary records from the Loan Transaction Summary table, causing the job to fail and display the following error message:

Resolution

This issue is fixed as now the unnecessary records are not created in the Loan Transaction Summary table for an investor.

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

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:

Resolution

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

6.21 Generation of duplicate fee streams in forecasting (Jira ID: ND-4286)

Issue Description

When the Expected First Repayment Date falls on the forecast stream date of the fee component, the system is generating duplicate fee streams in forecasting.

Resolution

This issue is fixed.

6.22 Transaction summary displaying an incorrect disbursement date (Jira ID: ND- 4416)

Issue Description

When a backdated disbursement transaction is made, the Transaction Summary is displaying an incorrect disbursement date.

Resolution

This issue is fixed.

6.23 Errors while processing a return file (Jira ID: ND-4399)

Issue Description

When processing a return file that has the IPT IDs to be reversed, the system is displaying the following error:

Resolution

This issue is fixed as the null pointer exception is now handled in the system.

6.24 Backdated transaction calculates IPTs incorrectly (Jira ID: ND-4462)

Issue Description

When a backdated payment is made or cleared in an !PT-enabled loan, the Interest Posted amount in the re-applied IPTs and in the loan are calculated incorrectly.

Resolution

This issue is fixed.

6.25 Interest Posting Transactions getting created for Closed- Written Off loans (Jira ID: ND-4419)

Issue Description

When an LPT is created for a loan with the status Closed-Written Off, the system is creating IPTs atthe defined frequency.

Resolution

This issue is fixed.

6.26 Error while running the Investor Payout Reversal job (Jira ID: ND-4358)

Issue Description

When an Investor Payout Reversal job is run, it is fetching a lot of unnecessary records from the Loan Transaction Summary table, causing the job to fail and display the following error message:

Resolution

This issue is fixed as now the unnecessary records are not created in the Loan Transaction Summary table for an investor.

6.27 Excess payment transaction incorrectly marks the Payoff flag true (Jira ID: ND- 4443)

Issue Description

In a Flexible AMZ-based loan, when an excess payment transaction of an amount that is less than the sum of Principal Remaining, Interest Remaining, and Fees Remaining is being made, the system is incorrectly marking the Payoff flag as true.

Resolution

This issue is fixed as the Payoff flag is now not marked as true when the contract has a balance amount left that is not within the payment tolerance amount.

6.28 Oldest Unpaid Due Date getting updated incorrectly on rescheduling the loan (Jira ID: ND-4482)

Issue Description

When a loan is rescheduled to change the Repayment Start Date, and if the Maintain Delinquency is set to true and the last bill is paid, the Oldest Unpaid Due Date is getting updated incorrectly.

Resolution

This issue is fixed.

6.29 FloatingRatelnterestRevisionJob failing with an error (Jira ID: ND-4423)

Issue Description

When a batch job is processing a contract that has a floating interest type with the Floating Rate Revision Frequency same as the Billing Frequency and the Due Date of the Amortization Schedule less than the Floating Rate Revision Date, the FloatingRatelnterestRevisionJob job fails, and the following error is getting displayed:

Resolution

This issue is fixed.

6.30 Loan does not close after a payoff (Jira ID: ND-4216)

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.

6.31 Fee-only payment satisfies the unpaid bills too (Jira ID: ND-4476)

Issue Description

When a fee-only payment is made in a loan with the Add Fee Amount to Bill flag as true, then apart from satisfying the fee amount, the payment is satisfying the unpaid bills too, irrespective of the value of the Include in Dues flag.

Resolution

This issue is fixed as the payment now satisfies the unpaid bills only when the charge is included in dues.

6.32 Incorrect Deposit interest accrual calculation leading to an incorrect interest posted in the loan (Jira ID: ND-4537)

Issue Description

When the system calculates the interest accrued for a Deposit, it is not considering the interest accrued due to any LAD-changing event in the Deposit, such as a deposit adjustment, after the first LAD of the Deposit, and is, thus, calculating an incorrect interest posted amount in Deposit.
This is leading to an incorrect interest posted amount in the loan too.

Resolution

This issue is fixed.

7.   Known Issues

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

7.1 Future dated payoff quote calculated incorrectly when a payment is made in the middle of the payment cycle (Jira ID: ND-4634)

Issue Description

When a payment is made in the middle of the payment cycle of a loan with the Pay Future Dues Timely flag enabled, the future dated payoff quote is calculated incorrectly.

7.2 A negative value displayed for the final interest for line of credit type loans (Jira ID: ND-4362)

Issue Description

When a line of credit type of loan is created with a negative floating rate index value, the system is displaying the final interest as a negative value instead of a zero value. However, upon disbursal, the interest rates are calculated correctly.

7.3 Error after running the data mapping job for data archival (Jira ID: ND-4444)

Issue Description

After running the data mapping job for data archival for more than 7000 records, the system is successfully migrating the data but not deleting a few records, and is displaying the following message:

Workaround

This issue is occurring due to a Salesforce constraint because of bulk processing, and as a workaround, you can perform either one of the following steps to resolve this problem:

• Run the mapping again, and the system deletes the records.

• You can write a separate data deletion job after the mapping is done to delete those records.

7.4 Data archival for charge only considers the Paid Amount, and not the Paid Flag, defined in the ruleset (Jira ID: ND-4274)

Issue Description

While configuring data archival for the charge object, if a ruleset is added with the defined values of the Paid Amount and Paid Flag, then the system is considering only the value of the Paid Amount to archive the charges.

Workaround

This issue is occurring due to a rule engine issue, and as a workaround, you can provide a custom query or add a custom query class for filtering the data.

7.5 Objects for Fee Payment and Due Payment are not archiving for the rule provided (Jira ID: ND-4284)

Issue Description

While configuring data archival for Fee Payment and Due Payment, if a ruleset is added for it, then the system is not archiving the data for that rule.

Workaround

This issue is occurring due to a rule engine issue, and as a workaround, you can provide a custom query or add a custom query class for filtering the data.

8.   New and Modified Objects

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

8.1 New Objects

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

8.2 Modified Objects

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

9.   Global Methods

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

10.   Post GA Release

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

10.1 Issues fixed in Q2 Marketplace 3.5003.11 patch

10.1.1 For a fully sold IO, the system is calculating the Total Amount Paid incorrectly (Jira ID: PDRFF-3043/MD-505)

Issue Description

Consider an Investor with the investment amount of $10,000 and there is an Interest Amount Paid of $100. Now the Investment Order (IO) is fully sold to some other investor.

Currently the fields on the IO are updated as follows:

• Remaining Investment Amount: $0

• Principle Paid: $10,000

• Interest Amount Paid = $100

  The system is incorrectly displaying the Total Amount Paid as $100. Instead the expected amount to be displayed by the system must be $10,100 (correct).

Resolution

The issue is now resolved and the system is displaying Total Amount Paid correctly.

10.2 Issues fixed in Q2 Loan Servicing 3.5054.233

10.2.1 UI issues on the loan page in the Lightning Experience (Jira ID: PDRFF-3174/ND-8168)

Issue Description

After an upgrade, the Lightning Experience is displaying the following errors:

• Angular arrow are not being displayed properly on collapse and expand view.

• Tabs on loan account details page are being displayed with a blue background.

Resolution

The issue is fixed now by modifying the logic such that the UI appears as expected.

10.3 Issues fixed in the Marketplace 3.5003.10 patch

10.3.1 On the first day after an Investor Order is sold, the system is neither updating the Interest Posted field nor is the system creating a Investor Loan Transaction (Jira ID: PDRFF-3205/MD-502)

Issue Description

On the first day after an Investor Order is sold, the system is neither updating the Interest Posted field nor creating is the system creating a Investor Loan Transaction. Hence there is a loss of interest of one day.

Resolution

The issue is fixed by modifying the code such that the system is now updating the Interest Posted field and is creating an Investor Loan Transaction.

10.4 Issues fixed in the Q2 Loan Servicing 3.5054.227 and Marketplace 3.5003.7

10.4.1 The system is displaying invalid date and time on contract page with ICU Locale enabled (Jira ID: PDRFF-2880/ND-7543/MD-488)

Issue Description

The system is displaying the following error message and is not allowing any modification to the CL Loan Contract:

The issue appears when the user is trying to make modifications to the following pages:

• Loan Account > Investors > Investment Order Sale page

• Quick Menu > Repayment Schedule > Extension/Payment Deferral

• Quick Menu > Repayment Schedule > Regenerate Principal and Interest Payment

• Quick Menu > Loan Actions > Loan Cancellation

• Quick Menu > Loan Actions > Deposit Transfer

• Quick Menu > Account Statement > Download Account Statement

• Created by and Last Modified by fields on the Lending Product Details page

Resolution

The issue is now fixed and the system is allowing changes to the CL Loan contract without displaying any error message.

10.5 Issues fixed in the 3.5054.227 patch

10.5.1 The system is displaying a discrepancy in the Next Inv Interest Posting Date and the Next Interest Posting Date on the loan contract page (Jira ID: PDRFF-3078/ND-7798)

Issue Description

When a loan contract is rescheduled, the system is not updating the Next Inv Interest Posting Date field, thus causing a discrepancy between the values of the Next Interest Posting Date on the loan contract and the Next Inv Interest Posting Date on the Investor page. This issue is causing adiscrepancy in the investor payout.

Resolution

The issue is now fixed by modifying the logic and the system is updating the Next Inv Interest Posting Date field correctly.

10.5.2 When the Investor Payout job is run, the system is calculating the Interest Accrued even after the IOs are sold (Jira ID: PDRFF-3086/ND-7872)

Issue Description

For a back-dated payment, when the Investor Payout job is run, the system is calculating the Interest Accrued even after the IOs are sold.

Resolution

This issue is fixed and the internal logic has been modified to prevent interest from accruing for the sold off IOs when the Investor Payout job is run.

10.6 Issues fixed in Q2 Loan Servicing 3.5054.223 and marketplace 3.5003.8 patches

10.6.1 The system is calculating the backdated investor payout post an the sale of Investment Order incorrectly (Jira ID: PDRFF-2793/ND-7690)

Issue Description

Investor payout post Investment Order sale is allocating higher interest than the payment's transaction amount to the sold investor.

Example to understand the issue

1. Let us create a contract on March 1, 2013, with the following values:

   • Loan Amount = $1,00,000

   • Rate = 10%

   • Term = 10

   • Interest Only Terms=3

   • Interest Posting Frequency = Monthly

   • Payment Frequency = Monthly

   • Time Counting Method = Month and Days

     Go to Setup > Custom settings > Fractionalization Parameters > set Interest Payout Method = Proportional Interest

     Add two Investor accounts in org.

2. Approve and disburse the loan.

3. Add two Investment Orders having unique investors and each having 50% share.

4. Move the current system date to NIPD, that is, April 01, 2013.

5. Run Investment Order Accrual and posting job.

6. Move the current system date by few days to April 10, 2013.

7. Sell Investment Order-2 to Investment Order-3.

8. The system must create a IPT-1 of $41.67 for first cycle and IPT-2 of $12.50 on the IO for accrued amount from April 01, 2013 to April 10, 2013. the values are updated as follows:

   • Interest Posted = $54.17

   • Interest Accrued = $0

   • Interest Remaining = $0

9. Create a backdate LPT of amount $83.33 with transaction date of April 01, 2013.

10. Run Investor Payout job.

    On Investment Order system displays the Payment ILT of amount incorrectly as $54.17 instead of $41.67 (correct value).

    On LPT-1 details page the under the Investor Loan Transactions section the system is displaying two records of Transaction amount as $41.67 and $54.17 respectively. The sum ($41.67+$54.17= $95.84) is greater than the transaction amount of LPT-1.

Resolution

The issue is now fixed and the system behavior is as follows:

1. Only $41.67 must be paid to the investor because as of LPT-1's transaction date only $41.67 is posted on the Investment Order.

2. IPT-2 of the amount $12.50 must be reversed and a new IPT must be created for the same amount after the processing of the backdated payment.

3. On LPT-1 details page the under the Investor Loan Transactions section the system must display two records of Transaction amount as $41.67 and $41.66 respectively. The sum ($41.67 + $41.66 = $83.33) which is equal to the Transaction Amount of LPT-1.

10.6.2 Payout on a Backdate LPT created prior to the Investment Order sale date, the system is displaying an error(Jira ID: PDRFF-3042/ND-7805)

Issue Description

While calculating the payout on a Backdate LPT created prior to the Investment Order sale date, the Investor Payout job is failing and is displaying the following error message:

Example to understand the issue

1. Let us create a contract on March 1, 2013, with the following values:

   • Amount = $1,00,000

   • Rate = 10%

   • Term = 10

   • Interest Only Terms=3

   • Interest Posting Frequency = Monthly

   • Payment Frequency = Monthly

   • Time Counting Method = Month and Days

     Go to Setup > Custom settings > Fractionalization Parameters > set Interest Payout Method = Proportional Interest

     Add three Investor accounts in org.

2. Approve and disburse the loan.

3. Add two Investment Orders with unique investors and each having 50% share.

4. Move the current system date to NIPD, that is April 01, 2013.

5. Run Investment Order Accrual and posting job.

6. Move the current system date by few days to April 10, 2013.

7. Sell all shares from Investment Order-1 to Investment Order-3

8. On the Sold Investment Order, system creates an IPT-1 of $41.67 for first cycle and IPT-2 of $12.50 on Investment Order for the accrued amount from April 01, 2013 to April 10, 2013. The values are updated as follows:

   • Interest Posted = $54.17

   • Interest Accrued = $0

   • Interest Remaining = $0

9. Create a backdate LPT of $83.33 with the transaction date of April 01, 2013.

10. Set Priority = 1 for the sold Investment Order -1

    Note:

    All sold Investment Order ( if more than one Investment Orders are present) should have Priority = 1

11. Run the Investor Payout job.

    In the Batch Process Log object, the system displays the following exception:

    Investor Payout Job failed due to unknown exception.Message: Divide by 0

    Cause: nullStack: (loan)Line number: 586Type name: System.MathExceptionStacktrace - Entering - execute() of MFiFlexBatchJobDelegate

Resolution

The issue is now fixed and the system behavior is as follows:

1. On the sold Investment Order-1, only $41.67 must be paid because as of LPT-1's transaction date only $41.67 was posted on the Investment Order.

2. IPT-2 of $12.50 should get reversed and new IPT should be created for the same amount after the processing of the backdated payment.

3. On LPT-1 details page the under the Investor Loan Transactions section the system must display two records of Transaction amount as $41.67 and $41.66 respectively. The sum ($41.67 + $41.66 = $83.33) which is equal to the Transaction Amount of LPT-1.

10.7 Issues fixed in Q2 Loan Servicing 3.5054.223 patch

10.7.1 When the loan is paid off in mid- cycle, the system is calculating the interest to be paid to the investor on the IO incorrectly (Jira ID: PDRFF-1989/ND-7804)

Issue description

If the loan is paid off mid-cycle, the interest should be accrued from the last billing day to the payoff date, and this interest is the interest that should be paid to the investor but the system is calculating the is interest as zero when the Investor Share on the Fee component is set to zero. This is because when the Payout job is run, there are two LPTs in the contract, the first one is the Fee only LPT with the Investor Share as zero and the payoff LPT.

The Payout job is considering the Fee only LPT first and is incorrectly updating the LAD and Interest Accrued fields on the IO even though there is no payout as the investor share is set to zero. Now, when the payoff LPT is considered by the job the LAD is already updated as the payoff date, hence the for the interest calculation there are no days passed after the LAD, hence the system calculates the interest incorrectly as zero for zero days.

Example to understand the behavior after the fix

1. Create a Fee with the following values:

   • Name = Commitment Fee

   • Fee Category = Loan

   • Fee Calculation Method = Fixed

   • Amount = $1,000.00

   • Time of Charge = Other

   • Investor Share (%) = $0.0000

     Create a fee set and add the above fee to this fee set

2. Let us create a contract on September 17, 2022, with the following values:

   • Loan Amount = 100,000.00

   • Term = 12

   • Interest Posting = Enabled

   • Interest Posting Frequency = Monthly

   • Interest Posting for IO = Enabled

   • Draw Billing Method = Interest Only

   • Interest Calculation Method = Declining Balance

   • Time Counting Method = Month And Days

   • Interest Only Period = 11

   • Interest Rate = 6.0000

   • Fee = Add the above fee set

3. Disburse the loan and add two Investors, Investor1 and Investor 2, with 50% share each.

4. Move the current system date to September 30, 2022.

5. Run the IO Accrual Job.

6. Create a charge on the loan of above Fee, amount is populated as $1000 by default.

7. Create an LPT of $1000 and clear it.

   This payment is paid towards the charge only.

8. Create a Payoff LPT.

9. Run the IO Posting job.

10. Run the Investor Payout job.

    Interest paid is $0.

    IPT is created on the IO.

11. Run payout job.

    IPT is paid.

Resolution

This issue is now fixed and the system is generating a new IPT on the IO till the payoff date with the number of days from the last billing date to the payoff date.

10.8 Issues fixed in Q2 Loan Servicing 3.5054.216

10.8.1 Rate Change is failing with an error message (Jira ID: PDRFF-2669/ND-7497)

Issue Description

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

Example to understand the issue

1. Create a loan with term as 360 and frequency as Monthly.

2. Go to Loan Quick Menu > Loan Actions > Rate Change, and perform multiple rate changes on loan for different dates.

3. Set up more than 10 Automated Payment Setups on Loan with the following details: (Type: One time, Debit Date: any date for each month, Transaction Amount: equal to or less than the current payment amount on loan)

   

4. Again go to Loan Quick Menu > Loan Actions > Rate Change, and add another schedule by providing the start date as the current system date.

5. Select Validate.

   The system displays the following message: Schedule is valid!

6. Now select Save.

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

Resolution

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

10.8.2 On reversing an adhoc payment LPT, the system is displaying an error (Jira ID: PDRFF-2921/ND-7652)

Issue Description

The system is displaying a Null reference error when attempting to reverse an adhoc payment LPT.

Following is an example of the issue:

1. Consider a contract with a Due Date of 9 February, 2024.

2. Make three payments simultaneously on 14 February, 2024.

   The first payment successfully clears the Due bill and IPT.

   However, the subsequent two payments were classified as adhoc and are allocated towards the principal.

3. Reverse the two adhoc payments.

   The system is displaying the following error.

   Rolling back the batch. Message - Attempt to de-reference a null object

Resolution

The issue is fixed. Adhoc payment LPTs can now be reversed without any error.

10.8.3 The system is displaying an incorrect Last Transaction Timestamp (Jira ID: PDRFF-2688/ND-7410)

Issue Description

The system is displaying an incorrect Last Transaction Timestamp due to the due to the variations in user timezones and the organization's timezone.

Following is an example of the issue:

1. Consider that the transaction creation time, as per the user timezone of GMT+0, is recorded as December 13, 2023, 03:16 AM.

2. Salesforce converts this time to match the company timezone of GMT-5, displaying it on the UI as December 12, 2023, 10:16 PM, while storing the actual UTC time in the field as December 13, 2023, 03:16 AM.

3. However, the last transaction timestamp field displays December 11, 2023, 10:16 PM in the UI, and stores December 12, 2023, 03:16 AM in the UTC time.

The Salesforce database stores datetime field values in UTC format, while the UI displays them according to the timezone of the user viewing it. In this case, when last transaction timestamp takes the date value from the organization's system date and the time value from Salesforce UTC, it is resulting in an incorrect combination. Consequently, displaying an incorrect value.

Resolution

The issue is fixed, the last transaction timestamp field is now populating based on the timezone of the viewing user (company timezone).

10.8.4 The system is not displaying a confirmation message upon a successful payoff (Jira ID: PDRFF-2797/ND-7495)

Issue Description

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

To reproduce the issue perform the following steps:

1. Go to Loan Quick Menu > Payment Transactions > Loan Payoff.

2. On the Record a Pay-off page, in the Spread section, in the Transaction Amount field, enter the expected payoff amount and select Save.

Resolution

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

10.9 Issues fixed in CL Common 3.5003.6

10.9.1 When the Investment Orders are completely sold off, the system is not updating the Remaining Investment Amount field to zero (Jira ID: PDRFF-2463/ND-7536)

Fixed Versions

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

• Q2 Loan Servicing Oxygen (3.5054.212)

• Q2 Loan Servicing Oxygen CL Common (3.5003.6)

Issue Description

Currently, when all the Investment Orders are sold, the system is failing to update the Remaining Investment Amount field to zero. For instance, if there is an investment of $50,000, and all of it are being sold, the Remaining Investment Amount field must reflect as zero. Instead, the Remaining Investment Amount field is displaying $50,000.

Resolution

This issue is fixed. Now, when all of the Investment Orders are sold off the Remaining Investment Amount field is getting correctly updated to zero.

10.10 Issues fixed in Q2 Loan Servicing 3.5054.212

10.10.1 The system is not updating the payment type to Closure - Tolerance, when the contract is closed during excess payment mode (Jira ID: PDRFF-2646/ND-7416)

Fixed Versions

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

• Q2 Loan Servicing Oxygen (3.5054.212)

Issue Description

The system is not updating the payment type to Closure-Tolerance, when the contract is closed during excess payment mode.

Example of the system behavior after the fix

1. Create a Lending Product with the following values:

   • Payment Frequency = Single-Payment

   • Payment Start Date = December 31, 3000

   • Time Counting Method = Actual Days

   • Minimum Interest Option = Minimum Interest Period

   • Minimum Interest Period (in Days) = 185

   • Payoff Tolerance Amount = 50

2. Set the Current System Date to June 30, 2013, and create a loan contract with the following values, and then approve and disburse the complete loan:

   • Loan Amount = $4,402.50

   • Term = 1

   • Rate = 21.90 %

3. Move the Current System Date to July 30, 2013 and create an LPT with the following values:

   • Manual Spread = True

   • Principal Paid = $4,970 (Such that the Principal Remaining is less than the Payoff Tolerance)

   • Interest = $253.42 (Minimum Interest Amount)

   • Fee = $0

   The values are updated as follows:

   • Transaction Amount = $5,223.42

   • Principal Paid = $4,970

   • Interest Paid = $42.47 (The Interest accrued till date gets paid )

   • Excess = $210.95

   • Loan Status = Active-Marked For Closure

     • Principal Remaining = $30

     • Reserve Amount for Next Due Date = $5,012.47

   • Minimum Interest Charge is not created yet.

   • Last Interest Posting = July 31, 2013

   • IPT -1 is created for $42.47

4. Run Loan Closure Job.

   Minimum Interest type Charge is created of original amount of $210.95 with the following values:

   • Total Amount Due = $30

   • Total Amount Paid= $180.95

   An LPT is created from excess amount with the following values

   • Payment Mode= Excess

   • Transaction Amount = $210.95

   • Principal Paid = $30.00

   • Interest Paid = $0

   • Excess = 0

   • Loan status = Loan Status Active - Marked For Closure.

5. Run the Loan Closure Job one more time. The values must be updated as follows:

   • Loan Status updates to Closed - Obligations Met

   • Principal Remaining = $0

   • Loan Balance = $0

   • Fee Paid = $210.95

   • Interest Paid = $42.47

   • Reserve Amount for Next Due Date = $5,042.47

   • Charge is marked Paid

   • Total Amount Paid = $210.95

   • LPT-3 is created with the following values:

     • Payment Mode = Excess

     • Payment Type = Cloure - Tolerance

     • Transaction Amount = $30.00

     • Fees = $30.00

Resolution

This issue is fixed. The payment type is now getting updated as Closure - Tolerance, when the contract is closed during Excess payment mode.

10.10.2 When the Investment Orders are completely sold off, the system is not updating the Remaining Investment Amount field to zero (Jira ID: PDRFF-2463/ND-7536)

Fixed Versions

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

• Q2 Loan Servicing Oxygen (3.5054.212)

Issue Description

Currently, when all the Investment Orders are sold, the system is failing to update the Remaining Investment Amount field to zero. For instance, if there is an investment of $50,000, and all of it are being sold, the Remaining Investment Amount field must reflect as zero. Instead, the Remaining Investment Amount field is displaying $50,000.

Resolution

This issue is fixed. Now, when all of the Investment Orders are sold off the Remaining Investment Amount field is getting correctly updated to zero.

10.11 Issues fixed in Q2 Loan Servicing 3.5054.207

10.11.1 After a backdated Certificate Rate Change, the system is calculating the Interest Posted on an Investment Order incorrectly (Jira ID: PDRFF-2660/ND-7491)

Fixed Versions

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

• Q2 Loan Servicing Oxygen (3.5054.207)

Issue Description

When a backdated Certificate Rate Change is performed on an Investment Order (IO), the system is calculating the value of Interest Posted on that IO incorrectly.

It is calculating the Interest Posted on IO as a sum of interest accrued till the current system date using the older certificate rate and the interest accrued from the backdated transaction date of the rate change till the current system date using the new certificate rate.

The expected behavior is that the Interest Posted on IO must be calculated as a sum of the interest accrued till the backdated transaction date of the certificate rate change using the older certificate rate and the interest accrued from that backdated transaction date to the current system date using the new certificate rate.

Let us say a loan is disbursed on September 17, 2023, and an Investment Order (IO) is added to this loan. Then let us say a payment is made after a month on October 17. This results in the system calculating some value for the Interest Posted on the IO. Then move the date to a month later, say November 16. Now let us say that a backdated rate change is performed on the loan and then a backdated Certificate Rate Change is performed on the IO for November 12. Then move to November 17. After running the necessary jobs, it is observed that the system is calculating the Interest Posted on IO using the old Certificate Rate considering 29 days, which is till today (November 17), instead of 25 days, which is till November 12, and then adding it to the interest calculated using the new Certificate Rate for the rest of the 5 days (from November 12 to November 17.)

The expected behavior is that the Interest Posted on IO must be a sum of the interest accrued till the backdated transaction date (November 12) of the certificate rate change using the older certificate rate and the interest accrued from that backdated transaction date (November 12) to the current system date (November 17) using the new certificate rate.

Resolution

To fix this issue, the internal logic has been modified and the system now calculate the Interest Posted correctly by considering the backdated Certificate Rate Change transaction date.

10.12 Issues fixed in Q2 Loan Servicing 3.5054.205

10.12.1 The system is calculating the Fee Amount Paid to the investors incorrectly (Jira ID: PDRFF-2560/ND-7137)

Fixed Version

This issue has been fixed in the following version:

• Q2 Loan Servicing Oxygen (3.5054.205)

Issue Description

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

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

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

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

Resolution

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

10.13 Issues fixed in Q2 Loan Servicing 3.5054.204

10.13.1 The system is generating a null pointer exception when trying to reverse a Principal Only payment (Jira ID: PDRFF-2580/ND-7111)

Fixed Version

This issue has been fixed in the following version:

• Q2 Loan Servicing Oxygen (3.5054.204)

Issue Description

The system is displaying a null pointer exception while reversing a Principal Only payment.

Example to understand the issue

1. Create a contract with Contract Date as November 29, 2023, with the following values:

   • Interest Calculation Method = Declining Balance

   • Repayment Procedure = Equal Monthly Installments

   • Excess Threshold % for Reschedule = 0.01

   • Reschedule Option On Excess Payment = Keep Same Payment Amount

   • Pre-Bill Days = 3

   • No of Terms = 12

   • Loan Amount = $10,500

   • Add the following Flexible Repayment Plan while creating the contract:

     • Payment Plan 1:

       • Payment Type 1 = Equal Monthly Installments

       • Payment Amount 1 = $200.00

       • Number Of Payments 1 = 1

       • Payment Start Date 1 = December 29, 2023

     • Payment Plan 2:

       • Payment Type 2 = Equal Monthly Installments

       • Payment Amount 2 = $500.00

       • Number Of Payments 2 = 10

       • Payment Start Date 2 = January 29, 2024

2. Approve and disburse the Loan.

3. Make a payment of $1,000.

   Since we are making a payment before the Due Date and there is no interest due, the amount satisfies only the principal.

   As the principal amount changes due to the preceding payment, the amortization schedule must get restructured when the job runs next and hence the current Reschedule Status updates to Pending.

4. Run the Reschedule Transaction Job for the contract.

   System reschedules the contract and updates the Reschedule Status to Success.

   The system creates an OLT with the values for Due Day and Effective Date as null.

5. Now reverse the payment made in Step 3.

   The system is throwing a null pointer exception as it encounters null values in the preceding DD and ED fields of the repayment snapshot.

Resolution

This issue is fixed as the system now checks if the preceding DD and ED fields contain a null value to be able to reverse the required payment successfully.

10.13.2 The Actual Next Installment Date is getting reverted after Index Rate Changes (Jira ID: PDRFF-2222/ND-6856)

Fixed Version

This issue has been fixed in the following version:

• Q2 Loan Servicing Oxygen (3.5054.204)

Issue Description

In a loan contract that has an interest rate change occurring on the Next Due Generation Date, when the Billing Job runs, the system is updating the Actual Next Installment Date correctly, but after the Change Interest Rate job runs on the same day, the system is reverting the Actual Next Installment Date to the previous value. The system must not change the value of Actual Next Installment Date after the Change Interest Rate job runs.

Example to understand the behavior after the fix

1. Set the Current System Date to March 1, 2013, and crate a loan contact with the following values:

   • Interest Rate = 10%

   • Loan Amount = $10,000

   • Terms = 10

   • TCM = Month And Days

   • Payment Frequency = Monthly

   • Interest Posting Transaction = Billing Frequency

   • Interest Type = Floating

   • Pre Bill Days = 1

   • Floating Rate Revision Frequency = Daily

   • Add Actual Next Installment Date to Loan Details layout if not added already

   • Add multiple Interest Rate Schedules with the following values:

     • FRI, Index Rate = 0, Margin = 0 Start from March 1, 2013

     • FRI, Index Rate = 0, Margin = 5 Start from March 31, 2013

   • Approve and disburse the loan

2. Move the Current System Date to the Next Due Generation Date that is, March 31, 2013.

3. Bill 1 is generated for April 1, 2013, and the Next Due Date is May 1, 2013.

   Actual Next Installment Date is getting updated to May 1, 2013, correctly after the Billing Job is run, but it is reverting to April 1, 2013, after Change Interest Rate job is run.

Resolution

This issue is now fixed. The system is updating the Actual Next Installment Date correctly.

10.14 Issues fixed in Q2 Loan Servicing 3.5054.204

10.14.1 The system is generating a null pointer exception when trying to reverse a Principal Only payment (Jira ID: PDRFF-2580/ND-7111)

Fixed Version

This issue has been fixed in the following version:

• Q2 Loan Servicing Oxygen (3.5054.204)

Issue Description

The system is displaying a null pointer exception while reversing a Principal Only payment.

Example to understand the issue

1. Create a contract with Contract Date as November 29, 2023, with the following values:

   • Interest Calculation Method = Declining Balance

   • Repayment Procedure = Equal Monthly Installments

   • Excess Threshold % for Reschedule = 0.01

   • Reschedule Option On Excess Payment = Keep Same Payment Amount

   • Pre-Bill Days = 3

   • No of Terms = 12

   • Loan Amount = $10,500

   • Add the following Flexible Repayment Plan while creating the contract:

     • Payment Plan 1:

       • Payment Type 1 = Equal Monthly Installments

       • Payment Amount 1 = $200.00

       • Number Of Payments 1 = 1

       • Payment Start Date 1 = December 29, 2023

     • Payment Plan 2:

       • Payment Type 2 = Equal Monthly Installments

       • Payment Amount 2 = $500.00

       • Number Of Payments 2 = 10

       • Payment Start Date 2 = January 29, 2024

2. Approve and disburse the Loan.

3. Make a payment of $1,000.

   Since we are making a payment before the Due Date and there is no interest due, the amount satisfies only the principal.

   As the principal amount changes due to the preceding payment, the amortization schedule must get restructured when the job runs next and hence the current Reschedule Status updates to Pending.

4. Run the Reschedule Transaction Job for the contract.

   System reschedules the contract and updates the Reschedule Status to Success.

   The system creates an OLT with the values for Due Day and Effective Date as null.

5. Now reverse the payment made in Step 3.

   The system is throwing a null pointer exception as it encounters null values in the preceding DD and ED fields of the repayment snapshot.

Resolution

This issue is fixed as the system now checks if the preceding DD and ED fields contain a null value to be able to reverse the required payment successfully.

10.14.2 The Actual Next Installment Date is getting reverted after Index Rate Changes (Jira ID: PDRFF-2222/ND-6856)

Fixed Version

This issue has been fixed in the following version:

• Q2 Loan Servicing Oxygen (3.5054.204)

Issue Description

In a loan contract that has an interest rate change occurring on the Next Due Generation Date, when the Billing Job runs, the system is updating the Actual Next Installment Date correctly, but after the Change Interest Rate job runs on the same day, the system is reverting the Actual Next Installment Date to the previous value. The system must not change the value of Actual Next Installment Date after the Change Interest Rate job runs.

Example to understand the behavior after the fix

1. Set the Current System Date to March 1, 2013, and crate a loan contact with the following values:

   • Interest Rate = 10%

   • Loan Amount = $10,000

   • Terms = 10

   • TCM = Month And Days

   • Payment Frequency = Monthly

   • Interest Posting Transaction = Billing Frequency

   • Interest Type = Floating

   • Pre Bill Days = 1

   • Floating Rate Revision Frequency = Daily

   • Add Actual Next Installment Date to Loan Details layout if not added already

   • Add multiple Interest Rate Schedules with the following values:

     • FRI, Index Rate = 0, Margin = 0 Start from March 1, 2013

     • FRI, Index Rate = 0, Margin = 5 Start from March 31, 2013

   • Approve and disburse the loan

2. Move the Current System Date to the Next Due Generation Date that is, March 31, 2013.

3. Bill 1 is generated for April 1, 2013, and the Next Due Date is May 1, 2013.

   Actual Next Installment Date is getting updated to May 1, 2013, correctly after the Billing Job is run, but it is reverting to April 1, 2013, after Change Interest Rate job is run.

Resolution

This issue is now fixed. The system is updating the Actual Next Installment Date correctly.

10.15 Issues fixed in Q2 Loan Servicing 3.5054.202

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

Fixed Version

This issue has been fixed in the following version:

• Q2 Loan Servicing Oxygen (3.5054.202)

Issue Description

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

Example to understand the issue

1. Let us create a contract on March 1, 2013, with the following values and then approve and disburse it:

   • Amount = $10,000

   • Rate = 10%

   • Term = 1

   • Pay Frequency = Single-Payment

   • IPT Frequency = Monthly

   • TCM = Month and Days

   • Minimum Interest Option = Minimum Interest Period

   • Minimum Interest Period (in Days) = 180

2. In the Additional Parameters section, verify that the value of Minimum Interest Amount is displayed as $491.67.

3. Move the SOD to May 10, 2013.

   Since the SOD has moved by two cycles (monthly) the system creates two IPTs.

   For the period between May 1, 2013, and May 10, 2013, the system updates the different parameter values as follows:

   • Interest Accrued = $25

   • Today's Payoff = $10,491.67

4. Let us create an LPT of amount $10,291.67.

5. The system creates Minimum Interest Charge of amount $300 which has the following values:

   • Total Amount Due = $200

   • Amount Paid = 100

   • Today Payoff = $200

   • Loan Balance = $0

   • Principal Remaining = $0

6. Let us go to May 11, 2013.

   The Loan Payoff must be $200. As the Loan Balance is $0 no interest must be accrued but the system is adding a Minimum Interest Amount of $300 to today's payoff.

7. Let us move to June 1, 2013 the next Due Date.

   System does not post an IPT of $0 amount on June 1, 2013.

Resolution

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

10.15.2 The system is not displaying a confirmation message upon a successful payoff (Jira ID: PDRFF-636/ND-7099)

Fixed Version

This issue has been fixed in the following version:

• Q2 Loan Servicing Oxygen (3.5054.202)

Issue Description

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

To reproduce the issue perform the following steps:

1. Go to Loan Quick Menu > Payment Transactions > Loan Payoff.

2. On the Record a Pay-off page, in the Spread section, in the Transaction Amount field, enter the expected payoff amount and select Save.

Resolution

The issue is fixed, the system now displays a success message when the payoff is successful.

For example, the system displays the following message when the Payoff is successful:

10.16 Issues fixed in Q2 Loan Servicing 3.5054.194

10.16.1 Floating Rate Revision job is failing with an error message (Jira ID: PDRFF-2157/ ND-6918)

Fixed Version

This issue has been fixed in the following version:

• Q2 Loan Servicing Oxygen (3.5054.194)

Issue Description

When the Floating Rate Revision job is run to perform the floating rate change for a loan, it is failing with the following error message:

Resolution

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

10.17 Issues fixed in Q2 Loan Servicing 3.5054.191 and Q2 Marketplace 3.5003.3

10.17.1 The Investment Order is not getting paid out and interest is not getting posted for the sold IO when the Investor Payout Job is run (Jira ID: PDRFF-2178/ND-6819)

Fixed Version

This issue has been fixed in the following versions:

• Q2 Loan Servicing Oxygen (3.5054.191)

• Q2 Marketplace Oxygen (3.5003.3)

Issue Description

After an Investment Order is sold, when the Investor Payout Job is run, interest is not getting posted for the sold IO and Investment Order is not getting paid out.

Example to understand the issue

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

   • Loan Amount = $100,000

   • Interest Rate = 10%

   • Term = 6

   • Interest Only Period = 4

   • IPT Frequency = Billing Frequency

   • Time Counting Method = Month And Days

   • Contract Start Date = March 1, 2013

   • Interest Posting on Investment Order = True

   • Payment Frequency = Monthly

   • Pre Bill days=10

   • Sample fee set attached

2. Let us add two investor accounts, Investor-1 and Investor-2, without any priority, and create an Investment Order on the existing contract with the following details and activate it:

   • Investment Amount = $100,000

   • Share = 100%

   • Certificate Rate = 10%

3. Let us go to April 1, 2013.

   Bill-1 gets generated.

4. Let us create an LPT-1 of amount $833.33 to pay the bill.

5. Now let us run the IO Interest Accrual Job, IO Interest Posting Job, and Investor payout Job.

6. Let us go to April 20, 2013.

   Interest Accrued = $527.78.

7. Run the IO Interest Accrual Job and IO Interest Posting Job.

8. Let us now sell the entire share of Investor-1 to Investor-2 with Transfer Income flag set to false and Add Income in Buying Price flag set to false.

   After being sold Investment Order-1 must have the following values: Status = Sold, Enabled=False, Income to Be Collected=True, Last Interest Accrual Date = April 20, 2013, End Date= April 20, 2013, Accrued Interest = 0.00, Next Investor Interest Posting Date = December 31, 3000.

   Whatever was Accrued Interest till selling date, that must get posted. Hence, ILTID record must be created for Interest Posting Transaction for amount = $527.78, Transaction Date = April 20, 2013.

   The Investment Order-1 gets marked sold and becomes inactive.

   Investment Order-2 (newly created) must have a Start Date = April 20, 2013, and Last Interest Accrual Date = April 20, 2013.

9. Let us go to May 1, 2013.

   Bill-2 gets generated.

10. Let us create an LPT-2 of amount $833.33 to pay the bill.

11. Now let us run the IO Interest Accrual Job, IO Interest Posting Job, and Investor payout Job.

    The values must be updated as follows:

    • On running IO Interest Accrual Job: No accural must happen on Investment Order-1. On Investment Order-2, Accrued Interest must be = $305.56.

    • On running IO Interest Posting Job: IPT must be created on Investment Order-2 but no IPT records must be created for Investment Order-1 for May 1, 2013.

    • On running Investor payout Job: Investment Order-1 must get paid out. Interest Remaining on Investment Order-1 must be = $136.11 (Total Interest Accrued from March 1 to April 20)

    • Interest Amount Paid on IO must be = $136.11

    • Interest Balance must be = 0.

    • For Investment Order-2, Interest Remaining must be = $305.56, Interest Amount Paid = $305.56, Next Investor Interest Posting Date = June 1, 2013

    • ILT for posting must be created on Investment Order-2 for amount = $305.56.

    However, the system is reporting the following behavior:

    • On running the Investor Payout Job, the system is displaying the following error message:

      common.apex.runtime.impl.ExecutionException: Duplicate id in list: a8JDn000000HXmnMAG Please find attached logs.

    • Interest is not getting posted for Investor-1 and there is still an Interest Accrued existing on the contract, hence the Investment Order-1 is not getting paid out.

Resolution

This issue is fixed as IPT is now getting created when the IO is sold so that Investor Payout Job pays the due accrued amount correctly and the payout is made correctly.

10.17.2 The system is displaying an error message while generating a future dated payoff quote (Jira ID: PDRFF-2385/ND-6864)

Fixed Version

This issue has been fixed in the following version:

• Q2 Loan Servicing Oxygen (3.5054.191)

Issue Description

While trying to generate a future dated payoff quote, the system is displaying the following error message:

Resolution

This issue is fixed now, and the future dated payoff quote is getting generated successfully.

10.17.3 The interest is not getting posted when an LPT is reversed using ACH (Jira ID: PDRFF-2278/ND-6869)

Fixed Version

This issue has been fixed in the following version:

• Q2 Loan Servicing Oxygen (3.5054.191)

Issue Description

In a loan contract where fees are capitalized, if the backdated LPTs are reversed using ACH and then the Interest Posting Job is run, a dishonor charge gets created incorrectly, and due to this the interest is not getting posted.

For example, let's say on June 16, 2023, a payment is made and June 17, 2023, is the due date, on which the IPT gets generated. Now on June 19, 2023, you try to reverse the payment made on June 16, 2023. Due to this, the IPT gets reversed and after LPT reversal, a dishonor charge gets auto-generated in the system, which updates the LAD to June 19, 2023 while the posting is still to be generated dated as of June 17, 2023. In this scenario, posting is not occurring until the next cycle (in the interim a reschedule action is updating the interest posting date to next cycle.)

Thus, the interest posting transaction generation is missed when a backdated payment is reversed, as a result a dishonor charge is getting created for the current date, advancing the LAD. As a result of this, interest posting is not occurring for that cycle.

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

   • Is Capitalization Enabled = True

   • Payment Frequency = Monthly

   • Contract Start Date = March 1, 2013

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

   • Fee Name = NSF Fee

   • Time of Charge = NSF Fees

   • Fee Calculation Method = Fixed

   • Fee Amount = $25

   • Enable Fee Capitalization = True

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

   • Transaction Amount = $1,000

   • Debit Date = March 25, 2013

   • Amount Type = Fixed

   • Frequency = Monthly

   • Payment Mode = ACH

   • Fee Amount = $25

   • Retry = Enabled

   • Number of Retry Attempts = 0

   • Return Codes for Retry = X

   • Retry Attempt Interval (in days) = 0

   • Apply NSF on Attempt = 0,1

4. Let us go to March 25, 2013 and run the Loan Payment Transaction Creation Dynamic Job.

   The system creates an automated LPT-1 of $1,000.

5. Let us go to April 1, 2013. The system calculates the values as follows:

   • Int Posted = $83.01

   • Bill-1 = $1,046.69

   • Loan Balance = $9,083.01

6. Let us go to April 3, 2013. Reverse the LPT-1 using ACH return such that NSF charge gets created after the LPT reversal.

   The following scenarios must occur, and the values are updated as follows:

   • IPT-1 must be marked reversed.

   • IPT-2 of $84.93 must be created on April 3, 2013.

   • The NSF Charge-1 of $25 must be created on April 3, 2013.

   • The next Interest Posting Date must be updated to May 1,2013.

   • System must create IPT-2 before NSF charge creation.

   • Last Accrual Date must be updated to April 3,2013 due to capitalized NSF charge creation.

   However, the interest is not getting posted on the contract after LPT reversal.

   The interest posting is not getting created by the IPT Job because the IPT-1 (April 1, 2013) is occurring before the LAD (April 3, 2013).

Resolution

This issue is fixed. Now when a backdated LPT is reversed using ACH and the Interest Posting Job is run, the interest is getting posted correctly on the contract.

10.17.4 The interest on the Deposit Amount is not getting included in the payoff quote (Jira ID: PDRFF-2328/ND-6858)

Fixed Version

This issue has been fixed in the following version:

• Q2 Loan Servicing Oxygen (3.5054.191)

Issue Description

In a loan contract with Payment Application Mode as Deposit , when a payoff quote is generated, the interest on the deposit amount is not getting included in the payoff quote.

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

   • Is Capitalization Enabled = True

   • IPT enabled = True

   • Payment Frequency = Monthly

   • Contract Start Date = January 1, 2013

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

   • Loan Amount = $1,000

   • Deposit Rate = 10%

   • Priority = 1

3. Let us go to February 1, 2013.

   The values must be updated as follows:

   • Interest Capitalized = $75

   • Loan Balance = $10,075

   • Deposit Interest Accrued = $8.33

4. Now let us generate a payoff quote.

   The values in the payoff quote must be updated as follows:

   • Payoff Amount = $9,075

   • Interest Capitalized = $75

   • Principal Balance = $10,000

   • Deposit Amount = $1,000

5. Let us go ahead and generate a future dated payoff quote for March 1, 2013.

   The values in the payoff quote must be updated as follows:

   • Payoff Amount = $9,150.62

   • Interest Capitalized = $150.62

   • Principal Balance = $10,000

   • Deposit Amount = $1,000

   However, the Payoff Amount of both the current and future dated payoff quote is not including the interest on the Deposit Amount, and hence the value of the Payoff Amount is getting calculated incorrectly.

   This issue is occurring because the system is calculating the Interest Remaining and the Interest Accrued only on the Principal Balance and not including the interest on the Deposit Amount.

Resolution

This issue is fixed, and now the interest on the Deposit Amount is getting included in the payoff quote.

10.18 Issues fixed in Q2 Loan Servicing 3.5054.183

10.18.1 The Deposit Rate is getting updated incorrectly when a loan contract with interest type as floating is rescheduled (Jira ID: PDRFF-1955/ND-6710)

Fixed Version

This issue has been fixed in the following version:

• Q2 Loan Servicing Oxygen (3.5054.183)

Issue Description

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

Example to understand the issue

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

   • Loan Amount = $10,000

   • Interest Rate = 10%

   • Terms = 10

   • Interest Type = Floating

   • Index Rate Change = 10%

   • Payment Frequency = Monthly

   • Payment Application Mode = Deposit

   • Auto Change Deposit Rate = True

   • Contract Date = March 1, 2013

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

   • Loan Amount = $1,000

   • Deposit Rate = 10%

3. Let us go to March 5, 2013, and reschedule the loan with the following details:

   • Floating Rate Index = Current FRI on loan (This value is selected when the product is created)

   • Interest Rate = 8%

   • Repayment Start Date = March 5, 2013

   The values must be updated as follows:

   • Loan is rescheduled.

   • The current Interest Rate on the loan must reduce from 10% to 8%.

   • The Deposit Rate on the loan must also get reduced from 10% to 8% .

   However, the Deposit Rate is not getting updated automatically after the loan is rescheduled, even though the Auto Change Deposit Rate flag is set to true.

Resolution

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

10.18.2 The amortization schedule is getting generated incorrectly when an Interest Only loan with flexible repayment plan is rescheduled (Jira ID: PDRFF-1927/ND-6813)

Fixed Version

This issue has been fixed in the following version:

• Q2 Loan Servicing Oxygen (3.5054.183)

Issue Description

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

Example to understand the issue

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

   • Contract Date = January 9, 2013

   • Is Capitalization Enabled = True

   • Payment Frequency = Monthly

   • Payment Start Date = February 9, 2013

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

   • Interest Only Period = 6, Payment Start Date = February 9, 2013

   • Equal Monthly Installments = 4, Payment Start Date = August 9, 2013

3. Let us go to February 9, 2013.

   Bill-1 is generated.

4. Let us go to February 20, 2013, and reschedule the loan .

   The values must be updated as follows:

   • Loan is rescheduled.

   • Interest Only Term must be updated to 5.

   • The number of installments must be updated 9.

   However, the amortization schedule for one of the Interest Only Term is getting skipped.

Resolution

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

10.19 Issues fixed in Q2 Loan Servicing 3.5054.179

10.19.1 Paid to Investor flag is not getting set to true when an LPT is created to pay the Charge amount (Jira ID: PDRFF-2095/ND-6728)

Fixed Version

This issue has been fixed in the following version:

• Q2 Loan Servicing Oxygen (3.5054.179)

Issue Description

When a Loan Payment Transaction ( LPT) is created manually to satisfy a charge, the Paid to Investor Flag is not getting set to true due to which the next month's Interest LPT is also not getting picked up by the Paid to Investor Job and hence the investor is not getting paid with the next month's interest paid.

Example to understand the issue

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

   • Amount = $10,000

   • Rate =10%

   • Terms = 6

   • Interest Only Terms = 4

   • Payment Frequency = Monthly

   • Enable Interest Posting For IO = True

   • Contract Date = March 1, 2013

2. Let us create an Investment Order on the existing contract with the following details and activate it.

   • Certificate Rate = 10%

   • Share = 100%

3. Let us add a fee set with the following parameters:

   • Fee Name = NSF Fee

   • Fee Amount = $100

4. Let us go to March 2, 2013, and create an LPT-1 of amount $100 to satisfy only the Charge.

5. Now let us run the IO Interest Accrual Job, IO Interest Posting Job, and Investor Payout Job.

   Paid to Investor flag must be set to true.

   However, the Paid to Investor flag is not getting set to true.

6. Let us go to April 1, 2013.

   Bill-1 is generated.

7. Let us create an LPT-2 to pay the bill .

8. Now let us run the IO Interest Accrual Job, IO Interest Posting Job, and Investor Payout Job.

9. Let us go to April 2, 2013, and create an LPT-3 of amount $100 to pay the Principal.

10. Now let us run the IO Interest Accrual Job, IO Interest Posting Job, and Investor Payout Job.

    The values must be updated as follows:

    • Paid to Investor flag must be set to true.

    • ILT must be created for Payment on investor side.

    However, the third payment is not paid toward the Investor. Also, the Paid to Investor flag is not getting set to true for fee only payment after LPT-1.

Resolution

This issue is now fixed, and the Paid to Investor flag is getting set to true .

10.19.2 Paid to Investor flag is getting set to true incorrectly when an LPT is created (Jira ID: PDRFF-1851/ND-6375/ND-6729)

Fixed Version

This issue has been fixed in the following version:

• Q2 Loan Servicing Oxygen (3.5054.179)

Issue Description

When LPTs are created for investor loan accounts, the Paid to Investor flag is being set to true incorrectly even though the LPT is not creating ILTID.

Example to understand the issue

1. Let us create an FAMZ contract with the following details and disburse it:

   • Loan Amount = $100,000

   • Pre Bill-Days = 10

   • Interest Only Period = 4

   • Contract Start Date = January 3, 2021

   • Payment Frequency = Monthly

   • IPT = True

   • IPT Frequency = Monthly

   • Term = 6 months

   • Rate = 5%

   • Enable IPT for IO = True

2. Let us create an Investment Order on the existing contract with the following details and activate it.

   • Investment Amount = $100,000

   • Certificate Rate = 5%

   • Share = 100%

   • Contract Date = January 3, 2021

3. Let us go to February 3, 2021, and run the Loan Payment Transaction Creation Dynamic Job.

   The LPT is created.

4. Let us clear the LPT with the transaction date as February 3, 2021, which is the billing due date.

   The bill gets satisfied.

5. Now let us run the IO Interest Accrual Job, IO Interest Posting Job and Investor Payout Job.

   The Investor payout amount is updated accordingly.

   However, the Paid to Investor flag is set to true incorrectly even though the amount has not been paid to the investor.

Resolution

The issue is fixed now, by adding a condition that ensures that the Paid to Investor flag is not set to true if the amount is not paid to the investor.

10.19.3 The system is displaying an error message when the Investor Payout Job is run(Jira ID: PDRFF-2129/ND-6727)

Fixed Version

This issue has been fixed in the following version:

• Q2 Loan Servicing Oxygen (3.5054.179)

Issue Description

When an Investment Order is sold in between the billing cycles, and the Investor Payout Job is run , the system is displaying the following error message:

Example to understand the issue

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

   • Loan Amount = $1,000,000

   • Rate = 10%

   • Terms = 6

   • Payment Frequency = Monthly

   • IPT Frequency = Billing Frequency

   • Enable Interest Posting for IO = True

   • Is Interest Posting = True

   • Contract Date = March 1, 2013

2. Let us add two investor accounts without any priority, and create an Investment Order on the existing contract with the following details and activate it.

   • Investment Amount = $100,000

   • Share = 100%

   • Certificate Rate = 10%

3. Let us go to April 1, 2013.

   Bill-1 is generated.

4. Now let us create an LPT-1 of amount $833.33 to pay the bill.

5. Now let us run the IO Interest Accrual Job, IO Interest Posting Job, and Investor Payout Job.

6. Let us go to April 20, 2013, and run the IO Interest Accrual Job, and IO Interest Posting Job.

7. Let us now sell the entire share of investor1 to investor2.

   The Investment Order 1 is marked sold and becomes inactive.

8. Let us go to May 1, 2013.

   Bill-2 is generated.

9. Let us create an LPT-2 to pay the bill.

10. Now let us run the IO Interest Accrual Job, IO Interest Posting Job and Investor Payout Job.

    The interest values must be updated .

    However, the system is displaying the following error message:

    common.apex.runtime.impl.ExecutionException: Duplicate id in list: a8JDn000000HXmnMAG Please find attached logs

Resolution

The issue is now fixed, and the Investor Payout Job is running successfully.

10.20 Issues fixed in Q2 Loan Servicing 3.5054.177

10.20.1 The Pre-Paid Fees is not getting added in the loan amount while conversion of an application to a contract (JIRA ID: PDRFF-2028/ ND-6581/ND-6588)

Issue Description

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

Resolution

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

10.20.2 The remaining amount on an Investment Order is getting incorrectly calculated when a loan is paid off (Jira ID: PDRFF-1893/ND-6611)

Issue Description

When a loan is paid off, the remaining amount on the Investment Order is getting calculated incorrectly. The remaining amount must be updated to zero .

Example to understand the issue

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

   • Amount = $2,00,000

   • Rate =10%

   • Terms = 12

   • Time Calculating Method = Month and Days

   • Interest Type = Fixed

   • Payment Frequency = Monthly

   • IPT enabled = True

   • Is IPT enabled for IO = True

   • IPT Frequency = Monthly

   • Contract Date = October 3, 2013

2. Let us create four investors with investor name as InvestorA, InvestorB, InvestorC and InvestorD with the following details:

   • Investor flag = True

   • Available funds = $1,00,000

   • InvestorA share = 15%

   • InvestorB share = 15%

   • InvestorC share = 20%

   • InvestorD share = 20%

3. Let us change the InvestorA priority to 1 , InvestorB priority to 2 and keep InvestorC and InvestorD as null.

4. Let us create a spread wise principal LPT of amount $60,000 and clear it.

5. Let us run the Investor Payout Job.

   This payment satisfies InvestorA and InvestorB and both the investor status is updated to Inactive.

6. Now let us remove the priority from InvestorA and InvestorB.

7. Let us go to Nov 3, 2013.

   The IPT is created.

8. Now let us run the Investment Order posting Job.

   IPT is created for InvestorC and InvestorD.

9. Let us create a payoff transaction and payoff the loan, and run the Investor Payout Job.

   The values must be updated as follows:

   • Remaining Investment Amount and Interest Posted amount must get paid off and become zero.

   • IO status must change to Inactive on both the IO's (InvestorC and InvestorD)

   But the Remaining Investment Amount is not getting updated to zero when a loan is paid off.

This issue is occurring because the investors with null priority are not getting picked up by the Investor Payout Job.

Resolution

This issue is fixed now, and the Remaining Investment Amount is getting calculated correctly.

10.21 Issues fixed in Q2 Loan Servicing 3.5054.173

10.21.1 The system is displaying an error message while performing a Rate change (Jira ID: PDRFF-1762 / ND-6427)

Issue Description

While performing the Rate Change action from the Loan Actions menu, the system is displaying the following error message:

Resolution

This issue is now fixed. The Rate change is performed successfully without any error messages.

10.22 Issues fixed in Q2 Loan Servicing 3.5054.172

10.22.1 Paid to Investor flag is getting set to true incorrectly when an LPT is created (Jira ID: PDRFF-1851 / ND-6375)

Fixed Version

This issue has been fixed in the following version:

• Q2 Loan Servicing Oxygen(3.5054.172)

Issue Description

When LPTs are created for investor loan accounts, the Paid to Investor flag is being set to true incorrectly even though the LPT is not creating ILTID.

Example to understand the issue

1. Let us create an FAMZ contract with the following details and disburse it:

   • Loan Amount = $100,000

   • Pre Bill-Days = 10

   • Interest Only Period = 4

   • Contract Start Date = January 3, 2021

   • Payment Frequency = Monthly

   • IPT = True

   • IPT Frequency = Monthly

   • Term = 6 months

   • Rate = 5%

   • Enable IPT for IO = True

2. Let us create an Investment Order on the existing contract with the following details and activate it.

   • Investment Amount = $100,000

   • Certificate Rate = 5%

   • Share = 100%

   • Contract Date = January 3, 2021

3. Let us go to February 3, 2021, and run the Loan Payment Transaction Creation Dynamic Job.

   The LPT is created.

4. Let us clear the LPT with the transaction date as February 3, 2021, which is the billing due date.

   The bill gets satisfied.

5. Now let us run the IO Interest Accrual Job, IO Interest Posting Job and Investor Payout Job.

   The Investor payout amount is updated accordingly.

   However, the Paid to Investor flag is set to true incorrectly even though the amount has not been paid to the investor.

Resolution

The issue is fixed now, by adding a condition that the Paid to investor flag will not get enabled if the amount is not paid to the investor.

10.23 Issues fixed in Q2 Loan Servicing 3.5054.171

10.23.1 The system is not considering the Max Term defined on the lending product (Jira ID: PDRFF-1197/ ND-6164)

Issue Description

When we create a contact with term greater than the maximum lending term defined in the loan product, the contract is getting created without validating the Maximum Term.

Example

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

1. Let us create a loan product with maximum term of 15 months.

2. Let us create a contract associated to the same product with a term of 18 months.

3. Click save.

The system should display the following error message:

But the contract is getting incorrectly created without checking the Max Term field value.

Resolution

The issue is fixed now, and the lending product max feature is working correctly during contract creation.

10.23.2 The Loan Payment Transaction is not getting reversed (Jira ID: PDRFF-1407/ ND-5990)

Issue Description

While reversing an FAMZ rescheduled loan, the loan payment transaction is not getting reversed.

Example

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

1. Create an FAMZ loan with the following details and disburse it:

   • Loan Amount = $10,000

   • Contract Date = March 1, 2020

   • Payment Frequency = Monthly

   • Term = 60 months

   • Interest Rate = 10%.

   • Interest Posting on Investment Order = True

2. Let us go to April 1, 2020.

   Since the billing cycle is monthly, the system generates a bill.

3. Let us create a Loan Payment Transaction with the Transaction Date as April 1, 2020, and clear the bill.

4. Let us go to April 15, 2020, and reschedule the loan.

5. Let us go to April 20, 2020, and reverse the rescheduling of the loan.

6. Now let us reverse the loan payment transaction created in step 3.

   The Loan Payment Transaction should be reversed after the reversal of the rescheduling of the loan.

   But the Loan Payment Transaction is not getting reversed.

   This issue is occurring because after reversal of the rescheduling of the loan, the Last Transaction Type is not getting updated to payment transaction, thus causing payment reversal to not occur.

Resolution

The issue is fixed now, and Loan Payment Transaction is getting reversed after the reversal of the rescheduling of the loan.

After reversal of the rescheduling of the loan, the Last Transaction Type is getting updated to Payment transaction, and the system is successfully reversing the payment transaction.

10.23.3 The system is throwing a Null Pointer Exception during contract conversion (Jira ID: PDRFF-1599/ ND-6093)

Issue Description

When an originate loan product with pre-paid fee specified is converted to a loan contract, the system is not considering the pre-paid fee at the time of loan conversion and is throwing a null pointer exception.

Resolution

The issue is fixed now. The pre-paid fee is getting considered and the loan contract is getting created successfully.

Also If the pre-paid fee amount is not specified at the time of loan conversion, the system will display the following error message:

10.23.4 Maximum view state error message seen while previewing the rescheduling of a loan (Jira ID: PDRFF-1580/ PDRFF-1584/ ND-6110)

Issue Description

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

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

Resolution

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

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

• 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.

10.24 Issues fixed in CL Common 3.5008.44

10.24.1 The system is not downloading documents with a size that exceeds 170KB (Jira ID: PDRFF-1209/ PD-1360)

Issue Description

When trying to download a larger size document, the system is throwing the following error message:

Example

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

1. Log in to the sandbox.

2. Click All Tabs.

3. Click the Documents tab.

4. Select the file to be downloaded.

Resolution

The issue is fixed as the larger size documents are getting downloaded without any error messages.

10.25 Issues fixed in Q2 Loan Servicing 3.5054.166

10.25.1 The loan Status is not getting updated to Closed – Obligations met and the system is creating Excess Loan Payment Transactions when an excess payment is done (Jira ID: PDRFF-1277/ ND-6158)

Issue Description

When an excess payment is done, the loan Status is not getting updated to Closed – Obligations met and the system is creating an Excess Loan Payment Transaction.

This is because the Fee Remaining is not getting updated to zero and the Capitalized Fee is not getting cleared.

Example

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

1. Create a loan with the following details and disburse it:

   • Amount = $100,000

   • Contract Date: April 13, 2020

   • Payment Frequency: Monthly

   • First Payment Date: May 13, 2020

   • Term: 3 years

   • Payment Application mode: Future Dues

   • Interest Rate: 3.5%

2. Change the system date to May 13, 2020.

   The system will generate the bill and the Interest Posting Transaction will get created.

3. Change the system date to May 15, 2020.

   The charges will be calculated as per the current contract as follows:

   • Unpaid Charges = $2,000.

   • Interest Posted = $287.67.

   • Payoff Amount = $100,000.

4. Let us create a backdated payment as of May 14, 2020, for an amount greater than the payoff quote value generated for May 15, 2020.

5. This will create an additional amount in the Excess field on the contract and the Loan Payment Transaction is created with the following values:

   • Transaction Amount = $110,000

   • Excess = $9712.33

     This should change the status of the contract as Active – Marked for Closure.

6. Let us run the Loan Closure job.

   The loan Status should be updated to Closed – Obligations met.

   But the loan Status is not getting updated to Closed – Obligations met and creating an Excess Loan Payment Transaction.

Resolution

The issue is fixed. When an excess payment is done, the Fee Remaining value is now correctly updated to zero and the Capitalized Fee is getting cleared due to which the loan Status is getting updated to Closed – Obligations met without creating any amount in the Excess field.

10.26 Issues fixed in Q2 Loan Servicing 3.5054.163

10.26.1 The Maturity flag on the contract is not getting set to True even after the loan contract has matured and the Maturity Processing Job is executed (Jira ID: PDRFF-1292/ND-6003)

Issue Description

When the Maturity Processing Job is executed, the Maturity flag on the contract is not set to True even if the contract has matured.

Example

Let us create a contract and go to a date beyond the Maturity Date. Then let us execute the Maturity Processing Job.

It is seen that the Maturity field on the contract is not selected to indicate that the loan has matured.

Resolution

The issue is fixed and now when a loan is in Active-Good Standing status then, after running the Maturity Processing Job, the loan Status is rightly changing to Active - Matured and the Matured flag is getting set to True.

And when the loan is in Active-Bad Standing status, then even after running the Maturity Processing Job, the loan status is rightly not changing, and the Matured flag is set to False.

10.26.2 Fee Accrual Job is not generating accrual entries for Pre-Paid Fees that are created manually within a loan (Jira ID: PDRFF-1318/ND-6017)

Issue Description

When a Fee Accrual Job is run, the accrual entry for prepaid fee is not getting generated even if the Accrual flag is marked as true. The accrual entries for late fee are generating successfully.

This issue is occurring because the Next Accrual Date was not getting generated while running the batch job.

Example To understand this issue

Let us see the following example:

1. Let us go to a loan contract and click the New Pre-Paid Fee button in the Pre Paid Fee tab to create a new prepaid fee in the loan to be charged.

2. While creating the New Pre-Paid Fee, set the Accrual Required flag to True.

3. Once the Pre-Paid fee is created, the Next Accrual Date should get generated.

4. To verify if the accrual entries are generating, go to the Next Accrual Date and let the Apex Jobs get completed. Then run the Fee Accrual Job from Batch job.

This should generate the accrual entries. But the Next Accrual Date is not getting updated and hence the accrual entries are not getting generated even when the Accrual Required flag is set to True.

Resolution

The issue has been fixed and the accruals entries are getting generated successfully when the Accrual Required flag is set to true.

10.27 Issues fixed in Q2 Loan Servicing 3.5054.161

10.27.1 Backdated payment reversal is updating Interest Remaining incorrectly (Jira ID: ND-5956)

Issue Description

After the reversal of a backdated payment, the Interest Remaining is getting calculated incorrectly.

Example to understand the issue

Let us look at an example to understand this issue.

1. Let us say Periodic Fees are created in the system with the following details:

2. Let us say a Simple Loan Lending Product with the preceding fees is created with the following values:

3. Let us say a loan is created from the preceding Lending Product and with the following values:

4. Let us say the following amount is disbursed:

Transaction Amount = $10,000.

5. Now, let us go to the following date: June 2, 2013, and create a Periodic Fee manually with the date as: June 2, 2013.

6. Let us then make a backdated payment with the following details:

• Transaction Amount = $1000.

• Transaction Date = June 1, 2013.

7. Now reverse this backdated payment.

After the backdated LPT is reversed, Interest Remaining should be ($10,000 * 1 * (10/360) * 100) = $2.77.

But the system is calculating the Interest Remaining as $2.91.

This issue is occurring because during the payment reversal, only paid charges were getting uncapitalized, due to which the unpaid charges were still accounted for and thereby causing deviation in the interest calculation.

Resolution

Now, whenever a backdated payment is reversed, along with reversing the IPTs, the charges that were created on a date greater than the IPT Transaction Date are uncapitalized and updated in the database. These charges are then picked up by the IPT Job for capitalization. The other charges that were created between the last reversed IPT date and Last Accrual Date of the contract are uncapitalized for some time and then recapitalized immediately when the backdated payment reversal is taken into account by the system.

Thus, this issue is fixed and the Interest Remaining is getting calculated correctly after the backdated payment reversal.

10.27.2 Investor Payout Dynamic Reversal Job is failing (Jira ID: PDRFF-1398/ND-5989)

Issue Description

While trying to run Investor Payout Dynamic Reversal Job, the system is displaying the following error message: “First error: loan:Too many DML rows: 10001.”

To elaborate on this issue, for the following configuration of the loan, the InvestorPayoutReversalJob is failing with the Too many DML rows exception:

• Create Summaries = True

Internally, when the InvestorPayoutReversalJob runs, it leads to the fetching of the transaction summaries of the transaction records. To get the transaction summary records, the system is not checking if there are any record IDs passed to the query for the fetching of those transaction summary records. Instead, it just excludes the Where clause in the dynamic query when it finds that there are no transaction summary records IDs passed to the query for fetching. And as there is no Where clause, it fetches all the transaction summary records.

Thus, when the system is excluding the Where clause of the dynamic query, it is fetching more than 10,000 records resulting in the following error message:

Resolution

This issue is fixed as the logic is updated wherein the system does not go ahead with fetching any records for the dynamic query when it finds that there are no record IDs passed to the query for fetching the transaction summaries. This ensures in preventing the system from querying all the records.

If there are any record IDs passed to the query, then the dynamic query will have the Where clause and will limit the number of records then.

10.28 Issues fixed in Q2 Loan Servicing 3.5054.156

10.28.1 The Fees Remaining field is getting updated incorrectly when a backdated LPT is reversed (Jira ID: PDRFF-1286/ ND-5928)

Issue Description

While performing a backdated reversal of an LPT on a contract with a capitalized fee, instead of updating the Fees Capitalized field, the Fees Remaining field is getting updated with a non-zero value. The Fees Remaining must not get updated with a non-zero value.

When Fees Remaining is updated and Fees Capitalized is not, the Loan Balance is getting updated incorrectly, and as a result, the running balances in the statement are getting impacted.

Example

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

1. Create a Simple Lending Product with a Periodic Fee Set having fee with capitalization enabled.

2. Create a contract for the newly created product on March 1, 2022, and move the SOD to April 1, 2022. The Periodic Fee will be created, and it will be capitalized.

3. Now, move the SOD to April 30, 2022, and create an LPT which satisfies the Periodic Fee.

4. Again, if you move the SOD to May 1, 2022, another Periodic Fee is created, and it is capitalized.

5. Now, reverse the LPT created on April 30, 2022.

It is observed that instead of increasing the value of Fees Capitalized, the system is increasing the value in the Fees Remaining field.

Resolution

This issue is fixed as the internal logic has been updated such that, immediately after the payment reversal, the Interest Posting Job is run internally by the code so that the system does not have to wait for someone else to run this job. Due to this, now, the Fees Remaining field, Fees Capitalized fee, and all other fields are getting updated with correct values.

10.28.2 Total Payoff Amount is calculated as $0 when the Payoff Date is greater than or equal to the Next Due Date (Jira ID: ND-5856)

Issue Description

While generating a payoff quote for a loan where the Payoff Date is greater than or equal to the Next Due Date, the Financial Calculator is throwing a null pointer exception, resulting in an incorrect Payoff Amount of $0.

For example, let us say that the Current System Date is November 6, 2018, and the Next Due Date is Nov 15, 2018, then on generating a Payoff Quote for November 15, 2018, the system throwing a null pointer exception resulting in Total Payoff Amount as $0.

Resolution

This issue is fixed as the internal logic has now been updated. The system is not throwing a null pointer exception now and is calculating the Total Payoff Amount correctly.

10.28.3 The system is calculating an incorrect Total Payoff Amount when a future dated payoff quote is generated on a date that is between the Pre-Bill Days and the Next Due Date (Jira ID: ND-5652)

Issue Description

When a future dated payoff quote is generated on a date, that is between the Pre-Bill Days and the Bill Due Date, for a date that is after one cycle and if the Pay Future Dues Timely flag is True, then the system is calculating an incorrect Total Payoff Amount.

In other words, where there is a pre-billed bill transaction, the PayOff Quote is not correctly calculating future dated quotes unless the future date also goes past a future unbilled Bill date. For example, let us say September 1, 2021, is pre-billed, then the quote value is not correct for a quote in September as the September 1, 2021, payment is not taken into account, but for a quote in October it is correctly taking into account both September 1, 2021, and October 1, 2021, payments.

This is because as the bill is already generated between the Pre-Bill Days and the Bill Due Date, due to the Pre-bill Days defined in the system, the system is incorrectly calculating the Total Payoff Amount by considering the payment start date as the next due date after the upcoming Next Due Date as the system is considering the upcoming Next Due Date as already billed and thus resulting in an incorrect payoff amount.

Resolution

This issue is fixed as the internal logic is now updated to consider the correct payment start date for calculating the Total Payoff Amount.

10.29 Issues fixed in Q2 Loan Servicing 3.5054.154

10.29.1 Backdated LPT before Index Rate Change is updating Interest fields incorrectly (Jira ID: PDRFF-1375/ ND-5925)

Issue Description

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

Steps to Recreate

1. Create a Lending Product with the following configuration:

   • Type: Simple Product

   • Is Interest Posting Transaction Enabled: True

   • Interest Type: Floating

2. Create a contract for the newly created product and move the date forward a few days, resulting in the accrual of those days.

3. Select the Payment Frequency as Monthly.

4. Select the Contract Creation Date as 12/6/2022.

5. Select the Next Index Rate Change action date as 05/7/2022.

6. Now, move the system date to 5/7/2022.

7. After moving the system date to 5/7/2022, the rate changes.

8. The last transaction details are updated, and Interest Accrued is moved to the Interest Remaining field.

9. On the same day, post a regular LPT with the following date: 4/7/2022. As a result, the value in the interest remaining field remains the same, but a day’s interest is accrued at the new rate and updated in the Interest Accrued field.

Resolution

This issue is fixed as a validation has been added to block a backdated payment before the Index Rate Change. Also, the following logics are updated:

• Reversing the Index rate Change.

• Backdated Index Rate Change.

10.29.2 Backdated payment before charge capitalization date is updating Interest Accrued incorrectly (Jira ID: PDRFF-1375/ ND-5841)

Issue Description

When a backdated payment is created for a loan contract that has capitalized charges after the Transaction Date, the system is considering the capitalized charges to be the part of loan balance even on the Transaction Date due to which the accrued interest is calculated incorrectly, and the loan balance increases.

Steps to Recreate

1. Create a Simple Loan Lending Product.

2. Create a capitalized charge on 15/11/2022 with EOD/SOD batch.

3. Create a backdated LPT prior to capitalized charge on 14/11/2022 and clear it. As a result, the accrued interest is getting updated incorrectly.

Resolution

This issue is fixed as the logic in the system is changed to uncapitalize the charges that were capitalized after the backdated payment transaction date and then recapitalize the charges when the payment has been accounted for.

10.30 Issues fixed in Q2 Loan Servicing 3.5054.150

10.30.1 Amortization Schedule is getting generated with incorrect values (Jira ID: ND-5616)

Issue Description

When a loan contract is restructured to change the Interest Only Period and the Interest Only Payment Amt, the Amortization Schedule is getting generated with incorrect values.

Example to understand the Issue

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

1. Open a CL Contract in Current status.

2. Click Reschedule.

3. Enter the Interest Only Period and Interest Only payment amount such as $1500.

4. Click Preview.

5. Save the changes.

6. Observe the Amortization Schedule.

It is seen that the repayment Amount in the Amortization Schedule is incorrect.

Reason

This issue is occurring due to the user entering invalid values causing the calculator to create incorrect schedules (Negative balances).

Resolution

This issue is fixed by restricting the schedules from getting generated if the values in the schedule are going to be negative and by throwing an error message indicating that the value entered as input is invalid.

10.30.2 Amount Due Till Current is incorrect if the Include In Dues is set to true for fees and when loan becomes delinquent (Jira ID: PDRFF-1127/ND-5907)

Issue Description

When a loan becomes delinquent and if the Include In Dues flag is set to true for fees for such a loan, the system is calculating an incorrect Amount Due Till Current of a loan contract.

Example

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

1. Create a Periodic Fee by setting the Include In Dues flag value to true.

2. In the Lending Product, set the Add Fee Amount To Bill flag value to true.

3. Create a contract with the preceding lending product and provide Delinquency Basis as Schedule Balance.

4. Move the Current System Date to the date in the Next Due Generation Date field. The system generates a Periodic Fee as per the configuration and adds this fee amount to the generated bill. The Due Amount field on the bill thus includes the fee amount as well.

5. Move the CSD ahead such that the bill is not paid, and thus loan is marked as delinquent.

As the Periodic Fee is already included in the bill, the Amount Due Till Current field should only hold the Delinquent Amount and any fees that are not added to the bill. However, the issue is that the Amount Due Till Current field calculation is also considering the fees that are already included in the bill, which is an incorrect behavior.

Resolution

This issue is fixed as the internal logic has been updated such that only those Unpaid Charges, for which the Include in Dues flag is set to false, are included in the Amount Due Till Current calculation.

10.30.3 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:

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.

10.30.4 The system is throwing an error while converting a loan application into a loan contract (Jira ID: PDRFF-1336/ND-5859)

Issue Description

When trying to convert a loan application, which has interest components attached to it, to a loan contract, the conversion is failing with the following error message:

Reason

The contract conversion uses enhanced loan API where most of the child objects are passed as input to the API and validated. It is required that a conversion mapping be present for individual fields of the child objects. As such a mapping is missing in the configuration, the enhanced loan API to create contracts is failing and displaying the error when certain fields are not queried.

Resolution

This issue is fixed. As a solution, for each child object configured in the conversion mapping, the conversion logic in loan is modified to query all necessary fields for the child object. Thus, the existing mapping configurations are not required to be changed.

The child objects impacted are Repayment Plans, Interest Components, Holiday Schedules, StepUp Schedules, Disbursement Plans and Collateral Liens.

10.30.5 Payoff Quote is incorrect when the Payoff Quote is generated with Pay Future Dues Timely flag as True (Jira ID: ND-5444)

Issue Description

On generating a Payoff Quote setting the Pay Future Dues Timely flag to true, the value of the calculated Payoff Quote is incorrect.

This issue is occurring when the Transaction Date is between the Due Dates.

Resolution

This issue is fixed. The internal logic has now been updated to calculate the correct value of the Payoff Quote while generating the Payoff Quote with the Pay Future Dues Timely flag to true.

10.30.6 Error while generating Payoff Quote with Pay Future Dues Timely flag set to true for a loan contract that has a custom Payment Spread defined for it (Jira ID: ND-5351)

Issue Description

If a custom Payment Spread is defined in a loan system that is other than the standard Payment Spread, then while generating a Payoff Quote for such a loan with the Pay Future Dues Timely flag set to True, the system is displaying the following error: “Apex CPU time limit exceeded.”

Reason

This error occurred because the system was trying to find the standard Payment Spread of the following order only: Fees, Interest, Principal. It could not recognize the custom Payment Spread and kept looking for the standard one resulting in a loop.

Resolution

This issue is fixed as the internal logic is now updated such that the system is now able to recognize the Custom Payment Spread and process it accordingly. Thus, the system is now able to successfully generate the Payoff Quote with Pay Future Dues Timely flag set to true for a loan contract that has a custom Payment Spread defined for it.

10.30.7 DateUtil function is not calculating the correct number cycles between two dates for a Semi-Monthly-PD Frequency (Jira ID: ND-5697)

Issue Description

While trying to use the cyclesBetween method of the DateUtil class to get the number of cycles between two dates for a loan with Payment Frequency as Semi-Monthly-PD frequency, the system is giving an incorrect number.

For example, for a 15-year loan with 2 payments per month, the number of cycles or terms is to be calculated as 15 * 12 * 2 = 360. But the system was not calculating it as 360.

Resolution

This issue is fixed as the cyclesBetween method of the custom class, DateUtil.cls, is now updated to provide the correct number of terms for a Semi-Monthly-PD frequency.

10.30.8 Flexible Repayment Plan is not getting reflected in the Repayment Schedule after conversion of an application to a contract (Jira ID: ND-5070)

Issue Description

After converting a loan application to a loan contract using the contract creation API and passing both the Rate Schedule and the Flexible Repayment Plan for the CL Contract, then on marking the contract as approved and disbursing it, the Flexible Repayment Plan is not getting reflected in the Amortization Schedule. On clicking Reschedule, and then Preview, the system gives the desired output. But the Regenerate Amortization Schedule API needs to be called again in the class to get the desired output, which slows down the process and the loan API internally calls the Amortization Schedule API twice in the flow making it an additional call that may exceed the salesforce limits.

Reason for the Issue

This issue is occurring as the Flexible Repayment Plans are not getting passed to the contract creation API called in the conversion phase.

Resolution

This issue is fixed by replacing the loan contract creation API for conversion with a new create-contract API to pass the Flexible Repayment Plans. Once this is done, the Flexible Repayment Plans are used in the schedule creation at the time of contract conversion, and the Amortization Schedules are getting generated as per the Flexible Repayment Plans.

10.31 Enhancements made in Q2 Loan Servicing 3.5054.150

10.31.1 Disbursement is allowed between Bill Generation Date and Due Date for FIT loans (Jira ID: PDRFF-877/ND-5775)

Enhancement Description

With this patch release, the system allows you to disburse a loan between the Bill Generation Date and Due Date for FIT loans.

Earlier, for a multi-disbursement type of loan facility, the subsequent disbursements were not being allowed if the disbursement date fell between the Pre-Bill Date (on which the bill is getting generated) and the actual Due Date as many parameters like the interest would get affected.

With this enhancement, whenever you disburse the loan between the Bill Generation Date and the Due Date, the system can regenerate the repayment schedule of a loan and adjust extra interest in the future schedules because the bill for that period would already have been generated and cannot be altered.

For example, let us see the following scenario of a loan:

In this scenario, the Bill for Due Date of 01 July 2022, gets generated on 21 June 2022 as per the pre-bill days configuration. Once the bill is generated, no disbursement was allowed on the contract from 21 June 2022 (Bill Generation Date) to 01 July 2022 (bill Due Date).

But with this enhancement, the Loan Servicing Product now supports the disbursements in between this period, without changing the original Due Amount for the billed Due Date or cancelling the already generated Bill.

The following scenarios are also included as part of this enhancement:

• When the current bill is unpaid.

• When the bill is fully paid.

• When the bill is partially paid.

10.31.2 New frequency named Billing Frequency added to the Periodic Fee Setup Frequency list (Jira ID: ND-5237)

Enhancement Description

With this patch release, Q2 Loan Servicing has been enhanced to provide an additional option in the list of Frequencies, that you can select from, in a Periodic Fee Setup. Thus, you can now select Billing Frequency as the Frequency in the Periodic Fee Setup of a loan contract. Billing Frequency will follow the billing schedules date for calculating the Next Recurring Fee Date.

Example

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

1. Create Periodic Fees with Include in Schedules/Dues = true, Fee Calculation Method = Fixed, Amount = 200, Periodic Fee Amount Type = Total Amount.

2. Create a Simple Loan Lending Product with FIT = false, Payment Frequency = Monthly.

3. Let us say the SOD = 4/30/2013. Then create a Loan Account with Loan amount = 10000, Interest Rate = 10, Contract Date = April 30, 2013, Payment Start Date = May 30, 2013, Term = 10.

4. On Periodic Fee Setup, provide Frequency = Billing Frequency, and then Save.

5. Approve and disburse with Transaction Amount = 10000.

6. Move SOD to May 30, 2013.

On the CL Contract details page, Periodic Fee Setup will display Frequency = Billing Frequency.

The Next Recurring Fee Date will display May 30, 2013, after disbursing the contract.

7. On moving SOD to May 30, 2013, the Next Recurring Fee Date will display June 30, 2013.

10.32 Issues fixed in CL Common 3.5008.41

10.32.1 DataMapperInitiatorJob is failing and throwing an exception while 100K records processing test (Jira ID: PDRFF-583/PD-913)

Issue Description

While executing 100k records, the DataMapperInitiatorJob for the accounting jobs are failing with the following error messages:

Steps to Recreate

1. Load 100K records in CL loan.

2. Trigger accounting jobs. This is throwing the exception.

Expected Result

All records must get processed successfully without any errors.

Reason

This issue occurs during validating queries of all accounting setup. The DataMapperInitiatorJob runs validation of mapping headers queries. During this validation, it queries more than one record that leads to the query rows exception when the database is large for a particular object.

Resolution

This issue is fixed as there are no exceptions getting thrown now and all the records are getting processed successfully.

10.33 Issues fixed in Q2 Loan Servicing 3.5054.143

10.33.1 Amortization Schedule is getting generated with incorrect values (Jira ID: ND-5616)

Issue Description

When a loan contract is restructured to change the Interest Only Period and the Interest Only Payment Amt, the Amortization Schedule is getting generated with incorrect values.

Example to understand the Issue

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

1. Open a CL Contract in Current status.

2. Click Reschedule.

3. Enter the Interest Only Period and Interest Only payment amount such as $1500.

4. Click Preview.

5. Save the changes.

6. Observe the Amortization Schedule.

It is seen that the repayment Amount in the Amortization Schedule is incorrect.

Reason

This issue is occurring due to the user entering invalid values causing the calculator to create incorrect schedules (Negative balances).

Resolution

This issue is fixed by restricting the schedules from getting generated if the values in the schedule are going to be negative and by throwing an error message indicating that the value entered as input is invalid.

10.33.2 Last Interest Rate in LTS is getting updated incorrectly during the Index Rate Change (Jira ID: PDRFF-1231/ND-5830)

Issue Description

After the floatingRateRevision job is run, the Last Interest Rate on the LTS is not getting updated correctly.

Example

Let us look at an example to understand this issue.

Let us say a loan contract is created. Then let us run floatingRateRevision job. This changes the rate successfully. An OLT record gets created successfully with Transaction Type as Index Rate Change. A Loan Transaction Summary (LTS) also gets generated with the same Transaction Type.

But the Last Interest Rate on the LTS is either blank or incorrectly updated.

Expectation

The Last Interest Rate on LTS must get updated with the interest rate that was before the rate change.

Resolution

This issue is fixed as the Last Interest Rate on the LTS is now getting updated correctly.

10.34 Issues fixed in Q2 Loan Servicing 3.5054.141

10.34.1 Incorrect interest amount seen in the AIC IPT when a backdated payment is made after the AIC interest posting (Jira ID: PDRFF-1222/ND-5754)

Issue Description

In a setup where payments are generated one day backdated, it was observed that, when an Additional Interest Component (AIC) interest posting was followed by a backdated payment, the system is adding one day's extra accrual to the contract.

If the AIC Interest Posting Transaction (IPT) date is different than the loan IPT date, then if a backdated payment is made after the AIC IPT is created, the payment discards that IPT, and once the Interest Posting Job runs again, IPTs gets recreated, but it is seen that the interest amount in the AIC IPT is an incorrect amount.

Reason

This occurs because after the AIC IPT is discarded, the Interest Remaining on AIC is incorrectly calculated.

Example of the issue

Let us understand this issue with an example.

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

2. Let us create a contract from the above Lending product, then approve and disburse it.

3. Move to the first bill date of July 7, 2013. One regular IPT is posted of $41.67.

4. Move one day ahead to July 8, 2013. One AIC interest will get posted of $26.66.

5. Create a backdated LPT with Transaction Date as of July 7, 2013. The AIC IPT gets reversed and if you run the Interest Posting Job again, the AIC IPT is created with an incorrect amount instead of the same amount of $26.66.

Resolution

This issue is fixed as the logic to calculate the Interest Remaining on AIC is now corrected, and thus, the interest amount on AIC IPT is now correct when a backdated payment is made after the AIC.

10.35 Issues fixed in CL Common 3.5008.40

10.35.1 Running the Floating Rate Revision Job before the cutoff date of IO expiry in an Advance Interest IO loan is resulting in an exception (Jira ID: PD-1160)

Issue Description

While running the Floating Rate Revision Job before the cutoff date of IO expiry in an Advance Interest, Interest Only (IO) loan, the system is throwing the following exception:

“CL010101: Unexpected Exception List index out of bounds: -1 at line 1880”

Example

Let us look at the following example:

1. Create an Advance Interest IO loan with IO period of 5 months.

2. Let the Repayment Start Date for IO be January 20, 2021, and the cutoff date be May 20, 2022, after which the loan becomes non-IO (with Principal and Interest).

3. Do a rate change by running the Floating Rate Revision Job in May before or on the cutoff date of the IO expiry.

Floating Rate Revision Job fails with an exception and Amortizations Schedules do not get generated.

Resolution

This issue is fixed by fixing the internal logic in the code.

10.36 Issues fixed in Q2 Loan Servicing 3.5054.140

10.36.1 Floating Rate Revision job is failing with an error message (Jira ID: PDRFF-1026/ND-5708)

Issue Description

When the FloatingRateInterestRevisionDynamicJob runs, it is failing with the following error message: “Aggregate query has too many rows for direct assignment, use FOR loop.”

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

Resolution

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

10.36.2 The system is not displaying any message when more than the defined Digits After Decimals is entered on the UI for LPT (Jira ID: PDRFF-1038/ND-5550)

Issue Description

When the Digits After Decimals in the Org Parameters and in the Lending Product is defined as 2, the users can still enter 3 digits after decimal in the Transaction Amount field on the UI for LPT. This value then gets rounded off to 2 internally.

Expected

The system must display a message if the user enters more than the defined Digits After Decimals in the Org Parameters. In this case, the system must display a message if the user enters more than 2 decimal places in the Transaction Amount field on the UI for LPT.

Reason

The users may have entered more than 2 digits due to the fat-finger syndrome and the rounding was incorrect.

Resolution

This issue is fixed as the system now displays an information message when the number of decimal digits after the decimal point is more than the allowed decimal digits defined in the Org Parameters. The information message displayed is: “You are trying to enter more decimal places than what is permitted for this field.” If the user still enters more than the defined Digits After Decimals, then the system rounds it off and saves it to the defined Digits After Decimals.

10.37 Issues fixed in Q2 Loan Servicing 3.5054.136

10.37.1 Reserve Amount for Next Due is not getting cleared when a payoff is made with amount more than the billed amount (Jira ID: PDRFF-965/ND-5677)

Issue Description

When a loan payoff, with an amount greater than the billed amount, is made with the Payment Application Mode as Future Dues before the Maturity Date of the contract, the Reserve Amount for Next Due captures the additional amount.

Expectation

The system must not transfer any amount to the Reserve Amount for Next Due field if the loan is getting closed. The payoff amount must satisfy the total outstanding and there must not be any amount appearing in the Reserve Amount for Next Due field.

Reason

When a payment is made of an amount greater than the billed amount, the extra amount is already paid against the principal, and the system is just storing the extra amount as virtual amount in the Reserve Amount for Next Due field to mark the future bills as paid with that amount. But, when a payoff is made, there would be no more future bills to be marked as paid, and so that extra amount must not be stored in the Reserve Amount for Next Due field.

Resolution

This issue is resolved by making changes in the internal logic. Now, if the payment type is Payoff, the internal logic is modified such that the additional amount is not stored in the Reserve Amount for Next Due.

10.37.2 Pre-Paid Fees that are not set to be added to the Loan Amount are being added to the Loan Amount (Jira ID: PDRFF-1025/ND-5695)

Issue Description

When a Simple Loan has the Revolving flag set to True and Funding in Tranches flag set to True, the Pre-Paid Fee amounts are getting added to the Loan Amount during the creation of a Loan Disbursal Transaction even though the Pre-Paid Fees are not set to be added to the Loan Amount. This means it is possible to fund an amount including the fees.

Example

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

1. Create a new Pre-Paid-Fee with the following details:

2. Add this fee to the lending product in the Prepaid Fee section.

3. Create a lending product with Funding in Tranches = True and Revolving = True.

4. Create a contract with Loan Amount = $10,000 and check for the fee.

5. $1,000 amount should be reduced from the disbursal amount, and Total Pre-Paid Fees should be $1,000.

6. As Loan Amount is $10,000 and disbursal amount = $9,000,

if we create an LDT (Loan Disbursal Transaction) of $10,000, then the following two DTD (Disbursal Transaction Distribution) should be created:

• $1,000 for Pre-Paid Fee

• $9,000 for the normal Disbursement

7. If we provide an amount of more than $10,000 to disburse, say $11,000, and click Regenerate Distributions, then the system should display the following error message:

“Disbursement transaction amount should be less than available amount.”

But the system was not displaying any error messages and it was allowing to disburse $11,000.

Reason

This is because, for Pre-Paid Fee, with Add to Loan Amount set to False, the system was incorrectly calculating the maximum limit allowable for the LDT Transaction Amount.

For example, referring to the preceding example, the system was adding the fee Amount of $1,000 to the Loan Amount ($10,000) and considering $11,000 as the maximum allowable limit for the LDT Transaction Amount, which was incorrect, and the system was not displaying an error message to indicate that the entered Transaction Amount is an incorrect amount.

Resolution

This issue is resolved as the maximum allowable limit for the LDT Transaction Amount is now correctly calculated, and the system displays an exception on the UI when you enter Transaction Amount that is greater than the maximum allowable limit calculated.

Referring to the preceding example, for a loan with Add Amount to Loan Amount set to False, if the Transaction Amount is $10,001, then the system is now displaying the following error message: “Disbursement transaction amount should be less than available amount.”

10.38 Issues fixed in Q2 Loan Servicing 3.5054.132

10.38.1 Updating of charges is failing with an error in the Charge Trigger after accounting file is generated for the charges (Jira ID: ND-5458)

Issue Description

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

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

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

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

• Fees_Remaining_c

• Total_Due_Chargesc

• Pay_Off_Amount_As_Of_Todayc

• Fees_Paid_c .

Basically, the flow is as follows:

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

Resolution

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

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

• Waive__c

• Original_Amount__c

• Total_Amount_Due__c

• Principal_Due__c

• Interest_Due__c

• Calculated_Interest3__c

• Tax_Remaining__c

10.38.2 Investor Payout Job is throwing an exception (Jira ID: PDRFF-1117/ND-5646)

Issue Description

On running the Investor Payout Job, the system is throwing the following exception:

“Investor Payout Job failed due to unknown exception.

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

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

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

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

Resolution

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

10.39 Issues fixed in Q2 Loan Servicing 3.5054.127

10.39.1 LPT satisfying over and above principal amount of the bill (Jira ID: PDRFF-911/ND-5578)

Issue Description

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

Example

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

Let us set the deposit offset to 1 day.

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

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

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

Expected Behavior

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

Actual Behavior

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

Resolution

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

10.39.2 Interest is not getting accrued for Single-Payment frequency in an FAMZ loan (Jira ID: PDRFF-934/ND-5587)

Issue Description

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

Example

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

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

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

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

Expected Behavior

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

Resolution

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

10.39.3 Interest Per Diem on the Payoff Quote should be based on the Principal Balance owing on the day of payout when Pay Future Dues Timely is True (Jira ID: PDRFF-917/ND-5551)

Issue Description

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

Resolution

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

10.39.4 Bank accounts from all customers are available to select from while doing a refund for a reversed LPT (Jira ID: PDRFF-957/ND-5568)

Issue Description

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

Resolution

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

10.40 Issues fixed in CL Common 3.5008.24

10.40.1 EMI calculator performance issues (Jira ID: PD-919)

Issue Description

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

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

Resolution

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

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

10.40.2 The custom version of the internal EMI calculator is unable to come up with a payment amount when there is an additional payment schedule (Jira ID: PD-1009)

Issue Description

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

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

Resolution

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

10.41 Issues fixed in Q2 Loan Servicing 3.5054.120

10.41.1 The system is displaying an incorrect Current Loan Balance on the LTS of Excess Payoff IPT after the final payoff (Jira ID: PDRFF-754/ND-5501)

Issue Description

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

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

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

Example explaining the issue

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

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

Resolution

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

10.42 Issues fixed in Q2 Loan Servicing 3.5054.117

10.42.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.

10.43 Issues fixed in Q2 Loan Servicing 3.5054.113

10.43.1 Inconsistency in the future dated Payoff Quote (Jira ID: PDRFF-896/ND-5466)

Issue Description

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

• Scenario 1: Future Dated Payoff Quote with minimum interest feature enabled If we create a future dated Payoff Quote in a loan that includes the Minimum Interest calculations, the system is incorrectly considering both the minimum interest amount as well as the accrued interest that is calculated from the current system date to the Payoff Quote date if the Payoff Date is within the Minimum Interest Period. Example To understand the issue in this scenario, let us see an example. Let us say that Minimum Interest Period is defined as 180 days.

Now, let's assume the accrual start date is January 1, 2022, and the current system date is also January 1, 2022. Then let us create a Payoff Quote on January 1, 2022, with a future Payoff Date such as January 10, 2022. The system is calculating the Payoff Quote that is including the interest of the 180 days (as per minimum interest configuration) as well as the accrued interest of the 10 days (accrued interest from January 1, 2022, to January 10, 2022).

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

• Scenario 2: Future dated Payoff Quote with interest capitalization of a different frequency than the billing frequency Example To understand the issue in this scenario, let us see an example. Let's assume the current system date January 1, 2022, and the IPT posting and capitalization date is January 5, 2022

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

This means that the system should have capitalized the interest on January 5, 2022, and then the capitalized interest should be added to the Principal Remaining for the Payoff Quote calculation. But the system is not doing this. It is not adding the capitalized interest to the Principal Remaining for the Payoff Quote calculation. Thus, the system is calculating interest on the same initial Principal amount even after the capitalization date for a future dated payoff quote.

Resolution

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

• Scenario 1: Future Dated Payoff Quote with minimum interest feature enabled The system is now calculating the future dated Payoff Quote correctly. It is including only the minimum interest amount (when Minimum Interest Period is defined) when the Payoff Date is within that period.

• Scenario 2: Future dated Payoff Quote with interest capitalization of a different frequency than the billing frequency The future dated payoff quote calculation logic has now been updated such that on every future capitalization day, the system will update the Principal Remaining and then calculate the interest on that updated amount.

10.44 Issues fixed in Q2 Loan Servicing 3.5054.111

10.44.1 Pre-Paid Fees that are not set to be added to the Loan Amount are being added to the Loan Amount (Jira ID: PDRFF-534/ND-5457)

Issue Description

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

Resolution

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

10.44.2 InterestPostingAmzDynamicJob is failing with an error message (Jira ID: PDRFF-828/ND-5413)

Issue Description

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

Resolution

This issue is fixed.

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

10.44.3 Rescheduling on Loan Balance of Interest Only loans with Advance Interest enabled is resulting in a higher bill amount (Jira ID: PDRFF-913/ND-5439)

Issue Description

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

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

Resolution

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

10.45 Issues fixed in Q2 Loan Servicing 3.5054.106

10.45.1 Contract creation via the API is failing when contract has an additional interest component (Jira ID: PDRFF-806/ND-5345)

Issue Description

If a contract that has an additional interest component is created using the createContract API of the LoanActionFactory class, the system is throwing the following exception:

Resolution

This issue is now fixed by updating the logic in the system. Now the system is not throwing any exceptions when trying to create a contract that has the additional interest component using the createContract API of the LoanActionFactory class.

10.45.2 Interest Rate not getting displayed after clicking Validate button on the Rate Change screen (Jira ID: PDRFF-458/ND-5434)

Issue Description

On the Rate Change screen, after providing the values in the Floating Rate Index, Margin Rate, and the Start Date fields, and then clicking Validate, the Interest Rate field is displaying a null value. The new value in the Interest Rate field is only getting displayed after clicking Save. There is no preview of the new Interest Rate unless the rate change transaction record is saved. Once the record is saved, the system is creating a transaction and it is recorded in the customer's Transaction Summary.

Expected Behavior

The new calculated interest must be displayed in the Interest Rate field after clicking the Validate button so that the user can check the new interest rate before saving the data in the system.

Resolution

This issue is now fixed. After clicking Validate, the system is now displaying the updated value in the Interest Rate field.

10.46 Issues fixed in Q2 Loan Servicing 3.5054.103

10.46.1 The system is not allowing backdated waiving of fee and additional interest component (Jira ID: PDRFF-625)

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.

10.47 Issues fixed in Q2 Loan Servicing 3.5054.96

10.47.1 The system is updating the Transaction Date of the LPT to the system date while doing a Deposit to Loan (Jira ID: PDRFF-720/ND-5324)

Issue Description

While doing a Deposit to Loan Transfer and changing the Transaction Date, the system is creating the corresponding LPT with the Transaction Date as the system date instead of the given date.

Example

Let us say that the system date is May 31, 2020.

While doing the Deposit to Loan Transfer, let us change the Transaction Date to May 29, 2020.

Then, the LPT that gets created due to this internal transfer is of the Transaction Date May 31, 2020, instead of May 29, 2020. This updates the LAD to the system date, which affects the interest calculations too.

Resolution

This issue is fixed. Now while doing a Deposit to Loan Transfer and changing the Transaction Date, the system is creating the corresponding LPT with the updated Transaction Date, and not the system date.

10.48 Issues fixed in Q2 Loan Servicing 3.5054.90

10.48.1 Floating Rate Loan Reset Job is throwing an exception if a revolving loan contract is having a zero Loan Amount (Jira ID: PDRFF-587/ND-5254)

Issue Description

If the Floating Rate associated with a revolving, zero- Loan Amount loan is updated through the Submit Reset Process button, then the following exception is thrown by the Floating Rate Loan Reset Job:

“loan.LoanProcessingException: Interest rate change failedCL019410: This loan does not have any remaining principal balance.”

Due to this, the interest rate on other contracts is also not getting updated.

This issue is occurring because the system is internally checking the value in the Principal Remaining field during rescheduling and if it is zero, then the system is throwing the preceding exception.

Resolution

This issue is fixed as the internal check is now only applied for non-revolving loans. Due to this, the system is able to successfully run the Floating Rate Loan Reset Job without throwing any exceptions and the interest rate on other contracts is also getting updated successfully.

10.48.2 The system is not waiving the interest of the additional interest component charged on the delinquent amount (Jira ID: PDRFF-563/ND-5274)

Issue Description

If an additional interest component is created in a loan to charge interest on the delinquent amount, and then such an additional interest is being waived using the Additional Interest Component Waiver type in the Loan Actions, the system is displaying a Waive Amount of zero even though there is an interest accrual on the delinquent amount in the additional interest component.

Resolution

This issue is now fixed. The system now displaying the correct amount as the Waive Amount while waiving the additional interest component on the delinquent amount.

10.48.3 Payment Amount remains the same after using the API to reschedule the loan to update the Repayment Plan (Jira ID: PDRFF-686/ND-5292)

Issue Description

If the rescheduleALoan API is used to reschedule a loan to update the Repayment Plan, the system is not replacing the old repayment plan with the new one while passing the Repayment Plan to the API and hence, even after the rescheduling, the Payment Amount remains the same as the one in the old Repayment Plan.

Resolution

This issue is now fixed as the system is successfully replacing the old Repayment Plan with the new Repayment Plan while passing the Repayment Plan to the rescheduleALoan API.

10.49 Issues fixed in Q2 Loan Servicing 3.5054.84

10.49.1 System is allowing more than one floating rate on the same date for the same Floating Rate Index (Jira ID: ND-4950)

Issue Description

The system is allowing to maintain more than one rate on the same date for the same floating rate index. This means that if we define two floating rates with the same Effective From date, the system is not validating it, and is allowing such a configuration.

Example

Let us say we have defined a Floating Rate Index with the following floating rates:

The system is allowing such a configuration to be saved.

It should not allow this configuration as it cannot be possible to have three rates on the same date.

Resolution

This issue is resolved. Before saving a floating rate configuration for a floating rate index for a particular date, the system is now validating and checking if there is already a floating rate existing on that day. It then displays the following message if it finds a rate already existing on the same date:

“There exists a Floating Rate with effectivity dates overlapping with this rate.”

10.49.2 System is throwing an exception while trying to generate a Payoff Quote (Jira ID: PDRFF-592/ND-5234)

Issue Description

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

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

This issue is occurring due to more than 200 records being processed by the system.

Resolution

The internal logic has now been changed to use FOR loop in the code.

10.49.3 Periodic Fee is not being charged as per the frequency defined in the Periodic Fee Setup (Jira ID: PDRFF-597/ND-5235)

Issue Description

If a periodic fee is added in the Periodic Fee Setup with the charging Frequency as Annual, the system is charging this periodic fee monthly instead of annually.

This issue is occurring because while generating the periodic charges, the internal logic is considering the loan contract’s frequency as the charging frequency instead of the specified frequency in the Periodic Fee Setup.

Example

Let us say the following periodic fee is added in the Periodic Fee Setup:

Charges are created as follows in the system:

Resolution

This issue is resolved as the system is now considering the specified frequency in the Periodic Fee Setup as the charging frequency, and thus the system is charging the periodic fee at the correct frequency that is specified in the Periodic Fee Setup.

10.50 Issues fixed in Q2 Loan Servicing 3.5054.81

10.50.1 The system is throwing an exception while reversing LPT “Aggregate query has too many rows for direct assignment, use For loop” (Jira ID: ND-5268/PDRFF-607)

Issue Description

While carrying out the reversal of an LPT, the system is throwing the following exception:

This is because, to carry out the payment reversal, all the bills of the contract are queried as child records. Even though the queried child records count is less than 200, the exception is observed because of the size of the child record set that is retrieved.

Hence, whenever we are trying to assign these retrieved child records that are more than 200 or a record set of such size, the "Aggregate query has too many rows for direct assignment, use FOR loop" exception is thrown.

Resolution

This issue is fixed as the existing logic is changed by using the For loop as suggested by Salesforce. The system will not throw an exception while reversing the LPT even if there are more than 200 child records or the record set size is huge.

Now, the system will not assign the retrieved child record to a list directly (List<loan__Loan_Payment_Transaction__c> lpts = lacc.loan__loan_payment_transactions__r;). It will iterate the child records in a for loop and then assign them to a new list.

10.51 Issues fixed in Q2 Loan Servicing 3.5054.80

10.51.1 Not able to create loan disbursals (Jira ID: ND-5255)

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 condition in the queries to filter the records correctly:

• Adding a Where clause to the query to filter the records by the ID. Only those contracts whose record id matches with Source_Record_ID__c, are getting fetched. For those contracts, where Source_Record_ID__c is NULL, the method to query records will not be called.

Thus, the fix helps in preventing the code from always querying without a Where clause, which, hence, helps in not querying the entire database.

10.52 Issues fixed in Q2 Loan Servicing 3.5054.76

10.52.1 Periodic fees are getting charged incorrectly after the February month cycle (Jira ID: PDRFF-477/ND-5189)

Issue Description

When a periodic fee is charged in a loan that has the due day for the payment defined as 30 of every month, then on encountering the month of February, the system correctly considers the due date as February 28, but after that, the system considers the due date as 28 for all the other months.

Resolution

The logic to calculate the Next Recurring Fee Date is now corrected. Earlier the system was calculating the Next Recurring Fee Date by looking at the Next Recurring Fee Date’s day. Now this logic has been updated to consider the Next Recurring Fee Date to be calculated using the Due Day defined in the loan contract. This ensures that the periodic fees are now correctly charged on the correct date of all months.

10.53 Issues fixed in Q2 Loan Servicing 3.5054.73

10.53.1 System is throwing an exception while reversing the latest LPT if there are more than 200 LPTs already existing in the system (Jira ID: PDRFF-607)

Issue Description

If the system has more than 200 LPTs created in the system, and then if you try to reverse the latest LPT, the system is throwing the following exception: “Aggregate query has too many rows for direct assignment, use FOR loop."

Resolution

This issue is fixed as the existing logic is changed by using the For loop as suggested by Salesforce. Now the system will not throw an exception while reversing the latest LPT even if there are more than 200 LPTs existing in the system.

10.54 Issues fixed in Q2 Loan Servicing 3.5054.70

10.54.1 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:

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.

10.55 Issues fixed in CL Common 3.5008.14 and Q2 Loan Servicing 3.5054.70

10.55.1 Errors in a loan with Semi-Monthly-PD Payment Frequency (Jira ID: ND-5133/PDRFF-353)

Issue Description

The following issues are observed in loans with Semi-Monthly-PD Payment Frequency:

• If a loan with Semi-Monthly-PD Payment Frequency is created or rescheduled by giving different Second Payment Date and Second Due Day, then the system is displaying an error message. For example, if the Second Payment Date is specified as August 15, 2021, and the Second Payment Due Day is specified as 14, then the system displays the following error: “Due Day provided should not differ from payment date unless it is month-end.”

• The rescheduleALoan API is not considering the new value passed in the parameter for the Second Payment Date, and hence the value remains the same as the one before the API was used. Thus, the loan and the amortization schedules display an incorrect due date.

Resolution

These issues are fixed and now the amortization schedules are generating correctly without errors.

10.56 Issues fixed in Q2 Loan Servicing 3.5054.66

10.56.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.

• Exception 3: INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST, Field Name: bad value for restricted picklist field: clcommon__Collateral__c.Address_Geolocation__Latitude__s: [Field]

  Reason: This exception is due to the Address_Geolocation__Latitude__s being a custom field

Resolution

This issue is fixed as per the following resolution for the preceding respective exceptions:

• For Exception 1: Objects are now divided into chunks so that each chunk is processed at a time. When one chunk is processed, new instance of this job is initiated to process remaining chunks. The chunk size can be altered. Changing batch size is optional. If you need to reduce time, you can create a custom DAG job, name it as required, then add a job record under it with class name, loan.MarkFieldsAccessibleJob, and then specify batch size there.

• For Exception 2: Job is automatically retried three times to try adding permissions to objects or fields that have failed. At the end of the third retry, failed objects or fields permissions are logged in loan__Batch_Process_Log__c. Such permissions will need to be handled manually.

• For Exception 3: Only managed fields will be considered by the job.

10.56.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.

10.57 Issues fixed in Q2 Loan Servicing 3.5054.62

10.57.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.

10.57.2 Investor Payout Job is failing due to an unknown exception (Jira ID: ND-5036)

Issue Description

On running the Investor Payout Job in an FIT loan that has an additional interest component, the job is failing with an unknown exception.

Resolution

This issue is fixed.

10.58 Issues fixed in Q2 Loan Servicing 3.5054.61

10.58.1 System is not updating the Amortization Schedule when the Repayment Plan is updated in an Advance Interest-enabled loan (Jira ID: ND-4943)

Issue Description

When an Advance Interest-enabled loan is rescheduled to delete the existing Repayment Plan and add a new one, the system is not updating the Amortization Schedule to extend the duration of the loan.

Resolution

This issue is fixed as the system is now updating the Amortization Schedule when an existing Repayment Plan is cleared and a new one is added.

10.59 Issues fixed in Q2 Loan Servicing 3.5054.58

10.59.1 Custom Additional Interest Component is calculating interest incorrectly (Jira ID: ND-5032)

Issue Description

When a loan has a periodic charge with capitalization enabled, the Custom Additional Interest Component is not calculating the interest correctly.

Resolution

This issue is fixed.

10.59.2 Interest Posted is calculated incorrectly for loans with interest charged in advance and capitalized (Jira ID: ND-4986)

Issue Description

During the Interest Only period of a loan in which the interest is charged in advance and capitalization is enabled, the Interest Posted amount is calculated using the value in the Principal Advanced/Remaining field instead of the value in the Loan Balance field.

Resolution

This issue is fixed as the system is now using the Loan Balance to calculate the

10.59.3 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.

10.60 Issues fixed in Q2 Loan Servicing 3.5054.55

10.60.1 Interest Posting Job is failing with STRING_TOO_LONG error (Jira ID: ND-4970)

Issue Description

While the system was running the Interest Posting Job, the snapshot for Interest Posting Transaction Snapshot field contained more than 255 characters due to which the job failed with the following error:

Resolution

This issue is fixed as few fields were removed in the snapshot to reduce the size of the snapshot.

10.60.2 System is throwing a NullPointerException while funding a contract with Advance Interest enabled AIC from a Marketplace application (Jira ID: ND-4436)

Issue Description

While funding a contract manually from a Marketplace application by clearing the LDT manually with Advance Interest flag enabled on the Additional Interest Component, the system is throwing a NullPointerException.

If the Advance Interest flag is enabled, the system tries to create IPT for Additional Interest while manually clearing the LDT. During IPT creation, Interest Posting Day is to be updated from Next Interest Posting Date, which is blank before the funding, and thus the system throws a NullPointerException resulting in a failure in posting the IPT.

Resolution

This issue is fixed as now the system is not throwing the exception and the Interest Posting is successful when LDT is cleared manually.

10.60.3 Investment Order is getting updated before LDT clearance in a revolving loan (Jira ID: ND-4590)

Issue Description

In a revolving loan where Loan Disbursal flag in the Transaction Approval Config is enabled, on disbursing and before clearing the LDT, the system is updating the Investment Amount and Share % on the IOs. Then on clearing the LDT after approval, the system is updating the Investment Amount again and updates the Share% to zero.

Resolution

This issue is fixed as now the Investment Order is getting updated correctly after clearing the LDT after the approval.

10.60.4 System is updating an incorrect Next Due Date on FIT contracts for Interest Only periods with Advance Interest enabled for backdated disbursals (Jira ID: ND-5024)

Issue Description

When a backdated disbursal is made in an FIT loan for an Interest Only period with Advance Interest flag enabled, the Next Due Date and the Next Due Generation date for the Repayment Schedule are incorrectly set to the Next Interest Posting Date.

Resolution

This issue is fixed as now the schedule is correctly getting generated at the first unreversed and non-discarded Interest Posting Date, which is the Last Interest Posting Date, when a backdated disbursal is done in FIT loans for the Interest Only period and Advance Interest enabled.

10.61 Issues fixed in Q2 Loan Servicing 3.5054.50

10.61.1 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.

10.61.2 Interest is calculated incorrectly in IO (Jira ID: ND-4702)

Issue Description

For loans with Investment Order (IO), the Investment 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.

10.62 Issues fixed in CL Common 3.5008.12

10.62.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.

10.63 Issues fixed in Q2 Loan Servicing 3.5054.47

10.63.1 Accrued interest is not getting posted on a Flexible AMZ loan (Jira ID: ND-4833)

Issue Description

When an FAMZ loan is disbursed, the InterestPostingAmzJob is failing with the following error: “First error: Apex heap size too large” due to too many repayment schedules being fetched by the job. This is resulting in accrued interest not getting posted.

Resolution

This issue is fixed as the query is now updated.

10.63.2 Disbursal is failing for a non-FIT loan when Create Summaries is enabled and Payment Start Date is the same as the Expected Disbursal Date (Jira ID: ND-4981)

Issue Description

When trying to disburse a non-FIT loan that has Create Summaries enabled and has the Payment Start Date same as the Expected Disbursal Date, the system is unable to create transaction summaries due to a null value in the Loan Balance field, and hence the disbursal is failing with the following error message: “Rolling back the batch. Message - Attempt to de-reference a null object - Cause null-421.”

Resolution

This issue is fixed.

10.63.3 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.

10.63.4 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.

10.63.5 After a disbursement is rejected, the next disbursement transaction is failing with a NullPointerException (Jira ID: ND-4855)

Issue Description

On rejecting a disbursal, the Contract Date is getting set to null, and after that, if another disbursal is tried, the system is throwing a NullPointerException.

Resolution

This issue is fixed as the Contract Date is now not getting set to null after rejecting a disbursal.

10.64 Issues fixed in CL Common 3.5008.11

10.64.1 DAG jobs are failing with an error (Jira ID: ND-4901)

Issue Description

On running the DAG that icludes BillingIOADynamicJob and LoanPaymentTransactionCreationDynamicJob, the jobs are failing with the following error:

Resolution

This issue is fixed.

10.65 Issues fixed in Q2 Loan Servicing 3.5054.39 / CL Common 3.5008.9

10.65.1 Interest Only Period payments schedule is not calculating the rounding error (Jira ID: ND-3001)

Issue Description

In the Interest Only Period of the amortization schedule of a loan with Actual Interest Only Payments enabled, the Interest Rounding Error field is displaying a zero value.

Resolution

This is fixed as now the Interest Rounding Error field is displaying a correct value.

10.66 Issues fixed in Q2 Loan Servicing 3.5054.39

10.66.1 Interest Rounding Error field is displaying a zero value (Jira ID: ND-4922)

Issue Description

If a payment is made for a capitalized charge in a loan contract, the system is displaying a zero value in the Interest Rounding Error field.

Resolution

This issue is fixed.

10.67 Issues fixed in CL Common 3.5008.9

10.67.1 Interest Rounding Error field is displaying zero for Advance Interest-enabled loans (Jira ID: ND-4923)

Issue Description

In loans where Advance Interest is enabled, the system is displaying a zero value in the Interest Rounding Error field in the Interest Only Period of an amortization schedule.

Resolution

This issue is fixed as the system is now displaying the correct value in the Interest Rounding Error field.

10.68 Issues fixed in Q2 Loan Servicing 3.5054.33

10.68.1 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.

10.68.2 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.

10.69 Issues fixed in Q2 Loan Servicing 3.5054.36

10.69.1 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.

10.70 Issues fixed in Q2 Loan Servicing 3.5054.33

10.70.1 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.

10.70.2 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.

10.71 Issues fixed in Q2 Loan Servicing 3.5054.32

10.71.1 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.

10.71.2 Future-dated payoff quote for a Single 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.

10.72 Issues fixed in Q2 Marketplace 3.5003.2

10.72.1 Price Per Share value in IO 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 IO 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.

10.73 Issues fixed in Q2 Loan Servicing 3.5054.21

10.73.1 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.

10.73.2 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.

10.73.3 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.

10.73.4 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.

10.74 Issues fixed in Q2 Loan Servicing 3.5054.12

10.74.1 Creation of backdated payments is not regenerating IPT (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.

10.74.2 Interest is calculated incorrectly in IO (Jira ID: ND-4702)

Issue Description

For loans with Investment Order (IO), the Investment 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.

10.74.3 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.

10.74.4 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.

These steps ensure that you do not have to scroll and the tab names that you provide in the Custom Tabs text box are not displayed on the CL Contract page.

10.74.5 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.

10.75 Issues fixed in CL Common 3.5008.3/Q2 Loan Servicing 3.5054.10

10.75.1 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.

10.76 Issues fixed in Q2 Loan Servicing 3.5054.10

10.76.1 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.

10.76.2 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 SOQL 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.

10.77 Issues fixed in Q2 Loan Servicing 3.5054.5

10.77.1 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.

10.77.2 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.

10.78 Issues fixed in Q2 Loan Servicing 3.5054.4

10.78.1 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.

10.79 Issues fixed in Q2 Marketplace 3.5003.1

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

Issue Description

In the CL 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.

11.   Change Record