Producer sets stock level = 0 for product but receives orders for items

[lbwright22]

Description

Issue reported by UK producer = Top Barn Harvest Shop which supplies JQ Hub - Slow Food Birmingham and Mercia Food Hub.

Top Barn Harvest Shop state they set stock level of all their tomatoes, pak choi and pak sum to Zero 01/11/20. There are no inventory overrides on the products. Since 1st November these orders have been placed in which one or more of the above products was included: R046662763 09-11-20 R265674324 13-11-20 R033815623 14-11-20 R111481767 15-11-20 R471366174 15-11-20 R546872511 15-11-20 R618122526 15-11-20 R666885725 15-11-20 R747870764 15-11-20 R760474188 15-11-20 R826621748 15-11-20 R831533483 15-11-20 R865626512 15-11-20 R107284215 16-11-20

There is no record (accessible to support) to verify that the producer stock levels were 0 at the time the orders were placed or if they mis-remembered the date. There is no record (accessible to support) to see if the above orders were placed in the backoffice (ie they might be an occurrence of issue #5989 or not.

Assume user error BUT similar occurrence of orders for out of stock products has been noted in Australia @emilyjeanrogers

Expected Behavior

Product stock level = 0 item can not be ordered and does not appear on the shop front

Actual Behaviour

case of user error: product stock level is not set to zero and hence item is ordered by customer -> no problem with the platform. Platform error: Product stock level = 0 Customer is able to purchase a non-zero quantity of this product (ie in /reports the item appears with quantity not equal to zero- different behaviour to issue #5300

Steps to Reproduce

Not sure what the steps would be here. 1. 2. 3. 4.

Animated Gif/Screenshot

Workaround

Severity

Your Environment

• Version used:
• Browser name and version:
• Operating System and version (desktop or mobile):

Possible Fix

[RonellaG]

This issue has occurred in Aus as well. On 13 Nov 2020 the manager of Wangaratta Farmers' Market Hub (2630) said that the manager of from Food Direct (3184) zeroed her items for WFMH order cycle but it didn't stick. The Food Direct manager said she had saved the command but she ended up with orders!

The Wangaratta Farmers' Market Hub order cycle is called "13th Nov Market 32" from 8 - 11 Nov (Order cycle 7130). Even though none of Food Direct's products were selected as Incoming Products in this order cycle, the order cycle suppliers total report showed these orders were made for Food Direct products through that order cycle.

On 13 Nov our system showed that the products for Food Direct were zeroed.

Wangaratta do use the inventory tool but not for Food Direct products.

[lbwright22]

This issue seems to have cropped up again. Hub: Slow Food Birmingham Producer: Sole Of Discretion Product: Live Mussels

Producer says they set the stock level to 0 for mussels mid Dec. Order received for mussels on 3rd jan. There is no product override in the inventory of Slow Food Birmingham

Mussel orders in the last month 06/12/20 14:43 SFB 07/12/20 06:41 SoD 07/12/20 10:37 SFB 10/12/20 18:31 SoD 11/12/20 18:18, 19:48, 20:22 TVFH 12/12/20 8:10 TVFH

03/01/21 13:00

These are consistent with the producer setting the stock level to zero mid Dec. The unexplained order is on 3rd Jan 2021

[lbwright22]

This appears to have occurred again: Hub: Slow Food Birmingham Producer: Top Barn Harvest Product: Asian Greens- Pak Choi

No product override in the inventory. Stock level at 0 (although no way of verifying this) Order placed for one pack 2021-01-02 19:52:45 Order ID R403853206

[lbwright22]

Hi all more instances of this issue cropping up: Hub: StroudCo Producer: Day's Cottage Products: Apple Juice and Gold Top Apple Juice

order Ids: R200516642 R255062880 R873322777 R664301463 R780674218 R578827324 R374118823 R664661745 R468818715 R028430754 Producer has the stock levels of the apple juice set to 0. Products are in the StroudCo inventory. StroudCo had stock levels = 0 BUT the inherit box was unchecked on all products which were sold mistakenly. I have re-checked the inherit box. Variants of the apple juice for which the inherit box in the StroudCo inventory was checked were not sold in the last few months (ie. the correct scenario occurred= stock was 0 and hence no sales).

[lbwright22]

Another instance: Sole of Discretion product mussels No inventory override for this product at all.

Order IDs R115446207

[andrewpbrett]

Thanks for the details @lbwright22. Do you know if any of the shops are using product import, or if they're setting the stock levels to 0 manually?

[lin-d-hop]

@andrewpbrett They are manually setting stock levels to 0. This is a constant and continuous problem for any producer manually setting stock levels to zero. This is not related to product import to my knowledge. (I thought I replied to this last week, sorry).

[andrewpbrett]

You did reply @lin-d-hop! On slack :)

[RachL]

hello @lbwright22 do you remember if you have managed to reproduce this one?

[lbwright22]

@RachL sorry, I wasn't able to reproduce. There were an awful lot of instances of it though in the UK. I can provide more examples if required.

[Matt-Yorkley]

Were the orders that reduced the stock below zero created by subscriptions?

[lbwright22]

@Matt-Yorkley no. No subscriptions for some of the hubs affected and the products weren't in subscriptions anyway

[lin-d-hop]

This is still being reported. It has a big impact on user trust in the system.

Can we escalate this? Cancelling and order and asking the user to refund a shopper is not really a suitable workaround.

[andrewpbrett]

I wasn't able to immediately reproduce this locally but there's clearly something buggy going on here.

Have we ever had someone report seeing a product in the shopfront even though it's currently "zero'ed out" in the product list? That would help to narrow it down if that's what's happening - however, I just tried loading a shop and adding a product to my cart, then changing the stock to 0 on the backend, and then checking out; it shows a message saying it's out of stock.

I'd have to guess that these orders are being created from front end shops, however, since I assume that the hub manager wouldn't be adding out of stock products to backoffice orders. And @lbwright22 already mentioned that there are no subscriptions involved.

So to bring out the 🦆 again:

It looks like there's a few places where we check if a given variant is in stock.

VariantStock and Quatifier both have can_supply?(quantity) methods that do essentially the same thing, looking at total_on_hand and on_demand/backorderable.

Similar to #7461, there's the possibility of a variant override changing the results of these methods; however, there seem to be quite a few of these cases where variant overrides are not present. So we can probably rule that out.

There's also the skip_stock_check flag, called from the sufficient_stock? method, but it looks like that's only in play with subscriptions. That method also uses the ScopeVariantToHub trick, but the Live Mussels product, for example, definitely doesn't have any VariantOverrides, so I don't think that's the cause.

I'm a bit stumped for now.... it may help, if a hub is willing to do so, to have them leave the out of stock item on the order temporarily so that we could download the database in that state and see if that gets us any further. It'd be up to @lbwright22 to coordinate that I think.

[lin-d-hop]

@lbwright22 After discussions this evening in Delivery Meeting we thought that perhaps this could be caused by the following:

• Hub finds out that the product is out of stock at the end of an order cycle
• They set stock to zero
• All orders for this item from the previous OC are then removed - qty_ordered = 0 for this item
• When the hub does this, stock for the item is readded to the available stock
• Next order cycle the item is then available for purchase again because the stock is > 0

Does this sound like a possible cause for this issue? To confirm this we need to understand the order in which hubs update the stock and remove item from orders. If done in the wrong order this would cause this bug.

If we can confirm this is the problem we can think about the best solution..... :thinking:

notabugafeature

[lbwright22]

I think there are two cases:

1. Users (not just in the UK) reported items being sold which were out of stock (last report was in Feb 2021). I am not aware of any other reports more recently.
2. Report from UK enterprise on Wed 21st April 2021 of the same thing happening.

Case 2 can be explained (and big apologies from the UK support team that we didn't thoroughly investigate) : the stock of the two items sold 'mistakenly' is '1'. Most likely the above theory is correct (stock set to 0, refund orders which returns stock, start of OC stock > 0)

Case 1 (possibly historical now??) The same items were sold even though they were out of stock more than one week in a row. I know for certain that with the SoD mussels (as well as some of the other products) that I saw the stock level was 0 on 5th Jan and yet the product was ordered on 12th Jan. Although I can't 100% disprove the theory (it is always possible since in each case the producers supply more than one enterprise and so people may refund/return stock to products at random times for historical orders) it isn't consistent with what I have observed.

Proposal: degrade this issue to S3 until there is another instance of it being reported (Case 1 hasn't cropped up for a couple of months- it may be historical)

ping @lin-d-hop @andrewpbrett

[Matt-Yorkley]

I wonder if this is partly a UX issue. Like: when a user is cancelling an order we could show a checkbox (checked by default) with a message like "Restock Items: return all items from this order to stock". That way it's clear what's happening, and there's an option to not restock the items, if that's not what the user wants to do.

Just thinking out loud...

[andrewpbrett]

I think it's fine to downgrade to S3.... if we are, in fact, showing products on the shopfront (and letting them be added to the cart and checkout) despite them having 0 stock and no inventory overrides, that would be a pretty concerning bug. It would also be really hard to catch and fix, since I imagine it would be really difficult to reproduce.

If it pops up again, we could look at adding at least some logging/Bugsnag calls to determine if the theory (that the products are having their stock level increased by canceled orders) is correct.

[lbwright22]

@Matt-Yorkley how difficult would it be to have a toggle option which allowed the user to choose between 'return items to stock' 'yes' and 'no'? (like with the shipping methods- if you change the method you can now opt to adopt the new fee or stick with the original) again, just thinking aloud... (ie. not urgent/not a priority)

[lin-d-hop]

This has not come up since April - and on that occasion it wasn't really this issue. I'm going to close this issue and we can reopen if we see it again.