C1-HOLDACTV

This algorithm is invoked when the status of the hold request is changed to Active. It validates the following on activation:

• The entity start date is not earlier than the hold request start date.

• The entity end date is not later than the hold request end date.

• The hold amount is less than or equal to the outstanding amount when the entity level is set to Bill.

• A bill with non-zero outstanding bill amount is added in the hold request.

• The entity end date or process end date is not earlier than the system date.

It also does the following (in the online mode):

• If the start date of the hold request, hold entity, or hold process is earlier than the system date, it sets the respective start date to the system date.

• If an active overdue process (if any) exists for the account which is kept on hold, it cancels the respective overdue process of the account. The status of the overdue process is changed to Inactive.

In addition, it does the following in the online or deferred (i.e., when the C1-HLDRQ or C1-HLMON batch is executed) mode depending on the defer processing count:

• If the hold request is created for the Account entity, the Bill Generation process is on hold, and the entity start date in the hold request is earlier than or equal to the system date or batch business date, it sets the bill after date to the hold entity end date or bill generation process end date whichever is earlier. In addition, it creates an entry for the hold request in the CI_​BILL_​DEL_​REQUEST table.

• If the hold request is created for the Account entity, the Overdue process is on hold, and the entity start date in the hold request is earlier than or equal to the system date or batch business date, it sets the postpone credit review until date to the hold entity end date or overdue process end date whichever is earlier.

• If the hold request is created for the Account entity, the Delinquency process is on hold, and the entity start date in the hold request is earlier than or equal to the system date or batch business date, it sets the postpone credit review until date to the hold entity end date or delinquency process end date whichever is earlier.

• If the hold request is created for the Person entity, the Delinquency process is on hold, and the entity start date in the hold request is earlier than or equal to the batch business date, it sets the postpone credit review until date to the hold entity end date or delinquency process end date whichever is earlier. If the Hierarchy option is selected for the person, this algorithm sets the postpone credit review until date for the person, its immediate accounts, its child persons, and for the child persons’ accounts. Note that the system considers only the child persons and not the grandchild persons from the person’s hierarchy and then derives the accounts where the child person is the main customer. However, if the Hierarchy option is not selected for the person, this algorithm sets the postpone credit review until date for the person and its immediate accounts (where the person is the main customer).

  Note: This happens only in the deferred mode when the C1-HLDRQ or C1-HLMON batch is executed.) For more information, see Hold Delinquency in the Oracle Revenue Management and Billing Insurance User Guide.

• If the hold request is created for the Person entity, the Bill Generation process is on hold, and the entity start date in the hold request is earlier than or equal to the batch business date, it sets the bill after date to the hold entity end date or bill generation process end date whichever is earlier. The bill after date is set either for all the accounts in the person’s hierarchy or only for the persons’ immediate accounts depending on whether the Hierarchy option is selected or not. Note that the system considers only the child persons and not the grandchild persons from the person’s hierarchy and then derives the accounts where the child person is the main customer.

  Note: This happens only in the deferred mode when the C1-HLDRQ or C1-HLMON batch is executed.) In addition, it creates an entry for the hold request in the CI_​BILL_​DEL_​REQUEST table.

• If the hold request is created for the Account entity, the Auto Pay process is on hold, and the entity start date in the hold request is earlier than or equal to the system date or batch business date, it sets the defer auto pay date to the hold entity end date or auto pay process end date whichever is earlier.

• If the hold request is created for the Account entity, the Auto Pay process is on hold, and the entity end date in the hold request is earlier than or equal to the system date or batch business date, it updates the automatic payment details of the debit bills (if any) for the respective account in the CI_​BILL_​ACH table.

• If the hold request is created for the Account entity, the Refund process is on hold, and the entity start date in the hold request is earlier than or equal to the system date or batch business date, it sets the hold refund until date to the hold entity end date or refund process end date whichever is earlier. In addition, the status of the non-final refund request (if any) for the respective account is set to Hold.

This algorithm contains the following parameter:

• Alert Type – Used to indicate the alert type using which the alerts should be created in the dashboard whenever an account is kept on hold. You can then click on the hyperlink and navigate to the Alerts tab of the Account screen. Note that the start and end dates of the alert is set to the hold request start and end dates, respectively. The alert appears until the hold request for the account is released. This parameter is optional.

  Note: You need to specify the same alert type in both the C1-HOLDACTV and C1-RELENTITY algorithms.