Periodic Review Inventory (R,S): model notes

Periodic Inventory

A periodic-review inventory model simulating an (R, S) reorder policy with lost sales.

Problem

Unlike continuous-review systems, a periodic-review system only checks inventory levels at fixed intervals of \(R\) days. Every \(R\) days, the system checks the inventory position; if it is below the target level \(S\), an order is placed to bring the position back up to \(S\). In this model, unfilled demand is not backordered but is instead "lost," representing a penalty to the organization.

This model demonstrates the "sawtooth" nature of periodic inventory and the impact of review frequency on service levels.

This is based on the periodic-review (R, S) formulation in Law-SMA and Example 12 of the Schriber-GPSS/H textbook.

Model in this directory

The model uses a time-triggered orchestration:

Reviewer puck (lines 101-130): The central controller that fires every \(R\) days. It records the current on-hand level into a histogram and determines if a replenishment order is necessary.
Demand_Gen puck (lines 64-93): Drives stochastic demand. If on-hand stock is insufficient, units are marked as "lost."
Replenishment puck (lines 134-148): Handles the lead-time delay before units are added back to the on-hand stock.
sim.Histogram (line 52): Used to capture the distribution of on-hand levels at the moment of review. This is critical because a simple mean cannot characterize the non-Gaussian distribution produced by periodic triggers.

Why this shape

The la-periodic trigger is implemented by having the Reviewer puck call eng.advance with a fixed interval of \(R\) days (line 128). This ensures that the review occurs precisely every \(R\) units of time, regardless of other system events.

The use of a histogram (via sim.histogram_record on line 108) allows the model to provide deeper insights than just the mean on-hand inventory. The distribution of levels at the moment of review reveals the "risk" of stockouts just before a review occurs, which is a primary driver for choosing \(R\) and \(S\).

Alternatives considered

Continuous Review: If the system were continuous, we would use a Notify_Var and wait_until (as seen in examples/order_point_inventory).
Backordering: This model uses lost sales rather than backorders to simplify the cost function and contrast with Example 9.

What this example teaches

Periodic Triggers: Implementing processes that fire at fixed intervals rather than responding to state changes.
Distribution Analysis: Using histograms to characterize a state variable's behavior over time.
(R, S) Policy Logics: Understanding the operational trade-offs between review frequency (\(R\)) and order-up-to levels (\(S\)).

CLI

./periodic_inventory [options]

Add --json to emit the uniform envelope (metadata, execution_stats, metrics, details) instead of the default text output.

Flag	Type	Default	Description
`--days`	float	`365`	Simulation horizon in days.
`--warmup`	float	`30`	Warmup cutoff in days; stats before this are ignored.
`--R`	int	`7`	Review period in days.
`--S`	int	`200`	Order-up-to level (S).
`--seed`	int	`42`	RNG seed.
`--json`	bool	`false`	Emit uniform JSON envelope instead of text.

Example runs:

./periodic_inventory                                   # default text run
./periodic_inventory --json                            # uniform envelope
./periodic_inventory --days=90 --R=7 --S=50 --json     # custom policy, JSON

Running it

odin run examples/periodic_inventory