Purchasing Hierarchy Project FAQs

Yes. If the HAF has already approved as Budget-Holder and meets the financial threshold, the system will not require a second approval. To avoid this, assign a different Budget-Holder.

Yes. Individuals can belong to multiple approval groups.

Yes, if appropriate. The same person can wear both 'hats'.

Yes. Requisitions charged to projects go through both checks. Departments can assign the same or different people to these approval groups.

Yes. All members of the group will receive notifications for, and be required to make an approval decision, for every requisition raised in the department. Only one person needs to act on each requisition.

No. When you make an approval decision, you make it for all approval roles that you hold simultaneously. If a requisition requires approval from you as policy and grants checker then there is no way to separate these decisions and only make one.

Yes, anyone who needs to raise requisitions can be given requestor access, including Budget-Holders.

No, they can only be assigned at the cost centre level. However, departments can add an extra approval step for source of funds if needed. This can be configured in the approval route by any approver.

No, you are not able to nominate more than one person as the approver for a specific budget. An individual needs to be named for GL cost centres, and individuals are already specified for projects at the task and sub-task level (and Requisition Approver position if used).

The requisition has changed so a new approval route is created. It will go back to the new budget holder for approval.

No, this is not possible. A requisition that is not coded to a specific budget will result in an error as the system will not be able to generate an approval route.

No, all transactions must be approved by the Budget-Holder, regardless of value. This ensures compliance with funder and audit requirements. If a Budget-Holder prefers not to approve every transaction, they can delegate this responsibility to another requisition approver to act on their behalf, or temporarily delegate their approval if they're on leave.

Full Buyer Access should be limited to individuals who need to edit Purchase Orders (POs) – for example, to close or reopen them. This role carries significant responsibility and should be assigned only to trusted, experienced finance staff. A new Read-Only Buyer role is being introduced. This allows users to view all POs (regardless of budget) without being able to make changes. It includes access to both the PO Enquiry responsibility (Java side) and the Buyer Work Centre (web-based), but in a view-only mode.

Departments should review who currently has Buyer Access and assess whether they truly need it. If a current buyer only needs to view PO details, they should be assigned the read-only role instead.

You can check this in your User Access Dashboard, which shows who holds the Buyer position. It’s also visible in the Purchasing Hierarchy Report, where there’s a column indicating Buyer module access. This report can be run at any time.

No. You’ll need Full Buyer Access to manually create POs. Read-only access allows you to view PO details, but not take actions.

Yes. There are no planned changes to the delegation functionality. It will continue to work as it does currently, including vacation rules and workflow redirection.

Research Accounts will continue to manage delegation through the existing Oracle functionality. If a PI or project owner needs someone else to approve on their behalf, Research Accounts can help ensure the correct person is assigned to the 'requisition approver' position in the project setup. For temporary delegation, vacation rules can be used.

Yes, the helpdesk will still be able to reallocate approvals in emergency situations – such as when someone is unexpectedly unavailable and hasn’t set up vacation rules. However, this should not be the default approach. Users are strongly encouraged to manage delegation themselves using Oracle’s vacation rule functionality. Training and guidance will be provided to support this.

Yes. Requestors (shoppers) must complete the coding details – including GL codes and project information – when submitting a requisition. This information is essential for generating the correct approval route. If it’s missing, the system will return an error such as 'Approval route could not be generated', and the requisition won’t proceed.

The worklist functionality in Oracle is not changing. It will continue to display the same information as it does now. However, to improve usability, email notifications will be enhanced to include clearer guidance and key details to support decision-making. Approvers can still click into Oracle for full requisition details if needed.

Shopper access is requested via an OSM (Oxford Service Manager) request, just as it is now. The recently issued hierarchy structure form does not include a section for shoppers because they are not part of the approval chain. You can request access for one or multiple shoppers at once.

Yes, but only by line. You can code different lines of a requisition to different budgets (e.g. one line to a GL, another to a project), and each line will follow its own approval route. However, do not split a single line across multiple budgets—this causes issues with the approval process and is not supported. This limitation remains in place until the future transition to Oracle Cloud or a new financial system.

The go-live date for the new approval hierarchy is currently scheduled for 15 November. This date may be subject to change depending on testing and readiness, but it is the target for now.

There may be a short freeze period around the go-live date (currently planned for 15 November) during which the ability to raise new requisitions is temporarily paused. This is to allow the new approval hierarchy to be activated smoothly. The freeze is expected to be brief—possibly overnight—and we’re working to minimise disruption. You can continue to make changes to your current hierarchy until closer to go live, at which point changes will be restricted to allow for the new structure to be loaded.

Yes. As part of the rollout, departments will receive example workflows and guidance documents to help users understand how the new hierarchy functions. This will include how to handle common errors, such as missing approvers or incorrect coding, and how to resolve them efficiently.

No, each department will have a single formal hierarchy in the system. However, within that structure, you can assign different requisition approvers to specific projects or cost centres. Departments can also agree internally on how requisitions are distributed among approvers. While the system doesn’t support multiple hierarchies, it does allow for flexible use of the single hierarchy to suit departmental needs.

No, it’s not compulsory. One person can hold multiple roles (e.g. Budget-Holder, Quality Check, Finance Approver) and approve a requisition once, wearing all hats. The system recognises their approval and won’t prompt them again. However, if that person also raises the requisition, the system will escalate approval to the next appropriate financial authority to maintain segregation of duties. This ensures compliance with audit and governance standards.

Yes. Approval groups can include individuals from other departments, which is especially useful for small teams or shared services.