2.7.2 Importmöglichkeiten in DATES II

Für den Vorhaben-Import werden folgende Importmöglichkeiten unterstützt:

• Einzelimport (Recht: C.2.12) eines neuen und bestehenden Vorhabens im Status „In Bearbeitung“ oder „Bestätigt“ über das Importmodul oder die Vorhabenverwaltung (gilt nur für bestehendes Vorhaben)
• Einzelimport (Recht: C.2.12) pseudonymer Teilnehmerdaten eines Vorhabens über das Importmodul oder die Vorhabenverwaltung (gilt nur für bestehendes Vorhaben)
• Massenimport (Recht C.2.13) von Vorhaben nur im Status „Bestätigt“ und/oder deren Teilnehmerdaten über das Importmodul
• Teilnehmer eines Vorhabens, das sich an Teilnehmer richtet, können im Importmodul über einen Einzel- (Recht C.2.12) und Massenimport (Recht C.2.13) gelöscht werden.

Abbildung: Importmöglichkeiten in DATES II

Struktur der Importdatei

Die Struktur einer Importdatei ist über ein XML Schema (XSD-Datei) vorgegeben. Sie muss dieser Struktur entsprechen und wird beim Import gegen dieses Schema validiert. Nicht schemakonforme Dateien werden in DATES II direkt abgewiesen. Anhand dieses Schemas können strukturelle Fehler bereits durch den Zulieferer (Verwaltungsstellen-Nutzer) erkannt werden. Die XSD-Datei enthält eine Beschreibung zu allen für einen Vorhaben- und Teilnehmerdaten-Import erforderlichen XML-Elementen.

Basisinformationen zum XML Schema

• Die Definition der Datenstrukturen des XML Schemas basiert auf den elementaren Datentypen der allgemeinen XML Schema Definition und deren Strukturelementen. Dies soll beispielhaft erläutert werden:

• Das gezeigte Beispiel definiert den Datentyp Wiedereinziehungsbeschluss. Dieser enthält eine Sequenz, d.h. eine Reihe von Elementen, die in der aufgeführten Reihenfolge in der Importdatei vorliegen müssen. Das 1. Element heißt bescheiddatum und ist optional (minOccurs=“0“).
• Über die Attribute minOccurs und maxOccurs kann das XML Schema erzwingen, dass eine bestimmte Anzahl dieser Elemente enthalten sein muss. Der default-Wert dieser beiden Attribute ist „1“. Wird also in der Schemadatei für ein XML-Element keine Angabe zu diesen Attributen gemacht, dann muss es in der Importdatei genau einmal an dieser Stelle erscheinen.
• Als Typ des Elements bescheiddatum ist xs:date angegeben. Gültige Datumsformate hierfür sind der allgemeinen XSD-Spezifikation zu entnehmen.

Das XML Schema definiert eine Baumstruktur für XML-Elemente. Dabei können einem Element untergeordnete Elemente in unterschiedlichen Anzahlen (Multiplizitäten) vorkommen. Diese sog. Multiplizität lässt sich der Stammblatt-Exceldatei (Tab „Stammblatt“) entnehmen. Für jede Entität (also jede Zelle der Stammblatt-Datei, bei denen in Spalte „Typ“ der Wert „Entität“ steht) bzw. Stammblatt-Bereich ist hierin angegeben, wie sie sich auf den übergeordneten Typ bezieht. Durch Semikolon getrennt sind alle Bereiche (Entitäten) aufgeführt, zu denen ein Bereich (Entität) eine Beziehung hat, mit der jeweiligen Angabe einer Zahl, einem Zahlenbereich (0,…,3) oder N (für beliebig viele). Beispielsweise bedeutet TeilnehmerDaten N : 1 Vorhaben, dass ein Vorhaben beliebig viele Teilnehmerdaten-Datensätze enthalten kann. Die Angabe der Multiplizität wird dabei im XML Schema durch die Attribute minOccurs und maxOccurs angegeben. Häufig werden untergeordnete XML-Elemente als Liste definiert, die dann eine Sequenz von Elementen enthält.

