PURCHASING OVERVIEW 8.9

Transcription

1 PURCHASING OVERVIEW 8.9 ROLES INITIAL APPROXIMATE RESOURCES: (ALL) Initiators Approvers Receivers OVERVIEW This section outlines the Purchasing process and provides some definitions. Details will be discussed in the manuals specific to each process. The system utilized by the University of South Florida for financial transactions and reporting is a software product developed and sold by PeopleSoft, company owned by Oracle since FAST (Financial Accounting SysTem) is the USF acronym that designates this software as implemented and used by the university. In the FAST PeopleSoft environment all procedures will, in time, be automatic FAST consists of a number of modules, designed to be used alone or in tandem, as needed. Purchasing (PO) is one such module. Other modules also used by USF and implemented in July 2003 are: Accounts Payable (AP) General Ledger (GL) Budgets (BU) Asset Management (AM) Accounts Receivable (AR) Billing (BI) Grants Management (GM) Capital Construction Project Costing (PC) Working within the FAST framework are other important processes: Workflow - approval routing (WF) Commitment Control - budget checking (KK) Security PURCHASING PROCESS & PAYMENT CONNECTION Departmental Users currently use the online requisition functionality in the PeopleSoft Purchasing module to initiate a request for purchase. The identification of where the expense should be charged is done on the requisition and will carry forward automatically through the Purchase Order (PO) to the Receipt and then to the Voucher (as the system refers to the invoice as input by AP.) Online Workflow approval and receiving processes will replace the manual signature approval. Once the requisition is approved, the system will generate a purchase order (PO) which is the official authorization to purchase goods or services. There will be no automatic notification of the requestor when the POs have been created or dispatched (printed.) The requestor/user will be responsible for monitoring their requisitions and knowing when a PO has been generated and purchase authorized. Updated 3/26/2007 Purchasing Overview Page 1 of 7

2 The vendors will be directed to send invoices directly to the Accounts Payable department for processing rather than to the requesting departments. Authorization to pay will be confirmed via online receiving and acceptance of the goods or services by the departments. Accounts Payable will enter the invoices from the vendors, as vouchers, into the PeopleSoft Payables system in the order they are received. PeopleSoft will match the vouchers to the purchase orders and receipts. Any exceptions to the matching process (quantity or price variances) over predefined tolerances will be routed via Workflow to the departments for review. Once the vouchers are successfully matched, the PeopleSoft payables system will generate payments when due based on payment terms and invoice dates. There will be no automatic notification of the user/requestor when invoices are entered and paid. The user/requestor will be responsible for monitoring his/her requisitions and knowing when invoices are entered and paid. In the near future USF will be adding the following modules: Travel and Expense (EX) Budget Analysis Reporting Tool a.k.a. BART (EPM) The GEMS system (Global EMployment System) in Human Resources is also a PeopleSoft product. The Purchasing manuals deal only with the procurement side of the financial processes in FAST. DOCUMENTS STILL REQUIRED Payment Request Form Change Order Request Form Updated 3/26/2007 Purchasing Overview Page 2 of 7

3 Purchasing to Accounts Payable process flow: Online Requisition (requisition must have a budget check status of Valid) Approval (could be multiple levels depending on the nature and amount of the purchase) PO Batch Processing PO Sourcing PO Calc PO Create PO Dispatch Order Placed with Vendor A Approved? Goods/ Services Invoice Record Inspection of Goods in PS Purchasing (required for consturction only) Inspection Required? Record Receipt of Goods in PS Purchasing Placed in Service Goods/ Services accepted? Return to Vendor (RTV) Matching (compares invoice to PO, Reciept and where applicable Inspection) Invoice Entered into PS Payables B Return for Credit or Exchange Return B Route for Exception Handling Matched? Exchang e Available for Payment Processing A General Ledger Expenditure Transfers Updated 3/26/2007 Purchasing Overview Page 3 of 7

4 GLOSSARY Approval (Requisition) - After a requisition is entered, Workflow will direct it through the system to the appropriate approvers. Once it is approved, it will move through several processes and be built into a purchase order. The requisition will show a status of Approved on the Maintain Requisition page and the user may be moved to the Requisition Inquiry page if they are not a Purchasing Agent. Encumbrance An amount temporarily removed from budget based on a purchase order. It is recorded in Commitment Control and reduces RSA. It is reversed by an Expense. Expense An amount permanently removed from budget due to a payment. It is recorded in Commitment Control and reduces RSA. LPO Limited Purchase Order. A requisition that is less than $ and for a commonly approved type of supply or repair can will automatically source into a purchase order without Purchasing review or approval. Placing the order is in the hands of the department as a printed purchase order will not be mailed. OCO (Operating Capital Outlay) Purchases that add to the overall value of the university such as equipment or land acquisition. Pre-encumbrance An amount temporarily removed from budget based on a requisition. It is recorded in Commitment Control and reduces RSA. It is reversed by an Encumbrance. Purchase Order Authorization to purchase goods or services. Receipt/Receiving Online acknowledgement of receipt and acceptance of goods or services. Req_Approver A Workflow role that acts as the first level of approval authority in the department. Most approvers have both this role and that of Req_Manager.. In areas with two levels of approval, different users will have only one of these roles. Req_Manager A Workflow role that is the highest level of approval authority in the department/college. Most approvers have both this role and that of Req_Manager. In areas with two levels of approval, different users will have only one of these roles. Requisition - The online request for goods or services to be acquired from a supplier. Rollup In the chart of accounts several specific definitions of expenditures (expense accounts) are added together and form a larger category of budget accounts. Those accounts are further added together into even larger categories. This tree structure allows for various levels of budgeting and reporting. This is necessary because various agencies that provide funding, such as the State Comptroller or the National Science Association, require different levels of accountability from the university. Updated 3/26/2007 Purchasing Overview Page 4 of 7

