Dokumentation Vertragsänderungen um Überlegungen zu den unterschiedlichen Profilen erweitert.

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{Einfache Änderung} 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{Komplexe Änderung} 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{Deckungsänderung} mit Prämienauskunft}&{Ja\vspace{0.2cm}}&{Ja\vspace{0.2cm}}&{Ja\vspace{0.2cm}}\\
         \bottomrule
     \end{tabularx}