Hold Request Update Request and Response - Tags in JSON Format

Note: We recommend you to refer the Hold Request Update Request in the JSON Format and Hold Request Update Response in the JSON Format topics in parallel while understanding the below mentioned tags. This will help you to understand how the tags are nested in the XML format.

Before calling the C1-ReleaseHoldRequest business service through an inbound web service, you need to ensure that the hold request update request contains the following tags:

Tag Name Tag Description Mandatory (Yes or No)
C1-UpdateHoldRequest Used to indicate that you want to invoke the C1-UpdateHoldRequest business service. Yes
sourceSystem Used to indicate the external system from which the hold update request is received.
Note:

You must specify an external system which is already defined in the system.

The external system is used when the Inbound Web Service History feature is enabled. The specified external system should match the external system which is associated with the outbound message type specified in the C1-IWSHIST algorithm. If the external system is not specified in the hold request update request, the system, by default, stamps the external system associated with the outbound message type (specified in the C1-IWSHIST algorithm) corresponding to the record in the C1_​IWS_​HIST table. For more information, see Inbound Web Service History.

No
externalTransactionId Used to indicate the transaction in the external system through which the hold request update request is sent.
Note: The external transaction ID is used when the Inbound Web Service History feature is enabled.
No
externalSourceId Used to specify the external source system ID.
Note: The external source system ID is used when the Inbound Web Service History feature is enabled.
No
holdRequestId Used to specify the hold request ID of the hold request for which the hold request update request is sent.
Note: You must specify the hold request ID which is already defined in the system.
Yes
holdComments Used to specify additional information about the hold request. No
holdEndDate Used to specify the date till when the hold request is effective.
Note:

The hold request end date must be either derived or provided by the upstream system before creating a hold request in an Active status.

The hold request end date cannot be earlier than the hold process end date.

No
entityId Used to specify a list of entities for which you want to create a hold request.
Note: You need to specify the entity ID when the hold entity is BILL.
No
entityEndDate Used to specify the date till when the entity is effective for hold request.
Note:

The entity end date cannot be later than the hold end date and earlier than the hold process end date.

The entity end date cannot be later than the system date.

At present, you can only update the end date of a single entity specified in the hold request update request. If there are two or more entities on hold, you need to initiate a separate hold request update request for each entity in order to update its respective end date.

No
holdProcessData Used to specify the details of the hold process. No
holdProcess Used to specify the process that you want to keep on hold in the hold request. The valid values are:
  • ATPY - Used when you want to specify the auto pay process.

  • BILL - Used when you want to specify the bill generation process.

  • FNDG - Used when you want to specify the funding process.

  • OVDU - Used when you want to specify the overdue process.

Note: You must specify a value which is already defined in the HOLD_​PROCESS_​FLG lookup field. It must be in the Active status.
Yes (Conditional)
Note: This data is required while updating the hold request information.
holdProcessEndDate Used to specify the date till when the entity is effective for hold request.
Note:

The hold process end date cannot be later than the hold end date.

At present, you can only update the end date of a single process specified in the hold request update request. If there are two or more processes on hold, you need to initiate a separate hold request update request for each process in order to update its respective end date.

Yes (Conditional)
Note: This data is required while updating the hold request information.
characteristics Used to specify a characteristic for the hold request. Yes (Conditional)
Note: This data is required while updating the hold request information.
action Used to specify the action to be performed on the characteristic. The valid values are:
  • Update

  • Delete

Yes (Conditional)
Note: This data is required while updating the hold request information.
characteristicType Used to indicate the characteristic type.
Note: You must specify a characteristic type where the characteristic entity is set to Hold Request and which is associated with the hold request type.
Yes (Conditional)
Note: This data is required while updating the hold request information.
characteristicValue Used to specify the value for the characteristic type.
Note: You must specify a characteristic value which is associated with the characteristic type and is present in the system.
Yes (Conditional)
Note: This data is required while updating the hold request information.
effectiveDate Used to specify the date from when the characteristic is effective. Yes (Conditional)
Note: This data is required while updating the hold request information.

The following table lists and describes the tags which appear in the hold request view response in the XML format:

Tag Name Tag Description
requestProcessStatus Indicates whether the hold request update request is successfully processed or not. The valid values are:
  • Success

  • Failure

holdRequestId Displays the hold request ID.
errormsg Indicates the error that occurred while updating the hold request.
Note: This tag appears when the value in the requestProcessStatus tag is set to Failure.

Related Topics

For more information on... See...
Sample Hold Request Update Request and Response in the JSON Format Sample Hold Request Update Request and Response in the JSON Format