Spring 2022 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 **Set in Target**, **Set in Target** 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 **Set in Target****Set in Target** version (**Set in Target**) 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 **Set in Target** release:

• Installation Information

• Upgrade Considerations

• System Performance

• New Features and Enhancements

• Fixed Issues

• Known Issues

• New and Modified Objects

• New and Modified APIs

• Global Methods

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

2.   Introduction

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

3.   Installation Information

Contact your Q2 Professional Services team or the Customer Success team for information on the package dependency and installation order of the packages required to install and set up the latest version of **Set in Target**.

4.   Upgrade Considerations

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

5.   System Performance

To view the batch jobs performance statistics for **Set in Target** without customizations under test conditions, see the Q2 Performance Benchmarking Guide.

6.   New Features and Enhancements

This section briefly describes the new features and enhancements added in the **Set in Target** release of **Set in Target**.

6.1 Balloon Payment

6.1.1 Balloon Payment calculation with Balloon Type (Jira ID: ND-4640/PD-935)

Enhancement Description

Prior to the Spring’22 release, The Financial Calculator considered the Balloon payment as the final payout amount on the loan at the maturity of the loan, which included interest amount accrued in the last payment term and the last remaining principal

For example, If you would have booked a loan contract of $100K with balloon amount of $10K for a tenor of 12 months, on the last payment term, you would have paid and EMI of 10K total which would look like somewhat, lets say $500 towards interest and $9500 towards principal.

With Spring’22 you would be able to define only the principal remaining amount as Balloon.

This means if we take the example of above mentioned loan parameters, it corresponds to the extra Principal of $10K that the user should pay as part of the final payment over and above the EMI that is due for that term.

A new field named the Balloon Type has been introduced to select the type of balloon payment you would like to make. The following are the two types of balloon payment that you can see in the Balloon Type field:

• Balloon Amount Including Principal and Interest

• Balloon Amount Including Only Principal

6.2 APS Enhancements for Amount Type

6.2.1 Direct debit on the last bill balance amount (Jira ID: PDRFF-709/ND-5310)

Enhancement Description

When the Payment Application Method is Future Dues, the bill maybe partially satisfied by the amount in the Reserve Amount Next Due. For this, the direct debit that is generated for that day should be equal to the balance remaining on the bill and not the whole balance. If there is no due on the bill, then payments should not be generated, and the system should move the debit date to the next debit date. The Q2 Loan Servicing has now been enhanced to accommodate such a requirement.

Before the Spring’22 release, the Amount Type picklist of the Automated Payment Setup page consisted of the following values:

• FIXED AMOUNT

• LAST BILLED AMOUNT

• CURRENT PAYMENT AMOUNT

• OLDEST UNPAID BILL AMOUNT

• TOTAL OUTSTANDING BILL AMOUNT

With the Spring'22 release of Q2 Loan Servicing, an additional value has been added to the Amount Type picklist field of the Automated Payment Setup page. This additional value is Last Bill Balance Amount.

If this value is selected, the system considers the pending or the remaining amount to be paid from the latest bill. This means that the system creates an LPT for the amount that is pending from the last bill amount, and then pays it as per the payment spread defined toward the oldest unpaid bill amount.

6.2.2 Ability to provide any type of amount for LPT in APS by the custom code (Jira ID: PDRFF-647/ND-5312)

Enhancement Description

Earlier, you could only set up the automated payment for the amount types listed in the Amount Type field. However, there was a requirement to create APS for amounts that included certain fees that have been created in the current billing cycle.

For example, if the following are the scheduled dates:

• January 5

• February 5

• March 5

Let us say that a periodic charge is created on February 25, which needs to be included in the amount that the LPT is created for. But, before the Spring’22 release, there was no option in the Amount Type field to include such an amount.

With the Spring’22 release, a new option named Custom is provided in the Amount Type field of the Automated Payment Setup so that any type of amount for the LPT can be specified by the custom code.

With the preceding feature, the new list of Amount Types available on the Automated Payment Setup page are as follows:

• FIXED AMOUNT

• LAST BILLED AMOUNT

• CURRENT PAYMENT AMOUNT

• OLDEST UNPAID BILL AMOUNT

• TOTAL OUTSTANDING BILL AMOUNT

• LAST BILL BALANCE AMOUNT

• CUSTOM

6.3 Holiday Treatment Setup/Business Hours

6.3.1 Interest Capitalization Posting on Business Days only (Jira ID: PDRFF-325/ND-5312)

Enhancement Description

It is a standard practice in some of the commercial lending markets to post interest capitalizations only on business days. So, if the capitalization is enabled in a loan and if the interest posting date falls on a non-working day, the system must move it to post it on a previous or the next working day.

For example, in a capitalization-enabled loan, say the holiday treatment is defined such that the interest posting date is to be moved to a previous date (Schedule Adjustment Method = Before) in case of a holiday and the interest posting frequency is monthly with the due date on every month as 25.

Let us say that for a particular month, the 25th day turns out to be a holiday. In this case, the system should automatically post the interest on the immediate previous working day, which can be the 24th or the 23rd whichever is a working day.

To incorporate such a requirement, with the Spring’22 release, the Q2 Loan Servicing has been enhanced to post the interest capitalizations on business days only. This can be done by configuring the Holiday Treatment Setup for the Interest Capitalization Posting. This enhancement includes the postings of the additional interest capitalization of Master Facility loans too to occur on business days only.

Before the Platinum patch (3.2019.115) release of Q2 Loan Servicing, the system was not posting the regular interest and additional interest capitalization on business days when they were falling on a holiday if the regular interest and additional interest frequencies were Billing Frequency. With this enhancement, if the Holiday Treatment Setup is configured for Interest Capitalization Posting, the system is posting the interest capitalization for regular and additional interest on business days for all frequencies when both the regular interest and additional interest are posted at the same frequency.

This means that if the Holiday Treatment Setup is not configured for the Interest Capitalization Posting, then even if there are Business Hours applied to the loan, the Next Interest Posting Date will not be updated to a working day if it falls on a holiday when interest and the additional interest are posted at the Billing Frequency.

Important Information:

Only if the regular interest and the additional interest posting frequencies are the same and Holiday Treatment Setup is configured for the Interest Capitalization Posting, the system will post the interest capitalizations for both regular and additional interest on business days at all frequencies.

What this means is that, for a capitalization-enabled loan, even when the Holiday Treatment Setup is configured for the Interest Capitalization Posting, if the regular loan interest posting is monthly and the additional interest posting frequency is quarterly, then the system will not apply the holiday treatment to the interest postings, which means that the system will not post the regular interest and additional interest on a business day if their posting dates fall on a holiday. In such cases, the system will throw an error message saying, "Allowed for same frequency of Loan and AIC with Holiday Treatment enabled."

However, for a capitalization-enabled loan, when the Holiday Treatment Setup is configured for the Interest Capitalization Posting, if the regular interest posting frequency is monthly and the additional interest posting frequency is also monthly, then the system will successfully apply the holiday treatment to both the interest postings, which means that the system will post the regular interest and additional interest on a business day if their posting dates fall on a holiday.

6.3.2 Business days applied to APS payment creation and clearing (Jira ID: PDRFF-816/PDRFF-821/ND-5376)

Enhancement Description

With the Spring'22 release, if you want the Days in Advance To Create File and Lock Period for ACH payment creation and clearing respectively to consider only the business days or working days, then you need to create the default Business Hours with the name BANK.

i. For Days in Advance To Create File for APS payment creation

Action to be taken:

The LPT for Automatic Payment Setup must get created after considering working days only when Days in Advance To Create File is defined. To ensure this, when you create the Business Hours in the Setup, you must create it in the name of BANK.

Reason:

The system requires that you create the Business Hours in the name of BANK. This will ensure that all customers follow one Business Hours named BANK and the ACH can follow the BANK Business Hours to consider only working days for the payment creation. If the Business Hours are not created with the name BANK, the ACH will consider it as normal calendar days to create the payment creation.

ii. For Lock Period for APS payment clearing

Action to be taken:

The LPT for Automatic Payment Setup must get cleared after considering working days only when the Lock Period is defined. To ensure this, when you create the Business Hours in the Setup, you must create it in the name of BANK.

Reason:

This is because, for some customers, the system needs the Business Hours named the same as the name of their Payment Mode. For example, some customers may name their Business Hours as ACH for ACH Payment Mode, Credit Note for Credit Note Payment Mode, and so on. If a customer has named their Business Hours as ACH for ACH Payment Mode, and if the system does not find the name ACH for the Business Hours for another customer, then the system will consider the calendar days instead of considering business days only. Thus, for considering working days only, if the system does not find the Business Hours with the required name, it will use all calendar days and not just working days.

6.4 Manage excess amount

6.4.1 Manage excess amount: Refund or Reduce Principal Remaining (Jira ID: PDRFF-710/ND-2624/ND-5309)

Enhancement Description

Before the Spring '22 Release:

Earlier, if you pay an excess amount, or, if the repayment amount is more than the outstanding Loan Balance at any time in the duration of the loan, then, to refund this excess amount, on clicking Refund at a time when the loan is closed, the system was throwing the following exception:

“You can refund only against a loan with status - Closed.”

In other words, you were not able to refund until the loan was closed.

Reason for allowing refund before the loan closes:

However, there are times when a borrower may pay an excess amount any time while the loan is active. In such scenarios, the business may need to refund the excess amount to the borrower whenever there is an additional (more than the loan balance outstanding) repayment on the loan account. Earlier, the system would not allow you to refund this amount when the loan is not closed. It would only allow refunding once the loan has been closed and the loan contract status was set to Closed - Obligations Met.

Expected behavior:

The system must be able to refund the excess amount without closing the loan account; a loan must close after the loan balance is fully paid off and the mortgage is discharged, and the loan closure must be the last step of the whole process.

Spring '22 release onward:

With the Spring '22 release, this expectation is met as the system is now enhanced to perform a partial refund on the loan too. Now if an excess payment is made and if you try to refund a loan that is not closed, the system successfully processes such a refund for the borrower.

On the Excess Adjustment page, in the Refund Actions section, the following two new checkboxes have been added:

• Refund to Borrower The amount can now be refunded to the borrower even before the loan closes. On refunding the excess to the borrower, the amount from the Excess field goes to the borrower, the value in the Excess field becomes zero, and an OLT of the type Refund is created.

• Reduce Principal Remaining While adjusting the excess amount, if the user selects Reduce Principal Remaining, an LPT of the payment type Refund is created of the required amount with the Payment Mode as Excess and the refunded transaction amount is moved toward principal reducing the Principal Remaining satisfying the future dues, and considering the payment spread of the loan account. Note: The flag Reduce Principal Remaining is visible only when there is some Principal Remaining left on the contract to be able to reduce it to adjust the excess amount toward satisfying the dues.

Thus, Q2 Loan Servicing has the ability to move the funds that are in excess to either the loan account or refund them back to the customer (borrower).

6.5 Minimum Interest Amount enhancement

6.5.1 Additional Interest Component can be included in Minimum Interest Amount when it's based on Minimum Interest Period (Jira ID: PDRFF-731/ND-5356)

Enhancement Description

With the Spring'22 release, Q2 Loan Servicing has been enhanced to add the option of including the Additional Interest Component (AIC) while calculating the Minimum Interest Amount if:

• The Minimum Interest Period is defined and

• The Interest Bearing Principal for Additional Interest Component is "Credit Limit".

To include AIC within the Minimum Interest Amount calculation, a flag has been introduced on the Interest Component page. This flag is: "Include AIC in Minimum Interest Amount".

If this flag is set to true, the system includes the additional interest together with the regular interest in the Minimum Interest Amount calculation. If the payoff is made within the Minimum Interest Period, a charge will get created with amount = Minimum Interest Amount - (Interest Paid + Additional Interest Paid)

What this means is that when a disbursal is made, the system calculates the Minimum Interest Amount by including both the regular and the additional interest for that period. Thus, while disbursing, the system calculates the Minimum Interest Amount by including both the regular interest and the Additional Interest amounts for that period.

Thus, Minimum Interest Amount = Regular interest for that period + Additional Interest for that period.

Also, when a disbursal is made, the system immediately calculates the Payoff including the Minimum Interest Amount that has both the regular and AIC in its calculation.

7.   Fixed Issues

This section describes the issues fixed in the Spring’22 release of Q2 Loan Servicing and Q2 Marketplace.

7.1 Bills are getting satisfied for Interest Only loans when the borrower is making a backdated part principal payment (Jira ID: ND-5190)

Issue Description

For an interest only loan (the bill/due amount includes only the interest), when a backdated part payment is made during the interest only period, the future bills are also getting satisfied, and the Primary flag becomes True. If the transaction amount is less than the due amount, the bill is partially satisfied and when the transaction amount is greater than or equal to the due amount, the bill is fully satisfied. Since the bill is for an interest only period, the due amount is only the interest component. This interest component changes after the backdated payment since the principal amount is adjusted, and hence the expected behavior is that bills should also be regenerated along with Interest Posting Transactions.

For example, a simple loan of amount $10,000 is created and disbursed on March 31 with the Payment Application mode as Future Dues. On April 30, a bill is generated for the interest posted amount that is $83.33. Let us say the borrower wants to make a payment of $83.33 on April 29. After making the payment, the bill is marked as satisfied and primary.

Resolution

This issue is fixed. Now, any payment made in the interest only period will not satisfy the future existing bill. The existing bill is discarded, and a new bill is generated for the new IPT amount for interest only period.

For all the payments with the Payment Application mode as Current Dues irrespective of the interest only period, it will not satisfy the future bills.

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

7.3 The system is unable to payout LPTs with IOA amount to investors (Jira ID: ND-5262/PDRFF-585)

Issue Description

In a Flexible AMZ loan with an investment order, if there is an IOA defined on the Investors side when an LPT is created for the IOA amount, on running the Investor Payout Job, the LPT amount is not paid out to the investor.

Log:

• LPT not paid out to investor: LPT-000000108

• Loan a7w5e000000gbYKAAY removed

This is because the system was not checking for the IOA amount while running the Investor Payout Job. If Principal, Interest, and Fees are zero, the system was not generating ILTID.

For example, let us say that a FAMZ loan is created with IOA defined on Investor on March 1.

Resolution

This issue is fixed. Now the system will check for the IOA amount. If the IOA amount is greater than zero, the LPT will be considered for Investor Payout and the IOA amount will be paid out in the following scenarios:

• LPT has only IOA amount

• LPT has Principal, Interest, Fees along with the IOA amount

On running the Investor Payout Job,

• An ILTID will be created with a transaction amount equal to the LPT amount, and the IOA Amount will be paid out to the Investor.

• IOA Amount Paid on IO will be updated with the correct amount.

• LPT will be marked as 'Paid To Investor’

7.4 Payoff amount discrepancy (Jira ID: ND-5269/PDRFF-595)

Issue Description

For a loan, after reversing a payoff transaction, the Interest Remaining calculated on the contract is more resulting in a discrepancy in the payoff amount.

This is because the Payoff reversal is not considering the correct principal paid amount from the snapshot. Due to this, interest remaining is getting updated incorrectly. So, for a subsequent payoff on a later date but backdated to the same date as the first payoff transaction, is satisfying this incorrect interest.

For example, a FAMZ loan is created and disbursed.

Resolution

Snapshot value is taken correctly for principal paid and hence interest remaining is updated correctly after payoff LPT reversal. The payoff screen is recalculating the payoff amount when the transaction date is changed.

7.5 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: "Aggregate query has too many rows for direct assignment, use FOR loop".

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.

7.6 Multiple excess LPTs are created due to previous uncleared payment transactions (Jira ID: ND-5270/PDRFF-656)

Issue Description

The Excess LPTs are created when there is some amount remaining in the Excess field and there is an unpaid bill in the system.

For example, let's assume the following contract is created:

The expected behavior is that the ExcessForAMZbasedLoans Job should not generate the Excess LPTs till there is an uncleared LPT present in the system.

Resolution

This issue is fixed. Now, the ExcessForAMZbasedLoans Job will create LPTs only for the difference of Unpaid Bills and Uncleared Payments. Also, the LPT amount should not exceed the Excess amount present on the contract.

For example,

7.7 Backdated payment transaction with backdated payoff quote amount is being considered as excess (Jira ID: PDRFF-658/ND-5282)

Issue Description

This issue is occurring in scenarios where a backdated payoff quote is present in the system, and you are doing a backdated payment as a backdated payoff with that quote amount.

The issue is that if there is a backdated payoff quote present in the system and if you then create a backdated payment with that quote amount, system is not considering it as a backdated payoff, but rather considering it as an excess amount.

