cancel
Showing results for 
Search instead for 
Did you mean: 

Multinode Inventory

Multinode Inventory

Feature request from tanya-soroka, posted on GitHub Jan 17, 2014

Multi-node inventory

Multi-node inventory functionality will introduce support for multiple warehouses, management of product stock per website and warehouse, order processing through drop shippers and vendors. It will allow set up of multiple shipping origins, flexible shipping configurations, and automatic vendor notifications.

Functional Requirements

  • Ability to enable/disable shipping from multiple addresses (either you’re your business address or from 3rd party warehouses and suppliers)
  • Ability to specify the addresses of these warehouses/suppliers
  • Ability to assign products to different warehouses/suppliers
  • Ability to manage stocks in different warehouses
  • Ability to specify preferences for picking up products from warehouses
  • Ability to automatically define nearest warehouse to customer's destination
  • Ability to notify warehouse/supplier upon order and/or invoice creation
  • Ability to create/update email templates to be sent to warehouses/suppliers
  • Ability to see products assigned to selected warehouse
  • Ability to see shipments from selected warehouse

Inventory per Website

Provides ability to:

  • Set up a QTY attributes per website
  • Specify different inventory levels for each website
  • Track inventory level for each website
  • Track low stock for each website
  • Get a total QTY of the product

This feature entails the following changes:

  • General settings of inventory Scope should be available under Configuration > Catalog > Inventory Section
  • Additional rows on Product QTY of Product Grid (for products which are using inventory option)
  • Updates of Low Stock report

Warehouse Settings

It should be possible to enable and set up Multi-node inventory functionality. As a merchant, I want to have the following options:

  • Enable/Disable service
  • Show warehouse information on product page, shopping cart, checkout process, order/invoice/shipment/refund
  • Select any enabled Shipping service/method per warehouse

Manage Warehouses

The Manage Warehouses tab should appear under System > Store set upon a primary menu. It should contain the following action:

  • Create / Edit / Delete a new Warehouse.
  • Filter and search data of Warehouse list.
  • Provide general information about a warehouse: title and address.
  • Mass action, such as delete and update.

Admin user should have ability to specify the following warehouse data:

  • Warehouse contact information and Address
  • List of assigned Products
  • Shipping methods data
  • Sales data (Shipment, Orders, etc.)

Managing Inventory per Product

Alternatively, admin user should be able to specify warehouse/supplier data on the Product Information page and manage inventory per each warehouse individually.

The QTY field of the Inventory section (i.e. general quantity of a product) should display the sum of the numbers entered to the QTY fields per warehouses. It be set for read-only purposes.

Shipping / Delivery Configuration

Store owner should be able to select a shipping method from existing list of vendors (USPS, USP, DHL, FedEx, etc.). Additionally, one can set up a custom shipping method (Drop-shipping) per warehouse. Configuration settings, delivery fee, and delivery time are required on global/warehouse level.

