Unfinalize Claim

Details

Pricing finalized and finalized claims cannot be changed. If a change to a pricing finalized or finalized claim is required or a pricing finalized or finalized claim needs to be recalculated due to configuration or reference data changes, that claim must first be unfinalized.

A claim (processCategory as null) can be unfinalized in one of the following possible ways:

With a click on the Unfinalize button on the claims page.
With the Claims Reprocessing integration point.
With the Claims In integration point.
With the Claims Update integration point.
With the Unfinalize operation on generic claims resources.
With the Cancel operation on generic claims resources.

A large claim (process category as L)can be unfinalized in one of the following possible ways: Refer Un-finalize Large Claim section below.

A sub-claim (process category as S)can be unfinalized in one of the following possible ways:

With a click on the Unfinalize button on the claims page.
With the Unfinalize operation on generic claims resources.
With the Unfinalize operation on large claim.

The flow for unfinalizing a claim is schematically depicted by the following figure:

Any existing unfinalize reasons attached during a previous unfinalize are removed. The new unfinalize reasons are attached to the claim. The new unfinalize reasons are specified either in the IP message or in the Unfinalize Claim page, and it depends on what triggered the unfinalize.

Access restrictions always protect unfinalize reasons. If the current user does not have access rights for all the attached unfinalize reasons. The following error message is returned:

CLA-IP-CLAI-025 "Not authorized for those unfinalize reasons"

The user must have a grant with both the Read and Update flags set. If any rights are missing, no change is made to the claim or any of its details.

If one or more new unfinalize reasons have the Lock Claim Lines indicator checked, all non-replaced claim lines of the claim are locked. Locked claim lines cannot be changed and will not be reprocessed when the claim is reprocessed; the previous results on these claim lines will be kept.

Resetting Routing Slips

When an integration point triggers the unfinalize, the values of the Preprocessing Done and Pricing Done? indicators may have been specified as part of that request, it is not overwritten if "Preprocessing Done" or "Pricing Done" is set explicitly.

Suppose the unfinalized results are in a status transition to CHANGE, and the Preprocessing Done and Pricing Done? are set to N. In that case, if the unfinalize results in a status transition to INITIAL, the Pricing Done? is set to N.

If the claim contains claim tag actions and these are not set explicitly (through, for example, a reprocessing request that specifies claim tag actions), these tag actions are reset as follows:

REDO ⇒ REDO
SKIP ⇒ SKIP
HOLD ⇒ REDO
FORCE ⇒ REDO

Flagging Claims Transaction Repository (CTR) and Store Reversal

Note that the different elements are joined within a single step because the execution should lead to all parts being successfully processed.

Flag CTR

When a finalized claim is unfinalized, the current claims transaction in the Claims Transaction Repository is flagged as in process by adding a transaction label of type Unfinalized. This is to notify downstream components that keep track of claim transactions, enabling them to postpone processing for that particular transaction.

Unfinalizing a large claim applies all these steps to the large claim and all the linked sub-claims.

Create Reversal Claim Transaction

A reversal transaction of the last claim transaction available in the CTR is stored. A reversal transaction looks like the original transaction (including the same version) but with the relevant amount and number attributes multiplied by -1. The relevant attributes can be identified as follows:

For fixed attributes: A static list is provided. See the Repository Model page of the Claims Transaction Repository chapter of the Developer Guide.
For dynamic fields: It is configurable for each field whether they should be reversed; this applies to both dynamic fields and dynamic records that use such fields.

The reversal transaction is marked by an indicator, and the transaction datetime of the reversal transaction is the same as the datetime of storing the reversal. Reversal transactions are not shown in the UI.

Create Reversal Financial Transaction

A reversal financial transaction is created if an original financial transaction is present (it is possible that, reservations and quotes may result in no financial transactions). A reversal financial transaction looks like the original financial transaction (including the same version), differs from the original financial transaction in the following aspects:

Reversal indicator is set to Y.
Total amount is set to the original total amount *-1.
Reference to the activity that created the financial transaction is left blank.
Source of the reversal is set to CP (Claims Processing).

In addition, detailed records are created that reference the reversal financial transaction:

Financial transaction process data. It differs from the original financial transaction process data in the following aspects:
- Financial message ID is left blank.
- Financial message result is left blank.
- Fin message handled datetime is left blank.
- Financial message mandatory indicator is set to N.
Financial transaction detail. It differs from the original financial transaction detail in the following aspects:
- Amount is set to the original amount *-1.
- Number of units is set to the number of units *-1.
Financial transaction detail process data. It differs from the original financial transaction detail process data in the following aspects:
- Invoice ID is left blank.
- Invoice line ID is left blank.
- Accounting detail ID is left blank.

These detailed records do not hold a reversal indicator of their own.

For dynamic fields, it is configurable for each field if they should be reversed or not:

Non time valid dynamic fields are possible on financial transaction process data and financial transaction detail process data, not on financial transaction and financial transaction detail.
Negating fields works both for straight dynamic fields that have their reversible indicator set and for fields as part of dynamic records that have their reversible indicator set.

Marking Consumption

All finalized consumption on any of the claim lines is marked for reversal.