Hinweise zu Kodierung und Namenskonventionen der Importdatei

Kodierung: Die Importdatei muss mit dem UTF-8-Zeichensatz kodiert werden. Die Zeichenkodierung kann in der XML-Deklaration in Zeile 1 der Datei angegeben werden. Wird kein Encoding angegeben, wird von UTF-8 ausgegangen.

Namenskonventionen: Der Name der Datei darf aus Buchstaben (a-z, A-Z, keine Umlaute), Zahlen und den Zeichen ‘_‘ (Unterstrich), ‘-‘ (Bindestrich), ‘.‘ (Punkt) bestehen. Insbesondere darf er keines der Zeichen '<', '>', '|', '\', '/', ':', '(', ')', '&', ';', '#', '?' und '*' enthalten. Der Dateiname darf bis zu 100 Zeichen lang sein und muss mit ".xml" enden.

Zentrale Elemente der Importdatei

Im Folgenden werden zentrale Elemente der XML-Importdatei kurz erläutert.

• Wurzelelement

Über das Wurzelelement der XML-Datei wird entschieden, ob ein Vorhaben oder ausschließlich Teilnehmerdaten importiert werden sollen. Wird als Wurzelelement vorhabenImport angegeben, werden vollständige Vorhaben importiert, die optional auch Teilnehmerdaten enthalten können. Wird als Wurzelelement teilnehmerDatenImport angegeben, werden nur Teilnehmerdaten zu einem existierenden Vorhaben importiert. In diesem Fall muss die GUID des Vorhabens angegeben werden.

Dabei können in DATES II Vorhaben neu importiert oder bereits existierende Vorhaben über einen Import aktualisiert werden. Für eine Aktualisierung müssen die GUID und das Aktenzeichen des Vorhabens mitgeliefert werden.

Über das Wurzelelement teilnehmerLoeschKennzeichen können Teilnehmer übergeben werden, die aus dem DATES II Datenbestand für ein Vorhaben entfernt werden sollen. Dabei ist grundsätzlich die automatisch in DATES II erzeugte GUID des Teilnehmers (D301) zur Identifikation anzugeben. Zusätzlich können die Teilnehmer-ID des Projektträgers (D300) und die Teilnehmer-ID des Vorsystems (D302) angegeben werden. In diesem Fall wird geprüft, ob sie mit den in DATES II zu einer GUID gespeicherten IDs übereinstimmen. Wird eine Abweichung festgestellt, führt dies dazu, dass der Import mit einer Systemmeldung abgewiesen wird.

• Vorhaben

Die XML-Datei beim Vorhabenimport enthält genau ein Element vorhaben, das alle (als XML deklarierte) Attribute des Vorhabens enthält:

Abbildung: Darstellung der erforderlichen XML-Elemente für den Vorhabenimport

Teilnehmerdaten (bezieht sich auf Stammblatt Teil D)

Teilnehmerdaten können in einem vollständigen Vorhaben enthalten sein oder unter Angabe der Vorhaben-GUID separat importiert werden. In beiden Fällen wird ein Element vom Typ TeilnehmerDatenListTyp benötigt. Dieser TeilnehmerDatenListTyp enthält einen oder mehrere Teilnehmerdaten-Datensätze. Diese Datensätze enthalten nur pseudonyme, also keine personenbezogenen Teilnehmerdaten. Daten, die Rückschlüsse auf die Identität des Teilnehmers zulassen, werden also nicht in DATES II importiert!

Abbildung: Darstellung der erforderlichen XML-Elemente für den Teilnehmerdatenimport

Wichtiger Hinweis zum Import von Teilnehmerdaten: Wird für ein existierendes manuell bearbeitetes Teilnehmerstammblatt bei einem Import eine identische GUID übergeben, werden die Teilnehmerdaten im System unwiederbringlich durch die importierten Teilnehmerdaten überschrieben.

