Purchase Requisitions - Project Purchase

Source file: 2026-06-08-user-manual-pr-project-purchase.html

User Manual

Field	Value
Document Type	User Manual
Portal	GRINEA – Internal Operations Portal
Module	Purchase Requisitions – Project Purchase
Version Number	1.0
Document Date	May 28, 2026
Prepared by	Christian Canlubo

Version History

Version Number	Version Details	Author	Date Published
1.0	Initial Version	Christian Canlubo	May 28, 2026

1.0 Introduction

This section provides an overview of the purpose, scope, and intended audience of this document. Platform users are encouraged to review this document in full before proceeding to other manuals to ensure that they understand how it applies to their roles and responsibilities within the organization and the platform.

1.1 Purpose of the Document

This document is the official user manual for Project Purchase Requisition workflows on the GRINEA Internal Operations Portal. It covers the creation, setup, submission, approval, revalidation, and lifecycle management of Purchase Requisitions (PRs) that are linked to a project. This document addresses both origins of a Project Purchase PR: PRs generated directly from a Bill of Materials and Services (BoMS) and PRs created manually from the PR module.

The Purchase Requisitions module is the operational entry point between project planning and supplier sourcing. A Project Purchase PR captures what is being purchased, for which project, where it must be delivered, and who must approve it before sourcing activity can begin. Once accepted, the PR is passed to the Request for Quotation (RFQ) module as the source for a new RFQ.

This manual ensures that all users responsible for creating, completing, approving, or accepting a Project Purchase PR can independently perform their role, understand the three-step approval flow, and use the search, filter, and pagination tools to manage the PR list across the project lifecycle.

This document is intended to complement, not replace, any organization-specific procurement policies, project governance frameworks, or system administration guidelines. Users who encounter platform issues not covered in this manual should contact their designated system administrator.

1.2 Scope of the Document

This document covers Project Purchase Requisition workflows on the GRINEA Internal Operations Portal. The scope is limited to PRs linked to a project and does not extend to Non-Project (Indirect) Purchase Requisitions for CAPEX or OPEX spend, which are addressed in the Non-Project Purchase Requisitions manual. Specifically, this document covers:

• Navigating to the Purchase Requisitions module from the Internal Operations Portal
• Understanding the two origins for Project Purchase PRs: BoMS-generated and manually created from the PR module
• Generating a PR from a BoMS line item in PR - For Generation status
• Completing a BoMS-generated PR Draft, including the required fields not inherited from BoMS
• Creating a Project Purchase PR manually from the PR module
• Setting up a manually-created PR through the four-step Setup PR wizard
• Editing line items and managing the Delivery Schedule and Service Schedule on a Project Purchase PR
• Submitting a Project Purchase PR and understanding post-submission behavior
• Routing a Project Purchase PR through the three-step approval flow and revalidation handling
• Project Purchase PR statuses across the full lifecycle
• Searching, filtering, and paginating the Purchase Requisitions list
• Receiving and acting on email and in-app notifications generated by Project Purchase PR events
• Understanding the downstream handover of an accepted PR for RFQ generation

The following areas are out of scope and are addressed in separate documentation:

• Non-Project (Indirect) Purchase PR creation for CAPEX or OPEX spend — covered in the Non-Project Purchase Requisitions manual
• Budget Owner, Investment Controller, CEO and Purchasing Director approval flows — covered in the Non-Project Purchase Requisitions manual
• User account provisioning, RBAC role assignment and permission configuration — covered in the User Management and RBAC manuals
• Project Profile creation, project locations and project team assignment — covered in the Project Profile manual
• BoMS creation, cost validation, schedule creation and PR generation flagging — covered in the BoMS manual
• RFQ, PO and Receiving workflows that consume approved PRs — covered in their respective module manuals
• Material and Service Category Management, including PKK classification — covered in the Material Management manual
• ERP integration with Impuls and system-to-system synchronization
• IT infrastructure, network access, and device management policies

