Direct answer: Site requests in Odoo need an operating procedure that defines who requests, who reviews completeness, who approves the commitment, and how the request keeps its project reference through purchasing, receipt, issue, and vendor billing. Recording a request in the system is not enough when decisions and exceptions still happen outside it.
This is one specific control in the contracting cycle. For broader platform evaluation, see our guide to choosing contracting software in Saudi Arabia. Here, the focus is the point where site demand begins to affect purchasing, cost, and project profitability.
Why do requests remain slow after go-live?
A common reason is that the request form moved into the system while the operating decision remained undefined. Users may know where to enter a description and quantity, but not who checks stock availability, who validates urgency, when the request becomes a financial commitment, or who can authorize an exception. Teams then return to calls and messages to obtain a decision, leaving the official record behind reality.
Separate request, review, approval, and execution
| Stage | Purpose | Possible owner | Required evidence |
|---|---|---|---|
| Request | Record the need, project, date, and cost context | Site team or project manager | Complete data and project reference |
| Review | Validate specification, quantity, stock, and budget context | Project, inventory, or purchasing | Traceable review result |
| Approval | Authorize commitment within delegated authority | Operational or financial authority | User, decision, and timestamp |
| Execution | Purchase, issue, or transfer the requirement | Purchasing or warehouse | Transaction linked to the request |
Smaller companies may combine some roles, but that should be an intentional design decision. More approvals are not automatically better. Each stage should correspond to a real decision, risk, or segregation-of-duties requirement.
What information should a site request contain?
- Project, site, or phase.
- Requirement type: material, service, equipment, or expense.
- Description, quantity, unit of measure, and required date.
- Cost code or analytic context when applicable.
- Urgency or exception reason.
- Attachments required to confirm specification or scope.
Do not make every available field mandatory. A useful field supports a later decision, transaction, or cost explanation. Fields that have no operational consumer become formality rather than control.
From site request to purchase or stock issue
Before creating a purchase, the procedure should determine whether the material is available in stock or can be transferred from another location. If purchasing is required, the purchase document should preserve the project and original request reference. Receipt or issue should then send the material to the intended site, and the resulting vendor cost or material movement should appear in the approved project analysis.
The exact implementation depends on the Odoo configuration and project scope. Standard applications may cover a large part of the cycle, while field material requests, approval limits, bills of quantities, or company-specific controls may require configuration or a focused extension. Do not describe every construction-specific procedure as a standard ready-made feature without a fit-gap review.
How to design approvals without blocking operations
- Base authority on value or risk, not job title alone.
- Define an authorized delegate for absence, with visible audit history.
- Distinguish return-for-correction from final rejection.
- Prevent self-approval where segregation of duties is required.
- Measure waiting time at each stage before adding another approval.
Odoo activities and notifications can support follow-up, but notification volume is not a control objective. A useful notification identifies the blocked record, current owner, due date, and business impact.
Design a controlled exception path
Construction projects sometimes require urgent procurement. A realistic process should therefore include a controlled exception: mandatory reason, named authority, value limit, subsequent documentation, and periodic review. If the urgent path becomes the normal path, the base procedure or planning model needs attention.
A concise weekly report
- Requests exceeding the expected review or approval time.
- Purchases created without a complete project reference.
- Urgent exceptions and their reasons.
- Duplicate or cancelled requests discovered after buying.
- Received or issued materials that do not appear against the intended project.
Connect this report to the weekly project cost reconciliation procedure. Request control should not be separated from its financial effect.
How should the process be tested?
Use three realistic scenarios: a material already in stock, a requirement that needs purchasing, and an urgent exception. Execute each scenario end to end with realistic users and authority levels. Verify documents, inventory movement, project cost, and reporting. Classify every gap as configuration, data, training, integration, or development, and assign an acceptance test to each change.
Frequently asked questions
Do more approvals always reduce risk?
No. An approval that adds no decision or evidence may only increase delay. Every stage should address a defined authority or risk.
Must the company stop using WhatsApp?
It may remain a communication channel, but the request, decision, and reference used by purchasing and cost reporting should remain in the controlled system of record.
Is custom development always required?
No. Standard configuration may be sufficient for some companies. Others may need a material-request extension, approval rules, cost-code linkage, or contract-specific controls. A fit-gap exercise and realistic scenario should determine the answer.
Next step
Neyar Solutions can review a sample of real site requests, map the current and target procedure, and distinguish what can be delivered through standard Odoo, configuration, integration, or a focused extension. Explore our Odoo solutions and implementation and process-design services.
