### The gap
Business Central's reordering policies consume Safety Stock Quantity, Reorder Point,
Reorder Quantity and Maximum Inventory as static numbers typed onto the Item or SKU card.
The planning engine executes them faithfully. Nothing in the product calculates them.
In practice that leaves three outcomes:
1. The fields stay blank, so Fixed Reorder Qty. and Maximum Qty. are unusable in practice
and implementations default to Lot-for-Lot.
2. They are filled once at go-live from a spreadsheet and never revisited, so within a
quarter they no longer describe the business.
3. The customer buys or commissions an add-on.
The formulas are settled APICS material, not a judgement call about how a business
should operate:
Safety stock = Z x sigma(demand during lead time), from a target service level
Reorder point = (average daily demand x lead time) + safety stock
EOQ = sqrt((2 x annual demand x ordering cost) / holding cost) [Wilson]
Every input already exists in Business Central. Demand history is in Item Ledger
Entries. Lead time is on the item and in receipt history. Unit cost is on the item.
Ordering cost and holding rate are the only two values a customer supplies, and both
are company constants.
### The extension points already exist — I built the proof
This is not a request to re-architect planning. Codeunit 99000855 "Planning-Get
Parameters" already publishes integration events at exactly the right point
(OnAtSKUOnAfterCopyFromItem passes the Stockkeeping Unit buffer the planning run
consumes), and codeunit 99000854 "Inventory Profile Offsetting" publishes
OnAfterTransferPlanningParameters and two hundred more.
I have published a free, open-source app that implements the whole feature on top of
those events:
https://github.com/GmsoftLtd/bc-inventory-planning
It calculates all three parameters plus a recommended reordering policy
(Syntetos-Boylan ADI/CV-squared classification) from Item Ledger Entry history, with a
statistical-significance guard, order-modifier respect, result caps, a calculation
audit log, a current-vs-proposed worksheet, Job Queue scheduling — and an opt-in mode
that supplies the values to the planning engine at planning time through the events
above, so the engine consumes numbers computed from live history instead of a stale
batch write.
Microsoft built the extension point. What is missing is a first-party calculation
behind it, so customers who have not found a partner app still get usable planning
parameters.
### Supporting material
- Consolidated app: https://github.com/GmsoftLtd/bc-inventory-planning
- Original standalone calculators (methodology proven separately):
https://github.com/GmsoftLtd/Lexon-SafetyStockCalculator
https://github.com/GmsoftLtd/bc-reorder-point
https://github.com/GmsoftLtd/bc-eoq-calculator
- Methodology write-ups:
https://insidebusinesscentral.com/safety-stock-business-central-calculator/
https://insidebusinesscentral.com/reorder-point-in-business-central-calculator/
https://insidebusinesscentral.com/eoq-in-business-central-calculator/
https://insidebusinesscentral.com/choosing-a-reordering-policy-in-business-central/
The point is not that the calculation is difficult. It is that every partner rebuilds
the same three formulas, inconsistently, because the product stops one step short of
usable — while the extension point to close the gap already ships in the base
application.
### Why it belongs in the product
- It makes two existing reordering policies practical rather than theoretical.
- It closes a gap against comparable mid-market ERPs where this is standard.
- The inputs are already in the database. No new data capture, no new integration.
- It is bounded, well-specified work with fifty years of settled theory behind it —
and a working reference implementation exists under MIT license.