Dokumentation Vertragsänderungen um Überlegungen zu den unterschiedlichen Profilen erweitert.
This commit is contained in:
@@ -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}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user