Zustände eines Geschäftsobjekts

Teil des Prozesswissens. Zuerkannte Zustände (Entwurf, Bereit) folgen aus dem Inhalt, gesetzte Zustände aus Übergängen und der Bearbeitung durch den Versicherer; der allgemeine Lebenszyklus gilt für jedes Geschäftsobjekt.

Zuerkannte und gesetzte Zustände

Die Zustände eines Geschäftsobjekts entstehen auf zwei Arten:

Zuerkannte Zustände (assessed states) stellt der Server nach jeder Inhaltsänderung – Bearbeitung wie Ersetzung – neu fest. Er prüft, ob das Objekt gültig ist, also konform zum Produktmodell und vollständig in den Pflichteingaben, und erkennt ihm danach den Zustand Entwurf oder Bereit zu. Was „Bereit“ je Objekttyp bedeutet, hat einen eigenen Namen: beim Antrag einreichbar, beim Offert annehmbar, bei der Berechnung berechenbar. Ein zuerkannter Zustand lässt sich nicht setzen; er folgt aus dem Inhalt. Eine Änderung kann ein bereites Objekt wieder zum Entwurf machen (Pflichtbaustein ausgeschlossen) und einen Entwurf bereit (letzte Pflichtangabe gesetzt).
Gesetzte Zustände (set states) entstehen durch einen Übergang des Clients oder durch den Versicherer in seiner Bearbeitung: eingereicht, in Prüfung, Rückfrage, angenommen, abgelehnt. Sie folgen nicht aus dem Inhalt, sondern aus einer Handlung.

„Bereit“ (ready) ist der Name des zuerkannten Zustands „gültig im Sinne des Objekttyps“. Die typbezogenen Namen einreichbar, annehmbar, berechenbar stehen daneben.

Zustände eines Antrags

Am Antrag sieht das so aus: Solange der Vermittler ihn bearbeitet, wechselt er zwischen Entwurf und Einreichbar, je nachdem, ob die Pflichteingaben vollständig sind. Der Übergang „einreichen“ ist nur aus Einreichbar zulässig; danach liegt der Antrag beim Versicherer, der ihn in Prüfung nimmt, Rückfragen stellt, annimmt oder ablehnt. Bei einer Rückfrage öffnet der Versicherer den Antrag für eine begrenzte Bearbeitung (Antwort, Beleg); der Vermittler schließt die Rückfrage mit einem Übergang ab. Mit der Annahme leitet der Versicherer den Vertrag ab.

Allgemeiner Lebenszyklus

Alle Geschäftsobjekte folgen demselben Lebenszyklus; die Geschäftsfalltypen füllen ihn nur mit anderen Namen und lassen einzelne Schritte aus:

Zustand	Bedeutung
Entwurf	zuerkannt; das Objekt ist konform, aber unvollständig. Der Client darf es bearbeiten oder ersetzen; der Bericht nennt, was fehlt.
Bereit	zuerkannt; das Objekt ist gültig. Der zustandsabhängige Übergang steht unter den Folgeschritten: berechnen, annehmen, einreichen, melden.
Übergeben	gesetzt durch den Übergang des Clients; ab hier ist das Objekt in der Hand des Versicherers und für den Client unveränderlich.
In Bearbeitung beim VU	gesetzt durch den Versicherer: Prüfung, Berechnung, Annahmeentscheidung. Bei Dunkelverarbeitung – etwa dem Berechnen einer Berechnung – durchläuft das Objekt diesen Zustand synchron in derselben Antwort.
Rückfrage	gesetzt durch den Versicherer; er öffnet das Objekt für eine begrenzte Bearbeitung (Antwort, Beleg). Der Client schließt die Rückfrage mit einem Übergang ab.
Abgeschlossen	gesetzt durch den Versicherer; das Ergebnis liegt vor (Prämie, Annahme, Regulierung), und wo der Typ es vorsieht, hat der Versicherer das nächste Objekt abgeleitet (Vertrag aus Antrag).
Abgelehnt	gesetzt durch den Versicherer; Endzustand ohne Folgeobjekt.

Zustand

Bedeutung

Entwurf

zuerkannt; das Objekt ist konform, aber unvollständig. Der Client darf es bearbeiten oder ersetzen; der Bericht nennt, was fehlt.

Bereit

zuerkannt; das Objekt ist gültig. Der zustandsabhängige Übergang steht unter den Folgeschritten: berechnen, annehmen, einreichen, melden.

Übergeben

gesetzt durch den Übergang des Clients; ab hier ist das Objekt in der Hand des Versicherers und für den Client unveränderlich.

In Bearbeitung beim VU

gesetzt durch den Versicherer: Prüfung, Berechnung, Annahmeentscheidung. Bei Dunkelverarbeitung – etwa dem Berechnen einer Berechnung – durchläuft das Objekt diesen Zustand synchron in derselben Antwort.

Rückfrage

gesetzt durch den Versicherer; er öffnet das Objekt für eine begrenzte Bearbeitung (Antwort, Beleg). Der Client schließt die Rückfrage mit einem Übergang ab.

Abgeschlossen

gesetzt durch den Versicherer; das Ergebnis liegt vor (Prämie, Annahme, Regulierung), und wo der Typ es vorsieht, hat der Versicherer das nächste Objekt abgeleitet (Vertrag aus Antrag).

Abgelehnt

gesetzt durch den Versicherer; Endzustand ohne Folgeobjekt.

Dazu kommen Endzustände, die der Typ vorsieht und die nicht aus der Bearbeitung des Versicherers folgen: storniert (der Client zieht das Objekt zurück), abgelaufen (die Gültigkeit eines Offerts endet). Untergeordnete Geschäftsobjekte füllen denselben Rahmen mit eigenen Namen; den Lebenszyklus der Nebenprozesse zeigt deren Seite.

Abhängigkeit zwischen Objekten

Der zuerkannte Zustand eines Objekts folgt in erster Linie aus seinem eigenen Inhalt. Er darf aber auch von Inhalt und Zustand anderer Objekte desselben Geschäftsfalls abhängen, in zwei Richtungen:

Vom Hauptobjekt zum untergeordneten Objekt. Eine Inhaltsänderung des Hauptobjekts kann ein untergeordnetes Objekt ungültig machen: Wird der Vorschaden aus dem Antrag entfernt, ist die angeforderte Besichtigung gegenstandslos; wird das Fahrzeug getauscht, gilt die Besichtigung nicht mehr. Der Versicherer bewertet das bei jeder Verarbeitung des Hauptobjekts neu. Weil jedes Objekt seine eigene Version hat, ändert sich dabei die Version des untergeordneten Objekts; ein Client, der dessen alte Version voraussetzt, wird abgewiesen und liest neu.
Vom untergeordneten Objekt zum Hauptobjekt. Der Zustand untergeordneter Objekte geht in die Vollständigkeit des Hauptobjekts ein: Der Übergang „einreichen“ ist erst zulässig, wenn alle blockierenden untergeordneten Objekte erfüllt sind. Die Folgeschritte zeigen das – der Übergang fehlt, solange ein blockierendes Objekt offen ist –, und der Bericht nennt die blockierenden Objekte (Prüfungen und Zuständigkeiten).

Die Abhängigkeit ist keine gemeinsame Invariante der beiden Objekte, sondern eine Prüfung zum Zeitpunkt des Übergangs und eine Neubewertung bei der Verarbeitung: Jedes Objekt bleibt für sich konform, und jedes wird für sich gespeichert.

Begründung zu gesetzten Zuständen

Jeder gesetzte Zustand trägt optional eine Begründung (bc:stateReason): einen Code aus einer Liste, die der Geschäftsfalltyp je Zustand deklariert, und einen Text. Für die Zustände abgelehnt, abgebrochen, abgelaufen, ungültig und storniert ist sie verpflichtend – ein Client oder Agent soll dem Kunden sagen können, warum ein Antrag abgelehnt oder eine Besichtigung hinfällig wurde. Die Begründung ist vom Prüfbericht getrennt: Der Bericht nennt, was an Inhalt und Pflichteingaben fehlt oder verletzt ist; die Begründung erklärt eine Handlung oder Entscheidung. Auch ein Übergang des Clients darf eine Begründung mitgeben, etwa beim Stornieren oder Abbrechen.