Index: main/waeup.sirp/trunk/docs/source/developerdocs/german/accesscodes.rst
===================================================================
--- main/waeup.sirp/trunk/docs/source/developerdocs/german/accesscodes.rst	(revision 5643)
+++ main/waeup.sirp/trunk/docs/source/developerdocs/german/accesscodes.rst	(revision 5643)
@@ -0,0 +1,18 @@
+Access Codes
+------------
+
+Die Access Codes (AC) dienen zwei Zwecken. Zum einen ermöglicht der Verkauf dieser Codes auf Scratch Cards die Bezahlung von Dienstleistungen ohne Verwendung des aufwendigen Cash Card Systems. Zum anderen kann über die persönlich ausgegebenen Codes (beim Verkauf wird zu jeder Seriennummer der Name notiert) der sichere Erstzugang zum Portal ermöglicht werden. Der Zufallsteil des Codes wird bei der Application als geheime Zugangskennung zum persönlichen Datensatz und beim Admission Checking als Erstpasswort für das Portal verwendet. Das AC-Modul hat folgende Eigenschaften:
+
+- Die ACs werden in einer Tabelle verwaltet und in Batches generiert. Ein Batch wird innerhalb der Tabelle durch einen Prefix (= Verwendungszweck) und eine Batch Number identifiziert. Der Access Code besteht insgesamt aus drei Teilen: dem Batch-Prefix aus bis zu 7 Großbuchstaben, der bis zu dreistelligen Batch Number und einer zehnstelligen Zufallszahl, die innerhalb eines Batches eindeutig ist. Das Anzeigeformat ist wie folgt:
+
+ APP-1-1234567890
+
+ In der Tabelle werden zu jedem AC außerdem abgespeichert: Serial Number (innerhalb eines Batches fortlaufend), Cost (Kosten der jeweiligen Scratch Card), Date (Datum der Entwertung), Student (Id oder Registration Number des Studenten, für den der AC entwertet wurde)
+
+- Zu jedem Batch müssen das Herstellungsdatum und der Nutzer (in der entsprechenden Log-Datei) protokolliert werden. 
+
+- Bei der Herstellung eines AC-Batches muss eine für den AC-Verwalter (eigene Rolle) zugängliche csv-Datei erzeugt werden, deren Dateinamen die Nutzer-Id, das Herstellungsdatum, den Prefix und die Batchnummer enthält. Ansonsten enthält die Datei drei Datenspalten: Serial Number, AC (im Anzeigeformat) und Cost. 
+
+- Schließlich muss die Möglichkeit der Archivierung (und wahlweise Löschung) eines Batches sowie des Reimports von Archiv-Dateien gegeben sein. In den Archivdateien müssen zusätzlich die Spalen: Date und Student enthalten sein.
+
+
Index: main/waeup.sirp/trunk/docs/source/developerdocs/german/application.rst
===================================================================
--- main/waeup.sirp/trunk/docs/source/developerdocs/german/application.rst	(revision 5643)
+++ main/waeup.sirp/trunk/docs/source/developerdocs/german/application.rst	(revision 5643)
@@ -0,0 +1,65 @@
+Application
+***********
+
+Das Application Package dient der Anmeldung einer großen Zahl von Personen (bis 50.000) zur Teilnahme an einem hochschulinternen Screening-Verfahren, welche die Zulassung zum Studium an der Hochschule regeln. Es gibt zur Zeit acht verschiedene Screening-Verfahren und entsprechend viele Anmeldeformulare, die sich alle in in ihren Stammdaten sehr ähneln. Ein Screening wird in der Regel durch einen Massentest ('Exercise') begleitet. Manchmal spielt auch nur die Herkunft (z.B. aus dem armen Norden) oder das Geschlecht eine Rolle bei der Vergabe von Studienplätzen. Hier die verschiedenen Screening-Verfahren:
+
+**1. Universities**
+
+PUME: Post University Matriculation Examination 
+ Die UME-Daten werden von JAMB übermittelt. Diese Studenten haben schon eine JAMB-Prüfung absolviert, die sich UME nennt. JAMB ist die zentrale nigerianische Zulassungsstelle, über die die Zuweisung der Applikanten an die verschiedenen Hochschulen gesteuert wird.
+    
+PUDE: Post University Direct Entrance
+ Die UDE-Daten werden von JAMB übermittelt. Diese Studenten haben keine JAMB-Prüfung absolvieren müssen, ihre Daten werden nur weitergeleitet.
+    
+DP: Screening für Diploma Students
+
+CT: Screening für Certificate Students (einige Certificates tragen den offiziellen Namen 'Certificate'')
+    
+SANDWICH: Screening für Sanwich Programme Students (= Part-Time Degree in Education)
+    
+PT: Screening für Part-Time Degree Students (das sind ältere Studenten, die ein Abendstudium absolvieren)
+    
+(CEST: Common Entrance Screening Test) 
+ Obwohl hier aufgeführt, ist CEST **kein** eigenständiges Screeningverfahren. Es ist ein Test, der bei verschiedenen Screening-Verfahren zum Einsatz kommt. Das hat mich anfangs auch sehr verwirrt, auch dass oft nur von Screening gesprochen wird und automatisch ein Test gemeint ist. So gibt es z.B. ein Screening Venue. Ich habe aber gelernt, dass ein Screening auch ganz ohne Test auskommen kann.    
+
+**2. (Federal) Colleges of Education**
+
+PCE: (Post-) Polytechnics and Colleges of Education Matriculation Examination
+ Die PCE-Daten werden von JAMB übermittelt. Diese Studenten haben schon eine JAMB-Prüfung absolviert, die sich PCE nennt. Eigentlich müsste das Screening-Verfahren PPCE heißen, denn es ist das Pendent zu PUME. PCE-Applikanten streben als Abschluss das NCE =  Nigerian Certificate in Education an, welches drei Jahre dauert.
+    
+PRENCE: Preliminary-NCE = Screening für Vorstudium des Nigerian Certificate in Education
+ Ich habe nicht ganz verstanden, welche Studenten so ein einjähriges Vorstudium absolvieren müssen. Vermutlich ist die Schulvorbildung entscheident (s. http://www.nasarawastate.org/articles/56/1/-College-of-Education-Akwanga/Page1.html). Die Pre-NCE Absolventen machen dann automatisch mit dem NCE-Programm weiter. Im SRP starten diese Studenten im Level 000 und gehen dann automatisch in das Level 100 über, ein Trick, der sich bewährt hat.
+    
+Darüber hinaus bieten die FCEs auch noch Sandwich und Diploma-Programme an. Die Formulare der Universitäten können benutzt werden.
+
+Bei den Certificates gibt as das Attribut application_category. Dieses Attribut hilft bei der Gruppierung von Certificates, die den Antragstellern zur Auswahl gestellt werden. Hier werden die Screening-Typen DP, CT und PT noch einmal zusammengefasst, da sie anscheinend alle zu den gleichen Abschlüsse führen. Auch kommt bei all diesen Studenten der CEST zum Einsatz.
+
+Für den Worksflow müssen zwei Gruppen unterschieden werden. PUME, PUDE und PCE durchlaufen vorher das JAMB-Screening, d.h. JAMB liefert den Basisdatensatz, der inkl. der Passfotos über das Data Center importiert werden muss. Bei der Anmeldung im Portal müssen sich die Applicanten erst durch ihre JAMB Registration Number identifizieren. Zusätzlich geben sie noch eine Application PIN ein, mit der sie die Berechtigung gekauft haben, das Formular weiter auszufüllen zu dürfen. Alle anderen Applikanten geben nur die PIN ein. Ihr Datensatz wird in diesem Moment erzeugt. Als Registration Number wird dann (anstatt die JAMB RegNo) die Batch- und die Seriennummer der Scratch Card verwendet (Bauweise s.u.).
+
+Die Vorgehensweise und der Workflow ist wie folgt:
+
+- JAMB-Datensätze werden im Status 'created' importiert.
+
+- Applicants öffnen die entsprechende Eingabemaske für die PIN und ggf. der JAMB Registration Number. Der PIN Prefix entspricht dem obigen Screeining-Kürzel. Nach dem ersten Zugriff auf einen Datensatz ändert sich dessen Status nach 'edited'.
+
+- Das Formular öffnet sich, das Passbild wird hochgeladen (falls noch nicht vorhanden) und die Felder werden ausgefüllt. Etwas komplizierter sind die Eingabefelder für Zeugnisnoten. Das müsste man sich mal im alten SRP anschauen.Das Passbild wird in einem separaten Verzeichnis mit der Registration Number als Name abgespeichert. Nur jpg-Bilder mit einer begrenzten  Bytegröße werden erlaubt. 
+
+- Es gibt nur ein einziges Select-Feld, das sich Daten aus der Academic Section holt: das Auswahlfeld des gewünschten Study Course (=Certificate). Die Auswahl möglicher Certificates geschieht dynamisch. Das Feld application_category der Certificates dient als Filter.
+
+- Wenn alle Pflichtfelder ausgefüllt sind, kann der Datensatz vom Applicant submitted werden. Der Status des Datensatzes ändert sich entsprechend. Nach der Einreichung erscheint ein Drucksymbol zum Ausdrucken eines Slips. Der Slip öffnet sich in einem separaten Fenster und zeigt nur eine Auswahl der Felder aus dem Datensatz an. Der Slip dient zur Vorlage bei der Vorprüfung an der Universität.
+
+- Nach der Massenprüfung an der Universität werden die Ergebnisse der Prüfung importiert und der Datensatz entweder auf 'non admitted' oder 'admitted' gesetzt. In den admitted Datensätzen wird zudem der certificate code importiert, des Kurses für den die Applicants vorläufig zugelassen wurden. 
+
+- Ein paar Tage später werden die admitted Datensätze in das Portal kopiert (ca. 5000 bis 7000 Stück), d.h. in Studentenobjekte umgewandelt. Die Applicants-Tabelle wird nach einem Jahr geleert. Sehr bürokratisch ist die Verwaltung der Registration Number. CEST und Sandwich applicants bekommen eine eigene Registration Number verpasst (siehe WAeUPTool.py)::
+
+    if brain.screening_type in ('dp','pt','ct','cest','sandwich','sandwich2008') and brain.serial and brain.entry_session:
+        if brain.course1:
+            reg_no = "%s%s/%s" % (brain.course1[:3],brain.serial,brain.entry_session)
+        else:
+            reg_no = "%s%s/%s" % (brain.course_admitted[:3],brain.serial,brain.entry_session)
+    elif brain.screening_type in ('pume2','pde2'):  #second choice Uniben applicants
+        reg_no = brain.jamb_reg_no.upper()
+    else:
+        reg_no = brain.reg_no
+
+ Deswegen ist zu überlegen, ob wir nicht grundsätztlich zwei Registration Numbers verwalten: Einmal die portaleigene, die sich aus der Session, des Screening-Typen und einer fortlaufenden Nummer zusammensetzt und die den Datensatz identifiziert, und zum anderen die vorgegebene aus Nigeria, die auf dem Slip erscheint und bei der Datenverarbeitung keine weitere Rolle mehr spielt. Nur beim Import oder beim Transformieren der Daten muss aufgepasst werden, dass eine Registration Number  nicht zweimal vergeben werden darf, sie muss eindeutig sein. Studenten müssen hinterher über ihre Registration Number und Matriculation Number eindeutig identifizierbar sein. Das ist erfahrungsgemäß nicht immer der Fall. SIRP kann der Hochschule behilflich sein, Mehrfachzuordnungen zu identifizieren.
Index: main/waeup.sirp/trunk/docs/source/developerdocs/german/datacenter.rst
===================================================================
--- main/waeup.sirp/trunk/docs/source/developerdocs/german/datacenter.rst	(revision 5643)
+++ main/waeup.sirp/trunk/docs/source/developerdocs/german/datacenter.rst	(revision 5643)
@@ -0,0 +1,27 @@
+Data Center
+-----------
+
+Über das Data Center (ehemals Upload Section) werden alle hochgeladenen Dateien verwaltet und importiert. Folgende Eigenschaften haben sich im SRP bewährt:  
+
+- Speicherung des Datums und der User Id beim Hochladen einer Datei
+
+- Manuelle Auswahl des Importers anbieten
+
+ Unabhängig vom Header der hochgeladenen Datei sollten alle Importer zur Auswahl angeboten werden. Der ausgewählte Importer sollte gespeichert werden.
+
+- CSV-Headerprüfung durchführen
+
+ Der Header muss nach der Auswahl eines Importers mit dem Import-Schema verglichen werden. Bei fehlerhaftem Header sollte eine Fehlerbeschreibung und eine Online Editiermöglichkeit des File Headers angeboten werden (siehe SRP).
+
+- Import modes 'edit', 'create' and 'remove' etablieren
+
+ Jedem Datensatz sollte über den import_mode mitgeteilt werden, ob er vorhandene Datensätze überschreibt, ob er als neuer Datensatz hinzugefügt oder ob er per import die entsprechenden Objekte gelöscht und archiviert werden sollen. Im create und im edit mode sind unterschiedliche Felder required.
+
+- Import der Daten
+
+ Der Import bleibt zunächst dem Portaladministrator vorenthalten. Datum und User Id sollten beim Import abgespeichert werden.
+
+- Pending Data Files etablieren
+
+ Auf eine automatisierte Vorab-Datenprüfung kann zunächst verzichtet werden. Nicht importierbare Datensätze müssen mit einer Fehlermeldung in einer Pending Datei landen, die manuell nachimportiert werden können muss. 
+
Index: main/waeup.sirp/trunk/docs/source/developerdocs/german/index.rst
===================================================================
--- main/waeup.sirp/trunk/docs/source/developerdocs/german/index.rst	(revision 5643)
+++ main/waeup.sirp/trunk/docs/source/developerdocs/german/index.rst	(revision 5643)
@@ -0,0 +1,15 @@
+Instructions for Developers (German)
+************************************
+
+by Henrik Bettermann
+
+
+This German introduction describes the properties and workflows of the existing Student Registration Portal (SRP) which has been developed by Joachim Schmitz (†) and Henrik Bettermann in close cooperation with the Central Registration and Processing Unit (CRPU) of the University of Benin in Nigeria. The introduction is has been written for Uli Fouquet, the senior software engineer of waeup.sirp.
+
+Diese deutschsprachige Anleitung beschreibt im Wesentlichen die Eigenschaften und Abläufe des existierenden Student Registration Portals (SRP), welches von Joachim Schmitz (†) und Henrik Bettermann in enger Zusammenarbeit mit der Central Registration and Processing Unit (CRPU) der University of Benin in Nigeria entwickelt wurde. Die Anleitung wurde in erster Linie für Uli Fouquet geschrieben, den Chefentwickler von waeup.sirp.
+
+.. toctree::
+
+   datacenter
+   accesscodes
+   application
Index: main/waeup.sirp/trunk/docs/source/developerdocs/index.rst
===================================================================
--- main/waeup.sirp/trunk/docs/source/developerdocs/index.rst	(revision 5350)
+++ main/waeup.sirp/trunk/docs/source/developerdocs/index.rst	(revision 5643)
@@ -5,3 +5,3 @@
 
    api/index
-
+   german/index
