Dave
aed3f5c861
Added support for discounts in the POS checkout process, allowing operators to apply either a fixed amount or a percentage off the gross total. Updated the state management to include discount details and modified the receipt and cart rendering to display pre- and post-discount values. Enhanced the checkout API to handle discount inputs and ensure proper calculations. Updated relevant tests to cover new discount logic.
3.2 KiB
3.2 KiB
WFDASH Standard Operating Procedures (SOPs)
These documents define the what, how, and how-measured for every operator role in the Westcott Fasteners business. Each role has its own SOP file covering:
- Daily / Weekly Checklist — concrete actions with cadence
- Step-by-Step Procedures — how to do each recurring task
- Decision Tree — what to do when X happens
- KPIs — the scorecard, with how each metric is measured
The source of truth is the markdown in this folder. The WFDASH app
renders them at /sops for in-app reference.
Roles
| Role | File | What they own |
|---|---|---|
| Quote Operator | quote-operator.md |
Sprint queue, line-item pricing, sending quotes, follow-ups |
| Order Operator | order-operator.md |
Order lifecycle, purchase orders, delivery, invoicing handoff |
| Collection Driver | collection-driver.md |
Mobile app, supplier pickups, deliveries, surplus/shorts |
| Approver / Supervisor | approver-supervisor.md |
Approvals queue, pricing policy, escalations, dashboards |
How to read these
- Each SOP is role-scoped. Don't read another role's SOP unless you're cross-training. They overlap on shared handoffs — those overlaps are intentional and called out in the relevant procedures.
- The Daily Checklist is the minimum bar. If you only have 10 minutes, do the checklist.
- The Decision Tree is a fallback. When you encounter the situation and you don't know what to do, find the branch. The tree is not exhaustive — when in doubt, escalate (see each role's escalation path).
- KPIs are not aspirational. They are how your performance is measured in the weekly review. If a KPI is unclear, raise it — don't ignore it.
How to suggest changes
- Open a PR against the relevant file.
- PR title:
sop(<role>): <change>(e.g.sop(quote-operator): add partial-approval procedure). - Tag the approver / supervisor in the review.
- After merge, the
/sopspage in the app updates on the next deploy.
If you can't write the change yourself, drop the suggestion in
#sop-feedback and someone will turn it into a PR.
Conventions used in these documents
- Routes are written as
/path/to/page(e.g./sprint,/orders/123). - Buttons / actions are in bold (e.g. Claim).
- Status values are in
code(e.g.approval_pending,collection_pool). - Collection / field names are in
code(e.g.order_items.item_status). - SLA times are in working days (Mon–Fri, SAST). Weekends don't
count. The
isOlderThanWorkingDays()helper in the dashboard uses the same convention. - Currency is ZAR (excl. VAT) unless otherwise noted.
When a section is missing or wrong
These SOPs are derived from APP_CAPABILITIES.md, the
item_status lifecycle, the quote/order state machines, and the
order-workflow-rules. If the system has changed and the SOP hasn't:
- It's a doc bug. File a PR or ping the supervisor.
- The SOP is not authoritative over the system. The system is authoritative. If they disagree, follow the system and fix the SOP.