My team and I had a question around the inventory_change query.
Let’s say an inventory change event was made for location A, depositing 6250 items, and another inventory change event was made for a different location B, depositing 6250 items. In reality, our team knows the 6250 items were moved from A to B; however, when I query inventory_change for that specific item (sku), we don’t see an event that shows a “zeroing out” of the first location.
In other words, rather than creating another event denoting the removal of 6250 items from location A, ShipHero instead seems to have deleted the initial event. Here’s the example request_id: 63e4079b39746cf8ee1a0bc9.
Is there a reason why this event is missing from inventory_change? Thanks!
I’m checking that product, and I don’t see the stock moving from one location to another. I see 6250 added to a location. Several orders shipped, removing stock from that location and finally removing the remaining 6238 from that location, zeroing it out.
I see this both in the UI and API.
There’s an extra entry in the API for a receiving of 6250 of that SKU. It has the URL to access the PO, and the number in eh URL is the POs ID. If you check that PO, you will see it is associated with another child account.
Not sure if this helps clear everything, but if you can point out how and when you zeroed out that inventory, I may be able to find more info. Though these actions seem to be old now so, there might not be complete logs for them.
Just to clarify, an inventory change event was made for location A, depositing 6250 items, then another inventory change event was made for a different location B, depositing 6250 items
Eventually, another inventory change event was made for location B, removing 6250 items. Looking at our stock today (specifically for the SKU in the request_id), location A and location B are empty.
By just going off of the inventory change events, we would expect location A still contains 6250 items. This means that ShipHero did not create an inventory change event to zero-out location A when the inventory was moved from A to B.
Right now, we only see a single inventory_change event for location QmluOjMwNDI3Nzc= , depositing 6250 items.
Due to the missing event for zeroing out location QmluOjMwNDI3Nzc=, we are currently unable to rely on inventory_changes to construct the state of our inventory at a given point in time.
@tomasfd , would you mind confirming that you are observing the same issue that we are? Specifically the issue of location QmluOjMwNDI3Nzc= containing 6250 items according to inventory_changes.
Assuming that you confirm the issue exists, how can we correct the state of inventory_changes so that we may rely on it for calculating our storage totals over time?
Is not that the inventory change log is not returning it. I can’t find that zeroed out action in our logs. Can you share how and when this was done for us to look into it?
Thanks again for your reply. Check out these attached images from the ShipHero UI. In one image, you will see that the inventory change log indicates that B.01.07.02 has 6250 of 1001-02-INSERT stored. In the other image, you will see product locations view, indicating that B.01.07.02 is not at all storing 1001-02-INSERT.
This is the issue. Is it possible that the product locations view is filtering out 1001-02-INSERT due to the SKU being inactive, or something of that sort?
I checked the PO for that movement. You can see the ID on the inventory log reason. When you go inside it you can see the SKU does not exist for that customer.
I believe that is what is causing this inconsistency.
Thanks again for your reply. I do see that the purchase order shows that the product does not exist in ShipHero. However, when I search for the product under the “Products” page, it does exist.
So my question is, using the GraphQL API, how can we determine whether or not a product “exists within ShipHero” as the purchase order page is reporting?
If you check the associated 3PL customer for the product and the PO, you will see they differ. You need to have the product created for each customer account.
You could run a product query using sku and customer_account_id as filters.
@tomasfd , thank you for clarifying that. We have remediated the issue on our side by joining inventory change with product, on both accountId and productId. The problematic row is then filtered out due to the product no longer corresponding to the account on the inventory change entry.
