My analysis
1. Your current architecture
1.1
You have multiple warehouses configured on Amazon under «Location based Shipping Settings».
1.2
Celigo periodically retrieves the up-to-date inventory balances from NetSuite and transmits them to Amazon via the SP-API, using the «Multi-Location Inventory» (MLI) feature.
1.3
The warehouses are assigned to your active shipping templates with «Shipping Settings Automation» (SSA) enabled.
1.4
For a specific order, SSA calculates the «Promised Delivery Date» (PDD) based on the warehouse with available inventory that is closest to the customer:
2
Judging by the symptoms, your NetSuite too often selects a fulfillment warehouse that is not the closest to the customer among those with available inventory.
This could happen, in particular, for the following reasons:
2.1
When transferring an order from Amazon to NetSuite, Celigo fails to pass to NetSuite the data indicating which of your warehouses Amazon assigned to fulfill the order (developer-docs.amazon/sp-api/reference/getorders, the FulfillmentInstruction → FulfillmentSupplySourceId property), causing NetSuite to select a warehouse based on its own rules.
2.2
Even if Celigo transmits FulfillmentInstruction → FulfillmentSupplySourceId correctly, NetSuite can ignore this information if it conflicts with its internal order allocation rules.
2.3
The item has already gone out of stock at the closest warehouse since the last Celigo data transmission from NetSuite to Amazon.
2.4
NetSuite determines that the closest warehouse lacks the capacity to process the order.
3
The problem in §2 leads:
3.1
Either to late delivery → a violation of the PDD → declining of your «On-time delivery rate» (OTDR) and «On-Time Delivery» (OTD) metrics.
3.2
Or to financial losses on shipping, because when you purchase shipping for an order, «Buy Shipping» compares the «Expected Delivery Date» (EDD) of each shipping method with the PDD and filters out those that do not meet the PDD → you are forced to use expensive shipping methods.
4
If the OTDR due to §3.1 has already fallen below 90% — your account is threatened with an algorithmic block.
In such a case, first of all, it is necessary to temporarily downgrade your shipping templates by disabling SSA and reverting to «manually calculated transit times» (with a buffer of the required number of days):
5
When the OTDR no longer threatens with an algorithmic block, it is necessary to implement proper solutions to your problem.
6
The proper solution to the out-of-stock problem (§2.3) is inventory ring-fencing: a strict inventory quota in NetSuite exclusively for Amazon, shielded from other sales channels.
This is the gold standard of managing inventory in enterprise.
7
The proper solution to the warehouse overload problem (§2.4) is dynamic API throttling.
NetSuite should calculate the length of the packaging queue based on data from RF-SMART modules and based on set the overload status for each warehouse.
Celigo must read the overload status from NetSuite and request to the Amazon Supply Sources API (updateSupplySource) to temporarily zero out the capacity (configuration → operationalConfiguration → throughputConfig → throughputCap → value) of the overloaded warehouse (without altering the inventory balances on Amazon).