In this case, since the payment is made as a regular payment and not by using the Loan Pay Off menu, to be able to consider it as a payoff, the system is expecting a payoff amount as per the current system date, but the actual backdated payment amount is less than the current payoff quote, which is why the system is considering this backdated payment as an excess and not as a backdated payoff amount.

Example

Let’s assume the following actions:

As seen in the above example, the system considers the backdated payment of $5,000 made as on March 10 as excess. This is because it is expecting a payment of $6,000 to be considered as payoff and $5,000 is less than that.

Resolution

This issue is now resolved, and now if a backdated payment of the backdated payoff amount (as of the same date) is made, then the system is not considering it as excess and is considering the loan as paid off as on that date.

7.8 Multiple excess LPTs created due to earlier uncleared payment transactions (Jira ID: PDRFF-675/ND-5284)

Issue Description

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

Example

Let’s assume the following FAMZ contract is created:

Resolution

To resolve this issue, before creating an excess LPT, the system should check the earlier uncleared excess LPTs. It should create a new excess LPT only if the excess paid is more than the total amount in all earlier uncleared excess LPTs.

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

This issue is now resolved as the system does not create new excess LPTs if it exceeds the excess amount.

7.9 Amount To Current is reducing incorrectly after making the LPT payment when Include in Dues on fee is true (Jira ID: PDRFF-396/ND-5107)

Issue Description

After making a payment in a loan where Include in Dues flag is enabled for the fee, the formula field, Amount To Current, is displaying an incorrect value.

Amount Due Till Current is the sum of delinquent amount and unpaid fee.

If Include In Dues flag is enabled at the fee level for a charge, then it's considered as part of the bill. But as we are adding it again as unpaid fee, the Amount Due Till Current is displaying a higher value than expected.

Example

Let us say we have a loan contract with the following configurations:

• Add Fee Amount To Bill = False (at the Contract Level)

• Include in Dues = True (at the Fee level)

• Status of the contract = Active-Bad Standing with the following IPT, Bill, and Charges

  • IPT = $58.33

  • Bill = $865.27 (Principal = $806.94, and Interest = $58.33)

  • Charges = $200

This results in the following:

• Delinquent Amount = $865.27

• Amount Due Till Current = $1065.27 (Delinquent Amount + Unpaid Charges)

Now if we make a payment (LPT) of $220, then $200 is accounted for charges and $20 is accounted for Interest.

The system then behaves as follows:

As the Include in Dues flag is true at the Fee level, the system considers charges to already be included in the bill, that is in $865.27, and the system deducts ($200 + $20) from the delinquent amount resulting in:

$865.27 - $200 - $20 = $645.27.

Thus, Amount Due Till Current = $645.27 + 0 (as charges are paid) = $645.27.

Due to this, the difference between Amount Due Till Current before and after Payment (LPT) appears to be $420 ($1065.27 – $645.27) even though the payment was only $220.

Resolution

This issue is fixed by updating the logic in such a way that if Include in Dues flag is true, then the Amount Due Till Current is not including the charges before the payment.

Thus, referring to the preceding example, now the Amount Due Till Current before the payment is calculated as follows: $865.27 (not adding $200 to it.)

7.10 Issue with the clearance of charge when the charge is part of a bill and schedule (Jira ID: PDRFF-525/ND-5240)

Issue Description

In a simple loan contract where the Include in Dues and Include in Schedules is enabled for the Periodic Fee, if the Periodic Fee accrual date is before the billing date and if the customer pays the bill amount on the charge due date before the bill gets generated, then the charge gets paid and when the bill gets generated later it gets underpaid by the periodic charge amount.

Example

Let's assume there is a loan contract with payment frequency as monthly and where the periodic fee is getting accrued on first of the month and the bill is getting due on the fifth of the month.

Let us assume the following:

• Charge accrual date = January 1

• Bill due date = January 5

• Charge = $10

• Bill amount is $100.

Say if we pay $100 on January 1, then the amount should go to the Reserve Amount Not Due as it is not yet the Due Date, and then on due date, the system should automatically take the $100 and satisfy the bill. However, this is not how the system is behaving. What the system does is, it only moves the $90 to the Reserve Amount Not Due, and then on the due date, the bill is satisfied for only $90, and the remaining $10 is still remaining as due.

Resolution

This issue is fixed and now the system is correctly clearing the charges, the bill gets paid, and the loan is not becoming delinquent too.

This issue is fixed when Periodic Fee Amount Type is Per-Period Amount. If the Periodic Fee Amount Type is Total amount or null, the system displays the following error message if the start date of the Periodic Fee is different from the Due Date:

“Start date cannot be modified for Periodic Fee Amount type - Total Amount or Null.”

7.11 Default value of the Second Due Day is set to 0 (Jira ID: ND-5204)

Issue Description

While creating a loan contract, the system is setting the default value of the Second Due Day to 0. This is causing the system to behave incorrectly.

But, because the default value of Second Due Day is set to 0, as it already has a value assigned to it, the system is not updating its value to the Second Payment Date resulting in incorrect calculations and incorrect Next Due Date of the cycles in the schedules.

Resolution

This issue is now resolved as the default value is now removed for the Second Due Day, and hence it is, by default, set to null. Now the system is behaving correctly and setting the Next Due Date correctly in the schedules.

Now if nothing is specified in the Second Due Day, which means it is null, the system is updating its value to the Second Payment Date resulting in correct payment due dates for the schedules.

7.12 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.”

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

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

7.15 Generation of the Repayment Schedule is failing if the disbursed amount is less than Balloon Payment amount (Jira ID: PDRFF-517/ND-5263)

Issue Description

While creating a simple loan contract where Balloon Payment is specified, if a disbursement of less than the Balloon Payment is made, then the status of the contract changes to Active – Good Standing, but the Repayment Schedule is not getting generated.

This is because the internal calculator used by Q2 Loan Servicing is not able to generate a schedule when the payment expected in the Balloon Payment amount is more than the amount that is disbursed as the principal to be paid, which in this case is the Balloon Payment, cannot be more than what is disbursed.

Example

Say if a loan contract is created with the following details:

• Loan Amount = $10,000

• Balloon Payment = $5,000

• Disbursed amount = $1,000

Then the system is not generating the Repayment Schedule, as the disbursed amount of $1,000 is less than the Balloon Payment of $5,000.

Resolution

To resolve this, the Balloon payment amount that the internal calculator has to use is prorated to the ratio of total loan amount disbursed to the total Loan Amount of the contract.

This means that the system is now calculating the balloon payment for the last schedule as follows:

Balloon payment for the last schedule = (total disbursed amount/total Loan Amount) * Balloon Payment amount on the contract.

Considering the preceding example, the balloon payment for the last schedule will be calculated as follows = (1,000/10,000) * 5,000 = $500.

So, in the repayment schedules, the balloon payment will be as per the amount disbursed, and so, only on full disbursal, the complete balloon payment will be considered to calculate the expected payment amount in the schedules.

Hence, when a full disbursal is made, the balloon payment for the last schedule is calculated as follows = (10,000/10,000) * 5,000 = $5,000.

7.16 System is not allowing backdated waiving of fee and additional interest component (Jira ID: PDRFF-586/ND-5277)

Issue Description

Backdated waiving of fee and additional interest component is one of the actions that is required for various scenarios related to accrual in Q2 Loan Servicing. However, the system is not capable of allowing that. The Transaction Date field on the UI for waiving charge and additional interest component is not editable and hence you cannot specify a backdated date for waiving of fee and additional interest component respectively.

Resolution

This issue is fixed as the Transaction Date field on the UI for fee and additional interest component is now made editable so that you can specify a backdated date for waiving fee and additional interest component respectively.

The value of the Transaction Date is also checked by the system to ensure that the date specified is not before the Last Accrual Date of the loan contract.

7.17 System is allowing the user to specify Interest Only Period to be more than Payment Term (Jira ID: PDRFF-513/ND-5279)

Issue Description

While creating a simple loan contract with Interest Posting Frequency as Billing Frequency, Payment Frequency as Monthly, and Accrual Type as Accrual To Date, if we specify the Interest Only Period as more than the Payment Term and then do a disbursement, then the status of the contract changes to Active – Good Standing, but the Repayment Schedule is not getting generated.

Resolution

This issue is fixed as now the system displays the following error message if the user specifies the Interest Only Period more than the Payment Term:

“Interest Only Period should be less than the contract term.”

The system now does not allow the user to proceed with creating such a contract by displaying the preceding message while saving the contract.

7.18 System is allowing disbursements after the Maturity Date (Jira ID: PDRFF-577/ND-5264)

Issue Description

In a loan contract that is a Simple Loan Product Type, if the Funding In Tranches flag is enabled, the system is allowing the disbursements even after the Maturity Date, resulting in an increase in the Loan Balance.

The system should not allow disbursements on or after the Maturity Date as it serves no purpose to allow disbursement on or after the loan has matured.

Resolution

This issue is resolved as the disbursement on or after the loan maturity is now restricted, and the system is displaying the following message when you try to do a disbursement on or after the Maturity Date:

“Disbursement is not allowed on or after Maturity Date of the contract.”

7.19 Flexible Repayment Plan is allowing a Principal Only payment amount that is more than Loan Amount (Jira ID: PDRFF-580/ND-5266)

Issue Description

In a Flexible Repayment Plan, if a Principal Only payment plan is created with a Payment Amount more than the Loan Amount, then the system is not restricting such a configuration.

A single Principal Only payment plan or a sum of all the Principal Only payment plans in a Flexible Repayment Plan must not be more than the Loan Amount.

Resolution

This issue is resolved as the system is now displaying the following validation message whenever a single Principal Only payment plan or the sum of all the Principal Only payment plans in a Flexible Repayment Plan crosses the Loan Amount:

“Principal Only Payment Amount cannot exceed the Loan Amount.”

7.20 Payment Term is not populated in a Master Facility loan contract after the contract’s activation (Jira ID: PDRFF-561/ND-5280)

Issue Description

While creating a Master Facility loan contract, if a Maturity Date and the Payment Frequency is provided, then on activating such a contract, the system is not updating the Payment Term automatically.

Payment Term should be calculated and displayed based on the Contract Start Date, Maturity Date, and the Payment Frequency.

Resolution

This issue is resolved as now the Payment Term is calculated and displayed based on the Contract Start Date, Maturity Date and Payment Frequency defined.

7.21 System is not allowing to set up a contract when Payment Application Order is date wise (Jira ID: PDRFF-425/ND-5155)

Issue Description

While trying to set up a loan contract where interest accrual is an EOD process, if the Payment Application Order is selected as Date with the Interest Posting Frequency as Billing Frequency and Payment Frequency as Monthly, then the system is displaying the following error message:

“End of Day Accrual is not allowed with Interest Posting Frequency as Billing Frequency and Payment Application Order as Date Wise.”

Resolution

This issue is resolved as the error message has been now removed and the billing job is now run as part of the EOD process.

Therefore, now the system is allowing to set up a contract with Payment Application Order as Date when a loan has an Interest Posting Frequency set as Billing Frequency and Payment Frequency as Monthly.

For more information on why the billing job is run as part of the EOD process, see the following note.

7.22 Interest Posting Transaction is created on the billing date for an EOD accrual process where accrual type is Accrual To Date (Jira ID: PDRFF-429)

Issue Description

In a loan where the interest accrual is an EOD process and the Accrual Type is Accrual To Date, if the Interest Posting Frequency is Billing Frequency and Payment Frequency is Monthly, it is observed that the system is creating the Interest Posting Transaction on the billing date (due date) instead of creating it on the day before the billing date.

Resolution

This issue is fixed as the billing job is now run as part of the EOD process and the Interest Posting Transaction for an Accrual To Date type of an accrual in an EOD accrual process is now correctly created on the previous day of the billing date (due date).

7.23 Error while rescheduling a Master Facility loan (Jira ID: PDRFF-581/ND-5278)

Issue Description

When a Master Facility type of loan is being rescheduled to change the Repayment Start Date, the Due Day, or the Maturity Date, the system is displaying the following error: “This loan does not have any remaining principal balance.”

This is because for loans that are not of the Master Facility type, the system should not allow rescheduling if the Principal Remaining is zero. However, for a Master Facility type of loan, the Principal Remaining is always zero as a Master Facility type of loan is never disbursed. So, as the system is seeing the Principal Remaining as zero, it is not allowing the rescheduling and displaying an error message.

Resolution

This issue is fixed as the system is now allowing the rescheduling of a Master Facility loan without any error messages.

Additionally, now the system is not allowing a rescheduling before the last LAD for the Master Facility loan and its child loans.

For a Master Facility loan, the following can be changed as part of the rescheduling:

• Repayment Start Date

• New Due day

• Maturity Date

• Frequency of Loan Payment

• Second Payment Date

• New second due day

• Interest Rate

• AIC Rate

7.24 The system is not creating an LPT for the tolerance amount when a payoff is made for a loan with capitalization not enabled (Jira ID: PDRFF-638/ND-5276)

Issue Description

The system is not creating a Loan Payment Transaction (LPT) for the tolerance amount when a payoff is made for a loan where capitalization is not enabled and where a tolerance amount has been defined, but the status is getting updated to Closed-Obligations Met.

The ideal scenario is that if a loan is created with some tolerance amount, then when a payoff is done with amount that does not include the tolerance amount, the system must perform the steps in the following order:

a. Principal Remaining on the loan must get updated to zero.

b. Interest Posted must be added to Loan Balance.

c. Loan status must get updated to Active-Marked for Closure.

d. LPT for the tolerance amount with the transaction type as Closure-Tolerance must be created in the system.

e. The loan status must be set to Closed-Obligations Met.

However, when a payoff is done in a loan where capitalization is not enabled, the Loan status is not getting updated to Active-Marked for Closure as per the preceding steps, and hence the loan status is directly getting updated to Closed-Obligations Met without creating any LPT for the tolerance amount.

This issue is not seen for loans where capitalization is enabled.

Resolution

This issue is fixed, and if capitalization is not enabled on loans where there is some tolerance amount defined, when a payoff is made with the amount that does not include the tolerance amount, the system is now following the correct steps as in the following order:

1. Principal Remaining on the loan must get updated to zero.

2. Interest Posted must be added to Loan Balance.

3. Loan status must get updated to Active-Marked for Closure.

4. LPT for the tolerance amount with the transaction type as Closure-Tolerance must be created in the system.

5. The loan status must be set to Closed-Obligations Met.

7.25 Too many query rows exception observed while doing disbursals (Jira ID: PDRFF-695)

Issue Description

While doing disbursals, the system is throwing the following exception: “Too many query rows: 50001.”

This is because, internally, if, in a single execution, the system already has 50,000 records to be fetched, which may not necessarily contain records for the disbursals but may have records including payments, disbursals, rate changes, and more, then when an additional transaction like a disbursal is made, the number of records to be fetched becomes more than 50,000 resulting in the system not able to process it further and throw an exception.

A single execution can have many queries that can fetch many records. Now, if, in an execution, there are a total of more than 50,000 records getting fetched by multiple queries then the system is throwing the following exception: “Too many query rows: 50001.”

To understand this, let us say there are two queries: one on LPT and one on disbursal. If the query on LPTs returns 50,000 records, then when a query is run for disbursals, the system is throwing the exception. Thus, the exception is thrown not because of the 50,000 records getting fetched per query, but because of 50,000 records fetched overall in one execution. In one execution, you can only fetch 50,000 records.

Also, while doing disbursal transactions, it is not necessary that all the queries have to be run for all contracts. Let us say in one contract there are 1000 repayment schedules, and, in another contractor, there are only five repayment schedules. This would mean that not all records may need to be fetched.

For example, a query may not have a Where clause which can filter out the records for a particular contract. That means that this could query all contracts, and it could fetch 49524 DTD records.

Now say there is another query that fetches some more records making the total records more than 50,000. Then the system is throwing this exception as follows: “Too many query rows: 50001.”

This means that the queries may be taking the entire org’s data.

Resolution

This is fixed by adding the following conditions in the queries to filter the records correctly:

• Adding a condition in the Where clause of the query to filter the records by the ID. Only those contracts that are getting through in the execution logic are filtered.

• Adding two more conditions to conditionally query the records further.

Thus, the fix helps in preventing the code from always querying without a Where clause, which, hence, helps in not querying the entire database.

7.26 The system is considering a part of the payoff amount as Excess even if the payoff amount is the exact amount as in the Payoff Quote (Jira ID: PDRFF-658/ND-5282)

Issue Description

In a Flexible AMZ loan, even after making a payoff with the exact amount as generated in the Payoff Quote, the system is not considering it as a complete payoff. The system is satisfying only the fees with that payoff amount. The remaining amount of the payoff amount is getting considered as Excess. This is because the system is considering an incorrect amount for the principal component of the payoff amount.

