JinJin48

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

July 8, 2026 · 12 min read

SAP Fieldglass ビジネスユニット

ビジネスユニットは、SAP Fieldglassの会社構造におけるコストおよびレポート作成の組織ディメンションであり、テナントレベルのマスタデータで、サイトとは独立しています。これは、財務レポート、総勘定元帳転記、および下流の原価センタ配分のために、調達活動をグループ化します。物理的な作業場所を固定するサイトとは異なり、ビジネスユニットは別の質問に答えます。つまり、この作業に対して組織のどの部門が支払いとレポートを行っているかです。また、ビジネスユニットは独自の階層を持つ唯一の会社構造オブジェクトでもあります。ビジネスユニットは親ビジネスユニットの下にネストして、サイトやロケーションの編成方法とは独立したロールアップレポートツリーを構築できます。この記事では、すべてのFieldglass機能領域にわたるビジネスユニットのコアコンセプトをマッピングし（パート1）、次に、管理者がビジネスユニットレコードを作成および保守する際に設定するすべてのフィールドを詳細に説明します（パート2）。

パート 1: 事業領域 — 中核概念（全モジュール共通）#

1.1 ビジネスユニットとは#

ビジネスユニットは、購買依頼を所有する内部の組織またはコスト報告エンティティ（部門、事業部、予算保持グループなど）を表し、作業が物理的に行われる場所とは独立しています。フェーズ1の会社構造設定シーケンスでは、サイトの後に作成されます（新しいビジネスユニットのサイトIDフィールドが参照可能なサイトを必要とするため、サイトが既に存在している必要があります）。ただし、組織的にサイトの下位に位置するわけではありません。ビジネスユニットは独自のテナントレベルのブランチであり、サイトは親ではなく参照フィールドとしてのみ付与されます。

1.2 ビジネスユニットのスコープディメンション#

サイトと同様に、ビジネスユニットには正式な「ビジネスユニットタイプ」フィールドはありません。その影響は、その下で作成されるすべての購買依頼に継承される一連の下流スコープディメンションとして現れます。設計時にビジネスユニット階層を誤ってモデル化すること（例：マルチレベルのコストロールアップであるべきものをフラット化する、またはサイトのロケーションスコープと混同する）は、本番稼働後の総勘定元帳転記およびレポートの手戻りの一般的な原因です。

設計原則: ビジネスユニット階層は、物理的な所在地ではなく、ビジネスが統合支出レポートをどのように表示したいかに基づいてモデル化します。所在地のグループ化はサイトに属し、この2つを混同すると、レポート要件が分岐した時点でどちらかの再設計を余儀なくされます。

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

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

Tenant "WorkingNet" (client-level scope)
│
├── Business Unit "BU-ENG" — Network Engineering  ◄── this article
│      └── Business Unit "BU-NETDESIGN" — Network Design (child of BU-ENG)
│
├── Cost Center "CC-1001" — flat financial-tracking master (not hierarchical)
│
└── Site "SITE-CHI" — Chicago, US
       └── Location "LOC-CHI-01" — Chicago HQ Floor 3

ビジネスユニットはテナントの直下に位置し、サイトおよび原価センタと同階層（兄弟関係）にあります。つまり、ビジネスユニットはサイトや原価センタの内部にネストされておらず、サイトや原価センタもビジネスユニットの内部にネストされていません。ビジネスユニットはこのゾーン内で唯一の階層オブジェクトであり、BU-ENG 配下の BU-NETDESIGN のように子ビジネスユニットを持つことができ、統合レポートのために任意の階層レベルで支出をロールアップできます。一方、原価センタはフラットで非階層的な財務追跡用マスタです。また、サイト独自の階層はロケーションへと下方向に展開され、ビジネスユニットへは展開されません。

2つのオブジェクトは、ビジネスユニットの組織上の子ではありませんが、ビジネスユニットを参照しています。ビジネスユニット自体には、要求元組織を物理的な作業場所に関連付けるためのサイトIDフィールドがあります（これはネストではなく参照フィールドとして表現される割り当てです。セクション1.2を参照）。また、原価センタ（FG-A02-04）は、作成される前に既存のアクティブなビジネスユニットを必要とし、予算のロールアップのために独自のビジネスユニットIDフィールドを介してビジネスユニットを参照します。これも割り当てであり、組織上の子ではありません。サイトも原価センタも、このランドスケープではビジネスユニットの下に描画されていません。なぜなら、どちらもビジネスユニットに含まれていないからです。

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

事業部レコードは単独で存在するものではありません。これは、下流のフェーズ1オブジェクト1つ、自己参照1つ、および外部システム1つがすべて指し示す、コスト報告のアンカーです。

パート 2: FG固有のフィールド詳細#

2.0 FG所有権の範囲#

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

2.1 基本識別とサイト割当#

これらのフィールドは、ビジネスユニットを一意に識別し、子の原価センタや下流の参照を設定する前に、どのサイトとペアリングされるかを確立します。

2.2 階層設定#

これは、ビジネスユニットにサイトやロケーションとは独立した独自のマルチレベル構造を与えるフィールドであり、この方法でモデル化された唯一の会社構造オブジェクトです。

2.3 総勘定元帳勘定と原価配賦#

これらのフィールドは、このビジネスユニットで発生した支出がどのように財務転記されるか、また使用される場合に複数の原価対象にどのように分割されるかを決定します。

前提条件: 事業単位のサイトID割当フィールドに入力するには、事前にサイトが存在している必要があります。また、原価センタ(FG-A02-04)が事業単位を参照するには、事業単位が存在し、かつアクティブである必要があります。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction