小売割引

  • [アーティクル]

この記事は、Dynamics 365 Commerce の割引機能の概要について説明します。 さまざまな割引フォームにあるプロパティとおよび割引管理のベスト プラクティスについて説明します。 ただし、この記事では、さまざまな割引のタイプの詳細、たとえば、単純割引、数量割引、組み合わせ割引、およびしきい値割引などについては扱いません。 これらの詳細については、これらの割引タイプごとに作成された個別の記事で説明します。

小売業者は、柔軟な割引を必要としており、割引のスタイルとタイプは業界によって異なるため、コマースで割引を定義するにはさまざまな方法があります。 割引機能は、コア製品 (Supply Chain Management) の既存の割引機能に追加されたため、いくつかの重複機能があります。 その結果、割引タイプは、5 つの異なるエンティティ (顧客、ロイヤルティ プログラム、チャンネル、カタログ、および所属) にコンフィギュレーションすることができます。 割引オプションの数が多いため、割引戦略を計画して文書化することは特に重要です。

割引の作成

各割引タイプには、専用ページがあり、割引を作成および管理するために使用します。 コマースには、すべての割引ページおよび価格と割引の管理ワークスペースがあり、どちらも任意のタイプの新しい割引を作成するのに使用できます。

割引ヘッダーと割引明細行

すべての割引には、ヘッダー 1 つと 1 つ以上の明細行があります。 すべての割引タイプには、ヘッダーで定義されているプロパティがあり、一部の割引タイプには明細行ごとに定義されているその他のプロパティがあります。 たとえば、数量割引には数量の階層があります。 顧客は、多くの場合、割引ヘッダーの観点からのみコマースの割引を考え、割引ヘッダーを共有しているために割引のすべての明細行が互いに関連付けられているものと見なします。 ただし、割引のこのビューは非常に単純です。 単純割引と数量割引の場合、各割引明細行を、他の割引明細行と一部のプロパティを共有する独立した割引と考える方が正確です。 実際には、価格決定エンジンは、この方法だけで単純割引と数量割引を評価します。 単純割引および数量割引の各割引明細行は依存していません。 単純な割引の場合、割引の資格を得るために必要な数量または金額の条件がないため、各割引明細行が同じ割引の他のすべての割引明細行から独立していることを理解するのは難しくありません。 数量割引の場合、明細行は、割引の数量基準に到達させるために組み合わせることができると考えるかもしれませんが、そうではありません。 数量階層は、数量割引の行ごとに個別に到達する必要があります。 価格戦略で、複数の販売明細行を合計して数量基準に達したときに数量割引を適用する必要がある場合は、Microsoft では、それらの品目を補助カテゴリにグループ化し、そのカテゴリを数量割引明細行として構成することをお勧めします。

割引を作成するときは、割引の重複する明細行を常に回避するか最小限に抑えることをお勧めします。 重複する割引明細行は、同じ割引の 2 つ以上の割引明細行を同じ製品に適用できる場合に発生します。 この場合、価格決定エンジンは、最適な割引金額を見つけるために相互に評価する必要がある複数の独立した割引として割引を処理する必要があります。 さらに、割引定義を見ただけで、割引の内容をユーザーが把握することが難しい可能性があります。

注記

1 つの割引の行数が 1,000 に達すると、数量制限のある割引を有効にしたり、行を含む割引と除外行の両方を使用して割引を有効にしたりすると、パフォーマンス上の問題が生じます。 コール センターおよび POS 注文の価格計算よりかなり低い程度まで、パフォーマンスの低下が確認される場合もあります。 これらのパフォーマンス上の問題を回避するために、すべての割引製品を含むカテゴリを 1 つ作成し、そのカテゴリを使用して割引行を作成できます。

割引を管理する

すべての割引に共通する設定とオプション

このセクションでは、割引のすべてのタイプに共通するプロパティについて説明します。

割引を管理するときは、各割引オプションを個別に理解することが重要ですが、どのオプションが互いにどのような影響を与えるかを理解しておくことも同じように重要です。 割引の一般的な設定は、2 つのカテゴリに分類されます。 最初の分類は、考慮すべき割引をフィルター処理する設定です。 例としては、ステータス、通貨、および 測定単位 です。 2 番目のカテゴリの設定は、複数の割引が考慮されて適用される順序を制御します。 例としては、割引同時実行モード および 価格決定の優先順位 があります。 次の図は、割引の各種プロパティを示しています。