Example

Let us say a flexible AMZ contract is created with the following details:

Bill is already generated on March 27 as the pre-bill days is 5, and due date is April 1.

Now let us see how the system is behaving when the following payments are made:

Let us then generate a Payoff Quote on March 29 with the Payoff Date as March 29. This would include the excess amount too.

On March 30, if we create a payment transaction with the amount as the Payoff Quote amount and the Transaction Date as March 29, which is the Payoff Quote date, then we see that this amount is considered as excess by the system.

Resolution

This issue is fixed. Now the system is considering the correct amount for the principal component of the payoff amount. Hence, when a payoff is done, the system is satisfying all the components of that amount correctly, and the payoff is successful.

7.27 Investor Payout job is failing with an exception for a loan with backdated and current-dated payments (Jira ID: PDRFF-680/PDRFF-519/ND-5286)

Issue Description

In a Flexible AMZ loan, if a current-dated payment is made after a backdated payment, the Investor Payout job is failing with an exception.

For example, let us say there are two payments made and cleared in the system as follows:

This is because on running the Investor Payout Job, while creating the ILT1 for LPT1, the system is incorrectly considering the current date (May 6) as the transaction date for ILT1, and hence, when the system is trying to create an ILT2 for the LPT2, it is unable to create it as it is finding an existing ILT1 (Investment Order payment) transaction (May 6) after the LPT2 Transaction Date (May 5).

Resolution

This issue is fixed as now the system is not throwing an exception while running the Investor Payment Job for a loan with a backdated and a current dated payment.

Referring to the preceding example, as a fix, now the system checks the Loan Payment Transaction Time of the LPT1 (April 10) and not the Transaction Date of the ILT1 (May 6) before creating the ILT2 for LPT2. Hence, on finding that there are no LPTs created after LPT2 (May 5), the system is successfully creating the ILT2 for the LPT2 without any exceptions.

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

Issue Description

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

Resolution

This issue is fixed. Now the installment payment is satisfying the bill correctly and the system is marking the existing IPT closed and paid.

7.29 InvestorPayoutReversalJob is failing with the Too many query rows error message (Jira ID: PDRFF-440/ND-5223, PDRFF-481/ND-5265)

Issue Description

For the following configuration of the loan, the InvestorPayoutReversalJob is failing with the Too many query rows exception:

• Enable Adjustment Entry = False (at Product-level)

• 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 50,000 records resulting in the following error message:

“First error: mfiflexUtil:Too many query rows: 50001.”

Note: The preceding exception is being thrown because the maximum number of rows you can return in SOQL calls in Apex is 50000.

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.

7.30 The system is unable to process the refund of the excess amount when loan is closed (Jira ID: ND-2624)

Issue Description

If you pay an excess amount, or, if the repayment amount is more than the outstanding Loan Balance at anytime in the duration of the loan, then, to refund this excess amount, on clicking Refund at a time when loan is closed, the system is throwing the following exception:

“You can refund only against a loan with status - Closed.”

There are times when a borrower may pay an excess amount any time while the loan is active. In such scenarios, the business may need to refund the excess amount to the borrower whenever there is an additional (more than the loan balance outstanding) repayment on the loan account. The system is not allowing to refund this amount when the loan is not closed. It is only allowing to refund once the loan has been closed and the loan contract status is set to Closed - Obligations Met.

The expectation is that the system must be able to refund the excess amount without closing the loan account; a loan must close after the loan balance is fully paid off and the mortgage is discharged; and the loan closure must be the last step of the whole process.

Resolution

This issue is now fixed as the logic is updated to not throw the preceding exception when you are trying to do a refund on a loan that is not closed. This allows the system to perform a partial refund on the loan.

Now if an excess payment is made and if you click Refund for a loan that is not closed, the system successfully processes such a refund for the borrower.

7.31 The system is not updating the Clearing Date of the cleared IFT (Jira ID: ND-5194/ND-4945)

Issue Description

After uploading the bank statement file in the Upload Bank Statement tab of the Bazaar application, on clicking the Reconcile Statement, if the Investor Deposit flag in the Custom settings > Transaction approval Config is false, then the Investor Fund Transaction (IFT) is correctly getting cleared by marking the Cleared flag true, but the Clearing Date on the created IFT is not getting updated.

Resolution

This issue is fixed as the system is clearing the IFT enabling the Cleared flag and updating the Clearing Date when the Investor Deposit flag is disabled in the Transaction Approval Config.

Additionally, if the Investor Deposit flag is enabled and the Cleared flag is manually enabled, then the Clearing Date is getting updated to the current system date when the Cleared flag is enabled.

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

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

7.34 Maximum view state error message seen while previewing the rescheduling of the loan (Jira ID: PDRFF-662/ND-5304)

Issue Description

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

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

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

Resolution

This issue is now fixed.

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

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

• First Page

• Next Page

• Previous Page

• Last Page

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

o Next Page

o Last Page

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

o First Page

o Previous Page

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

Note: This issue is also seen when the Number of Installments are more than 950 even when each view is displaying only 50 records. This will be fixed in one of the upcoming releases.

7.35 Next Deposit Payment Date is not getting updated on rescheduling (Jira ID: PDRFF-651/ND-5288)

Issue Description

While rescheduling a loan or while doing a Due Day Change, the system is not updating the Next Deposit Payment Date.

Resolution

This issue is fixed. The system is now updating the Next Deposit Payment Date when a loan is being rescheduled or a Due Day Change has been performed.

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

Fixed Version

Oxygen (3.5054.90)

7.37 Maturity Date is getting updated if it falls on a holiday for loans with Funding in Tranches set as False (Jira ID: PDRFF-542/ND-5323)

Issue Description

While booking a contract with Funding in Tranches set as False, the Maturity Date is getting updated to the next working day on the repayment schedule.

However, when a contract is booked with Funding in Tranches is set to True, the Maturity date provided by the user is not updated to the next working day.

Expected Behavior

Maturity date should not move to the next working day if it falls on a holiday while booking a contract with Funding in Tranches set as False. The system should retain the date provided by the user in the Maturity Date field and the Current Maturity Date should move to a working day based on the values selected in the Move Across Month and the Schedule Adjustment Method fields.

The system should display a consistent behavior when a contract is booked with Funding in Tranches set to True or False.

Example of the Issue

Let us say we are creating a loan contract with Funding in Tranches set to False and with the Maturity Date as February 26, 2022.

Note that Saturdays and Sundays are marked as Holiday as per the Business Hours.

When the contract status moves to Partial Application, the Maturity Date gets updated to February 28, 2022.

Resolution

This issue is now fixed as the system is now successfully retaining the value in the Maturity Date field as provided by the user. If the Maturity Date falls on a holiday, the system correctly updates the Current Maturity Date to a working date based on the Move Across Month and the Schedule Adjustment Method field values.

7.38 Current Maturity Date is not following the Holiday Treatment Setup (Jira ID: PDRFF-560/ND-5323)

Issue Description

When a Master Facility loan contract is created with Maturity Date that falls on a holiday, then the system is not applying the Holiday Treatment to the Current Maturity Date. This means that even when the system finds that the Current Maturity Date falls on a holiday, it is not moving the Current Maturity Date to a working date based on the Move Across Months and Schedule Adjustment Method.

Example of the Issue

Let us say we have created a Master Facility contract, and the Maturity Date provided by the user is falling on holiday. Let us not provide any Payment Terms.

On activating this contract, the Current Maturity Date is the same as the Maturity Date, which is a holiday. The system is not applying the Holiday Treatment on the Current Maturity Date.

Resolution

This issue is now fixed as the system is now applying the Holiday Treatment on the Current Maturity Date if it falls on a holiday and moves it to a working date based on the values specified in the Move Across Months and Schedule Adjustment Method fields.

7.39 The system is unable to create child loans if Maturity Date of a Master Facility loan falls on a holiday (Jira ID: PDRFF-604/ND-5323)

Issue Description

When a Master Facility is created with the Maturity Date falling on a holiday, the Current Maturity Date is not moving to the next working day. Due to this, while creating a child loan, the system is displaying the following error and is not allowing to create child loans:

“Child loans maturity date should be less than or equal to parent loan maturity date.”

This is because, while the child loan is getting created, the Current Maturity Date of the child loan moves to the next working day, which is greater than the Master Facility loan as the Current Maturity Date on the parent Master Facility is not getting updated and remains the same.

Resolution

This issue is now fixed. The system is successfully able to create child loans without errors if the Maturity Date of a parent Master Facility loan contract falls on a holiday as now the system is successfully moving the Current Maturity Date of the Master Facility loan contract if it falls on a holiday based on the values specified in the Move Across Months and Schedule Adjustment Method fields.

7.40 First Payment Date is not following the Holiday Treatment even when the Scheduled Adjustment Method is defined (Jira ID: PDRFF-547/ND-5327)

Issue Description

Even if Scheduled Adjustment Method is defined in a loan, the system is not moving the First Payment Date to a working date. However, the system is correctly moving the Next Due Date to a working date if it falls on a holiday. Due to this, the First Payment Date and the Next Due Date do not have the same values.

Example

Let us say a simple loan is created with the following terms and conditions:

Let us say that the scheduled Due Date falls on February 5, 2022, which is a Saturday.

The issue is that the First Payment Date is updated to the scheduled Due Date of February 5, 2022, even though it is a non-working day, whereas the Next Due Date is moved to a working date, which is February 7, 2022, Monday. Hence the Next Due Date and the First Payment Date do not have the same values.

The First Payment Date must be moved to a working date so that it is same as the Due Date to which the Holiday Treatment is applied.

Resolution

This issue is now fixed as the system is successfully moving the First Payment Date to a working date based on the Holiday Treatment parameters defined.

7.41 The system is not adjusting the Charge Accrued if charge is completely or partially waived (Jira ID: ND-4847)

Issue Description

If a fee is accrued over a period of time and then if a user is waiving off the fee completely or partially during the life of a contract, then either there would be no income out of that fee or there would be an income which is less than the accrued amount.

But, in such scenarios, the system is not updating the accrued amount and is not posting a reversal accrual (negative accrual) entry.

The system should update the Charge Accrued field and should post a reversal accrual entry to the excess amount which is accrued.

Example

Let us say we have set up a fee with the following values and a loan is created with the following fee set:

Now let us move the system date and run the fee accrual job, so that a part of the fee is accrued.

Then let us waive the fee completely or partially such that it is greater than the remaining amount for accrual. Now on moving the system date and then running the accrual job, we see that the system is not updating the accrued amount and is not posting a reversal accrual (negative accrual) entry

Resolution

This issue is now fixed. An additional check is introduced in the Fee Accrual Job such that when this job runs, it would check if the charge has been accrued more than the waived amount. If the job finds such a charge, then it will generate a negative accrual entry for the difference amount. That means the system will now create a negative entry for an amount equal to (amount waived - amount accrued).

7.42 The system is throwing an error while performing a loan payoff transaction (Jira ID: PDRFF-622/ND-5291)

Issue Description

In a Master Facility loan, after paying off all the child loans, when the user is trying to make a complete payoff, the system is displaying the following error message:

“Apex CPU time limit exceeded.”

Resolution

This issue is now fixed as the system is allowing the user to perform a payoff on the Master Facility contract without any errors.

7.43 Billed fees are not getting cleared on making a payment of the bill amount on the Due Date (Jira ID: PDRFF-761/ND-5334)

Issue Description

For a term loan contract that has the Payment Application Order set as Date, and that has a specific fee type, on making a payment of the billed amount for such a contract on the Due Date, the system is not clearing the due fees included in the bill and instead the system is clearing the payment against the principal amount.

The system should clear all the fees that are due and included in the bill when the payment amount is the billed amount.

Resolution

This issue is now fixed as the system is correctly clearing the payment of the specific fee type against that fee due. This means that now when a billed amount is paid, the system is successfully clearing the required payment against the fees included in the bill amount too.

7.44 Payment is not getting cleared against the applied spread if the spread only consists of the additional interest component (Jira ID: PDRFF-764/ND-5334)

Issue Description

In a Master Facility loan contract, if the payment spread is defined to consider only the additional Interest Component, then the system is not clearing the payment against that additional interest, but instead is considering it as an excess amount.

Resolution

This issue is now fixed as the system is successfully clearing the payment against the interest component mentioned in the applied spread in a Master Facility loan contract.

7.45 The system is not waiving the charge of the required fee type (Jira ID: PDRFF-776/ND-5334)

Issue Description

On waiving of a charge of a specified fee type, the system is waiving the fee type of the earliest found charge in the loan contract.

Resolution

This issue is now fixed as the system is waiving the correct fee type of the charge as specified by the user.

7.46 The Balloon Payment in the repayment schedule is considering only the disbursed amount that does not include the pre-paid fee (Jira ID: PDRFF-783/ND-5330)

Issue Description

While creating a simple loan contract where Balloon Payment is specified, if a disbursement of less than the Balloon Payment is made, then while calculating the balloon payment ratio, the system is not including the pre-paid fee in the disbursed amount.

This is because the prepaid fee amount is also deducted from the loan amount, and then this loan amount is considered in calculating the prorated balloon amount calculation because the disbursed amount consists only of the actual disbursed amount.

Example

Say if a loan contract is created with the following details:

• Loan Amount = $10,000

• Balloon Payment = $5,000

• Disbursed amount = $4,000 Total disbursed amount = $4,000 + $1,000 (Prepaid fee) = $5,000.

After disbursing, while calculating a balloon payment, in the repayment schedule, the system is not considering the principal amount disbursed and the pre-paid fee provided.

Thus, the balloon payment is incorrectly calculated as per the previous formula as follows:

($4,000/$9,000) * $5,000.

This formula is not including the prepaid fees.

Resolution

To resolve this, the Balloon payment amount that the internal calculator has to use is calculated using the following updated formula:

(1- (Remaining Amount / Loan Amount)) * Balloon Payment

= (1-(5,000/10,000)) * 5,000.

This means that the system is now correctly calculating the balloon payment including the prepaid fees too.

7.47 Incorrect Interest Posting Day updated when Interest Posting Frequency is set to Billing Frequency (Jira ID: PDRFF-565/ND-5318)

Issue Description

When Interest Posting Frequency is set to Billing Frequency, the Interest Posting Day is incorrectly updated.

Example

Let us say that the Contract Start Date is January 31. The Interest Posting Day of the contract is then expected to be as 31. However, when Interest Posting Frequency is Billing Frequency, the next IPT date is set to February 28, as February has only 28 days and the Interest Posting Day is updated looking at the IPT date which is 28.

The Interest Posting Day should be updated to 31 because the contract is activated on month end.

Resolution

This issue is resolved by updating the Interest Posting Day looking at the contract due day, and not the IPT date, as the IPT frequency is Billing Frequency.

7.48 Floating Rate Revision to occur only on business days (Jira ID: PDRFF-378/ND-5331)

Enhancement Description

It is a standard practice in the commercial lending market to perform floating rate revisions only on business days as the new rates are released by most indices or agencies only on a working day.

In the Q2 Loan Servicing system, if the floating rate revision date falls on a non-working day, the system should be able to post it on the next working day. Hence, there needs to be a configuration that can provide this added flexibility, and the user should be able to configure the floating rate revision date logic in the system. The user should be able to define if the floating rate revision should be moved to the previous date or the next date in case of a holiday.

To address this, the Q2 Loan Servicing has been enhanced to include the Floating Rate Revision parameter in the Holiday Treatment Setup.

Upgrade Step

To be able to add Floating Rate Revision to the Holiday Treatment Setup, ensure that the picklist value Floating Rate Revision is added in the Holiday Treatment Setup object. Also ensure that the picklist value Quarterly is added to the Floating Rate Revision Frequency picklist field of the CL Contract object. Note: For more information on adding Floating Rate Revision picklist value in the Holiday Treatment Setup and Quarterly picklist value in CL Contract, see the Latest Oxygen patch (3.5054.xx) to latest Platinum patch (3.6019.104) upgrade steps in the Q2 Loan Servicing (CL Loan) and Marketplace Upgrade Steps section of the Q2 Product Upgrade Guide.

Example

Let us say that a Floating Rate Index is defined as follows:

Let us say that Business Hours are created with Saturday and Sunday as holidays, and the Floating rate Revision Frequency is Monthly.

Let us say that the Contract Start Date is March 3 (Wednesday), 2021, then on April 3 (Saturday), 2021, the rate does not change as it is a Saturday.

On April 5 (Monday), 2021, we see that the Current Interest Rate is 15% and the Floating Rate Revision Date is May 3 (Monday), 2021.

On May 3, 2021, the Current Interest Rate is 19%, and the Floating Rate Revision Date is June 3 (Thursday), 2021.

