fulfillable_quantity: 0 on initial webhook then changed

[Aaron_Rubin2]

I have seen this on multiple orders across 2 stores so far. The webhook comes in with "fulfillable_quantity":0. When I query later it's "fulfillable_quantity":1. 

"fulfillable_quantity":1 is correct.

Why is the initial webhook coming in with "fulfillable_quantity":0? 

[Aaron_Rubin2]

I have found this across multiple stores all happening on 3/1 and 3/2. Is this a known issue?

[Kevin_A]

@Aaron_Rubin2 

It could be this: https://help.shopify.com/en/manual/orders/fulfillment/fulfilling-orders/fulfill-your-own#fulfillment...

[Aaron_Rubin2]

@Kevin_A thanks for the response. The fulfillment_status was None not On Hold on those orders so it doesn't match that use case. I have logs of a few examples if you want me to share privately.

[Kevin_A]

Hey @Aaron_Rubin2 

If you could pass an order or fulfillment ID I would be happy to take a look. 

[Aaron_Rubin2]

Thanks. order_id 3648329351239. At Tue Mar 02 21:12:59.768059 2021 UTC it showed "fulfillable_quantity":0..."fulfillment_status":null
I have a few other examples from other stores on that day if needed.

[syf_]

Hey @Aaron_Rubin2,

Happy to throw some more light on this issue for you!

We rolled out a feature for fulfillment holds on March 1 but we reverted on March 2. I believe this might be consistent with your observations on March 1 and 2. 

For a fulfillment status being On hold, this is merchant-facing and is only available in the Admin. Currently the only way to determine if there is a fulfillment hold via APIs is the fulfillable_quantity being 0, with the reasoning being that there's nothing to be fulfilled, so fulfillment apps shouldn't do anything yet. An orders/update webhook is sent once the hold is released, and the fulfillable_quantity is set accordingly.

For the request ID you shared, there was an upsell on the order and that explains why the initial webhook sent had fulfillable_quantity=0, which in this scenario is expected behaviour.

Giving you a heads up that the fulfillments hold feature was rolled out again yesterday, so you might be seeing this behaviour a bit more.

Let me know if you have any additional questions or there's anything I could clarify for you.

Thanks,
Seth.

[Aaron_Rubin2]

@syf_ thanks Scott. We indeed saw it again this morning. 

Thanks for the clarification. We understand it is upsell causing it. What is tripping us ip that the fulfillment_status is null. We're expecting it to be on hold in this situation. It should have a fulfillment_status of on hold, correct? If you want a specific example, order id 3671623827623 showed "fulfillable_quantity":0 and fulfillment_status":null this morning. We logged about 500 orders with that same pattern this morning. Do you know why fulfillment_status isn't coming is on hold? Is there some other way we can reliably identify that it's a hold from an upsell?

I appreciate the help. We get in a couple hundred thousand orders a day so even though it's a small percent of the time where this is occurring, it's causing us a bit of pain.

[syf_]

Hey @Aaron_Rubin2,

I do understand that this is a bit confusing, and I'll try my best to clarify as much as I can.

The only valid values for the fulfillment_status are the four listed below as per our docs. No new value has been introduced to indicate a fulfillment hold. 

• fulfilled: Every line item in the order has been fulfilled.
• null: None of the line items in the order have been fulfilled.
• partial: At least one line item in the order has been fulfilled.
• restocked: Every line item in the order has been restocked and the order canceled.

The On Hold status is only seen on the Merchant's Admin dashboard, but the fulfillment_status field got via the Admin API would still be null, in addition to the fulfillable_quantity being 0. You could say that if an order hasn't been refunded, has fulfillment_status=null, and has fulfillable_quantity=0, then it is highly likely that there is a fulfillment hold on the order. This is the behaviour currently, and the team in charge indicated that if an order has fulfillable_quantity=0 then any fulfillment service should be doing anything with that order yet.

If you had any feedback or a use-case why this is pivotal, I could relay your concerns to the team.

Best,
Seth.

[Aaron_Rubin2]

@syf_ thanks Steve. I didn't realize that, I assumed the on hold would be reflected in the api response. Knowing that intentionally isn't there is helpful, thank you.

We have 2 issues.

The first is that prior to this roll out the fulfillable_quantity never increased without the quantity also increasing. We create the order on our side when we get a webhook even if there is no fulfillable quantity (we do so because our system is often used as the Order Management System for merchants customer services teams). When we create the order we have quantity X, fulfillable_quantity 0. When we get a webhook later the quantity is unchanged, so we don't check the fulfillable_quantity value as previously it wasn't possible that fulfillable_quantity changed and quantity didn't. Catching the scenario isn't terrible, we handle order editing which is more complex, but in the case of order editing we had advance notice and tested on a small number of stores over weeks before it was supported globally. This was unexpected.

The second is an active issue which we haven't figured out how to handle. We are responsible for insuring inventory isn't oversold across the merchants stores and channels. If we get a fulfillable_quantity and it's on hold we can handle that well. What we do in that case is reserve the stock but not release the order for shipping (we do the same for amazon currently - they hold all orders for a period of minutes before they are shippable, very similar to what is happening here). Today when we get a webhook with fulfillable_quantity of 0, how should we determine if we should hold the stock? A fulfillment_status of "on hold" would let us know how much stock to reserve and also let us know that the order isn't ready to be shipped. From my seat that gives us the most visibility and is the ideal option I can think of.

I appreciate you reading through the long post!

[syf_]

@Aaron_Rubin2 the hold feature has been rolled back and you should no longer be experiencing the issue.

That being said, it is likely to roll out again in the future so hopefully you can consider this scenario in your implementation. Also, the FulfillmentOrder API might surface some of the information you were interested in about the fulfillment_status.

If you had any more questions, please do let me know.

Best,
Seth.

[tjohnson1]

I know this old, but it seems this was implemented again and is causing issues.  Setting Fulfillable Quantity to 0, is the wrong solution.  Did you speak with existing customers before implementing this?  I have two alternative suggestions for implementing On Hold.  1) change the order's status as suggested above and leave Fulfillable Quantity as is.  2) Webhook Create shouldn't send orders where status is on Hold until they are not on hold.