在SAP圈子里聊到BP总得分清楚说的是哪一个。有人讲的是神经网络里的反向传播有人讲的是抓包工具但S/4HANA顾问嘴里说的BP是Business Partner业务伙伴主数据。从ECC时代开始做顾问的人第一次打开S/4HANA的BP事务代码时多半会愣一下原来熟悉的XD01创建客户、XK01创建供应商好像都还能用但系统一保存弹出来的却是一个BP号客户号、供应商号也跟着变成了同一个号码。这不是界面调整而是主数据模型层面的变化。这篇文章就把SAP S/4HANA的BP功能从头到尾拆一遍内容包括BP主数据模型、CVI同步、后台配置、日常维护和常见报错排查适合正在做S/4HANA实施、系统升级或主数据运维的FICO、MM、SD顾问也适合刚接触S/4HANA的初学者。1. BP到底解决了什么问题客户、供应商、业务伙伴的一张表1.1 ECC时代的两套主数据S/4HANA里合成了一个人在ECC里客户主数据和供应商主数据是两套独立的数据模型。客户有KNA1、KNB1、KNVV这些表供应商有LFA1、LFB1、LFM1这些表。同样的一个“公司”如果既是我们的客户又是我们的供应商就需要分别在客户、供应商里各建一遍。维护地址得维护两遍银行账号维护两遍等到财务对账的时候还要在两个主数据之间建立映射关系防止应收应付对冲出错。听起来只是笨一点但实际运维中最大的问题在于一致性。地址变化了只改了一边付款条件在供应商侧改了、客户侧没改这种错位在ECC项目里特别常见最后只能靠手工报表比对。S/4HANA把这个模型改了。客户、供应商、联系人、潜在客户这些角色全部统一挂在同一个业务伙伴上。BP是唯一的主数据主体客户主数据只是BP在“客户”这个角色下的业务视图供应商主数据只是BP在“供应商”这个角色下的业务视图。同一个公司如果既是客户又是供应商建一个BP把两个角色都分配上去一套地址、一套银行信息两边共用。以前那种“两套主数据各维护一遍”的工作量从模型设计上就消掉了。1.2 “BP不是改名是模型变了”对业务和IT的双重影响很多从ECC升级上来的企业以为BP只是把客户主数据改名了这个认知在项目里会吃大亏。首先对业务人员来说创建客户、创建供应商的操作习惯会变。原来XD01就是客户、XK01就是供应商清楚得很。现在标准做法是先建BP再在BP上分配角色事务代码XD01、XK01虽然还能用但本质上是给BP套了一个客户/供应商壳界面和字段逻辑都和BP相关配置有关。如果后台的BP角色、字段分组没有配好业务人员打开XD01会看到一堆奇怪的字段还不知道哪些必填。对IT和顾问来说主数据模型变了意味着字段归属变了。原来维护在KNA1上的字段现在可能变成了BP通用数据原来维护在KNB1上的公司代码数据现在挂在BP的客户角色下会计信息里。权限设计也要跟着改给一个人分配BP事务权限他可能同时能改客户和供应商。这在ECC时代是用不同事务代码隔离的在S/4HANA里必须更仔细地配置权限对象和字段级别。从业务场景看一个BP可以既有“客户”角色又有“供应商”角色。这意味着财务在对账、清账时系统能快速识别出“同一个商业伙伴既是客户又是供应商”从而支持应收应付的净额结算、预付款对冲等。很多企业在实现这种“既是客户又是供应商”的对冲前都必须先把BP打通。这是一个很重要的业务价值。同时BP还支持关系模型例如“联系人是某客户的员工”。联系人本身也可以是一个BP。这样销售、市场、客服都可以围绕BP做360度视图而不是分散维护在Excel里。这一点对想做客户主数据治理的企业尤其有用。2. BP主数据结构拆解通用数据、角色数据和那些容易记混的表2.1 通用数据与角色数据哪些字段写在哪一层BP的数据分两层。第一层是通用数据也就是General Data主要存在BUT000这类表里。一个BP只有一个通用数据集包括名称、搜索项、地址、语言、通讯号码、行业、身份属性等。这些数据不依赖业务范围不管这个BP在系统里是客户、是供应商还是既是客户又是供应商通用数据只有一份。第二层是角色数据也叫Role-Specific Data与BP角色绑定。同一个BP可以有多个角色。比如客户角色FLCU00下面的数据包括销售范围数据、开票数据、客户主数据中公司代码相关的会计数据例如统驭科目、付款条款、催款程序等。供应商角色FLVN00下面的数据包括采购组织数据、公司代码数据、采购相关参数等。通用数据改一次所有角色都生效。角色数据则不同比如在中国区的客户角色里维护了“付款条款”这个字段只对这个角色有效不影响BP作为供应商时的付款条款。这种分层对大型集团特别有意义因为你不用因为一个公司在某个区域有特殊开票要求就去动全集团共享的地址和名称。理解这一层关系后再去看BP界面就不会晕。BP界面里“通用数据”页签和“角色”页签承担的责任完全不同日常出了问题先判断是通用层的问题还是角色层的问题能省很多排查时间。2.2 BP编号、客户编号、供应商编号为什么往往完全相同S/4HANA中BP编号是全局主键。大多数项目里客户号、供应商号都会沿用BP编号也就是同一个号。很多刚接触的人会问BP号、客户号、供应商号三者一样吗严格来说它们是不同对象的主键但CVI的设计让它们可以保持一致。系统在创建BP时如果同时分配了客户角色和供应商角色会根据后台配置自动生成对应的客户主数据和供应商主数据编号与BP编号一致。这样做的好处是从外部看到的客户号、供应商号没有变内部查询时可以非常容易地通过BP号关联到两个视图。如果历史数据是从ECC迁移过来的客户号和供应商号可能长得不一样那么CVI会建立一个映射关系把BP与旧客户、旧供应商联系起来。这时不要随便修改BP编号否则会破坏映射财务单据、采购单据里的号码都会对不上。我在项目里见过有人为了“让客户号从100开始”去改BP外部编号结果历史未清项、合同、采购订单全乱了最后只能靠开发报表去补映射教训很深。2.3 常用的BP表KNA1、LFA1它们之间是什么关系在S/4HANA数据库里并没有把KNA1、KNB1、LFA1、LFB1这些表删掉。它们还在只是数据来源变了。BP相关的主要表包括BUT000BP的通用数据主表。BUT001记录BP分配了哪些角色。BUT020BP地址。KNA1客户主数据常规数据表内容大部分来自BP通用数据但只有“客户视图”独有的字段才在这里维护。KNB1客户主数据公司代码层。LFA1、LFB1对应供应商视图。也就是说你在BP事务代码里维护的数据一部分直接写进BUT类表一部分通过CVI同步写入KNA1、LFA1等客户/供应商表。所以SAP顾问排查问题时不要只看KNA1还要看BUT000两边不一致往往是CVI同步出了问题。排查BP问题时经常需要同时核对BUT000、BUT020、KNA1、LFA1。如果你在BP里改了地址但报表里读KNA1地址还是旧的先查CVI同步队列再看是不是有外围系统直接更新了KNA1绕过了BP。3. 从ECC老主数据切换到BPCVI同步机制与容易踩的坑3.1 CVI到底在同步什么CVI全称Customer-Vendor Integration中文一般叫客户供应商集成。它的作用是把已存在的客户、供应商主数据“回填”到BP并且保持后续的数据同步。在S/4HANA升级项目中常规做法是先做CVI激活再切生产。CVI激活时会扫描所有KNA1、LFA1记录为每个客户/供应商创建BP并把地址、名称、税号、银行信息等字段搬过去。之后客户表和供应商表仍然保留但每当通过BP修改数据时系统会同步写入KNA1、LFA1相反如果客户/供应商侧的字段被修改系统也会通过同步机制反向写回BP。在ECC时代如果你实施过CVI其实已经体会到这套机制了。S/4HANA只是让BP变成了强制路径不再允许“纯客户主数据不带BP”的情况。所以对于还在ECC上、准备后续升级S/4HANA的客户我通常建议提前实施CVI把主数据质量问题在ECC阶段消化掉不要留到切换窗口。很多项目等到升级的时候才大批量清洗主数据时间紧、任务重很容易出纰漏。3.2 老数据切换前必须做的三件事第一查重复。同一个公司既在KNA1有记录、又在LFA1有记录的情况很常见。CVI会为它们各自创建一个BP但业务上这两个BP其实是同一个商业伙伴。如果不对重复记录做合并后续做BP关系、应收应付对冲、信用管理时都会乱。最好在切换前用事务代码或报告找出“同名同地址同税号”的重复客户供应商逐个确认是否合并成一个BP。第二清历史。BP激活过程中历史单据上的主数据编号不能被随意变更。如果CVI需要把客户号、供应商号统一成BP号那么所有该客户的历史凭证涉及到的字段会连带更新。此时要特别关注未清项、合同、采购订单、销售订单的引用完整性。SAP标准迁移工具会提醒你哪些对象不一致不要忽略。第三做映射测试。选一批代表性的客户和供应商模拟完整迁移核对BP号、客户号、供应商号、外部编号、地址、税号、银行数据、支付条件是否一致。测试时别只测主数据本身要连销售订单、采购订单、发票过账、清账一起测。很多项目在主数据迁移测试时没问题一跑单据就露馅。3.3 切换后数据一致性检查与补救切换上线后BP和客户/供应商主数据的一致性不会自动百分之百稳定。常见错误包括报表程序直接更新了KNA1或LFA1绕过了BP导致两边不一致。外围系统通过RFC、BAPI、API直接创建客户/供应商但没有正确传递BP信息。权限设置不严有人手工改了KNA1里的字段而BP里的对应字段没有变化。这些长期“带病运行”的数据早晚会在月末关账、发票校验、信用检查时爆雷。我的建议是在项目上线初期每周跑一次CVI一致性检查关注BP地址、客户地址、供应商地址是否一致以及BP角色与账户组是否匹配。发现问题后能用标准CVI同步报告修复的就修复修复不了的再逐条分析。不要图省事直接改数据库一旦改错BP和财务、物料单据的关联会出大问题。4. BP配置核心账户组、字段分组、编号范围一个都不能少4.1 BP角色与账户组决定主数据能用在哪里BP的配置入口在后台IMG → Cross-Application Components → SAP Business Partner。最核心的是三个动作配置BP角色、配置账户组、配置字段分组。BP角色决定了这个BP能承担什么业务范围。标准角色至少有000000通用业务伙伴、FLCU00客户、FLVN00供应商以及FLCU01、FLVN01等扩展角色。一个BP可以同时分配多个角色。比如一个公司既是客户又是供应商就给同一个BP同时分配FLCU00和FLVN00。账户组在S/4HANA里既可以是客户账户组也可以是供应商账户组还可以是纯BP账户组。账户组决定两件事一是编号范围二是字段状态和字段分组。同时账户组还跟角色绑定。比如中国项目的客户账户组可能分为“国内客户”、“国外客户”、“一次性客户”供应商账户组分为“国内供应商”、“国外供应商”、“一次性供应商”这些账户组都要在CVI配置中与BP角色关联。只要后台配置里账户组和角色匹配正确创建BP时才能正确跳出客户/供应商视图。否则系统会提示“账户组与业务伙伴角色不匹配”这就是很多“BP激活失败”的根源之一。项目里遇到过顾问把客户账户组配到供应商角色下面前台创建供应商时一直报错检查了两天才发现是账户组和角色的绑定关系配错了。4.2 字段分组和字段状态让输入界面“干净好用”BP界面上的字段并不是所有都显示显示哪些、必填哪些、只读哪些由字段分组和字段状态控制。配置路径大致是IMG → Cross-Application Components → SAP Business Partner → Business Partners → Basic Settings → Field Grouping and Field Attributes里面可以定义字段分组也就是Field Group再把字段属性设为隐藏、必填、可选、只读。例如地址区域某些国家的地址必填字段不同。税号区域是否需要统一税号、增值税号。银行账号是否必填。联系人信息电话、传真、手机、邮箱哪些必填。行业信息是否显示行业分类。实际项目中我见过很多BP界面难用、不直观的问题十有八九是字段状态没有按业务场景区分要么该隐藏的都显示要么该必填的不必填。特别是“一次性客户”场景如果字段全都必填前台根本没法快速开票。所以配置字段属性前一定要先梳理业务场景而不是照搬标准配置。做字段分组时还有一个容易忽略的点同一个字段在“创建”和“修改”场景下可以设置不同状态。比如创建BP时银行账号必填修改时可以设为只读防止财务数据被随意改动。这种精细控制在ECC的老客户/供应商配置里也存在但到了BP里字段归属变化后很多人就忘了去调结果上线后才发现修改界面也能乱改关键财务字段。4.3 编号范围与外部给号设计不好后面全是坑BP的编号范围控制着BP编号的生成方式。可以内部给号也可以外部给号。在S/4HANA里因为BP号、客户号、供应商号往往要保持一致所以编号范围的分配要特别小心。常见做法是BP编号使用内部给号从某个号段开始例如从1000000开始。客户账户组的编号范围也指向同一个号段。供应商账户组同样指向这个号段。当一个BP同时是客户和供应商时内部给号会生成同一个BP号且客户号、供应商号也沿用这个号。三套编号范围必须允许同一个号否则就会出现“BP号在客户编号范围里不存在”的报错。外部给号适合从旧系统迁移的情况外部系统已经给客户、供应商编好了号迁移时想保留旧编号。这时需要把BP编号范围设为外部给号把客户/供应商的编号范围也设为外部编号。注意外部给号和内部给号不能混用在同一个账户组上否则保存时会报编号冲突。另外S/4HANA里客户号、供应商号、BP号的长度可能不同设置编号范围时一定要确认号段位数一致否则一个10位的BP号映射到8位客户号里直接爆长度错误。5. BP日常维护与报错排查从建BP到“激活失败”的完整链路5.1 标准建BP流程事务代码BP我平时代维时建BP最常用的事务代码就是BP。步骤如下输入事务代码BP回车。在“BP角色”里选择需要分配的角色比如FLCU00客户、FLVN00供应商。如果公司既是客户又是供应商可以两个都勾上。维护通用数据页签标题名称1/名称2搜索项。地址国家、邮编、城市、街道。通讯电话、移动电话、邮箱。语言、VIP标识等。保存前系统会分配BP编号。保存后到客户/供应商视图维护角色数据客户视图销售范围数据、开票数据、公司代码数据、付款条件、统驭科目、催款程序等。供应商视图采购组织数据、公司代码数据、付款条件、统驭科目等。第一次用这个流程的人可能会问为什么我在BP上维护了地址保存前还要去客户视图再填一遍其实地址是BP层面的客户/供应商视图下只需要补业务相关字段。如果你后台配置了“客户账户组要求填统驭科目”那么保存时系统会提示缺统驭科目这就是很多人说的“BP激活失败”最常见的表面现象。5.2 “BP激活失败”的根因排查清单S/4HANA里BP没有单独的激活按钮所谓的“激活失败”大部分发生在“创建BP并保存”或者“修改BP并保存”的阶段。出现报错时先看报错弹窗别急着取消。常见情况见下表报错现象常见根因排查思路BP号不在客户/供应商编号范围中账户组编号范围未包含BP编号段检查BP编号范围和客户/供应商账户组编号范围提示账户组与BP角色不匹配BP角色与账户组绑定关系没配好在BP角色配置里检查账户组分配必填字段缺失如统驭科目、付款条件字段属性配置过严或业务字段没维护补充角色数据或调整字段必填设定地址不完整或国家不存在地址必填字段缺失或国家主数据未配置检查国家、邮编、地区的有效性补充地址信息权限不足PFCG权限对象不完整检查BP相关权限对象及字段级权限BP提示已存在或重复CVI映射重复同一BP对应多个客户/供应商用CVI一致性检查合并或重新链接主数据税号或税务管辖区无效税号类型、税务管辖区配置缺失检查后台税号类型和各国税务配置排查顺序我一般从后往前先看权限再看编号范围再看字段状态最后才查CVI数据一致性问题。因为权限和编号范围最快能排除而CVI问题需要动数据最好放到最后确认。每个项目做BP权限时要注意不能再按事务代码一刀切因为事务代码BP一个入口可能同时操作客户和供应商。建议配合权限对象做字段级控制至少要把“允许创建客户角色”“允许创建供应商角色”“允许修改BP通用数据”区分开。否则一个销售助理拿到BP的维护权限理论上就能改供应商付款条件这是很危险的。5.3 BP在MM、SD、FI中的典型联动问题BP不是孤立主数据它和MM、SD、FI之间的联动关系非常重要。MM里创建供应商、修改采购主数据底层就是BP的供应商视图。如果BP的采购组织数据没维护完整采购订单创建时会报“采购组织数据不完整”。这种问题常见于新增采购组织后BP没有同步扩展该采购组织视图。解决方法是回到BP事务代码给该BP分配新的采购组织数据而不是去供应商表里硬插一条记录。SD里创建售达方、送达方底层还是BP。SD通常使用“客户账户组销售范围”共同决定主数据字段如果字段分组没配好销售订单里的合作伙伴功能会缺失。有一个高频场景创建BP时只分配了通用客户角色但销售订单需要“送达方”作为另一个BP结果前台无法选择。这需要在销售范围数据里维护对应的合作伙伴功能把送达方分配出来。FI里过账供应商发票时系统读的是BP供应商视图下的统驭科目和付款条件。很多“MIRO报错”或者“发票过账后无法清账”问题追根溯源常常是BP主数据的供应商会计信息不对。比如供应商的公司代码数据里没有维护统驭科目或者维护成了应付统驭之外的科目过账时系统就会出现科目确定错误。最后说一点个人经验。BP这个功能表面上是个主数据维护入口实际上牵一发动全身。建议任何项目上BP时都先把账户组、编号范围、字段状态这三件事定下来再让业务人员使用。另外不要在系统里随意删除BP哪怕它看起来没有业务单据也要先查历史凭证和CVI映射。主数据模型改起来容易清理起来非常痛苦。