Learning contextDemo Retail Group LLC12 stores · 2 distribution centres · AED/SAR/USD · omnichannel replenishmentChange scenario details →
Skip to content

Demo Retail Group LLC: one complete operating day ​

This is the reference scenario used by the Academy when explaining retail. It is fictional training data, not a verified customer result. The company is a UAE retailer with two branches, one distribution centre, AED base currency, SAR and USD transactions, perpetual inventory, barcode items, VAT, and a leading IFRS book.

Opening context ​

At 07:00 the Dubai distribution centre opens with 1,200 oak chairs, 600 lamps, and 4,000 kitchen accessories. The branch manager sees 112 chairs reserved for online orders, 48 chairs on a transfer to Abu Dhabi, and 75 chairs in quality hold because the carton labels do not match the batch. The available quantity is therefore not the physical count. The operator must read on hand, reserved, in transit, quarantine, and available separately.

The opening checklist is not a single “open store” button. The supervisor confirms the company, branch, warehouse, posting period, cashier shift, payment types, price list, tax regime, and the default sales salesperson. If one of these is wrong, every later record may still save while reporting to the wrong legal entity or branch.

08:15 — replenish the fast seller ​

The buyer opens the item master for CHAIR-OAK-001. The code is the stable identifier; the description is customer-facing; the UOM is PCS; the category is furniture; the barcode is scanned at receiving and POS; the tax category supplies the default VAT rate; and the warehouse policy determines whether batches or serials are required. The buyer checks the availability report, not just the item’s last price.

An approved purchase request becomes a requisition and then an RFQ. The buyer records the supplier’s quotation currency, lead time, minimum order, incoterm, and validity. The comparison should show total landed cost, not merely unit price: freight, insurance, duty, clearing, and local delivery may change the preferred supplier. The purchase order records the supplier, company, branch, warehouse, expected date, currency, rate, lines, quantity, UOM, unit price, discount, tax, and project or cost centre if the buy belongs to a campaign.

At goods receipt, the warehouse user records supplier challan number/date, transporter, vehicle, e-way bill where applicable, warehouse, bin, batch, manufacture date, expiry date, and accepted quantity. A receipt is evidence that goods arrived; it is not automatically a supplier invoice. Quality inspection holds mismatched cartons. Only released stock becomes available for sale.

10:00 — a multi-branch customer order ​

Lulu places an order for 100 chairs for a Saudi store. The sales user selects the legal customer record, ship-to address, customer PO number/date, salesperson, currency SAR, price basis, payment terms, expected delivery, and Dubai warehouse. The header establishes the commercial context. Each line then carries the item, description, quantity, UOM, warehouse, price, discount, tax code, and project dimension.

The quotation is not posted. When Lulu accepts, the quotation becomes a sales order. OSERP checks credit policy and reserves 100 units, reducing available-to-promise while leaving on-hand unchanged. If only 80 can be promised, the correct action is a partial confirmation or alternate warehouse—not editing the ordered quantity to conceal the shortage.

If the discount exceeds the configured threshold, the document enters Approval. The approver sees the reason, margin, customer exposure, and delivery promise. Approving the document does not create revenue or cash; it unlocks the next stage.

12:30 — pick, pack, and dispatch ​

Fulfilment turns the open order quantity into a pick task. The picker scans the barcode and confirms the bin. Batch-controlled goods require the selected batch; a substitute must be recorded rather than silently scanned. Packing records carton count and handling notes. The delivery note records delivered quantity, transporter, vehicle, and logistics reference. Delivery cannot exceed the approved open quantity.

Shipment records the carrier, tracking reference, freight terms, dispatch time, destination, and in-transit status. A shipment is a logistics fact; the invoice is a legal receivable fact. Depending on company policy, delivery may issue stock and invoice may recognise the financial event, or the configured stage matrix may combine them. The consultant must read the actual Stage Matrix rather than teach a universal assumption.

15:00 — invoice and foreign-currency settlement ​

The invoice is raised for delivered quantities. The user rechecks the legal company address, Saudi place of supply, tax treatment, invoice date, posting date, due date, SAR exchange rate, payment terms, and customer PO. The invoice total is stored in SAR and translated to AED using the approved dated rate. A rate difference on settlement follows the FX policy; it is not corrected by changing the original invoice rate.

The GL Mapping simulation should show the expected roles: customer AR debited for the total, revenue credited for net supply, and the correct output tax or export treatment credited. The payment is a separate document. The bank transfer reference is captured, then allocated to the invoice. An unallocated receipt is still cash received but does not clear the customer’s open item.

17:30 — POS close and online reconciliation ​

The Dubai branch cashier closes the shift by payment type: cash, card, UPI, and gift/loyalty tender. The POS report is compared with the payment gateway settlement, cash count, refunds, and voids. A void is not a deletion; it retains the audit event and authority. A gateway callback must be idempotent so a retried webhook cannot create a second payment.

The e-commerce order feed is checked for reservation age, cancelled orders, split shipments, COD carrier balances, and returns awaiting inspection. Marketplace commission and chargeback lines are reconciled separately from the customer payment.

19:00 — return and exception handling ​

A customer returns five chairs. The return records source delivery/invoice, return note number/date, reason, quantity, batch/serial, condition, inspection result, and receiving warehouse. Damaged chairs go to quarantine, not saleable stock. The credit note reverses only the approved returned amount and tax. It does not delete the original invoice or rewrite history.

The operations manager investigates three exceptions: one unallocated card settlement, one carton in quarantine, and one order past its promised date. Each becomes an accountable work item with owner, evidence, next action, and due date. “Resolved” means the underlying record changed, not merely that a comment was added.

Daily control report ​

QuestionOSERP evidence
What can we sell tomorrow?On-hand minus reserved minus quarantine, by warehouse
What did each branch earn?Posted invoices and payment allocations by branch
Where is cash?POS close, gateway settlement, bank receipt, and unallocated balance
What is overdue?Customer statement and due-date ageing
What changed inventory?Delivery, receipt, return, transfer, adjustment, and audit trail
Which journal is wrong?Stage chain → journal → source document → GL Mapping rule

What improved because OSERP is used correctly ​

The business has one chain from customer PO to reservation, pick, delivery, invoice, payment, and return. Branches can see their own stock without pretending in-transit stock has arrived. Finance can explain an AR balance from posted documents. Warehouse can trace a returned batch. Management can separate sales margin from payment timing. These are control improvements produced by disciplined data and workflow—not automatic promises of the product.

Use this case with the sales field guide, advanced GL Mapping manual, API Library, and industry context. The same template will be applied to manufacturing, consulting, hospitality, e-commerce, projects, education, and nonprofit chapters.

OSERP™ Atlas · Understand every field. Master every workflow.