# Policy Transaction Stack



Workflow [#workflow]

The policy transaction workflow is identical to the [quotes](/features/policy-quotation/quotes) workflow.

<Callout>
  Transactions in `issued` state may not be discarded, invalidated, or reset. Transactions in `accepted` state may not be discarded or reset.
</Callout>

<span id="TransactionData" />

Transaction Data [#transaction-data]

Policy transactions have the following important properties:

* `basedOn` is set for all but issuance transactions. basedOn refers to the top-most transaction that:
  * Is immediately lower in the transaction stack and
  * Is not reversed

* The `updateInstruction` contains information on how to change coverage information (adding elements, mutating element data, etc.).

* The `segments` array contains all the segments created by the transaction.

* `reversesTxs` is an array populated for out-of-sequence or reversal cases.

* `reapplicationOf` is used for out-of-sequence handling, where Socotra reverses a set of transactions latest to earliest, applies a new transaction, and then reapplies the reversed transactions. If non-null, `reapplicationOf` contains the locator of the transaction that this one is reapplying.

* `termHead` indicates the head of the term stack that this transaction is based on.

* The `previousChargeSummary` is a set of denormalized summary-level charge amounts by term, element, charge and type. It includes the transaction's new charges, such that the total price and non-financial sums for that entire term through that transaction are reflected in the summary.

* The `staticLocator` refers to the locator of the original transaction. The `staticLocator` field will remain unchanged for a transaction, even when a transaction is reversed and reapplied.

* The `expirationTime` prevents policy transactions from moving to the next stage of the policy transaction [lifecycle](/features/policy-management/policy-transactions#process) if the `expirationTime` is equal to or before the current time when a request is processed. Expired policy transactions can still be reset (moved to the `draft` state) or discarded. If an issued or reversed policy transaction is reapplied, the `expirationTime` will be ignored.

<Callout>
  Descriptions can be added to policy transactions in the Operations Workbench. These descriptions are stored as [aux data](/api/aux-data/aux-data). You can retrieve descriptions by using the <ApiLink name="getAuxData">Fetch Aux Data</ApiLink> API endpoint, setting the `locator` as the transaction locator, and setting the `key` as `transactionDescription`.
</Callout>

Documents [#documents]

Documents can be created and attached to the transaction at any of the `validated`, `priced`, `underwritten`, `accepted`, or `issued` states, based on the configuration for documents for that transaction. Some of the documents may be copied to the policy or term based on the configuration when the transaction is issued.

Validation [#validation]

Validation works similarly to the process in [quotes](/features/policy-quotation/quotes). Each segment will be validated independently based on the configuration schema.

For example, if there is a vehicle element with quantifier "one or more" declared as `vehicle+` in the configuration contents, then each segment must confirm that there is at least one vehicle active in the segment. This could be satisfied by a vehicle persisting across segments or being replaced with another by the transaction.

The validation plugin should generally check each segment independently in the same way, but since some use cases require context from other segments, all segments to be validated will be sent in one call.

See Also [#see-also]

* [Policy Transactions](/features/policy-management/policy-transactions)
* [Policy Quotation](/features/policy-quotation/quotes)