This implies that, to other claims, the consumption remains visible as though nothing has changed. Within the claim, the finalized consumption is ignored, i.e., it does not count towards any limit or regime. If the consumption is still marked for reversal when the claim (re)finalizes, the consumption is actually reversed.

Clearing Claim Line Status

The status of each claim line is cleared. Note that this step is not performed if one or more new unfinalize reasons have a checked Lock Claim Lines indicator. The results on locked claim lines must be kept to keep their statuses.

Pend or Reprocess

It is possible that the reprocessing request message attached new pend reasons to the claim, bill, or claim line. If so, the claim status is set to CHANGE, and the claim is rerouted to the Level 2: Receive, Change, or Enter Claim flow, where an operator can work on it. If the claim was unfinalized manually, then it is also rerouted to the Level 2: Receive, Change, or Enter Claim flow.

If the claim is changed through an IP and no pend reasons are attached, then the claim status is set to INITIAL, and the claim is rerouted to the Level 2: Sanity Checks flow. The Reverse Edits substep is described in Receive Change or Enter Claim.

Un-finalize Large Claim

Once a claim with the process category Large Claim System (also called Large Claim) reaches Finalized status, it is impossible to make any changes to the Large Claim or linked Sub-claims.

If changes are required to a finalized large claim, it must be unfinalized and brought back to In Process status.

A large claim unfinalize flow is triggered when:

A user click the Unfinalize button on the large claim header page.
A user performs a POST request on Large Claims – Unfinalize IP.See Unfinalize Large Claim for more details.
A user sends an existing Large claim code which is in finalized status with an un-finalize reason using the Large claim Import IP.
The large claim header, updated and submitted, could unfinalize an already finalized sub-claim. See Submit a Large Claim For Processing for more details.

The flow for un-finalizing a large claim is schematically depicted by the following figure:

When a large claim is un-finalized, on the large claim level, the system:

Removes the old un-finalize reasons.
Attaches new un-finalize reasons.
Creates a Reversal CTR version.
All linked sub-claims are unfinalized and brought back to Change status.
The Large claim is brought back to In Process status.

Removes the Old Un-finalize Reasons & Attach New Un-finalize Reasons

Access restrictions always protect unfinalize reasons. If the current user does not have access rights for all the attached_ unfinalize_ reasons. The following error message is returned:

CLA-IP-CLAI-025 "Not authorized for those unfinalize reasons"

The user must have a grant with both the Read and Update flags set. If any rights are missing, no change is made to the claim or any of its details.

Creates a Reversal CTR Version

Flag CTR

Create Reversal Claim Transaction

A reversal transaction of the last claim transaction available in the CTR, is stored. A reversal transaction looks just like the original transaction (including the same version), but with the relevant amount and number attributes multiplied by -1. The relevant attributes can be identified as follows:

For fixed attributes: A static list is provided. See the Repository Model page of the Claims Transaction Repository chapter of the Developer Guide.
For dynamic fields: It is configurable for each field whether they should be reversed; this applies to both dynamic fields and dynamic records that use such fields.

For dynamic fields, it is configurable for each field if they should be reversed or not:

Nontime valid dynamic fields are possible on financial transaction process data and financial transaction detail process data, not on financial transaction and financial transaction detail.
Negating fields works for both straight dynamic fields that have their reversible indicator set and fields as part of dynamic records that have their reversible indicator set.

Sub-Claims Un-finalization Process:

In this process, each sub-claim is unfinalized. The unfinalization process is the same as a regular claim process.

Un-finalizing a claim means that it is open for changes, but it will need to go through the entire process flow to be finalized again. When a large claim is un-finalized, it gets a status In-Process, and all the sub-claims are un-finalized and brought back to a status CHANGE. A user can unfinalize a group of sub-claims without unfinalize each sub-claim using a large claim un-finalization integration point process.

CTR Mappings

Consider a large claim that gets finalized the first time, assuming sub-claims one and two are on version 1 and sub-claim three is on version 2. In this scenario, the CTR mapping table holds the following information:

Table 1. CTR Mappings Table
Large claim CTR version 1	Sub-claim 1 Version 1
Large claim CTR version 1	Sub-claim 2 Version 1
Large claim CTR version 1	Sub-claim 3 Version 1
Large claim CTR version 1	Sub-claim 3 Version 1R
Large claim CTR version 1	Sub-claim 3 Version 2

Consider the large claim is now un-finalized and re-finalized. In this scenario, when the large claim is un-finalized, all sub-claims also get un-finalized to maintain reversal consistency. In this case, the CTR mapping table holds the following information.

Table 2. CTR Mappings Table
Large claim CTR version 1	Sub-claim 1 Version 1
Large claim CTR version 1	Sub-claim 2 Version 1
Large claim CTR version 1	Sub-claim 3 Version 1
Large claim CTR version 1	Sub-claim 3 Version 1R
Large claim CTR version 1	Sub-claim 3 Version 2
Large claim CTR version 1R	Sub-claim 1 Version 1R
Large claim CTR version 1R	Sub-claim 2 Version 1R
Large claim CTR version 1R	Sub-claim 3 Version 2R
Large claim CTR version 2	Sub-claim 1 Version 2
Large claim CTR version 2	Sub-claim 2 Version 2
Large claim CTR version 2	Sub-claim 3 Version 3

For a claims-out response on a large claim, see Changes Related to Large Claim for more details.