How to use the Stock Count app

M-KOPA Nigeria's end-of-month stock count. Stock controllers and the WH team scan device serials; admins reconcile the scans against the expected inventory (the manifest), explain or fix every difference, and sign each region off for audit.

Who uses it

• Shop Controller scans stock at a shop / depot.
• Warehouse Team scans stock at the warehouse locations.
• Regional admin (Viewer role) looks after one or more regions: manages who can scan there, explains variances, proposes fixes. Can view every region but only change their own.
• Auditor works from the Audit desk: approves or rejects fixes (moves, floor additions), approves or returns each region's count, spot-checks and downloads evidence. Read-only everywhere else.
• Allocations the Central Allocation Team: sees only the DSR custody tracker and follows up phones that are with DSRs but still on a shop's list.
• Super admin runs everything — uploads, settings, admin access — in every region.

Month-end checklist for regional admins

1. Before the count: in Scanner access, check every stock controller in your region is mapped to the right location(s), including relief cover.
2. After the count: open My actions to see what's left per location, then click Open on each one (or go to Reconciliation — it opens on your region).
3. Work through the fix panels first (they explain many rows at once):
   • Found at a shop, still on the WH list → Count at shop, send to WH.
   • Scans saved under the wrong location → Propose move.
4. Then give every remaining Missing and Unexpected row a reason code (click the Reason cell, or bulk / template).
5. For real phones on no list, use U02 / U03 / U04 — they go to an auditor as floor additions.
6. DSR re-codes: in My actions, click the purple DSR re-code number. Reconciliation opens on just those phones (each shows last month's DSR details). If they're still with the same DSR, click Carry forward M01. If something else happened (sold, stolen, back in the WH…), click the phone's Reason cell and give that code instead — any reason answers it, and the DSR custody case closes.
7. Submit your region. It turns Ready to submit by itself in My actions → Region sign-off once the count window has closed, every Missing and Unexpected row has a reason, nothing is waiting for an auditor and no M01 is missing its DSR details. Click Submit for audit, review any warnings and confirm, as preparer, that the reasons reflect what was found. Your name, the time and your confirmation are recorded and go into the auditor's evidence pack.

Month-end checklist for auditors

1. Open the Audit desk and pick the count month. The tiles show what's waiting for you.
2. Decide the queues first — move batches and floor additions. A region can't be approved while it has any pending.
3. In Region readiness, look at each submitted region: % explained, blockers and quality flags (Other reasons, M07 without a case reference, M01 without DSR details, M12, DSR cases stuck 3+ months, large bulk-applied reasons). Use Review to see the detail in Reconciliation and Serial search for any single phone.
4. Draw sample to pick random explained variances, check them in the field, and fill in the result columns of the downloaded file.
5. Approve the region, or Return it with a note saying what needs fixing.
6. Download the region's Evidence pack for the audit file.

1. Scanning — Shop Controllers & Warehouse Team

Start a session

• Open the app — you're signed in automatically with your M-KOPA account.
• Your role and location come from Scanner access. With one assigned location you'll simply see "You're scanning as … / [your location]" — nothing to pick. With several, choose from your assigned locations only. Wrong or missing location? Ask your regional admin.
• Choose the Model (required) and Condition, and (Warehouse Team) the Dynamics Warehouse / Location.
• Tap Start scanning.

While scanning

• The big "Scanning into …" box at the top always shows the location your scans are being saved to. Check it before each safe or shelf.
• If you're assigned more than one location (e.g. Ajah 1 and Ajah 2 in one shop with separate safes), use Switch location before you start the next safe — no need to restart.
• If most of your recent scans belong to your other location, the app warns you: "12 of your last 14 scans are listed under Ajah 2". Tap Switch if you're in the wrong place, and tell your admin so the earlier scans can be moved.
• Accepted serial formats: IMEI — starts with 3 or 8, 15 digits; or R-serial — starts with R, 11 characters. At the main warehouse only IMEIs are accepted.
• Scan the phone's first IMEI (IMEI 1). Scanning IMEI 2 makes the phone look missing.
• Model is required. Pick it before you start and change it when you move to a different model. R-serials are only accepted for A24 and A52 — an R-serial under any other model is a wrong scan and is refused (not saved).
• End session waits for syncing. The green line under your counts shows "All scans synced ✓" or how many are still waiting. End session (and Start a new session) stay locked until everything has reached the server; the summary then confirms your scans against the server.
• Each scan beeps / vibrates, so you don't need to watch the screen. Model / Condition can be changed mid-session.
• The app checks the model against the IMEI. The first 8 digits of an IMEI tell which model the phone is. If they don't match the model you picked, you hear a falling two-tone sound and see "This IMEI belongs to an A07s. You selected A06." Tap Switch to A07s and save (your model changes for the next scans too), or Cancel. On count days the wrong model can't be saved. If you're sure the phone really is the model you picked, cancel, put it aside and tell your admin — only the super admin can accept it as an exception.
• "Check this IMEI" appears when MkNet has never seen the phone's IMEI prefix. Usually it means you scanned IMEI 2 or a box code — tap Rescan and scan IMEI 1 (the top barcode). If you're sure it's IMEI 1 (e.g. a new model or a refurb), tap It's IMEI 1 — save it; it is saved and flagged for your admin.

What the badges mean

• Synced saved.   Pending held on your device, syncing in the background.
• Server dup already saved this month — the line underneath says where and when it was first scanned. If that's a different location, check you have the right one selected.
• Not assigned you aren't assigned to that location — ask your admin.
• Wrong location / Rejected not allowed (e.g. an R-serial at the main warehouse, or an R-serial under a model other than A24 / A52).
• Not saved the count window was closed.

Good to know

• Scans work on a weak connection — they sync automatically, one batch at a time, and are never saved twice.
• You can pause and resume; the screen stays awake while scanning.
• If scanning is disabled, the count window is closed — contact the admin.

2. Scanner access — who can scan where

Admin → Scanner access. The scan app only offers each person their assigned locations, and the server refuses scans anywhere else.

• The list starts from who actually scanned in the last 2 months, with scan counts per location. Locations holding 5%+ of a person's scans are suggested; tiny counts are usually mistakes.
• Accept suggested (one person) or Accept suggestions for all not mapped, then Edit anyone who looks wrong.
• Add a scanner by email, or Add in bulk: one line per email, location, valid_until. valid_until (yyyy-mm-dd) is for relief cover — access ends automatically.
• Regional admins manage only their own regions' locations and can't give themselves scanning access. Auditors see the latest access changes on the Audit desk.
• Grace / Strict (super admin): in Grace, people not on the list can still scan and appear as Not mapped; in Strict, they can't scan until added.

3. The Admin page

• Overview — what data is loaded, and the sign-off status of every region.
• Audit desk (auditors & super admin) — the auditor's home page: regions waiting for approval, a readiness board (% explained, blockers, quality flags such as Other reasons, M07 without a case reference or M01 without DSR details), move batches and floor additions to decide in one place, Draw sample for random field spot-checks (each draw recorded), and a per-region Evidence pack CSV (control block, totals, every variance and reason, moves, floor additions, reason change history, samples). Auditors see only Audit desk, Serial search, Reconciliation (read-only) and DSR custody.
• My actions — your to-do list: for each location in your regions (all regions for the super admin), how many Missing and Unexpected rows still need a reason, phones that can be fixed in bulk (WH transfers, moves), DSR cases to re-code M01, and anything waiting for an auditor. Open jumps straight to that location in Reconciliation.
• Serial search (Auditor, Super) — any serial's full history: expected where, scanned where and by whom, reasons, sign-off.
• Reconciliation — the dashboard, fix panels, reasons and sign-off.
• Manifests & settings (Super) — count window, manifest upload, depot → region map, admin access (roles and each admin's regions).
• Scanner access — see section 2.
• DSR custody — every M01 phone (with a DSR, allocation not completed) tracked month on month. Each case shows how many months it's been flagged and its status from the latest manifest:
  • Flagged in latest count — coded M01 this month; next month's manifest will confirm.
  • Still on shop list — not re-coded — M01 earlier, still on the list, no reason this month yet (its own orange tile). The regional admin needs to answer it.
  • Allocation completed, Back in shop or Re-coded — no longer with DSR (e.g. now M08 Sold) — the case closes by itself.
  For the Central Allocation Team: the purple Needs your details tile lists M01 phones where the regional admin didn't know who holds the phone — look each serial up in the allocation app and fill in DSR name + phone or SE/FSM name + ticket, row by row or via Download details to fill → Upload filled details. Your details are credited to you in the reason history (the M01 itself stays the regional admin's) and can be added even after the region is approved. Set the follow-up (Re-pushed · Chased · Escalated · Resolved, with notes) and download open cases; the line at the top shows new / open / closed cases and average months open. A case closes by itself when the latest count shows the allocation completed, the phone back in the shop, or a different reason — or when you set it Resolved. Your follow-up applies to the month it was flagged: if the phone is coded M01 again in a later count, the case reopens as Open with a “Flagged again” tag and your last follow-up shown underneath (it stays in the CSV and log). The Allocations role sees only this tab; regional admins see their regions' cases read-only.
• Danger zone (Super) — data clean-up tools.

IMEI → model check (super admin)

Manifests & settings → IMEI → model check. The app learns which model each IMEI prefix (TAC) belongs to from MkNet — the September 2026 export plus every manifest you upload — and rebuilds automatically after each upload. A TAC is trusted with 20+ phones and 99%+ on one model; rarer ones only warn. Modes: Warn (pre-count testing) and Block (count days — switch it on before the window opens). From the same page: download saved scans with the wrong model, the scans the check stopped, and scans saved with an unknown IMEI prefix (with whether they're on any manifest), add a one-serial exception for a phone you've checked by hand, or pin a TAC to a model (e.g. a new model not yet in MkNet). Every change is logged. Manifest uploads also list rows whose MkNet model contradicts the IMEI, to send for correction. The master export has two new columns: imei_model_family and model_check.

4. Reconciliation numbers explained

The page is split into six numbered sections — 1 Sign-off · 2 Summary · 3 Breakdown · 4 Condition · 5 Fix variances · 6 Serial detail & reasons — with a jump bar at the top.

Pick a Count month and Manifest type (Shop or Warehouse), then Load reconciliation. Regional admins land on their own region; click any region row to view another.

5. Explaining variances — reason codes

Every reason comes from one fixed list, so everyone records the same thing the same way. Some codes need one extra detail; the note is always optional (except for Other).

Missing — on the list, not found here

Unexpected — scanned, on no list here

Three ways to log reasons

• One row: click the Reason cell → pick the code, fill the detail, Save (Enter saves, Esc cancels).
• All shown: use the bar above the table — it applies to every row in the current tab and filter. "Only rows without a reason" is ticked by default so nobody's specific reason gets overwritten.
• By file: Download template (your editable rows, existing reasons filled in) → fill reason_code, detail, note → save as CSV → Import. Don't edit the serial or location columns. Unchanged rows are skipped; rejected rows are listed with their row number and why.

6. Fixing variances

Three panels in Reconciliation fix whole groups at once — use them before logging reasons row by row.

Found at a shop, still on the WH list

The WH dispatched the phones but never transferred them on MkNet (e.g. phones at Ile-Ife 2 still listed under the main warehouse).

• The shop's regional admin clicks Count at shop, send to WH.
• The phones count as stock at the shop (U05); the WH's Missing rows close automatically (M03).
• Download Transfers to post gives the WH team the list to post on MkNet. When next month's manifest is uploaded, the panel shows how many were posted and how many are still on the WH list.

Scans saved under the wrong location

A controller forgot to switch location between safes (Ajah 1 → Ajah 2) or picked a location they don't serve.

• The panel groups them by session: "6 of Bola's 11 scans at Ajah 1 on 30 Sep are on Ajah 2's list".
• Pick a reason — L01 shared shop, location not switched before the next safe · L02 wrong location selected · L99 other (note) — and click Propose move.
• An auditor approves the whole batch once (you can't approve your own). The scans are moved, not deleted — the location they were scanned under is kept. The super admin can revert.

Floor additions — real phones on no list

• Coding an Unexpected phone U02, U03 or U04 sends it to the Floor additions panel as a request (badge: Floor addition: pending).
• An auditor accepts or rejects (reject needs a note). Accepted phones count as inventory at that location.
• Accepting a U02 also closes the wrong serial's Missing row (M04).
• Once decided, the phone's reason code is locked; the super admin can reopen it.
• Don't know the wrong serial? Leave the U02 detail blank, and code the wrong serials' Missing rows M04 (bulk apply works). The Vendor serial balance in the panel compares, per location and model, correct serials added (U02) with wrong serials removed (M04) — equal numbers mean it's fully explained without knowing the pairs.
• Download MkNet serial corrections — ADD rows (accepted floor additions) and REMOVE rows (Missing coded M04), so MkNet gets fixed and the phones don't show up again next month.

7. Signing off

Sign-off runs region by region.

1. Submit for audit — the region's own admin (as preparer) from My actions → Region sign-off once the region is Ready to submit, or the super admin at any time from Reconciliation.
2. Approve or Return (Auditor or Super) — from the Audit desk, or the sign-off panel in Reconciliation. Approving freezes a snapshot of the region's numbers.

Approval is blocked while the region has:

• a location move waiting for a decision, or
• a floor addition waiting for a decision.

Rows without a reason give a warning that the approver can knowingly override.

Statuses: reconciling → submitted → approved, or returned.

8. Exports

• Master record — every manifest line and every scan, once each, with its final status and a counts_as_inventory Y/N column. Statuses:
  • matched, matched_location_corrected (moved; scanned_under shows the original location), at_shop_transfer_pending, floor_addition — count as inventory
  • missing, missing_dispatched_to_shop, misplaced, unexpected, floor_addition_pending, floor_addition_rejected, duplicate — don't count
• Audit export — every variance with its reason code, detail, who logged it and the region's sign-off.
• Transfers to post — for the WH team (section 6).
• MkNet serial corrections — ADD rows (accepted floor additions) and REMOVE rows (Missing coded M04), for whoever maintains MkNet (section 6).
• DSR custody — open cases or all cases, with DSR / SE-FSM details, months flagged and follow-up status, for the Central Allocation Team.
• Evidence pack (Audit desk) — one file per region and month: control block (who submitted / approved and when), totals, quality flags, every variance and its reason, moves, floor additions, reason change history and samples drawn.
• Spot-check sample (Audit desk) — the randomly drawn variances, with blank columns to record the field check.

Tip: the reasons template, Transfers to post and MkNet corrections files protect serials from Excel turning them into "3.5E+14". For the other exports, widen the serial column or format it as a number with no decimals before saving — never re-import a file where the serials look like 3.5E+14.

9. DSR stock (sales)

DSRs count in the sales app. Their counts reach this app automatically and are compared with each DSR's allocated phones. Matching is per DSR, not per depot.

Who does what

• DSRs only scan, in the sales app. They do not use this app.
• SE / FSM explain the variances of their depot (and any depot they cover) on the My depot page, on a phone. Pick rows, pick a reason, apply — or apply one reason to every open row.
• SFSM / DRM see their region, explain only depots with no SE/FSM or cover, and submit the region once it is ready.
• RM, SSOM, HOS see their regions (SSOM/HOS: all) on the DSR audit desk, view only.
• RSTL review audit flags and approve or return their region. They never give reasons.

Reasons for DSR stock

Missing: M07, M08, M13 (returned to depot), M14 (DSR did not take part), M15 (DSR exited), M99. Unexpected: U01, U03, U99. M16, U06 and U07 are set by the system.

Custody swaps

When a phone allocated to DSR A is counted by DSR B, the system pairs the two rows and gives them M16 and U07 (U06 if the phone is still on a shop's list). Either side's SE/FSM can confirm the pairing or dispute it with a note. A dispute withdraws the system reasons, so both rows need a reason from a manager, and the audit desk sees the dispute. A phone counted by both its owner and another DSR is not paired — it becomes an audit flag.

Audit flags (RSTL)

• Phone counted by more than one DSR
• DSR counted far more than allocated (3 or more phones and over 20% of the allocation, or 3 or more with no allocation)
• Count received late (stored, not counted until a super admin accepts it)
• Active DSR with an allocation and no count
• Custody swap disputed

Clear each flag with a review note of at least 5 characters. A region cannot be approved while flags are open. Exports on the audit desk: Master export (every phone with status and reason), Flags export and Evidence pack (sign-off trail, flags with review notes, all stock).