5 RSA Remaining Spending Authority or Budget Balance this is the amount available to spend in a particular budget category. Route, Routing Chartfield, Workflow Route The chartfield value that is used for approval routing on a particular requisition. For a full explanation of Workflow routing in Purchasing, refer to Purchasing Workflow on the Fast Financial Webpage under Business Procedures. Sourcing The group of processes that turn a requisition into a purchase order. They eliminate the pre-encumbrance and create the encumbrance in Commitment Control. Security Role A role that determines what areas of the system a user can access and what they can do there. For example, there is a Security Role of Requisition Approver (PO_REQAPPR.) If a requisition has been pushed into Workflow, user can access the Approve Amounts screen and make changes to the Approval Action, comments, etc. But in addition to the security role, a user must also have one of the Workflow routes for Req_Approver/Manager on the routing chartfield for that requisition. Workflow The process that moves requisitions through layers of approval until it is sourced to a purchase order. For a full explanation of Workflow routing in Purchasing, refer to Purchasing Workflow on the Fast Financial Webpage under Business Procedures. CHARTFIELDS FOR DUMMIES Chartfields are groups of numbers and/or letters that organize and define specific aspects of a financial transaction in the FAST system. This breakdown of finances into categories allows the university to more efficiently record and report its transactions. Each category has it s own field on the distribution that defines the transaction in a code that is standardized so the system can understand and organize it. The categories used in FAST Purchasing are defined in the chart below. Updated 3/26/2007 Purchasing Overview Page 5 of 7

6 CHARTFIELD NAME General Ledger Business Unit Operating Unit Fund Account Department ID Product Initiative AKA GL Unit GL BU OU Oper Unit Acct DeptID Dept Prod Init RO DEFINITION The highest level and official record of financial transactions in the system The first breakdown of transactions after the GL BU. They usually designate one of the campuses or a large subdivision of a campus Designates the source of funding used in the transaction Defines a category of expenditure for Purchasing such as Service Medical or Postage Designates the USF department that will be charged for the expenditure A free field that can be defined as needed by department who require additional breakdown of expenditures This designates a Research Overhead allocation FIELD DESIGN 5 characters 3 letters 5 digits 5 digits 6 digits 6 characters 7 characters NOTE There is only one GL BU for USF TheTampa campus uses 2 OUs, TPA and HSC for the Health Sciences and TPA for everything else USF obtains funding from hundreds of reportable sources; FL state budget, federal grants, auxiliary income, etc. Although Purchasing uses only Expense accounts, other accounts exist such as Budget Accounts or Revenue Accounts There is a rough correlation of department number to college This field is not used for official GL reporting or Workflow. However it is a required field and must be filled out with zeros if it is not being used The employee id of the Principal Investigator is usually the number used. This is required field and must be filled out with zeros if it is USF01 EXAMPLE STP (St. Pete) LKL (Lakeland) SAR (Sarasota) FPR (FIPR) (E&G) (State grant) (Auxiliary) PRO R Updated 3/26/2007 Purchasing Overview Page 6 of 7

7 CHARTFIELD NAME Project Costing Business Unit Project Activity ID Budget Reference Resource Type Resource Category AKA PC BU PC Bus Unit Proj Act Bud Ref Res Type Res Cat DEFINITION FIELD DESIGN NOTE EXAMPLE not being used Specifies a particular project costing type Sepcifies a particular grant or construction project A further breakdown of the project within the project costing module Designates allocation information for Construction Further refinement of Construction activity Additional information for Construction 5 characters characters 1-16 characters 4 characters Both Grants and Construction use the same tables so a distinction is made between them here Grant projects use 10 numbers beginning with the first digits of the department id. Construction projects use up to 14 characters and begin with P Construction uses familiar terminology while Grants uses allocation related names and numbers Usually 2 letters followed by 2 digits 5 characters Usually letters 5 characters Usually letters USF01 GRT PF A&E INFRASTRUCTUR E LAND BUDGET COSTSHARE PE10 GR06 SURV PARK ROADS BLDG Updated 3/26/2007 Purchasing Overview Page 7 of 7