ヘッダーをスキップ

Oracle Advanced Pricingインプリメンテーション・マニュアル
リリース12
E05612-01		目次へ
目次		前のページへ
前へ		次のページへ
次へ

Oracle Advanced Pricingとの統合

この章では次のトピックについて説明します。

Oracle Advanced Pricingとの統合の概要

Oracle Advanced Pricingは、すべての統合アプリケーションから呼び出すことができるAPIベースのエンジンです。この章では、Advanced Pricingとの統合を成功させるために不可欠な情報について説明します。

詳細は、次を参照してください。

Oracle Pricingに必要な統合ステップ

次のステップは、Oracle Pricingとの統合に必要なプロセスを示します。

手順1: 価格設定に関するエンド・トゥ・エンドのビジネス・ニーズを確認します。

アプリケーションで必要とする価格設定機能を判断するには、『Oracle Advanced Pricingユーザーズ・ガイド』およびこのマニュアルの該当の項を参照してください。

  1. 各取引の相違点を評価し、取引サイクルの各フェーズで呼び出す価格設定イベントを選択します。新規価格設定フェーズの作成方法や、価格設定フェーズおよびイベントの詳細は、『Oracle Advanced Pricingユーザーズ・ガイド』を参照してください。

  2. ビジネス・ニーズを確認し、価格設定取引エンティティ（PTE）を選択します。新規PTEが必要な場合は、「価格設定取引エンティティの新規作成」を参照し、PTEの作成方法を確認してください。新規PTEを作成する場合、シード済コンテキストおよび属性は使用できません。新規作成したPTEに新規コンテキストおよび属性を作成するか、既存の属性をこのPTEにリンクする必要があります。

  3. 価格設定エンジンは要求タイプを使用して呼び出す必要があります。各要求タイプはPTEにリンクされます。要求タイプにより、価格設定エンジンの呼出し時に検索される価格表およびモディファイアと、build_context APIの呼出し時に実行される属性マッピング・ルールの2つが決まります。各モディファイアまたは価格表はソース・システムに関連付けられるため、PTEにも関連付けられます。価格設定エンジンは、PTEにリンクされたソース・システムに属すモディファイアまたは価格表を参照します。

  4. 属性マッピング・ルールは、個々の取引システムによってそれぞれのPTEについてシードされます。PTEは一連の要求タイプおよびソース・システムにリンクされます。すでに定義されている属性マッピング・ルールと取引データが対応するかどうかを確認します。対応しない場合は、カスタム・マッピングの定義方法について属性マッピングの項を参照してください。

手順2: PL/SQLグローバル体系を決定します。

APIを呼び出してコンテキストを作成する前に、クオリファイア/価格設定属性情報を作成する必要のある要約明細（受注ヘッダー）または要求明細（受注明細）に関する情報を、要求タイプに対応するグローバル・レコード体系で設定する必要があります。要求タイプONTには、受注明細用としてoe_order_pub.g_line、受注ヘッダー用としてoe_order_pub.g_hdrの各グローバル体系が使用されます。要求タイプASOには、グローバル体系aso_pricing_int.g_line_recおよびaso_pricing_int.g_header_recが使用されます。

oe_order_pub.g_line/g_hdr体系や、aso_pricing_int.g_line_recおよびaso_pricing_int.g_header_recのOrder Capture APIドキュメントの詳細は、『Oracle Order Management Open Interfaces, API, & Electronic Messaging Guide』を参照してください。

要求をこれらの体系のいずれかにマップできるかどうかを確認します。呼出し側アプリケーションによって使用される体系に特定の属性マッピング・ルールを定義する必要があります。要求体系をこれらの体系のいずれかにマップできない場合は、新規体系を定義し、この新規体系を使用して属性マッピング・ルールを作成する必要があります。

手順3: 調整情報を保持する表を確認します。

受注/見積/価格設定要求に与えられるすべての特典の分岐を表示するために価格設定エンジンから戻される情報を保持する必要がある場合は、受注管理または受注獲得で使用される価格調整表の使用可否を確認します。

OE_PRICE_ADJUSTMENTS/ASO_PRICE_ADJUSTMENTS

価格調整を保持します。

OE_PRICE_ADJ_ATTRIBS/ASO_PRICE_ADJ_ATTRIBS

調整を行うために適用する資格条件を保持します。

OE__PRICE_ADJ_ASSOCS/ ASO_PRICE_ADJ_RELATIONSHIPS -

価格分岐、販促品およびその他の品目特典用の複数の調整レコード間の関連を保持します。

独自の表を作成する必要がある場合は、上の表の表定義を参考にして表を作成してください。

手順4: 価格設定要求体系を設定します。

次に、QP_PREQ_PUB.PRICE_REQUESTのAPI体系を示します。

(p_control_rec IN
QP_PREQ_GRP.CONTROL_RECORD_TYPE,
x_return_status OUT VARCHAR2,
x_return_status_text OUT VARCHAR2
);

  1. 管理レコードp_control_recを設定します。

    管理レコードのパラメータの詳細は、『Oracle Order Management Suite APIおよびオープン・インタフェース・マニュアル』のPricingのAPIの項を参照してください。管理レコードにより、価格設定エンジンが価格を戻す方法が決まります。

  2. APIのQP_Price_Request_Context.Set_Request_Id()を呼び出します。

    価格設定のrequest_idを設定し、現行の価格設定エンジン呼出しに属する価格設定一時表のデータを価格設定エンジンが識別できるようにします。一時表のデータが、各価格設定エンジン呼出しの前に削除されることはありません。かわりに、以前の価格設定エンジン呼出しのデータが価格設定一時表に残ることがあります。呼出し側アプリケーションは、価格設定エンジンを呼び出すたびにrequest_idを設定する必要があります。これが最初のステップになります。

    APIのQP_Price_Request_Context.Set_Request_Id()は、コミットまたはロールバックせずに同じセッションで行われたすべての価格設定エンジン呼出しに対して一意のrequest_idを設定します。これにより、呼出し間の価格設定一時表のデータを削除する必要がなくなります。また、request_idが設定されていない場合、呼出し側アプリケーションは、コミットまたはロールバックせずに次の価格設定エンジン呼出しを行う前に価格設定一時表のデータを削除する必要があります。コミットまたはロールバックを行うと一時表内のデータがパージされ、レコードを削除する必要がなくなります。

  3. 属性マッピングに使用されるグローバル体系を設定します。たとえば、要求タイプONTを使用している場合、PL/SQL体系OE_ORDER_PUB.G_LINEを設定します。

  4. APIのQP_ATTR_MAPPING_PUB.Build_contextsを呼び出します。

    QP_Attribute_Mapping_PUB.Build_Contexts
(          p_request_type_code    IN      VARCHAR2,
        p_line_index                  IN      NUMBER,
        p_pricing_type_code           IN      VARCHAR2
);

    このAPIは、属性マッピング・ルールに記載されているパブリック・レコード体系を参照します。このため、各明細の要求明細情報が要求体系にロードされ、明細ごとにAPIが呼び出される必要があります。「コンテキストのビルド」APIは、渡されたline_indexを使用して、マップされている属性を価格設定一時表に挿入します。したがって、要求明細に使用したものもと同じline_indexを使用する必要があります。

    属性マッピング・ルールまたはレコード体系が見つからない場合、クオリファイアおよび価格設定属性をqp_preq_line_attrs_tmpに挿入できます。たとえば、価格設定エンジンが特定の価格表から価格をフェッチするには、qualifier_context=MODLISTを使用して価格表をqp_preq_line_attrs_tmpに渡します。

    qualifier_attribute=QUALIFIER_ATTRIBUTE4およびqualifier_attr_value_fromにより、price_list_idを保持します。

    inventory_item_idはpricing_context=ITEMを使用して一時表qp_preq_line_attrs_tmpに渡されるため、pricing_attribute=PRICING_ATTRIBUTE1およびpricing_attr_value_fromは、item_idを保持します。

    「コンテキストのビルド」APIは、p_pricing_type_codeのL（要求明細）を使用して呼び出す必要があります。

  5. 要求明細をロードするためのCopy_Line_to_requestの詳細は、『Oracle Order Management Open Interfaces, API, & Electronic Messaging Guide』の「受注管理体系を使用したサンプル・コード」を参照してください。APIのQP_PREQ_GRP.Insert_Lines2を呼び出し、要求明細を価格設定一時表qp_preq_lines_tmpに挿入します。

    API体系およびパラメータの説明の詳細は、『Oracle Order Management Open Interfaces, API, & Electronic Messaging Guide』を参照してください。

  6. ユーザー入力の価格設定属性および販促/取引の要求またはクーポンを一時表qp_preq_line_attrs_tmpに追加します。価格設定が資格をチェックしないようにするには、販促品を適用する前にqp_preq_line_attrs_tmpのvalidated_flagを「Y」（販促請求）に設定します。

    Append_ask_forプロシージャの詳細は、『Oracle Order Management Open Interfaces, API, & Electronic Messaging Guide』の「受注管理体系を使用したサンプル・コード」を参照してください。これらの属性は、APIのQP_PREQ_GRP.insert_line_attrs2を使用して一時表qp_preq_line_attrs_tmpに挿入できます。

    API体系およびパラメータの説明の詳細は、『Oracle Order Management Open Interfaces, API, & Electronic Messaging Guide』を参照してください。

    注意: 価格設定インタフェース表および一時表にキーを渡す場合、line_index、line_detail_index などのキーは、pls_integerデータ型の範囲内にする必要があります。

  7. 手動調整を適用する場合や、価格設定エンジンにその他の調整を考慮させる場合、これらのレコードを、applied_flagおよびupdated_flagを「Y」（Yes）に設定して価格設定一時表qp_preq_ldets_tmpに挿入します。QP_PREQ_GRP.insert_ldets2 APIを使用して、調整またはモディファイアを価格設定エンジンに渡します。

  8. 要約明細が設定されていることを確認します。

    価格設定エンジンに対するすべての要求には、受注ヘッダーの情報とともにqp_preq_lines_tmpの要約レコードが含まれている必要があります。価格設定エンジンは、渡された要約明細に対して受注レベルのモディファイアを適用します。要約明細が渡されない場合、価格設定エンジンは、受注レベルの調整を適用できないことがあります。

    要約明細のline_type_codeをORDERに設定します受注ヘッダーの場合は、ステップ1〜6を繰り返し、要約明細に対するQP_ATTR_MAPPING_PUB.build_context()の呼出し時にp_pricing_type=Hを使用します。

    copy_Header_to_request()を使用して要約レコードを設定する方法の詳細は、『Oracle Order Management Open Interfaces, API, & Electronic Messaging Guide』の「受注管理体系を使用したサンプル・コード」を参照してください。

  9. パーセント価格があるサービス明細については、親明細が渡されることを確認します。サービス品目の価格設定方法の詳細は、「サービス品目の価格設定」を参照してください。

