How to correctly set an order fulfillment_status to "Default" using the API

GraphQL API
1

Hi guys,

Can someone help me understand this. In my current system all my orders come in with a “Waiting for merge” status (we did that with an automation rule). I then have a Python script that update that status to “pending” after 1 business day to give us time to merge the orders.

    while True:
        for order in sh.query_orders(match={"fulfillment_status": "Waiting for merge", "shop_name": "moi-dabord.myshopify.com"},
                                     sort=["+order_date"],
                                     data=["id", "shop_name", "order_number", "fulfillment_status", "order_date"]):
            # if expired change status
            order_datetime = datetime.strptime(order["order_date"], '%Y-%m-%dT%H:%M:%S')
            if datetime.utcnow() > (order_datetime + BDay(1)):
                __log__.info(f'Updating order {order["order_number"]}')
                sh.mutation_order_update(order_id=order["id"],
                                         data={"fulfillment_status": "pending"})

        __log__.info("Sleep for 30 minutes")
        time.sleep(1800)

The issue is that these orders do NOT appear in the packing app if I select “status: Default” in the dropdown.

Screen Shot 2021-06-07 at 15.28.20

It dosent appear in the picking app either.

It will show up in the packing app only IF i do it manually:

  1. Select all orders
  2. A bulk edit on all orders
  3. Update the status to Default

Am I setting the wrong status with the API? Should it be different than “pending”?

I tried “default”, “Default”, “unfulfilled” and it sets the status to “no status”. “pending” does change the status to “Default”, but only partially (a.k.a not for the packing app or the picking app)?

In other words, what’s the appropriate way to set an order status to “Default” using the API.

Any help would be appreciate!

Hans Daigle

2

Hi @hansdaigle!
Our apologies for the delayed response about this.

Do you happen to have a request ID of when you updated an order status using the Public API?
Then, with that information we can investigate further on our end to see why its not working.

Thanks in advance!
Tom

1 Like
3

Hi @tomasw, thanks for answering and of course, I can send you that.

I changed our workflow and we are now changing the status to “Ready” instead of “Pending” but we are getting the same bug.

Here some request id (same request id that were generated in the screen recording below):

{'data': {'order_update': {'request_id': '60c8d9e51ecaca96c4f25e9c', 'complexity': 10}}}
{'data': {'order_update': {'request_id': '60c8d9e6b129fff287aa2b38', 'complexity': 10}}}
{'data': {'order_update': {'request_id': '60c8d9e645abab8d272381a2', 'complexity': 10}}}
{'data': {'order_update': {'request_id': '60c8d9e6f7c047bf5d8f646b', 'complexity': 10}}}
{'data': {'order_update': {'request_id': '60c8d9e73ee0087d8f3d0f29', 'complexity': 10}}}

(Edited Video)

I tried to change where the statues were created, at the client level or at the 3PL level and same bug in every scenario.

This is the code I run to update the status using our custom python API:

resp = sh.mutation_order_update(order_id=order["id"], data={"fulfillment_status": "Ready"})

This is what the GraphQL query looks like:

mutation { order_update(data: { order_id: "T3JkZXI6MTk3MjIyOTM5" fulfillment_status: "Ready" } ) { request_id complexity } }
6

Hi @hansdaigle
Thank you very much for that detailed description of the issue and the video!
I edited it because it had some sensitive information (password) on the video, but we got that part so thanks! :ok_hand:

Allow us to do some troubleshooting and investigation regarding this and get back to you asap

1 Like
7

Hi again @hansdaigle
I think we might have found it :slightly_smiling_face:

Try using this Mutation to update the status instead:

mutation {
  order_update_fulfillment_status(
    data: { order_id: "<order_id>", fulfillment_status: "Ready" }
  ) {
    request_id
    complexity
  }
}

That should do the trick

8

Hi @tomasw,

Good catch for the password!

I updated my script with the new mutation and it’s working correctly now, thank you so much for the fix! Does that mean we shouldn’t update the order fulfillment_status using the order_update mutation?

This new mutation also creates 2 entries in the logs:

Screen Shot 2021-06-17 at 10.27.04
Screen Shot 2021-06-17 at 10.27.041883×157 12.9 KB

The first one is correct, but the second one is just empty.

9

Hey @hansdaigle !
Thanks for pointing that out. I will make a ticket for our engineers to remove that extra empty note.

Yeah I assume that the order_update_fulfillment_status is more specific and probably contemplates an “extra step” upon updating the order values, so I will ask internally, because maybe we want to remove the ability of updating the order status form the order_update mutation or fix it

10

Awesome, thanks for everything @tomasw!

2 Likes