The Wait Is Not a Number of Days
Every reorder calculation ever written assumes that if you order today, it arrives some fixed number of days from today. On an island resupplied by scheduled sailings that is not how waiting works, and the difference is not a rounding error — it is a whole interval.
Lead time is stored as a number of days, in every inventory system anybody has ever used, and that choice encodes an assumption so ordinary that it is almost invisible: that ordering is something you can do at any moment, and that the wait which follows is the same length whenever you start it. Order on a Monday, wait fourteen days, receive. Order on the Thursday instead, wait fourteen days, receive three days later. The wait is a property of the goods.
For an island economy that is simply not true, and the way it fails is specific rather than approximate. Resupply arrives on scheduled sailings. The wait is not a property of the goods; it is a property of when you asked relative to the schedule. Order the day before a cut-off and your wait is the transit. Order the day after and your wait is the transit plus the entire interval until the next one.
The same order, placed forty-eight hours apart, can land weeks apart. No number of days describes that, because it is not one number — it oscillates between a best case and a worst case, and which one you get is decided by the calendar rather than by anything about the item.
What the reorder engine actually computes
It is worth being concrete about the arithmetic, because it is good arithmetic and its assumption is the entire subject of this post. The engine itself is described in general terms in how demand forecasting works; what follows is the part of it that a schedule breaks.
The forecast works out how fast an item is moving, then sets a threshold at velocity multiplied by lead time, plus safety stock — the amount you need on hand to survive the wait. If stock falls below that threshold, it proposes an order quantity that closes the gap and adds roughly a month of further demand on top. Risk banding follows the same logic: an item is Critical when the days of cover left have fallen to the lead time, High when there is about a week more than that, Medium when it is merely below the threshold.
That is a textbook continuous-replenishment model and it is correct. It is also, in every line, built on the assumption that the wait starts when you decide it starts.
Where the assumption bites
Three consequences follow, and they get worse in order.
The threshold is set against the optimistic wait. Whatever single figure sits in the lead time field, the engine treats it as the wait you will actually get. If that figure is the transit time, the threshold protects you against the good case and leaves you exposed for the interval you did not count.
The risk bands inherit the same optimism. An item goes Critical when its days of cover fall to the lead time. If the true wait can be a whole interval longer than that figure, the warning arrives after the last order that could have prevented the stock-out has already been missed. The band is not wrong; it is measuring against a wait that was not available.
The proposed quantity is horizon-blind. The order quantity closes the gap and adds a fixed thirty days of demand. Where replenishment comes round faster than that, it over-orders slightly and no harm is done. Where it comes round more slowly, thirty days of cover will not reach the next opportunity — and the shortfall will not announce itself until the shelf is empty and the next sailing is still some way off.
A stock-out on an island is rarely a forecasting failure. It is almost always a calendar you were not allowed to tell the system about.
The asymmetry that decides what to do
The standard instinct when a lead time is variable is to use the average. That instinct is right when being early and being late cost roughly the same, and it is wrong here, because on a discrete schedule the two errors are not remotely symmetric.
Ordering earlier than you needed to
- You hold stock for longer than necessary.
- Cost is working capital and storage, and it is proportional — a bit early costs a bit.
- It is visible the whole time, on every stock report.
- Recoverable at any point by simply ordering later next time.
Ordering later than you could have
- You miss the sailing.
- Cost is an entire interval of stock-out, and it is a step change — a day late costs the same as a fortnight late.
- Invisible until it is unrecoverable, because nothing counted down to the cut-off.
- Air freight, if it exists for that item, at a price that usually exceeds the whole holding cost you were avoiding.
Once the costs are laid out like that, the configuration follows from it rather than being a judgement call.
Configuring for a schedule the system cannot see
-
Set lead time to the worst case, not the average
The field takes one number and the engine trusts it completely, so the number should be transit plus a full replenishment interval — the wait you get when you just miss. This deliberately over-protects most of the time, and given the asymmetry above, over-protecting most of the time is the correct answer rather than a compromise.
-
Use safety stock for variability, not for the interval
Once lead time carries the worst-case wait, safety stock goes back to doing its actual job: absorbing demand variation and the occasional disrupted sailing. Loading the interval into safety stock instead works arithmetically and hides the reason from whoever inherits the settings.
-
Review before the cut-off, not when the report fires
This is the one that matters most and it lives entirely outside the software. The reorder report tells you what is below threshold today; it has no idea that today is the last day to act. A standing review in the days before each cut-off turns a continuous signal into a decision made at the only moment it can be acted on.
-
Order to the next opportunity, not to thirty days
The proposed quantity adds a fixed month of demand. Treat it as a floor and extend to cover the gap to the sailing after next, so that a single missed opportunity is an inconvenience rather than a stock-out.
-
Keep lead times per item honest when routes differ
Lead time is stored per item and there is no per-supplier or per-route figure. Where an item is sourced two ways with genuinely different schedules, the single field will describe one of them. Decide which, and record the other decision somewhere a human will read — the field cannot hold it.
What the engine is genuinely good at
It would be a poor reading of all this to conclude that the forecasting is not worth using here. The velocity calculation, the days-of-cover figure and the risk ranking are all doing real work, and they are doing it on your actual movement history rather than on a guess. On an island, where the cost of being wrong is higher than almost anywhere, knowing which items are closest to the edge is worth more, not less.
The single input that has to carry the schedule is the lead time. Set it to describe the wait you might actually get, and every figure downstream — threshold, risk band, proposed quantity — becomes usable. Set it to the transit time because that is what "lead time" sounds like it means, and every one of them is confidently early.
What AWRA OpsHub does today
- A demand forecast built from your own movement history, producing velocity, days of cover and an expected stock-out date per item.
- A reorder threshold of velocity × lead time plus safety stock, with a proposed order quantity when stock falls below it.
- Risk banding — Critical, High, Medium — ranked so the most exposed items surface first.
- Lead time and safety stock per item, with tenant-level defaults where an item does not specify its own.
- A plain low-stock report against a fixed reorder point, for items where a simple threshold is the right tool.
- A full purchase order workflow from requisition through quotation to order, so the decision, once made, has somewhere to go.
What it does not do
- No replenishment calendar of any kind. No order cut-off, no sailing or arrival schedule, no ordering window. The system cannot know that today is the last day to act.
- Lead time is a single scalar in days, so a wait that oscillates between a best and worst case has to be represented by one of them.
- No per-supplier, per-route or per-site lead time. One item has one figure however many ways it is sourced.
- The proposed order quantity uses a fixed thirty-day forward horizon, not one derived from your replenishment interval.
- No order consolidation. Nothing groups requirements into a shipment, and there is no minimum order value or container fill logic.
- No freight, landed cost or duty modelling on the ordering decision — the trade-off between sea and air is not one the system can weigh for you.
What is not built for Mauritius today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in Mauritius. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a certified EBS fiscalisation connection, a Mauritian payroll engine, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
Real-time fiscalisation, through certification we do not hold
Invoice fiscalisation against the Revenue Authority in real time — structured invoices, a validation response held on the transaction, retries, a failure queue and a daily report of invoices carrying no reference. Stated precisely, because precision is the whole value of saying it here: this requires becoming a certified Electronic Billing System, which is an accreditation rather than an integration. We are not certified and hold no connection today. If you are in scope, choose your EBS first and fit everything else around it.
Banks, cards and genuinely multi-currency settlement
Bank statement feeds and card acquirer settlement into the Payments Register, across the several currencies a Mauritian entity actually operates in rather than one reporting currency with conversions bolted on. There is no exchange control to work around here, which makes this the ordinary version of a problem that is difficult almost everywhere else on the continent.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
PAYE, National Pensions Fund and National Savings Fund contributions and the associated returns, computed on live records and produced in the layout each body expects. Not built today — our maintained engine covers Kenya only, and the local providers here are good.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedThe compliance and structural side of operating from these islands is a genuinely different subject, and it is covered separately in substance is a records problem. This post is about the other half — the half where the island is not a jurisdiction but a place that things have to be shipped to, on somebody else's timetable.
Frequently asked questions
What should we put in the lead time field if our supply arrives on scheduled sailings?
The worst case: transit time plus a full replenishment interval — the wait you get when you just miss a cut-off. The engine treats that figure as the wait you will actually get, and on a discrete schedule the cost of ordering slightly early is proportional while the cost of missing an opportunity is a step change. Over-protecting most of the time is the correct answer here, not a compromise.
Can the system know about our shipping schedule or order cut-offs?
No. There is no replenishment calendar anywhere in the product — no cut-off dates, no arrival schedule, no ordering window. Every calculation assumes an order placed today arrives a fixed number of days from today. The calendar has to live in your review routine, timed to the cut-off rather than to when the reorder report happens to fire.
Why does an item go Critical only when it is nearly out?
Because the risk bands are measured against the lead time figure: Critical is when days of cover have fallen to the lead time, High is roughly a week above that. If the lead time recorded is the transit time rather than the worst-case wait, the warning is measuring against a wait that may not be available — which is why the lead time figure is the one input that has to carry the schedule.
Can we set a different lead time for our sea supplier and our air supplier?
Not in the standard field. Lead time is stored per item, not per supplier or per route, so an item sourced two ways carries one figure between them. Choose which route the number describes — usually the one you actually rely on — and record the alternative where a person will read it.
Does the proposed order quantity account for how long until we can order again?
No. It closes the gap to the threshold and adds a fixed thirty days of forward demand, regardless of your replenishment interval. Where resupply comes round more slowly than that, treat the proposal as a floor and extend it to cover the gap to the opportunity after next.
