Adobe Commerceのストアフルフィルメントのテストとデプロイ

開発環境でのオンボーディングプロセスを完了したら、ストアフルフィルメントソリューションをテストし、実稼動環境にデプロイするプロセスを開始できます。

前提条件

情報、ストア、オーダーをテストまたは同期する前に、次のタスクを完了していることを確認してください。

テストの準備

テストオーダーを作成したり、統合テストを実行したりするには、接続設定を完了する必要があります。 テストする前に、ストアデータが同期されていることも確認する必要があります。

  1. ストアフルフィルメントソースを同期します。

    • Stores > Sources に移動します。

    • Synchronize Store Fulfillment Sources」を選択します。

  2. ストアグリッドから、テストオーダーを作成する前に、ストアが Synced としてマークされていることを確認します。

サンプルテスト計画

小売業者は、デプロイメントの設定およびテストフェーズで、ストアフルフィルメントソリューションの基本機能を検証します。 このサンプルテストプランは、テストの出発点となります。 必要に応じて、シナリオを追加します。

NOTE
ストアフルフィルメントソリューションの最初のオンボーディングを完了するか、既存のインストールを更新した後、実稼動環境にデプロイする前に、常に実稼動以外の環境でアプリケーションをテストします。

このサンプルテスト計画は、次の機能領域をカバーしています。

機能領域
関数
役割
在庫と注文の同期
在庫 API 同期
Adobe Commerce管理者
エンドツーエンド
注文キャンセルワークフロー
顧客、管理者、店員
Admin
Store Fulfillment App の権限
Admin
Adobe Commerce フロントエンド
製品タイプ
顧客、管理者
フロントエンドのチェックアウ
フォーム
チェックイン操作
顧客、管理者
ストアシストアプリ
Order
Pick
Stage
and Handoff
ストアの関連付け

Inventory API の同期

テスト計画のこのセクションでは、在庫と注文の同期について説明し、集荷ソースと在庫の更新がAdobe Commerceと Store Fulfillment ソリューションの間で正しく同期されることを確認します。

機能領域:在庫と注文の同期

役割: Admin

テストタイプ: すべて陽性

関数
シナリオをテスト
期待される結果
集荷在庫ソースの追加
新しい集荷在庫ソースを保存します。
リアルタイム同期により、ソースの詳細が 5 分以内にウォルマートGIFサービスに送信されます。
既存の集荷在庫ソースの更新
既存の集荷在庫ソースの更新を保存します。
リアルタイム同期処理により、詳細が 5 分以内にウォルマートGIFに送信されます
集荷在庫ソース
Is Synced 状態
既存の集荷在庫ソースの更新を保存します。
操作が成功すると、Sourceの管理ページの「Is Synced」列が No から Yes に更新されます。
変更された在庫予約プロセス
商品の新しい注文を作成して送信します。
それに応じて、商品の売り上げ可能数量が減少します。
新しい注文のプッシュ、API 同期:顧客の注文
顧客が店舗の受け取り注文を送信します。
  • 管理者の注文表示で、Adobe Commerce管理者ユーザーに注文の同期ステータスが次のように更新されたことを 知らせします。 Sent
  • 注文の詳細ログには、メッセージが含まれます Order was sent to BOPIS solution for sync, it's not yet acknowledged yet.
新しい注文のプッシュ、API 同期 – 管理者が注文を送信
Adobe Commerce 管理者 が集荷注文を送信します。
  • 管理者の注文表示で、注文同期のステータスが Sent に更新されます。
  • 注文の詳細ログには、メッセージが含まれます Order was sent to BOPIS solution for sync, it's not yet acknowledged yet.
新規受注プッシュ、例外キュー
フルフィルメントサービス(FaaS)とのやり取りを必要とせずにAdobe Commerceを通じてフルフィルメントできる、Adobe Commerce Admin のバーチャルおよびダウンロード可能な商品をいくつか特定します。
ダウンストリームでの FaaS との競合を防ぐために、これらの製品は、書き出しで適切に削除またはフラグ付けされます。

注文キャンセルワークフロー

テスト計画のこのセクションには、Adobe Commerceを通じてキャンセルされた注文のエンドツーエンドのワークフローをテストするシナリオが含まれます。

機能領域: Adobe Commerce管理者

役割: エンドツーエンド(管理者、ストアの関連付け、顧客)

テスト結果のタイプ: すべてのシナリオでプラス

