Zuletzt bearbeitet vor einem Jahr
von Thomas Lipke

Konfigurationshandbuch Bewerbung, Zulassung

Konfigurationshandbuch Komponente Bewerber, Zulassungen

Einführung

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.

Installation des Bewerbungs-Moduls

Die Installation des ZUL-Moduls unterscheidet sich zwischen HISinOne und SuperX. Daher gibt es zu jedem System eine eigene Installationsseite:

Daten entladen

Entladen aus SOSPOS mit eingeschränkten Datenbankrechten

Wenn Sie die Datenbank-Rechte beim Entladen aus dem Vorsystem sospos so ändern wollen, dass der Datenbank-User nur auf ausgewählte Tabellen Leserechte besitzt, dann müssen Sie folgende Tabellen mit Leserechten versehen:

  • antr
  • bew
  • db_version
  • degree
  • eignbew
  • eignstg
  • eigntxt
  • hskonst
  • k_abext
  • k_abint
  • k_akfz
  • k_astfr
  • k_astgrp
  • k_bland
  • k_fb
  • k_gender
  • k_hrst
  • k_hzbart
  • k_ikfz
  • k_kzfa
  • k_le
  • k_modulart
  • k_nc
  • k_ncbuch
  • k_ncplaz
  • k_ppruef
  • k_pstatus
  • k_s_var
  • k_schwp
  • k_sperre
  • k_status
  • k_stg
  • k_stort
  • k_stuart
  • k_stufrm
  • k_stutyp
  • k_topf
  • k_verarbkz
  • k_vert
  • k_zulart
  • mtknr_ldsg
  • nc_rang
  • person
  • quote
  • sos
  • sossys


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 <<Kennung>>

Inkrementelles Laden

Modul Bewerbungen Zulassungen inkrementell Laden - HISinOne-BI

Entladeparameter

Eine Übersicht über die Entladeparameter finden Sie hier: Entladeparameter Bewerbung, Zulassung

Details zu einzelnen Parametern


Entladeparameter SOSPOS

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:

Entladeparameter für HISinOne

APP_CONTENT

attention.svg
Verfügbar ab Version 		{{{1}}} {{{2}}}

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.

Datei:zul app content 4.png
Schlüsseltabellen GANG-Modul


Folgender SQL gibt ebenfalls die verfügbaren Bewerbungsbestandteil-Definitionen und somit deren uniquenames aus (Voraussetzung ist, dass der ZUL-Konnektor bereits gelaufen ist): 

select * from zul_app_content;

Die Bewerbungsbestandteile lassen sich als weitere Tabelle über das Bewerbungen und Zulassungen Datenblatt abrufen (s. Benutzungshandbuch).

APP_request_status und APP_requestsubject_status

APP_request_status

Der Filter für entladene Bewerbungen kann konfiguriert werden: Standardvorgabe ist der Wert 

KRS.hiskey_id not in (1,2,3)

Dies bedeutet, dass Bewerbungen mit den Antragsstatus (Tabelle k_request_status)

  • in Vorbereitung
  • eingegangen
  • in Bearbeitung

nicht in die BI übertragen werden. Sie können den Filter aber auch ändern, hier der Inhalt der Tabelle k_request_status (HISinOne 6.1): 

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

APP_requestsubject_status

Der Filter für entladene Bewerbungen kann konfiguriert werden: Standardvorgabe ist der Wert 

KRS.hiskey_id not in (1,2,3)

Dies bedeutet, dass Bewerbungen mit den Antragsfachstatus (Tabelle k_requestsubject_status)

  • in Vorbereitung
  • eingegangen
  • vorläufig ausgeschlossen

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
  101      Immatrikulation beantragt
  102      Immatrikulationsantrag in Bearbeitung
  103      Immatrikulationsantrag abgelehnt
  104      Immatrikuliert


Bitte prüfen Sie, welche Status zu Ihren Anforderungen passen. Wenn Sie z. B. nur Bewerbungen mit dem Antragsstatus in Vorbereitung ausschließen wollen, würde der Filter lauten: 

(KRS.hiskey_id not in (1) or KRS.hiskey_id is null)

Entladeparameter CO

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)"

Einladen der Bewerberdaten

Historisierung

In ZUL-GX und HISinOne-APP ist es gängige Praxis, 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 jew. Semester aus ZUL 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.

Repository-Variable für ZUL "gültige Bewerbungen" anpassen

Damit auch die gültigen Bewerber/-innen richtig angezeigt werden, müssen diese richtig selektiert werden. Die Selektion selbst ist von Hochschule zu Hochschule unterschiedlich. Daher wurde ein hochschulspezifischer Filter angelegt, der im ZUL-Modul verwaltet wird. In der Repositoryvariable „ZUL_FILTER_AGGR“ steht eine SQL-Bedingung, die wahr sein muss, um einen Datensatz als gültigen Bewerber einzustufen. Gehen Sie dazu in das Menü Administration -> Tabelle suchen -> Stichwort "repo" -> dort auf die Tabelle Hochschul-Repository (Liste).

Datei:zul repo1.png

Dort suchen Sie den Filter ZUL_FILTER_AGGR

Datei:ZUL FILTER AGGR suchen.png

Es erscheint ein Bearbeitungsformular:

Datei:zul repo3.png

Im Auslieferungszustand steht dort: 

and (B.fehlerkz != 'F' or B.fehlerkz is null)

Möchten Sie anstatt von einer Auswahl lieber eine bestimmte Selektion ausschließen, ändern Sie den Anfang wie folgt: 

and (B.fehlerkz not in ( …

Dies könnte dann z.B. so aussehen: 

and (B.fehlerkz not in ('F','-') or B.fehlerkz is null)

An manchen Hochschulen wird auch eine ganz andere Spalte benutzt. Dies ist natürlich auch möglich. Beispiel: 

and (B.verarbkz in (select apnr from zul_k_verarbkz where uniquename in ('BA','IM','EX','BB')) or B.verarbkz is null)

Wichtig ist hierbei nur ('BA','IM','EX','BB'). Diese Kette können Sie beliebig erweitern, kürzen und ändern, je nachdem welche Verarbeitungskennzeichen Sie nutzen. Es muss lediglich der Text zwischen zwei Hochkommata stehen und diese mit Kommas getrennt sein.

Nach einer Änderung müssen Sie den ZUL-Update neu starten bzw. eine Nacht warten. Kontrollieren Sie dann die Werte anhand der Abfrage Bewerbungsprozess nach Studiengang.

Spezielle Transformationen bei Datenquelle CO

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:

  • Wenn es pro Gesamtantrag mehrere Teilstudiengänge gibt, wird der Gesamtantrag entfernt, und das Annahme-Kennzeichen entfernt. Solche Datensätze sind erkennbar an: antr.bewnr=antr.satzid
  • Wenn eine Fach/Abschluss-Kombination in mehreren Anträgen vorkommt, wird die mit Zulassung und Einschreibungs-Kennzeichen mit jeweils höherer Priorität genommen als ohne

Validierung Bewerbung

Validierung Bewerbungen gegen HISinOne-APP

Die Bewerbungen können über die Oberfläche oder per SQL-Abfrage direkt auf der Datenbank validiert werden.

Validierung Bewerbungen (Köpfe) an der Nutzeroberfläche

APP

Wählen Sie z. B. die Rolle Bewerber-Manager/-in. Wählen Sie dann im Menü {{#navigation: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.

Validierung Bewerbungen (Köpfe) per Skript

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
Validierung Bewerbungen (Anträge) an der Nutzeroberfläche

APP

Wählen Sie z. B. die Rolle Bewerber-Manager/-in. Wählen Sie dann im Menü {{#navigation: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.

Validierung Bewerbungen (Anträge) per Skript

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
Validierung Bewerbungen (Antragsfächer) an der Nutzeroberfläche

APP

Wählen Sie z. B. die Rolle Bewerber-Manager/-in. Wählen Sie dann im Menü {{#navigation: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.

Validierung Bewerbungen (Antragsfächer) per Skript

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
Gültigkeiten von Fächern und Studiengängen in der Bewerberstatistik

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.

Validierung Bewerber gegen ZUL-GX

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

Datei:bew validierung zul.png

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.

Vorgehen bei Unstimmigkeiten bei der Validierung

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 Filter Bewerbungen anpassen.

4. Bitte überprüfen Sie auch das Prüfprotokoll nach Hinweisen, ob z. B. Datensätze nicht übernommen wurden.

Konfiguration nach der Installation

Konstanten

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#BI-Komponente_Bewerbung.2C_Zulassung
Besonderheiten einzelner Konstanten
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

Button Filter Zulassung

Die ZUL-Abfrage hat in der Abfragemaske eine Schaltfläche namens Filter Zulassungen. Diese ist vorbelegt mit Beispieleinträgen, bei denen z. B. nach "nur Antragsnummer = 1" gefiltert wird.

Der Feldinhalt des Buttons kann von einem/einer Administrator/-in leicht mit eigenen Werten gefüllt werden. In der Repositoryvariable „ZUL_BEW_FILTER“ steht eine SQL-Bedingung, die Wahr sein muss, um einen Datensatz als gültigen Bewerber/gültige Bwerberin einzustufen. Gehen Sie dazu in das Menü Administration -> Tabelle suchen -> Stichwort "repo" -> dort auf die Tabelle Hochschul-Repository (Liste).

Datei:zul repo1.png

Gehen Sie hier zu den Filtern der Art " ZUL" (Vorgehen wie oben). In der Auslieferung gibt es zwei Filter:

Filter-ID SQL-Klausel Anzeigename Erläuterung Art des Filters
ZUL_FILTER_ANTR_1 antrnr=1 nur Antragsnummer = 1 Hauptantrag ZUL_BEW_FILTER
ZUL_FILTER_ANTR_GR_1 antrnr>1 nur Antragsnummer > 1 Hilfsantrag ZUL_BEW_FILTER

Die Hochschule kann diesen Filter jeweils ändern oder sogar ganz eigene Filter erzeugen. Der Feldinhalt kann z. B. in Form einer SQL-Where-Bedingung auf die Tabellen "zul_antr_aggr Z, zul_k_abint A, zul_k_stg S" formuliert werden.

Wenn ein Filter eingebaut wird, muss er in die Tabelle sx_repository eingetragen werden (Neue ID vergeben, Feld art ="ZUL_BEW_FILTER" ), systeminfo_id=130.

Nach einer Änderung ist der Filter direkt in der Maske nutzbar (also nicht erst einen Tag später).

Prüfprotokoll Bewerbung und Zulassungen

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:

Datei:zul pruefrout maske.png

Und hier ein Beispielergebnis:

Datei:zul pruefrout tabelle.png

Mischbetrieb HIS-GX und HISinOne

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:

  • Anders als SOSPOS arbeitet HISinOne mit historisierten Stammdaten für Studiengänge, d. h. die Stammdaten haben einen Gültigkeitszeitraum. Bitte die Gültigkeiten z. B. der Fächer in HISinOne prüfen: sie müssen länger gültig sein als die Studiengänge, die dieses Stammdatum referenzieren. Wenn z. B. die Studiengänge vom 1.1.1900 gültig sind, muss man beim Fach statt "Gültig vom=xx.xx.2014" folgendes schreiben: "Gültig vom=01.01.1900".
  • Eine Zuordnung von uniquename zur ID wird persistent gespeichert und kann (derzeit noch) nicht manuell geändert werden.

Entfernen des ZUL-Moduls

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)

Abgerufen von „https://superxhosting.de/wiki/index.php?title=Konfigurationshandbuch_Bewerbung,_Zulassung&oldid=11583“