1.3 Intended Audience

This manual is intended for all users who interact with Project Purchase Requisition workflows on the platform, written to be accessible regardless of technical experience.

PPS / PR Requestor

The PPS or the PR Requestor is the user who creates the Project Purchase Requisition, either by completing a BoMS-generated draft or by manually setting up a PR from the PR module. The Requestor is responsible for entering accurate purchase details, line items, and delivery information, and for submitting the PR into the approval workflow. The Requestor is the first step in the Project Purchase approval flow. In the GRINEA context, this role is typically performed by the PPS assigned to the project.

Project Manager

The Project Manager approves Project Purchase PRs after the Requestor submits them. The Project Manager reviews the requested items against the project plan and budget before routing the PR forward to the Buyer. The Project Manager only acts on PRs linked to projects to which they are assigned and is the second step in the Project Purchase approval flow.

Buyer

The Buyer is the final reviewer and acceptor on the Project Purchase approval flow. The Buyer accepts the PR for sourcing, returns it for revalidation if corrections are required, or releases it for downstream RFQ activity once accepted. The Buyer must be assigned to the project that the PR is linked to.

Backoffice Users

Backoffice users can view all Purchase Requisitions on the platform regardless of project assignment. Backoffice users cannot create or edit PRs and have read-only access across the PR list.

Other Roles with RBAC Access

Beyond the primary audiences listed above, the Purchase Requisitions module is governed by RBAC. Any user granted Create access can create a PR, any user granted Update access can update one in the same way the Requestor does, and any user granted View access can see the PR on the list and open its details. The primary audiences listed above should not be interpreted as a closed list.

2.0 Module Overview

2.1 Description

The Purchase Requisitions module is the operational entry point for all procurement requests on the GRINEA Internal Operations Portal. It is accessed from the portal navigation under Internal Operations Portal > Frontoffice > Purchase Requisitions. Every project-linked purchase made through the platform originates as a Purchase Requisition inside this module.

When a user opens the Purchase Requisitions module, the PR list table is the default landing page. Backoffice users see every PR on the platform; Frontoffice users see only PRs related to projects they are assigned to through the Project Working Team. The list defaults to 100 rows per page and the page size is configurable from the bottom of the table. Users can search by PR ID, Impuls PR Number, or Item Name, and can apply filters by Buyer or Status.

2.2.1 PR List (Landing Page)

The PR list is the default landing page of the Purchase Requisitions module. It displays all Purchase Requisitions visible to the current user in a table format. Backoffice users see every PR on the platform; Frontoffice users see only PRs linked to projects they are assigned to as part of the Project Working Team.

The list defaults to 100 rows per page. Pagination size is configurable from the bottom of the table. Each row gives the user a quick view of the PR identifier, source, project, Buyer, and current status. Clicking a row opens the full PR detail view.

[Screenshot: PR List – Landing Page]

2.2.2 PR Sources

A Project Purchase PR can originate from two distinct sources. The behavior of the PR draft, the fields that are pre-filled, and the editing scope available to the Requestor all depend on which source the PR originates from.

PR from BoMS

When a BoMS line item reaches the status PR - For Generation on an Active BoMS, the platform allows the Requestor to generate a PR directly from that line item, either individually or by selecting multiple line items at once. The resulting PR is created in DRAFT status and automatically inherits the following from the BoMS:

• Purchase Details, including the linked project context
• Line Items, including quantities, units, and specifications
• Delivery Details and the corresponding Delivery Schedule
• Attachments linked to BoMS line items, where applicable

Some fields may remain empty if they were not defined on the BoMS. The Requestor is responsible for completing them before submitting the PR.

PR from the PR Module

A Requestor can also create a Project Purchase PR manually from inside the PR module without originating from a BoMS line item. The Requestor selects a project they are assigned to, selects the associated Issue Number, and the PR is created in DRAFT status. The PR is then configured through the four-step Setup PR process described in section 2.2.5.

