1. 课程导入与全景认知
在 SAP ECC 时代，客户、供应商和联系人分别存储在不同的主数据表中，客户用 KNA1/KNVV，供应商用 LFA1/LFM1，联系人也各有独立维护入口。这种"分而治之"的模型在业务简单时运行良好，但当企业需要统一视图、跨系统共享、合规审计时，就会暴露出重复、冲突、难以追溯的问题。SAP S/4HANA 引入业务伙伴（Business Partner，简称 BP）作为统一的主数据载体，把自然人、组织、客户、供应商、联系人等角色收敛到同一个对象上，这是本课程要理解的第一件事。
业务伙伴到底是什么
业务伙伴不是"客户表改名"，而是一个以角色为核心的主数据模型。一个 BP 记录本身只承载通用信息，比如名称、地址、税号、银行账户、通讯方式；它具体是客户还是供应商，取决于挂载了哪些角色。同一个 BP 可以同时拥有"客户"和"供应商"两个角色，也可以只拥有其中一个。角色决定了该 BP 能参与哪些业务流程、能出现在哪些单据里。
理解 BP 的关键在于三层结构：通用数据层（跨角色共享，如名称、地址）、角色层（决定业务身份，如 FLCU01 客户、FLVN01 供应商）、公司代码/销售组织层（决定该角色在具体组织单元下的行为，如付款条件、统驭科目、销售区域）。这三层不是并列的，而是逐层细化的关系。通用数据改一次，所有角色都受影响；公司代码层的数据只对特定组织有效。
为什么需要主数据治理
BP 模型解决了"统一载体"的问题，但没有自动解决"数据质量"的问题。如果录入时名称拼写不一致、税号重复、地址格式混乱，统一模型反而会把错误放大到所有业务流程中。主数据治理的目标可以概括为四个维度：唯一性（一个真实实体只对应一个 BP）、完整性（关键字段如税号、银行账户、付款条件必须齐全）、一致性（跨系统、跨组织的数据口径统一）、可追溯性（谁在什么时候改了哪个字段，有审计记录）。
在 S/4HANA 中，治理不是靠人工检查实现的，而是通过校验规则（如税号格式校验、重复检查）、审批流程（如 BP 创建需经过主数据团队审核）、字段状态控制（哪些字段必填、哪些只读）和变更文档（CDHDR/CDPOS 记录）共同落地。课程后续会逐一展开这些机制。
关键术语速览
在进入后续章节前，先建立几个高频术语的准确理解，避免后续混淆：
- BP 编号：业务伙伴的唯一标识，分为内部给号（系统自动分配）和外部给号（手工指定），编号范围由 BP 分组决定。
- BP 分组：决定编号范围、字段状态和是否允许自然人/组织等，是 BP 创建时的第一道分类。
- 角色：BP 的业务身份标签，如 FLCU01（客户）、FLVN01（供应商），一个 BP 可挂多个角色。
- CVI 链接：Customer-Vendor Integration，S/4HANA 中 BP 与客户/供应商主数据的同步机制，确保 BP 角色数据与传统客户/供应商视图一致。
- MDS：Master Data Synchronization，主数据同步框架，用于 BP 与客户/供应商之间的数据一致性校验与同步。
- 变更文档：记录 BP 字段修改历史的审计表，是治理可追溯性的基础。
课程整体学习路径
本课程共 30 章，按"认知 → 配置 → 操作 → 治理 → 排障"的逻辑推进。前几章建立 BP 模型、编号范围、分组、字段状态等基础认知；中间章节进入实际操作，包括 BP 创建、角色维护、CVI 同步、批量导入；后续章节聚焦治理机制，如重复检查、审批流、变更文档、数据清洗；最后以排障和复盘收尾，覆盖常见错误、同步失败、编号冲突等场景。
一个贯穿课程的示例场景
为了让后续章节有统一的参照对象，这里设定一个示例场景（参数为教学假设，非实测数据）：某制造企业"晨星机械"需要在 S/4HANA 中录入一家新供应商"华远轴承有限公司"。该供应商同时是企业的客户（存在返利结算）。在 BP 模型中，需要创建一个 BP，挂载 FLVN01 和 FLCU01 两个角色，通用数据层录入名称、地址、税号，供应商角色下维护公司代码层的统驭科目和付款条件，客户角色下维护销售组织层的销售区域和定价过程。后续章节会围绕这个场景展开创建、校验、同步和治理操作。
理解了这个场景，就能明白为什么 BP 不是简单的"客户表 + 供应商表合并"——它要求我们在创建之初就想清楚：这个实体在业务中扮演什么角色、在哪些组织下生效、哪些数据共享、哪些数据隔离。这正是主数据治理从"录入"走向"设计"的起点。