Inventory Forecasting

Paid pluginsize Mplanned, not built

Indicative price, not an offer: €39/mo; demand forecasting, reorder-point calculation, supplier lead-time input

Generated from docs/plan/paid/inventory-forecasting/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

A paid analytics module that predicts when to reorder based on historical order patterns and supplier lead times. Calculates reorder points, suggests optimal order quantities, and alerts staff when stock is trending toward stockout. Prevents lost sales from runouts and overstock waste from over-ordering.

The problem

I run out of fast-moving items mid-week and lose sales. I over-order slow items and tie up cash. I have no systematic way to decide when to reorder or how much. Right now, I guess.

What it does

• Reorder point calculation: (average_weekly_sales × lead_time_weeks) + safety_stock_days
• Lead-time input per supplier: merchant sets days to fulfill one PO
• Safety stock setting: configurable days of extra buffer (default 7 days)
• Demand forecast: simple moving average of last 12 months of orders, per product
• Reorder quantity: economic order quantity (EOQ) or merchant-set minimum
• Reorder suggestion endpoint: GET /api/products/:id/reorder-suggestion returns next order date, qty, cost estimate
• Dashboard: list of all products trending toward reorder, sorted by urgency (days to stockout)
• Alerts: configurable threshold; notify staff if stock <= reorder_point
• Forecast report: CSV export of all products, reorder dates, lead times, for spreadsheet review
• Trend chart: per-product graph of sales velocity, projected stockout date, reorder history
• Webhook trigger on reorder alert: integrate with Slack or email for daily summary

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Machine learning or advanced time-series (ARIMA, Prophet) — uses simple moving average only; no seasonal decomposition or trend extrapolation
• Multi-level forecasting (production lead time + procurement + shipping) — single lead_time_days input only; no supply-chain simulation
• Supplier reliability scoring or demand shaping — merchants control reorder_point and lead_time; no algorithmic vendor selection
• Promotion forecasting or price elasticity — uses historical orders as-is; no demand lift modeling for upcoming sales

Data model

New tables: forecast_config (id, product_id, lead_time_days, reorder_point_qty, safety_stock_days, min_order_qty, last_updated_at), forecast_runs (id, product_id, run_date, avg_weekly_sales, projected_stockout_date, suggested_order_date, suggested_qty_minor_units, confidence_pct), demand_history (id, product_id, week_start_date, order_qty, created_at).

API

• GET /api/products/:id/forecast
• POST /api/forecast/calculate/:productId
• POST /api/forecast/calculate-all
• GET /api/reorder-suggestions
• GET /api/reorder-suggestions/:productId
• PATCH /api/products/:id/forecast-config
• GET /api/forecast/report/:reportType

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Forecast dashboard with urgency-sorted table (Days to Stockout, Suggested Order Date, Qty), trend sparkline per product, reorder-config editor per product, bulk forecast-run button, CSV export, alert threshold setting, webhook URL input.

The seam — why this is paid

Core owns the forecast interface and simple moving-average calculation. Paid owns demand-pattern detection, supplier lead-time validation, forecast accuracy monitoring, and the SLA for reorder alert delivery.

Support commitment: forecast accuracy, demand-pattern detection, supplier SLA

Dependencies

• product module (SKU)
• order history (last 12 months sales)
• inventory module (current qty)
• supplier module (lead times)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• Forecast uses order_qty from completed orders in last 12 months
• avg_weekly_sales = sum(last_52_weeks_orders) / 52, truncated to integer
• projected_stockout_date = today + (current_qty / avg_weekly_sales) weeks
• reorder_point_qty = (avg_weekly_sales × lead_time_days / 7) + (safety_stock_days × avg_weekly_sales / 7)
• suggested_order_date = projected_stockout_date - (lead_time_days)
• GET reorder-suggestions returns only products where current_qty <= reorder_point_qty
• Forecast does not calculate if order history < 8 weeks (insufficient data)
• Merchant can override safety_stock_days and lead_time_days per product

Risks

Insufficient order history (new products) returns null forecast; seasonal spike in orders inflates avg_weekly_sales year-round; lead-time change mid-month breaks accuracy; forecast runs slow on 50k+ products; alert fatigue if threshold too low (staff ignores warnings).

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.