Procurement Management PMIS {FRM-7} 

 General Information

This is the User Manual for the operation and maintenance of the ITS Tertiary Software Procurement Management Information Subsystem. The abbreviation for the Subsystem is PM. It is one of a series of user and technical manuals that is available for the ITS Tertiary Software systems.

• Code Structures Menus
• Maintenance Menus
• Operational Menus
  
• Requests
• Purchases 
• Deliveries
• Creditors
• Stock
• Correspondence
  

Code Structure {FPM- 3}

• Codes used in the creditor and item definitions
• Creditor Categories
• Commodities
• Creditor Types
• Account Types
• Payment Terms and Methods. 
• Used on Creditors and Documents
• Note Classification Codes and Action Codes
• Used in PM documents.
• Change/Cancellation/Complete/Retain Reasons Codes.  
• Used by store and general items, 
• Issue and Order Units.
• Kind Codes to enhance the Item descriptions.
  

Maintenance {FPM-2}

    Maintenance menu options are used to define and maintain the entities in the PM system for example creditor biographical information, store definition, item definition etc.

• Creditor's and Creditor Alias master definitions and maintenance..
• Stores, and Sections within Stores definition..
• General and Store Item Definitions including  detail Creditor Unit Cost with prioritisation plus enhanced Item Description using Kind Codes.
• Packages Item Definition combining Store Items that are not available as a unit from the Suppliers.
• Accumulation and deletion of  history records.  This action cannot be performed for periods less than 14 months.
• Year-end close for primary and secondary ledgers including 
• Accruals on GRV or Order level,
• Carry forward Budgets, Standing Orders, Commitments and Creditor Balances
• Update Creditor history record 
• Incrementing the fincancial year and cycle of the subsystem..
  

Operational
    Requests {FPMO-1}

• This module provides for requisition creation, buyer quotation maintenance, overriding of funds, requisition approval, requisition cancellation and  requisition interrogation (query)  of  back office  Requisitions.
• The creation, overriding of funds and approval of iEnabler Requisitions  are performed in the web module however buyer quotation maintenace may be performed in both the back office or in the iEnabler  for these documents.
• Commitments on back office Request is optional, and is based on rules as defined in the System Operational Definitions  BD - REQ Budget Control. Budget control on iEnabler requisitions are  mandatotory.
• The Commitment of a Request will be cancelled as soon as the Request is copied to an Order, Stock Issue or Payments  (for Payment Requests), by means of a reference copy. If copied to a Purchase Order the commitment will be carried over to the order.
• The use of the Request facility is optional, and users may prefer to process orders directly.  If so preferred, required items may be entered, leading to the printing of Order Forms and updating of commitments.
• Requests can be used to request Stock Items from Stores, Items to be Purchased or Counter System Payments.
• The back office requisition maintenance application alows from the entering of a simple request as well as a more complex request through numerous drill downs and pop-up screens.  
• Electronic Requisitions can be routed for authorization and approval.
• Buyer Requisition Scheduling - requisitions can be allocated to specific buyers by the department head..
• Buyer Quotation Maintenance - quotation detail can be recorded on the system.

• This module provides for the creation and printing of Orders and updating of Commitments.
• Budget control can be done on Cost Centre, Account or Account Category level.
• Budget and Commitment carried forward can be done for the Secondary Ledgers during the cycle end and for the Primary Ledger during year end of the Subsystem.
• Audit, Management and Cost reports are produced.
• Override Insufficient Funds  functionality with routing notification is available..
• Electronic Order authorisation with routing notification is available.

• This module provides for the creation and printing of  GRVs, Supplier Returns.
• Generating Accrual can be done for the Secondary Ledgers during the cycle end and for the Primary Ledger during year end of the Subsystem.
• Audit, Management and Cost reports are produced.
• Electronic GRV authorisation with routing notification is available.

• The stock system supports the Average Cost Price method to calculate stock values.
• Stock Orders can be placed and the receipt of goods are recorded.
• The stock system supports the accounting entries and physical movement of store items i.e. transactions are generated by the system and posted to the relevant accounts.
• The stock system supports Returns from Departments to the Store, and Return of deficient stock items to Suppliers.
• Items can be sold for cash or on credit to students and debtors, in which case the amounts are automatically debited against the student or debtor account.
• Functionality with  security features  is available to adjust Stock Levels and the Stock Values.
• The system can calculate Economic Order Quantities and related statistics on the basis of actual consumption.
• Item Units
• The Store distinguishes between "Order Units" and "Issue Units", which must be defined for each stock item. Stock on hand is stored as "Actual Units". 
• The actual record keeping in the system will be in terms of individual stock items. 
• The stock level in the system, and adjustments to that, will be in terms of individual items. 
• The initial selection of appropriate Issue and Order Units should be handled with care, as an inappropriate selection will result in a clumsy system.
•  The following are some possibilities in this regard:  