7.49 The system is rescheduling the loan on Principal Remaining only when Reschedule Balance is selected as Principal Remaining (Jira ID: PDRFF-511/ND-5335)

Issue Description

In a loan contract where redraw is enabled, if the loan contract is rescheduled using Reschedule Balance as Principal Remaining, the contract is getting rescheduled only on the Principal Remaining.

Expectation

Even if the Reschedule Balance is selected as Principal Remaining, the loan contract must be rescheduled on the following amount = Loan Balance + Reserve Amount Not Due (redraw amount).

Resolution

This issue is resolved. Now, for redraw-enabled loans, internally, the system is rescheduling the loan on the following amount:

Minimum of (Schedule Balance and (Loan Balance + Reserve Amount Not Due))

This applies to both automatic and manual rescheduling.

7.50 Interest Rounding Error field is updating to zero (Jira ID: PDRFF-501/ND-5321)

Issue Description

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

Resolution

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

7.51 Interest Rounding Error field is displaying a zero value (Jira ID: PDRFF-552/ND-5322)

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. Now if a payment is made for a capitalized charge in a loan contract, the system is not displaying a zero value in the Interest Rounding Error field.

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

7.53 The loan status is not getting updated to Closed-Obligations Met by the Loan Closure Job after making a payoff (Jira ID: PDRFF-738/ND-5339)

Issue Description

While making a payoff, the system is applying the payoff amount to principal and interest, and the remaining amount of the payoff amount is getting considered as an Excess updating the loan status to Active – Marked for Closure, after which the Loan Closure Job creates an Excess LPT, and the amount gets cleared to Excess again.

This is because while making a payoff, in the payment split process, the Excess Payoff and the Additional Interest Excess Payoff IPTs are not being considered. Hence, the payment amount is getting applied to Excess.

Expected Behavior

While making a payoff, all balances should be cleared, and the loan status should be updated to Closed-Obligations Met by the Loan Closure Job.

Resolution

This issue is fixed as the logic has been updated to consider the Excess Payoff and the Additional Interest Excess Payoff IPTs too in the payment split process if they exist. Now, while making a payoff, all balances get cleared and the loan status gets updated to Closed-Obligations Met by the Loan Closure Job.

7.54 Issue with the clearance of charge when the charge is part of a bill and schedule (Jira ID: PDRFF-525/ND-5240)

Issue Description

In a simple loan contract where the Include in Dues and Include in Schedules is enabled for the Periodic Fee, if the Periodic Fee accrual date is before the billing date and if the customer pays the bill amount on the charge due date before the bill gets generated, then the charge gets paid and when the bill gets generated later it gets underpaid by the periodic charge amount.

Example

Let's assume there is a loan contract with payment frequency as monthly and where the periodic fee is getting accrued on first of the month and the bill is getting due on the fifth of the month.

Let us assume the following:

• Charge accrual date = January 1

• Bill due date = January 5

• Charge = $10

• Bill amount is $100.

Say if we pay $100 on January 1, then the amount should go to the Reserve Amount Not Due as it is not yet the Due Date, and then on due date, the system should automatically take the $100 and satisfy the bill. However, this is not how the system is behaving. What the system does is, it only moves the $90 to the Reserve Amount Not Due, and then on the due date, the bill is satisfied for only $90, and the remaining $10 is still remaining as due.

Resolution

This issue is fixed and now the system is correctly clearing the charges, the bill gets paid, and the loan is not becoming delinquent too.

This issue is fixed when Periodic Fee Amount Type is Per-Period Amount. If the Periodic Fee Amount Type is Total amount or null, the system displays the following error message if the start date of the Periodic Fee is different from the Due Date:

“Start date cannot be modified for Periodic Fee Amount type - Total Amount or Null.”

7.55 The payment is not getting processed when a Payment Amount Change is performed in a loan (Jira ID: PDRFF-642/ND-5385)

Issue Description

On creating a payment change transaction by going to Loan Quick Menu > Loan Actions > Payment Amount Change and then making a payment, the payment is not getting processed.

This is because when the user is creating a payment change transaction as of the bill due date, the future schedules are getting archived and new bills are getting created based on the new payment amount. Due to this, the existing bill is getting delinquent and when a payment is made, the amount is going into excess.

Example

Let us consider the following:

Let us perform the following steps:

1. Create a Flexible AMZ contract of $10,000.

2. Enable the Is Interest Posting and FIT flags.

3. Create a Disbursement transaction of $5,000 and activate the contract.

4. Run the EOD job and once the bill gets created, satisfy with the payment transaction.

5. Run EOD Job again. A new bill gets created.

6. Create another disbursement transaction of $5,000.

7. Now, on May 2 (Bill Due Date), create a payment change transactions and change the payment amount by going to Loan Quick Menu > Loan Actions > Payment Amount Change. This will come into effect from June 2.

We observe that, due to the payment change transaction, the repayment schedule of May 2 are getting archived, and the future schedules are getting re-generated, and the bill with the Due Date as May 2 is remaining untouched.

Due to this, the May 2 bill is becoming delinquent and when we create a payment transaction, the amount is going into excess.

Resolution

This issue is fixed as now the existing repayment schedule is not getting archived when a Payment Amount Change is performed, and the payment is getting processed correctly.

7.56 MixandmatchBatch job is failing with Too many SOQL queries error (Jira ID: PDRFF-679/MD-467)

Issue Description

If a Bazaar application consists of a high number of investment bookings, after running the QueuecreationBatch job, the MixandmatchBatch job is failing with the following error message:

“First error: peer:Too many SOQL queries: 201”

Resolution

This issue is resolved. Now, the MixandmatchBatch job is running successfully creating investment bookings successfully without any error messages.

7.57 Unable to increase the Min Financed Amount value of a Lending Product (Jira ID: PDRFF-536/ND-5341)

Issue Description

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

“Invalid Minimum And Maximum Loan Amount.”

Example

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

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

“Invalid Minimum And Maximum Loan Amount.”

Resolution

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

7.58 Amortization schedule from the Loan Quick Menu is not working in the Lightning Experience (Jira ID: PDRFF-537/ND-5360)

Issue Description

In the Lightning Experience, when the user is clicking on Loan Quick Menu > Repayment Schedule > View Amortization Schedule and then clicking the PDF for Print button, the system is displaying the following error message:

“An internal server error has occurred.”

Note: This works fine in the Salesforce Classic theme. The issue is only seen in the Lightning Experience.

Resolution

This issue is fixed. Now the user is able to click the Loan Quick Menu > Repayment Schedule > View Amortization Schedule > PDF for Print in the Lightning Experience and view the PDF of the amortization schedule successfully without any errors.

7.59 Contract status is incorrectly updating to Active - Marked for Closure after making a payment even if the Adjust Deposit Amount In Payoff flag is off (Jira ID: ND-5007)

Issue Description

After making a payment of the payoff amount and if the payment is satisfied toward the Deposit, the loan contract status is getting updated to Active - Marked for Closure even if the Adjust Deposit Amount In Payoff flag is off. Also, once the status is moved to Active - Marked for Closure, the system is not allowing any further transactions on deposit by displaying the following error message:

“CL019109: Contract: Active - Marked for Closure status should be either in Active Good Standing or Active Bad Standing for Deposit Change/Transfer.”

Example

Let us say on October 5, 2021, a loan with Loan Amount as $100,000 is disbursed, where the Adjust Deposit Amount In Payoff flag is False.

Let us say on another day, interest on loan is $10, and a payment of $100,000 is made. This amount is paid toward the Deposit, and loan status remains as Active - Good Standing.

Now say another payment of $10 is made. This amount is also applied toward the Deposit. However, this payment changes the status to Active - Marked for Closure as the available amount in Deposit is sufficient to close the loan.

Then if any other transaction is performed on the Deposit, the system displays the following error:

“CL019109: Contract: Active - Marked for Closure status should be either in Active Good Standing or Active Bad Standing for Deposit Change/Transfer.”

Resolution

This issue is fixed. Now the status of the loan contract is getting changed only if the Adjust Deposit Amount In Payoff flag is False. Then on performing any transaction on Deposit, the system is not displaying any error message.

7.60 The system is calculating an incorrect Amount Due Till Current value resulting in the contract not getting closed (Jira ID: PDRFF-736/ND-5333)

Issue Description

In a loan with a capitalized charge in it, on a date one day after the due date of the last bill cycle, the system is incorrectly including the charge amount twice in the Amount Due Till Current. Hence, when a payment of the bill Due Amount is made, the Bill is getting marked unpaid by the system and the loan is not getting closed.

This is because the last bill generated depends on the payoff amount, and the capitalized charge is getting added to the payoff amount. Due to this, the bill amount is also including the charge amount, and when the system is calculating the Amount Due Till Current, it adds the bill amount and the capitalized charge resulting in the charge amount getting included twice.

Example

Let us say we disburse a loan with the following parameters defined for a fee:

Let us say this loan has a charge that is capitalized. On moving to the last Due Date of the loan and checking the bill, we see that the bill Due Amount has increased by the charge amount.

On the next day of this Due Date, we observe that the Amount Due Till Current has an incorrect value as it is including the charge amount twice

Then on making a payment equal to the bill Due Amount for such a loan, the Bill is getting marked as unpaid due to which the loan is not getting closed.

Expected Behavior

The Amount Due Till Current should include the charge amount only once, and the payment that includes both the bill amount and the charge should satisfy the bill completely leading to the closure of the loan.

Resolution

This issue is now fixed. Now the system is not including the charges in the payoff amount and so the last bill is not getting increased by the charge amount. Due to this, the Amount Due Till Current is including the charge amount only once. Hence, when a payment of the bill amount and the charge amount is made, it is satisfying the bill completely and the system is marking the bill paid leading to the successful closure of the loan.

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

7.62 Remaining Amount for Funding in a Master Facility loan is not considering the Pre-Paid Fee disbursed through its child loans (Jira ID: PDRFF-596/ND-5352)

Issue Description

The Remaining Amount For Funding in a Master Facility loan is not considering the Pre-Paid Fee disbursed though its child loans.

Example

Let us say there is a Master Facility loan, and it has two child Simple Loans created as follows:

Before disbursal of the two child loans, we observe the following values in the Master Facility loan contract:

After disbursal of the two child loans, the values in the Master Facility loan contract should change to the following:

As observed, the Remaining Amount For Funding of the Master Facility loan contract should consider the Pre-Paid Fee amount with the disbursed amount of each of the two child loans and hence reduce ($9500 + $500) of each of the two child loans from the Loan Amount of the Master Facility loan contract. Thus the system should reduce 2 * (9500+ 500) = 2 * (10,000) = $20,000 from the Loan Amount. Hence, the Remaining Amount For Funding should reduce to = $50,000 - $20,000 = $30,000.

And thus, the additional interest on the Available Amount For Funding of $30,000 should be calculated as follows:

$30,000 * (10/100) * (31/365) = $254.79.

However, the issue is that the Remaining Amount for Funding of the Master Facility is not taking into account the pre-paid fee disbursed across the child loans in its calculation, and hence the additional Interest Component with Interest Bearing Principal as Available Amount For Funding is also calculated incorrectly.

This is because internally, the Remaining Amount For Funding is formula field that takes its funded value from the Disbursed Amount field, which includes only the Financed Amount excluding the pre- paid fees amount.

Resolution

This issue is fixed. Now, for the Master Facility loan, the system is updating the Disbursed Amount field to include the pre-paid fee amount disbursed for child contracts as well so that the Remaining Amount For Funding field is getting calculated including the pre-paid fee amount. Hence, the additional interest is also getting calculated correctly.

7.63 Available Amount for Next Funding in a refinanced child loan contract is not considering the principal outstanding of the consolidated child loan (Jira ID: PDRFF-737/ND-5375)

Issue Description

The Available Amount for Next Funding in a refinanced child loan contract is not considering the principal outstanding of the consolidated child loan.

After settling the child loans and then performing a disbursement in the consolidated child loan, the Available Amount for Next Funding in the consolidated loan remained the same.

The Available Amount for Next Funding and Current Credit Limit fields in the refinanced loan should be reduced by considering the consolidated principal amount of the consolidated loan.

This is because, on disbursement of a refinanced child loan, the system is not reducing the Current Credit Limit of the Master Facility loan contract that was increased during the payoff of the refinanced child loans.

Refinancing a loan, therefore, does not indicate that the debt will be cleared, it simply means that the existing loan can be restructured in terms of interest rates and different loan terms.

Resolution

This issue is fixed. Now, the Current Credit limit field is getting updated correctly to include the refinanced amount also as part of the calculation, and hence the Available Amount For Next Funding is getting calculated correctly.

7.64 Prepayment Fee is not getting included in the Total Payoff Amount of future- dated Payoff Quote (Jira ID: PDRFF-716/ND-5361)

Issue Description

Prepayment penalty field is not getting updated during future-dated payoff, and it is not getting included in the Total payoff amount.

Resolution

This issue is fixed. The internal logic has been updated such that the prepayment penalty fee is now getting updated during the future-dated payoff and getting included in the Total Payoff Amount.

7.65 Interest posted amount is not getting updated in a future-dated payoff quote (Jira ID: PDRFF-722/ND-5362)

Issue Description

While generating a future-dated payoff quote for a date less than the Next Due Date, the Interest Posted and the Interest Remaining fields are not displaying the updated values.

Resolution

This issue is fixed. The internal logic has now been updated to display the correct updated values of the Interest Posted and Interest Remaining while generating a future-dated payoff at a date less than the Next Due Date.

7.66 Interest accrual is getting calculated from the Contract Start Date instead of first disbursal date (Jira ID: PDRFF-665/ND-5368)

Issue Description

For a loan with Funding in Tranches flag set as False and Is Interest Posting flag set as True, even when the Accrual Start Basis is selected as Disbursement Date in the lending product of the loan contract, the system is calculating the interest accrual from the Contract Start Date instead of the disbursal date.

Resolution

This issue is fixed. The system is now calculating the interest accrual from the first disbursal date when Accrual Start Basis is the Disbursement Date, the Is Interest Posting flag is true, and Funding in Tranches flag is false.

7.67 Inactive Bank Accounts are accepted while making disbursements (Jira ID: PDRFF-668/ND-5364)

Issue Description

While making a loan disbursal, the system is allowing to select inactive Bank Accounts and make the disbursements. The system must not allow the user to do a disbursement to a bank account which is currently not active.

Expected Behavior

Only the bank accounts which are marked as active should be available in the Bank Account look up field in the Loan Disbursal Transaction.

Resolution

This issue is fixed. Now, if a user tries to save a disbursal transaction where an inactive Bank Account is selected, the system is throwing the following error message and not allowing to save such a disbursement:

“BA-… Bank accounts is/are inactive.”

7.68 Incorrect Principal Posted in an IPT in Accrual To Date type of accrual in an EOD-accrual-enabled loans (Jira ID: PDRFF-874/ND-5370)

Issue Description

In an Accrual To Date type of EOD-accrual-enabled loans that have charges to be included in bills, the Principal Posted in an IPT is not equal to the Principal Due of the Repayment Schedule and Bill. And when a payment is made, only the principal balance is cleared and not the billed fee.

Expected Behavior

The Principal Posted must be equal to the Principal Due as per the Repayment Schedule and Bill. And when a payment is made, both the billed principal and fee dues must be cleared.

RCA

This is because, in an Accrual To Date type of EOD-accrual-enabled loans, the IPTs get generated a day before the EOD, and the system considers the bills that have due dates less than the bill date on which the IPT needs to be created. This is resulting in no bills getting selected. When no bills are selected, the system is looking at the last bill. From the last bill amount, the system subtracts the interest amount and considers the rest as the principal amount as there is no way of knowing the fee amount in the last bill. Thus, the principal posted tends to be higher and thus, incorrect. Thus, the Fees Paid Amount is getting considered as zero.

Resolution

This issue is fixed as the internal logic has now been updated to consider bills with a Due Date that is one more than today so that tomorrow’s bills are considered and posted correctly. Then the Principal Posted amount is calculated as a correct amount.

7.69 APS payment creation is not considering only working days when Days In Advance To Create File is defined (Jira ID: PDRFF-816/ND-5376)

Issue Description

The LPT for Automatic Payment Setup is not getting created at the correct date when Days in Advance To Create File is defined.

In Custom Settings > ACH Parameters, let us say that the Days in Advance To Create File is set to 3, then the Loan Payment Transaction (LPT) is not getting created three working days before the Due Date. It is instead getting created three calendar days before the Due Date.

Resolution

To resolve this issue, when you create the Business Hours in the Setup, you must ensure that they are created in the name of BANK so that the ACH can follow these Business Hours and consider only working days for the payment creation. If the Business Hours are not created with the name as BANK, the ACH will consider it as normal calendar days to create the payment creation.

