Packs_per_day query giving duplicated labels in some cases

Hello!

In the packs_per_day query, I’m running into a situation where there are multiple packs performed for a shipment due to needing to send more than one package, but when getting that information out of the API, I’m getting duplication on the labels.

Here’s the query with a prefilled problematic order number:

query($record_count: Int) {
  packs_per_day (
    order_number: "S1496167"
  ) {
    request_id
    data (first: $record_count, sort: "created_at") {
      pageInfo {
        hasNextPage
        endCursor
      }

      edges {
        cursor
        node {
		  id
		  legacy_id
          user_first_name
          user_last_name
		  user_id
          unique_items
          total_items
          barcodes_scanned
          created_at
          order_number
		  shipment_id
          shipment {
			id
			legacy_id
			created_date
			total_packages
			pending_shipment_id
			profile
			total_packages
			user_id
            shipping_labels {
			  created_date
			  id
              legacy_id
              tracking_number
			  package_number
			  packing_slip
			  shipment_id
			  source
              carrier
              shipping_name
              shipping_method
              label_cost: cost
              label_status: status
              insurance_amount
			  box_name
			  box_id
			  box_code
              dimensions {
                weight
                length
                width
                height
              }
            }
          }
        }
      }
    }
  }
}

An example request_id is: 6356e077fbf545abec65f94e

In this case, I get back 2 packs for order number S1496167, each one with 2 shipping label legacy IDs: 192244916 and 192244918. The weights of the two packages are different because they have different contents, and therefore both IDs are valid. The problem is that both labels show up under both packs, each one with a different number of unique or total items listed.

In other words, for that order, I get two “packs”. The first one has 46 unique items, and the other has 5 unique items. Drilling down into the shipment details of each of these, I get both labels, one weighing 65 lbs, and the other weighing 24 lbs. In the end, for this order, what I wind up with is 4 records:

  • Two records for legacy ID 192244916, weighing 65 lbs, with one containing 46 unique items and the other containing 5.
  • Two records for legacy ID 192244918, weighing 24 lbs, with one containing 46 unique items and the other containing 5.

Depending on the affected order, sometimes it’s not the number of items that’s different, but the number of barcodes scanned. I think I even saw one where the number of items and barcodes scanned were the same between the two packs, but it still gave me duplicated records.

This causes a number of problems. When calculating user metrics, it inflates the number of “packs” they performed. When doing analysis on how much shipping is costing us, cases like this inflate the total label cost because those labels each get counted twice. And because there is different pack-level information (the number if unique or total items) there’s no way to consolidate it down to just the two records and ensure that the correct information goes with each label.

This is just one example. From what I can tell, it seems to be happening when we need to send out multiple physical packages for a single order, but it does not seem to happen in other cases where multiple labels are issued, such as if we reship a package or if orders are merged.

Please let me know if you need any other information from me.

Thanks,
Jeremy

Hello @jeremyw!

Thanks for reaching out!

We will run some tests to see how deep this goes.

I think we do understand the problem, though. You get both labels in each packing event, and in each case, both are showing roughly the same details.

I will let you know as soon as we have an update.

Have a great day!
TomasFD

1 Like

Hey @jeremyw,

Just wanted to let you know we’re still looking into this issue!
We’ll have an update for you shortly!

Best,
RayanP

1 Like

Hey @jeremyw,

Thanks for hanging in there while we investigated this!
I believe this is not intended and I’ve made an Engineering Ticket for this issue.

It will take some time for this to make its way through the process but I’ll let you know when a fix has been pushed for this issue.

Please let me know if you have any questions or concerns.

Best,
RayanP

1 Like

Thanks, @Rayanp! I’ll be interested to hear what the decided fix is for it. I can think of a couple of different ways it could go, and neither one is great or intuitive, so hopefully the brighter minds there can come up with something better than I can. :slight_smile:

Thanks agan,
Jeremy

1 Like