Item states

The operator repair page allows operators to repair items after payment images and their data are preloaded into the browser. When an item and its data is displayed to a user, the user repairs the data, decides on a disposition for the item, or both. This is a simple view of the repair process. After all of the preloaded payments have either received dispositions or been skipped, more payment data and images are preloaded into the browser.

Payment Repair provides the capability to re-repair an item, which complicates the flow of information. In addition, items can be deferred by operators, which places them into a set of items that are repaired using the deferred item repair page. Before understanding the repair process information flow, the re-repair and defer item capabilities must be understood.

After an item is repaired, deferred, or rejected, the item is placed in a pending state and any repair information is held until the item is finalized. Pending items can be recalled by the operator and re-repaired. When a pending item is finalized, it is placed in a final state and can no longer be changed because the Transaction Server has saved the disposition for the item.

Note: The number of items that can be placed in a pending state is configured on the Payment Repair system properties page. This is referred to as the pending buffer size.

Pending items are finalized when:

an item is repaired, deferred, or rejected and it causes the number of pending items to exceed the configured pending buffer size. The oldest pending item in the list is the item that is finalized.
the user forces finalization by clicking the Finalize all button.
an item is recalled from the pending item list and it has not been changed when the next pending item is recalled from the list. The unchanged item is finalized and the next pending item is displayed for repair.

The state values for an item are stored in the SYS_DISPOSITION column of the REPAIR_INVALID table. The internal state values are shown in Table 1.

Table 1. Internal item state values
Type of state	State value	State name	Description
New	n	Repairable	New items that do not have an operator assigned disposition. This state is also for items that have been repaired and finalized, but require further review by other operators.
New	D	Deferred	Item has been deferred by an operator and must now be repaired using the deferred item page.
Pending	p	Pending repair	An operator has repaired the item. If the item is still in the pending item list, it is available for further repair using the Redo button.
	s	Pending reject	An operator has determined that the item cannot be resolved and has been submitted. If the item is still in the pending item list, it is available for further repair using the Redo button.
	d	Pending defer	An operator has deferred the item. If the item is still in the pending item list, it is available for further repair using the Redo button. If an item in the pending defer state is removed from the pending item list because the size of the list has been exceeded, the item changes to the deferred state.
Redo	x	Redo repair	The operator selected the Redo button for an item in the pending repair state. The item is displayed for the operator to repair. After the operator repairs the item, it changes state based on the decision made by the operator: Repair If the operator repairs the item, it changes to the pending repair state. Reject The item changes to the pending reject state. Defer The item changes to the pending defer state.
	y	Redo defer	The operator selected the Redo button for an item in the pending defer state. The item is displayed for the operator to repair. After the operator repairs the item, it changes state based on the decision made by the operator: Repair If the operator repairs the item, it changes to the pending repair state. Reject The item changes to the pending reject state.
	z	Redo reject	The operator selected the Redo button for an item in the pending reject state. The item is displayed for the operator to repair. After the operator repairs the item, it changes state based on the decision made by the operator: Repair If the operator repairs the item, it changes to the pending repair state. Reject If the operator rejects the item again, it changes to the pending reject state. Defer The item changes to the pending defer state.
Finalizing	q	Finalizing repair	The request to finalize the repaired item has been sent to the repair engine.
Finalizing	t	Finalizing reject	The request to finalize the rejected item has been sent to the repair engine.
Final	R	Repaired	Final state for an item that has been repaired. The item has been updated in the database.
Final	U	Rejected	Final state for an item that cannot be resolved. The item has been updated in the database to indicate that it cannot be resolved.

To ensure that an item can be repaired by only one operator at a time, locks are used. The following states are lockable states:

Repairable
Deferred

The following states are locked states:

Pending repair
Pending reject
Pending defer
Redo repair
Redo defer
Redo reject

The following state diagrams illustrate the different ways that items may flow through the repair process. The following figure shows the item state changes that occur when the operator repairs and rejects items.

The following figure shows the item state changes that occur when an operator first defers and then repairs or rejects an item.

The following figure shows the item state changes that occur when an operator is re-repairing or rejecting an item.