Post Transactions To Ledger (FGLO-28) / (FGLP)

Transactions in the subsystems are available to the General Ledger for reporting and query purposes under the following conditions:

All transactions with a cycle smaller than or equal to that of the GL; All transactions with a cycle greater than that of the GL, will only be available as "Future Transactions".

Although transactions are available to the GL for query- and reporting purposes, they may actually not yet have been "flagged" as transactions belonging to the GL. This can be explained by using the following extract from the Detail Cost centre Cost report, menu option {FGLOR1-8}:

Two columns have been highlighted, namely, Ss - Sub-system and Or Ss - Original Sub-system. The first two transactions indicate that the original sub-system for these transactions (Or Ss) is Payroll (PR) and Counter System (CT) and that these transactions are posted or 'belong' to the sub-system (Ss) General Ledger (GL) as well.

The third transaction indicate that the original sub-system for these transactions (Or Ss) is Procurement Management System (PM) and that this transaction is not posted or do not 'belong' to the sub-system General ledger (GL) but that they still only 'belong' to sub-system (Ss) (PM).

Thus, to summarise the above, should the sub-system (Ss) be any other financial sub-system other the GL, it indicates that these transactions still belong to the original sub-system (Or Ss) and therefore, these transactions are yet to be posted to the Ledger.

The only exception to this rule is commitments generated by the Procurement management system (PM). Orders etc, commit funds only and thus by definition, do not constitute actual transactions. Commitments only become actual transactions when the 'payment process' honours the commitment.

Therefore, to ensure that transactions not yet posted to the Ledger are posted, the options hereunder need to be executed on a regular basis. Postings to the Ledger can be done on a daily basis but institutions can decide on how often the postings should be done. In order to have 'up-to-date' information reflected in the Ledger, it is recommended that postings be done on a daily basis.

Whatever the decision is on how often the postings are to be done, it is important that ALL financial systems are posted at the same time. The only exceptions are the Cash Book and Payroll sub-systems. The Payroll financial cycle, generally, does not coincide with the financial cycles of the other financial sub-systems. The major reason being that salaries are to be paid towards the end of a month and thus, the payroll process is completed during the course of the month. Before the process for the following month may begin, the current month must be closed and posted to the general ledger and the next financial cycle must be opened.

Generally, the Payroll's next financial cycle opens during the course of the other financial systems financial cycles.

Before the Cash Book sub-system's cycle can be incremented to the next cycle, all transactions that appear on bank statements applicable to the specific cycle need to be processed. These transactions are transactions such as bank charges, direct deposits etc.

When the user enters this option, the user will be presented with a menu listing the financial subsystems. These options are as follows:

Menu Selection	Prompt Text ^{* an item between square brackets [ ] is the default answer}
	1. Counter Subsystem {FGLP-1}
	2. Student Debtors {FGLP-2}
	3. Procurement Management Subsystem {FGLP-3}
	4. Accounts Receivable Subsystem {FGLP-4}
	5. Payroll Subsystem {FGLP-5}
	6. Long Term Loans Subsystem {FGLP-6}
	7. Cash Book Subsystem {FGLP-7}
	8. Meal Subsystem {FGLP-8}
	9. Research Subsystem {FGLP-21}
	10. All Subsystems {FGLP-28} When menu options {FGLP-1} to {FGLP-21} are executed, users will be confronted with the following prompt: Is This The Last Posting For This Period/Cycle, If So The Cycle Will Be Incremented On Completion Of This Posting - Y/N :

Before answering this prompt, users must understand what is implied when supplying a (Y)es or (N)o answer. As already mentioned, postings can occur on a daily basis. Furthermore, postings of sub-systems can be done on a de-centralised or centralised basis, with the exception of the Cash Book and Payroll sub-systems. That is, either one user is delegated the responsibility of executing the postings or the responsibility is delegated to specific users of each financial sub-system, who are responsible for the specific sub-system. Once again, the decision of whether postings are executed in a centralised or de-centralised manner is entirely up to the institution. To ensure that postings of financial sub-systems take place at the same time, the centralised option is the better option. However, should the decision be on a de-centralised basis, the responsible user of each financial sub-system must ensure that postings take place at the same time. The reason for ensuring that postings o f all financial sub-systems take place at the same time is to ensure that only transactions applicable for a specific cycle are posted to that cycle and thus, not including transactions applicable to the next cycle. A second and important reason is to facilitate the reconciliation process.

Returning to the prompt mentioned above, when (N)o is supplied, it is implied that all transactions processed which are not yet posted, must now be posted but the cycle must not be incremented to the next financial cycle as this is not the final posting for this financial cycle. Thus, postings can be done on a daily basis without incrementing the cycle. This is applicable to all financial sub-systems.

When (Y)es is supplied, it is implied that all transactions processed which are not yet posted, must now be posted and the cycle must be incremented to the next financial cycle as this is the final posting for this cycle. This is not applicable to the Procurement Management sub-system. The financial cycle for this sub-system can only be incremented by the Cycle End Close program on menu option {FPMM-10}. When the answer provided is (Y)es for the Procurement Management System, the program will give the message :

