Stock Count — Interactive Prototype

9:41Stock Count100%

Check in

Select your store to begin

Rules engine

Rules the merchandiser app runs, in the order they can fire during a count. Each one lights up the moment it applies.

Activity log

Nothing yet. Open Stock Count and start scanning.

Near-expiry items marked as sold (R11 sheet)

Nothing logged yet.

Open points for the meeting

Restricted checkout list — demo blocks large packs and bottles. Final list comes from Tarweej as an Excel file, keyed by barcode.
UOM per item — fixed in the item master, not chosen by the merchandiser. IT to confirm this field exists for all Mars SKUs.
Warehouse check — compares against dates captured in the same visit. If a location has no entry yet, no comparison runs.
Warning vs block — warehouse date warning lets the merchandiser confirm and continue. Checkout restriction blocks entirely.
PDF export — generated on the phone and shared from there. If it should also reach the manager by email automatically, that is a server-side job and needs to be scoped separately.
Full report, shaded by urgency (R12) — the PDF is no longer a month-limited export. Every line in the report goes in; the current month and the next four are each shaded a different colour so the manager can scan by urgency at a glance, and the open-ended 6-months-and-beyond bucket stays unshaded since it isn't one specific month.
Item master source — the live version reads the existing Mars item list in the app. Category and UOM per barcode, plus a new checkout-restricted flag from Tarweej.
Created Date (R6) — pulled here from the Mars item master's CREATED_ON column. GALAXY Jewels 550g is the one genuinely new SKU in this demo list (created about a month ago), which is why it is the item that triggers the warning.
Store + month key (R11, R14) — this demo has one store and one fixed "last month" report to show the logic. The live version needs every store's report keyed by store + month so this and the leader checklist can look back reliably.
R11 walkthrough default — CELEBRATIONS 600g is the running example for this rule: last month's report recorded it with an expiry of that month, and this month's count has no line for it at all. Press Finish count → Fully finished without scanning it and the audit screen shows: "CELEBRATIONS 600g was on last month's report with an expiry within the next 4 months, but has not been counted this month — are you sure it was sold and is no longer in the market?"
Quantity-increase confirmation (R7) — same CELEBRATIONS 600g example: last month's report recorded 12 cases for its expiry month. Scan it this month, enter a higher quantity at that same expiry, and the confirmation sheet fires before the line saves. Declining leaves the merchandiser on the count screen with nothing saved — they can adjust the quantity or leave via the back button at their own pace; only "Yes, confirmed" proceeds.
Full or partial finish (R10) — pressing Finish count always asks this first. Choosing "Continue next visit" skips the R11 audit and the R12 PDF export entirely for this visit; the count stays open and reappears exactly as left next time. Only "Fully finished" unlocks the rest.
Leader app (R13) — shown here as a toggle for convenience. In production it is a separate app on the leader's own device.
Merchandiser identity (R14) — this demo hard-codes this month's and last month's merchandiser to always differ, so the top-priority notification is easy to see. In production it comes from the login on each report.
Accuracy score (R13) — intentionally not built beyond the Area Manager's Merchandiser Accuracy page. Not tied to incentives for at least 6 months once it exists.
Area Manager dashboard — read-only, laid out like the team's existing Tableau reports (grid + filter rail), with a Stock Count Report tab and a Merchandiser Accuracy tab. Real columns come from this demo's data; region/account/site-number/Mars-code columns from the live Tableau report are not modelled here and would come from the same data source in production.
Merchandiser Accuracy page — now built, not just a placeholder. Two prior months are fixed demo history; the current month's row is computed live from the leader's matches/corrections this session. A merchandiser needs at least 10 recorded reviews before being ranked, so one bad week can't brand someone the worst performer.
R11 answers are not graded for "field verification" — the merchandiser app is GPS-gated and only runs while on-site at the store, so every "sold" or "confirmed not present" answer is already given in person. There is no separate unverified/verified tier — both are logged and trusted the same way.
Rule numbering (R1–R14) — numbered in the order they actually fire during the merchandiser's visit, not the order they were first specified. Export (R12) moved from its original "R8" to last, since it only unlocks after a full finish; the leader's two rules are R13/R14, since they only ever read what already happened here.
Language toggle (EN/AR) — top right. Switches the merchandiser app's screens, buttons and rule descriptions for IT to preview both. Leader and Area Manager screens are English-only in this pass.

Handoff · Android engineering team

Stock Count — Requirements & Business Logic

This page defines the business logic, data model, and integration requirements for this project. Implementation is entirely up to your team.

1. Rules — one requirement each

Format: Condition → Expected behaviour → Data required. No day-capture, no partial dates — every date in this system is month + year only, unless stated otherwise.

