Changeset 13040

Timestamp:

10 Jun 2015, 07:20:39 (9 years ago)

Author:

Henrik Bettermann

Message:

More docs.

Location:

main/waeup.kofa/trunk

Files:

• docs/source/userdocs/students/browser.rst (modified) (2 diffs)
• src/waeup/kofa/students/browser.py (modified) (2 diffs)
• src/waeup/kofa/students/utils.py (modified) (1 diff)

main/waeup.kofa/trunk/docs/source/userdocs/students/browser.rst

@@ -76 +76 @@
 .. _transferring_students:
 
-Transferring Students
-=====================
+Student Transfer
+================
 
-Transferring a student means switching the study course of a student.
+Transferring a student means enabling the student to study another programme.
 
-The simple but dirty way is to select another certificate and adjust study course attributes accordingly. Existing study levels can be either removed or, in case registered courses can be credited, left as they are. This simple way is tedious and also dangerous, because the changes are not tracable. Only the logfile does tell us, that an officer has edited the student's data. The data of the previous study course are not backed up. They are lost.
+The simple but dirty way is to select another certificate and adjust study course attributes accordingly. Existing study levels can be either removed or, in case registered courses can be credited, left as they are. This simple way is tedious and also dangerous, because changes are not tracable. Only the logfile can tell us, that an officer has edited the student's data. The data of the previous study course are not backed up. They are lost.
 
 Kofa provides a more adequate, cleaner and tracable way of transferring students. It can make a backup of the entire study course container and create a new and empty container for the new study programme with only one click or even by batch processing.
 
-After clicking the 'Transfer student' button the `StudentTransferFormPage` opens and asks for the new certificate, current session, current level and current verdict. After submitting this form, the student transfer method checks if the old study course is complete and ready for transfer. It also checks if the number of possible transfers is not exceeded. Kofa allows only two (2) transfers! Finally the copying process is started and history and logfile messages are added.
+After clicking the 'Transfer student' button the `StudentTransferFormPage` opens and asks for the new certificate, current session, current level and current verdict. After submitting this form, the student transfer method checks if the old study course is complete and ready for transfer. It also checks if the number of possible transfers is not exceeded. Kofa allows two (2) transfers! Finally the copying process is started and history and logfile messages are added.
 
 The old study course container(s) can still be accessed via links on the current study course display page. But, they can neither be edited, removed, exported or reimported.
@@ -94 +94 @@
 Sometimes students of an entire study programme have to be transferred to another programme. This can be done with the :py:class:`StudentStudyCourseProcessor<waeup.kofa.students.batching.StudentStudyCourseProcessor>`. The import file must contain the following columns: `student_id` (or any other locator), `certificate`, `current_session`, `current_level` and `entry_mode`. Do not import `entry_session`. A transfer is automatically initialized if the `entry_mode` value is ``transfer``.
 
-Reverting a Transfer
---------------------
+Reverting Previous Transfers
+----------------------------
 
 Previous transfers can be reverted by opening the previous study course and clicking the 'Reactivate this study course (revert previous transfer)' button. This is a complete rollback of the last transfer. The current study mode will be irrevocably deleted and replaced by the previous study course. The second last study course will become the previous study course.
 
-.. _adding_payment_tickets:
+.. _payment_tickets:
 
-Adding Payment Tickets
-======================
+Payment Tickets
+===============
 
-Adding Bed Tickets
-==================
+The `PaymentsManageFormPage` is used by both students and students officers. The page tabulates existing payment tickets and allows to add or remove tickets. Officers can remove all payment tickets, students only those without a response code (`r_code`). Attention: Students can remove tickets without response code even if they have been marked paid.
+
+There are three different add form pages to add `StudentOnlinePayment` instances (= payment tickets). They all create objects of the same type, only their attributes are set differently.
+
+Current Session Payment Tickets
+-------------------------------
+
+Current session payments are the regular payments which have to be made in each session to proceed to the next registration step. The add form provides a select box of available payment categories (`p_category`). After submitting the form, Kofa determines the total amount and sets attributes like payment item (`p_item`), payment session (`p_session`) and payment level (`p_level`) automatically. The Boolean `p_current` attribute is set ``True``. The creation datetime is stored in the `creation_date` attribute and is also used to construct the unique payment id (`p_id`).
+
+.. note::
+
+  Kofa always determines the total amount, including any fees charged by the school and its service providers. This is the amount which is authorized by students and finally submitted to one of the payment gateways. No fees can be added once the payment ticket is created. Payment tickets do not store any information about charged fees.
+
+Previous Session Payment Tickets
+--------------------------------
+
+Previous session payments are additional payments which do not induce further actions in Kofa. Their sole purpose is to enable students to pay for services in previous sessions which they missed to pay. The add form for previous session payments allows the student to select the payment category, session and level by him/herself.
+
+Balance Payment Tickets
+-----------------------
+
+Balance payments have been introduced to correct previously made payments. In some cases students select the wrong payment category or other things may have happened which led students pay less than expected. This can be balanced by paying a differential amount. Therefore, the add form for balance payments allows to freely choose the amount to be paid. It also asks for the category, the session and the level the payment is meant for. Like previous session paymnets, balance payments do not induce further actions in Kofa. Both can be omitted in customized versions of Kofa.
+
+Activation Codes
+----------------
+
+Bed Tickets
+===========
 
 Bed Relocation
+--------------
+
+Course Tickets
 ==============
 
-Adding Course Tickets
-=====================
-
-Register Courses
-================
-
-Using Activation Codes
-======================
+Course Registration
+===================
 
 Requesting a Password

main/waeup.kofa/trunk/src/waeup/kofa/students/browser.py

@@ -1754 +1754 @@
 
 class PreviousPaymentAddFormPage(KofaAddFormPage):
-    """ Page to add an online payment ticket for previous sessions
+    """ Page to add an online payment ticket for previous sessions.
     """
     grok.context(IStudentPaymentsContainer)
@@ -1792 +1792 @@
 
 class BalancePaymentAddFormPage(KofaAddFormPage):
-    """ Page to add an online payment ticket for balance sessions
+    """ Page to add an online payment which can balance s previous session
+    payment.
     """
     grok.context(IStudentPaymentsContainer)

main/waeup.kofa/trunk/src/waeup/kofa/students/utils.py

@@ -376 +376 @@
     def setPaymentDetails(self, category, student,
             previous_session, previous_level):
-        """Create Payment object and set the payment data of a student for
-        the payment category specified.
-
+        """Create a payment ticket object and set the payment data of a
+        student for the payment category specified.
         """
         p_item = u''