• Item	Order Unit Description	Order Unit Quantity	Issue Unit Description	Issue Unit Quantity
  A4 Paper	Boxes of 5 reams	5	Reams	1
  Cement	50 Kg Bag	1	Bag	1
  Paper Clips	Carton of 100 boxes	100	Box 1000 clips	1
  HB pencils	Cartons of 1000 pencils	1000	Box of 10 pencils	10




• Items that are returned, either from department to store or from store to supplier, are always handled as single items, i.e. partial issue units will be accepted as returns by the store, and partial order units can be returned to a supplier. 
• In terms of the above structure, individual reams of paper can be returned, but half a bag of cement cannot be returned. Only a box of paper clips rather than an individual paper clip can be returned, but a single pencil can be returned. 
• The units that apply to each aspect of the system are clearly set out on the screens when the transactions are entered: - On the screens that are used for entering requests and issues, all quantities will be displayed in terms of Issue Units.
  
• On the screens that are used for Orders and the of Goods Receiving, quantities will be displayed in terms of Order Units.
• The screens that are used for stock returns or adjustments to stock levels will, on the other hand, display the number of Actual Units in the system.

• Average Cost Pricing 
• The system calculates the cost of items that are issued in terms of the "Average Cost Pricing"method.  
• Within the system the total cost of the stock in respect of each item is continuously maintained.
• The issue price of an item is then calculated by dividing the number of items into this total cost.
• The calculations done by the system can be illustrated by the following example based on an Order Unit and Issue Unit of 1: 

• Note that Issue Prices are rounded off to the nearest cent. If items of very low value (say less than 5 cents each) are issued, the rounding errors can, in the long run, become significant. It may be better to issue such items in units of 5 and 10 only. 

• This module supports the  processing of invoices, credit notes and adjustments in respect of Creditor's  with or without orders.. 
• Invoices can be allocated to multiple GL accounts.  
• Commitments are adjusted when invoices are processed or when budget control is done on invoices not linked to orders.
• Payments to creditors can be generated as cheques, ACB, transfers and/or journals and in the interim, cheques can be made out on the Counter Subsystem. 
• Cheques can be generated for all outstanding invoices, or payments can be made for invoice items, which qualify on the basis of the most "effective payment date" only.
• Control totals are kept and audit reports are available.
• Electronic Invoice authorization is available.

• The PM subsystem use the values defined in the Financial Code Structure Subsystem, these include

•     System Operation Definitions - Rules set up in the system which the institution can set to apply operational policies. These rules are defined by ITS with default values
•  Subsystem Financial Year and Cycle
• Indicates the current financial period in which transaction in the subsystem are recorded.
• The approval rules linked to the subsystem
• The retain rules for balances and transactions (How long records must be kept on the system).
• General Ledger Allocations - Financial managers are able to control the ledger allocation of transactions originating from the subsystem 
• Transaction Types for the events of the Subsystem - The subsystem is totally event driven which means that all actions, i.e. capturing an invoice, that results in financial transactions in the system  are linked to a code (event). When a program executes the program attempts to find a transaction type for the event which is used to process financial transaction. 
• Foreign Currency Codes and Rates - Foreign currency definition and exchange rate maintenance 
• Document Types - Documents to be used in the PM system have been pre-fined by ITS i.e. Orders, GRV's Invoices
• Auto Generated Numbers -  Documents number are automatically allocated to a documents in some application
• User Restrictions / Access Control - the area in which a user may operate in the subsystem may be controlled through  access and user restrictions
• Account Type Definition  
  

• The update or view access to menu options for the subsystem is done in the General Support System, and is described in detail in General System User Manual {GMAIN-3}.
• Address Maintenance.
• Printers Maintenance and Dedicated to Functions for automatic printing.
• Routing.

• Use the SQL Generator in the Technical Subsystem to generate additional reports 

• Views and Discoverer.

• All cheques and other payments are numbered when generated, and the value of this control file can be queried and updated in the Counter Subsystem {option FCTM-1}.  
• Creditor Payments from {FCTO-6} link the payment to the Creditor Account and taking settlement discount is optional.
• Any bank statement transaction for a Creditor, not yet on the Creditor Account, can be processed in the Cash Book.
  

• All transactions in this subsystem are validated against the GL-Allocations. Such transactions can be queried on the General Ledger transaction file, and are logically posted to the GL via a separate menu option in the GL Subsystem (option {FGLP-3}). The GL-Allocations used within this subsystem can also be queried. 

• Also interfaces with the Student Accounts- and Accounts Receivable Subsystems (since credit sales to currently registered students and to Debtors are debited directly to their accounts via direct purchases or stock issues)

• The Student Distance Education and Health Management Subsystems can issue prescribed Items from the stock. This is either free or not.

• Debtors debit (Accounts Receivable Subsystem) balance can be deducted before payment to the Creditor if it is the same person or company.

• Asset Inventory, Costing and Central Reservation Subsystems by means of request, orders and/or issues.

