JinJin48

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

July 19, 2026 · 19 min read

SAP Service Cloud 保証

SAP Service Cloud における保証は、意図的に薄いレコードです。作成時には名称と期間のみが入力されますが、このオブジェクトは、機能範囲説明書の1行の要約では完全に捉えきれない、真に双方向のデータモデル内に位置しています。登録製品と機能場所 (SC-A11-02) はそれぞれ、直接的な保証 UUID 参照とキャッシュされた開始日/終了日を保持しており、つまり、これらは保証を指し示しており、その逆ではありません。インストールベース (SC-A11-01) とケースはその参照を一切保持せず、それらが含むか参照する機能場所または登録製品を介してのみ、間接的に保証情報を参照します。この記事では、その参照方向を正確にマッピングし、機能範囲説明書とセットアップガイドのフィールドレベルモデル間の実際のドキュメントの矛盾を解決し、「保証」という単語を使用する3つの無関係なSAPコンセプトにフラグを立て、ケースルーティングルールとサービスレベル決定が保証範囲と全く関係がないことを確認します。

パート 1: 保証 — 基本概念（全モジュール共通）#

1.1) 保証とは#

保証とは、「特定の製品または拠点が、どの期間、どのような名称の補償対象で保護されるのか」という一つの問いに答えるために存在します。SAP Service Cloud は、他のオブジェクトが参照する、小さく独立したレコード（保証）でこれを実現しており、自ら他のオブジェクトに結びつくレコードではありません。保証への直接的なフィールドレベルの参照を持つことが確認されているオブジェクトは、登録製品と機能場所の2つだけです。保証自体は、これらのいずれへの逆参照も保存しません。

名称の衝突 — 「Warranty（保証）」は、SAP内の他の場所で少なくとも3つの無関係なものを意味します。 このオブジェクトは、名称を共有しているだけで、以下とは何の関係もありません。(1) SAP S/4HANA Warranty Claim Management（コンポーネント LO-WTY） — 修理後の顧客からのクレーム処理と仕入先への求償処理を行うFioriアプリ（スコープ項目 63Y / 5HR）。これは財務的な償還プロセスであり、保証範囲を割り当てるオブジェクトではありません。(2) 従来型のオンプレミス SAP Plant Maintenance / EAM における、設備または機能場所の保証サブスクリーン（トランザクション IE02/IL02、スクリーングループ 110 — コミュニティソースで確認済み。ご自身のシステムで検証してください）— この従来のオンプレミス「機能場所」は、SAP Service Cloudのクラウド「機能場所」（SC-A11-02）とは異なる無関係な技術オブジェクトであり、その姉妹記事でも改めて指摘すべき命名上の落とし穴です。(3) 従来型の SAP CRM（オンプレミス） における、クラシックCRMサービスモジュール内の個別の保証オブジェクト。これら3つはすべて、共通の英単語を再利用しているだけの無関係な概念として扱ってください。

1.2) 添付ポイント：保証を実際に割り当てることができる場所#

FSDのマーケティング的な要約では、保証は「登録製品」に適用されると記載されていますが、これはフィールドレベルのインポートテンプレートを確認すると、明らかに不完全な説明です。保証自体に設定可能な「補償タイプ」は存在せず、実際の差異は、特定の保証がどのオブジェクトに実際に結び付けられているかであり、セットアップガイドの依存関係テーブルとフィールドテンプレートから、エンティティごとに一つずつ確認されます。

設計原則 — FSDはスコープの要約であり、データモデルではありません。 フィーチャースコープ記述（FSD）はライセンス目的で法的拘束力を持ちますが、簡潔な一行のマーケティング要約として記述されており、Registered Product（登録製品）のみを記載しています。セットアップガイドのフィールドレベルインポートテンプレートは、システムが実際に保存する内容についてより詳細で信頼性の高い情報源であり、Functional Location（機能場所）が同一の Warranty UUID / 開始日 / 終了日フィールドを持つことを独立して確認しています。「保証は登録製品のみに適用される」という記述は技術的に不完全なものとして扱ってください。本記事では、Functional Location（機能場所）を2つ目の独立して確認されたアタッチメントポイントとして文書化し、いずれかの方向に黙示的に解決するのではなく、その矛盾を明示します。

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

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

