Consumption Report {FSAO1-13}

This report is dependent on the setup in {BATCH-7}. For System 'FIN' and Function 'CONSUM', a path where the output should reside must be specified. In {FCSM-1b2}, journals will be created if the SOD 'RA- Apply Student Income Recognition' is set to (Y)es.

When a student registers, revenue is recognized in the month the registration is processed. This option allows for income to be recognized over the service period of costs incurred. That is, enrolment revenue is calculated per service period month and evenly distributed over the duration of the service period (service period = enrolment block). 

Monthly Income Recognition = Amount charged / Service Period Months

If a student cancels, the effect is in the cancellation month.
If the start date of the service period is a future date, the transaction is ignored.
If the end date of the service period is in a previous year, the transaction is ignored if not cancelled. If cancelled and the cancellation date in the current year, the transaction is reported on.

If a student completes early, outstanding earnings is realized in the month when the qualification / subject is completed (early completion = pass before end date of registration record).

If an enrolment period runs over two months, earnings can either be reflected in the end month or over two months.

If the enrolment period runs over more than one year, the earnings are subsequently reflected in the different years. 

This program cannot be run more than once per cycle / month.

Some institutions register students for courses where the start and end date of the registration block is not a true reflection of the actual start and end date of the service period. The actual service period is mostly a much shorter time than the registration block (typically skills courses). All registration, cancellation and programs where registration detail can be changed have start and end registration dates that will be a true reflection of the service period on the qualification registration table and the subject registration table. These dates will default from the registration block {GOPS-1} but can be updated by the user during the registration if indicated as updatable on the qualification / subject definition {SACAD-13 and SACAD-14 respectively}. The user can check start and end registration dates, and update if necessary during registration. This program will use the actual start and end dates as recorded against the registration record to determine the service period. 

For residence registrations, the date in and date out (end date of residence block if date out is null) is used. The date out is applied according to the reason code:

• If the reason code is ‘D - Daily billing’, the date out can be entered. This will not be treated as a cancellation or an early completion. The period between the date in and date out represents the period over which this transaction must be consumed.
• If the reason code is ‘E’ or ‘X’ (end of block) it implies that the end date of the registration period has changed.  This will not be treated as a cancellation or early completion. The period between the date in and date out represents the period over which this transaction must be consumed.
• If reason code is ‘T’, ‘S’ or ‘A’ (transfer) it will be considered that the end date of the registration has been changed. This will not be treated as a cancellation or early completion. The period between the date in and date out represents the period over which this transaction must be consumed.
• If reason code ‘V’, ‘H’ or ‘C’, it is considered as a cancellation. The date out will be selected as the cancellation date for the record.

Ledger year end month:
If the year end month of the primary ledger is not 12, the program will convert the financial year and cycle to the equivalent actual year and cycle to use in calculations. The ‘up to year’ and ‘up to cycle’ input parameters are also converted to the equivalent actual year and cycle to use in calculations.

Early completion:
If a student completes early, outstanding earnings are realized in the month when the subject / qualification is completed. Early completion is established as follows:
Event 07 Subject: if the subject has a pass result recorded before the end registration date.
Event 05 Qualification: if all not cancelled and not exempted subjects for the qualification are completed.
Event 13 Residence: no early completion will be applicable for event ‘13’.

Cancellation:
Cancellations are handled in the financial year and cycle of the cancellation transaction.
A residence registration record will be seen as cancelled where it has a date out and the reason code is a ‘C’,’V’ or ’H’.

Enrollment over 2 months
If an enrolment period runs over two months, the program will reflect the income according to the system operational definition ‘RC – Latest Reg. Day of Month for Student Income Recognition over 2 Months‘ for subsystem SD on {FCSM-1}.
If the day of the start registration date is less than the day recorded against the SOD, revenue is reflected over the 2 month period.
If the day of the start registration date is after or equal to the day recorded against the SOD, income is reflected in the 2nd month.  

Enrollment over multiple years
If the enrolment period runs over more than one year, the earnings are subsequently reflected in the different years

{FSAO-29} must be completed to define an income GLA for every income in advance GLA. The look up process to find the corresponding income GLA for every income in advance GLA, is as follow:

• Each transaction that needs to be analyzed by the income recognition calculation will contain an income in advance GLA. This will be the credit GLA if it is a debit transaction or the debit GLA if it is a credit transaction.
• The program will firstly try to find a record on the look up table where both the income in advance cost centre and account is not null, and corresponds to the income in advance cost centre and account of the transaction selected. That is, the program will try to find a record where the income in advance cost centre and the income in advance account in the look up table is equal to the income in advance GLA of the transaction.
• If no exact match is found, the program income in advance account on the look up table. Two types of records can be found:
• The income cost centre defined can be not null and will be used as the income cost centre.
• The income cost centre defined can be null. In this case, the income in advance cost centre of the transaction will be used as the income cost centre.
• If no matching record is found, processing will be stopped and an error message printed on the report.
  

Contra and Create General Ledger Journals:
If the SOD ‘RB’ for subsystem 'SD' on {FCSM-1} indicates that journals should be generated by this program, the previous months’ journal will be reversed in the current month and a new journal generated.
Journals will only be created when the student debtor subsystem is posted to the general ledger. If the report is requested from the menu, a trial run will be enforced.
Contra GL journals:
The GL journals created with the previous run of this report will be cancelled by creating a contra transaction for each journal created.
If these journals were created for the previous financial year, contra journals will not be created. Journals for the previous year may not be cancelled.
Generate GL Journals:
The program uses the year and cycle of SD subsystem – NOTE: THIS ONLY WORKS IF SD SUBSYSTEM IS POSTED CORRECTLY.
A GL journal will be created for each income in advance GLA, irrespective of the income GLA.  If more than one income in advance GLA maps to the same income GLA, a separate GL journal will still be created for each income in advance GLA. Therefore, each total line printed for the income in advance GLA will map to one GL Journal.
If the user selected to sort per faculty and department, a GL journal must be created per GLA within the faculty and department, therefore, if the same GLA is linked to different faculties and departments, different GL journals will be created for each faculty / department combination.
All journals created will be generated with the same journal number.

• Procedures:
• None