Technical Vision. Catalog Inventory

Multi Source Inventory (MSI) is developing for Magento Open Source. MSI is an evolution of original CatalogInventory module and interfaces.

We consider two main entities of stock:

• Source stock, the stock that is physically in a source
• Aggregate stock, the virtual stock of what can be sold in a sales channel

For example, there are 3 physical sources (A, B and C) which assigned to specific sales channel (for example, Magento Website). If Customer comes to this website and wants to buy some product (Product1), we should show him that we have next amount of this product: Qty of Product1 on A + Qty of Product1 on B + Qty of Product1 on C We call it – Virtual Aggregated Stock (StockItem in Magento words).

There are two important considerations for stock handling:

• Aggregation (StockItem), aggregating the stock of several sources
• Multiple sales channels can use the same aggregate (DE & NL share the same stock)

How it looks like on the code level. On the code level we have next entities:

• Source – definition of physical stock (brick and mortar store, source, warehouse etc.)
• SourceItem – relation object, which represents the amount of specific product on the particular physical source. We use this entity for updating inventory on each particular source. (sync with PIM or ERP system, or stock deduction during the checkout process). Can’t be used for retrieving data which need to be rendered on front-end, because only aggregated data should be used for all validations and UI representation.
• StockItem – Aggregated Virtual Stock. Read-only data which were generated as a result of re-indexation process. Where based on pre-defined mapping we define what sources are assigned to current scope (sales channel), and aggregates quantities from all these sources. Also we use StockItem to check whether specific Product is in Stock or Out of Stock. Making this segregation by Read-Only interface (StockItem) and Write-Only interface (SourceItem) we achieve CQRS on the level of Inventory architecture. Roughly saying, all the GET HTTP requests should use StockItem entity, all the POST/PUT should use SourceItem.

When Customer buys the product, it should be shipped from the particular location. A customer usually does not care what location product was shipped from, as soon as this is the cheapest option. For the Merchant, it is important to have minimal overhead for the inventory storage and shipping costs. An algorithm which assigns the particular inventory to the order item should take all these considerations into account and select the best possible options. Our current idea is to provide two out of the box algorithms:

• Priority based algorithm (where each source given a priority in the scope of specific sales channel)
• Minimal delivery cost algorithm

On the level of API we should provide an ability to support both Synchronous as well as Asynchronous calculation during the checkout process. You can read here more about our insight and requirements for Algorithm API and implementation