Hi everybody,
I added multi-warehouse support to the latest version 3.40 of nopCommerce and published it as a fork at https://git01.codeplex.com/forks/hubix2000/multiwarehousesupport for contribution.
The feature set is coordinated with Andrei and will be hopefully part of 3.50.
With a setting "Use multiple warehouses" in "Shipping settings" this feature can be enabled.
There is a new tab for products available called "Inventory" where you can edit the inventory per warehouse.
The mechanism distinguishs between
- StockQuantity: Total in stock incl. ordered items not sent out yet.
- ReservedQuantity: Items, that have been ordered, but are not delivered yet
- PlannedQuantity: Items, which are already added to a shipment, but not delivered yet.
The supplied stock quantity is
StockSupplyQuantity = StockQuantity - ReservedQuantity.
There is a new table called "ProductInventory" created.
There are a couple of events fired for inventory events.
Bulk editing of products is supported.
When you upload inventory by modifying "Product.StockInventory" through SQL the inventory will be inconsistent.
You need to modify then "ProductInventory.StockInventory" for the specific product/warehouse combination, too.
Deleting/cancelling an order having delivered shipments/items just increases the inventory for the shipped, unshipped items - not the delivered once.
Missing features:
- Shelf support is not yet implemented (Store owners misusing warehouses as shelfs should try carefully).
The fork can be just complied, installed and started. Demo data for multi warehouse support are provided.
Feedback is greatly welcome.
Jörg, nopDynamics
http://www.nopdynamics.com
Multi-warehouse support v1.0b (contribution). Feedback please...
- 28
- 304
- 4/12/2013
- Germany
Hi,
when Multi-Warehouse support is enabled a new tab "Inventory" is currently created.
My intention is to give different roles (product manager/warehouse employee) different interfaces.
I think a guy in the warehouse normally doesn't change the product details and the product manager doesn't touch the inventory. That's the reason why I introduced a new right for managing inventory, too.
For shops having just one warehouse the functionallity remains the same. Smaller shops normally don't split the roles. But if a shop has several warehouses normally thats reallity in my opinion.
There is an option to move the tab content to the info tab, too. I like to get your opinion - so feedback is welcome.
Best regards
Jörg
when Multi-Warehouse support is enabled a new tab "Inventory" is currently created.
My intention is to give different roles (product manager/warehouse employee) different interfaces.
I think a guy in the warehouse normally doesn't change the product details and the product manager doesn't touch the inventory. That's the reason why I introduced a new right for managing inventory, too.
For shops having just one warehouse the functionallity remains the same. Smaller shops normally don't split the roles. But if a shop has several warehouses normally thats reallity in my opinion.
There is an option to move the tab content to the info tab, too. I like to get your opinion - so feedback is welcome.
Best regards
Jörg
Certified Developer
- 189
- 2395
- 2/9/2013
- United States
First, let me start by saying...great job hubix2000 !
I have installed an gone over the fork and so far this is looking very good. Below are some thoughts.
To start, your idea on segmentation with security between warehouse worker and manager makes sense.
The purpose of inventory control and warehouse support will provide the underpinning framework to do some very advanced functions and features. One on the current roadmap is the Rental product support. I am trying to use this "use case" to guage if were hitting the mark;
Basic scenario... Car Rental agency with 4 car lots (warehosues).
The owner owns 10 honda civics (all identical). Thus we have 10 identical SKU's (stock keeping unit) as there is no variation in attributes.
I place 4 in lot 1, 2 in lot 2, 2 in lot 3, and 2 in lot 4
Now, your implementation so far allows for this scenario...and from your fork perspective this may be enough.
But...in the real world of inventory (handling returns, etc...) a unique identifier is required. This is where serialized inventory comes into play. Should a car need service after its been rented, etc... a VIN (vehicle identification number) is required which is equivalent to a serial number.
I could use almost any example...say your renting generators for homes. If a generator comes back after being rented and needs service... when you the shop owner talk to the manufacturer...they are going to ask you for the serial number...not the model (sku)...as we need to be specific as to "which one" of the identical generators you rent needs service.
So again, not sure if this should be done after your fork is merged...just needs to happen before Rental product support can be added... this implementation fork is a pre-requisite.
Once done, it could be possible to apply a discount to a specific product (a scratched table) could be sold at a discount at warehouse 2, whereas all other tables (ones with the same sku) would be regular price. List of possibilities is endless here.
So...1 more table that is simply (productId and or SKU, warehouseLocationId, serial (unique identifier)) can be related to your productInventory table. The # of quantities in your productinventory table should match the number of corresponding lines/rows in this new table.
eg. if you have 2 skus, in 2 warehouses in your productinventory tale, we should have 2 unique rows in this new table ... may as well call it SerilizedInventory.
Does all this make sense? And again...great job thus far!
I have installed an gone over the fork and so far this is looking very good. Below are some thoughts.
To start, your idea on segmentation with security between warehouse worker and manager makes sense.
The purpose of inventory control and warehouse support will provide the underpinning framework to do some very advanced functions and features. One on the current roadmap is the Rental product support. I am trying to use this "use case" to guage if were hitting the mark;
Basic scenario... Car Rental agency with 4 car lots (warehosues).
The owner owns 10 honda civics (all identical). Thus we have 10 identical SKU's (stock keeping unit) as there is no variation in attributes.
I place 4 in lot 1, 2 in lot 2, 2 in lot 3, and 2 in lot 4
Now, your implementation so far allows for this scenario...and from your fork perspective this may be enough.
But...in the real world of inventory (handling returns, etc...) a unique identifier is required. This is where serialized inventory comes into play. Should a car need service after its been rented, etc... a VIN (vehicle identification number) is required which is equivalent to a serial number.
I could use almost any example...say your renting generators for homes. If a generator comes back after being rented and needs service... when you the shop owner talk to the manufacturer...they are going to ask you for the serial number...not the model (sku)...as we need to be specific as to "which one" of the identical generators you rent needs service.
So again, not sure if this should be done after your fork is merged...just needs to happen before Rental product support can be added... this implementation fork is a pre-requisite.
Once done, it could be possible to apply a discount to a specific product (a scratched table) could be sold at a discount at warehouse 2, whereas all other tables (ones with the same sku) would be regular price. List of possibilities is endless here.
So...1 more table that is simply (productId and or SKU, warehouseLocationId, serial (unique identifier)) can be related to your productInventory table. The # of quantities in your productinventory table should match the number of corresponding lines/rows in this new table.
eg. if you have 2 skus, in 2 warehouses in your productinventory tale, we should have 2 unique rows in this new table ... may as well call it SerilizedInventory.
Does all this make sense? And again...great job thus far!
Certified Developer
- 189
- 2395
- 2/9/2013
- United States
Just one more quick point around what we are calling "shelf" support. This level of control is what the original work item for inventory control and warehouse support called for (11867). I just didn't call it "Shelf" support... I only described the primary use case of what it could be used for...similar to above. And as of now, it is still on the 3.5 roadmap.
Thanks
Chuck
Thanks
Chuck
Certified Developer
- 189
- 2395
- 2/9/2013
- United States
Hi Jorg,
I was thinking further about the overall approach here, and there is one thing that is bugging me a bit and I want to get your opinion.
Presently, ProductInventory has a foreign key relationship to Product (based on your productInventoryMap). This scenario makes sense except for when we enter the world of combinable products where the sku combination is more important than the generic productId that it belongs to.
Did you consider creating the relationship against the sku in productvariantattributecombinations instead of Id in Product? To me this makes more sense. Effectively what we want is to extend the inventory functionality to only products with specified sku's to create the possibility of covering both simple and any combinations of skus for a product.
If we go back to a similar scenario in the thread above where a store is selling generators, the engine size would be the attribute that causes the sku variant. It is really at this level where we want to track at what warehouse the "specific" product type is. So Product Id = 1 is a the generator with a default size of 200cc for example. This product has a base sku of "A000". There are 3 engine upgrades, 300 cc, 400 cc, and 500 cc resulting in skus like A001, A002, and A003 that live in the combination table. If I am storing my generators in multiple warehouses, I am only interested in "how many" specific types I have.
So, lets think about the advantages of creating the relationship at this level (sku) instead of product Id. Of course, this particular post is only about the "type" of product which is what the sku's represent (eg. I have two 300 cc generators at warehouse 2, and three 300 cc generators are warehouse 3). We still have the other decision about introducing serialized inventory so we can know which two generators are at warehouse 2 and which are at warehouse 3.
Looking forward to your thoughts.
I was thinking further about the overall approach here, and there is one thing that is bugging me a bit and I want to get your opinion.
Presently, ProductInventory has a foreign key relationship to Product (based on your productInventoryMap). This scenario makes sense except for when we enter the world of combinable products where the sku combination is more important than the generic productId that it belongs to.
Did you consider creating the relationship against the sku in productvariantattributecombinations instead of Id in Product? To me this makes more sense. Effectively what we want is to extend the inventory functionality to only products with specified sku's to create the possibility of covering both simple and any combinations of skus for a product.
If we go back to a similar scenario in the thread above where a store is selling generators, the engine size would be the attribute that causes the sku variant. It is really at this level where we want to track at what warehouse the "specific" product type is. So Product Id = 1 is a the generator with a default size of 200cc for example. This product has a base sku of "A000". There are 3 engine upgrades, 300 cc, 400 cc, and 500 cc resulting in skus like A001, A002, and A003 that live in the combination table. If I am storing my generators in multiple warehouses, I am only interested in "how many" specific types I have.
So, lets think about the advantages of creating the relationship at this level (sku) instead of product Id. Of course, this particular post is only about the "type" of product which is what the sku's represent (eg. I have two 300 cc generators at warehouse 2, and three 300 cc generators are warehouse 3). We still have the other decision about introducing serialized inventory so we can know which two generators are at warehouse 2 and which are at warehouse 3.
Looking forward to your thoughts.