Vertragsänderung
| Dieser Geschäftsfalltyp ist beschrieben, aber noch nicht umgesetzt; die Deklaration als Prozesswissen und die Abbildung auf OMDS 3 folgen mit der Umsetzung. |
Die Vertragsänderung ändert einen bestehenden Vertrag: Kfz-Wechsel, Anpassung der Deckung, Änderung von Bausteinen, Attributen oder Risikoobjekten. Sie ist der zweite Geschäftsfalltyp der Norm und eine Anwendung des Produktwissens: Die Konfiguration des bestehenden Vertrags wird mit dem Produktwissen des Produkts ausgespielt, auf dem der Vertrag läuft, und mit denselben Bearbeitungen geändert wie in der Antragsstrecke. Der geänderte Vertrag ist eine neue Version des bestehenden Vertrags auf demselben Produkt; der Wechsel auf ein anderes Produkt ist die Konvertierung.
Was für alle Typen gilt – die sechs Operationsarten, die vier Prüfungen, der allgemeine Lebenszyklus eines Geschäftsobjekts –, steht im Prozesswissen und wird hier nicht wiederholt.
Geschäftsobjekte und Ableitungen
-
Der bestehende Vertrag ist der Bezug des Geschäftsfalls. Er wird nicht in den Geschäftsfall aufgenommen und nicht verändert; der Geschäftsfall nennt ihn als Herkunft des Änderungsantrags.
-
Der Änderungsantrag ist das Geschäftsobjekt, an dem gearbeitet wird. Er entsteht durch eine Ableitung des Vermittlers aus dem bestehenden Vertrag und trägt dessen Konfiguration als Ausgangsstand, dazu den Änderungsgrund und das Wirksamkeitsdatum. Es gibt kein „Änderungsangebot“ als eigenes Objekt: Prämie und Folgen der Änderung sind Ergebnisse, die der Versicherer bei der Verarbeitung am Änderungsantrag ergänzt.
-
Der geänderte Vertrag entsteht nur durch eine Ableitung des Versicherers aus dem angenommenen Änderungsantrag und ist eine neue Version des bestehenden Vertrags.
Beim Fahrzeugwechsel sind Zulassung des neuen Fahrzeugs und Vorschadenbesichtigung Nebenprozesse unter dem Änderungsantrag, mit denselben Arten, Zuständen und Deklarationen wie in der Antragsstrecke.
Zustände und Übergänge
Die Zustände leben am Änderungsantrag; die Namen folgen dem allgemeinen Lebenszyklus (Zustände eines Geschäftsobjekts).
| Zustand | Bedeutung |
|---|---|
Entwurf (zuerkannt) |
Der Änderungsantrag ist konform zum Produktwissen, aber unvollständig: Pflichtangaben der Änderung fehlen, etwa das Wirksamkeitsdatum oder ein Risikoobjekt für einen neu eingeschlossenen Baustein. |
Einreichbar (zuerkannt) |
Der Änderungsantrag ist gültig, also konform und vollständig; der Versicherer hat Prämie und Folgen der Änderung ergänzt. Der Übergang „einreichen“ ist zulässig. |
Eingereicht, in Prüfung, Rückfrage (gesetzt) |
Nach dem Übergang „einreichen“ liegt der Änderungsantrag beim Versicherer und ist für den Vermittler unveränderlich; eine Rückfrage öffnet ihn für die Bearbeitung „beantworten“ und den Übergang „Rückfrage abschließen“. |
Angenommen, abgelehnt, storniert (gesetzt) |
Der Versicherer nimmt an und leitet den geänderten Vertrag ab, lehnt ab oder der Vermittler storniert den Änderungsantrag vor der Annahme. |
Operationen
| Operation | Art | Beschreibung |
|---|---|---|
Vertrag lesen |
Auskunft |
Konfiguration und Daten des bestehenden Vertrags, ausgespielt mit dem Produktwissen seines Produkts; Grundlage der Ableitung. |
Änderungsantrag anlegen |
Ableitung (Vermittler) |
Aus dem bestehenden Vertrag; legt den Geschäftsfall an. Parameter: Änderungsgrund, Wirksamkeitsdatum. |
Baustein ein- und ausschließen, Attributwert setzen, Risikoobjekt anlegen und zuordnen, Personen ergänzen |
Bearbeitung |
Dieselben Bearbeitungen wie in der Antragsstrecke, am Änderungsantrag; der Versicherer erkennt den Zustand nach jeder Bearbeitung neu zu und ergänzt Prämie und Folgen der Änderung. |
Änderungsantrag ersetzen |
Ersetzung |
Der ganze Änderungsantrag wird übermittelt (OMDS-3-Stil); der Versicherer erkennt den Zustand danach neu zu. |
Einreichen, Rückfrage abschließen, stornieren |
Übergang |
Zustandswechsel des Änderungsantrags; „einreichen“ nur im Zustand Einreichbar, mit dem Bestätigungs-Token des Freigabe-Gates als Parameter wie in der Antragsstrecke. |
Geänderten Vertrag ableiten |
Ableitung (VU, immer) |
Aus dem angenommenen Änderungsantrag; der geänderte Vertrag wird die aktuelle Version des bestehenden Vertrags. |
Zustandsänderungen abrufen |
Auskunft |
Zustandswechsel, die der Versicherer gesetzt hat, nach dem Vorbild von OMDS 2 |
Rolle des Produktwissens
Die Vertragsänderung braucht kein eigenes Vokabular für die Konfiguration: Das Produktwissen des Produkts, auf dem der Vertrag läuft, liefert Bausteine, Attribute, Kardinalitäten und Regeln, und der Änderungsantrag ist eine Produktinstanz wie der Antrag der Antragsstrecke. Zwei Dinge kommen hinzu: Das Produktwissen muss zum Wirksamkeitsdatum ausgespielt werden, nicht zum heutigen Stichtag, weil ein Tarif inzwischen ausgelaufen sein kann; und die Regeln können Änderungen einschränken, die bei Neuabschluss zulässig wären (etwa ein Baustein, der nur bei Abschluss wählbar ist). Beides deklariert das Produktwissen; die Norm legt dafür keine eigene Operation fest.
Prozessvarianten
Die Deklaration des Typs legt je Versicherer fest: ob Änderungsanträge als Entwurf am Server geführt werden; welche Änderungsgründe zulässig sind; ob eine Rückfrage vorgesehen ist; ab wann der Geschäftsfall persistiert und gemeinsam bearbeitbar ist; wie Zustandswechsel zugestellt werden. Was die Norm abschließend aufzählt und was Regelfall ist, legt die Spezifikation des Typs fest, die mit der Umsetzung entsteht.
Abbildung auf OMDS 3
OMDS 3 kennt die Vertragsänderung über den Änderungsgrund an einer neuen Vertragsversion; der Änderungsantrag entspricht dem Antrag mit gesetztem Änderungsgrund und Bezug auf die Polizzennummer, der geänderte Vertrag der neuen Version derselben Polizze. Die genaue Abbildung der Operationen und Codelisten folgt mit der Spezifikation des Typs.
Stand der Umsetzung
Nicht umgesetzt. Muster-Versicherung und Muster-Vermittler kennen heute nur die Antragsstrecke bis zur Berechnung. Die Vertragsänderung folgt nach der Umstellung der Referenzimplementierungen auf Geschäftsobjekte mit eigenen Zuständen (Vorgehen und Artefakte).