States of a Business Object

Part of Process Knowledge. Assessed states (draft, ready) follow from the content, set states from transitions and the insurer’s processing; the general lifecycle applies to every business object.

Assessed and Set States

The states of a business object arise in two ways:

Assessed states (zuerkannte Zustände) are determined anew by the server after every change of content – edit as well as replacement. It checks whether the object is valid, that is conforming to the product model and complete in its mandatory inputs, and then assesses it as draft or ready. What "ready" means per object type has a name of its own: submittable for the application, acceptable for the offer, calculable for the calculation. An assessed state cannot be set; it follows from the content. A change can turn a ready object back into a draft (mandatory component excluded) and a draft into a ready one (last mandatory input set).
Set states (gesetzte Zustände) arise through a transition by the client or through the insurer in its processing: submitted, under review, query, accepted, rejected. They do not follow from the content but from an action.

"Ready" (Bereit) is the name of the assessed state "valid in the sense of the object type". The type-specific names submittable, acceptable, calculable stand beside it.

States of an Application

At the application this looks as follows: as long as the broker edits it, it switches between draft and submittable, depending on whether the mandatory inputs are complete. The transition "submit" is only permitted from submittable; after that the application lies with the insurer, which takes it under review, raises queries, accepts or rejects it. With a query the insurer opens the application for a limited edit (answer, document); the broker closes the query with a transition. With the acceptance the insurer derives the contract.

General Lifecycle

All business objects follow the same lifecycle; the business case types only fill it with other names and leave out individual steps:

State	Meaning
Draft	assessed; the object is conforming but incomplete. The client may edit or replace it; the report names what is missing.
Ready	assessed; the object is valid. The state-dependent transition is among the next steps: calculate, accept, submit, report.
Handed over	set by the transition of the client; from here on the object is in the hands of the insurer and immutable for the client.
In processing at the insurer	set by the insurer: review, calculation, acceptance decision. With straight-through processing – such as running a calculation – the object passes through this state synchronously within the same response.
Query	set by the insurer; it opens the object for a limited edit (answer, document). The client closes the query with a transition.
Completed	set by the insurer; the result is available (premium, acceptance, settlement), and where the type provides for it, the insurer has derived the next object (contract from application).
Rejected	set by the insurer; final state without a follow-up object.

State

Meaning

Draft

assessed; the object is conforming but incomplete. The client may edit or replace it; the report names what is missing.

Ready

assessed; the object is valid. The state-dependent transition is among the next steps: calculate, accept, submit, report.

Handed over

set by the transition of the client; from here on the object is in the hands of the insurer and immutable for the client.

In processing at the insurer

set by the insurer: review, calculation, acceptance decision. With straight-through processing – such as running a calculation – the object passes through this state synchronously within the same response.

Query

set by the insurer; it opens the object for a limited edit (answer, document). The client closes the query with a transition.

Completed

set by the insurer; the result is available (premium, acceptance, settlement), and where the type provides for it, the insurer has derived the next object (contract from application).

Rejected

set by the insurer; final state without a follow-up object.

In addition there are final states that the type provides for and that do not follow from the processing by the insurer: cancelled (the client withdraws the object), expired (the validity of an offer ends). Subordinate business objects fill the same frame with names of their own; the lifecycle of the subprocesses is shown on their page.

Dependency Between Objects

The assessed state of an object follows first of all from its own content. It may, however, also depend on content and state of other objects of the same business case, in two directions:

From the main object to the subordinate object. A change of content of the main object can make a subordinate object invalid: if the previous damage is removed from the application, the requested inspection is void; if the vehicle is exchanged, the inspection no longer holds. The insurer reassesses this at every processing of the main object. Because every object has a version of its own, the version of the subordinate object changes in the process; a client that presupposes its old version is rejected and reads anew.
From the subordinate object to the main object. The state of subordinate objects enters into the completeness of the main object: the transition "submit" is admissible only once all blocking subordinate objects are fulfilled. The next steps show this – the transition is missing as long as a blocking object is open –, and the report names the blocking objects (Checks and Responsibilities).

The dependency is not a shared invariant of the two objects but a check at the time of the transition and a reassessment at processing: every object remains conforming on its own, and every one is stored on its own.

Reason for Set States

Every set state optionally carries a reason (bc:stateReason): a code from a list the business case type declares per state, and a text. For the states rejected, aborted, expired, invalid and cancelled it is mandatory – a client or agent should be able to tell the customer why an application was rejected or an inspection became void. The reason is separate from the validation report: the report names what is missing or violated in content and mandatory inputs; the reason explains an action or decision. A transition of the client may give a reason as well, for instance when cancelling or aborting.