JinJin48

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

July 19, 2026 · 27 min read

SAP Service Cloud 機能場所

SAP Service Cloudにおける機能場所とは、「サービスまたは保守を必要とするオブジェクトの物理的な場所」であり、このバッチ内のインストールベースや保証と同様に、ワークリストから手動で作成されるサイトレベルのマスタデータレコードです。構造上の特徴は、そのフィールドテンプレートにあります。これは、Registered Productと並ぶ2つの兄弟アイテムエンティティタイプの1つであり（Product Installation Pointとは異なります）、直接的なWarranty_Warranty UUID参照も持ち、さらに3つの親ポインタフィールド（Parent Installed Base UUID、Parent Registered Product UUID、Parent Installation Point UUID）をすべて同時に保持します。つまり、インストールベースの直下、またはその2つの兄弟のいずれかの1階層下に直接ネストでき、固定された階層の一段階に留まるわけではありません。また、専用の「ケース機能場所」サブエンティティを介して、ケースからの直接的なファーストクラス参照も持ちます。この記事では、その柔軟な構造を正確にマッピングし、Feature Scope DescriptionとSetup Guideのフィールドレベルモデル間の実際のドキュメントの矛盾を解決し、ケースルーティングルールとサービスレベル決定が機能場所とまったく関係がないことを確認し、この17記事からなるマスタデータバッチ全体で最もリスクの高い命名の衝突を指摘します。

パート 1: 機能場所 — 中核的概念（全モジュール共通）#

1.1) 機能場所とは#

機能ロケーションは、1つの問いに答えるために存在します。すなわち、保守対象のオブジェクトは正確にどの物理的な場所にあり、その場所にはどのような商取引およびカバレッジのコンテキストが付随するのか、という問いです。SAP Service Cloudは、手動で作成されたレコードでこれに応答します。このレコードは、「ロケーション」オブジェクトとしては異常に豊富なフィールドテンプレート（パーティロール、販売組織データ、直接の保証添付、柔軟な親の選択）を保持しています。常にルートコンテナであるインストールベースとは異なり、機能ロケーションは3つの兄弟アイテムエンティティの1つであり、それぞれが他の2つのいずれか、またはインストールベースに直接アタッチできます。

名前の衝突 — このバッチ全体で最もリスクの高い名前の衝突です。
「機能場所 (Functional Location)」は、SAP Service Cloud 以外の SAP ポートフォリオ全体で最も確立され、広く教えられている概念の一つであり、SAP コンサルティング経験のある読者は、先に もう一方の 意味を知っている可能性が高いです。すなわち、従来の SAP プラント保全 (PM) / カスタマーサービス (CS)、オンプレミスの ECC および S/4HANA における「機能場所」（トランザクション IL01 作成 / IL02 変更 / IH01 構造表示、テーブル IFLOT がバックエンド）です。従来の機能場所は、PM/CS における基礎的な技術オブジェクトであり、企業の保全オブジェクトを構造化する組織単位です。これは明示的に 自己参照かつ階層的 であり、各従来の機能場所は上位の機能場所を持つことができ、複数レベルの構造ツリー（例：プラント → 生産ライン → 機械 → 構成部品）を形成し、そのツリー内の 場所 に設備が設置されます。同じ従来の概念とデータは、従来の SAP CRM サービス（WebClient UI）にも同様に現れ、これは従来、PM/CS の機能場所および設備マスタデータを ERP バックエンドと共有/複製しています。SAP Service Cloud の機能場所は、根本的に異なるオブジェクトです。(a) 自己参照ではありません — その親ポインタフィールドは、インストールベース、登録製品、または製品設置ポイントのみを指し、別の機能場所を指すことは決してありません。また、(b) ケース管理/サービスリクエストのコンテキストにおいて、顧客サイト にある「サービスを必要とするオブジェクトの物理的な場所」を表し、オンプレミスのオブジェクトとはデータベーステーブル、API、設定 UI を一切共有しません。IL01/IFLOT に関する知識がこのオブジェクトにそのまま適用されるとは想定せず、オンプレミス SAP の背景を持つ読者にはこの違いを明確にしてください。

1.2) 親アタッチメントオプション：機能場所をネストできる場所#

機能場所のフィールドテンプレートには、3つすべての親ポインタフィールドが同時に含まれていますが、実際には各レコードに設定されるのは1つだけです。親の選択によって、機能場所が顧客のインストールベースに直接接続されたサイトを表すのか、特定のシリアル化された製品に固有のロケーションを表すのか、あるいはより広範な設置ポイントの下にネストされたロケーションを表すのかが決まります。作成時にこの選択を誤ると、後で単純なフィールド編集ではなくレコードの親変更が必要になり、機能場所作成時に事前設定される顧客/製品コンテキストも変わります。

