Unfinalize
A claim with the Finalized status can brought back to Change status, using the unfinalize operation_.
The attribute Process Category
on the claims entity categorizes the claim as a Regular Claim, Large Claim System, or Sub-Claim.
-
If the value of the attribute
Process Category
is`L` orS
, the claim is classified as a Large Claim System or Sub-Claim, respectively. -
If the value of the attribute
Process Category
isNULL
, then the claim is classified as a Regular Claim.
The unfinalize operation works in distinct ways when performed on a Large Claim or Regular/Sub-Claim, as explained in the following section.
Unfinalize Regular Claim or Sub-Claim
Pricing finalized and Finalized claims (process category
not set to large claim system
) can brought back to the Change status by the synchronous unfinalize operation.
The steps to unfinalize are described in Unfinalize Claim.
When a claim is either in the status Finalized or Pricing Finalized and the claim is not settled, an unfinalize link is added to the claim resource:
... claim properties ...
"links": [
{
"href": "http://[hostName]:[portNumber]/[api-context-root]/generic/claims/{id}",
"rel": "self"
},
{
"href": "http://[hostName]:[portNumber]/[api-context-root]/claims/{id}/unfinalize",
"rel": "claim:unfinalize",
"httpMethod": "POST"
}
]
}
Clients must send one or more claim unfinalize reasons in the POST
payload:
{
"claimunfinalizeReasonList": [
{
"sourceReference": "<source reference value>",
"unfinalizeReason": {
"id": "<id of unfinalize reason>"
}
},
{
"unfinalizeReason": {
"code": "<code of 2nd unfinalize reason>"
}
} {
"unfinalizeReason": {
"id": "<id of 3rd unfinalize reason>"
}
}]
}
In the example, two unfinalize reasons are passed as parameters. A minimum of one is necessary, while more are feasible. Without an unfinalize reason, the following response is returned:
HTTP Status 400 (Bad Request) with the message CLA-CLUR-002: "To unfinalize a claim, you must enter at least one unfinalize reason".
|
Unfinalize reasons are always protected by access restrictions. HTTP API operations enforce those access restrictions:
-
HTTP status 403 is returned if the current user does not have access rights for all the unfinalize reasons in the payload. The error specified in the Unfinalize Claim for missing access grant on the unfinalize reason has also been returned.
-
If any rights are missing, no change is made at all to the claim or any of its details. The unfinalize reasons in the payload will replace possibly existing unfinalize reasons for the claim. HTTP Status 200 is returned together with a representation of the claim resource (which is now in status Change).
Authorization
A user authorization configuration protects access to this feature.
The relevant access restriction is claims.unfinalize IP
.
A grant must be given with the Read and Update flag set.
Response Message
- Success
-
HTTP 200 OK is returned.
- Failure
Response | Description |
---|---|
HTTP 401 |
Unauthorized |
HTTP 404 |
Claim is unknown. |
HTTP 406 |
Cannot unfinalize a sub-claim as the linked Large Claim status is not in |
HTTP 409 |
Claim is not in a status that allows unfinalize. |
See Response Messages for more details.
Unfinalize Large Claim
Finalized claims (process category
is set to large claim system
) can be brought back to In Process status by the asynchronous unfinalize operation.
This long-running operation unfinalize integration point supports unfinalize a large claim that has been finalized.
When a large claim is in the status Finalized and the claim is not settled, an unfinalize link is added to the claim resource:
... claim properties ...
"links": [
{
"href": "http://[hostName]:[portNumber]/[api-context-root]/claims/{id}/unfinalizelargeclaim",
"rel": "claim:unfinalizelargeclaim",
"httpMethod": "POST"
}
]
}
Similar to the unfinalization online operation, clients must send one or more claim unfinalize reasons with its dynamic data in the POST
payload. In addition, like the synchronous IP, this IP also enforces those access restrictions around Unfinalize reasons.
A successful unfinalize operation on a Large Claim brings the following:
-
The Large Claim to status In Process
-
All the Sub-Claims to status Change.
The operation requires all the sub-claims and the large claim to be unfinalized successfully.
-
In case the activity fails then user can navigate to the response header to view the activity status and can restart the activity.
The steps to unfinalize are described in Unfinalize Large Claim. |
Authorization
A user authorization configuration protects access to this feature.
The relevant access restriction is claims.largeclaimUnfinalize IP
.
A grant must be given with the Read and Update flag set.
Response Message
The link to the activity is given in the response header.
- Success
-
HTTP 201 Created with operator and monitor links.
- Failure
Response | Description |
---|---|
HTTP 401 |
Unauthorized |
CLA_IP_UNLC_001 |
Claim is unknown. |
CLA_IP_UNLC_002 |
Claim is not in a status that allows unfinalize. |
CLA_IP_UNLC_003 |
The process category of the claim is not Large Claim |
See Response Messages for more details.