Client (SAP Service Cloud Tenant)
   │
   ├── Installed Base "IB-40021 — Acme Manufacturing, Packaging Line 2" (Status: Active, illustrative)
   │        │        (container only — Installed Base carries no Warranty field of its own;
   │        │         it reaches Warranty only indirectly, through the two child objects below)
   │        │
   │        ├── Functional Location "FL-2200 — Packaging Robot Arm"
   │        │        ── references ──> Warranty "WTY-10045 — 24-Month Extended Coverage"
   │        │             (Warranty UUID + cached Warranty Start/End Date fields)
   │        │
   │        └── Registered Product "RP-88231 — Serial# ROB-2024-3390"
   │                 ── references ──> Warranty "WTY-10045 — 24-Month Extended Coverage"
   │                      (Warranty UUID + cached Warranty Start/End Date fields)
   │
   ├── Warranty "WTY-10045 — 24-Month Extended Coverage" (Duration: 24 months)
   │        (own record; only Name + Duration are entered at create — no back-reference
   │         field to Functional Location or Registered Product exists on Warranty itself)
   │
   └── Case "CS-500192 — Robot arm malfunction, no power"
            ── references ──> Registered Product "RP-88231"
                 (Case has no direct Warranty field; warranty visibility reaches the agent
                  only indirectly, through whichever Registered Product or Functional
                  Location the Case references — see Solution Guide Ch. 28)

設計原則 — 参照は製品/ロケーションから保証へと一方向に進み、逆方向には決して進みません。 機能場所と登録製品の両方が、外部キーとして Warranty UUID を保持し、さらに開始日と終了日の独自のキャッシュコピーを持ちます。保証側には、自身が何に紐づいているかのリストは保持されません。つまり、単一の保証レコードは、原則として複数の機能場所や登録製品から参照される可能性があります（多対一の形状）。ただし、本調査のいずれのソースも、UI が実際に一対一の割り当てを強制するかどうかを確認または否定していません。カーディナリティは、方向性が確認されている（製品/ロケーション → 保証）が、網羅的に制限されているわけではないものとして扱ってください。インストールベースは両方の子要素の一段上に位置し、それ自体が参照点になることは決してありません。

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

保証は、他のオブジェクトと正確に2つの方向で関連します。登録製品と機能場所から参照され（インバウンド）、その補償範囲は最終的に外部システムによってサービスオーダーレベルで下流に決定されます（アウトバウンド、情報提供のみ — 保証自体はその決定結果を保存しません）。以下の表は、どの関係がソースされているか、どの関係が非関係として確認されているかを明確に示しています。

迷信を打ち破る — 保証はケースルーティングやSLA割り当ての条件にはなりません。 ケースの保証状況が、どの従業員、チーム、またはサービスレベルにルーティングされるかに影響を与えると考えがちですが、実際にはそうではありません。ケースルーティングルールとサービスレベル決定は、どちらも徹底的に検索（全文検索、設定章全体にわたって）され、「保証」という単語が一切含まれていないことが確認されました。実際の保証範囲の条件ロジックは、すべてサービスオーダーレベルに存在し、SAP S/4HANAへの同期Webhook呼び出しを介して実行されます。SAP Service Cloudは、その外部決定の結果を消費するだけで、ケースまたはケースルーティング設定のどこでも保証範囲を評価することはありません。

適用範囲ノート: (1) 「補償タイプ」の値に関する公式かつ単一の正規リストは見つかりませんでした。保証エンティティ自体のフィールドテンプレートでは、Status と Duration のみが公開されています（UIレベルでは Name/ID/External ID も表示されます）。特定の補償タイプの値セットを公式に確認されたものとして提示しないでください。 (2) 保証作成フォーム自体には、明示的な開始日/終了日の入力フィールドは文書化されていません（Duration のみが入力されます）。登録製品および機能場所に存在するキャッシュされた開始日/終了日フィールドは、これらが設置日/納入日と Duration から計算されていることを示唆していますが、正確な計算ロジックを文書化したソースはありません。特定の計算式を主張しないでください。

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

2.0) SC所有権の範囲#

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

2.1) 保証ヘッダ#

これはスタンドアロンのレコードそのものです。作成時に入力を求められるフィールドよりも、作成後に表示されるフィールドの方が多い、意図的に簡素化された設計となっています。

2.2) 保証外部ID#

大量インポート/エクスポートに使用される子エンティティで、1つの保証を他の外部通信システムにおける1つ以上の識別子にマッピングします。

2.3) 保証説明#

2つ目の子エンティティは、多言語保証テキスト専用です。ヘッダーとは別に保持されるため、1つの保証がその条件を複数の言語で保持できます。

2.4) 添付参照項目（登録製品/機能場所）#

これらの3つのフィールドは、保証自体ではなく、登録製品と機能場所に文書化されています。しかし、これらは保証を実際の製品または場所に結び付ける実際のメカニズムであるため、この記事のフィールドレベルの範囲に属します。

前提条件: これら3つのフィールドを入力することで、実際に登録品目または機能場所に保証が紐付けられます。保証レコード（セクション2.1）を作成するだけでは、それ自体では何にも紐付けられません。

2.5) 作業区 / アクセス制御#

このバッチ内の他のマスタデータオブジェクトと同様に、保証ワークリストへのアクセスは、保証レコード自体のフィールドではなく、ビジネスロール割当を通じて完全に管理されます。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction