電子商取引プラットフォームにおける注文設計モデルを詳しく解説！

ビジネス サブシステムとして、注文システムは、電子商取引、小売、ケータリング、教育、医療の SaaS システムで非常に一般的です。

プラットフォーム上で取引が行われる限り、注文システムは避けられません。なぜなら、最終的にはすべての取引は注文の作成と支払いによって完了する必要があるからです。

注文システムの発生頻度が高く、さまざまなビジネスで注文設計のアイデアが類似しているため、これを基盤となるシステムとして抽象化し、一連の注文設計モデルを確立して、さまざまなビジネス システムへの迅速な適用を容易にすることができます。

電子商取引を例に挙げてみましょう。

電子商取引の最も複雑なコアシステム (またはモジュール) として、注文は他のシステム モジュール上に構築されます。

商品、クーポン、メンバーシップ、マーケティング活動、住所情報、ポイント、配送、ショッピング カート、支払い、配達、受領などを含むモジュールはすべて注文と密接に関連しています。いずれかのモジュールに変更を加えると、注文に影響する可能性があります。注文は取引プラットフォームのコアサブシステムであると言っても過言ではありません。

注文に含まれる情報:

電子商取引注文システムのアーキテクチャ:

したがって、適切な注文管理のために最も重要なことは、包括的なカバレッジと強力なスケーラビリティです。

注文は主に注文作成と注文管理の 2 つの部分に分かれています。

1. 注文の作成

注文の作成は、C エンドユーザーと B エンドユーザーによって開始され、注文システムで生成されます。

注文作成用のノードがページに表示されます。注文送信ページで「注文を送信」ボタンをクリックした瞬間に注文が作成されます。

もちろん、表面的には「注文を送信」をクリックすると注文の作成がトリガーされますが、舞台裏では、作成プロセスによって上記のさまざまなモジュールが呼び出され、多くの論理的判断が散在します。

注文送信ページのプロトタイプ:

以下は注文によって生成された検証です。

つまり、「注文を送信する」という瞬間に、複数の情報が論理的に判断されることになります。

配送情報: 配送方法と配送先住所。

配送方法や配送先が記入されているか、（テイクアウトの場合）配送先住所が配送範囲を超えていないかなどを判断する必要があります。

商品

（１）商品が店頭に並んでいるかどうかを判断する必要がある。

（２）商品が売り切れているかどうか

（３）商品の在庫が注文数量より少ないかどうか。（ギフトがある場合）ギフトが在庫切れかどうか。

貨物

（1）配送先住所を選択すると、バックグラウンドで運賃テンプレートに従って運賃が自動的に計算され、[注文送信]ページに表示されます。

（２）注文時に、貨物情報に変更がないか確認する必要があります。

プロモーション

現在のユーザーと注文品目に適用可能なすべてのプロモーション活動を決定する必要があります。プロモーション活動は一般的にプラットフォームレベルと店舗レベルの2つのレベルに分けられます。

（１）プラットフォームレベル：プラットフォーム上の商品のプロモーション活動

（２）店舗レベル：店舗内での商品のプロモーション活動。

もちろん、このような活動にはいくつかの制限があり、例えば

（１）参加するにはいくらの注文金額が必要ですか？

（２）一定レベル以上の会員のみ

（３）参加できるのは特定のカテゴリーまたは指定された製品のみ

（4）複数のアクティビティに同時に参加するための条件を満たす場合は、優先順位が最も高いアクティビティにのみ参加できます。

プロモーションの数や複雑さに応じて異なります。

会員特典

ご注文の際には、会員レベルとそれに応じた優待権が変更されたかどうか、また、利用可能なポイント数が変更されたかどうかを確認する必要があります。

クーポン

（１）クーポンが使用されたか否かを判断する必要がある。

（２）有効期限が切れているかどうか

（３）適用期間内であるかどうか

（４）使用の有無等

注文が送信されると、注文が作成されます。この時点で、注文モジュールは他のモジュールにそれに応じて協力するように要求する指示も発行します。

（１）注文品の在庫は商品モジュールで凍結する必要がある

（２）注文に使用したクーポンはクーポンモジュールでステータスを変更する必要があります

（３）注文に使用されたプロモーション権には使用済みと表示する必要があります。

（４）注文により減算されたポイントは、利用者のポイント等から減算されるものとします。

もちろんテイクアウトの場合も、店舗が休業中かどうか、店舗が配達方法を開いているかどうか、注文価格が最低配達価格を満たしているかどうかなど、注文を送信する際の状況を判断する必要があります。変更がある場合は、ユーザーにそれに応じたプロンプトが表示されます。

2. 注文管理

注文が作成されると、注文管理段階に入ります。

C終了ページ:

B面の注文管理ページ：

注文ローテーションプロセス:

注文状況について

ユーザー（購入者）の観点から見ると、電子商取引プラットフォームの注文フローのステータスは、一般的に次の 6 つの状態になります。

