Grund der Zustellung des Dialogfalls, ab V 2.0 DM-ORG, Kapitel J.1, Feld-Information: Nr. - (siehe Element "zustellgrund") Name - zustellungsgrund Anzahl min. - 1 Anzahl max. - 1 Länge - 1 Typ - string Beschreibung - "M" - Dialogfall gemeldet "U" - Dialogfall urgiert "O" - Dialogfall obsolet gesetzt Dialogfall gemeldet Dialogfall urgiert Dialogfall obsolet gesetzt Dringlichkeit des Dialogfalls, ab V 2.0 DM-ORG, Kapitel J.1, Feld-Information: Nr. - (siehe Element "dringlichkeit") Name - dringlichkeit Anzahl min. - 0 Anzahl max. - 1 Länge - 1 Typ - string Beschreibung - "D" - dringend "K" - Kontrollfall "N" - nicht dringend Ist das Element im Datensatz nicht angegeben, so ist als Vorgabewert der Wert "N" für "nicht dringend" anzunehmen. Dialogfall ist dringend, Handlung nötig Kontrollfall, Meldung kontrollieren Dialogfall ist nicht dringend Format-Version des Dialogfalls, ab V 2.0 DM-ORG, Kapitel J.1, Feld-Information: Nr. - (siehe Element "version") Name - version Anzahl min. - 1 Anzahl max. - 1 Länge - 7..70 Typ - string Beschreibung - Version des Dialogfalls in der Form "ELDA_DIALOGFALL_major_minor" Muster: ELDA_DIALOGFALL_<majorVersion3stelligNumerisch>_<minorVersion3stelligNumerisch>_<updateVersion3stelligNumerisch> Versionierungs-Semantik: - JEDE Instanz des Dialogfalls hat eine Versions-Information, bestehend aus: - der Information, um welche Daten es sich handelt: "ELDA_DIALOGFALL" in der Form "<IT-System>_<Datenbestand>" WICHTIG: die Kombination IT-System + Datenbestand muss eine eindeutige Type der Schnittstelle und Bedeutung der über die Schnittstelle übertragenen Daten implizieren - einer MAJOR-Version - einer MINOR-Version, welche die MAJOR-Version hierarchisch unterteilt - Version 1.x.x wird dadurch gekennzeichnet, dass das Element "version" NICHT vorhanden ist - Ab Version 2.0.0 ist das Element "version" ZWINGEND immer vorhanden - eine Erhöhung der MAJOR-Version ist nötig, wenn die Verarbeitung des CF-Dokuments durch eine Software, die sich die niedrigere Version erwartet, zu einer Verfälschung des FACHLICHEN Tatbestandes führt. Dies inkludiert z.B.: - Ein Element fällt weg - Ein Element kommt hinzu, dessen Verwendung zwingend notwendig für die fachlich richtige Verarbeitung des Datensatzes ist - Ein Element bekommt einen anderen Namen - Ein Element erhält einen erweiterten Wertebereich - eine Erhöhung der MINOR-Version reicht aus, wenn die Verarbeitung des CF-Dokuments durch eine Software, die sich die niedrigere Version erwartet, zu keiner Verfälschung des FACHLICHEN Tatbestands führt. Dies ist immer im Einzelfall zu betrachtet und inkludiert z.B.: - ein Element kommt hinzu, darf aber ignoriert werden, ohne FACHLICH falsche Verarbeitung zu erzeugen ANM: es kann durchaus sein, dass das Ignorieren eines Elements BETRIEBLICH zu Problemen führt, dies ist aber abhängig von der betrieblichen Logik es Empfänger-Systems des Clearingfalls Ein Beispiel für einen solchen Fall ist das "version"-Element selbst: Ein Empfänger-System, das nur Version 1.x.x erwartet, darf das "version"-Element in einem V 2.x.x-Datensatz ignorieren. Es könnte jedoch sein, dass der Parser des Empfänger-Systems das Dokument als invalide erkennt, da es Elemente enthält, die im Schema der Version 1.0 nicht enthalten sind. Ein anders gelagertes Beispiel ist das "zustellungsgrund"-Element in Version V 2.0: (Abgesehen von der Tatsache, dass ein validierender XML-Parser, der auf der V 1.0 basiert, das "zustellungsgrund"-Element als fehlerhaft erkennt) Wird das "zustellungsgrund"-Element ignoriert, erscheint ein CF, der auf Grund der Urgenz erneut zugestellt wird (siehe SVCLEAR-22) wie ein neuer CF, der allerdings identisch zum ursprünglichen CF ist. Die Semantik von Clearingfällen besagt, dass es zu einer Meldung nur EINEN CF gibt. Einen "neuen" CF kann es daher nicht geben. Es ist jedoch von der Logik im Empfängersystem abhängig, welche Auswirkungen diese Urgenz-Zustellung hat. - ein Element erhält einen VERRINGERTEN Wertebereich, ohne jedoch die fachliche Semantik des vorhandenen Wertebereichs zu verändern - eine Erhöhung der UPDATE-Version reicht aus, wenn die physische Repräsentation der Dateninhalte (inklusive Element-Namen) unverändert bleibt und auch keine Wertebereiche verändert werden sowie die FACHLICHE Bedeutung der einzelne Werte erhalten bleibt. Eine Erhöhung der UPDATE-Version ist durch eine editorielle Änderung der durch dieses Schema beschriebenen Schnittstelle gerechtfertigt, d.h. wenn die INHALTE der "annotation"-Elemente z.B. aus dem Grunde der Klarstellung geändert werden. Ebenso ist eine Erhöhung der UPDATE-Version dann gerechtfertigt, wann sich in diesem Schema KEINE Änderung ergeben hat, jedoch begleitende Dokumente, die z.B. den Wertevorrat von Datenfeldnern beschreiben, eine Änderung erfahren haben. In diesen Dokumenten wird dann auf diejenige Version Bezug genommen. Die Version 2.0.0 ist die erste Version, die eine Versions-Kennung in Form des Felds "version" im Clearing-Datensatz trägt. Die Version 2.0.x wird mit der DM-ORG mit 01.12.2019 freigegeben. In der Version 2.0.0 ist der Inhalt des Felds "version" der Wert "ELDA_DIALOGFALL_2_0_0" DM-ORG, Kapitel J.1, Feld-Information: Nr. - (nach "testkennzeichen") DM-ORG, Kapitel J.1, Feld-Information: Nr. - (nach "version") DM-ORG, Kapitel J.1, Feld-Information: Name - "Dringlichkeit" Nr. - (nach "bereitstellungsdatum")