Policy Transaction Stack

Workflow

The policy transaction workflow is identical to the quotes workflow.

Note

Transactions in issued state may not be discarded, invalidated, or reset. Transactions in accepted state may not be discarded or reset.

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.

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 works similarly to the process in 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.