割引プロパティ。

割引 ID

このフィールドには 割引 というラベルが付き、割引を初めて作成したときに設定された割引ごとに固有の ID が保持されます。 割引 ID を後で変更することはできません。 コマース パラメーターでは、割引の種類ごとに独立した番号順序を設定することができます。 この場合、番号順序が競合しないことを確認します。 たとえば、各割引タイプに固有の接頭語を使用できます。 たとえば、discount には D、quantity には Q、mix and match には MM、threshold には T などです。

割引名

このフィールドは、割引の説明に使用される簡単な自由書式フィールドです。 このフィールドの文字列値は、Web カートに対応する Store Commerce アプリケーションと Store Commerce に表示され、Web 顧客レシート用に Store Commerce アプリおよび Store Commerce に印刷されます。 レジ担当者および顧客は、この説明を参照できます。 これは、Store Commerce アプリおよび Web 用 Store Commerce ユーザーおよび顧客が適用された割引を確認するためにを使用する主な手段です。

割引タイプ

Commerce には次の 5 つのタイプの割引があります: 割引、数量制限付き割引、数量、組み合わせ、しきい値。 割引タイプは最初に割引を作成した時に設定され、数量制限を変更することで 2 つの割引タイプを他の割引タイプに切り替える 割引 と 数量制限付き割引 を除き、後で変更することはできません。 割引タイプは、割引の資格を得るために満たす必要がある数量または金額の基準があるかどうかを決定します。

ステータス

割引のステータスは、有効 または 無効 です。 最初に割引を作成するとき、ステータスは 無効 です。 割引は、無効になっている場合にのみ編集できます。 Commerce スケジューラ パラメータ で 同期後に無効なマスタ データをクリーンアップ パラメータが有効になっている場合、チャンネルに割引データをプッシュすると、無効な割引は適用されません。 割引が以前に有効になり、同期完了後不要なマスター データをクリーン アップする パラメータが有効化されている場合、この新しいプッシュによりチャンネルから割引も削除されます。 ステータスを 有効 に変更すると、割引のタイプに応じて、割引を実行するさまざまな検証チェックが実行されます。 検証チェックの一覧は、不完全または定義が不十分な割引がコマース チャネルにプッシュされることを防ぐため、製品の最新の更新で増加しました。 割引を有効にするときに実行される検証の一覧の一部を以下に示します。

  • 割引には、少なくとも 1 つの割引明細行が必要です。
  • 割合割引の割合値は 0 (ゼロ) よりも大きく、100 以下にする必要があります。
  • 数量割引の数量値は、0 (ゼロ) より大きくなければなりません。 0 や負の金額は、有効となりません。
  • 割引には、少なくとも 1 つの価格グループが必要です。 価格グループを設定していない割引をトランザクションに適用することはありません。
  • 測定単位 (UoM) は数量割引と組み合わせ割引の明細行に必要です。
  • 2 つ以上の数量階層を持つ数量割引の場合、割引額は数量が大きくなると大きくなることが検証されます。
  • 2 つ以上のしきい値階層を持つしきい値割引の場合、層ごとの割引額は、それより前の層の最大割引以上である必要があります。
  • 組み合わせ最安値割引の場合、最安値の製品の数は、1 より大きく、かつ割引をトリガーするために必要な製品の数よりも少ない必要があります。

Currency

割引の通貨は、割引のすべての金額および価格フィールドの通貨を定義します。 割引タイプごとにフィールドのオプションは異なります。 通貨は、割引の計算時にもフィルターとして機能します。 Commerce では、すべての販売注文と Store Commerce アプリ/Web 用 Store Commerce トランザクションに通貨があり、価格決定エンジンは同じ通貨の割引のみを考慮します。

割引同時モード

このモードは、どの割引がトランザクションで競合し、どの割引が複合されるかを決めます。 このオプションの 3 つの値は 排他、ベスト価格、福利 です。

排他 割引は、すべてのその他の設定が同じの場合、常に ベスト価格 割引と 複合 割引の前に評価および適用され、同じ明細行に他のすべての割引が適用されるのを防ぎます。 2 つ以上の 排他 割引がベスト価格のために競合します。

割引の同時実行制御が、優先順位内のベスト価格と福利、優先順位間で組み入れない に設定された場合、同じ価格優先内のすべての 福利 割引が組み入れされ、組み合わされた結果は、同じ価格優先内で 最適価格 割引と競合します。 取引明細に割引が適用されると、価格決定優先順位が低いですべての割引が無視されます。

