LIVE NOW
What is implemented
A Streamlit page loads data, calculates suggested quantities, shows a replenishment table, lets Tim edit final quantities, exports an order CSV, and stores open-order notes.
13 Aug 2026
Tim’s dashboard · current state
The app is a buying workbench.
It is trying to turn stock, sales, supplier files, and ordering rules into a short list of products Tim can review and order. It is not yet a full inventory system, customer relationship manager, or automatic purchasing system.
Implemented now: replenishment recommendationsAPI + uploadsPilot: Tim reviews and gives feedbackHuman approval stays in the loop
Three things to keep separate
Live app, intended pilot, future redesign
The current page is useful but overloaded because it mixes the working tool, technical controls, and future product ideas. This is the clean distinction.
INTENDED PILOT USE
What Tim is expected to do
Open the app, check the data, review the short list, change anything that looks wrong, send the order, and tell us what was confusing or inaccurate.
NOT LIVE YET
What the redesign should do
Start with “Your next order,” hide technical detail, show only decisions that need attention, and make inbound orders part of the same simple loop.
Current function set
What the app can do today
These are the current functions, translated into the job they perform for Tim.
01 / DATA
Load the product list
Use the data-center API for the MYOB item master, or upload an item export as an override or fallback.
02 / DATA
Load current stock
Bring in on-hand, on-order, committed, and available quantities from MYOB stock data.
03 / DATA
Load sales history
Use API sales data, a local cache, or uploaded sales files to estimate how quickly each product sells.
04 / SETTINGS
Set the planning rules
Choose lead time, safety stock, and the sales period used to estimate demand.
05 / DECISION
Suggest what to buy
Compare target stock with current coverage and apply MYOB reorder quantities to produce a suggested quantity.
06 / TRUST
Flag problems
Call out negative available stock, suspicious inputs, order mismatches, and items that cannot be matched safely.
07 / ACTION
Review and edit
Filter the replenishment table, inspect a product, and change the final quantity before sending anything.
08 / FOLLOW-THROUGH
Export and track
Download a supplier-ready CSV, optionally save it as an open order, then update received quantity, ETA, status, and notes.
The current UI
What Tim sees today
The page is one long workbench. The left sidebar contains setup and data controls. The main area contains the decision table and several technical or follow-up sections below it.
Derwent Ordering DashboardStreamlit page · one long workbench
—Total SKUs
—Need reorder
—Negative available
—Total suggested qty
Review may be needed. Some rows have flags or unusual inputs.Inspect flagged SKUs
Replenishment table
SKUProductAvailableIncomingSuggestedFinal qty
ITEM-001Example product401212
ITEM-002Another product181000
ITEM-003Flagged product——Review—
This is a structural map, not a screenshot. The exact counts and rows change with Tim’s data.
Intended pilot workflow
How we expect Tim to use it now
The current pilot is not asking Tim to become a system administrator. It is asking him to test whether the proposed order is useful enough to act on.
01 / OPEN
Load the dashboard
The API should load items, stock, and sales. Uploads remain available when a source needs to be overridden.
02 / CHECK
Confirm the data
Look for source errors, missing sales, stale cache information, or an unexpected stock picture.
03 / FOCUS
Find the buy list
Use Need Reorder, the flagged inspector, and table filters to focus on products that need a decision.
04 / REVIEW
Use judgment
Check the product, available stock, incoming stock, demand, and suggested quantity. Edit Final qty when needed.
05 / SEND
Export the order
Download the supplier CSV. Save it to the tracker if it represents an order Tim has sent.
06 / REPORT
Give feedback
Tell us what was right, wrong, missing, slow, or harder than the old process. That feedback shapes the next version.
The expected behavior is not “trust the number.”
It is “use the number as a starting proposal, then tell us whether the facts and the workflow match how Derwent actually buys.”
Feedback we need
What Tim’s use should teach us
Signal
- Did the right products appear on the buy list?
- Were products missing that Tim expected to see?
- Were products included that should be ignored?
Quantity
- Did the suggested quantity make sense?
- What did Tim change?
- Was the reason a formula issue, a data issue, or business judgment?
Data and trust
- Did stock, sales, and incoming quantities look current?
- Could Tim understand why a row was flagged?
- Did the API and supplier file disagree?
Workflow
- Could Tim find the first useful action without help?
- Which controls did he ignore or misunderstand?
- Did export and tracking fit the real buying routine?
Current UI versus intended use
Why the current page feels overwhelming
| What is on the page | What it is for | What Tim should do in the pilot |
|---|---|---|
| Planning inputs in the sidebar | Control lead time, safety stock, and demand assumptions. | Accept the saved defaults unless a real Derwent policy needs changing. Do not treat every control as a required setup step. |
| API status, cache details, and uploads | Make the data source visible and provide a fallback. | Confirm that the data is usable. Upload only when the source needs an override or the API is incomplete. |
| KPI row and flagged warning | Summarize the catalogue and surface possible data problems. | Use “Need reorder” and flags as the entry point. The totals are context, not the work itself. |
| Replenishment table | Put one decision row per product in front of Tim. | Review the short list, inspect why, edit Final qty, and select lines for export. |
| Reconciliation, planner, formulas, diagnostics | Support follow-up, explanation, and troubleshooting. | Use these when a decision needs investigation. They are not supposed to be read top-to-bottom every time. |
The redesign target
What should change next
The redesign should keep the current calculation and data integration while changing the first impression and the order of attention.
Start with the decision
Open on “Your next order” or “Nothing urgent,” not on a catalogue of controls.
Use progressive disclosure
Keep settings, uploads, formulas, mapping, and technical logs available but out of the main path.
Keep the loop visible
Make review, export, sent orders, incoming stock, and reconciliation feel like one continuous task.
Bottom line: the current app is a working pilot instrument. Its job is to generate real buying decisions and learn from Tim’s corrections. The next UI should make that loop obvious without changing the underlying goal.