リリース12
E05611-01
目次
前へ
次へ
| Oracle Order Managementインプリメンテーション・マニュアル リリース12 E05611-01 | 目次 | 前へ | 次へ |
この章の内容は、次のとおりです。
処理制約を使用すると、Oracle Order Managementで使用する営業文書に加えた変更を制御できます。この章では、処理制約のフレームワークの詳細を説明します。
処理制約は、誰が何をいつ変更できるかを管理するルールです。処理制約を使用すると、特定の変更を防止できるのみでなく、変更に基づいて処理を実行するように設定できます。変更事由の要求、監査証跡またはバージョン作成における処理のトリガー、統合イベントの発生など、変更によって生じる処理を定義できます。
処理制約を使用すると、次のことを制御できます。
変更できるユーザーは職責に基づきます。制約（ルール）は、すべての職責、制約職責リストにのみ、または承認済職責リストを除くすべてに適用できます。
制御できるのは、更新できる内容のみではありません。作成、更新、削除、取消および分割の各操作を、すべてエンティティ・レベルで制御できます。たとえば、条件セットで、ユーザーに新規受注明細の作成を許可しないようにします。また、更新操作を属性レベルまで制御できます。たとえば、特定の条件セットについて、受注明細の「価格表」フィールドではなく「倉庫」フィールドの更新を許可するように選択できます。
エンティティに対する変更を制御できます。エンティティは、表またはウィンドウにほぼ対応しています。Oracle Order Managementで制御できるエンティティは、次のとおりです。
受注ヘッダー
受注明細
受注販売実績
明細販売実績
受注価格調整
明細価格調整
受注支払
明細支払
営業基本契約ヘッダー
営業基本契約明細
変更は条件グループに基づいて制御できます。変更を許可または禁止するには、制約の条件がすべてTRUEである必要があります。条件の基礎として、フロー内でエンティティが達しているワークフロー・アクティビティの状態、または表の値を使用できます。また、カスタムAPIを使用することもできます。つまり、独自のPL/SQLコードをコールして条件を評価できます。
AND論理（すべての条件がTRUE）またはOR論理（1つ以上の条件がTRUE）を使用して、複数の条件を結合できます。
制約に違反する操作が試行された場合に、カスタム・メッセージを表示できます。
この章では、処理制約と従来のOracle Order Entryのセキュリティ・ルール機能の違いと、「処理制約」、「検証テンプレート」および「レコード・セット」の各フォームで選択する値の含意の詳細について説明し、最後に次のビジネス例を使用して処理制約の設定を具体的に説明します。
顧客発注は明細レベルで変更できません。会社は、受注と顧客発注を1対1で関連付けできるようにする必要があるとします。
受注に含まれる明細が1つでも請求インタフェース済になった後は、その受注に明細を追加できません。
記帳後に受注明細を取り消すには、事由が必要です。
明細の出荷後に受注明細の割引率を変更できるのは、顧客サービス・マネージャのみです。
受注タイプ = 返品で識別されたすべての返品受注は、中央の返品処理施設に出荷する必要があります。
直接出荷機能用の制約を使用すると、Oracle Order ManagementとOracle Purchasing間の直接出荷フローでの変更を制御できます。これらの制約の詳細は、「処理制約」を参照してください。
Order Managementのバージョン作成では、制約を使用して自動バージョン作成を使用可能にします。たとえば、検証テンプレートを使用して、取引タイプを条件としてバージョン作成を実行できます。処理制約とワークフロー・アクティビティを使用して、バージョンを追加してバージョンに適用できるステータスを決定できます。これにより、バージョン作成の設定に柔軟に対応できます。
参照: 「バージョン作成」
セキュリティ・ルールには、受注に対する変更を制御するための機能が用意されています。ただし、基本原則と実装の両面で特定の制限があります。Oracle Order Managementでは、他の製品でも使用できる処理制約フレームワークが提供されています。
このフレームワークにより、次のことが可能です。
変更を、それを試行するユーザーに基づいて（職責別に）制御する。
関連オブジェクトの状態に基づいて制約条件を定義する（受注の状態に基づく明細の制約の定義など）。
フィールドの値に基づいて変更を制御する。「検証テンプレート」を参照してください。
カスタムのPL/SQLコードをコールして条件がTRUEであるかどうかを判断する。
プロセス・フローの任意の時点で操作に制約を適用する。以前のリリースでは、ハード・コード化された特定のサイクル処理の操作のみが制御可能でした。
処理制約はきわめて強力であり、簡単に設定できます。ただし、次の用語を理解しておくと役立ちます。
エンティティ
Order Managementの表またはウィンドウにほぼ対応する関連属性のグループ。処理制約を使用して管理できるエンティティは、「受注ヘッダー」、「受注明細」、「受注価格調整」、「明細価格調整」、「受注販売実績」、「明細販売実績」、「受注支払」、「明細支払」、「営業基本契約ヘッダー」および「営業基本契約明細」です。各エンティティは旧セキュリティ・ルールの「オブジェクト」に対応しています。
属性
エンティティに属しているフィールドまたは列。たとえば、受注単位は「受注明細」エンティティの属性です。属性は、旧セキュリティ・ルールのフィールドに対応しています。
操作
エンティティに対して実行できる処理。処理制約で制御できる操作は、作成、更新、削除、取消および分割です。
処理制約フレームワーク
アプリケーションのエンティティと属性に関する処理制約を定義するための一般的な機能。エンティティまたはその属性に対する操作に制約が存在するかどうかを問い合せるAPIセットが含まれています。
「システム」ボックスが選択されていると、シード済制約は変更できません。
検証テンプレート
条件に名前を付け、条件の検証方法のセマンティクスを定義します。処理制約フレームワーク内で検証テンプレートを使用して、特定の制約の条件を指定できます。
レコード・セット
共通の属性値で結合されたレコードのセット（受注の全明細など）。処理制約フレームワークでは、制約条件を定義するときに、検証テンプレートの定義と同じ方法で、特定の条件に対してレコード・セットを検証するように指定できます。
スコープ
レコード・セットと条件が与えられると、スコープ（All/Any）によってレコード・セット内のレコードの検証方法が定義されます。「All」の場合は、セット内の全レコードの検証結果がTRUEである必要があります。「Any」の場合は、セット内の少なくとも1つのレコードの検証結果がTRUEである必要があります。
条件
制約が有効になるために合格する必要があるテスト。たとえば、制約には、受注が記帳済であるという条件を設定できます。
「処理制約」ウィンドウの「条件」タブ
「処理制約」ウィンドウにナビゲートします。「受注管理」->「設定」->「ルール」->「セキュリティ」->「処理制約」。
このウィンドウは複数のリージョンに分かれているため注意してください。最上部のリージョンには、「アプリケーション」フィールドと「エンティティ」フィールドがあります。「エンティティ」フィールドに有効な値は、OMエンティティのいずれかです。これは問合せ用で、新規エンティティは作成できません。エンティティを問い合せると、そのエンティティに対して定義されている制約がすべて表示されます。
制約
「制約」リージョンでは、処理制約のほとんどの詳細を定義します。このリージョンを使用すると、シード済制約の表示、会社用に作成された制約の表示または更新ができます。新規制約を作成できますが、システムのチェック・ボックスがオンになっているシード済制約は変更できません。
「操作」フィールド
「操作」フィールドで選択できる値は、任意のエンティティの場合は「作成」、「更新」および「削除」、受注ヘッダーおよび受注明細エンティティの場合は「取消」のみ、受注明細エンティティの場合は「分割」のみです。
「属性」フィールド
「属性」フィールドを使用できるのは、選択した操作が「更新」の場合のみです。このフィールドに値を入力すると、そのフィールドにのみ制約が適用されます。たとえば、受注明細の「倉庫」フィールドにのみ影響する制約を定義できます。「属性」フィールドを空白にすると、制約はエンティティのすべての属性に対して有効になります。たとえば、受注明細のすべてのフィールドの更新を禁止する制約を定義できます。ただし、制約属性が更新される場合のみ処理制約を実行できることに注意してください。すべての属性が制約可能ではないため、選択した操作が「更新」であっても制約可能でない属性に対して処理制約を実行できません。
「処理」フィールド
「処理」フィールドでは、制約条件に該当する場合に実行される処理を選択できます。
注意: 一意の「事由必須」処理はありません。「バージョン作成」または「監査」とともに使用する必要があります。
「ユーザー処理」メニューを表示した「処理制約」ウィンドウ
選択可能な処理の組合せは次のとおりです。
「バージョンの生成」、「必要事由」および「統合イベントの呼出し」
「バージョンの生成」および「必要事由」
「バージョンの生成」
「事由および履歴必須」および「統合イベントの呼出し」
「事由および履歴必須」
「履歴必須」
「統合イベントの呼出し」
監査履歴の「事由必須」、「事由および履歴必須」処理でサポートされているのは、UPDATE操作のみです。
制約は次の順序で評価されます（1つの変更で有効な制約は1つのみです）。
ユーザー処理
不許可
「バージョンの生成」、「事由必須」および「統合イベントの呼出し」。これにより自動バージョン作成が有効になります。
「バージョンの生成」および「事由必須」。これにより自動バージョン作成が有効になります。
「バージョンの生成」。これにより自動バージョン作成が有効になります。
「事由および履歴必須」および「統合イベントの呼出し」。これにより監査証跡が有効になり、変更情報が取得されます。
「事由および履歴必須」。これにより監査証跡が有効になり、変更情報が取得されます。
「履歴必須」。これにより監査証跡が有効になり、変更情報が取得されます。
「統合イベントの呼出し」。これはバージョン作成で使用できます。
実装中は、「統合イベントの呼出し」を含むすべての処理を選択できます。このイベントは現在XML処理で使用されていますが、他の製品で使用することもできます。
事由が必要な処理は、事由を必要としない処理より優先度が高くなります。
例
価格表の更新に適用するバージョン作成と監査制約の両方の制約を考えます。バージョンは優先度が高く、この更新では監査履歴を使用できないため、取得されるのはバージョンのみです。ただし、支払条件の更新のように、監査制約が別の属性に関するもので、支払条件と価格表を変更する場合は、バージョンと監査履歴の両方が取得されます。
「適用先」フィールド
「適用先」フィールドは、「交渉」または「履行」取引フェーズで制約が適用可能かどうかを定義するために使用します。このフィールドが空白の場合、いずれのフェーズも適用できます。
「使用可」フィールド
「使用可」フィールドは、現行の制約が有効かどうかを示します。このフィールドを使用すると、必要に応じて制約を一時的に使用不可にできます。
「システム変更」フィールド
「システム変更」フィールドを使用して、制約条件に該当する場合にもシステム変更が許可されるかどうかを指定します。この場合のシステム変更は、ソース属性に変更があった場合に内部的にデフォルト値を取得するか、デフォルトが再設定される属性を指します。これは、属性またはフィールド・レベルのUPDATE操作にのみ適用されます。考えられる値は、次のとおりです。
挿入後禁止: このフィールドに対するシステム変更が許可されるのは、エンティティがデータベースに保存されていない場合のみです。これはデフォルト値です。
常に: 属性に対するシステム変更は常に許可されます。
「ユーザー変更」フィールド
「ユーザー変更」フィールドを使用して、操作を実行するユーザーに制約が適用される場合を指定します。これは、属性またはフィールド・レベルのUPDATE操作にのみ適用されます。考えられる値は、次のとおりです。
挿入後禁止: このフィールドを変更できるのは、エンティティがデータベースに保存されていない場合のみです。これはデフォルト値です。
常に: エンティティ（受注など）を初めて作成する場合にも、この属性の値を入力できません。
「システム」フィールド
「システム」フィールドは、OMシステムとともに組み込まれた制約がユーザー更新可能であるかを示します。システム制約はデータ整合性エラーを防止するのに有効ですが更新はできません。これらの制約に添付されている操作、フィールド、処理または職責リストは変更できません。ただし、グループ番号が異なる場合は、追加の検証条件を組み込むことができます。
「使用可」フィールド
「使用可」フィールドは、現行の条件が有効かどうかを示します。このフィールドを使用すると、必要に応じて条件を一時的に使用不可にできます。条件がすべて使用不可でも制約自体が使用不可でない場合には、変更に対して制約が常に適用されます。条件を使用不可にすることでビジネス・フローに問題が生じないことを確認してください。
このウィンドウの下部には、「条件」および「適用先」という2つのタブ・リージョンがあります。
条件
「条件」リージョンでは、制約を有効にするためにTRUEであることが必要な条件を定義できます。条件グループがTRUEでないかぎり、制約は有効になりません。
「グループ番号」フィールド
「グループ番号」フィールドでは、条件の結合にAND論理またはOR論理のどちらを使用するかを指定します。たとえば、すべてがTRUEに評価される必要のある条件（AND条件）の場合は、同じグループ番号を入力します。異なる番号を使用すると、OR条件を定義できます。
「スコープ」フィールド
「スコープ」フィールドは、「レコード・セット」フィールドとともに評価され、条件がTRUEであるかどうかが判断されます。考えられる値は、次のとおりです。
どれか: この検証条件のレコード・セットで複数のレコードを選択できる場合は、少なくとも1つ以上のレコードについて、この条件がTRUEである必要があります。たとえば、「受注の明細が1つでも取消済の場合...」のように、条件は受注の任意の明細に対して評価できます。
すべて: この検証条件のレコード・セットで複数のレコードを選択できる場合は、すべてのレコードについて、この条件がTRUEである必要があります。たとえば、「受注の全明細が取消済の場合...」のように、条件は受注のすべての明細に対して評価できます。
検証エンティティ
「検証エンティティ」は、条件の評価対象です。検証エンティティには、強制エンティティ（「エンティティ」リージョンに表示）または関連エンティティを指定できます。たとえば、強制エンティティを受注明細にして、制約を検証エンティティである受注ヘッダーの特性に基づいて評価できます。
「レコード・セット」を選択すると、選択したスコープに基づいてセット内のいずれかまたはすべてのレコードについて条件が評価されます。シード済レコード・セットの一例が出荷セットです。レコード・セットは必要に応じて追加定義できます。
注意: 条件の検証エンティティが強制エンティティとは異なる場合、値リストから選択できるのは、検証エンティティの主キーに基づくレコード・セットのみです。
「対象外」ボックスをオンにすると、NOT条件が作成されます。たとえば、条件が「記帳済」の場合に、このフラグをオンにすると、条件「記帳済でない」が評価されます。
「システム」フィールド
OMシステムとともに組み込まれた条件の場合は、「システム」フィールドがオンになり、ユーザーは更新できません。また、システム条件と同じグループ番号を持つ新規AND条件は定義できません。
「ユーザー・メッセージ」フィールド
制約違反となる操作を試みると、「ユーザー・メッセージ」フィールドが表示されます。このメッセージは、制約に固有であるのみでなく、違反となった特定の条件にも固有です。たとえば、「明細は記帳されています。」というユーザー・メッセージを作成できます。制約で明細が記帳済の場合は受注明細の「品目」フィールドの更新を禁止していると、実行時には「明細は記帳済であるため、この品目は更新できません。」という完了エラー・メッセージが表示されます。
次の画面も「処理制約」ウィンドウを示していますが、この場合は「適用先」タブが選択されています。このタブを使用して、制約の適用先となる職責を定義します。
「処理制約」ウィンドウの「適用先」タブ
「全職責」ボタンを選択すると、制約は全ユーザーに適用されます。このため、いずれのユーザーも制約付き処理を実行できなくなります。すべてのシード済制約をすべての職責に適用できます。
「承認済職責」ボタンを選択すると、処理を実行できるのは指定した職責のみになります。他のすべてのユーザーは、制約により処理の実行を停止されます。
「制約職責」ボタンを選択すると、定義した職責を除き、すべてのユーザーが処理を実行できます。指定したユーザーは、制約により処理の実行を停止されます。
処理制約の設定には、他にも「検証テンプレート」および「レコード・セット」という2つのウィンドウを使用します。前述のように、「処理制約」ウィンドウでは、作成した検証テンプレートおよびレコード・セットと、シード済の検証テンプレートおよびレコード・セットを使用できます。
注意: 制約または条件、あるいはその両方を更新した後は、更新された制約が適切に適用されるように、営業文書のウィンドウを閉じてから再び開きます。
「検証テンプレート」ウィンドウ
「検証テンプレート」ウィンドウにナビゲートします。「受注管理」->「設定」->「ルール」->「セキュリティ」->「検証テンプレート」。
このウィンドウは複数のリージョンに分かれています。最上部のリージョンには「アプリケーション」フィールドが表示されます。「検証テンプレート」リージョンには、検証テンプレートごとに1行ずつ、各行に複数のフィールドが表示されます。「エンティティ」フィールドは10個あるOMエンティティのいずれかになります。このエンティティをチェックして、条件がTRUEであるかどうかを判断します。「テンプレート名」フィールドで検証テンプレート名を指定し、「短縮名」フィールドで短縮名、「摘要」フィールドで摘要を指定します。この3つはユーザー定義です。検証テンプレートを保存した後は、短縮名を変更できません。検証テンプレートがOracle開発チームによりシード済の場合は、このボックスをオンにします。シード済の検証テンプレートは変更できません。
「検証タイプ」フィールドはラジオ・ボタンのグループで、考えられる値は「WF」、「API」および「TBL」です。このウィンドウの「検証の意味」リージョンで使用可能なフィールドは、このグループから選択した値に応じて変化します。「WF」を選択すると、検証はワークフロー・アクティビティのステータスに基づいて行われます。たとえば、シード済検証テンプレート「記帳済」は、受注ヘッダー・ワークフローの「記帳済」アクティビティのステータスに基づきます。「API」を選択すると、PL/SQLコードがコールされ、検証テンプレートがTRUEであるかどうかが評価されます。APIをコールするシード済検証テンプレートは、受注の明細が入力済かどうかを判断する「明細存在」など、複数が用意されています。「TBL」を選択すると、検証はフィールドの値に基づいて行われます。たとえば、フィールド「受注タイプ」の値が「標準」の場合に、条件がTRUEになります。
注意: 検証テンプレートでアクティビティが「記帳済」の場合、処理制約操作は「取消」になり、記帳前に明細を取り消そうとする場合、「受注数量」は0になりますが、明細状態は「取消」ではなく「入力済」として表示されます。
検証タイプ「WF」を選択した場合の「検証の意味」リージョン
この図は、検証タイプ「WF」を選択した場合の「検証の意味」リージョンを示しています。「品目タイプ」フィールドは、「受注ヘッダー」エンティティの「OM交渉ヘッダー」や「OM受注ヘッダー」などのエンティティに関連付けられているワークフロー項目タイプを定義するために使用できます。「アクティビティ」フィールドは、ステータスをチェックするワークフロー・アクティビティの名称です。「ステータス」フィールドと「結果」フィールドは、検証テンプレートによりTRUEの値が戻される場合の、ワークフロー・アクティビティの属性です。この図では、受注ヘッダーのアクティビティ「請求書インタフェース - ヘッダー・レベル」がどのような結果で完了した場合も、検証テンプレートがTRUEになります。
検証タイプ「API」を選択した場合の「検証の意味」リージョン
この図は、検証タイプ「API」を選択した場合の「検証の意味」リージョンを示しています。戻り値がTRUEかどうかについてAPIを検証するように、検証の意味を入力します。（これは、複雑な検証に使用できます。）
PL/SQLパッケージ: データ・パッケージ名を入力します。
プロシージャ名: API名を入力します。
すべての検証APIは、フレームワーク定義のシグネチャ形式で記述する必要があります。
PROCEDURE YourValidationAPI
(p_application_id in number,
p_entity_short_name in varchar2,
p_validation_entity_short_name in varchar2,
p_validation_tmplt_short_name in varchar2,
p_record_set_short_name in varchar2,
p_scope in varchar2,
x_result out number);
戻り値x_resultは、条件が有効な場合は1、有効でない場合は0になります。
このプロシージャでは、すべてのエラー・メッセージ（存在する場合）をOE_MSG_PUBスタックに置く必要があります。エンティティの制約APIパッケージ内のグローバル・レコード変数を参照し、制約対象となるレコードを参照できます。命名規則は、次のとおりです。
エンティティの制約APIパッケージ名:
ApplicationShortName_Entity_Short_Name_PCFWK
（例: OE_HEADER_PCFWK）
グローバル・レコード変数名: g_record
（例: エンティティHEADERの場合、変数名はOE_HEADER_PCFWK.g_record）
検証タイプ「TBL」を選択した場合の「検証の意味」リージョン
この図は、検証タイプ「TBL」を選択した場合の「検証の意味」リージョンを示しています。「列」フィールドに列名を入力します。検証操作として次のいずれかを選択できます。
=（等しい）
<>（等しくない）
NULL値
NULL値でない
「値文字列」には、任意の値を指定できます。列の検証の意味の例を次に示します。
列: 受注タイプ
検証演算子: =（等しい）
値文字列: 標準
この場合は、タイプが「標準」のすべての受注についてTRUEが戻されます。値文字列「STANDARD」を入力した場合は、機能しないことに注意してください（正確に一致する必要があります）。
次の図は、レコード・セット作成用のウィンドウを示しています。このウィンドウも複数のリージョンに分かれています。
レコード・セット
最上部のリージョンには、アプリケーション名「Oracle Order Management」が表示されます。
「レコード・セット」リージョンは、レコード・セットごとに1行が表示されます。「エンティティ」フィールドは、10個のOMエンティティのいずれかになります。レコード・セット内の各レコードは、このエンティティに属しています。たとえば、レコード・セットを明細または受注で構成できます。レコード・セットがシードされている場合は、このボックスがオンになります。ユーザーは、このフラグもシード済レコード・セットも変更できません。
「レコード・ セット」フィールドでレコード・セット名、「短縮名」フィールドで短縮名、「摘要」フィールドで摘要を指定します。この3つはユーザー定義です。レコード・セットが保存された後は、短縮名を変更できません。このレコード・セットの選択に主キーを使用する場合は、「主キーがベース?」ボックスをオンにします。特定のエンティティに対して指定できる基本レコード・セットは1つのみです。
このウィンドウの下部には「レコード選択に一致する列」リージョンがあります。検証エンティティの表から複数行を選択できるように、検証レコードから一致する列の名前を入力します。たとえば、受注明細エンティティの「ヘッダーID」と「出荷セット番号」を一致させると、同じ出荷セット内のすべての受注明細が選択されます。
新規の処理制約を作成または更新するには、新規の検証テンプレートまたはレコード・セットを作成する際に必要となる、「検証の作成パッケージ」コンカレント・プログラムを実行する必要があります。このプログラムは、「検証テンプレート」ウィンドウまたは「レコード・セット」ウィンドウのメニュー・バーにある「ツール」オプションから実行するか、「設定」->「ルール」->「セキュリティ」->「制約パッケージの生成」の順に選択してナビゲーション・メニューから実行します。処理制約を作成、更新または変更するときは常にこのプログラムを実行します。
処理制約リスティング・レポートには、定義済の処理制約が表示されます。これは、旧リリースのOracle Order Entryのセキュリティ・ルール・リストにかわるレポートです。このレポートのパラメータは、次のとおりです。
エンティティ
制約対象となるエンティティ。
属性
制約対象となる属性。このパラメータを使用できるのは、前述のパラメータでエンティティを選択した場合のみです。
操作
制約対象となる操作。このパラメータを使用できるのは、「属性」パラメータを選択していない場合のみです。
検証エンティティ
この検証エンティティに基づく条件を持った制約のみが組み込まれます。このパラメータを使用できるのは、「エンティティ」パラメータを選択した場合のみです。
レコード・セット
このレコード・セットに関して条件が設定されている制約のみが組み込まれます。このパラメータを使用できるのは、「検証エンティティ」パラメータを選択した場合のみです。
検証テンプレート
この検証テンプレートを使用する条件を持った制約のみが組み込まれます。このパラメータを使用できるのは、「検証エンティティ」パラメータを選択した場合のみです。
シード済
このフィールドを空白にすると、シード済制約条件とシード済でない制約条件の両方が表示されます。「Yes」を選択するとシード済条件のみが表示され、「No」を選択するとシード済でない条件のみが表示されます。
これらのパラメータはいずれもオプションです。パラメータを何も指定しないと、レポートにはすべての値が含まれます。
セキュリティ・ルールと処理制約の間で根本的なアーキテクチャに大幅な変更があったため、ユーザー定義のセキュリティ・ルールはアップグレードしないように決定されました。処理制約とセキュリティ・ルールは本質的に異なるため、シード済の処理制約はシード済のOEセキュリティ・ルールを擬似実行しません。データの整合性を保証するために必要となるのは、シード済の処理制約のみです。
Oracle Order Managementを実装する企業は、Oracle Order Entryを実装した企業に比べると、時間をかけて処理制約の設定を評価する必要があります。Oracle Order EntryからOracle Order Managementにアップグレードする企業は、アップグレード・プロジェクト計画に処理制約の設定時間を見込んでください。
例
この例では、実際のビジネス・ニーズにあわせて処理制約を使用する方法を考えます。5つのビジネス・シナリオの設定手順と結果は次のとおりです。
顧客発注は明細レベルで変更できません。会社は、受注と顧客発注を1対1で関連付けできるようにする必要があるとします。
「処理制約」ウィンドウにナビゲートします。アプリケーション「Oracle Order Management」とエンティティ「受注明細」の制約を検索します。「制約」リージョンで、次の値を指定して新規明細を追加します。
| 操作 | 属性 | ユーザー処理 |
|---|---|---|
| UPDATE | 顧客発注 | 許可なし |
この制約を保存します。これで、最も単純なタイプの制約が作成されます。この制約は、すべての条件ですべての職責に適用されます。ユーザーが明細の発注番号の変更を試みると、メッセージが表示されます。
受注に含まれる明細が1つでも請求インタフェース済になった後は、その受注に明細を追加できません。
「処理制約」ウィンドウにナビゲートします。アプリケーション「Oracle Order Management」とエンティティ「受注明細」の制約を検索します。「制約」リージョンで、次の値を指定して新規明細を追加します。
| 操作 | 属性 | ユーザー処理 |
|---|---|---|
| CREATE | [空白] | 許可なし |
「条件」リージョンの1行に次の情報を入力します。
| グループ番号 | スコープ | 検証エンティティ | レコード・セット | 検証テンプレート |
|---|---|---|---|---|
| [任意の番号] | どれか | 受注明細 | 受注 | 請求インタフェース済 |
「ユーザー・メッセージ」に、「受注のうち明細の1つが請求済です。」と入力します。この制約を保存します。この制約には条件があるため、条件がTRUEの場合にのみアクティブになります。条件がTRUEになるのは、受注の明細が1つでも請求インタフェース済の場合です。この制約は、レコード・セットの使用方法を示す好例で、すべての職責に適用されます。ユーザーが請求インタフェース済の明細がある受注について新規明細の作成を試みると、「受注明細は作成できません。受注のうち明細の1つが請求済です。」というメッセージが表示されます。このエラー・メッセージに、条件について入力したユーザー・メッセージが含まれていることに注意してください。
記帳後に受注明細を取り消すには事由が必要です。「処理制約」ウィンドウにナビゲートします。アプリケーション「Oracle Order Management」とエンティティ「受注明細」の制約を検索します。「制約」リージョンで、次の値を指定して新規明細を追加します。
| 操作 | 属性 | ユーザー処理 |
|---|---|---|
| CANCEL | [空白] | 「事由および履歴必須」 |
「条件」リージョンの1行に次の情報を入力します。
| グループ番号 | スコープ | 検証エンティティ | レコード・セット | 検証テンプレート |
|---|---|---|---|---|
| [任意の番号] | どれか | 受注明細 | 明細 | 記帳済 |
「ユーザー・メッセージ」に、「受注が記帳済です。」と入力します。この制約を保存します。この制約には条件があるため、条件がTRUEの場合にのみアクティブになります。条件がTRUEになるのは、受注が記帳済の場合で、すべての職責に適用されます。すべてのユーザーは、記帳済の明細を取り消すときに、事由を入力するように要求されます。
明細の出荷後に受注明細の割引率を変更できるのは、顧客サービス・マネージャのみです。「処理制約」ウィンドウにナビゲートします。アプリケーション「Oracle Order Management」とエンティティ「明細価格調整」の制約を検索します。「制約」リージョンで、次の値を指定して新規明細を追加します。
| 操作 | 属性 | ユーザー処理 |
|---|---|---|
| UPDATE | オペランド | 許可なし |
「条件」リージョンの1行に次の情報を入力します。
| グループ番号 | スコープ | 検証エンティティ | レコード・セット | 検証テンプレート |
|---|---|---|---|---|
| [任意の番号] | どれか | 受注明細 | 明細 | 出荷確認 |
「ユーザー・メッセージ」に「この明細は出荷済です。」と入力します。「適用先」タブにナビゲートし、「承認済職責」ラジオ・ボタンを選択します。ラジオ・ボタンの下の表に「顧客サービス・マネージャ」と入力します。
この制約を保存します。この制約には条件があるため、条件がTRUEの場合にのみアクティブになります。条件がTRUEになるのは、この明細が出荷済の場合です。これはシード済の職責ではないため注意してください。この例では、システム管理者の職責の定義機能を使用して職責が作成されたと想定しています。顧客サービス・マネージャの職責でログインしていないユーザーが、出荷済明細の割引率の変更を試みると、「パーセントは更新できません。この明細は出荷済です。」というメッセージが表示されます。
会社は、受注タイプ = 返品で識別されたすべての返品受注は、中央の返品処理施設に出荷するように要求しています。
この例では、デフォルト・ルール・フレームワークを使用して、「返品」タイプの受注のすべての明細について倉庫をデフォルトで「Wichita」に設定するルールを作成したとします。デフォルト・ルールの作成方法の詳細は、ホワイト・ペーパー『Using Defaulting Rules in Oracle Order Management』を参照してください。
制約を作成するには、まず受注タイプが「返品」の受注用に新規検証テンプレートを作成します。「検証テンプレート」ウィンドウにナビゲートし、アプリケーション「Oracle Order Management」の検証テンプレートを検索します。「検証テンプレート」リージョンに、次の情報を指定して新規の1行を入力します。
| エンティティ | テンプレート名 | 短縮名 | 摘要 | 検証タイプ |
|---|---|---|---|---|
| 受注ヘッダー | 返品受注 | RETURN | 受注タイプ「返品」 | TBL |
「検証の意味」リージョンに次の情報を入力します。
| 列名 | 検証演算子 | 値文字列 |
|---|---|---|
| 受注タイプ | =（等しい） | 返品 |
「制約」ウィンドウにナビゲートし、新規の検証テンプレートを使用して制約を作成します。アプリケーション「Oracle Order Management」とエンティティ「受注明細」の制約を検索します。「制約」リージョンで、次の値を指定して新規明細を追加します。
| 操作 | 属性 | ユーザー処理 |
|---|---|---|
| UPDATE | 倉庫 | 許可なし |
「条件」リージョンの1行に次の情報を入力します。
| グループ番号 | スコープ | 検証エンティティ | レコード・セット | 検証テンプレート |
|---|---|---|---|---|
| [任意の番号] | どれか | 受注ヘッダー | 受注 | 返品 |
「ユーザー・メッセージ」に、「すべての返品はWichitaで処理されます。」と入力します。
この制約を保存します。この制約には条件があるため、条件がTRUEの場合にのみアクティブになります。条件がTRUEになるのは、受注タイプが「返品」の場合です。これは、検証テンプレートの作成時に、そのように指定しているためです。これは、会社が「返品」という名前で受注用の取引タイプを作成している場合です。この条件は、すべての職責に適用されます。ユーザーが受注明細の倉庫の変更を試みると、「倉庫は更新できません。すべての返品はWichitaで処理されます。」というメッセージが表示されます。
『Oracle Order Management Open Interfaces, API, & Electronic Messaging Guide』
バージョン作成とは、取引に対する変更や更新を取得する方法です。バージョン作成は現在、受注、見積および営業基本契約で使用できます。手動バージョン作成と自動バージョン作成の両方がサポートされています。
バージョン作成には、次のものが含まれます。
バージョン管理: 受注、見積および営業基本契約に対する変更および更新の取得。これにより次のことが可能です。
バージョンの生成
バージョン番号の検証
バージョン履歴の保守と比較
前のバージョンの検索
バージョン作成の事由およびコメント
営業基本契約、受注または見積に関する契約条件の変更の追跡
APIおよび受注インポート: 複数のモードで作成または更新された販売取引に対するバージョン作成のサポート
指定の取引について総合的な情報がある場合に、バージョンを作成、管理、表示および比較する機能
取引サイクルの履歴を保守することで販売取引の交渉フェーズをサポートする機能
注意: 価格表とモディファイアでは、営業基本契約でのバージョン作成は行われません。
バージョン作成機能はデフォルトでは手動です。自動バージョン作成を使用可能にするには、適切な処理制約を設定する必要があります。たとえば、検証テンプレートを使用して、取引タイプを条件としてバージョン作成を実行できます。処理制約とワークフロー・アクティビティを使用すると、バージョンを追加する時期およびバージョンに適用できるステータスを決定できます。
たとえば、ある取引で特定の属性が変更または更新されている場合にのみバージョンを追加できます。受注数量、支払条件、価格表、要求日またはその他の属性になんらかの変更があった場合は、いつでもバージョン番号を追加できます。
バージョン作成管理をワークフロー・アクティビティのステータスにリンクできます。バージョン生成機能は、次のとおりです。
手動/自動オプション
文書番号に続く、整数および単独フィールドとしてのバージョン番号
随時の手動更新（特定のステータスでの修正が可能な設定を使用）
受注への移動中に文書番号を保持するオプション
自動バージョン作成に必要な条件の指定
バージョン履歴の保守は、参照と比較に役立ちます。承認の前に取引伝票が何度も変更される交渉フェーズでの見積および営業基本契約（SA）では特に役立ちます。顧客の要求を満たすために頻繁に設計変更が行われる複雑な製品や、より多くの受注数量を長期にわたって契約し、最善価格を取り付けるために長い間交渉を行う得意先では、このようなバージョン履歴の保守作業が発生する可能性があります。
有効なバージョンが変更されると、バージョン作成で前バージョンの履歴が維持されます。ただし、この前バージョンは、コピー機能を使用して新規の受注、見積または営業基本契約を作成するためのテンプレートとしていつでも使用できます。
バージョン履歴の保守と比較により、次のことが可能です。
前バージョンの取引履歴の保守
最新バージョンの取引の変更
一定期間にわたる変更内容の追跡と変更内容の表示
取引に対する変更のバージョン間の比較
任意のバージョンの見積の受注へのコピー
制約は次の順序で評価されます（1つの変更で有効な制約は1つのみです）。
ユーザー処理
許可なし
「バージョンの生成」、「事由必須」および「統合イベントの呼出し」（バージョンの有効化）
「バージョンの生成」および「事由必須」（バージョンの有効化）
「バージョンの生成」（バージョンの有効化）
「事由および履歴必須」および「統合イベントの呼出し」（監査証跡）
「事由および履歴必須」: 「履行」フェーズのみ（監査証跡）
「履歴必須」: 「履行」フェーズのみ（監査証跡）
「統合イベントの呼出し」（電子メッセージ）
実装中は、「統合イベントの呼出し」を含むすべての処理を選択できます。このイベントは現在XML処理で使用されていますが、他の製品で使用することもできます。
参照: 『Oracle Order Management Open Interfaces, API, & Electronic Messaging Guide』
注意: 1つの属性に複数の制約を設定し、バージョン作成と監査の両方の制約を条件に適用した場合、バージョン作成のみが取得されます。システムのパフォーマンスを改善するために、処理制約数は設定中の主要な更新のみに限定してください。バージョンが有効化されていると、取引全体が履歴に保存され、その結果、大量受注の場合に保存に要する時間が増えます。
バージョン作成を使用するには、処理制約を適切な属性に設定します。
Order Managementの「処理制約」ウィンドウにナビゲートします。「受注管理」->「設定」->「ルール」->「セキュリティ」->「処理制約」。
「ユーザー処理」メニューを表示した「処理制約」ウィンドウ
バージョン作成用の処理制約を設定します。「処理制約の定義」を参照してください。「ユーザー処理」フィールドから、目的のユーザー処理を選択します。オプションは次のとおりです。
「バージョンの生成」、事由必須および「統合イベントの呼出し」
「バージョンの生成」および「事由必須」
「バージョンの生成」
「事由および履歴必須」および「統合イベントの呼出し」
「事由および履歴必須」
「履歴必須」
「統合イベントの呼出し」
必要に応じて、いずれかの検証テンプレートを適用します。「検証テンプレート」ウィンドウにナビゲートします。「受注管理」->「設定」->「ルール」->「セキュリティ」->「検証テンプレート」。
「検証テンプレート」でのバージョン作成の設定
注意: 条件が適用された場合は、検証テンプレートを使用する必要があります。
変更による更新操作をバージョン番号に渡します。必要に応じて、p_header_recパラメータのchange_reasonパラメータか、受注インポート用のインタフェース表のchange_reason列で事由を指定します。
API/受注インポートを使用したその他の取引の変更は、制約の設定に基づいてバージョンを更新します。制約処理に必要事由が含まれる場合は、その事由も渡す必要があります。
同じ操作に対するバージョン作成制約があるかどうかを確認してください。バージョン作成は優先度が高いため、監査レコードではなくバージョンが取得されます。
例:
定義した処理制約は、次のとおりです。
処理「履歴必須」による記帳済受注の価格表の更新
処理「バージョンの生成」による記帳済受注の価格表の更新
システムの動作
記帳済受注の価格表が更新されるとバージョンは生成されますが、監査は取得されません。この変更は監査履歴フォームでは表示できません。
バージョン作成が必要となる変更はないが、バージョンが更新される
ユーザー変更に起因するシステム更新があったかどうかを確認してください。
例:
要求日が更新されると予定日が変更され、この変更に対してバージョン作成制約が付加されます。このようなバージョンに記録される事由は「SYSTEM」です。
明細の分割で2つのバージョンが生成される
処理制約は、分割操作を行うときと、分割中に更新された他の属性（倉庫など）を更新するときに存在します。
参照:
詳細は、「処理制約」を参照してください。参照: 『Oracle Order Managementユーザーズ・ガイド』
監査証跡は、指定した受注属性が更新された際に、それを記録および追跡します。Oracle Order Managementの監査証跡に関する総合的な更新のレポートは、処理制約、参照、システム・パラメータおよび監査履歴連結コンカレント・プログラムを使用して生成されます。現行の処理制約機能では、受注変更の実行時に、エンティティごとに制御するビジネス機能を正確に指定できます。処理制約を新規に定義して、監査証跡の更新を記録する時期と受注の属性を指定できます。この機能を使用するには、Order Managementのシステム・パラメータ「監査証跡」を使用可能にしておく必要があります。
Oracle Order Managementを使用すると、企業の必要性に応じて受注処理の多寡を柔軟に調整し、監査を行うことができます。企業ごとに監査の保守が必要となる重要な受注属性を判断し、それに応じて処理制約を設定できます。制約を定義した後、ユーザーは常に自分の受注の入力や変更を行うことができます。属性の変更に事由が必須と定義した属性が変更された場合は、ユーザー定義リストから事由コードを選択するように要求するメッセージが表示されます。
最終的には、監査可能な属性に対して実際に加えられた変更の内容、変更者、変更時期について、問合せを実行したり、レポートを生成できます。
現在、バージョン作成は監査証跡とともに機能しますが、これは取引が履行フェーズに入った場合のみで交渉フェーズでは行われません。監査証跡では受注の変更をすべて追跡できますが、受注を新規バージョンに改訂する構成が必要とはかぎりません。1つの変更をバージョン作成と監査証跡の両面から追跡することはできません。変更履歴の追跡に使用する方法は、ユーザーが決定する必要があります。バージョン管理と監査証跡には次のような違いがあります。
バージョン管理ではビジネス・オブジェクト全体が記録されるため、ユーザーは文書に加えられた変更をオンラインでリアルタイムに表示できます。また、監査証跡は、変更者および変更内容を把握するために、1つの変更を記録します。
バージョン管理がオンラインで表示できるのに対し、監査証跡はレポート生成後でなければオンラインで表示できません。バージョン管理では前バージョンとの比較が可能ですが、監査証跡では比較できません。監査証跡では1つのバージョン内での変更が取得されますが、バージョン管理ではバージョンを追加する変更が記録されます。最後に、バージョン管理は受注、見積および営業基本契約を含む、すべての営業文書に適用されますが、監査証跡が適用されるのは受注のみです。
新規フォーム
「監査履歴」ウィンドウは、「受注」、「返品」または「監査履歴」メニュー・パスから起動できます。
受注関連のすべてのエンティティについて、ユーザーが変更できる属性の監査履歴をすべて表示するには、問合せウィンドウが使用されます。
このフォームは「検索」ウィンドウおよび「結果」ウィンドウで構成されています。「検索」ウィンドウでは入力値として、履歴の日付範囲、エンティティ名、属性と受注番号範囲、ユーザーIDおよび職責が使用されます。すべての入力パラメータはオプションです。
「監査履歴検索」ウィンドウ
「結果」ウィンドウでは、入力した問合せ基準に基づいて履歴レコードが表示されます。このウィンドウには、監査レコードを持つことができる各エンティティに対してタブが用意されています。各タブの書式は類似しており、すべてのデータが表示されています。「明細」エンティティのタブでは、明細番号だけでなく他のデータもすべて表示されています。少しのスクロールですべてのデータを表示できるため、このウィンドウはフォルダ形式ではありません。事由コードとコメントは選択した行の行外の領域に表示されます。
「監査履歴」の「結果」ウィンドウ
ユーザーが変更事由コードとコメントを入力できるように、このフォームには新たにポップアップ・ウィンドウが追加されています。処理制約の設定に基づいて、更新の変更事由を入力する必要がある場合は、入力用にこの小さなウィンドウがポップアップ表示されます。また、必須でない場合にも、ユーザーはこのウィンドウを「ツール」メニューから起動して、監査事由を記録できます。
「監査履歴変更理由」ウィンドウ
新規の監査履歴のフォームを表示する際に必要となる職責について、「受注管理」メニューに「監査履歴の表示」メニュー・オプションを追加します。このメニュー・オプションはシード・データから作成されます。
処理制約を設定し、監査証跡を記録する受注の属性を指定します。「処理制約の定義」を参照してください。
監査情報を記録するかどうかを制御する特定の条件がある場合には、新規の検証テンプレートをいくつか作成します。「検証テンプレートの定義」を参照してください。
OMシステム・パラメータ監査証跡を設定します。
「受注管理」->「設定」->「システム・パラメータ」->「値」にナビゲートします。
「営業単位」を選択します。
値リストから「一般パラメータ」を選択します。
監査証跡パラメータは、値リストの「記帳時、使用可」、「受注入力時、使用可」または「使用不可」から選択します。
「OMシステム・パラメータの設定」を参照してください。
通常どおり、受注を入力して処理します。
連結プログラムを定期的に実行するように予定作成して、問合せとレポート作成に監査情報を使用できるようにします。
レポートまたは問合せを実行して監査情報を表示します。
注意: 設定した処理制約によっては、ユーザーは受注を変更する際に事由を入力するように求められることがあります。
| システム・パラメータ | 処理制約 | 受注ステータス | 履歴を取得するかどうか |
|---|---|---|---|
| 使用不可 | 入力済または記帳済 | 入力済または記帳済 | 取得履歴なし |
| 入力済 | 入力済 | 入力済 | Yes |
| 入力済 | 記帳済 | 入力済 | No |
| 入力済 | 記帳済 | 記帳済 | Yes |
| 記帳済 | 入力済 | 入力済 | No |
| 記帳済 | 入力済 | 記帳済 | Yes |
| 記帳済 | 記帳済 | 記帳済 | Yes |
このレポートを使用すると、ユーザーは異なるパラメータで監査情報を取得できます。レポート・パラメータには、開始日/終了日、エンティティ、属性、受注番号、ユーザーおよび変更者の職責が含まれます。
このレポートを実行するには、「レポート」->「要求」->「監査履歴レポート」にナビゲートします。
