From a407dfbb93574a3ccd54e2f824b38dc95d478f11 Mon Sep 17 00:00:00 2001 From: JensBuehring Date: Wed, 14 May 2025 14:04:42 +0200 Subject: [PATCH] =?UTF-8?q?Dokumentation=20Vertrags=C3=A4nderungen=20um=20?= =?UTF-8?q?=C3=9Cberlegungen=20zu=20den=20unterschiedlichen=20Profilen=20e?= =?UTF-8?q?rweitert.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../ON_3.04 Vertragsänderungen.tex | 153 +++++++++++++++++- 1 file changed, 147 insertions(+), 6 deletions(-) diff --git a/OMDSServiceDefinition/doc/ON_3 Vertragsbestand/ON_3.04 Vertragsänderungen/ON_3.04 Vertragsänderungen.tex b/OMDSServiceDefinition/doc/ON_3 Vertragsbestand/ON_3.04 Vertragsänderungen/ON_3.04 Vertragsänderungen.tex index 13194a5c..e10992ac 100644 --- a/OMDSServiceDefinition/doc/ON_3 Vertragsbestand/ON_3.04 Vertragsänderungen/ON_3.04 Vertragsänderungen.tex +++ b/OMDSServiceDefinition/doc/ON_3 Vertragsbestand/ON_3.04 Vertragsänderungen/ON_3.04 Vertragsänderungen.tex @@ -117,6 +117,147 @@ \pagebreak \section{Einleitung} + + \subsection{Aspekte von Änderungen} + \subsubsection{Fachliche Einteilung Änderungen} + Vertragsänderungen lassen sich fachlich wie folgt kategorisieren: + \begin{itemize} + \item Vertragsänderungen bei denen der Versicherungsschutz nicht tangiert ist. Beispiel wäre eine + Änderung der Kontonummer, von der abgebucht wird. Hier wird ein Detail angepasst, die Prämie verändert + sich nicht, daher ist auch keine Prämienauskunft erforderlich. Da keine Änderungen am Umfang des + Versicherungsschutzes erfolgen, ist auch keine Beratung des Kunden erforderlich. Die Anpassung kann + technisch unterschiedlich kompliziert sein. Die Änderung der Kontonummer bzw. des IBANs ist einfach. + Das Hinzufügen eines abweichenden Prämienzahlers ist schon ein deutlich komplexerer Vorgang. + \item Vertragsänderungen, die den Versicherungsschutz betreffen. Dies kann eine Änderung am Risikoobjekt + sein oder eine Änderung an den Deckungen. Hier wird in der Regel eine neue Prämie bestimmt, über die + der Kunde informiert werden sollte. Der Kunde muss über den neuen Versicherungsschutz informiert werden, + d.h. es wird in der Regel ein Polizzendokument ausgestellt werden. Änderungen am Risikoobjekt oder an + den Deckungsbausteinen sind ein komplexerer Vorgang. + \end{itemize} + + \subsubsection{Berücksichtigung Dokumente} + Wenn für die Änderung Dokumente notwendig sind, hat dies Auswirkung auf die Anzahl der Serviceaufrufe, + die für die Änderung implementiert werden müssen: + \begin{itemize} + \item Bereitstellung eines Dokuments im Upload: Die Bereitstellung eines Dokuments durch den Aufrufer kann + im eigentlichen Serviceaufruf erfolgen. Dazu muss der Client aber a priori wissen, welche Dokumente er + für die Änderung bereitstellen muss. Ist dies a priori nicht bekannt, bedarf es zweier Serviceaufrufe, da im + Response des ersten mitgeteilt werden muss, welche Dokumente hochgeladen werden müssen. + \item Bereitstellung eines Dokumentes im Download: Damit der Server ein oder mehrere Dokumente bereitstellt, + bedarf es keines zusätzlichen Services. Es genügt ein einfacher Änderungsservice. + \item Bereitstellung eines Dokumentes für den Upload: Wenn der Serviceprovider ein Dokument bereitstellen möchte, + welches ausgefüllt oder unterschrieben hochgeladen werden soll, muss es zwei Aufrufe geben. Im ersten wird + das Dokument generiert und im Response für den Download bereitgestellt. Im zweiten Aufruf kann das ausgefüllte + bzw. unterschriebene Dokument hochgeladen werden. + \end{itemize} + + \subsubsection{Technisch stehen uns für die Realisierung von Änderungen zwei Wege offen:} + \begin{itemize} + \item Einfache Änderungen können mittels eines einfachen Serviceaufrufs realisiert werden. Um einen neuen + IBAN bekannt zu geben, braucht man einen einzelnen Request. Sollte die Nummer nicht validiert werden + können, genügt es, eine einfache Fehlermeldung zurück zu geben. Wie ein IBAN aufgebaut ist, ist vorab bekannt und + ändert sich nicht von heute auf morgen. Eine Übermittlung des IBAN-Formats zur Laufzeit wäre möglich, + wäre aber unnötig kompliziert. Fazit: Zur Realisierung der Änderung genügt ein einfacher Serviceaufruf. + \item Je komplexere Angaben für eine Änderung gemacht werden müssen, desto schwieriger wird es, mit nur einem + Serviceaufruf auszukommen, der gleich die Änderung durchführt. Dies gilt insbesondere für die Wechselwirkung + zwischen Risikoobjekt und möglichem Versicherungsumfang im Deckungsbaum. Der Client soll nicht alle Regeln für + die Wechselwirkung zwischen Risiko und Deckung bis ins kleinste kennen müssen. Es bedarf daher eines + unverbindlichen Hilfsservice, welcher das Objektmodell für die Änderung validiert + und berechnet ohne die Änderung gleich durchzuführen. + \begin{itemize} + \item Insbesondere wenn die Prämie betroffen ist, ist ein mehrmaliger unverbindlicher Aufruf zur + Ermittlung der Prämie sinnvoll. Der Versicherungsnehmer sollte abwägen können, + ob Deckungsumfang und Prämie für ihn in einem vernünftigen Verhältnis stehen. + \item Wenn mehrere Parameter gleichzeitig abgeändert werden, wie z.B. bei der Angabe eines komplett + neuen Fahrzeugs, dann widersprechen sich eventuell Parameter an verschiedenen Stellen des Datenmodells: + Wenn bestimmte Deckungen beispielsweise nur bis zu einem bestimmten Fahrzeugwert möglich sind. Es soll + die Validierungslogik am Server aufgerufen werden, ohne die Änderung gleich auszulösen. + \item Für manche Bereiche des Vertrags, ist es sinnvoll dem Client Änderungs- oder Aktionsunterstützung zu bieten, + so dass der Client a priori nur die Unterstützungssyntax verstehen muss, nicht aber die konkreten + Möglichkeiten des Vertrags kennen muss. Dies trifft insbesondere auf den Deckungsbaum zu. + Der Client kann nicht die Produktregeln jedes beliebigen Vertrags kennen. Die Information, welche + Bausteine ein- bzw. ausgeschlossen werden können, müssen also vom Server kommen. Die Erzeugung der + Unterstützungselemente muss unverbindlich möglich sein, ohne die Änderung auszulösen. + \end{itemize} + + \end{itemize} + + \subsubsection{Normierungsgrad des Laufzeitverhaltens} + \begin{itemize} + \item Datenobjekte mit individuellem Laufzeitverhalten: Bei diesen Objekten wird zwar die Struktur des + Objekts in der Norm oder durch den Serviceprovider mittels Xml-Schema-Definition (XSD) festgelegt, die + inhaltliche Bedeutung der Felder und das Laufzeitverhalten der Objekte ist aber entweder trivial und unbeschrieben + oder Bedeutung und Verhalten wird in der Dokumentation beschrieben. Es wird angenommen, das der Client ein + perfektes a priori Wissen über Bedeutung, Validierungsregeln und Laufzeitverhalten hat und dieses implementiert. + Aus diesem Grund kann er die Felder selbst validieren und kennt das Verhalten, bevor er die Daten an den Server + sendet. Es wird dafür nur ein Serviceaufruf benötigt, der die Änderung gleich durchführt. + \item Datenobjekte mit normiertem Laufzeitverhalten: Wenn der Client \textemdash~abgesehen vom strukturellen Aufbau des Datenobjekts \textemdash~das vollständige Wissen zu + Interpretation, Validierungsregeln oder Laufzeitverhalten nicht hat, kann er mit dem Datenobjekt nicht umgehen. + Es ist unerheblich, ob das Nicht-Wissen des Clients aus einem Nicht-Wissen-Können erwächst, weil die Daten + erst zur Laufzeit vorliegen oder ob das Wissen a priori vorhanden wäre, aber aus Kostengründen keine + Berücksichtigung im Client gefunden hat. + Hier gibt es zwei Lösungsmöglichkeiten: + \begin{itemize} + \item Der Client zeigt die Daten einem Menschen, welcher mit heterogene textliche Informationen etwaiger + Fehlermeldungen interpretieren kann und die Daten in die passende Form bringt. + \item Das Objektmodell wird so erweitert, dass es statt vieler individueller und vom Client unberücksichtigter + Regeln einige wenige vom Client zu berücksichtigende Regeln gibt. Der Client wird so erstellt, + dass er der formalen Unterstützung folgt. Damit dieser Weg effizient verfolgt werden kann, muss die Unterstützung + von allen Serviceprovidern gleich geboten werden, d.h. sie muss in der Norm verbindlich vorgeschrieben werden. + Diese Unterstützung muss abrufbar sein, ohne die Änderung gleich auszulösen. + \end{itemize} + Bei beiden Lösungswegen ist ein zusätzlicher Service erforderlich, um das Objektmodell zu validieren oder + auszuführen. + \end{itemize} + + \subsubsection{Modell am Server stateful vs. stateless} + Wenn zwei Services stellt sich die Frage, ob diese stateless umgesetzt werden sollen oder stateful, das Modell der + Änderung also am Server verwaltet werden soll. + \paragraph{Vorteile stateful} + \begin{itemize} + \item Bei einem invaliden Request vom Client, kann das letzte gültige Modell am Server erhalten bleiben. + \item Einzelne Aktionen im Request werden denkbar, es muss nicht immer das vollständige Modell übermittelt werden. + \item Upload von benötigten Dokumenten kann sukzessive in einzelnen Schritten erfolgen. + \end{itemize} + \paragraph{Nachteile stateful} + \begin{itemize} + \item Umgang mit Status und Geschäftsfall komplizierter. + \item Laufzeitregeln komplizierter: Falscher Request führt zu invalidem Objekt im Geschäftsfall oder + bleibt das letzte valide und was gibt dann der Response zurück? + \end{itemize} + + + \paragraph{Vorteile stateless} + \begin{itemize} + \item Kein Geschäftsfall und kein Status erforderlich. Viel klareres Laufzeitverhalten. + \item Weniger Profile erforderlich. + \item Das Probehandeln ist wirklich optional, ein Client der weiss was er tut (bei einfachen Services), + kann das ignorieren. + \end{itemize} + \paragraph{Nachteile stateless} + \begin{itemize} + \item Immer vollständige übermittlung des Modells erforderlich. + \item Upload aller Dokumente in einem Request. + \end{itemize} + + \subsubsection{Aspekte ohne Auswirkung auf Profil} + Welche Aspekte einer Änderung haben keine Auswirkung auf das technische Profil: + \begin{itemize} + \item Ob die Änderung sofort durchgeführt wird oder nur zeitverzögert durchgeführt wird, hat auf das Profil der + Durchführung keine Auswirkung. Wenn eine Änderung zeitverzögert ausgeführt wird, ist eine Geschäftsfallnummer + für die Änderung zu vergeben und im Response des Durchführungsservice zurückzugeben. + \item Jede Änderung kann zu einem oder mehreren Dokumenten führen. Diese sind im Response des Durchführungsservice + zum Download bereitzustellen. + \item Ein Vertrag kann verschiedene Zustände annehmen. Abhängig vom Zustand des Vertrages sind bestimmte + Änderungen möglich oder nicht möglich. Damit der Client in Erfahrung bringen kann, welche Änderungen aktuell + möglich sind, bedarf es eines Auskunftsservice, der für einen angegebenen Vertrag, die möglichen Änderungen + retourniert. + + \end{itemize} + + \subsection{Profile} + Profile sollen die unterschiedlichen Qualitäten von Änderungen im Objektmodell transparent machen. + Wir unterscheiden in OMDS 3 die folgenden Formen von Vertragsänderungen bzw. Konvertierungen in aufsteigender Komplexität: @@ -131,16 +272,16 @@ \toprule \textbf{Profil}&{\textbf{Charakteristik}}&\textbf{Modell}&{\textbf{SOAP Operations}}\\ \midrule - {\texttt{Einfach} ohne Prämienauskunft\vspace{0.2cm}}&{Die Änderung bezieht sich nicht auf Risikoobjekt + {\texttt{Einfache Änderung} ohne Prämienauskunft\vspace{0.2cm}}&{Die Änderung bezieht sich nicht auf Risikoobjekt oder Deckungsbaum und es ist keine Prämienauskunft erforderlich.\vspace{0.2cm}}&nein&{GetContract, SubmitChange \vspace{0.2cm}}\\ - {\texttt{Komplex} ohne Prämienauskunft}&{Die Änderung ist nicht trivial und wird als Modelltransformation + {\texttt{Komplexe Änderung} ohne Prämienauskunft}&{Die Änderung ist nicht trivial und wird als Modelltransformation abgebildet, beinhaltet aber keine Änderung von Risikoobjekt und Deckungsbaum und daher auch keine Prämienauskunft.\vspace{0.2cm}}&ja& {GetContract, CheckChange, SubmitChange}\\ - {\texttt{Schutz} mit Prämienauskunft}&{Die Änderung ist nicht trivial und wird als Modelltransformation + {\texttt{Deckungsänderung} mit Prämienauskunft}&{Die Änderung ist nicht trivial und wird als Modelltransformation abgebildet. Sie beinhaltet auch eine Änderung des Versicherungsschutzes also eine Ändeurng von Risikoobjekt oder Deckungsbaum und enthält daher auch eine Prämienauskunft.\vspace{0.2cm}}&ja& {GetContract, CheckChange, SubmitChange}\\ @@ -158,9 +299,9 @@ \toprule \textbf{Profil}&{\textbf{Auskunft}}&\textbf{Prüfen}&{\textbf{Durchführung Änderung}}\\ \midrule - {\texttt{Einfach} ohne Prämienauskunft}&{Ja\vspace{0.2cm}}&{-\vspace{0.2cm}}&{Ja\vspace{0.2cm}}\\ - {\texttt{Komplex} ohne Prämienauskunft}&{Ja\vspace{0.2cm}}&{Ja\vspace{0.2cm}}&{Ja\vspace{0.2cm}}\\ - {\texttt{Schutz} mit Prämienauskunft}&{Ja\vspace{0.2cm}}&{Ja\vspace{0.2cm}}&{Ja\vspace{0.2cm}}\\ + {\texttt{Einfache Änderung} ohne Prämienauskunft}&{Ja\vspace{0.2cm}}&{-\vspace{0.2cm}}&{Ja\vspace{0.2cm}}\\ + {\texttt{Komplexe Änderung} ohne Prämienauskunft}&{Ja\vspace{0.2cm}}&{Ja\vspace{0.2cm}}&{Ja\vspace{0.2cm}}\\ + {\texttt{Deckungsänderung} mit Prämienauskunft}&{Ja\vspace{0.2cm}}&{Ja\vspace{0.2cm}}&{Ja\vspace{0.2cm}}\\ \bottomrule \end{tabularx}