目次
この記事のポイント
- SAP S/4HANA ではBP（Business Partner）が取引先マスタの leading object。仕入先も顧客もBPで作る
- 仕入先はBPの役割「FLVN01（仕入先）」で表現する。1つのBPに顧客役割と仕入先役割を同居できる
- 会社コード・購買組織のデータはBPの仕入先役割の中で持つ（従来の3階層の考え方は同じ）
- 旧 XK01／MK01／FK01 は互換トランザクション。オンプレミスでは使えるが、SAPの推奨はBP。Cloud は Fiori アプリが前提
- CVI（Customer/Vendor Integration）が BP と仕入先側の勘定グループ・番号範囲・データを同期する
01WHAT S/4HANAでは BP が「唯一の入口」——取引先の統合モデル
SAP S/4HANA では、顧客マスタ（Customer Master）と仕入先マスタ（Vendor Master）という2つの台帳が、BP（Business Partner／取引先）という1つのオブジェクトに統合されました。SAP Help の「Business Partner Approach」は、「Business Partner is the leading object while creating customer or supplier master data」と明記しています。つまり、仕入先を作るときの正規の入口は BP です。
BPは「取引先そのもの」を表すレコードで、その相手とどんな取引をするかを役割（BP Role）で表します。仕入先なら FLVN01（Supplier）、顧客なら FLCU01（Customer）です。同じ会社が顧客でも仕入先でもある場合、BPは1つで済み、役割を2つ持たせます。ERP時代にあった「顧客コードと仕入先コードが別々で、同じ会社が二重に存在する」状態を解消するのが狙いです。
では、会社コード別の照合勘定や購買組織別の購買グループはどこへ行ったのか。ここは従来と同じ考え方です。BPの一般データに住所・名称を持ち、仕入先役割の中に会社コードデータ（照合勘定・支払条件）と購買組織データ（購買グループ・通貨）を持ちます。つまり「3つの視点」は残っており、入口が BP に変わっただけ、と捉えると理解が早くなります。
| 項目 | ERP（従来） | S/4HANA |
|---|---|---|
| 仕入先の入口 | XK01（作成）／XK02／XK03 | BP（取引先）＋役割 FLVN01 |
| 顧客の入口 | XD01 など | BP＋役割 FLCU01 |
| 同一企業の扱い | 顧客と仕入先で別レコード | 1つのBPに複数役割 |
| 購買だけの登録 | MK01 | BP（仕入先役割）／Fiori の仕入先アプリ |
| 会計だけの登録 | FK01 | BP（仕入先役割の会社コードデータ） |
「XK01はもう使えないの？」——答えは「使えるが、推奨されない」
SAP Help は、BPからも、顧客／仕入先のトランザクションからもマスタを保守できると説明しています。つまりオンプレミスの S/4HANA では XK01・MK01・FK01 は互換トランザクションとして残っており、実行するとCVI経由でBPに反映されます。ただしSAPが leading object と位置づけているのはBPであり、S/4HANA Cloud ではこれらのSAP GUIトランザクションは提供されません。新規設計・移行後はBPを標準にするのが正解です。
02POINTS 前提設定：BPグループ・番号範囲・役割・CVIマッピング
BPで仕入先を登録する前に、押さえる設定は4つです。BPグループ（番号範囲を決める）、番号範囲、役割（FLVN01）、そしてCVI（Customer/Vendor Integration）のマッピングです。
ERP時代の「勘定グループ（OBD3）」と「仕入先の番号範囲（XDN1）」は、S/4HANAでは BP 側のグループ・番号範囲と対応づけて管理します。この対応づけがCVIの役割です。CVIは、取引先勘定グループとBPグループの対応、番号範囲の対応、そして項目レベルの値を同期する仕組みで、BPと仕入先側のデータがずれないようにする土台になります。
設定は主にカスタマイズ（SPRO）で行います。BPの基本設定は「Cross-Application Components ＞ SAP Business Partner」、CVIの設定は「Cross-Application Components ＞ Master Data Synchronization ＞ Customer/Vendor Integration」の配下です。どの画面がどの設定かは、BPグループと取引先勘定グループの対応を1枚の表にしてから作業すると迷いません。
| 設定 | 決めること | ERP時代の対応物 |
|---|---|---|
| BPグループ | BPの区分と番号範囲。項目の必須・非表示も制御 | 勘定グループ（OBD3）に相当 |
| BPの番号範囲 | 内部採番／外部採番と番号ブロック | 仕入先の番号範囲（XDN1）に相当 |
| 役割（FLVN01） | 仕入先としてのデータ区分を有効化 | 「仕入先として使う」宣言に相当 |
| CVIマッピング | 勘定グループ↔BPグループ、番号範囲、項目同期 | ERPには存在しない（統合のための仕組み） |
BPで作ると「仕入先コード」はどうなる？
BPの番号と、購買・会計で使う取引先コードは、採番の設計次第で同じにも別にもできます。CVIのマッピングで番号範囲を対応づけるため、「BP番号＝仕入先コード」にするのか、「既存の仕入先コードを保持してBP番号は別にするのか」を移行前に決めてください。ここが曖昧なまま移行すると、購買文書・請求書・支払履歴の紐付けが崩れ、照会（ME2L など）の結果が現場の感覚と合わなくなります。
03STEP BPで仕入先を登録する——一般・会社コード・購買組織
実際の登録は、BPトランザクション（SAP GUI）またはFioriアプリで行います。クラウドや新UIでは「Manage Supplier Master Data」などのアプリが入口です。ここでは画面構成が共通のBPトランザクションの流れで説明します。
- BPを起動し、役割「FLVN01（仕入先）」を選ぶ——役割は「このBPを仕入先として使う」宣言です。顧客にもなる相手なら、後からFLCU01を追加します
- BPグループを選び、番号を指定する——内部採番なら番号は空欄で構いません。グループは番号範囲と項目制御を決めるため、既存の設計（勘定グループとの対応）を確認します
- 一般データを入力する——名称・検索語・住所・言語・通信情報を登録します。BPの住所は役割をまたいで共通です
- 会社コードデータを入力する——照合勘定・支払条件・与信の要否を設定します。照合勘定は買掛金の統制勘定で、請求書照合・支払の転記先になります
- 購買組織データを入力する——購買グループ・注文通貨・インコタームズ・最小発注数量を設定します。購買グループは発注書の既定値になります
- 保存し、BP照会と仕入先側のビューで確認する——BPの表示と、購買・会計から見える取引先データの両方を確認します。とくに照合勘定と番号の関係は、稼働前に必ず検証してください
| 区分 | 必須になりやすい項目 | 設計のポイント |
|---|---|---|
| 一般 | 名称・検索語・住所・国・言語 | 検索語は「カナ＋英字」など規則を決める。重複登録の防止にも効く |
| 会社コード | 照合勘定・支払条件 | 照合勘定は会社・勘定科目表ごとに決まる。未設定だと請求書照合が止まる |
| 購買組織 | 購買グループ・注文通貨 | 通貨は請求通貨と合わせる。インコタームズは契約条件と整合させる |
BPには「潜在的重複のチェック」がある
BPでは、登録時に名称・住所などの類似から重複候補を提示する仕組み（重複チェック）が用意されています。ERP時代の「同じ会社を顧客と仕入先で二重に作ってしまった」という事故を減らせるのがBP統合の実利です。運用ルールとして「登録前にBP検索で重複確認」を徹底し、可能なら承認フローも組み合わせてください。
04INSIGHT 旧TコードとBPの関係、そして何が変わるか
結論から言えば、新規はBP、既存運用は互換トランザクションという住み分けが実務的です。オンプレミスのS/4HANAでは XK01・MK01・FK01 が残っているため、現場が慣れた画面を使い続けることはできます。ただし、SAPが leading object としているのはBPであり、Cloudでは旧トランザクションが提供されません。将来のUI移行やクラウド化を見据えるなら、BPを標準にするのが安全です。
BP統合で実務が変わるのは、次の3点です。第一に、顧客と仕入先が同じBPになるため、与信・重複・関係性の管理が一本化されます。第二に、番号の設計が移行の成否を分けるため、BP番号と取引先コードの関係を先に決める必要があります。第三に、登録・変更の入口がBPに集約されるため、権限ロールと承認フローをBP前提で組み直す必要があります。
移行時は、既存の顧客・仕入先をすべてBPへ変換することが前提条件です（SAP Help も明記しています）。変換後に「BPはあるが仕入先役割がない」「照合勘定が空」といった不整合が残ると、購買や支払が止まります。移行後の検証は、BPと仕入先側のデータを突き合わせるチェックリストを用意してください。
BPと購買・会計の接続は、購買組織の設計や請求書照合の理解とセットです。購買組織の定義は購買組織・購買グループの定義方法：OX08・OME4の設定手順、請求書照合の会計連携はSAP Proforma Invoiceはなぜ売掛・買掛を作らないのか——F5・F8・F2とMIROを1枚でつなぐ、GR/IRの消し込みは入庫/請求仮勘定（GR/IR）の消し込み方法で整理しています。
ADTでは、S/4HANA移行におけるBP統合を、単なるマスタ移行ではなく「取引先の持ち方・番号体系・権限・承認フロー」の再設計として支援しています。BP番号と取引先コードの設計、CVIのマッピング、移行後の不整合チェックまでを一貫して整えることが、稼働後の手戻りを最も小さくします。
まとめ
- S/4HANAでは BP が取引先マスタの leading object。仕入先も顧客も BP で作る
- 仕入先は BP の役割 FLVN01 で表現。1つのBPに顧客・仕入先の両役割を持てる
- 会社コード（照合勘定・支払条件）と購買組織（購買グループ・通貨）は BP の仕入先役割の中で持つ
- XK01／MK01／FK01 はオンプレミスでは互換トランザクションとして利用可。Cloud では提供されない
- CVI が勘定グループ↔BPグループ・番号範囲・項目値を同期する
- 移行前に「BP番号と取引先コード」の関係を確定させる。既存取引先のBP変換は移行の前提条件
出典・参考
- Business Partner Approach (Customer/Supplier Integration)（SAP Help Portal／SAP Business Partner, S/4HANA 2025 FPS02） https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/74b0b157c81944ffaac6ebc07245b9dc/25b46c8241fd4852bf7876d87bed8fd0.html
- SAP Note 2265093（S4TWL - Business Partner Approach） https://me.sap.com/notes/2265093
- Manage Supplier Master Data（SAP Help Portal／SAP S/4HANA Cloud） https://help.sap.com/docs/SAP_S4HANA_CLOUD/f86dc2eb1f8b48c880a7607213104b27/fdb98c570c9b6b10e10000000a441470.html
- 購買組織・購買グループの定義方法：OX08・OME4の設定手順 https://www.aladdin-techec.com/blog/sap-mm-config-create-purchasing.html
※本記事は上記の公開情報をもとに、アラディンテクノロジー株式会社編集部が独自に整理・考察したものです。内容は執筆時点（2026-10-31）の情報です。考察部分は当社の見解であり、特定の製品・導入を推奨するものではありません。Tコード・設定パスはオンプレミス／Private Editionの標準機能に基づく一般情報で、リリースにより異なる場合があります。
05FAQ よくある質問
XK01・MK01・FK01はもう使えないのですか？
オンプレミスのS/4HANAでは互換トランザクションとして利用でき、実行するとCVI経由でBPに反映されます。ただしSAPはBPを leading object と位置づけており、S/4HANA Cloudでは旧トランザクションは提供されません。新規設計ではBPを標準にしてください。
BP番号と仕入先コードは同じになりますか？
設計次第です。CVIのマッピングで番号範囲を対応づけるため、「BP番号＝仕入先コード」にすることも、既存の仕入先コードを保持してBP番号を別にすることもできます。移行前に決めないと、購買文書・支払履歴の紐付けが崩れます。
顧客と仕入先の両方と取引している会社はどう登録しますか？
1つのBPに両方の役割（FLCU01 と FLVN01）を持たせます。ERP時代のように顧客コードと仕入先コードを別々に作る必要はなく、与信・重複・関係性の管理が一本化されます。
既存の仕入先マスタは移行時にどうなりますか？
S/4HANAへ移行する際は、既存の顧客・仕入先をすべてBPへ変換することが前提条件です（SAP Help「Business Partner Approach」）。変換後は、仕入先役割・照合勘定・番号の対応が正しく入っているかをチェックリストで検証してください。