Yummy Stock Waste

01Context

In a cloud kitchen, stock leaves the shelf without being sold for many reasons. Each one has to land in a different place in the ERP:

Some brands are brand partners (BP): their expired stock goes back to the partner or to Hub Kemang, the central hub, and doesn't simply get thrown away.

02The problem

Before:

• Yummykitchen outlets logged waste in Airtable
• Other outlets had an ops admin enter waste directly in Odoo Outlet

That caused:

• Two sources of truth, re-typed by hand
• No proof: no photo, so no way to check or dispute
• No limits: a "5000" typed instead of "5" went straight into the books
• Units chosen by hand: pcs vs pack vs gram
• Returns done manually: someone had to know which brands needed a return document and make it

PRD goal: "Input waste directly into the system without touching the ERP." That meant removing Odoo Outlet, moving to Odoo Core through the middleware, and giving supervisors a portal to see the waste documents.

03Users

04How the system works

05Key design decisions

D1. Category first, because the category decides the form

Crews pick what kind of waste before anything else, because the category changes which fields appear:

• Expired: product, expiry date, quantity, photo
• Spoiled / leftover prep / central-kitchen waste: product, quantity, photo. The expiry date is hidden.

Hiding expiry dates where they mean nothing removed a field that crews had been filling with made-up dates.

D2. Product search scoped to the category

Supervisors choose which products can be wasted in each category (including recipe items for leftover prep). In the app, search only returns those products. Crews can't, for example, record a sealed packaging item as "leftover prep".

D3. Limits set per unit, not per product

Supervisors set a maximum quantity per smallest unit (gr, pcs, ml…). If a crew member goes over it:

• A warning appears under the field
• They can't continue, and the photo upload stays disabled

Why per unit and not per product? There are hundreds of products but only a handful of units. Supervisors maintain a short table instead of a long one that would go stale. Trade-off: it's coarse. 2,000 g is plausible for rice and absurd for saffron (see Reflection).

D4. The unit is chosen for you

The system matches each product to its reference (smallest) unit, so crews never pick a unit and quantities add up correctly.

D5. A photo is the receipt

Every line needs a photo. In the admin portal the first photo appears as a thumbnail on the row, and tapping it opens a gallery of everything the crew uploaded. The photo discourages misuse and settles disputes with brand partners over expired returns.

D6. Think like a crew member, book like an accountant

Crews think in terms of "what did I throw away". The ledger cares about "where does it go". One submission is split automatically into one document per category and destination, so crews never deal with Odoo locations.

D7. The biggest change: a return isn't a category, it's a rule

v1 gave crews two extra categories to choose from: Return to Hub Kemang and Return to BP.

What went wrong: crews had to remember each brand's return agreement. Choosing wrong sent stock to the wrong place in the books and broke the return to the partner.

v2 (Phase 3):

1. Removed both return categories from the app, the portal and the configuration
2. Added a Return Waste configuration: for each brand, Return to BP or Return to Hub Kemang, active or inactive, with import and export
3. When crews submit Expired waste for a brand that has a return rule, the system creates the return document automatically (Waste → Transit – Hub Kemang, or → Brand Partner)
4. The admin portal got two tabs: Waste Document and Return Document

The decision moved from every crew member at every outlet to a few supervisors setting it once. Crews now pick from five categories, all of which describe what happened, not what the contract says.

D8. Exports that can't bring the portal down

Clicking Export with no filter shows "Data terlalu banyak" ("too much data") with Filter / Batal (cancel), which steers people to narrow the date range or outlet first. You can also export from a single document's page.

D9. Configuration edits that are safe to back out of

• Tree checklist: checking a category selects all of its products
• Cancel with a choice: Hapus perubahan (discard changes) vs Tetap pilih produk (keep selecting), so a misclick doesn't wipe a long selection
• Delete mode behind the ⋯ menu, with checkboxes and a confirmation step, kept away from the main actions
• Import checks with plain messages: duplicates ("Data telah dimasukkan. Silahkan upload data yang baru": "this data already exists, please upload new data"), wrong template, failed upload ("Impor data gagal. Silahkan coba lagi": "import failed, please try again")

D10. Empty and error states that tell you what to do

When a filter finds nothing: "Data tidak ditemukan. Harap periksa kembali detail yang dimasukkan." ("no data found, please check the details you entered"). The same message is used in every module (see the Portal case study).

06Screens

07Rollout

08Impact

09Reflection

• The best decision was taking a choice away. Removing the return categories made the app simpler and the data more accurate.
• What I'd change:
  • Limits per unit are too blunt. I'd add per-category or per-product overrides for high-value items.
  • Offline drafts. Waste often gets recorded in the storeroom, where the signal is worst.
  • Waste reasons inside each category (dropped, wrong temperature, over-prepped) so the data explains why, not just how much.