割引の同時実行制御を 優先順位内でのみ最高の価格 に設定した場合、すべての ベスト価格 と 複合 割引に設定すると、常に優先順位全体で複合化が行われると、すべてのベスト価格および複合割引が単一の価格決定の優先順位内で ベスト価格 割引として処理され、その価格決定の優先順位で最適な割引を決定するために競合します。 価格決定優先順位ごとに 1 つの割引のみを 1 つの製品に適用することができ、その 1 つの割引が ベスト価格 または 複合 割引の場合、価格決定優先順位が低いほど ベスト価格 または 複合 割引の最適な割引と複合します。

複数の割引がトランザクション明細行に適用されるとき、次の順序で適用されます。

  • 割引価格割引
  • 金額割引
  • 割合割引

両方のタイプがトランザクション明細行に適用される場合、組み入れ割引は、最良価格割引と競合します。 したがって、組み入れ 設定は、どの割引を組み入れるかを決定するために使用します。 使用される割引同時実行コントロール モードに応じて、複数の 組み入れ 割引を組み合わせることができ、同じ商品に適用される 最良価格 割引と競合します。 最大合計割引金額を持つ割引が適用されます。

割引勘定

コマースでは、個別の総勘定元帳 (GL) 勘定にトランザクションの割引金額を転記することができます。 割引 GL 勘定は、製品または顧客別に設定されています。 コマースには、転記時に、割引金額を区別する固有の方法が用意されています。 各タイプの割引を特定の GL 勘定に転記できます。 両方のオプションで、総勘定元帳で使用されている割引や割引タイプを決定することが簡単になります。

メモ

割引勘定転記機能が有効になると、コマース割引 GL 勘定から割引 GL 勘定に転記された割引を再分類するために追加の借方項目および貸方項目が作成されます。

クーポン コードが必要です

アプリのバージョン 7.2 から、割引にコール センター クーポンが統合されました。 割引の場合、クーポン コードが必要 が はい に設定されている場合、ステータス フィールドおよび標準日付フィールド 有効日 および 有効期限 は使用できません。 これらのプロパティは、クーポン ページにある同等のプロパティによって制御されます。

割引で クーポン コードが必要 が はい に設定されていると、Store Commerce アプリまたは Web 用 Store Commerce が提供されている場合にのみ割引はトランザクションに適用されます。 クーポン コードおよびバーコードの値は、クーポン という名前の個別のページで定義され、構成されます。 クーポン ページでは、割引にクーポンがリンクされています。 クーポン コードが必要 を いいえ に設定すると、クーポン コードは必要なく、割引が常にその価格グループに適用されます。

優先順位および価格決定優先順位の上書き

これら 2 つのフィールドは連携して動作します。 優先順位の上書き が はい に設定されていると、価格決定の優先順位 フィールドが編集可能になります。 割引に直接設定する価格決定の優先順位を選択できます。 優先順位の上書き が いいえ に設定されていると、優先順位は割引に関連付けられている価格グループの優先順位から継承されます。 複数の価格グループの関連付けの場合、優先順位番号は、割引に関連付けられているすべての価格グループの最上位の価格決定優先順位を選択することによって決定されます。

関連するすべての価格グループと一致

Commerce バージョン 10.0.16 以降では、すべての割引フォームで関連するすべての価格グループと一致という構成を使用できます。 構成が有効な場合、割引に関連するすべての価格グループがトランザクションに適用される場合にのみ割引が考慮されます。 たとえば、「PG-Student」 (学生所属の価格グループ) と「RP-Houston」 (ヒューストン店舗の価格グループ) という 2 つの価格グループが割引に関連付けられていて、関連するすべての価格グループと一致 が有効になっている場合、割引はヒューストンの店舗で買い物をする学生に対してのみ考慮されます。 この構成は、所属およびロイヤルティ ベースの割引を限定された店舗に制限する方法を提供します。

メモ

2 つ以上のチャネル価格グループが割引に関連付けられていて、関連するすべての価格グループと一致が有効になっている場合、トランザクションは 1 つの店舗にのみ関連付けることができるため、割引は適用されません。 したがって、割引に関連付けられているすべての価格グループが一致しません。

Description

このフィールドは、自由形式テキスト フィールドです。 これは、Web システムやトランザクションで Store Commerceアプリ/Web 用 Store Commerce で使用されません。

免責事項

