We’re wondering if there are better ways to ping Amazon to create better shipments or shipment plans for our customers but we’re having trouble discerning between the two of them, especially from an API perspective and how they get treated. Anyone have any insights to that?
A “shipping plan” is Amazon’s proposed plan for splitting your inventory between fulfillment centers. It is automatically generated by Amazon when you use the “send/replenish” button on your Manage Inventory screen. A shipping plan may, for example, direct you to send two units of SKU 001 and four units of SKU 002 to Baltimore, while directing you to send ten units of SKU 001 to Moreno and eight units of SKU 002 to Tampa. You have the option of accepting the shipping plan or canceling it. To the best of my knowledge, there is no penalty for canceling a shipping plan.
If you accept the shipping plan, Amazon creates one or more “shipments,” for you, each to a particular warehouse. At this point, you’re committed to following through with each of the shipments indicated. Although shipments can be canceled, this should be done sparingly and only as a last resort, since Amazon does penalize sellers who repeatedly cancel shipments.
So is there a better way to create the shipments for the users such that there is less splits. We know spilts happen, we know they happen more so in Q4 but we’re trying to optimize the listing creation part. if the users creates their own shipment plans on Seller Central and doesn’t use us then it seems the splits are not as bad.
Yes-- there are several ways of approaching this:
(1) Use Amazon’s inventory placement service, which allows you, for a fee, to choose where your inventory is sent;
(2) Cancel the shipping plan and wait a few days to see whether the allocation changes (it often does);
(3) Tinker with the contents of the shipping plan, removing whatever it is that is causing small shipments to be generated;
(4) Hold off sending small shipments until you have a second shipment going to that same warehouse, at which time you can combine the two shipments into one.
However, I don’t know what you mean by this: “if the users creates their own shipment plans on Seller Central and doesn’t use us . . .” Are you a third-party seller, or are you providing some kind of service for sellers?
It is confusing, seller central refers to shipment plans like they are a separate thing. This is just a construct of the gui, and doesn’t really exist in MWS. With MWS the developer calls the CreateInboundShipmentPlan with their own list of sku/quantity and gets back a list of proposed shipments.
There seems to be some nuance here for developers.
- the seller central way: use CreateInboundShipmentPlan with a full list of all items and skus, use the results to CreateInboundShipment
- the one at a time way: use CreateInboundShipmentPlan for each sku, and use the results to either CreateInboundShipment or UpdateInboundShipment
Creating the shipments with all the sku/qty at once leads to fewer shipments. (seller central method) Creating shipments with one sku at a time has other interesting advantages.
This assumes you understand and have marked the appropriate handling/labeling inputs, items with different handling or labeling requirements will always be split into their own shipments.
shipping plans are ephemeral.
Excellent description, but not precisely accurate in one respect (see bolded text above). At the point the shipments are created you can still increase or decrease the quantity of any item in that shipment by 6 or 10% whichever is greater (it may be +/-15%, I forget). If you are able to decrease a small shipment to zero within that range the shipment to that FC will go away.
Thanks so much everyone. One thing we did learn through this is that we can allow the seller to add items to existing shipment plans if the warehouse designation and prep type/labeling instructions are the same and that is good to know as we’ll be building a solution for that.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.