Rule	Condition	Expected behaviour	Data required
R1	A barcode is scanned or typed.	Only Chocolate, Confectionery, Gum and Healthy categories may be counted. Any other category (or an unknown barcode) is rejected immediately — no entry is created.	Item category, per barcode.
R2	Location = Checkout, and the scanned barcode is on the restricted list.	Entry is blocked entirely — cannot be saved. The same barcode counts normally at the other three locations.	Checkout-restricted flag, per barcode.
R3	Item is matched.	Unit of measure (Outer or Case) is fixed per item and shown, not chosen. Piece is never offered as an option.	UOM, per item.
R4	Merchandiser is entering an expiry for a count line.	Picker offers exactly 6 options: the current month, the next 4, and a 6th open-ended option covering every date 6 months out and beyond. The 6 options roll forward automatically as the calendar month changes.	Current system date only.
R5	The same item is scanned again with a different expiry date already recorded this visit.	Saved as a new, separate line. Existing lines for that item are never overwritten.	Count lines already recorded this visit.
R6	Item's Created Date is within the last 6 months, and the entered expiry is less than 6 months from today.	Non-blocking confirmation naming the item as new and asking the merchandiser to confirm the date. Declining returns to the count screen to edit the expiry — nothing saves. Confirming saves. This must never affect any accuracy/performance score.	Item Created Date (Mars item master).
R7	This visit's running quantity for an item + expiry date exceeds what last month's report recorded for the same store, item and expiry date.	Non-blocking confirmation showing last month's quantity vs. this visit's, asking the merchandiser to confirm. Declining returns to the count screen to edit the quantity — nothing saves until confirmed.	Last month's quantity for the same store + item + expiry (via the store+month key, §2).
R8	Selected expiry = the current month.	Warning, not a block. Merchandiser is instructed to pull the stock, mark the barcode, and move it to damages. Entry saves and is flagged accordingly once confirmed.	None beyond the entry itself.
R9	A Warehouse-location entry and an in-store entry exist for the same item, and the warehouse date is nearer than the in-store date (in either direction of entry).	Blocking — cannot save until corrected. Message must name which in-store location it was compared against and both dates.	All count lines for that item across locations, this visit.
R10	Merchandiser presses Finish count.	Must ask first whether this store's count is fully finished or will continue on a future visit, before anything else runs. A partial answer skips R11 entirely and hides R12 until a later visit is marked fully finished; existing lines stay saved and reappear exactly as left.	This visit's draft report and its finished/partial state.
R11	Runs only after "fully finished" (R10). For every item on last month's report (same store) whose expiry falls within the next 4 months and that has not been counted this visit.	Ask "sold and no longer in the market?" — Yes/No. Yes: log to a separate sold record (merchandiser name + ID, store, item, expiry, timestamp). No: item returns to this visit's task list; must be counted or explicitly marked "confirmed not present" before the count can finish.	Last month's report for the store (store+month key), filtered to the 4-month window; this visit's counted barcodes.
R12	Reachable only after a full finish (R10) and submission.	Exports the entire report — never a month-limited subset. Columns, in order: City, Store, Brand, Item, Expiry, Qty, Location, UOM, Note. Sorted by nearest expiry, then location, then brand and item. See §5 for the required shading.	The full submitted report for this visit.
R13	After any store's report is submitted for a period.	Generate a 5–10 item review checklist per store for the leader, in priority order: (1) R14 mismatch if triggered, (2) items that raised an R6 warning this period, (3) quantities differing 50%+ vs. last month, (4) an item present in the two prior reports that has no line this period and whose recorded expiry is within the near-term window, (5) random sample. Leader's only options are Matches / Needs correction — the leader cannot edit values directly. Needs correction sends a task to the merchandiser with the leader's note; before/after value, who resolved it, and when must all be stored. This checklist must never block the merchandiser's count from closing.	This period's and the prior period's report per store (store+month key); R6-flagged lines; correction records.
R14	The merchandiser (name + employee ID) who submitted this store's report this period differs from who submitted it last period.	Always ranks first in R13's checklist, ahead of every other item. The leader-facing notification must state the reason explicitly — e.g. "the merchandiser who counted this month is different from the one who counted this store last month" — not a generic "review this store."	Submitting-merchandiser identity per store, this period and the prior one (store+month key).

2. The store + month key

R7, R11, R13 (priority 3–4) and R14 all depend on being able to look up exactly one report for a given store and a given month — this period's and the prior period's. This key must exist and be reliable before any of those four rules can be implemented correctly; get it agreed with backend first, not last.

Every submitted report belongs to exactly one (store, year, month) combination.
Each report carries the identity (name + employee ID) of the merchandiser who submitted it.
Given a store and a month, it must be possible to fetch: that month's report, and the immediately prior month's report, reliably and without ambiguity.

3. Backend API contract needed

These endpoints (or their equivalents) must exist server-side — confirm exact shapes and auth with backend before building against assumptions:

Item master — barcode, brand, name, category, UOM, checkout-restricted flag, Created Date. Full list, syncable.
Fetch a store's report for a given year/month — keyed exactly per the store+month key above.
Submit a store's report for the current period — including the full/partial flag from R10.
Fetch a store's leader checklist for a period, and resolve one item (Matches / Needs correction, with note).
Fetch a merchandiser's rolling accuracy figures (for the Area Manager's accuracy page).
Auth — reuse whatever scheme the existing Tarweej apps already use.

4. Non-technical functional requirements

These are requirements, not implementation suggestions — how each is built is up to your team.

Offline-first. The merchandiser app must keep working, and let the merchandiser keep counting, without an internet connection. Last month's data (needed by R7 and R11) must already be available on the device before a store visit starts, not fetched mid-visit.
Full right-to-left (RTL) support. The merchandiser app must render correctly, completely, in Arabic — not just translated strings, but a genuinely mirrored layout. Numbers, barcodes and dates stay left-to-right even inside an RTL screen.
Location verification at Finish count (R10). Before a "fully finished" answer is accepted, the app must verify the device is physically at the store. This is a hard requirement of R10 — a full finish is not a UI choice a merchandiser gets to declare freely from anywhere.
Barcode reading. The app must support scanning a barcode via the device camera. Manual (typed) barcode entry must also be supported as a fallback for damaged or unreadable barcodes.

5. PDF shading colours (fixed design requirement)

Not a suggestion — the printed report must use exactly this palette, so it matches what has already been reviewed. Current month through +4 months, one colour each; the 6th, open-ended bucket ("6 months and beyond") gets no fill, since it isn't one specific month.

Bucket	Colour	RGB
Current month	Light red	253, 226, 226
+1 month	Light orange	254, 235, 220
+2 months	Light yellow	253, 247, 214
+3 months	Light yellow-green	236, 246, 220
+4 months	Light green	221, 243, 233
6 months and beyond	No fill	—