C1-RELENTITY

This algorithm is invoked when you click the Release button. It checks whether the Release Approval option is selected in the respective hold request type. If the Release Approval option is selected in the respective hold request type, it changes the status of the hold request to Release Approval in Progress. However, if the Release Approval option is not selected in the respective hold request type, it changes the status of the hold request to Released. On releasing a hold request, it checks whether the number of entities added (either manually or via filter criteria) in the hold request exceeds the defer processing count. If the number of entities added in the hold request does not exceed the defer processing count, this algorithm does the following (in the online mode):

• If the hold request is created for the Account entity, the Bill Generation 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, the bill after date is cleared for the respective account.

• 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, the defer auto pay until date is set to the system date for the respective account. In addition, 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 Overdue 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, the postpone credit review until date is set to the system date for the respective account.

• If the hold request is created for the Account entity, the Delinquency process is on hold, and the entity end date in the hold request is earlier than or equal to the batch business date, the postpone credit review until date is set to the system date for the respective account. (Note: This happens only in the deferred mode when the C1-HLMON batch is executed.)

• If the hold request is created for the Account entity, the Refund 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, the hold refund until date is set to the system date for the respective account. In addition, the status of the refund request (if any) for the respective accounts is changed from Hold to its previous status.

• If the hold request is created for the Person entity, the Bill Generation process is on hold, and the entity end date in the hold request is earlier than or equal to the batch business date, the bill after date is cleared 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-HLMON batch is executed.)

• If the hold request is created for the Person entity, the Delinquency process is on hold, and the entity end date in the hold request is earlier than or equal to the batch business date, the postpone credit review until date is set to the system date 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-HLMON batch is executed.)

However, if the number of entities added in the hold request exceeds the defer processing count, a log entry is created indicating that the hold request is manually released but the above-mentioned release process would be completed when the C1-HLMON batch is executed.

This algorithm also updates the alert end date on the respective account to the system date irrespective of whether the number of entities added in the hold request exceeds the defer processing count or not.

This algorithm contains the following parameter:

• Alert Type – Used to indicate the alert type. The system then considers the alerts of the respective alert type on the account and updates its end date when the hold request is released. This parameter is optional.

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