Profil nach Vertrag wählbar.

OMDSServiceDefinition/doc/ON_3 Vertragsbestand/ON_3.05 Einbeziehung/ON_3.05 Einbeziehung.tex

@@ -269,10 +269,23 @@
 
     \subsubsection{Response}
 
-        Der Response kann 0…n passende Verträge enthalten, von denen die Polizzennummer oder die VertragsID übermittelt wird.\\
-
         \includegraphics[width=9cm]{../../../docGen/omds3_ON3_Vertrag_p5}
 
+        Der Response kann 0…n passende Verträge enthalten, von denen die Polizzennummer oder die VertragsID und das
+        anzuwendende Profil für die Einbeziehung übermittelt wird.\\
+
+        Das Element Vertrag hat die folgende Form:
+
+
+        \includegraphics[width=9cm]{omds3_ON3_Vertrag_p6}
+
+        Wobei\\
+        \begin{itemize}
+            \item Vertrag \textemdash~eine Polizzennummer oder VertragsID ist
+            \item Profil \textemdash~die Nummer des Profils 1 bis 4 für die Einbeziehung ist.
+            Es können auch mehrere Profile angegeben werden.
+        \end{itemize}
+
         Wenn für einen Versicherungsnehmer in der Sparte keine Verträge existieren, enthält das Responseobjekt keine
         Vertrag-Elemente, es wird aber kein Soap-Fault geworfen.
 
@@ -480,6 +493,7 @@
 
     \subsection{Fachliche Beschreibung}
     Der Service \glqq AmendRiskSubmit\grqq{} führt die Einbeziehung durch.
+    Für diese Durchführung der Einbeziehung sind keine vorangegangenen Serviceaufrufe notwendig.
     Wenn der Aufruf in irgend einer Weise fehlerhaft ist, erhält der Aufrufer eine SOAP-Exception zurück.
 
     \subsubsection{Status}
@@ -489,30 +503,14 @@
     Der Benutzer existiert und kann über die Daten im SOAP-Header authentifiziert werden.
 
     \subsubsection{Ablauf}
+
     Der Consumer übermittelt die Daten für eine Einbeziehung (Vertrag, Risikoobjekt und etwaige weitere Angaben).
     Der Serviceprovider prüft diese Daten und antwortet mit einer Bestätigung, dass die Einbeziehung durchgeführt
-    wurde oder entgegengenommen wurde.
+    wurde oder entgegengenommen wurde oder mit einem Fehler.
 
     \subsubsection{Prüflogik}
-    Es wird geprüft, ob eine Authentifizierung des Benutzers über die Daten im SOAP-Header möglich ist.\\
-
-    Weiters wird geprüft, ob die angegebene VUNr vom Service unterstützt wird. Falls die VUNr falsch ist, wird
-    ein SOAP-Fault geworfen.\\
-
-    Es wird geprüft, ob im Request ein AuthFilter-Element vorhanden ist, welches den Vermittler näher spezifiziert. Es \textit{kann} ein
-    SOAP-Fault geworfen werden, wenn ein AuthFilter-Element übermittelt wird, obwohl ein solches nicht erwartet wird. Es
-    \textit{muss} ein SOAP-Fault geworfen werden, wenn kein AuthFilter-Element übermittelt wird, obwohl ein solches benötigt wird.
-    und es \textit{muss} ein SOAP-Fault geworfen werden, falls ein AuthFilter-Element übermittelt wird, es aber fachlich nicht passt,
-    beispielsweise weil der User für den Vermittler nicht berechtigt ist.\\
-
-    Es wird geprüft, ob der Vertrag in der übermittelten Einbeziehung existiert und ob der User bei diesem eine Einbeziehung
-    durchführen darf. Ist dies nicht der Fall \textit{muss} ein SOAP-Fault geworfen werden.
-
-    Es wird geprüft, ob die Daten zum Risikoobjekt ausreichend sind und verarbeitet werden können. Können die Angaben zum
-    Risikoobjekt nicht verarbeitet werden, \textit{muss} ein SOAP-Fault geworfen werden.
-
-    Wenn weitere Angaben zur Einbeziehung übermittelt werden, so werden diese auf Gültigkeit geprüft. Scheitert die
-    Prüfung \textit{muss} ein SOAP-Fault geworfen werden.
+    Die Prüflogik \texttt{muss} die gleiche wie bei der Methode \glqq AmendRiskCheck\grqq{} sein, sie wird hier daher nicht nochmals
+    beschrieben.
 
     \subsection{Technische Dokumentation}
 
@@ -522,31 +520,34 @@
 
     \subsubsection{Request}
 
-    \includegraphics[width=9cm]{../../../docGen/omds3_ON3_Vertrag_p25}
+    \includegraphics[width=9cm]{../../../docGen/omds3_ON3_Vertrag_p18}
 
     \noindent Wobei
     \begin{itemize}
         \item AuthFilter \textemdash~falls für die Einbeziehung fachlich die Angabe eines Vermittlers benötigt wird
         und dieser sich nicht aus dem User ableiten lässt, kann hier eine Vermittlernummer oder eine MaklerID
         übermittelt werden. Es ist vom Serviceprovider vorher festzulegen, ob eine solche Angabe erforderlich ist.
-        \item Einbeziehung \textemdash~die Einbeziehung, die geprüft werden soll als \texttt{Einbeziehung\_Type}.
+        \item Einbeziehung \textemdash~die Einbeziehung, die durchgeführt werden soll als \texttt{Einbeziehung\_Type}.
     \end{itemize}
 
     \subsubsection{Response}
 
+    \includegraphics[width=9cm]{../../../docGen/omds3_ON3_Vertrag_p21}
+
     Der Response enthält
     \begin{itemize}
-        \item Status \textemdash~der Status OK, wenn die Angaben für die Einbeziehung stimmen und eine Einbeziehung in der
-        übermittelten Form möglich ist. den Status NOK, wenn die Angaben für die Einbeziehung in der übermittelten Form
-        in Ordnung sind und eine Einbeziehung so nicht möglich wäre. Unabhängig ob der Status OK oder NOK ist, kann der
-        Response Meldungs-Objekte mit Hinweisen enthalten, welche Änderungen an den Daten der Einbeziehung gemacht werden sollten.
-        \item Einbeziehung \textemdash~die unveränderte oder mit Hinweisen ergänzte Einbeziehung aus dem Request.
+        \item Dokument \textemdash~optional ein oder mehrere Dokumente, die sich aus der Einbeziehung ergeben. Wenn bei
+        einer Flotte Einzelpolizzen erstellt werden, kann das die Einzelpolizze sein.
+        \item Einzelvertrag \textemdash~optional die Polizzennummer oder VertragsID eines Einzelvertrags, der sich aus
+        der Einbeziehung ergibt.
+        \item Geschaeftsfallnummer \textemdash~falls die Einbeziehung angenommen wurde aber aus technischen oder
+        fachlichen Gründen nicht sofort durchführbar ist eine Geschaeftsfallnummer, mit welcher die Einbeziehung
+        nachverfolgt werden kann. Falls die Einbeziehung wegen eines Fehlers nicht angenommen werden kann, wird ein
+        SOAP-Fault geworfen.
     \end{itemize}
 
-    \includegraphics[width=9cm]{../../../docGen/omds3_ON3_Vertrag_p28}
-
     \subsubsection{Fehler}
-    Folgende Fehler werden über das Fault-Element des Webservice geworfen:
+    Es werden die gleichen Fehler wie bei \glqq AmendRiskCheck\grqq{} über das Fault-Element des Webservice geworfen:
 
     \begin{tabularx}{\textwidth}{lp{2cm}p{3.5cm}p{6cm}}
         \toprule
@@ -562,5 +563,25 @@
         \bottomrule
     \end{tabularx}
 
+    \section{Anforderungen Implementierung}
+    \subsection{Client}
+
+    Der Client muss mit derzeit zwei Profilen umgehen können. In jedem Fall kann der Client über die Informationen zum VN
+    die VertragsIds beziehen, in welche das Risikoobjekt (lies das Kfz) einbezogen werden kann.
+
+    Zum einen ist zu implementieren ein sehr einfaches \textit{Profil 1}, bei welchem keine weiteren
+    Angaben für eine Einbeziehung gemacht werden und bei dem es nur die Methode \glqq AmendRiskSubmit\grqq{} gibt.
+
+    Zum anderen ist zu implementieren das aufwändigere \textit{Profil 2}, bei welchem \glqq AmendRiskProposal\grqq{}
+    die Information vorgibt, wie \textemdash~insbesondere mit welchen zusätzlichen Angaben \textemdash~eine Einbeziehung erfolgen soll.
+    Ferner der Test der Einbeziehung mit \glqq AmendRiskCheck\grqq{} und die Durchführung der Einbeziehung mittels
+    \glqq AmendRiskSubmit\grqq{}.
+
+    Für die zusätzlichen Angaben zur Einbeziehung gibt das jeweilige Versicherungsunternehmen das zu verwendende Objekt
+    und die Logik dazu vor.
+
+    Zu einem späteren Zeitpunkt ist \textit{Profil 3} mit einer unternehmensübergreifenden Logik für Angaben zur
+    Einbeziehung zu implementieren und ein \textit{Profil 4} mit einer Übergabe eines Deeplinks in \glqq AmendRiskProposal\grqq{},
+    wobei dann die Einbeziehung im Browser abgeschlossen wird.
 
 \end{document}