一句话理解
供应商主数据记录的是"我们向谁买东西"：名称地址、付款条件、采购组织相关设置。ECC 里用 XK01/XK02/XK03 维护；S/4HANA 里供应商和客户统一为 Business Partner（BP），用事务代码 BP 按"角色"维护——这是 S/4 转型中每个 MM 顾问必须跨过的概念。
实战提示：记住这个对应关系——ECC 的"供应商"= S/4 的"BP + 供应商角色（FLVN01）"。底层数据模型变了，但业务含义没变：还是那个送货、开票、收钱的对象。
ECC vs S/4HANA：供应商主数据对比
| 维度 | ECC | S/4HANA |
|---|---|---|
| 事务代码 | XK01 / XK02 / XK03 | BP（统一） |
| 数据模型 | 供应商主表 LFA1 等 | Business Partner（BUT000 等） |
| 客户/供应商 | 两套独立主数据 | 同一套 BP，按角色区分 |
| 组织级别 | 一般数据 / 公司代码 / 采购组织 | BP 一般数据 + 公司代码角色 + 采购组织角色 |
BP 的核心概念
业务伙伴类别
| 类别 | 说明 |
|---|---|
| Person（个人） | 自然人 |
| Organization（组织） | 公司、机构——供应商通常用这个 |
| Group（一组） | 一组 BP 的集合 |
供应商相关的 BP 角色
| 角色代码 | 说明 |
|---|---|
| FLVN00 | 业务伙伴（通用） |
| FLVN01 | 供应商（采购侧） |
| FLVN02 | 供应商（公司代码层，财务侧） |
一个供应商 BP 通常同时拥有 FLVN01（采购组织视图：采购组、合作伙伴）和 FLVN02（公司代码视图：统驭科目、付款条件）。
组织级别视图（延续 ECC 逻辑）
| 视图层级 | 维护内容 |
|---|---|
| BP 一般数据 | 名称、地址、税号、银行信息 |
| 公司代码视图 | 统驭科目、付款条件、付款方式、冻结标识 |
| 采购组织视图 | 采购组、计划交货时间、确认控制、合作伙伴（订单地址/发票方） |
常见坑：只建了 BP 一般数据、没扩展采购组织视图，就跑去下 PO，系统会报"供应商在采购组织 XXXX 下未维护"。排错第一步永远是：用 BP 打开看角色和组织视图是否完整，而不是怀疑 PO 配置。
关键字段说明
| 字段 | 视图 | 说明 |
|---|---|---|
| 统驭科目（Reconciliation Account） | 公司代码 | 供应商往来的总账统驭科目，由 FI 设定 |
| 付款条件（Payment Terms） | 公司代码 | 如 30 天净额、2% 现金折扣，影响应付账款 |
| 付款方式 | 公司代码 | 支票、电汇等 |
| 采购组 | 采购组织 | 负责该供应商的采购员/组 |
| 计划交货时间 | 采购组织 | 默认交货提前期，会带入 PO |
| 合作伙伴（Partner Functions） | 采购组织 | 订单地址、发票开具方、供货方是否同一主体 |
| 冻结标识 | 公司代码/采购组织 | 冻结后不能下 PO 或不能付款 |
实战操作要点
BP 创建（S/4）：BP → 新建组织 → 选择 BP 类别 → 维护地址 → 添加角色 FLVN01 → 选择采购组织 → 维护采购视图 → 添加角色 FLVN02 → 选择公司代码 → 维护财务视图 → 保存。编号可内配（系统给号）或外配。
XK01 创建（ECC）：逻辑相同，只是界面按"一般/公司代码/采购组织"三段式组织。
实战提示：上线前做一次供应商主数据去重：按税号、名称模糊匹配查重复。重复供应商是应付账款对账的噩梦，付款付错对象追回来极其痛苦。宁可上线前多花一周清洗。
常见问题
Q：一个供应商多个工厂供货，要建多个 BP 吗？
A：不需要。一个 BP 可以扩展到多个采购组织/公司代码。如果是"同一供应商、不同开票主体"，才需要分别建 BP（因为公司代码视图的统驭科目、税号不同）。
Q：ECC 升级到 S/4，供应商主数据要手工重建吗？
A：不需要。S/4 迁移有专门的 BP 转换工具（CVI，Customer Vendor Integration），把 ECC 的供应商/客户主数据同步生成为 BP。但 CVI 的同步方向、编号映射需要在迁移前设计好，这是 S/4 迁移的重点任务之一。
Q：一次性供应商怎么处理？
A：用一次性供应商（One-time Vendor）功能：建一个通用的"一次性供应商"主数据（如 CPD），下 PO 时在"地址"页签手工输入本次的供应商地址。适合零星、小额、不值得建档的采购。
实战经验
- 付款条件是 MM 和 FI 的共同字段：采购谈下来的账期，最终体现在 BP 公司代码视图的付款条件里。MM 顾问要懂它，因为它直接影响 MIRO 发票校验和 F110 自动付款。
- 供应商的"合作伙伴功能"（如下单地址≠发票地址）在跨国采购中很常见，PO 打印、发票校验都依赖它，蓝图阶段就要问清楚业务场景。
- 银行信息（IBAN/账号）变更是高风险操作：建议走审批流程并留痕，实务中这是财务诈骗的高发点。
相关阅读
相关文章
Material Master（物料主数据）
物料主数据是 MM 的地基：视图、组织级别、物料类型、编号范围一次讲清，并给出 MM01/MM02/MM03 的实战操作要点。
Goods Receipt（收货）
MIGO 收货是库存增加的起点：移动类型 101/102/103/105 一次讲清，收货自动记账逻辑，以及收货冲销的实战处理。
Invoice Verification（发票校验）
MIRO 发票校验是 P2P 的收官环节：三单匹配逻辑、价格/数量容差、差异处理，以及发票校验与 FI 自动付款的衔接。
Enterprise Structure（企业结构）
公司代码、工厂、库存地点、采购组织、采购组到底是什么关系？本文讲清 MM 企业结构的核心组织单元、层级关系与实战配置要点。