At Period End - Cycle May Not Be Incremented Here: The Procurement Management Subsystem Period End Procedure Must Be Performed.

Users must then execute menu option {FPMM-10}. Users must return to this menu option to do the postings but answer (N)o to the question.

Thus, during the course of the financial cycle, users can execute postings on a daily basis without incrementing the cycle by supplying (N)o to the question and then to increment the cycle to the next financial cycle, (Y)es must be provided with the exception of the Procurement Management System.

At financial year-end, that is, when the financial cycles of the sub-systems are in cycle 12, the process is exactly the same as described above, except for the Procurement Management and Accounts Receivable sub-systems. These two systems have year-end programs, which must be executed in order for the cycles to increment to the next financial year.

The year-end programs for the Procurement Management and Accounts Receivable sub-systems are on menu options {FPMM-11} and {FARM-2} respectively. After the respective year-end programs have been executed, users must return this menu to do the postings but answer (N)o to the question.

Some additional comments are in order concerning the posting of PR transactions. Program {FGLP-5} will post all salary transactions that have not yet been posted, as well as the reversing late rolled-back transactions which had already been posted before rollback, with relevant control totals.

Note also that the program to Generate Payments {FPRN-5} in the Payroll system for every salary calculation, also creates a number of GL- and Cash Book transactions for those events which have bearing on salary calculations. This process happens as follows:

Before the first generation of payments is attempted, users must link five Transaction Types (TT's) {FCSO-7}, to the five events, which have bearing on salary calculations. Thereby, allowing the generation program to take the actions as indicated below (note that whereas code 993 must be used as indicated, the other codes are the user's choice and the codes used here serve merely as examples):

TT 994: linked to event RS = PR - Salary Calculation
Credit GLA must be supplied Debits will be to normal expense GLA's Credits will be deductions, and the net credit will be to Salary Control GLA

TT 993: linked to event RQ = PR - Cheque Payments
Debit and Credit GLA's must be supplied. Debit will be to Salary Control GLA Credit will be to Bank GLA

* When payments are generated, the necessary inserts are done to the two payment files. The generation program need therefore create no Cash Book journal.

TT 995: linked to event RC = PR - Cash Payments
Debit and Credit GLA's must be supplied. Debit will be to Salary Control GLA Credit will be to Cash Control GLA

* The user has two options regarding cash payments:

1.the cash withdrawal can be made directly from the bank, with an instruction that the amount be debited directly to the bank
account; in this case the user must pass a Cash Book journal to credit Bank and debit Cash Control

2.Alternatively, a covering cheque could be sent with the cash request, in which case the CTS will have created the necessary
transactions.

* Since the method chosen by the user is not known, the generation program cannot create a Cash Book Journal.

TT 996: linked to event RD = PR - Bank Transfers
Debit and Credit GLA's must be supplied Debit will be to Salary Control GLA Credit will be to Transfer Control GLA
* The net amount will be directly debited and will appear on the bank statement; the generation program will create a Cash Book journal to debit Transfer Control and credit Bank.

TT 997: linked to event RA = PR - ACB Payments
Debit and Credit GLA's must be supplied Debit will be to Salary Control GLA Credit will be to ACB Control GLA

* The net amount will be directly debited and will appear on the bank statement; the generation program will create a Cash Book journal to debit ACB Control and credit Bank.
* The same TT is used for Bond Payments via ACB, and will result in a Cash Book journal to debit Bond Control and credit Bank.

It is important that the above TT's are created before the first generation of payments is attempted, since the generation program will verify that TT's have been linked to the events as above. If not, the program will terminate with the message: "TT's are not linked to events or TT's incorrectly specified". In this case payments will not be generated, nor will a "Q" record be created.

A control report provides subtotals per TT, allowing the following comparisons:

- the total of TT's 993, 995, 996 and 997 will equal the amount posted to the Salary Control GLA under TT 994 for the current pay cycle; - the payments issued via CTS will contra the amounts posted to the Cash Control account; - the Cash Book journals will contra the amounts posted to the Transfer- and ACB Control accounts.

Hereunder is an example of the report that the posting programs will produce.

Sort Order	Per	Comments

System Select
	No special system selection

Date	System Version	By Whom	Job	Description
29-May-2008	v01.0.0.0	Charlene van der Schyff	t145484	New manual format.
27-May-2009	v01.0.0.1	Charlene van der Schyff	t158348	Edit language but need to split manual into all FGLP.
14-Jul-2009	v01.0.0.2	Charlene van der Schyff	t160159	Remove Image frame, other menu options FGLP.
04-Aug-2009	v01.0.0.3	Charlene van der Schyff	t160160	Just to srelease insert task no.
11-May-2012	v02.0.0.0	Frans Pelser	T182888	Change the word Cheque to Payment