C1-HLD-VALID

This algorithm is invoked when the user clicks the Validate button. It validates the records which are in the Pending status. It validates the following:

  • The hold request type given in the record is valid and active in the system.

  • The hold reason is a valid and active value of the HOLD_​REASON_​FLG lookup field.

  • The hold entity is a valid and active value of the HOLD_​ENTITY_​LVL_​FLG lookup field.

  • The account ID given in the record is valid when the hold entity is ACCT.

    Note: If the account ID is invalid, it derives the account ID using the respective account identifier type and account identifier combination. Once the account ID is derived, the corresponding record is updated in the C1_​UPLOAD_​REQ_​DTLS table. If the system could not derive the account ID using the account identifier type and account identifier combination, the status of the record in the C1_​UPLOAD_​REQ_​DTLS table is changed to Invalid.

  • The person ID given in the record is valid when the hold entity is PERS.

    Note: If the person ID is invalid, it derives the person ID using the respective person identifier type and person identifier combination. Once the person ID is derived, the corresponding record is updated in the C1_​UPLOAD_​REQ_​DTLS table. If the system could not derive the person ID using the person identifier type and person identifier combination, the status of the record in the C1_​UPLOAD_​REQ_​DTLS table is changed to Invalid.

  • The bill ID given in the record is valid when the hold entity is BILL, and the outstanding amount of the bill is not equal to zero.

  • The process’s start and end dates are within the hold request start and end dates.

  • The entity’s start and end dates are within the hold request start and end dates.

  • The entity’s start and end dates should fall within at least one process’s start and end dates.

  • At least one process is kept on hold for the entity in the record.

  • The value of each hold process in the record is set to either Y or N.

  • The hold request start and end dates are set to either the system date or a future date.

  • The start dates are not later than the end dates and the end dates are not earlier than the start dates.

  • The same entity is not already kept on hold with the same hold reason through an existing draft or active hold request.

  • The Overdue, Auto Pay, and Refund processes are not set to Y when the hold entity is set to PERS.

  • The Bill Generation, Overdue, Auto Pay, Refund, and Delinquency processes are not set to Y when the hold entity is set to BILL.

  • Both the Overdue and Delinquency processes are not set to Y at the same time in the record.

    Note: The Overdue process is valid for the financial services and health insurance domains, but the Delinquency process is valid only for the health insurance domain.

  • The characteristic type given in the record is valid and its characteristic entity is set to Hold Request.

  • The adhoc characteristic values are validated as per the validations defined in the respective algorithm.

  • The predefined characteristic value is already defined for the characteristic type.

  • The foreign key reference characteristic value is valid.

  • The two or more records with the same entity ID do not exist in the upload request.

    Note: If duplicate records exist in the upload request, it validates and changes the status of one record to Valid and the status of the remaining records to Invalid.

If any of above validations fail, the status of the record in the C1_​UPLOAD_​REQ_​DTLS table is changed to Invalid. However, if all the above validations are successful, the status of the record in the C1_​UPLOAD_​REQ_​DTLS table is changed to Valid. Once all the pending records in the upload request are validated, the status of the upload request is changed to Validated.

Note: If there are no pending records while validating an upload request, a message appears indicating that there are no records to be validated. In such case, you can only delete an upload request.