Unfinalize Claim

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

A claim can be unfinalized in one of five possible ways:

by a user through the Unfinalize button in the claims page;
by the Claims Reprocessing integration point;
by the Claims In integration point;
by the Claims Update integration point.
by operation Unfinalize on generic claims resource
by operation Cancel on generic claims resource

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

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

Unfinalize reasons are always protected by access restrictions. If the current user does not have the access rights for all the unfinalize reasons that are being attached. Error CLA-IP-CLAI-025 "Not authorized for those unfinalize reasons" is returned . The user must have a grant with both the Read and Update flag set. If any rights are missing, no change is made at all to the claim or any of its details.

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

Resetting Routing Slips

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

If the unfinalize results in a status transition to CHANGE, the "Preprocessing Done" and "Pricing Done" are set to N; 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 e.g. a reprocessing request that specifies claim tag actions), these tag actions are reset as follows:

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

Flagging 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.

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 section in the CTR Implementation Guide)
for dynamic fields, it is configurable for each field if they should be reversed or not; this implies both to dynamic fields and to dynamic records making use of such fields

The reversal transaction is marked by an indicator and the transaction datetime of the reversal transaction is 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 a original financial transaction is present (for quotes and reservation, it is possible no financial transaction was created). A reversal financial transaction looks just like the original financial transaction (including the same version), differing 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, detail 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
aspect:
```
- amount is set to the original amount *-1
- number of units is set to 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 detail 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 of the new unfinalize reasons have a checked Lock Claim Lines indicator. The results on locked claim lines need to be kept so their statuses are kept.

Pend or Reprocess

It’s 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 it can be worked by an operator. If the claim was unfinalized manually then the claim is also rerouted to the Level 2: Receive, Change or Enter Claim flow.

If the claims 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.