Business Central asks planners to fill in Safety Stock Quantity, Reorder Point, Reorder Quantity and Maximum Inventory on the Item or SKU card, and the planning engine uses these numbers faithfully. But nothing in the product calculates them. The planner is expected to know them.

After many implementations I keep seeing the same three outcomes. Either the fields stay empty, so Fixed Reorder Qty. and Maximum Qty. policies are never used and everything falls back to Lot-for-Lot. Or the fields are filled once at go-live from a consultant's spreadsheet and never touched again, so after a year they describe a business that no longer exists. Or the customer pays for an add-on that does what the product could do itself.

The calculations are not exotic. They are standard APICS textbook material that has been settled for decades:

- Safety Stock: Z-score for the target service level, multiplied by the standard deviation of demand over the lead time

- Reorder Point: average daily demand multiplied by lead time, plus safety stock

- EOQ (Wilson formula): square root of (2 x annual demand x ordering cost / holding cost)

Every input already exists in the database. Demand history is in the Item Ledger Entries. Lead time is on the item card and can also be measured from posted purchase receipts. Unit cost is on the item. The only two values the customer must provide are ordering cost and holding rate, and both are company-level constants.

My suggestion is a calculation routine, run on demand or on a schedule via the Job Queue, that:

- analyses a configurable window of demand history (for example the trailing 365 days)

- derives safety stock from a target service level, reorder point from measured demand and lead time, and EOQ from the Wilson formula

- skips items with too little history instead of producing an unreliable number (this matters - planners stop trusting the feature after the first bad suggestion)

- respects the existing order modifiers (Minimum and Maximum Order Quantity, Order Multiple) and caps extreme results

- writes the results into the existing planning fields, and logs the inputs of every calculation so a planner can see WHY a number was proposed

- works at item and SKU level

Importantly, this does not require re-architecting anything. The planning engine already exposes the right extension points: codeunit 99000855 "Planning-Get Parameters" publishes OnAtSKUOnAfterCopyFromItem, which passes the Stockkeeping Unit buffer the planning run actually consumes, and codeunit 99000854 "Inventory Profile Offsetting" publishes OnAfterTransferPlanningParameters. I have implemented the complete feature as a free open-source extension using exactly these events, including a mode where the calculated values are supplied to the planning engine at planning time:

https://github.com/GmsoftLtd/bc-inventory-planning

I am sharing it as proof that the feature is well-bounded and achievable inside the current architecture, and I would gladly see Microsoft make it a standard part of the product. Every partner in this market keeps rebuilding the same three formulas, each slightly differently. Customers who never find a partner app simply get no usable reorder point planning at all, in an ERP that is otherwise excellent at executing it.

Comparable mid-market ERP systems calculate these parameters natively. Business Central has all the data, all the extension points, and fifty years of settled theory to lean on. It should have the calculation too.