Ein Vorhaben kann eine Liste von Indikatorenwerten enthalten. Dabei werden nur vorhabenbezogene Indikatoren erfasst. Jeder Indikatorwert kann dabei einen Soll- und Ist-Wert, sowie die Angabe des betreffenden Jahres enthalten. Das Element IndikatorTyp enthält die im OP spezifizierte ID eines Indikators. Diese kann der Spalte „OP-ID“ von Stammblatt v96_1 (Tab „Indikatoren“) entnommen werden.

Allgemein sind sämtliche gemeinsame Indikatoren und jeweils relevante programmspezifische Indikatoren, die einem Vorhaben durch das Programm zugeordnet sind, zu übermitteln.

Finanzinstrumente (bezieht sich auf Stammblatt Teil G)

Grundsätzlich ist die Erfassung der Datenfelder zu Finanzinstrumenten über die Importschnittstelle optional, sie kann auch komplett in DATES II erfolgen. Wenn ein Vorhaben einem Programm zugeordnet ist, das bei der Programmanlage durch die Verwaltungsbehörde als Finanzinstrument ausgezeichnet wurde, dann muss das zugeordnete Vorhaben genau ein Finanzinstrument-Element enthalten. Im XML Schema ist das Finanzinstrument-Element optional. Ein fehlendes Finanzinstrument wird daher noch nicht bei der Schemavalidierung erkannt, sondern erst während des Importvorgangs in DATES II.

Hinweise zu den Finanzinstrument-Daten eines Vorhabens: Die Finanzinstrument-Daten auf Vorhabenebene, die nach manueller Eingabe oder Import in DATES II im Stammblatt Teil G vorgehalten werden (D601-D670, D687), müssen: 1. gemäß Artikel 46 Absatz 1 der VO (EU) Nr. 1303/2013 grundsätzlich einmal jährlich im Rahmen des Durchführungsberichts geliefert werden. 2. für die Datenfelder D624, D688, D637, D640, D641 geliefert werden, wenn eine weitere Tranche der reservierten ESF-Mittel als Vorschuss für das Finanzinstrument im Rahmen eines Zahlungsantrags abgerufen wird. Dies dient zur Überprüfung der Einhaltung der Vorschussregelungen gemäß Anhang VI Anlage 1, Spalte C + D der DVO (EU) Nr. 1011/2014.

Allgemeiner Ablauf eines Einzel- und Massenimportvorgangs

Einzelimportvorgang

Der Vorhaben-Einzelimport dient dazu, eine Importdatei (XML-Datei) auszuwählen und den Importprozess hierfür auszulösen. Hierzu wurden in DATES II drei Import-Funktionen umgesetzt:

• Import eines neuen Vorhabens
• Änderungen eines bestehenden (vollständigen) Vorhabens
• Import ausschließlich von Teilnehmerdaten eines bestehenden Vorhabens

Bei einem Vorhabenimport muss immer die vollständige Datenstruktur eines zu importierenden Vorhabens geliefert werden. Ein Deltaimport, d.h. eine Datenaktualisierung um nur geänderte Datenfelder eines Vorhabens oder ein Import von einzelnen Stammblatt-Teilen (außer den Teilnehmerdaten, die in Stammblatt Teil D vorgehalten werden) wird von DATES II nicht unterstützt.

Am Ende eines Imports wird eine Statusmeldung auf dem Dialog ausgegeben, die den Status des Importvorgangs und ggf. eine Fehlermeldung anzeigt (analog zum Eintrag in die sog. Protokolldatei). Zusätzlich erfolgt ein Eintrag in eine sog. Importhistorie und eine Protokolldatei wird erzeugt.

Beim Einzelimport-Vorgang durchläuft die Anwendung nacheinander folgende Schritte:

• Das Einlesen der XML-Datei
• Die Validierung gegen die XML-Schemadefinition
• Die Abbildung der externen auf die interne Datenstruktur von DATES II
• Der Aufruf der Funktionalität „Vorhaben anlegen/bearbeiten“
• Die Rückgabe des Importergebnisses, Erzeugung einer Protokoll- und ggf. Fehlimport-Datei sowie ein Eintrag in Importhistorie. Bei einem Importvorgang werden Systemmeldungen sowohl auf dem Importdialog als auch in der Protokolldatei angezeigt.

