Skip to main content

Project Managers

Project Managers keep procurement work tied to the project it supports. They care less about day-to-day RFQ handling and more about whether the request matches the project, budget, timing, and expected delivery.

In Grinea, their work appears around Project Profiles, BOM review, PR decisions, and project-facing delivery follow-up.

Project purchase setupProject purchase setupProject PurchaseLine ItemsDelivery DetailsDocumentsRecord detailAction stateProjectIssue numberBudget ownerAdd Line ItemUpdate DeliverySubmit PR
Project purchases start from project and BOM context, then move into a PR workspace.

Basic Concepts​

Project Managers provide project context and make project-level decisions when the workflow asks for them. They help keep planned demand, purchase requests, and delivery expectations aligned.

The Project Manager is not the Buyer. A Buyer owns sourcing and supplier execution. The Project Manager helps decide whether the project should move forward with the request and whether the purchasing work still matches project reality.

Project Context​

Procurement Web AppProcurement Web AppDashboardNavigationPurchase RequisitionRequest for QuotationOrdersWork queuePending approvalsRFQs closing soonOrders awaiting delivery
The main app is organized around dashboard work, module navigation, and record lists.

Project Profiles hold the information that downstream procurement records depend on: project identity, locations, team assignments, and budget ownership.

When this context is wrong, later pages can look wrong even if the Buyer did everything correctly. The Project Manager should treat project setup as part of procurement readiness, not only project administration.

Review And Approval Work​

Approval actionsApproval actionsApproval FlowApproval FlowReviewer noteNext approverReason required on returnApproveReturn
Approval work is handled from record headers and confirmation modals, not from a separate flow screen.

Project Managers may appear in approval flows when a project purchase needs a project-side decision. Their task is to read the request, check whether it still fits the project need, then approve it or return it with a specific reason.

Returning a request is not the same as rejecting the whole procurement path. It sends the record back so the owner can correct the detail that is blocking approval.

Delivery Visibility​

Receive Delivery modalReceive Delivery modalReceive DeliveryReceive DeliveryItem deliveryProof of deliverySummaryBackSubmit
Receiving uses a guided modal for quantities, proof, and review before saving delivery history.

Project Managers may need to follow delivery state because late, partial, or rejected delivery affects project execution. They should read Orders as the source for PO and delivery history, not the original BOM.

Receiving may be handled by a Site Manager or another eligible receiver. The Project Manager's concern is whether the project can use what was delivered and whether unresolved delivery work affects the plan.

Boundaries​

Project Managers do not manage supplier invitations, quotation comparison, supplier selection, or PO sending unless the workflow explicitly gives them that action.

Their role is project accountability. They keep the request grounded in project need while Buyers handle the purchasing path.