DAT-Import scheitert bei Schüler/innen mit mehreren Bildungsgängen

[Alexander Dedy]

DAT-Import scheitert bei Schüler/innen mit mehreren Bildungsgängen (bewusste Dubletten) — Lösung in SchILD3/SVWS-Server geplant?

Wir haben uns bei uns am JDBK ein kleines Tool gebaut (Aktuell noch in SchILD2), das bestimmte Änderungen (Adressänderungen, Klassenwechsel, Notenänderungen in alten Abschnitten usw.) automatisiert über die SchILD-DAT-Schnittstelle importiert, statt sie manuell in der Oberfläche einzutragen.

Dabei sind wir auf folgendes Problem gestoßen: Bei uns durchlaufen viele Schüler/innen im Laufe der Zeit mehrere Bildungsgänge (z. B. erst eine schulische AV Maßnahme, dann BFS und noch eine duale Ausbildung). Für jeden neuen Bildungsgang legen wir bewusst einen neuen Schüler-Datensatz an, statt den bestehenden weiterzuführen — das ist bei uns Absicht: Würden wir stattdessen den alten Datensatz einfach weiterlaufen lassen, hätten wir bei Zeugnisnachdrucken usw. das Problem, dass Beginn und Ende des jeweiligen Bildungsgangs in SchILD nicht sauber ausgewiesen sind — dieses Feld zieht ja den Eintritts- und Endtermin des allerersten Bildungsgangs mit. Für eine korrekte Schülerlaufbahn pro Bildungsgang brauchen wir also getrennte Datensätze.

Das führt aber zu folgendem Nebeneffekt: Derselbe Mensch (identischer Vorname, Nachname, Geburtsdatum) existiert dadurch mehrfach in der Datenbank (als Duplikat) — der/die „alte" Datensätze bleibt als Abgänger/Abschluss stehen, daneben der neue, aktive.

Die DAT-Importschnittstelle identifiziert Schüler/innen offenbar ausschließlich über Nachname+Vorname+Geburtsdatum. Trifft dieser Schlüssel auf mehr als einen Datensatz zu, lehnt SchILD den Import mit einer Meldung in Richtung „gefunden, aber nicht eindeutig identifizierbar" ab — auch wenn der aktive Datensatz für einen menschlichen Bearbeiter eindeutig erkennbar wäre.

Workaround bei uns: Wir gleichen vor jedem Import zusätzlich gegen eine separate, vollständige Ehemaligen-Liste ab und schließen betroffene Fälle vom Automatik-Import aus (manuelle Nachbearbeitung in der Oberfläche). Funktioniert, ist aber Zusatzaufwand und nur so gut wie die Aktualität dieser Liste.

Fragen:
Gibt es in SchILD einen anderen Weg/Modus, pro Bildungsgang ein sauberes Beginn-/Enddatum zu führen, OHNE dafür einen komplett neuen Personendatensatz anzulegen? Dann könnten wir uns die Dubletten evtl. sparen.
Falls nicht: Kennt jemand einen saubereren Umgang mit dem DAT-Import in genau diesem Fall (Name+Geburtsdatum nicht eindeutig)?
Ist bekannt, ob SchILD3 bzw. der SVWS-Server für den Import eine stabilere, eindeutige Schüler-ID statt Name+Geburtsdatum als Matching-Schlüssel verwenden wird oder zumindest auf den Status "aktiv"? Das würde das Import-Problem lösen, auch wenn man weiterhin pro Bildungsgang getrennte Datensätze anlegt.
Grüße

[Alexander Dedy]

Kurzes Update zu meiner Frage: ich habe die Lösung inzwischen selbst durch Ausprobieren gefunden.

Das Problem war der bekannte Fehler "Schüler/-in gefunden, aber nicht eindeutig identifizierbar" beim DAT-Import, wenn zu einer Person mehrere SchILD-Datensätze mit identischem Nachname+Vorname+Geburtsdatum existieren (z. B. aktiver Schüler + ehemalige/r Schüler/in mit gleichem Namen).

Die Lösung: Im SchILD-Export gibt es das Häkchen "Klasse als zusätzliches Identifikationsmerkmal". Aktiviert man es bei einem Testexport, zeigt sich im Diff, wie SchILD das technisch löst: es fügt keine neue Spalte hinzu, sondern hängt die Klasse direkt mit einer Raute ans Nachname-Feld an, z. B. "Mustermann#10A" statt "Mustermann". Die separate Klasse-Spalte bleibt davon unberührt und wird ganz normal befüllt.

Das lässt sich beim eigenen DAT-Import 1:1 nachbauen: einfach im Nachname-Feld "Nachname#Klasse" statt nur "Nachname" eintragen. Damit kann SchILD den richtigen Datensatz eindeutig zuordnen, der Import läuft ohne die Fehlermeldung durch.

Ich habe das mittlerweile für mehrere DAT-Dateitypen getestet (Basis-/Zusatz-/Leistungs-/Lernabschnitts-/Sprachenfolge-/Vermerk-/Adressdaten) — funktioniert überall gleich, auch wenn man in einer Datei Zeilen mit und ohne diesen Suffix mischt (also nicht nur bei tatsächlichen "Karteileichen" nötig, unauffällige Zeilen bleiben davon unberührt).

Vielleicht hilft das jemand anderem mit demselben Problem weiter.