Massenimportvorgang

Durch den Massenimport können ein oder mehrere Vorhaben eines ESF-Programms aus einer ZIP-Datei importiert werden, in der die Importdateien aller zu importierenden Vorhaben zusammengefasst werden. Hierbei können sowohl die Importdateien für einen (vollständigen) Vorhaben- als auch für einen Teilnehmerdatenimport zusammen in der ZIP-Datei geliefert werden.

Nach dem Starten des Massenimports findet keine weitere Interaktion mit dem angemeldeten Nutzer statt, sondern der aktuelle Status des Importvorgangs lässt sich in der Importhistorie nachverfolgen. Für jeden Massenimportvorgang wird dabei ein Eintrag in der Importhistorie vorgenommen. Schlägt der Import eines einzelnen Vorhabens fehl, bricht der Importvorgang nicht vollständig ab, sondern es werden alle Dateien der ZIP-Datei nacheinander abgearbeitet.

Beim Massenimport-Vorgang durchläuft die Anwendung nacheinander folgende Schritte:

• Neuer Eintrag in die Importhistorie mit dem Status „Import läuft“. Nach abgeschlossenem Importvorgang wird der Importstatus hierin dokumentiert.
• Für jede in der Massenimportdatei enthaltenen Einzelimportdatei (Vorhabenimport oder Teilnehmerimport) erfolgt:
  • Das Einlesen der XML-Datei
  • Die Validierung gegen die XML-Schemadefinition
  • Die Abbildung der externen auf die interne Datenstruktur von DATES II
  • Ein Aufruf der Funktionalität „Vorhaben anlegen/bearbeiten“
  • Die Rückgabe des Importergebnisses, Erzeugung einer Protokoll- und ggf. Fehlimport-Datei sowie ein Eintrag in Importhistorie. Bei einem Importvorgang werden Systemmeldungen sowohl auf dem Importdialog als auch in der Protokolldatei angezeigt.

Fehler und Validierungen beim Einzel- und Massenimport

• Fehlerklassen

Ein möglicher Fehler wird nach dem Importvorgang auf dem Importdialog (nur Einzelimport), der Importhistorie und in der Protokolldatei angezeigt.

Allgemein werden in DATES II folgende Fehlerklassen bei einem Einzel- und Massenimport-Vorgang unterschieden:

• Fachlicher Fehler
• XML-Validierungsfehler
• Technischer Fehler

Hierbei kann das Systemverhalten im Fehlerfall zwischen Einzel- und Massenimport unterschieden werden:

Validierungen beim Einzel- und Massenimport

• Validierung der Nutzerrechte
• Nur Einzelimport: Validierung der Größe der XML-Datei (gegenwärtig bis 1 MByte). Ein Fehlschlagen der Validierung führt zu einem Importabbruch wegen eines technischen Fehlers.
• Nur Massenimport: Validierung der Größe der ZIP-Datei (gegenwärtig bis 10 MByte) im Fall eines Massenimports. Ein Fehlschlagen der Validierung führt zu einem Importabbruch wegen eines technischen Fehlers.
• Validierung der XML-Kodierung (UTF-8). Ein Fehlschlagen der Validierung führt zu einem Importabbruch wegen eines technischen Fehlers.
• Validierung gegen das XML Schema (Form/Inhalt müssen Schema entsprechen). Ein Fehlschlagen der Validierung führt zu einem Importabbruch wegen eines XML-Validierungsfehlers.
• Validierung der gültigen Kombination aus GUID und Aktenzeichen. Ein Fehlschlagen der Validierung führt zu einem Importabbruch wegen eines fachlichen Fehlers.
• Validierung des Ampelstatus (bei vorhandenen Vorhaben dürfen Daten nur importiert werden, wenn ein „grüner“ Ampelstatus vorliegt). Ein Fehlschlagen der Validierung führt zu einem Importabbruch wegen eines fachlichen Fehlers.
• Nur Massenimport: Validierung des Vorhabenstatus (Daten dürfen nur importiert werden, wenn Vorhaben „Aktiv“ und im Vorhabenstatus „Bestätigt“ sind). Ein Fehlschlagen der Validierung führt zu einem Importabbruch wegen eines fachlichen Fehlers.

