We are facing a situation related to the creation of shipment plans when box-level information is not provided in advance. Below is a description of the process we follow and the problem we have encountered:
We create the shipment plan and obtain the shipmentConfirmationId.
We pack the contents into different boxes based on the distribution of legs.
2.1 We place the necessary contents into our local Box # 1 and print the label BARCODE_2D # 1 (This label is the result of calling the getLabels operation).
2.2 We place the necessary contents into our local Box # 2 and print the label BARCODE_2D # 2 (This label is the result of calling the getLabels operation).
2.3 We continue this process for each local box (#n), placing the contents and printing the corresponding label BARCODE_2D #n (These labels are the result of calling the getLabels operation).
[example of labels]
Afterward, we use the setPackingInformation operation to send the dimensions, weights, and contents of each box.
When calling the listShipmentBoxes operation, we find that the order of the boxes we have labeled locally does not match the order referenced by Amazon, forcing us to relabel all the boxes.
In the v0 version of the Fulfillment Inbound API, the POST_FBA_INBOUND_CARTON_CONTENTS feed allowed us to assign an ID to maintain the relationship. However, in the v2024-03-20 version, the setPackingInformation operation does not allow sending an ID to maintain the box order.
Here is an example of the mismatch we experience:
We kindly request your support in resolving this issue, either by enabling the possibility of assigning an ID to the boxes as in previous versions of the API, or by suggesting an alternative solution to maintain the correspondence between local labels and the Amazon-assigned box IDs.
Dear Amazon team,
We are facing a situation related to the creation of shipment plans when box-level information is not provided in advance. Below is a description of the process we follow and the problem we have encountered:
We create the shipment plan and obtain the shipmentConfirmationId.
We pack the contents into different boxes based on the distribution of legs. 2.1 We place the necessary contents into our local Box # 1 and print the label BARCODE_2D # 1 (This label is the result of calling the getLabels operation). 2.2 We place the necessary contents into our local Box # 2 and print the label BARCODE_2D # 2 (This label is the result of calling the getLabels operation). 2.3 We continue this process for each local box (#n), placing the contents and printing the corresponding label BARCODE_2D #n (These labels are the result of calling the getLabels operation). [example of labels]
Afterward, we use the setPackingInformation operation to send the dimensions, weights, and contents of each box.
When calling the listShipmentBoxes operation, we find that the order of the boxes we have labeled locally does not match the order referenced by Amazon, forcing us to relabel all the boxes.
In the v0 version of the Fulfillment Inbound API, the POST_FBA_INBOUND_CARTON_CONTENTS feed allowed us to assign an ID to maintain the relationship. However, in the v2024-03-20 version, the setPackingInformation operation does not allow sending an ID to maintain the box order.
Here is an example of the mismatch we experience:
We kindly request your support in resolving this issue, either by enabling the possibility of assigning an ID to the boxes as in previous versions of the API, or by suggesting an alternative solution to maintain the correspondence between local labels and the Amazon-assigned box IDs.