BUG: Loc/Bucket bug #434

New Issue

2026-06-29T08:38:12Z

rob commented

2026-06-29 08:38:12 +00:00

There's a strange, infrequent, that causes Bucket/Location sync to diverge. I spent some time trying to track it down, and it needs to be fully fixed pretty soon.

See this order/shipment:

https://point-v.estack.com/retail/orders/134216

It appears the customer changed their order because of iphone 6/6+ confusion. I'm guessing someone in CS went in and modified the shipment, removing three SKUs, and adding an alternate 3.

However, it appears that the system failed to manipulate the container(items) for the shipment properly. The system recorded the original skus being shipped when it moved the ShipmentContainer to the customer-premises container.

So, I need to take a careful look at the code for modifying (retail) shipments, and make sure that stuff is handled correctly.

Notes

Currently, when a shipment is imported from a channel, we set up a "New"-status shipment. As the shipment is being created, a listener in the Retail module creates a ShipmentContainer, and adds the items to that container. It's done like this because doing it at label-generation time is very slow, and makes life hell for warehouse-bros. (Note: this might change if we can ever get our tree representation moved form nested-set to materialized-path. That's not guaranteed, but is a possibility)

Sketch-a-solution

Add events for shipment-modified, and have Retail module listen for those events. When those events happen, Retail module should either move stock from Shipment=>Picking-Area or vice-versa (based on whether we're removing or adding items, respectively).

There should also be a sanity check written that can be invoked on a shipment to make sure Shipment/ShipmentItem objects are in sync with any related Container/ContainerItem objects.

There's a strange, infrequent, that causes Bucket/Location sync to diverge. I spent some time trying to track it down, and it needs to be fully fixed pretty soon. See this order/shipment: https://point-v.estack.com/retail/orders/134216 It appears the customer changed their order because of iphone 6/6+ confusion. I'm guessing someone in CS went in and modified the shipment, removing three SKUs, and adding an alternate 3. However, it appears that the system failed to manipulate the container(items) for the shipment properly. The system recorded the original skus being shipped when it moved the ShipmentContainer to the customer-premises container. So, I need to take a careful look at the code for modifying (retail) shipments, and make sure that stuff is handled correctly. ## Notes Currently, when a shipment is imported from a channel, we set up a "New"-status shipment. As the shipment is being created, a listener in the Retail module creates a ShipmentContainer, and adds the items to that container. It's done like this because doing it at label-generation time is very slow, and makes life hell for warehouse-bros. (Note: this might change if we can ever get our tree representation moved form nested-set to materialized-path. That's not guaranteed, but is a possibility) ## Sketch-a-solution Add events for shipment-modified, and have Retail module listen for those events. When those events happen, Retail module should either move stock from Shipment=>Picking-Area or vice-versa (based on whether we're removing or adding items, respectively). There should also be a sanity check written that can be invoked on a shipment to make sure Shipment/ShipmentItem objects are in sync with any related Container/ContainerItem objects.

Sign in to join this conversation.

No Label

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: rob/pms3#434