このフィールドは、自由形式テキスト フィールドです。 これは、Web システムやトランザクションで Store Commerceアプリ/Web 用 Store Commerce で使用されません。

行タイプ

このフィールドは、すべての割引明細行にあります。 含める と 除外する のいずれかが指定されます。 このフィールドを カテゴリ、製品、および バリアント フィールドと組み合わせて使用して、割引が適用される製品のセットを定義します。 割引を除外する明細行は常に割引を含める明細行をオーバーライドします。 行タイプ が 除外 の場合、割引明細行の他のフィールドの多くが淡色表示になります。適用されないためです。

測定単位

測定単位 (UoM) は、しきい値割引明細行を除くすべての割引明細行上のフィールドです。 このフィールドは、コマース のラベル単位です。 測定単位 フィールドは、トランザクション明細行に割引を適用するかどうかを決定するためにフィルター として機能します。 トランザクション明細行の UoM は、割引明細行で UoM と一致する必要があります。 それ以外の場合、割引明細行は割引計算中に考慮されません。 割引の計算中に UoM 換算は行われません。

カテゴリ、製品、バリアント、および製品分析コード

カテゴリ、製品、バリアントおよび分析コード は、すべての割引に共通する最後の割引の設定です。 これらのフィールドは、各割引明細行で設定され、割引されるものを指定します。 価格決定エンジンがトランザクションに適用可能な割引を検索するとき、フィルターとして動作します。 これらのフィールドはそれぞれのルールにしたがって相互に関連しあっています。カテゴリには製品が含まれ、製品のサイズ、色、スタイル、および構成はさまざまです。

価格決定は、割引の計算中に割引の順序を決定するためにカテゴリ、製品、およびバリアントの親/子の関係を使用しません。 この動作は、価格決定エンジンが販売価格の売買契約を処理する方法とは異なります。 たとえば、あるカテゴリの 10% の割引と同じカテゴリの製品の 5% の割引の両方が考慮されます。 他のすべてのプロパティが同じであり、両方が組み合わせらる 複合 に割引が設定されていない場合、2 つの割引金額の大きい方が使用されます。 カテゴリ割引で製品割引の使用を強制する場合、価格決定の優先順位または割引の同時発生モードを使用して、ある割引を別の割引より前に適用することができます。

割引を編集するとき、カテゴリ、製品、バリアント、分析コード 設定が相互のフィルターとして機能します。 製品またはバリアントが直接入力される場合、カテゴリおよび製品フィールドが コマース カテゴリ階層から自動的に設定されます。 次のセクションでは、これらの各フィールドの詳細説明を提供します。

カテゴリ

少なくとも、カテゴリ フィールドを設定する必要があります。 製品カテゴリ階層から、または補助カテゴリ階層からカテゴリを選択できます。 ただし、チャネル ナビゲーション階層または他の非コマース階層からカテゴリを選択することはできません。 割引明細行にカテゴリだけが指定されている場合、他のすべての割引基準 (通貨や UoM など) を満たしていれば、そのカテゴリ内のすべての製品 (割引が作成された後にカテゴリに追加された製品を含む) に割引が適用されます。

メモ

割引明細行で選択したカテゴリは、特定の階層です。 したがって、ほとんどのコマース フィールドでできるように、フィールドに部分的な値を入力して値を指定することはできません。 フル カテゴリ名を入力した場合は、ドロップダウン リストが展開され、そのカテゴリが選択されます。 さらに、Alt + 下方向キーを押して選択ダイアログ ボックスを展開し、Tab キーを押してドロップダウン リスト内で階層選択と階層ツリーの間で移動することができるため、マウスがなくてもフィールドを使用できます。

カテゴリと連携する機能は、割引と売買契約割引の主な差別化要因であり、売買契約の割引を使用しないことをお勧めする主な理由です。 カテゴリは、複数レベルの階層で構成されます。 対照的に、売買契約で使用される品目割引グループは、グループは単一レベルのみであり、各グループは 3 つの売買契約割引タイプ (明細行割引、複数行割引、および合計割引など) のいずれかに固有です。 したがって、売買契約では、すべての 3 つの売買契約割引タイプに同じ製品セットを使用する場合、3 つの独立した割引グループを作成して管理する必要があります。 ただし、割引の場合、1 つのカテゴリのみを管理する必要があります。 4 つのすべての割引タイプでそのカテゴリを使用することができます。 価格調整、品揃え管理、およびロイヤルティ管理で同じカテゴリを使用することもできます。

