プロジェクト・ステータス変更ワークフロー
ユーザーがプロジェクトをワークフロー対応ステータスに設定すると、プロジェクト・ステータス変更承認ワークフローがトリガーされます。 その後、このワークフローによって構成済の割当先に通知され、その割当先はステータス変更を承認または否認するか、必要に応じて詳細情報を調べる必要があります。 このワークフローのデフォルト承認ルールは、承認をプライマリ・プロジェクト・マネージャにルーティングします。 承認ワークフローが取り下げられたり、エラーが発生した場合、アプリケーションはプロジェクトを前のステータスに戻します。
BPMワークリスト・ツールでは、このワークフローはProjectStatusNotificationApprovalと呼ばれます。
プロジェクト・ステータス変更承認プロセス
プロジェクト・ステータス変更承認プロセスについて説明する表を次に示します。
タスク番号 | エージェント | 摘要 | コメント |
---|---|---|---|
1 | Requester* *Project Manager. プロジェクト管理者、またはプロジェクト・ステータスを変更する権限を持つその他のロール。 |
ユーザーは、ワークフローをトリガーするワークフロー対応ステータスに(UIまたはREST APIを使用して)プロジェクトのステータスを変更します。 | 「設定およびメンテナンス」内の「プロジェクト・ステータスの管理」タスクで、プロジェクト・アプリケーション管理者によるワークフロー承認に対してステータスが使用可能になります。 |
2 | プロジェクト・ステータス変更承認ワークフロー | ワークフローは、構成済のとおり、電子メール通知またはアプリケーション内通知を使用して、すべての構成済割当先に通知を送信します。 | 承認ワークフロー通知の変更方法の詳細は、共通アプリケーションの実装ガイドのワークフロー通知を参照してください。 |
3 | ワークフロー割当先 | 担当者は、承認通知をレビューし、プロジェクト・ステータス変更を承認または否認します。 担当者は、依頼者から詳細情報を求めることもできます。 |
ワークフローでパラレル承認者が使用されている場合、投票率ルールを使用して最終承認が決定されます。 BPMワークリストを使用して承認ワークフローを更新する方法の詳細は、共通アプリケーションの実装ガイドの「ワークフロー承認および通知」を参照してください。 「買掛/未払金請求書を使用した支払」ガイドの請求書の承認方法も参照してください。 |
4 | プロジェクト・ステータス変更承認ワークフロー | ワークフローにより、プロジェクト・ステータスが更新されます:
新しいステータスもワークフロー対応の場合は、別の承認タスクが起動されます。 |
NA |
財務管理に使用可能なプロジェクトのステータス変更のワークフローを以前に構成していて、ワークフローを非財務プロジェクトに拡張する場合は、まずワークフロー構成をレビューして、必要に応じて更新します。

プロジェクト・ステータス変更承認ワークフローの構成
「設定および保守」の「プロジェクト・ステータスの管理」タスクを使用して、ワークフロー承認のプロジェクト・ステータスを使用可能または使用不可にします。 ワークフロー承認をトリガーする各プロジェクト・ステータスの「ワークフロー使用可能」チェック・ボックスを選択します。
ワークフローが有効な各プロジェクト・ステータスについて、次の属性も指定する必要があります:
-
変更受入後のステータス: プロジェクト・ステータス変更を受け入れると、アプリケーションによってプロジェクトに割り当てられるステータス。
-
変更否認後のステータス: プロジェクト・ステータス変更を否認した後に、アプリケーションによってプロジェクトに割り当てられるステータス。
その他のルール変更:
- すべての事前定義済ルール・セットのデフォルトの承認ルールは、承認のためにプライマリ・プロジェクト・マネージャに通知を送信するように構成されています。 事前定義済ルールをレビューし、必要に応じて変更する必要があります。
-
使用しない関係者を無効にするには、関係者の無視オプションを有効にするか、関係者を無視するルールを定義します。
このワークフローのルールを構成するには、プロジェクト・アプリケーション管理者ジョブ・ロール(または同様の権限を持つ別のジョブ・ロール)が必要です。
たとえば、実装時に「発行済」ステータスのワークフローを有効にし、次のワークフロー属性を構成するとします:
-
「発行済」プロジェクト・ステータスの「変更受入後のステータス」フィールドで、「アクティブ」ステータスを、ステータス変更が受け入れられるときにアプリケーションがプロジェクトに割り当てるステータスとして指定します。
-
「発行済」プロジェクト・ステータスの「変更否認後のステータス」フィールドで、「却下済」ステータスを、ステータス変更が否認されたときにアプリケーションがプロジェクトに割り当てるステータスとして指定します。
この例では、依頼者がプロジェクト・ステータスを「発行済」に変更すると、ワークフロー・プロセスによってステータス変更リクエストがプライマリ・プロジェクト・マネージャのワークリストにルーティングされます。 プロジェクト・マネージャがステータス変更を受け入れると、ワークフロー・プロセスによってアクティブ・ステータスがプロジェクトに割り当てられます。 プロジェクト・マネージャがステータス変更を否認すると、ワークフロー・プロセスによって「否認済」ステータスがプロジェクトに割り当てられます。

