Release 0.0.2 Deep Dive

by Kevin Fasusi |

Release 0.0.2 sees the introduction of the Monte Carlo simulation as a feature of the library. Using historical data supplied from a .csv, probable transactions are simulated. The simulation uses normally distributed random demand, to decrement stock over a given period. Inventory movement trigger consumption of stock and affect the transactions for opening stock, closing stock, backlog and purchase orders.

Running the Monte Carlo simulation is as simple as:

Running the Simulation

Before running the simulation, an analysis of the inventory profile is required. The series supplied by the .csv file, an example of the format is here. A detailed breakdown of the model_inventory.analyse_orders_abcxyz_from_file function can be found in the release-0.0.1 deep dive.

Now that we have the demand profile analysed, we can run the Monte Carlo. The interface for the Monte Carlo is in the simulate.py module. In the simulate.run_monte_carlo function, simulation instantiates SetupMonteCarlo class.

Generate a Random Normal Distribution for Demand

The generate_normal_random_distribution method, generates the normally distributed random demand for each sku.

Build Transaction Summary

The function simulation.build_window is a generator that yields the simulation_window.MonteCarloWindow object. The run_monte_carlo method is displayed below.

Most of the transaction logic for the inventory occurs in the build_window generator. The generator iterates over each SKU in the list of UncertainDemand objects containing the inventory analysis.

Much of the logic presented below is expressed as lambdas in the build_window generator and assigned to attributes in the sim_window a MonteCarloWindow object.

The full method is here. Below all the transaction logic in the build_window method is walked through case by case. The calculations below share a similar implementation, using lambda functions to assign a value to attributes of the sim_window object (an instance of the MonteCarloWindow class).

Opening Stock

The sim_window.opening_stock is set to reorder-level (safety sock + lead-time demand):

$$RL = LT \times D + Z \times \sigma \times \sqrt{LT}$$

Where: Z = service level, LT = Lead-time, D = Demand.

Opening stock is set at the reorder level in the first period for each SKU. In subsequently the the opening stock is the previous closing stock.

Closing Stock

The sim_window.closing stock is the non-negative result of the sum of $$demand$$ (orders) and $$backlog$$ subtracted from the sum of $$opening \ stock$$ and $$deliveries$$. If the result is negative, the absolute value of the negative closing stock will be added to backlog value.

Backlog

The current backlog for any given period is calculated as the absolute value of $$(demand + opening \ stock) - orders$$, if the result is less than 0. The following lambda expression is used to assign a value to sim_window.backlog in the build_window.

Shortages

Shortages in units are quantity of unmet demand in a given period; excluding earlier backlog.

Purchase order quantity

The amount raised on the purchase order, is based on the EOQ and lead time demand. In future, the purchase order amount raised will use the forecasting method used. More information will be available, like simulated forecast accuracy, when implemented in the simulation. Currently, the lambda function assigning the value looks like:

When a purchase order amount is above zero, a purchase order is raised. Logging the makes it easier to follow the transactions over the simulated period.

Units Sold

To calculate the revenue generated the units sold for each period are calculate. Oversight in this release means that the retail price is an omitted parameter, only the taking unit cost. The _units_sold method, is a private attribute.

Conclusion

All releases so far have been planning releases. There are still issues surrounding implementation and speed. Using Cython for some of the EOQ and simulation logic helped to speed things up. Python is not normally the go-to language of choice for programming simulations, so ultimately there is a trade-off. Some C++ wrappers are in development. However, Python is preferable if more Pythonic code and better implementation can reduce the bottlenecks.

Release-0.0.3 will not have a deep-dive. The new package was a result of testing for cross platform compilation of the Cython modules, on Windows, Mac, and Linux. To target a Windows machine compile the library from source using:

A second post, continuing the release-0.0.2 deep dive, will continue with the summarize_window, summarise.frame and optimise_service_level methods.