Changeset 13040


Ignore:
Timestamp:
10 Jun 2015, 07:20:39 (10 years ago)
Author:
Henrik Bettermann
Message:

More docs.

Location:
main/waeup.kofa/trunk
Files:
3 edited

Legend:

Unmodified
Added
Removed
  • main/waeup.kofa/trunk/docs/source/userdocs/students/browser.rst

    r13031 r13040  
    7676.. _transferring_students:
    7777
    78 Transferring Students
    79 =====================
     78Student Transfer
     79================
    8080
    81 Transferring a student means switching the study course of a student.
     81Transferring a student means enabling the student to study another programme.
    8282
    83 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.
     83The 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.
    8484
    8585Kofa 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.
    8686
    87 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.
     87After 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.
    8888
    8989The 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.
     
    9494Sometimes 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``.
    9595
    96 Reverting a Transfer
    97 --------------------
     96Reverting Previous Transfers
     97----------------------------
    9898
    9999Previous 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.
    100100
    101 .. _adding_payment_tickets:
     101.. _payment_tickets:
    102102
    103 Adding Payment Tickets
    104 ======================
     103Payment Tickets
     104===============
    105105
    106 Adding Bed Tickets
    107 ==================
     106The `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.
     107
     108There 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.
     109
     110Current Session Payment Tickets
     111-------------------------------
     112
     113Current 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`).
     114
     115.. note::
     116
     117  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.
     118
     119Previous Session Payment Tickets
     120--------------------------------
     121
     122Previous 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.
     123
     124Balance Payment Tickets
     125-----------------------
     126
     127Balance 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.
     128
     129Activation Codes
     130----------------
     131
     132Bed Tickets
     133===========
    108134
    109135Bed Relocation
     136--------------
     137
     138Course Tickets
    110139==============
    111140
    112 Adding Course Tickets
    113 =====================
    114 
    115 Register Courses
    116 ================
    117 
    118 Using Activation Codes
    119 ======================
     141Course Registration
     142===================
    120143
    121144Requesting a Password
  • main/waeup.kofa/trunk/src/waeup/kofa/students/browser.py

    r13031 r13040  
    17541754
    17551755class PreviousPaymentAddFormPage(KofaAddFormPage):
    1756     """ Page to add an online payment ticket for previous sessions
     1756    """ Page to add an online payment ticket for previous sessions.
    17571757    """
    17581758    grok.context(IStudentPaymentsContainer)
     
    17921792
    17931793class BalancePaymentAddFormPage(KofaAddFormPage):
    1794     """ Page to add an online payment ticket for balance sessions
     1794    """ Page to add an online payment which can balance s previous session
     1795    payment.
    17951796    """
    17961797    grok.context(IStudentPaymentsContainer)
  • main/waeup.kofa/trunk/src/waeup/kofa/students/utils.py

    r13031 r13040  
    376376    def setPaymentDetails(self, category, student,
    377377            previous_session, previous_level):
    378         """Create Payment object and set the payment data of a student for
    379         the payment category specified.
    380 
     378        """Create a payment ticket object and set the payment data of a
     379        student for the payment category specified.
    381380        """
    382381        p_item = u''
Note: See TracChangeset for help on using the changeset viewer.