# Policy Transactions



import Image from 'next/image';

The Policy Transaction is the structure that the policy module uses to track policy changes, starting with *issuance* and any subsequent modifications, such as endorsement, renewal, cancellation, and reinstatement.

Structure [#structure]

Policy transactions are independent. After validation, most of the important data on a transaction is immutable. This offers the following capabilities:

* The state of the policy (including data, pricing, coverages, and other [elements](/features/policy-management/policy-elements)) as of a moment in time can be easily assessed: start at the most recently issued transaction and proceed down the transaction stack until you find the first transaction issued on or before the given time.
* The state of the policy as of a certain effective time can be easily found: start at the most recently issued transaction and find the policy segment that spans the given effective time.
* It is easy to answer questions like "what would the policy look like if this transaction were to be issued?"
* The pricing "caused" by a transaction is easy to find: it's stored in the transaction itself, for premium and any other relevant charge.
* When reverting transactions (such as in reinstatements and transaction reversals), the data and prices for the policy will be restored to the exact values immediately before the reversed transaction, even in complex out-of-sequence cases.

See the [Policy Transaction Stack](/features/policy-management/policy-transaction-stack) topic for details about these and other cases.

Provisional Transactions [#provisional-transactions]

Like [policy quotes](/features/policy-quotation/quotes), transactions are created in a provisional state starting with `draft` and advancing through intermediate steps for validation, pricing, underwriting, and other processes, and ultimately proceeding through issuance (or, potentially, invalidation and/or discard.)

Provisional transactions can be chained (for example, one prospective transaction can be based on an earlier transaction that hasn't been issued yet.) Any number of transactions may be stacked in this way, provided that no transaction is based on a transaction with an earlier state. For example, a `validated` transaction can't be based on a `draft` transaction.

Transactions can also be branched, allowing convenient side-by-side comparisons while ensuring only one branch can go on to be issued.

Basic Transactions [#basic-transactions]

The following transactions are included in Socotra Insurance Suite:

* Issuance
* Policy Change
* Renewal
* Cancellation
* Reinstatement
* Reversal

<span id="Process" />

Process [#process]

Policy transactions exhibit a workflow similar to the [policy quotation](/features/policy-quotation/quotes) process:

<Image src="/images/policy_transaction_main_flow.png" alt="policy transaction main flow" width={800} height={301} unoptimized />

With underwriting flow:

<Image src="/images/policy_transaction_underwriting_flow.png" alt="policy transaction underwriting flow" width={800} height={151} unoptimized />

Compared to quotes, the major difference with policy transactions is the addition of the `initialized` step. The transaction automatically enters this step when it is advanced, or when it is edited from `draft` state.

On creation, the transaction is in `draft` state and contains a set of change instructions, such as add a new coverage, remove an exposure, update data or coverage terms, etc. These are descriptors of how the existing policy data (as of the effective time of the new transaction) should be changed.

When initialized, the transaction will use the change instructions to materialize the segment for the revised coverage period. This includes creation of the new elements and setting the data extensions and coverage terms. At this point the segment data can be modified directly, much like quotes are modified when they are in `draft` state, but the effective time of the transaction can no longer be changed.

Edits to the segment data will also automatically generate updates or changes to the transaction's change instructions, such that the collection of change instructions, when applied to the previous segment's data, is guaranteed to produce the current segment data.

<span id="trx-reset" />

Transaction Reset [#transaction-reset]

Like quotes, policy transactions that have advanced past `draft` state but are not yet `issued`, `rejected`, or `discarded` can be <ApiLink name="resetTransaction">reset</ApiLink>. Accepted transactions must first be `refused` before they can be reset. For transactions, there is a choice between resetting to `initialized` state, or resetting to `draft` state.

The default is reset to `initialized` state, which will remove pricing, documents, and underwriting information (based on the <ApiLink name="ResetOptions" />), but will retain the segment data that was created based on its change instructions. This can be helpful if you want to retain the locators of newly created elements, as they won't change based on the default reset action.

Alternatively, you can set the `resetToDraft` query parameter to `true`, and the segment data will be discarded. It will be regenerated when the transaction is edited or revalidated.

See Also [#see-also]

* [Policy Transaction Stack](/features/policy-management/policy-transaction-stack)
* [Quotes](/features/policy-quotation/quotes)
* [Policy Transaction API](/api/policy-management/policy-transactions)