Merge mit Einbeziehung-Branch
This commit is contained in:
@@ -0,0 +1,156 @@
|
||||
%! Author = jensbuehring
|
||||
%! Date = 02.04.2025
|
||||
|
||||
% Preamble
|
||||
\documentclass[a4paper, 10pt]{scrartcl}
|
||||
|
||||
% Packages
|
||||
\usepackage[ngerman]{babel} %recommended
|
||||
\usepackage{alltt,graphicx,textcomp,hyperref,amsmath}
|
||||
\usepackage[utf8]{inputenc} %soll direkte Verwendung von Umlauten erlauben
|
||||
\usepackage{caption}
|
||||
\usepackage{booktabs}
|
||||
\usepackage{makecell}
|
||||
\usepackage{listings}
|
||||
\usepackage{tabularx}
|
||||
\usepackage{ltablex} % bringt longtable eigenschaften nach tabluarx
|
||||
\usepackage{geometry}
|
||||
\usepackage{datetime}
|
||||
\usepackage{lastpage}
|
||||
\usepackage{scrlayer-scrpage}
|
||||
\pagestyle{scrheadings}
|
||||
|
||||
\usepackage{tgadventor}
|
||||
\renewcommand*\familydefault{\sfdefault} %% Only if the base font of the document is to be sans serif
|
||||
\usepackage[T1]{fontenc}
|
||||
\usepackage{csquotes}
|
||||
|
||||
|
||||
%% Konfig Seitengeometrie, siehe https://texdoc.org/serve/geometry.pdf/0
|
||||
\geometry{
|
||||
left=3.5cm, right=3.5cm,
|
||||
includehead, head=32.9pt, top=2cm, headsep=1.5cm, %% Abstand oben 2cm, gemessen bis zum Head
|
||||
footskip=1.8cm, bottom=3.3cm, %% footskip ist Abstand Fusszeile von unterem Textrand
|
||||
marginpar=3cm}
|
||||
|
||||
% Konfiguriere Listings
|
||||
\lstset{numbers=left, numberstyle=\tiny, numbersep=5pt, basicstyle=\small,}
|
||||
\lstset{language=XML}
|
||||
|
||||
% nenne Abstract wieder Abstract
|
||||
\addto\captionsngerman{%
|
||||
\renewcommand{\abstractname}{Abstract}
|
||||
\renewcommand{\contentsname}{Inhalte} % Table name
|
||||
}
|
||||
|
||||
\date{2. April 2025}
|
||||
\author{Jens Bühring}
|
||||
\title{3.04 - Vertragsänderungen}
|
||||
|
||||
|
||||
%% Kopf und Fußzeile
|
||||
|
||||
\setkomafont{pagefoot}{%
|
||||
\normalfont
|
||||
}
|
||||
|
||||
\ihead{\includegraphics[scale=0.1]{../../VVO_Logo_2024}}
|
||||
|
||||
\cfoot*{\textcopyright~\the\year~\textemdash~VVO Versicherungsverband Österreich\\Seite~\pagemark~von~\pageref{LastPage}}
|
||||
|
||||
|
||||
% Document
|
||||
\begin{document}
|
||||
|
||||
\begin{flushleft}
|
||||
|
||||
\LARGE{\textbf{3.04 \textemdash~Vertragsänderungen}}
|
||||
\normalsize
|
||||
\vspace{1cm}
|
||||
|
||||
\textbf{Release} voraussichtlich 2026.XX-MAJOR\\
|
||||
\vspace{0.5cm}
|
||||
|
||||
\textbf{Kurzbeschreibung}\\
|
||||
Dieses Dokument beschreibt Vertragsänderungen im allgemeinen und Inkassoänderungen im Besonderen.
|
||||
|
||||
\vspace{0.5cm}
|
||||
|
||||
\textbf{Ansprechpartner} Manfred Klaber \underline{\texttt{\href{mailto:manfred.klaber@vvo.at}{manfred.klaber@vvo.at}}}\\
|
||||
\vspace{0.5cm}
|
||||
|
||||
\textbf{Dokumentenhistorie}\\
|
||||
\vspace{0.3cm}
|
||||
\begin{tabularx}{\textwidth}{lp{9cm}l}
|
||||
\toprule
|
||||
\textbf{Name}&{\textbf{\"Anderung}}&{\textbf{Datum}}\\
|
||||
\midrule
|
||||
\endfirsthead
|
||||
|
||||
\textbf{Name}&{\textbf{\"Anderung}}&{\textbf{Datum}}\\
|
||||
\midrule
|
||||
\endhead
|
||||
{Jens Bühring}&{Anlage des Dokuments}&27.3.2025\\
|
||||
{Jens Bühring}&Überarbeitung nach Einbeziehungen&13.5.2025\\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
\vspace{1cm}
|
||||
|
||||
%% Dokumente / Regeln, die hier Voraussetzung sind
|
||||
\textbf{Voraussetzungen} ON\_1.02.1\_AuthentifizierungAllgemein\\
|
||||
\vspace{1cm}
|
||||
|
||||
%% Rechtliche Hinweise
|
||||
\begin{addmargin}[0cm]{1cm}
|
||||
\textbf{Rechtliche Hinweise} Dieses Dokument wie auch alle anderen Arbeitsgrundlagen, Dokumente und
|
||||
Ergebnisse des OMDS 3.0 unterliegt den Nutzungsbedingungen des OMDS 3.0.
|
||||
\end{addmargin}
|
||||
\vspace{1.5cm}
|
||||
|
||||
%Seite Inhaltsverzeichnis
|
||||
\pagebreak
|
||||
|
||||
\setcounter{tocdepth}{2}
|
||||
|
||||
\tableofcontents
|
||||
\end{flushleft}
|
||||
\pagebreak
|
||||
|
||||
\section{Einleitung}
|
||||
Wir unterscheiden in OMDS 3 die folgenden Formen von Vertragsänderungen bzw. Konvertierungen in aufsteigender
|
||||
Komplexität:
|
||||
|
||||
\begin{itemize}
|
||||
\item Einfache Vertragsänderungen (ohne Änderung der Prämie)
|
||||
\item Komplexe Vertragsänderungen ohne Änderung der Prämie
|
||||
\item Komplexe Vertragsänderungen mit Änderung der Prämie
|
||||
\item Konvertierung (eigene Services, siehe Dokument ON_2.03.01 BOA Konvertierungshilfe)
|
||||
\end{itemize}
|
||||
|
||||
Da die Änderungen unterschiedlich Komplexitätsgrade aufweisen, sind auch die unterschiedliche Änderungsverfahren
|
||||
vorgesehen. Diese unterschiedlichen Verfahren sind in eigenen Profilen definiert.
|
||||
|
||||
Allen Änderungen ist gemeinsam, dass sie nicht in jedem Vertragszustand durchführbar sind. Es gibt daher einen
|
||||
Auskunftsservice auf den Vertrag, in dessen Response zu erkennen ist, welche Änderungen gerade durchführbar sind.
|
||||
Dabei wird auch das zu verwendende Änderungsprofil übermittelt.
|
||||
|
||||
\section{Einfache Vertragsänderungen ohne Änderung der Prämie}
|
||||
|
||||
Einfache Änderungen am Vertrag, welche nicht das Risiko und nicht die Deckungen betreffen, sondern nur die
|
||||
administrativen Merkmale (Antragsfragen) des Vertrags.
|
||||
|
||||
Es wird daher keine neue Prämie errechnet und da das Datenmodell des Vertrags nicht verändert wird
|
||||
(weder Risikoobjekte noch Deckungsbaum), wird für die Kommunikation auch kein Datenmodell verwendet.
|
||||
|
||||
Für die einzelnen Änderungen gibt es jeweils andere Objektstrukturen, welche alle von einem abstrakten Basisobjekt
|
||||
abgeleitet sind. Die Strukturen werden nicht zur Laufzeit offenbart, sondern sind Server und Client a priori
|
||||
(zur Entwicklungszeit) bekannt.
|
||||
|
||||
Antwort ist nur OK im Response oder eine Exception in Form eines SOAP-Faults.
|
||||
|
||||
Wenn die Änderung sofort wirksam wird, wird keine Geschäftsfallnummer zurückgegeben. Wenn die Änderung
|
||||
zeitversetzt wirksam wird, sei es, weil Sacharbeiter auf Seiten des VU eingreifen müssen, sei es, dass die
|
||||
Verarbeitung technisch asynchron verläuft, wird eine Geschäftsfallnummer zurückgegeben.
|
||||
|
||||
|
||||
\end{document}
|
||||
Binary file not shown.
Binary file not shown.
@@ -1,5 +1,5 @@
|
||||
%! Author = jensb
|
||||
%! Date = 26.02.2025
|
||||
%! Author = jensbuehring
|
||||
%! Date = 02.04.2025
|
||||
|
||||
% Preamble
|
||||
\documentclass[a4paper, 10pt]{scrartcl}
|
||||
@@ -12,7 +12,6 @@
|
||||
\usepackage{booktabs}
|
||||
\usepackage{makecell}
|
||||
\usepackage{listings}
|
||||
%\usepackage{longtable}
|
||||
\usepackage{tabularx}
|
||||
\usepackage{ltablex} % bringt longtable eigenschaften nach tabluarx
|
||||
\usepackage{geometry}
|
||||
@@ -30,9 +29,8 @@
|
||||
%% Konfig Seitengeometrie, siehe https://texdoc.org/serve/geometry.pdf/0
|
||||
\geometry{
|
||||
left=3.5cm, right=3.5cm,
|
||||
head=32.81087pt, includehead, top=1cm, headsep=1.5cm,
|
||||
includefoot, bottom=1.5cm, %% Abstand unten 1 cm, gemessen bis zum Footer
|
||||
%textwidth=15cm,
|
||||
includehead, head=32.9pt, top=2cm, headsep=1.5cm, %% Abstand oben 2cm, gemessen bis zum Head
|
||||
footskip=1.8cm, bottom=3.3cm, %% footskip ist Abstand Fusszeile von unterem Textrand
|
||||
marginpar=3cm}
|
||||
|
||||
% Konfiguriere Listings
|
||||
@@ -45,9 +43,9 @@
|
||||
\renewcommand{\contentsname}{Inhalte} % Table name
|
||||
}
|
||||
|
||||
\date{28. Januar 2025}
|
||||
\date{2. April 2025}
|
||||
\author{Jens Bühring}
|
||||
\title{1.04.4 - Dokumententypen}
|
||||
\title{3.05 - Einbeziehung von Risikoobjekten}
|
||||
|
||||
|
||||
%% Kopf und Fußzeile
|
||||
@@ -70,7 +68,7 @@
|
||||
\normalsize
|
||||
\vspace{1cm}
|
||||
|
||||
\textbf{Release} 2025.27-MINOR-SNAPSHOT\\
|
||||
\textbf{Release} voraussichtlich 2026.XX-MAJOR\\
|
||||
\vspace{0.5cm}
|
||||
|
||||
\textbf{Kurzbeschreibung}\\
|
||||
@@ -96,6 +94,8 @@
|
||||
\endhead
|
||||
{Jens Bühring}&{Anlage des Dokuments}&2.4.2025\\
|
||||
{Jens Bühring}&Einführung von Implementierungsprofilen&2.5.2025\\
|
||||
{Jens Bühring}&Statt einer Sparte wird das einzubeziehende Risikoobjekt evaluiert, um eine Liste der Verträge zu liefern.
|
||||
Der Typ Einbeziehung ist abhängig vom Implementierungsprofil, dadurch kann Service AmendRiskProposal entfallen, &6.5.2025\\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
\vspace{1cm}
|
||||
@@ -115,7 +115,6 @@
|
||||
\pagebreak
|
||||
|
||||
\setcounter{tocdepth}{2}
|
||||
%\setcounter{secnumdepth}{2}
|
||||
|
||||
\tableofcontents
|
||||
\end{flushleft}
|
||||
@@ -129,65 +128,66 @@
|
||||
Vertrag existiert, welcher die Einbeziehung des Risikoobjekts ermöglicht.
|
||||
|
||||
|
||||
Die Einbeziehung kann in bis zu vier Schritten erfolgen:
|
||||
Eine Einbeziehung erfolgt in bis zu drei Schritten:
|
||||
|
||||
\begin{enumerate}
|
||||
\item Im ersten Schritt kann der Vermittler eine Auskunft einholen, welche Verträge für eine Einbeziehung
|
||||
für den gegebenen Kunden und die gegebene Sparte in Frage kommen.
|
||||
\item Im ersten Schritt holt der Vermittler eine Auskunft ein, welche Verträge für die Einbeziehung
|
||||
eines gegebenen Risikoobjekts für einen Versicherungsnehmer in Frage kommen. Mit den möglichen Verträgen wird
|
||||
zugleich die Information übermittelt, wie die Einbeziehung vorgenommen werden kann.
|
||||
Dies kann je nach Vertrag unterschiedlich sein.
|
||||
|
||||
\item Im zweiten Schritt gibt er den gewählten Vertrag und die Eigenschaften des Risikoobjekts bekannt und
|
||||
erhält Deckungsfragen für die Einbeziehung. Die Deckungsfragen können je nach Vertrag unterschiedlich sein.
|
||||
\item Im optionalen zweiten Schritt kann der Vermittler die zusätzlichen Angaben zur Einbeziehung beantworten
|
||||
und prüfen, ob die Antworten gültig sind, ohne dass die Einbeziehung tatsächlich durchgeführt wird.
|
||||
|
||||
\item Im optionalen dritten Schritt kann der Vermittler die Deckungsfragen beantworten und prüfen, ob die
|
||||
Antworten gültig sind.
|
||||
|
||||
\item Im vierten Schritt führt der Vermittler die Einbeziehung gemäß seinen Vorstellungen durch, in dem er
|
||||
die zuvor beantworteten Deckungsfragen übergibt.
|
||||
\item Im dritten Schritt führt der Vermittler die Einbeziehung gemäß seinen Vorstellungen durch, in dem er
|
||||
die Angaben zur Einbeziehung übermittelt.
|
||||
|
||||
\end{enumerate}
|
||||
|
||||
Dieses mehrstufige Vorgehen hat den Zweck, dass auch komplexe Einbeziehungen ermöglicht werden,
|
||||
bei denen zur Laufzeit Fragen zur Einbeziehung gestellt werden, die von Vertrag und Risikoobjekt abhängig sein
|
||||
bei denen zur Laufzeit Angaben zur Einbeziehung gemacht werden, die von Vertrag und Risikoobjekt abhängig sein
|
||||
können.
|
||||
|
||||
Je nach Komplexität der Aufgabenstellung gibt es für ein Versicherungsunternehmen derzeit zwei
|
||||
Implementierungsprofile. Das Profil ist dem Client vor der Anbindung bekannt zu geben.
|
||||
Implementierungsprofile. Das jeweils zu verwendende Profil wird dem Serviceconsumer im Response des ersten
|
||||
Methodenaufruf bekannt gegeben.
|
||||
|
||||
\begin{tabularx}{\textwidth}{p{4cm}p{9cm}}
|
||||
\begin{tabularx}{\textwidth}{p{4cm}p{6cm}p{3cm}}
|
||||
\toprule
|
||||
\textbf{Profil}&{\textbf{Charakteristik}}\\
|
||||
\textbf{Profil}&{\textbf{Charakteristik}}&{\textbf{SOAP Operations}}\\
|
||||
\midrule
|
||||
{Profil 1: Ohne weitere Angaben zur Einbeziehung\vspace{0.2cm}}&{Es sind keine Fragen zur Deckung.
|
||||
Die Einbeziehung erfolgt über Angabe des Risikoobjekts und des Vertrags.\vspace{0.2cm}}\\
|
||||
{Profil 2: Mit Angaben zur Einbeziehung als VU-spezifisches Objekt}&{Die Angaben zur
|
||||
Einbeziehung sind über VU-spezifische Objekte abgebildet, welche in einer eigenen XSD vom Typ
|
||||
\texttt{AngabenEinbeziehung\_Type} abgeleitet werden. Die Operation AmendRiskProposal gibt vor, welcher Typ für eine
|
||||
konkrete Einbeziehung zu verwenden ist. Die Operation AmendRiskCheck erlaubt die wiederholte Prüfung der Angaben.
|
||||
SOAP Operations: AmendableContracts, AmendRiskProposal, AmendRiskCheck, AmendRiskSubmit.}\\
|
||||
{Profil \texttt{einfach} ohne weitere Angaben zur Einbeziehung\vspace{0.2cm}}&
|
||||
{Die Einbeziehung erfolgt lediglich über Angabe des Risikoobjekts und des Vertrags.
|
||||
Es gibt keine weiterführende Spezifikation der Einbeziehung.\vspace{0.2cm}}&
|
||||
{Amendable-Contracts, AmendRiskSubmit\vspace{0.2cm}}\\
|
||||
{Profil \texttt{vu-spezifisch} mit Angaben zur Einbeziehung als VU-spezifisches Objekt}&{Die Angaben zur
|
||||
Einbeziehung sind über VU-spezifische Objekte abgebildet, welche in einem VU-spezifischen Xsd-File vom Typ
|
||||
\texttt{AngabenEinbeziehung\_Type} abgeleitet werden. Die Operation AmendRiskCheck erlaubt die wiederholte Prüfung der Angaben.}&
|
||||
{Amendable-Contracts, AmendRisk-Check, AmendRiskSubmit}\\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
|
||||
|
||||
\pagebreak
|
||||
\noindent Zu einem späteren Zeitpunkt soll die Norm um die folgenden Profile erweitert werden:\\
|
||||
\begin{tabularx}{\textwidth}{p{4cm}p{9cm}}
|
||||
\toprule\textbf{Profil}&{\textbf{Charakteristik}}\\
|
||||
\begin{tabularx}{\textwidth}{p{4cm}p{6cm}p{3cm}}
|
||||
\toprule\textbf{Profil}&{\textbf{Charakteristik}}&{\textbf{SOAP Operations}}\\
|
||||
\midrule
|
||||
{Profil 3: Mit generischen Angaben zur Einbeziehung\vspace{0.2cm}}&{Zu einem späteren Zeitpunkt wird der Standard um ein
|
||||
{Profil \texttt{standard} mit generischen Angaben zur Einbeziehung\vspace{0.2cm}}&{Zu einem späteren Zeitpunkt wird der Standard um ein
|
||||
Modell mit generischen Deckungsfragen erweitert, welche an Stelle eines VU-spezifischen Typen verwendet werden
|
||||
können. Die Operation AmendRiskProposal gibt vor, welche Deckungsfragen zu beantworten sind.
|
||||
Die Operation AmendRiskCheck erlaubt die wiederholte Prüfung der Deckungsfragen.
|
||||
SOAP Operations: AmendableContracts, AmendRiskProposal, AmendRiskCheck, AmendRiskSubmit.\vspace{0.2cm}}\\
|
||||
{Profil 4: Als Deep-Link}&{Zu einem späteren Zeitpunkt wird der Standard um ein Modell mit Deep-Link
|
||||
erweitert. Mit Hilfe des Deeplinks können Deckungsfragen in einer Maske des Versicherers beantwortet werden und
|
||||
dort die Einbeziehung abgeschlossen werden.}\\
|
||||
können. Die Operation AmendRiskCheck erlaubt die wiederholte Prüfung der Deckungsfragen.\vspace{0.2cm}}&
|
||||
{Amendable-Contracts, AmendRiskCheck, AmendRiskSubmit\vspace{0.2cm}}\\
|
||||
{Profil \texttt{deeplink}}&{Mit Hilfe des Deep-Links können Deckungsfragen in einer Maske des Versicherers
|
||||
beantwortet werden und dort die Einbeziehung abgeschlossen werden.}&{Amendable-Contracts}\\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
|
||||
\noindent Die Services sind durchgängig „stateless“ also untereinander nicht verbunden.
|
||||
\noindent Die Services sind durchgängig „stateless“ also untereinander nicht verbunden.\\
|
||||
|
||||
Der Service AmendRiskSubmit kann eine eine Geschäftsfallnummer zur Nachverfolgung zurückgegeben, wenn die
|
||||
Einbeziehung nicht sofort durchgeführt werden kann und daher eine Nachverfolgung notwendig ist. Das Vorhandensein
|
||||
der Geschäftsfallnummer signalisiert dem Client, dass die Einbeziehung entgegen genommen wurde, aber
|
||||
noch nicht durchgeführt wurde ist.
|
||||
der Geschäftsfallnummer signalisiert dem Client, dass die Einbeziehung angenommen aber
|
||||
noch nicht durchgeführt wurde.
|
||||
|
||||
Hauptanwendungsgebiet dieser Services ist der Flottenvertrag. Alle Beispiele in diesem Dokument beziehen sich auf Flottenverträge.
|
||||
Die Servicedefinitionen sind aber neutral gehalten, da auch Einbeziehungen von Risiken in anderen Sparten möglich sind.
|
||||
@@ -201,28 +201,24 @@
|
||||
xsd & {http://www.w3.org/2001/XMLSchema} \\
|
||||
omds & {urn:omds20} \\
|
||||
cst & {urn:omds3CommonServiceTypes-1-1-0} \\
|
||||
ost & {urn:omds3ServiceTypes-1-1-0} \\
|
||||
ac & {urn:at.vvo.omds.types.omds3types.v1-3-0.on2antrag.common} \\
|
||||
boak & {urn:at.vvo.omds.types.omds3types.v1-3-0.on2antrag.kfz} \\
|
||||
boaU & {urn:at.vvo.omds.types.omds3types.v1-4-0.on2antrag.unfall} \\
|
||||
boaL & {urn:at.vvo.omds.types.omds3types.v1-4-0.on2antrag.leben}\\
|
||||
boaSp & {urn:at.vvo.omds.types.omds3types.v1-4-0.on2antrag.sachprivat} \\
|
||||
\bottomrule
|
||||
\end{tabular} \\
|
||||
|
||||
|
||||
|
||||
\pagebreak
|
||||
\section{Methode AmendableContracts}
|
||||
|
||||
\subsection{Fachliche Beschreibung}
|
||||
Der Service AmendableContracts liefert die Polizzennummern bzw. VertragsIDs von Verträgen, in welche
|
||||
Risikoobjekte einbezogen werden können.\\
|
||||
Risikoobjekte einbezogen werden können.
|
||||
|
||||
\subsubsection{Status}
|
||||
Entwurf (0)
|
||||
|
||||
\subsubsection{Vorbedingung}
|
||||
Der Benutzer existiert und kann über die Daten im SOAP-Header authentifiziert werden.
|
||||
Der Benutzer existiert und kann über die Daten im SOAP-Header authentifiziert werden. Weiters wird geprüft,
|
||||
ob die angegebene VUNr vom Service unterstützt wird. Falls der Benutzer nicht autorisiert ist oder die VUNr falsch ist,
|
||||
wird ein SOAP-Fault geworfen.
|
||||
|
||||
\subsubsection{Ablauf}
|
||||
Der Benutzer spezifiziert einen VN, für den er die Liste der Verträge erhalten möchte, bei denen er
|
||||
@@ -230,21 +226,14 @@
|
||||
Antwort mit 0~\dots~n Verträgen gemäß dem Schema möglich.
|
||||
|
||||
\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.
|
||||
SOAP-Fault geworfen werden, wenn ein Auth-Filter-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.\\
|
||||
beispielsweise weil der User für den angegebenen Vermittler nicht berechtigt ist.\\
|
||||
|
||||
Es wird geprüft, ob eine Vertragssparte übermittelt wurde. Falls keine Vertragssparte erwartet wird aber eine
|
||||
Vertragssparte übermittelt wird oder falls eine Vertragssparte übermittelt wird, der Service aber grundsätzlich
|
||||
keine Vertragssparten unterscheidet, \textit{muss} ein SOAP-Fault geworfen werden. Falls eine Vertragssparte übermittelt
|
||||
wird, diese Sparte aber vom Service nicht unterstützt wird, \textit{muss} ein SOAP-Fault geworfen werden.
|
||||
Es wird geprüft, ob ein Risikoobjekt übermittelt und dieses fachlich sinnvolle Werte enthält.wurde. Falls dies
|
||||
nicht der Fall ist \textit{muss} ein SOAP-Fault geworfen werden.
|
||||
|
||||
\subsection{Technische Dokumentation}
|
||||
|
||||
@@ -255,161 +244,99 @@
|
||||
\subsubsection{Request}
|
||||
|
||||
Der Request hat die folgende Form:\\
|
||||
\includegraphics[width=9cm]{../../../docGen/omds3_ON3_Vertrag_p1}
|
||||
\includegraphics[scale=0.5]{omds3_ON3_Vertrag_p1}
|
||||
|
||||
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.
|
||||
übermittelt werden.
|
||||
\item {Versicherungsnehmer – die Vorgabe eines Versicherungsnehmers als \texttt{Person\_Type}. Diese Vorgabe kann
|
||||
lediglich aus der Partnernummer bestehen oder nähere Angaben wie den Namen usw. enthalten.}
|
||||
\item {Sparte – der Code der Vertragssparte, bei Flotte wird dies regelmäßig \glqq BKF\grqq{} für Kfz-Bündel sein.}
|
||||
\item Risikoobjekt \textemdash~die Daten zum Risikoobjekt, welches einbezogen werden soll als \texttt{cst:VersichertesInteresse\_Type}.
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Response}
|
||||
|
||||
\includegraphics[width=9cm]{../../../docGen/omds3_ON3_Vertrag_p5}
|
||||
\includegraphics[width=9cm]{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.\\
|
||||
Der Response kann 0…n passende Einbeziehungen enthalten, die immer aus Vertragsreferenz, Risikoobjekt und
|
||||
jeweils anzuwendendem Profil für die Einbeziehung bestehen. Wenn für einen Versicherungsnehmer
|
||||
keine Verträge existieren, in welche das angegebene Risikoobjekt einbezogen werden kann, wird kein SOAP-Fault
|
||||
geworfen, sondern die Liste der Einbeziehungen im Responseobjekt bleibt dann leer.\\
|
||||
|
||||
Das Element Vertrag hat die folgende Form:
|
||||
\noindent Das Element Einbeziehung wird vom abstrakten Typ \texttt{Einbeziehung\_Type} abgeleitet.
|
||||
|
||||
\includegraphics[scale=.5]{omds3_ON3_Vertrag_p26}
|
||||
|
||||
\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.
|
||||
\item Vertrag \textemdash~die Polizzennummer oder VertragsID des Vertrags, in welchen einbezogen werden soll.
|
||||
\item Risikoobjekt \textemdash~die Daten zum Risikoobjekt als \texttt{cst:VersichertesInteresse\_Type}, welches einbezogen werden soll.
|
||||
\item Beginn \textemdash~den Beginn der Einbeziehung als \texttt{xsd:date}.
|
||||
\end{itemize}
|
||||
\vspace{1cm}
|
||||
|
||||
\noindent Die unterschiedlichen Profile werden jeweils durch ihren abgeleiteten Typ repräsientiert.
|
||||
\begin{itemize}
|
||||
\item {
|
||||
Das Profil \texttt{einfach} nimmt keine Erweiterungen vor:\\
|
||||
\includegraphics[scale=.5]{omds3_ON3_Vertrag_p32}
|
||||
\vspace{0.2cm}
|
||||
}
|
||||
\item{
|
||||
Profil \texttt{vu-spezifisch}\\
|
||||
\includegraphics[scale=.5]{omds3_ON3_Vertrag_p35}\\
|
||||
\vspace{0.2cm}\\
|
||||
{Hierbei ist Angaben ein Element vom abstrakten Typ \texttt{AngabenEinbeziehung\_Type}. Von diesem Typ
|
||||
muss das jeweilige Versicherungsunternehmen seine spezifischen Typen ableiten.}
|
||||
}
|
||||
|
||||
\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.
|
||||
\noindent Diese abgeleiteten Typen werden auch in den folgenden Methoden verwendet, um die Einbeziehung durchzuführen.
|
||||
|
||||
\subsubsection{Fehler}
|
||||
Folgende Fehler werden über das Fault-Element des Webservice geworfen:
|
||||
|
||||
|
||||
\begin{tabularx}{\textwidth}{lp{2cm}p{3.5cm}p{6cm}}
|
||||
\begin{tabularx}{\textwidth}{lp{1.3cm}p{3.9cm}p{6.8cm}}
|
||||
\toprule
|
||||
{\textbf{Fehlertyp}}&{\textbf{Fehlercode}}&{\textbf{Meldung}}&{\textbf{Warum}}\\
|
||||
{\textbf{Typ}}&{\textbf{Code}}&{\textbf{Meldung}}&{\textbf{Warum}}\\
|
||||
\midrule
|
||||
\endfirsthead %% Ende erster Kopf der Tabelle
|
||||
|
||||
{\textbf{Typ}}&{\textbf{Code}}&{\textbf{Meldung}}&{\textbf{Warum}}\\
|
||||
\midrule
|
||||
\endhead % Ende Fortsetzungskopf der Tabelle, hat kein Toprule
|
||||
|
||||
{Fehler}&{40100}&{Unauthorized}&{Der User ist auf die Methode nicht berechtigt.}\\
|
||||
{Fehler}&{40040}&{VUNr nicht unterstützt}&{Die angegebene VUNr wird von diesem Service nicht unterstützt.}\\
|
||||
{Fehler}&{40040}&{AuthFilter-Element benötigt}&{Nähere Angaben zum Vermittler werden benötigt, sind aber nicht vorhanden.}\\
|
||||
{Fehler}&{40040}&{AuthFilter-Element ungültig}&{AuthFilter-Element wurde übermittelt, kann aber nicht verarbeitet werden.}\\
|
||||
{Fehler}&{40040}&{Unerwartetes AuthFilter-Element}&{AuthFilter-Element wurde übermittelt, es wird aber kein AuthFilter-Element erwartet.}\\
|
||||
{Fehler}&{400}&{Angaben VN unzureichend}&{Die Angaben zum VN sind nicht ausreichend oder in sich widersprüchlich und können nicht erfolgreich verarbeitet werden.}\\
|
||||
{Fehler}&{400}&{VN konnte nicht gefunden werden.}&{Der VN existiert nicht oder der Aufrufer hat keine Berechtigung auf den VN.}\\
|
||||
{Fehler}&{400}&{Sparte nicht unterstützt}&{Die angegebene Vertragssparte wird von der Implementierung grundsätzlich nicht unterstützt.}\\
|
||||
{Fehler}&{400}&{Unerwartete Spartenangabe}&{Es wurde eine Spartenangabe übermittelt, es wird aber keine Angabe erwartet.}\\
|
||||
{Fehler}&{400}&{Sparte fehlt}&{Es wird eine Spartenangabe erwartet, es wurde aber keine übermittelt.}\\
|
||||
{Fehler}&{40510}&{AuthFilter-Element benötigt}&{Nähere Angaben zum Vermittler werden benötigt, sind aber nicht vorhanden.}\\
|
||||
{Fehler}&{40030}&{AuthFilter-Element ungültig}&{AuthFilter-Element wurde übermittelt, kann aber nicht verarbeitet werden.}\\
|
||||
{Fehler}&{40020}&{Unerwartetes AuthFilter-Element}&{AuthFilter-Element wurde übermittelt, es wird aber kein AuthFilter-Element erwartet.}\\
|
||||
{Fehler}&{40000}&{Angaben VN unzureichend}&{Die Angaben zum VN sind nicht ausreichend oder in sich widersprüchlich und können nicht erfolgreich verarbeitet werden.}\\
|
||||
{Fehler}&{40000}&{VN konnte nicht gefunden werden.}&{Der VN existiert nicht oder der Aufrufer hat keine Berechtigung auf den VN.}\\
|
||||
{Fehler}&{40000}&{Risikoobjekt ungültig}&{Die Spezifikation für das Risikoobjekt kann nicht verarbeitet werden, z.B. weil die Angaben widersprüchlich sind oder ein entsprechendes Risikoobjekt nicht auffindbar ist.}\\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
|
||||
|
||||
|
||||
\section{Methode AmendRiskProposal}
|
||||
|
||||
\subsection{Fachliche Beschreibung}
|
||||
Der Service \glqq AmendRiskProposal\grqq{} liefert für einen gegebenen Vertrag und ein gegebenes Risikoobjekt einen
|
||||
Vorschlag oder mehrere Vorschläge für die Einbeziehung. Wenn VU-spezifische Objekte für die Zusatzangaben zur
|
||||
Einbeziehung verwendet werden, so kann der Client an dem Vorschlag ablesen, welches Objekt für diese Einbeziehung
|
||||
zu verwenden ist. Werden generische Objekte für die Angaben zu dieser Einbeziehung verwendet oder ein Deep-Link,
|
||||
so kann dies ebenfalls am Response dieses Service abgelesen werden.
|
||||
|
||||
\subsubsection{Status}
|
||||
Entwurf (0)
|
||||
|
||||
\subsubsection{Vorbedingung}
|
||||
Der Benutzer existiert und kann über die Daten im SOAP-Header authentifiziert werden.
|
||||
|
||||
\subsubsection{Ablauf}
|
||||
Der Benutzer spezifiziert den Vertrag und das Risikoobjekt für die Einbeziehung. Daraufhin gibt der Service
|
||||
einen oder mehrere Vorschläge für die Durchführung der Einbeziehung zurück. Insbesondere kann aus diesen
|
||||
Vorschlägen abgelesen werden, welche Angaben für die Einbeziehung erforderlich sind und wie sie übermittelt
|
||||
werden sollen.
|
||||
|
||||
\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.\\
|
||||
|
||||
\subsection{Technische Dokumentation}
|
||||
|
||||
\subsubsection{ServiceID}
|
||||
|
||||
Die ServiceID dieser Methode ist \glqq AmendRiskProposal\grqq{}.
|
||||
|
||||
\subsubsection{Request}
|
||||
|
||||
\includegraphics[width=9cm]{../../../docGen/omds3_ON3_Vertrag_p19}
|
||||
|
||||
\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 Vertrag \textemdash~die Vorgabe eines Vertrags als Polizzennr. oder VertragsID.
|
||||
\item Risikoobjektparte \textemdash~die Vorgabe eines Risikoobjekts vom Typ\\ \texttt{cst:VersichertesInteresse\_Type}.
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Response}
|
||||
|
||||
Der Response enthält 1…n Vorschläge, mit welchen Angaben die Einbeziehung durchgeführt werden kann.\\
|
||||
|
||||
\includegraphics[width=9cm]{../../../docGen/omds3_ON3_Vertrag_p23}
|
||||
|
||||
\noindent Wobei der einzelne Vorschlag vom Typ \texttt{Einbeziehung\_Type} ist.
|
||||
|
||||
\includegraphics[width=9cm]{../../../docGen/omds3_ON3_Vertrag_p24}
|
||||
|
||||
\begin{itemize}
|
||||
\item Vertrag \textemdash~die Polizzennummer oder VertragsID des Vertrags, in welchen einbezogen werden soll.
|
||||
\item Risikoobjekt \textemdash~die Daten zum Risikoobjekt als \texttt{cst:VersichertesInteresse\_Type}, welches einbezogen werden soll.
|
||||
\item Angaben \textemdash~optional weitere Angaben zur Einbeziehung als \texttt{AngabenEinbeziehung\_Type}.
|
||||
Dies können beispielsweise Angaben zur Zahlweise oder Fragen zur Deckung sein.
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Fehler}
|
||||
Folgende Fehler werden über das Fault-Element des Webservice geworfen:
|
||||
|
||||
|
||||
\begin{tabularx}{\textwidth}{lp{2cm}p{3.5cm}p{6cm}}
|
||||
\toprule
|
||||
{\textbf{Fehlertyp}}&{\textbf{Fehlercode}}&{\textbf{Meldung}}&{\textbf{Warum}}\\
|
||||
\midrule
|
||||
{Fehler}&{40040}&{VUNr nicht unterstützt}&{Die angegebene VUNr wird von diesem Service nicht unterstützt.}\\
|
||||
{Fehler}&{40040}&{AuthFilter-Element benötigt}&{Nähere Angaben zum Vermittler werden benötigt, sind aber nicht vorhanden.}\\
|
||||
{Fehler}&{40040}&{AuthFilter-Element ungültig}&{AuthFilter-Element wurde übermittelt, kann aber nicht verarbeitet werden.}\\
|
||||
{Fehler}&{40040}&{Unerwartetes AuthFilter-Element}&{AuthFilter-Element wurde übermittelt, es wird aber kein AuthFilter-Element erwartet.}\\
|
||||
{Fehler}&{40040}&{Vertrag ungültig}&{Die Spezifikation für den Vertrag kann nicht verarbeitet werden, z.B. weil der Vertrag nicht existiert oder der Client nicht auf den Vertrag berechtigt ist.}\\
|
||||
{Fehler}&{40040}&{Risikoobjekt ungültig}&{Die Spezifikation für das Risikoobjekt kann nicht verarbeitet werden, z.B. weil die Angaben widersprüchlich sind oder ein entsprechendes Risikoobjekt nicht auffindbar ist.}\\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
|
||||
|
||||
\pagebreak
|
||||
\section{Methode AmendRiskCheck}
|
||||
|
||||
\subsection{Fachliche Beschreibung}
|
||||
Der Service \glqq AmendRiskCheck\grqq{} prüft die Angaben zu einer Einbeziehung auf Gültigkeit ohne die Einbeziehung
|
||||
jemals durchzuführen. Wenn der Aufruf grob fehlerhaft ist, erhält der Aufrufer eine SOAP-Exception zurück. Wenn der
|
||||
Aufruf nur teilweise Fehlerhaft ist, besteht die Möglichkeit einen mit Meldungen dekorierten Response zurückzugeben.
|
||||
Der Service \glqq AmendRiskCheck\grqq{} prüft in Profilen \texttt{vu-spezifisch} und \texttt{standard} die Angaben
|
||||
zu einer Einbeziehung auf Gültigkeit,
|
||||
ohne die Einbeziehung jemals durchzuführen. Wenn der Aufruf grob fehlerhaft ist, erhält der Aufrufer eine
|
||||
SOAP-Exception zurück. Wenn der Aufruf nur teilweise Fehlerhaft ist, besteht die Möglichkeit,
|
||||
einen mit Meldungen dekorierten Response zurückzugeben.
|
||||
|
||||
\subsubsection{Status}
|
||||
Entwurf (0)
|
||||
|
||||
\subsubsection{Vorbedingung}
|
||||
Der Benutzer existiert und kann über die Daten im SOAP-Header authentifiziert werden.
|
||||
Der Benutzer existiert und kann über die Daten im SOAP-Header authentifiziert werden. Weiters wird geprüft, ob die
|
||||
angegebene VUNr vom Service unterstützt wird. Falls der Benutzer nicht autorisiert ist oder die VUNr falsch ist,
|
||||
wird ein SOAP-Fault geworfen.\\
|
||||
|
||||
\subsubsection{Ablauf}
|
||||
Der Consumer übermittelt die Daten für eine Einbeziehung (Vertrag, Risikoobjekt und etwaige weitere Angaben).
|
||||
@@ -419,16 +346,12 @@
|
||||
eine tatsächliche Einbeziehung erfolgt.
|
||||
|
||||
\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.
|
||||
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 Auth-Filter-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.\\
|
||||
beispielsweise weil der User für den angegebenen 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.
|
||||
@@ -447,7 +370,7 @@
|
||||
|
||||
\subsubsection{Request}
|
||||
|
||||
\includegraphics[width=9cm]{../../../docGen/omds3_ON3_Vertrag_p7}
|
||||
\includegraphics[width=9cm]{omds3_ON3_Vertrag_p7}
|
||||
|
||||
\noindent Wobei
|
||||
\begin{itemize}
|
||||
@@ -468,27 +391,34 @@
|
||||
\item Einbeziehung \textemdash~die unveränderte oder mit Hinweisen ergänzte Einbeziehung aus dem Request.
|
||||
\end{itemize}
|
||||
|
||||
\includegraphics[width=9cm]{../../../docGen/omds3_ON3_Vertrag_p10}
|
||||
\includegraphics[width=9cm]{omds3_ON3_Vertrag_p10}
|
||||
|
||||
\subsubsection{Fehler}
|
||||
Folgende Fehler werden über das Fault-Element des Webservice geworfen:
|
||||
|
||||
\begin{tabularx}{\textwidth}{lp{2cm}p{3.5cm}p{6cm}}
|
||||
\begin{tabularx}{\textwidth}{lp{1.3cm}p{3.9cm}p{6.8cm}}
|
||||
\toprule
|
||||
{\textbf{Fehlertyp}}&{\textbf{Fehlercode}}&{\textbf{Meldung}}&{\textbf{Warum}}\\
|
||||
{\textbf{Typ}}&{\textbf{Code}}&{\textbf{Meldung}}&{\textbf{Warum}}\\
|
||||
\midrule
|
||||
\endfirsthead %% Ende erster Kopf der Tabelle
|
||||
|
||||
{\textbf{Typ}}&{\textbf{Code}}&{\textbf{Meldung}}&{\textbf{Warum}}\\
|
||||
\midrule
|
||||
\endhead % Ende Fortsetzungskopf der Tabelle, hat kein Toprule
|
||||
{Fehler}&{40100}&{Unauthorized}&{Der User ist auf die Methode nicht berechtigt.}\\
|
||||
{Fehler}&{40040}&{VUNr nicht unterstützt}&{Die angegebene VUNr wird von diesem Service nicht unterstützt.}\\
|
||||
{Fehler}&{40040}&{AuthFilter-Element benötigt}&{Nähere Angaben zum Vermittler werden benötigt, sind aber nicht vorhanden.}\\
|
||||
{Fehler}&{40040}&{AuthFilter-Element ungültig}&{AuthFilter-Element wurde übermittelt, kann aber nicht verarbeitet werden.}\\
|
||||
{Fehler}&{40040}&{Unerwartetes AuthFilter-Element}&{AuthFilter-Element wurde übermittelt, es wird aber kein AuthFilter-Element erwartet.}\\
|
||||
{Fehler}&{40040}&{Vertrag ungültig}&{Die Spezifikation für den Vertrag kann nicht verarbeitet werden, z.B. weil der Vertrag nicht existiert oder der Client nicht auf den Vertrag berechtigt ist.}\\
|
||||
{Fehler}&{40040}&{Risikoobjekt ungültig}&{Die Spezifikation für das Risikoobjekt kann nicht verarbeitet werden, z.B. weil die Angaben widersprüchlich sind oder ein entsprechendes Risikoobjekt nicht auffindbar ist.}\\
|
||||
{Fehler}&{40040}&{Angaben zur Einbeziehung ungültig}&{Die zusätzlichen Angaben zur Einbeziehung sind ungültig und es kann kein Vorschlag für eine gültige Form unterbreitet werden.}\\
|
||||
{Fehler}&{40510}&{AuthFilter-Element benötigt}&{Nähere Angaben zum Vermittler werden benötigt, sind aber nicht vorhanden.}\\
|
||||
{Fehler}&{40030}&{AuthFilter-Element ungültig}&{AuthFilter-Element wurde übermittelt, kann aber nicht verarbeitet werden.}\\
|
||||
{Fehler}&{40020}&{Unerwartetes AuthFilter-Element}&{AuthFilter-Element wurde übermittelt, es wird aber kein AuthFilter-Element erwartet.}\\
|
||||
{Fehler}&{40000}&{Vertrag ungültig}&{Die Spezifikation für den Vertrag kann nicht verarbeitet werden, z.B. weil der Vertrag nicht existiert oder der Client nicht auf den Vertrag berechtigt ist.}\\
|
||||
{Fehler}&{40090}&{Vertragsstatus verhindert Einbeziehung}&{Der Vertrag ist richtig spezifiziert und Risikoobjekte können grundsätzlich einbezogen werden, aber der aktuelle Status des Vertrags lässt eine Einbeziehung nicht zu.}\\
|
||||
{Fehler}&{40000}&{Risikoobjekt ungültig}&{Die Spezifikation für das Risikoobjekt kann nicht verarbeitet werden, z.B. weil die Angaben widersprüchlich sind oder ein entsprechendes Risikoobjekt nicht auffindbar ist.}\\
|
||||
{Fehler}&{40000}&{Angaben zur Einbeziehung ungültig}&{Die zusätzlichen Angaben zur Einbeziehung sind ungültig und es kann kein Vorschlag für eine gültige Form unterbreitet werden.}\\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
|
||||
|
||||
|
||||
\pagebreak
|
||||
\section{Methode AmendRiskSubmit}
|
||||
|
||||
\subsection{Fachliche Beschreibung}
|
||||
@@ -500,17 +430,23 @@
|
||||
Entwurf (0)
|
||||
|
||||
\subsubsection{Vorbedingung}
|
||||
Der Benutzer existiert und kann über die Daten im SOAP-Header authentifiziert werden.
|
||||
Der Benutzer existiert und kann über die Daten im SOAP-Header authentifiziert werden. Weiters wird geprüft,
|
||||
ob die angegebene VUNr vom Service unterstützt wird. Falls der Benutzer nicht autorisiert ist oder die VUNr falsch ist,
|
||||
wird ein SOAP-Fault geworfen.
|
||||
|
||||
\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 oder mit einem Fehler.
|
||||
Wenn die Einbeziehung nicht sofort durchgeführt werden kann, wird eine Geschäftsfallnummer im Response zurückgegeben.
|
||||
|
||||
Optional können Dokumente zur Einbeziehung im Response zurückgegeben werden. Optional kann auch eine
|
||||
Einzelpolizzennummer zurückgegeben werden.
|
||||
|
||||
\subsubsection{Prüflogik}
|
||||
Die Prüflogik \texttt{muss} die gleiche wie bei der Methode \glqq AmendRiskCheck\grqq{} sein, sie wird hier daher nicht nochmals
|
||||
beschrieben.
|
||||
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}
|
||||
|
||||
@@ -520,19 +456,19 @@
|
||||
|
||||
\subsubsection{Request}
|
||||
|
||||
\includegraphics[width=9cm]{../../../docGen/omds3_ON3_Vertrag_p18}
|
||||
\includegraphics[width=9cm]{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 durchgeführt 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}
|
||||
\includegraphics[width=9cm]{omds3_ON3_Vertrag_p21}
|
||||
|
||||
Der Response enthält
|
||||
\begin{itemize}
|
||||
@@ -549,39 +485,73 @@
|
||||
\subsubsection{Fehler}
|
||||
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}}
|
||||
\begin{tabularx}{\textwidth}{lp{1.3cm}p{3.9cm}p{6.8cm}}
|
||||
\toprule
|
||||
{\textbf{Fehlertyp}}&{\textbf{Fehlercode}}&{\textbf{Meldung}}&{\textbf{Warum}}\\
|
||||
{\textbf{Typ}}&{\textbf{Code}}&{\textbf{Meldung}}&{\textbf{Warum}}\\
|
||||
\midrule
|
||||
\endfirsthead %% Ende erster Kopf der Tabelle
|
||||
|
||||
{\textbf{Typ}}&{\textbf{Code}}&{\textbf{Meldung}}&{\textbf{Warum}}\\
|
||||
\midrule
|
||||
\endhead % Ende Fortsetzungskopf der Tabelle, hat kein Toprule
|
||||
{Fehler}&{40100}&{Unauthorized}&{Der User ist auf die Methode nicht berechtigt.}\\
|
||||
{Fehler}&{40040}&{VUNr nicht unterstützt}&{Die angegebene VUNr wird von diesem Service nicht unterstützt.}\\
|
||||
{Fehler}&{40040}&{AuthFilter-Element benötigt}&{Nähere Angaben zum Vermittler werden benötigt, sind aber nicht vorhanden.}\\
|
||||
{Fehler}&{40040}&{AuthFilter-Element ungültig}&{AuthFilter-Element wurde übermittelt, kann aber nicht verarbeitet werden.}\\
|
||||
{Fehler}&{40040}&{Unerwartetes AuthFilter-Element}&{AuthFilter-Element wurde übermittelt, es wird aber kein AuthFilter-Element erwartet.}\\
|
||||
{Fehler}&{40040}&{Vertrag ungültig}&{Die Spezifikation für den Vertrag kann nicht verarbeitet werden, z.B. weil der Vertrag nicht existiert oder der Client nicht auf den Vertrag berechtigt ist.}\\
|
||||
{Fehler}&{40040}&{Risikoobjekt ungültig}&{Die Spezifikation für das Risikoobjekt kann nicht verarbeitet werden, z.B. weil die Angaben widersprüchlich sind oder ein entsprechendes Risikoobjekt nicht auffindbar ist.}\\
|
||||
{Fehler}&{40040}&{Angaben zur Einbeziehung ungültig}&{Die zusätzlichen Angaben zur Einbeziehung sind ungültig und es kann kein Vorschlag für eine gültige Form unterbreitet werden.}\\
|
||||
{Fehler}&{40010}&{AuthFilter-Element benötigt}&{Nähere Angaben zum Vermittler werden benötigt, sind aber nicht vorhanden.}\\
|
||||
{Fehler}&{40030}&{AuthFilter-Element ungültig}&{AuthFilter-Element wurde übermittelt, kann aber nicht verarbeitet werden.}\\
|
||||
{Fehler}&{40020}&{Unerwartetes AuthFilter-Element}&{AuthFilter-Element wurde übermittelt, es wird aber kein AuthFilter-Element erwartet.}\\
|
||||
{Fehler}&{40000}&{Vertrag ungültig}&{Die Spezifikation für den Vertrag kann nicht verarbeitet werden, z.B. weil der Vertrag nicht existiert, dieser Vertrag keine Einbeziehung zulässt oder der Client nicht auf den Vertrag berechtigt ist.}\\
|
||||
{Fehler}&{40090}&{Vertragsstatus verhindert Einbeziehung}&{Der Vertrag ist richtig spezifiziert und Risikoobjekte können grundsätzlich einbezogen werden, aber der aktuelle Status des Vertrags lässt eine Einbeziehung nicht zu.}\\
|
||||
{Fehler}&{40000}&{Risikoobjekt ungültig}&{Die Spezifikation für das Risikoobjekt kann nicht verarbeitet werden, z.B. weil die Angaben widersprüchlich sind oder ein entsprechendes Risikoobjekt nicht auffindbar ist.}\\
|
||||
{Fehler}&{40000}&{Angaben zur Einbeziehung ungültig}&{Die zusätzlichen Angaben zur Einbeziehung sind ungültig und es kann kein Vorschlag für eine gültige Form unterbreitet werden.}\\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
|
||||
\section{Anforderungen Implementierung}
|
||||
\section{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.
|
||||
Der Client muss mit derzeit zwei Profilen umgehen können. Der Client bezieht über \glqq AmendableContracts\grqq{} und
|
||||
die Verträge für den VN, in welche das Risikoobjekt (lies das Kfz) einbezogen werden kann. Dabei erhält er
|
||||
je Vertrag auch die möglichen Profile der Einbeziehung.
|
||||
|
||||
Zum einen ist zu implementieren ein sehr einfaches \textit{Profil 1}, bei welchem keine weiteren
|
||||
Zum einen ist das sehr einfache Profil \texttt{einfach} zu implementieren, 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{}.
|
||||
Zum anderen ist das aufwändigere Profil \texttt{vu-spezifisch} zu implementieren: Dabei gibt \glqq AmendableContracts\grqq{}
|
||||
vor, mit welchem Profil und insbesondere mit welchen zusätzlichen Angaben die Einbeziehung erfolgen kann.
|
||||
Die Methode \glqq AmendRisk\\Check\grqq{} erlaubt es die Angaben zur Einbeziehung zu prüfen und die Durchführung
|
||||
der Einbeziehung erfolgt 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.
|
||||
Bei Profil \texttt{vu-spezifisch} gibt der jeweilige Serviceprovider für die zusätzlichen Angaben zur Einbeziehung
|
||||
eigene Typen vor und dokumentiert ihre Verwendung.
|
||||
|
||||
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.
|
||||
|
||||
\subsection{Serviceprovider}
|
||||
Dem Serviceprovider stehen aktuell zwei Profile zur Auswahl:
|
||||
\begin{itemize}
|
||||
\item ein sehr einfaches, bei dem die Einbeziehung ohne
|
||||
Zusatzangaben funktioniert und
|
||||
\item ein aufwändigeres, bei dem der Serviceprovider seine eigene Lösung für die
|
||||
Zusatzangaben bei der Einbeziehung definieren kann, diese Lösung aber auch an jeden Client kommunizieren muss.
|
||||
\end{itemize}
|
||||
|
||||
Der Serviceprovider kann sich vorab für eines der Profile entscheiden oder je nach Vertrag unterschiedliche Profile
|
||||
zuordnen. Er signalisiert die für einen Vertrag anwendbaren Profile in der Operation \glqq AmendableContracts\grqq{}.
|
||||
|
||||
Im derzeit einfachsten Profil \texttt{einfach} implementiert der Serviceprovider neben\\ \glqq AmendableContracts\grqq{} nur die
|
||||
Methode \glqq AmendRiskSubmit\grqq{}. In dem Fall können neben Vertrag und Risikoobjekt keine zusätzlichen
|
||||
Angaben zur Einbeziehung gemacht werden.
|
||||
|
||||
Im komplexeren Profil \texttt{vu-spezifisch} ist zusätzlich die Methode \glqq AmendRiskCheck\grqq{}
|
||||
zu implementieren. Außerdem erstellt der Serviceprovider eigene Objekte für die zusätzlichen Angaben zur Einbeziehung
|
||||
als Ableitung von \texttt{AngabenEinbeziehung\_Type} und Dokumentiert ihre Verwendung für den Client.
|
||||
|
||||
\section{Hinweise}
|
||||
|
||||
Mit dem nächsten Major-Release wären folgende Änderungen wünschenswert:
|
||||
\begin{itemize}
|
||||
\item Die Lfnr bei \texttt{VersichertesInteresse\_Type} sollte optional werden.
|
||||
\item Beim Versicherungsnehmer als \texttt{Person\_Type} sollte es möglich sein, eine Person nur mit Id ohne Sonstige-Person oder
|
||||
Natürliche-Person zu bilden.
|
||||
\end{itemize}
|
||||
|
||||
\end{document}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 13 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 6.8 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 11 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 10 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 3.5 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 4.4 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.9 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 6.0 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 7.8 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 3.0 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 12 KiB |
Reference in New Issue
Block a user