Application Process
The application process (Antragsstrecke) is the path from product selection via configuration and calculation to the contract. It is the first business case type of the standard and the first example of the common model of business case, business objects, operation kinds and process knowledge (Business Objects and Operations). It is implemented and tried out first; the further types – contract change, conversion, claim notification and claims handling – follow in the same grid.
This page describes the application process in this grid: which business objects exist, how they emerge from one another, who is responsible for what, which transitions each object has and which process variants the standard permits. What applies to all types – the six operation kinds, the four checks, the general lifecycle of a business object – is on the concept page and is not repeated here. The states of the individual objects in the motor line of business are shown in State Diagram Motor. The product that is configured and the rules for it are described by Product Knowledge; the application process is its first application.
Business Objects and Derivations
A business case of the application process is the bracket around up to four business objects: calculation, offer, application and contract. Each has a content of its own, a business state of its own and an IRI of its own below the business case; the business case itself has no state. The objects emerge from one another by derivation: the new object takes over the content of the predecessor and carries its IRI as origin, the predecessor remains unchanged.
The derivations calculation → offer and offer → application are optional: an offer may be created without a calculation and an application without an offer; the client then sets up the object in full (OMDS 3 knows this as "offer without calculation" and "submission without a previous CreateApplication"). The only mandatory derivation is application → contract: there is no contract without an application, and this derivation is triggered by the insurer after its check, not by the broker.
A calculation that the insurer does not keep – the client sends a configuration and receives premium and validation report – is an inquiry and not a business object; it does not establish a business case. Only when the insurer keeps the calculation, because the broker wants to find it again, share it or derive an offer from it, does it become a business object, and thereby the business case comes into being.
| Business object | Content | Ready means | Transitions of the client | States set by the insurer |
|---|---|---|---|---|
Calculation |
product configuration: sales product, included components, attribute values, risk objects (Product and Product Tree, Objects) |
calculable |
calculate |
calculated (premium as result) |
Offer |
the configuration, supplemented by policyholder, premium guarantee and validity period |
acceptable |
accept, cancel |
accepted; expired (validity period ends) |
Application |
the configuration, supplemented by persons and roles, application questions and collection (Persons and Roles, Application Questions) |
submittable |
submit (with confirmation token of the approval gate), close query, cancel |
submitted, under review, query, accepted (contract derived), rejected |
Contract |
the accepted application, policy issued; reference for contract change, conversion and claim notification |
– (comes into being only by derivation of the insurer) |
– |
ongoing insurance cover; termination, expiry |
As long as the broker edits an object, it switches between the assessed states draft and ready, depending on whether the mandatory inputs of the state are complete; the server determines this anew after every edit or replacement. The transition – calculate, accept, submit – is only permitted from ready and hands the object over to the insurer; after that it is immutable for the client, and the further states are set by the insurer.
Responsibilities
-
The broker creates and edits calculation, offer and application, derives the offer from the calculation and the application from the offer, and triggers the transitions calculate, accept and submit. Submission requires a confirmation token of the approval gate: a human confirms before an application leaves the broker’s hands (Solution Approach).
-
The insurer performs the four checks for every operation, delivers the premium, sets the states after the transition (under review, query, accepted, rejected) and derives the contract from the accepted application. Additions during processing – premium, default elements, warnings – are expressly permitted; the response is the supplemented object.
-
With a query the insurer opens the application for a limited edit (answer, document); the broker closes the query with a transition.
Subprocesses
Beside the four main objects the application process knows subprocesses: subordinate business objects under offer, application or contract that represent a procedure at the customer, broker, insurer or a third party and can block submission. The standard defines six kinds:
| Kind | Procedure | Default case |
|---|---|---|
Discount approval |
The broker requests a discount beyond its authority, the insurer approves; until then the premium is provisional. |
before submission, blocking |
Approval reservation / acceptance |
The insurer decides on acceptance under reservation; until then cover is provisional. |
after submission |
Certificate |
The customer presents proof from a third party; the content is confidential. |
declared |
Previous damage inspection |
An assessor inspects the vehicle when the application names previous damage. |
three variants, declared |
Identification of persons |
The customer proves their identity, for instance by video identification. |
before submission, blocking |
Registration |
The customer registers the vehicle with the insurance confirmation; the registration office reports to the insurer. |
after submission, carried over to the contract |
A subprocess comes into being by addition by the insurer during processing of the main object when the declared trigger condition is met, or at the request of the broker. If it is blocking and open, the transition "submit" is missing from the next steps of the application, and the report names it; a client need not compute this itself. Which kinds an insurer offers, when they block and are merged, is declared by its process knowledge (Subprocesses).
Flow
Every response along the way has the same form: the business object concerned in full, its state, the validation report, the results of the insurer and the next steps at the business case and at its objects. The client reads the next step from the response; what is not listed there is not permitted.
Process Variants
The standard lists the permitted variants of the application process exhaustively; every insurer declares as process knowledge which of them it implements, and the client adapts to this at runtime:
-
Calculation as inquiry or as business object: whether the insurer keeps calculations and from when a business case comes into being.
-
Draft at the server: whether the insurer holds calculation, offer and application as a draft and offers edits, or whether the client sends the whole object (replacement, OMDS 3 style; Solution Approach).
-
Offer without calculation and application without offer: which creations without a predecessor are permitted.
-
Application kinds and calculation history: which application kinds the insurer offers and whether the business case carries earlier versions of an object as history.
-
Subprocesses: which of the six kinds the insurer offers, under which main object, whether they block, when they are merged and under which trigger condition it requests them.
-
Persistence, authorisation and joint editing of the business case: whether the insurer keeps it, who may access it, whether further brokers or clerks edit it jointly.
Mapping to OMDS 3
The existing OMDS 3 services of the motor application process can be mapped to the operation kinds, so that an insurer can offer the new services as a wrapper on top of them:
| OMDS 3 | Operation kind |
|---|---|
|
inquiry (tariff inquiry), or creation of the calculation with transition "calculate" if the insurer keeps it |
|
derivation calculation → offer with the whole object (OMDS 3 style), or creation without calculation |
|
derivation offer → application with the whole object, or creation without offer |
|
transition "submit" of the application |
status notification (OMDS 2 |
inquiry about the state changes of the business objects that occurred since a point in time, including the subprocesses |
read subprocess, submit result |
inquiry and edit at the subprocess; the subprocess hangs at the main object instead of the business case, the block of submission is in the next steps |
The mapping in detail – fields, application kinds, error codes – is defined by the declaration of the application process.
Content of the Business Objects
The core of every business object of the application process is the product configuration: the chosen sales product with its components, attribute values and risk objects (Product and Product Tree, Product Tree and Instance Tree). The product is delivered at runtime; which configurations are permitted is stated by the product knowledge, not by the service.
As the process advances, the configuration is enriched: the calculation carries the premium per component, the offer premium guarantee and validity period, the application persons and roles (Application and Contract Roles), application questions (Application Questions) and collection, the contract the policy issuing. What may be stated at every component in every object is described by the structural pillar of the vocabulary (Vocabulary Layers).
State of the Implementation
Sample insurer and sample broker today implement the application process up to the calculation: product selection at
the reference date, configuration as a draft at the server with the edits addComponent and removeComponent,
calculation with validation report, product knowledge for the instance and next steps
(Installation & Setup Client). This still happens in the form before the model of business
objects: the calculation responds like a tariff inquiry but at the same time sets up an object under a business case
id, and the draft status is kept at the business case. Offer, application and contract follow together with the switch
to business objects with states of their own (Approach and Artefacts).
Further Business Case Types
The contract change and the conversion begin at the existing contract, which they name as reference without taking it into the business case: the broker derives a contract change or conversion application from it, which has the same edits and transitions as the application of the application process, and the insurer derives the changed or new contract from that. Both have chapters of their own; the claim notification begins with a creation for the contract and is described with its type. All four are placed side by side by Business Case Types in the same grid.