関数
シナリオ
期待される結果
完全な注文のキャンセル
  1. 注文する。
  2. 注文が同期されるまで待ちます。
  3. 請求書の作成を検証します(承認してキャプチャする場合)。請求書の E メールの受信。
  4. 請求書ビューで、すべての受注製品を使用してクレジット・メモを作成します。
  • We refunded $X online. Transaction ID: transactionID とで注文履歴が更新されました Received Cancel acknowledgment from the BOPIS solution.
  • 注文ステータスは Closed です。 (支払いレビューを設定しました。)
  • Adobe Commerceで作成されたクレジットメモ。 (cron が動作するまで待ちます。
  • すべてのアイテムが選択された場合、[ 集荷の準備完了 ] E メール DISPLAY COMMENT HISTORYOrder is ready for pickup と表示されます(CUSTOMER NOTIFIED フラグは true です)。
  • すべての項目が選択されていない場合は、キャンセルメールおよびコメント履歴を表示 Order has been canceled - all items were not available
  • CUSTOMER NOTIFIED フラグは true)。
一部注文のキャンセル
  1. 少なくとも 2 つの製品で注文します。
  2. 注文が同期されるまで待ちます。
  3. 請求書が作成され(承認してキャプチャする場合)、請求書の電子メールが受信されたことを確認します。
  4. トランザクションの決済まで 2 時間待ちます。
  5. 請求書ビューから受注製品の一部のみを使用してクレジット・メモを作成します。
  • 注文履歴の更新: We refunded $X online. Transaction ID: transactionID
  • 注文履歴の更新: Order notified as partly canceled at: Date and Hour
  • 注文の払い戻しメールの受信: $x amount was refunded
  • 注文ステータスは Processing です。
  • Adobe Commerceで作成されたクレジットメモ (cron が機能するまで待つ)。
  • 一部の商品が選択されていない場合は、nil の選択または払い戻しセクションが記載された Ready for Pickup ールメールが表示されていることを確認します。 DISPLAY COMMENT HISTORYOrder is ready for pickup, but some items not available. を示す。
  • CUSTOMER NOTIFIED フラグは true です。
集荷の準備完了