Status eines erfolgten Einzel- und Massenimports

Das Ergebnis eines Importvorgangs wird als Status ermittelt, abhängig davon, ob bei dem Importvorgang:

• XML-Dateien erfolgreich hochgeladen werden konnten
• ein Fehler auftrat
• keine Veränderung von Daten erfolgte
• der Nutzer keine Berechtigung zum Import eines Vorhabens hat

Nach einem Importvorgang wird dieser Status auf dem Anwendungsdialog (nur Einzelimport), in der Importhistorie und in der Protokolldatei aufgeführt:

Beim Import zu übermittelnde Daten

Grundsätzlich lässt sich festhalten, dass alle Felder, die per Import nach DATES II übertragen werden können, für die Abwicklung von Vorhaben und Programmen relevant sind - und zwar unabhängig davon, ob es sich um sog. Pflicht- oder ampelrelevante Felder handelt.

Alle importierbaren Datenfelder müssen deshalb immer von den Vorsystemen bereitgestellt werden. Nur Datenfelder, die fachlich ausschließlich für bestimmte Programmtypen relevant sind (wie z.B. für Finanzierungsinstrumente), sind nicht für alle Programme zu liefern.

Grundsätzlich ist das Streichen von importrelevanten Feldern in den Vorsystemen nur nach Rücksprache mit der Verwaltungsbehörde möglich!

Prüfung von Pflichtfeldern, tolerante Validierung von Teilnehmerdaten und ampelrelevanten Datenfeldern:

(1) Pflichtfelder

Pflichtfelder sind Felder, die unabhängig von anderen Feldern beim Import bereitgestellt werden müssen. Ob es sich bei einem Datenfeld um ein (unbedingtes) Pflichtfeld handelt, kann der XSD-Deklaration entnommen werden (Attribut minOccurs eines Elements). Pflichtfelder werden in der Schema-Definition der Importdatei als solche gekennzeichnet, so dass eine Importdatei vom Verwaltungsstellen-Nutzer schon vor dem Import auf Vollständigkeit validiert werden kann.

(2) Bedingte Pflichtfelder/fachliche Validierungsregeln

Neben den unbedingten Pflichtfeldern gibt es noch bedingte Pflichtfelder oder fachliche Validierungsregeln. Fachliche Validierungsregeln werden angewendet, wenn (a) eine Validierung über mehrere Datenfelder erfolgen muss (ein Beispiel hierfür wäre, wenn mindestens eines der Datenfelder D72, D73, D74, D75 gesetzt werden muss) oder wenn eine Validierung von einem anderen Datenfeld (b) im Vorhaben (ein Beispiel hierfür wäre, dass Angaben zum Aufbewahrungsort von Belegen (D14 bis D19) zu Pflichtfeldern werden, wenn Datenfeld „Anderer Ort“ (D13) gesetzt ist) oder (c) im Programm abhängt. Diese Validierungen werden erst durch die Importfunktion in DATES II überprüft. Eine Verletzung dieser Regeln führt zu einer fachlichen Fehlermeldung und einem Abbruch des Imports.

(3) Tolerante Validierung von Teilnehmerdaten

A. Pro Teilnehmer sind folgende Werte an DATES II via Schnittstelle zu übergeben:

B. Validierung und Konsequenz einer negativen Validierung:

Der Prozess der Validierung erfolgt in zwei Stufen:

1. Validierung der bereitgestellten XML-Datei mit Hilfe der XSD

2. Validierung innerhalb der Business Logik

Die Festlegung der (unbedingten) Pflichtfelder erfolgt mit Hilfe der XSD. Die weiteren (bedingten) Prüfungen erfolgen innerhalb der Business Logik.

