Question about purchase order receiving

Hi @tomasw,

This is not an end-user GQL question, but rather a question about how/why purchase order receiving at makes certain calls.

Since the launch of case barcodes, we have noticed that the receiving page ( hangs on just about every scan. Digging in a bit further, it looks like each scan generates 3 calls for a product barcode:

  1. an OPTION call
  2. a POST call to check if the scanned barcode is a case pack
  3. a POST call to check if the scanned barcode matches a product

The total time for these tends to come in around 2 seconds, but has lingered as long as 8.

I’m curious why you aren’t matching the scanned barcode against the product payload that is loaded on the prior page? I see that the product data does not (yet?) contain the case barcode so I can understand the network call for the case pack, but is there a reason for a network call for matching a scan to a product? For us, at least, this call makes up the majority of the lag.


Hi @david
Thanks for the detailed description!

I brought that to our engineering team and they responded that we will be implementing some improvements about this soon (the way those 3 calls are made).
Unfortunately, I don’t have an exact ETA, but I will be monitoring closely and will let you know as soon as I have an update about it.

Thanks again!

Hi @tomasw,

Sounds good! I figured it was one of those “let’s get the first iteration shipped and then improve” situation. No rush at all!


1 Like

Hi @david
This should be resolved now. Thanks for the heads up!
Let us know if there is anything else we could help with!,