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


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


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.


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)


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.


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


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.


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.


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


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.


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.


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


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?


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.


Catalogue Requisitions: Process Flow (1 of 2)

Demand

Function Inputs Tasks Deliverables Description

Identify need for goods/services

Requisitioner


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.


Catalogue Requisitions: Process Flow (2 of 2)

Demand


Receive notification requesting approval

Approver



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.


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


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.


Non-Catalogue Requisitions: Process Flow (1 of 3)

Demand



Requisitioner

Non-Catalogue

Requisitions


Process for the creation and approval of non-catalogue requisitions



Yes

No

Fill in required item

information

Is additional information required?

No

Yes

Fill in information


information

Requisitioner

Requisitioner

Requisitioner

Requisitioner

Requisitioner


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



Demand



Approver

Non-Catalogue

Requisitions


Review requisition

details



Reply with required

information

Approve/Reject?


RequisitionerReject

No

Yes

Yes

Approve

Approver

Approver


Approver

Submit for approval

Requisitioner


The first Approver in the approval chain will receive a notification via workflow asking them review the requisition.






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.




Demand


Non-Catalogue

Requisitions


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)


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


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.


P-Card Purchases: Process Flow (1 of 2)

Demand



Requisitioner

P-Card Purchases

Goods OrderedRequisitioner

Process for the purchase of goods and services using p-cards.



Yes

No

Requisitioner


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


P-Card Purchases: Process Flow (2 of 2)

Demand


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.


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.


Call-Off Orders: Process Flow (1 of 3)

Demand


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


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?


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



Demand


Call-Off Orders




Approver

Review requisition

details



Reply with required

information

Approve/Reject?


RequisitionerReject

No

Yes

Yes

Approve

Approver

Approver


Approver

Submit for approval

Requisitioner


The first Approver in the approval chain will receive a notification via workflow asking them review the requisition.





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.




Demand


Call-Off 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


No

ApproveYes


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.


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.


Scenarios

The following process scenarios are incorporated within the Create Orders section:

Autocreation Autosourcing (Future Process) Contract Purchase Agreements (Future Process) Direct PO Creation


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.


Autocreation: Process Flow

Approved Requisition


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.


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.


Autosourcing (Future Process): Process Flow



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



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.


Contract Purchase Agreements (Future Process): Process Flow

Autosourcing Requirement


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


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.


Direct PO Creation: Process Flow

Emergency Order


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-


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.


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.


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


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.


Amending Requisitions: Process Flow (1 of 2)

Amendment Required



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


Approver

Review requisition

details



Reply with required

information

Approve/Reject?


RequisitionerReject

No

Yes

Yes

Approver

Approver


Approver

The first (or next) Approver in the approval chain will receive a notification via workflow asking them review the requisition.


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 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).


Amending Requisitions: Process Flow (2 of 2)

Amendment Required



Amended RequisitionRequisitioner

Process for the amendment of requisitions prior to PO creation.

High Level approver required?

Approve

System


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.


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.


Amending Orders: Process Flow

Amendment Required



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.


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.


Cancelling Requisitions: Process Flow

Cancellation requirement


Cancelling Requisitions

Cancelled RequisitionRequisitioner

Process for the cancellation of requisitions prior to PO creation.

Has an order been assigned?

Requisitioner Yes

No


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.


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.


Cancelling Orders: Process Flow



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.


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


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


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.


Desktop Receiving: Process Flow


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


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.


Buyer Receipts: Process Flow


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


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.


Returns: Process Flow


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.


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.


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


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.


Supplier Queries: Process Flow

Supplier Query


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.


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.


Internal Queries: Process Flow

Internal Query


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


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


AP Queries: Process Flow Please refer to the Hold Resolution process in the AP PDD for details.



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.


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


Scenarios

The following process scenarios are incorporated within the Supplier Maintenance section:

Supplier Setup Supplier Deactivation Supplier Merge Supplier Updates


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.


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.


Supplier Setup: Process Flow (1 of 3)

New Supplier Setup

Request


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


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



New Supplier Setup

Request



SupplierSupplier

Maintenance Clerk


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?


Clerk

Yes

Perform Credit Check


Clerk

Passed?

Yes


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.



Setup Supplier in Oracle

New Supplier Setup

Request



SupplierSupplier

Maintenance Clerk


Yes


Clerk

Send forms to Supplier


Clerk

Supplier Bank Detail

Maintenance

Finalise Request Form

Inform Requisitioner & Operational

Buyer


Clerk


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


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.


Supplier Deactivation: Process Flow


Request


Request



Supplier record

deactivated


Clerk

Process for the deactivation of suppliers no longer required or in breach of contract.


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.


Clerk


Clerk


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


Clerk


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.


Supplier Merge: Process Flow

Duplicate Suppliers


Supplier Merge

Single Supplier Record


Clerk

Process for the merge of duplicate suppliers.


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


Clerk


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.


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.


Supplier Updates: Process Flow

Supplier Update Request


Supplier Updates

Updated Supplier Record


Clerk

Process for ongoing maintenance of active supplier records.


Clerk

Supplier Update Request

Verify Request

Make update

Bank Details

Update?Yes

Supplier Bank Detail

Maintenance

No

Inform requester (if

required)


Clerk


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.


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.


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


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.


Month-End & Close: Process Flow

Month-End


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


Clerk

No

Review Inactive

Suppliers

Inactive Suppliers?

YesSupplier

Deactivation

Run procurement performance

reports


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.


P2P Process Definition Document Procurement

Documents

Transcript of P2P Process Definition Document Procurement