A Python toolkit for building and testing supply-chain simulations

A supply chain is more than a list of suppliers. It is a network: goods move between manufacturers, distributors and retailers, while orders, delays and shortages can affect connected parts of the system. SupplyNetPy, an open-source Python library described by Tushar Lone and Neha Karanjkar, is designed to help users model these networks and explore how they behave under different conditions.

The practical question is whether reusable software can make it easier to build and check detailed supply-chain simulations, rather than requiring users to write all the simulation logic from scratch. The paper presents SupplyNetPy as a collection of components for describing supply-chain entities and connections, running simulations and reporting results.

From a network diagram to a running model

Users describe a supply chain as a directed graph. Nodes can represent suppliers, manufacturers, inventory-holding locations or points where customer demand enters. Links represent transport between nodes and can include cost and delivery time. Users can specify stochastic demand and lead times, as well as node or link disruptions.

The library is built on SimPy, a Python framework for discrete-event simulation. Instead of advancing in tiny, fixed time steps, this approach moves from one event to the next—for example, an order being placed, a shipment arriving or inventory expiring. SupplyNetPy offers a function-based interface for assembling models and an object-oriented interface for greater control.

Its built-in features include several inventory replenishment rules and supplier-selection strategies. Perishable items can be tracked by manufacture date and removed when their shelf life ends, with waste costs recorded. Users can extend components through inheritance. Simulation output includes event logs and measures such as inventory, fulfilled demand, shortages, costs and revenue.

What the validation found

The authors tested individual components and compared simulations with analytical results for three established inventory problems. In the newsvendor example, the simulated profit curve peaked at an order quantity near the analytical optimum of about 110 units. In the economic order quantity example, the simulated cost-minimizing lot size was about 1,010 units, compared with an analytical value of about 980—within roughly 3%. The safety-stock example was less exact: simulated safety stock and average inventory were above their analytical values, while estimated order flow time was below its analytical value. The authors attribute those differences to resampling negative demand values, which raises effective demand relative to the nominal assumptions.

The team also compared small deterministic models with AnyLogistix, a commercial supply-chain simulation tool. Most tested configurations matched across tracked measures. Some differences prompted the authors to make assumptions configurable, so users could represent alternative interpretations of parameters or policies. They also describe specific boundary cases where results diverged: simultaneous demand and replenishment events can be processed in a different order by the two tools, while real-valued deterministic time intervals can produce accumulating floating-point differences that shift event timing. These are implementation-sensitive cases, not evidence that one tool is universally correct and the other wrong.

For a further check, the authors reproduced a published pharmacy supply-chain case study. It includes Poisson-distributed demand, stochastic supplier disruptions, perishable medicine, fixed transport lead time and a periodic replenishment policy. Unmet demand is lost. The paper reports that the expected-cost patterns and optimal policy region were consistent with the original study. Separate performance tests on generated networks found execution time grew approximately linearly with network size and simulation length in the tested setups; that does not guarantee the same speed for all models or hardware.

What the results can—and cannot—tell us

Together, these tests provide evidence that SupplyNetPy implements its supported features coherently in the examples examined. They do not show that it can predict what will happen in a particular company’s supply chain. Results depend on the network structure, input data and assumptions. Inaccurate demand estimates or missing supplier links, for instance, can produce detailed reports that still misrepresent the real system.

The paper says the current version does not support continuous material flows such as pipelines, shared inventory for multiple products, or advanced logistics such as fleet management and vehicle routing. Broader disruption modeling and built-in resilience metrics are among the proposed future extensions, not capabilities established as current features. Validation is also limited to selected benchmarks, configurations and case studies.

The paper identifies itself as an author preprint of work accepted at the 2026 Winter Simulation Conference. The supplied manuscript does not establish what changes, if any, appeared in the final proceedings version. Its results should be read as evidence about the library and the tested examples, rather than independent proof of broad real-world predictive performance.

For researchers and developers, the contribution is a reusable way to describe networks programmatically, vary assumptions and inspect simulated outcomes. Whether it is appropriate for an operational decision depends on careful model construction, validation against relevant data and an understanding of what the software leaves out.