ワークフローの構成: サポートされている属性
プロジェクト・ステータス変更承認ワークフローが起動されると、複数のプロジェクト関連属性の現在の値がペイロードに含められます。 これらの属性を使用して、特定のビジネス・ニーズにあわせて承認をルーティングするルールを構成できます。
属性 | 摘要 |
---|---|
ProjectId | プロジェクトの一意の識別子。 |
ProjectName | プロジェクトの名前。 |
ProjectNumber | プロジェクト番号。 |
CarryingOutOrganizationId | プロジェクト組織の一意の識別子。 |
ProjectOrganizationName | プロジェクト組織の名前。 |
ProjectUnitId | プロジェクト・ユニットの一意の識別子。 |
ProjectUnitName | プロジェクト・ユニットの名前。 |
ProjectTypeId | プロジェクト・タイプの一意の識別子。 |
ProjectTypeName | プロジェクト・タイプの名前。 |
BusinessUnitId | ビジネス・ユニットの一意の識別子。 |
BusinessUnitName | ビジネス・ユニットの名前。 |
LegalEntityId | 法的エンティティの一意の識別子。 |
LegalEntityName | 法的エンティティの名前。 |
WorkTypeId | 作業タイプの一意の識別子。 |
WorkTypeName | 作業タイプの名前。 |
ProjectCurrencyCode | プロジェクト全体の金額を共通通貨でレポートするために使用される通貨のコード。 |
ProjectLedgerCurrencyCode | プロジェクトに関連付けられた元帳の通貨のコード。 |
SponsoredFlag | プロジェクトがスポンサードかどうかを示すフラグ。 |
ProjectTeamMember-> ProjectPartyId | プロジェクト・チーム・メンバーの一意の識別子。 |
ProjectTeamMember-> TeamMemberRoleId | プロジェクト・チーム・メンバーに割り当てられたロールの一意の識別子。 |
ProjectTeamMember-> TeamMemberRoleName | プロジェクト・チーム・メンバーに割り当てられたロールの名前。 |
ProjectTeamMember-> TeamMemberPersonId | プロジェクト・チーム・メンバーのレコード個人の一意の識別子。 |
ProjectTeamMember-> TeamMemberEmailAddress | プロジェクト・チーム・メンバーの電子メール・アドレス。 |
ProjectTeamMember-> TeamMemberUserName | プロジェクト・チーム・メンバーのユーザー名。 |
ProjectTeamMember-> StartDateActive | プロジェクト・チーム・メンバーの開始日。 |
ProjectTeamMember-> EndDateActive | プロジェクト・チーム・メンバーの終了日。 |
ProjectTeamMember-> PjsTrackTime | チーム・メンバーの欠落時間を追跡するかどうかを示すフラグ。 |
プロジェクト・フレックスフィールド | 組織で使用するために作成されたカスタムのプロジェクト関連フレックスフィールド。 |
ProjectEpsNodeMember-> EpsNodeId | プロジェクトが属するエンタープライズ・プロジェクト体系(EPS)ノードの一意の識別子。 |
ProjectEpsNodeMember-> EpsNodeName | プロジェクトが属するエンタープライズ・プロジェクト体系(EPS)ノードの名前。 |
ProjectEpsNodeMember-> EpsNodeTypeCode | プロジェクトが属するエンタープライズ・プロジェクト体系(EPS)ノードのタイプのコード。 |
ProjectEpsNodeMember-> EpsMemberId | エンタープライズ・プロジェクト体系(EPS)メンバーの一意の識別子。 |
ProjectEpsNodeMember-> EpsMemberDisplayName | エンタープライズ・プロジェクト体系(EPS)メンバーの名前。 |
ProjectEpsNodeMember-> EpsMemberTypeFlag | エンタープライズ・プロジェクト体系(EPS)メンバーのタイプを示すフラグ。 |
ProjectEpsNodeMember-> EpsMemberUsername | エンタープライズ・プロジェクト体系(EPS)メンバーに関連付けられたユーザー。 |
ProjectClassification-> ProjectClassCategory | プロジェクトに割り当てられたプロジェクト・カテゴリ。 |
ProjectClassification-> ProjectClassCode | プロジェクトに割り当てられたプロジェクト区分カテゴリに関連付けられたプロジェクト区分コード |
ProjectClassification-> ClassCodePercentage | プロジェクト区分コード率。 |
属性 | 摘要 |
---|---|
projectStatusCode | プロジェクト・ステータスの一意のコード。 |
projectStatusName | プロジェクト・ステータスの名前。 |
sourceStatusCode | STATUS_TYPEで識別される、各ソース・オブジェクトに固有のステータス・コード。 プロジェクト・ステータス・モデルを取り込むオブジェクトは、STATUS_TYPEおよびSOURCE_STATUS_CODEを使用してプロジェクト・ステータスを解決するか、グローバルに一意のPROJECT_STATUS_CODEを使用します。 |
startDateActive | プロジェクト・ステータスの有効開始日。 |
endDateActive | プロジェクト・ステータスの有効終了日。 |
プロジェクト・ステータス変更承認ワークフロー通知
プロジェクト・ステータス変更承認ワークフローは、次の場合に通知を送信します:
- プロジェクト・ステータス変更承認ワークフローが開始されます。
-
プロジェクト・ステータス変更承認ワークフローは、「承認済」または「却下済」です。
デフォルトのプロジェクト・ステータス変更承認ワークフロー通知には、次の詳細が含まれます:
-
ヘッダー
-
プロジェクト・ステータス変更承認通知
- プロジェクト名
-
- 承認オプション(承認者に送信された場合)
- 承認
- 否認
- 情報のリクエスト?
- コンテンツ・セクション
- 作成日
- 作成者
- プロジェクト番号
- プロジェクト摘要
- 前のプロジェクト・ステータス
- 現在のプロジェクト・ステータス
- 承認された場合の次のプロジェクト・ステータス
- 否認された場合の次のプロジェクト・ステータス
- 発行者からのコメント
-
プロジェクト詳細
-
プロジェクト・タイプ
-
ビジネス・ユニット
- 組織
- プロジェクト・ユニット
- プロジェクト・マネージャ
- プロジェクト開始日
- プロジェクト終了日
-
-
財務サマリー
- 実績原価
- 取引約定
- 完了時予算
- 収益
- 承認履歴: 承認者ごとに1行。
- 承認者
- 割当先 / 承認者 / 棄却者 <承認者の名前>
- 割当 / 承認 / 否認の日時
- 送信者
- 送信者<送信者の名前>
- 送信の日時
- トランザクション詳細へのリンク
- 承認者
BPMワークリスト・ツールでワークフロー通知を使用する方法のガイダンスは、アプリケーションの共通実装ガイドの「ワークフロー通知」の項を参照してください。
Oracle BI Publisherカタログの「共有フォルダ」>「プロジェクト」>「ワークフロー通知」>「プロジェクト・ファウンデーション」フォルダで、プロジェクト・ステータス変更承認ワークフローで使用されるテンプレートおよびデータ・モデルを検索できます。 このフォルダのProjectStatusChangeApprovalReportファイルには、通知レポートで使用されるテンプレートが含まれます。 「プロジェクト・ファウンデーション」>「データ・モデル」フォルダを展開して、通知レポートで使用されるデータ・モデルを含むProjectStatusDMファイルにアクセスします。
通知テンプレートの変更方法の詳細は、『Common Implementing Applications』ガイドの「構成可能な通知」の項を参照してください。