Eine nicht erfolgreiche Validierung der XML-Datei, sowohl bei der Validierung mit Hilfe der XSD, als auch innerhalb der Business Logik führt dazu, dass die Validierungsfehler im Importprotokoll ausgegeben werden und der Import des Teilnehmerdatensatzes abgebrochen wird. Als Ergebnis wird der Teilnehmerdatensatz nicht nach DATES II importiert.

1.) Pflichtfelder beim Import von TN-Daten (Mindeststandard)

Folgende Felder sind je TN-Datensatz zwingend zu übergeben. Ein Fehler dieser Felder führt dazu, dass ein TN-Datensatz nicht nach DATES II importiert wird:

• D301 / GUID des Teilnehmers
• D313 / Datum Maßnahmeneintritt
• D314 / Datum (Plan) Maßnahmenaustritt
• D317 / Geschlecht
• D318 / Einverständnis Teilnehmer

2.) Toleranz gegenüber fachlich unvollständigen TN-Daten

Ein Validierungsfehler bei den nachfolgenden Feldern führt nicht dazu, dass der Import des TN-Datensatzes abgebrochen wird:

• D313 / Datum Maßnahmeneintritt (Vorhanden, aber fehlerhafte Validierung)
• D315 / Datum (Ist) Maßnahmenaustritt (Vorhanden, aber fehlerhafte Validierung)
• D316 / Teilnehmer hat Maßnahme abgebrochen? (wenn D315 vorhanden)
• Teilnehmerbezogene Indikatoren: Fehlen von Pflichtindikatoren oder fehlerhafte Validierung übermittelter Indikatoren.

Eine derartige fehlerhafte Validierung hat folgende Konsequenz:

• Der TN-Datensatz wird nach DATES II importiert.
• Der entsprechende Datensatz wird als „fachlich invalide“ gekennzeichnet.
• Über das Import-Protokoll erfolgt eine detaillierte Rückmeldung, welche Validierungen fehlgeschlagen sind.

3.) Umgang mit „fachlich invaliden“ Datensätzen

• Fachlich invalide TN-Datensätze werden für die Berechnung der Indikatoren in Stammblatt Teil F nicht herangezogen.
• Fachlich invalide TN-Datensätze werden in Reports nicht berücksichtigt (z.B. Berichte zum materiellen Controlling)
• Fachliche invalide TN-Datensätze werden in Stammblatt Teil D angezeigt, werden aber als „fachlich invalide“ gekennzeichnet (zusätzliche Spalte „fachlich invalide“)
• Fachliche invalide TN-Datensätze werden in Exporten mit ausgegeben und in der Exportdatei mit dem Flag (D319 „fachlich invalide“) gekennzeichnet.
• Die Korrektur von fachlich invaliden Datensätzen kann nur über einen erneuten Import vorgenommen werden.
• In Bezug auf die Indikatorenampel sind nur vollständige TN-Datensätze relevant. Fachlich invalide Datensätze werden in Bezug auf die für die Indikatorenampel definierten Kriterien nicht berücksichtigt.

(4) Pflichtfelder und Erfassung von Wiedereinziehungen/Einbehaltungen

Die Beschluss-ID bei einer Wiedereinziehung bzw. Einbehalt-ID (D143) ist zwingend zu übergeben und muss eindeutig sein. Der Inhalt von D143 ist eine GUID, d.h. das Vorsystem muss eine GUID übergeben. Bei Anlage einer Wiedereinziehung oder eines Einbehalts in DATES II wird für D143 eine GUID erzeugt.

Sobald ein Zahlungsantrag durch die Bescheinigungsbehörde abgeschlossen wurde, wird für die entsprechende Entität das Feld „D159 Datum der Wirksamkeit im ZA“ mit dem Abschlussdatum befüllt und die Spalte X im Debitorenbuch ausgewiesen. Alle angelegten Entitäten bleiben beim Öffnen einer neuen Bearbeitungsversion sichtbar, sind aber nicht mehr editierbar. Korrekturen von falschen Einträgen können daher nur über die Anlage neuer Entitäten mit Negativbeträgen erfolgen.

