Contract Change

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 contract change (Vertragsänderung) changes an existing contract: change of vehicle, adjustment of cover, change of components, attributes or risk objects. It is the second business case type of the standard and an application of product knowledge: the configuration of the existing contract is delivered with the product knowledge of the product the contract runs on and changed with the same edits as in the application process. The changed contract is a new version of the existing contract on the same product; the move to another product is the conversion.

What applies to all types – the six operation kinds, the four checks, the general lifecycle of a business object – is described by Process Knowledge and not repeated here.

Business Objects and Derivations

The existing contract is the reference of the business case. It is neither taken into the business case nor changed; the business case names it as the origin of the contract change application.
The contract change application (Änderungsantrag) is the business object being worked on. It comes into being by a derivation of the broker from the existing contract and carries its configuration as the starting point, plus the reason for the change and the effective date. There is no "change offer" as an object of its own: premium and consequences of the change are results the insurer adds to the application during processing.
The changed contract comes into being only by a derivation of the insurer from the accepted contract change application and is a new version of the existing contract.

At a change of vehicle, the registration of the new vehicle and the previous damage inspection are subprocesses under the contract change application, with the same kinds, states and declarations as in the application process.

States and Transitions

The states live at the contract change application; the names follow the general lifecycle (States of a Business Object).

State	Meaning
Draft (assessed)	The application conforms to the product knowledge but is incomplete: mandatory data of the change are missing, for instance the effective date or a risk object for a newly included component.
Submittable (assessed)	The application is valid, that is conforming and complete; the insurer has added premium and consequences of the change. The transition "submit" is admissible.
Submitted, in review, query (set)	After the transition "submit" the application lies with the insurer and is immutable for the broker; a query opens it for the edit "answer" and the transition "close query".
Accepted, rejected, cancelled (set)	The insurer accepts and derives the changed contract, rejects, or the broker cancels the application before acceptance.

State

Meaning

Draft (assessed)

The application conforms to the product knowledge but is incomplete: mandatory data of the change are missing, for instance the effective date or a risk object for a newly included component.

Submittable (assessed)

The application is valid, that is conforming and complete; the insurer has added premium and consequences of the change. The transition "submit" is admissible.

Submitted, in review, query (set)

After the transition "submit" the application lies with the insurer and is immutable for the broker; a query opens it for the edit "answer" and the transition "close query".

Accepted, rejected, cancelled (set)

The insurer accepts and derives the changed contract, rejects, or the broker cancels the application before acceptance.

Operations

Operation Kind Description

Operation	Kind	Description
Read contract	Inquiry	Configuration and data of the existing contract, delivered with the product knowledge of its product; basis of the derivation.
Create contract change application	Derivation (broker)	From the existing contract; sets up the business case. Parameters: reason for the change, 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 contract change application; the insurer reassesses the state after every edit and adds premium and consequences of the change.
Replace contract change application	Replacement	The whole application is transmitted (OMDS 3 style); the insurer reassesses the state afterwards.
Submit, close query, cancel	Transition	State change of the application; "submit" only in the state submittable, with the confirmation token of the release gate as parameter like in the application process.
Derive changed contract	Derivation (insurer, always)	From the accepted application; the changed contract becomes the current version of the existing contract.
Fetch state changes	Inquiry	State changes the insurer has set, modelled on OMDS 2 `GetStageChanges`.

Read contract

Inquiry

Configuration and data of the existing contract, delivered with the product knowledge of its product; basis of the derivation.

Create contract change application

Derivation (broker)

From the existing contract; sets up the business case. Parameters: reason for the change, 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 contract change application; the insurer reassesses the state after every edit and adds premium and consequences of the change.

Replace contract change application

Replacement

The whole application is transmitted (OMDS 3 style); the insurer reassesses the state afterwards.

Submit, close query, cancel

Transition

State change of the application; "submit" only in the state submittable, with the confirmation token of the release gate as parameter like in the application process.

Derive changed contract

Derivation (insurer, always)

From the accepted application; the changed contract becomes the current version of the existing contract.

Fetch state changes

Inquiry

State changes the insurer has set, modelled on OMDS 2 GetStageChanges.

Role of the Product Knowledge

The contract change needs no vocabulary of its own for the configuration: the product knowledge of the product the contract runs on supplies components, attributes, cardinalities and rules, and the contract change application is a product instance like the application of the application process. Two things are added: the product knowledge has to be delivered as of the effective date, not as of today, because a tariff may have expired in the meantime; and the rules may restrict changes that would be admissible at conclusion (for instance a component that can only be chosen at conclusion). Both are declared by the product knowledge; the standard defines no operation of its own for it.

Process Variants

The declaration of the type specifies per insurer: whether contract change applications are kept as a draft at the server; which reasons for change are admissible; whether a query is provided for; from when on the business case is persisted and jointly editable; how state changes are delivered. What the standard enumerates exhaustively and what is the default case is laid down by the specification of the type, which comes with the implementation.

Mapping to OMDS 3

OMDS 3 knows the contract change by the reason for change at a new contract version; the contract change application corresponds to the application with the reason for change set and a reference to the policy number, the changed contract to the new version of the same policy. The exact mapping of operations and code lists follows with the specification of the type.

State of the Implementation

Not implemented. Sample insurer and sample broker today know only the application process up to the calculation. The contract change follows after the switch of the reference implementations to business objects with states of their own (Approach and Artefacts).