手順5: Price_request()を呼び出します。

APIを呼び出します。

QP_PREQ_PUB.PRICE_REQUEST
(p_control_rec IN QP_PREQ_GRP.CONTROL_RECORD_TYPE,
x_return_status OUT VARCHAR2,
x_return_status_text OUT VARCHAR2);

手順6: 価格設定要求の結果を解釈します。

  1. エラーの処理:

    価格設定エンジンは、ハード・エラーとソフト・エラーを戻すことができます。x_return_statusの値がFND_API.G_RET_STS_SUCCESSである場合、価格設定エンジンの呼出しは成功です。

    ソフト・エラーは、価格設定時の明細レベルの例外を示します。これらのエラーは、qp_preq_lines_tmp.pricing_status_codeに設定されます。次に、明細に対する3つの成功コードを示します。

    G_STATUS_NEW
G_STATUS_UPDATED;
G_STATUS_UNCHANGED

    次は、呼出し側アプリケーションからの処理が必要なコードです。

    G_STATUS_DELETED
G_STATUS_TRANSIENT
G_STATUS_GROUPING
G_STATUS_INVALID_PRICE_LIST
G_STATUS_GSA_VIOLATIONG_STS_LHS_NOT_FOUND
G_STATUS_FORMULA_ERROR
G_STATUS_OTHER_ERRORSG_STATUS_SYSTEM_GENERATED
G_STATUS_BEST_PRICE_EVAL
G_STATUS_INCOMP_LOGIC
G_STATUS_CALC_ERROR
G_STATUS_UOM_FAILURE
G_STATUS_PRIMARY_UOM_FLAG
G_STATUS_OTHER_ITEM_BENEFITS
G_STATUS_INVALID_UOM
G_STATUS_DUP_PRICE_LIST
G_STATUS_INVALID_UOM_CONV
G_STATUS_INVALID_INCOMP
G_STATUS_BEST_PRICE_EVAL_ERROR
G_STATUS_LIMIT_HOLD
G_STATUS_LIMIT_EXCEEDED
G_STATUS_LIMIT_ADJUSTED
G_STATUS_LIMIT_CONSUMED

GSA違反のG_STATUS_GSA_VIOLATIONは、特殊ケースです。GSA違反の動作の詳細は、次の項の「GSA違反」トピックを参照してください。

様々なステータス・コードの詳細は、このマニュアルのトラブルシューティングの項を参照してください。

要求明細に対してフェッチされた価格表

価格設定エンジンとの対話の詳細

この項では、価格設定エンジンによってサポートされている機能の概要と価格設定エンジンによるこれらの機能の処理方法について説明します。これには、各機能の戻り値に関する情報や、同じ要求明細に対して同じ結果を取得するために後続の呼出しに要求情報を渡す方法に関する情報などが含まれます。

価格設定エンジンに対して調整/モディファイアを渡す

呼出し側アプリケーションが特定のモディファイアを要求明細に適用するために価格設定エンジンに適用する必要がある場合、pricing_status_code = QP_PREQ_GRP.G_STATUS_UNCHANGEDとしてqp_preq_ldets_tmpに挿入する必要があります。QP_PREQ_GRP.insert_ldets2 APIを使用して、調整またはモディファイアを価格設定エンジンに渡すことができます。

手動調整

ユーザーから値引および追加料金タイプと認定され、（非互換性設定ルールのために）非互換解決の一部として削除されるすべての自動モディファイア（automatic_flag = Y）は、プロファイル「QP: 手動値引戻し」が「Y」に設定されている場合、手動値引として戻されます。これらの値引以外にも、値引タイプとして認定されているすべての手動モディファイアも戻されます。呼出し側アプリケーションには、追加料金値引も未適用として戻されます。

注意: 手動調整が適用されたり自動調整が上書きされた場合、これらのモディファイアに対する価格設定の変更は適用できなくなります。これらのモディファイアに対する資格チェックは行われません。たとえば、資格が変更された場合（モディファイアの適格性の基準が変更された場合など）、要求明細が認定されなくても、手動で上書きされたモディファイアは適用され続けます。たとえば、受注見積に手動モディファイアを適用した後、見積が認定されないように変更を行うと、このモディファイアは削除されません。この条件は、モディファイアに対するクオリファイアの変更にも該当します。

自動上書き可能なモディファイアについても同じように処理できます。自動モディファイアを上書きし、単位を変更すると、モディファイアは見積から削除されなくなります。

手動調整の適用

手動調整は、次の2つの方法で適用できます。

適用された手動調整の削除

適用された手動調整を削除するには、価格設定エンジンから戻された適用済調整が格納される呼出し側アプリケーションの取引表からこれらの手動調整を削除する必要があります。つまり、呼出し側アプリケーションも、調整の属性および関連を削除する必要があります。手動調整が価格分岐である場合、価格分岐の子明細、価格分岐と子明細の属性、および価格分岐と子明細の関連も適用する必要があります。

これらはいったん取引表から削除されると、価格設定エンジンに対する後続の呼出しに渡されなくなり、適用もされません。

適用された自動上書き調整の削除

ビジネス上、自動上書き調整の削除がサポートされている場合、呼出し側アプリケーションは、これらの調整をapplied_flag = Nおよびupdated_flag = Yとして挿入する必要があります。また、これらの調整は、後続の価格設定エンジン呼出し時に価格設定エンジンに渡す必要があります。要求明細がこの自動調整に適格であっても、この自動調整は適用されません。

自動上書き可能モディファイアの適用

自動上書き可能モディファイアを適用するには、updated_flag = Y、applied_flag = Yおよびpricing_status_code = QP_PREQ_GRP.G_STATUS_UNCHANGEDとしてモディファイアをqp_preq_ldets_tmpに挿入することにより、モディファイアを価格設定エンジンに渡します。価格設定エンジンにより、このモディファイアが適用されます。

手動/上書き可能価格分岐

手動上書き可能価格分岐を適用するには、価格分岐ヘッダー調整および子明細を価格分岐モディファイアと子分岐明細の関連とともに上書き済オペランドを使用して渡します。分岐が評価され、上書済価格分岐が適用されます。また、価格設定エンジンから以前に戻された容積属性を価格分岐モディファイアおよび子明細とともに必ず渡す必要があります。価格設定エンジンは価格分岐モディファイアに関する品目数量/金額情報を導出するために価格設定を参照しないため、容積属性が必要です。関連を挿入するには、QP_PREQ_GRP.insert_rltd_lines2 APIを使用します。

GSA違反

価格設定を使用して、GSA価格表を作成できます。品目の価格がGSA以外の顧客の品目のGSA価格未満である場合、GSA違反が発生します。価格設定エンジンは、価格設定エンジン呼出しの終わりにGSA違反をチェックします。GSA違反が起きた場合は、要求明細のpricing_status_codeはQP_PREQ_GRP.G_STATUS_GSA_VIOLATIONに設定されます。呼出し側アプリケーションは、警告またはエラー・メッセージを表示して、GSA違反を処理します。GSA顧客の場合、価格設定エンジンは、GSA価格表の価格を提供します。この要求明細は、GSA顧客に対してさらに値引の対象となる資格を付与できます。

価格設定エンジンがGSA違反のチェックを行うのは、管理レコードのGSA_CHECK_FLAGが「Y」として渡され、要求明細でGSAクオリファイア（コンテキスト= CUSTOMER、属性= QUALIFIER_ATTRIBUTE15）が値「N」（顧客がGSA以外であることを示す）として渡された場合のみです。属性マッピングAPIは、ARの場合は顧客でチェックされたgsa_indicatorフラグに基づいて、あるいは請求先事業所のgsa_indicatorが「Y」に設定されている場合にGSAクオリファイアを戻します。

Order Managementにおいて、プロファイル「GSA違反」が「警告」に設定されている場合、警告メッセージが表示されます。プロファイルが「エラー」に設定されている場合、エラー・メッセージが出されます。

バケット

価格設定エンジンは、すべてのモディファイアを取得した後、バケット・ルールを適用し、販売単価を計算します。

価格設定算式

価格設定エンジンに渡された属性またはファクタに基づいて、算式が処理され、オペランドが評価されます。

端数処理

端数処理とは、定価および販売価格の端数処理を示します。端数処理は、価格設定エンジンの入力であるcontrol_recordのrounding_flag、およびプロファイル「QP: 販売価格端数処理オプション」の値によって管理されます。詳細は、このマニュアルの「プロファイル・オプション」を参照してください。端数処理フラグの値の詳細は、『Oracle Order Management Open Interfaces, API, & Electronic Messaging Guide』を参照してください。

運送費

受注明細に適用される運送費が評価され、要求明細の手数料タイプ（charge_type_codeおよびcharge_subtype_code）ごとに最大運送費が適用されます。運送費は販売価格に影響しません。適用が必要な手動および上書き手数料は、すべての手動調整（値引および追加料金）と同様に、applied_flag = Yおよびupdated_flag = Yとして価格設定エンジンに渡す必要があります。

クーポン発行

クーポンの発行時には、一意のクーポン番号が生成されます。この一意のクーポン番号とともに、レコードがQP_COUPONS表に挿入されます。この番号が表に表示され、ユーザーが選択可能なクーポンが示されます。この番号は一意です。この番号は、後で値引を消費するときに使用できます。1つのクーポン番号は1つの消費に相当します。いったん使用（消費）されたクーポン番号は再使用できなくなります。ユーザーがクーポンを消費するには、クーポン番号を把握している必要があります。

次に注文を行う場合、クーポン番号を入力すると、クーポンに適した値引が認定され、値引が適用されます。クーポンはいったん消費されると削除されます。

注意: クーポン発行モディファイアの場合、「特典数量」フィールドおよび「特典単位」フィールドに入力した値にかかわらず、発行されるクーポンは1つのみとなります。

クーポンはQP_COUPONS表に格納され、消費されると消費済としてマークされます。

クーポンを消費するには、クーポンを受注明細のクオリファイアとして価格設定エンジンに渡す必要があります（コンテキスト = MODLIST、属性 = QUALIFIER_ATTRIBUTE3、値 = <クーポン番号>）。クーポンは、ask_for_promotionsとともに明細の属性として格納できます。価格設定エンジンが後続の価格再設定呼出しにクーポン値引を提供できるようにするには、クーポンを属性として渡す必要があります。

設定時にクーポン発行モディファイアがクオリファイアを持つようにできます。クーポンが消費されると、すべてのクオリファイアが渡されたかどうかについての資格チェックが行われます。クオリファイアが渡されなかった場合、クーポンに関連するモディファイアの要求明細は認定されません。この資格チェックが行われないようにするには、このクーポンのクオリファイア・レコードに対するqp_preq_line_attrs_tmpのvalidated_flagに値「Y」を渡します。

Order Managementでは、受注に対するクーポンが認定されると、受注が取り消されたり品目が戻されても、クーポンは削除されません。価格再設定時には、新規クーポンが発行され続けます。

品目アップグレード

受注明細について品目アップグレードが認定されると、品目アップグレード・モディファイアがこの明細に対して適用され、qp_ldets_v temporary一時表に表示されます。qp_ldets_v一時表では、related_item_id列にはアップグレードされた品目のinventory_item_idがあり、inventory_item_id列には元の品目のinventory_item_idがあります。呼出し側アプリケーションは、明細上の当初の受注品目をアップグレードされた品目に置換できます。価格再設定時には、呼出し側アプリケーションは元の品目を明細に渡し戻し、受注の価格が同じ方法で再設定されるようにする必要があります。これを行うには、属性マッピングの前に元のinventory_item_idを品目アップグレード・モディファイアからパブリック・レコード体系にロードします。

品目アップグレード・モディファイアを設定するには、関連タイプを販促アップグレードとして在庫品目関連に購買品目とアップグレード品目間の関連を定義する必要があります。

販促品

受注明細に対して販促品モディファイア（PRG）が認定されると、無償品目明細用の新規受注明細が作成されます。通常、PRGは、品目Aを購買すれば品目Bをx%オフで購買可能、という方式で設定されます。この場合、品目Aを受注したときにこの品目に対してPRGが認定されると、品目Bについて新規受注明細が作成され、この新規明細に対してx%の値引が適用されます。1つ購買すれば1つ無償という場合、この値引は100%になります。

価格設定エンジンによって作成される新規明細は、QP_PREQ_GRP.G_BY_ENGINEに設定されたqp_preq_lines_tmp一時表のprocessed_codeの値によって識別できます。

呼出し側アプリケーションは、無償品目明細を示す新規受注明細を作成する必要があります。この無償品目は、qp_preq_line_attrs_tmpの属性としてこの明細に渡されます。この無償品目明細の値引はqp_ldets_v一時表に渡されます。PRGモディファイアを認定された受注明細は親モディファイアであり、無償品目明細の値引は子明細です。

qp_preq_rltd_lines_tmp一時表にはrelationship_type_code = QP_PREQ_GRP.G_GENERATED_LINEとして親子関連が作成されます。line_detail_indexは親明細のline_detail_indexで、related_line_detail_indexは子明細のline_detail_indexです。価格設定エンジンから戻された前述の情報は、呼出し側アプリケーションによって取引表に格納される必要があります。

価格再設定時には、価格設定エンジンのパブリックAPIのQP_PREQ_PUBにより、価格設定の既存の無償品目明細と販促品モディファイアが比較されます。販促品モディファイアが変更されていない場合、QP_PREQ_GRP.G_STATUS_UNCHANGEDの値がqp_preq_lines_tmpのprocess_status列に設定されます。この場合、呼出し側アプリケーションは無償品目明細を変更する必要はありません。価格設定が変更された場合、process_statusにはQP_PREQ_GRP.G_STATUS_UPDATED値が設定されます。要求明細の1つが販促品明細に対して認定される新規の価格設定エンジン呼出しの場合、process_status = QP_PREQ_GRP.G_STATUS_NEWとして新規明細がqp_preq_lines_tmpに作成されます。この場合、呼出し側アプリケーションはこの明細を取引システムに挿入できます。

process_status = QP_PREQ_GRP.G_STATUS_NEW/G_STATUS_UPDATEDとして無償品目明細が作成される場合、呼出し側アプリケーションは別の呼出しを行い、無償品目明細の運送費を計算する必要があります。販促品の運送費に対する暗黙的呼出しの詳細は、「無償品目明細の運送費」を参照してください。

無償品目明細が必要ない場合は、無償品目明細を明細から削除できます。無償品目を再作成する必要がないことを価格設定エンジンに認識させるには、次の手順を実行します。

  1. 無償品目明細、その属性、調整、購買明細と無償品目明細の関連をシステムから削除します。購買明細のPRG調整は保持しますが、updated_flag = QP_PREQ_GRP.G_YESと設定してこれを更新済としてマークします。

  2. 受注/見積に同じPRG（Aを購買すればBとCが無償という方式で販促品モディファイアが設定されている場合）があるために、その他の無償品目明細が存在する場合、updated_flag = Yと設定し、残りの無償品目明細に対する値引を更新済としてマークします。

これで、削除した無償品目明細が再作成されなくなります。呼出し側アプリケーションが無償品目をその他の品目に置換する必要がある場合も、この方法を採用する必要があります。

購買明細を削除する場合、呼出し側アプリケーションは、この購買明細に関連付けられているすべての無償品目、購買明細の調整、無償品目明細の調整、および購買明細と無償品目明細の関連を削除する必要があります。

無償品目明細の運送費

無償品目明細には運送費が適用されません。無償品目の運送費を取得するには、2回目の価格設定エンジン呼出しを行い、price_flag = QP_PREQ_GRP.G_PHASEである無償品目明細のみを挿入します。これにより、無償品目明細の運送費が検索されます。運送費は無償品目明細の価格に影響しません。無償品目明細に運送費（存在する場合）を適用できないのは、運送費を検索するための属性が無償品目明細にマップされていないためです。無償品目明細は価格設定情報とともに挿入され、この明細に挿入される属性は製品のみです。無償品目の運送費を取得するには、呼出し側アプリケーションが価格設定エンジンに対して別の暗黙的呼出しを行う必要があります。運送費呼出しは、process_status = QP_PREQ_GRP.G_STATUS_NEW / G_STATUS_UPDATEDである明細がqp_preq_lines_tmpに存在する場合のみ行う必要があります。この場合、呼出し側アプリケーションはこの暗黙的呼出しを行うことにより、すべての無償品目明細を価格設定エンジンに渡せます。明細グループ・ベースのモディファイアがある場合、受注または見積の価格再設定時に受注または見積に対して無償品目明細が認定されます。たとえば、2つの販促品モディファイアがある場合、Aを追加するとBが無償になります。

Bの運送費の計算時には、Aも渡されている場合、受注または見積に対して無償品目Cを認定することもできます。これを行うには、呼出し側アプリケーションが受注または見積のすべての明細を暗黙的呼出しに渡し、運送費を評価する必要があります。この場合、QP_UTIL_PUB.Get_Order_Line_statusが呼び出され、Get_Order_Line_Statusの出力によってall_lines_flag = QP_PREQ_GRP.G_YESが渡される場合のみ、すべての明細を渡す必要があります。そうでない場合、無償品目明細のみを渡します。Get_Order_Line_Statusによってall_lines_flag = QP_PREQ_GRP.G_YESが渡されるのは、明細グループ・モディファイアまたは他の品目値引モディファイアがある場合です。すべての明細を渡すことにより、見積/受注に対して適用可能なすべてのモディファイアが認定され、後続の価格再設定時に価格が変更されないようにします。

他の品目値引

他の品目値引（OID）は、新規受注明細が作成されない点を除いて、前述した無償品目や販促品と非常に似ています。他の品目値引は購買品目Aとして設定され、品目Aと品目Bの両方を受注した場合、品目Bに対してx%の値引が適用されます。

したがって、OIDとして認定されるには、品目Aと品目Bの両方が要求明細に含まれている必要があります（品目Aと品目Bが含まれる要求明細を価格設定エンジンに渡す必要があります）。この場合、品目Aが含まれる要求明細にOIDモディファイアが適用され、品目Bが含まれる明細に値引が適用されます。

OIDモディファイアは、OIDモディファイアの主要品目である品目Aが含まれる要求明細のline_indexが含まれ、created_from_list_line_type = QP_PREQ_GRP.G_OTHER_ITEM_DISCOUNTであるqp_ldets_vにあります。OID値引は、品目Bが含まれる要求明細のline_indexとともに挿入されます。また、他の明細に対するOIDモディファイアと値引調整間の関連レコードもqp_preq_rltd_lines_tmpに作成されます。この場合、relationship_type_code = QP_PREQ_GRP.G_GENERATED_LINEで、OIDモディファイアのline_detail_indexはline_detail_index、値引調整のline_detail_indexはrelated_line_detail_indexです。これらすべての情報は、呼出し側アプリケーションの取引表に格納する必要があります。

コンフィギュレータからの価格設定

Order Management（OM）およびOrder Capture（OC）のコンフィギュレータは、OM APIおよびOC APIを使用して価格設定エンジンを呼び出します。展開品目および構成品目の場合、unit_priceは0（ゼロ）にデフォルト設定されています。価格設定エンジンが呼び出される場合、展開品目または構成品目が含まれる受注明細がOMプロファイル「OM: 展開品目の手数料」に応じてprice_flag = NまたはPとして価格設定エンジンに渡されます。

このプロファイルが「Y」に設定されている場合、展開品目の運送費を計算する必要があります。この場合、price_flagは「P」です。そうでない場合は「N」です。いずれの場合も、unit_priceは計算されません。

サービス品目の価格設定

