Conversion

This business case type is described but not yet implemented; its declaration as process knowledge and the mapping to OMDS 3 follow with the implementation.

The conversion (Konvertierung) moves an existing contract to a current product: the old contract is cancelled, the new one takes its place. It is the third business case type of the standard and a type of its own, not a variant of the contract change: the contract change forms a new version of the same contract on the same product, the conversion a new contract on a different product. It is an application of product knowledge in two respects: the product knowledge of the existing product describes the starting point, that of the current product the target configuration.

What applies to all types is described by Process Knowledge and not repeated here.

Business Objects and Derivations

The existing contract is the reference of the business case, not its content. It remains unchanged until the new contract exists; then the insurer cancels it as of the effective date of the conversion.
The conversion application (Konvertierungsantrag) is the business object being worked on: a product instance of the current product. It comes into being by a derivation of the broker from the existing contract; the configuration is carried over as far as the current product carries it, and the rest is filled from the defaults of the product knowledge. Which products are available for conversion and which configuration the insurer proposes is an inquiry on the existing contract.
The new contract comes into being only by a derivation of the insurer from the accepted conversion application and replaces the existing contract.

If the conversion involves a change of vehicle, registration and previous damage inspection are subprocesses under the conversion application as in the application process.

States and Transitions

The states live at the conversion application and correspond to those of the contract change application (Contract Change): draft and submittable are assessed; submitted, in review, query, accepted, rejected and cancelled are set. In addition, the existing contract receives the state cancelled, set by the insurer as soon as the new contract exists.

Operations

Operation	Kind	Description
Conversion options	Inquiry	For an existing contract: the current products it can be converted to, with the proposed configuration and the premium per product – the basis for a comparison by broker or agent.
Create conversion application	Derivation (broker)	From the existing contract to a chosen current product; sets up the business case. Parameters: target product, effective date.
Include and exclude component, set attribute value, create and assign risk object, add persons	Edit	The same edits as in the application process, at the conversion application according to the product knowledge of the current product; the insurer reassesses the state and adds premium and difference to the existing contract.
Replace conversion application	Replacement	The whole conversion application is transmitted; the insurer reassesses the state afterwards.
Submit, close query, cancel	Transition	State change of the conversion application as in the contract change.
Derive new contract, cancel existing contract	Derivation and transition (insurer, always)	From the accepted conversion application the new contract comes into being; the existing one receives the state cancelled.
Fetch state changes	Inquiry	As in the contract change.

Operation

Kind

Description

Conversion options

Inquiry

For an existing contract: the current products it can be converted to, with the proposed configuration and the premium per product – the basis for a comparison by broker or agent.

Create conversion application

Derivation (broker)

From the existing contract to a chosen current product; sets up the business case. Parameters: target product, effective date.

Include and exclude component, set attribute value, create and assign risk object, add persons

Edit

The same edits as in the application process, at the conversion application according to the product knowledge of the current product; the insurer reassesses the state and adds premium and difference to the existing contract.

Replace conversion application

Replacement

The whole conversion application is transmitted; the insurer reassesses the state afterwards.

Submit, close query, cancel

Transition

State change of the conversion application as in the contract change.

Derive new contract, cancel existing contract

Derivation and transition (insurer, always)

From the accepted conversion application the new contract comes into being; the existing one receives the state cancelled.

Fetch state changes

Inquiry

As in the contract change.

Role of the Product Knowledge

The conversion is the business case type that benefits most from product knowledge at runtime: an agent can read the existing contract, query the conversion options, compare the proposed configurations with the product knowledge of the current products and adapt the conversion application so that the cover is preserved – without knowing the old or the new product beforehand. For this the product knowledge has to deliver two states: the old product as of the existing contract and the current product as of the effective date. Carrying the configuration over between the two products is the insurer’s business (proposal in the inquiry); the standard defines no mapping vocabulary for it.

Process Variants

The declaration of the type specifies per insurer: which products are conversion targets; whether the insurer proposes a configuration or only names the target products; whether conversion applications are kept as a draft at the server; whether a query is provided for; how state changes are delivered.

Mapping to OMDS 3

OMDS 3 maps the conversion by replacement policies (Ersatzpolizzen): the new contract refers to the replaced policy, the old contract ends with the corresponding reason. The conversion application corresponds to an application on the new product with a reference to the policy to be replaced. The exact mapping follows with the specification of the type.

State of the Implementation

Not implemented. The conversion follows the contract change, because it reuses its objects and transitions and additionally needs the inquiry "conversion options" (Approach and Artefacts).