JinJin48

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

July 16, 2026 · 16 min read

SAP IBP ロケーションマスタ

ロケーションマスタは、SAP IBPのマスタデータタイプであり、供給ネットワーク内のすべての物理的または組織的なノード（プラント、倉庫、保管場所、クロスドック、顧客サイト、仕入先/サプライヤサイト）を、単一の統合オブジェクトのインスタンスとして表します。S/4HANAがプラント、顧客、仕入先を3つの個別のマスタデータオブジェクトとして保持するのに対し、SAP IBPはこれら3つすべてを1つのロケーションレコードに収集して変換し、LocationTypeフィールド（P = プラント、C = 顧客、V = 仕入先/サプライヤ）によってのみ区別します。この記事では、ロケーションレコードとは何か、そのタイプディメンションの仕組み、マスタデータ階層内での位置付け、およびロケーションの作成、編集、削除に使用される「ロケーション管理」アプリのフィールドレベルの詳細について説明します。

第1部: ロケーションマスタ — 基本概念（全モジュール共通）#

1.1 ロケーションマスタとは#

ロケーションレコードはスキーマ定義ではなく、Location マスタデータタイプ（MDT-LOC、IBP-A02-01参照）に準拠した実際のマスタデータインスタンスです。計画モデルが参照する必要があるすべてのプラント、ディストリビューションセンタ、顧客出荷先サイト、または仕入先/サプライヤサイトは、計画レベル、ロケーション製品、またはロケーション供給元関係で使用される前に、ロケーションレコードとして存在している必要があります。ロケーションマスタは、SAP IBPのフェーズ1マスタデータ構築においてオプショナルマスタとして分類されています。これは、計画エリアがロケーション別に計画する場合にのみ必要であり、例えば純粋な製品および顧客需要計画では、必要にならない場合があります。

1.2 ロケーションタイプ#

SAP IBPは、S/4HANAのようにプラント、顧客、仕入先を3つの独立したマスタデータオブジェクトとしてモデル化しません。統合時にこれらすべてを1つのロケーションレコードに収集・変換し、LocationTypeフィールドのみが、特定のロケーションが現実世界でどの役割を果たすかを計画モデルに伝えます。統合モデルを設計する際に、プラント、顧客、仕入先が別々のオブジェクトのままであると想定することは、プロジェクト初期によくある誤解です。なぜなら、下流のすべてのオブジェクト（ロケーション品目、ロケーション供給元、計画レベル）は、この1つのフィールドからタイプ固有の動作を読み取るからです。

設計原則: 顧客-品目情報レコードから生成されたVMI（仕入先管理在庫）ロケーションは、LocationType P で自動的に作成され、C ではありません。統合結果を検証する際は、VMIロケーションを顧客タイプのパターンではなく、プラントタイプの例外として扱ってください。

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

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

Client (SAP IBP tenant / Model)
   │
   ├── Master Data Type "MDT-LOC" — Simple · Location             (Zone A — see IBP-A02-01)
   │      └── Attribute "ATTR-REGION" — Region (NVARCHAR)           (Zone A — see IBP-A02-02)
   │
   └── Location Master (instances, Zone B)
          ├── Location "LOC-JP01" — Tokyo Plant, LocationType P (Plant)
          │      LOC-JP01 ── conforms to ──> MDT-LOC
          └── Location "LOC-JP02" — Osaka DC, LocationType P (Plant, node type DC)
                 LOC-JP02 ── conforms to ──> MDT-LOC

設計原則: ロケーションは、ゾーンAで定義されたMDT-LOCスキーマに準拠する具体的なレコードとしてゾーンB（マスタデータインスタンス）に位置します。これは、すべてのシンプルマスタデータタイプのインスタンスが従う同一のクライアント・テナント関係です（ゾーンAのスキーマレベルの概要については、IBP-A02-01 セクション1.3を参照）。ロケーションIDは3つのロケーションタイプすべてでグローバルに一意である必要があるため、上記のLOC-JP01とLOC-JP02が両方ともプラントタイプであっても、顧客ロケーションとプラントロケーションが同じIDを共有することはできません。ブループリント作成時に、この統合モデルの設計制約にフラグを立ててください。

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

Location Masterは単独で存在するわけではありません。これは、コンシューマ（マスタデータタイプに準拠し、属性を通じてカレンダー/地域の詳細を読み取る）であると同時に、基盤（ロケーションディメンションを必要とするほぼすべての下流の計画オブジェクトがその上に構築される）でもあります。

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

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

![IBPの所有権を示すチェックリスト：ロケーションマスタ設定セクション（識別、基本データ、カレンダー/属性割当、統合マッピング、ダウンストリーム消費）]

凡例: ◎ = オーナー / クリティカル、○ = 直接関与

2.1 一般ロケーション識別とタイプ#

すべてのロケーションレコードは、実際の役割に関係なく、同じ識別フィールドから始まります。これは、Manage Locationsアプリで手動入力する場合でも、S/4HANAからのマスタデータ統合によって自動的に設定される場合でも同様です。

2.2 基本データ#

基本データ項目は、ロケーションをビジネス用語で記述します。統合ロケーションの場合、これらの項目は手動入力ではなく、ソースとなるプラント/顧客/仕入先マスタから収集・変換されます。手動入力は通常、サンドボックスモデルやS/4HANAに対応するものがないロケーションに限定されます。

2.3 カレンダーと属性割当#

ロケーションマスタは、その基本スキーマに専用のカレンダータイプ項目を持ちません。カレンダーと地域グループ化は、どちらもIBP-A02-02ですでに説明されている同じ汎用属性メカニズムを通じて実装されます。本セクションでは、そのメカニズムがロケーションに具体的にどのように適用されるかを相互参照するのみであり、属性設定自体を再説明するものではありません。

2.4 統合とソースシステムマッピング#

ロケーションマスタレコードは、実際には手動入力よりも、S/4HANAからのマスタデータ統合によって作成および最新維持されることが最も多いです。そのため、スコーピングと転送メカニズムを理解することが、ロケーションデータの欠落や古さに関するトラブルシューティングの中心となります。

2.5 下流消費#

作成されたロケーションレコードは、複数の下流計画オブジェクトが参照する再利用可能な構成要素となります。このセクションでは、それらのオブジェクトが何であるかをマッピングし、各オブジェクトのフィールドレベルの詳細は重複して記載しません。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction