Current version · API wiring

It is a replenishment workbench, not yet a complete inventory system.

The Streamlit dashboard already turns MYOB item, stock, and sales feeds into one reviewable reorder list. The remaining hard problem is supplier-side truth: what was accepted, shipped, delayed, or backordered.

API path verified 3 API routes used Supplier inbound still manual 51 dashboard tests passing

What happens today

From raw feeds to a decision

The API feed uses the same compiler as the upload workflow. That lets the prototype gain automation without throwing away the data-cleaning and review logic already built for Tim.

API or uploadsItems, stock, sales, supplier files

→

NormalizeTranslate messy fields into one shape

→

Merge by SKUOne decision row per product

→

RecommendDemand, coverage, flags

→

Review + exportTim edits final quantity

Current behavior

The six useful pieces

01 / SOURCE

Choose the feed

With the API configured, the app fetches data-center feeds. An uploaded file overrides the API for that slot. Without the API, uploads still work.

02 / NORMALIZE

Clean the shape

Adapters turn MYOB JSON into the CSV-like payloads the existing dashboard compiler already understands.

03 / COMBINE

Build one SKU row

Item master, stock, sales, supplier pipeline, settings, and diagnostics are combined into one product decision row.

04 / CALCULATE

Estimate the gap

Demand is converted into a target stock level. Incoming stock is counted once even when MYOB, supplier, and tracker views overlap.

05 / REVIEW

Keep a human in the loop

Tim can filter, inspect warnings, change the final quantity, and decide which lines should actually be ordered.

06 / EXPORT

Make the next action

The selected lines become a supplier-ready CSV and can optionally be saved to the local order tracker.

API map

What the data center tells us

The API is valuable now, but “the API is working” does not mean every MYOB field is already part of the ordering model.

Source	Today	Kept by the dashboard	Still missing from the model
`/v1/items`	Used	SKU, name, description, CAI, supplier, reorder quantity, minimum level, active state	Most of the 24 MYOB columns, including costs, selling prices, accounts, and richer metadata
`/v1/raw/stock-on-hand`	Used	On hand, on order, committed, available	Average cost, value, record IDs, flags, and drilldown metadata
`/v1/raw/item-sales`	Used + cached	SKU, date, units, CAI when present	Amount, customer, invoice identity, prices, tax, margin, promised dates, and notes
`/v1/raw/item-register`	Not used	Nothing yet	Longer movement history: purchases, sales, and inventory adjustments
`/v1/status`	Not used	Nothing yet	Upstream build times, row counts, job freshness, and source health
Supplier / DDT workbook	Upload only	GIT, waiting, backorder, total ordered, reserved	No automatic supplier refresh or confirmed lifecycle

Decision logic

Why a product is suggested for reorder

The calculation is not a black box, but it is an estimate. Its quality depends on the freshness and meaning of stock, sales, lead-time, and inbound inputs.

available = on_hand + on_order - committed

coverage = on_hand - committed + incoming_stock

monthly_demand = selected_period_sales / selected_period_months
weekly_demand = monthly_demand / 4.345

target_units = weekly_demand × (lead_time_weeks + safety_stock_weeks)
raw_recommendation = max(ceil(target_units - coverage), 0)
recommended_quantity = max(raw_recommendation, MYOB_reorder_quantity)

The system suggests; Tim decides.

The final quantity remains editable. Negative available stock, order mismatches, suspicious demand, oversized suggestions, and non-master SKUs are flagged for review.

Boundary

What is automated versus still manual

API-backed now

Item master and active catalogue
On hand, MYOB on order, committed, available
Item-level sales history, with a local cache
One normalized SKU decision table
Reorder recommendation, warnings, review, export

Still separate

Supplier acknowledgement and confirmed quantity
Goods in transit, waiting to ship, backorders, ETAs
Order lifecycle until MYOB or a supplier feed catches up
Freshness metadata from the upstream jobs
Full transaction economics and customer context

Next move

Wire the truth before expanding the product

Source inspector

Show whether each feed is live, cached, uploaded, or fixture data; its fetch time; upstream build time; row count; date range; and missing fields.

Map item-register

Test whether the unused route provides the historical movements needed for better demand, adjustments, and purchasing visibility.

Validate ten decisions

For ten real reorder lines, record what Tim knew, what the app knew, what it suggested, what changed, and why.

Recommendation: keep Streamlit for this pilot. The important boundary is already outside the UI: client → adapters → compiler → order logic. Add observability and improve mappings before considering a frontend rewrite.