設計原則: 3つの親ポインタフィールドのうち、実際にはレコードごとに1つだけが設定されます。フィールドテンプレートでは3つすべてが公開されていますが。セットアップガイドの第12章では、機能場所、登録製品、製品設置ポイントを、より広範な「設置ポイント」概念のUIレベルの「カテゴリ」として位置づけており、これは十分に裏付けられたニュアンスです。ただし、これら3つすべてを文字通り同一の基盤テーブルと明示的に等価とする公式な声明は見つかりませんでした。

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

データ階層の具体例（テナントレベル；SAP Service Cloudには、この上位に会社コード/プラントのスコープ設定はありません）

Client (SAP Service Cloud Tenant)
   │
   └── Account "ACC-77410 — Acme Manufacturing K.K." (base customer party role)
          │
          └── Installed Base "IB-40210 — Acme Mfg, Yokohama Plant, Packaging Line 2"
                 │        (ROOT — carries no Parent-* field and no Warranty field of its own)
                 │
                 ├── Functional Location "FL-8801 — Packaging Robot Cell"
                 │        (Parent Installed Base UUID = IB-40210 — nested directly under Installed Base)
                 │        │
                 │        └── ── references ──> Warranty "WTY-10045 — 24-Month Extended Coverage"
                 │                 (Warranty_Warranty UUID + cached Warranty Start/End Date fields —
                 │                  a direct field-level reference, not inherited from Installed Base)
                 │
                 └── Registered Product "RP-90215 — Serial# CNV-2024-118"
                          │        (Parent Installed Base UUID = IB-40210)
                          │
                          └── Functional Location "FL-9040 — Conveyor Drive Access Panel"
                                   (Parent Registered Product UUID = RP-90215 — illustrates that a
                                    Functional Location can nest one level deeper, under a
                                    Registered Product, instead of directly under Installed Base)

Case "CS-500311 — Packaging robot cell offline, no coverage confirmation"
     ── references ──> Functional Location "FL-8801"
          (direct field-level link via the "Case Functional Locations" subentity —
           Functional Location ID field)

設計原則 — 機能場所は固定された階層の段ではなく、柔軟な兄弟アイテムである。 同じ3つのフィールドからなる親ポインタセット（親インストールベースUUID、親登録製品UUID、親設置ポイントUUID）が、登録製品および製品設置ポイントにも存在することが確認されている。これら3つはすべて、フィールドモデルの証拠により互換性のある兄弟アイテムタイプである。ただし、この等価性を直接述べる公式のSAP文章は存在しない。製品設置ポイントとは異なり、機能場所とその兄弟である登録製品は、それぞれ独自の直接的な保証参照（セクション1.4）を持つ。そのため、上記の図では、インストールベースではなく機能場所から保証の矢印が発している。

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

機能場所は単独で存在するわけではありません。これは、インストールベースの下で相互に交換可能な3つのネスティング選択肢の1つであり、直接的な保証のアタッチメントポイント、直接的なケースの参照先、そしてサービスオーダーレベルで文書化されたS/4HANAレプリケーションパスでもあります。読者が当然関連すると思われる2つのオブジェクトとは、まったく関係がありません。

真の直接関係であり、また別の誤解を解く話ではない。 インストールベース自身の記事によると、インストールベースは保証と間接的な関係しか持たず、その関係はインストールベースに含まれる機能場所または登録製品明細を介してのみ成立する。機能場所はその逆である。Warranty_Warranty UUID とキャッシュされた開始日/終了日フィールドが機能場所自身のフィールドテンプレートに直接存在しており、これは登録製品の同一フィールドパターンと同じ構造ファミリーに属する、真の、確認済みの、第一級のリンクである。これを別の非関係の発見として扱ってはならない。これは真の直接的なアタッチメントである。

ドキュメントの矛盾 — FSDは「登録製品」のみを記載しています。 機能範囲説明書の「保証管理」行には「登録製品に適用する保証を定義する」とあり、機能場所については触れられていません。一方、セットアップガイドのフィールドレベルデータモデル（§5.7.9.1 依存関係テーブルおよび§5.7.9.2.1 フィールドテンプレート）では、機能場所に対して Warranty_Warranty UUID / 開始日 / 終了日の各フィールドが明示的かつ具体的に含まれています。FSDは簡潔でマーケティングに近いスコープ記述言語として扱い、網羅的なアタッチメントポイントリストとは見なさないでください。セットアップガイドのフィールドテンプレートの方がより詳細で信頼性の高い情報源です。保証が登録製品にのみ適用されると記載しないでください — それは特に機能場所に関して技術的に不完全になります。