Existieren fixierte Wiedereinziehungen/Einbehalte (W/E) an einer vorherigen Version des Vorhabens, werden die entsprechenden W/E aus der Importdatei ignoriert. Die entsprechende W/E (identifiziert über die GUID) aus der vorherigen Vorhabenversion wird übernommen.

Alle in der Import-Datei ggf. nicht enthaltenen W/E werden in die aktuelle Vorhaben-Version übernommen. Ein entsprechender Hinweis wird im Import-Protokoll ausgegeben („Die Wiedereinziehung/Einbehaltung mit der ID xxx wurde nicht importiert, da diese bereits in einen ZA eingeflossen ist“).

Weicht die übergebene W/E von der im System fixierten W/E ab wird im Import-Protokoll die Abweichung protokolliert („W/E ID xxx weicht von DATES II ab - bitte prüfen und im Vorsystem korrigieren“).

(5) Ampelrelevante Datenfelder

Ampelrelevante Datenfelder sind Datenfelder, die bei einem Einzelimport noch nicht vorliegen müssen, aber für eine Bestätigung des Vorhabens verpflichtend sind. Sind diese Datenfelder in einer Importdatei nicht enthalten, müssen sie manuell in DATES II befüllt werden, bevor das Vorhaben weiter verarbeitet und bestätigt werden kann.

Prüfung ampelrelevanter, bedingter Datenfelder/fachlicher Validierungsregeln beim Massenimport:

Bei einem Massenimport werden Vorhaben nur dann importiert, wenn die Ampelprüfung erfolgreich (d.h. ein Vorhaben hat eine „grüne Ampel“) ist. Daher müssen beim Massenimportvorgang sowohl die ampelrelevanten Prüfungen als auch die fachlichen Validierungsregeln/bedingte Pflichtfeldprüfungen vollständig erfüllt sein.

Hinweise zu initial zu übergebenden Datenfeldern: Folgende Datenfelder können nach der initialen Vorhabenanlage (manuell oder Import) nicht mehr aktualisiert werden: D72 (Realkosten), D73 (Standardeinheitskosten), D74 (Pauschalbetrag), D75 (Pauschalsatz), D76 (Pauschalierung durch delegierten Rechtsakt). Folgende Datenfelder können nur solange geändert werden, solange das Vorhaben noch nicht an einem Zahlungsantrag teilgenommen hat: D22: Kategorie der betreffenden Region (Zielgebiet).

Bedeutung der GUID und des Aktenzeichens eines Vorhabens

Bedeutung der Vorhaben-GUID

Die GUID (globally unique identifier) dient zur eindeutigen Identifikation eines Vorhabens in DATES II. Beim Import eines neuen Vorhabens aus einem Vorsystem kann die GUID entweder über die Importdatei geliefert oder durch DATES II erzeugt werden.

Beim Import eines neuen Vorhabens ist hinsichtlich der GUID also zu beachten, dass dieses Datenfeld in der Importdatei nicht gesetzt werden muss. In diesem Fall wird die GUID von DATES II erzeugt. Die GUID kann aber beim Import eines neuen Vorhabens in der Importdatei gesetzt werden, indem die im Vorsystem erzeugte GUID übernommen wird. Diese wird dann in DATES II übernommen.

Beim Import eines bestehenden Vorhabens muss die Vorhaben-GUID immer mit übergeben werden, da es ein Vorhaben eindeutig identifiziert. Existiert die GUID eines Vorhabens bereits in DATES II, aber in einem anderen Programm, wird der Import abgebrochen. Existiert die GUID eines Vorhabens in DATES II und ist identisch mit der GUID in der übergebenen Importdatei, werden die Daten überschrieben. Dabei wird nur eine Bearbeitungsversion angelegt, wenn das vom Anwender explizit gewünscht ist.

Für den Import von Teilnehmerdaten ist ebenfalls die GUID des Vorhabens anzugeben. Bei einem Import der Teilnehmerdaten muss ebenfalls die GUID eines Teilnehmers, als eindeutiger Schlüssel für einen Teilnehmer mitgeliefert werden. Dieses Datenfeld ist also ein Pflichtfeld, das bereits im Vorsystem erzeugt werden muss.

Prüfung der gültigen Kombination aus GUID und Aktenzeichen bei Vorhabenimport

Der Import eines Vorhabens ist nur dann erlaubt, wenn in der Importdatei eine gültige Kombination aus GUID und Aktenzeichen eines Vorhabens vorliegt. Grundsätzlich sind dabei folgende Varianten zu unterscheiden:

Schlägt diese Prüfung fehl, so werden die entsprechenden Daten nicht importiert, ein fachlicher Fehler protokolliert und die entsprechende Importdatei für ein Vorhaben der Fehlerdatei hinzugefügt.

Hinweis für Entwickler der Vorsysteme zur GUID-Erzeugung: DATES II nutzt für die Erzeugung der GUID die Klasse java.util.UUID der Java Standard-Bibliothek. Die Vorsysteme können einen beliebigen RFC4122-konformen GUID-Generator verwenden.

Umgang mit Datenfeld D79

Bedeutung des Datenfelds D79 bei der manuellen Bearbeitung von Vorhaben im System

In DATES II wird beim (manuellen) Erstellen einer neuen Bearbeitungsversion eines Vorhabens das Datenfeld D79 „Das Vorhaben wurde gemäß Artikel 125 Abs. 4a und 5 der VO 1303/2013 geprüft“ in Stammblatt Teil A zurückgesetzt und muss neu aktiviert werden (Ausnahme: Der Ersteller der Bearbeitungsversion ist ein Projektträger). Ansonsten erhält man nach dem Speichern von Änderungen in den Stammblatt-Teilen eine fehlgeschlagene Ampelprüfung und das Vorhaben kann nicht bestätigt werden.

Umgang in System mit dem Datenfeld D79 bei Einzel- und Massenimporten

Grundsätzlich handelt es sich bei diesem Datenfeld um ein importierbares Datenfeld, das ampelrelevant ist. Bei Vorhabenimporten durch berechtigte Verwaltungsstellen-Nutzer können hinsichtlich des Umgangs mit dem Datenfeld D79 zukünftig mehrere Fälle unterschieden werden.

Dokumentation der Importschnittstelle

Stammblatt

Als Einstiegspunkt in die Import-Thematik von DATES II kann die Exceldatei Stammblatt (aktuell: Version v96_1) dienen, die den Vorsystem-Betreibern im Zuge der Bereitstellung der XSD-Schnittstelle ebenfalls zur Verfügung gestellt wurde. Dort sind auf dem Tab „Stammblatt“ die Datenfelder von DATES II erläutert. Spalte „Import“ gibt an, ob das jeweilige Attribut über die Schnittstelle importiert oder nur in DATES II gepflegt werden kann. Ein Filter auf dieser Spalte ermöglicht einen unmittelbaren Überblick über alle import-relevanten Datenfelder. Diese Stammblattliste dient als ergänzende Dokumentation.

XML Schema (XSD-Datei)

Maßgeblich für die Erstellung von Import-Dateien ist das XML Schema. Sie definiert die Struktur, der die Import-Dateien genügen müssen.

Kataloge bzw. Schlüsseltabellen

Die ebenfalls den Vorsystem-Betreibern zur Verfügung gestellte Schlüsseltabellendatei definiert zu jedem Element des Stammblatts vom Typ „Katalog“ (siehe Stammblatt-Exceldatei, Spalte „Typ“) die entsprechend zulässigen Werte (in der Spalte „Key“) der Schlüsseltabellendatei.

Wichtiger Hinweis zu Katalogdaten: Katalogdaten können im System über die Katalogverwaltung deaktiviert werden. Deaktivierte Katalogdaten sind weiterhin im System verfügbar, so dass Bestandsdaten weiterhin darauf verweisen können. Bei einem erneuten Import eines bestehenden Vorhabens können sie weiterverwendet werden, insofern sie in der vorherigen Version des Vorhabens bereits enthalten waren. Sie können aber nicht in einem neu importierten Vorhaben verwendet werden oder in einem bestehenden Vorhaben neu gesetzt werden.