7.70 APS payment clearing is not considering working days when Lock Period is defined (Jira ID: PDRFF-821/ND-5376)

Issue Description

The LPT for Automatic Payment Setup is not getting cleared at the correct date when Lock Period is defined.

Let us say that Lock Period is set to 3, then the LPT is not getting cleared after three working days after the payment creation. It is instead getting cleared three calendar days after the payment creation.

This is because in the existing scenario, while clearing, the system is trying to find the Payment Mode that has the name as ACH. If it is not finding the name ACH, it is considering calendar days instead of considering business days only. Thus, for applying the holiday treatment, the system is not finding the Business Hours with the specific required Payment Mode name.

Also, every customer may have a different name assigned for the Payment Mode, so assigning one specific name to the Payment Mode of each Business Hours may also not work for all the customers as some customers may want to maintain only one Business Hours.

Resolution

This issue is resolved by ensuring that the customers create a Business Hours named BANK. This makes the process simpler because if the system does not find the Payment Mode with the name ACH, it tries to find the Business Hours with the name as BANK. If it does not find the Business Hours names BANK, it will not apply the holiday treatment to the days to be considered for the Lock Period. Hence, if the system finds the Business Hours named BANK, then the payment is cleared three working days after the creation.

7.71 Direct debit/APS payment generated is not considering the Additional Interest billed in a Master Facility loan contract (Jira ID: PDRFF-873/ND-5380)

Issue Description

In a Master Facility loan contract where the APS frequency is Billing Frequency and Amount Type is Last Billed Amount, the payment amount of an APS is not considering the Additional Interest billed, and hence the APS payment amount calculated is not the same as the billed amount.

This is because, when APS Amount Type is Last Billed Amount, it is considering only the last bill. The Master Facility consists only of additional interest, but the payoff considers Principal and Interest. While creating an LPT as the APS Amount Type is Last Billed Amount, the system compares the payoff amount and the last billed amount, and it considers the lesser of the two to generate a debit payment. When it does that, it finds that the payoff is zero for the Master Facility as Master Facility only has additional interest. So, it considers the payoff amount to be debited, which is zero, as it is the lesser amount, and hence no LPT is generated.

Resolution

This issue is fixed as the system is now considering the additional interest too while calculating the Payoff Amount for a Master Facility loan so that the payoff amount cannot be zero when there is an additional interest existing on the Master Facility loan and it can be compared with the Last Billed Amount, and then whichever is lesser is used to generate the APS payment.

7.72 While creating a child loan, the system is throwing an error if the Maturity Date of the child loan is greater than the Maturity Date of the Master Facility loan contract (Jira ID: PDRFF-777/ND-5390)

Issue Description

In a Master Facility, when holiday treatment is applied, the system is not allowing to create a child loan with Maturity Date greater than that of the Master Facility loan and lesser than the Current Maturity Date of the facility. While creating a child loan with Maturity Date greater than that of the Master Facility and lesser than the Current Maturity Date of the Master Facility, the system is throwing the following error message:

“Maturity date of child loan should be less than parent loan maturity date.”

Example

Let us that a Master Facility loan contract has a Maturity Date on Saturday and as Saturday is a holiday and if holiday treatment is applied such that the date has to be moved after, then the new or the Current Maturity Date of the Master Facility becomes Monday. Now while creating a child loan with Maturity Date as Sunday, the system is throwing the following error message as it is seeing that Maturity Date of the child loan (Sunday) is greater than the Maturity Date of the Master Facility loan (Saturday):

“Maturity date of child loan should be less than parent loan maturity date.”

Expected Behavior

Referring to the preceding example, the system must see if the Maturity Date of the child loan (Sunday) is greater than the Current Maturity Date of the Master Facility loan (Monday).

Resolution

This issue is fixed as the system is now checking whether the Maturity Date of the child loan is greater than the Current Maturity Date of the Master Facility or not. If the Maturity Date of the child loan is greater than the Current Maturity Date of the Master Facility, the system is throwing the preceding error message.

7.73 Interest Capitalization Posting on business days only (Jira ID: PDRFF-325/ND- 4558/ND-5178/PDRFF-788)

Enhancement Description

It is a standard practice in some of the commercial lending markets to post interest capitalizations only on business days. So, if the capitalization is enabled in a loan and if the interest posting date falls on a non-working day, the system must move it to post it on a previous or the next working day.

For example, in a capitalization-enabled loan, say the holiday treatment is defined such that the interest posting date is to be moved to a previous date (Schedule Adjustment Method = Before) in case of a holiday and the interest posting frequency is monthly with the due date on every month as 25.

Let us say that for a particular month, the 25th day turns out to be a holiday. In this case, the system should automatically post the interest on the immediate previous working day, which can be the 24th or the 23rd whichever is a working day.

To incorporate such a requirement, with the Platinum patch (3.6019.118) release, the Q2 Loan Servicing has been enhanced to post the interest capitalizations on business days only. This can be done by configuring the Holiday Treatment Setup for the Interest Capitalization Posting.

7.74 The system is calculating an incorrect Amount Due Till Current value resulting in the contract not getting closed (Jira ID: PDRFF-736/ND-5333)

Issue Description

In a loan with a capitalized charge in it, on a date one day after the due date of the last bill cycle, the system is incorrectly including the charge amount twice in the Amount Due Till Current. Hence, when a payment of the bill Due Amount is made, the Bill is getting marked unpaid by the system and the loan is not getting closed.

This is because the last bill generated depends on the payoff amount, and the capitalized charge is getting added to the payoff amount. Due to this, the bill amount is also including the charge amount, and when the system is calculating the Amount Due Till Current, it adds the bill amount and the capitalized charge resulting in the charge amount getting included twice.

Example

Let us say we disburse a loan with the following parameters defined for a fee:

Let us say this loan has a charge that is capitalized. On moving to the last Due Date of the loan and checking the bill, we see that the bill Due Amount has increased by the charge amount.

On the next day of this Due Date, we observe that the Amount Due Till Current has an incorrect value as it is including the charge amount twice.

Then on making a payment equal to the bill Due Amount for such a loan, the Bill is getting marked as unpaid due to which the loan is not getting closed.

Expected Behavior

The Amount Due Till Current should include the charge amount only once, and the payment that includes both the bill amount and the charge should satisfy the bill completely leading to the closure of the loan.

Resolution

This issue is now fixed. Now the system is not including the charges in the payoff amount and so the last bill is not getting increased by the charge amount. Due to this, the Amount Due Till Current is including the charge amount only once. Hence, when a payment of the bill amount and the charge amount is made, it is satisfying the bill completely and the system is marking the bill paid leading to the successful closure of the loan.

7.75 Delinquent amount is getting incorrectly updated and the loan is delinquent even when all bills are satisfied (Jira ID: PDRFF-541/ND-5396)

Issue Description

In a loan with Delinquency Basis = Balances, and Payment Application Mode = Deposit, if there is situation where there is some Delinquent Amount and all bills are satisfied, then when the next payment is made, the excess amount is paid toward the Deposit instead of satisfying the Delinquent Amount within the system. Due to this, the status of the loan incorrectly remains as Active-Bad Standing even when all bills are satisfied.

The system can pay the excess amount toward the Deposit when there is no Delinquent Amount left in the loan.

Example

To understand this better, let us say that a loan is delinquent since two cycles (the due amount has not been paid for the past two due dates). In such a case, the loan would have gathered a lot of interest than usual.

Now when you make a payment, the system will first satisfy the interest and then the principal. Thus, the principal would have been paid lesser than what it should have if the interest amount had not increased due to non-payment. However, the bill would have been paid in full by now as the bill does not see the portions of interest and principal paid, it just sees whether the total due amount is paid, and if the due amount is paid, it considers the bill paid.

However, the loan remains delinquent as the delinquency depends on whether the balance left on the loan at this point in time is more than what it should have been as per the balance calculated in the schedule. The balance in the loan is more as the principal unpaid is more than what it should have been.

Now, when one more payment is made to satisfy the Delinquent Amount, as the system finds that the bill has already been paid, it considers this payment as extra and moves it toward the Deposit. (The system can move the extra amount toward the Deposit when there is no Delinquent Amount left in the loan.) Thus, the Delinquent Amount value does not reduce and remains the same. Due to this, the status of the loan incorrectly remains as Active-Bad Standing.

Thus, when a payment is made to satisfy the Delinquent Amount, the Delinquent Amount does not reduce and hence seems to display an incorrect amount, and even though all the bills are satisfied and there is no due amount, the contract is still showing as delinquent.

Resolution

This issue is now fixed. The internal logic has now been updated to satisfy the Delinquent Amount correctly by deducting the payment amount from the Principal Remaining and thus updating other fields such as the Principal Paid and the Loan Balance correctly. Now the loan does not become delinquent when all the bills are paid.

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

“SObject row was retrieved via SOQL without querying the requested field: clcommon_Interest_Componentc.loanInterest_Posting_Day_c.”

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.

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

7.78 Event Reversal is not displaying the Principal Adjustment transactions as expected (Jira ID: PDRFF-830/ND-5435)

Issue Description

On clicking Event Reversal to reverse transactions, the system is not displaying the expected Principal Adjustment transactions. This is because internally the system is picking the ten oldest Principal Adjustment records instead of picking the ten latest Principal Adjustment records.

Expected Behavior

The system must display the latest ten Principal Adjustment transactions on clicking Event Reversal.

Resolution

This issue is now fixed. The system now displays the expected ten latest Principal Adjustment transactions on clicking Event Reversal.

7.79 Repayment Schedules are not getting generated in a Single Payment frequency contract after activation (Jira ID: PDRFF-889/ND-5423)

Issue Description

When a contract that has payment frequency selected as a Single Payment frequency is activated, the system is not generating repayment schedules.

This is because on activating the contract, internally, the system is incorrectly assigning the next cycle date as the current contract date, and because the payment frequency is Single Payment frequency, the Maturity Date is getting the value of the same current contract date resulting in no repayment schedules getting generated.

Expected Behavior

When calculating the Maturity Date with Single Payment frequency, the system must consider the First Payment Date as the Maturity Date.

Resolution

This issue is now fixed. The system now considers the First Payment Date as the Maturity Date in a loan where payment frequency is selected as Single Payment.

7.80 Payment Term and Repayment Schedule are not updated after Term Extension is made in a loan contract (Jira ID: PDRFF-696/ND-5408)

Issue Description

If a loan term is extended by updating the Term after going to Loan Quick Menu > Loan Actions > Term Extensions, the Payment Term and the Repayment Schedule are not getting updated to the new values.

This is because the system does not allow the term extensions for loans other than the Line of Credit product type of loan.

Resolution

This issue is now fixed. For all loans except the LOC loans, the system is now not displaying the Term Extensions menu after going to Loan Quick Menu > Loan Actions. And for LOC loans, if the term is extended by going to Loan Quick Menu > Loan Actions > Term Extensions, the system is correctly updating the new values for the Payment Term and Repayment Schedules.

7.81 Repayment Schedule is not getting updated after changing the Due Day (Jira ID: PDRFF-715/ND-5408)

Issue Description

If the Due Day of a loan is changed by going to Loan Quick Menu > Loan Actions > Change Due Day, the system is not updating the Repayment Schedule.

This is because the system regenerates the repayment schedules only for AMZ loans.

Resolution

This issue is now fixed.

On clicking Change Due Day in Loan Quick Menu > Loan Actions for all loans except the AMZ loans, the system is correctly displaying a message implying that the repayment schedule would not be regenerated for the corresponding product type contract.

For AMZ loans, on clicking Loan Quick Menu > Loan Actions > Change Due Day and then changing the Due Day, the system is updating the Repayment Schedule with new values.

7.82 Delinquent amount is getting incorrectly updated and the loan is delinquent even when all bills are satisfied (Jira ID: PDRFF-541/ND-5433/ND-5437)

Issue Description

If the Due Day of a loan is changed by going to Loan Quick Menu > Loan Actions > Change Due Day, the system is not updating the Repayment Schedule.

This is because the system regenerates the repayment schedules only for AMZ loans.

Resolution

This issue is now fixed.

On clicking Change Due Day in Loan Quick Menu > Loan Actions for all loans except the AMZ loans, the system is correctly displaying a message implying that the repayment schedule would not be regenerated for the corresponding product type contract.

For AMZ loans, on clicking Loan Quick Menu > Loan Actions > Change Due Day and then changing the Due Day, the system is updating the Repayment Schedule with new values.

7.83 The system is validating the creation of a child loan based on the Maturity Date instead of the Current Maturity Date (Jira ID: PDRFF-940/ND-5442)

Issue Description

If holiday treatment is applied to a Master Facility loan contract, and if the Current Maturity Date is shifted to a previous date as per the adjusting parameters, the system is displaying the following error message while creating a child loan:

“Child loans maturity date should be less than or equal to parent loan maturity date.”

This is because the system is comparing the Maturity Date of the child loan with the Maturity Date of the parent Master Facility loan contract instead of comparing the Current Maturity Date of the child loan with the Current Maturity Date of the parent Master Facility loan contract.

The system must allow the user to create a child loan because the Current Maturity Date of a single tranche term loan would be the same as the Current Maturity Date of the Master Facility loan contract.

Example of the Issue

Let us say we have a Master Facility loan product and a child loan product where the FIT flag is set to False. Let us say in both the products, the following values are set:

• Schedule Adjustment Method = After

• Move Across Month = False

Now let us say we create a Master Facility loan contract on a month end, such as January 31, 2021, and select the Maturity Date in such a way that it falls on a holiday, such as on May 31, 2021, which is a holiday.

After activating such a contract, the system updates the Current Maturity Date of the Master Facility loan contract to a day before the month end, which is May 28, 2021, because the Move Across Month flag is set to False.

Now let us try to create a child loan of the defined Master Facility loan contract. The system is displaying the following error message:

“Child loans maturity date should be less than or equal to parent loan maturity date.”

Resolution

This issue is now fixed. The internal logic has now been modified such that the system is now comparing the Current Maturity Date of the child loan with that of the Master Facility loan.

Now the system is not displaying any error messages when a child loan is getting created if there is holiday treatment applied to the respective Master Facility loan contract.

7.84 InterestPostingDynamicJob is displaying an error message while running (Jira ID: PDRFF-910/ND-5436)

Issue Description

In a single tranche term loan product, when payment frequency is Single Payment and Interest Posting Frequency is Billing Frequency, on running the InterestPostingDynamicJob, the system is displaying the following status error message:

Resolution

This issue is now fixed. The internal logic has now been updated and the InterestPostingDynamicJob is running successfully without any error messages.

7.85 The system is not applying the holiday treatment to the additional interest postings when the additional interest and regular interest frequencies are different (Jira ID: PDRFF-908/ND-5431)

Issue Description

When the Additional Interest Posting Frequency and the regular Interest Posting Frequency are different from each other, and if the Additional Interest Posting Date falls on a holiday, then the system is not moving it to a working date even when the holiday treatment is applied.

Example

Let us say we set up and activate a term loan contract with Additional Interest component on January 31, 2021.

Let the frequency of the additional interest posting and the regular interest posting be different.

The next IPD (Interest Posting Date) must fall on February 26, 2021, because February 27, 2021, and February 28, 2021, fall on a holiday.

Now after running the EOD DAG jobs one day before the IPD, the Interest Posting Date of the Additional Interest Component falls on February 28, 2021, which is a holiday.

The expected behavior is that the Interest Posting Date must fall on February 26, 2021, based on the Schedule Adjustment Method = After and Move Across Months = False.

Resolution

This issue is now fixed. If the additional interest frequency is greater than the Monthly frequency and even when it is not the same as the regular interest posting frequencies, the system is now applying the holiday treatment to the additional interest postings and the additional interest postings are not falling on a holiday.

7.86 The system is not reversing any LPTs even if one of the LPT reversal fails in a batch (Jira ID: PDRFF-439/ND-5230)

Issue Description

When attempting to reverse an LPT where there is a newer LPT, the system is throwing a general exception to let the user know that there is a newer LPT and not allowing the reversals of the rest of the LPTs.

For example, if the customers are inserting three reversals (for three separate contracts) as a partial, it is failing the whole batch.

Thus, on calling Database.insert with allOrNone parameter = false such as the following script:

then when one payment reversal is failing, the system is not allowing to insert other payment reversals. It is doing a full rollback.

The system should allow partial save of reversals. This will allow customers to process more reversals at larger batch sizes.

Resolution

This issue is fixed. Now if you try the same preceding script, the system is allowing reversals for other LPTs and only failed reversals are not being committed.

Example after the Fix

Let us see the following scenarios:

Scenario 1:

Now let us say we have passed the following set of IDs in the script:

• Second LPT of Loan1

• Loan2 LPT

• Loan3 LPT

Result: The system will reverse the LPTs of Loan2 and Loan3, and the system will display the following error in the logs for Loan1 as the second LPT is reversed before the third LPT of Loan1:

“You must reverse the last payment transaction”

Scenario 2:

Now let us say we have passed the following set of IDs in the script:

• LPT2

• LPT1

• LPT3

Result: The system will not reverse any LPTs of the whole batch as one of the LPTs is of the type principal adjustment.

Scenario 3:

Now let us say we have passed all the three preceding LPT IDs in the script:

Result: The system will log an error for the first LPT, and the other two LPTs will be reversed.

Scenario 4:

Now let us say we have passed all the three preceding LPT IDs in the script:

Result: The system will log an error for the first LPT, and the other two LPTs will be reversed.

8.   Known Issues

There are no known issues in the Spring’22 release of Q2 Loan Servicing and Q2 Marketplace.

9.   New and Modified Objects

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

9.1 New Objects

There are no new objects added in the Spring’22 release of Q2 Loan Servicing and Q2 Marketplace

9.2 Modified Objects

The following table describes the objects modified in the **Set in Target** release of **Set in Target**.

10.   New and Modified APIs

This section briefly describes the new and modified APIs in the **Set in Target** release of **Set in Target**.

10.1 New APIs

There are no new APIs added in the **Set in Target** release of **Set in Target**.

10.2 Modified APIs

There are no APIs modified in the **Set in Target** release of **Set in Target**.

11.   Global Methods

This section briefly describes the global methods that are added or modified in the **Set in Target** release of **Set in Target**.

The following table describes the global methods added/modified in the **Set in Target** release of **Set in Target**.

12.   Post GA Release

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

12.1 Issues fixed in 3.8004.3

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

Issue Description

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

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

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

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

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

12.2 Issues fixed in 3.8004.6

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

Issue Description

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

Let us say the FRI details are as follows:

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

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

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

Issue -1:

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

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

Issue -2:

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

Resolution

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

12.3 Issues fixed in 3.8004.27

12.3.1 Loan Payoff is not working after the Spring '22 upgrade for an FAMZ loan (Jira ID: PDRFF-1314/ND-5835)

Issue Description

After the Spring '22 upgrade, the Loan Payoff is not working for an FAMZ Loan. When we click the Loan Payoff, the system is displaying the following error message:

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

Example of the issue

Let us create a Flexi AMZ loan with a Payment Frequency of daily and a Payment Term of 396.

Let us say that the Interest Posting is enabled with frequency as daily.

When the loan status is in Active good standing or active bad standing, click the Loan Payoff button (or through the Loan Quick Menu action), the system displays the following error message:

Resolution

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

12.4 Issues fixed in 3.8004.31

12.4.1 The system is throwing an exception while reversing an LPT (Jira ID: ND-5398)

Issue Description

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

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

Resolution

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

12.5 Issues fixed in 3.8004.38

12.5.1 Out of order reversal functionality through ACH return file is not working for FAMZ loans (Jira ID: PDRFF-1010/ND-6008)

Issue 1

Issue Description

When trying to perform an out of order reversal through ACH return file for an FAMZ loan, it is failing with the following error message in the logs:

“Message: Insert failed. First exception on row 0; first error: FIELD_CUSTOM_VALIDATION_EXCEPTION, Rolling back the batch. Message - You must reverse the last payment transaction. Please check the activity log of loan - LAI-00001360 in Other Transaction view. - Cause null-1116: [].”

Example to understand the Issue

Let us say we have an existing FAMZ loan contract where five payments are already made. Let us try to reverse the third payment by uploading the ACH return file. While trying to process the ACH return file, the apex job, processACHreturnjob, is getting aborted with the following error message getting displayed in the log:

“Job Process ACH Return Job with Batch Job Id = 7073I00000luiVMQAY failed due to DMLException Message: Insert failed. First exception on row 0; first error: FIELD_CUSTOM_VALIDATION_EXCEPTION, Rolling back the batch. Message - You must reverse the last payment transaction. Please check the activity log of loan - LAI-00001360 in Other Transaction view. - Cause null-1116: [] Cause: null Stack…”

Reason

This issue was occurring as the value of Event Reversal Count was less and needed to be increased.

Resolution

This issue did not need a fix as the value in the Event Reversal Count field was less and it needed to have a higher value to accommodate the maximum number of event reversals that can be done in a loan.

Issue 2

Issue Description

In an FAMZ loan contract where there is an investor, if the Investor Payout Job is not run for the payments made, then, after reversing the required out of order payment, when the system is trying to reapply the next payments (LPTs), it is not able to do so throwing an exception.

Example to understand the Issue

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

1. Create an FAMZ loan contract with an investor.

2. Create three LPTs (LPT1, LPT2, LPT3).

3. Do not run the Investor Payout Job so that there is no Investor Loan Transaction (ILTID) created in the system.

4. Now reverse the oldest LPT, which is LPT1.

On reversing the oldest LPT, the system tries to reapply the LPTs following the oldest LPT. While reapplying the LPT2 and LPT3, the system is trying to find the ILTID for LPT2, but it is unable to find and is throwing the following exception: “LoanEventPaymentAction.process: line 57, List has no rows for assignment to SObjectCause.”

Reason

This issue is occurring as the system is unable to find an ILTID for the LPT to be reapplied and it is unable to find it as the Investor Payout Job is not run after making the payments.

Resolution

This issue is fixed now by making changes to the internal code. The system is now successfully able to reapply the LPT after reversing the required out of order LPT.

Issue 3

Issue Description

The system is creating an incorrect interest and principal amount in the ILTID while reapplying the LPTs after an out of order reversal of an LPT.

In the normal scenario, after payments are made in an FAMZ loan, on running the Investor Payout Job, the system creates the Investor Loan Transactions (ILTIDs) for the respective payouts to the investors. And on reversal of a payment, the corresponding ILTID also gets reversed.

Now, in this case, after the reversal of the corresponding ILTID, the system is updating incorrect interest-related values on the Investment Order (IO), and it is creating incorrect amounts of the principal, interest, and transaction on the new ILTID.

Example to understand the Issue

Let us assume that we have an FAMZ loan contract with an investor and let us make an out of order reversal.

Now due to the out of order reversal, the system reapplies the LPT. This LPT was originally created with Principal amount 118.34, Interest amount 31.91, and Transaction Amount 150.25, but while reapplying the LPT, the corresponding ILTD is created with Principal amount of 118.34, Interest amount of 6.4, and Transaction Amount of 124.74.

Thus, the Investor Order Balance Details section is updating incorrect field values for the following fields:

• Interest Remaining

• Interest Amount Paid

• Interest Balance

• Total Amount Paid

Reason

This issue is occurring because while reversing the out of order LPT of a past date, the interest-related fields (such as LAD, Accrued Interest, Interest Remaining) on the IO are getting updated to the values that were there on that past date of the LPT, resulting in an incorrect amount distribution for the ILTID for FAMZ loans.

Resolution

This issue is fixed as the internal logic was updated such that the ILTID reversal does not change the following:

• LAD on IO for FAMZ loan.

• The fields such as the Last Interest Accrual Date, Accrued Interest, Interest Remaining, and Interest Rounding Error on the IO.

Thus, now the system is creating correct amounts of the principal and interest on the ILTID while reapplying the LPTs after an out of order reversal of an LPT.

12.5.2 The system is throwing an exception while trying to reverse a payment (Jira ID: PDRFF-1465/ND-6009)

Issue Description

On upgrading to Spring’22 release, when a payment (LPT) is set for reversal in an FAMZ loan, the reversal is failing, and the system is throwing the following exception:

“Error processing payment reversal for contract - LAI-00000019 - Argument cannot be null.

CL010100: Unexpected DML Exception Insert failed. First exception on row 0; first error: FIELD_CUSTOM_VALIDATION_EXCEPTION.”

This is because the payment reversals that were created before the upgrade are failing due to the missing snapshot values corresponding to the new fields that were added in the Spring’22 release version.

Resolution

To fix this issue, null checks have been added within the code and the system will update the IOA fields on the contract after the payment reversal.

Thus, the issue is fixed, and the system is not throwing an exception while trying to reverse a payment

12.5.3 Backdated reversal is resulting in incorrect Next Due Dates and skipping of bills (Jira ID: PDRFF-1392/ND-5934)

Issue Description

When a backdated LPT is reversed, the following issues are seen:

• Due Date: The Next Due Date is getting updated incorrectly.

• Billing: Few bills are not getting generated and are skipped.

Example to understand the issue

Let us say that the system date is July 15, 2020.

On reversal, the Next Due Date updating to June 10, 2020, as expected because this is a backdated transaction, and when there is a backdated transaction, the bills generated after the backdated transaction date are discarded (marked as Non Primary in the product). So, the system has to again generate the bills for the June 10, 2020, and July 10, 2020. Hence the Next Due Date is updated to June 10, 2020. But after moving the system date to next day (July 16, 2020), and when the billing jobs are run, the Next Due Date should be updated to August 10, 2020, and not September 10, 2020. Thus, the system is skipping bill of August 10, 2020.

This is because, internally, the Actual_Next_Installment_Date__c is not getting updated from the snapshot upon the reversal action. Hence, the Next Due Date is moving ahead of the next bill causing the current upcoming bill to be skipped.

Resolution

To fix this issue, the Actual_Next_Installment_Date__c field is now getting updated correctly from the snapshot field.

Thus, the issue is fixed, and the system is updating the Next Due Dates correctly and not skipping bills after a backdated reversal.

12.6 Issues fixed in 3.8004.41

12.6.1 The system is throwing an exception while creating backdated LPT on a backdated disbursal date (Jira ID: PDRFF-1470/ND-6007)

Issue Description

For an existing Contract, when a backdated LPT is created on a backdated disbursal date, the system is throwing the following exception:

“Rolling back the batch. Message - You cannot process this transaction. Please check the activity log of the account - LAI-00011718. You need to reverse the posted transaction before processing this transaction. - Cause null-151 CL010100: Unexpected DML Exception Insert failed. First exception on row 0; first error: FIELD_CUSTOM_ VALIDATION_EXCEPTION, Rolling back the batch. Message - You cannot process this transaction. Please check the activity log of the account - LAI-00011718. You need to reverse the posted transaction before processing this transaction. - Cause null-151: [] at line 20.”

Example

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

1. Let us create an FIT Loan with the following details:

   • Loan Amount = $10,000

   • Payment Frequency = Monthly

   • Funding In Tranches = True

   • Payment Start Date = October 12, 2022

2. Let us now disburse this loan on October 12, 2022.

3. On October 25, 2022, let us try to create a backdated loan disbursement of amount = $1,000 for the Transaction Date October 23, 2022.

4. On October 25, 2022 let us try to create a backdated LPT for October 23, 2022

   The system is throwing the following exception:

   “Rolling back the batch. Message - You cannot process this transaction. Please check the activity log of the account - LAI-00011718. You need to reverse the posted transaction before processing this transaction. - Cause null-151 CL010100: Unexpected DML Exception Insert failed. First exception on row 0; first error: FIELD_ CUSTOM_VALIDATION_EXCEPTION, Rolling back the batch. Message - You cannot process this transaction. Please check the activity log of the account - LAI- 00011718. You need to reverse the posted transaction before processing this transaction. - Cause null-151: [] at line 20”

Resolution

The issue is fixed and now the backdated Loan Payment Transaction is getting created successfully on a backdated disbursal date without any exceptions.

12.7 Issues fixed in 3.8004.42

12.7.1 ACH Debit Date is getting changed when a Payment reversal or backdated reversal is done (Jira ID: PDRFF-1615/ND-6123)

Issue Description

While making a payment reversal or a backdated reversal, the ACH Debit Date is changing to a backdated due date if ACH frequency is same as Billing frequency. ACH Debit Date should not move backwards.

Resolution

The issue is fixed now and ACH Debit Date is not getting changed when a payment reversal is done.

12.7.2 ACH payment is not applied when there is a floating rate change on the Due Date (Jira ID: PDRFF- 1527/ ND-6019)

Issue Description

If there is a Floating Index Rate change on a Due Date that is same as the billing and the Automated Payment Setup (APS) Debit Date, then the ACH payment is not applied. This is because the APS Debit Date is getting incorrectly updated to the Actual Next Installment Date when the Floating Rate changes on the same date as billing and APS debit date.

When the Billing, Floating Index Rate change and APS payment, all fall on same date every time, the floating rate change job performs an index rate change and reschedules the contract thereby updating the APS Debit Date to the Next Due Date and skipping the ACH payment for the current date.

Example

The issue is occurring when there is a floating index rate change on the same date as the billing and the APS Debit Date.

Let us say that following is the floating rate and the loan configuration:

• Interest Type = Floating

• Interest Rate Change Method = Keep Same Payment Amount

• Is Interest Posting Transaction Enabled = True

• Is Capitalization Enabled = True

• Interest Posting Frequency = Billing Frequency

• Floating Rate Revision Frequency = Billing Frequency

• Floating Rate Revision Date = January 15, 2022.

• Floating Rate Revision Date Actual = January 15, 2022

• Payment Mode = ACH

• Amount Type = Last Billed Amount

Because of this configuration, the billing, floating index rate change and APS payment, all fall on the same date every time as they are at the Billing Frequency.

In the system, first the Billing Job runs followed by the Floating Rate Change Job (FloatingRateInterestRevisionDynamicJob) and then the payment creation job (LoanPaymentTransactionCreationDynamicJob).

This is explained as follows:

1. Billing job changes the Next Due Date to the next bill date as expected.

2. Floating rate change job (FloatingRateInterestRevisionDynamicJob) performs an index rate change and reschedules the contract. As part of this, the system updates the APS Debit Date to the Actual Next Installment Date.

3. When the payment creation job (LoanPaymentTransactionCreationDynamicJob) runs, the APS Debit Date would have already advanced to the Actual Next Installment Date, hence, the current due date's payment is not created.

Thus, the APS Debit Dates are updated to the Actual Next Installment Date on the contract when you reschedule a loan (because the billing frequency expects them to be in sync).

This is a correct behavior when you are changing the payment date on rescheduling, but this is not required in floating rate change job as we do not expect a payment date to change. The ACH payment must be applied to the contract. But the Floating rate change job performs index rate change and reschedules the contract.

As part of this, the system updates APS Debit Date to the Actual Next Installment Date.

Resolution

The issue is fixed by skipping the updating of the APS Debit Date in the floating rate change job (FloatingRateInterestRevisionDynamicJob). Thus, the floating rate change does not update the due dates.

Hence, the APS Debit Dates will not be changed when the frequency is Billing Frequency.

12.8 Issues fixed in 3.8004.43

12.8.1 The Loan Payment Spread preference is not working properly (Jira ID: PDRFF-1591/ ND-6227)

Issue Description

When an FAMZ loan is written off, the loan Payment Spread preference is not working as per the details defined in the Payment Spread.

Example

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

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

   • Payment frequency = Daily or Weekly

   • Attorney fee charge amount = $500

   • Attorney fee charge paid flag = False

2. Let us Run the SOD/ EOD Job and the Loan Payment Transaction Job.

3. Let us write off the loan before the maturity date.

   When a loan is written off, the system should perform the following actions:

   • Write off principal.

   • Write off Interest (Interest accrued but not paid)

   • Pre closure charges (Unaccrued unpaid interest till maturity from the write off date)

     The current Q2 system does not consider unaccrued interest for write off or payoff if done before maturity.

   • The system will create write off record under the other transaction tab.

   • The system will create a pre closure charge under the fee transaction tab.

4. Let us manually create an attorney fee charge under the Fee transaction tab.

5. Now let us make a payment for the attorney fee charge with payment mode- Attorney fee and with a payment spread- Attorney fee, Principal, Interest and fee.

   The attorney fee payment must update the attorney fee charge record.

   But the attorney fee charge is getting applied to the write off related fee component.

Resolution

The issue is fixed now and the payment is getting correctly applied to the defined loan spread.

12.9 Issues fixed in 3.8004.44

12.9.1 The system is displaying an error message when an existing contract is rescheduled (JIRA ID: PDRFF- 1737 /ND-6247)

Issue Description

When an FAMZ contract that has Interest only period less than the contract term, is rescheduled the system is displaying the following error message:

"Update failed. First exception on row 0 with id a7o7F000000GoHsQAK; first error: CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY, loan.LoanAccountTrigger: execution of BeforeUpdate caused by: loan.LoanProcessingException: Interest Only Period should be less than the contract term."