2.2.3 Completing a BoMS-Generated PR Draft

A PR generated from BoMS arrives in Draft already pre-filled with the Purchase Details, Line Items, and Delivery Details inherited from the BoMS. The Requestor's role at this stage is to complete the fields that the BoMS does not carry and to make any line item or schedule adjustments required before submission. The fields the Requestor must complete are: Organizational Unit, Demand Type, Issue Number, Cost Centre, Warehouse, Internal Comments (optional), and Attachments (optional; may already be inherited from the BoMS).

The following sections of the PR remain editable until the PR is submitted. Any changes made are automatically reflected in the actuals of the originating BoMS, including updated quantities, schedules, and item details:

• Line Items, where the Requestor can add, edit, or remove items
• Schedules for material and service line items

Schedule Rules: The schedule displayed on the PR depends on the type of line items it contains. Material line items use the Delivery Schedule; Service line items use the Service Schedule. If the PR contains both material and service line items, both schedules are displayed.

[Screenshot: BoMS-Generated PR Draft]

2.2.4 Creating a Project Purchase PR from the PR Module

A Project Purchase PR is created manually when a Requestor needs to raise a Purchase Requisition linked to a project that does not originate from a BoMS line item. To create one:

• The Requestor selects the Project from the available list. Only projects to which the user is assigned through the Project Working Team are visible. If the user has no project assignments, Project Purchase PR creation is not permitted.
• The Requestor selects the Issue Number linked to the project.
• The PR is created as a Draft and the user enters the four-step Setup PR wizard described in section 2.2.5.

[Screenshot: Create Project Purchase PR]

2.2.5 Setting Up a Manually-Created Project Purchase PR

When a PR is created from the PR module, only the Setup PR tab is initially available. The Requestor must complete a four-step setup process before the PR can be submitted. The same four steps apply to both BoMS-generated and manually created Project Purchase PRs when the Requestor is configuring the PR in Draft.

Step 1 – Purchase and Additional Details

The first stepper captures the core PR header information. The Purchase Details section is auto-filled based on the project and Issue Number selected at creation. The Requestor must complete the following required fields: Organizational Unit, Demand Type, and Transaction.

The following fields are auto-filled from the project context and are disabled at this step: Issue Number, Cost Centre, and Warehouse. Internal Comments and Attachments are optional at this step and can be added at any point before submission.

Step 2 – Line Items

The second stepper is where the Requestor adds, edits, and removes line items on the PR. Both Material and Service line items are supported. Line item creation follows the same logic as line item creation in the BoMS module; refer to the BoMS user manual for the full line item configuration behavior, including specification selection, attribute configuration, and historical purchase references.

Step 3 – Schedule

The third stepper displays the schedule for the line items added in Step 2. The Delivery Schedule is shown for material line items and the Service Schedule is shown for service line items. If the PR contains both material and service items, both schedules are displayed side by side. The schedule rules described in section 2.2.3 apply.

Step 4 – Summary and Submission

The fourth stepper is the final review screen. It consolidates all information captured across the previous steps: Purchase Details, Additional Details, Documents and Attachments, and Line Items.

The Requestor reviews each section, returns to earlier steppers if any correction is required, and then submits the PR. Once submitted, the PR transitions from DRAFT to FOR APPROVAL and the Setup PR tab is replaced by the standard PR detail tabs: Purchase Details, Line Items, and Schedule.

2.2.6 Searching and Filtering the PR List

The PR list provides a search field and a filter drawer to help users locate a specific PR quickly. The search field accepts the following inputs: PR ID, Impuls PR Number, and Item Name.

The filter drawer, opened from the list toolbar, allows the user to filter by Buyer or by Status. The drawer includes a reset function that clears all applied filters in a single action.

[Screenshot: PR List – Search and Filter Drawer]

2.2.7 Email and In-App Notifications

The Purchase Requisitions module generates notifications at every key event in the Project Purchase PR lifecycle. Notifications are triggered when a PR is submitted, at each approval step, when a PR is sent back for revalidation, when the Buyer accepts the PR, and at every other status change relevant to the assigned users.