完全キャンセル
(すべての製品は数量 0 の集荷として設定されます)
  1. 注文します。
  2. 注文が同期されるまで待ちます。
  3. 請求書が作成され(承認してキャプチャする場合)、請求書の電子メールが受信されたことを確認します。
  4. Postmanに移動し、0 qtypicked 定されたすべての商品を含む Ready for Pickup リクエストを実行します。
  • 注文履歴が更新されました: We refunded $X offline
  • 注文ステータスは「CLOSED」です。
  • クレジット・メモが作成されます。 (cron が動作するまで待ちます。
  • 返金処理の電子メールが届きました: $x amount was refunded
  • 注文のキャンセル用メールが送信されました。
集荷の準備完了 – 一部キャンセル

(一部の商品は集荷され、一部は 0 qty で集荷される)
  1. 注文します。
  2. 注文が同期されるまで待ちます。
  3. 請求書が作成され(承認してキャプチャする場合)、請求書の電子メールが受信されたことを確認します。
  4. Postmanに移動し、一部の商品が 0 数量でピッキング済みとしてセットされ、残りの商品がピッキング済みになっている状態で、Ready for Pickup リクエストを実行します。
  • Your order is ready for pickup Ready for Pickup Items テーブルと Canceled Items テーブルを使用します。
  • 注文ステータスが集荷準備の状態です。
  • 注文履歴が更新されました:We refunded $X offline.
  • 注文履歴が更新されました:Order notified as partly canceled at: Date and hour
  • 返金処理の電子メールが届きました:$x amount was refunded
  • クレジット メモが作成されます。 (cron が動作するまで待ちます。
集荷準備完了 – 一部取消

一部の商品は集荷され、一部の商品は 0 qty で集荷されます)
  1. 注文します。
  2. 注文が同期されるまで待ちます。
  3. 請求書が作成され(承認してキャプチャする場合)、請求書の電子メールが受信されたことを確認します。
  4. Postmanに移動し、一部の商品が 0 数量でピッキング済みとしてセットされ、残りの商品がピッキング済みになっている状態で、Ready for Pickup リクエストを実行します。
  • Your order is ready for pickup Ready for Pickup Items テーブルと Canceled Items テーブルを使用します。
  • 注文ステータスが集荷準備の状態です。
  • 注文履歴が更新されました:We refunded $X offline.
  • 注文履歴が更新されました:Order notified as partly canceled at: Date and hour
  • 返金処理の電子メールが届きました:$x amount was refunded
  • クレジット メモが作成されます。 (cron が動作するまで待ちます。
調剤(調剤中)

フルキャンセル(全商品が拒否に設定)
  1. 注文します。
  2. 注文が同期されるまで待ちます。
  3. 請求書が作成され(承認してキャプチャする場合)、請求書の電子メールが受信されたことを確認します。
  4. Postmanに移動し、すべての商品がピッキング済みとして設定された状態で Ready for Pickup リクエストを実行します。
  5. メールボックスを開き、Ready for Pickup のメールを見つけます。 次に、「**Confirm Arrival**」をクリックします。
  6. チェックインします。
  7. Postmanに移動し、拒否されたとおりにすべての商品を指定して「調剤」リクエストを実行します。
  • 注文履歴が更新されました: We refunded $X offline.
  • 返金処理の電子メールが届きました: $x amount was refunded
  • 状態が CLOSED に設定されました。
  • 作成されたクレジット メモ。 (cron が動作するまで待ちます。
調剤済み(調剤中)

一部解除
(調剤済み、不合格の製品あり)
  1. 注文します。
  2. 注文が同期されるまで待ちます。
  3. 請求書が作成され(承認してキャプチャする場合)、請求書の電子メールが受信されたことを確認します。
  4. Postmanに移動し、すべての商品がピッキング済みとして設定された状態で Ready for Pickup リクエストを実行します。
  5. メールボックスを開きます。 Ready for Pickup の電子メールを探し、Confirm Arrival を選択します。
  6. チェックインします。
  7. Postmanに移動し、調剤された商品と拒否された商品を含む調剤リクエストを実行します
  • 注文履歴が更新されました: We refunded $X offline

  • Order notified as partly canceled at: Date and Hour

  • 返金処理の電子メールが届きました:$x amount was refunded

  • 注文ステータスを Ready for pickup Dispensed に設定

  • 作成されたクレジット メモ。 (cron が動作するまで待ちます。

返品後の新しい RMA (完全)
  1. 注文します。
  2. 注文が同期されるまで待ちます。
  3. 承認して取り込みオプションが設定されている場合は、請求書が作成され、お客様が請求書メールを受け取ったことを確認します。
  4. Postmanですべての商品を選択します。
  5. チェックインします。
  6. 調剤をしなさい。
  7. order に移動し、select Create returns=
  8. RMA を作成します。
  • RMA が作成され、[Order] ビューの [Returns] タブの下に表示されます。 - 顧客は RMA 確認メールを受信しました。
再来訪後の新規 RMA – 一部
  1. 注文します。
  2. 注文が同期されるまで待ちます。
  3. 請求書が作成され(承認してキャプチャする場合)、請求書の電子メールが受信されたことを確認します。
  4. Postmanですべての商品を選択します。
  5. チェックインします。
  6. 調剤をしなさい。
  7. 注文に進み、を選択します。 Create returns
  8. 注文した製品の一部を使用して RMA を作成します。
  • RMA が作成され、[Order] ビューの [Returns] タブの下に表示されます。
  • 顧客は RMA 確認メールを受け取った。
  • RMA を作成したら、RMA 認証を取得します。管理者から、Sales > Returns に移動します。 作成した RMA を選択し、承認します。
  • お客様が RMA 認証確認メールを受信したことを確認します。
  • 返金がトランザクションおよび注文履歴に追加されたことを確認します。

Store Fulfillment App の権限

テストプランのこのセクションでは、Store Fulfillment App ユーザーのアカウント管理について説明します。

  • Store Associate が、Adobe Commerce管理者から作成された新しいユーザーアカウントを使用して認証できることを確認します。
  • 既存のアカウントに対する更新が正常に適用されていることを確認します。

機能領域: Adobe Commerce管理者

役割: 管理者、ストアの関連付け

テストタイプ: すべて陽性

関数
シナリオ
期待される結果
ユーザーアカウント管理 – アカウントの作成
  1. Admin — Adobe Commerce Admin にログインします。
  2. System / Store Fulfillment App Permissions / All Store Fulfillment App Users に移動します
  3. 新しいユーザーを追加します。
  • アカウントが正常に作成されました。
  • 新しいユーザーアカウントが Store Fulfillment Users ダッシュボードに表示されます。
  • ストア関連付け 新しいユーザーアカウントでストアアシストアプリにログインします。
ユーザーアカウント管理 – 既存のユーザーアカウントを更新
  1. 管理者ユーザーアカウントでAdobe Commerce管理者にログインします。
  2. System / Store Fulfillment App Permissions / All Store Fulfillment App Users に移動します。
  3. ユーザーアカウント リストで、既存のアクティブなユーザーアカウントを選択して開 Edit ます。
  4. Is Activeいいえ に変更して、アカウントを無効にします。
  • Store Fulfillment App Users ダッシュボードで、更新されたアカウントのステータスが Inactive に変更されました。
  • ストアの関連付けは、非アクティブなアカウント資格情報ではストアアシストアプリにログインできません。

Adobe Commerceの製品タイプ

Adobe Commerce商品タイプのテストシナリオでは、様々な商品タイプに対して正しい商品、在庫、配信方法が顧客に表示されることを確認します。

  • Configurable
  • Grouped
  • Virtual
  • Adobe Commerceのストアフロントに Bundle products ります。

機能領域: Adobe Commerce フロントエンド

役割: ストアシストアプリユーザー(ストアアソシエイト)

テストタイプ: すべて陽性

関数
シナリオ
コメント
設定可能な製品
  • ユーザーが設定可能なオプション(有効なソース、在庫の割り当て済み)のみを表示できること、および在庫に一部の品目があることを確認します。子製品をチェックします。
  • 別のストアを選択する際に、使用できないオプションが取り消し線で表示されていることを確認します。
  • ユーザーが別のストアを選択すると、設定可能なオプションの選択が解除されることを確認します。
  • 設定可能な商品が既に買い物かごに入っていて、ユーザーが別のストアを選択した場合、その商品は在庫切れとして表示されることを確認します。
グループ化された製品
  • すべての子製品に次の機能がある場合は、顧客の「配信方法と Add to cart」ボタンが無効になっていることを確認します qty0 に設定します。
  • 少なくとも 1 つの子製品がに設定されている場合、顧客に対して配信方法が有効 qty なっていることを確認します 0.
  • メソッドが、有効になっ Store Pickup Delivery いる製品に対してのみ表示され、アクティブで Available for Store Pickup ることを確認します。 (子の製品を確認してください。)
バーチャル製品
仮想製品が In-store Pickup の配信方法を提供していないことを確認します。
バンドル製品
  • 少なくとも 1 つの子製品が無効になってい Available for Store Pickup 場合、顧客が店舗での受け取り配信オプションを使用できないことを確認します。
  • 少なくとも 1 つの子製品が無効になっ Available for Home Delivery いる場合、顧客がホーム配信オプションを使用できないことを確認します。
  • バンドル内の子製品の少なくとも 1 つが在庫切れであるかどうかを確認します。バンドル(親製品)も表示されます Out of stock の通りです。

チェックイン操作

テスト計画のこのセクションでは、次の機能のストア ピックアップ注文のチェックイン エクスペリエンスについて説明します。

  • 代替ピックアップ担当 – Alternate Pickup Contact ータを追加し、ストア・ピックアップ受注の Preferred Contact を選択するワークフローを検証します。

  • チェックイン フォーム – ストアの集荷注文に対してチェックイン要求を送信するワークフローを確認します。

機能領域: 買い物かごのチェックアウト、店舗の受け取り注文のチェックインフォーム

役割: 管理者、顧客、ストアの関連付け

テストタイプ: すべて陽性

代替ピックアップ連絡先

機能領域: 買い物かごチェックアウト

役割: 顧客

テストタイプ: すべて陽性

関数
シナリオ
期待される結果
代替ピックアップ連絡先
チェックイン
顧客が店舗内受け取りオプションを使用して注文を送信します。
チェックアウトプロセス中に、顧客は Alternate Pickup Contact のオプションを出荷手順で確認できます。
代替ピックアップ優先連絡先、チェックイン
顧客が店舗内受け取りオプションを使用して注文を送信します。 チェックアウト時に、顧客は Alternate Pickup Contact を追加します。
チェックアウトプロセス中に、お客様には配送手順に Preferred Contact のオプションが表示されます。
代替集荷連絡先詳細、チェックイン
顧客が店舗内受け取りオプションを使用して注文を送信します。 チェックアウト時に、顧客は出荷手順で Alternate Pickup Contact を選択します。
顧客には、連絡先の詳細(First name、Last name、Phone、Email)を入力するための入力オプションが表示されます。
代替受け取り、E メールでチェックイン
顧客が店舗内受け取りオプションを使用して注文を送信します。 チェックアウト時に、顧客は出荷手順で Alternate Pickup Contact を選択し、連絡先の詳細を追加して、注文を送信します。
顧客と代替担当者の両方が、注文のチェックイン E メールを受け取ります。
代替ピックアップ、オーダー詳細
顧客が店舗内受け取りオプションを使用して注文を送信します。 チェックアウト時に、顧客は出荷手順で Alternate Pickup Contact を選択し、連絡先の詳細を追加して、注文を送信します。
管理者には、保存された注文に関する追加の連絡先情報が表示されます。
代替集荷連絡先、店舗の関連付け注文ビュー
顧客が店舗内受け取りオプションを使用して注文を送信します。 チェックアウト時に、顧客は出荷手順で Alternate Pickup Contact を選択し、連絡先の詳細を追加して、注文を送信します。
Store Associate は、注文に関する追加の連絡先情報を FaaS/ChaS で確認できます。

チェックインフォーム

機能領域: チェックインフォーム

役割: 顧客

テストタイプ: すべて陽性

関数
シナリオ
期待される結果
チェックイン処理 – 要求の送信
チェックインフォームで、顧客はすべての必須フィールドに入力し、リクエストを送信します。
顧客が成功応答を受信します。
「チェックイン」アクション – リクエストの詳細を表示します
顧客がチェックイン要求を正常に送信した。
FaaS システムで注文ステータスが更新され、ストアの関連付け担当者は FaaS でチェックイン要求の詳細を確認できます。
「チェックイン」アクション – リクエストを 1 回だけ送信します。
注文のチェックイン要求を送信した後、顧客は再度チェックインするリンクを選択します。
チェックインフォームには、フォームを編集または再送信するオプションは表示されません。
チェックイン動作 – 到着を確認
FaaS では、店頭での集荷注文は集荷準備完了としてマークされます。 顧客は Ready for Pickup のメールを受け取り、Confirm Arrival を選択します。
顧客には、注文のチェックインフォームが表示されます。

ストアシストアプリ

テスト計画のこの節では、ストアアシストアプリで注文、選択、およびハンドオフのワークフローをテストするシナリオについて説明します。

機能領域: ストアシストアプリ

役割: ストアの関連付け

テストタイプ: すべて陽性

関数
シナリオ
期待される結果
1 回の注文でピッキングする – Happy Path、Curbside Picking
単一数量および複数数量の品目をピックします。 ニルの選択および縁側の選択は行われません(ステージングを使用)。
複数注文のピッキング – ハッピーパス、カーブサイドのピックアップ
単一および複数数量の品目 ニル・ピックおよび縁側ピックなし(ステージング時)
1 回の注文で商品を受け取る
単一および複数数量の品目 ニルの選択および店舗でのピックアップは行われません(ステージングを使用)
複数注文のピッキング – ハッピーパス、店舗でのピックアップ
単一数量および複数数量の品目をピックします。 ニルの選択および縁側の選択は行われません(ステージングを使用)。
1 回の注文ピッキング – 満足できないパス、店舗での受け取り
部分ピッキングおよびピッキングと店舗内集荷による単一品目および複数数量品目のピック(ステージングを使用)
複数注文のピッキング – 満足できないパスカーブサイドのピックアップ
部分ピッキングおよびピッキングと店舗内集荷による単一品目および複数数量品目のピック(ステージングを使用)
1 回の注文でピッキングする – 満足できないパス、カーブサイドのピックアップ
部分取り出しおよび非点弧取り出しを使用した単一品目および複数数量品目のピック(ステージングを使用)
注文 – ピッキング前にキャンセル
注文 – ハンドオフ前にキャンセル
注文 – 注文モジュールを検索
注文 – 検索とハンドオフのための手動チェックイン
注文済み – すべての品目が選択されているか、ピッカーによってマークされていない
バンドル品目で発注 – ピッキングおよびハンドオフ
注文が行われました – 拒否を含む受け渡し
注文 – すべての品目を拒否して引き渡します

デプロイ

ソリューションが設定され、仕様に合わせてテストされたことを確認したら、ステージング環境から実稼動環境にデプロイする準備が整います。

デプロイメントとテストは、インフラストラクチャと機能によって異なります。

TIP
クラウドインフラストラクチャプロジェクトでのAdobe Commerceのデプロイメントのガイドライン、チェックリスト、ベストプラクティスについては、Adobe Commerce開発者向けドキュメントの ストアのデプロイを参照してください。
recommendation-more-help
dd168ac6-a357-4bc5-ae6f-a7e463fa4dfb