Verfügbar ab Version
HISinOne-BI: 2024.12
Die Funktion steht ab diesem Release zur Verfügung. Für SuperX ist dies das ZUL-Modul 0.8.
HISinOne-BI:
Kategorie:HISinOne-Dokumentation
Kategorie:Business Intelligence Analysen-Dokumentation
Konfigurationshandbuch Komponente Bewerber, Zulassungen
Die Auswertungsmodule innerhalb von BI zu den Bewerbungs- und Zulassungsdaten wurden von der Firma Memtext entwickelt und basieren auf Postgres / Informix als Datenbanksystem. Es können die Vorsysteme HISZUL, HISinOne-APP und CO angebunden werden.
Die Installation des ZUL-Moduls unterscheidet sich zwischen HISinOne und SuperX. Daher gibt es zu jedem System eine eigene Installationsseite:
Wenn Sie die Datenbank-Rechte beim Entladen aus dem Vorsystem ZUL-GX so ändern wollen, dass der Datenbank-User nur auf ausgewählte Tabellen Leserechte besitzt, dann müssen Sie folgende Tabellen mit Leserechten versehen:
Darüber hinaus benötigt die Entladekennung Schreibrecht auf die Pseudonymisierungstabelle mtknr_ldsg. Bei Postgres wird auch das Schreibrecht auf die zugehörige Sequence benötigt:
grant update on mtknr_ldsg_mtknr_ldsg_seq to <>
Modul Bewerbungen Zulassungen inkrementell Laden - HISinOne-BI
Eine Übersicht über die Entladeparameter finden Sie hier: Entladeparameter Bewerbung, Zulassung
Aus Datenschutzgründen werden im Normalfall Daten, die auf eine Person schließen lassen, nicht übernommen. Falls aber genau dies benötigt wird, können Vor- und Nachname und weitere Daten aus dem Vorsystem übernommen werden. Zudem gibt es noch einige weitere Parameter, die eingerichtet werden können. Hier finden Sie diese Parameter:
Mit den Entladeparametern APP_request_status und APP_requestsubject_status bestimmen Sie, welche Bewerbungen in die HISinOne-BI übertragen werden.
APP_request_status
Standardvorgabe ist der Wert:
KRS.hiskey_id not in (1,2,3)
Dies bedeutet, dass Bewerbungen mit den Antragsstatus (Tabelle k_request_status)
nicht in die BI übertragen werden. Sie können den Filter aber auch ändern, hier der Inhalt der Tabelle k_request_status:
hiskey_id longtext 1 In Vorbereitung 2 Eingegangen 3 In Bearbeitung 4 Gültig 5 Ausgeschlossen 6 Zulassungsangebot liegt vor 7 Zulassungsangebot aktuell nicht möglich 8 Zugelassen 9 Platz zurückgegeben 10 Zurückgestellt 11 Ausgeschieden 12 Abgelehnt 13 Frist überschritten 14 Eingegangen, zurückgezogen 15 In Bearbeitung, zurückgezogen 16 Gültig, zurückgezogen 17 Zulassungsangebot aktuell nicht möglich, zurückgezogen 101 Immatrikulation beantragt 102 Immatrikulationsantrag in Bearbeitung 103 Immatrikulationsantrag abgelehnt 104 Immatrikuliert 105 Immatrikulationsantrag zurückgezogen
Die häufigste Änderung des Parameters durch Hochschulen besteht darin, dass alle Bewerbungen mit beliebigen Antragsstatus in die HISinOne-BI überführt werden mit Ausnahme des Status in Vorbereitung. Dann lautet der entscheidende Teil des Entladeparameters APP_request_status
(KRS.hiskey_id not in (1) or KRS.hiskey_id is null)
APP_requestsubject_status
Standardvorgabe ist der Wert
KRS.hiskey_id not in (1,2,3)
Dies bedeutet, dass Bewerbungen mit den Antragsfachstatus (Tabelle k_requestsubject_status)
nicht in die BI übertragen werden. Sie können den Filter aber auch ändern, hier der Inhalt der Tabelle k_requestsubject_status :
hiskey_id longtext 1 In Vorbereitung 2 Eingegangen 3 Vorläufig ausgeschlossen 4 Gültig 5 Ausgeschlossen 6 Zulassungsangebot liegt vor 7 Zulassungsangebot aktuell nicht möglich 8 Zugelassen 9 Platz zurückgegeben 10 Zurückgestellt 11 Ausgeschieden 12 Abgelehnt 13 Frist überschritten 71 Teilnahme am Nachrückverfahren 101 Immatrikulation beantragt 102 Immatrikulationsantrag in Bearbeitung 103 Immatrikulationsantrag abgelehnt 104 Immatrikuliert 111 Bereits immatrikuliert
Die häufigste Änderung des Parameters durch Hochschulen besteht darin, dass alle Bewerbungen mit beliebigen Antragsfachstatus in die HISinOne-BI überführt werden mit Ausnahme des Status in Vorbereitung. Dann lautet der entscheidende Teil des Entladeparameters APP_requestsubject_status
(KRS.hiskey_id is null or KRS.hiskey_id not in (1))
Zusammengefasst werden also am häufigsten über beide Entladeparameter - also APP_request_status und APP_requestsubject_status - Bewerbungen mit den Antragsstatus sowie Antragsfachstatus in Vorbereitung von der Übertragung in die HISinOne-BI ausgeschlossen, sodass in BI-Berichten alle Bewerbungen mit den Antrags(fach-)status eingegangen sowie allen späteren Statusausprägungen des Bewerbungsprozesses ausgewertet werden können.
Bitte prüfen Sie genau, welche Status zu Ihren Anforderungen passen!
Verfügbar ab Version
Standardmäßig werden nur gülitge Bewerbungen aus dem Vorsystem geladen. Aber auch die ungültigen Anträge können der Hochschule "Arbeit" machen und können daher auswertbar gemacht werden. Damit können Hochschulen in den Bewerbungsberichten alle Anträge, also mit allen Antragsstatus, auswerten.
Zum Laden und Erkennen ungültiger Bewerbungen stellen Sie das wie folgt um:
Verfügbar ab Version
Die Definitionen der Bewerbungsbestandteile und deren Felder werden immer nach zul_app_content entladen. Dort sind keine Angaben von Bewerbungen enthalten. Wenn im Folgenden von Bewerbungsbestandteilen gesprochen wird, dann sind damit die Angaben zu einem Bewerbungsbestandteil in einer Bewerbung gemeint und nicht die Definition des Bewerbungsbestandteiles.
Der Filter für entladene Bewerbungsbestandteile kann konfiguriert werden. Standardvorgabe ist der Wert
('uniquename1','uniquename2')
Dies bedeutet, dass keine Bewerbungsbestandteile entladen werden. Sie können den Filter aber auch ändern. Als Zulassungsadministrator/-in schicken Sie ohne Angabe von Filtern den Bericht Bewerbungsbestandteil-Definitionen bearbeiten ab. Es werden die verfügbaren Bewerbungsbestandteil-Definitionen und deren Schlüssel aufgelistet. Die Schlüssel sind die uniquenames, welche im Entladeparameter anzugeben sind.
Folgender SQL gibt ebenfalls die verfügbaren Bewerbungsbestandteil-Definitionen und somit deren uniquenames aus (Voraussetzung ist, dass der Konnektor Bewerbung, Zulassung bereits gelaufen ist):
select * from zul_app_content;
Die Bewerbungsbestandteile lassen sich als weitere Tabelle über das Bewerbungen und Zulassungen Datenblatt abrufen (s. Benutzungshandbuch).
| Parameter | Defaultwert | Beschreibung |
|---|---|---|
antr_stort | stort | Soll das Feld antr.stort (Studiort, falls HS mehrere Standorte hat) entladen werden? Wenn ja, dann ist der Wert "stort", wenn nein, dann ist er "null::char(1)" |
antr_zulart | zulart | Soll das Feld antr.zulart (Status des Bewerbers) entladen werden? Wenn ja, dann ist der Wert "zulart", wenn nein, dann ist er "null::char(1)" |
BEW_FILTER | (B.fehlerkz != 'F' or B.fehlerkz is null) | Nur für ZUL-GX und CO: Sollen BEW-Datensätze mit Fehlerkennzeichen entladen werden oder nicht, letzteres ist Default. Wenn Sie die Zeilen entladen wollen, setzen Sie den Filter auf "1=1". |
bew_anschrkz | anschrkz | Soll das Feld bew.anschrkz (fuer Vorabimmatrikulation - siehe Tabelle sos) entladen werden? Wenn ja, dann ist der Wert "anschrkz", wenn nein, dann ist er "null::char(1)" |
bew_antrnr | antrnr | Soll das Feld bew.antrnr (Kleinste Antragsnummer, zu der ein Zulassung vorliegt, sonst 99) entladen werden? Wenn ja, dann ist der Wert "antrnr", wenn nein, dann ist er "null::char(1)" |
bew_erfassungsart | erfassungsart | Soll das Feld bew.erfassungsart (Erfassungsart) entladen werden? Wenn ja, dann ist der Wert "erfassungsart", wenn nein, dann ist er "null::char(1)" |
bew_fehlerkz | fehlerkz | Soll das Feld bew.fehlerkz (Fehlerkennzeichen) entladen werden? Wenn ja, dann ist der Wert "fehlerkz", wenn nein, dann ist er "null::char(1)" |
bew_gebdat | gebdat | Soll das Feld bew.gebdat entladen werden? Wenn ja, dann ist der Wert "B.gebdat", wenn nein, dann ist es null::char(1). Gilt nur für SOSPOS als Quellsystem |
bew_gebname | null::char(1) | Soll das Feld bew.gebname entladen werden? Wenn ja, dann ist der Wert "B.gebname", wenn nein, dann ist es null::char(1). Gilt nur für SOSPOS als Quellsystem |
bew_gebort | null::char(1) | Soll das Feld bew.gebort entladen werden?. Wenn ja, dann ist der Wert "B.gebort", wenn nein, dann ist es null::char(1). Gilt nur für SOSPOS als Quellsystem |
bew_hmkfz | hmkfz | Soll das Feld bew.hmkfz (Heimat-Kfz) entladen werden? Wenn ja, dann ist der Wert "hmkfz", wenn nein, dann ist er "null::char(1)" |
bew_hmkfzkz | hmkfzkz | Soll das Feld bew.hmkfzkz (Heimat-Kfz-Kennz., I=Inland, A=Ausland) entladen werden? Wenn ja, dann ist der Wert "hmkfzkz", wenn nein, dann ist er "null::char(1)" |
siehe Hochschul-Repository-Bewerbung-Zul- HISinOne-BI
In ZUL-GX und HISinOne-APP ist es vorgesehen, Bewerberdaten semesterweise zu löschen. In der HISinOne-BI können diese Daten weiterhin vorgehalten werden. Dazu werden die Bewerbernummern in Kombination mit dem Semester einer künstlichen Bewerber-ID zugeordnet (Tab. zul_bewnr_bewid), Sie können die Daten also semesterweise in der HISinOne-BI speichern. Sobald ein Semester aus dem Vorsystem entladen wird (d.h. mindestens ein Datensatz für das Semester ist im Unload enthalten), werden die Daten dieses Semesters in der HISinOne-BI ausgetauscht.
Semesterweise Archivierung von Bewerberdaten
Die Laderoutine Bewerbungen arbeitet wie folgt:
ZUL_start_antr_aggr ein, Bei der Datenquelle CO werden Anträge bei Mehrfachstudiengängen jeweils als Gesamtantrag und für die jeweiligen Teilstudiengänge geliefert. In diesem Fall muss der Gesamtantrag entfernt werden, und bei den Teilstudiengängen muss das "Annahme"-Kennzeichen entfernt werden, weil die jeweiligen Teilstudiengänge auch in anderen Anträgen angenommen werden können.
Bei Einfachstudiengängen ist dies nicht nötig.
Außerdem kann ein Teilstudiengang in mehreren Anträgen vorkommen. Die Information, ob zugelassen oder eingeschrieben wurde, wird aber nicht bei jedem Datensatz geliefert. In diesem Falle wird der Teilstudiengang mit Zulassungs- bzw. Einschreibungs-Kennzeichen mit jeweils höherer Prio genommen also ohne.
Folgende Regeln wurden demnach implementiert:
Die Bewerbungen können über die Oberfläche oder per SQL-Abfrage direkt auf der Datenbank validiert werden.
APP
Wählen Sie z. B. die Rolle Bewerber-Manager/-in. Wählen Sie dann im Menü siehe bewerbungbearbeiten. In der (erweiterten) generischen Suche geben Sie das Wintersemester 2020 an. Außerdem wählen Sie entsprechend der Einstellung Ihrer Entladeparamter APP_request_status und APP_requestsubject_status (hier für die voreingestellten Defaultwerte der beiden Entladeparameter)
Antragsstatus != 'In Vorbereitung' oder 'Eingegangen' oder 'In Bearbeitung'
sowie
Antragsfachstatus != 'In Vorbereitung' oder 'Eingegangen' oder 'Vorläufig ausgeschlossen'
Außerdem müssten Sie noch die Einschränkung auf Köpfe analog zur BI-Suche angeben:
Fachnummer = 1 Antragsnummer = 1
Klicken Sie dann auf "Suchen", so erhalten Sie eine Liste der Bewerber/innen. Rechts unten sehen Sie die Anzahl der Suchergebnisse, die der Anzahl der Bewerber/innen entspricht.
HISinOne-BI
Wählen Sie z. B. die Rolle BI-Spezialist/-in. In der BI rufen Sie in der Komponente Bewerbungen, Zulassungen den Standardbericht Bewerbungsprozess nach Fach/Studiengang auf. Wählen Sie:
Bewerbungen: Köpfe, Semester: WiSe 2020/2021,
Klicken Sie anschließend auf Abschicken und Sie erhalten die Berichtsausgabe mit der Gesamtzahl von Bewerberinnen und Bewerbern im Wintersemester 2020/21.
OLAP
Wählen Sie z. B. die Rolle BI-Spezialist/-in. In OLAP ziehen Sie im Cube Bewerbungen die Kennzahl "Anzahl (Köpfe)" in die Spalten und das Level "Semester" in die Zeilen und erhalten so Bewerber/-innen im Wintersemester 2020/21.
APP
SELECT count(distinct p.id) from requestsubject RS, requestsubjectgroup_requestsubject RG, requestsubjectgroup RSG,request R, requestgroup G, application AP, applicant AT, person P , term_type T where RS.id=RG.requestsubject_id and RSG.id=RG.requestsubjectgroup_id and RSG.request_id=R.id and R.requestgroup_id=G.id and G.application_id=AP.id and AP.applicant_id=AT.id and AT.person_id=P.id and T.id=AP.term_type_id and AP.term_year::text || T.termnumber='20202' --aktuelles Bewerbungssemester and R.k_request_status_id in (select KRS.id from k_request_status KRS where (KRS.hiskey_id not in (1,2,3) or KRS.hiskey_id is null)) and RS.k_requestsubject_status_id in (select KRS.id from k_requestsubject_status KRS where (KRS.hiskey_id is null or KRS.hiskey_id not in (1,2,3)));
HISinOne-BI
select count(*) from zul_antr_aggr where bewsem=20202 and antrnr=1 and fachnr=1
APP
Wählen Sie z. B. die Rolle Bewerber-Manager/-in. Wählen Sie dann im Menü siehe requestMassEdit. In der generischen Suche geben Sie das Wintersemester 2020 an. Außerdem wählen Sie entsprechend der Einstellung Ihrer Entladeparameter APP_request_status und APP_requestsubject_status (hier für die voreingestellten Defaultwerte der beiden Entladeparameter)
Antragsstatus != 'in Vorbereitung' oder 'eingegangen' oder 'in Bearbeitung'
sowie
Antragsfachstatus != 'in Vorbereitung' oder 'eingegangen' oder 'vorläufig ausgeschlossen'
Klicken Sie dann auf Suchen, so erhalten Sie eine Liste mit Anträgen.
HISinOne-BI
Wählen Sie z. B. die Rolle BI-Spezialist/-in. In der BI rufen Sie in der Komponente Bewerbungen, Zulassungen den Standardbericht Bewerbungsprozess nach Fach/Studiengang auf. Wählen Sie:
Bewerbungen: Anträge, Semester: WiSe 2020/2021.
Klicken Sie anschließend auf Abschicken und Sie erhalten die Berichtsausgabe mit der Gesamtzahl von Anträgen im Wintersemester 2020/21.
OLAP
Wählen Sie z. B. die Rolle BI-Spezialist/-in. In OLAP ziehen Sie im Cube Bewerbungen die Kennzahl "Anzahl (Anträge)" in die Spalten und das Level "Semester" in die Zeilen und erhalten Bewerber/-innen im Wintersemester 2020/21.
APP
SELECT count(distinct r.id) from requestsubject RS, requestsubjectgroup_requestsubject RG, requestsubjectgroup RSG, request R, requestgroup G, application AP, applicant AT,person P, term_type T where RS.id=RG.requestsubject_id and RSG.id=RG.requestsubjectgroup_id and RSG.request_id=R.id and R.requestgroup_id=G.id and G.application_id=AP.id and AP.applicant_id=AT.id and AT.person_id=P.id and T.id=AP.term_type_id and AP.term_year::text || T.termnumber='20202' --aktuelles Bewerbungssemester and R.k_request_status_id in (select KRS.id from k_request_status KRS where (KRS.hiskey_id not in (1,2,3) or KRS.hiskey_id is null)) and RS.k_requestsubject_status_id in (select KRS.id from k_requestsubject_status KRS where (KRS.hiskey_id is null or KRS.hiskey_id not in (1,2,3)));
HISinOne-BI
select count(*) from zul_antr_aggr where bewsem=20202 and fachnr=1
APP
Wählen Sie z. B. die Rolle Bewerber-Manager/-in. Wählen Sie dann im Menü siehe requestSubjectMassEdit. In der generischen Suche geben Sie das Wintersemester 2020 an. Außerdem wählen Sie entsprechend der Einstellung Ihrer Entladeparameter APP_request_status und APP_requestsubject_status (hier für die voreingestellten Defaultwerte der beiden Entladeparameter)
Antragsstatus != 'in Vorbereitung' oder 'eingegangen' oder 'in Bearbeitung'
sowie
Antragsfachstatus != 'in Vorbereitung' oder 'eingegangen' oder 'vorläufig ausgeschlossen'
Klicken Sie dann auf Suchen, so erhalten Sie eine Liste der Antragsfächer.
HISinOne-BI
Wählen Sie z.B. die Rolle BI-Spezialist/-in. In der BI rufen Sie in der Komponente Bewerbungen, Zulassungen den Standardbericht Bewerbungsprozess nach Fach/Studiengang auf. Wählen Sie:
Bewerbungen: Antragsfächer, Semester: WiSe 2020/2021.
Klicken Sie anschließend auf Abschicken und Sie erhalten die Berichtsausgabe mit der Gesamtzahl der Antragsfächer im Wintersemester 2020/21.
OLAP
Wählen Sie z.B. die Rolle BI-Spezialist/-in. In OLAP ziehen Sie im Cube Bewerbungen die Kennzahl "Anzahl (Antragsfächer)" in die Spalten und das Level "Semester" in die Zeilen und erhalten Antragsfächer im Wintersemester 2020/21.
APP
SELECT count(*) from requestsubject RS, requestsubjectgroup_requestsubject RG, requestsubjectgroup RSG, request R, requestgroup G, application AP, applicant AT,person P, term_type T where RS.id=RG.requestsubject_id and RSG.id=RG.requestsubjectgroup_id and RSG.request_id=R.id and R.requestgroup_id=G.id and G.application_id=AP.id and AP.applicant_id=AT.id and AT.person_id=P.id and T.id=AP.term_type_id and AP.term_year::text || T.termnumber='20202' --aktuelles Bewerbungssemester and R.k_request_status_id in (select KRS.id from k_request_status KRS where (KRS.hiskey_id not in (1,2,3) or KRS.hiskey_id is null)) and RS.k_requestsubject_status_id in (select KRS.id from k_requestsubject_status KRS where (KRS.hiskey_id is null or KRS.hiskey_id not in (1,2,3)));
HISinOne-BI
select count(*) from zul_antr_aggr where bewsem=20202
Wenn einzelne Studiengänge bei Datenquelle APP in der Statistik fehlen, liegt es vielleicht an der Gültigkeit der Fächer bzw. Studiengänge, z. B. wenn ein Studiengang, der vom 1.1.1900 gültig ist, ein Fach zugewiesen bekommt, das erst ab 2015 gültig ist. Das ist nicht vorgesehen, ein Fach muss zur gesamten Laufzeit des Studiengangs gültig sein.
Sie können solche Fälle in HISinOne in der Datenbank abfragen mit
select S.valid_from as beginn_fach,C.valid_from as beginn_studiengang,C.defaulttext as studiengang from hisinone.subject S, hisinone.course_of_study C where C.subject_lid=S.lid and S.valid_from > C.valid_from order by defaulttext;
Die Ergebnisliste zeigt den Beginn von Fach und Studiengang, ggf. korrigieren Sie den Gültigkeitsbeginn des Studiengangs.
In der Maske "Bewerbungsprozeß nach Fach/Studiengang" werden nicht nur gültige Bewerbungen angezeigt, sondern davon dann absolut und relativ jeweils
Bei Datenquelle APP sind die Kriterien fest vorgegeben. Folgende Bedingungen setzen das Kennzeichen "Zulassung":
Folgende Bedingungen setzen das Kennzeichen "Annahme":
Folgende Bedingungen setzen das Kennzeichen "Einschreibung":
Wenn Sie keine spezielle Konfiguration im Filter für gültige Bewerbungen vorgenommen haben, können Sie die Bewerbungen leicht validieren. Nehmen wir z.B. das WiSe 2014/2015: folgende Zahl wird im Bericht Bewerbungsprozeß nach Studiengang ausgegeben: 310
Die Selektion in ZUL-GX würde lauten:
select count(*) from antr A, bew B where A.bewnr=B.bewnr and (B.fehlerkz != 'F' or B.fehlerkz is null) and B.bewsem=20142 and (A.bewsem=20142 or A.bewsem is null);
Das Ergebnis von 310 Bewerbungen (es handelt sich hier um "Fälle") ist identisch.
Wenn die Zahlen aus dem Vorsystem und der BI nicht übereinstimmen, kann das mehrere Gründe haben. Bitte prüfen Sie zunächst die Entladeparameter und passen Sie die Validierungsabfrage an.
Ein paar Beispiele:
1. In der BI werden weniger Bewerber/-innen ausgegeben, als in APP. Der Entladeparameter APP_request_status ist so eingestellt, dass nur Anträge von Bewerberinnen und Bewerbern mit den Status 1 (in Vorbereitung), 2 (eingegangen) oder 3 (in Bearbeitung) in die BI eingelesen wurden. Bei der Selection in APP aber wurde nach allen Bewerberinnen und Bewerbern gesucht, also auch die mit anderen Antragsstatus, z. B. 5 (ausgeschlossen) oder 6 (Zulassungsangebot liegt vor). Hier müssen Sie entscheiden, ob Sie den Entladeparameter in der BI anpassen und somit weitere Anträge einlesen, oder ob Sie die Selection in APP verändern.
2. Das Gleiche gilt für den Entladeparameter APP_requestsubject_status; hier wird nach dem Antragsfach selektiert. Auch hier müssen Sie die Antragsstatus im Entladeparamter und in APP überprüfen.
3. Bei der Datenübernahme aus ZUL ist das Verfahren anders. Hier wird nicht über Entladeparameter gefiltert, sondern über die Variablen. Sie finden diese unter Bewerbung, Zulassung --> Administration Bewerbung, Zulassung --> Prüfprotokoll Bewerbung, Zulassung --> Filter Bewerbungen. Bitte lesen Sie dazu
4. Bitte überprüfen Sie auch das Prüfprotokoll nach Hinweisen, ob z. B. Datensätze nicht übernommen wurden.
Nach der Installation können Sie das Verhalten der Software über Konstanten steuern.
Übersicht
:Eine Übersicht über alle Konstanten der Komponente finden Sie hier: Konstanten - HISinOne-BI
Besonderheiten einzelner Konstanten
ZUL_start_antr_aggr
Diese Konstante legt fest ab welchem Bewerbungssemester Bewerbungsdaten in BI gelöscht und mit Daten aus dem Liefersystem (z.B. HISinOne-APP oder ZUL-GX) neu geschrieben werden sollen.
ZUL_Quellsystem
:Die Konstante zeigt an, aus welchem Quellsystem der letzte Konnektorlauf stattgefunden hat.
:*Für die Hauptladeroutine können Sie diese im Entladescript setzen
:* Unterladeroutinen gelten jeweils nur für ein Vorsystem, verwenden Sie hier den entsprechenden Konnektor
siehe Hochschul-Repository-Bewerbung-Zul- HISinOne-BI
Die Maske Prüfprotokoll Bewerbung und Zulassungen gibt Warnungen und Informationen zum Ladeprozess aus. Informationen zu Warnungen geben die FAQs. Bei der Datenbereinigung sollten Sie immer zunächst die Probleme in Stammdaten bereinigen.
Hier die Auswahlmaske:
Und hier ein Beispielergebnis:
Beim Mischbetrieb HISinOne und SOSPOSZUL werden die Stammdaten migriert, und die HISinOne-Stammdaten werden über den "eindeutigen Schlüssel" (uniquename) zum alten SOSPOSZUL-Schlüssel "gemappt". So lassen sich im DWH für Altdaten Daten aus dem alten Vorsystem (ZUL-GX) laden und in jüngeren Semestern aus APP.
Folgenden Fallstrick gibt es dabei:
Die Deinstallation des ZUL-Moduls unterscheidet sich zwischen HISinOne und SuperX. Daher gibt es zu jedem System eine eigene Installationsseite:
Wenn Sie nur die Inhalte der Daten- und Hilfstabellen des Moduls löschen wollen (z. B. aus Datenschutzgründen), ohne das ganze Modul zu deinstallieren, können Sie dies mit folgendem Befehl tun:
DOSQL $SUPERX_DIR/db/module/zul/zul_purge_pg.sql (für Postgres)bzw. DOSQL $SUPERX_DIR/db/module/zul/zul_purge_ids.sql (für Informix)
Für SuperX: Modul-Version
Für HISinOne: siehe aktuelle Release Notes