一般的な課題とベストプラクティス
このセクションでは、MCFコネクター統合の作成時に開発者が直面する一般的な課題と、それらの課題の克服に役立つベストプラクティスをいくつか説明します。
注文状況の最新情報の取得
一般的な課題： 開発者は、すべての注文状況の最新情報の通知を読むことが難しい場合があります。
ベストプラクティス： 次のうちいずれかの方法により、注文状況の最新情報を取得します。
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通知タイプをサブスクライブすることをお勧めします。Amazon在庫とリアルタイムで同期でき、在庫の変化が反映されます。通知を見逃さないように、開発者はgetInventorySummaries APIを1日1回呼び出して、在庫レベルの完全なスナップショットを取得する必要があります。
getInventorySummaries APIを1日に複数回呼び出すと、API呼び出しの合間にデータが古くなる可能性があるため、お勧めしません。
APIのみを使用する開発者には次のことをお勧めします。
• 発注およびキャンセルされた注文に基づいて、独自の内部在庫記録を維持します。この場合は、在庫同期プロセス中にそのレコードを上書きできます。これは1日に1回か2回実行できます。
• 在庫同期ジョブの間に過剰販売が発生しないように、いくつかの安全在庫設定で運用します。
Amazonフルフィルメントセンターにある手持ち在庫のみに注目する場合、開発者はレスポンスでinventorySummaries.Fulfillableについて追跡する必要があります。
輸送中/入荷待ちの会計処理に注目する開発者は、[inventoryDetails.Fulfillable + inventoryDetails.inboundWorkingQuantity+inventoryDetails.inboundShippedQuantity+inventoryDetails.inboundReceivingQuantity]の合計を求めます。
注： 輸送中/入荷待ちの在庫は、手持ち在庫よりも到着予定日が長い場合があります。
ベストプラクティス： FBA_INVENTORY_AVAILABILITY_CHANGES通知タイプをサブスクライブすることをお勧めします。Amazon在庫とリアルタイムで同期でき、在庫の変化が反映されます。通知を見逃さないように、開発者はgetInventorySummaries APIを1日1回呼び出して、在庫レベルの完全なスナップショットを取得する必要があります。
getInventorySummaries APIを1日に複数回呼び出すと、API呼び出しの合間にデータが古くなる可能性があるため、お勧めしません。
APIのみを使用する開発者には次のことをお勧めします。
• 発注およびキャンセルされた注文に基づいて、独自の内部在庫記録を維持します。この場合は、在庫同期プロセス中にそのレコードを上書きできます。これは1日に1回か2回実行できます。
• 在庫同期ジョブの間に過剰販売が発生しないように、いくつかの安全在庫設定で運用します。
Amazonフルフィルメントセンターにある手持ち在庫のみに注目する場合、開発者はレスポンスでinventorySummaries.Fulfillableについて追跡する必要があります。
輸送中/入荷待ちの会計処理に注目する開発者は、[inventoryDetails.Fulfillable + inventoryDetails.inboundWorkingQuantity+inventoryDetails.inboundShippedQuantity+inventoryDetails.inboundReceivingQuantity]の合計を求めます。
注： 輸送中/入荷待ちの在庫は、手持ち在庫よりも到着予定日が長い場合があります。
早期追跡情報へのアクセス
一般的な課題： お問い合わせ伝票番号は、注文が出荷完了にならなくても利用できるようになりました。
ベストプラクティス： getOrder APIを呼び出す開発者は、注文が完了または部分的に完了のステータスになっている場合にのみ追跡の詳細が表示されると想定しないでください。追跡の詳細は、注文が処理段階にあるときに利用できるようになります。
注文通知をリスニングしている開発者には、注文状況を「処理中」として、早期追跡情報を含めた通知が明示的に送信されます。これには配送業者、パッケージ番号、お問い合わせ伝票番号が含まれます。
多くの場合、getOrder APIを呼び出す開発者は、追跡情報を活用して注文を出荷済みとマークしますが、フルフィルメントセンターでリスラム（変更）が発生すると、追跡情報は更新される可能性があります。注文を出荷済みとしてマークすると、更新に気付かず、追跡情報が無効になります。
FULFILLMENT_ORDER_STATUS通知を必ずお読みください。この通知では、早期追跡情報のイベントや、追跡情報の更新がある場合はそのイベントが送信されます。このアプローチにより、出品者は注文に関する正確な追跡情報を常に把握できます。
ベストプラクティス： getOrder APIを呼び出す開発者は、注文が完了または部分的に完了のステータスになっている場合にのみ追跡の詳細が表示されると想定しないでください。追跡の詳細は、注文が処理段階にあるときに利用できるようになります。
注文通知をリスニングしている開発者には、注文状況を「処理中」として、早期追跡情報を含めた通知が明示的に送信されます。これには配送業者、パッケージ番号、お問い合わせ伝票番号が含まれます。
多くの場合、getOrder APIを呼び出す開発者は、追跡情報を活用して注文を出荷済みとマークしますが、フルフィルメントセンターでリスラム（変更）が発生すると、追跡情報は更新される可能性があります。注文を出荷済みとしてマークすると、更新に気付かず、追跡情報が無効になります。
FULFILLMENT_ORDER_STATUS通知を必ずお読みください。この通知では、早期追跡情報のイベントや、追跡情報の更新がある場合はそのイベントが送信されます。このアプローチにより、出品者は注文に関する正確な追跡情報を常に把握できます。
ノーブランド包装（Amazonロゴのない無地ダンボール）とAmazon Logisticsブロック機能の使用
一般的な課題： 開発者が、ノーブランド包装とAmazon Logisticsブロック機能の設定方法を知りません。
ベストプラクティス： MCFは、ほとんどの注文を米国地域内でノーブランド包装で配送しますが、一部の出品者は、すべての注文をノーブランド包装で配送することを義務付けている場合があります。
ノーブランド包装（Amazonロゴのない無地ダンボール（BB））：
1. SKUレベルでフラグを設定して、ノーブランド包装をBlankBox（BB）専用SKUとしてマークします。getFeatureInventory APIを呼び出すと、BlankBoxの対象商品を確認できます。
2. BB専用SKUの場合は、ノーブランド包装（BlankBoxまたはBB）と通常の在庫の両方を必ず追跡します。
3. 販売経路レベルでトグルを設定し、必要な販売経路で常にBB在庫が確認されるようにします。BB注文を作成し、BB在庫をこれらの販売経路に伝えます。
4. 注文作業レベルでは、Blank_Box=Requiredという機能制約を指定してPREVIEW OrderとCREATE Orderオペレーションを呼び出し、商品がノーブランド包装でのみ配送されるようにします。
Amazon Logisticsブロック（Block AMZLまたはBAMZL）：
セラーセントラルとサプライチェーンポータルはそれぞれ、出品者アカウントのマーケットプレイスレベルでBlock
AMZL設定を提供しています。この設定はすべての注文で有効にでき、5%の追加料金がかかります。特定の注文にBlock AMZLを必要とする開発者は、以下の設定手順を実行してください。
1. 必要な販売経路の注文がAmazon Logisticsによって配送されないように、販売経路レベルでトグルを設定します。これらの経路のBAMZL注文を作成してください。
2. 注文作業レベルで、機能制約Block_AMZL=Requiredを指定して、PREVIEW OrderとCREATE Orderオペレーションを呼び出し、Amazon Logistics以外の別の配送業者が商品を出荷していることを確認します。
ベストプラクティス： MCFは、ほとんどの注文を米国地域内でノーブランド包装で配送しますが、一部の出品者は、すべての注文をノーブランド包装で配送することを義務付けている場合があります。
ノーブランド包装（Amazonロゴのない無地ダンボール（BB））：
1. SKUレベルでフラグを設定して、ノーブランド包装をBlankBox（BB）専用SKUとしてマークします。getFeatureInventory APIを呼び出すと、BlankBoxの対象商品を確認できます。
2. BB専用SKUの場合は、ノーブランド包装（BlankBoxまたはBB）と通常の在庫の両方を必ず追跡します。
3. 販売経路レベルでトグルを設定し、必要な販売経路で常にBB在庫が確認されるようにします。BB注文を作成し、BB在庫をこれらの販売経路に伝えます。
4. 注文作業レベルでは、Blank_Box=Requiredという機能制約を指定してPREVIEW OrderとCREATE Orderオペレーションを呼び出し、商品がノーブランド包装でのみ配送されるようにします。
Amazon Logisticsブロック（Block AMZLまたはBAMZL）：
セラーセントラルとサプライチェーンポータルはそれぞれ、出品者アカウントのマーケットプレイスレベルでBlock
AMZL設定を提供しています。この設定はすべての注文で有効にでき、5%の追加料金がかかります。特定の注文にBlock AMZLを必要とする開発者は、以下の設定手順を実行してください。
1. 必要な販売経路の注文がAmazon Logisticsによって配送されないように、販売経路レベルでトグルを設定します。これらの経路のBAMZL注文を作成してください。
2. 注文作業レベルで、機能制約Block_AMZL=Requiredを指定して、PREVIEW OrderとCREATE Orderオペレーションを呼び出し、Amazon Logistics以外の別の配送業者が商品を出荷していることを確認します。
公開アプリでの認可フローのテスト
一般的な課題： 開発者が、セラーセントラルでアプリを公開または出品せずに出品者認証フローをテストする方法を知りません。
ベストプラクティス： 開発者は、アプリを公開しなくても出品者テストアカウントの認証フローを検証できます。セラーセントラル認証フローとウェブストア認証フローの両方について、セラーセントラル同意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
MCF開発者向けの主要レポート：
一般的な課題： 開発者が、レポートAPIを使用して抽出できるレポートを知りません。
ベストプラクティス： 以下のコール情報を使用して、MCF開発者向けの主要なレポートを抽出してください。
MCF開発者向けの主要レポート：
• 出品レポート - 出品用アカウントの商品出品データを取得します。
GET_FLAT_FILE_OPEN_LISTINGS_DATAおよびGET_MERCHANT_LISTINGS_ALL_DATA
• 在庫レポート - Amazonフルフィルメントセンターでの在庫の動きを追跡します。
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATAとGET_LEDGER_SUMMARY_VIEW_DATA
• 注文/売上レポート - Amazonから出荷されたすべての注文および出荷データを取得します。
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
ベストプラクティス： 以下のコール情報を使用して、MCF開発者向けの主要なレポートを抽出してください。
MCF開発者向けの主要レポート：
• 出品レポート - 出品用アカウントの商品出品データを取得します。
GET_FLAT_FILE_OPEN_LISTINGS_DATAおよびGET_MERCHANT_LISTINGS_ALL_DATA
• 在庫レポート - Amazonフルフィルメントセンターでの在庫の動きを追跡します。
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATAとGET_LEDGER_SUMMARY_VIEW_DATA
• 注文/売上レポート - Amazonから出荷されたすべての注文および出荷データを取得します。
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
サンドボックスアクセスの認証情報の管理
一般的な課題： 開発者が、ダイナミックサンドボックス環境と本稼働環境で異なるアプリ認証情報を維持したいと考えています。
非公開アプリと公開アプリの両方で、ダイナミックサンドボックス環境のみにアクセスを制限する方法があります。本稼働承認アプリは、ProductionエンドポイントとSandboxエンドポイントの両方にアクセスでき、アクセスを制限する方法はありません。
ベストプラクティス： 2つのクライアント認証情報を別々に保持する場合、この問題を解決するために、開発者はサンドボックス環境と本稼働環境用にドラフトステータスで異なる非公開アプリを作成し、本稼働環境でのみ商品を出品できます。
非公開アプリと公開アプリの両方で、ダイナミックサンドボックス環境のみにアクセスを制限する方法があります。本稼働承認アプリは、ProductionエンドポイントとSandboxエンドポイントの両方にアクセスでき、アクセスを制限する方法はありません。
ベストプラクティス： 2つのクライアント認証情報を別々に保持する場合、この問題を解決するために、開発者はサンドボックス環境と本稼働環境用にドラフトステータスで異なる非公開アプリを作成し、本稼働環境でのみ商品を出品できます。
