リリース11i
B25746-01
目次
前へ
次へ
| Oracle Advanced Product Catalogインプリメンテーション・ガイド リリース11i B25746-01 | 目次 | 前へ | 次へ |
変更カテゴリとそれに関連するタイプを定義するには、次のタスクを実行する必要があります。
| タスク | 必須かどうか |
| 変更カテゴリの定義 | |
| 変更タイプの定義 | 必須 |
| ライン・タイプの定義 | |
| 変更タイプ属性グループの定義 | |
| 変更ライン属性グループの定義 | |
| 変更属性グループ・セキュリティの設定 | |
| 変更タイプ属性に対するユーザー定義関数の実施 | |
| 変更タイプ属性の関連付け | |
| 変更管理ワークフローのカスタマイズ | |
| 承認経路テンプレートの定義 | 必須 |
| ユーザー定義優先度コードの作成 | 必須 |
| ユーザー定義事由コードの作成 | |
| ユーザー定義ステータスの作成 | |
| 変更カテゴリの基準テンプレートの定義 | |
| 変更カテゴリの結果書式の定義 | |
| 変更レポートの定義 |
変更カテゴリを使用すると、企業に必要な変更を定義および管理できます。シードされている変更カテゴリ（「懸案」、「変更要求」、「変更オーダー」）に加えて、自社のビジネス・ニーズに固有な変更カテゴリを作成できます。たとえば、「拡張要求」変更カテゴリを作成すると、製品に対する顧客の拡張要求を追跡できます。シードされている変更カテゴリは削除できませんが、無効にすることはできます。
各変更カテゴリは、そのカテゴリのビジネス目的に基づいて、改訂品目または要求ラインを含めるように構成できます。たとえば、変更オーダーに改訂品目を含めると、その変更オーダーによって品目に関連する変更を実施できます。要求ラインを含めると、品目に関連する変更を要求したり、タスクを指定してその品目を個人またはグループに割り当てることができます。また、頻繁に実行する検索基準については、基準テンプレートと結果書式を変更カテゴリに関連付けることができます。
APCには、次の変更カテゴリがシードされています。
懸案: 製品またはプロセスに関連する各種懸案を追跡、管理および解決するために使用します。
変更要求: 変更を要求し、要求された変更に対する承認を取得するために使用します。
変更オーダー: 要求された変更を実施して品目を改訂するために使用します。
アイディア: 顧客と内部ユーザーから提案、工夫、改善などを取得するために使用します。
新規品目要求: 新規品目を定義および承認する正式プロセスを設定するために使用します。
文書レビュー: 文書に関するレビューとフィードバックの非公式プロセスを許可するために使用します。
文書添付の承認: 文書を検討して承認する正式プロセスを許可するために使用します。
フォーム機能を指定すると、変更カテゴリ・オブジェクトを表示および作成できるユーザーを管理できます。このフォーム機能は、変更管理セキュリティ・メニュー（EGO_CHGMGMT_USER_SECURITY）に追加する必要があります。このメニューは、ユーザー職責（開発マネージャや開発エンジニアなど）によって参照されます。また、「品目カタログ」ワークベンチでは、状況に応じて品目に関する変更カテゴリの全インスタンスを表示するタブを有効にすることもできます。
「品目カタログ」で有効になった新規変更カテゴリ「拡張要求」
変更カテゴリ機能セキュリティと品目変更カテゴリ・タブの有効化
変更カテゴリ機能と品目変更カテゴリ・タブを有効にする手順は、次のとおりです。
品目拡張要求タブにフォーム機能を作成します。
「摘要」タブ
機能
EGO_ITEM_ENH_REQ
ユーザー機能名
EGOユーザー品目拡張要求サブタブ
摘要
EGOユーザー品目拡張要求サブタブ
「プロパティ」タブ
タイプ
SSWA JSP機能
保守モード・サポート
なし
コンテキスト依存
職責
「Web対応 HTML」タブ
HTMLコール OA.jsp?page=/oracle/apps/ego/item/eu/webui/EGOTEMCHANGEMGMTLISTPGL=431=RP=EGO_USER_WORKBENCH_HOMEPAGE=EGO_ITEM_ENH_REQ=ENHANCEMENT_REQUEST
注意: 太文字は、フォーム機能と変更カテゴリの内部名を表します。
「拡張要求」セキュリティにフォーム機能を作成します。機能名は、‘ENG_CREATE_’（たとえば、ENG_CREATE_ENHANCEMENT_REQUEST）にする必要があります。
「摘要」タブ
機能
ENG_CREATE_ENHANCEMENT_REQUEST
ユーザー機能名
設計作成拡張要求
「プロパティ」タブ
タイプ
SSWA JSP機能
保守モード・サポート
なし
コンテキスト依存
職責
「Web対応 HTML」タブ
HTMLコール OA.jsp?page=/oracle/apps/eng/changemgmt/webui/SelectChgTypePG=ENHANCEMENT_REQUEST
注意: 太文字は変更カテゴリの内部名を表します。
変更カテゴリ・セキュリティのフォーム機能と品目変更カテゴリ・タブの作成
「拡張要求の作成」機能を変更管理ナビゲーション・メニューに追加します（メニューEGO_CHANGE_MGMT_MENUを参照）。
プロンプト
拡張要求の作成
機能
設計作成拡張要求
変更管理メニューへの機能の追加
「拡張要求」セキュリティ機能を変更管理セキュリティ・メニューに追加します（メニューEGO_CHGMGMT_USER_SECURITYを参照）。
機能
設計作成拡張要求
変更管理セキュリティ・メニューへの機能の追加
品目拡張要求機能を品目変更管理タブ・メニューに追加します（メニューEGO_USER_CHANGE_MANAGEMENT_TABを参照）。
プロンプト
拡張要求
機能
EGOユーザー品目拡張要求サブタブ
注意: EGO_USER_CHANGE_MANAGEMENT_TABなどの変更管理メニューに機能を追加する場合は、プロンプトを入力する必要があります。
既存の変更カテゴリをコピーして、「拡張要求」の新規変更カテゴリを追加します。後述の例に示す新規の「拡張要求」変更カテゴリは、「懸案」カテゴリをコピーして定義しています。
内部名
ENHANCEMENT_REQUEST
名称
拡張要求
摘要
拡張要求
複数名称
拡張要求
ソート順序
9
開始日
システム日付にデフォルト設定されます。
番号生成
生成済順序
プリフィクス
ER-
次有効番号
0001
既存の変更カテゴリをコピーして新規変更カテゴリを追加
注意: これらの設定タスクが完了した後は、JservおよびApacheリスナー中間層ポートを停止して再起動することをお薦めします。
変更カテゴリ管理の詳細は、APC iHelpで変更カテゴリの作成に関する説明を参照してください。フォーム機能の詳細は、『Oracle Applicationsシステム管理者ガイド』および『Oracle Applications開発者ガイド』を参照してください。
優先度コードを使用すると、懸案または変更の緊急度を追跡できます。また、優先度コードを作成すると、別の優先度（「高」、「中」、「低」など）を取得できます。
優先度コードは、すべての変更カテゴリとその変更タイプに適用できます。
シードされている優先度コードは削除できませんが、無効にして、使用目的に応じた新規コードを定義できます。優先度は、「無効日」フィールドに指定した日付で無効にできます。
事由コードを使用すると、懸案または変更が作成された事由を追跡できます。事由コードを作成して懸案または変更の事由（「品質改善」、デザイン改善、「コスト低減」、「テスト失敗」、非適合など）を取得します。
事由コードは、すべての変更カテゴリとその変更タイプに適用できます。
シードされている事由コードは削除できませんが、無効にして、使用目的に応じた新規コードを定義できます。事由は、「無効日」フィールドに指定した日付で無効にできます。
分類によって、会社は変更オーダーのカテゴリ化を自動化し、変更オーダーが生産に与える影響をユーザーに正確に示すことができます。APCには、次のタイプの分類が用意されています。
導出
「導出」分類コードは、ユーザー定義関数から導出されます。たとえば、Vision社のある事業部門では、変更オーダーを特定の分類コードに割り当てるプロセスの自動化が必要だとします。Vision社は、自動化された分類プロセスを作成するために、ユーザーの入力時に変更オーダーを特定の分類またはワークフロー経路に分類する一連の属性を作成しました。ユーザーが入力した属性はユーザー定義関数にマップされます。この関数は、属性に入力されたデータを取得し、有効な分類コードを導出します。「導出」分類コードは、読取り専用データとしてユーザーに表示されます。ユーザー定義の属性と関数の詳細は、「ヘッダー/ライン・タイプ属性と属性グループの定義」および「ユーザー定義関数の定義」を参照してください。変更タイプ属性に対するユーザー定義関数の設定方法の詳細は、「例: 変更タイプ属性に対するユーザー定義関数の実施」を参照してください。
有効
「有効」分類コードはユーザーが値リストから選択します。有効値は変更ヘッダー・タイプで指定されます。注意: 分類を使用できるのは、基本カテゴリが「変更オーダー」の変更カテゴリのみです。
ステータスを使用すると、懸案または変更をライフサイクルを通して管理できます。懸案または変更の様々な状態を示すステータスを定義します（「オープン」、「保留中」、「完了」、「取消済」など）。
ステータスは、すべての変更カテゴリとその変更タイプに適用できます。
シードされているステータスは削除したり無効にできませんが、自社のビジネス・プロセスに固有な新規ステータスを定義できます。ユーザー定義ステータスは、「無効日」フィールドに指定した日付で無効にできます。
ワークフロー・テンプレートを使用すると、ビジネス承認プロセスを事前定義できます。「懸案」、「変更要求」、「変更オーダー」などの変更カテゴリは、承認経路が正常に完了した場合のみ承認されます。各変更タイプに対するワークフロー・テンプレートは、「変更管理」ワークフロー・タブの「設定ワークベンチ」にリストされているワークフロー・テンプレートを使用して作成および保守できます。
新規ワークフロー・テンプレートの作成
ワークフロー・テンプレートの作成時には、そのタイプを指定する必要があります。
注意: 特定のタイプを指定してワークフロー・テンプレートを作成した後、そのタイプは変更できません。
現在、次のタイプのワークフロー・テンプレートがサポートされています。
承認
「承認」タイプのワークフロー・テンプレートは、ステータス・タイプが「承認」のワークフローでのみ有効です。
定義
「定義」タイプのワークフロー・テンプレートは、ステータス・タイプが「オープン」の新規品目要求のワークフローで主に使用されます。
定義と承認
「定義と承認」タイプのワークフロー・テンプレートは、ステータス・タイプが「承認」の新規品目要求で主に使用されます。
一般
「一般」タイプのワークフロー・テンプレートは、その他のステータス・タイプの場合に使用されます。
特定のワークフロー・タイプを特定のステータスに関連付けることができます。次の表に、ステータス・タイプとワークフロー・タイプの関連付けを示します。
| ステータス・タイプ | 有効なワークフロー・タイプ |
| 承認/検討 | 承認 |
| その他 | 一般 |
| ステータス・タイプ | 有効なワークフロー・タイプ |
| オープン | 定義 |
| 承認/検討、定義と承認、承認 | 承認 |
| その他 | 一般 |
ワークフロー・テンプレートは、基本的に複数の承認ステップで構成されています。各承認ステップでは、ワークフロー・プロセスを記述して担当者を指定します。たとえば、承認の要求、コメントの要求、FYI通知の送信などを実行するステップを作成できます。
ワークフロー・テンプレートには、次のシード済ワークフロー・プロセスを使用できます。
承認の要求
「承認の要求」ワークフローを使用すると、個人またはグループから承認を要求できます。
参考
「参考」ワークフローを使用すると、個人またはグループにFYI通知を送信できます。
コメントの要求
「コメントの要求」ワークフローを使用すると、個人またはグループからコメントを要求できます。
定義
「定義」ワークフローは主に新規品目要求で使用し、「新規品目要求」プロセスで品目属性グループを関連付けることができるため、ステップ担当者が品目属性グループを定義できます。
定義と承認
「定義と承認」ワークフローは「定義」ワークフローに類似していますが、ステップ担当者の承認が必要です。詳細は、「新規品目要求の定義」の項を参照してください。
特定タイプの変更に必要な承認プロセスを企業内で計画して文書化する必要があります。承認プロセスを事前に計画することによって、自社のビジネス目的に適合したワークフロー・テンプレートを定義できます。
承認は並列またはシリアルに管理できます。並列の場合は複数の個人またはグループを1つの経路ステップに割り当て、シリアルの場合は1名の個人または1つのグループを1つの経路ステップに割り当てます。特定のロール、個人またはグループを1つの経路ステップに割り当てることもできます。品目ロールは、承認経路ステップに割り当てられた変更ロールにマップする必要があります。これによって、変更が作成されたとき、個人またはグループが確実に割り当てられます（変更ロールへの品目ロールのマッピングの詳細は「ロールの定義」を参照）。
オラクル社は、ワークフローの拡張機能をサポートしています。拡張機能には、既存のシード済プロセスを使用して新規ワークフロー・プロセスを構築する機能、およびプロセス・ロジックを変更せずにアクティビティのパラメータを変更する機能（たとえば、承認経路の中止サブプロセスへのカスタム・ロジックの追加）が含まれます。
シードされている「変更管理」ワークフローが自社のビジネス処理ニーズに適合しない場合は、同じくシードされている「変更管理」ワークフロー・プロセスをカスタマイズまたは拡張できます。これを行うには、独自のプロセスの作成、シード済プロセスの変更、シード済プロセスへの新規アクティビティの追加、またはカスタム・フックPL/SQLプロシージャの変更を実行するか、これらを組み合せて実行します。
関連項目: シードされているワークフローのカスタマイズ、またはOracle APCへの新規ワークフローの追加の詳細は、付録A「変更管理ワークフロー」を参照してください。
シードされているワークフローを変更しないで、「優先度変更」用の新規ワークフロー・プロセスを作成する場合は、「ワークフローの開始」でコールされるカスタム・フックでカスタム・ワークフローが開始されるように、独自のカスタム・ロジックを記述する必要があります。
変更承認経路ステップ（ENGCSTEP）で新規ワークフロー・プロセスを追加すると、そのプロセスは「承認経路」ページの承認経路ステップ・ワークフローとして有効になります。ワークフロー・プロセスは、「承認経路」ワークフローから自動的にコールされます。
アクティビティは複数のオブジェクトのプロセスで共有されるため、アクティビティは「ENG: 標準」（ENGWFSTD）品目タイプで作成してください。それ以外の場合、アクティビティは適切なオブジェクトの品目タイプで作成してください。
ワークフロー通知を変更するのではなく、新規メッセージを作成する必要があります。Oracle Workflow Builderでは、品目タイプ、品目タイプ属性、メッセージ、参照タイプなどのオブジェクトのバージョン情報が保守されません。このようなオブジェクトの場合は最新の定義が常に適用されるため、これらのオブジェクトに対する変更に下位互換性があるかどうかを考慮する必要があります。変更によって既存のプロセスが影響を受ける場合は、既存のオブジェクトを編集するのではなく、新規オブジェクトを作成する必要があります。
注意: オラクル社がサポートしているのは、このガイドで説明しているシード済のアクティビティ、プロセス、および拡張機能のタイプのみです。カスタムのアクティビティとプロセスはサポートしていません。
タスク・テンプレートによって、変更オーダーについて完了する必要がある様々なタスクを定義します。タスク・テンプレートを作成できるのは、基本変更カテゴリが「変更オーダー」のカテゴリに対してのみです。
タスク・テンプレートの作成
タスク・テンプレートは特定の組織用に作成します。したがって、複数のタスク・テンプレートを1つの変更オーダー・タイプに関連付けることができます。変更オーダーを作成した組織に応じて、変更オーダーに関連付けられている組織に対して定義したタスク・テンプレートが適用可能になります。
タスクが「必須」として指定されている場合、そのタスクは、変更オーダーが次のステータスに進む前に完了する必要があります。タスク・テンプレートを作成した後は、そのタスク・テンプレートを使用して変更オーダー・ヘッダー・タイプの組織ポリシーを定義できます。詳細は「ヘッダー・タイプの定義」の項で説明します。
属性と属性グループを定義すると、懸案、変更要求および変更オーダーに関連する追加情報を取得できます。検証ロジックを持つユーザー定義属性を作成し、その内容を属性グループ内の属性の集合として変更タイプに関連付けることができます。
属性は名称と値で定義し、属性グループ内に保存されます。属性グループは、変更ヘッダー・タイプまたは変更ライン・タイプに関連付けることができます。ヘッダー・タイプとライン・タイプには、属性グループを個別に定義する必要があります。異なる変更カテゴリおよびその変更タイプの間で同じ属性グループを再利用できます。ユーザーは、変更タイプごとに作成されたページで属性の値を入力します。さらに、変更オブジェクトの属性の表示方法を定義して使いやすさを改善できます。
検索パフォーマンスの速度を上げるために、属性の索引を作成できます。数値または日付データ型の場合、Bツリー索引を作成すると、ユーザーは広範囲の値を検索したり、「より小さい」、「より大きい」などの比較演算子を使用できます。テキスト属性の場合は、Oracle Textの索引を使用すると柔軟なキーワード検索ができます。
ユーザー定義属性を作成する前に、次の作業を実行してください。
関連する属性を同じ属性グループにグループ化します。次の表に、属性をグループ化する例を示します。
| 属性グループ | 属性 | データ型 |
| 顧客優先度 | 顧客 | CHAR |
| 優先度 | CHAR | |
| 日付 | 標準日付 | |
| 検討 | CHAR | |
| 実施原価 | 製造 | NUMBER |
| 設計 | NUMBER | |
| 仕入先費用など | NUMBER |
必要な場合は、カスタム権限を持つオブジェクト・ロール（変更）を作成して、属性グループ・セキュリティを定義します。属性グループを保護するには、編集権限または参照権限を設定します。これによって、これらの属性を参照または編集できるのは、特定のロールを持つユーザーのみに限定されます。
属性のデータ型を決定します（たとえば、NUMBER、CHAR、DATE）。
注意: 属性を保存した後はデータ型を編集できません。
単位区分（通貨など）と単位（USドルなど）を設定します。
属性ごとに検証ルールを設定し、対応する値セットを作成します。詳細は、「ユーザー定義属性に対する値セットの定義」を参照してください。
属性グループの表示方法を決定します。
単一行: 各テキスト・フィールドに1つの値を表示します。
複数行: 表内で、同じ属性（列）に対して複数の値（行）を表示します。
注意: 属性グループを複数行で表示する場合は、レコードの一意性が維持されるように、属性または属性の組合せを定義してください。
次の図は、異なる属性に対する表示オプションの設定方法を示しています。「変更タイプ属性の定義」の項にある図は、表示オプション設定の結果を示しています。たとえば、属性「顧客」はテキスト・フィールドとして表示するように設定され、結果の図ではテキスト・フィールドとして表示されています。属性「顧客」には値セット「顧客」が使用されています。この値セットは、実際には値リスト（LOV）テキスト・フィールドとして表示される表です。また、属性「顧客」は一意キーの一部として保守されます。この一意キーは、複製を作成して既存のレコードの一意性が損なわれないかぎり、追加したり編集できます。
また、次の図では、「会社名」属性の「使用可能」パラメータが「No」に設定されています。これは、この属性が変更ページに表示されないことを示します。属性はいつでも無効にできます。ただし、属性グループが変更タイプにすでに関連付けられている場合は属性を削除できません。
変更属性と属性グループの定義
変更タイプ属性の定義（属性値の設定）
関連項目: 属性グループと属性の作成方法の詳細は、「品目属性と属性グループの定義」およびAPCオンライン・ヘルプ（iHelp）を参照してください。
変更タイプによって、企業はビジネス・プロセスに対応して変更カテゴリ内の変更タイプを分類できます。たとえば、品質、製品、パフォーマンスなどに関わる懸案タイプを定義し、企業内の様々なタイプの懸案を把握できます。
変更タイプは、次の項目を設定して構成できます。
自動追跡番号
プリフィクスおよび連番の次有効番号を指定できます。たとえば、設計変更タイプにプリフィクスDSGNが付くように構成できます。
デフォルト割当ロール
特定の個人またはグループには、品目ロール（「デザイン・エンジニア」など）をデフォルト割当ロールとして指定できます。たとえば、「デザイン・エンジニア」を選択すると、変更が作成された対象品目に対して「デザイン・エンジニア」ロールを持つ個人またはグループが、その変更に割り当てられます。変更は1名の個人または1つのグループにのみ割り当てられるため、予定していた個人またはグループにのみ変更が割り当てられていることを確認してください。指定のロールを持つ個人が複数必要な場合は、グループを作成して、同じロールを持つすべてのユーザーをそのグループに配置し、グループに対してデフォルト割当ロールを指定することをお薦めします。「デザイン・エンジニア」ロールのユーザーが複数存在する場合、変更はいずれかのユーザーにランダムに割り当てられます。
属性グループ/ページ
ヘッダーに対して定義した複数の属性グループを1つの変更タイプに割り当てることができます。これらの属性グループを使用すると、作成する変更のタイプに関する追加情報、または変更の処理に必要なビジネス・プロセス固有の属性を取得できます。また、変更タイプ用のページを作成して、変更タイプに関連付けられた属性グループを論理的な方法で編成できます。
有効コードの設定
変更タイプには、「優先度」、「事由」および「分類」の有効コードを指定できます（分類コードが使用できるのは、「変更オーダー」カテゴリに基づいた変更タイプのみです）。これによって、ユーザーが選択できる値を、各コードに対して選択した値に制限できます。各コードに対する値の作成については、この章ですでに説明しています。
基準属性グループとセクションの構成
自社のビジネス・プロセスに従って、変更タイプに対して特定の基準属性グループとセクションのみを有効にできます。たとえば、マーケティングに関する問題の場合、「プロジェクト名」属性と「プロジェクト・タスク名」属性はほとんど使用しないため、これらの属性を無効にできます。同様に、仕入先要求に関する問題の場合は、組織の人員とそのロールを仕入先に表示する必要がないため、「担当」セクションを無効にできます。
ワークフロー
ワークフロー・タブでは、変更タイプに対して様々なステータスを定義できます。ステータスごとに関連付けることによって、促進と後退に有効なステータスを指定し、ワークフローを各ステータスに関連付けることができます。「承認」ステータスの場合、選択できるのは「承認」タイプのワークフローのみです。また、必要な場合は、承認用のデジタル署名を有効にできます。ワークフローがステータスに関連付けられている場合は、自動促進と自動後退も有効にできます。この場合、変更は、ワークフローが正常に完了すると、選択したステータスに自動的に促進され、ワークフローが拒否されると、選択したステータスに自動的に後退します。
変更オーダーに対する組織ポリシーとタスク・テンプレート
タスク・テンプレートと伝播ルールを組織別に指定できるのは、変更オーダーの場合のみです。一連の変更タスク（タスク・テンプレートで定義します）を、変更タイプのワークフローの特定のステータス時または特定の2つのステータス間で実行されるようにグループ化できます。全部または一部のタスクを必須にするかどうかも指定できます。
組織別のタスク・テンプレートの関連付け
変更オーダーの伝播ルール
各組織に対するタスク・テンプレートの関連付けに加え、このタイプの変更オーダーを他の組織に伝播する場合の伝播ルールを指定できます。伝播ルールを使用すると、関連するすべての改訂品目とタスクも含めて変更オーダーを伝播する組織階層を指定できます。伝播ルールは、変更オーダーが指定のステータスになると自動的に実行されます。
伝播ルールの定義
変更ライン・タイプを使用すると、品目に対する特定の変更、または変更に関連するタスクを取得できます。たとえば、複数のライン・タイプを定義すると、品目に関連する変更（品目属性の変更、構成部品再設計の変更、文書の変更、部品の廃止など）を取得できます。
変更ライン・タイプ
ライン・タイプの作成は、変更ヘッダー・タイプの作成と類似しています。各ライン・タイプには、関連付けられた件名およびデフォルト担当者を設定できます。
変更ライン・タイプの定義
属性、値、値セットおよび属性グループを作成した後は、属性グループを変更タイプまたはライン・タイプに関連付けます。また、関連付けられた属性グループを表示するためのページを定義できます。
注意: 異なる変更カテゴリに属する変更タイプ間で、同じ属性グループを再利用できます。
属性グループを変更タイプに関連付ける手順は、次のとおりです。
該当する変更タイプ（「変更オーダー」または「懸案」）の「属性グループ」リストに属性グループを追加します。
たとえば、変更カテゴリ「変更オーダー」には、変更タイプ「設変」を設定します。次の図では、属性グループの「実施原価」と「単位原価」がヘッダー・タイプ「設変」に関連付けられています。
変更タイプ属性の関連付け
関連付けられた属性グループの変更ページを定義します。1ページに複数の属性グループを配置したり、属性グループごとに個別のページを作成することができます。次の図は、変更オーダー・タイプ「設変」に「分類」ページと「影響分析」ページがあることを示しています。「属性のページの作成」にある図は、変更オーダーの1ページに2つの属性グループがレンダリングされている例を示しています。
属性のページの作成
変更オーダーの「概要」ページに表示された属性の変更ページ
ライン・タイプは、属性グループまたはページが含まれるように構成できます。ラインに対して定義した複数の属性グループを1つの変更タイプに割り当てることができます。これらの属性グループを使用すると、作成する変更のタイプに関する追加情報、または変更の処理に必要なビジネス・プロセス固有の属性を取得できます。また、ライン・タイプ用のページを作成して、ライン・タイプに関連付けられた属性グループを論理的な方法で編成できます。
変更ライン・タイプに対する属性グループ
ロール・ベースの変更管理セキュリティを実施するときは、権限を設定して、特定の変更管理属性グループに対する表示権限と編集権限を管理できます。変更オブジェクトの特定の属性グループを表示または編集（あるいはその両方）できるユーザーを管理するには、そのユーザーに特定の権限を付与したロールを割り当てます。デフォルトでは、変更ロールの「変更基本情報の表示」権限と「変更の編集/削除」権限によって、属性グループ・レベルで特に管理されない属性を表示または編集できるかどうかが管理されます。つまり、変更管理セキュリティを実施するときは、属性グループごとに表示権限または編集権限を指定する必要はありません。
たとえば、所属している会社が仕入先と共同で次世代デスクトップ・コンピュータの新しいマザーボードを設計するとします。マザーボードの設計変更に関する仕入先とのコミュニケーションを向上させるには、外部の変更要求情報を仕入先と契約製造業者で安全に共有する必要があります。したがって、特定の属性グループを参照できるのは、仕入先エンジニアのみに制限する必要があります。
変更管理の属性グループ・セキュリティを実施する手順は、次のとおりです。
「アプリケーション開発者」職責を選択して「フォーム機能」フォームにナビゲートし、属性グループに対する表示権限と編集権限を管理する権限ごとにフォーム機能を作成します。フォーム機能ごとに「オブジェクト」フィールドで「変更」または「ラインの変更」を指定します。
「開発マネージャ」職責を選択して「設定ワークベンチ」にナビゲートします。各属性グループの「属性グループ詳細」ページにある「データ・セキュリティ」セクションで、「参照権限」および「編集権限」を指定します。
ロール詳細の変更ページで、前のステップでフォーム機能として定義した権限を付与します。
関連項目: 変更管理に対する属性グループ・セキュリティ設定の詳細は、「品目属性グループ・セキュリティの設定」およびAPCオンライン・ヘルプ（iHelp）の次の項を参照してください。
カスタム権限の作成
ユーザー定義属性
ロールの管理
ユーザー定義の関数および処理を既存の変更ページに追加して、独自のカスタム・ロジックを定義できます。この場合、ページ全体をカスタマイズする必要はありません。
ユーザー定義関数は、顧客固有のビジネス・ルールや計算を実行するために登録できます。この関数は、JavaまたはPL/SQLで記述できます。また、URL関数を使用すると、特定のパラメータの値をURL文字列に渡し、ユーザーを保護されたページにリダイレクトできます。関数ごとにパラメータ・タイプを指定して、パラメータのリスト、そのデータ型、および値の取得方法を登録する必要があります。
処理は関数に対するトリガー・ポイントで、ボタンまたはリンクとして表示できます。ユーザーの入力に基づいて、ボタンまたはリンクの条件表示を設定したり、ユーザーにプロンプトを表示できます。
例: 変更タイプ属性に対するユーザー定義関数の実施
次の例では、属性グループ「実施原価」を使用して原価合計を計算する方法を示します。
| 順序 | 属性グループ: 「実施原価」 | 属性グループ: 「実施原価」 | 属性グループ: 「実施原価」 | PL/SQL関数: 原価の計算 | PL/SQL関数: 原価の計算 | PL/SQL関数: 原価の計算 |
| 順序 | 属性名 | データ型 | 属性とパラメータのマッピング | パラメータ名 | データ型 | パラメータ・タイプ |
| 1 | 仕入先費用 | NUMBER | --à ---à ---à | 原価1 | NUMBER | 入力 |
| 2 | 製造 | NUMBER | --à ---à ---à | 原価2 | NUMBER | 入力 |
| 3 | 設計 | NUMBER | --à ---à ---à | 原価3 | NUMBER | 入力 |
| 4 | フィールド/修理 | NUMBER | --à ---à ---à | 原価4 | NUMBER | 入力 |
| 5 | 実施原価合計 | NUMBER | --à ---à ---à | 原価結果 | NUMBER | 戻り値 |
最初に、（PL/SQLパッケージにあるPL/SQLプロシージャに基づいて）必要なパラメータをすべて指定してPL/SQL関数の原価の計算を登録します。
次に「設変」変更オーダー・タイプにナビゲートして「処理の更新」をクリックし、属性グループ「実施原価」に処理を追加します。この処理によって、変更ページで関数が実行されます。処理を作成した後は、関数パラメータを対応する属性にマップします。
「処理詳細」ページのマッピング・セクションには、関数パラメータのマッピング情報が表示されます。また、関数のパラメータをオブジェクトの主キー値（たとえば、変更オブジェクトのCHANGE_ID）にマップすることもできます。
処理を設定する手順は、次のとおりです。
処理を保護するために、ロール・ベースの権限を指定します。
ユーザーに対して処理ボタンまたはリンクを表示する前に満たす必要がある条件がある場合は、動的表示制御関数（Javaのみで記述）を処理に追加します。たとえば、1つまたはすべてのフィールドが空の場合は、処理を実行するためのボタンまたはリンクをユーザーに対して表示しないようにできます。
特定の条件に応じてボタンまたはリンクのラベルを変更する必要がある場合は、動的プロンプト関数（Javaのみで記述）を処理に追加します。たとえば、「実施原価合計」属性が空の場合はボタン・ラベルを「適用」にし、それ以外の場合は「変更の適用」にできます。
注意: 動的プロンプト関数および動的表示制御関数のパラメータも対応する属性にマップする必要があります。
関数を実行するための処理と属性グループの関連付け
処理ボタンが表示された変更タイプ属性ページ
関連トピック
関連項目: ユーザー定義関数の詳細は、「品目属性に対するユーザー定義関数の実施」およびAPCオンライン・ヘルプ（iHelp）を参照してください。
基準テンプレートを使用すると、頻繁に使用する検索基準を保存できます。この検索基準は、基本的には特定の属性と属性値の保存リストとして動作します。管理者が作成するこの基準テンプレートはすべてのユーザーが使用でき、懸案、変更要求および変更オーダーに関する検索を迅速に処理できるため、ユーザーは検索基準を指定して変更管理検索を頻繁に実行する時間を節約できます。
ユーザーは、独自に使用する基準テンプレートを作成することもできます。ユーザーと管理者の両方が特定の変更カテゴリに対してデフォルトの基準テンプレートを定義した場合は、ユーザー定義の基準テンプレートが優先されます。
基準テンプレートにはユーザー定義属性が含まれるため、管理者は常に変更カテゴリに応じて基準テンプレートを定義する必要があります。必要な数の基準テンプレートを定義でき、最も頻繁に使用する基準テンプレートをデフォルトの基準テンプレートとして示すこともできます。たとえば、オープン変更要求、懸案または計画済変更オーダーを迅速に検索するための基準テンプレートを定義できます。
関連項目: 変更カテゴリの基準テンプレートの作成方法は、APCオンライン・ヘルプ（iHelp）を参照してください。
結果書式を使用すると、各変更カテゴリの検索結果ビューを事前定義できます。このビューを使用して、検索によって戻される変更オブジェクト（懸案、変更要求、変更オーダーなど）に関する別の属性セットを参照できます。結果書式は管理者およびユーザーのいずれも作成できます。管理者が作成した結果書式はすべてのユーザーが使用できます。ユーザーが作成した結果書式は、その結果書式を作成したユーザーのみが使用できます。必要な数の結果書式を定義でき、最も頻繁に使用する結果書式をデフォルトの結果書式として示すこともできます。
結果書式の定義には、任意の基本属性またはユーザー定義属性を含めることができます。ただし、複数行の属性グループは結果書式を使用して表示できません。この場合は、表示セクションを結果書式に挿入し、検索結果からそのセクションに直接ジャンプできるリンクを表示します。これによって、検索結果には、ユーザー定義変更タイプ・ページ（「原価情報」など）へのリンク、または、「ライン」、「添付」、「処理ログ」、「承認」、「承認履歴」、「依存関係」、「改訂」および「担当」の各標準表示セクションから任意のセクションを表示できます。
関連項目: 変更カテゴリの結果書式の作成方法は、APCオンライン・ヘルプ（iHelp）を参照してください。
「原価情報」結果書式を使用した変更要求の検索結果
変更管理レポートは基本的に検索基準と表示書式で構成され、保存、ブラウズ、電子メールまたは印刷が可能です。すべての変更管理カテゴリについてレポートを作成できます。また、レポートは順次にブラウズしたり、要約ビューを使用することもできます。レポートを順次にブラウズすると、レポート内に表示された各変更オブジェクトを順番に参照できます。要約ビューには、レポートが表形式で表示されます。レポートは他のユーザー（登録されている仕入先および顧客を含む）に送信できます。
管理者は、システムのユーザーが最も多くまたは頻繁に実行する検索についてレポートを作成できます。このようなレポートは、実施するビジネス・プロセスに基づいて作成します。一般ユーザーは管理者が定義したレポートを使用することによって、変更カテゴリ、検索基準および表示書式を選択したり、同じ検索を何度も繰り返す時間を節約できます。レポートには意味のある名称を付けることができます。たとえば、高優先度のオープン懸案を検索すると懸案が多数検出され、それぞれ懸案名と番号で識別されます。このような検索結果のレポートには、次の図に示すように「高優先度オープン懸案レポート」という名称を付けることができます。
レポート・セキュリティは検索セキュリティと一貫性を維持しています。このため、アクセスできるのは、必要なロールを持つ変更オブジェクトのみです。また、管理者が作成したレポートはすべてのユーザーが使用できますが、管理者が編集できるのは管理者自身が作成したレポートのみです。
高優先度懸案レポート
