State Diagram Motor

The business states of the application process lie at the business objects – calculation, offer, application, contract –, not at the business case; that is only the bracket around them. Every object follows the general lifecycle of the concept page: assessed states (draft, ready) are determined by the server from the content after every change of content, set states arise through a transition of the client or through the insurer. This page fills the lifecycle for the motor line of business with the names of the application process.

Within draft and ready the object may be incomplete and is stored as such ("change parameters" means edit or replacement); every response reports what is still missing. The transition into the hands of the insurer requires a valid – conforming and complete – object and is otherwise rejected without changing anything. Which transitions are currently possible is stated by the insurer in every response as next steps at the object; a client shows object, state and next steps (see Solution Approach, product knowledge).

Calculation

states-motor-calculation

A calculation that the insurer does not keep is an inquiry and has no state. Calculating is straight-through processing: the object passes through "in processing at the insurer" synchronously and is calculated with the response. Whether a calculated calculation may be edited further – as a new version in the history of the business case – or a new calculation is created for that is defined by the declaration of the application process.

Offer

states-motor-offer

Application

states-motor-application

Review and acceptance can be straight-through processing; then the application passes through "under review" synchronously and is accepted or rejected with the response. If the insurer sets the states with a delay, the client learns of the change through an inquiry about the state changes of its business cases (modelled on OMDS 2 GetStageChanges); whether a notification can be declared in addition is defined by the process knowledge.

Contract

The contract comes into being only by derivation of the insurer from the accepted application and is immutable for the broker: ongoing insurance cover until termination or expiry. Changes to the contract are not states of the application process but business case types of their own that name the contract as reference:

  • Contract change (change of vehicle, include or exclude a component): existing contract → contract change application (derivation by the broker) → changed contract (derivation by the insurer).

  • Conversion (change of tariff or product generation): the inquiry "conversion options" on the existing contract, then existing contract → conversion application on the new product → new contract that replaces the old one.

  • Claim notification and claims handling: creation of a claim report for the contract.

Their states are in the table of the business case types.

Motor Particularity: Insurance Confirmation and Registration

For the registration of the vehicle the customer needs an insurance confirmation (Versicherungsbestätigung, VB) before the contract exists. It is a business object of its own of the motor application process (business case types, glossary): the insurer derives it from the application at the request of the broker – or creates it, where the declaration provides for it, even without an application –, and the registration office accepts it:

motor-insurance-confirmation

Which states the insurance confirmation has, from which state of the application it may be derived and whether it can also be created without an application is declared by the process knowledge of the application process.