Full P2P implementation on XeerSoft Cloud ERP as sole Implementation Consultant: gathered procurement requirements, configured master data for 180+ materials and 10+ vendors, designed 2-level approval workflow, and applied statistical modelling to solve chronic stockouts at Newton Sixth Form School.
Newton's uniform and textbook procurement ran on intuition — 22% of intake seasons hit XS/XXL stockouts. I rebuilt it as a statistically-planned, approval-controlled procure-to-pay system on XeerSoft Cloud ERP.
Newton Sixth Form managed procurement for school uniforms (~180 SKUs) and textbooks (~40 titles) without a structured system: purchase requests were uncontrolled, approval was informal, and uniform stockouts occurred every intake season due to intuition-based ordering.
· Chronic XS/XXL stockout rate at 22% of intake seasons, root cause: planning parameters set by intuition, not statistical models
· Textbook over-ordering at 8–12% buffer above enrolment → ฿28–45K annual write-off from obsolete editions
· No approval threshold: any staff could raise unlimited purchase requests
I joined as sole Implementation Consultant. The challenge wasn't simply to configure an ERP module: it was to diagnose why the existing process was failing, design a system that solved root causes, and ensure adoption across 15+ procurement staff.
I split the work into three streams running in parallel: (1) Master Data Configuration for 180+ materials and 10+ vendors on XeerSoft, (2) Statistical Modelling to calculate scientifically-grounded reorder parameters, and (3) Workflow Design for 2-level purchase approval authorization.
Before configuring a single screen I fixed the consulting spine of the build: the method that decides the numbers, the tools that hold them, and the logic the developers implement. Every interactive exhibit further down is an artifact of one of these three.
The root cause was intuition-based ordering. I matched a demand model to how each SKU actually behaves, then sized and timed every order from it.
The numbers live in the XeerSoft master data I configured and are read back for decisions — no parallel spreadsheets drifting out of sync.
I wrote the system's behaviour as decision rules in the FSD — not prose — so the build is traceable and testable line by line.
Read the rest of this page as proof of the spine above: the Procurement Simulation runs the methodology live, the Order Entry catalog is the configured tooling, and the FSD logic is what the developers received.
Every stock item asks the same question: how much safety stock guards against a stockout at a 97% service level? The honest answer depends on how much the item actually sells — so I chose the demand model by volume, not by product type. The three panels show why.
The model is chosen by demand volume, not by product. At very low volume a Normal curve even predicts impossible negative demand (the red 2.3% at λ=4), so low-volume SKUs use Poisson — safety stock from the mean alone, which is robust when there's too little sales history to estimate σ reliably. As volume rises the two converge (λ=19.5 → reorder 28 vs 27.8; λ=63 → 78 vs 77.9), so high-volume sizes use the simpler Normal-Z.
Three planning rules, each matched to how its items behave. The Purchase Requisition catalog below tags every line with the rule that governs it.
| Planning model | Applied to | Why this model |
|---|---|---|
| Poisson | Low-volume SKUs — XS/XXL sizes, minority subjects, subject-kit specialty | Safety stock from the mean alone; robust when sales history is too thin to estimate σ |
| Normal-Z | Mid / high-volume sizes & steady consumables | Enough history to estimate σ; a service-level Z gives a tighter reorder point |
| Modified EOQ | Textbooks (~40 titles) | Order size balances holding vs ordering cost, with an edition-risk penalty to curb obsolete-edition write-off |
Capital equipment (laptops, tablets, scanners) is deliberately not demand-planned — it's irregular and high-value, so it's controlled by the value-based approval routing instead. Alongside this: a 2-level approval workflow (≤ ฿50K → Dept Head, >฿50K → Director), ABC stock flagging, ~180 uniform SKUs and ~40 textbook titles configured, a vendor master for 10+ suppliers, and the full P2P cycle (Purchase Requisition → Purchase Order → Goods Receipt → Invoice, 3-way match).
"We only run statistical planning on recurring stock items, and we match the distribution to each SKU's demand volume — Poisson where data is too sparse to estimate σ, Normal-Z where it isn't. Capital equipment isn't forecast at all; it's irregular and high-value, so it's controlled by value-based approval routing."
The full P2P process as configured in XeerSoft, driven by module screens and menu navigation (no transaction codes). Each step maps to a module → function path in the live system.
| # | Process Step | XeerSoft Module → Function |
|---|---|---|
| 1 | Create Purchase Requisition | Procurement › Purchase Requisition › Create |
| 2 | PR Approval · 2-level | Workflow Authorization › Approval Rule |
| 3 | Create Purchase Order | Procurement › Purchase Order › Create |
| 4 | Goods Receipt | Inventory › Goods Receipt |
| 5 | Invoice Matching · 3-way match | Procurement › Invoice Matching |
| 6 | Stock Monitoring | Inventory › Stock Balance / Reorder Report |
| 7 | Vendor Evaluation | Procurement › Vendor Scorecard |
| 8 | Master Data | Inventory › Item & Vendor Master |
Build a requisition from the configured catalog and watch the planning class and approval routing respond — the specified behaviour I designed, not the proprietary XeerSoft UI. The catalog is the item master I set up across six classes (Uniforms, PE Kit, Subject Kit, Stationery, Textbooks, Equipment). Each stocked line is tagged by its planning model (Poisson for low-volume sizes & minority specialty; Normal-Z for steady consumables; Modified EOQ for textbooks) with a live stock signal against its reorder point; capital equipment is value-routed, not demand-planned. Every unit carries a 9-character serial and a Learn Balance Code (LB######) engraved to the owning student at issue. Submitting applies the 2-level approval rule (FSD-P1-01: ≤ ฿50,000 → Dept Head; > ฿50,000 → Director) — add an Equipment line and watch routing escalate to Director.
The business logic I authored in the Functional Specification Document (FSD) and handed to the XeerSoft development team to implement.
An interactive simulation that runs the FSD logic above directly in your browser: it reproduces the specified behaviour I designed, not the proprietary XeerSoft UI.
Purchase Requisition
Routing Decision · FSD-P1-01
Stock vs statistical target · FSD-P1-03
Drag on-hand to watch status recompute: STOCKOUT if below safety stock, OVERSTOCK if above target × 1.2.
| SKU | On-hand | Safety | Target | Status |
|---|
Equipment catalogue · pick & quantity
Capital / equipment items at Thai-market reference prices; the PR total auto-routes by the ฿50K rule (FSD-P1-01).
Purchase Requisition · auto-routed
On XeerSoft Cloud ERP I worked as Functional Consultant / Business Analyst, owning requirements, configuration, FSD authoring, UAT and defect management. The custom logic below was implemented by XeerSoft’s in-house development team against my specifications.
The pseudocode shown is the specified expected behaviour (my FSD deliverable), not vendor source code, and deliberately platform-neutral so it reads the same to a XeerSoft or generic ERP reviewer.
I did not sign off the build as one pass/fail. I decomposed the P2P scope into 10 sub-unit tests, each run as a manual test case of ~10 ordered steps validated against 5 complex conditions, with one written specific assurance per sub-unit (the exact thing the test guarantees). This is the breakdown behind the UAT & defect-fix window in the delivery timeline below — the part that is easy to claim and hard to show.
Each sub-unit test is a manual procedure: log in under the correct role, drive the transaction step by step, and confirm the posting, workflow and data outcome at each gate. Every test carries 5 complex conditions — partial / over-tolerance / variance / missing-config / period-control paths — not just the happy path. A sub-unit only closes when its specific assurance holds under all five and a regression retest is clean.
Manual procedure · 10 steps
Complex conditions · 5 paths
Guarantees that no goods movement posts without a valid inventory + receipt/invoice clearing account pair, that the 3-way match holds quantity and price within the configured tolerance key, and that receipt/invoice clearing nets to zero after invoice posting. A receipt that cannot derive a GL account is hard-stopped with an error, not silently skipped — the exact failure mode caught in UAT cycle 1 and closed as DEF-P1-01.
| ID | Sub-unit | What broke (symptom) | Sev | Root cause | Fix I specified to dev | Days | Retest |
|---|---|---|---|---|---|---|---|
| DEF-P1-01 | UT-04 receipt posting | Goods receipt for the IT-asset item category silently failed to post — no error, no receipt document. | HIGH | No GL account determination for that item accounting category — posting had no inventory / offset account. | Mapped the asset category → inventory GL 160000 + receipt/invoice clearing, and added a hard-stop error when determination is missing. | 2 | ✓ PASS |
| DEF-P1-02 | UT-02 PR approval | Editing a PR amount above ฿50K after first submit did not re-trigger director approval. | HIGH | Approval route was evaluated only on create, not on value change. | Re-evaluate the approval route on any value edit and reset prior approvals before re-routing. | 3 | ✓ PASS |
| DEF-P1-03 | UT-05 3-way match | An invoice with 7% unit-price variance auto-posted instead of blocking. | MED | Tolerance key upper limit was set too wide (10%). | Tightened the price tolerance to 5% and routed over-tolerance invoices to the buyer worklist. | 2 | ✓ PASS |
| DEF-P1-04 | UT-08 EOQ reorder | Textbook reorder point ignored edition risk and over-ordered obsolete editions. | MED | Safety-stock formula used plain EOQ with no edition-risk penalty term. | Added an edition-risk penalty to EOQ so flagged editions order down toward run-out. | 4 | ✓ PASS |
| DEF-P1-05 | UT-09 vendor scorecard | Late-delivery count double-counted across partial GRs of one PO line. | LOW | Scorecard counted each partial receipt as a separate late event. | Dedupe on the PO line; count only the first late event per line. | 1 | ✓ PASS |
5 defects raised to the XeerSoft dev team across the UAT window, ~12 working days of fix-and-retest in total. Two were go-live blockers (silent goods-receipt failure, approval bypass); all five closed with a clean regression retest before the intake-season Go-Live. The discipline is the point: every defect has a named symptom, a root cause, a fix I specified, and a retest result — nothing closed on assertion.
Rather than guess safety stock values, I applied three different statistical models based on SKU demand patterns, and entered the calculated parameters directly into XeerSoft inventory planning fields.
· Poisson Distribution for low-volume SKUs (λ < 25): XS and XXL uniform sizes at 97% service level
· Normal Z-score for mid-range sizes (S–L) with stable demand patterns
· Modified EOQ with Edition-Risk Penalty for textbooks subject to edition obsolescence
An XS or XXL shirt doesn't sell in a steady stream. It sells as a few separate, countable events over a season: rare, independent arrivals that Poisson is built to describe. The choice between Poisson and the Normal model comes down to one thing, how much the size sells.
The model is chosen by demand volume, not by product. At very low volume the Normal curve even predicts impossible negative demand, so the low-volume tails (XS, XXL) use Poisson: safety stock from the mean alone, robust when there is too little sales history to estimate σ reliably. As volume rises the two converge, so high-volume sizes (S–L) use the simpler Normal-Z. The λ = 21 and λ = 78 panels are the same XS and M SKUs from the worked example below (reorder 30 and 95).
Turning the models into the actual numbers entered into XeerSoft's Reorder-Point Planning fields. The inputs below are reconstructed so they reproduce the safety stock and reorder points behind the 97% service level (the same ROPs the order screen above flags against); the achieved outcomes (stockout 22% → 3%, write-off ฿45K → ฿8K) are the real results.
| SKU | Model | Demand | Lead time | λ / σ_LT | Safety stock | Reorder point |
|---|---|---|---|---|---|---|
| PE Shirt · XSlow-vol | Poisson | ~3 /wk | ~7 wk | λ = 21 | 9 | 30 |
| PE Shirt · M | Normal-Z | ~13 /wk | ~6 wk | σ_LT ≈ 8.8 | 17 | 95 |
| PE Shirt · XXLlow-vol | Poisson | ~3 /wk | ~7 wk | λ = 21 | 9 | 30 |
The reorder-point and EOQ models above plan independent-demand items, whose demand comes from forecasts. But when an item's demand is derived from a parent through a bill of materials, you don't forecast it, you calculate it. That is Material Requirements Planning. Below is a full MRP run worked end-to-end on a 4-item, 3-level BOM, every number traced from the master schedule down to the shop-floor release.
Standard A/B/C/D worked example, used to demonstrate the MRP method itself, not a specific client BOM.
MRP is a push system: a master schedule pushes calculated requirements down the BOM and out as orders, rather than pulling against live consumption. The split that decides the planning method is the type of demand.
Originates outside the system (customers, term intake). Planned with reorder point / EOQ / statistics — the uniform and textbook SKUs above.
Derived from a parent item's schedule. Never forecast: it is exploded from the parent through the bill of materials. This is the job MRP does.
Each parent's planned release becomes the child's gross requirement, then on-hand is netted off:
| Component | Source (parent release) | × per parent | = Gross req | On-hand | Net req |
|---|---|---|---|---|---|
| B | A: 80 @W5 · 50 @W7 | ×2 | 160 @W5 · 100 @W7 | 30 | 130 @W5 · 100 @W7 |
| C | A: 80 @W5 · 50 @W7 | ×1 | 80 @W5 · 50 @W7 | 10 | 70 @W5 · 50 @W7 |
| D | B: 130 @W3 · 100 @W5 | ×1 | 130 @W3 · 100 @W5 | 0 | 130 @W3 · 100 @W5 |
| Week | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
|---|---|---|---|---|---|---|---|---|
| Gross requirements | – | – | – | – | – | 100 | – | 50 |
| Scheduled receipts | – | – | – | – | – | – | – | – |
| Projected on-hand | 20 | 20 | 20 | 20 | 20 | 0 | 0 | 0 |
| Net requirements | – | – | – | – | – | 80 | – | 50 |
| Planned order receipt | – | – | – | – | – | 80 | – | 50 |
| Planned order release | – | – | – | – | 80 | – | 50 | – |
| Week | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
|---|---|---|---|---|---|---|---|---|
| Gross requirements | – | – | – | – | 160 | – | 100 | – |
| Scheduled receipts | – | – | – | – | – | – | – | – |
| Projected on-hand | 30 | 30 | 30 | 30 | 0 | 0 | 0 | 0 |
| Net requirements | – | – | – | – | 130 | – | 100 | – |
| Planned order receipt | – | – | – | – | 130 | – | 100 | – |
| Planned order release | – | – | 130 | – | 100 | – | – | – |
| Week | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
|---|---|---|---|---|---|---|---|---|
| Gross requirements | – | – | – | – | 80 | – | 50 | – |
| Scheduled receipts | – | – | – | – | – | – | – | – |
| Projected on-hand | 10 | 10 | 10 | 10 | 0 | 0 | 0 | 0 |
| Net requirements | – | – | – | – | 70 | – | 50 | – |
| Planned order receipt | – | – | – | – | 70 | – | 50 | – |
| Planned order release | – | – | – | 70 | – | 50 | – | – |
| Week | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
|---|---|---|---|---|---|---|---|---|
| Gross requirements | – | – | 130 | – | 100 | – | – | – |
| Scheduled receipts | – | – | – | – | – | – | – | – |
| Projected on-hand | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| Net requirements | – | – | 130 | – | 100 | – | – | – |
| Planned order receipt | – | – | 130 | – | 100 | – | – | – |
| Planned order release | – | 130 | – | 100 | – | – | – | – |
| Item | BOM level | Planned order releases |
|---|---|---|
| A | 0 · end item | W5 → 80 · W7 → 50 |
| B | 1 | W3 → 130 · W5 → 100 |
| C | 1 | W4 → 70 · W6 → 50 |
| D | 2 | W2 → 130 · W4 → 100 |
All planned order releases on one timeline. Read the staircase: the deeper the item, the earlier it must start, so the schedule cascades up from D toward the end item A.
| Item | W1 | W2 | W3 | W4 | W5 | W6 | W7 | W8 |
|---|---|---|---|---|---|---|---|---|
| D | – | 130 | – | 100 | – | – | – | – |
| B | – | – | 130 | – | 100 | – | – | – |
| C | – | – | – | 70 | – | 50 | – | – |
| A | – | – | – | – | 80 | – | 50 | – |
Every BOM level adds its own lead-time offset, and the offsets compound down the tree. To have A ready in Week 6, the deepest branch has to start far earlier:
That is a 4-week cumulative lead time across three levels for what looks like a 1-week end item. The same compounding is exactly why the independent-demand SKUs above carry a 6–7 week planning lead time: the supplier offset plus every upstream step, stacked. Plan against the cumulative lead time, never the item's own.
The MRP run above is the method in the abstract; this is the same explode → pool → cost → offset logic applied to the institute's real start-of-term procurement. Three headcounts drive the whole plan: change them (or pick a different device model) and the demand, cost and order timeline recompute live.
Prices are Thai-market reference (2026), starting configurations; adjust per quote. Lead times in weeks. Everything below recomputes from these inputs.
Each headcount explodes into per-item quantities through its kit:
| Item | Per unit | Headcount | Quantity |
|---|
Pens, folders and the teacher set are stationery-class items used across kits. Instead of ordering them per-kit, they net into one consolidated stationery PO (the Stationery vendor from the scorecard above): fewer POs, one delivery, volume pricing.
| Pooled item | Source | Qty | Cost |
|---|
| Item | Qty | Unit ฿ | Line ฿ |
|---|
Goods-ready is week 0 (term start). Order release = 0 − lead time:
The longer the bar, the earlier the order must be placed. The Apple / laptop devices (LT5) start the whole procurement, five weeks before term.
The LT5 devices (Lenovo laptop, iPad, MacBook) are both the schedule bottleneck — ordered 5 weeks before term, earliest of anything — and the cost centre:
Everything else can wait until the last 1–2 weeks, but slip the device order and the whole term opening slips. Same compounding lead-time logic as the MRP run above: plan the long-lead, high-value items first — which is why those sit at the 6–7 week end of the planning horizon.
Configured the full master data foundation for the P2P cycle from scratch on XeerSoft.
Vendor master records were scored each cycle on delivery, quality, price and lead time, and the underperformers actively managed. Driving them up moved portfolio on-time delivery 68% → 87%.
| Vendor | Scope | On-time | Quality | Lead time | Score |
|---|---|---|---|---|---|
| Vendor A | Uniforms | 92% | 98% | 35 d | 4.6 |
| Vendor B | Core textbooks | 88% | 96% | 21 d | 4.4 |
| Vendor C | Imported texts | 81% | 95% | 45 d | 4.0 |
| Vendor D | Stationery | 90% | 97% | 14 d | 4.5 |
| Vendor E | Lab consumables | 84% | 94% | 28 d | 4.1 |
The measurable outcome was not one isolated KPI; it was a controlled P2P operating model. Uniform stockouts moved from 22% to 3%, unauthorised POs from 30% to 0%, textbook write-off from ฿45K to ฿8K, and vendor on-time delivery from 68% to 87%. Those are the same audited results shown in the executive KPI cards and Power BI exhibit above.
How the project was actually run end-to-end after the consulting work above: the timeline and where it was at risk, how I specified the build for the developers and verified it, the weekly Agile cadence, and the stakeholder network I coordinated as the single point of accountability.
Go-Live was gated to the June intake season: uniforms and textbooks had to be on shelf before the Jun–Jul intake. Slipping the date meant another full season at the old 22% stockout rate plus ฿28–45K of textbook write-off. The schedule was not flexible: the intake calendar set a hard, externally-fixed deadline.
Project timeline · month-by-month
Schedule risk & recovery
During UAT, goods-receipt posting was blocked for the IT-asset item category because no GL account determination existed (FSD-P1-02), a silent stopper that would have frozen receiving. Resolved → I traced it to a missing mapping, specified the fix to dev (category → GL 160000), retested, and kept Go-Live on the intake date.
The statistical reorder points were correct, but procurement staff were used to ordering by gut feel: the real risk to the result was non-adoption, not configuration. Resolved → I ran weekly adoption reviews for the first 3 months post Go-Live until system-driven reorder points became the default.
Spec design → developer handoff → build verification
How I spec for developers
How I verify the build (functional, not source-code review)
Weekly Agile cadence
Backlog & defect triage by severity
Spec clarification with dev
Build structure review vs FSD
Test / retest fixed items
Demo + stakeholder sign-off
Stakeholder network & RACI
| Stakeholder | Count | Their part | RACI |
|---|---|---|---|
| You · Consultant/BA | 1 | Requirements, config, FSD, UAT, training | A / R |
| Director & Dept Heads | 2+ | Approval workflow authority (฿50K rule) | C / A |
| Procurement staff | ~15 | Day-to-day users; trained & on-boarded | I / R |
| Vendors | 10+ | Master data, lead-time, scorecard | C |
| XeerSoft dev team | remote | Built config logic from my FSD | R |
I was the only consultant, but not working alone. I was the single node connecting approvers, ~15 users and the vendor dev team, and the only person with end-to-end visibility of requirements, build and adoption.
The biggest learning was that ERP success is 30% configuration and 70% adoption. The statistical models were rigorous, the workflow was clean, but the real win came from training procurement staff to trust system-driven reorder points instead of intuition. Weekly review sessions for the first 3 months post Go-Live were critical to making the change stick.