At a Glance
Persona: Requestor (hotel / department staff) · Module: purchase-request · Workflow stages: draft → submit → in_progress (+ send-back re-entry, cancel from draft) · Key permissions: create/edit draft, attach, submit, cancel own draft, resubmit after send-back
What this persona does: Originates the PR — fills header and line list, attaches supporting docs, submits for approval, and revises on send-back.
The Requestor is the hotel or department staff member who originates a Purchase Request — the upstream demand signal that authorises procurement before any external commitment is made to a vendor. They own the PR while it is in draft: they fill the header (PR type — General Purchase, Market List, Asset — department, currency, requestor, request and required delivery dates, job/cost code, delivery point, description and justification), build the line list (product or free-text description, store location, requested quantity, FOC quantity, unit of measure, estimated unit price, discount, tax treatment, line delivery date), attach supporting documents (quotations, specs, photos), and submit when the request is ready for approval. Their involvement does not end at submit: when an approver chooses Send Back the PR returns to draft and the Requestor re-enters the flow to revise and resubmit, and at any time while the PR is still in draft they may cancel it. They cannot edit a PR after submission and they are not part of the approval, vendor-allocation, or PO-conversion steps — those belong to the Approver chain, the Purchaser, and the Procurement Manager respectively (see the module landing Section 4).
The Requestor is the owner of a PR only while it is in draft. Once it leaves draft (in_progress, approved, completed) or terminates (voided) the Requestor retains view-only access. Action availability is enforced server-side by PR_AUTH_001 and the state-machine guards.
| Action | draft (own) | in_progress | approved | completed | voided |
|---|---|---|---|---|---|
| View PR | ✅ | ✅ | ✅ | ✅ | ✅ |
| Edit header / lines | ✅ | ❌ | ❌ | ❌ | ❌ |
| Add / remove items | ✅ | ❌ | ❌ | ❌ | ❌ |
| Add attachments / comments | ✅ | ✅ (comment only) | ✅ (comment only) | ✅ (comment only) | ❌ |
| Submit | ✅ (≥1 line + workflow selected) | ❌ | ❌ | ❌ | ❌ |
| Cancel | ✅ | ❌ | ❌ | ❌ | — |
| Resubmit (after Send-back) | ✅ (PR is in draft again) |
❌ | ❌ | ❌ | ❌ |
ℹ️ Send-back loop: when an approver chooses Send Back the PR's
pr_statusreturns todraftand the Requestor is once again the owner — every cell in the draft (own) column above re-applies. Revision history is preserved (PR_POST_008).
Entry point: Sidebar → Purchase Request module → PR list view → Create New PR button (alternatively: Create from Template when reusing a saved template, or Alt+N from anywhere in the module).
Primary flow (happy path):
pr_status = draft, auto-generates the reference number, stamps pr_date with today's date, and pre-fills requestor_id from the logged-in user.General Purchase, Market List, or Asset), confirm or change department_id, set the required delivery date, choose currency (exchange rate is fetched automatically), enter the description / justification, and select the target workflow_id for purchase-request scope. Save the header (auto-save also runs on connection loss).PR_VAL_006 requires at least one non-deleted line at submit; per-line validations are enforced before the line can be saved).pr_status from draft to in_progress, advances workflow_current_stage to the first approval stage, creates the soft budget commitment on the relevant category, writes an audit entry, and routes notifications to the first approver (typically Department Head) and a copy back to the Requestor.department_id, no pr_date, no workflow_id, invalid currency or exchange rate): the submit action is blocked, the form scrolls to the first offending field, and an inline error message is shown. The PR remains in draft. Fix the field and retry submit.PR_VAL_006): submit is rejected with the message "At least one line is required". The PR remains in draft. Add at least one line and retry.Warning or Exceeded: the system surfaces the budget impact but does not block submit (the budget check is informational at submission). The Requestor decides whether to (a) reduce quantities or estimated prices and re-validate, (b) split the request into a smaller PR, or (c) proceed and let the Budget Controller approve or reject downstream.in_progress back to draft, the soft budget commitment is released until re-submission, the approver's reason is attached to the activity log, and the Requestor is notified. The Requestor re-enters at Section 2 step 2 (revise header or lines per the comment) and resubmits at step 9. Revision history is preserved.draft. The system transitions to voided, releases any in-progress edits, and terminates the document. Submitted PRs (in_progress, approved) cannot be cancelled by the Requestor — only the workflow can reject them (transitions to voided) or an administrator can void them (transitions to voided).in_progress, approved, completed, voided): all edit controls are read-only. The only way to change the content is to ask the current approver to send the PR back to draft. Once back in draft, the Requestor regains edit rights and the flow resumes at Section 2 step 2.The Requestor's primary involvement ends when the PR transitions from draft to in_progress at step 9 of Section 2. At that point the document leaves the Requestor's responsibility and is picked up by the first-stage approver in the configured workflow (typically Department Head; see 03-user-flow-approver.md when published). The document state at handoff is in_progress with workflow_current_stage pointing at the first approval stage and a soft budget commitment registered against the requestor's department.
A second handoff direction is back to the Requestor on send-back: any approver in the chain may return the PR to draft with a reason, releasing the soft commitment. This is not a true exit — the Requestor re-enters at Section 2 step 2 to revise the PR and resubmits. Cycles repeat until the PR is either approved (final stage), rejected or voided (voided).
Terminal exits for the Requestor (no further action possible by them) are:
pr_status = voided, terminal.pr_status = voided, terminal. Auditor reviews post-hoc.pr_status = voided, terminal. Auditor reviews post-hoc.pr_status = completed, terminal. The Purchaser owns the conversion; the Requestor sees the linked PO in the PR detail page for traceability.../carmen/docs/purchase-request-management/PR-User-Experience.md — primary source for the creation, submission, and send-back flows../carmen/docs/purchase-request-management/PR-Overview.md — module overview, requestor role definition, integration points../carmen/docs/purchase-request-management/purchase-request-module-prd.md — product requirements driving the Requestor flowtb_purchase_request, tb_purchase_request_detail, enum_purchase_request_doc_statusPR_VAL_006 (at-least-one-line) and other submit-time validations