Example to understand the issue

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

   • Loan Amount = $10,000

   • Contract Start Date = March 21, 2020

   • Payment Frequency = Monthly

   • Interest Posting Transaction Frequency = Monthly

   • Term = 11 months

   • Interest Rate = 10%

   • Interest Only Period = 0 months

   • Delinquency Grace Days = 7

2. Let us move the SOD to the next billing date which is April 21, 2020.

3. Now let us reschedule the loan with following parameters:

   • Maintain Delinquency = True

   • Interest Only period = 10 Months

   • Number of Installments =11

The loan should be rescheduled successfully.

But the loan is not getting rescheduled and the system is displaying the following error message:

"Update failed. First exception on row 0 with id a7o7F000000GoHsQAK; first error: CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY, loan.LoanAccountTrigger: execution of BeforeUpdate caused by: loan.LoanProcessingException: Interest Only Period should be less than the contract term."

Resolution

This issue is fixed, and the loan is getting rescheduled without any error message.

12.10 Issues fixed in 3.8004.50

12.10.1 The Interest Remaining field value is getting incorrectly reflected after the first rescheduled transaction (JIRA ID: PDRFF-1605/ ND-6292 / ND- 6293)

Issue Description

In an FAMZ loan, when an excess threshold Loan Payment Transaction is reversed, the system is calculating the Interest Remaining field value incorrectly.

Example to understand the issue

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

   • Loan Amount = $60,000

   • Contract Start Date = August 27, 2020

   • Payment Frequency = Monthly

   • Term = 12 months

   • Interest Rate = 16%.

2. Let us go to September 3, 2020, and reschedule the contract.

   The Interest Remaining and Last Accrual Date field values are updated.

3. Let us go to September 10, 2020, and create an LPT of $5,000 with the Transaction Date as September 10, 2020, and clear it.

   The Rescheduled Threshold Crossed flag is set to true in LPT, hence the complete payment goes towards the principal and the Reschedule Status is updated to Pending.

4. Now let us go to September 11, 2020.

   The SOD Jobs run, and the contract is rescheduled.

5. Reverse the LPT of $5,000 created in step 3.

6. Now let us go to October 27, 2020.

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

   The Interest values should be calculated as follows:

   • Interest Posted = $1,600

   • Interest Remaining = $1,600

   However, the system is calculating the values as follows:

   • Interest Posted = $1,600

   • Interest Remaining = $1,760

So, as we see, the Interest Remaining field value on the contract after the first reschedule, is getting calculated incorrectly.

Resolution

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

12.10.2 Interest Remaining is getting updated incorrectly when an ad hoc payment is reversed (Jira ID: PDRFF- 1495/ND-6299/ ND-6302)

Issue Description

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

Example of the Issue

Let us perform the following steps to understand this issue:

1. Let us create an FAMZ Lending Product with the following details:

   • Excess Threshold % for Reschedule = 1%.
     

     Note:

     The Reschedule Status field is used to mark the loans that are to be rescheduled when an LPT amount is higher than the threshold defined in Excess Threshold % for Reschedule. All such loans will be rescheduled in EOD processing.

   • Payment Application Mode = Future Dues

2. Let us create a contract on August 3, 2012, with the following details, and disburse it:

   • Loan Amount = $10,000.

   • Interest Rate = 10%.

   • Payment Frequency = Monthly.

     This sets the First Payment Date to September 3, 2012, and the Amortization Schedule gets generated for the following dates: September 3, 2012, October 3, 2012, November 3, 2012, till August 3, 2013, and the Due Amount for each schedule is $879.19.

3. Now let us go to August 13, 2012.

   It is observed that the system accrues the interest from August 3, 2012, to August 13, 2012, and the value is as follows:

   • Interest Accrued = $27.40. = 10,000 * 10/365 * 10/100.

4. Now let us create an ad hoc payment of $1,000 with the Transaction Date as August 13, 2012, and clear it.

   The system updates the contract's Reschedule Status to Pending because of this payment.

5. Let us go to August 14, 2022.

   It is seen that the system reschedules the contract successfully and updates the Interest Remaining field value. The system updates the contract fields as follows:

   • Principal Remaining = $9,000.

   • Principal Paid = $1,000.

   • Last Accrual Date = August 13, 2012.

   • Interest Remaining = $27.40

   • Interest Accrued = $2.46. (This is interest accrued for 1 day.)

   • Reschedule Status = Success

   • The Amortization Schedule also gets generated for the following dates: September 3, 2012, October 3, 2012, November 3, 2012, till August 3, 2013, and the Due Amount for each is $791.51.

6. Let us go to August 26, 2012.

   It is seen that the system accrues the interest from August 14, 2012, to August 26, 2012, as per the new schedule, and the values are as follows:

   • Interest Remaining: $27.40.

   • Interest Accrued: $32.05.

7. Now on August 26, 2012, let us reverse the ad hoc payment that was created in step 4.

   This should update the values as follows:

   • The Amortization Schedule should revert to the original one with the same following dates: September 3, 2012, October 3, 2012, November 3, 2012, till August 3, 2013, and the Due Amount for each schedule should be as the original one, which is $879.19.

   • Interest Remaining = $0.

   • Interest Accrued = $63.01. The interest is to be calculated on the original principal amount which is $10,000.

   • Principal Remaining = $10,000.

   • Principal Paid = $0.

8. Let us go to the next payment date, which is September 3, 2012.

   The Interest Remaining should be updated to $84.93, but this is not the case.

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

Resolution

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

12.10.3 The Interest Remaining is incorrectly calculated when payments are skipped (Jira ID: PDRFF-1586 /ND-6315)

Issue Description

In an FAMZ contract, when payments are skipped, the Interest Remaining field is not updated correctly.

Example

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

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

   • Amount = $100,000

   • Contract Date: January 3, 2020

   • Payment Frequency: Monthly

   • First Payment Date: May 13, 2020

   • Term: 60 Months

   • Interest Rate: 8%.

2. Let us go to February 3, 2020.

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

3. Let us create a Loan Payment Transaction on February 3, 2020, and clear the bill for that period.

   1. Now let us go to February 7, 2020, and create a rescheduling transaction on February 7, 2020, with Repayment Start Date as August 3, 2020.

      This should update the values as follows:

      • The system calculates the Interest on the scheduled balance from February 3, 2020, to August 3, 2020. The amount will be more than the payment amount, which is $2,027.64.

      • Since the Interest Remaining is more than the payment amount, the system distributes the calculated Interest Remaining value in subsequent schedules.
        

        Note:

        August and September will be Interest only Payments.

      • As per the new Amortization Schedule dated August 3,2020, the new Interest is $2,094.47, but the actual Interest is $3600. The difference in interest $1,600 will be adjusted in the next schedule.

        1. Now let us go to August 3, 2020.

           It is observed that the system creates a bill as per the schedule and the Interest Remaining is calculated as per the schedule, but the actual Interest Remaining value is $1,600.

           Note:

           The actual Interest is not getting added anywhere because this amount is collected in the next schedule.

4. Let us create a payment transaction on August 3, 2020, and clear the bill for that period.

   The Interest Remaining will be zero.

5. Let us reschedule the contract on August 3, 2020.

   The system should calculate a correct Principal amount and the Interest Remaining value as $1,600.

   But the system only calculates a correct Principal and updates the Interest Remaining field as zero and ignores the remaining $1600.

Resolution

The issue is fixed now, and the system is updating the Interest Remaining field correctly.

12.10.4 The Interest Remaining field value is updated incorrectly when Installment Payment is created on a delinquent contract (Jira ID: PDRFF-1379/ND-6306, ND-6307)

Issue Description

When Installment Payment is created on a delinquent FAMZ loan contract, the Interest Remaining is getting doubled and thus the value is incorrect.

Example to understand the issue

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

   • Loan Amount = $10,000

   • Time Counting Method = Actual Days

   • Pre Bill Days = 28 Days

   • Contract Start Date = January 18, 2022

   • Payment Frequency = Monthly

   • Interest Posting Frequency = Monthly

   • Term = 10 months

   • Rate = 10%

   • Interest Posting Enabled = True

   • Now, as we move on to February 21, 2022, two bills will be created: The February 18, 2022, bill and the March 18, 2022, bill due to the Pre Bill Days defined as 28 (Bills will get generated 28 days before the due date.)

     Note:

     This is the interest part of the previous cycle from January to February calculated as follows: $10,000 * 31 * 10/36500 = 84.93

   • Then, on the same day (February 21, 2022), let us create a payment with the following details of the LPT:

     • Transaction Amount = 84.93

   • Transaction Date = February 21, 2022

2. Let us move on to March 18, 2022.

3. As Interest is posted on March 18, the LAD is March 18, and thus the interest accrued till now will be moved to Interest Remaining.

   The correct Interest Remaining must be calculated as follows: 9,038.78 * 28 * 10/36500 = $69.34.

   Note:

   The interest is calculated on the Schedule Balance, which is: $10,000 - $961.22 = $9,038.78, where $961.22 is the principal due of the previous cycle, $84.93 is the interest due.

   But we see that the Interest Remaining is getting incorrectly calculated as: 2 * (9,038.78 * 28 * 10/36500) = 2 * 69.34 = $138.68.

   This issue was occurring the IPT that was closed was getting posted again and hence due to the IPT amount being twice the actual value, the Interest Remaining was also getting calculated as twice the actual amount.

Resolution

This issue is fixed as the logic has been updated to restrict the posting of the IPT that is already closed. Thus, the Interest Remaining is updated correctly after the installment payment.

12.10.5 The LPT and bills are not getting generated if a manual payment is done before the bill due date (Jira ID: PDRFF-1817 / ND-6290)

Issue Description

When a loan payment transaction is done manually before a bill due date, the system is not generating the LPT and bill for the upcoming billing cycle.

Example to understand the issue

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

   • Loan Amount = $10,000

   • Contract Start Date = January 10, 2020

   • Days ahead to generate ACH = 6 Days

   • Pre bill days = 6 Days

   • Excess Threshold % for Reschedule = 0.00

   • Payment Frequency = Monthly

   • Term = 12 months

2. Let us go to February 4, 2020, and Run the SOD/ EOD Job.

   The system generates a bill and LPT-1 is created.

3. Now let us go to February 5, 2020, and make an excess LPT-2 with value higher than the bill amount.

4. Now let us go to March 4, 2020, and Run the SOD/ EOD Job.

   The system generates a bill-2 and LPT-2 is created.

   However, the system is not generating the bill and not creating LPT for the next billing cycle.

Resolution

The issue is fixed now, a bill is being generated, and LPT is being created for the subsequent billing cycle.

12.10.6 The system is not allowing to edit the fields on the Repayment Transaction Reversal Detail section (Jira ID: PDRFF-1596 / ND-6304)

Issue Description

When the Edit button on the Repayment Transaction Reversal Detail section is clicked, the system is displaying the following error message:

“Error: SObject row was retrieved via SOQL without querying the requested field: loan_ Repayment_Transaction_Adjustmentc.loanLoan_Payment_Transaction_c”

The issue is observed when the content is viewed in Visualforce page in lightning theme.

Resolution

The issue is fixed now, and on clicking the Edit button, the system is not displaying any error message.

12.11 Issues fixed in 3.8004.52

12.11.1 The Additional Interest Component is not getting considered (Jira ID: PDRFF-1589 / ND-6337)

Issue Description

While calculating the investor's available funds for the investor payments, the Additional Interest Component specified on the Investment Order is not being considered for the calculation.

Example to understand the issue

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

   • Priority = 1

   • Share = 100%

   • Contract Start Date = January 10, 2021

2. Let us create an investment order with AIC component on both loan and IO with interest bearing principal as delinquent amount.

3. Let us go to Feb 10, 2021, and run the IO Accrual and Interest Posting Jobs.

   The system generates a bill.

   Let us not clear the bill 1. This makes the loan delinquent.

4. Now let us go to March 10, 2021, and run the IO Accrual and Interest Posting Jobs.

   The system generates a bill.

5. Let us clear bill 2.

   An amount equal to the ILTID is added to the investor's available balance. (Principal + Interest - Total Service Charge + AIC)

   However, AIC is not included when the available balance in the Investor Account is updated. If AIC is not included, the investor's available balance is updated with the value (Principal + Interest - Total Service Charge).

Resolution

This issue is fixed now, and the AIC component is being considered while calculating the investor's available funds for investor payment.

12.12 Issues fixed in 3.8004.60

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

Issue Description

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

Resolution

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

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

Issue Description

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

Example to Understand the Issue

1. Let us create a Flexible AMZ contract with the following details:

   • Billing Method = Declining Balance

   • Payment Frequency = Monthly

   • Time Counting Method = Month and Days

   • Accrual Start Basis = Contract Dates

   • Payment Application Mode = Current Dues

   • Payment Application Order = Date

   • Default Term = 12

   • Interest Type = Fixed

   • Interest Rate Change Method = Change Payment Amount

   • Default Interest Rate = 10%

   • Repayment Procedure = EMI

   • Is Interest Posting = true

   • Interest Posting Frequency = Monthly

   • Pre Bill Days = 5

   • Excess Threshold % for Reschedule = 5.00

   • Reschedule Option on Excess Payment = Keep Same Payment Amount

   • Loan Amount = $10,000

   • Current System Date = January 1, 2013

   • Payment Start Date = February 1, 2013

   • Accrual Start Basis = January 1, 2013

2. Let us approve and disburse this contract.
   An AMZ schedule gets created with an EMI amount of $879.16.

3. Let us move to the fourth bill date of May 1, 2013.
   
   The various parameters on a loan contract get updated as follows:
   

   • LAD = May 1, 2013

   • Interest Posted = 0.00

   • Interest Remaining = $293.32

   • Interest Accrued = 0.00

   • Principal/Advance Remaining = $10,000

   • Four bills get generated with an amount of $879.16 each(All bills are primary)

   • Following five IPTs get created:

     • Four IPTs in the Closed status

     • One IPT in the Open status with due date of June 1, 2013.

4. Now let us create a back dated LPT with the following details:

   • Transaction Date = March 1, 2013.

   • Transaction Amount = $4,000 (This must cross the Excess Threshold % for Reschedule of 5% as defined earlier.)

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

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

Resolution

This issue is fixed.

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

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

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

Issue Description

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

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

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

Example to Understand the Issue

1. Let’s assume the following FAMZ contract is created:

   • Current System Date = June 18

   • Pre Bill Days = 5

   • First Payment Date = July 18

   • Next Due Generation Date = July 13

Resolution

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

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

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

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

Issue Description

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

Example to Understand the Issue

1. Let us create a Flexible AMZ contract with the following details:

   • Interest Rate = 10%

   • Time Counting Method = Month and Days

   • Is IPT Enabled = true

   • Interest Posting Frequency = Single-Payment Frequency

   • Interest Period Calculation = Include Start Date

   • FIT = true

   • Loan Amount = $10,000

   • Term = 1

   • Contract Start Date = September 22, 2013

   • First Payment Date = October 22, 2013

2. Let us approve and disburse this contract.

3. Let us move two days ahead to September 24, 2013.

   Expected behavior: The various fields on the loan contract must reflect the following values:

   • LAD = September 22, 2013.

   • Interest Remaining = $2.78.
     
     This is one day's interest = 10,000 * 10/100 * 1/360 = 2.78 as the interest calculation includes the start date of the calculation period.

   Observed behavior: But the observed behavior is as follows:

   • LAD = September 21, 2013.

   • Interest Remaining = 0.

   This same issue has been observed with a contract with 10 terms too.
   

Resolution

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

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

Issue Description

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

"Error:

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

Example to Understand the Issue

1. Let us create a Flexible AMZ contract with the following details:

   • Billing Method = Declining balance

   • Payment Frequency = Monthly

   • Time Counting Method = Month and Days

   • Accrual Start Basis = Contract Dates

   • Payment Application Mode = Current Dues

   • Payment Application Order = Date

   • Default Term = 12

   • Interest Type = Fixed

   • Interest Rate Change Method = Change Payment Amount

   • Default Interest Rate = 10%

   • Repayment Procedure = EMI

   • Is Interest Posting Enabled = true

   • Interest Posting Frequency = Monthly

   • Pre Bill Days = 5

   • Excess Threshold % for Reschedule = 5.00

   • Reschedule Option on Excess Payment = Keep Same Payment Amount

   • Loan Amount = 10,000

   • Payment Start Date = February 2, 2013

   • Accrual Start Date =January 2, 2013

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

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

3. This updates the amortization schedule in the following way:
   
   

• The first three terms display an amount of $900.

• The next three terms display an amount of $879.16.

• The other six terms display an amount of $868.07.

• The last schedule display the balance as zero.

4. Let us approve and disburse this contract.