Notifications are delivered through two channels: email and in-app notifications within the Internal Operations Portal. Recipients are determined by the user role on the PR and their position in the active workflow step. Email notifications include call-to-action links that navigate recipients directly to the PR. In-app notifications use the same trigger events and deliver a condensed version of the email content inside the platform shell.

2.2.8 Cancellation of a Purchase Requisition

The PR creator can cancel a PR directly from the PR Details page, subject to the following conditions. The Cancel PR button is visible only when all of the following conditions are met: the logged-in user is the PR creator, the PR is in an eligible status, and no active Order exists against the PR.

Eligible statuses for cancellation are: DRAFT, FOR APPROVAL, FOR REVALIDATION, FOR ACCEPTANCE, ACCEPTED, and RFQ PUBLISHED.

Warning: Cancellation is blocked if the PR has at least one linked Order that is not in Cancelled status. The Cancel PR button is hidden in this case. The button becomes visible again if all linked Orders are subsequently cancelled.

The cancellation flow is as follows:

1. The PR creator clicks Cancel PR on the PR Details page.
2. A confirmation modal appears with a warning that cancellation is irreversible.
3. The modal presents two actions: Cancel (dismiss modal, no change) and Confirm (execute cancellation).
4. On confirmation, the PR status transitions to CANCELLED, the PR becomes read-only, and the action is recorded in the audit trail and displayed on the PR Approval Flow stepper.

A Cancelled PR is excluded from the RFQ staging PR dropdown. Any RFQ already linked to the PR displays a banner on the RFQ Detail page indicating that the source PR has been cancelled. Only the PR creator can execute the Cancel PR action.

2.2.9 Withdrawal from the Approval Queue

The PR creator can withdraw a PR that is currently in FOR APPROVAL status, provided the assigned Project Manager or Budget Owner has not yet taken any action on it. On withdrawal, the PR reverts to DRAFT status. The creator can then edit and resubmit the PR through the standard approval flow.

Withdrawal is not available once the PM or Budget Owner has approved, returned, or otherwise acted on the PR. In that case, the creator must wait for the PR to be returned via the revalidation flow or contact the assigned approver directly. The withdrawal action is recorded in the audit trail and displayed on the PR Approval Flow stepper.

2.3 Purchase Requisition Statuses

Each Project Purchase PR progresses through the following statuses across its lifecycle:

#	Status	Description
1	DRAFT	The initial status of a Purchase Requisition, set when the Requestor begins setting it up or when a PR draft is generated from BoMS. The PR can be edited freely in this state and has not yet entered the approval flow.
2	FOR APPROVAL	The PR has been submitted by the Requestor and routed to the Project Manager assigned to the linked project. The PR is no longer editable by the Requestor until the Project Manager approves or returns it.
3	WITHDRAWN	The PR creator retracted the PR from the approval queue after submission, while the assigned Project Manager or Budget Owner had not yet taken any action. The PR reverts to Draft and can be edited and resubmitted.
4	FOR ACCEPTANCE	The PR has been approved by the Project Manager and is sitting with the Buyer for final review and acceptance. The Buyer can accept the PR for sourcing or return it for revalidation.
5	FOR REVALIDATION	The PR has been returned by the Buyer to an earlier role in the workflow for corrections. Once corrections are applied and the PR is resubmitted, it re-enters the approval flow from the appropriate step.
6	FOR VALIDATION	The Buyer has accepted the PR. The PR is pending a final internal validation step before the APPROVED status is set. During this stage the PR is read-only. This step ensures that all PR data is complete and consistent before it is made available for RFQ generation.
7	APPROVED	The PR has passed all validation and approval steps. The PR is locked from further editing and an approved snapshot is created and made available for downstream RFQ generation in the RFQ module. Note: this status is labelled APPROVED in the platform (enum: APPROVED) — earlier documentation versions may reference this status as "Accepted".
8	RFQ PUBLISHED	All PR lines are linked to RFQs in Published status. Set automatically by the system when the aggregate RFQ phase is reached. The PR remains eligible for manual cancellation by the creator while no active Order exists.
9	PO ISSUED	All PR lines are linked to Purchase Orders in Issued status. Set automatically by the system. Where PR lines exist in mixed phases (some in RFQ, some in PO), the PR displays the lower lifecycle status (RFQ Published).
10	DELIVERED	All Purchase Orders raised against the PR have been completed and delivered. This is a terminal status for the Project Purchase PR lifecycle.
11	CLOSED	All Orders containing PR lines have transitioned to Closed. Set automatically by the system only when every PR line is in a Closed Order. Partial closure keeps the PR at the lowest active lifecycle status.
12	CANCELLED	The PR has been cancelled by the creator. The PR becomes read-only. A Cancelled PR is excluded from the RFQ staging dropdown. Any linked RFQs display a banner indicating the source PR is cancelled.

