Managing stocks in a multi-store environment: Best practices

In a multi-store environment, you can manage the warehouses to stores and database relations in several ways. This article contains scenarios that can help you choose the most suitable warehouse management workflow and implement it using the Inventory Management feature.

Scenario 1: Separate warehouses and databases

Suppose you own a big e-commerce business and ship orders worldwide. You want to manage logistics and products effectively. You also want each store to be completely independent from each other, so user, products, and other data is not shared between stores.

In this case, each store can have its own warehouse and an own database. Stocks, product reservations, and availability are not co-depended between stores, and therefore are not synced:

This scenario is good for big businesses managed from various locations, with worldwide deliveries. The stores do not depend on each other in any way and do not require additional communication or synchronization.

Scenario 2: A shared warehouse but separate databases

Suppose you have a big e-commerce business, with many products and orders, so you want to separate all data for each of your stores. For some reason, you can not have warehouses spread across various locations, or your deliveries are within a specific part of the world, so you don’t need multiple warehouses.

In this case, you can have a common warehouse for all your stores but separate databases. Since the warehouse is shared, for the correct product availability calculations, product reservations must be synced between the databases:

This approach is good for big businesses that can’t have or don’t need multiple warehouses but still want to have data of each store separated.

Implementation reference

To implement this scenario, you need these three additional database tables:

• spy_oms_product_reservation_store to store reservation requests from other stores.
• spy_oms_reservation_change_version to store information about the time when the last reservation occurred.
• spy_oms_reservation_last_exported_version to store information about the time when reservations were exported to other stores last time.

Also, there are plugins to help you implement synchronization of the reservations:

Scenario 3: Separate warehouses but a shared database

Suppose you own a medium to big e-commerce business and ship orders worldwide. You want to manage logistics and products effectively, so each store has its own warehouse. You also want product reservations and availability to be separated per store, but you want all the data stored in one place. So, for example, if a product is unavailable in the DE store, but available in the AT store, a registered user can simply switch from the DE store to AT store and buy the product there.

In this case, consider separated warehouses but a shared database:

This scenario is good for medium and big online shops that want to have a common database of product, user, and other data. It’s a good option to, for example, allow registered users to buy from any store without having to re-register.

Scenario 4: Warehouse and database are shared between stores

Suppose you own a small to big e-commerce business and can’t have or don’t need separate warehouses per each store. You also want all the data stored in one place. So, for example, if a product is unavailable in the DE store, but available in the AT store, a registered user can switch from DE store to AT store and buy the product there.

In this case, consider having a shared warehouse and a shared database for all the stores. Since the warehouse is shared, for the correct product availability calculations, product reservations are synced between the stores:

This scenario is especially good for small online shops with one warehouse that want to have a common database of product, user, and other data.