サービス品目の価格設定の要求は、Oracle Order Management、Oracle Quoting、Oracle Istore、およびOracle Service Contractsなどの統合アプリケーションによって渡すことができます。

品目に親明細の価格のパーセントとして設定されている価格表明細がある（たとえば、ゴールド・サポートと呼ばれるサービス品目の価格がプラチナ・サービスと呼ばれる親サービス可能品目の価格の10%である）場合、親明細をqp_preq_lines_tmpに渡し、親子の関連をqp_preq_rltd_lines_tmpに渡す必要があります。価格設定にサービス関連およびその他の関連を渡す場合は、API QP_PREQ_GRP.insert_rltd_lines2を使用して次のパラメータを設定します。

12か月間にわたるサービス品目の価格を設定する場合など、一定期間における品目の価格を設定する必要がある場合、期間をuom_quantityとしてqp_preq_lines_tmp体系に渡す必要があります。サービスの開始日および終了日が既知の場合は、それを、contract_start_dateまたはcontract_end_dateとしてqp_preq_lines_tmp体系に渡すことができます。

サービス品目の価格表明細が渡され、親明細の定価に基づいてパーセント価格が計算されます。この場合、親明細が別の受注/見積に属しているのが最適です。親明細を削除または更新する場合、サービス明細も削除または渡す必要があります。

価格設定エンジンに渡されるOrder Management属性

サービス品目の価格設定時には、次のOrder Management属性が価格設定エンジンのアプリケーション・プログラム・インタフェース（API）によって渡されます。

サービス継続期間と価格設定

サービス品目の価格設定時、Oracle Advanced Pricingは、単位（UOM）換算を評価して、次の基準を使用してサービス継続期間を判断します。

次の表に、サービス継続期間が渡される場合と渡されない場合に価格設定が金額を評価する方法を比較して示します。表では、次の用語が使用されます。

-- 要求単位、つまり単位換算なしで検出される価格表 価格表単位と要求単位の間で必要な単位換算 金額算式1
サービス継続期間が渡されている（Order Management、QuotingおよびiStore）

  • 単価は、サービス継続期間全体に対する。



  • 価格設定数量は製品数量と同じ。

  • 単価は価格表にあるものと同じ。



  • 価格設定数量は、製品数量×サービス継続期間。

単価×価格設定数量。
サービス継続期間が渡されない場合（Service Contracts）

  • 単価は価格表にあるものと同じ。



  • 価格設定数量はサービス継続期間と同じ。製品数量は含まれない。

  • 単価は価格表にあるものと同じ。



  • 価格設定数量は価格表単位でのサービス継続期間。製品数量は含まれない。

単価×価格設定数量×製品数量

注意: 1 価格要求（価格設定エンジンではなく）を呼出し側のアプリケーションによって金額が計算されます。

サービス品目のサービス継続期間および拡張され定価の計算例

次に、価格設定がサービス品目の金額を判断するためどのようにサービス継続期間を計算するかの例を示します。価格表設定、入力（価格設定が呼び出し側アプリケーションから受け取る日付およびサービス継続期間）、および価格設定が計算する出力（単価など）の詳細を表に示します。例では、次の価格表設定が使用されます。

次の表に、呼出し側アプリケーションから価格設定に送られる、サービス日付、単位、およびサービス継続期間などの価格要求の入力を示します。価格設定は、これらの入力を評価して、拡張された販売価格を計算します。

価格要求の入力
サービス開始日 サービス終了日 サービス単位 サービス継続期間 製品数量
2006年1月1日 2007年12月31日 年 2 10

次の表に、サービス継続期間が渡される場合と渡されない場合に、価格設定が拡張された定価、単価、価格設定数量（出力）を計算する方法を示します。どちらの場合も、金額は2400ドルです（金額は、Oracle Order ManagementやOracle Service Contractsなど、Oracle Advanced Pricingを呼び出しているアプリケーションによって計算されます）。

サービス日付およびサービス継続期間が渡される場合
-- 単価 価格設定数量 金額1
（単価×価格設定数量）
PL1を使用（単位換算なし） 240ドル（定価×サービス継続期間: 120×2） 10（製品数量と同じ） 240*10 = $2400
PL2を使用（単位換算） 10ドル（価格表上の定価と同じ） 240（製品数量×PL単価でのサービス継続期間 - 月: 10×12×2） 10*240 = $2400
サービス日付は渡されるが、サービス継続期間は渡されない場合
-- 単価 価格設定数量 金額1
（単価×価格設定数量×製品数量）
PL1を使用（単位換算なし） 120ドル（価格表上の定価と同じ） 2（PL単価でのサービス継続期間 - 年） 120*2*10 = $2400
PL2を使用（単位換算） 10ドル（価格表上の定価と同じ） 24（PL単価でのサービス継続期間 – 年: 12×2） 10*24*10 = $2400

1価格設定エンジンではなく呼出し側アプリケーションによって、価格要求後の金額が計算されます。どちらの場合も金額が同じであることに注意してください。

注意: 次の場合は、サービス日付およびサービス継続期間が渡されます。

販促要求

呼出し側アプリケーションは、販促品/モディファイアをクオリファイアとして要求明細に渡すことにより、要求明細に販促要求を適用するよう要求できます。コンテキスト = MODLIST、属性 = QUALIFIER_ATTRIBUTE1、value_from = 販促要求のlist_header_idとして販促要求をクオリファイアとして渡すと、販促要求のすべてのモディファイアが要求明細に適用されます。また、呼出し側アプリケーションは、特定のモディファイア明細を適用するよう要求することもできます。この場合、コンテキスト = MODLIST、属性 = QUALIFIER_ATTRIBUTE2、value_from = 要求対象のモディファイア明細のlist_line_idとしてモディファイア明細を渡す必要があります。これは、Append_ask_forプロシージャの一部として販促/モディファイア要求を属性としてqp_preq_line_attrs_tmpに挿入することで実行できます。

validated_flagが「Y」としてqp_preq_line_attrs_tmpのクオリファイア・レコードに渡される場合、価格設定エンジンは販促/モディファイア要求のクオリファイア設定を参照しません。validated_flagは適切に渡される必要があります。また、販促要求を取引表に格納し、価格再設定呼出しごとにこれらを渡すことにより、販促要求が一貫して適用されるようにする必要があります。

適用された販促要求の削除:

販促要求を削除する必要がある場合は、販促要求を取引表から削除し、価格設定エンジンを呼び出し、販促要求が適用されないようにする必要があります。また、販促要求のモディファイアが上書きされている場合、この販促要求は削除されません。呼出し側アプリケーションは、この販促要求を取引表から削除する必要があります。販促要求の削除時には、販促要求のlist_header_idがある調整を削除する必要があります。呼出し側アプリケーションが特定のモディファイア明細を要求した場合、要求されたモディファイア明細のvalue_fromとlist_line_idが同じである調整を削除する必要があります。

条件代替

要求明細に対して条件代替（TSN）モディファイアが認定されると、created_from_list_line_type = QP_PREQ_GRP.G_TERMS_SUBSTITUTIONとしてqp_ldets_vに明細詳細レコードが挿入されます。

価格設定では、次の3つのタイプの条件アップグレードがサポートされています。

qp_ldets_v.substitution_attribute = QUALIFIER_ATTRIBUTE1である場合、substitution_toにpayment_term_idが保持されます。

If qp__ldets_v.substitution_attribute = QUALIFIER_ATTRIBUTE10である場合、

substitution_toには運送条件コードが保持されます。

qp_ldets_v.substitution_attribute = QUALIFIER_ATTRIBUTE11である場合、

substitution_toには出荷方法が保持されます。

条件タイプであるsubstitution_attributeに基づいて、要求明細に対してTSNモディファイアが認定されると、該当する条件（受注/見積/要求の支払/出荷/運送条件など）をqp_ldets_v.substitution_toの値に置換する必要があります。属性マッピング・ルールがある場合は、価格再設定呼出しを行う前にレコード体系に古い条件を設定し、古い条件が戻されるようにする必要があります。あるいは、属性マッピング・ルールがなく、属性が直接渡される場合は、古い条件が価格設定エンジンに渡されるようにする必要があります。

また、要求明細に対してTSNモディファイアが認定されなくなったために、TSNモディファイアが後続の価格再設定呼出しに渡されない場合、TSNモディファイアを取引表から削除する前に古い条件を置換する必要があります。

クロス受注ボリューム・ベースのモディファイア

Oracle Advanced Pricingは、価格設定またはクオリファイア属性により設定できるクロス受注ボリューム・ベースのモディファイアを備えています。価格設定属性には、「期間1 品目数量」や「期間1 品目金額」などがあります。これらの属性は営業単位固有であり、オーダー管理PTEでシードされます。クロス受注ボリューム金額（期間1 品目金額など）は、販売価格ではなく定価により計算されます。したがって、計算された金額は、販売価格に基づくOrder Managementに表示される受注合計とは異なるものになります。

特定の営業単位のクロス受注ボリューム合計を検出するには、コンカレント・プログラム「クロス受注ボリューム・ローダー」を実行する必要があります。このプログラムは、受注管理（OM）表の受注情報を検証し、OM表のOE_ITEM_CUST_VOLS_ALLおよびOE_ITEM_CUST_VOLS_ALLを設定します。詳細は、『Oracle Advanced Pricingユーザーズ・ガイド』のレポートおよびコンカレント・プログラムに関する項を参照してください。

注意: モディファイア・レベル: クロス受注ボリューム属性によってモディファイアを設定している場合は、「明細のグループ」モディファイア・レベルではなく「明細」モディファイア・レベルを選択します。これをお薦めする理由は次のとおりです。1)クロス受注ボリューム属性は、現在のオーダーの受注に基づかず、以前に記帳された受注に基づく。2）クロス受注ボリューム・ロード属性の使用時には、以前の受注全体の明細の合計がすでに考慮される。

定型価格: クロス受注ボリューム・ローダーでは、定型価格が計算から除外されます。チャージ周期がNULLの受注明細のみ、この計算に含められます。

また、シード済属性マッピング・ルールにより、OMクロス受注ボリューム表から特定の属性のクロス受注ボリューム合計が取得されます。価格設定エンジンは、build_contexts APIが戻すクロス受注ボリューム属性に基づいて、要求明細に対してモディファイアを認定します。呼出し側アプリケーションが新規request_type_codeまたは別のグローバル体系を使用している場合、次の手順を実行して、価格設定エンジンがクロス受注ボリューム・ベースの値引を処理するようにします。

  1. モディファイアの設定時に使用されるクロス受注ボリューム属性ごとに前述の表または新規の表にクロス受注ボリューム合計を設定するコンカレント・プログラムを作成します。

  2. モディファイアの設定時に使用されるクロス受注ボリューム属性ごとにクロス受注ボリューム合計を抽出する属性マッピング・ルールを作成します。

クロス受注ボリュームの詳細は、『Oracle Advanced Pricingユーザーズ・ガイド』のクロス受注ボリューム・ロードおよびクロス受注ボリューム・レポートに関する項を参照してください。

販促限度

販促限度は、モディファイアに対して設定されます。価格設定エンジン呼出しが行われると、要求明細に適したモディファイアが認定されます。これらのモディファイアに限度が設定されている場合、適用されるモディファイアはこの限度から消費されます。価格設定エンジンは、限度残高詳細を保守する限度エンジンを呼び出します。限度機能を使用するには、price_request_codeを渡して各要求明細を一意に識別する必要があります。

たとえば、request_type_code||'-'||header_id||'-'||line_idを連結してprice_request_codeを作成します。限度消費は価格設定限度表で要求明細ごとに更新され、price_request_codeは要求明細を識別するためのキーとして使用されます。価格設定エンジン呼出しの後は、限度に関するエラーを処理する必要があります。限度が原因でエラーが発生した場合、各要求明細のqp_preq_lines_tmp.pricing_status_codeにエラー・ステータスが設定されます。エラーは適切に処理される必要があります。価格設定エンジン呼出しの目的が受注の価格設定である場合、限度が原因で明細の1つに対してエラー・ステータスが出されると、ビジネス要件に応じて受注または特定の明細が保留されたり、警告メッセージが表示されることがあります。

限度消費

限度消費では、手動モディファイアまたは上書きされた自動/手動モディファイアおよびフェーズ外のモディファイアは評価されません。フェーズ外のモディファイアとは、現在の価格設定イベントに属さない価格設定フェーズ内にある以前の価格設定イベントで適用されたモディファイアです。たとえば、受注明細が入力済および保存済で、その受注明細の価格が$80であったとします。限度は、たとえば10ドルのみを消費するバケットされた新規価格モディファイアで20ドルに定義されています。限度APIは、調整金額により新規価格モディファイアを適用するため、10ドルのみを消費できます。限度が20ドルすべてを消費できるというように、以前のバケットでモディファイアが上書きされている場合でも、限度エンジンは上書きされたモディファイアを参照せず、10ドルのみの消費を許可します。これは、以前のバケットにフェーズ外モディファイアまたは手動モディファイア、あるいは上書きされたモディファイアが存在する、バケットされたモディファイアで定義された限度に固有の問題です。

受注明細が戻されたり修正または取消しが行われる場合、限度残高を更新する必要があります。呼出し側アプリケーションが価格設定エンジン呼出しを行う場合、価格設定エンジンはこの処理をprice_request_code passedに対して実行します。価格設定エンジン呼出しが行われない場合、この処理を行うためのAPIが提供されます。限度消費詳細を更新するには、次のAPIを呼び出す必要があります。

QP_UTIL_PUB.Reverse_Limits (p_action_code             IN  VARCHAR2,
     p_cons_price_request_code IN  VARCHAR2,
     p_orig_ordered_qty        IN  NUMBER   DEFAULT NULL,
     p_amended_qty             IN  NUMBER   DEFAULT NULL,
     p_ret_price_request_code  IN  VARCHAR2 DEFAULT NULL,
     p_returned_qty            IN  NUMBER   DEFAULT NULL,
     x_return_status           OUT VARCHAR2,
     x_return_message          OUT VARCHAR2);

このAPIの詳細は、『Oracle Order Management Open Interfaces, API, & Electronic Messaging Guide』を参照してください。

複数通貨

複数通貨機能では、渡された価格表が渡された通貨に含まれる必要があります。または、渡された通貨が渡された価格表に含まれる必要があります。渡された通貨コードが複数通貨価格表の一部ではない場合、価格設定エンジンは価格を見つけることができません。これらが確実に含まれるよう、価格設定には、渡された通貨および価格表を検証するためのAPIが用意されています。この検証は、統合コードで行う必要があります。このAPIは次のようになります。

QP_UTIL_PUB.Validate_Price_list_Curr_code
(
     l_price_list_id             IN NUMBER
     l_currency_code             IN VARCHAR2
     l_pricing_effective_date    IN DATE
     l_validate_result          OUT VARCHAR2
);

詳細は、『Oracle Order Management Open Interfaces, API, & Electronic Messaging Guide』を参照してください。価格を導出するためにプロファイル「QP: 複数通貨インストール済」が「Y」に設定されている場合、価格設定エンジンは複数通貨の価格表を検索します。

また、価格設定では、端数処理した販売価格または調整金額を戻すAPIが用意されており、複数通貨の価格表および受注通貨に基づいて端数処理ファクタが使用されます。価格設定エンジンによる端数処理とは別に端数処理を行う必要がある場合、このAPIを使用できます。APIは次のように呼び出します。

QP_UTIL_PUB.Round_price(p_operand        => null
     ,p_rounding_factor         => null
     ,p_use_multi_currency      => p_use_multi_currency
     ,p_price_list_id           => p_price_list_id
     ,p_currency_code           => p_currency_code
     ,p_pricing_effective_date  => p_pricing_effective_date
     ,x_rounded_operand         => l_rounding_factor
     ,x_status_code             => l_status_code
     ,p_operand_type            => 'R'
);

以前に価格設定した受注または見積の価格表または通貨を変更する場合、異なる通貨に基づいて異なる価格が戻されることがあるため、要求の価格を必ず再設定してください。

価格設定エンジン呼出しを行うサンプル・スクリプトは複数あります。これらのサンプル・スクリプトには次のものがあります（$QP_TOP/patch/115/sqlを参照）。

他のOracle Applicationsによる複数通貨機能の組込み要件

Oracle Advanced Pricingでは、複数通貨価格表機能を使用して、複数通貨を同じ価格表または基本契約に添付できます。これにより、処理されるデータ量を削減し、ユーザーによる保守作業量を大幅に軽減できます。また、GL日次レート、固定レート、ユーザー入力および機能呼出しなど、換算レートを導出するための方法を各種設定できます。

複数通貨の価格表を使用したインストールをサポートするために、呼出し側アプリケーションによって次のステップが使用されます。

  1. Order Management Minipack-Hまたはアプリケーション・リリース11.5.8以上をインストールします。

  2. サイト・レベルのプロファイル・オプション「QP: 複数通貨インストール済」を「Yes」に設定します。

  3. コンカレント・プログラム「複数通貨換算基準で価格表の更新」を実行します。コンカレント・プログラムの実行後、すべての価格表および基本契約価格表が複数通貨の価格表に変換されます。

  4. ユーザーが複数通貨の価格表に変換した場合、通貨の換算を有効にするには、価格設定エンジンを呼び出すアプリケーションが管理レコード変数use_multi_currencyを「Yes（Y）」として価格設定エンジン呼出しに渡す必要があります。この変数は、呼出し側アプリケーションが複数通貨機能を起動するかどうかを決定するためのファクタです。

  5. ヘッダーおよび明細の価格表名の呼出し側アプリケーションLOV（値リスト）を変更し、複数通貨の価格表および通貨を示す必要があります。

  6. 価格表の新規端数処理APIを組み込みます。価格再設定処理の場合、呼出し側アプリケーションは、価格再設定処理時に価格表端数処理用のQP_UTIL_PUB.round_priceを呼び出す必要があります。これにより、「丸め処理先」の値を使用して価格の端数が処理されます。

  7. 「換算タイプ」が「取引」である場合、呼出し側アプリケーション統合は、「受注」ヘッダーに入力された換算レートおよび換算タイプ（存在する場合）を価格設定エンジンに渡す必要があります。

  8. 呼出し側アプリケーション統合は、機能通貨を価格設定エンジンの管理レコード変数function_currencyに渡す必要があります。

受注管理体系を使用したサンプル・コード

procedure copy_Line_to_request(

p_Line_rec OE_Order_PUB.Line_Rec_Type
,px_req_line_tbl in out nocopy QP_PREQ_GRP.LINE_TBL_TYPE
,p_pricing_event varchar2
,p_Request_Type_Code varchar2
)
is
l_line_index pls_integer := nvl(px_req_line_tbl.count,0);
l_uom_rate NUMBER;
v_discounting_privilege VARCHAR2(30);
begin
l_line_index := l_line_index+1;
px_req_line_tbl(l_line_index).Line_id := p_Line_rec.line_id;
px_req_line_tbl(l_line_index).REQUEST_TYPE_CODE :=
p_Request_Type_Code;
px_req_line_tbl(l_line_index).LINE_INDEX := l_line_index;
px_req_line_tbl(l_line_index).LINE_TYPE_CODE := 'LINE';
If p_Line_rec.pricing_date is null or
p_Line_rec.pricing_date = fnd_api.g_miss_date then
px_req_line_tbl(l_line_index).PRICING_EFFECTIVE_DATE :=
trunc(sysdate);
Else
px_req_line_tbl(l_line_index).PRICING_EFFECTIVE_DATE :=
p_Line_rec.pricing_date;
End If;
px_req_line_tbl(l_line_index).LINE_QUANTITY :=
p_Line_rec.Ordered_quantity ;
px_req_line_tbl(l_line_index).LINE_UOM_CODE :=
p_Line_rec.Order_quantity_uom;
px_req_line_tbl(l_line_index).CURRENCY_CODE :=

OE_Order_PUB.g_hdr.transactional_curr_code;

If (p_Line_rec.service_period = p_Line_rec.Order_quantity_uom) Then
px_req_line_tbl(l_line_index).UOM_QUANTITY :=
p_Line_rec.service_duration;
Else
INV_CONVERT.INV_UM_CONVERSION(From_Unit =>
p_Line_rec.service_period
,To_Unit => p_Line_rec.Order_quantity_uom
,Item_ID => p_Line_rec.Inventory_item_id
,Uom_Rate => l_Uom_rate);
px_req_line_tbl(l_line_index).UOM_QUANTITY :=
p_Line_rec.service_duration * l_uom_rate;
End If;
px_req_line_tbl(l_line_index).Active_date_first_type := 'ORD';
px_req_line_tbl(l_line_index).Active_date_first :=
OE_Order_Pub.G_HDR.Ordered_date;
If p_Line_rec.schedule_ship_date is not null then
px_req_line_tbl(l_line_index).Active_date_Second_type := 'SHIP';
px_req_line_tbl(l_line_index).Active_date_Second :=
p_Line_rec.schedule_ship_date;
End If;
px_req_line_tbl(l_line_index).PRICE_FLAG :=
nvl(p_Line_rec.calculate_Price_flag,'Y');
end copy_Line_to_request;

copy_attributes_to_Requestプロシージャ

p_line_index number
,p_pricing_contexts_Tbl
QP_Attr_Mapping_PUB.Contexts_Result_Tbl_Type
,p_qualifier_contexts_Tbl QP_Attr_Mapping_PUB.Contexts_Result_Tbl_Type
,px_Req_line_attr_tbl in out nocopy
QP_PREQ_GRP.LINE_ATTR_TBL_TYPE
,px_Req_qual_tbl in out nocopy
QP_PREQ_GRP.QUAL_TBL_TYPE
)
is
i pls_integer := 0;
l_attr_index pls_integer := nvl(px_Req_line_attr_tbl.last,0);
l_qual_index pls_integer := nvl(px_Req_qual_tbl.last,0);
begin
i := p_pricing_contexts_Tbl.First;
While i is not null loop
l_attr_index := l_attr_index +1;
px_Req_line_attr_tbl(l_attr_index).VALIDATED_FLAG := 'N';
px_Req_line_attr_tbl(l_attr_index).line_index := p_line_index;
-- Product and Pricing Contexts go into pricing contexts...
px_Req_line_attr_tbl(l_attr_index).PRICING_CONTEXT
:=
p_pricing_contexts_Tbl(i).context_name;
px_Req_line_attr_tbl(l_attr_index).PRICING_ATTRIBUTE :=
p_pricing_contexts_Tbl(i).Attribute_Name;
px_Req_line_attr_tbl(l_attr_index).PRICING_ATTR_VALUE_FROM :=
p_pricing_contexts_Tbl(i).attribute_value;
i := p_pricing_contexts_Tbl.Next(i);
end loop;
-- Copy the qualifiers
i := p_qualifier_contexts_Tbl.First;
While i is not null loop
l_qual_index := l_qual_index +1;
If p_qualifier_contexts_Tbl(i).context_name ='MODLIST' and
p_qualifier_contexts_Tbl(i).Attribute_Name
='QUALIFIER_ATTRIBUTE4' then
If OE_Order_PUB.G_Line.agreement_id is not null and
OE_Order_PUB.G_Line.agreement_id <>
fnd_api.g_miss_num then
px_Req_Qual_Tbl(l_qual_index).Validated_Flag := 'Y';
px_Req_Qual_Tbl(l_qual_index).Validated_Flag
:= 'N';
End If;
Else
px_Req_Qual_Tbl(l_qual_index).Validated_Flag := 'N';
End If;
px_Req_qual_tbl(l_qual_index).line_index := p_line_index;
px_Req_qual_tbl(l_qual_index).QUALIFIER_CONTEXT :=
p_qualifier_contexts_Tbl(i).context_name;
px_Req_qual_tbl(l_qual_index).QUALIFIER_ATTRIBUTE :=
p_qualifier_contexts_Tbl(i).Attribute_Name;
px_Req_qual_tbl(l_qual_index).QUALIFIER_ATTR_VALUE_FROM :=
p_qualifier_contexts_Tbl(i).attribute_value;
i := p_qualifier_contexts_Tbl.Next(i);
end loop;
end copy_attributes_to_Request;
procedure copy_Header_to_request(
p_header_rec OE_Order_PUB.Header_Rec_Type
,px_req_line_tbl in out nocopy QP_PREQ_GRP.LINE_TBL_TYPE
--,p_pricing_event varchar2
,p_Request_Type_Code varchar2
,p_calculate_price_flag varchar2
)
is
l_line_index pls_integer := px_req_line_tbl.count;
begin
l_line_index := l_line_index+1;
px_req_line_tbl(l_line_index).REQUEST_TYPE_CODE
:=p_Request_Type_Code;
--px_req_line_tbl(l_line_index).PRICING_EVENT :=p_pricing_event;
--px_req_line_tbl(l_line_index).LIST_LINE_LEVEL_CODE
:=p_Request_Type_Code;
px_req_line_tbl(l_line_index).LINE_INDEX := l_line_index;
px_req_line_tbl(l_line_index).LINE_TYPE_CODE := 'ORDER';
-- Hold the header_id in line_id for 'HEADER' Records
px_req_line_tbl(l_line_index).line_id := p_Header_rec.header_id;
if p_header_rec.pricing_date is null or
p_header_rec.pricing_date = fnd_api.g_miss_date then
ptrunc(sysdate);
x_req_line_tbl(l_line_index).PRICING_EFFECTIVE_DATE :=
Else
px_req_line_tbl(l_line_index).PRICING_EFFECTIVE_DATE :=
p_header_rec.pricing_date;
End If;
px_req_line_tbl(l_line_index).CURRENCY_CODE :=
p_Header_rec.transactional_curr_code;
px_req_line_tbl(l_line_index).PRICE_FLAG := p_calculate_price_flag;
px_req_line_tbl(l_line_index).Active_date_first_type := 'ORD';
px_req_line_tbl(l_line_index).Active_date_first :=
p_Header_rec.Ordered_date;
end copy_Header_to_request;

価格設定エンジンの挿入APIの呼出しについては、$QP_TOP/patch/115/sqlのサンプル・スクリプトqp_direct_insert.sqlを参照してください。

変更済明細API

このAPIによって、変更済明細および関連する明細を価格設定エンジンに渡すことができます。これによって、不要な価格設定処理が減り、パフォーマンスが向上します。

一般的な価格設定では、受注または見積ごとに複数の受注明細または見積明細があります。Oracle Advanced Pricingを使用して取引の価格設定を行うOrder ManagementやOrder Captureなどの呼出し側アプリケーションは、単一の価格設定要求内の1つ以上の受注明細を使用して、価格設定エンジンを呼び出します。受注ごとに全受注明細を渡すのではなく、変更された明細（新規に入力された明細、または更新された既存の明細）のみを価格設定エンジンに渡すと効率的です。これは、価格設定エンジンで不要な明細（処理しても同じ価格になる明細）を処理する必要がないためです。

呼出し側アプリケーションは、QP_UTIL_PUB.Get受注明細ステータスを呼び出して、エンジンに渡す明細を決定します。このAPIの出力レコードには、次の3つのフラグがあります。

All_Lines_Flag（YesまたはNo）

このフラグは、呼出し側アプリケーションに、全明細をエンジンに渡す必要があるかどうかを指示します。このフラグの値は、価格設定によって決まります。これらのモディファイアの場合、価格設定エンジンが値引の適格性を評価するために全明細情報が必要です。

Changed_Lines_Flag（YesまたはNo）

このフラグが'Y'に設定されている場合は、変更済明細のみエンジンに渡すことができます。明細レベルのモディファイアのみ存在する場合、このフラグは「Y」です。

Summary_Line_Flag（YesまたはNo）

このフラグの値は、受注レベルのモディファイア設定によって決まります。これらのモディファイアで、このフラグはY（Yes）に設定されます。これによって、受注要約明細のみエンジンに渡すことができます。

変更済明細API以外に、QP_ATTR_MAPPING_PUB.Build_contexts APIを署名Build_Contextsとともに使用できます。

(       p_request_type_code,               p_line_index,
     p_check_line_flag,
     p_pricing_event,
     p_pricing_type_code,
     p_org_id,
     x_pass_line)

変更済明細APIがAll_lines_flagをY（Yes）として渡した場合、build_contexts APIを属性マッピングに使用できます。変更された実績明細ではp_check_line_flagがN（No）として渡され、変更されなかった残りの明細ではp_check_line_flagがY（Yes）として渡されます。p_check_line_flagがY（Yes）として渡された明細で、このAPIは、アクティブで詳細な明細グループまたは他の品目値引タイプのモディファイア、あるいはその明細に対して指定される製品属性に基づいて定義された追加購入製品を伴う販促品モディファイアが存在するかどうかをチェックします。

このようなモディファイアが存在する場合は、「コンテキストのビルド」APIが、すべての製品/価格設定/クオリファイア属性を指定するとともにx_pass_lineをYとして戻して、呼出し側がこの明細を価格設定エンジンに渡す必要があることを示します。これは、明細が変更されていない場合も、受注/見積上の残りの明細の価格が影響を受ける可能性があるためです。このようなアクティブなモディファイアが見つからない場合、その明細には属性が指定されず、x_pass_lineはNoとして戻され、これによって、呼出し側がパフォーマンスのオーバーヘッドを回避するためにこの明細を価格設定エンジンに渡す必要はなくなります。

使用例

事例1

100明細を持つ受注で5明細が変更されました。設定: All_Lines_Flag = 'N', Changed_Lines_Flag = 'Y', Summary_Line_Flag = 'N' 結果: 変更された5明細のみ価格設定エンジンに渡されます。

事例2

100明細を持つ受注で全明細が変更されました。

設定: All_Lines_Flag = 'Y'、Changed_Lines_Flag = 'Y/N'、Summary_Line_Flag = 'N'

結果: 100明細すべてが価格設定エンジンに渡されます。

事例3

100明細を持つ受注で5明細が変更され、他の品目値引、販促品または明細のグループの値引のいずれかです。

設定: All_Lines_Flag = 'Y'、Changed_Lines_Flag = 'Y/N'、Summary_Line_Flag = 'N'

結果: 全明細が価格設定エンジンに渡されます。

事例4

100明細を持つ受注で5明細が変更され、受注レベルのモディファイアです。

設定: All_Lines_Flag = 'N'、Changed_Lines_Flag = 'Y'、Summary_Line_Flag = 'Y'

結果: 5明細および要約明細が価格設定エンジンに渡されます。

事例5

100明細を持つ受注で変更された明細はありませんでした。

設定: All_Lines_Flag = 'N'、Changed_Lines_Flag = 'N'、Summary_Line_Flag = 'N'

結果: 明細は価格設定エンジンに渡されません。

事例6

2明細が100明細を持つ受注に新規に追加されました。

設定: All_Lines_Flag = 'N'、Changed_Lines_Flag = 'Y'、Summary_Line_Flag = 'N'

結果: 追加された2明細のみ価格設定エンジンに渡されます。

Oracle Service Contracts（OKS）統合: 按分と価格表のロック

この項では、Oracle Service Contracts（OKS）がOracle Advanced Pricing（QP）に統合されているときに使用できる使用の按分機能と価格表のロック機能について説明します。OKS APIは、サービス継続期間の計算および開始日と終了日の決定に使用されます。使用の按分は、使用呼出しを行うすべての呼出し側アプリケーションで使用できます。価格表のロックは、OKSによる使用に対してのみ有効です。価格表のロックとは、次を示します。

たとえば、Oracle Service Contractsが法人価格表でlist_line_id = 201である価格表明細をロックする必要がある場合、次のようになります。

ロック済価格表明細は、OKS LOCKED Corporateという名前で作成されます。命名規則は、次のとおりです。

<Source System Code> || 'LOCKED' || <Source Price List>.

ロック済価格表明細はlist_line_id = 201である価格表明細からコピーされ、ロック済価格表OKS LOCKED Corporateに作成されます。たとえば、list_line_id = 301であるロック済明細は、次のように設定された価格設定属性を持ちます。

すでにロック済の価格表および価格表明細のロック

以前のリリースでは、ロック済の価格表および価格表明細は、ユーザー・インタフェース（UI）から作成する必要がありました。ただし、現在のリリースでは、APIがOKSコードからプログラムで呼び出され、ユーザーの介入なしに価格表および価格表明細をロックします。すでにロック済の価格表および明細もロックできるようになりました。

たとえば、<ソース・システム・コード> ||'LOCKED'|| <ソース価格表名>という名前のすでにロック済の価格表をロックするとします。ただし、ソース価格表名には、たとえば<ソース・システム・コード> ||'LOCKED'プリフィクスのようにすでにロックされた名前が割り当てられている場合、新しい名前は、<ソース・システム・コード> ||' LOCKED'|| <バージョン番号> || ' ' <元のソース価格表名>の形式を使用して、ロックされた価格表に自動的に割り当てられます。バージョン番号は2以降となります。たとえば、ソース価格表がCorporateという名前の場合、ロック済価格表は、QP LOCKED Corporateという名前になります。ただし、ソース価格表名がQP LOCKED Corporateの場合、ロック済価格表名はQP LOCKED2 Corporateとなります。

価格明細のロック

すでにロック済の価格表明細もロックできます。ソース価格表の価格表明細が、ロック済価格表の子としてコピーされる（ロック済価格表明細となる）と、価格明細がロックされます。たとえば、Oracle Service Contracts（OKS）がOKS LOCKED法人価格表でlist_line_id = 201である価格表明細をロックする必要があるとします。価格明細はすでにロック済であるため、その価格設定属性では、コンテキスト = QP Internal、属性 = List Line Id、値 = 201となります。

その後の手順は、次のようになります。新しくロックされる価格表明細は、list_line_id = 201の価格表明細のコピーとして、ロック済価格表であるOKS LOCKED2法人価格表の下に作成されます。たとえばlist_line_id = 301の新しいロック済明細には、list_line_id = 201のソース価格表明細からコピーされたその他の価格設定属性に加えて、コンテキスト = QP Internal、属性 = List Line Id、および値 = 301の新しい価格設定属性が添付されます。

ただし、list_line_id = 201のソース価格表明細に添付されているコンテキスト = QP Internal、属性 = List Line Id、および値 = 201の価格設定属性は、ソースからlist_line_id = 301を持つ新しくロックされる価格表明細にコピーされません。

注意: ロック済価格表は、特定のソース価格表およびソース・システム・コードに対して1回のみ作成されます。後続のロック要求については、既存のロック済価格表の下位にロック済価格表が新しく作成されます。

コピーされた価格表の有効日

ロック済価格表および価格表明細に有効日はコピーされません。ただし、OKSにより、関連するService Contractで有効日を使用することで、有効日を管理できます。

価格表のロックの統合フロー

次のステップは、価格表のロックの処理フローを示します。

  1. アプリケーションOracle Service Contracts（OKS）は、オーサリング単位を使用し、価格設定エンジンに対してオーサリング呼出しを行います。オーサリング単位には、四半期、月、年などの品目単位を使用できます。

  2. 価格設定エンジンは、価格表明細および価格分岐を戻します（数量が渡されない場合、価格分岐は計算されません）。

  3. OKSによって価格表明細/分岐（ロック済分岐など）がOKSのユーザー・インタフェースでOKSユーザーに表示され、更新が可能になります。価格表明細の製品は、ステップ2で戻された価格表明細と同じである必要があります。

  4. OKSによって「価格表」ウィンドウが表示され、ロック済価格表、ロック済価格表明細およびその分岐の作成がサポートされます。ウィンドウ・パラメータには次の関連値が渡され、'OKS '|| 'LOCKED ' || <ソース価格表名>という名前で新規価格表の作成および問合せが行われます。

    LOCK_MODE（='Y'）

    SOURCE_PRICE_LIST_ID

    SOURCE_LIST_LINE_ID

    ORIG_SYS_HEADER_REF（= 契約番号）

    STARTUP_MODE（= OKS）

    STARTUP_MODE = OKS

    NULLに設定されたSTART_DATE_ACTIVEおよびEND DATE ACTIVE列

  5. list_line_idと同じ値を使用してロック済PBH（価格分岐ヘッダー）明細に価格設定属性が作成されます。これにより、価格設定エンジンがこの特定の明細を選択できるようになります。ロック済PBH価格表明細の有効日（START_DATE_ACTIVEおよびEND_DATE_ACTIVE）はNULLに設定されます。

  6. OKSは、請求時に価格設定エンジンを呼び出すときに、価格表明細IDの外部キーを格納し、価格表IDを渡します。

  7. ロック済価格分岐をさらに更新するために、OKSは、適切なパラメータ（LOCK_MODE= 'N'、LOCKED_PRICE_LIST_ID、LOCKED_LIST_LINE_ID、STARTUP_MODE = 'OKS'）を使用して価格表フォームを起動し、指定したロック済価格表およびロック済価格表明細を問い合せます。

  8. OKSは、請求時に価格設定エンジンを呼び出し、按分用の単位を提供します。この場合、価格設定エンジンが正確に同じ価格を戻すことが前提です。

  9. LIST_SOURCE_CODE = 'OKS'であり、orig_system_header_refがNULLでない場合、OKSによって作成された価格表は「価格設定」ウィンドウでは更新できなくなります。

  10. ロック済価格分岐がある価格表は、パージAPIを使用して削除できます。ただし、パージするのは、無効な価格表のみにする必要があります。OKSは、価格設定パブリックAPIを使用して価格表を無効化します。

  11. 請求呼出し時には、契約IDおよび価格表がクオリファイアとして渡されます。また、価格表明細IDが価格設定属性として渡されます。

価格表のロックの統合フローの例

次のステップは、Oracle Service Contracts（OKS）がOracle Advanced Pricing（QP）に統合されているときの価格表のロックの統合フローを示します。

  1. 契約ヘッダーを定義し、価格表名（法人など）を選択します。

  2. 契約明細を入力し、品目を選択します。

    契約ヘッダーの価格表（法人など）を使用して価格設定エンジンが呼び出されます。価格分岐情報が戻され、情報が「契約」ウィンドウに表示されます。

  3. 品目の価格をロックするには、「ロック」ボタンをクリックします。

  4. この時点で、次のウィンドウ・パラメータが設定されます。

  5. その後で、次の処理が行われます。

    1. この呼出しがOKSからである（Startup_Mode = OKS）かどうかチェックします。

    2. Startup_Mode = OKSである場合、Lock_mode = Yであるかどうかチェックします。Startup_Mode = OKSでない場合、更新ステップに進みます。

    3. Lock_mode = Yである場合、レコードがqp_list_headers_bにあるかどうかチェックします。この場合、次のようになります。

    4. Source_system_code =「QP: ソース・システム・コード」のプロファイル・オプション値

    5. Locked_from_list_header_id = Source_price_list_id

    6. レコードがない場合は、新規価格表を作成する必要があります。このため、新規価格表のレコード体系が設定されます。ソース・システム・コードがOKSであり、「有効日:自」および「有効日:至」列がNULLであることを確認します。

    7. レコードがある場合、ロック済価格表に新規明細を作成する必要があり、明細体系を設定する必要があります。

    8. PBH明細、その属性および価格分岐の子明細をコピーします。次のようにする必要があります。

      • コピー済（ロック済）PBH明細レコードの「有効日:自」および「有効日:至」列をNULLに設定します。

      • 新規作成したPBH明細のlist_line_idを使用して、価格設定属性をPBH明細に追加します。レコードを転記します。

    9. 新しく挿入またはロックした価格表を問い合せます。

    10. 価格表明細ブロックの問合せ前に、WHERE句を設定して、新しく作成またはロックしたPBH明細を問い合せます。

    11. 「価格表明細」タブにナビゲートします。「価格分岐」タブをクリックし、価格分岐を更新します。

    12. グローバル変数を設定（.pldファイルに設定）し、最後に作成または変更したprice_list_idおよびlist_line_idをOKSに渡し戻します。

    13. 問合せ後に、WHERE句を消去して元のステータスに戻します。

    14. モードが「更新」である場合、ステップg）以降のステップを実行します。

  6. すでにロックされている既存のPBH明細を問い合せている場合、OKSは、List_line_idを価格設定属性として価格設定エンジンを呼び出す必要があります。これを行うには、「サービス契約オーサリング」ウィンドウにナビゲートします。

  7. 削除またはロック解除を行うには、価格設定APIを直接呼び出して価格表明細を削除する必要があります。

  8. アプリケーションがOKSである場合、Oracle Advanced Pricing（QP）は、シード・データをデフォルトのプロファイル「QP: ソース・システム・コード」に変更する必要があります。また、OKSをオーダー管理PTEに追加します。

  9. QPは、List_Line_Idを価格設定属性としてシードする必要があります。この価格設定属性には、PRICING ATTRIBUTEの価格設定コンテキストは使用できません。前述の価格設定属性を割り当てるには一般的な価格設定コンテキストが必要であるため、QP INTERNALと呼ばれる新規価格設定コンテキストも作成/シードされます。

    ロック済価格表の名前は、プリフィクス<ソース・システム・コード> || ' LOCKED ' || <ソース価格表名>（OKS LOCKED Corporateなど）である必要があります。

価格表のロック機能に関連する変更

「価格表」ウィンドウには、次のパラメータが追加されました。これらはエンド・ユーザーからは見えませんが、価格表のロック機能との統合には必要です。

パラメータ データ型 意味/値
LOCK_MODE CHAR(1) 有効値は「Y/N」です。ロック・モードがYesとNoのどちらであるかを示します。「価格表」ウィンドウの起動時に、OKSによって適切な値が渡されます。
LOCKED_PRICE_LIST_ID NUMBER Lock_Mode = Nである場合、「価格表」ウィンドウの起動時に、OKSによってロック済価格表のlist_header_idが渡されます。
LOCKED_LIST_LINE_ID NUMBER Lock_Mode = Nである場合、「価格表」ウィンドウの起動時に、OKSによってロック済価格表明細のlist_line_idが渡されます。
SOURCE_PRICE_LIST_ID NUMBER Lock_Mode = Yである場合、「価格表」ウィンドウの起動時に、OKSによってソース価格表のlist_header_idが渡されます。
SOURCE_LIST_LINE_ID NUMBER Lock_Mode = Yである場合、「価格表」ウィンドウの起動時に、OKSによってソース価格表明細のlist_line_idが渡されます。

次のグローバル変数により、情報がOKSに渡し戻されます。

パラメータ 意味/値
LOCKED_PRICE_LIST_ID OKSによって起動された「価格表」ウィンドウで作成または変更された最後のロック済価格表のLIST_HEADER_IDを持ちます。
LOCKED_LIST_LINE_ID OKSによって起動された「価格表」ウィンドウで作成または変更された最後のロック済価格表明細のLIST_LINE_IDを持ちます。

価格表ロック機能には、次の変更も関連しています。

按分の統合フロー

Oracle Service Contracts（OKS）は、Oracle Advanced Pricingの顧客に対し按分請求をサポートします。次のステップは、呼出し側アプリケーションに必要な変更と価格設定エンジンの動作を示します。

  1. 呼出し側アプリケーションは、ボリューム数量（500など）およびMONTHなどの（usage_break_UOM）とともに請求呼出しを価格設定エンジンに発行します。呼出し側アプリケーションがusage_break_UOM属性を渡さない場合、換算は必要なく、通常の価格分岐評価が行われます。

  2. 価格設定エンジンは、次を評価します。

  3. 価格設定は、単位換算のために契約APIを呼び出します。この契約APIには、qp_preq_lines_tempのservice_start_dateおよびend_dateとともに設定分岐単位が渡されます。

  4. このAPIは、按分用として換算ファクタを戻します。契約プロファイルが設定されていない場合、標準単位換算が行われます。たとえば、換算が1/3の場合、「分岐: 自/至」値は、下表のように換算されます。

    元の開始値/終了値 変更後の開始値 変更後の終了値
    0 - 1000 0 333.333.....3
    1000 - 2000 333.333...3 666.666...6
    2000 - 3000 666.666...6 1000

    注意: 表に示された値は、切り捨てられません。

  5. 価格設定エンジンは、前述の「分岐: 自/至」を評価し、呼出し側アプリケーションに設定分岐単位を戻します。

  6. OKSは按分計算のために次の値を価格設定エンジンに渡す必要があります。コンテキスト = BreakUOM、属性 = Pricing_Attribute1、値 = 請求単位

注意: 固定使用または実績使用に基づいて請求される新規に按分される連続する価格分岐が、リリース12以前に按分された価格分岐と異なる金額を持つ場合があります。按分される連続する価格分岐の層は、最小まで計算されません（つまり、前の自然数に設定されます）。

按分機能に関連する変更

「価格表」ウィンドウでは、「価格表明細」タブに価格分岐を入力するための2つの追加列が表示されます。

これらの列を表示するには、プロファイル・オプション「QP: 分岐単位按分を許可」を「Yes」に設定する必要があります。有効値は「Yes」または「No」です。これは、サイト・レベルおよびアプリケーション・レベルの両方で設定できます。

サービス品目の継続期間および一部期間の価格設定

継続期間は、特定のサービスに対する期間を定義します。一部期間の価格設定は、契約継続期間が変更された場合に、価格を変更するために必要です。たとえば、現在2年間のサービス・プログラムを契約中の顧客ABC Applications Softwareが、サービス契約を更新して、拡張したノートPCサービス・プログラムに対し、さらに10か月の追加を望んでいるとします。

Oracle Advanced PricingをOracle Service Contractsとともに使用して、継続期間および一部期間の価格設定を計算できます。Service Contractsを使用すると、Service Contracts換算ルーチン（単位換算を使用または不使用）を呼び出して明細数量を導出することにより、契約のサービス継続期間が契約の開始日/終了日から計算されます。

注意: 日付が渡されない場合は、在庫換算ルーチンが使用されます。

すべての呼出し側アプリケーションで一部期間の価格設定が一貫性を持つようにするため、Oracle Advanced Pricingでは、単位数量または契約の開始日が価格設定エンジンに渡されているかどうかによって、サービス明細の一部期間の価格設定の計算方法が異なります。

Oracle Service Contracts（OKS）での使用の按分の例

Oracle Service Contracts（OKS）での使用の按分の例を次に示します。

例1

プロファイル「QP: 分岐単位按分を許可」= Y

品目に価格分岐価格表明細（AS999など）を設定します。

価格表をクオリファイアとして渡し、数量500、usage_pricing_type = REGULARで同じ品目AS999に対して価格設定エンジンを呼び出します。また、この場合、価格設定コンテキスト = BREAK_UOM、属性 = PRICING_ATTRIBUTE1、値 = MTH（月）とします。

予想結果:

価格設定エンジンから戻されるunit_priceは、次のような価格分岐子明細の使用の按分に基づいて90（明細数量500）になります。

例2

プロファイル「QP: 分岐単位按分を許可」= Y

品目に価格分岐価格表明細（AS999など）を設定します。

価格表をクオリファイアとして渡し、数量910、usage_pricing_type = REGULARで同じ品目AS999に対して価格設定エンジンを呼び出します。また、この場合、価格設定コンテキスト = BREAK_UOM、属性 = PRICING_ATTRIBUTE1、値 = MTH（月）とします。

予想結果:

価格設定エンジンから戻されるunit_priceは、次のような価格分岐子明細の使用の按分に基づいて90.98（数量910）になります。

例3

プロファイル「QP: 分岐単位按分を許可」= Y

品目に価格分岐価格表明細（AS999など）を設定します。

価格表をクオリファイアとして渡して数量500、usage_pricing_type <> REGULARで同じ品目AS999に対して価格設定エンジンを呼び出します。また、この場合、次のように設定します。

予想結果:

渡されるusage_pricing_typeがREGULARではなく按分が行われないので、価格設定エンジンから戻されるunit_priceは100（明細数量500）になります。

例4

プロファイル「QP: 分岐単位按分を許可」= Y

品目に価格分岐価格表明細（AS999など）を設定します。

価格表をクオリファイアとして渡して数量500、usage_pricing_type = REGULARで同じ品目AS999に対して価格設定エンジンを呼び出します。ただし、この場合、明細には次の価格設定属性は渡しません。

予想結果:

分岐単位属性が価格設定エンジンに渡されず按分が行われないので、価格設定エンジンから戻されるunit_priceは100（明細数量500）になります。

例5

プロファイル「QP: 分岐単位按分を許可」= Y

品目に価格分岐価格表明細（AS999など）を設定します。

価格表をクオリファイアとして渡して数量500、usage_pricing_type = REGULARで同じ品目AS999に対して価格設定エンジンを呼び出します。また、この場合、次のように設定します。

予想結果:

価格分岐ヘッダー明細の分岐単位がNULLであり按分が行われないので、価格設定エンジンから戻されるunit_priceは100（明細数量500）になります。

通信事業のフローをサポートする価格設定の機能 [Oracle Telecommunications Service Ordering（TSO）]

携帯電話サービスなどのように、固定した定型サービス価格（近距離または長距離通話プランの月額、ナンバー・ディスプレイやキャッチホンなどその他のサービスの月額など）を顧客に課するサービスがあります。月ごと、四半期ごとなど、これらの料金の請求の周期が、「チャージ周期」です。サービスの提供会社では、同じサービスをそれぞれ異なるチャージ周期を持つ様々なプランで顧客に提供することを選択する場合があります。たとえば、携帯電話会社では、同じ通話サービスを、月または四半期ごとのいずれかの定額で提供する場合があります。

これらの定型価格は、通常、顧客がサービスの登録を行うときに設定されます。顧客が品目を定型価格で発注すると、その発注、見積、または買い物かごに対して月や年などの周期が指定され、そのサービスに対する適切な価格が取得されます。

注意: 「受注額」クオリファイアの値およびクロス受注ボリューム計算では、1回分の料金明細のみが集計され、定型価格明細は除外されます。

「チャージ周期」属性: 価格表明細またはモディファイア明細の定型価格にチャージ周期を設定する場合は、このシード済コンテキスト/属性を選択します。

注意: 「チャージ周期」値は、価格設定においてシードされません。「チャージ周期」価格設定属性の値リストは、プロファイル「OM: 賦課周期の単位区分」に登録されている単位区分に基づきます。この単位区分には、MONTH、QUARTER、およびYEARなどの単位があります。

関連トピック

通信サービスの定型価格の設定の詳細は、『Oracle Telecommunications Service Ordering Process Guide』を参照してください。

目次   |   前へ   |   先頭へ   |   次へ

Oracleロゴ
Copyright © 2004, 2007, Oracle.All rights reserved.