Physical stock count and shrinkage tracker for Clover

Build me an app my retail staff open to run physical stock counts against my Clover inventory and see exactly where we are losing product. Clover has no structured physical count, no discrepancy reporting, and no record of who changed a quantity or why, so this app is both the counting surface and the audit trail.

The main view is a count sheet. At the top I pick a category, loaded with Clover's List Categories. Picking one loads every item in that category using List Inventory Items, and pulls each item's current tracked quantity using List All Item Stock. Render one row per item showing the item name, its price, and the current system quantity, plus a blank input where whoever is counting types the quantity actually on the shelf. Handle categories with more items than one page returns, and if an item has no tracked stock in Clover, show it in the row as untracked, exclude it from the shrinkage math, and never write to it.

As counts get typed in, each row shows its variance live: counted quantity minus system quantity in units, and the same number multiplied by the item price in dollars. Clover returns monetary amounts as integers in cents, so divide by 100 for every dollar figure shown or logged. A negative variance means product is missing. Above the sheet, keep a running session total showing counted rows out of total rows, net variance in units, and total shrinkage in dollars, so I can see a $340 hole before I finish counting.

Let me set a variance threshold for the session, expressed either as units or as dollars. Any row whose variance exceeds it gets visibly flagged as needing a recount, and the header shows how many flagged rows are outstanding. I should be able to clear a flag by recounting the row and confirming the number, and I want a warning if I try to commit while flagged rows are unresolved, though I can override it.

Counts must be resumable. Persist the in-progress count session, including every entered quantity, the chosen category, the threshold, the counter's name, and any reason notes, so a staff member can stop mid-aisle and come back later, or hand off to someone else, with nothing lost. Show any open sessions when the app opens so they can be picked back up. Support counting one category at a time rather than forcing the whole store in one sitting.

Never write anything back to Clover until I explicitly commit. Commit is a separate, deliberate action with a confirmation summarizing how many items will change and the total dollar impact. On commit, for every row where the counted quantity differs from the system quantity, call Update Item Stock to set the corrected quantity, re-reading with Get Item Stock first so a stale system quantity is caught if the item moved since the sheet was loaded. Then append one row per adjustment to a Google Sheets audit log using Append Values, with the timestamp, category, item name, item id, old quantity, new quantity, variance in units, variance in dollars, the counter's name, and an optional reason note. Reason is picked from breakage, theft, miscount, supplier short-ship, expired, or other, with a free-text field. If the log sheet is empty, write the header row first with Update Values. Show a clear per-row result after commit so a partial failure is visible and retryable rather than silent.

A second view is count history. It reads the audit log back out of the same Google Sheet with Get Values and turns it into something I can actually study: adjustments grouped by item so I can see which products keep coming up short month over month, total dollars lost by category, and a breakdown by staff member showing who ran each count and what it turned up. Let me filter by date range, category, staff member, and reason. Surface repeat offenders, meaning items that have come up short across multiple separate counts, since those are where real shrinkage hides.

Keep the interface fast to use on a phone or tablet while standing at a shelf, with large input targets and easy movement from one row to the next. The counter's name should be captured once at the start of a session and carried onto every logged row.