2.4 Approval Flow

Every Project Purchase PR follows a fixed three-step approval flow regardless of whether the PR was generated from a BoMS or created manually from the PR module. The flow is set by the platform and cannot be modified at the PR level. Notifications are sent at every routing event to keep the Requestor and the next approver informed.

2.4.1 Project Purchase Flow

The Project Purchase flow applies to every PR linked to a project. The flow has three steps:

Step	Approver	Definition
1	Requestor (PPS)	The user who created the Purchase Requisition. The Requestor is always the first step in the approval flow. Once submitted, the PR is routed automatically to the Project Manager.
2	Project Manager	The Project Manager assigned to the project that the PR is linked to. The Project Manager acts as the second approver, reviewing the requested items against the project plan before routing the PR to the Buyer.
3	Buyer	The Buyer assigned to the project that the PR is linked to. The Buyer is the final approver and is responsible for accepting the PR for sourcing or returning it for revalidation.

2.4.2 Revalidation

At any point in the approval flow, the Buyer can return a PR for revalidation if the request requires correction. The Buyer provides a revalidation reason at the point of return. A PR returned for revalidation moves to the FOR REVALIDATION status and is routed back to the upstream role responsible for the issue. That role applies the corrections and resubmits the PR. Once resubmitted, the PR re-enters the approval flow from the appropriate step. Email and in-app notifications are sent at every revalidation event and include the revalidation reason.

3.0 FAQs

The following frequently asked questions address common queries about Project Purchase Requisition workflows.

Question	Answer
Where do Project Purchase PRs originate?	A Project Purchase PR can originate from two sources. The first is the BoMS, where line items in PR - For Generation status are converted into PR drafts that already carry the project context, line items, and delivery details. The second is the PR module itself, where a Requestor creates a PR manually and links it to an assigned project. Refer to section 2.2.2.
What happens to my changes when I edit a BoMS-generated PR Draft?	Any changes to line items or schedules on a BoMS-generated PR Draft are automatically reflected in the actuals of the originating BoMS. This includes updated quantities, delivery dates, and item details. Changes are captured in real time as the Requestor edits and saves the Draft.
Can I see PRs for projects I am not assigned to?	Frontoffice users see only PRs related to projects they are assigned to through the Project Working Team. Backoffice users with the appropriate RBAC permissions see every PR on the platform. If you cannot see a PR you expect to see, confirm your project assignment with the Project Manager.
What happens after the Buyer accepts a Project Purchase PR?	The PR transitions to Accepted status and is locked from further editing. An accepted snapshot is created and is available as a source for RFQ creation in the RFQ module. The Requestor, Project Manager, and Buyer each receive a completion notification.
How do I locate a specific PR on the list?	Use the search field at the top of the PR list to search by PR ID, Impuls PR Number, or Item Name. The filter drawer allows you to narrow the list by Buyer or by Status. Refer to section 2.2.6 for full search and filter guidance.

---