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

See also

• Compare with examples/order_point_inventory to see how periodic review generally increases the risk of stockouts and alters the on-hand inventory distribution.
• Schriber-GPSS/H Example 12.