Just trying to put my head around and understand the issue and list potential solutions.
How do backorders work today?
enabling or disabling backorders is done at instance level
if enabled it means stock levels can go into the negatives
if disabled it means it can’t so when shoppers buy and stock is reaching 0 it’s not possible to order this product anymore, and will disappear from shop
ALL INSTANCES today have disabled backorders.
How “on demand” works today?
a hub manager can tell for each variant of a product if the available stock is fixed or infinite (= on demand)
ALL INSTANCES have disabled backorders and hub managers who want to allow orders beyond stock level click on “on demand” but then it means the don’t manage stock anymore. A lot of users actually do today, few users apparently use the stock on hand to manage their stock level within OFN.
How Spree evolves?
got rid of “on demand”
moved “allow backorders” at stock item level, so variant level
Some input from product chain model inception work
In this when we imagined how stock info would be treated, we imagined the stock of a product going negative, then the hub sourcing the product so the product reaching it’s catalog and the stock going back to 0 (I won’t reexplain fully, check this other post to understand).
Possible solutions after Spree got rid of on-demand?
1- Option 1:
get rid of on-demand
allow backorder enabled by default for all variants (=on-demand checkbox checked by default for any new product, proposal = rename “can be ordered beyond stock” to be more precise) >TO BE DISCUSSED. If most hubs setup products to on demand it seems logical.
AND enable a hub to prevent ordering a product beyond stock level (override backorder setup) by unchecking the “on-demand” (renamed “can be ordered beyond stock”) checkbox.
So basically we could keep exactly the same UX for our users but just change what the system does bellow, which is good:
if “on demand” (renamed “can be ordered beyond stock”) is checked for a variant the stock level on hand remains (can be 0 or hub can specify a current stock) but backorders are allowed, so when orders are placed, stock will go to -10 for instance of 0 and 10 ordered, then when producer delivers hub, hub stock will go back to 0.
if “on demand” is unchecked it means the “allow backorders” info has been disabled for that variant (only for my own hub, can be overriden in inventory) so in my hub if a customer tries to order beyond stock on hand quantity she gets an error message, and if stock reaches 0 it disappears from shop.
Hey Myriam, thanks for putting this all together! Sounds good!
Option 1 will fit well with what’s in Spree 2. No problem.
For simplicity in the UX, can we make the “on_demand” concept disappear completely and keep the concept “backorderable” (or “allow backorders”) like in Spree?
I understand and agree with your descriptions, just one doubt:
if “on demand” is unchecked it means the “allow backorders” info has been disabled for that variant (only for my own hub, can be overriden in inventory) so in my hub if a customer tries to order beyond stock on hand quantity she gets an error message, and if stock reaches 0 it disappears from shop.
I understand “if “on demand” is unchecked it means the “allow backorders” has been disabled for that variant … and… if stock reaches 0 it disappears from shop.”
I dont understand the case where it’s overridden in inventory and the customer gets an error. VariantOverrides will also be backorderable or not, and that will make variant appear or disappear from the shop according to that config (backorderable or not) and its stock, I dont understand the “customer gets an error scenario”. Is the customer currently getting an error in some particular scenario related to this?
Yes @luisramos0 that’s it, maybe my phrasing was not super clear
What I meant with “error message” was that if a customer put some products in cart, but meanwhile they are ordered, when she tries to checkout she will get some error message saying some products have become unavailable.
Good to know that “backordability” can be overriden
The “allow backorder” concept for me is unclear, we should ask some English speaking people, @Kirsten@sstead@tschumilas would that be ok if on product the “on demand” checkbox was called “allow backorders”, or “backorders enabled” or something with “backorder” in it? This concept doesn’t exist in French so I would translate in French “can be ordered beyond stock” or “unlimited quantity available” or something like that… but maybe the concept is clear enough in English and can be used? And maybe for clarity of what it will actually do it’s better to rename and not stick to current “on demand”. So how would you rename?
for me the term ‘backorder’ is something a bit different from ‘unlimited quantity available’. When something is ‘on backorder’ - it means (to me) that the producer does not have anymore of the item - the seller/hub and the customer are waiting for the producer to make more. Backorder usually comes with an estimated availabiliity date. For ex - I have strawberry jam on backorder - won’t be available until more organic strawberries can be found - could be months. But I think the concept of ‘on demand’ is different - a producer is able to make/grow/deliver any amount of the item - because they have the ingredients, landbase, … to do so. So I think we want ‘unlimited quantity available’ here - not the term backorder.
@luisramos0 quick question: if I have a stock on hand of 30 of a variant and backorder is allowed for that variant, does the quantity on hand remain or is it overriden by the backorder info? I guess quantity remains and when the 30 are sold it can be ordered beyond and quantity becomes negative then.
Given @tschumilas feedback I suggest we let the En-master version decide of the term used to replace “on demand” and reflect correctly that behavior, and then every other language will translate as they want. But it seems the term backorder might not be the more adequate, even if that’s the one used by Spree. If that’s confusing maybe on En we can have something like “on-demand (backorders allowed)” or “can be ordered beyond stock (backorders allowed)”.
hey @MyriamBoure
I think this answers your question:
New products created in the system can be given a starting “on hand” inventory level. You can subsequently set new inventory levels and the correct things will happen, e.g. adding new on-hand inventory to an out-of-stock product that has some backorders will first fill the backorders then update the product with the remaining inventory count.
dictionary says backorders are orders against a temporarily out of stock item.
allow backorders would mean “allow orders against a temporarily out of stock item”, which is exactly what Spree does. I think we should keep it simple and keep the backorders term all over the internal system. If the translators want to use a different sentence or term (like “unlimited quantity available”), that’s fine.
Ok but we the En is the master default non translated local so if you keep “backorders allowed” term that’s what their users will see. So let’s see what Aus people say @Kirsten@sstead.
Sorry @MyriamBoure , I was not clear. When I say “internal system” I meant code. The default translation can still be something else. I just want to make sure we do not create an unnecessary concept in the code.
Ok sorry I misunderstood Then @Kirsten@sstead what do you want in default En local? That reflect maybe a bit better the new behavior than “on demand”? So that devs know what to put when implementing the solution.
I agree with Theresa. I prefer ‘unlimited’ to ‘backorders’.
If we are going to change ‘on demand’ would it also be a good time to improve ‘on hand’? To me this term is also not intuitive. Perhaps new default terms could be ‘stock level’ and ‘unlimited stock’. Or ‘units available’ and ‘unlimited units’. If the two terms match they’ll be more self explanatory.
Just a slight comment @sstead@Kirsten I’m afraid “unlimited stock” might be confusing with the new behavior. Reminder: you can have 30 in “stock level” AND check the checkbox “unlimited stock”, which formulated that way is a bit strange. You can handle BOTH a quantity on hand AND say that it is possible to order beyond that quantity. When I see “stock level” and “unlimited stock” I have the impression that it’s either one OR the other, but it’s not the case with the new behavior. I think it’s clearer to say “stock level” and “can be ordered beyond stock”, so if stock is 0 it means basically on demand, but if stock is something it means after that stock is sold people can still order. Keep in mind that now the stock will go negative, so if the hub doesn’t “resupply” the stock can go till -1000 for instance. So it will not behave exactly as “unlimited quantity”. Sorry I should have been clearer on that.
So if I have apples in an OC, and I check both ‘stock level’ and ‘unlimited stock’ or ‘stock level’ and ‘can be ordered beyond stock’ (whatever language we decide) - and buyers take all the ‘stock level’. The item stays visible in the shopfront - right? And so buyer #2 orders 3 units. In the backend, I presume I see a -3 somewhere. But - is there any communication to buyer #2 about when and where they get ther ‘can be ordered beyond stock’? This is what I’m missing. How does the messaging happen to the buyer about when and where their ‘can be ordered beyond stock’ units will be available? (it seems strange to me to have this option with a complementary option of telling the buyer when they’ll be available.)
Ah I see Myriam. In the new system I suppose it will be a) “Stock level” and b) “allow orders beyond stock level” or “restrict to stock level” . Sadly I can’t think of a more concise way to explain it- unless we put a generic term like “Restrict?” with tooltips.
@tschumilas I think the customer experience of purchasing the last +3 apples, or purchasing the apples that put stock to -3 would be no different. There’s no difference to the customer if they are buying stock that’s on hand, or stock that’s going into the negative in the backend. Is this right @MyriamBoure ?
That’s it @sstead ! Thanks for the clarification on the wordings as well. @luisramos0@sauloperez I think you have all you need for the upgrade on that part then
so @sstead - what would you do when someone places an order that goes beyond stock level. Would the hub communicate individually with the customer to tell them when they think the stock will be in? (I know this isn’t really the discussion - right now we just need to figure out the language for the feature) but I’m justing thinking ahead to the operational implications.
