Multinode Inventory

[tanya-soroka]

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.

[tegansnyder]

@tanya-soroka Including this in Magento 2 will solve a very large problem for my implementations. Inventory level management on a website level is crucial feature. I support this effort.

[jamiemck]

I too, feel this is one core feature that Magento 2 should have baked in.

[ArnaudLigny]

👍

[tzyganu]

👍 x 💯

[tegansnyder]

I'm curious for those of you who have liked this issue have any of you worked around this issue in your implementations?

Allowing QTY field to be scoped to website level would be a great addition.

[tegansnyder]

Seeing some progress in this @271615abecbe64b4fea4141f8dbf3513ef139250 "Introduced a consistent approach for using the Config scope"

[jonpday]

👍 x 💯 from Aligent too 😄

@tegansnyder we have used the InnoExts MultiWarehouse extension with pretty good success. AFAIK, it is the only available option.

[IvanChepurnyi]

In my personal opinion using of websites as scope for stock is not a good option.
Website is not a separate stock in most of the cases, hovewer there could different stocks based on customer group within a website.
The best option is to create separate scope entity for such thing, that will be dynamically mapped to a customer, website, country, region, depending on the rules specified in it.
The same should be done for prices.
Hope core team will listen to my suggestions.

[JoseHawkins]

What about ability to track stock per custom option item?

[aoldoni]

I would assign stock level to a zone, warehouses to zones, and zones to websites.
this would be better than assigning directly to websites?

It can get complicated though. 👍

[philwinkle]

I like this model 👍

On Tue, Mar 18, 2014 at 7:20 PM, Alisson Oldoni notifications@git.1-hub.cnwrote:

I would assign stock level to a zone, warehouses to zones, and zones to
websites.
this would be better than assigning directly to websites?

It can get complicated though. [image: 👍]

Reply to this email directly or view it on GitHubhttps://github.com//issues/473#issuecomment-38001186
.

Follow me on Twitter - @philwinkle
Friend me on Facebook - http://www.facebook.com/philwinkle

[adam-paterson]

I'd love to see this implemented.

[ihor-sviziev]

+1

[ddoddsr]

@tegansnyder We selected Innoexts Multi-warehouse as well.

[SchumacherFM]

What is the status on this issue?

We're currently implementing these features ... for Mage1 ;-)

[tegansnyder]

I've worked around the issue in Magento 1.14.0.1 by using the Innoex extension mentioned along with Xento stock import (it supports the Importing inventory levels via stock id by changing a constant).

I would be nice to know if multinode is ever going to make the core in Mage 2.

On Jul 7, 2014, at 10:36 PM, Cyrill Schumacher notifications@github.com wrote:

What is the status on this issue?

We're currently implementing these features ... for Mage1 ;-)

—
Reply to this email directly or view it on GitHub.

[tegansnyder]

For those of you looking for another Mage1 solution see: https://github.com/DemacMedia/Magento-Multi-Location-Inventory - in active development by @MattDunbar @amacgregor and others in the community.

[peterjaap]

+1

[octerpus]

[image: 👍]

[seansan]

+1

[ihor-sviziev]

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".

[tanya-soroka]

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

[jonpday]

awesome, thanks @tanya-soroka and Paul.

[aligentjim]

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.

[aoldoni]

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.

[MattDunbar]

It'd also be a much better featured to make enterprise exclusive (rather than caching).

[alankent]

What is the best way to work out an agreed spec on what should be in the platform and what not? (I cannot promise what we will do - I am probably as curious to work out how to have an effective conversation as the outcome of the conversation.) E.g. get @IvanChepurnyi to write up his proposal as a gist and let others comment?

[MattDunbar]

Don't care what approach Magento takes, as long as that approach follows along with the services contracts / interfaces patterns being used and is replaceable without tight coupling (keep all inventory logic in the inventory module).

[IvanChepurnyi]

Will make a gist and post it here.

[birchestx]

There are 2 conversations @alankent -

1. How to architecturally do this so that works best for agencies, extn providers, etc (e.g. allow ability to switch off, core features, etc)
2. The business discussion & roadmap around where Magento ends and agencies, providers start. Set the playing field.

The latter of these 2 should not be done on github. There are many technology partners affected by what's being said here (and other decisions), do you expect BD and CEO's to be sitting on github?

