获取订单状态更新
常见挑战： 开发者有时无法阅读所有订单状态更新的通知。
最佳实践： 使用以下两种方法之一来获取订单状态更新：
1. 调用 API： 定期调用 getOrder API 来更新订单状态，直至订单达到终端状态 [完成、部分完成、已取消、无法配送]。追踪详细信息将在可用的响应中共享（订单可能处于“处理中”、“完成”和“部分完成”状态）。
2. 订阅通知： 通过订阅通知和监听事件 FULFILLMENT_ORDER_STATUS。每次订单状态发生变化或生成追踪编码时，系统都会发出一条需要从 SQS 队列中读取的通知。
API 调用是一种调取机制，开发者可能不知道 API 调用的频率。建议的做法是阅读通知，仅在订单完成后才调用 getOrder API 来获取完整的订单详情。
通过遵循这种方法，您可以：
• 减少频繁调用 API 所需的带宽。
• 了解早期的追踪详情。
• 获取实时通知，因为 API 调用可能会出现延迟。
• 获取追踪编码更新通知（如果有）。
最佳实践： 使用以下两种方法之一来获取订单状态更新：
1. 调用 API： 定期调用 getOrder API 来更新订单状态，直至订单达到终端状态 [完成、部分完成、已取消、无法配送]。追踪详细信息将在可用的响应中共享（订单可能处于“处理中”、“完成”和“部分完成”状态）。
2. 订阅通知： 通过订阅通知和监听事件 FULFILLMENT_ORDER_STATUS。每次订单状态发生变化或生成追踪编码时，系统都会发出一条需要从 SQS 队列中读取的通知。
API 调用是一种调取机制，开发者可能不知道 API 调用的频率。建议的做法是阅读通知，仅在订单完成后才调用 getOrder API 来获取完整的订单详情。
通过遵循这种方法，您可以：
• 减少频繁调用 API 所需的带宽。
• 了解早期的追踪详情。
• 获取实时通知，因为 API 调用可能会出现延迟。
• 获取追踪编码更新通知（如果有）。
同步库存
常见挑战： 开发者会误读库存消息中的库存值，或者不知道如何正确同步库存，这可能会导致超卖和缺货或冗余库存。
最佳实践： 我们建议订阅 FBA_INVENTORY_AVAILABILITY_CHANGES 通知类型，这样可以与亚马逊库存实时同步并反映任何库存变动。为避免错过任何通知，开发者应每天调用一次 getInventorySummaries API，以获取完整的库存水平快照。
每天多次调用 getInventorySummaries API 可能会导致 API 调用间隔数据过时，因此不建议这样做。
对于只使用 API 的开发者，我们建议：
• 根据下达和取消的订单，维护自己的内部库存记录。然后，您可以在库存同步过程中覆盖该记录，而且可以每天进行一次或两次该操作。
• 使用一些安全库存设置进行操作，这样库存同步任务之间就不会出现超卖情况。
如果仅对现有库存（亚马逊运营中心的库存）感兴趣，开发者应在回复中追踪 inventorySummaries.Fulfillable。
如果对计算在途/入库商品感兴趣，开发者可以计算以下总和：[inventoryDetails.Fulfillable + inventoryDetails.inboundWorkingQuantity+inventoryDetails.inboundShippedQuantity+inventoryDetails.inboundReceivingQuantity]。
注意： 在途/入库库存的预计送达日期可能比现有库存的长。
最佳实践： 我们建议订阅 FBA_INVENTORY_AVAILABILITY_CHANGES 通知类型，这样可以与亚马逊库存实时同步并反映任何库存变动。为避免错过任何通知，开发者应每天调用一次 getInventorySummaries API，以获取完整的库存水平快照。
每天多次调用 getInventorySummaries API 可能会导致 API 调用间隔数据过时，因此不建议这样做。
对于只使用 API 的开发者，我们建议：
• 根据下达和取消的订单，维护自己的内部库存记录。然后，您可以在库存同步过程中覆盖该记录，而且可以每天进行一次或两次该操作。
• 使用一些安全库存设置进行操作，这样库存同步任务之间就不会出现超卖情况。
如果仅对现有库存（亚马逊运营中心的库存）感兴趣，开发者应在回复中追踪 inventorySummaries.Fulfillable。
如果对计算在途/入库商品感兴趣，开发者可以计算以下总和：[inventoryDetails.Fulfillable + inventoryDetails.inboundWorkingQuantity+inventoryDetails.inboundShippedQuantity+inventoryDetails.inboundReceivingQuantity]。
注意： 在途/入库库存的预计送达日期可能比现有库存的长。
访问早期追踪信息
常见挑战： 追踪编码现已可用，而订单并未处于“配送完成”状态。
最佳实践： 对于调用 getOrder API 的开发者，不要假设追踪详细信息仅在订单处于完成或部分完成状态时才可用。现在，当订单处于处理中阶段时，追踪详细信息即已可用。
对于监听订单通知的开发者，系统会明确发出通知，其中包含承运人、包裹编号和追踪编码等早期追踪详细信息，订单状态为处理中。
通常，调用 getOrder API 的开发者会在使用追踪详细信息后将其订单标记为已配送，但是当在运营中心发生更改（修改）时，追踪详细信息始终会更新。如果您将订单标记为已配送，您将不会获得任何更新，并且追踪详细信息将无效。
请务必阅读 FULFILLMENT_ORDER_STATUS 通知，该通知会发送事件以获取早期追踪详细信息及追踪详细信息的任何更新（如果有）。此方法将确保卖家始终获得正确的订单追踪详细信息。
最佳实践： 对于调用 getOrder API 的开发者，不要假设追踪详细信息仅在订单处于完成或部分完成状态时才可用。现在，当订单处于处理中阶段时，追踪详细信息即已可用。
对于监听订单通知的开发者，系统会明确发出通知，其中包含承运人、包裹编号和追踪编码等早期追踪详细信息，订单状态为处理中。
通常，调用 getOrder API 的开发者会在使用追踪详细信息后将其订单标记为已配送，但是当在运营中心发生更改（修改）时，追踪详细信息始终会更新。如果您将订单标记为已配送，您将不会获得任何更新，并且追踪详细信息将无效。
请务必阅读 FULFILLMENT_ORDER_STATUS 通知，该通知会发送事件以获取早期追踪详细信息及追踪详细信息的任何更新（如果有）。此方法将确保卖家始终获得正确的订单追踪详细信息。
使用无品牌包装箱和阻止使用亚马逊物流功能
常见挑战： 开发者不知道如何配置无品牌包装箱和阻止使用亚马逊物流功能。
最佳实践： 多渠道配送在美国地区用无品牌包装箱交付大多数订单，但一些卖家可能要求所有订单都使用无品牌包装箱配送。
无品牌包装箱 (BB)：
1. 在 SKU 级别保持标记，将无品牌包装箱标记为仅限无品牌包装箱 (BB) 的 SKU。您可以通过调用 getFeatureInventory API 来查看符合无品牌包装箱要求的商品。
2. 对于仅限 BB 的 SKU，请务必追踪无品牌包装箱 (BB) 库存和常规库存。
3. 在销售渠道级别设置此切换开关，并确保所需的销售渠道始终关注 BB 库存。创建 BB 订单并将 BB 库存转送到这些销售渠道。
4. 在订单工作级别，调用 PREVIEW Order 和 CREATE Order 操作，功能约束为 Blank_Box=Required，以确保商品仅用无品牌包装箱配送。
阻止使用亚马逊物流（阻止 AMZL 或 BAMZL）：
卖家平台和供应链门户网站均在卖家账户的商城级别提供“阻止 AMZL”设置，可以为所有订单启用该设置，并收取 5% 的附加费。要求针对特定订单“阻止 AMZL”的开发者可以使用以下配置步骤：
1. 在销售渠道级别设置此切换开关，确保所需销售渠道的订单不会由亚马逊物流配送。为这些渠道创建 BAMZL 订单。
2. 在订单工作级别，调用 PREVIEW Order 和 CREATE Order 操作，功能约束为 Block_AMZL=Required，以确保商品由除亚马逊物流之外的其他承运人配送。
最佳实践： 多渠道配送在美国地区用无品牌包装箱交付大多数订单，但一些卖家可能要求所有订单都使用无品牌包装箱配送。
无品牌包装箱 (BB)：
1. 在 SKU 级别保持标记，将无品牌包装箱标记为仅限无品牌包装箱 (BB) 的 SKU。您可以通过调用 getFeatureInventory API 来查看符合无品牌包装箱要求的商品。
2. 对于仅限 BB 的 SKU，请务必追踪无品牌包装箱 (BB) 库存和常规库存。
3. 在销售渠道级别设置此切换开关，并确保所需的销售渠道始终关注 BB 库存。创建 BB 订单并将 BB 库存转送到这些销售渠道。
4. 在订单工作级别，调用 PREVIEW Order 和 CREATE Order 操作，功能约束为 Blank_Box=Required，以确保商品仅用无品牌包装箱配送。
阻止使用亚马逊物流（阻止 AMZL 或 BAMZL）：
卖家平台和供应链门户网站均在卖家账户的商城级别提供“阻止 AMZL”设置，可以为所有订单启用该设置，并收取 5% 的附加费。要求针对特定订单“阻止 AMZL”的开发者可以使用以下配置步骤：
1. 在销售渠道级别设置此切换开关，确保所需销售渠道的订单不会由亚马逊物流配送。为这些渠道创建 BAMZL 订单。
2. 在订单工作级别，调用 PREVIEW Order 和 CREATE Order 操作，功能约束为 Block_AMZL=Required，以确保商品由除亚马逊物流之外的其他承运人配送。
在公共应用程序上测试授权流程
常见挑战： 如果不在卖家平台上发布应用程序，开发者就不知道如何测试其卖家身份验证流程。
最佳实践： 开发者无需发布应用程序即可验证测试卖家账户的身份验证流程。要测试您的身份验证流程，可以在卖家平台同意 URL 中为卖家平台身份验证流程和网店身份验证流程添加“version=beta”。注意： 在测试模式下，由于仅用于验证目的，因此只有不超过 25 个卖家可以授权该应用程序。
示例：
https://sellercentral.amazon.com/apps/authorize/consent?application_id=appidexample&state=stateexample&version=beta
最佳实践： 开发者无需发布应用程序即可验证测试卖家账户的身份验证流程。要测试您的身份验证流程，可以在卖家平台同意 URL 中为卖家平台身份验证流程和网店身份验证流程添加“version=beta”。注意： 在测试模式下，由于仅用于验证目的，因此只有不超过 25 个卖家可以授权该应用程序。
示例：
https://sellercentral.amazon.com/apps/authorize/consent?application_id=appidexample&state=stateexample&version=beta
为多渠道配送开发者提取重要报告
常见挑战： 开发者不知道可以使用我们的报告 API 提取哪些报告。
最佳实践： 使用下面的调用信息为多渠道配送开发者提取关键报告。
多渠道配送开发者的重要报告：
• 商品信息报告 - 获取卖家账户的商品信息数据。
GET_FLAT_FILE_OPEN_LISTINGS_DATA 和 GET_MERCHANT_LISTINGS_ALL_DATA
• 库存报告 - 追踪亚马逊运营中心的库存变动。
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA 和 GET_LEDGER_SUMMARY_VIEW_DATA
• 订单/销售报告 - 获取由亚马逊配送的所有订单和货件数据。
GET_XML_ALL_ORDERS_DATA_BY_ORDER_DATE_GENERAL、GET_FLAT_FILE_ALL_ORDERS_DATA_BY_ORDER_DATE_GENERAL 和 GET_AMAZON_FULFILLED_SHIPMENTS_DATA_GENERAL
最佳实践： 使用下面的调用信息为多渠道配送开发者提取关键报告。
多渠道配送开发者的重要报告：
• 商品信息报告 - 获取卖家账户的商品信息数据。
GET_FLAT_FILE_OPEN_LISTINGS_DATA 和 GET_MERCHANT_LISTINGS_ALL_DATA
• 库存报告 - 追踪亚马逊运营中心的库存变动。
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA 和 GET_LEDGER_SUMMARY_VIEW_DATA
• 订单/销售报告 - 获取由亚马逊配送的所有订单和货件数据。
GET_XML_ALL_ORDERS_DATA_BY_ORDER_DATE_GENERAL、GET_FLAT_FILE_ALL_ORDERS_DATA_BY_ORDER_DATE_GENERAL 和 GET_AMAZON_FULFILLED_SHIPMENTS_DATA_GENERAL
维护沙盒访问凭证
常见挑战： 开发者希望为动态沙盒环境和生产环境维护不同的应用程序凭证。
无论是私有应用程序还是公共应用程序，均有办法仅限制对动态沙盒环境的访问权限。任何获得生产批准的应用程序都可以访问生产端点和沙盒端点，并且无法限制访问权限。
最佳实践： 为了解决此问题，开发者可以分别为沙盒和生产环境创建处于草稿状态的私有应用程序，并且仅在生产环境中发布商品，前提是他们计划保留两组套单独的客户端凭证。
无论是私有应用程序还是公共应用程序，均有办法仅限制对动态沙盒环境的访问权限。任何获得生产批准的应用程序都可以访问生产端点和沙盒端点，并且无法限制访问权限。
最佳实践： 为了解决此问题，开发者可以分别为沙盒和生产环境创建处于草稿状态的私有应用程序，并且仅在生产环境中发布商品，前提是他们计划保留两组套单独的客户端凭证。
