KapDionOS/productmodel
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Schritte BOA über Vererbung miteinander verknüpft, Baujahr Gebäude optional, ErrorCode optional, neuer Dokumententyp Deckungsvergleich, ReleaseNotes angepasst

Browse Source
This commit is contained in:
Jens Bühring
2022-07-22 11:57:30 +02:00
parent 99cceeb47d
commit 2c420e22e3
5 changed files with 229 additions and 214 deletions
Download Patch File Download Diff File Expand all files Collapse all files

206
OMDSServiceDefinition/src/main/resources/def/r1_8_0/ReleaseNotes-1-8-0.txt
View File

@@ -5,29 +5,33 @@ Version 1.8.0
Was ist neu oder anders in Version 1.8.0 im Vergleich zur Version 1.7.0?
=====================================================================================
1. Version 1.8.0 ist abwärtskompatibel zur Version 1.7.0 in dem Sinne, dass ein XML welches unter 1.7.0 valide ist
auch unter 1.8.0 valide ist. Generierte Objekte können abweichen.
auch unter 1.8.0 valide ist. Generierte Objekte können abweichen und neue Elemente können im XML enthalten sein.
2. Neue Services Deckungsauskunft und Belegeinreichung aufgenommen:
Neue Methoden CheckCoverage und SubmitReceipt.
2. Haftpflicht in Kfz wird optionaler Vertragsbestandteil (bisher verpflichtend)
3. SpartendetailSchaden_Type bekommt folgende neue Attribute Koerperhaelfte, Koerperteil und BehoerdlicheAufnahme
4. Neu aufgenommen Legitimation_Type
5. Mit dem Wert "parameters" gab es ein Problem bei der Generierung von Clients unter Visual Studio. Daher wurde
3. Haftpflicht in Kfz wird optionaler Vertragsbestandteil (bisher verpflichtend)
4. SpartendetailSchaden_Type bekommt folgende neue Attribute Koerperhaelfte, Koerperteil und BehoerdlicheAufnahme
5. Neu aufgenommen Legitimation_Type
6. Mit dem Wert "parameters" gab es ein Problem bei der Generierung von Clients unter Visual Studio. Daher wurde
<message name="..."><part name="parameters" element="ost:.."/></message>
geändert auf
<message name="..."><part name="param" element="ost:.."/></message>
6. Anpassung des Veröffentlichungsprocederes im Dokument ON_1.01.3 Versionierung: Der Steuerkreis
7. Anpassung des Veröffentlichungsprocederes im Dokument ON_1.01.3 Versionierung: Der Steuerkreis
entscheidet über die Veröffentlichung unabhängig vom formalen Status der jeweiligen Norm.
7. Kfz-Kasko: Merkmal Neuwertklausel ja/nein auch bei Teilkasko verfügbar.
8. Selbstbehalt in Sach-Privat auf Produktebene verfügbar. Selbstbehalte bekommen eine Art
8. Kfz-Kasko: Merkmal Neuwertklausel ja/nein auch bei Teilkasko verfügbar.
9. Selbstbehalt in Sach-Privat auf Produktebene verfügbar. Selbstbehalte bekommen eine Art
und können künftig von VU nochmals abgeleitet werden.
9. Kfz-Risikoobjekt erhält ein optionales Element "Historisch" vom Typ boolean.
10. Möglichkeit den Dateinamen beim Upload / Download von Binaries mit anzugeben.
11. ???? === Neues Feld TarifId um einen Antrags- bzw. Vertragsbaustein auf eine konkrete Produktkomponente beziehen zu können.
10. Kfz-Risikoobjekt erhält ein optionales Element "Historisch" vom Typ boolean.
11. Möglichkeit den Dateinamen beim Upload / Download von Binaries mit anzugeben.
12. Neues Feld TarifId um einen Antrags- bzw. Vertragsbaustein auf eine konkrete Produktkomponente beziehen zu können.
Der Typ von TarifId ist abstrakt und muss von der VU überschrieben werden, z.B. mit einem Enum der zulässigen
Werte. === ????
12. Hauptfälligkeit, Zahlrhythmus und Zahlweg stehen jetzt optional auch auf Verkaufsproduktebene zur Verfügung.
Werte.
13. Hauptfälligkeit, Zahlrhythmus und Zahlweg stehen jetzt optional auch auf Verkaufsproduktebene zur Verfügung.
Auf der Produktebene ist die Hauptfälligkeit jetzt optional und Hauptfälligkeit, Zahlrhythmus und Zahlweg sind im
Kommentar als deprecated markiert.
14. Neues Element SpezBOASchritt_Type: Die Schritte in BOA erben von diesem gemeinsamen Element und
bauen aufeinander auf.
15. Baujahr Gebäude ist optional
16. Neuer DocumentType 42 = Deckungsvergleich
=============
@@ -37,7 +41,7 @@ Version 1.7.0
Was ist neu oder anders in Version 1.7.0 im Vergleich zur Version 1.6.0?
=====================================================================================
1. Version 1.7.0 ist abwärtskompatibel zur Version 1.6.0 in dem Sinne, dass ein XML welches unter 1.6.0 valide ist
auch unter 1.7.0 valide ist. Generierte Objekte können abweichen.
auch unter 1.7.0 valide ist. Generierte Objekte können abweichen und neue Elemente können im XML enthalten sein.
2. Berechnung-Offert-Antrag wurde für die Sparten Unfall und Leben hinzugefügt.
Für Leben wurde die Möglichkeit geschaffen bis zu 4 Produktebenen abzubilden (bisher max. 3 Ebenen).
3. Struktur für Konvertierung in BOA wurde nochmals überarbeitet und verwendet jetzt
@@ -59,20 +63,20 @@ Version 1.6.0
Was ist neu oder anders in Version 1.6.0 im Vergleich zur Version 1.5.0?
=====================================================================================
1. Version 1.6.0 ist abwärtskompatibel zur Version 1.5.0 in dem Sinne, dass ein XML welches unter 1.5.0 valide ist
auch unter 1.6.0 valide ist. Generierte Objekte können abweichen.
2. Aufnahme der Aufbauart in Kfz
3. Aufnahme Felder für Konvertierung in Berechnung-Offert-Antrag
4. Erweiterung der Liste der Dokumentenarten
5. Aufnahmen eines Änderungsgrundes in BOA
6. Verwendet OMDS 2.14-00 (SNAPSHOT) statt 2.11-00:
- neue Vertragsrollen: AZ - Abweichender Zulassungsbesitzer, FI - Firmeninhaber, ZB - Zustellbevollmächtigter
- neues Feld GesFormCdType in Sonst-Person
- TIN für "Titel nachgestellt"
- neuer LegArtCd_Type: FA - Firmenbuchauszug
- Geburtsland an der Person
7. Entfernen der Restriktion auf genau 4 Zeichen im Status
8. Verwendung technische Objekte in CommonRequest_Type
1. Version 1.6.0 ist abwärtskompatibel zur Version 1.5.0 in dem Sinne, dass ein XML welches unter 1.5.0 valide ist
auch unter 1.6.0 valide ist. Generierte Objekte können abweichen und neue Elemente können im XML enthalten sein.
2. Aufnahme der Aufbauart in Kfz
3. Aufnahme Felder für Konvertierung in Berechnung-Offert-Antrag
4. Erweiterung der Liste der Dokumentenarten
5. Aufnahmen eines Änderungsgrundes in BOA
6. Verwendet OMDS 2.14-00 (SNAPSHOT) statt 2.11-00:
- neue Vertragsrollen: AZ - Abweichender Zulassungsbesitzer, FI - Firmeninhaber, ZB - Zustellbevollmächtigter
- neues Feld GesFormCdType in Sonst-Person
- TIN für "Titel nachgestellt"
- neuer LegArtCd_Type: FA - Firmenbuchauszug
- Geburtsland an der Person
7. Entfernen der Restriktion auf genau 4 Zeichen im Status
8. Verwendung technische Objekte in CommonRequest_Type
=============
@@ -81,22 +85,22 @@ Version 1.5.0
Was ist neu oder anders in Version 1.5.0 im Vergleich zur Version 1.4.0?
=====================================================================================
1. Version 1.5.0 ist abwärtskompatibel zur Version 1.4.0 in dem Sinne, dass ein XML welches unter 1.4.0 valide ist
auch unter 1.5.0 valide ist. Generierte Objekte können abweichen.
2. Berechnung-Offert-Antrag wurde für die Sparte Sach-Privat hinzugefügt.
3. Es wurden Methoden definiert, um Schäden zu melden und Schadenmeldungen zu suchen und aufzurufen.
4. Vinkulierung ist nicht mehr im allgemeinen Antrags-Spezifikation zu finden, sondern
nur bei KFZ. Hintergrund ist, dass für Sicherstellungen (inkl. Vinkulierung) mit 1.6.0 eine
allgemeinere Lösung kommt.
5. In der Berechnung können optional schon Daten zu Personen angegeben werden. Dies erfolgt im
Vorgriff auf Personenversicherungen, wo dies benötigt wird. In der Praxis hat sich überdies
erwiesen, dass auch bei Sachversicherungen bei manchen Versicherern bereits in der Berechnung
Personendaten erforderlich sind.
6. Es wurden neue "generische" Produktbausteine geschaffen, welche optional Produkt-Metadaten
für den Client zu den Produktbausteinen enthalten können.
7. Es wurden neue Ableitungen für das Versicherte Interesse geschaffen.
8. Für die Übermittlung von Metadaten zu Attributen wurden spezielle Typen angelegt
9. Das allgemeine Response-Objekt kann "Referenzen" aufnehmen. Dies sind Deep-Links oder andere Querverweise.
1. Version 1.5.0 ist abwärtskompatibel zur Version 1.4.0 in dem Sinne, dass ein XML welches unter 1.4.0 valide ist
auch unter 1.5.0 valide ist. Generierte Objekte können abweichen und neue Elemente können im XML enthalten sein.
2. Berechnung-Offert-Antrag wurde für die Sparte Sach-Privat hinzugefügt.
3. Es wurden Methoden definiert, um Schäden zu melden und Schadenmeldungen zu suchen und aufzurufen.
4. Vinkulierung ist nicht mehr im allgemeinen Antrags-Spezifikation zu finden, sondern
nur bei KFZ. Hintergrund ist, dass für Sicherstellungen (inkl. Vinkulierung) mit 1.6.0 eine
allgemeinere Lösung kommt.
5. In der Berechnung können optional schon Daten zu Personen angegeben werden. Dies erfolgt im
Vorgriff auf Personenversicherungen, wo dies benötigt wird. In der Praxis hat sich überdies
erwiesen, dass auch bei Sachversicherungen bei manchen Versicherern bereits in der Berechnung
Personendaten erforderlich sind.
6. Es wurden neue "generische" Produktbausteine geschaffen, welche optional Produkt-Metadaten
für den Client zu den Produktbausteinen enthalten können.
7. Es wurden neue Ableitungen für das Versicherte Interesse geschaffen.
8. Für die Übermittlung von Metadaten zu Attributen wurden spezielle Typen angelegt
9. Das allgemeine Response-Objekt kann "Referenzen" aufnehmen. Dies sind Deep-Links oder andere Querverweise.
=============
@@ -106,7 +110,7 @@ Version 1.4.0
Was ist neu oder anders in Version 1.4.0 im Vergleich zur Version 1.3.0?
=====================================================================================
1. Version 1.4.0 ist abwärtskompatibel zur Version 1.3.0 in dem Sinne, dass ein XML welches unter 1.3.0 valide ist
auch unter 1.4.0 valide ist. Generierte Objekte können abweichen.
auch unter 1.4.0 valide ist. Generierte Objekte können abweichen und neue Elemente können im XML enthalten sein.
2. Folgend dem Beschluss des Steuerkreises zur Versionierung vom 28.5.2019 sind alle
Definitionen, die noch nicht durch zwei Implementierungen validiert wurden,
aus dem offiziellen Release entfernt worden.
@@ -155,28 +159,28 @@ Version 1.3.0
Was ist neu oder anders in Version 1.3.0 im Vergleich zur Version 1.2.0?
=====================================================================================
1. Version 1.3.0 ist abwärtskompatibel zur Version 1.2.0 in dem Sinne, dass ein XML welches unter 1.2.0 valide ist
auch unter 1.3.0 valide ist. Generierte Objekte können abweichen.
2. Neu enthalten ist: KFZ Berechnung - Offert - Antrag
3. Schaden hat bislang Status "Empfehlung" und wurde bisher noch in keiner Task-force erprobt.
Schaden wurde nicht-abwärtskompatibel verändert:
* VUNr in Requests ist jetzt obligatorisch
* Bereinigung von Inner-Classes
* SchadenStatus_Type erbt jetzt von AbstraktesEreignisStatusAenderung_Type und kann damit auch in
Service "GetStatusChanges" verwendet werden.
* InformationenPerson_Type - Fehlerkorrektur: Personennr war nicht als optional vermerkt
* GetNumberOfDocumentsRequest_Type und GetDocumentInfosRequest_Type:
a) Objektspezifikation, also der Bezug auf ein Geschäftsobjekt, ist optional
b) Zeitraumangabe: Änderung von omds:EL-Zeitraum_Type auf neues Element Zeitraum_Type,
welches keine Art des Zeitraums enthält
* GetDocumentInfosRequest_Type: Vorgaben zur Offset und MaxResults
* GetDocumentInfosResponse_Type: verwendet statt Typ ArcImageInfo den neuen Typ DokumentenReferenz_Type,
welcher eine Referenz auf ein Geschäftsobjekt enthalten kann
* SearchClaimRequest_Type, ChangedClaimsListRequest_Type und LossEventListRequest_Type verwenden statt
omds:EL-Zeitraum_Type den neuen Typ Zeitraum_Type
1. Version 1.3.0 ist abwärtskompatibel zur Version 1.2.0 in dem Sinne, dass ein XML welches unter 1.2.0 valide ist
auch unter 1.3.0 valide ist. Generierte Objekte können abweichen und neue Elemente können im XML enthalten sein.
2. Neu enthalten ist: KFZ Berechnung - Offert - Antrag
3. Schaden hat bislang Status "Empfehlung" und wurde bisher noch in keiner Task-force erprobt.
Schaden wurde nicht-abwärtskompatibel verändert:
* VUNr in Requests ist jetzt obligatorisch
* Bereinigung von Inner-Classes
* SchadenStatus_Type erbt jetzt von AbstraktesEreignisStatusAenderung_Type und kann damit auch in
Service "GetStatusChanges" verwendet werden.
* InformationenPerson_Type - Fehlerkorrektur: Personennr war nicht als optional vermerkt
* GetNumberOfDocumentsRequest_Type und GetDocumentInfosRequest_Type:
a) Objektspezifikation, also der Bezug auf ein Geschäftsobjekt, ist optional
b) Zeitraumangabe: Änderung von omds:EL-Zeitraum_Type auf neues Element Zeitraum_Type,
welches keine Art des Zeitraums enthält
* GetDocumentInfosRequest_Type: Vorgaben zur Offset und MaxResults
* GetDocumentInfosResponse_Type: verwendet statt Typ ArcImageInfo den neuen Typ DokumentenReferenz_Type,
welcher eine Referenz auf ein Geschäftsobjekt enthalten kann
* SearchClaimRequest_Type, ChangedClaimsListRequest_Type und LossEventListRequest_Type verwenden statt
omds:EL-Zeitraum_Type den neuen Typ Zeitraum_Type
4. ServiceFault kann einen zusätzlichen Rückgabewert enthalten: Den String "elementReference".
5. Fehlerkorrektur in ElementIdType: Das Attribut idValidUntil darf null sein.
4. ServiceFault kann einen zusätzlichen Rückgabewert enthalten: Den String "elementReference".
5. Fehlerkorrektur in ElementIdType: Das Attribut idValidUntil darf null sein.
=============
@@ -186,11 +190,11 @@ Version 1.2.0
Was ist neu oder anders in Version 1.2.0 im Vergleich zur Version 1.1.1?
=====================================================================================
1. Version 1.2.0 ist abwärtskompatibel zur Version 1.1.1, WSDLs und XSDs sind unverändert
1. Version 1.2.0 ist abwärtskompatibel zur Version 1.1.1, WSDLs und XSDs sind unverändert.
2. Dokument "ON_1.02.1_AuthentifizierungAllgemein 1.2.0.docx" wurde um OAuth ergänzt und
es wurde ein erläuterndes Dokument zu OAuth hinzugefügt: "Erläuterungen_OAuth_zu_ON_1.02.1.docx".
Die Einführung von OAuth hat aber keine Auswirkungen auf die SOAP-Definitions-Files.
2. Dokument "ON_1.02.1_AuthentifizierungAllgemein 1.2.0.docx" wurde um OAuth ergänzt und
es wurde ein erläuterndes Dokument zu OAuth hinzugefügt: "Erläuterungen_OAuth_zu_ON_1.02.1.docx".
Die Einführung von OAuth hat aber keine Auswirkungen auf die SOAP-Definitions-Files.
=============
Version 1.1.1
@@ -199,38 +203,38 @@ Version 1.1.1
Was ist neu oder anders in Version 1.1.1 im Vergleich zur Version 1.1.0?
========================================================================
1. Es werden einige Fehler korrigiert, es gibt keine grundsaetzlichen Aenderungen. Daher
ist bleiben die Namespaces unveraendert gegenueber Version 1.1.0.
1. Es werden einige Fehler korrigiert, es gibt keine grundsaetzlichen Aenderungen.
Daher bleiben die Namespaces unveraendert gegenueber Version 1.1.0.
2. Die Filenames der WSDL und XSD-Files haben die Versionsnummer nicht mehr angehängt,
da dies als unhandlich in der Generierung beeinsprucht wurde. Die Versionsnummer 1.1.1 ist
aber als Attribut im Kopf der XML-Dateien enthalten.
2. Die Filenames der WSDL und XSD-Files haben die Versionsnummer nicht mehr angehängt,
da dies als unhandlich in der Generierung beeinsprucht wurde. Die Versionsnummer 1.1.1 ist
aber als Attribut im Kopf der XML-Dateien enthalten.
3. Das Element serviceFault im File omds3CommonServiceTypes.xsd hatte keinen Type zugewiesen.
Dies wurde korrigiert auf Type ServiceFault.
3. Das Element serviceFault im File omds3CommonServiceTypes.xsd hatte keinen Type zugewiesen.
Dies wurde korrigiert auf Type ServiceFault.
4. Das Element GeschInteresseLfnr hatte keinen Typ und hat jetzt den Typ xsd:unsignedIint bekommen.
4. Das Element GeschInteresseLfnr hatte keinen Typ und hat jetzt den Typ xsd:unsignedIint bekommen.
5. In GetDocumentInfosResponse_Type hatten ActualOffset, ActualMaxResults und TotalResults keinen Typ.
Der Typ wurde für die drei Elemente auf xsd:unsignedInt festgelegt.
5. In GetDocumentInfosResponse_Type hatten ActualOffset, ActualMaxResults und TotalResults keinen Typ.
Der Typ wurde für die drei Elemente auf xsd:unsignedInt festgelegt.
6. In MeldungsZusammenfassung_Type hatte das Element LfdNr keinen Typ. Der Typ wurde festgelegt mit xsd:unsignedInt.
6. In MeldungsZusammenfassung_Type hatte das Element LfdNr keinen Typ. Der Typ wurde festgelegt mit xsd:unsignedInt.
7. In Schadenereignis_Type hatten die Elemente vormaligeIdGeschaeftsfall und nachfolgendeIdGeschäftsfall keinen Typ.
Der Typ wurde festgelegt mit 'xsd:string'. Der Umlaut im Element 'nachfolgendeIdGeschäftsfall' wurde aufgelöst
zu 'nachfolgendeIdGeschaeftsfall'.
7. In Schadenereignis_Type hatten die Elemente vormaligeIdGeschaeftsfall und nachfolgendeIdGeschäftsfall keinen Typ.
Der Typ wurde festgelegt mit 'xsd:string'. Der Umlaut im Element 'nachfolgendeIdGeschäftsfall' wurde aufgelöst
zu 'nachfolgendeIdGeschaeftsfall'.
8. In SchadenLight_Type hatte das Element 'bearbStandCd' keinen Typ. Dieser wurde festgelegt mit 'BearbStandCd_Type'.
Ferner hatten die Elemente 'vormaligeSchadennr' und 'nachfolgendeSchadennr' keinen Typ. Dieser wurde festgelegt mit 'xsd:string'.
8. In SchadenLight_Type hatte das Element 'bearbStandCd' keinen Typ. Dieser wurde festgelegt mit 'BearbStandCd_Type'.
Ferner hatten die Elemente 'vormaligeSchadennr' und 'nachfolgendeSchadennr' keinen Typ. Dieser wurde festgelegt mit 'xsd:string'.
9. In SchadenType hatte das Element 'bearbStandCd' keinen Typ. Dieser wurde festgelegt mit 'BearbStandCd_Type'.
Ferner hatten die Elemente 'vormaligeSchadennr' und 'nachfolgendeSchadennr' keinen Typ. Dieser wurde festgelegt mit 'xsd:string'.
9. In SchadenType hatte das Element 'bearbStandCd' keinen Typ. Dieser wurde festgelegt mit 'BearbStandCd_Type'.
Ferner hatten die Elemente 'vormaligeSchadennr' und 'nachfolgendeSchadennr' keinen Typ. Dieser wurde festgelegt mit 'xsd:string'.
10. In Meldungszusammenfassung_Type im ErgebnisSchaeden das Element 'LfdNr' war kein Typ festelegt. Dieser wurde auf
'xsd:unsignedInt' festgelegt.
'xsd:unsignedInt' festgelegt.
11. In omds3Services.wsdl und in omds3ServicesBroker.wsdl waren die Faultelemente bei einigen Services für wsdl und soap
unterschiedlich benannt. Die Benennung wurde angegelichen.
unterschiedlich benannt. Die Benennung wurde angegelichen.
=============
@@ -240,25 +244,25 @@ Version 1.1.0
Was ist neu oder anders in Version 1.1.0 im Vergleich zur Version 1.0.0?
========================================================================
1. Filenames wurden mit Versionsnummer '1-1-0' ergaenzt, Namespaces haben ebenfalls die Versionsnummer erhalten.
1. Filenames wurden mit Versionsnummer '1-1-0' ergaenzt, Namespaces haben ebenfalls die Versionsnummer erhalten.
2. Die Services für Schadenmeldung und Schadenstatus wurden ergänzt.
2. Die Services für Schadenmeldung und Schadenstatus wurden ergänzt.
3. Neues WSDL für Services auf der Maklerseite: 'omds3ServicesBroker-1-1-0.wsdl'.
3. Neues WSDL für Services auf der Maklerseite: 'omds3ServicesBroker-1-1-0.wsdl'.
4. Ein neues XSD fuer Typen, die allen OMDS 3 Services gemeinsam sind: 'omds3CommonServiceTypes-1-1-0.xsd'.
Übergeordnete Datentypen und Elemente sind in diese Datei verschoben worden.
4. Ein neues XSD fuer Typen, die allen OMDS 3 Services gemeinsam sind: 'omds3CommonServiceTypes-1-1-0.xsd'.
Übergeordnete Datentypen und Elemente sind in diese Datei verschoben worden.
5. Im Element UserDataResponse ist das Unterlement 'address' enfallen, da die Adressdaten auch im Unterelement 'person' übermittelt werden können.
5. Im Element UserDataResponse ist das Unterlement 'address' enfallen, da die Adressdaten auch im Unterelement 'person' übermittelt werden können.
6. Die Message 'serviceFault' im WSDL ist umbenannt worden nach 'ServiceFaultMsg', um Verwechslung mit dem Typ 'ServiceFault' im XSD zu vermeiden.
Die Referenzen auf das Element 'serviceFault' in den XSD-Files sind ersetzt worden durch lokale Elemente 'ServiceFault' mit dem Typ 'ServiceFault'
6. Die Message 'serviceFault' im WSDL ist umbenannt worden nach 'ServiceFaultMsg', um Verwechslung mit dem Typ 'ServiceFault' im XSD zu vermeiden.
Die Referenzen auf das Element 'serviceFault' in den XSD-Files sind ersetzt worden durch lokale Elemente 'ServiceFault' mit dem Typ 'ServiceFault'
7. Im Typ 'HttpActionLinkType' fehlten die verschiedenen in der Dokumentation vorgesehenen Types im Enum. Diese wurden ergänzt.
7. Im Typ 'HttpActionLinkType' fehlten die verschiedenen in der Dokumentation vorgesehenen Types im Enum. Diese wurden ergänzt.
8. Im Typ 'ElementIdType' fehlte der Typ des Elements 'idIsSingleUse'. Dieser wurde als boolean deklariert.
8. Im Typ 'ElementIdType' fehlte der Typ des Elements 'idIsSingleUse'. Dieser wurde als boolean deklariert.
9. Exemplarische Demonstration einer Versicherungs-spezifischen Erweiterung des Services wurde aufgenommen als 'omds3exampleVuServiceTypes-1-1-0.xsd'.
9. Exemplarische Demonstration einer Versicherungs-spezifischen Erweiterung des Services wurde aufgenommen als 'omds3exampleVuServiceTypes-1-1-0.xsd'.
10. Die Deklaration einer UsernameToken-Policy wurde ins WSDL 'omds3Services-1-1-0.wsdl' aufgenommen.

7
OMDSServiceDefinition/src/main/resources/def/r1_8_0/omds3CommonServiceTypes.xsd
View File

@@ -38,7 +38,7 @@
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="errorCode" type="xsd:integer">
<xsd:element name="errorCode" type="xsd:integer" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Fehlercode entsprechend allgemeiner Fehlerliste
</xsd:documentation>
@@ -330,6 +330,11 @@
<xsd:documentation>Anmeldung Kundenportal</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="42">
<xsd:annotation>
<xsd:documentation>Deckungsvergleich</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="PartnerRoleType">

5
OMDSServiceDefinition/src/main/resources/def/r1_8_0/omds3Services.wsdl
View File

@@ -1,8 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<!-- Release 1.8.0 -->
<!-- Hinweis für Generierung von Clients in Visual Studio: Visual Studio hat Probleme Clients zu generieren,
wenn der <part name="parameters" /> ist. Vorschlag für einen Work-around ist, beim Generieren des Clients den
"name" z.B. auf "param" zu ändern, z.B. <part name="param" />.
<!-- Hinweis 20.4.2022: Es gab ein Problem bei der Generierung von Clients in Visual Studio: Visual Studio hat Probleme Clients zu generieren,
wenn der <part name="param" ... /> ist. Es wurde daher der part name auf "param" geändert.
-->
<definitions name="omds3Services-1-4-0" targetNamespace="urn:omds3Services-1-4-0"
xmlns:os="urn:omds3Services-1-4-0"

223
OMDSServiceDefinition/src/main/resources/def/r1_8_0/omds3_ON2_Antrag_Common.xsd
View File

@@ -4,128 +4,135 @@
<xsd:import namespace="urn:omds3CommonServiceTypes-1-1-0" schemaLocation="omds3CommonServiceTypes.xsd"/>
<xsd:import namespace="urn:omds3ServiceTypes-1-1-0" schemaLocation="omds3ServiceTypes.xsd"/>
<!--Prozessobjekte Berechnung, Offert, Antrag - Spartenübergreifend-->
<xsd:complexType name="SpezBOASchritt_Type">
<xsd:annotation>
<xsd:documentation>Abstrackter Basistyp für das Datenmodell aller BOA-Prozessschritte</xsd:documentation>
</xsd:annotation>
</xsd:complexType>
<xsd:complexType name="SpezBerechnung_Type" abstract="true">
<xsd:annotation>
<xsd:documentation>Abstrakter Basistyp Berechnung, der bei Request und bei Response gleich ist</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="Personen" type="cst:BeteiligtePersonVertrag_Type" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>Liste aller benötigten Personen, welche dann über ihre Rolle direkt referenziert werden. Im Offert ist dies insb. der Versicherungsnehmer.</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:complexContent>
<xsd:extension base="SpezBOASchritt_Type">
<xsd:sequence>
<xsd:element name="Personen" type="cst:BeteiligtePersonVertrag_Type" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>Liste aller benötigten Personen, welche dann über ihre Rolle direkt referenziert werden. Im Offert ist dies insb. der Versicherungsnehmer.</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="SpezOffert_Type" abstract="true">
<xsd:annotation>
<xsd:documentation>Abstrakter Basistyp Offert, der bei Request und Response gleich ist</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="Offertnummer" type="cst:ObjektId_Type" minOccurs="0"/>
<xsd:element name="Personen" type="cst:BeteiligtePersonVertrag_Type" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>Liste aller benötigten Personen, welche dann über ihre Rolle direkt referenziert werden. Im Offert ist dies insb. der Versicherungsnehmer.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="Versicherungsnehmer" type="xsd:unsignedShort">
<xsd:annotation>
<xsd:documentation>Referenz auf die Person, die als Versicherungsnehmer fungiert. </xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:complexContent>
<xsd:extension base="SpezBOASchritt_Type">
<xsd:sequence>
<xsd:element name="Offertnummer" type="cst:ObjektId_Type" minOccurs="0"/>
<xsd:element name="Personen" type="cst:BeteiligtePersonVertrag_Type" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>Liste aller benötigten Personen, welche dann über ihre Rolle direkt referenziert werden. Im Offert ist dies insb. der Versicherungsnehmer.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="Versicherungsnehmer" type="xsd:unsignedShort">
<xsd:annotation>
<xsd:documentation>Referenz auf die Person, die als Versicherungsnehmer fungiert. </xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="SpezAntrag_Type" abstract="true">
<xsd:annotation>
<xsd:documentation>Abstrakter Basistyp für Antrag, der bei Request und bei Response gleich ist</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="Antragsart" type="cst:Antragsart_Type" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Die Antragsart kann auch vom ServiceProvider automatisch bestimmt werden, dann bleibt sie im Request leer.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="Personen" type="cst:BeteiligtePersonVertrag_Type" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>Liste aller benötigten Vertragspersonen (nicht versicherte Personen), welche dann über ihre Rolle referenziert werden. Die Personen können eine Adresse enthalten.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="Versicherungsnehmer" type="xsd:unsignedShort">
<xsd:annotation>
<xsd:documentation>Referenz auf die Person, die als Versicherungsnehmer fungiert. </xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="AbweichenderPraemienzahler" type="xsd:unsignedShort" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Referenz auf einen abweichenden Praemienzahler, wenn nicht der Versicherungsnehmer die Prämie zahlt</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="WeitereVersicherungsnehmer" type="xsd:unsignedShort" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>Referenz auf weitere Versicherungsnehmer</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="WeitereVertragspersonen" type="cst:Vertragsperson_Type" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>Weitere Personen in Vertragsrollen</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="AbgelehnteRisiken" type="cst:AbgelehnteRisiken_Type" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Bestehen Ablehnungen zu den beantragten Risiken</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="Vorversicherungen" type="cst:Vorversicherungen_Type" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Bestehende Vorversicherungen zu dem Antrag</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="Zahlungsdaten" type="cst:Zahlungsdaten_Type">
<xsd:annotation>
<xsd:documentation>Beschreibt die Art der Zahlung und enthält die zugehörigen Daten</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="Sepa" type="cst:SepaCd_Type" minOccurs="0">
<xsd:annotation>
<xsd:documentation>SEPA-Mandat-Steuerung, wenn Zahlungsdaten ein SEPA-Mandat notwendig machen.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="Polizzenversand" type="cst:PolizzenversandType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>alternativer Polizzenversand</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="Datenschutzbestimmungen" type="cst:Datenverwendung_Type">
<xsd:annotation>
<xsd:documentation>Allgemeine Datenschutzbestimmungen</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="Kontierung" type="cst:Kontierung_Type" minOccurs="0" maxOccurs="3"/>
<xsd:element name="Ersatzpolizzennummer" type="cst:Ersatzpolizzen_Type" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Ersatzpolizzennummern für eine manuelle Ablöse von Polizzen. Nicht für automatische Konvertierung oder Fahrzeugwechsel.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="ZusendungWeitereDokumente" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>Sollen weitere Antragsdokumente zugestellt werden (z.B. IVK)</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="ZusaetzlicheAntragsdaten" type="ZusaetzlicheAntragsdaten_Type" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>Moeglichkeit fuer die Erweitung des Standards um eigene Antragsdaten</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="Sicherstellungen" type="cst:Sicherstellung_Type" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>Daten zu etwaigen Sicherstellungen</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="Einwilligungen" type="cst:Einwilligung_Type" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>Zustimmung zu vorgegebenen Fragen, z.B. Datenverarbeitung von Gesundheitsdaten</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:complexContent>
<xsd:extension base="SpezOffert_Type">
<xsd:sequence>
<xsd:element name="Antragsart" type="cst:Antragsart_Type" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Die Antragsart kann auch vom ServiceProvider automatisch bestimmt werden, dann bleibt sie im Request leer.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="AbweichenderPraemienzahler" type="xsd:unsignedShort" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Referenz auf einen abweichenden Praemienzahler, wenn nicht der Versicherungsnehmer die Prämie zahlt</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="WeitereVersicherungsnehmer" type="xsd:unsignedShort" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>Referenz auf weitere Versicherungsnehmer</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="WeitereVertragspersonen" type="cst:Vertragsperson_Type" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>Weitere Personen in Vertragsrollen</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="AbgelehnteRisiken" type="cst:AbgelehnteRisiken_Type" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Bestehen Ablehnungen zu den beantragten Risiken</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="Vorversicherungen" type="cst:Vorversicherungen_Type" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Bestehende Vorversicherungen zu dem Antrag</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="Zahlungsdaten" type="cst:Zahlungsdaten_Type">
<xsd:annotation>
<xsd:documentation>Beschreibt die Art der Zahlung und enthält die zugehörigen Daten</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="Sepa" type="cst:SepaCd_Type" minOccurs="0">
<xsd:annotation>
<xsd:documentation>SEPA-Mandat-Steuerung, wenn Zahlungsdaten ein SEPA-Mandat notwendig machen.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="Polizzenversand" type="cst:PolizzenversandType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>alternativer Polizzenversand</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="Datenschutzbestimmungen" type="cst:Datenverwendung_Type">
<xsd:annotation>
<xsd:documentation>Allgemeine Datenschutzbestimmungen</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="Kontierung" type="cst:Kontierung_Type" minOccurs="0" maxOccurs="3"/>
<xsd:element name="Ersatzpolizzennummer" type="cst:Ersatzpolizzen_Type" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Ersatzpolizzennummern für eine manuelle Ablöse von Polizzen. Nicht für automatische Konvertierung oder Fahrzeugwechsel.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="ZusendungWeitereDokumente" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>Sollen weitere Antragsdokumente zugestellt werden (z.B. IVK)</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="ZusaetzlicheAntragsdaten" type="ZusaetzlicheAntragsdaten_Type" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>Moeglichkeit fuer die Erweitung des Standards um eigene Antragsdaten</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="Sicherstellungen" type="cst:Sicherstellung_Type" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>Daten zu etwaigen Sicherstellungen</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="Einwilligungen" type="cst:Einwilligung_Type" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>Zustimmung zu vorgegebenen Fragen, z.B. Datenverarbeitung von Gesundheitsdaten</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="SpezAntragPersonen_Type" abstract="true">
<xsd:annotation>

2
OMDSServiceDefinition/src/main/resources/def/r1_8_0/omds3_ON2_Antrag_SachPrivat.xsd
View File

@@ -94,7 +94,7 @@
<xsd:documentation>Ebenerdig, 1 Stockwerk, 2 Stockwerke oder mehr als 2 Stockwerke</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="BaujahrGebaeude" type="xsd:integer">
<xsd:element name="BaujahrGebaeude" type="xsd:integer" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Jahreszahl</xsd:documentation>
</xsd:annotation>