品目

製品は、リリースされた製品またはリリース済製品マスターにすることができます。 すべての割引は、会社固有です。 したがって、これらはリリースされた製品のみ処理します。 製品マスターを選択した場合、通貨や UoM などの他のすべての割引条件が満たされる限り、割引を作成した後にリリースされたバリアントでも、製品のすべてのバリエーションに割引が適用されます。

バリアント

割引明細行でバリアントを選択すると、通貨や UoM などの他のすべての割引条件が満たされる限り、割引はそのバリエーションにのみ適用されます。

分析コード

Retail 8.1.1 リリース以降、製品の分析コード レベルで割引を設定する機能が追加されました。 この機能により、割引明細行として製品の 1 つ以上の分析コードを選択する際に柔軟性が生まれます。 この柔軟性により、マーチャンダイジング マネージャーは、割引が適用されるバリアントを個別に追加する必要がなくなります。 たとえば、特定のスタイルを持つすべてのバリアントに割引を指定したり、特定の色およびスタイルのすべてのバリアントに割引を指定したりすることができます。

メモ

分析コードに基づいてプロモーションを設定する機能は、価格調整ではサポートされていません。 分析コードを定義するための特定のインターフェイスは、Retail バージョン 10.0.4 以降で削除されます。

改善された割引計算

適切な割引を検索して計算する機能は、小売業者の全体的な業務効率に影響する重要な要素になります。 Commerce バージョン 10.0.23 リリース時点で、Commerce の価格決定エンジンには、フラット化されたデータ スキーマを使用して実行時の割引検索および計算を高速化する、改善された割引計算機能が含まれています。 この機能を有効にすると、Commerce 本社で構成された割引データがチャネル データベースに送信される前に非正規化されます。 フラット化された割引データの公開は、割引が有効になったときに自動的にトリガーされます。

改善された割引計算機能を有効にするには、以下の手順に従ってください。

  1. Commerce 本社で、Retail と Commerce > 価格決定と割引の順に移動します。
  2. コマース割引の処理を選択します。
  3. 表示されるダイアログ ボックスで、バッチ ジョブを反復ベースで実行します。
  4. ワークスペース > 機能管理に移動します。
  5. フラット化された割引テーブルを使用して割引の計算パフォーマンスを向上させる機能を検索し有効化します。
  6. 1020 (価格と割引) および 1070 (チャネル コンフィギュレーション) 配送スケジュール ジョブを実行します。

注記

  • 特に Commerce 価格決定エンジンでカスタマイズを行う場合は、運用環境で有効にする前に、改善された割引計算機能を十分にテストしてください。
  • 改善された割引計算機能は、Commerce バージョン 10.0.32 以降を実行している環境では既定で有効になっています。 この機能を有効にすると、割引が有効になったとき、または割引に関連付けられている製品マスターに新しい製品バリアントがあるときに、バッチ ジョブがスケジュールされます。
  • 複数の "コマース割引の処理" バッチ ジョブを間違ってスケジュールし、他のジョブの実行をブロックする 問題 は、Commerce 10.0.38 リリースで修正されました。 ユーザーは、修正した Commerce バージョンにアップグレードするまで、フラット化された割引テーブルを使用して割引の計算パフォーマンスを向上させる 機能を無効にすることでこの問題を回避することができます。

ベスト プラクティス

  • 割引を作成する前に、割引戦略および手順を文書化します。 製品の使用の発展に応じて、ドキュメントを最新の状態にしてください。
  • 割引タイプごとに独立した番号順序を使用し、割引 ID 自体が割引タイプを示すように番号順序を構成します。 たとえば、さまざまな英数字定数を、各割引タイプの ID の接頭語として付けます。数量には Q、組み合わせには MM などです。
  • 割引を有効にする前に、価格シミュレーションを使用して、割引のコンフィギュレーションをテストします。 価格シミュレーションには、無効になっている割引を有効として扱うことができるオプションがあります。 このオプションは、有効になる前に割引をテストできるように設計されました。
  • 有効でなくなった場合に割引の有効期限が切れます。 このようにして、価格決定エンジンがトランザクションの際に考慮する割引の合計が無限に増えないようにします。 そうしないと、時間の経過と共に割引の計算のパフォーマンスに影響する可能性があります。
  • クリアランス製品や昨シーズンの製品など、補助カテゴリを使用して製品をグループ化します。
  • 重複する割引明細行は常に回避するか最小限にしてください。