Demand Planning & Auto-Replenishment

The problem this solves

NetSuite ships reorder point and preferred stock level fields on the item record, and it can calculate them for you. What it does not do well is reflect the way your demand actually behaves. A single blended lead time per item ignores the fact that one supplier ships in nine days and another in six weeks. A flat reorder point ignores the fact that half your SKUs triple in the run-up to a seasonal peak and go quiet afterwards. Service-level targets are usually a number in a spreadsheet, not a parameter anything in the system respects.

The result is the familiar pair of failures happening at the same time: stockouts on the items that matter, and cash tied up in slow-moving inventory that a planner over-ordered because the last stockout was painful. Planners end up maintaining a parallel spreadsheet model, exporting saved search results every Monday, and typing the answers back into NetSuite by hand. The model is invisible to everyone else, it breaks when the planner is on leave, and nothing in the audit trail explains why a purchase order was for 480 units instead of 200.

What ECOSIRE builds

We build a demand planning and replenishment layer inside your NetSuite account, using SuiteScript 2.1, custom records and SuiteFlow. It reads your own transaction history, computes item-location replenishment parameters on a schedule, and either proposes or generates the resulting purchase and transfer orders — with every input and assumption stored on a record you can open, search and report on.

Demand history and forecasting

A Map/Reduce script builds a demand history series per item and location from your posted sales orders, invoices, cash sales and inventory transfers, bucketed weekly or monthly to your preference. The forecast engine supports moving average, weighted moving average and exponential smoothing with a seasonality index derived from your own multi-period history, so a product that peaks in Q4 gets a reorder point that rises ahead of the peak and relaxes after it. Forecast method, alpha, horizon and seasonality treatment are all configurable per item class, item group or individual item — not hard-coded.

Forecast accuracy is tracked. Each cycle writes the prior forecast against actual demand, so you can run a saved search on mean absolute percentage error by item and see which parts of the catalogue the model handles well and which need a different method or manual override.

Statistical safety stock and reorder points

Safety stock is calculated from demand variability and lead-time variability against a service-level target you set, rather than a fixed number of days of cover. Service level is configurable by item, by item class, or by an ABC/XYZ classification the solution assigns automatically from revenue contribution and demand volatility. Reorder point, safety stock and suggested order quantity are written back to the item-location fields NetSuite already uses, so standard NetSuite screens, saved searches and the Inventory Status views stay consistent — and simultaneously stored on a custom planning record that preserves the calculation inputs.

Order quantity respects the constraints buyers actually work with: supplier minimum order quantity, order multiple, case pack, shelf life for lot-tracked items, and a maximum stock ceiling so a long-lead-time item cannot generate a twelve-month buy.

Supplier lead-time modelling

Rather than trusting the lead time typed on the item vendor sublist, a scheduled script measures realised lead time from your own purchase order and item receipt history per vendor and item, computing the mean and the standard deviation. Both feed the safety stock calculation. Where a vendor's realised performance diverges materially from the contracted lead time, the record flags it, giving procurement an evidence-based conversation instead of an anecdote.

Replenishment run and order generation

A scheduled replenishment run evaluates every in-scope item-location combination against on-hand, committed, on-order and in-transit quantities, then produces replenishment suggestions on a custom record. From a Suitelet workbench, planners review suggestions in a filterable list, adjust quantities, exclude lines, and approve. Approved lines are grouped by vendor and location and turned into purchase orders — or into inter-company or intra-company transfer orders where the recommendation is to move stock rather than buy it. In OneWorld accounts, subsidiary, location and currency are respected throughout, and transfer suggestions can be restricted to permitted subsidiary pairs.

Everything is driven by role and permission: who may run the engine, who may approve suggestions above a value threshold, and who may only look. SuiteFlow handles the approval routing and the email notifications.

Exceptions and visibility

The solution writes exception records for the situations planners need to see rather than discover: projected stockout inside the lead-time window, excess stock above the maximum, an item with no demand history that cannot be forecast, a vendor whose lead time has drifted, and a suggestion blocked by a missing item vendor record. Saved searches and dashboard portlets surface these on the planner's home page.

Who this is for

Distributors and manufacturers running NetSuite with more SKUs than a planner can reasonably reason about by hand — typically several hundred upwards — where demand is seasonal or lumpy, lead times vary materially by supplier, and inventory is a large enough number on the balance sheet that a few points of carrying cost matter. It suits OneWorld accounts with multiple stocking locations and subsidiaries particularly well, because that is where the transfer-versus-buy decision is hardest to make manually.

It is not the right fit if you carry a handful of items with steady demand and a single reliable supplier. NetSuite's native reorder point handles that case perfectly well.

How delivery works

This is built to order. Nothing is downloaded and switched on.

1. Scoping call. We walk through your item and location structure, how demand behaves, which historical transaction types represent true demand for you, your subsidiary layout, and how you want approvals to work. We look at the account itself where you can give us sandbox access.

2. Fixed quote and specification. You receive a written functional specification listing every script, custom record, field, saved search and workflow we will deliver, plus a fixed price and a delivery date. Nothing starts until you approve it.

3. Build. We develop as an SDF project against your sandbox, using your real item master and transaction history so the forecast logic is tuned on your data rather than on samples.

4. Install in your sandbox. We deploy to your sandbox account as an unmanaged bundle or SDF deployment, run a parallel period against your current planning process, and walk your planners through the results side by side so you can see where the model agrees with them and where it does not.

5. Production deployment. Once you sign off in sandbox, we deploy to production, configure the schedules, set role permissions and hand over the source. The customisation is yours — you own the SDF project and can maintain or extend it with or without us.

6. Support window. A defect-fix support window follows go-live, with the length agreed in the quote. Beyond that we offer ongoing support and enhancement on a separate arrangement.

Typical lead time from approved quote to production is two to four weeks, depending on how many locations, subsidiaries and exception rules are in scope.