• Linking the supporting documents to the SLGL-transactions.
• Convert supporting document values to debits and credits.
• Accumulate data for phase 3.
  

• The generation of cheques in which the system will:
  

• Issue cheque on the CT Subsystem with the "Creditor Type" field set to (C) and the "Post to GL" indicator on the transaction type set to (Y)es.  On entering the creditor's code, the system will display the creditor information and:
  

• In some cases the user will require payments to creditors for whom master records have not yet been created.  He/she will then issue cheques on the CT Subsystem with the "Creditor Type" set to (O) and creditor's code to "NULL".  The same Transaction Type will be used, and the system will:
  

• Lastly, some users may use a manual system of making out cheques to creditors.  To update these cheques to the creditor and the General Ledger, the user can:
  

• This report reflects totals per User per transaction type of the transactions that have been entered into this subsystem for a specified period.
• There are two selection options available, namely:
- For a single user - the system will list totals for all transaction types used by the specified user;
- For all users - the report will include ALL transactions that were updated into this subsystem, including transactions, which   were created on the CT Subsystem.  Only transactions with a "C" as (C)reditor Type will update this subsystem.
• The report is very important to institutions where a number of people are working on this subsystem, even more so when they are geographically separated.
  

• The SLGL-transactions of the Creditors.
• This report reflects summary or detail of transaction types for a specified range and for a specified period.
• Subtotals per type for debits and credits are calculated.
• The report can be requested in Detail or in Summary
• Transactions which were created in the PM Subsystem with a Creditor Type = "C", will also be listed.
  

• The SL-transactions of the Creditors.
• This report gives details of selected creditors with balances and is sorted per Account type, payment method and currency.
• The report reflects the local currency value and the foreign currency value for foreign creditors. 

• A summary report for each control account must be printed for each GL year up to PM year, where the balance is not yet carried forward to the next year.
• If there is more than one control account use Specific Account selection or Account Exception Indicator to reduce the period of time this report will run.
• The total of the actual column will be used to reconcile with the SLGL-transaction of the subsystem.
• Remember that un-posted transactions of subsystems that are not PM or AR will not form part of this report.
• The report reflects the local currency value.
  

• A summary report for each control account must be printed for each GL year not yet closed up to PM year.  Previous years have a different user selection.
• This report will be used to find the imbalance between the SLGL-transaction of the subsystem and GL of phase 3.
• Remember that un-posted transactions will not form part of this report.
• The report reflects the local currency value.

• This report can be printed for single, multiple or all creditors with balances or zero.
• If statements are requested immediately before the generation of payments and payment advices, the report will reflect the amount for which a payment will be generated if all invoice parameter is used excluding the settlement discount transaction that may be generated during payment generation.
  

• Transactions can be selected for a specified period.
• The net total will be equal to the "Application for Draft", if requested for the same period via option {FPMOPD-30}.

• Collect your users batch totals of the previous day.
• Run the User Work Summary and Transaction type report.
• Complete the sheet.
• Solve any errors.  In some cases a User Work Detail report for a specific user will help solve the imbalance between the batches of the user and the data on the system.
• During the month the previous day Total Accumulated must be carried to the next day Previous Recon Total.  Start the first day of a new cycle with zero in Previous Recon Total. 

• Carry forward the Totals of the previous phase 4 recon columns GL Transaction Type and Corrections as well as PM Transaction Type and Correction into Balance Brought Forward.  The Accumulative corrections must be added to PM Transaction Type value. Only the values that are not accumulative corrections must be entered into the PM Correction cell.  Not Accumulative Corrections are corrections that are not in the PM system at the time of the recon.
• Firstly enter the GL transaction type values from the GL Transaction Type Summary report.  The total of the column must be equal to Phase 3, Sub Total column Control Account.  If in balance, do the next paragraph.
• Enter the PM transaction type values from the PM Transaction Type Summary report.  The total of the column must be equal to Phase 3, Sub Total column Transaction Type.  If in balance, do the next paragraph.
• Brought forward corrections of Phase 3, encountered during the Subsystem reconciliation.
• The cell total of column Total PM must be equal to Phase 3 cell total column Transaction Type.
• Investigate the values of column Total Difference and enter the correction or contra values in the appropriate column.
• After the above your spreadsheet will be as followed.

• Complete the following values as printed on the above report, GL Balances for each GL Control Account from the Summary Cost Centre report, Subsystem Balance per Account Type from Creditor Balance report and Values from phase 3 namely subtotals for columns Subsystem Balance and Control Account
• After the above the difference column must zero, all three values, and the Difference between GL and Account Type columns Total and Total Phase 3 must be equal and the value must be equal to the total GL Correction of Phase 3.
• Enter all the corrections of Phase 4 into the appropriate column.
• If all the GL allocations were correct during the cycle the total of row Transfers between Controls should be zero.  But if incorrect, process a GL Journal to correct the Transfer between Control Accounts.