ソーシングと調達オペレーションとプロジェクト管理 (PM)との統合

  • リリースバージョン: Xanadu
  • 更新日 2024年08月01日
  • 所要時間：6分

    • ソーシングと調達オペレーションを 戦略的ポートフォリオ管理 (SPM) のプロジェクト管理 (PM)と統合することで、発注書をプロジェクトにリンクする手作業を排除します。

    ソーシングと調達オペレーションのプロジェクト原価計算 プラグイン (sn_spend_ppm) は、この統合を提供します。このプラグインは、個別に購入できる次のアプリケーションに依存しています。
    • ソーシングと調達オートメーション
    • Source-to-Pay 共通アーキテクチャ
    • ファイナンスコモンアーキテクチャ
    • 共通サービスデリバリ
    • 調達ケース管理
    • Source-to-Pay ワークスペース
    • サプライヤー共通アーキテクチャ
    • プレイブックエクスペリエンス
    • ドキュメントテンプレート
    • 共通ベンダーコア
    このプラグインは、個別にインストールする必要がある次のシステムプラグインにも依存しています。
    • 外部ユーザー自己登録
    • ファイナンスアプリケーション - 一般的な依存関係
    • 会計カレンダー
    • GraphQL プラグイン
    • Insert Multiple Web Service
    • PPM Standard
    • Process Automation Designer Core
    • Process Automation Designer for App Engine
    • スコープ対象のアプリケーション制限付きの発信者アクセス
    • Signature Pad
    • User Criteria Scoped API
    • ベンダーコア
    重要:
    チェックアウト時にプロジェクトの詳細を表示できるように、アドミニストレーターは、ライセンスされたロールである IT プロジェクトユーザーを購入者に手動で割り当てる必要があります。また、Source-to-Pay 価格設定イニシアチブの一環として、アドミニストレーターは PPM ユーザーロールを調達スペシャリストに手動で割り当てる必要があります。

    この統合により、プロジェクトマネージャーまたは購入者は購入をプロジェクトに関連付けることができます。これにより、購入の理由が提供されるだけでなく、そのプロジェクトのコスト計画と経費ラインも自動的に作成されます。これにより、プロジェクトマネージャー、買い物客、および調達スペシャリストは、 プロジェクト管理 (PM) プロジェクトの購入が行われるたびに計画コストを簡単に追跡し、 プロジェクト管理 (PM) プロジェクト購入の請求書が支払われるたびに実際のコストを実現できます。

    チェックアウトおよび購入の詳細への影響

    このアプリケーションがインストールされると、チェックアウト時に追加の質問 [既存プロジェクト用にこちらを購入されますか？ (Is this a purchase for an existing project?)] に回答する必要があります。回答が肯定である場合は、リストからプロジェクトを選択してチェックアウトを続行する必要があります。

    各プロジェクト名はデマンド番号に関連付けられており、どちらも [購入理由] フィールドに自動入力されます。必要に応じて、[購入理由] フィールドに情報を追加できます。チェックアウトが完了すると、これらの詳細が購入の詳細ページに表示されます。
    注:
    • この購入が既存のプロジェクトに対して行われていない場合は、[ 購入理由 ] フィールドに購入理由を入力してチェックアウトを続行する必要があります。
    • フルチェックアウト時に、購入全体のプロジェクトを選択することも、製品レベルで個別にプロジェクトを選択することもできます。
    • クレジット購入のプロジェクトを選択することはできません。

    購買要求行テーブルおよび発注明細テーブルへの影響

    購入要求が作成されると、購買要求行テーブルで [購入の詳細 (Purchasing Details)] フォームレイアウトを構成して、[プロジェクト] フィールドを表示できます。このフィールドは、選択したデマンドレコードを参照します。同様に、購買要求行が発注明細に変換されると、発注明細テーブルで [サマリー詳細] フォームレイアウトを構成して、同じ [プロジェクト] フィールドを表示できます。

    この統合の一環として、デマンドまたはプロジェクトの一部として購入が注文されるたびに、その発注明細に関連付けられたコスト計画が自動的に作成されます。発注明細の [サマリー詳細] フォームレイアウトを構成して、新しい [コスト計画 (Cost plan)] フィールドを表示できます。[発注明細] 関連リストも対応するコスト計画レコードに追加されます。[Cost Plan (コスト計画)] フォームの [Total planned cost (合計計画コスト)] フィールドは、発注書が生成された日時に基づいて自動入力されます。[ 合計実績コスト ] フィールドは、請求書と経費明細の作成に基づいて入力されます。

    フォームレイアウトの構成方法については、「 フォームレイアウトの構成」を参照してください。

    請求書明細行および経費明細テーブルへの影響

    請求書が作成され、請求書と請求書明細の両方が [支払い済み] ステータスの場合、プロジェクトの経費ラインが自動的に作成されます。この経費明細には [請求書明細行] 関連リストの参照があります。

    請求書の作成の詳細については、「 請求書」を参照してください。

    デマンドとプロジェクトのライフサイクルが ソーシングと調達オペレーション フローに与える影響

    デマンドがデマンドおよびプロジェクトライフサイクルの一部としてプロジェクトに変換される場合：
    • デマンド番号は、チェックアウト時に選択できません。
    • そのデマンド番号を使用する購買要求行が発注明細に変換されると、発注明細はデマンド番号ではなくプロジェクトを参照します。
    • コスト計画は、購入者が最初に選択したものではなく、新しく作成されたプロジェクトを参照します。
    • 請求書が作成されると、関連する経費明細はデマンド番号ではなくプロジェクトを参照します。
    デマンドまたはプロジェクトがクローズ済みステータスの場合：
    • チェックアウト時にデマンドまたはプロジェクト番号を選択することはできません。
    • コスト計画と経費ラインは、クローズ済みのデマンドとプロジェクトに対しては作成されません。ただし、クローズ済みデマンドまたはクローズ済みプロジェクトのコスト計画が既に作成されている場合は、すべての請求書が支払われるまで継続して経費明細が自動生成されます。

    調達要求への影響

    価格を利用できない製品の価格を要求する場合は、追加の質問「 これは既存のプロジェクトの購入ですか?」に回答する必要があります。回答が肯定である場合は、リストからプロジェクトを選択して要求の送信を続行する必要があります。送信が正常に完了すると、プロジェクトとデマンドの詳細が調達要求レコードに表示されます。

    購入者は、購入した価格を比較し、サプライヤーを選択して、チェックアウトに進むことができます。

    カタログ外購入要求への影響

    ShoppingHub カタログで利用できない製品の見積を要求する場合、追加の質問 [既存プロジェクト用にこちらを購入されますか？ (Is this a purchase for an existing project?)] に回答する必要があります。回答が肯定である場合は、リストからプロジェクトを選択して要求の送信を続行する必要があります。

    メール通知

    デマンドまたはプロジェクトに関連付けられた発注書が作成、更新、またはキャンセルされると、アサインされたデマンドマネージャーまたはプロジェクトマネージャーは、デマンドまたはプロジェクトのコスト計画への影響に関するメール通知を受け取ります。