JinJin48

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

July 15, 2026 · 12 min read

SAP FSM パートナー登録

パートナー登録とは、招待された外部企業がパートナー招待を受け入れ、パートナーポータルを通じて自社情報（法的名称、連絡先詳細、契約条件の承諾）を提出した時点で作成されるレコードです。これはパートナーエコシステムチェーン（パートナー招待 → パートナー登録 → クラウドパートナー → パートナーテクニシャン）における2番目のリンクであり、一方向の招待を双方向のデータ交換に変換します。この登録が完了することで、クラウドオーナーはその企業をレビューし、クラウドパートナーとして有効化できるようになります。本記事では、その概念とチェーン内での位置づけ（パート1）、続いてFSM固有のフィールド詳細（パート2）について説明します。

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

1.1 パートナー登録とは#

パートナー登録とは、招待された企業がFSMテナントに対して正式に自社を特定するために記入するセルフサービスの入力フォームであり、招待された側（招待元テナントではなく）がデータを入力する最初のポイントです。概念的には、パートナーエコシステムチェーンの要です。その前（パートナー招待）はテナントが作成し、その後（クラウドパートナー、パートナーテクニシャン）は再びテナントが管理しますが、パートナー登録自体は外部企業が作成します。

1.2 登録ステータスタイプ#

登録は、単一のステップで送信・承認されるわけではありません。パートナー管理者が入力を開始した時点から、クラウドオーナーがそれを完了（クラウドパートナーを作成）するか却下するまでの間に、レビューワークフローを経由します。ステータスを正しく管理することは運用上重要です。不完全な登録が「ドラフト」のまま無期限に放置されると、オンボーディングパイプライン全体が停止します。また、却下された登録は、まだレビュー待ちのものと区別できる必要があります。

設計原則: パートナー登録は、データ入力の負担を実際にそのデータを知っている当事者（招待された会社）に移しつつ、最終承認権限をクラウドオーナーに保持させるために存在します。レコード自体は決して派遣権限を付与せず、アクティブクラウドパートナーに変換された場合にのみ付与されます。

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

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

Client (FSM Tenant)
└── Partner Invitation "INV-001" — invite sent to partner@example.com, Status: Accepted
    └── Partner Registration "REG-001" — company info submitted by XYZ Service Co., Status: Completed
        └── Crowd Partner "CP-001" — XYZ Service Co., Status: Active
            └── Partner Technician "PT-001" — John Doe, works for CP-001
                                                          ── registers skill ──> Skill "SK-ELEC" (Zone C, Electrical Work L3)

パートナー登録は、パートナーエコシステムチェーンの中央に位置し、承認済みパートナー招待の直下、およびその結果生成されるクラウドパートナーの直上にあります。両方の包含リンクは1:1です（1つの招待から正確に1つの登録が生成され、1つの完了した登録から正確に1つのクラウドパートナーが生成されます）。クラウドパートナー → パートナーテクニシャンは1:Nであり、パートナーテクニシャンからスキルへのリンクは、兄弟関係にあるパートナー招待の記事と同様に、クロスゾーンの参照のままで、ネストされた下位ではなくサイド矢印として描かれます。

スコープに関する注意: パートナー招待と同様に、パートナー登録はビジネスパートナー、プラント、または地域に属さず、テナントレベルの自己完結型オンボーディングフローの一部です。組織単位への依存（地域、スキル要件のマッチング）は、チェーンがクラウドパートナーおよびパートナーテクニシャンに到達した時点でのみ考慮されます。

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

パートナー登録は、パートナーエコシステムチェーンの要であり、上流のオブジェクトを1つだけ消費し、下流のオブジェクトを1つだけ生成します。それ自体に他のマスタデータ統合はありません。

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

2.0 FSM 所有権の範囲#

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

2.1 識別と会社情報#

このセクションでは、登録レコード自体とその背後にある企業を特定します。これは、招待状のプレースホルダー「提案された会社名」を、招待された側が提供する正式な値に置き換えるデータです。

2.2 ステータスとレビューワークフロー#

これらのフィールドは、登録のレビュープロセスを駆動します。つまり、誰が、いつ、どのような結果でそれを確認するかを決定します。

2.3 連絡先 & 住所#

これらのフィールドは、クラウドオーナー（および後続の派遣プロセス）が、パートナー企業がアクティブになった後にその企業に連絡を取る方法を確立します。これは、最初の招待時に記録された一回限りの連絡先とは異なります。

2.4 用語とコンプライアンス#

これらのフィールドは、招待された企業が正式に同意した内容と、証拠として提供した内容を記録します。これは、クラウドオーナーが承認前に確認するコンプライアンスの基盤です。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction