| 1 | Students
********
Nach der Application erfolgt die Registrierung der Studenten. Studentendaten werden entweder durch Übernahme der Application-Daten, durch Import bestehender Datensätze oder durch Hinzufügen eines leeren Datensatzes erzeugt. An dieser Stelle sei zunächst nur die Übernahme der Applicationdaten beschrieben.
**1. Aus Applicants werden Studenten**
Nachdem durch Datenimport Applicants in den Status 'admitted' versetzt worden sind und gleichzeitig ein course_admitted zugeordnet wurde, werden alle Applicants im Status 'admitted' in Studentendatensätze umgewandelt und gleichzeitig in den Status 'created' versetzt.
Dabei wird zunächst ein Student-Objekt (Container?!) erzeugt und es werden Basisdaten von dem Applicant-Objekt in das neu erzeugte Student-Objekt kopiert (inkl. Passbild). Beim Erzeugen des Student-Objektes wird eine Student Id generiert die zusätzlich in das originale Applicant-Objekt eingetragen wird.
Sinnvoll wäre es, das originale Applicant-Objekt (ohne Passbild) in den Student-Container zu kopieren. Die meisten Daten aus dem Application-Objekt werden zwar nie wieder gebraucht, trotzdem ist es sinnvoll, die Application-Daten von zugelassenen Studenten vollständig zu erhalten.
Die Datenübernahme in die Students Section ist im Prinzip noch Aufgabe des (eigenständigen) Applicationmoduls. Das Studentmodul ist Basisausstattung von SIRP und sollte auch ohne Applicationmodul lauffähig sein.
**2. First-time Login (Admission Checking)**
Studenten loggen sich das erste Mal mit ihrer Student Id und einem neuen Access Code (PIN) ein. Der AC wird dann zum Password. Falls die Student Id noch nicht bekannt ist, z.B. beim Umgehen der Application, muss eine (z.B. JAMB) Registration Number als Ersatz dienen.
Jetzt prüft der Student zunächst seine Zulassungsdaten und ob der ihm zugewiesene Studiengang korrekt und genehm ist. Im SRP bestand die Möglichkeit, Einspruch zu erheben. Diese Möglichkeit hat sich nicht bewährt und nur zu Verwirrungen geführt. Einspruch muss außerhalb des Portals eingelegt werden
können. Sind die Daten korrekt, kann der Clearance-Prozess beginnen.
**3. Clearance**
Die Clearence wird mit einem Clearance AC eingeleitet. Eine spezielle Clearance Form muss ausgefüllt werden und viele Scans hochgeladen werden. Ist dies erfolgt, wird die Form an den Clearance Officer des Departments oder der Fakultät (User mit entsprechender lokaler Rolle) submitted. Der Clearance Officer überprüft die Daten. Sind die Daten korrekt, wird die Transition 'validate_and_clear' ausgeführt. Bei fehlerhaften Daten wird die Transition 'reject_clearance' ausgeführt und der Student erhält die Möglichkeit seine Daten zu korrigieren und erneut einzureichen. 'reject_clearance' wird durch Versand einer Email dem Studenten mitgeteilt. Nach erfolgreicher Clearance werden die Studiengebühren für das erste Jahr bezahlt (siehe Abschnitt 'Bezahlung der Studiengebühren').
**4. Personal Data Form**
Von Beginn an ist ein Teil der Daten, die nicht für die Clearance zwingend erforderlich und entscheidend sind, in der Personal Data Form jederzeit zum Editieren offen. Die Studentendaten sind somit dreigeteilt: 1. unveränderliche Application Data, 2. Clearance Data, die nach der Clearance gesperrt werden und 3. allzeit offene und veränderbare Personal Data.
**5. Bezahlung der Studiengebühren**
Die Bezahlung der Studiengebühren löst die Transition pay_school_fee aus. Studiengebühren könnten bei einer übersichtlichen Staffelung der Gebühren über die Eingabe eines AC bezahlt werden, d.h. für jede Gebührenform gäbe es einen eigenen AC-Batch. In Nigeria gibt es diese einfache Staffelung nicht. Komplexe Algorithmen oder aufwendige Tabellen kommen zur Ermittlung der Studiengebühren zum Einsatz. Hinzu kommen Zusatzgebühren für die verschiedenen Einrichtungen, so dass nur eine dynamische Berechnung der Gebühren und die Bezahlung über ein externes Paymentportal in Frage kommt. Dem Paymentportal wird von SIRP nicht nur die Höhe der Gebühren mitgeteilt, sondern auch wie sich die Gebühren aufteilen und auf welche Konten die Gebühren überwiesen werden müssen.
Aufgrund der Komplexität der Bezahlung ist es sinnvoll, ein eigenes Modul für die Online-Bezahlung von Gebühren zu entwickeln. Dieses Modul erzeugt Payment-Objekte die bei erfolgreicher Bezahlung als Quittung dienen und die im Student-Container abgelegt werden. Die Transition wird durch die Online-Bezahlung nicht automatisch vorgenommen, sondern muss - im Gegensatz zum SRP - manuell ausgelöst werden. Im gesonderten Payment-Modul werden Payment-Objekte erzeugt, die durch den Callback des Paymentgateways (das kann in der Zukunft unter Umständen auch ein Kreditkartenunternehmen sein) als bezahlt markiert werden. Dies ermöglicht, eine Bezahlung auch vorab oder nachträglich vorzunehmen, d.h. auch dann, wenn es der Workflow des Studenten gar nicht erlaubt. Zum manuellen Auslösen der Transition müsste nach einem Paymentobjekt gesucht werden, dass die erforderlichen Kriterien erfüllt. Im Falle der Studiengebühr wären das die die Payment Category, die Student Id, das Studienfach und die Session. vermutlich ist ein Catalog sinnvoll.
**6. Kursregistrierung**
- in Bearbeitung -
|
|---|
