Merge mit Einbeziehung-Branch
This commit is contained in:
Binary file not shown.
@@ -88,7 +88,7 @@
|
||||
|
||||
\makecell{Jens Bühring}&\makecell[tl]{Dokument erstellt}&\makecell{19.09.2024}\\
|
||||
\makecell{Jens Bühring}&\makecell[tl]{Formattierung angeglichen}&\makecell{28.01.2025}\\
|
||||
|
||||
\makecell{Jens Bühring}&\makecell[tl]{Dokumententypen ergänzt}&\makecell{28.04.2025}\\
|
||||
\bottomrule
|
||||
\end{tabularx} \\
|
||||
\vspace{1cm}
|
||||
@@ -172,7 +172,7 @@
|
||||
85 & Besondere Bedingungen (siehe auch 45) & Download \\
|
||||
86 & Klausel (siehe auch 45) & Download \\
|
||||
87 & \makecell[tl]{Besondere Vereinbarung \\(keine Standardklausel, siehe auch 45)} & Download \\
|
||||
89 & Reisepass (Spezialisierung von 53) & Upload \\
|
||||
89 & {Reisepass (Spezialisierung von 53)} & Upload \\
|
||||
90 & Führerschein (Spezialisierung von 53) & Upload \\
|
||||
91 & Personalausweis (Spezialisierung von 53) & Upload \\
|
||||
92 & \makecell[tl]{Behindertenausweis / Behindertenpass,\\(Spezialisierung 53)} & Upload \\
|
||||
@@ -182,8 +182,8 @@
|
||||
109 & Grundbuchauszug \\
|
||||
113 & Überleitungsprotokoll & Download \\
|
||||
119 & COC / Datenauszug / Typenschein Kfz & Upload \\
|
||||
122 & {Risikofragebogen \footnote{analog Gesundheitsfragen 30 für Sach-, Haftpflicht und weiterer Sparten}} & Upload \\
|
||||
\end{longtable}
|
||||
% \\
|
||||
|
||||
\subsection{Polizzen}
|
||||
Die Polizze ist aus Sicht des OMDS3-Postserivce die mit Abstand wichtigste Dokumentenklasse.
|
||||
@@ -224,7 +224,7 @@
|
||||
8 & \makecell[tl]{Manuelle Prämienberechnung} \\
|
||||
9 & \makecell[tl]{Indexanpassung} \\
|
||||
10 & \makecell[tl]{Wertsicherung (Dynamik im Bereich Leben)} \\
|
||||
11 & \makecell[tl]{Wertnachricht (aktuelle Vertragsinformation)} \\
|
||||
11 & \makecell[tl]{Wertnachricht (aktuelle Vertragsinformation) \footnote{Die Wertnachricht ist in der Regel bei Lebensversicherung ein Auszug, den man oftmals unterjährig bestellt und den aktuellen Wert (Rückkaufswert und oder Wert der Veranlagung) wiedergibt. Daher ist das keine Indexpolizze.}} \\
|
||||
\bottomrule
|
||||
\end{tabular} \\
|
||||
|
||||
@@ -239,13 +239,28 @@
|
||||
\toprule
|
||||
\textbf{Nr.} & {\textbf{Dokumententyp Bedingungen}} \\
|
||||
\midrule
|
||||
5 & Zusatzvereinbarungen \\
|
||||
43 & Rahmenvereinbarung \\
|
||||
%5 & \makecell[tl]{Zusatzvereinbarungen (zw. Vermittler und VU bezogen auf Courtage)} \\
|
||||
43 & \makecell[tl]{Rahmenvereinbarung (Produktbesserstellung für Kunden eines Vermittlers, \\einer Vermittlergruppe)} \\
|
||||
84 & \makecell[tl]{Allgemeine Versicherungsbedingungen} \\
|
||||
85 & \makecell[tl]{Besondere Versicherungsbedingungen, z.B. für eine bestimmte Sparte} \\
|
||||
86 & \makecell[tl]{Klausel, wie sie in Produkten z.B. für optionale Deckungen verwendet wird} \\
|
||||
87 & \makecell[tl]{Besondere Vereinbarung (für Makler, Maklergruppe oder nur für den Vertrag)} \\
|
||||
86 & \makecell[tl]{Klausel, wie sie in Produkten z.B. für optionale Deckungen verwendet wird, \\Teil eines Produkts} \\
|
||||
87 & \makecell[tl]{Besondere Vereinbarung (wie Klausel, aber nicht als Teil des Produkts \\sondern individuell
|
||||
für Vermittler, Vermittlergruppe oder nur für den Vertrag)} \\
|
||||
\bottomrule
|
||||
% Michael Selb vermisst den "Sideletter": In diesem Zuge ist mir noch aufgefallen, dass der Dokumenttyp
|
||||
% „Sideletter“ fehlt. Das ist eine Vereinbarung mit dem VU, wo generell Verbesserungen vereinbart werden.
|
||||
|
||||
\end{tabular} \\
|
||||
|
||||
\subsection{Vereinbarung zwischen VU und Vermittler}
|
||||
\begin{tabular}[c]{ll}
|
||||
\toprule
|
||||
\textbf{Nr.} & {\textbf{Dokumententyp Bedingungen}} \\
|
||||
\midrule
|
||||
5 & Zusatzvereinbarungen (zw. Vermittler und VU bezogen auf Courtage) \\
|
||||
124 & Sideletter (Vereinbarung zwischen Vermittler und VU)\\
|
||||
\bottomrule
|
||||
|
||||
\end{tabular} \\
|
||||
|
||||
\subsection{Ausweise}
|
||||
@@ -256,10 +271,11 @@
|
||||
\toprule
|
||||
\textbf{Nr.} & {\textbf{Dokumententyp Ausweise}} \\
|
||||
\midrule
|
||||
89 & \makecell[tl]{Reisepass} \\
|
||||
90 & \makecell[tl]{Führerschein} \\
|
||||
91 & \makecell[tl]{Personalausweis} \\
|
||||
92 & \makecell[tl]{Behindertenausweis} \\
|
||||
53 & {Ausweis} \\
|
||||
89 & {Reisepass} \\
|
||||
90 & {Führerschein} \\
|
||||
91 & {Personalausweis} \\
|
||||
92 & {Behindertenausweis} \\
|
||||
\bottomrule
|
||||
\end{tabular} \\
|
||||
|
||||
@@ -285,7 +301,7 @@
|
||||
38 & B/M Stufenbestätigung\\
|
||||
52 & Rendement\\
|
||||
57 & Abmeldebestätigung Kfz\\
|
||||
71 & Zahlschein, Erlagschein\\
|
||||
71 & Zahlschein, Erlagschein (siehe auch Präzisierung 82, 123)\\
|
||||
72 & Service-Card\\
|
||||
73 & Ablehnung eines Antrags\\
|
||||
74 & Depotauszug\\
|
||||
@@ -294,11 +310,15 @@
|
||||
78 & Sammelversand (z.B. betriebliche Lebensversicherung) \\
|
||||
79 & Verzeichnis der Versicherten (z.B. betriebliche Lebensversicherung)\\
|
||||
81 & Prämienrückvergütung\\
|
||||
82 & {FP-Zahlungsanweisung}\\
|
||||
93 & Abrechnung Unfall\\
|
||||
94 & Abrechnung Kranken\\
|
||||
97 & Hinterlegungsbestätigung Kfz\\
|
||||
98 & Wiederausfolgung Kfz\\
|
||||
110 & Mahnung\\
|
||||
121 & Bestandsmeldung \\
|
||||
123 & EP-Zahlungsanweisung\\
|
||||
127 & Provisionsabrechnung \\
|
||||
\bottomrule
|
||||
\end{tabular} \\
|
||||
|
||||
@@ -326,6 +346,8 @@
|
||||
83 & Fragebogen zur Schadenregulierung \\
|
||||
106 & Arztbrief \\
|
||||
107 & Befund \\
|
||||
125 & Rechnungseinreichung \\
|
||||
126 & Schadenzahlung \\
|
||||
\bottomrule
|
||||
\end{tabular} \\
|
||||
|
||||
@@ -361,6 +383,25 @@
|
||||
\bottomrule
|
||||
\end{tabular} \\
|
||||
|
||||
\subsection{Behördendokumente}
|
||||
|
||||
\begin{tabular}[c]{ll}
|
||||
\toprule
|
||||
\textbf{Nr.} & {\textbf{Dokumententyp}} \\
|
||||
\midrule
|
||||
54 & Firmenbuchauszug\\
|
||||
56 & Gewerbeschein\\
|
||||
59 & {Grundbuchsbeschluss, siehe auch 109} \\
|
||||
60 & {Einantwortungsbeschluss} \\
|
||||
61 & {Meldebestätigung ZMR} \\
|
||||
99 & Geburtsurkunde\\
|
||||
100 & Heiratsurkunde\\
|
||||
101 & Sterbeurkunde\\
|
||||
109 & Grundbuchauszug \\
|
||||
|
||||
\bottomrule
|
||||
\end{tabular} \\
|
||||
|
||||
|
||||
\subsection{Im Betrieb des Vermittlers}
|
||||
In der Liste der Dokumententypen sind auch solche enthalten, welche nur im Betrieb des Vermittlers
|
||||
@@ -521,7 +562,7 @@
|
||||
68 & Maklervertrag (nicht Maklervollmacht) \\
|
||||
69 & AGB des Vermittlers \footnote{Abzugrenzen von den Bedingungen einer Versicherung, 45 oder 84 \textemdash~87.} \\
|
||||
70 & E-Mail \\
|
||||
71 & Zahlschein, Erlagschein \\
|
||||
71 & Zahlschein, Erlagschein (siehe auch Präzisierung 82, 123) \\
|
||||
72 & Service-Card \\
|
||||
73 & Ablehnung eines Antrags \\
|
||||
74 & Depotauszug \\
|
||||
@@ -532,7 +573,7 @@
|
||||
79 & {Verzeichnis der Versicherten (betriebliche Lebensversicherung)}\\
|
||||
80 & Prolongationsschreiben \\
|
||||
81 & Prämienrückvergütung \\
|
||||
82 & FP-Zahlungsanweisung \\
|
||||
82 & {FP-Zahlungsanweisung \footnote{Folgeprämie-Zahlungsanweisung}}\\
|
||||
83 & Fragebogen zur Schadenregulierung \\
|
||||
84 & {Allgemeine Versicherungsbedingungen (Spezialisierung von 45)}\\
|
||||
85 & {Besondere Versicherungsbedingungen (Spezialisierung von 45)}\\
|
||||
@@ -541,7 +582,10 @@
|
||||
\footnote{Hier sind individuelle Vereinbarungen im Zuge eines Antrags gemeint oder
|
||||
spezielle Konditionen für eine Kundengruppe oder einen Vertriebskanal.
|
||||
Klauseln für optionale Deckungen eines Produkts wären 86.}} \\
|
||||
88 & Freigabeansuchen \\
|
||||
88 & {Freigabeansuchen
|
||||
\footnote{Ansuchen im KFZ Bereich: Wenn ein stärkeres KFZ zu einem bestehenden eingeschlossen werden
|
||||
soll. Um den Vertrag freizubekommen, muss das übernehmende VU dem Bestands-VU ein Schreiben mit der
|
||||
Freigabe ausstellen.}}\\
|
||||
89 & Reisepass (Spezialisierung von Ausweis 53) \\
|
||||
90 & Führerschein (Spezialisierung von Ausweis 53) \\
|
||||
91 & Personalausweis (Spezialisierung von Ausweis 53) \\
|
||||
@@ -567,13 +611,22 @@
|
||||
111 & Notiz \\
|
||||
112 & {Nachricht (Kurznachricht wie SMS, WhatsApp usw.)} \\
|
||||
113 & Überleitungsprotokoll \\
|
||||
114 & SV Zustimmungserklärung (Sozialversicherung) \\
|
||||
114 & {SV Zustimmungserklärung (Sozialversicherung) \footnote{Hierbei handelt es sich um eine spezielle
|
||||
Vollmacht vom Kunden an den Makler, dass dieser Auskünfte über beispielsweise eingereichte KV-Rechnungen
|
||||
erhält. }}\\
|
||||
115 & {Maklervollmacht offen (Spezialisierung von 35) \footnote{Vollmacht noch nicht unterschrieben}} \\
|
||||
116 & {Kündigung Maklervollmacht} \\
|
||||
117 & {Kündigungsbestätigung Maklervollmacht} \\
|
||||
118 & {Auskunftsvollmacht} \\
|
||||
119 & {COC / Datenauszug / Typenschein Kfz} \\
|
||||
|
||||
120 & {KFZ Kostenaufstellung \footnote{Abrechnung und Auflistung KFZ Anmeldung }} \\
|
||||
121 & {Bestandsmeldung \footnote{wie beispielsweise bei der Rechtschutz die aktuellen Risikoobjekte }}\\
|
||||
122 & Risikofragebogen \footnote{analog Gesundheitsfragen 30 für Sach-, Haftpflicht und weiterer Sparten} \\
|
||||
123 & {EP-Zahlungsanweisung \footnote{Erstprämie-Zahlungsanweisung}}\\
|
||||
124 & {Sideletter \footnote{Vereinbarung zwischen Vermittler und VU, wo generell Verbesserungen vereinbart werden.}}\\
|
||||
125 & Rechnungseinreichung \\
|
||||
126 & Schadenzahlung \\
|
||||
127 & Provisionsabrechnung \\
|
||||
\end{longtable}
|
||||
|
||||
\end{document}
|
||||
@@ -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