P2P Process Definition Document Procurement
Transcript of P2P Process Definition Document Procurement
P2P Process Definition Document Procurement Version: 1.3 Date created: 06 July 2009 Last release: 07 August 2009
Contents
Contents.............................................................................................................................. 2
Document Control ............................................................................................................... 4
Introduction ......................................................................................................................... 5
Document Purpose....................................................................................................... 5 Roles and Responsibilities ........................................................................................... 6 Service Level Agreements............................................................................................ 8 Reporting Requirements............................................................................................... 9
Create Requisitions .......................................................................................................... 10
Overview..................................................................................................................... 10 Key Design Decisions................................................................................................. 10 Scenarios.................................................................................................................... 12 Catalogue Requisitions............................................................................................... 13 Non-Catalogue Requisitions....................................................................................... 17 P-Card Purchases ...................................................................................................... 22 Call-Off Orders............................................................................................................ 25
Create Orders ................................................................................................................... 29
Overview..................................................................................................................... 29 Key Design Decisions................................................................................................. 29 Scenarios.................................................................................................................... 30 Autocreation................................................................................................................ 31 Autosourcing (Future Process)................................................................................... 33 Contract Purchase Agreements (Future Process) ..................................................... 35 Direct PO Creation...................................................................................................... 37
Amendments & Cancellation ............................................................................................ 39
Overview..................................................................................................................... 39 Key Design Decisions................................................................................................. 39 Scenarios.................................................................................................................... 39 Amending Requisitions............................................................................................... 40 Amending Orders........................................................................................................ 43 Cancelling Requisitions .............................................................................................. 45 Cancelling Orders....................................................................................................... 47
Receiving & Returns ......................................................................................................... 49
Overview..................................................................................................................... 49 Key Design Decisions................................................................................................. 49 Scenarios.................................................................................................................... 49 Desktop Receiving...................................................................................................... 50 Buyer Receipts ........................................................................................................... 52 Returns ....................................................................................................................... 54
Queries ............................................................................................................................. 56
Overview..................................................................................................................... 56 Key Design Decisions................................................................................................. 56 Scenarios.................................................................................................................... 56 Supplier Queries......................................................................................................... 57 Internal Queries .......................................................................................................... 59 AP Queries ................................................................................................................. 61
Supplier Maintenance ....................................................................................................... 63
Overview..................................................................................................................... 63 Key Design Decisions................................................................................................. 63 Scenarios.................................................................................................................... 64 Supplier Setup ............................................................................................................ 65 Supplier Deactivation.................................................................................................. 70 Supplier Merge ........................................................................................................... 72 Supplier Updates ........................................................................................................ 74
Procurement Process Definition Document 2
Month-End & Close........................................................................................................... 76
Overview..................................................................................................................... 76 Key Design Decisions................................................................................................. 76 Scenarios.................................................................................................................... 76 Month-End & Close..................................................................................................... 77
Procurement Process Definition Document 3
Document Control Version Change Made By Date
0.1 Document created David Stutters 14 July
1.0 Updates for review comments David Stutters 23 July
1.1 Updated Supplier Maintenance process and Emergency Order approver.
David Stutters 24 July
1.2 Updated for CE’s comments David Stutters 29 July
1.3 Amended p-card process David Stutters 07 August
Procurement Process Definition Document 4
Introduction
Document Purpose
As part of the P2P project being undertaken by the University of Manchester, the Procurement function is being altered to map to a new Target Operating Model. The objective of this change is to consolidate all the requisitioning methods currently employed by the University, onto Oracle. It is envisaged that the University will derive the following benefits as a direct result of the P2P project:
A smoother procurement experience for requestors of goods and services. Improvements to the purchase requisition approval process. Increased value for money spent for the University through streamlined supplier
relationships. Improved support for requestors of goods and services through an extended
professional procurement network embedded across the University. This document is intended to provide a complete overview of how the University’s Procurement function will operate. It incorporates detailed process designs, roles and responsibilities, Procurement service level agreements and reporting requirements. The only areas identified as out of scope for the P2P project include:
BSF, who are going live with their own ERP system imminently. The Library, who will continue to use Talis for their core purchases.
The processes covered by this document include:
Process Sub Process
Create Requisitions
- Catalogue Requisitions - Non-Catalogue Requisitions - P-Card Requests - Call-Off Orders
Create Orders - Autocreation - Autosourcing (Future Process)† - Contract Purchase Agreements (Future Process)† - Direct PO Creation
Amendments & Cancellation
- Amending Requisitions - Amending Orders - Cancelling Requisitions - Cancelling Orders
Receiving & Returns
- Desktop Receiving - Buyer Receipts - Returns
Queries - Supplier Queries - Internal Queries - AP Queries
Supplier Maintenance*
- Supplier Setup - Supplier Deactivation - Supplier Merge - Supplier Updates
Month-End - Month-End and Close
* Supplier bank detail creation and maintenance is owned by the AP team. Please see the AP PDD for details. † These processes are not currently utilised the University and are included for information purposes as they may be rolled out in the future following further investigation.
Procurement Process Definition Document 5
Roles and Responsibilities
The following roles and responsibilities have been identified for the new Procurement target Operating Model. This section incorporates all the parties who have a role to play in the procurement processes, not just core team members. The responsibilities listed against each role relate only to procurement processes within this document.
Function Responsibilities
Requester - Identifies and communicates the need for particular goods and/or services to the Requisitioner
Requisitioner* - Creates requisitions and submits for approval - Identifies the correct account coding for requisitions - Verifies the tax code assignment for requisitions - Verifies delivery addresses for requisitions - Responds to queries from the approver - Updates requisitions (if required) - Receipts orders upon receiving the goods or services - Places requests for new suppliers - Communicates p-card purchase requests to the Operational
Buyer - Abides by the University’s Financial Regulations
Approver† - Verifies the content of requisitions before approving/rejecting requisitions
- Ensures that there is a genuine business need for requisitions- Verifies the account coding for requisitions - Requests more information from the Requisitioner (if
required) - Verifies sufficient budget availability before approving
requisitions - Adheres to their obligations as specified by the University’s
Financial Regulations
Operational Buyer
- Converts requisitions into Purchase Orders - Verifies that the Purchase Order options are set correctly for
the type of purchase (e.g. call-off orders) - Verifies that the correct procurement process has been
followed - Acts as a local point of knowledge and expertise for the P2P
process - Communicates and acts on decisions made by the Central
Procurement Office - Helps the Central Procurement Office gather data for MI
reporting - Develops local relationships with suppliers - First point of contact for new supplier requests - Owns the p-card for their area - Amends orders if required to release invoice matching holds - Receipts orders if required to release invoice receipt holds
Receiver‡ - Enters a goods receipt when they receive the goods or services
- Amends receipts (if necessary) - Returns faulty goods to the supplier
Supplier Maintenance Clerk
- Sets up new suppliers for the University (if appropriate) - Sets up new suppliers for AP (if appropriate) - Performs credit checks on new suppliers - Performs housekeeping activities on the supplier database - Directs supplier bank detail update requests to AP - Maintains the supplier database - Ensures consistency between the contracted supplier
database and Oracle - Merges supplier accounts (if necessary)
Procurement Process Definition Document 6
Function Responsibilities
Central Procurement Office
- Monitors the Procurement function for the University - Monitors and reports on compliance to the new P2P
processes - Issues P2P related communications to the University via the
Operational Buyers - Gathers and analyses P2P MI - Negotiates future contracts - Uploads new supplier catalogues - Ensures the Procurement information and training is kept up
to date - Responds the queries and requests from the Operational
Buyers - Administers p-cards (future responsibility as this is currently
owned by AP)
Central AP - Processes all invoices and payments on behalf of the University
- Creates and maintains supplier bank details - Performs a sense-check on new supplier records
Financial Processing Manager
- Closes Purchasing and Inventory Periods
* The Requisitioner and Requester can be the same person. They will only be different in the event that someone is requisitioning on behalf of someone else: e.g. where the Requester does not have access to iProcurement. † The Approver and Requisitioner can be the same person. It is possible to self-approve requisitions if a budget holder creates a requisition against their own charge account. ‡ The Receiver and the Requisitioner can be the same person. It is likely to be different in the event of a purchase received by a goods-in function.
Procurement Process Definition Document 7
Service Level Agreements
The following processes are part of the Procurement function and have been identified as processes where the turnaround times can be easily quantified and measured. These SLAs are currently aspirational targets and will be reassessed after go-live when reliable benchmark figures can be obtained.
Process Measurement Responsible SLA
Create Requisitions
Time taken to review and approve/reject
Approver 48 Hours
P-Card Purchases
Time taken to turnaround p-card purchase requests
Operational Buyer
24 Hours
Autocreation Time to turn requisition into PO and dispatch to supplier
Operational Buyer
24 Hours
Direct PO Creation
Time taken to create emergency order
Operational Buyer
Same day
AP Queries Time taken to resolve AP hold resolution query
Operational Buyer
5 days
Supplier Creation
Time taken to create or reject a new supplier request (assuming no complex tendering or contracts required)
Central Procurement
5 days
Supplier Creation
Time taken to create new supplier request from AP
Central Procurement
24 Hours
Procurement Process Definition Document 8
Reporting Requirements
A number of reports are required by the Operational Buyer community and the Central Procurement Office for their day-to-day activities to measure compliance to the new processes. This reporting list will be reviewed after go-live when more detailed reporting requirements can be gathered.
Name Description Used for Run By Tool Frequency
PO 21 - Open Orders including GRNI
Can be used for Accruals information. Includes GL hierarchy parameter.
Accruals Local Finance Teams
Discoverer Monthly
PO09 - Requisition Details Per Activity.DIS
Requisition details for a selected activity
Monitoring requisitions raised by activity code
Multiple Discoverer Ad Hoc
PO1 - Product and Supplier Information.DIS
Report on spend by category or supplier for a School or Faculty.
Used to identify opportunities for new, or consolidation of existing, supplier contracts
Central Procurement
Discoverer Ad Hoc
PO1-1 Purchase Order Information by Supplier.DIS
Supplier expenditure with Purchase order details and date parameters. Can also be run with School and Purchasing Unit parameters
Used to track spend by supplier.
Multiple Discoverer Ad Hoc
PO12 - PO missing req
PO Orders without a requisition
Used to monitor direct PO creation.
Central Procurement
Discoverer Monthly
PO15 - Outstanding orders Barclaycard v1.1.DIS
Outstanding Barclaycard orders by cardholder
Used to track Barclaycard statement processing.
AP Discoverer Monthly
PO17 - Orders greater than or equal to £5,000.DIS
All Purchase Orders over £5,000, including those closed or cancelled. Reports Order amt £, Rec'd amt £, inv'd amt £. Selected date range, Faculty and School
Used to identify high value orders.
Multiple Discoverer Ad Hoc
PO22 - All orders over a selected amount
All orders including GRNI by Faculty and School (replaces old PO17-1)
Used to identify high value orders requiring attention from Central Procurement.
Central Procurement
Discoverer Ad Hoc
PO6-2 -All Purchase Orders by School or Activity Code
This is a report of ALL purchase orders (not matched to purchase invoices) by School, School & Purchasing Unit, or by Activity code.
Used to monitor compliance to contracted suppliers by school.
Central Procurement
Discoverer Ad Hoc
PO6-Outstanding orders.DIS
Housekeeping of Purchase Orders. Please review at least monthly. Outstanding purchase orders not matched to purchase invoices.
Used to identify open orders for closure.
Operational Buyer
Discoverer Ad Hoc
PO8 - Outstanding Requisitions by School and Purch Unit
Housekeeping of Requisitions. Please review at least monthly. Outstanding requisitions which have not yet been converted to a purchase order.
Used to identify open requisitions for closure.
Operational Buyer
Discoverer Ad Hoc
Procurement Process Definition Document 9
Create Requisitions
Overview
A process is required to capture demand for goods and services from the individuals in the University in a consistent and secure manner. Rather than employ multiple online and offline requisition tools, in the future, all requisitions will be created using Oracle iProcurement. This tool allows users to locate the goods and services they require using online catalogues. It also has the facility to allow users to create non-catalogue requisitions in the event that their demand cannot be met by a catalogue. When a requisitioner has created their requisition, Oracle will automatically forward this on to the appropriate approver for the spend based on the account code combination and department of the requisitioner. Approvers can then review the requisition, approve, reject or request more information. Following approval, requisitions are passed to the Operational Buyer to be turned into Purchase Orders. This is detailed in the Create Orders section. This Create Requisitions section also includes the process for p-card transactions
Key Design Decisions
Legacy Systems Requisitioners will use iProcurement for all their requisitioning requirements. All legacy systems will be decommissioned following go-live; this will include any offline processes. This will ensure a consistent process across the University alongside improved management information and control. Requisition Approval Rules The requisition approval hierarchy will not be altered by the P2P project. The current approval hierarchy is determined by two values on the requisition:
The activity code segment of the charge account The Purchasing School assignment of the requisitioner
For all requisitions under £5,000, the approver for the requisition will be the employee specified against the 5000XXX activity code in the hierarchy above the activity code selected on the charge account. If multiple activity codes are selected, the requisition will go to both approvers. For all requisitions over £5000, the approver for the requisition will be the owners of the relevant 5000XXX activity codes, plus the £5K approver specified against the Purchasing School of the Requisitioner. The aim is to make the Head of School Admin (or equivalent) the 5K approver for all Purchasing Schools. For all requisitions over £25,000, the £25K approver for the Purchasing School of the Requisitioner will also be added to the approval chain. For all Purchasing Schools this approver is from the Central Procurement Office. The diagram overleaf illustrates this approval hierarchy. The dotted lines illustrate that the additional 5000XXX code approvers will only be selected if the requisition is spread over multiple charge accounts.
Procurement Process Definition Document 10
Central Procurement Office 25K Approver
5000XXX Code Approver
Requisitioner
Position
Purchasing School5K Approver
Value
£25,000+
£0 - £5,000
£5,000 - £25,000
£250 (Self-Approve)*
* On a discretionary basis, the school accountants can grant self-approval against particular activity codes up to a value of £250. This value is dictated by the University’s financial regulations. iProcurement Access iProcurement access and training will be rolled out to all schools and faculties by mid-September 2009 (assuming all data is provided by these areas). However, access to the application will be restricted based on a user completing the pre-requisite iProcurement training courses. Supplier Setup The supplier field in iProcurement has been made mandatory for all non-catalogue requisitions. In the event that a requisitioner cannot find the supplier they wish to order from, they will be directed to a new, offline supplier setup process. This is detailed in the Supplier Maintenance section. Emergency Orders If a requisitioner requires an order to be raised in an emergency, and cannot wait for the necessary requisition approval stage, they will contact their Operational Buyer. In the event that this purchase cannot be made on a P-Card the Operational Buyer will seek offline approval from the School Accountant to create the PO directly in core Purchasing. Punchout Catalogues There are currently two punchout catalogues and multiple locally hosted catalogues available in iProcurement. An estimated forty new locally hosted and punchout catalogues will be available on go-live. Smartforms When buying particular items or categories of spend from a supplier, it is sometimes necessary to record additional information on the requisition so the supplier can service the request. For instance, an order for business cards will require a user to tell the supplier their name, telephone number, email address, etc. To capture this information in a consistent way and to avoid returned goods, iProcurement allows smartforms to be associated with particular categories of spend or items. These templates are not currently setup, but are on the future enhancements list.
Procurement Process Definition Document 11
P-Card Spend Categories P-Cards should not be used for all purchases as they reduce the level of control over purchasing spend. The standard requisition-PO ordering method should always be the preferred purchasing method and every effort should be made to utilise it, if at all possible. P-cards should only be used where the purchase meets the following criteria: Essential:
There is no supplier catalogue on iProcurement. The individual transaction is under £250 (third-party spend only, this does not
include travel, conferences, etc.) Optional (at least one must be met):
The purchase is urgent: i.e. where the order has to be raised and approved in less than 8 hours.
The purchase is for a supplier that will not accept a PO or will not proceed with the transaction without immediate payment.
The purchase is from an overseas supplier and the cost of making an EFT payment (£3.50) is over the 2.3% overseas transaction cost charged by Barclaycard.
Scenarios
The following process scenarios are incorporated within the Create Requisitions section:
Catalogue Requisitions Non-Catalogue Requisitions P-Card Requests Call-Off Orders
Procurement Process Definition Document 12
Catalogue Requisitions
Process Justification Catalogue requisitions are by far the easiest way for end users to create requisitions. They allow the user to select items for purchase based on a pre-defined list of available supplier items. This avoids the problems associated with deviation from contract prices, purchasing items from approved suppliers but for the wrong categories of spend, mistyping supplier part numbers etc. To avoid the effort associated with maintaining large, locally hosted catalogues, a number of punchout catalogues are also available. These allow the user to ‘punch out’ to the suppliers own catalogue website, with all items selected in this domain, added to the shopping basket in iProcurement. Process Description Having decided that the Requisition/Requester requires particular services or goods, they proceed to find these on the iProcurement website. If there is a catalogue item that matches their requirement, they proceed to add this item to their shopping cart in iProcurement. It is possible to add multiple items from different suppliers to the same requisition. For certain categories of spend, a user might also be required to record additional information for a particular purchase when they add the item to the shopping cart. For example, buying business cards might require the user to record their name, address, telephone, etc. before adding the item to the cart. Having finished shopping, the Requisitioner reviews their shopping cart, altering quantities or deleting items as required. When they are happy with the items on the requisition, they proceed to checkout. During checkout, the Requisitioner must validate several bits of information. At a minimum they must alter the Activity code segment of the requisition charge account, as this will default to a suspense account. To avoid having to do this step for every requisition, the Requisitioner can store their default charge account as a favourite, which will default onto every requisition. Requisitions should also verify:
Requisition description (as this will default from the first line of the requisition) Need-by date Requester (if ordering on someone else’s behalf) Deliver-to Location Project billing information (if ordering against for a project) Tax code assignment
The Requisitioner can also add specific notes to the Buyer, Approver and Supplier as well as adding document attachments for viewing by the Approver (e.g. additional offline approval forms, travel authorisation, etc). When the Requisitioner is satisfied with that their requisition is complete, they submit the document for approval. Oracle then sends the requisition to the approver (or approvers depending on the total value of the requisition) for approval. Upon receiving the notification that a requisition is pending their approval, the Approver is expected to verify certain pieces of information before approving/rejecting the requisition:
Is there sufficient budget to approve this requisition? By approving the requisition, am I adhering to my obligations as specified by the
University’s financial regulations? Does anyone else need to be aware that this requisition is being approved? Is the account coding correct? Is more information required before the requisition can be approved? Is there a genuine need for this spend?
Procurement Process Definition Document 13
Upon answering all these questions, the approver has several choices. If everything is correct, the requisition can be approved. If more information is required, the Approver can request this in the system from any Oracle user. This functionality will be used for any local approval requirements for particular categories of spend. If the requisition is incorrect, the additional local approver rejects the requisition or it does not meet the standards mentioned previously (even after requesting more information), the requisition can be rejected. In some scenarios, the Approver might also choose to amend the requisition. This effectively re-generates the requisition and creates a new requisition approval path. When the requisition has been approved it can then be turned into a purchase order, either automatically by the system (Autosourcing) or manually by the Operational Buyer (Autocreate). The Requisitioner also receives a notification to inform them that the requisition has been approved. Please note that autosourcing is a future aim for the University, and will not be setup without further investigation into its usefulness. Process Controls All requisitions require financial approval (please see Key Design Decisions). Users cannot post to the default purchasing suspense account.
Procurement Process Definition Document 14
Catalogue Requisitions: Process Flow (1 of 2)
Demand
Function Inputs Tasks Deliverables Description
Identify need for goods/services
Requisitioner
Catalogue Requisitions
Approved RequisitionRequisitioner
Process for the creation and approval of catalogue requisitions
Is a catalogue available?
Non-Catalogue
RequisitionsNo
Yes
Add items to cart
Is additional information required?
No
Yes
Fill in information
Validate requisition checkout
information
Update Charge Account
No
Update requisition
details
Changes Required?
Yes
Requisitioner
Requisitioner
Requisitioner
Requisitioner
Requisitioner
Requisitioner
Requisitioner
The Requisitioner identifies a need to purchase new goods or services. This demand might be their own, or from a Requester in their area.
The Requisitioner logs in to iProcurement and attempts to find a catalogue that matches their requirements. If they cannot find a catalogue, they proceed to the non-catalogue request form.
The Requisiitoner searches for the items they require within the catalogue.
Search for items
Requisitioner
When the Requisitioner finds the items that they need, they add them to the cart. Multiple items can be added to a single cart if required.
On selecting certain items, the system might request that the Requisitioner records additional information on the requisition. This can be for internal purposes, or to help a supplier service the order correctly.
When the Requisitioner has finalised their shopping cart, they proceed to checkout where they verify a number of pieces of information, e.g. delivery address, project costing, tax codes, etc.
If changes are required to any of the checkout information, these are made by the Requisitioner.
The charge account that defaults on a requisition will, in most cases, be the default suspense account. This has to be changed by the Requisitioner so that the system codes the expenditure correctly and builds the right approval hierarchy.
Procurement Process Definition Document 15
Catalogue Requisitions: Process Flow (2 of 2)
Demand
Function Inputs Tasks Deliverables Description
Receive notification requesting approval
Approver
Catalogue Requisitions
Approved RequisitionRequisitioner
Process for the creation and approval of catalogue requisitions
Review requisition
details
More information required?
Send note requesting information
Reply with required
information
Approve/Reject?
Send rejection reason to
RequisitionerReject
No
Yes
Higher level approval required?
Yes
No
Valid CPA in place?
Autocreation AutosourcingYesNo
Approve
Approver
Approver
Requisitioner/Recipient
Approver
System
System
Submit for approval
Requisitioner
When the Requisitioner has verified all the information on the Requisition and updated the charge accounts, they submit the document for approval.
The first (or next) Approver in the approval chain will receive a notification via workflow asking them review the requisition.
The Approver opens the notification and reviews the requisition details: e.g. account coding, suitable need, additional approval required, sufficient budget to approve, etc.
When the Approver has submitted their request for further information, the recipient (likely to be the Requisitioner) replies with the requested information.
When the Approver has obtained all the information required to make an informed decision about whether to approve the requisition, they approve or reject. If they reject, they send a notification to the Requisitioner detailing the reasons for this.
Depending on the value of the requisition and the account coding, further approval might be required (see Key Design Decisions). The system will determine this and send a notification to the next person in the approval chain as required.
If autosourcing has been enabled and there is a valid CPA in place for the supplier, the system will automatically turned the approved requisition into a purchase order. If there is no CPA (or autosourcing has not been enabled) the requisition will fall into the autocreate table for manual processing by the Operational Buyer.
In some scenarios, the Approver will require more information before they can approve the requisition. This can be requested from anyone setup on Oracle or from anyone in the requisition approval workflow list. This functionality will be used to cover local approval requirements for particular categories of spend.
Procurement Process Definition Document 16
Non-Catalogue Requisitions
Process Justification If a catalogue is not available for a particular type of spend, Requisitioners can still create their requisitions using the non-catalogue request form. This form allows users to create a free-text requisition specifying the particular goods or services they require. Certain fields are mandatory on this form to avoid requisitions with insufficient detail (e.g. Supplier Name, Item Description, etc.) Process Description Having decided that the Requisition/Requester requires particular services or goods, they proceed to find these on the iProcurement website. If there is no supplier catalogue that matches their requirement, they proceed to the non-Catalogue request form. The user fills in all the required requisition information on this form and then adds the line to their shopping cart. It is possible to add multiple items from different suppliers to the same requisition. For certain categories of spend, a user might also be required to record additional information for a particular purchase when they add the non-catalogue request to the shopping cart. For example, buying business cards might require the user to record their name, address, telephone, etc. before adding the request to the cart. In addition to the catalogue request process, these forms for recording additional information might be incorporated onto the non-catalogue request form. Having finished shopping, the Requisitioner reviews their shopping cart, altering quantities or deleting requisition lines as required. When they are happy with the lines on the requisition, they proceed to checkout. During checkout, the Requisitioner must validate several bits of information. At a minimum they must alter the Activity code segment of the requisition charge account, as this will default to a suspense account. To avoid having to do this step for every requisition, the Requisitioner can store their default charge account as a favourite, which will default onto every requisition. They should also verify:
Requisition description (as this will default from the first line of the requisition) Need-by date Requester (if ordering on someone else’s behalf) Deliver-to Location Project billing information (if ordering against for a project) Tax code assignment
The Requisitioner can also add specific notes to the Buyer, Approver and Supplier as well as adding document attachments for viewing by the Approver (e.g. additional offline approval forms). When the Requisitioner is satisfied with that their requisition is complete, they submit the document for approval. Oracle then sends the requisition to the approver (or approvers depending on the total value of the requisition) for approval. Upon receiving the notification that a requisition is pending their approval, the Approver is expected to verify certain pieces of information before approving/rejecting the requisition:
Is there sufficient budget to approve this requisition? By approving the requisition, am I adhering to my obligations as specified in the
University’s financial regulations? Does anyone else need to be aware that this requisition is being approved? Is the account coding correct? Is more information required before the requisition can be approved? Is there a genuine need for this spend?
Upon answering all these questions, the approver has several choices. If everything is correct, the requisition can be approved. If more information is required, the Approver
Procurement Process Definition Document 17
can request this in the system from any Oracle user. This functionality will be used for any local approval requirements for particular categories of spend. If the requisition is incorrect, the additional local approver rejects the requisition or it does not meet the standards mentioned previously (even after requesting more information), the requisition can be rejected. In some scenarios, the Approver might also choose to amend the requisition. This effectively re-generates the requisition and creates a new requisition approval path. When the requisition has been approved it can then be turned into a purchase order, either automatically by the system (Autosourcing) or manually by the Operational Buyer (Autocreate). The Requisitioner also receives a notification to inform them that the requisition has been approved. Please note that autosourcing is a future aim for the University, and will not be setup without further investigation into its usefulness. Process Controls All requisitions require financial approval (please see Key Design Decisions). Users cannot post to the default purchasing suspense account.
Procurement Process Definition Document 18
Non-Catalogue Requisitions: Process Flow (1 of 3)
Demand
Function Inputs Tasks Deliverables Description
Identify need for goods/services
Requisitioner
Non-Catalogue
Requisitions
Approved RequisitionRequisitioner
Process for the creation and approval of non-catalogue requisitions
Is a catalogue available?
Catalogue Requisitions
Yes
No
Fill in required item
information
Is additional information required?
No
Yes
Fill in information
Validate requisition checkout
information
Requisitioner
Requisitioner
Requisitioner
Requisitioner
Requisitioner
The Requisitioner identifies a need to purchase new goods or services. This demand might be their own, or from a Requester in their area.
The Requisitioner logs in to iProcurement and attempts to find a catalogue that matches their demand. If they find a catalogue, they use the Catalogue Requisitions process.
If no catalogue is found, the Requisitioner enters the non-catalogue requisition form.
Access non-catalogue
request formRequisitioner
The Requisitioner fills in the item/service information with sufficient detail for the supplier to service the order. They also enter a suitable category of spend for the requisition.
For certain categories of spend, the system might request that the Requisitioner records additional information on the requisition. This can be for internal purposes, or to help a supplier service the order correctly.
When the Requisitioner has finalised their shopping cart, they proceed to checkout where they verify a number of pieces of information, e.g. delivery address, project costing, tax codes, etc.
Is the supplier
available?
Supplier Maintenance
Clerk The Requisitioner searches for the supplier they wish to use for this purchase. If the supplier is not available, they will follow the link on iProcurement to the new supplier request form on the intranet. They must fill this in and send it to the Operational Buyer. When/If the supplier is created, they can restart the process.
YesFill in New Supplier
Request Form
No
Send to Operational
Buyer
Supplier Setup
Requisitioner
Procurement Process Definition Document 19
Non-Catalogue Requisitions: Process Flow (2 of 3)
Demand
Function Inputs Tasks Deliverables Description
Receive notification requesting approval
Approver
Non-Catalogue
Requisitions
Approved RequisitionRequisitioner
Review requisition
details
More information required?
Send note requesting information
Reply with required
information
Approve/Reject?
Send rejection reason to
RequisitionerReject
No
Yes
Yes
Approve
Approver
Approver
Requisitioner/Recipient
Approver
Submit for approval
Requisitioner
When the Requisitioner has verified all the information on the Requisition and updated the charge accounts, they submit the document for approval.
The first Approver in the approval chain will receive a notification via workflow asking them review the requisition.
The Approver opens the notification and reviews the requisition details: e.g. account coding, suitable need, additional approval required, sufficient budget to approve, etc.
In some scenarios, the Approver will require more information before they can approve the requisition. This can be requested from anyone setup on Oracle or from anyone in the requisition approval workflow list. This functionality will be used to cover local approval requirements for particular categories of spend.
When the Approver has submitted their request for further information, the recipient (likely to be the Requisitioner) replies with the requested information.
When the Approver has obtained all the information required to make an informed decision about whether to approve the requisition, they approve or reject. If they reject, they send a notification to the Requisitioner detailing the reasons for this.
Update Charge Account
No
Update requisition
details
Changes Required?
YesRequisitioner
Requisitioner
If changes are required to any of the checkout information, these are made by the Requisitioner.
The charge account that defaults on a requisition will, in most cases, be the default suspense account. This has to be changed by the Requisitioner so that the system codes the expenditure correctly and builds the right approval hierarchy.
Process for the creation and approval of non-catalogue requisitions
Procurement Process Definition Document 20
Non-Catalogue Requisitions: Process Flow (3 of 3)
Demand
Function Inputs Tasks Deliverables Description
Non-Catalogue
Requisitions
Approved RequisitionRequisitioner
No
AutocreationSystem
When the requisition has been fully financially approved, it will drop into the Operational Buyer’s autocreate table to be turned into a requisition (only in exceptional circumstances will non-catalogue requisitions be autosourced)
Process for the creation and approval of non-catalogue requisitions
High level Approver required?
System
Depending on the value of the requisition and the account coding, further approval might be required (see Key Design Decisions). The system will determine this.
Yes
Approve
Procurement Process Definition Document 21
P-Card Purchases
Process Justification In some scenarios, it may be necessary to make a payment to a supplier immediately, e.g. hotel reservations, internet shopping, etc. If this is the case, then the Operational Buyer can choose to make the purchase using a p-card. This must, however, be backed up by an approved requisition and purchase order to allow AP to clear the statement. In certain cases where the payment is required in an emergency, the Operational Buyer might choose to make the purchase using the p-card and then raise the requisition and order retrospectively. This must only be done in exceptional circumstances and the requisition must be created immediately after making the purchase, not retrospectively when the statement is received. Process Description Going forward, p-cards will be owned by the Operational Buyer community. When a Requisitioner needs to make p-card purchase, they contact the Operational Buyer offline, to ask for a p-card purchase to be made. The Operational Buyer will decide if there is a genuine need to use the card. If there is no need, they will advise the Requester to raise a requisition in the standard method. If a p-card purchase is suitable, then the requisitioner will create a non-catalogue requisition and get this approved in the normal way. They must select the supplier as Barclaycard and the site as the card holder, rather than choosing the actual supplier. When the requisition has been financially approved, the Operational Buyer turns the requisition into a purchase order using Autocreate. They must flag that this is a p-card order by selecting this in the relevant flexfield on the PO header. When the PO has been created, the Operational Buyer makes the purchase over the phone/email/website. They must make the purchase on behalf of the Requisitioner, rather than give them the card details. If not set to 2-way match, the p-card purchases must then be receipted in the normal way. On the 10th of the month, AP will issue the card statement to the card holder. They must write the PO numbers against each statement line and return to AP by the 15th of the month. AP will then match and clear the statement as a standard invoice before reconciling to the direct debit payment. Process Controls P-cards will be held by the Operational Buyers in the new process. P-card purchases must be backed up by an approved requisition and order. Card holders that do not adhere to the process for p-cards and raise their orders late, will have their card access removed. Card holders are instructed not to send the card details out to requisitioners; they must make the purchase on the requisitioner’s behalf.
Procurement Process Definition Document 22
P-Card Purchases: Process Flow (1 of 2)
Demand
Function Inputs Tasks Deliverables Description
Identify need for goods/services
Requisitioner
P-Card Purchases
Goods OrderedRequisitioner
Process for the purchase of goods and services using p-cards.
Is a catalogue available?
Catalogue Requisitions
Yes
No
Requisitioner
The Requisitioner identifies a need to purchase new goods or services. This demand might be their own, or from a Requester in their area.
The Requisitioner logs in to iProcurement and attempts to find a catalogue that matches their demand. If they find a catalogue, they must use the Catalogue Requisitions process in the first instance.
Is a p-card purchase suitable?
Non-Catalogue
RequisitionsNoRequisitioner
Contact Operational
Buyer
Yes
Review p-card request
Obtain price information
from the supplier
Approve/Reject?
Reject
Approve
Requisitioner
Requisitioner
Operational Buyer
Operational Buyer
If no catalogue is available, Requisitioner must then decide if a p-card purchase is more appropriate than using a non-catalogue request (see Key Design Decisions).
If the Requisitioner determines that a p-card purchase is required, they contact the supplier to find out the price information.
Having gathered all the information necessary to make the purchase, the Requisitioner contacts their Operational Buyer with the purchase information and account coding.
The Operational Buyer reviews the p-card request to make sure there is a genuine requirement to use the p-card instead of the normal requisition process.
If there is no need to use the p-card, the Operational Buyer tells the Requisitioner to use iProcurement as normal.
Raise requisition in iProcurement
Requisitioner
The Requisitioner creates a requisition for their p-card purchase using the non-catalogue request form. They set the supplier to Barclaycard for this purchase.
Approve/Reject?
ApproverThe requisition is submitted and approved in the same way as a standard non-catalogue requisition.
Non-Catalogue
RequisitionsReject
Approve
Procurement Process Definition Document 23
P-Card Purchases: Process Flow (2 of 2)
Demand
Function Inputs Tasks Deliverables Description
P-Card Purchases
Goods OrderedRequisitioner
Process for the purchase of goods and services using p-cards.
AutocreationOperational
Buyer
When the requisition has been financially approved, the Operational Buyer autocreates the purchase order.
Approve
Make purchase
using p-card
Operational Buyer
The Operational Buyer makes the purchase with the supplier over the phone/email/website using the p-card details.
ReceivingRequisitionerUnless set to 2-way match, the requisitioner must receipt the goods/services when they are received.
Procurement Process Definition Document 24
Call-Off Orders
Process Justification To generate PO compliant expenditure for categories of spend that do not fit the standard procurement method, it is necessary to create call-off purchase orders. These are large orders raised periodically for a supplier that cover numerous individual orders and payments. These call-off orders are useful from a budgeting perspective, improve PO compliance levels and speed up the Central AP invoice processing. Process Description Call-off orders are raised in exactly the same way as any other non-catalogue requisition. There are, however, some important points of information that the requisitioner must record on the requisition that affect how the Operational Buyer converts the requisition into a Purchase Order. The Requisitioner must:
Highlight the fact that this is a call-off requisition by stating this in the item description field. This will ensure that the Operational Buyer takes extra care when creating the purchase order and that the approver understands the high-value of the requisition.
Include in the Item Description or Note to Buyer field if they want the order to be 2 or 3-way matched. This decision will depend on whether the Requisitioner wants control over the spend on a month-by-month basis. If this is not important, they should specify 2-way matching. If the order is 3-way matched, the requisitioner will receive a notification each month from Central AP asking them to receipt the order so the invoice can be released from hold.
Include in the Item Description or Note to Buyer field if the order should be sent to the supplier, just the order number should be sent, or nothing should be sent to the supplier. In some scenarios (e.g. Utilities) there is no point in sending the supplier the PO as they will not quote the PO number. For other suppliers, it might be appropriate to tell them the PO number so they can quote this on their invoices, but not the actual PO as you do not want them to know how much you have agreed to spend with them for the period. And, as with most orders, it might be perfectly reasonable to send the supplier the PO as normal.
Alter the requisition need-by date so that it is for the end of the period in question. This will prevent the user receiving unwanted goods receipt reminders.
Having specified all this information, along with the standard amount and supplier details, the Requisitioner submits the requisition in the normal manner. This is then approved as standard (please see the Non-Catalogue Requisition process for details). Process Controls Closure of call-off orders that are no longer required will be monitored by the Operational Buyers as part of their month-end tasks. Only Operational Buyers are able to set a PO to 2-way match.
Procurement Process Definition Document 25
Call-Off Orders: Process Flow (1 of 3)
Demand
Function Inputs Tasks Deliverables Description
Identify need for a call-off
orderRequisitioner
Call-Off Orders
Call-Off order createdRequisitioner
Process for the creation and approval of call-off purchase orders.
The Requisitioner identifies a need to create a call-off purchase order. The will normally have discussed this with their Operational Buyer in advance.
Access non-catalogue
request form
Fill in supplier information
Record 2/3-way match
details
Alter the need-by date
Add to cart and proceed to checkout
Record PO send
preferences
Validate requisition checkout
information
Requisitioner
When the Requisitioner finalises a number of pieces of information, e.g. delivery address, project costing, tax codes, etc.
RequisitionerTo create the call-off order, the Requisitioner accesses the standard non-catalogue request form.
Requisitioner
Requisitioner
Requisitioner
Requisitioner
Requisitioner
The Requisitioner fills in the supplier information.
Is the supplier
available?
Supplier Maintenance
Clerk
The Requisitioner searches for the supplier they wish to use for the call-off order. If the supplier is not available, they will follow the link on iProcurement to the new supplier request form on the intranet. They must fill this in and send it to the Supplier Maintenance Clerk to get the supplier setup in Oracle. When/If the supplier is created, they can restart the process.
Fill in New Supplier
Request Form
No
Send to Supplier
Maintenance Clerk
Supplier Setup
Requisitioner Yes
The Requisitioner identifies if they need month-by-month control over the spend by identifying if the order should be 2 or 3-way matched.
The Requisitioner records if they want the PO sent to the supplier.
The Requisitioner adds the call-off requisition line to their shopping cart and proceeds to checkout.
The Requisitioner must amend the need-by date to state the end of the call-off order period. This will stop them receiving unnecessary receipt reminder notifications
Procurement Process Definition Document 26
Call-Off Orders: Process Flow (2 of 3)
Demand
Function Inputs Tasks Deliverables Description
Call-Off Orders
Call-Off order createdRequisitioner
Process for the creation and approval of call-off purchase orders.
Receive notification requesting approval
Approver
Review requisition
details
More information required?
Send note requesting information
Reply with required
information
Approve/Reject?
Send rejection reason to
RequisitionerReject
No
Yes
Yes
Approve
Approver
Approver
Requisitioner/Recipient
Approver
Submit for approval
Requisitioner
When the Requisitioner has verified all the information on the Requisition and updated the charge accounts, they submit the document for approval.
The first Approver in the approval chain will receive a notification via workflow asking them review the requisition.
The Approver opens the notification and reviews the requisition details: e.g. account coding, suitable need, additional approval required, sufficient budget to approve, etc.
When the Approver has submitted their request for further information, the recipient (likely to be the Requisitioner) replies with the requested information.
When the Approver has obtained all the information required to make an informed decision about whether to approve the requisition, they approve or reject. If they reject, they send a notification to the Requisitioner detailing the reasons for this.
Update Charge Account
No
Requisitioner
The charge account that defaults on a requisition will, in most cases, be the default suspense account. This has to be changed so that the system codes the expenditure correctly and builds the right approval hierarchy.
Update requisition
details
Changes Required?
YesRequisitionerIf changes are required to any of the checkout information, these are made by the Requisitioner.
In some scenarios, the Approver will require more information before they can approve the requisition. This can be requested from anyone setup on Oracle or from anyone in the requisition approval workflow list. This functionality will be used to cover local approval requirements for particular categories of spend.
Procurement Process Definition Document 27
Call-Off Orders: Process Flow (3 of 3)
Demand
Function Inputs Tasks Deliverables Description
Call-Off Orders
Call-Off order createdRequisitioner
Process for the creation and approval of call-off purchase orders.
AutocreationSystem
When the requisition has been fully financially approved, it will drop into the Operational Buyer’s autocreate table to be turned into a requisition (only in exceptional circumstances will non-catalogue requisitions be autosourced)
Further approval required?
System
Depending on the value of the requisition and the account coding, further approval might be required (see Key Design Decisions). The system will determine this.
No
ApproveYes
Procurement Process Definition Document 28
Create Orders
Overview
Having raised and approved a requisition, it is necessary to turn it into a purchase order to be sent to the supplier. After go-live, this task will be performed by the new Operational Buyer community who will be the local points of contact for any procurement related queries. In addition to turning the requisition into a PO, the Operational Buyers will also review the information on the requisition to makes sure it is appropriate spend, from the right supplier, etc. This is discussed in more detail in the Autocreation process. Although not available for go-live, it is also possible to setup Oracle so that it will automatically turn approved requisitions into purchase orders. Identifying the suppliers where this would be appropriate and configuring Oracle to allow this will be a future aim for the University. As the creation of a contract purchase agreement is a pre-requisite for autosourcing, this process is also included. In some scenarios it will be necessary to bypass the requisition stage and create a PO directly in core Purchasing. This will only be done on an exception basis, primarily in the event that an emergency order is required.
Key Design Decisions
Operational Buyers As part of the Target Operating Model design phase that took place in 2008, it was identified that the University should alter its operating model to account for the devolved nature of the procurement function within the Schools and Faculties. To achieve this operating model, it was deemed necessary to create a network of Operational Buyers who will be the local Procurement contacts for their area. The roles and responsibilities for these Operational Buyers can be found in the relevant section at the start of the document. The Operational Buyers are can be found in the attached spreadsheet:
OB Contact List.xls
Direct PO Creation Direct PO creation (i.e. without an approved requisition) will be halted except in exceptional circumstances where a PO number is required in an emergency. In these situations, the Operational Buyer will have to seek offline approval from the School Accountant before creating the order. The creation of POs directly in core Purchasing cannot be restricted for users, so this process will be monitored by the Central Procurement Office using the PO12 - PO Orders without a requisition report. Autosourcing Autosourcing can be setup for individual suppliers and allows the system to automatically turn requisitions into POs when the requisition references a Contract Purchase Agreement. Autosourcing should only be setup for high volume, low value suppliers where a catalogue has been agreed. For these suppliers, there is very little value that an Operational Buyer can add to the purchasing process, beyond consolidating the requisitions onto a single order. Autosourcing is not currently used by the University, but is a future goal as it will reduce Operational Buyer workload, releasing them to focus on more high value activities. This requires more investigation before it can be implemented.
Procurement Process Definition Document 29
Scenarios
The following process scenarios are incorporated within the Create Orders section:
Autocreation Autosourcing (Future Process) Contract Purchase Agreements (Future Process) Direct PO Creation
Procurement Process Definition Document 30
Autocreation
Process Justification When a requisition has been fully financially approved in iProcurement, it is necessary to convert the approved document into a Purchase Order. At this stage the Operational Buyer can perform their sourcing activities and make any required amendments to the PO. The PO then needs to be sent via post, fax or email to the supplier. Process Description The Operational Buyer will check the autocreate folder throughout the day. This folder contains all the approved requisitions for their area. When a requisition drops into this folder, the Operational Buyer proceeds to turn the requisition into a purchase order. At this stage, the Operational Buyer will check several points:
Is the purchase necessary? Is there a note to the buyer from the requisitioner? Is the supplier correct? Can the requisition be consolidated with other requisitions onto a single order? Should the order be two-way matched (e.g. call-offs)? Is the account coding correct? Should the order be coming from stores? Is the requisition description meaningful? Are the Ship-To and Deliver-To addresses correct? Can I send the PO via email?
Depending on the answers to these points, the Operational Buyer will approve/reject the requisition, make any amendments to the Order (if required) and approve the PO. When the PO has been approved it can be sent to the supplier via email or printed and posted. Process Controls Only Operational Buyers will have access to the autocreate function. They will only be able to autocreate requisitions from the area to which they are assigned. However, the Operational Buyer can amend their own Purchasing Unit assignment and can, therefore, see requisitions from all areas of the University. This will be retained to allow a single Operational Buyer to be shared by multiple purchasing schools if required.
Procurement Process Definition Document 31
Autocreation: Process Flow
Approved Requisition
Function Inputs Tasks Deliverables Description
Query Autocreate
table
Operational Buyer
Autocreation
PO Dispatched to
SupplierOperational
Buyer
Process for the conversion of approved requisitions into purchase orders and their dispatch to supplier.
Throughout the day the Operational Buyer reviews the queue of approved requisitions in their Autocreate table.
Valid requisition?
Operational Buyer
Return requisition
No
Create Purchase
Order
No
Yes
Correct Supplier?
Change supplier
Yes
No
Check Notes to Buyer
Consolidation possible/
YesSelect multiple
lines
Amendments required?
YesAmend
purchase order
No
Submit Purchase
Order
Print/Email PO to supplier
Operational Buyer
Operational Buyer
Operational Buyer
Operational Buyer
Operational Buyer
Operational Buyer
Operational Buyer
Firstly, the Operational Buyer verifies the requisition is valid. If there is no justified reason for the requisition, or it has been raised in error, the Operational Buyer returns the requisition to the Requisitioner with a reason for the rejection.
The Operational Buyer checks the Notes to Buyer field before creating the order to check if there is anything they must take into account whilst creating the order.
If at all possible, the Operational Buyer will consolidate multiple requisitions for the same supplier onto a single order.
The Operational Buyer checks that the supplier chosen by the Requisitioner is the most appropriate, if not, the Operational Buyer can change this before creating the purchase order. This does not affect the requisition.
The Operational Buyer uses the autocreate function to automatically create a purchase order with the same details as the requisitions they have selected.
In some cases (e.g. call-off purchase orders) it will be necessary for the Operational Buyer to make amendments to the order. They will also verify account coding, ship-to addresses, etc.
When they are satisfied with the purchase order, the Operational Buyer submits the purchase order, this will not require approval.
If the order submits successfully, the Operational Buyer prints the PO and sends to the supplier or, if an email address is available, sends the PO via email.
Procurement Process Definition Document 32
Autosourcing (Future Process)
Process Justification Autosourcing allows approved requisitions to be automatically turned into approved Purchase Orders. This removes some of the manual workload for the Operational Buyers, allowing them to focus on higher value activities. Process Description When the requisition Approver approves the requisition, the system will check to see if a contract purchase agreement (CPA) is referenced on the requisition. If there is an approved CPA reference and the requisition is below the individual transaction limit and within the total release amount, it will automatically turn into a purchase order. If the supplier is setup with an email address, then the PO will automatically be sent to the supplier. If there is no email address, the Operational Buyer must check the POs raised throughout the day and print these as necessary. If no CPA is referenced, then the requisition will drop into the Autocreate table for manual conversion into a Purchase Order. Process Controls Only requisitions for a supplier with a valid contract purchase agreement can be autosourced. Depending on the system setup, non-catalogue requests can be removed from the autosourcing step and pushed into the autocreate table. This process is a potential future enhancement for the system and requires more investigation before it will be implemented.
Procurement Process Definition Document 33
Autosourcing (Future Process): Process Flow
Approved Requisition
Function Inputs Tasks Deliverables Description
Autosourcing
PO Dispatched to
SupplierOperational
Buyer
Process for the automated conversion of approved requisitions into purchase orders and their dispatch to supplier.
Valid CPA referenced?
System AutocreationNo
Yes
When a requisition has been financially approve, the system checks to see if the requisition references a valid CPA for the supplier. If there is no CPA, the requisition goes to the Operational Buyer for manual processing.
Automatically create
purchase order
System
If there is a valid CPA reference the requisition is automatically turned into a purchase order. Note: if self-approval is enabled this will also be pre-approved.
Dispatch PO to supplier
Email address
available?
If the supplier site has a valid email address and the preferred contact method is email, the system will automatically send the PO to the supplier. Note: this is additional functionality which is not currently configured.
YesPrint PO
No
System
System
Operational Buyer
If there is no email address for the supplier, the PO has to be printed manually by the Operational Buyer.
The PO is dispatched by post or email to the supplier
Approved Requisition
Procurement Process Definition Document 34
Contract Purchase Agreements (Future Process)
Process Justification To enable autosourcing, a contract purchase agreement (CPA) has to be setup. This will be performed by the Central Procurement Office for suppliers where there is limited risk in bypassing the autocreation step: i.e. for suppliers with an approved catalogue on iProcurement. Process Description Having identified a supplier that is suitable for autosourcing, the Central Procurement Office access Oracle to create a contract purchase agreement. They create a new CPA for the supplier in core Purchasing and decide if any further control is necessary. Oracle allows a control to be created for the maximum amount limit on the CPA (i.e. the total amount that can be released against the CPA over its lifespan). Process Controls Only the Central Procurement Office will create contract purchase agreements. Depending on the system setup, non-catalogue requests can be removed from the autosourcing step and pushed into the autocreate table. This process is a potential future enhancement for the system and requires more investigation before it will be implemented.
Procurement Process Definition Document 35
Contract Purchase Agreements (Future Process): Process Flow
Autosourcing Requirement
Function Inputs Tasks Deliverables Description
Contract Purchase
Agreements
Autosourced Requisitions
Operational Buyer
Process for the creation of Contract Purchase Agreements.
Autosource Required?
Central Procurement
No
Yes
When a new catalogue is identified, the Central Procurement team must decide if it should be setup to autosource. If there is no requirement for this, then the catalogue requisitions will be created by the Operational Buyers.
New catalogue Autocreation
Create contract
purchase agreement
Controls required?
Central Procurement
Central Procurement
Central Procurement
Submit CPA
Autosourcing
No
NoAdditional controls
If autosourcing is required, the Central Procurement team create a CPA in core purchasing.
As part of the CPA creation, the Central Procurement team must decide if additional controls are required for the CPA. This will allow a maximum release limit to be set.
When the CPA information has been entered, it is submitted. This will not require additional approval.
Upload catalogue
When the CPA has submitted successfully, the Central Procurement team can upload the supplier catalogue with the CPA reference. All items will now be autosourced from this catalogue.
Central Procurement
Procurement Process Definition Document 36
Direct PO Creation
Process Justification Where an order is required on an emergency basis, the requisition approval requirements prevent this from happening and a p-card purchase is not suitable, the Operational Buyer can create an order directly within core Purchasing. This will happen only on an exception basis and the Operational Buyer will have to contact the School Accountant (or equivalent) for approval in the first instance. Process Description The requisitioner contacts the Operational Buyer specifying the need for an emergency purchase order to be raised. The Operational Buyer will review the request and decide if an alternative purchasing method would be more appropriate. If there is no alternative but to raise the order in core purchasing, the Operational Buyer will contact the School Accountant (or equivalent) for approval. If the order is approved by the School Accountant, the Operational Buyer creates the order in core Purchasing, making it clear in the PO description that this is an emergency order. If required, the Operational Buyer then dispatches the document to the Supplier by post or email. They then notify the Requester that the order has been created and tell them the PO number so they can communicate this to the supplier. The Requester must also know the PO number for receipting purposes. Process Controls Only Operational Buyers will be able to create orders directly within core Purchasing. Control over this process will be maintained using retrospective reporting to identify purchase orders raised without an approved requisition.
Procurement Process Definition Document 37
Direct PO Creation: Process Flow
Emergency Order
Function Inputs Tasks Deliverables Description
Direct PO Creation
PO dispatched to supplier
Operational Buyer
Process for the creation and approval of emergency purchase orders.
Genuine request?
Operational Buyer
No
Yes
In some situations, a PO will have to be created in an emergency to progress an urgent order. Firstly, the Operational Buyer must validate it is a genuine request and not an attempt to bypass the normal order process.
Emergency Order
Non-Catalogue
Requisitions
Gain approval from School
Accountant (or equivalent)
Operational Buyer
Before creating an emergency order, the Operational Buyer must check if a p-card purchase is possible as an alternative to creating a PO in core purchasing.
P-card possible?
P-Card Purchases
Yes
No
Create PO in core
purchasing
Approve Request?
NoNon-
Catalogue Requisitions
Yes
Dispatch PO?
YesSend PO via Post/Email
Notify Requester
No
Inform supplier
Operational Buyer
School Accountant
(or equivalent)
Operational Buyer
Operational Buyer
Operational Buyer
Requester
If there is no alternative to creating the PO directly, the Operational Buyer contacts the School Accountant (or equivalent) for their area to get approval. This is offline.
The School Accountnat (or equivalent) either approves or rejects the request. If they reject, the Requester will have to raise a requisition in the normal manner.
If the School Accountant approves the request, the Operational Buyer creates the order in core purchasing and submits.
The Operational Buyer must decide if it is necessary to dispatch the purchase order to the supplier.
The Operational Buyer informs the Requester of the PO number, this allows them to communicate this to the supplier (to progress the order) and for future receipting purposes.
The Requester contacts the supplier to tell them the PO number.
Procurement Process Definition Document 38
Amendments & Cancellation
Overview
In some cases, having created a requisition/order it is necessary to make an amendment to the document or to cancel it entirely. The process for these amendments or cancellations depends on where the document is in the approval path and document creation process.
Key Design Decisions
Amendments to Approved Requisitions Oracle has been setup in a manner that restricts the ability of Requisitioner to amend their requisitions when the document has been assigned a Purchase Order number. As such, if a Requisitioner needs an amendment or cancellation to their requisition, they have to contact the Operational Buyer to tell them of this fact. Supplier Obligations It is important to remember that, in many cases, the supplier is only obliged to honour the original order placed with them. If they receive an amended order or an order cancellation they are not contractually obliged to make a change to the original purchase document. This can leave the University liable to pay for any orders placed, even if the goods or services are no longer required. This makes it even more imperative to get the order/requisition correct in the first instance. It also makes it important the supplier is contacted directly by the Requisitioner or Operational Buyer if a cancellation or amendment is required, as the Supplier is far more likely to respond to the request if it is placed in this way.
AP Requests The primary reason for amendments to approved Purchase Orders will be to rectify differences between the invoice and the order. The Operational Buyers will be responsible for making all amendments to purchase orders raised in their areas. If necessary, they will contact the Requisitioner to get their approval for the amendment (particularly in the case of quantity or price discrepancies). Please see the AP Queries section for more details.
Scenarios
The following process scenarios are incorporated within the Amendments & Cancellation section:
Amending Requisitions Amending Orders Cancelling Requisitions Cancelling Orders
Procurement Process Definition Document 39
Amending Requisitions
Process Justification Up until the point where a purchase order number has been assigned to the requisition, the Requisitioner can make amendments to their own requisitions. This allows them to adapt the requisition for any details they might have missed. Importantly, the Requisitioner cannot add more items to the requisition, unless this is adapting the quantity or price of an existing line. Process Description If the Requisitioner needs to make an amendment to an existing requisition, they access the document from the iProcurement front page. The system will then prompt them to confirm they want to make an amendment. This warning appears as amending any of the details on a submitted requisition will remove it from the approval path and restart the approval process from scratch. If the Requisitioner confirms that they want to make an amendment they are taken through the checkout process. During this, they can make any amendments to any of the fields that were available to them the first time they submitted the requisition: e.g. delivery addresses, charge accounts, items and prices (for non-catalogue requisitions), etc. When they have finished making any amendments, they resubmit the requisition through the approval chain. If any amendments are made to the requisition, this will alter the requisition approval path from the first time it was submitted (only if they change the charge account or amount). If the requisition was removed from the approval chain after the first approver had approved the original document, and this approver is in the new approval chain, they will be required to re-approve the amended requisition. When the amended requisition has been through the approval process, it can be autocreated or autosourced in the same way as any other requisition. Process Controls Amendments can only be made to requisitions with no PO number assigned. All amendments to the requisition will require approval from all the individuals on the original (or revised) approval hierarchy.
Procurement Process Definition Document 40
Amending Requisitions: Process Flow (1 of 2)
Amendment Required
Function Inputs Tasks Deliverables Description
Amending Requisitions
Amended RequisitionRequisitioner
Process for the amendment of requisitions prior to PO creation.
Has an order been assigned?
Requisitioner Yes
No
Amendment required
Amending Orders
Withdraw requisition
from approval workflow
Requisitioner
Make amendment to
requisition
Resubmit requisition for
approval
Requisitioner
Receive notification requesting approval
Approver
Review requisition
details
More information required?
Send note requesting information
Reply with required
information
Approve/Reject?
Send rejection reason to
RequisitionerReject
No
Yes
Yes
Approver
Approver
Requisitioner/Recipient
Approver
The first (or next) Approver in the approval chain will receive a notification via workflow asking them review the requisition.
The Approver opens the notification and reviews the requisition details: e.g. account coding, suitable need, additional approval required, sufficient budget to approve, etc.
In some scenarios, the Approver will require more information before they can approve the requisition. This can be requested from anyone setup on Oracle or from anyone in the requisition approval workflow list.
When the Approver has submitted their request for further information, the recipient (likely to be the Requisitioner) replies with the requested information.
When the Approver has obtained all the information required to make an informed decision about whether to approve the requisition, they approve or reject. If they reject, they send a notification to the Requisitioner detailing the reasons for this.Approve
Requisitioner
If the requisition has been fully approved and the Operational Buyer has created a related PO, the system will prevent any amendments to the requisition (see Amending Orders).
If no order has been assigned, the Requisitioner withdraws the requisition from the approval workflow.
The Requisitioner can amend any of the details available to them at checkout. They cannot add additional lines to the requisition without cancelling and recreating.
When the Requisitioner has made any amendments they require, they resubmit the requisition for approval (this restarts the entire approval process).
Procurement Process Definition Document 41
Amending Requisitions: Process Flow (2 of 2)
Amendment Required
Function Inputs Tasks Deliverables Description
Amending Requisitions
Amended RequisitionRequisitioner
Process for the amendment of requisitions prior to PO creation.
High Level approver required?
Approve
System
Depending on the value of the requisition and the account coding, further approval might be required (see Key Design Decisions). The system will determine this.
No
Yes
Valid CPA in place?
Autocreation Autosourcing
YesNoSystem
If autosourcing has been enabled and there is a valid CPA in place for the supplier, the system will automatically turned the approved requisition into a purchase order. If there is no CPA (or autosourcing has not been enabled) the requisition will fall into the autocreate table for manual processing by the Operational Buyer.
Procurement Process Definition Document 42
Amending Orders
Process Justification If a requisition has already been converted into a purchase order, or a purchase order has been submitted to the supplier, it is not possible for the Requisitioner to amend the order via iProcurement. In these cases, they will have to contact the Operational Buyer who can make the amendment on their behalf. Orders might also have to be amended if an invoice is received that goes on a matching hold because of discrepancies between the price, quantity, tax, etc. Again, it will be the responsibility of the Operational Buyer to make these amendments. Process Description Having received a request to amend an order from a Requisitioner or Central AP, the Operational Buyer verifies the request and then queries the order in core Purchasing. If the request is approved, the Operational Buyer must decide if they need to contact the original requisitioner. If they do, they contact the Requisitioner to confirm the amendment. This will happen particularly in the scenario where the request for an amendment has come from the AP team and the Operational Buyer needs to confirm what was actually received by the Requisitioner. When the Operational Buyer has verified all the details of the amendment request, they make the change to the order, which can then be re-confirmed. For some amendments it will be necessary to resubmit the order to the Supplier. This is not the case for requests received from Central AP to amend the order for matching purposes. Process Controls Amendments to POs can only be completed by the Operational Buyer. However, there is no secondary approval step for amendments to POs.
Procurement Process Definition Document 43
Amending Orders: Process Flow
Amendment Required
Function Inputs Tasks Deliverables Description
Amending Requisitions
Amended Requisition
Operational Buyer
Process for the amendment of approved Purchase Orders.
RequisitionerAmendment
requiredContact
Operational Buyer
Operational Buyer
Valid Amendment
?
Reject request and inform
RequisitionerNo
Amend PO
Yes
Resend PO?
Dispatch amended PO to Supplier
Resubmit PO
Yes
Call supplier?
Yes
Call supplier about change
request.
No
Accept alteration?
Inform Requisitioner of rejection
No
Yes
Operational Buyer
Operational Buyer
Supplier
Operational Buyer
Operational Buyer
Operational Buyer
Operational Buyer
Inform Requisitioner of amended
order
No
In the first instance, the Requisitioner contacts the Operational Buyer to request the amendment to the order.
The Operational Buyer decides if the amendment is really required, or if the order should be cancelled and a new order raised.
Depending on the nature of the change request, the Operational Buyer decides if they should first call the supplier to agree the change before making the amendment to the order.
Cancel Orders
If necessary, the Operational Buyer calls the supplier to agree the change request before amending the order.
The supplier can feasibly reject any amendments to an existing order, particularly those with a long lead-time. If the Supplier rejects, the Operational Buyer calls the Requisitioner to inform them of this fact.
If the supplier agrees to the amendment, the Operational Buyer amends the purchase order.
When any changes have been made, the Operational Buyer resubmits the PO. This does not require approval.
Depending on the nature of the change, the Operational Buyer decides whether the revised PO should be resent to the supplier. If this is required, they dispatch the amended PO by email/post.
Following the completion of all amendments, the Operational Buyer informs the Requisitioner.
Procurement Process Definition Document 44
Cancelling Requisitions
Process Justification If a Requisitioner creates a requisition and subsequently realise that the goods or services are no longer required, they can cancel the requisition from iProcurement assuming the requisition has not had a PO number assigned. If an order number has been assigned, the Requisitioner must contact the Operational Buyer to cancel the order. Please see the Cancelling Orders process. Process Description If the Requisitioner realises that the demand for goods or services they have ordered is no longer required, the access the requisition from iProcurement. As long as no PO number has been assigned to the requisition, they can cancel the requisition and remove it from any in process approval chain. Cancelling a requisition in this way will also reverse any commitment in GL. If the Requisitioner realises that they have cancelled the requisition by mistake, they can copy the requisition and resubmit. Process Controls None identified.
Procurement Process Definition Document 45
Cancelling Requisitions: Process Flow
Cancellation requirement
Function Inputs Tasks Deliverables Description
Cancelling Requisitions
Cancelled RequisitionRequisitioner
Process for the cancellation of requisitions prior to PO creation.
Has an order been assigned?
Requisitioner Yes
No
Cancellation requirement
Cancelling Orders
Withdraw requisition
from approval workflow
Requisitioner
If the requisition has been fully approved and the Operational Buyer has created a related PO, the system will prevent any cancellation of the requisition (see Cancelling Orders).
If no order has been assigned, the Requisitioner withdraws the requisition from the approval workflow.
RequisitionerCancel
Requisition
The requisition can now be cancelled. If necessary, the cancelled requisition can be copied and resubmitted at a later date.
Reverse commitments
SystemThe system will automatically reverse any commitments when the requisition is cancelled.
Procurement Process Definition Document 46
Cancelling Orders
Process Justification If a purchase order has been created that is no longer required, or a line on a PO is not required, a process is required to cancel this Purchase Order/Line and inform the supplier of this alteration. The cancelling of orders as a housekeeping task is described in the Month-End and Close process. Process Description The Operational Buyer will receive an offline request from a Requisitioner to cancel a purchase order. When the request is verified, the Operational Buyer will query the relevant order and cancel the whole document or just the line that is no longer required. Having cancelled the order, the Operational Buyer must decide whether to communicate this to the supplier. If the PO has not been dispatched, there is no need to contact the supplier to inform them of the cancellation. If the PO has been dispatched, and the supplier is expected to deliver on the order, they must call the supplier to inform them of the cancellation. In cancelling the order, any encumbrances are reversed automatically by the system. The original requisition is also cancelled. Process Controls Orders cannot be cancelled if they have been matched to an invoice or goods receipted. If they are only partially matched, the outstanding amount or lines can be cancelled. Cancelling purchase orders will also cancel the requisition and reverse any encumbrances.
Procurement Process Definition Document 47
Cancelling Orders: Process Flow
Cancellation requirement
Function Inputs Tasks Deliverables Description
Cancelling Orders
Cancelled Order
Operational Buyer
Process for the cancellation of requisitions after PO creation.
RequisitionerCancellation requirement
If the Operational Buyer has created a PO for the requisition, the system will prevent any cancellation of the requisition from iProcurement. The Requisitioner must contact the Operational Buyer to perform this on their behalf. This is offline.
Contact Operational
Buyer
Contact Requisitioner
Has the order been invoiced?
Has the order been receipted?
No
ReturnsYes
SystemRequest
payment hold (if applicable)
Yes
No
Call supplier?
Call supplier about
cancellation
Yes
Cancel PO
Accept Cancellatio
n?
Inform Requisitioner of rejection
No
Yes
Reverse commitments
System
Operational Buyer
Operational Buyer
Supplier
Operational Buyer
Operational Buyer
System
If the order has already been matched to an invoice then it cannot be cancelled. If there is a remaining amount then that amount can be closed/cancelled. If a payment hold is required, the Requisition contacts Central AP to request this.
If the order has been receipted, the receipt must be corrected or a return entered before the order can be cancelled.
The Operational Buyer must decide whether to call the supplier about the order cancellation. If the supplier has never received the order, there is no need to contact them.
No
If required, the supplier is contacted to inform them of the intention to cancel the order.
The supplier can feasibly reject the request. If so, the Operational Buyer contacts the Requisitioner to inform them of this.
If the supplier agrees to the order cancellation (or there is no need to contact them) the Operational Buyer cancels the order in Oracle. This will also cancel any requisitions associated with the order.
When cancelled, the Operational Buyer contacts the Requisitioner to inform them.
The system will automatically reverse any commitments created for the cancelled documents.
Procurement Process Definition Document 48
Receiving & Returns
Overview
The receiving process is critical to the whole of the P2P process. The receiving process ensures that the University only pays for goods and services that are ordered and which have actually been supplied. It will ensure that invoiced goods and services are reconciled within Accounts Payables against the order and delivery information (3-way matching), enable delivery tracking and support execution of payments within agreed terms. Orders that have been goods receipted but not invoiced is also the basis for the University’s accruals process. The returns process is available for goods that have been received but are defective and need to be returned to the supplier for a replacement or refund. This section does not include receiving conducted by the goods-in functions within the University
Key Design Decisions
Receiving Access To allow the goods-in function to work and the Operational Buyers to receipt orders on behalf of Requisitioners, it is necessary to give users access to receipt all orders in the system, not just those which they have raised. Receipt Reminders The P2P project is exploring the possibility of sending automated receipt reminders in Oracle. These will be generated based on the need-by date entered at the requisition stage and will be sent to the Requisitioner reminding them that they need to receipt. The issues around goods-in functions receipting on behalf of requisitioners needs to be investigated prior to implementing this change.
Scenarios
The following process scenarios are incorporated within the Receiving & Returns section:
Desktop Receiving Buyer Receiving Returns
Procurement Process Definition Document 49
Desktop Receiving
Process Justification This process allows Requisitioners to receipt requisitions they have raised in iProcurement. All Requisitioners will be strongly advised how important the receiving process is to the follow-on P2P process (accruals and invoice processing). This process will also be utilised when Stores receipt on behalf of Requisitioners. Process Description Upon receipt of goods or services, the Requisitioner logs into iProcurement and queries the relevant requisition. They must first verify that anything received is of sufficient quality and the same amount as was originally ordered. If they are satisfied with that the items or services received are correct, they enter a goods receipt on the system. When an invoice is received for this order, it can be matched successfully. For goods received by the goods-in team, the order will already have been receipted. In this scenario, the requisitioner will not be able to duplicate the receipt. For call-off orders that are set to 3-way matching, the prompt to receipt the order is likely to come from the Central AP team upon receipt of the invoice. The Requisitioner should use this reminder to verify the invoice and then enter a receipt for the corresponding amount. Process Controls The Requisitioner is warned if they attempt to over receipt an order, although this is allowed by the system. On attempting to enter an invoice against this requisition, the invoice will go on hold if the order has not also been amended by the Operational Buyer to reflect the over receipt. The tolerance for this is set to 10% of the original order value. If invoices are received and no receipt has been entered on the system, the invoice will go on hold. AP will send a reminder to the Operational Buyer in the first instance to get this resolved. Please see the Buyer Receipts process for more details. If an order is over/under receipted the receipt can be corrected in Oracle to prevent any invoice discrepancies.
Procurement Process Definition Document 50
Desktop Receiving: Process Flow
Function Inputs Tasks Deliverables Description
Goods/Services Received
Desktop Receiving
Goods Receipt NoteRequisitioner
Process for the creation of goods receipt notes by requisitioners for approved orders.
Requisitioner
Goods/Services Received
Enter a receipt for the items/
services received
Damaged/Faulty?
No
Invoice Entry
If the items haven’t already been receipted, the Requisitioner enters a goods receipt for the amount or quantity received.
Perform quality check
Over/Under Supplied?
UnderContact supplier
Over Returns
Correct
Requisitioner
Yes Returns
Requisitioner
Requisitioner
If the supplier has over supplied, then the Requisitioner returns the extra items. If the supplier has under supplied the Requisitioner contacts the supplier to request the remaining items.
Having entered the receipt and verified the amounts received, the Requisitioner performs a quality check on the items received.
If the items are damaged or faulty, the Requisitioner returns the items to the supplier.
If the items are correct, the Requisitioner need take no further action. When the invoice is received, it will match successfully assuming it matches the order and receipt.
Already Receipted?
Take no actionYes
No
If the goods or services have already been received (e.g. by stores), there is no need for the Requisitioner to take any action (this is also true if the order is set to 2-way match).
Requisitioner
Procurement Process Definition Document 51
Buyer Receipts
Process Justification If a PO invoice is received that goes on a receipt matching hold, the Central AP team will initially contact the Operational Buyer of the order to receipt the order. The aim of this process is to speed up the receipt hold resolution process as it should be faster for the Operational Buyer to resolve the hold, than AP having to contact the original Requisitioner. Process Description Upon receipt of a PO invoice that goes on a receipt matching hold, the Operational Buyer will be sent a notification by the AP team using the Remedy service desk tool. This notification will ask them to verify receipt of the goods/services with the Requisitioner. If the Requisitioner has received the items the Operational Buyer will enter a goods receipt on their behalf and inform the AP team that this has been done by responding to the email sent from Remedy. If the Requisitioner has not received the goods or services, the Operational Buyer will respond to the reminder informing the AP team. They will then monitor the status of the goods/services and enter a goods receipt when they have been received. They will inform the AP team when this has been completed by responding to the Remedy incident notification. Process Controls Operational Buyers will be instructed to contact the Requisitioner to verify the status of the goods/services before entering a goods receipt on their behalf. If more appropriate (e.g. in the case of a call-off order), the Operational Buyer can ask the Requisitioner to enter a goods receipt on their behalf. The most appropriate method will be left up to the Buyer. If an order is over/under receipted the receipt can be corrected in Oracle to prevent any invoice discrepancies.
Procurement Process Definition Document 52
Buyer Receipts: Process Flow
Function Inputs Tasks Deliverables Description
Invoice on Hold
Buyer Receipts
Matched Invoice
Operational Buyer
Process for the creation of goods receipt notes by Operational Buyers where the invoice is on Receipt Hold.
Operational Buyer
Hold Resolution Request
Enter a receipt for the items/
services received
Damaged/Faulty?
No
Inform AP
Perform quality check
Over/Under Supplied?
UnderContact supplier
Over Returns
Correct
Requisitioner
Yes Returns
Requisitioner
Requisitioner
If the supplier has over supplied, then the Requisitioner returns the extra items. If the supplier has under supplied, the Requisitioner contacts the supplier to request the remaining items.
Having verified the amounts received, the Requisitioner performs a quality check.
If the items are damaged or faulty, the Requisitioner returns the items to the supplier.
Following the finalisation of the receipt amount, the Operational Buyer informs AP that the hold should release.
If an invoice is on hold because no goods receipt has been entered, the Operational Buyer is sent a Remedy incident asking them to resolve the hold. They first contact the Requisitioner to confirm if the goods/services have been received.
Operational Buyer
Contact Requisitioner
to verify receipt
Goods/services
received?
Inform AP and track progress
No
Yes
If the goods or services have not been received, the Operational Buyer informs AP and monitors the hold.
Operational Buyer
If the goods or services have been received, the Operational Buyer enters a goods receipt on behalf of the Requisitioner. This can be done in iProcurement or core Purchasing.
Operational Buyer
Procurement Process Definition Document 53
Returns
Process Justification If goods are received that are faulty, the Requisitioner or Stores must enter a return on the system before returning the items to the supplier. If the supplier is going to send replacement items then the Requisitioner should enter a normal goods receipt when the items are received. If the supplier is not going to send replacement items then the Requisitioner must inform AP that they should not pay any invoice that might be received. Any orders received by the goods-in function that require a return will be dealt with by this team as per the current process. Process Description As with the receiving process, when the Requisitioner receives the goods they have ordered they must enter a goods receipt on the system. Having entered a goods receipt they must perform a quality check to ensure everything is of the correct standard. If the goods are faulty or the supplier has sent the wrong items, the Requisitioner must enter a return in Oracle against their receipt. The Requisitioner must also enter a reason for the return (e.g. Faulty Goods), a Return Material Authorisation (if available) and any additional comments. The goods should then be physically returned to the supplier and the Requisitioner should contact them to inform them of the returned items. It is up to the Requisitioner to decide if they want the supplier to send them replacement items. If they would prefer not to receive a replacement, the Operational Buyer should be contacted who can cancel the order and the supplier should be told of the cancellation. If the Requisitioner requests that the supplier resends the items, then they wait until the items are received before altering the original receipt (if the items are satisfactory). Process Controls As long as a return has been entered, any 3-way matching invoice will not be paid until the receipt has been altered following the receipt of the correct items.
Procurement Process Definition Document 54
Returns: Process Flow
Function Inputs Tasks Deliverables Description
Unwanted Items Returns
Items returned to supplierRequisitioner
Process for return of unwanted or faulty items.
RequisitionerUnwanted
Items
If a Requisitioner has received items that are faulty, or the supplier has over supplied, they must enter a return in Oracle. This will reduce the receipt amount so the invoice will only be paid for the items of the correct items
Enter Return
Having entered a return, the Requisitioner must return the physical items to the supplier. In the case of services, the Requisitioner should correct the receipt rather than enter a return.
RequisitionerReturn items to supplier
RequisitionerVerify final
receiptThe Requisitioner verifies the final receipt quantity to ensure it is correct.
Replacement required?
YesDesktop
Receiving
The Requisitioner must decide if they want a replacement for any faulty items. If they do, they should contact the supplier and await the items in the normal way.
No
Requisitioner
Cancelling Orders
Operational Buyer
If the Requisitioner does not want a replacement, they should contact the Operational Buyer to get the remaining order cancelled.
Procurement Process Definition Document 55
Queries
Overview
As part of the new target operating model for Procurement, the new Operational Buyer community will become the procurement process experts for their area. As part of this role, they will be expected to deal with any queries coming from the Requisitioners in their area and resolve any hold resolution issues sent to them by the AP team. Supplier queries will, in the majority of cases, be dealt with in the first instance by the Requisitioner or Central AP, depending on the nature of the query. AP queries are covered in the AP PDD. As the volumes of queries received by individual Operational Buyers should be quite small, a dedicated query resolution tool has not been provided to these users. As a result, all queries will be dealt with offline. The only exception to this, are queries received from the Central AP team that will be created and managed using Remedy. The Operational Buyers will not have access to this tool.
Key Design Decisions
Primary Contact The Operational Buyer will be the primary contact for all hold resolution requests sent by Central AP. Although the Requisitioner could also deal with these issues, it is expected that making the Operational Buyers responsible for resolving these issues will speed up the hold resolution turnaround times.
Scenarios
The following process scenarios are incorporated within the Queries section:
Supplier Queries Internal Queries AP Queries
Procurement Process Definition Document 56
Supplier Queries
Process Justification Supplier queries tend to fall into two categories, those related to the order and those related to invoicing and payment. If the query is related to the order: e.g. seeking confirmation of delivery address, item amendments, etc., the supplier will tend to contact the Operational Buyer listed on the order. A process is needed so that the Operational Buyer can respond or forward these queries in an efficient manner. Process Description Upon receiving the query from the supplier, the Operational Buyer must decide if they are able to resolve the query immediately or following a check on the order in Oracle. If they can resolve the query themselves, they will do so. If the query is payment related, the Operational Buyer will forward the supplier onto the Central AP team. Process Controls None identified.
Procurement Process Definition Document 57
Supplier Queries: Process Flow
Supplier Query
Function Inputs Tasks Deliverables Description
Supplier Queries
Query Resolved
Operational Buyer
Process for the resolution of supplier queries.
SupplierQuery
Nature of query?
If a supplier has a query, they will tend to contact the Operational Buyer, if it’s an order related query, or the Central AP team if it’s related to invoicing or payments.
Contact Central AP
Payables
Contact Operational
Buyer
Procurement
Resolve Query
Supplier
Queries
Supplier
Central AP/ Operational
Buyer
Upon receiving the query, the Operational Buyer or Central AP team proceed to resolve the query. For the AP query resolution process, please see the AP PDD.
Procurement Process Definition Document 58
Internal Queries
Process Justification Numerous queries are likely to be raised from within the University. These can be on many subjects but tend to relate to training requirements, procurement queries or technical issues. As their role as the procurement expert for their area, the Operational Buyers need a process to efficiently manage the resolution to these issues. The process for resolving internal queries is off-system. Process Description When a Requisitioner has a query regarding iProcurement or the procurement process in general, they will contact the Operational Buyer for their area. A number of links have been added to the iProcurement pages to try and reduce the volume of these queries. When the Operational Buyer receives the query they will attempt to resolve it by directing the Requisitioner to training materials or answering any process related questions. In the event that the query is technical (e.g. password resets, error messages), the Operational Buyer will refer the Requisitioner towards the Oracle Support Team who will resolve the issue. If the query relates to invoicing or payment, the Operational Buyer will refer the Requisitioner to the Central AP helpdesk. Process Controls None identified.
Procurement Process Definition Document 59
Internal Queries: Process Flow
Internal Query
Function Inputs Tasks Deliverables Description
Internal Queries
Query ResolvedRequisitioner
Process for the resolution of internal queries from Requisitioners
RequisitionerQuery
When the Requisitioner has a query, they should first check iProcurement and any of their enquiry/reporting responsibilities to try and resolve the issue for themselves
Check iProcurement
Nature of query?
If the query relates to invoices or payments, the Requisitioner contacts the Central AP Helpdesk. If the query is procurement related, they contact the Operational Buyer for their area. If the query is technical, they contact the Oracle Support Team.
Requisitioner
Central AP/ Oracle
Support team/
Operational Buyer
The Central AP team, Oracle Support team or the Operational Buyer resolve the Requisitioner’s query.
Query resolved?
No
Take no actionYes
If the Requisitioner has resolved their query without seeking outside help, there is no further action to take. If they cannot resolve the query, they must decide what further action to take.
Requisitioner
Contact Central AP
Payables
Contact Operational
Buyer
Procurement
Resolve Query
Resolve Query
RequisitionerContact
Operational Buyer
Technical
Resolve Query
Procurement Process Definition Document 60
AP Queries
Process Justification Part of the Operational Buyer’s role is to deal with hold resolution issues from the AP team. Please refer to the Hold Resolution process in the AP PDD for details. Process Description Process Controls
Procurement Process Definition Document 61
AP Queries: Process Flow Please refer to the Hold Resolution process in the AP PDD for details.
Procurement Process Definition Document 62
Supplier Maintenance
Overview
A key element of the AP process review has been to ensure adequate segregation of duties. One of the key elements is the segregation of supplier creation and bank detail maintenance. To ensure adequate controls in this area, the supplier creation and maintenance process has been moved to the Central Procurement Office. The bank detail maintenance has been moved to the Payments Team in the new Central AP function. An extra advantage of moving the supplier maintenance function to the Central Procurement Office is the opportunity for this team to take control of the supplier base and make more informed decisions about whether a supplier should be setup and if any contract negotiations need to take place.
Key Design Decisions
New Supplier Setup Requests Requisitioners will be directed as part of their training (and via link in iProcurement) to an offline supplier setup request form. This form is intended to reduce the workload for the Central Procurement Office by getting the Requisitioner to gather the majority of the data required for supplier setup. The supplier setup form will be added to the Procurement intranet pages. A copy is attached below:
New Supplier Request Form.doc
Credit Checks The Supplier Maintenance Clerk will be expected to perform credit checks on all new supplier requests where the purchase value, or expected annual expenditure, is greater than £100k. If a supplier fails the credit check then the supplier setup request will be rejected. Dun and Bradstreet will be used for these credit checks. Tendering and Contracts As a primarily operational document, the details of the tendering and contracts processes conducted by the Central Procurement Office are not included in this document. These processes are, however, referenced in the supplier setup process. Supplier Naming Convention To ensure consistency in the supplier database, all supplier names setup in Oracle will be the full legal entity name of the supplier, exactly as it is written by the supplier, with no abbreviations and in block capitals. Supplier numbering is the first four letters of the supplier name, followed by a four digit sequential number. Example: Supplier Name: BRITA WATER FILTER SYSTEMS LTD Supplier Number: BRIT0001 Supplier Name: BRITISH GAS PLC Supplier Number: BRIT0002
Procurement Process Definition Document 63
Scenarios
The following process scenarios are incorporated within the Supplier Maintenance section:
Supplier Setup Supplier Deactivation Supplier Merge Supplier Updates
Procurement Process Definition Document 64
Supplier Setup
Process Justification A process is required to allow users out in the University to request the setup of new suppliers. Importantly, this setup process must also consider the strategic aims of the Central Procurement Office to reduce the supplier base and increase contracted spend. New supplier requests will also be received by the AP team in the event that they receive a non-PO invoice that cannot be paid using the sundry supplier account. Process Description In the event that a Requisitioner cannot find a supplier catalogue for the goods or services they want to buy, and the supplier they want to use cannot be found from the non-catalogue request form, they will be directed (via a link on iProcurement) to the new supplier request form. They will then proceed to gather the information required to fill in this form. When the form has been completed, the Requisitioner will send this to the Operational Buyer in their area for review. The Operational Buyer will vet the request to ensure that an alternative, existing supplier wouldn’t be more appropriate or the purchase would be better made using a p-card. If the request is genuine and a p-card cannot be used, the Operational Buyer will make sure the request form is complete before forwarding this to the Supplier Maintenance Clerk. The Supplier Maintenance Clerk performs a quick check on the request and sends to a Senior Procurement Officer for review. The Senior Procurement Officer also makes sure that there are no alternative suppliers who are already setup on Oracle who would be suitable for the purchase. If there are no alternatives, the Senior Procurement Officer determines if tendering is required. If so, the tendering process is launched and a preferred supplier selected. This Senior Procurement Officer then goes through contract negotiation to ensure the supplier agrees to the University terms and conditions and the details of the supplier relationship are acceptable. If these negotiations fail, then the tendering process restarts, or an alternative supplier from the first round of tendering is selected. When a supplier contract has been agreed, if the purchase is greater than £100k, the Supplier Maintenance Clerk performs a credit check. If this fails, then the tendering process restarts, or an alternative supplier from the first round of tendering is selected. When the supplier has passed the credit check (if required) the Supplier Maintenance Clerk contacts the Supplier to request that they: send their bank details on headed note paper to the AP team for setup; agree to the University’s Terms and Conditions; and fill in an equality questionnaire. If the supplier refuses to send their bank details, the clerk will tell the AP team to setup the supplier with a payment method of cheque (this will be strongly discouraged). The supplier can now be setup on Oracle by the Supplier Maintenance Clerk. When the supplier is setup in Oracle, the Supplier Maintenance Clerk completes the admin section of the request form and informs the Requisitioner and Operational Buyer that the supplier is setup for purchasing. New supplier requests will also be received from the AP team where they receive a non-PO invoice from a supplier that is not rejected and cannot be paid using the sundry supplier account. The request for these suppliers will go directly to Central Procurement and will be put on a fast track (1 day turnaround) to speed up the invoice processing times. Suppliers created in this way will be setup with an end-date to ensure that they are not left open without going through the formal supplier setup process.
Procurement Process Definition Document 65
Process Controls Only the AP team have access to create and maintain supplier bank details. Please see the AP PDD for details. Only the Central Procurement Office will have access to create supplier records.
Procurement Process Definition Document 66
Supplier Setup: Process Flow (1 of 3)
New Supplier Setup
Request
Function Inputs Tasks Deliverables Description
Supplier SetupNew Oracle
SupplierSupplier
Maintenance Clerk
Process for the creation of new suppliers in Oracle
Operational Buyer
New Supplier Setup
Request
Review new supplier request
Alternative supplier
available?
Reject Request
Yes
No
Request form
complete?
No
Return request for completion
Complete Request
Yes
Send request to Supplier
Maintenance Team
Operational Buyer
Operational Buyer
Operational Buyer
Operational Buyer
The Operational Buyer will review all new supplier requests sent by Requisitioners in their area.
The Operational Buyer checks that there are no alternative suppliers already setup in Oracle that would be suitable for the purchase. If there is an alternative supplier, or it already exists under a different name, they inform the Requisitioner and reject the request.
If there is no alternative supplier, the Operational Buyer checks that the new supplier request form is complete. If it is not complete, they return the form to the Requisitioner to correct.
When the request form is complete, the Operational Buyer forwards the form onto the Supplier Maintenance Team.
Operational Buyer
If the value of the request is under £250 and the purchase is one-off, the Operational Buyer might choose to make the purchase using their P-Card.
P-card suitable?
P-Card Purchases
Yes
No
Send to Senior
Procurement Officer
Supplier Maintenance
Clerk
The Supplier Maintenance Clerk checks the request’s validity and forwards onto a Senior Procurement Officer for review.
Senior Procurement
Officer
The Senior Procurement Officer checks that there are no alternative suppliers already setup on Oracle which would be suitable for the purchase. If there is an alternative, they reject the request and inform the Operational Buyer and Requisitioner.
Alternative supplier
available?
Reject Request
Yes
No
Procurement Process Definition Document 67
Supplier Setup: Process Flow (2 of 3)
New Supplier Setup
Request
Function Inputs Tasks Deliverables Description
Supplier SetupNew Oracle
SupplierSupplier
Maintenance Clerk
Process for the creation of new suppliers in Oracle
Senior Procurement
Officer
The Senior Procurement Officer determines if a formal tendering process is required for this purchase.
Tendering Required?
No
Yes
No
Launch Tendering Process
Select Supplier
Contract Negotiations
Negotiationsuccessful?
No
If the supplier contract negotiation or tendering is not successful, then the tendering process starts again, or an alternative supplier from the initial process is selected.
Senior Procurement
Officer
Requisitioner
Senior Procurement
Officer
Senior Procurement
Officer
Yes
Purchase > £100k?
Supplier Maintenance
Clerk
Yes
Perform Credit Check
Supplier Maintenance
Clerk
Passed?
Yes
Supplier Maintenance
Clerk
If formal tendering is required, the Senior Procurement Officer launches the tendering process.
Having completed the tendering process, the Requisitioner and Senior Procurement Officer selects the preferred supplier.
The Senior Procurement Officer is responsible for supplier contract negotiations and ensuring the supplier signs up to the University’s terms and conditions.
If the one-off, or annual contract value, is greater than £100k, then a supplier credit check is required.No
The Supplier Maintenance Clerk performs a credit check on the supplier.
If the supplier fails the credit check, then the tendering process starts again, or an alternative supplier from the initial process is selected.
Procurement Process Definition Document 68
Supplier Setup: Process Flow (3 of 3)
Setup Supplier in Oracle
New Supplier Setup
Request
Function Inputs Tasks Deliverables Description
Supplier SetupNew Oracle
SupplierSupplier
Maintenance Clerk
Process for the creation of new suppliers in Oracle
Yes
Supplier Maintenance
Clerk
Send forms to Supplier
Supplier Maintenance
Clerk
Supplier Bank Detail
Maintenance
Finalise Request Form
Inform Requisitioner & Operational
Buyer
Supplier Maintenance
Clerk
Supplier Maintenance
Clerk
When the original supplier (or a supplier selected during tendering) is approved and the credit check has been performed (if applicable) the Supplier Maintenance Clerk contacts the supplier and requests that they: send their bank details on headed notepaper to the AP team; agree to the University’s T&Cs; and fill in an equality questionnaire.
When the supplier setup is complete, the Supplier Maintenance Clerk informs the Requisitioner and Operational Buyer that they can now order from the supplier.
When the supplier has been contacted, the Clerk creates the supplier record in Oracle.
The Supplier Maintenance Clerk finalises the request form and scans it into Oracle.
No
Create Requisitions
Procurement Process Definition Document 69
Supplier Deactivation
Process Justification Suppliers that are underperforming, or are inactive, need to be end-dated to remove them from the order and invoice entry screens. Requests to deactivate underperforming suppliers will be received and processed on an ad hoc basis by the Supplier Maintenance Clerk. Inactive suppliers will be identified from the Suppliers not Used (UOM) report run on a monthly basis by the Supplier Maintenance Clerk (please see the Month-End & Close process for details). Process Description If a supplier is not performing to contract terms or is no longer required, the supplier record must be deactivated. Requests to do this will be received on an ad hoc basis from the AP team, the Central Procurement Office and from the Operational Buyer community. Upon receipt of this request, the Supplier Maintenance Clerk will verify that it is genuine. This will involve consulting with a Senior Procurement Officer. If the request is valid, the clerk disables the supplier for purchasing before closing down any open orders and invoices. When all the open items have been closed or paid, the Supplier Maintenance Clerk adds an end-date to the supplier record. To keep a track of the reasons for the supplier closure, they will also add a short-text attachment to the supplier header/site with the reasons for the closure. The Supplier Maintenance Clerk will also check to make sure that there is no supplier catalogue or store associated with the supplier in iProcurement. If there are specific supplier references in iProcurement, the Supplier Maintenance Clerk will highlight this to the catalogue maintenance team who will remove these. Process Controls Only the Central Procurement Office will have access to deactivate or reactivate supplier records. In the event that a supplier is utilised by a single area of the University, the Supplier Maintenance Clerk will contact the Operational Buyer for this area to confirm the supplier is no longer required. They will identify this by looking at who has ordered from the supplier.
Procurement Process Definition Document 70
Supplier Deactivation: Process Flow
Supplier Deactivation
Request
Supplier Deactivation
Request
Function Inputs Tasks Deliverables Description
Supplier Deactivation
Supplier record
deactivated
Supplier Maintenance
Clerk
Process for the deactivation of suppliers no longer required or in breach of contract.
Supplier Maintenance
Clerk
Chase open item closure
If the request is valid, the Clerk will disable the supplier site for new orders.
Open Orders/
Invoices?
Close open items
Yes
Remove iProcurement
content
Catalogues/Stores?
Yes
Add inactive date to
supplier site/header
No
Disable Supplier Site for Invoicing
Disable Supplier Site for Ordering
If there are any open invoices or purchase orders against the supplier, these must be closed down prior to deactivating the supplier. The Supplier Maintenance Clerk will chase the closure of these items with the Central AP Team (invoices) and the Operational Buyers (orders).
When all open items have been cleared, the Supplier Maintenance Clerk will disable the supplier for invoicing.
If there is any supplier specific content in iProcurement (stores or catalogues) these must be removed by the Central Procurement Team.
When all supplier information has been removed from iProcurement, the Supplier Maintenance Clerk can add an end-date to the supplier. For future reference, they will also add a short-text attachment explaining the reason for the deactivation.
Supplier Maintenance
Clerk
Supplier Maintenance
Clerk
Supplier Maintenance
Clerk
Central AP/ Operational
Buyer
Central Procurement
If a supplier is no longer required or is in breach of contract terms, a request will be sent to the Supplier Maintenance Clerk asking them to deactivate the supplier. Initially the Clerk will verify the request and seek guidance form a Senior Procurement Officer.
Valid Request?
Reject Request
No
Yes
Supplier Maintenance
Clerk
Procurement Process Definition Document 71
Supplier Merge
Process Justification If a supplier record is accidentally duplicated in the existing supplier database or in error by the Supplier Maintenance Clerk, a process is required to merge these two supplier records. Process Description Having identified if a supplier record has been duplicated by mistake, the Supplier Maintenance Clerk reviews the supplier sites to see what items should be copied across. They also check to see which sites have open invoices or orders. Whichever site has the least open documents should be merged into the other site. When they have verified the setup and data of the two suppliers, they run the supplier merge program to transfer all documents across and close the duplicate supplier record. Process Controls Only the Central Procurement Office will have access to merge supplier records.
Procurement Process Definition Document 72
Supplier Merge: Process Flow
Duplicate Suppliers
Function Inputs Tasks Deliverables Description
Supplier Merge
Single Supplier Record
Supplier Maintenance
Clerk
Process for the merge of duplicate suppliers.
Supplier Maintenance
Clerk
As part of their daily tasks, the Supplier Maintenance Clerk will be responsible for ensuring the integrity of the supplier database, this includes identifying duplicate supplier records.
Identify duplicate suppliers
Identify primary supplier record
Start supplier merge
Supplier Maintenance
Clerk
Supplier Maintenance
Clerk
Transfer supplier items
System
If the Supplier Maintenance Clerk finds a duplicate record, they must first identify the primary supplier record. They will do this based on the volume and recent history of orders/invoices.
Having identified the primary supplier record, the Supplier Maintenance starts the supplier merge program.
The system will automatically transfer open (and closed if required) items to the primary supplier site. It will also add an inactive date to the duplicate site.
Procurement Process Definition Document 73
Supplier Updates
Process Justification Updates to supplier data is likely to be received from two sources, the supplier and Central AP. A process is required to manage these requests. Process Description Dealing with supplier data amendments will be dealt with by the Central AP team and the Supplier Maintenance Clerk depending on the nature of the request. Anything related to the supplier’s bank or payment details will be maintained by the Payments team in AP. All other supplier data will be amended by the Supplier Maintenance Clerk. Upon receiving a request for an amendment, the Supplier Maintenance Clerk will vet the request to ensure it is valid. If the request is genuine, the Supplier Maintenance Clerk will make the amendment in Oracle and attach any back up documentation to the supplier header/site if applicable. Process Controls All updates to the supplier will be audited by Central AP during the payments process. Please see the Batch Payment Process in the AP PDD for details.
Procurement Process Definition Document 74
Supplier Updates: Process Flow
Supplier Update Request
Function Inputs Tasks Deliverables Description
Supplier Updates
Updated Supplier Record
Supplier Maintenance
Clerk
Process for ongoing maintenance of active supplier records.
Supplier Maintenance
Clerk
Supplier Update Request
Verify Request
Make update
Bank Details
Update?Yes
Supplier Bank Detail
Maintenance
No
Inform requester (if
required)
Supplier Maintenance
Clerk
Supplier Maintenance
Clerk
Central AP
Supplier update requests will be received from the Supplier, Operational Buyers, Requisitioners and Central AP.
If the supplier update request is related to the suppliers bank or payment information, these requests will be forwarded to the Central AP team.
For all other update requests, the Supplier Maintenance Clerk will make the update to the supplier record.
If required, the Supplier Maintenance Clerk informs the individual who requested the supplier change.
Procurement Process Definition Document 75
Month-End & Close
Overview
Although not a formal financial month-end process, it is important that the housekeeping is performed and the periods are closed for the Purchasing module. This ensures data integrity, removes obsolete records and helps to prevent retrospective ordering. Month-end is also a good time to review the other key purchasing metrics and produce any reporting packs for management review.
Key Design Decisions
PO Closure Criteria Part of the month-end process for procurement will be to manually close any open POs that will never be fully matched to an invoice. The following criteria will be used to determine which open POs should be pursued by the Operational Buyers for closure:
No invoice, no receipt, PO creation date is greater than 90 days ago and the need-by date is not in the future.
OR Amount received or invoiced is greater than 80% of the net PO amount and the
PO creation date is greater than 90 days POs that meet any of these criteria will be flagged using the PO6-Outstanding orders report in Discoverer. They will then be queried with the requester and closed as required. If no response is received, the PO will be closed by the Operational Buyers. Supplier Closure Criteria Part of the month-end process for procurement will be to deactivate any suppliers that are inactive. The following criteria will be used to determine which suppliers should be closed:
No invoices entered for over 13 months AND
No purchase orders entered for over 13 months AND
Supplier created over 13 months ago AND
Closing the supplier site will not leave a single order/pay site with no corresponding order/pay site.
The Supplier Maintenance Clerk will run the Suppliers not Used (UOM) report to identify these suppliers. If any orders or invoices are still open against these sites the clerk will contact the Operational Buyer or Invoice Entry Clerk to get the document paid or closed.
Scenarios
The following process scenarios are incorporated within the Month-End & Close section:
Month-End & Close
Procurement Process Definition Document 76
Month-End & Close
Process Justification This process is designed to ensure the integrity of transactional data and as an opportunity to review any of the key procurement metrics. Process Description A few days prior to the end of the month, the Operational Buyers review any open orders in the system that meet the PO closure criteria (see Key Design Decisions). For any orders that are identified from the PO6-Outstanding Orders report the Operational Buyer will contact the Requisitioner to find out if the order is still required. If the order is still required, the Operational Buyer will leave the order and monitor it in future periods. If the order is no longer required, the Operational Buyer cancels the order and any associated requisition lines. Oracle will automatically reverse any encumbrances. At a similar time each month, the Supplier Maintenance Clerk runs the Suppliers not Used (UOM) report to identify any supplier sites/headers that can be deactivated. When a supplier is identified, they verify that there are no open invoices or orders for the supplier. If there are no open orders or invoices, the supplier site will be closed. If there are open orders, they contact the Operational Buyer for the order to get it closed. If there are open invoices, they contact the Central AP team who will be able to resolve these issues. Following the closure of the invoices/orders, the Supplier Maintenance Clerk adds an inactive date to the supplier site. On the last day of the month the Central Procurement Office run any reports required to monitor the procurement process and compliance levels. The Purchasing Period is closed by the Financial Processing Manager, Financial Accountant or Financial Controller depending on who is performing month-end. This will not be altered from the existing process. Process Controls Only the Financial Processing Manager, Financial Account or Financial Controller can close the purchasing periods. Periodically, the Central Procurement Office will review the Outstanding Orders reports to ensure that the Operational Buyers are performing their housekeeping duties.
Procurement Process Definition Document 77
Month-End & Close: Process Flow
Month-End
Function Inputs Tasks Deliverables Description
Month-End and Close
Data IntegrityCentral Procurement
Process for the month-end procurement data maintenance and reporting.
Operational Buyer
Review open POs
POs to close?
YesContact
Requisitioner
Close PO
Operational Buyer
Supplier Maintenance
Clerk
No
Review Inactive
Suppliers
Inactive Suppliers?
YesSupplier
Deactivation
Run procurement performance
reports
Supplier Maintenance
Clerk
Central Procurement
No
Close/Open Purchasing
Periods
Financial Processing Manager
Several days prior to month-end, the Operational Buyers will review all open orders for their area.
If there are any open POs that meet the closure criteria (see Key Design Decisions), the Operational Buyer will contact the Requisitioner to verify the order is no longer required, and then any POs not required.
Also prior to month-end, the Supplier Maintenance Clerk reviews the inactive supplier report to identify any supplier records that can be closed.
If any supplier records are identified, the Supplier Maintenance Clerk follows the Supplier Deactivation process to close the records.
After these activities have been completed, the Central Procurement team run any procurement performance reports and distribute these as required.
The formal close of the old purchasing period and open of the new period will be performed by the Financial Processing Manager as part of the finance month-end. Note this task will also be performed by the Financial Accountant or Financial Controller depending on who is performing month-end.
Procurement Process Definition Document 78