Many factory purchases begin informally. A supervisor sends a message about a tool, maintenance reports a spare part by phone, or production writes a material request in a register. Purchasing then has to discover the correct specification, required quantity, need-by date, reason, and approval while the requester waits without a dependable status.
Purchase requisition software for manufacturing should create one controlled internal request before supplier selection or a purchase order. It gives the requester, approver, stores, planning, and purchasing the same context and makes exceptions visible early.
Separate the requisition from the purchase order
A purchase requisition records an internal need and asks the organisation to review it. A purchase order is the authorised commercial instruction issued to a supplier after the purchasing process. Keeping these stages distinct prevents an incomplete request from becoming an accidental commitment.
The requisition should show who needs what, why it is needed, when it must be available, where it will be used, and which approval applies. Purchasing can then source, combine, clarify, reject, or convert approved lines according to the factory's process.
Define when a requisition should begin
Requests may originate from a production shortage, planned replenishment, maintenance task, tooling need, quality action, engineering project, office requirement, or one-time service. Record the trigger because it determines the supporting information and urgency.
Where the need comes from a job, shortage, or maintenance record, create the requisition from that source rather than asking the user to retype it. The workflow should retain the relationship to the affected work.
Capture the fields purchasing needs
Keep the form short enough to use, but require the information needed to avoid repeated clarification:
- Request context: requester, department, request date, purpose, source record, and required location.
- Item or service: item code where available, description, quantity, unit, specification, drawing or revision, and acceptable alternatives.
- Timing: need-by date and the production, maintenance, or project date it supports.
- Responsibility: cost centre or project, approver, buyer, and technical reviewer where needed.
- Evidence: drawing, photograph, sample reference, scope, or prior purchase reference when it improves clarity.
Use controlled master data for repeat items and units. Free-text requests are useful for unusual services, but routine material should not create a new description every time.
Control specification and revision
Purchasing cannot source correctly when the request says only “same as last time” or uses an outdated drawing. Link the current specification, approved manufacturer or grade where required, inspection needs, and applicable revision. Preserve the version used when the request was approved.
For production material, the request may originate from the approved product structure described in the guide to BOM and revision control. For a spare, include the machine, assembly position, or equipment reference that helps identify the correct part.
Check stock and open supply before approval
Show usable stock, reserved quantity, open requisitions, open purchase orders, expected receipts, and other requests for the same item. This helps prevent duplicate buying and reveals whether an internal transfer or release of existing stock can meet the need.
Physical stock is not always usable. Inspection hold, rejection, allocation, location, or condition may matter. The inventory management guide explains the controlled movements and statuses that make this check trustworthy.
Use a meaningful need-by date
A need-by date should describe when the material or service must be available for use, not simply “urgent.” Show the job start, planned maintenance, dispatch commitment, or project milestone behind it. Purchasing can then work backward through sourcing, supplier lead time, transport, receipt, and inspection.
If the date is already at risk, flag the issue during the request rather than after approval. Connect production-driven requests to the current production plan so a schedule change does not leave the old requirement unexplained.
Design approval around risk and responsibility
Approval rules may consider department, request type, amount band, project, urgency, or technical risk. Keep the route understandable and avoid sending every routine request through the same long chain. Assign delegates for planned absence and show how long each request has waited.
An approver should be able to approve, reject, return for clarification, or request a controlled change. Preserve comments, time, and the values that were approved. A material change to quantity, specification, date, or responsibility may require a new review according to the factory's policy.
Use one visible requisition workflow
- Create. The requester selects the source need and completes the required fields.
- Validate. The system checks item data, units, required fields, stock, duplicates, and timing.
- Review. A technical or stores reviewer confirms specification and availability where necessary.
- Approve. The responsible approver records a clear decision.
- Assign. Approved lines move to a buyer or purchasing queue.
- Source. Purchasing records clarification, enquiry, comparison, and selected action in the appropriate process.
- Convert and track. The requisition links to the resulting purchase order, internal fulfilment, or closure reason.
The requester should see the current status without asking purchasing for an update. A single requisition may split across suppliers or orders, so status should remain visible at line level.
Handle urgent and exceptional requests carefully
Factories need an emergency path for breakdowns or immediate production risk, but it should not erase essential control. Require an urgency reason, affected machine or job, responsible approver, and later completion of any information that could not be supplied immediately.
Review repeated emergency requests separately. They may point to missing spare policy, inaccurate planning, late transaction entry, unreliable supply, or unclear ownership. The material shortage alert workflow can surface some production needs before they become emergencies.
Make status precise and actionable
Use a small set of states such as draft, awaiting information, under review, awaiting approval, approved, assigned to buyer, converted, partly converted, rejected, cancelled, and closed. Show the current owner and how long action has been pending.
Avoid a generic “in process” status. The requester needs to know whether information, approval, sourcing, supplier confirmation, or receipt is the current constraint.
Connect related records without duplicate entry
Link the requisition to item master data, stock, production jobs, maintenance work, projects, supplier records, purchase orders, receipts, and inspection where those systems exist. Define which record is the source of truth for each field.
When selecting software, test the workflow and integration responsibilities as described in the comparison of custom and ready-made ERP. An integration must handle changes, errors, duplicates, and recovery, not only the normal transfer.
Review process health, not just request count
Monitor requests awaiting clarification, overdue approvals, duplicate requests, emergency reasons, ageing by current owner, lines not converted after approval, and orders that no longer support the need-by date. Use stable definitions and inspect the underlying records.
The purpose is to find delay and rework in the process. A rising request count may simply reflect business activity; it is not automatically good or bad.
Pilot one request category
Choose a repeat category such as maintenance spares, indirect consumables, tooling, or non-stock production material. Define required fields, reviewers, approvers, status names, duplicate checks, and the purchasing handoff. Load a small set of clean item and user data.
Test a normal request, insufficient stock, duplicate line, revised quantity, missing specification, rejected approval, delegated approval, partial conversion, cancellation, and emergency request. Run the pilot until requesters and buyers can follow status without a parallel register.
Begin with the request that causes the most chasing
Select one type of purchase need that currently moves through calls, messages, and paper. Map who requests, checks, approves, buys, and receives it. Identify the information each person needs and the exceptions that cause repeated delay.
A focused digital requisition workflow creates a reliable handoff before purchasing begins. Once that path works, the factory can extend it to more departments, item categories, projects, and connected supply processes without losing ownership.
Want a practical purchase requisition workflow?
Share one current request form and the approval path your team follows before purchasing. Ploqy Technologies can help map a focused digital workflow around specification, stock checks, need-by dates, ownership, and status.