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]

:+1:

[tzyganu]

:+1: x :100:

[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]

:+1: x :100: from Aligent too :smile:

@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. :+1:

[philwinkle]

I like this model :thumbsup:

On Tue, Mar 18, 2014 at 7:20 PM, Alisson Oldoni notifications@github.comwrote:

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: :+1:]

Reply to this email directly or view it on GitHubhttps://github.com/magento/magento2/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: :+1:]

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

[SchumacherFM]

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

[aligentjim]

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

[wsakaren]

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

[MattDunbar]

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

[wsakaren]

Disagree. Right now have a balanced ecosystem, if you remove the pollen the bees go elsewhere or die. Magento will never do it as good as the ecosystem are achieving.

[MattDunbar]

From the perspective of someone who's been doing client (agency) work for many years and has spent a significant amount of time working with Magento - the ecosystem is actually a disaster. Its littered with crap that barely works, extensions that are only possible because of very hacky approaches, encrypted code, etc. Its to the point that a lot of dev shops have a whitelist (or blacklist) of extension shops they don't trust (webshopapps has always been on our whitelist - you guys put out great work).

Also, in this case multi location inventory in the core would do significantly better than what the ecosystem can achieve. Not because Magento has a better team or better developers (I don't know well enough to comment), but because when you have to build on top of the core implementation of something as complex as this it's almost always going to be hacky.

Take a look at what we released while I was working for Demac Media as an example - https://github.com/DemacMedia/Magento-Multi-Location-Inventory/

It works, and it has very few issues. That said, it could be done significantly better in the core and more than 50% of the code there is because this unfortunately is something that is tightly coupled with many other parts of the core and required a lot of rewrites.

Regardless, with all that's going on at Magento right now and Magento hopefully realizing if they delay again they'll really make us question if M2 will ever happen, I really doubt this will get attention or be implemented.

[ladle3000]

It needs to be in the core.

For instance right now, we're looking for a saas inventory solution to update multiple inventory locations in Magento. In order to do so, it's going to require customization of the saas api to work with some Magento 3rd party extension. Half the solutions we want don't even offer an api.

Further, it makes using Magento as a pos a real possibility. If you can separate out multiple physical location storefronts with actual allocated inventory.

It should just be a core feature that can be supported by the greater ecosystem of integrated solutions outside of Magento.

[SchumacherFM]

My full support for the opinion of @MattDunbar :+1:

There is enough room for the extension developers to build on top of that feature more features.

[alankent]

Could it be the challenge is to work out how much should be standardized (in the core) and how much left to extension developers? I would have thought N different implementations of a "core" area blocks other extension developers from building on top. Which base do they pick? Also if the core never standardizes common functionality, ultimately that will lead to a stagnant base. I keep thinking of JSR like working groups. Find commonality across extensions, get that into the core. Not a 100% do nothing policy if an extension exists, not a implement every feature of every extension out there policy. That middle ground is hard but I think ultimately more fruitful for the overall ecosystem as it opens up new possibilities for new extensions, helps merchants see Magento as moving forwards, and not completely replace existing extensions.

[ladle3000]

The thing is, is if you include this feature, you will have a ton of extensions that utilize multi location. Examples are pos systems for retail stores, ERP, and inventory systems, etc.

You could build a very worthy ERP right into the UI.

[pzamani]

Just found out about this post and wanted to reply that we have built an extension http://www.magentocommerce.com/magento-connect/dropship360.html to address this very problem in Mage 1. Our customers use the extension for multi-warehouse/multi-vendor inventory and order management mostly around drop shipping or 3pl integration. It has gone through 3 revisions with the latest release last month with a portal for all external vendors/warehouses to manage inventory and orders. We are working with Magento extension team to make it available as an extension with 2.0.

[ladle3000]

@pzamani - that's just an advertisement, and the opposite of this threads objective.

[seansan]

:+1: x :100:

As a webstore owner we would really love to see basic support as described in the original call.

It is also true that Magento is on the verge of adding ERP elements /becoming ERP-ish ... versus being a storefront only.

Having several webviews and 3 stock locations, one of which physical we support the addition of this functionality.

[rtull]

I'm on board with supporting multi-node inventory as a platform concept. I'm not interested in seeing Magento build a lot of business logic around multi-node inventory. Having multi-nodes arranged manually with some sort of priority would work as a minimum version of platform support, I think.

The goal of this, IMO, is to create enough fundamental structure to avoid invasively changing the platform to achieve multi-node applications without getting into lots of multi-node business function. The former is Magento's job. The latter is the job of the ecosystem (developers / extension vendors).

If Magento starts building lots of fancy functionality around this, like automated source selection rules or binning support, then it's gone too far and yes, I think damaged the ecosystem opportunities.

On the other hand, not supporting multi-node as a concept leaves a very large hole that cannot be worked around without extensive changes to very deep parts of the system. As a result, supporting this in the platform creates the opportunity for stable development and innovation, as I see it.

[MattDunbar]

Agreed with @rtull's comment - basically, I never want to do this again: https://github.com/DemacMedia/Magento-Multi-Location-Inventory/blob/master/app/code/community/Demac/MultiLocationInventory/etc/config.xml

Instead, I'd like to hook into a few events and maybe rewrite 1 model's method of how the data is used to decide on shipments.

[jonpday]

absolutely agree with @rtull and @MattDunbar - from an agency/developer POV @wsakaren , the very serious issue is that all of the multi-warehouse extensions that we've tried (we haven't had the pleasure of WSA one, but based on my painfully deep knowledge of this problem domain over the years, my understanding if that it must be similarly invasive because the nature of Magento's cataloginventory module), the extent of rewrites and kludgy observers required means that any third-party extension must and will conflict with other extensions or customizations in non-extensible and highly inefficient ways. The concept of supporting multiple inventory locations/repository in the core then allowing the agency OR extension developer to implement business-logic on top is an excellent compromise and big step forward for the platform, IMHO.

[wsakaren]

As a FYI we don't do inventory management. I think good arguments are raised here, in particular @rtull and @alankent. My key points are:

1) Should collaboration/ Decisions on big features like this be done via Github 2) Where does Magento end and extension providers start? Been a problem since the start, get the innovation angle, just appreciate what you are killing off

