To date the MSI project has added a lot (I even read somewhere it is 30% of all core code?) ... good work. In our M1 system we have been using several multistock solutions and kind of learned along the way. One of the things however we are missing in M2 MSI is that currently a warehouse can be either enabled/or not ... on and off. In essence this influences the salabilty. Can the products be sold from this source?
However in several store situations we have seen different behaviors of sources where there is more granularity "exactly what a source location can do" some examples include. I will list some examples of the extra granularity and add some situations. See under expected behavior.
Expected behavior (*)
Sources have additional core settings controlling the behavior of the source not only for sales, but also for returns and shippability
enabled - this is the master switch for a source. If on then the source is added into queries, logic, but if turned off then all the below settings are overridden to no or disabled.
salable - a source can be salable and this means the qtys in that source are added in the formula for salable qty
can ship from source - sometimes sources have a special function and can be used to ship from during shipping, but not to sale from on the frontend or backend. And example is an "INC - Incoming source" where backordered products or new (season) products are received; or maybe an "RES - Restore source" where products in some kind of return or fix state are stored until they can be sold again. An admin may want to ship from it if necessary, but does not want to sell from it on the backend.
accepts returns - in a later stage we imagine MSI will also have some kind of logic to select to "which" source a return is sent. Often there is some logic that differs for order items before they are shipped (goes back to same source -selected by default-, but a dropdown should exist to select which source) and after they are shipped (goes back to some RES- Restoration source -selected by default-, but a dropdown should exist to select which source)
not salable only for admin - in some cases one would not want to sell products from the frontend, but a source can only be used by admins creating an order in he backend.
Benefits
Customer situations may exist where sources exist that behave like, e.g.
INC Incoming source: source where backordered products belonging to some waiting order are scanned and received. Item stock is updated +1 upn receival and the "waiting" orders can be shipped. Items from this source for example may not be sold (a second time) on the frontend nor on the backend. The source settings may look like this
RES - Restoration or fix source. When returns are processed they are sometimes sent back to the originating source. But actuall y in most cases this wont happen. In real merchant life there is always an in-beween state where returns maybe are "reviewed before going back into salable stock" or "need to be reconditioned before going into salable stock" or "need to be fixed before going into salable stock". To me Magento has always been close to our real life processes and I see this as a missing feature that can easily be added. The source settings may look like this
Additional information
Many examples exist in M1 extensions and use cases that somehow never reached the MSI project which is interesting as these are real life examples that affect us every day. It would really be great if these situations and use cases for merchants are also covered by the core.
Description (*)
To date the MSI project has added a lot (I even read somewhere it is 30% of all core code?) ... good work. In our M1 system we have been using several multistock solutions and kind of learned along the way. One of the things however we are missing in M2 MSI is that currently a warehouse can be either enabled/or not ... on and off. In essence this influences the salabilty. Can the products be sold from this source?
However in several store situations we have seen different behaviors of sources where there is more granularity "exactly what a source location can do" some examples include. I will list some examples of the extra granularity and add some situations. See under expected behavior.
Expected behavior (*)
Sources have additional core settings controlling the behavior of the source not only for sales, but also for returns and shippability
enabled
- this is the master switch for a source. If on then the source is added into queries, logic, but if turned off then all the below settings are overridden to no or disabled.salable
- a source can be salable and this means the qtys in that source are added in the formula for salable qtycan ship from source
- sometimes sources have a special function and can be used to ship from during shipping, but not to sale from on the frontend or backend. And example is an "INC - Incoming source" where backordered products or new (season) products are received; or maybe an "RES - Restore source" where products in some kind of return or fix state are stored until they can be sold again. An admin may want to ship from it if necessary, but does not want to sell from it on the backend.accepts returns
- in a later stage we imagine MSI will also have some kind of logic to select to "which" source a return is sent. Often there is some logic that differs for order items before they are shipped (goes back to same source -selected by default-, but a dropdown should exist to select which source) and after they are shipped (goes back to some RES- Restoration source -selected by default-, but a dropdown should exist to select which source)not salable only for admin
- in some cases one would not want to sell products from the frontend, but a source can only be used by admins creating an order in he backend.Benefits
Customer situations may exist where sources exist that behave like, e.g.
Additional information
Many examples exist in M1 extensions and use cases that somehow never reached the MSI project which is interesting as these are real life examples that affect us every day. It would really be great if these situations and use cases for merchants are also covered by the core.
Some examples may be gathered from reviewing this extension: https://www.safemage.com/multi-warehouse-inventory.html