Hello,
We have used NopCommerce several times, versions 1.90, 2.20 and 2.40. Most of the sites we build are for physical shops that have the Products in-stock and therefore the stock management functionality is very important to them. Most aspects of Nop both we and the client really like, but the Stock Management Functionality truly lets the solution down - there is also a huge difference between the functionality when managing stock by Variant versus by Product Attributes. I would like to suggest the following improvements:
1) There should be a field for "Back in stock timescale". This would allow the Administrator to enter a value in day/weeks/months that would indicate how long it would take to be back in stock. From an Customer's point of view, if an Item was out of stock the message could say something like "Out of Stock, available in 10-14 days". This should be available when managing stock by Variant or by Product Attributes.
2) The "Minimum Stock Quantity" field should be available when managing stock by either Variant or by Product Attributes. I would suggest that this is still set at the Variant level, so therefore each of the product attribute combinations uses the same "Minimum stock quantity" value.
3) The "Low Stock Activity" field/functionality should be available when managing stock by either Variant or by Product Attributes. Again, I would suggest that this field is still set at the Variant level. Only when Nop detects that every Product Attribute Combination within a variant has a stock level of Zero would it either Disable the Buy button or Disable the Wishlist button.
4) The "Notify Admin for Quantity below", "Back Orders" and "Allow back in stock subscriptions" field/functionality should be available when managing stock by either Variant or by Product Attributes. Again, I would suggest that this field is still set at the Variant level.
5) If the Option is selected to Manage Stock by Product Attributes it should not be possible to Save the variant without every possibly combination of Product Attributes having been added to the system. For example, Sizes (8, 10, 12) with Colours (Red and Blue) would require 6 entries (8, 10, 12 for Blue and 8, 10, 12 for Red). This ensures two things - if the administrator accidentally forgot to add a particular combination it still ensures that a Customer cannot buy it. Otherwise it is a half hearted effort at managing stock. I would suggest a Button within the Product Attribute Combinations screen labelled Pre-Populate. This would create an entry for every possible combination leaving the Administrator only to have to update the Stock Levels.
6) Currently there is an option to Disable the Buy Button/Unpublish the product if an item goes out of stock. If you add stock back for a particular product Nop does not automatically Republish/Re-enable the buy button. I can understand the logic why (we may have unpublished the product or disabled the buy button for another reason), however there is a place that this creates a problem. e.g:
A Customer places an order for a Product that only has 1 left in-stock. The customer reaches the Confirm page and clicks "Go to payment" (i.e. via WorldPay/Paypal etc). At this point Nop creates an order for that Customer, minuses 1 from the stock count - this would mean that the stock count is now zero. If the Variant was set to "Disable the buy button" or "Unpublish the product", Nop will now do this. For whatever reason, the Customer does not complete the purchase and therefore in reality we should still have a Qty of 1 left in stock. Later that day the Administrator cancels the order - Nop re-adds the Qty of 1 to the stock level for the product the Customer purchased, but it does not Re-enable the buy button or Re-publish the page. That's a massive problem, because currently we are saying if an Administrator Cancels an order they must go back into the product variant and check if its unpublished/disabled.
My suggestion would be that when an order is cancelled a dialog window should appear with the following options (for each product in the order)
- Do you want to want to re-allocate stock for Product N? Yes/No
- [Product N appears to be un-published, would you like to re-publish? Yes/No]
- [The "Buy Now" button for Product N appears to be disabled. Would you like to re-enable? Yes/No]
The reason I have added the question "Do you want to re-allocate stock for Product N" is because that the system shouldn't automatically re-allocate the stock just because the order is being cancelled. If the Customer purchased the goods and they were faulty and wanted a refund the Store owner may well decide not to recover their goods, so it can't be assumed they will always come back into stock.
7) Back in stock subscriptions should not require the Customer to register. I would suggest that we remove the requirement to register and simply store an email address and possibly name. For users that are already registered and logged-in, we can pre-populate the form fields for email/name. Yes, ok we are duplicating data her by storing an additional entry for the customers name and email, but we are doing so to make the process far more user friendly, and frankly we are only storing a few bytes per customer.
8) The Low stock report should contain both variants where the Stock is managed at the variant level, or by product variant attributes.
9) All triggers/events i.e. back in stock subscriptions, admin notification when stock below "Minimum stock level" etc should be triggered in both scenarios.
The list above does no-doubt represent a considerable amount of work, however I believe it will:
- Increase it's suitability for larger clients
- Increase it's suitability for client's with slightly more complicated stock management requirements i.e. by product attributes (this is very common offline in high street shops that manage stock by colour, by size etc)
- Make it far easier to integrate with external stock management applications
- Make it a far more comprehensive eCommerce platform
I have seen so many comments on the forums about the stock management. If anyone else has any suggestions it would be a good idea to roll them into the same ticket. I am going to open a work request on CodePlex, if I can get enough support from the community. IF YOU FEEL THIS IS BENEFICIAL TO NOPCOMMERCE PLEASE VOTE.
Nop team - appreciate you taking the time to read this and hopefully providing back your thoughts/reactions.
Thanks in advance
Al
SUGGESTION: Improvements to Stock Handling
- 1
- 2
MVP
Silver Solution Partner
- 5236
- 49495
- 10/4/2010
- Mexico
Hi Al:
You have pointed some of the key issues in inventory management which is one of the top weaknesses Nop against its competitors. So here are my 2 cents:
- SKU (Stock Keeping Unit) should be included in both variants and variant attributes.
- Here are two options for handling stock management in a more efficient and flexible way:
Option 1) Handle all stock control properties (Stock quantity, Display stock availability, Display stock quantity, Minimum stock quantity, Low stock activity, Notify admin for quantity below, Backorders, Allow back in stock subscriptions) in an independent table for both variants and variant attributes linked by the SKU. In this way most processes and reports could be programatically standardized. So, for inventory control, an SKU will be defined for each attribute combination/variant (this workitem for v2.8 will be of great help) instead of the stock control properties. The new table could include some other properties such as an image for keeping a photo or color swatch of the variant/combination. With this option an SKU could be associated other type of attributes which are also sold independently, such as add-ons or accessories of the product and have stock control for both situations: when they are sold independently or added to a product as an attribute.
Option 2) Do not use variant attribute combinations for handling variations or versions of products; instead each combination should be handled as a variant of the product. So if a shirt is sold in 6 sizes and 5 colors and all are available the product should have 30 variant. This is the way other cart applications (such as Magento) handle product with variations/versions. In this case, for each product the folowing settings are necessary: defined as "Product with combination attributes" (or alike), which are the combination attributes (example size and color -no more than 5 are necessary) and the way they are going to be displayed in the product details page (drop-down/radio-button list). In each variant the values of each of its combination attributes should be defined. Under this option product variant attributes can still be used for other accessories or options of the product. The copy product variant functionality can be very useful in this case.
This second option gives more flexibility for many situations. Example: images or color swatches, discounts for some less demanded combinations, bulk editing, etc.
You have pointed some of the key issues in inventory management which is one of the top weaknesses Nop against its competitors. So here are my 2 cents:
- SKU (Stock Keeping Unit) should be included in both variants and variant attributes.
- Here are two options for handling stock management in a more efficient and flexible way:
Option 1) Handle all stock control properties (Stock quantity, Display stock availability, Display stock quantity, Minimum stock quantity, Low stock activity, Notify admin for quantity below, Backorders, Allow back in stock subscriptions) in an independent table for both variants and variant attributes linked by the SKU. In this way most processes and reports could be programatically standardized. So, for inventory control, an SKU will be defined for each attribute combination/variant (this workitem for v2.8 will be of great help) instead of the stock control properties. The new table could include some other properties such as an image for keeping a photo or color swatch of the variant/combination. With this option an SKU could be associated other type of attributes which are also sold independently, such as add-ons or accessories of the product and have stock control for both situations: when they are sold independently or added to a product as an attribute.
Option 2) Do not use variant attribute combinations for handling variations or versions of products; instead each combination should be handled as a variant of the product. So if a shirt is sold in 6 sizes and 5 colors and all are available the product should have 30 variant. This is the way other cart applications (such as Magento) handle product with variations/versions. In this case, for each product the folowing settings are necessary: defined as "Product with combination attributes" (or alike), which are the combination attributes (example size and color -no more than 5 are necessary) and the way they are going to be displayed in the product details page (drop-down/radio-button list). In each variant the values of each of its combination attributes should be defined. Under this option product variant attributes can still be used for other accessories or options of the product. The copy product variant functionality can be very useful in this case.
This second option gives more flexibility for many situations. Example: images or color swatches, discounts for some less demanded combinations, bulk editing, etc.
- 117
- 1143
- 9/19/2011
- United Kingdom
Hi,
Andrei - thanks for creating the Work Item. Could I just ask, how do you prioritise Work Items? I know there is a voting system, but is this used?
Eduardo - thanks for your feedback. I agree that the stock options could be stored in one place, but using the current modelling of NopCommerce variants I dont see anything wrong with just storing the options against the variant - attribute combinations can only belong to a variant after all. If they were stored in a seperate table as you suggest, I wouldnt necessarily want to see them linked to an SKU - you would be amazed how many clients we have that dont work with SKU's. I have a client that takes around 10,000 orders per month on our Nop Solution, and they dont use SKU's!!!!
I do however totally agree with your point about the setup of variants and attributes in Nop. In no other system have I seen variants modelled in such a way - to this day I struggle to get my head round the reason for designing them like that, and with every client I have demo'd the system to, explaining why there is a product, a variant, and then attributes has always been extremely confusing. I personally, and in-line with almost every other system (whether it be an online ecommerce system, and in-house stock management system, or POS) would like to see A Product, and then if there are options such as Size, Colour etc, those being listed as the variants - with the possibility of storing an SKU against those. Whilst the design is as it is, Nop will always struggle to be integrated with other offline systems, because Nop's model is quite unusual.
I have asked this question several times in the past and the response has always been it's more flexible. I personally don't agree because I dont think many people that use Nop use more than 1 variant per product, and if that is the case, it does nothing more than make it confusing for end-users and deters system-integrators from integrating Nop with their systems.
Seeing as Andrei is already in this post, perhaps he would be kind enough to comment?
Regards,
Al
Andrei - thanks for creating the Work Item. Could I just ask, how do you prioritise Work Items? I know there is a voting system, but is this used?
Eduardo - thanks for your feedback. I agree that the stock options could be stored in one place, but using the current modelling of NopCommerce variants I dont see anything wrong with just storing the options against the variant - attribute combinations can only belong to a variant after all. If they were stored in a seperate table as you suggest, I wouldnt necessarily want to see them linked to an SKU - you would be amazed how many clients we have that dont work with SKU's. I have a client that takes around 10,000 orders per month on our Nop Solution, and they dont use SKU's!!!!
I do however totally agree with your point about the setup of variants and attributes in Nop. In no other system have I seen variants modelled in such a way - to this day I struggle to get my head round the reason for designing them like that, and with every client I have demo'd the system to, explaining why there is a product, a variant, and then attributes has always been extremely confusing. I personally, and in-line with almost every other system (whether it be an online ecommerce system, and in-house stock management system, or POS) would like to see A Product, and then if there are options such as Size, Colour etc, those being listed as the variants - with the possibility of storing an SKU against those. Whilst the design is as it is, Nop will always struggle to be integrated with other offline systems, because Nop's model is quite unusual.
I have asked this question several times in the past and the response has always been it's more flexible. I personally don't agree because I dont think many people that use Nop use more than 1 variant per product, and if that is the case, it does nothing more than make it confusing for end-users and deters system-integrators from integrating Nop with their systems.
Seeing as Andrei is already in this post, perhaps he would be kind enough to comment?
Regards,
Al
MVP
Silver Solution Partner
- 5236
- 49495
- 10/4/2010
- Mexico
Thanks Andrei. I hope the community would vote and discuss this suggestions. This features are very important in e-commerce since now the most demanded category in the web is clothes and accessories (above electronics, computers, and travel). Other important categories in e-commerce are office supplies and tools and hardware which also handle colors, sizes, etc. All require advanced features for variants: display effects, selection, stock control, etc.
Hi Al:
We also have found that several merchants do not have SKU's but we encourage and sometimes force them to use them because it is a good practice (no matter if its very simple, such as composed by a sequential product code followed with suffixes for the sizes (S, M, L, X,... ), color intitials(REd, WHite, BLack, ...)) if you want to upload/download data form/to Excel or ERP or stock management applications.
The attribute model is a simple and powerful functionality for: (A) product configuration (i.e. Build your own computer) and (B) handling simple cases for management of product variations/versions, in place of the variants model. My guess (Andrei would later tell us the true story) is that when developing Nop from zero the attribute model was taken for both and is was quite suitable for small/simple stores and the variants model was left aside. Then when demand for stock management of product variations arose it was included within the attributes model and we ended up handling stock in 2 very different environments, which originates the problems you point in your suggestions 2, 3 4, 8... If Nop wants to continue using the attributes model for both (A and B) purposes then it makes sense to handle it with Option 1, in my previous post.
I agree with you and find that for (B) the variants model described in Option 2 is more appropriate.
Hi Al:
We also have found that several merchants do not have SKU's but we encourage and sometimes force them to use them because it is a good practice (no matter if its very simple, such as composed by a sequential product code followed with suffixes for the sizes (S, M, L, X,... ), color intitials(REd, WHite, BLack, ...)) if you want to upload/download data form/to Excel or ERP or stock management applications.
The attribute model is a simple and powerful functionality for: (A) product configuration (i.e. Build your own computer) and (B) handling simple cases for management of product variations/versions, in place of the variants model. My guess (Andrei would later tell us the true story) is that when developing Nop from zero the attribute model was taken for both and is was quite suitable for small/simple stores and the variants model was left aside. Then when demand for stock management of product variations arose it was included within the attributes model and we ended up handling stock in 2 very different environments, which originates the problems you point in your suggestions 2, 3 4, 8... If Nop wants to continue using the attributes model for both (A and B) purposes then it makes sense to handle it with Option 1, in my previous post.
I agree with you and find that for (B) the variants model described in Option 2 is more appropriate.
Team Member
- 16639
- 156220
- 10/22/2008
- Armenia
higgsy wrote:
Yes. Number of votes matters but not always. Any approved bug has the maximum priority no matter of votes. The understanding of what is really required also matters. Furthermore, not all forum members use this voting system but I know what is discussed and requested on these forums for months or years (I read absolutely all topics here). Some work items are very demanded (e.g. multi-store) but they are quite large (good implementation could take months) and will be started later. So there's no any certain criteria how to prioritize work items.
higgsy wrote:
No =(( It requires a lot investigation and I haven't decided on it yet. Still thinking about better approach.
Andrei - thanks for creating the Work Item. Could I just ask, how do you prioritise Work Items? I know there is a voting system, but is this used?
Yes. Number of votes matters but not always. Any approved bug has the maximum priority no matter of votes. The understanding of what is really required also matters. Furthermore, not all forum members use this voting system but I know what is discussed and requested on these forums for months or years (I read absolutely all topics here). Some work items are very demanded (e.g. multi-store) but they are quite large (good implementation could take months) and will be started later. So there's no any certain criteria how to prioritize work items.
higgsy wrote:
Seeing as Andrei is already in this post, perhaps he would be kind enough to comment?
No =(( It requires a lot investigation and I haven't decided on it yet. Still thinking about better approach.
- 117
- 1143
- 9/19/2011
- United Kingdom
Hi Andrei,
Thanks for the clarification. I do think the voting feature should have a greater influence on the priority of work items - this really is key to the success of an open-source project. I'm sure you are overloaded with work and have many other things to think about, so I'm not suggesting there is any quick fix, but I do think it's something you should look at when you have the chance.
I'm also very glad to hear that you are at least considering the modelling of products/variants. You mention it will require a lot of investigation, why don't you break that investigation up into tasks and ask the community to help? I would certainly be willing to invest time in this. My email is al AT dotcentric.co.uk if you want to discuss.
Regards,
Al
Thanks for the clarification. I do think the voting feature should have a greater influence on the priority of work items - this really is key to the success of an open-source project. I'm sure you are overloaded with work and have many other things to think about, so I'm not suggesting there is any quick fix, but I do think it's something you should look at when you have the chance.
I'm also very glad to hear that you are at least considering the modelling of products/variants. You mention it will require a lot of investigation, why don't you break that investigation up into tasks and ask the community to help? I would certainly be willing to invest time in this. My email is al AT dotcentric.co.uk if you want to discuss.
Regards,
Al
MVP
Silver Solution Partner
- 5236
- 49495
- 10/4/2010
- Mexico
UPDATE
The suggestion by Andy (https://www.nopcommerce.com/boards/t/20764/product-picture-mapped-to-attribute-option-value.aspx) could be useful for Option-1 above
The suggestion by Andy (https://www.nopcommerce.com/boards/t/20764/product-picture-mapped-to-attribute-option-value.aspx) could be useful for Option-1 above
MVP
Certified Developer
- 2143
- 22251
- 7/23/2009
- India
higgsy wrote:
I agree with you... and also like your suggestions to involve the community to help. This is very important for any opensource project.
Hi Andrei,
Thanks for the clarification. I do think the voting feature should have a greater influence on the priority of work items - this really is key to the success of an open-source project. I'm sure you are overloaded with work and have many other things to think about, so I'm not suggesting there is any quick fix, but I do think it's something you should look at when you have the chance.
I'm also very glad to hear that you are at least considering the modelling of products/variants. You mention it will require a lot of investigation, why don't you break that investigation up into tasks and ask the community to help? I would certainly be willing to invest time in this. My email is al AT dotcentric.co.uk if you want to discuss.
Thanks for the clarification. I do think the voting feature should have a greater influence on the priority of work items - this really is key to the success of an open-source project. I'm sure you are overloaded with work and have many other things to think about, so I'm not suggesting there is any quick fix, but I do think it's something you should look at when you have the chance.
I'm also very glad to hear that you are at least considering the modelling of products/variants. You mention it will require a lot of investigation, why don't you break that investigation up into tasks and ask the community to help? I would certainly be willing to invest time in this. My email is al AT dotcentric.co.uk if you want to discuss.
I agree with you... and also like your suggestions to involve the community to help. This is very important for any opensource project.
- 1
- 25
- 9/13/2010
- United States
I own a site and we do use multi variant attributes. Sporting Apparel business. (Color and Size attibutes) We really like NOP. However our presesent set up of where Nop cannot manage out of stock situations for us by product attribute. Is a big issue on two fronts:
1) Our Customers Play a guessing game as to what we may have instock and the items that are not instock. Only after a customer attempts to place an item in the cart a message "out of Stock" pops up. This is not a great situation and not standard for an apparel business.
2) Lots of manual administration work for us - we must manually review items that are not instock and then navigate back to the product attribute section and mannually eliminate attributes that are not instock. Had we realized that Nop was not able to mange out of stocks in an more automated way we probably would have selected another option.
Do any of you know of any examples of customization option for NOP that is quick in the product detail page -- showing only the size attributes that are instock or where the allow out of stock box has been checked?
For us to continue with Nop We really need a solution for this. Manually going back and trying to eliminate size attributes is not a great thing for growing a business in an organized manner. Please send me a message if you have an example site where you have fixed this. Also We are using version 1.9.
Thanks
Matt
1) Our Customers Play a guessing game as to what we may have instock and the items that are not instock. Only after a customer attempts to place an item in the cart a message "out of Stock" pops up. This is not a great situation and not standard for an apparel business.
2) Lots of manual administration work for us - we must manually review items that are not instock and then navigate back to the product attribute section and mannually eliminate attributes that are not instock. Had we realized that Nop was not able to mange out of stocks in an more automated way we probably would have selected another option.
Do any of you know of any examples of customization option for NOP that is quick in the product detail page -- showing only the size attributes that are instock or where the allow out of stock box has been checked?
For us to continue with Nop We really need a solution for this. Manually going back and trying to eliminate size attributes is not a great thing for growing a business in an organized manner. Please send me a message if you have an example site where you have fixed this. Also We are using version 1.9.
Thanks
Matt
- 1
- 2