訂正 — 機能場所に品目マスタへの直接参照はありません。
登録品目や品目設置ポイントには Reference Product_Product UUID フィールドが存在しますが、機能場所のフィールドテンプレートには品目マスタを直接参照するフィールドはありません。機能場所の標準的な定義（「品目または登録品目の情報も含む」）は、登録品目の下にネストされた場合に親ポインタリンクを介して到達する情報上の関連付けとして解釈されるべきであり、機能場所レコード自体に品目の外部キーが直接設定されるわけではありません。

迷信を打ち破る — ケースルーティングルールとサービスレベル決定は機能場所を参照しません。 ケースの機能場所がルーティングやSLA割り当てロジックに直接入力されると思い込むのは魅力的ですが、文書化された直接的な関係は見つかりませんでした。ソリューションガイドとセットアップガイドの「ケースルーティング（従業員へ）」「ケースルーティング（チームへ）」「サービスレベル決定」の各設定セクションを全文検索した結果、「機能場所」という言及はゼロでした。これらは管理者が設定可能な汎用ルールテーブル（最大15列）であり、ガイドのテキストでは利用可能な列が列挙されていないため、これは文書化された参照がないことの確認であり、技術的に不可能であるという主張ではありません。拡張機能の「動的プロパティルール」と「カスタムロジック」でサポートされるエンティティリストには機能場所が含まれており、標準の標準的なルーティング/SLA参照は存在しないものの、カスタムシナリオが技術的に可能であることを示唆しています。

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

2.0) SC所有権の範囲#

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

2.1) 基本識別情報 & ステータス#

これらのフィールドは、この機能場所とその有効期間を確定します。これらが設定されて初めて、以下のすべてのパーティロール、アドレス、参照フィールドが意味を持ちます。

2.2) 顧客および取引先ロール#

これらのフィールドは、機能場所を正しい顧客に対応付け、さらにビジネス上必要な場合には、インストールベースですでに確認されている同一の5ロールパターンを使用して、個別の所有者、支払者、または納入先を対応付けます。

2.3) 住所と位置情報#

これらのフィールドは、物理的な現場そのもの、つまり、この機能場所に直接ケースが起票された場合にフィールドテクニシャンが派遣される場所を記録します。

2.4) サービス割当#

これらのフィールドは、ケースまたはサービスオーダーがサイトに対して起票された際に、誰がそのサイトに対して責任を持つかを決定します。これらの設定を誤ると、ケースルーティングルールの設定が評価される前（機能場所自体は、これらのルールへの文書化された入力項目ではありません — セクション1.4を参照）に、作業が誤ったチームにルーティングされてしまいます。

2.5) 保証参照#

これらの3つのフィールドは、機能場所を保証に直接結びつける実際のメカニズムです。これらを入力すること（単にカバーされたインストールベースの下にネストするのではなく）が、紐付けを作成します。

2.6) 親添付ファイル項目#

これらの3つのフィールドは、セクション1.2の柔軟なネスティングモデルを実現するメカニズムです。実際には、任意の機能場所レコードにおいて、これらのうち1つだけが入力されます。

前提条件: 機能場所が、インストールベース直下ではなく、登録製品または製品設置ポイントの子として実際に作成される専用の実例は見つかりませんでした。この柔軟性はフィールドモデルで確認されていますが、UIのステップバイステップのチュートリアルとしては文書化されていません。機能場所が完全に「親なし」（3つのフィールドすべてが空）で存在できるかどうかについても、いずれのガイドでも明示的に対処されていません。実装時には、どちらかに断言するのではなく、未解決の質問としてフラグを立ててください。

2.7) 販売管理#

これらのフィールドは、機能場所を標準のSD組織構造に結び付けます。このオブジェクトにおける特定のビジネス上の意味に関する専用の設定手順は、いずれのガイドにも見つかりませんでした。そのため、このセクションはフィールドレベルの参考情報としてのみ扱ってください。

2.8) ケース連携（ケース機能場所サブエンティティ）#

これらの2つのフィールドは、機能場所自体ではなく、リレーションシップのケース側に存在します。しかし、これらはケースに機能場所への直接的かつ第一級の参照を提供する実際のメカニズムであるため、本記事のフィールドレベルの範囲に含まれます。

前提条件: このサブエンティティは、確定済みの「ケース設置ベース」「ケース登録製品」「ケース製品設置ポイント」の各サブエンティティと構造的に同一の形式です。これら4つの品目/コンテナタイプはすべて、それぞれ独自のケース直接結合サブエンティティを持ち、ケースにリンクするために他のオブジェクトを経由する必要はありません。

2.9) 作業区とアクセス制御#

このバッチ内の他のマスタデータオブジェクトと同様に、機能場所ワークリストへのアクセスは、機能場所レコード自体のフィールドではなく、ビジネスロール割当によって完全に管理されます。ただし、機能場所は2つの異なるUIアプリを公開している点が特筆されます。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction