文章详情
以下为资讯详情页模板：正文区域由后台内容渲染，图片与正文将自动替换为对应文章内容。
做 SAP SD 实施这几年合作伙伴确定Partner Determination是我每逢新人培训都必须重点讲的一个功能。很多刚接触 SD 的人第一次在销售订单界面看到“售达方、送达方、付款方、收票方”同时出现时会愣住同一个客户为什么要拆成四种身份更常见的现象是明明客户主数据里维护了送达方创建订单时系统却没带出来最后排查半天才发现是合作伙伴确定程序分配错了销售区域。合作伙伴确定本质上回答一个问题当销售前端录入一个“售达方”客户号之后系统凭什么知道货发到哪里、发票开给谁、钱向谁收。这些关系如果靠人工每次复制粘贴既慢又容易错如果靠写死后端逻辑业务一变就崩。SAP 给出的方案是用一套“合作伙伴功能 合作伙伴确定程序 主数据映射”的配置框架让系统在单据创建瞬间自动带出这些角色。这篇文章我会按“业务原理 → 客户主数据 → 核心配置 → 判定逻辑 → 排错实战”的顺序拆开讲清楚适合刚入行的 SD 顾问、负责主数据运维的同事以及想理解订单背后逻辑的财务或运营人员。1. 先用业务语言看一遍一张销售订单上到底坐着哪几个“人”1.1 四个经典角色售达方、送达方、付款方、收票方SAP SD 最基础的合作伙伴角色有四个我先把它们的对照关系列出来这个表后面每段都会用到角色含义一句话描述售达方Sold-to Party下单方、签约客户这个订单跟谁签的送达方Ship-to Party收货方货最终送到哪里付款方Payer实际付钱的一方钱找谁收收票方Bill-to Party接收发票的一方发票开给谁、寄到哪里注意这四种“人”在系统里都不一定是自然人更多时候是“客户编号”或“地址编号”。售达方可以是集团总部送达方可以是某个异地仓库付款方可以是财务共享中心收票方可以是税务开票点。系统并不关心这个编号对应的组织叫什么只关心“这个编号在客户主数据里存了哪些地址和联系人”。在 SAP 标准配置里这四个角色通常有固定编码但在不同项目里顾问可能根据行业习惯调整编码。我见过不少外贸行业客户把“送达方”同时承担了“通知方”的角色也见过快消行业在订单级别增加“门店编码”作为附加伙伴。所以你们项目里的合作伙伴功能代码务必以实际配置为准不要只看教科书里的标准码。1.2 同一个客户为什么要“分裂”成多个伙伴举一个我在某化工集团项目里遇到的真实业务形态。客户方是集团化采购总部在华南负责签合同生产基地在华东负责收货付款统一走总部财务公司发票却要求开给各个基地的税务主体。如果只在客户主数据里建一个客户号“某某化工集团”业务上是没法用的——因为一张订单必须同时满足以上四种身份的记录需求。于是我们必须建出至少四个客户号总部售达方客户号、两个生产基地送达方客户号、财务公司付款方客户号、各税务主体的收票方客户号。然后在售达方的主数据里维护好“这个售达方默认对应哪个送达方、哪个付款方、哪个收票方”。这样销售员创建订单时只需要输入售达方其余三个角色自动填充。这就是合作伙伴确定最大的价值让系统把企业间的“组织关系”沉淀在主数据里而不是让每个销售员去记忆。不只是集团客户贸易商、代工厂、连锁超市、平台电商几乎都会用到这种拆分逻辑。有一次客户问“为什么我们不能在订单上只填一个客户号”我把他们的业务流程图打印出来之后客户自己就明白了。1.3 合作伙伴数据在订单、交货、发票里是怎么存在的我们把视角从业务切回技术。在 SAP 的数据模型里SD 单据销售订单、交货单、发票都会把合作伙伴保存在一张通用表VBPA中。VBPA 的核心字段很直白VBELN单据编号POSNR行项目号其中 0000 表示表头PARVW合作伙伴功能例如售达方、送达方KUNNR客户编号也就是说合作伙伴不是存内存里的临时变量而是随单据持久化的一张标准表。你打开 VA03 能看到订单的“合作伙伴”页签本质上就是从 VBPA 按条件查出来的。交货单有它自己的 VBPA 记录开票凭证同样有自己的 VBPA 记录。这里就引出一个关键认知合作伙伴确定发生在“单据创建”的瞬间一旦保存合作伙伴就作为单据数据的一部分固化下来了。之后用户手动改了订单伙伴系统不会自动同步去修改这个订单对应的交货单伙伴反过来交货单复制自订单时伙伴是按“复制控制规则”生成的。后面我会专门讲这种复制关系导致的坑。所以合作伙伴确定不只是“配置”它直接影响一张单据的完整度、后续发票的抬头、甚至开票科目的自动确定。理解了这一点再看下面的主数据和配置逻辑就不容易迷路。2. 一切从客户主数据开始角色映射与数据来源2.1 客户主数据的三个视图与合作伙伴字段合作伙伴确定能自动执行前提是客户主数据里有值可读。很多项目在配置上没问题最后查出来是主数据没维护到位。客户主数据在经典 ECC 架构里分三个层级视图一般数据视图客户名称、地址、电话、银行信息等跨公司有效。公司代码视图统驭科目、付款条件、催款程序等只在某个公司代码内有效。销售区域视图销售组织、分销渠道、部门组合下的数据包括销售员、定价过程、交货规则还有我们这里要说的合作伙伴功能。合作伙伴在客户主数据的销售区域视图里维护一般可以在 XD02/XD03或 S/4 的 BP 事务的“合作伙伴”页签看到。界面上你会看到一张表伙伴功能如售达方、送达方、付款方、收票方伙伴客户号可能还有自定义的补充字段比如“增强编号”“承接何处”每个售达方主数据下可以维护多个送达方系统允许同一伙伴功能重复多次。这是为了适应一个客户有多个收货地点的业务。你可以在主数据里维护一个“默认送达方”也可以按不同销售区域维护不同送达方。2.2 主数据里的合作伙伴功能如何决定后续文档我直接结合一个模拟过程来讲。假设你在客户主数据里给客户号1001售达方维护了下面几条伙伴记录伙伴功能伙伴客户号售达方1001送达方2001付款方3001收票方1001当你用 VA01 创建销售订单、输入售达方 1001 后系统触发销售订单类型的合作伙伴确定程序。程序第一步通常会处理“售达方”这个号已经由你手工输入接下来的“送达方”步骤会去查售达方 1001 的客户主数据里有没有维护送达方查到 2001就自动带入再查付款方带入 3001收票方没有单独维护就沿用了 1001。这个动作不是写死的而是由配置里“伙伴确定类型”“伙伴确定规则”决定的。主数据只是提供数据来源配置才决定“从哪张表、以什么顺序取值”。开发或运维同事看后台时可以在表KNVP里查询客户主数据的合作伙伴数据。里面同样有KUNNR客户号、PARVW伙伴功能、KUNN2伙伴号这些字段。排查主数据问题的时候直接用 SE16N 看 KNVP 往往比在界面上翻页更快。2.3 从客户到业务伙伴S/4 环境下的延续逻辑S/4 发布之后客户、供应商统一到“业务伙伴BP”模型。原有 XD01 创建客户的目录可能被BP事务取代但底层仍然需要把 BP 角色映射到“客户”这个角色。对合作伙伴确定而言逻辑核心没变系统读取的还是客户主数据中合作伙伴功能对应的那些字段只是这些字段在 S/4 界面里嵌套在 BP 的“客户一般数据”视图中。如果项目从 ECC 升级到 S/4实施团队一般会做“CVI 客户供应商集成”把老客户主数据转成 BP。此时一定要检查BP 的角色是否分配正确、SD 合作伙伴功能是否仍然有效映射到 BP 主导数据。有项目在升级后发现订单创建时送达方带不出来后来发现是 S/4 里伙伴角色没有勾选“能力分配”里的 SD 相关角色。这种问题不在合作伙伴程序配置而在 BP 主数据的主数据模型。因此我的建议是无论是 ECC 还是 S/4先把客户主数据合作伙伴页签看成“源头抽屉”配置看成“取货规则”。源头没货规则再对也没用。3. 配置合作伙伴确定程序按销售区域和单据类型定制这一节是整个模块的“引擎”部分。我不会把所有菜单截图贴出来每个 ERP 版本界面略有不同但会把逻辑步骤和每个配置节点“为什么存在”讲清楚照着 SPRO 菜单找到对应节点就能配。配置路径大致如下不同版本略有层级差异销售与分销SD → 基本功能 → 合作伙伴确定 → 设置合作伙伴确定3.1 定义合作伙伴功能名称、类型与可重复性第一步是维护一张“合作伙伴功能”码表。这里要定义的不只是四个基本角色而是这个企业可能用到的所有伙伴维度合作伙伴功能一般是一到两位字符的内部编码例如 AE 表示售达方、WE 表示送达方、RG 表示付款方。名称给这个伙伴功能起个业务名字比如“外部销售代表”“收货联系人”。合作伙伴类型可以是客户、供应商、联系人、用户。这决定了系统从哪类主数据里去取值。普通订单伙伴基本都用“客户”。可重复性这个角色在文档上允许多行吗比如一张订单允许有 10 个送达方那么这个伙伴功能就允许重复。客户主数据字段映射指定该伙伴功能在客户主数据里对应哪个字段用于后续从 KNVP 取值。这一步看起来简单但我见过不少项目在“合作伙伴类型”上翻车。比如把某个联系人角色配成了“用户”类型结果主数据里维护的是客户系统永远取不到。配置项目实操中我倾向于把码表分成三组公司级必用角色售达方、送达方、付款方、收票方、行业扩展角色联系人、通知方、承运商、销售代表、项目自定义角色如门店编码、电商平台仓。分类清楚后后面定义程序时才不会两百多行全是杂乱功能。3.2 创建合作伙伴确定程序角色顺序与自动确定开关第二步是定义“合作伙伴确定程序”。程序不是什么复杂代码而是一张有序的角色清单。我给客户培训时常说程序就是你交代给系统的一张“自动填表顺序表”。举个例子一个标准销售订单使用的程序可以长这样步骤号合作伙伴功能必输伙伴确定类型说明10售达方是手工输入订单创建时前端必须输入20送达方否客户主数据从售达方主数据自动带出30付款方否客户主数据从售达方主数据自动带出40收票方否客户主数据从售达方主数据自动带出50联系人否手工输入可选订单级别联系人关键是“伙伴确定类型”这一列常见取值有手工输入前端必需或可手工录入系统不自动带出。客户主数据系统根据某个已确定的伙伴通常是售达方的主数据读取对应伙伴号。组织单位从销售组织、分销渠道、部门等组织数据中取值比如“销售办事处”。不处理该程序步骤只占位或仅作记录不触发确定逻辑。顺序也很讲究。售达方步骤必须排在前面因为后面的角色都要以它为源头取数。如果遇到“先输入送达方再反查售达方”的特例业务那就需要等到后面的逻辑关系而不是绝对要求售达方第一。我实际操作中会建议顾问不轻易改顺序改一次等于重排一遍业务验证用例。3.3 分配程序销售区域 单据类型的组合逻辑定义了程序还不够系统得知道哪种销售区域、哪种单据类型用哪个程序。分配节点一般有两个入口分配合作伙伴确定程序给销售区域比如“销售组织 1000 分销渠道 10 部门 00”统一使用程序 “STANDARD”。分配合作伙伴确定程序给单据类型比如销售订单类型OR用程序 A交货单类型LF用程序 B开票凭证类型RE用程序 C。分配优先级上单据类型的分配覆盖销售区域的分配。也就是说如果销售区域默认程序是 A但某个单据类型明确指定了程序 B该单据创建时使用 B。举实际例子某企业外销订单的付款方是集团离岸公司内销订单的付款方是本地客户两个场景的伙伴角色序列不一样。这时候可以在同一条销售区域内配两种单据类型分别挂不同合作伙伴程序也可以在单据类型层面区分。我偏向用“销售区域分配做兜底单据类型分配做差异化”这样维护量少也容易跟权限设计对齐。还有一个容易漏的点交货单和开票凭证分别有自己的程序。不要以为销售订单配好了就万事大吉。交货单里的送达方可能还需要按“装运点”重新确定开票凭证里的收票方可能因付款条款不同而改变。只要这类业务要求存在就得给目标单据类型也配程序。4. 判定顺序与优先级主数据、组织数据、手工录入谁说了算4.1 三种数据来源的优先级设计合作伙伴确定真正执行时本质是“某个伙伴功能应该从哪个数据源获取”。数据源不是只有主数据一种实际配置里可能组合使用。这里我用“取值优先级”来讲类似于做采购时的货源优先顺序。假设要确定一个“送达方”的值系统可能按以下顺序尝试前端手工录入的送达方是否存在存在就用它。如果没手工录入按**客户主数据K**里售达方维护的送达方取值。如果主数据里没有再看组织数据O例如销售区域默认的送达方。最后还找不到就报错或留空取决于“必输”设置。这套顺序并不是所有版本都在界面里显式展示。有些配置界面把“数据来源”写成组合列比如 VOPA 中每行伙伴都有“伙伴确定类型”和“伙伴确定规则”。你只要理解系统是按步骤号从上往下逐行处理伙伴一行取值时遵循内置优先级。这也是为什么客户主数据里维护了送达方订单创建时却带不出来的原因之一——可能程序里那行“伙伴确定规则”被改成了“仅手工输入”系统直接从根上放弃了自动取值。4.2 地址确定如何和合作伙伴确定配合很多同事会把“合作伙伴确定”和“地址确定”混为一谈我这里特意分开讲。合作伙伴确定解决的是这个角色是谁哪个客户编号。地址确定解决的是这个角色的主数据里有好几个地址单据上到底写哪条。比如送达方客户号 2001 维护了五个地址分别在华东五个生产基地。订单创建时系统带出了客户号 2001但默认地址地址可能跟你这次发到哪个基地没关系。地址确定有一套独立的配置按“使用用途”来区分比如送达地址交货时使用发票地址开票时使用付款地址催款函打印时使用合作伙伴确定和地址确定的配合方式是伙伴确定先把客户号填进订单然后地址确定再按单据类型和用途从该客户主数据地址清单里选。如果订单需要手工指定送达地址通常勾选“手动地址”或在地址页签选择编号即可。这种分立设计带来的好处是一个客户号可以对应无数个地址主数据不用为每个地址新建客户号坏处是业务用户如果不懂容易误以为“地址老是不对是合作伙伴的问题”结果折腾半天实际上查的是地址确定规则。4.3 一次性客户、多收货点、付款方隔离进阶场景光讲基础不够我把实践中常见的三种复杂场景也带一下。一次性客户很多项目专门建一个“一次性客户”客户号用来承接那些散客、零售、临时收货人的订单。仔细看合作伙伴确定逻辑它并不特殊售达方还是固定的一次性客户号但地址和名称每次由手工录入。关键在于配置上要让“送达方”“付款方”这类角色允许与售达方不同一般可设置为“手工输入”或“客户主数据为空时默认为自己”否则一旦客户主数据没有对应伙伴系统直接报错。多收货点一张销售订单下多个送达方业务上需要拆分开票、分批发货。配置上要把“送达方”这个伙伴功能设置为“可重复”。创建订单时可以直接在合作伙伴页签增加多行送达方或在行项目级别分别维护不同送达方。这里还要注意交货单拆分的逻辑否则一张订单多个送达方会变成多个交货单对后面的运输计划影响巨大。付款方隔离集团内两个子公司互相下单不希望系统自动把对方的付款方带过来而是要各自走独立收款主体。这种场景往往不是改伙伴程序而是在主数据上做文章售达方的主数据里不维护“付款方”程序里付款方设为“无数据时默认售达方”这样既保证有值可填又不串到集团其他实体。5. 实战复盘最容易出问题的五个场景与排查链路这一节是我自己项目中踩过坑之后的复盘。每个场景我都按“现象 → 排查 → 根因 → 解决”给出来你可以直接照着当检查清单用。5.1 创建订单时送达方带不出来这是反馈率最高的一个问题。现象VA01 输入售达方保存订单后“送达方”字段为空。排查步骤先确认该销售订单类型的合作伙伴确定程序用的是哪个去 SPRO 分配“销售区域-单据类型”节点找到该订单类型的程序编号。打开程序检查里面有没有“送达方”这一步骤并且“伙伴确定类型”是否为“客户主数据”。如果配置没问题去客户主数据XD02/XD03确认送达方是否维护在售达方主数据里。直接到后台用 SE16N 查表KNVP输入售达方客户号和销售区域过滤PARVW是送达方的记录。如果 KNVP 有值但订单带不出把程序里那两行伙伴的角色属性截图对比看看是不是PARVW编码写错了。我见过最隐蔽的一个坑程序里那行送达方“伙伴确定类型”配成了“联系人类型”也就是说系统要去联系人主数据里取而不是客户主数据自然永远取不到。5.2 复制单据后合作伙伴被莫名换掉场景用户从一张历史订单复制创建新订单发现“付款方”变成了另一家不是原订单的付款方。排查思路订单复制不是简单整单拷贝而是走“复制控制”。复制控制里定义了合作伙伴数据的处理方式。如果复制控制配置成“使用目标类型合作伙伴程序重新确定”那么系统会根据新单据类型再跑一次合作伙伴程序。这时候如果目标单据类型的程序与原单据不同伙伴自然可能变化。如果配置成“复制源单据伙伴”通常保持原值但要注意某些版本对“必输”伙伴的处理可能重新触发默认值覆盖。有一个经验值得记下来客户验收时不应该只验证“正常从报价单复制到订单”这个路径要把“订单复制到订单”“交货单复制到发票”“寄售补货订单转正常订单”等路径全部过一遍。我见过的坑几乎都出现在不常见的复制路径上。5.3 交货单里的合作伙伴消失现象销售订单伙伴正常但 VL01N 从订单创建交货后交货单伙伴页签一片空白。多数情况是因为目标交货单类型没有分配合作伙伴确定程序或者分配的是一个不含任何步骤的空程序。复制控制里合作伙伴处理方式选了“不复制、不重新确定”。这种情况交货单自然无伙伴。交货单由其他单据类型生成比如从外向交货单、从转储单创建源单本身就没有所需伙伴系统无从取数。解决思路很清晰给交货单类型配好程序然后逐条检查复制控制。如果你业务上确实希望交货单伙伴件沿用订单可以在复制控制里勾选“复制合作伙伴”而不是“重新确定”。这里的“重新确定”反而容易因交货类型的程序与订单不同而产生差异。5.4 手动冲掉默认值带来的后续问题日常操作里业务用户经常会手动修改订单伙伴比如把送达方改成一个临时收货地或者把付款方改成客户指定账户。这类操作本身合法但有一个隐含风险系统不会因为你改了送达方自动反向去联动修正付款方或收票方。合作伙伴程序只在最初创建时或特定复制路径下执行保存后的修改不会被二次联动。实际影响是如果你把售达方 A 的送达方改成客户 D但付款方仍保留为 A 的主数据默认值而客户 D 本身是另一个财体的账户那么订单最终可能把款收到 A 所在的账户上去。好一点的追溯还好坏一点的开票号串账。所以我在用户培训里反复强调输入顺序和业务纪律先输入售达方确认其余伙伴自动带出。再修改需要变更的伙伴。修改后重新看一遍付款方和收票方是否符合本次交易预期。有些项目还设了审批流程订单伙伴与售达方主数据不一致时自动触达风险提示。这个思路很值得借鉴在销售订单抬头层加一个增强校验即可成本不高但能避免大量账务纠纷。5.5 一套快速验证配置是否生效的测试清单每次配置完成或切换后我都会跑一遍下面的清单确保不是“改完看起来没问题、上线后出一堆问题”测试步骤事务/路径检查点预期结果维护售达方主数据XD02 / BP合作伙伴页签维护 4 个角色保存成功无报错创建销售订单VA01输入售达方观察订单伙伴页签送达方、付款方、收票方自动带出修改订单伙伴VA02修改送达方保存成功付款方不受联动影响创建交货单VL01N / VL03N从订单生成交货后查看交货伙伴伙伴页签与复制控制预期一致开发票VF01 / VF03从交货或订单生成发票后查看伙伴收票方符合发票类型程序后台上表校验SE16N 表 VBPA按单据号查询伙伴记录PARVW和KUNNR与界面展示一致这个清单看着简单但每一次配置变更都值得跑一遍。特别是第 4、5 步很多顾问在配置阶段只在销售订单里看到伙伴正常就收工了结果上线后交货、开票环节才爆发问题。6. 写在最后我建议养成的几个配置和运维习惯最后聊几点长期实践下来的个人体会不放电也不绕弯。第一配置前先画业务矩阵。不要急着点 SPRO先把公司所有销售单据类型和销售区域列一张 Excel填清楚“哪种单据、哪种区域、必须有哪些伙伴、自动还是手工”。我一般会画成一张矩阵表行是单据类型列是销售区域单元格里写程序编号。配置时就照着矩阵填填完再交叉复核两次。这个习惯帮我挡住过大部分因“漏配区域”导致的问题。第二主数据号段规划会比想象中更重要。如果客户号段能够体现角色身份比如 1001-1999 是售达方、2001-2999 是送达方、3001-3999 是付款方、4001-4999 是收票方那么排查问题速度极快——打开订单只需看伙伴号就知道大概哪类。这个做法在跨系统集成时尤其方便接口报错日志一看伙伴号段就能判断。第三文档移交时把“程序-销售区域-单据类型”三件套打包归档。合作伙伴确定排错时首先要确认的就是这三张映射关系。我做过一个项目上一任顾问留下大堆配置但没有留下这块映射清单结果每次问“这张订单为什么伙伴不对”都得重新查 SPRO绕了一大圈。第四S/4 升级前一定要复核 BP 角色映射。CVI 集成后客户主数据与 BP 的映射如果少了一个角色那合作伙伴确定就可能在运行时表现异常例如订单上伙伴有值但地址确定不到。这类问题隐蔽度高不容易在功能测试里暴露等数据量一上来才开始跳。上线前专门跑一轮“SD 伙伴功能 ↔ BP 角色”映射审核是值得的。最后再分享一个小技巧怀疑是配置问题但不敢乱动时不要直接改配置先复制一份当前合作伙伴确定程序在复制出的程序上调参数、跑测试订单验证通过后再覆盖正式程序。这个做法既保留了回滚点又不会影响线上数据比我早期直接线上改配置稳妥太多。合作伙伴确定属于“牵一发动全身”的配置慢一点、稳一点才是效率最高的一种做法。特别提醒：考试时间、报名批次等安排如有调整，以河南省应急管理厅及官方考点最新通知为准。