In my mind if you are tackling say the roadmap for email, inventory, ERP or whatever then in the spirit of open source and collaboration you would share such information with partners for discussion, maybe have ability for feedback, initial thoughts and even a meeting. And make it available for the community at large to see, as this has potential to affect their lives. The impact on extension developers is high if you get this wrong, you could knock someone out of play that has played an essential role in the advance of Magento. At least have the courtesy to discuss it with them before playing it out with a group of developers.

As I've said before this has less impact on us, we have no inventory mgmt solution today (and based on this discussion will not be building one tomorrow). It's the process that needs sorting here, not just the development architecture.

[davidalger]

@wsakaren Please keep in mind that these broad level topics have been discussed with partners multiple times long before even the M2 developer beta dropped. So has this very multi-node inventory feature, which is why this issue was opened in the first place. The requirements came straight out of the notes from the technical discussions had in Chicago in October, 2013. Partners predominantly told Magento it was needed at some of these meetings (I was present). That is to say I think the conversation people are asking for already happened and the issue was opened so that the feature could receive broader community feedback, which looking at the early 2014 comments, the feedback was predominantly positive but the issue remains open since it hasn't (as of yet) been implemented.

Pushing for different interaction and involvement would be better done, IMO, outside the context of a GitHub issue, where the entire thing is ending up pretty muddled and it does nothing but breed unclarity around what is actually being done here. Maybe you could get together with Alan et. al. at the Austin offices and hash out your thoughts. ;)

[Sam-PUMP]

I too can't believe there is no solution for this problem in Magento 2. We use Advanced Inventory by Wyomind and its fantastic. Not too intrusive. Not ioncube encoded. Allows stock levels to be assigned by region store view or customer group. Includes a csv import that is capable of mapping the columns to each location. I've tested so many others and while good, this one just has more features and the way they split your inventory doesn't change Magento's global stock so you could still technically sync with an external master inventory for global.

[IvanChepurnyi]

@alankent @wsakaren Here is my draft of architectural proposal how to implement this in a simple and flexible way. I focused my proposal more on inventory management, but price management architecture should be similar, if more deep explanation is needed, I can spend some time on it as well.

https://gist.github.com/IvanChepurnyi/70fcea1793db4b22c7fe

[sibia-ti]

Great requirement post Tanya,

Actually I also need this. But there is only one extension(Innoexts Multi-Warehouse) which meets most of those above mentioned requirements. But I need other solution , Please suggest me another extension name which satisfies these requirements.

Guys please advice me asap

Thanks in advance

[Krapulat]

Does anyone work on this?

[alankent]

We are working on multi node inventory. I don't have a release date, and it is not extactly what Ivan proposed after further review, backwards compatibility, Magento COM (our order management product) alignment, etc. But we certainly used multiple sources of information and are working in this area. I like to characterize it as getting a common base data structure in Digital Commerce (the web store). Hopefully more of the multi warehouse related extensions out there can then interact or cooperate better due to the shared data model we provide.

[MagePsycho]

Any updates on this? When we can expect the beta version of multi-node inventory in Magento2?
This would definitely help lots of merchants.

[mbrinton01]

@MagePsycho I do not have an firm ETA, but I can confirm this feature is in development now. Thank you for your feedback on priority.

[andrss]

@mbrinton01 Will be this feature available for CE edition or it will be EE only feature?

[mbrinton01]

@andrss It will be EE only

[MagePsycho]

Still waiting for the updates on multi-website inventory feature. Any timeline for this feature? We need this feature desperately.

[seansan]

About adding it to EE only : please be aware that many CE users have 1 store and 1 webshop often with two stock locations. So even CE users would need this and love this. Not adding it all for CE users - to me- sounds a little bit akward. Why not :

• limit the numbers of nodes for CE to 2 or 3?
• disable advanced filters/rulesets for orders to node logic?

Basic 2 node implementation (remote and local for example) would mean a great thing for CE users too. And make them participate and add code/pull requests too

[piotrekkaminski]

Thank you for your submission.

We recently made some changes to the way we process GitHub submissions to more quickly identify and respond to core code issues.

Feature Requests and Improvements should now be submitted to the new Magento 2 Feature Requests and Improvements forum (see details here).

We are closing this GitHub ticket and have moved your request to the new forum.

[andrewhowdencom]

Googlers: https://github.com/magento-engcom/msi/wiki