Admin user should have ability to specify ship/delivery option for products from warehouse(s):

  • Shipping from a nearest warehouse (closest to customer's area) ** When a product that is assigned to multiple warehouses is added to the cart, the nearest warehouse is selected for delivery. Otherwise, product should be delivered from next nearest warehouse where it is available
  • Shipping from a warehouses with the highest priority ** When a product that is assigned to multiple warehouses is added to the cart, the warehouse with highest priority is selected for delivery. Other warehouses are selected according to the specified priority.

Checkout

Once multi-inventory functionality is enabled, the following delivery scenario should apply:

  • When ordered product is assigned to a warehouse, the address of a warehouse is considered as a pick-up address for the shipping service provider. Shipping rate to be calculated accordingly.
  • When ordered product is not assigned to a warehouse, the store address is considered as a pick-up address for the shipping service provider. The shipping rate is to be calculated accordingly.
  • When ordered products are assigned to multiple warehouses, multiple orders are created. Address of appropriate warehouse is considered as pick-up address for shipping service provider to each of the orders. The shipping rate is to be calculated accordingly for each created order.

Returning Items Assigned to Different Warehouses

Store address to be the return address for products. If Automatically Return Credit Memo Item to Stock feature is enabled, the returned items should affect the general quantity of the product and appropriate Warehouse should be considered as place of their storage.

Displaying the Warehouse/Supplier Information on the Order Review Page in Backend

Order View page should display warehouse/supplier information for every ordered product. The same data should be also displayed on the Invoice, Credit Memo and Shipment pages. Products should be displayed on separate rows in case these products will be delivered from multiple warehouses.

Notifying Warehouse/Supplier Upon Creation of an Order in Backend

Admin user should be able to manage their notifications. Notifications can be configured to be sent per warehouse when an order/invoice/refund is created.

Creating Email Template for a Warehouse/Supplier

By default, email to a warehouse/supplier should contain all product details (i.e. product name, product parameters, quantity of each item, tracking information, and shipping method details). However, admin user should be able to create their own templates. There it should be ability possible to specify email template that will be used for sending a notification (per warehouse or globally).

Tax Calculation

Depending on tax configuration and local tax laws, tax may be collected for products shipped from a warehouse location and should be included when an order is placed.

Reports

Warehouse data should be updated with reports about Sales and Products, like Orders, Shipment, Low Stock and etc.

33 Comments
New Member

Comment from seansan, posted on GitHub Dec 01, 2014

+1

New Member

Comment from ihor-sviziev, posted on GitHub Dec 24, 2014

I think this is really big improvement and I don't think that it can be done before release. I think first of all should be implemented "Inventory per Website".

New Member

Comment from tanya-soroka, posted on GitHub Mar 18, 2015

Hello all, thank you for your feedback. We have created tickets for these features: MAGETWO-14308 (MNI) and MAGETWO-24274 - Inventory per website.

New Member

Comment from jonpday, posted on GitHub Mar 18, 2015

awesome, thanks @Tanya-soroka and Paul.

New Member

Comment from aligentjim, posted on GitHub Mar 18, 2015

I think first of all should be implemented "Inventory per Website".

We've got a number of clients using Multilocation inventory systems in Mage 1 for whom an :Inventory Per Website" solution wouldn't work (it would work for others though).

A great compromise would be allowing in the architecture "pools" of inventory to have their own distinct identifier (i.e. remove the assumption in the core that the cataloginventory_stock table contains only 1 record and that stock_id is always 1). Then create a single class which handles the "this order uses this inventory pool" logic. That single class could then implement "inventory per website". But more importantly, it also provides a convenient extension point for someone else to insert their own logic via a rewrite or similar.

If those two things could be implemented it would make for a system that can be readily extended to handle more complex scenarios without the implementation effort of having to implement that complexity in the core.

New Member

Comment from aoldoni, posted on GitHub Mar 18, 2015

As mentioned above, "per website" stock wouldn't be enough.

@aligentjim idea above is great, I would also vote to have some pre-built layers that add value out of the box.

This could potentially start with layers in between, such as warehouses or zones. We would then assign stock to these warehouses/zones, which would then be assigned to websites.

It could be the case as well that 1 website can handle multiple warehouses. Moreover, an order that was just created could potentially be fulfilled by several different warehouses.

Thanks.

New Member

Comment from SchumacherFM, posted on GitHub Mar 18, 2015

I reported this "bug" "Inventory per Website" end of January https://github.com/magento/magento2/issues/1002

New Member

Comment from aligentjim, posted on GitHub Mar 18, 2015

@SchumacherFM totally agree with your #1002 ... What I was proposing above was to overcome the Mage 1 limitation on stock id, then bind websites to a stock id in (easily replaceable) code to implement the "inventory per website" functionality. Agree that this won't suit everyone, which is why it'd be great if the "decision" about which stock location to use for a given order was centralised into a single location which can easily be replaced/rewritten. Thus enabling those of us with more complex needs to insert our own logic easily when required.

New Member

Comment from wsakaren, posted on GitHub Aug 01, 2015

This change knocks off a whole load of extensions & cabilities that cater for it. By implementing you adversely affect the income of extension developers.

New Member

Comment from MattDunbar, posted on GitHub Aug 02, 2015

@wsakaren - The fact that this is lucrative for 3rd party developers is exactly why it should be built in. That clearly demonstrates demand from retailers for this functionality. It might not be ideal for businesses like WebShopApps but it most definitely is for the retailers, which are Magento's customers. I'm sure with this (if it happens) the need for many extensions built upon it (such as various shipping implementations) will arise anyways.