Order_Create mutation, throttling, and closing without shipping

Hello,

For an internal process, I need to generate a large order (often 400+ SKUs) so that our warehouse can use their scanners for picking, but the final order will not be shipped anywhere. I guess you could call it an internal transfer combined with an inventory adjustment. (It’s staying in a single warehouse.) I would prefer to keep this as a single order as only one person will be picking it.

I have a number of questions about how this might work what the “gotchas” might be. First, my questions regarding the actual order creation:

  1. I know for queries, there’s hard limit of 100 results. Does the same thing apply to mutations? In other words, would I have to somehow “paginate” creating a huge order like this?

  2. Does the quota/throttling apply to mutations like it does for queries?

  3. If I do have to paginate or take throttling into account, what’s the best approach to creating this large order? Can I send the order_create mutation multiple times with the same order header info, but different line items?

Next, regarding the closing out of the order once the picking is completed, I have these questions:

  1. Once the picking is complete, in order to get it to “drop off” as an open order, I’m assuming that the order needs to be somehow finalized. Does an order need to be shipped in order to make this happen, or will marking it as fulfilled be enough to get it off the radar of the warehouse?

  2. If the order can just be marked as fulfilled, will that be enough to move the inventory out of the system, including out of allocated status?

I think that’s it. I know the second part isn’t strictly API related, so if there’s a better place to ask those questions, feel free to point me there.

Thanks,
Jeremy

Hi @jeremyw !

For the order_create mutation limit, we don’t have, and throttling should be the same as any other order_create mutation, but to be honest, I haven’t tried so many SKUs to provide a knowledgeable answer to this, I will need to do some testing first
Will you be doing this often?
Maybe if its a once in a while thing, you can upload a CSV at https://app.shiphero.com/dashboard/csv-management
Let me know if you still choose to create it through Public API so I can make some testing about it.

As for when the picking is completed, would you want to remove inventory as well?
In that case, you could manually fulfill it on the Order Detail page (I’m suggesting this because it’s only a button that says Set as Fulfilled and you can choose if you want to remove inventory or not, and might be faster)
But again, let me know if you still need to handle this using the Public API

Thanks in advance!
Tom

Hey @tomasw!

Thanks for the feedback. Regarding the second half about the “set as fulfilled” option, that should work perfectly. I wasn’t planning on doing that part via the API anyway, but it’s good to know that there is an option to keep the inventory removed when doing so.

For the order creation side, for right now I’ll need to do this about once a week. So, I guess it’s not a lot in terms of frequency at the moment, but if we get this to work, we have other tasks that we would like to use this for, and it would become at least a daily occurrence. Uploading the CSV is an option if we need to go that route (I didn’t even realize that existed!) but I wanted to try to limit the number of steps for the end user as much as I can.

This may be part of the question that you need to find out an answer to, but regarding the throttling, what would that look like as far as the actual mutation syntax I’d send? For example, to oversimplify it, let’s say that throttling only allowed me to upload 5 SKUs at a time. Uploading the first 5 is easy, but to get the next 5 into the same order, would I still use the order_create mutation with all the same order information (order number, shipping address, etc.) but just supply a new set of SKUs? Or should I instead send the subsequent groups of 5 via the order_add_line_items mutation?

Finally, regarding the large number of SKUs I want to have in the order, one other question I have is: is it practical to have 400+ SKUs in an order? For example, in Shopify we’ve previously run into issues with system sluggishness when the number of lines on an order hits around 250 or so, and it wreaks havoc on our export process. In ShipHero, would such a large order be problematic for, say, the “app” side such as the scanning software, or other places in the fulfillment process that I may not be aware of?

Thanks again!
Jeremy

HI @jeremyw!

That is correct, you will need to add the following 5 items using the order_add_line_items mutation.
I’m pretty sure you won’t get throttled, but you might get a timeout if the mutation is too long (I will test this asap and get back to you about this) So you might want to break it down to 50 or less SKUS for example (just to be sure)

For the app side, I’ve seen large orders, and they are not always slow and prone to timeouts, but most times they might be slow to load on Mobile devices for example, but to be honest, I haven’t seen many orders like this one (+400skus) so I would assume it is not a common scenario

I will let you know as soon as I’m able to test this

Thanks again!
Tom

1 Like

Hi @jeremyw !
So I’ve been doing some testing and it might be simpler than what I thought.
I just created an order with the order_create mutation for 400 line_items and it took 21 seconds to respond back with a success status, so you might not need to use the order_add_line_items mutation after all
Again, this is not a typical case, because orders usually have few line items, big orders like this one might experience some trouble afterwards (when scanning the items for example)
Let me know if there is anything else I could help you with!
Thanks again for the patience while I tested this out
Tom

Hey @tomasw!

Thank you so much for testing that. I really appreciate it. It’s good to know that the response time on creating the large order is quick like that. That sounds very hopeful, and it will definitely simplify the code.

Since you have the big testing order created, is there any way you could test the scanning of some lines on that order, and then marking it as fulfilled? I think those are last two open “what if” type questions on this.

Thanks,
Jeremy

Hi @jeremyw!
I tried with that same order and I did experience slowness when opening the order, not much, but slower than usual.
Scanning worked good, but a bit slow due to the number of line items involved.
I did manage to scan a few items and then set the order as fulfilled (using the Public API, with the order_update_fulfillment_status ) because the button on the UI for Set As Fulfilled times out when there are many items
Do you also want to remove stock as well for those line items?
Thanks again!
Tom

Hey @tomasw!

That is all excellent information. Yes, we do want to remove stock for those items.

I think the last question I have, again, doesn’t relate 100% to the API, so if there is a better place to ask it, please feel free to direct me there. My question is: in speaking with one of my coworkers who knows the day-to-day functionality of the system better than I do, they informed me that even if we did smaller orders, such as 100 line items each, and if they are all part of the same batch, the scanning software will still load all the lines at once. Do you think breaking up the one big order into the smaller orders of 100 line items will still result in the same slowness when it comes to scanning and picking if we group those orders into the same batch? I would assume it would help on the Set as Fulfilled process as there would be a much lower number of lines per order, but do you think it would it be enough to keep that button from timing out?

Thank you again for all of this incredibly helpful information! You are really helping us flesh out our process.

Have a great weekend,
Jeremy

Hi @jeremyw

I apologize for the delay.

My suggestion would be the smaller the better!, but I understand you may want to use larger orders, so I was able to run some tests and here is a recap of it

Order with 400 Items

  • Mutation: OK, No time out
  • Set as Fulfilled + remove inventory: Times out
  • Scanning on App: OK, minor lag

Order with 200 Items

  • Mutation: OK, No time out
  • Set as Fulfilled + remove inventory: OK, some lag, but works
  • Scanning on App: OK, no lag

Order with 100 Items

  • Mutation: OK, No time out
  • Set as Fulfilled + remove inventory: OK, no lag
  • Scanning on App: OK, no lag

Order with 10 Items

  • Mutation: OK, No time out
  • Set as Fulfilled + remove inventory: OK, no lag
  • Scanning on App: OK, no lag

So I guess it you still want to work with bigger orders the 100 line items, maybe the best way would be to change the fulfillment status using a Mutation and then Removing inventory using inventory_sync mutation
I hope this helps! But let me know if there is anything else I could help with
Thanks again!
Tom

1 Like

Hey @tomasw!

Thank you so much for all of this info! I really appreciate it. I think that clears up most of the questions I had, at least as far as the API side goes.

Thanks,
Jeremy

1 Like