JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

June 27, 2026 · 19 min read

SAP PS WBS階層

WBS階層は、すべてのSAPプロジェクトシステムプロジェクトの構造的な基盤です。プロジェクト定義内のWBS要素間の親子関係を捉え、プロジェクトツリー全体でコスト集約、予算配分、ステータスレポートを駆動する階層的な分解構造を形成します。この記事では、階層の概念的な役割、テーブルPRHIにおけるデータベース表現、それが及ぶ組織ディメンション、およびPSコンサルタントがS/4HANAでプロジェクト構造を設計・保守する際に理解すべきフィールドレベルの詳細について説明します。

第1部: WBS階層 — 中核概念（全モジュール）#

1.1 WBS階層とは#

WBS階層は、従来の意味での独立したマスタデータレコードではありません。これは、個々のWBS要素間の親子リンクの集合であり、テーブルPRHIに永続化され、プロジェクトのツリー状の分解構造を集合的に定義します。WBS要素（テーブルPRPS）がコスト、収益、ステータスデータを保持する一方、WBS階層は構造的な関係（どの要素がどの要素の親であるか、各要素がツリー内のどのレベルにあるか）を保持します。

1.2 階層レベルと構造パターン#

WBS階層は、プロジェクトプロファイルが許可する任意のツリー形状を取ることができますが、実際のPS実装では、少数の構造パターンに収束します。ブループリント段階で適切な深さと分岐戦略を選択することは重要です。プロジェクト実行開始後（実績原価が転記された後）の階層変更には、注意深いCJFN（再構築）手順が必要であり、コスト再割り当てワークフローをトリガーする可能性があります。

設計原則: 階層の深さは、組織上の見栄えではなく、実際の報告および原価収集のニーズを反映すべきです。追加のレベルごとに、決済ルール、予算配分ステップ、および期末処理時間が倍増します。深さは、管理会計チームと財務チームが現実的に維持できる範囲に制限してください。

1.3 組織レベルとデータ階層#

具体的な例を用いたデータ階層

Project Definition PROJ-2026-002
   Automotive Line Retooling
   │
   └── WBS Element PROJ-2026-002 (Level 1 — Summary)
          │
          ├── WBS Element PROJ-2026-002-DESIGN (Level 2)
          │      Design Phase
          │      │
          │      └── WBS Element PROJ-2026-002-DESIGN-BASIC (Level 3)
          │             Basic Engineering
          │
          └── WBS Element PROJ-2026-002-BUILD (Level 2)
                 Build Phase

1.4 他のマスタデータオブジェクトとの統合#

WBS階層は、PSマスタデータのほぼすべての他のオブジェクトと構造的に結合されています。階層への変更は、コスト集約、予算管理、決済処理に波及します。

第2部: PS固有のフィールド詳細#

2.0 PS オーナーシップの範囲#

凡例: ◎ = オーナー/重要, ○ = 直接関与

2.1 階層構造 (PRHI)#

表PRHIは、WBS階層のリレーショナルバックボーンです。プロジェクト構造におけるすべての親子関係は、1つのPRHIレコードとして表現されます。PSコンサルタントはPRHIを直接編集しません。これはCJ20N、CJ11、CJ12によって管理されますが、その構造を理解することは、階層レポートやカスタムABAPクエリにとって不可欠です。

2.2 WBSレベルと順序（PRPS階層フィールド）#

PRHI に階層構造が保持されていますが、WBS要素テーブル PRPS のいくつかのフィールドは、階層上の位置を直接反映し、制御しています。これらのフィールドは、CJ20N で階層が構築される際に自動的に設定されますが、PSコンサルタントはレポート設計や階層再構築のためにこれらを理解する必要があります。

2.3 勘定設定区分#

各WBS要素の3つの勘定割当インジケータは、プロジェクト階層におけるその役割を決定します。PSコンサルタントは、各階層レベルでこれらを意図的に割り当てる必要があります。誤ったフラグの組み合わせは、本番プロジェクトにおける転記エラーや予算利用可能在庫確認の失敗の主要な根本原因です。

前提条件: 勘定割当要素フラグを使用するには、WBS要素のステータスプロファイル（プロジェクトプロファイルで設定）が勘定割当を許可している必要があります。システムステータスAVAI（勘定割当可能）がアクティブでない場合、フラグが設定されていても転記はブロックされます。

2.4 責任原価センタと利益センタ#

各WBS要素の「責任原価センタ」および「利益センタ」フィールドは、間接費配賦と利益センタ会計の組織上の基点を定義します。S/4HANAでは、これらはもはやオプションではありません。実績値を転記するすべてのWBS要素において利益センタは必須であり、CO原価計算シートによる間接費追加計算には責任原価センタが必要です。

2.5 プロジェクト通貨と管理領域#

プロジェクト通貨と管理領域はプロジェクト定義レベルで定義され、階層内のすべてのWBS要素に継承されます。PSコンサルタントは、これらの継承された値がWBS階層とどのように相互作用するかを理解し、コストレポート作成や期末処理における通貨および領域の不一致を回避する必要があります。

主要な設計判断: プロジェクトが複数の会社コードにまたがる場合（クロスカンパニープロジェクト）、各会社コードは同一の管理領域に属している必要があります。プロジェクト定義の会社コードがプライマリコードとなり、クロスカンパニーの転記は会社間消込勘定を介して決済されます。階層設計を確定する前に、ブループリント段階でFIとともにこれを検証してください。

2.6 決済ルール#

決済ルールは、各WBS要素で収集された原価と収益が期末（通常はトランザクションCJ88またはCJB1経由）にどこへ転送されるかを決定します。WBS階層における要素の位置は、決済順序を直接決定します。すなわち、リーフ要素が最初に決済され、その後サマリ要素が集計された残高を決済します。PSコンサルタントはCJ20NまたはCJ11で決済ルールを定義し、CO/FI-AAは資産会計および原価センタポリシーへの準拠についてルールをレビューします。

前提条件: 決済ルールは、プロジェクトプロファイル（OPSA）で割り当てられた決済プロファイルを参照します。決済プロファイルは、許可される受入者カテゴリと、手動作成または自動作成の必要性を定義します。決済受入者カテゴリが決済プロファイルで許可されていない場合、ルールを保存することはできません。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction