Inventory Management with a Continuous Replenishment Policy Back to simulation
Classification tags: business operations management, DES, next-event time progression
Classification tags: business operations management, DES, next-event time progression
The potentially relevant object types are:
Potentially relevant types of events are:
These object and event types, with their participation associations, can be visually described in a UML class diagram, as shown below.
If a demand is greater than the current stock level, the difference counts as a lost sale. Whenever the stock level falls below a certain threshold (called reorder point)), the shop places a replenishment order with a quantity computed as the difference between an upper threshold (called target inventory) and the current stock level.
| ON (event type) | DO (event routine) | Conceptual Event Rule Diagram |
|---|---|---|
| customer order | if there is sufficient inventory, then product handover, else customer departure |  |
| product handover | customer payment |  |
| customer payment | customer departure |  |
The random variation of the lead time between a replenishment order and the corresponding delivery
is modeled by a random variable with a uniform probability distribution between 1 and 3 days.
The inventory is modelled as an object with three attributes: productQuantityInStock,
reorderPoint and targetInventory. For simplicity, the model does not create
replenishment order events, but instead it only schedules corresponding delivery events.
Consequently, we model just one object type: SingleProductShop, with three attributes
quantityInStock (NonNegativeInteger), reorderPoint (NonNegativeInteger),
and targetInventory (PositiveInteger). In addition, we model two event types:
DailyDemand as an exogeneous event type with one attribute: quantity (PositiveInteger),
and with the random variable function sampleQuantity and, as an exogeneous event type,
with a recurrence function.Delivery as a caused event type with one attribute: quantity (PositiveInteger),
and with the random variable function sampleLeadTime.
When the design model is implemented with an object-oriented programming language or framework,
the participation associations between DailyDemand and SingleProductShop, as well as
between Delivery and SingleProductShop, are represented with the corresponding
reference properties shop and receiver. This is also the case when using the Object Event
Simulation (OES) framework OESjs available from Sim4edu,
where all object types are derived from the pre-defined OES category oBJECT
and all event types are derived from the pre-defined OES category eVENT,
as shown in the following diagram:
oBJECT and eVENT.| ON (event type) | DO (event routine) |
| DailyDemand( demQuant) @ t |
IF demQuant <= shop.quantityInStock
THEN
IF shop.quantityInStock − demQuant < shop.reorderPoint AND
shop.quantityInStock > shop.reorderPoint
THEN
SET ordQuant TO shop.targetInventory −
shop.quantityInStock - demQuant
SCHEDULE Delivery( ordQuant) @ t + sampleLeadTime()
DECREMENT shop.quantityInStock BY demQuant
ELSE (if demQuant > shop.quantityInStock)
INCREMENT shop.lostSales BY demQuant − shop.quantityInStock
SET shop.quantityInStock TO 0
|
| Delivery( delQuant) @ t |
INCREMENT receiver.quantityInStock BY delQuant
IF receiver.quantityInStock <= receiver.reorderPoint
THEN
SET ordQuant TO receiver.targetInventory −
receiver.quantityInStock
SCHEDULE Delivery( ordQuant) @ t + sampleLeadTime()
|