リリース12
E05612-01
目次
前へ
次へ
| Oracle Advanced Pricingインプリメンテーション・マニュアル リリース12 E05612-01 | 目次 | 前へ | 次へ |
この章では次のトピックについて説明します。
Oracle Advanced Pricingは、基本価格設定コンポーネントが含まれているOracle Order Managementと共通コード・セットを共有します。Oracle Order Managementのライセンスを持っているユーザーはこのセットの基本機能を使用でき、Oracle Advanced Pricingのライセンスを持っているユーザーはこのセットの全機能を使用できます。
SQL*Plus内からSQL文「select qp_util.get_qp_status from dual;」を発行し、Oracle Advanced Pricingのインストール・ステータスを取得できます。
次の表は、get_qp_statusの値を示します。
| 値 | 意味 |
|---|---|
| S | 「共有」インストール。基本価格設定機能のみ使用できます。 |
| I | 「フル」インストール。Oracle Advanced Pricingの全機能を使用できます。 |
価格設定機能を「共有」としてインストールすると、設定フォームに表示される機能が制限されます。次に示すような複数の方法によって機能が制限されます。
ユーザーが選択できる値リストの制限。たとえば、リスト・タイプ・コードの値リストには、値引、追加料金および運送費リスト・タイプのみ表示されます。
フィールドの無効化。基本価格設定ユーザーが使用できないフィールドは、ウィンドウ内でグレー表示になるか、または表示されません。
基本価格設定ユーザーが使用できないフィールドのデフォルト設定。たとえば、基本機能セットを使用する場合、「非互換グループ」フィールドは、自動的に「レベル 1 非互換性」にデフォルト設定されます。
リージョンとタブの変更。たとえば、Oracle Advanced Pricingがインストールされていない場合、Oracle Advanced Pricingのモディファイアのタブ（「クーポン」、「販促アップグレード」）は表示されません。
価格設定エンジンおよび価格設定APIは、Oracle Advanced Pricingがインストールされている場合のみ使用できます。
注意: 価格設定エンジンは、基本価格設定およびOracle Advanced Pricingの共通コンポーネントですが、APIのGet_qp_statusを実行しません。価格設定エンジンは、APIおよび設定フォームで許可されているとおりのユーザー設定を戻します。
Oracle Advanced Pricingにより、Oracle Order Managementの価格設定機能が大幅に強化されます。Oracle Advanced Pricingと基本価格設定は両方とも、次を目的としています。
ユーザーが、直観的なインタフェースを介して、価格設定の複雑さを感じることなく価格設定を行えること
販促管理およびE-Businessでの価格設定に新機能を組み込むこと
様々な業界において、価格設定に対する顧客の個々のニーズに柔軟に対応できること
アーキテクチャに関する変更および新機能
Oracle Advanced Pricingのアーキテクチャに関する主な機能と新機能は、次のとおりです。
新規データ・モデル: 価格表、値引、価格設定ルールを含むすべての内部価格設定データは、Oracle Advanced Pricing内部の共通の表セットに保存されます。このデータ・モデルには、拡張されたE-Businessにおけるニーズをサポートするために必要な様々な構成が含まれています。
Oracle Advanced Pricingは、Oracle Order ManagementおよびOracle iStoreなどのOracleカスタマ・リレーションシップ・マネジメント（CRM）製品と統合されています。価格設定エンジンは、オンデマンドで呼び出され、呼出し時に適切なパラメータを渡します。このパラメータは、単一行または複数行の呼出しとして、価格設定要求構造に渡されます。パラメータおよび結果の受渡しは、APIを介して実行されます。
Oracle Advanced Pricingは、呼出し側アプリケーションからの起動時に、この価格設定要求構造を受け取ります。この価格設定要求では、起動時に渡されたパラメータに基づいて内部表を参照し、定義済のAPIに結果セットを戻します。
価格表、モディファイアおよび算式の表に対して、多言語サポート（MLS）が提供されています。
Oracle Advanced Pricingエンジンは、検索エンジンと計算エンジンで構成されています。
検索エンジンでは、クオリファイアと価格設定属性を使用して、価格表とモディファイア・リスト明細を選択します。これらは、適格性、非互換性、排他性および優先についての各ルールに従って、価格設定要求に適用されます。
検索エンジンでは、有効日に基づいて価格表および価格表明細を選択します。次に、呼出し側アプリケーションから提供される価格設定有効日と次の日付を比較して、価格表や価格表明細が指定された価格設定日に対して有効かどうかを判断します。
価格表
価格表: 有効日範囲
価格表明細: 開始日と終了日
価格表クオリファイア: 開始日と終了日
モディファイア・リスト
モディファイア・リスト: 有効日範囲
リスト・クオリファイア: 開始日と終了日
モディファイア・リスト明細: 開始日と終了日
明細クオリファイア: 開始日と終了日
算式
価格設定算式: 有効日範囲
モディファイア・リストでの日付範囲の追加
モディファイア・リストには、2つの日付範囲と、各範囲の日付タイプが含まれています。これによって、日付の適格性をモディファイア・リストに追加定義できます。シードされている日付タイプの値は、次のとおりです。
受注日
要求出荷日
たとえば、夏季販促期間が6月1日〜8月31日であるとします。顧客がこの販促品を受け取るには、7月31日までに注文する必要があるとします。この場合、販促品の有効日は6月1日〜8月31日で、これに追加して、受注日タイプの日付範囲が終了日を7月31日として定義されます。
注意: この2つの日付範囲が両方ともモディファイア・リストに対して定義されている場合は、両方の基準が満たされる必要があります。たとえば、販促品XYZに、日付範囲が12月1日〜12月31日の受注日タイプが定義されているとします。また、この販促品には、2番目の日付タイプとして日付範囲が12月15日〜12月31日の要求出荷日が定義されているとします。この場合、販促品を受け取るには、受注日と要求出荷日の両方が日付範囲内にある必要があります。この2つの基準をOR条件で定義する場合は、クオリファイアを使用する必要があります。
有効/無効なリスト
検索エンジンの選択対象となるには、リストが「有効」とマークされている必要があります。有効フラグがno（無効）に設定されていると、リストが価格設定日に対して有効な場合でも、検索エンジンではそのリストは考慮されません。
価格設定の通貨
単一通貨価格表の場合、検索エンジンは、取引の通貨を価格表またはモディファイア・リストの通貨と照合します。取引と同じ通貨で定義されているリストのみが選択されます。取引の通貨は、価格設定要求構造に含まれている必要があります。
複数通貨で取引の価格を設定するには、取引の価格を設定する通貨ごとに価格表とモディファイア・リストを設定します。算式機能を使用すると、基準通貨の価格表とモディファイア・リストを取引通貨に換算できます。取引通貨を算式の価格設定属性として渡します。
複数通貨価格表の場合、検索エンジンは、取引通貨と、この取引通貨に対応する基準通貨または換算通貨を持つ価格表の通貨とを照合します。価格設定エンジンは、基準通貨から価格を換算し、設定されている換算ルールに基づいて取引通貨を計算します。検索エンジンは、取引の通貨をモディファイア・リストの通貨と照合します。取引と同じ通貨で定義されているモディファイアのみが選択されます。取引の通貨は、価格設定要求構造に含まれている必要があります。
複数通貨で取引の価格を設定するには、複数の通貨換算が添付された複数通貨価格表を設定し、取引の価格を設定する通貨ごとにモディファイア・リストを設定します。
取引の適切な価格設定データの識別
検索エンジンでは、データ・ソースが取引の価格を設定するのに適切かどうかを判断するために、データ・ソースを識別する必要があります。たとえば、契約明細の価格を導出する場合は、契約の価格を設定するために設定された価格表のみを識別する必要があります。
ソース・システム識別子は、価格設定データを作成したアプリケーションを識別するもので、すべての価格表とモディファイア・リストに記録されています。これは、Oracle Order Management、Oracle MarketingおよびOracle Service Contractsでも同様です。
要求タイプは、価格設定対象の取引のタイプを識別します。価格設定の各要求明細は、要求タイプを使用して識別する必要があります。これは、Oracle Order ManagementおよびOracle Order Captureでも同様です。
要求タイプを1つ以上のソース・システムにマップして、取引の価格設定に使用する価格設定データのソースを定義します。たとえば、価格設定要求明細に要求タイプ「受注」がある場合、検索エンジンは、このタイプの要求にマップされたソース・システムのデータのみを考慮します。次の図は、ソース・システムと要求のマッピングの概念を示しています。
ソース・システムと要求のマッピングの概念
取引の価格設定のフェーズ
ソース・システム処理フローにおいて価格設定の処理が必要な場合、ユーザーは、価格設定フェーズと価格設定イベントを使用して価格設定取引を構成できます。価格設定フェーズと価格設定イベントでは、取引処理フロー内のその時点で要求へ適用するために考慮する価格設定データも定義します。取引の価格設定は、取引全体の価格を一度に設定するのではなく、個々のアクティビティに細分化できます。
価格設定イベントは、ソース・アプリケーションの処理フローの特定の時点で、価格設定エンジンによるサービスが必要になると発生します。ソース・システム内の価格設定イベントがトリガーとなって、取引、特定の取引明細、および、取引全体または特定の取引明細に適用される価格調整、特典または手数料についての基準価格が決定されます。
価格設定フェーズでは、検索エンジンでどのモディファイアを考慮するか、およびそれらのモディファイアをどのような順序で要求に適用するかが制御されます。価格設定フェーズのいくつかの属性によって、フェーズ内に配置できるモディファイアが決まります。たとえば、価格設定フェーズの価格表タイプが「手数料」の場合、フェーズ内に配置できるのは、このタイプの価格表明細のみです。フェーズ内に配置するモディファイアを制御するために使用されるフェーズ属性は、次のとおりです。
モディファイア・レベル・コード
リスト・タイプ・コード
リスト明細タイプ・コード
注意: すべての価格表は、シードされているフェーズ0のリスト明細基準価格に自動的に配置され、別のフェーズに割り当てることはできません。
価格設定イベントは1つ以上の価格設定フェーズにマップできます。また、価格設定フェーズは複数の価格設定イベントに割り当てることができます。次の図は、価格設定イベントとフェーズのマップ方法を示しています。
価格設定イベントとフェーズのマッピング
この図で示す方法によって、次の価格設定ビジネス・ルール・タイプを実装できます。
すべての運送費と特別手数料は、出荷時に計算する。
大量バッチ環境で受注ボリュームの合計が導出された後、クロス受注ボリューム値引は、1日の終わりに適用する。
クーポンを与えるのは、ショッピング・カート内の全品目の価格が設定され、ユーザーが最終チェックアウトに進んだ後のみとする。
クオリファイアに基づく価格表とモディファイア・リストの選択
クオリファイアは、価格設定エンジンが価格表、価格調整、または特典や手数料を適用するための条件を1つ以上指定する、ユーザー定義のルールです。検索エンジンの処理中にクオリファイアで記述された条件がTRUEと評価されると、検索エンジンでは、そのルールに関連付けられた価格設定オブジェクトが適格とみなされます。
多くの企業が、複数の顧客階層にわたって、また顧客階層の様々なレベルで、価格と値引を適用しています。ビジネスで価格と値引を設定しているレベルごとに、クオリファイアによる条件付きのテストができます。
価格表、値引または販促を作成するときに、事前定義のクオリファイアを使用して、価格またはモディファイアに対する適格者を定義できます。
クオリファイア属性と演算子を組み合せて、価格表ヘッダーまたはモディファイアの認定条件を作成します。次の演算子を使用できます。
=
BETWEEN（>=および<=を含む）
Not =
次の例のように認定条件を使用して、価格、販促などに対する適格を定義します。
顧客 = XYZ
販売テリトリ = 北東地区
受注額 > 100ドル
契約署名日が12月1日〜12月31日の間
取引明細の価格を設定するとき、検索エンジンは、価格表ヘッダーの認定条件と、価格設定要求明細のクオリファイア値を比較します。価格設定要求明細のクオリファイアは、ディメンション・ソースを使用して作成されます。たとえば、価格表の適格の条件が「市場セクター」=「顧客製品」で、「市場セクター」クオリファイアの値が「顧客製品」の場合、その取引明細の価格設定でその価格表を使用できます。価格表ヘッダーのクオリファイアがモディファイア・リストに適合している場合、検索エンジンは、明細レベルのすべてのクオリファイアも適合していることを確認します。
クオリファイアをグループ化し、グループ化番号を使用したAND/OR条件を作成できます。たとえば、顧客が優先顧客で、かつ150ドル以上購入する場合に10%の値引を適用する場合、その認定条件は、同じクオリファイア・グループ内に複数のクオリファイアを作成することで定義できます。
| クオリファイア・グループ | クオリファイア属性 | 演算子 | 値:自 | 値:至 |
|---|---|---|---|---|
| 1 | 顧客区分 | = | 優先 | 適用なし |
| 1 | 受注額 | BETWEEN | 150 | 99999999999 |
顧客が優先顧客であるか、または150ドル以上購入する場合に10%値引するという要件の場合、認定条件は異なるクオリファイア・グループ内にクオリファイアを作成することで定義できます。
| クオリファイア・グループ | クオリファイア属性 | 演算子 | 値:自 | 値:至 |
|---|---|---|---|---|
| 1 | 顧客区分 | = | 優先 | 適用なし |
| 2 | 受注額 | BETWEEN | 150 | 99999999999 |
1つのクオリファイア・グループに、複数のクオリファイアを含めることができます。
あるクオリファイアがすべての認定条件に対して必須で、すべてのクオリファイア・グループに含まれている必要がある場合は、クオリファイア・グループ番号として-1を設定できます。検索エンジンは、他のすべてのグループをチェックする前に、必ずこの条件が満たされていることを確認します。 たとえば、1つの注文に対して10%の値引を受ける条件は、顧客が優先顧客であること、または顧客が150ドル以上購入して英国のWebサイトから発注していることで、いずれの場合も顧客はVisaカードで支払う必要があるとします。この場合は、次のように定義します。
| クオリファイア・グループ | クオリファイア属性 | 演算子 | 値:自 | 値:至 |
|---|---|---|---|---|
| -1 | クレジット・カード・タイプ | = | Visa | 適用なし |
| 1 | 顧客区分 | = | 優先 | 適用なし |
| 2 | 受注額 | BETWEEN | 150 | 99999999999 |
| 2 | Webサイト・ドメイン | = | .co.uk | 適用なし |
価格設定属性: 価格設定の対象の選択
価格設定属性は、価格を設定または変更する対象を定義するユーザー定義の属性です。属性には、品目の価格に影響を与えるファクタ、品目の作成を必要としない追加定義を提供するファクタ、または製品階層内の品目より高いレベルでの価格と値引の設定を管理するファクタが含まれます。
次に、価格設定属性の例を示します。
品目X:
A級の価格は60ドル
B級の価格は55ドル
C級の価格は50ドル
次の項目に基づく、コピー機のサービス業務の価格設定:
サービス・センターからの距離
コピー機の使用年数
環境
受講者数に基づく研修コースの値引:
受講者が1〜5名の場合は10%値引
受講者が6〜10名の場合は12%値引
受講者が10名以上の場合は15%値引
すべてのコンタクト・レンズの価格を1組2.25ドルに設定
価格設定属性は、コンテキストおよび属性に基づいて定義されます。様々なコンテキストで価格設定属性を作成すると、ビジネス上の用途に従って属性をグループ化できます。品目コンテキストは、製品の価格設定階層の定義用に確保されています。価格および値引が設定される製品階層の各レベルは、このコンテキストのセグメントとして定義する必要があります。
| 価格設定カテゴリ: | 製粉商品 |
| 価格設定サブカテゴリ: | 小麦粉 |
| マージン・グループ: | ブランドの小麦粉 |
| マージン・サブグループ: | Homepride社 |
| 製品グループ: | ホワイト |
| サイズ | 1.0kg |
| 構成 | 12*2 |
| 在庫商品識別番号: | SKU1234 |
製品価格設定階層の例
この製品価格設定階層の例では、コンテキストおよび属性で定義された価格設定コンテキストの品目コンテキストに、8つのレベルがそれぞれ属性として定義されています。
属性は、製品価格設定階層の体系を反映する順番に並べられ、階層の最下位レベルに最も小さい連番が設定されています。検索エンジンは、この連番を使用して、最も特殊性の高い価格または値引を選択します。たとえば、販促品の価格が見つからない場合は、構成の価格を使用します。構成の価格が見つからない場合は、パック・サイズの価格を使用します。パック・サイズの価格が見つからない場合は、小麦粉のタイプを使用します。価格設定属性の品目コンテキストは、製品価格設定階層の水平ビューを表します。
クオリファイアと同様に、検索エンジンは、取引要求明細または価格設定要求明細の価格設定属性を、価格表明細またはモディファイア・リスト明細の価格設定属性と比較します。これによって、基準価格またはモディファイアを要求明細に適用できるかどうかを判断します。価格設定要求明細の製品および価格設定属性は、ユーザーが入力するか、または属性マッピングを使用して作成できます。
除外を設定すると、製品階層内の特定のレベルで価格調整、特典または手数料を指定できますが、それより下位のレベルはモディファイアから除外されます。たとえば、前述の例で定義されている製品価格設定階層で、Homeprideブランド以外のすべての小麦粉に10パーセントの値引を適用するとします。この値引を作成するには、Oracle Advanced Pricingの製品属性のサブカテゴリを「小麦粉」に指定し、マージン・サブグループ「Homepride社」を除外します。検索エンジンでは、マージン・サブグループ価格設定属性がHomepride社の価格設定要求明細を削除します。
検索エンジンは、価格設定と同じ単位で定義されているモディファイア（前述のように、基準価格の導出時に判断されます）、または製品単位が指定されていないモディファイアのみを戻します。後者は、モディファイアが製品固有でない場合のケースです。
単位換算ロジック
検索エンジンは、価格設定単位と同じ単位で定義されているモディファイア、または単位が指定されていないモディファイアのみを戻します。後者は、モディファイアが製品固有でないか、単位の指定が不要なモディファイア・タイプの場合です。
モディファイア・レベル・コード
モディファイア・レベル・コードによって、要求明細がモディファイアに対して適格かどうかを決定するときに、検索エンジンによって考慮されるクオリファイアと価格設定属性が判断されます。このコードによって、モディファイアを要求に適用するレベルも判断されます。
明細レベル・コード
検索エンジンによって考慮されるのは、各要求明細のクオリファイアと価格設定属性のみです。数量関連の価格設定属性の場合、適格性については要求明細の数量のみが考慮されます。モディファイアの適用は、要求レベルで行われます。
明細グループ･レベル･コード
価格設定単位での数量と品目に支払われた金額が、認定された要求明細全体にわたって集計されます。要求に対する品目の数量と金額の合計、または製品階層の1レベルにある数量と金額の合計が、モディファイアを認定するかどうかを決定するときに、検索エンジンによって考慮されます。モディファイアの適用は、要求明細レベルで行われます。
受注レベル・コード
モディファイアを認定するかどうかを決定するときに、検索エンジンによって考慮されるのは、要約要求明細またはヘッダーのクオリファイアまたは価格設定属性のみです。ヘッダー・レベル・モディファイアを要求明細によって認定することはできません。モディファイアの適用は、要約要求明細またはヘッダー・レベルで行われます。
価格設定要求明細の固定
呼出し側アプリケーションは、価格計算フラグを使用して、価格設定要求明細の価格のすべてまたは一部を固定できます。このフラグの値に応じて、追加のモディファイアを適用せずに価格を完全に固定したり、特定のフェーズに追加のモディファイアを適用することができます。選択可能な値は次のとおりです。
| フラグ値 | 処理 |
|---|---|
| Y（価格の計算） | すべての価格とモディファイアを要求明細に適用します。 |
| N（固定価格） | 価格またはモディファイアを要求明細に適用しません。 |
| P（部分価格） | 特定のフェーズの価格またはモディファイアのみを適用します。 |
価格計算フラグを「部分価格」に設定すると、検索エンジンは、そのフェーズで「上書固定」フラグを検索します。価格計算フラグを「Yes」に設定すると、検索エンジンは、このフェーズの適格なモディファイアを要求明細に適用します。価格計算フラグを「No」に設定すると、このフェーズのモディファイアは、要求明細への適用が考慮されません。これによって明細の価格は固定されますが、運送費などは明細に適用できます。
その他の認定品目
いくつかのモディファイア・タイプを使用すると、複数の購買品を特典または手数料に適格な品目として指定できます。次に例を示します。
6脚組の椅子と、コーヒー・テーブルまたは2台のフロア・スタンドを購入すると、ダイニング・テーブルが400ドル値引されるとします。
この例の場合、検索エンジンは、特典品目に対する価格設定要求明細（ダイニング・テーブルに対する400ドルの値引）にモディファイアを適用する前に、指定の数量または金額の認定品目がすべて価格設定要求に含まれているかどうかを判断します。モディファイアには、他の品目のグループと組み合せることができる主要品目が必ず含まれている必要があります。この例では、椅子が主要品目で、他の2つの認定品目であるコーヒー・テーブルおよびフロア・スタンドと組み合せます。OR条件は、追加の購買品に異なるグループ番号を付けて作成します。値引の条件が6脚組の椅子、コーヒー・テーブルおよび2台のフロア・スタンドの場合は、同じグループ番号を付けます。
注意: 追加の認定品目で使用できる価格設定属性は、容積コンテキストの属性のみです。
追加の認定品目を定義できるモディファイアは、次のとおりです。
他の品目値引
販促品
クーポン発行
検索エンジンは、価格設定要求明細へ適用可能なモディファイアをすべて検索した後、モディファイアが排他的であるか、非互換的であるかを判断します。
同じ価格設定フェーズで価格設定要求明細に排他的なモディファイアが適用されている場合は、その要求明細に別のモディファイアを適用することはできません。たとえば、顧客がある品目を15%値引で購入する場合、その品目に対して他の値引は適格になりません。
同じ価格設定フェーズ内で、非互換モディファイアが適用された価格設定要求明細に他の非互換モディファイアは適用できません。たとえば、全スポーツ商品に6%の値引が適用されるサマー・スポーツ・キャンペーンに適格な顧客には、テニス・ラケットの5%の値引は適用できません。
複数の値引の非互換性は、値引適用階層の同じレベルのモディファイア間で定義します。次の図に、この概念を示します。この図では、レベル1が基準レベルの値引、レベル2が特別交渉済の値引、レベル3が遡及的な値引を表します。
この図のレベル1〜4の値引が同じ製品ファミリに設定されている（したがって、同じ価格設定要求明細に適用される）場合、すべての値引に対して適格な顧客は、各非互換グループから1つの値引のみ受けることができます。たとえば、顧客は、5%値引、1%の特別値引、および請求書からの100ドル値引を受けることができます。
価格設定フェーズの非互換グループ
顧客が交渉して同じ製品ファミリに対して15%の排他的な値引を受けることになり、検索エンジンがこの値引を価格設定要求明細に適用可能と判断した場合、現行の価格設定フェーズで適用できるのはこの値引のみになります。レベル1〜Nのすべての値引は考慮されません。この概念を次の図で説明します。
非互換グループと排他ルール
注意: 非互換ルールと排他ルールは、同じ価格設定フェーズにあり、同じ価格設定要求明細へ適用可能なモディファイアにのみ適用されます。
価格表明細
価格表明細は、常に排他的として処理されます。すべての価格表明細は、自動的にEXCL（排他的な非互換グループ）に割り当てられます。同じ価格設定要求明細に受注単位または価格設定単位の価格が複数ある場合、検索エンジンは、優先度を使用して価格表を選択します。価格表明細の優先度が等しい場合は、要求明細に関するエラーが戻されます。
次の図は、価格表の検索/非互換処理のパートAを示しています。この図では、菱形のボックスは判断を表し、長方形のボックスは処理を表します。
ボックス1では、価格表が呼出し側アプリケーションによって渡されているかどうかを判断します。
Noの場合はボックス1a: 「すべての価格表で検索を実行」に進みます。ボックス1aからボックス2に進みます。
ボックス1がYesの場合はボックス1bに進み、価格表を検証または強制するかどうかを判断します。Yesの場合はボックス1b-a: 「製品および価格設定属性を照合して適格な価格表明細を選択」に進みます。Noの場合はボックス1b-b: 「クオリファイア、製品および価格設定属性を照合して適格な価格表明細を選択」に進みます。両方のボックスとも、ボックス2に進みます。
ボックス2では、一致する明細が見つかったかどうかを判断します。Noの場合はパートBに進みます。Yesの場合はボックス3: 「価格設定属性を照合してグループ化を実行」に進みます。ボックス4に進み、グループ化で価格表明細を照合するかどうかを判断します。Noの場合はパートBに進みます。Yesの場合はボックス5: 「単位を照合」に進みます。ボックス6に進み、同一の単位明細が受注単位に存在するかどうかを判断します。Yesの場合はボックス7に進みます。Noの場合はボックス6aに進み、基準単位の明細があるかどうかを判断します。Noの場合はパートBに進みます。Yesの場合はボックス7: 「最も優先度が高い明細を検索」に進みます。ボックス8に進みます。ボックス8では、優先度が同じ明細が複数あるかどうかを判断します。Yesの場合はボックス8a: 「一致する属性項目数を使用して同じ優先度を解決」に進みます。ボックス8bに進み、同一属性で同一番号の明細が複数あるかどうかを判断します。Yesの場合はパートBに進みます。Noの場合はボックス9に進みます。ボックス8でNoの場合はボックス9に進み、受注単位が価格設定単位と異なるかどうかを判断します。Noの場合はボックス10に進みます。Yesの場合はボックス9a: 「単位換算を実行」に進みます。ボックス9bに進み、換算エラーが発生しているかどうかを判断します。Yesの場合はパートBに進みます。Noの場合はボックス10: 「価格表明細を選択」に進みます。これで、処理を終了します。
価格表検索と非互換処理
次の図は、価格表の検索および非互換処理のパートBを示しています。この図では、菱形のボックスは判断を表し、長方形のボックスは処理を表します。
ボックスBでは、検索する価格表が基準価格表、第2価格表、すべての価格表のいずれかを判断します。
基準価格表を検索する場合は、ボックスB1: 「優先度順に第2価格表から一致する明細を選択」に進みます。ボックスB1aに進み、一致する明細が見つかったかどうかを判断します。Yesの場合はパートAのボックス3に戻ります。Noの場合はボックスB1bに進み、価格設定フェーズの検索フラグがYesかNoかを判断します。Yesの場合はボックスBに戻ります。Noの場合はボックスB2a: 「価格が見つからない」に進みます。
第2価格表を検索する場合はボックスB3に進み、価格表を検証または強制するかどうかを判断します。Noの場合はパートAのボックス1aに戻ります。Yesの場合はボックスB2に進みます。
すべての価格表を検索する場合はボックスB2に進み、ステータス・コードが「非互換」、「価格なし」、「単位エラー」のいずれかを判断します。「価格なし」または「単位エラー」の場合は、ボックス2aに進みます。「非互換」の場合はボックスB2b: 「エラー: 非互換性を解決できない」に進みます。ボックスB2aおよびB2bともに、処理を終了します。
価格表検索と非互換処理
モディファイア
価格設定要求明細への適用に適格なモディファイアが非互換グループ内に複数存在する場合、検索エンジンは、適用するモディファイアを決定する必要があります。この決定を行うために、検索エンジンでは優先度と最善価格に基づいた2つの方法を使用します。検索エンジンがどちらの方法を選択するかは、価格設定フェーズに設定されている非互換性解決方法によって決まります。フェーズの非互換性解決コードが優先度に設定されている場合、検索エンジンは最も特殊性の高いモディファイアを選択します。これが失敗した場合（優先度の等しいモディファイアが複数ある場合）、検索エンジンは最善価格を使用して解決します。フェーズの非互換解決方法が最善価格に設定されている場合、検索エンジンは値引が最大のモディファイアを検索します。これが失敗すると、検索エンジンは、要求明細に対しエラーを戻します。
次の図は、モディファイアの検索および非互換処理を示しています。この図では、菱形のボックスは判断を表し、長方形のボックスは処理を表します。
ボックス1では、モディファイア/ヘッダー明細を認証済要求として渡すかどうかを判断します。Yesの場合はボックス1a: 「認定なしで製品を照合するためのモディファイアを選択」に進みます。Noの場合はボックス1b: 「クオリファイア、製品、属性を照合してモディファイアを選択」に進みます。両方のボックスとも、ボックス2: 「価格分岐の評価を実行」に進みます。ボックス3: 「明細グループ処理を実行」に進みます。ボックス4: 「クオリファイア・グループと属性グループの照合を実行」に進みます。
ボックス4からボックス5に進み、選択した明細のモディファイアに、排他グループに含まれるモディファイアがあるかどうかを判断します。Yesの場合はボックス6に進みます。Noの場合はボックス5aに進み、他に非互換グループがあるかどうかを判断します。Noの場合は、処理を終了します。Yesの場合はボックス5bに進み、非互換グループがNULLかどうかを判断します。Yesの場合はボックス9に進みます。Noの場合はボックス6に進みます。
ボックス6では、選択した明細のモディファイアが要求かどうかを判断します。YesかNoかによって異なるケースに進みます。Noの場合は、ボックス6a-1から始まるケースに進みます。このボックスでは、選択した明細に、複数の非互換モディファイアに対して適格な明細があるかどうかを判断します。Noの場合はボックス9に進みます。Yesの場合はボックス6a-2に進み、フェーズの非互換性解決を判断します。最善価格の場合はボックス7に進みます。優先の場合はボックス6a-3: 「最も優先度の高い明細を検索」に進みます。ボックス6a-4に進み、優先度が同じ明細が複数あるかどうかを判断します。Yesの場合はボックス7に進みます。Noの場合はボックス9に進みます。
ボックス6でYesの場合は、ボックス6b-1から始まるケースに進みます。このボックスでは、同じ非互換グループに、複数の要求に対して適格な明細があるかどうかを判断します。Noの場合はボックス9に進みます。Yesの場合はボックス6b-2に進み、フェーズの非互換性解決コードを判断します。最善価格の場合はボックス7に進みます。優先の場合はボックス6b-3に進み、優先度が同じ明細が複数あるかどうかを判断します。Yesの場合はボックス7に進みます。Noの場合はボックス9に進みます。
ボックス7: 「モディファイアを比較して最善価格を検索」からボックス8に進み、同一最善価格が複数のモディファイアにあるかどうかを判断します。Noの場合はボックス9に進みます。Yesの場合はボックス8a: 「任意のモディファイアを選択」に進みます。ボックス9: 「モディファイアの選択完了」に進みます。ボックス10に進み、選択したモディファイアが排他グループに含まれるかどうかを判断します。Noの場合はボックス5aに戻り、Yesの場合は処理を終了します。
モディファイア検索と非互換処理
検索エンジンは、最も特殊性の高いモディファイア、つまり、最小の優先番号を持つモディファイアを選択します。
たとえば、すべての優先顧客が製品ファミリAを5%値引で購入できるとします。顧客のBoomerang Emporium社は優先顧客ですが、交渉の結果、この製品ファミリを10%値引で購入できることになったため、5%値引については適格でなくなります。
この2つの値引は、両方とも同じ非互換グループとフェーズで定義されます。検索エンジンは、製品ファミリAの品目に対するBoomerang Emporium社の注文に、2つの値引を適用できるかどうかを判断します。2つの値引は非互換であり受注明細に両方は適用できないため、検索エンジンで特殊性の高い値引を判別する必要があります。この例では、Boomerang Emporium社が交渉して得た値引は、一般顧客区分の値引より特殊性が高くなります。検索エンジンは、各クオリファイアおよびモディファイアの製品属性から最小の優先番号を選択して、モディファイアの特殊性を導出します。次に、検索エンジンは、最小の優先番号を持つモディファイアを価格設定要求明細に適用します。前述の例の場合、顧客クオリファイアの優先度が1、顧客区分クオリファイアの優先度が2、製品ファミリの優先度を3とすると、特殊性は次のように計算されます。
| 値引のタイプ | クオリファイアの優先度 | 価格設定属性の優先度 | 全体の優先度/特殊性 |
| 5%値引 | 2（顧客区分） | 3 | 2 |
| Boomerang Emporium社に対する10%値引 | 1（顧客） | 3 | 1 |
Boomerang Emporium社に対する10%値引が最小の優先番号を持つ（最も特殊性の高い）値引であるため、検索エンジンはこれを選択します。この概念を次の図で説明します。
優先と非互換
設定時に、クオリファイアまたは製品属性の優先度には、属性管理で定義された値がデフォルト設定されます。コンテキスト内および複数のコンテキストにわたるクオリファイアおよび製品属性の順序によって、優先するクオリファイアが決定されます。この決定は、選択エンジンが、要求明細へ適用可能な複数の価格、非互換の特典または手数料の間からクオリファイアの選択を強制される場合に実行されます。各セグメントの連番は、クオリファイア付加コンテキスト、品目コンテキスト全体で一意にする必要があり、最も特殊性の高いクオリファイアおよび製品属性には、最小の連番が割り当てられます。
最善価格
最善価格は、適格な非互換モディファイアが複数ある場合、価格設定要求明細に適用するモディファイアを選択するときの優先度を決めるもう1つの方法です。この方法を使用して、顧客に最大値引を提供するモディファイアが選択されます。詳細は、「モディファイアに対する最善価格による解決」を参照してください。
計算エンジンは、価格設定要求明細と関連付けられた価格設定要求明細詳細を取得して、基準価格、調整価格または金額を計算します。
固定最低価格（GSA価格設定）
Oracle Advanced Pricingでは、最低価格を設定して、全顧客または一部の顧客に対して品目価格が最低価格を下回らないようにできます。この設定は、通常General Service Administration（GSA）契約を管理するために使用します。この契約では民間の顧客はGSA契約で顧客に対して決められた固定金額以上の値引を受けることはできません。GSA違反は、顧客がGSA違反の場合、または請求先事業所がGSAの場合にチェックされます。GSA違反は、顧客がGSA違反の場合、または請求先事業所がGSAの場合にチェックされます。
品目の最低価格またはGSA価格は、特別なGSA最低価格表に設定されます。これは、最低価格が新しい（固定）価格タイプの値引として指定された値引リストです。GSA値引は、GSA顧客に対して通常の品目価格をGSA価格まで値引するときに作成され、これによって値引コストを認識できます。GSA値引リストは、GSA顧客に対してのみ使用でき、作成時にGSA =「Yes」を指定すると自動的に認定されます。属性マッピングを使用し、GSA =「Yes」でGSA顧客の注文をソース指定すると、これらのすべての注文に品目の最低価格が適用されます。
GSA価格設定が使用可能で顧客がGSA顧客でない場合、計算エンジンは、品目の販売価格がその品目に許可されている最低価格に違反していないかを判断します。販売価格が最低価格に違反している場合、計算エンジンは、GSA違反のステータスを要求明細に戻します。呼出し側アプリケーションでは、受注明細を保留にするかどうかの判断など、エラー処理を実行します。
注意: 計算エンジンでは、要求明細の販売価格とGSA価格の比較時に、価格設定属性を考慮しません。このため、GSA価格は製品属性に対してのみ設定できます。
GSA以外の環境では、この機能は、価格設定が許容最低価格を下回るのを防ぐために使用できます。この場合、GSA価格表は、すべての品目とその可能な販売価格のリストになります。GSA顧客として定義されている顧客はいないため、計算エンジンは、全顧客について、品目の販売価格が最低価格を下回っていないことを確認します。
価格分岐の計算
価格分岐は、顧客が注文する数量、容積、金額または重量の範囲に応じて決められた価格または値引に関連した一連の数量区切りです。価格分岐は、Oracle Advanced Pricingでは、価格分岐ヘッダー・モディファイアに属する関連モディファイアからグループ化された、値引、追加料金または手数料モディファイアのセットとしてモデル化されています。価格分岐ヘッダーには、クオリファイア、製品属性、価格設定属性（容積コンテキストの価格設定属性を除く）、単位、有効日、および価格分岐の共通要素であるその他の属性がすべて含まれています。価格分岐明細には、分岐単位のみが含まれます。分岐単位は、価格設定属性付加フレックスフィールドの容積コンテキスト内の価格設定属性である必要があります。
検索エンジンは、価格設定要求明細に適用できる価格分岐を検索します。検索エンジンは、価格分岐ヘッダーの要素、（クオリファイア、製品属性および価格設定属性の）非互換性、および価格設定要求明細の分岐単位（数量、金額など）に一致する価格分岐明細が存在するかどうかのみ考慮します。
計算エンジンは、価格分岐明細を取得し、モディファイアの基準価格または値引値を判断します。この値は、次に示す価格分岐のタイプによって決まります。
点: 分岐単位の各数量が、合計数量が収まる分岐範囲内の基準価格モディファイアを取得するボリューム分岐。
範囲: 分岐単位の各数量が、その数量が収まる分岐範囲内の価格/値引を取得するボリューム分岐。
定型: 分岐範囲内に収まる分岐単位の各数量に対してモディファイアが指定されるボリューム分岐。この価格分岐タイプは、モディファイアにのみ使用されます。
手動調整の適用
価格設定エンジンは、呼出し側アプリケーションから渡される上書きされた手動調整または自動調整を適用できます。詳細は、このマニュアルの「統合」の章を参照してください。
価格設定エンジン呼出しの間、呼出し側アプリケーションは、次のことを実行します。
戻されたモディファイアと既存の調整を比較して、必要に応じて更新を実行します。
ローカルの計算エンジンを呼び出して、販売価格を取得します。
次に示すOracle Advanced Pricingエンジンの呼出しの疑似コード・フローは、説明をわかりやすくするために簡略化されています。このフローは、今後のリリースで変更される場合があります。
アプリケーション統合コードの起動
engine call preparation
populate global record as needed in attributes mapping
call build_Contexts for header and the line (or for every line if it is save or book event)
populate engine PL/SQL record structure
call the engine (QP_PREQ_PUB.Price_Request) within engine call
clear the temporary tables
populate temporary tables from input PL/SQL structure
for every phase of the event loop
if pricelist phase then
select pricelist list line in the pricelist provided by the call
if not found then perform the secondary search
if not found in secondary search perform big search (see Event Phases)
end if
if modifiers phase then
select and insert matching modifiers into temp tables
perform grouping, incompatibility, breaks processing
end if
end loop
call calculation engine
populate output PL/SQL structure from temp tables
return back to the invoking application
Oracle Advanced Pricingは、いくつかの拡張機能を備えています。
Oracle Advanced PricingのAPI
Oracle Advanced Pricingは、いくつかのApplication Programming Interface（API）を備えています。設定およびOracle Advanced Pricingエンジンの呼出しに、PL/SQL APIを使用できます。作業用のAPI呼出しの例は、ARUを使用してOracleMetalinkからダウンロードできます。この例を検討し、特定の顧客のニーズに合せて変更できます。Oracle Advanced PricingのパブリックAPIの完全なリストは、『Oracle Order Management Open Interfaces, API, & Electronic Messaging Guide』を参照してください。
関連トピック