5. Then, on the same day, let's reschedule the loan contract by updating the values as follows:

   • Transaction Date = February 1, 2013

   • Interest Only Period = 0

   • Repayment Start Date = February 2, 2013

   • Payment Frequency = Monthly

   • Maintain Delinquency = true

6. Let us edit the first row of the Flexible Repayment Plan as follows and try to save this Rescheduling:
   
   

   Sequence	Payment Type	Payment Amount	Number of Payments	Payment Start Date
   1	Equal Monthly Installments	$1,000	3 (non-editable)	February 2, 2013 (non-editable)

7. The system is not able to reschedule and displays an error message as follows:
   
   "Error:

   CL010101: Unexpected Exception SObject row was retrieved via SOQL without querying the requested field: loan_Loan_Accountc.loanRevolving_c at line 139"
   
   Instead, the system must update the amortization schedule with the following values:

   • The first three terms with an amount of $1,000.

   • The next three terms with an amount of $879.16.

   • The remaining terms with amount of $814.86.

   
   Thus, the old schedule must get archived, and the new must be created.
   

Resolution

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

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

Issue Description

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

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

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

Example to Understand the Issue

1. Let us create a Flexible AMZ contract with the following details:

   • Loan Amount = $10,000

   • Terms = 3

   • Rate = 10%

   • Time Counting Method = Month & Days

   • Payment Frequency = Monthly

   • Interest Posting Frequency = Monthly

   • Contract Start Date = January 1, 2022

2. Let us approve and disburse this contract.

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

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

Resolution

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

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

Issue Description

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

Example to Understand the Issue

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

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

   • Loan Amount = $10,000

   • Interest Posting Frequency = Monthly

   • Contract Start Date = March 21, 2013

   • Terms = 10

   • Interest Rate = 10%

   • Time Counting Method = Month and Days

   • Transaction Approval Configuration > Payments = true

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

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

Expected behavior:

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

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

Resolution

This issue is fixed.

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

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

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

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

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

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

Issue Description

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

Example to Understand the Issue

1. Let us create a Flexible AMZ contract with the following details:

   • Contract Start Date = August 29, 2021

   • Pre Bill Days = 5

   • Payment Start Date = September 29, 2021

   • Next Due Generation Date = September 24, 2021

2. Let us move to the end of day of September 24, 2021 (You can move the EOD batch to September 24, 2021 to do this.)

   The bill gets generated.

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

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

Resolution

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

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

Issue Description

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

Example to Understand the Issue

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

   • Contract Start Date = January 1, 2013

   • Loan Amount = $10,000

   • Interest Rate = 10%

   • Term = 10

   • Is Interest Posting = True

   • Payment Frequency = Monthly

   • Interest Posting Frequency = Monthly

   • Disbursal Date = February 1, 2013

   • Payment Start Date = March 1, 2013

2. Let us go to February 1, 2013, and approve and disburse this contract.

3. Move a few days ahead so that the interest gets accrued. Let us say we have moved to February 25, 2013.
   This updates the Interest Accrued to $66.67.
   

4. Make a Loan Payoff by creating a payoff transaction of $10066.67 and clear it.

   Note:

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

   The Interest Accrued of $66.67 is paid and hence Interest Accrued must be 0 and Interest Paid must be $66.67.

5. Reverse the payoff and verify Interest Accrued and Interest Remaining field values.
   
   Expected behavior: After reversing the payoff, the Interest Remaining must reflect the correct amount based on the reversal and the Interest Accrued must get back to the previous state as follows:

   • Interest Paid = 0

   • Interest Accrued = $66.67

   • Interest Remaining = 0
     

   Observed behavior: After reversing the payoff, the Interest Accrued and the Interest Remaining are reflecting incorrect values because the system was considering the Loan Balance incorrectly during the reversal process.
   

Resolution

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

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

Issue Description

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

Example to Understand the Issue

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

   • Contract Start Date = June 18, 2022

   • Loan Amount = $10,000

   • Interest Rate = 6%

   • Term = 3

   • Is Interest Posting = true

   • Payment Frequency = Daily

   • Interest Posting Frequency = Daily

   • Payment Start Date = June 19, 2022

   • Time Counting Method = Actual Days

   • Accrual Start Basis = Disbursal Date

   • Payment Application Mode = Current Dues

   • Payment Application Order = Date

   • Accrual Based Accounting = true

   • Accrual Entry Frequency = Daily

   • FIT = True

   • Draw Billing Method = Interest Only

   • Interest Rate Change Method = Keep Same Payment Amount

2. Let us approve and disburse the loan.
   

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

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

Resolution

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

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

Issue Description

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

Example to understand the issue

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

   • Contract Start Date = January 1, 2013

   • Loan Amount = $10,000

   • FIT = True

   • Interest Rate = 5%

   • Term = 10

   • Interest Period Calculation = Include Start Date

   • Is Interest Posting = True

   • Payment Frequency = Monthly

   • Accrual Start Basis = Disbursal Date

   • Interest Rate Change Method = Change Payment Amount

   • Interest Posting Frequency = Monthly

   • Payment Start Date = February 2, 2013

2. Let us go to February 2, 2013, approve and disburse the loan contract.

   The Interest Remaining must be = $1.39

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

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

Resolution

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

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

Issue Description

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

Example to understand the issue

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

   • Time Counting Method = Month and Days

   • Default Interest Rate = 10

   • Is Interest Posting = true

   • Interest Posting Frequency = Monthly

   • Excess Threshold % for Reschedule = 0

   • Reschedule Option on Excess Payment = Keep Same Payment Amount

   • Contract Start Date = March 1, 2022

   • Loan Amount = 10,000

   • Term = 10

   • Interest Rate Change Method = Change Payment Amount

   • Payment Frequency = Monthly

   • Payment Start Date = February 3, 2022

2. Let us approve and disburse the loan contract.

3. Let us create an LPT with Transaction Amount = $200. (Reschedule Threshold Crossed on the LPT is true.)

4. Let us try to update Reschedule Threshold Crossed to false and save it.
   

   The system must not allow you to change the value of this flag, but the system allows you to change this flag.

5. Let us go to the next day and reverse the LPT created.
   
   The Amortization Schedules are not reverting back to the previous schedules as the Reschedule Threshold Crossed flag is set to true.

Resolution

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

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

Issue Description

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

Example to Understand the Issue

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

   • Contract Start Date = January 1, 2013

   • Payment Frequency = Monthly

   • Interest Posting Frequency = Monthly

   • Default Interest Rate = 10%

   • Reschedule Option on Excess Payment = Keep Same Payment Amount

   • Excess Threshold % for Reschedule = 0.00

   • Terms = 10

   • Time Counting Method = Month And Days

   • Loan Amount = $10,000

2. Let us approve and disburse the loan contract.

3. Now let us go to the first bill date February 1, 2013.

   The system generates the following:

   • Bill 1 of $1046.4

   • IPT 1 of $83.33

4. Now let us create an LPT of $1,046.4 for the first bill.

5. Let us go to February 15, 2013, and make a payment (LPT) of $2,000, which is higher than the bill amount.
   This updates the following:
   

   • Interest Accrued = $35.14

   • Interest Paid = $83.33

   • Reschedule Status = Pending

6. Let us go to the next day, which is February 16, 2013, to run the SOD/EOD jobs for rescheduling. (Ensure that the LoanRescheduleDynamicJob or LoanRescheduleJob as part of the SOD/EOD Job is trigger the automatic reschedule.)

   This updates the following:

   • Reschedule Status = Success

   • Reschedule transaction (OLT of the Transaction Type, Reschedule) gets created with the Maturity Date as blank, which is incorrect.

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

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

Resolution

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

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

Issue Description

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

Example to Understand the Issue

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

   • Payment Frequency = Monthly

   • Interest Posting Frequency = Monthly

2. Move the system date by a few days ahead.

3. Make a payment for the contract with the Spread Manually Flag set to true such that the entire amount must go towards the principal component.

4. On saving this payment transaction, the LPT is cleared.

   Note:

   The Reschedule Threshold Crossed is set to false.

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

Resolution

This issue is now fixed.

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

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

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

Issue Description

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

Example to Understand the Issue

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

   • Loan Amount = $10,000

   • Contract Start Date = January 1, 2013

   • Payment Start Date = February 1, 2013

   • Payment Frequency = Monthly

   • Interest Posting Frequency = Monthly

   • Excess Threshold % for Reschedule = 5.00

   • IPT enabled = True

   • Pre-bill days = 5

   • Interest Rate Change Method = Change Payment Amount

2. Let us approve and disburse the loan contract.
   AMZ schedule gets created with EMI amount = $879.16.
   

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

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

Resolution

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

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

Issue Description

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

Example to Understand the Issue

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

   • Loan Amount = $60,000

   • Contract Start Date = August 27, 2012

   • Payment Frequency = Monthly

   • Term = 12 months

   • Interest Rate = 16%

   • Pre Bill Days=15

2. Let us go to September 3, 2012, and reschedule the contract by updating the Repayment Start Date as October 27, 2012.

   The Interest Remaining and Last Accrual Date field values are updated to $160 and September 3, 2012, respectively, and the amortization schedules are accordingly generated.

3. Let us go to September 10, 2012, and create an LPT of $5,000 with the Transaction Date as September 10, 2012, and clear it.
   Interest Accrued is updated to $186.67 for 7 days (from September 3 to September 7).
   LAD is updated to September 10, 2012.
   

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

4. Now let us go to September 12, 2012.

   The SOD jobs run, and the contract is rescheduled.

   Interest Remaining is updated to $346.67 and Interest Accrued is updated to $48.89.

5. Reverse the LPT of $5,000 created in step 3.
   
   The expected behavior must be as follows:

   • Interest Remaining = $160

   • LAD must change from September 10, 2012, to September 3, 2012.

   • Interest Accrued must be recalculated from September 3 to September 12 as $240.

   • Old IPT must be discarded and a new IPT must be created in an Open status.

   • LAD on new IPT must be set to September 9, 2012.

   But the actual behavior observed is as follows:

   • The LPT is reversed but the Interest Remaining is not getting updated correctly in the open IPT after the excess threshold LPT reversal. Interest Remaining remains unchanged as $346.67.
     

   • LAD is not updated to September 3, 2012. It remains unchanged.

   • Hence, many other fields are also getting incorrectly updated.
     

6. Now let us go to October 27, 2012.

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

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

Resolution

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

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

Issue Description

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

Example to Understand the Issue

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

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

   • Amount = $100,000

   • Contract Date = January 3, 2022

   • Payment Frequency = Monthly

   • First Payment Date = February 3, 2022

   • Term = 60 Months

   • Interest Rate = 8%

   • Pre-Bill Days = 28

2. Let us go to February 3, 2022.

   It is observed that the system generates a bill as per the schedule.
   AMZ schedule amount is 2,027.64 (where Principal = 1,360.97 and Interest =666.67.)
   

3. Let us pay and satisfy the bill of $2,027.64.
   

4. Now let us go to February 7, 2022, and reschedule the loan to change the Repayment Start Date to August 3, 2022 by going to Loan Actions > Reschedule > Transaction Date = 2/7/2022, Repayment Start Date = 8/3/2022.
   This way we are skipping months for payment to August 3.

   Note:

   August and September are Interest only Payments.

5. Move the system date to August 3, 2022.
   

6. Create a payment transaction of amount 2,094.47.

7. Let us reschedule the loan to change the Repayment Start Date to September 3, 2022, by going to Loan Actions > Reschedule > Transaction Date = 8/3/2022, Repayment Start Date = 9/3/2022.

8. The following are observed:

   • The system calculates the interest from February 3, 2022, to July 3, 2022 on the scheduled balance as follows = 98,639.03 * 8/100 * 150/360 = 3,287.98 and assigns it to the Interest Remaining. (where 98,639.03 = 100,000 - 1360.97.)

   • This amount is more than the payment amount, which is $2,027.64. Hence, the system distributes the calculated Interest Remaining value in subsequent schedules by deducting the remaining interest amount to be paid from the due Amount in each schedule till there is no more interest left. Thus this interest of 3,287.98 must get split in the next schedules August 3, 2022, September 3, 2022, and October 3, 2022 schedules as 1436.88 + 1436.88 + 414.22 = 3287.98. You can refer to the following image.
     

9. After clicking Preview to preview the rescheduling:

   • The interest of the September 3, 2022, schedule must have the interest = 2,094.47 as seen in the following schedule ( = 1436.88 + 657.59). But this is not the case, and so Interest Remaining is getting incorrectly calculated when moved to the next due date, which is September 3, 2022.

   • The interest of the October 3, 2022, schedule must have the interest = 1,071.81 ( = 657.59 + 414.22). But this is not the case, and so Interest Remaining is getting incorrectly calculated when moved to the next due date, which is October 3, 2022.

   

Resolution

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

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

Issue Description

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

Example to Understand the Issue

Let us perform the following steps to understand this issue:

1. Let us create an FAMZ Lending Product with the following details:

• Excess Threshold % for Reschedule = 1%.

• Payment Application Mode = Future Dues

2. Let us say we create a contract on August 3, 2012, with the following details, and disburse it:

• Loan Amount = $10,000.

• Interest Rate = 10%.

• Payment Frequency = Monthly.

This sets the First Payment Date to September 3, 2012, and the Amortization Schedule gets generated for the following dates: September 3, 2012, October 3, 2012, November 3, 2012, till August 3, 2013, and the Due Amount for each schedule is $879.19.

3. Now let us go to August 13, 2012.

It is observed that the system accrues the interest from August 3, 2012, to August 13, 2012, and the value is as follows:

• Interest Accrued = $27.40. = 10,000 * 10/365 * 10/100.

4. Now let us create an ad hoc payment of $1,000 with the Transaction Date as August 13, 2012, and clear it.

The system updates the contract's Reschedule Status to Pending because of this payment.

5. Let us go to August 14, 2022.

It is seen that the system reschedules the contract successfully and updates the Interest Remaining field value. The system updates the contract fields as follows:

• Principal Remaining = $9,000.

• Principal Paid = $1,000.

• Last Accrual Date = August 13, 2012.

• Interest Remaining = $27.40

• Interest Accrued = $2.46. (This is interest accrued for 1 day.)

• Reschedule Status = Success

• The Amortization Schedule also gets generated for the following dates: September 3, 2012, October 3, 2012, November 3, 2012, till August 3, 2013, and the Due Amount for each is $791.51.

6. Now let us go to August 26, 2012.

It is seen that the system accrues the interest from August 14, 2012, to August 26, 2012, as per the new schedule, and the values are as follows:

• Interest Remaining: $27.40.

• Interest Accrued: $32.05.

7. Now on August 26, 2012, let us reverse the ad hoc payment that was created in step 4.

This must update the values as follows:

• The Amortization Schedule should revert to the original one with the same following dates: September 3, 2012, October 3, 2012, November 3, 2012, till August 3, 2013, and the Due Amount for each schedule should be as the original one, which is $879.19.

• Interest Remaining = $0.

• Interest Accrued = $63.01.
  
  The interest is to be calculated on the original principal amount that is $10,000. (10,000 * 10/100 * 23/365, where days = Aug 26 - Aug 3 = 23 days.)

• Principal Remaining = $10,000.

• Principal Paid = $0.

8. Let us go to the next payment date, which is September 3, 2012.

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

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

Resolution

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

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

Issue Description

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

Example to Understand the Issue

1. Let us say today is January 18, 2022, and we create an FAMZ contract with the following details and disburse it:

   • Loan Amount = $10,000

   • Time Counting Method = Actual Days

   • Pre Bill Days = 28 Days

   • Contract Start Date = January 18, 2022

   • Payment Frequency = Monthly

   • First Payment Date = February 18, 2022

   • Interest Posting Frequency = Monthly

   • Term = 10 months

   • Rate = 10%

   • Interest Posting Enabled = True

2. Now, as we move on to February 18, 2022, the following two bills get generated:

   • The February 18, 2022 bill

   • The March 18, 2022 bill

     Note:

     As the Pre Bill Days is defined as 28, bills get generated 28 days before the due date.

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

4. Let us move on to March 18, 2022.
   
   The system, internally, reopens the closed IPT, again accrues interest till March 18 and adds to the Interest Remaining.
   

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

Resolution

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

12.13 Issues fixed in 3.8004.75

12.13.1 For an FAMZ loan contract, the system is calculating Today's Payoff Amount incorrectly (Jira ID: PDRFF-2991/ND-7991)

Issue Description

In an FAMZ loan contract, the system is calculating Today's Payoff Amount incorrectly. This is because the Principal Posted field on the loan contract consists of an incorrect value and the Schedule Balance is calculated considering the Principal Posted value. Hence the Interest Accrued value is calculated incorrectly.

Resolution

This issue is fixed.

13.   Change Record