[MattDunbar]

@wsakaren and its too bad - we could have really used a solid option :)

[ladle3000]

@wsakaren

Regarding #2 It would be creating more than what it will kill off. If you have multiple stores as an option in Magento, then multiple inventories should have been there at the inception of that IMO... It's sort of naive to assume that retailers are using just one warehouse.

Isn't the question of any core enhancement where Magento ends and extensions begin?

[jonpday]

I offer this next opinion cautiously, as I've never earned my living as an extension developer but...

I think it is a reasonable expectation that whenever Magento itself increases market share via great functionality, then extension developers directly benefit. The more merchants that choose Magento because of inbuilt multi-warehouse capability (would be a massive killer feature versus competing ecom platforms AFAIK), the more merchants that will purchase good quality shipping customizations, discount plugins, homepage banner extensions, etc. So, I don't think the debate should be confined to "Magento versus extensions".

[amacgregor]

@alankent @wsakaren I'm a bit late to the discussion but I'll chime in. Around a year ago we tried to tackle the MultiWarehouse inventory problem; as @MattDunbar already mentioned the amount of work and customization that went into it was far from ideal.

As we continued working with the multiwarehouse inventory extension we faced another challenge; no merchant is the same, every single one had different requirements for the way their MultiLocation Inventory system should work.

While I agree that having multi-warehouse as part of the core would make for killer functionality and a great addition to the platform. I fear that Magento will try to shoehorn a one size fits all Multi-warehouse solution and make development more difficult or painful for the merchants that don't fit in that model.

So I would like to propose the following to Magento, develop Multi-node Inventory but do so as a standalone extension that can be required and easily extend if the project needs it. Don't make it part of the core or bundled by default.

Release it as an extension that provides the bare minimum functionality for multi-warehousing, and leave the agencies and extension developers do the rest.

[wsakaren]

Agreed @amacgregor Mutli-Warehouse/Dropship/Inventory Management is very open ended.

[ladle3000]

Don't agree. I think it's very straight forward the solution this thread offers.

[IvanChepurnyi]

I think no one's business will be affected by this functionality, as soon as they do it in a way I explained to @antonkril before, then having a separate scope for stock and price without direct relation to a store-front identifiers (e.g. website, store_id, customer group) will solve a problem of flexability and provide a correct way to customize the functionality.

As soon as we get that separation, there is nothing else needed from core and community will just take their own implementations of dropshipping or mutli-stock features as different customer businesses will need.

What I think everyone should agree, that we do not need that strick relation of stock and prices to configuration scopes, as configuration scope can be different from business scope. And we should not just duplicate rows in database and make system more complex in this area.

[MattDunbar]

Agree with @amacgregor. To add on, this could be a whole lot easier if we made inventory and multi node inventory entirely self contained modules that can be disabled.