（1）支払い保留：ユーザーが注文を送信した後、支払いが行われるまでの間、注文は支払い保留状態となり、販売者側も支払い保留状態となります。

（2）発送保留：ユーザーが支払いを完了すると、注文ステータスが「発送保留」に変わり、同時に販売者側も「発送保留」ステータスに更新されます。

（3）受領待ち：販売者がバックグラウンドで発送を確認すると、注文ステータスは購入者側では「受領待ち」、販売者側では「発送済み」と表示されます。双方の表示には違いがあります。

購入者が商品を受け取った後に確認をクリックしない場合、プラットフォームには通常、一定期間（Taobaoの場合は14日間）が設けられます。14日後、システムは自動的に受領を確認し、取引が成功したものに変更します。

（4）返金処理中：注文が「返金処理中」ステータスに変更される状況は2つあります。

1) 注文が「受領保留中」の状態の場合、つまり販売者が商品を発送した後、購入者が返金すると、注文ステータスは直接「返金中」に変わります。

2) 商品が「発送保留中」の状態にある間に、購入者が注文をキャンセルしたり、販売者が全額返金を要求したりした場合、商品は返金状態になります。

3) 購入者が商品の受領を確認した後、返金を申請すると、ステータスは「返金処理中」になります。通常、電子商取引プラットフォームは、受領確認後 7 日以内であれば理由なく返品を受け付けます。

（5）取引完了：注文が「取引成功」に変更される状況は2つあります。

1) ユーザーが商品の受領を確認します。

2) 購入者が一部返金を申請し、返金処理が完了し、残りの商品が受領されたことが確認されると、注文は「取引成功」に変更されます。

（6）取引終了：「取引終了」が発生する状況は3つあります。

1) 「取引成功」後に全額返金が開始され、完了後に返金プロセスが「取引終了」に変更されます。

2) 購入者が注文をキャンセルする/注文が「支払い保留中」のときにタイムアウトする。

3) 注文が「発送待ち」の場合、購入者は返金を申請し、販売者が確認した後、注文は「取引終了」に変更されます。

優先配分について

なぜ割引の共有を検討する必要があるのでしょうか? 注文時に特定の割引アクティビティが使用され、注文が部分的に払い戻された場合、商品の元の価格を直接購入者に払い戻すことはできません。これは、販売者に多大な損失をもたらすためです。

したがって、注文が生成されると、割引アクティビティを使用する製品の割引割り当てが計算されます。

より複雑な例を見てみましょう。このケースには、プラットフォーム間の店舗間プロモーション、店舗プロモーション、クーポン、割引が含まれます。

そして優先順位に従って、商品A+Bは店舗Aの活動1に参加して（100+200-50）=250元になり、その後A+B+Cはプラットフォームの活動2に参加し続け、（250+300-100）=450元になります。最後に、プラットフォームバウチャーを使用した後の支払いは（450-150）=300元、つまり最終支払いは300元になります。

つまり、参加はアクティビティ 1 > アクティビティ 2 > バウチャーの優先順位に基づいて行われます。

返金時にバウチャーを返却できないと仮定して、注文が生成されたときに、各割引層を割り当てた後の A、B、C の返金可能金額を計算してみましょう。

第1層: アクティビティ1が割り当てられたあと

商品A = 100-50/(100+200)*100 = 83.33元

商品B = 200-50/(100+200)*200 = 166.67元

商品C = 300元

第2層: アクティビティ2が割り当てられた後

商品A = 83.33-100/550*83.33 = 68.18元

商品B = 166.67-100/550*166.67=136.37元

商品C = 300-100/550*300 = 245.46元

注: 83.33+166.67+300=550元

3番目の層: バウチャーが割り当てられた後

商品A = 68.18-150/450*68.18 = 45.45元

商品B = 136.37-150/450*136.37=90.91元

商品C = 245.46-150/450*245.46=163.64元

注: 68.18+136.37+245.46=450元

したがって、優先順位の高いものから低いものまでの 3 段階の優先割り当て後、最終的な実際の払い戻し額は、A の場合は 45.45 元、B の場合は 90.91 元、C の場合は 163.64 元になります。

注文の分割について

電子商取引プラットフォームでは、ショッピングカート機能があれば、店舗をまたいで商品を購入する購入者が存在します。

たとえば、注文にはストア A からの商品 A が 1 つとストア B からの商品 B が 1 つ含まれています。購入者にとっては注文は 1 つだけですが、プラットフォームにとっては、A の注文情報をストア A にプッシュし、B の注文情報をストア B にプッシュする必要があるため、購入者の注文を分割する必要があります。

また、ストア A に送信された注文の場合、注文に複数の商品 A、B、C が含まれていると、配送注文も分割され、たとえば、A と B は一緒に発送され、C は別々に発送されることがあります。

著者: スマートチーム

出典: Simat Team (lifelaosiji)