SAP采购价格确定原理与条件技术四要素详解

简介：本资源是一份面向SAP采购模块初学者与实施顾问的系统性学习文档，聚焦采购价格确定这一核心业务场景，深入解析条件技术在实际配置中的落地逻辑。内容覆盖条件类型（PB00/PB01/PB02）、存取顺序、条件记录与条件表、计算方案、价格确定全流程、有效期与定价日期控制、等级结构及信息记录维护等关键知识点，并通过目录结构可见其分四章展开：从条件技术组成、价格确定机制，到抬头/组条件应用，再到条件维护实操，体系完整、层次清晰。资源为单个Word文档（.doc），大小719KB，轻量易读，适合作为配置参考手册或培训辅助材料。目前已有436人学习下载，读者可直接获取结构化知识框架、典型配置逻辑说明及实务注意事项，快速掌握SAP采购单价配置的底层原理与操作要点。

1. SAP采购价格确定到底是什么：一个超市采购员的“自动比价小账本”

想象你是一家连锁超市的采购员，每天要给全国几十家门店采购纸巾、洗衣液、零食这些日常商品。供应商老王给你发来三份报价：

• 纸巾：买100箱打95折，买500箱打9折，买1000箱打85折；
• 洗衣液：按采购总金额算——满10万减500，满30万减2000；
• 零食：只对A门店有效，B门店不适用，且必须在6月30日前下单才生效。

你不可能每次下单都翻微信聊天记录、查Excel表格、打电话确认折扣规则——更别说还要叠加运费、现金折扣、增值税、不同工厂的供货价差异……这时候，SAP采购价格确定，就是系统替你默默运行的一套「全自动比价小账本」：它不靠人脑记忆，而是用结构化规则（条件类型）、预设查找路径（存取顺序）、分层计算逻辑（计算方案）和带有效期的“电子合同”（条件记录），在你点下“保存采购订单”的0.3秒内，自动从成百上千条价格约定中，精准挑出此刻、此单、此物料、此供应商、此工厂、此交货时间下最该用的那一个价格。

它不是简单的“填个单价”，而是把采购谈判成果（比如“买够500箱纸巾就降3元/箱”）、合同条款（“框架协议有效期至2025年12月31日”）、财务要求（“现金折扣2/10，n/30”）全部翻译成系统能读懂的“机器语言”，让每一次采购都可追溯、可复现、不漏单、不翻车。搞懂它，你就从“凭经验填数字的人”，变成了“能看懂系统为什么这样算、哪里可以调、出错了往哪查”的采购技术操盘手——这才是SAP采购模块里真正值钱的硬功夫。

2. 条件技术四要素：价格确定的“DNA双螺旋”

SAP采购价格确定不是黑匣子，它的底层是一套清晰、可配置、有逻辑的“条件技术”（Condition Technology）。你可以把它理解为价格计算的“DNA双螺旋”：一边是数据载体（条件记录、条件表），一边是运算逻辑（条件类型、存取顺序、计算方案），两者咬合才能驱动整个定价引擎。下面我们就拆开这四根核心支柱，讲透它们各自干什么、怎么配合、为什么缺一不可。

2.1 条件类型：价格世界的“词性标签”

条件类型（Condition Type）是SAP里对所有价格相关要素的“身份定义”。它不存具体数值，只负责回答三个问题：

• 这是什么？（价格？折扣？运费？税？）
• 怎么算？（按百分比？按固定金额？按数量阶梯？）
• 影响方向？（加钱还是减钱？）

提示：PB00不是“价格”，而是“总价”——它代表的是含所有折扣/附加费后的最终应付金额，是采购订单行项目上显示的那个数字。而PB01、RA00这类才是真正的“折扣条件类型”，它们的存在，就是为了在PB00之前被系统找到、计算、扣减。

举个真实例子：
你在维护一张信息记录时输入“纸巾单价10元”，这个10元会被系统自动记为PB00条件类型；
但如果你额外勾选“满500箱减3元/箱”，这个“减3元”就会以RA00（通用折扣）条件类型单独存在，并在计算时从PB00中扣除。
→ 所以PB00是结果，RA00是过程；PB00是主干，RA00是枝叶。没有PB00，系统不知道基准在哪；没有RA00，系统不会主动打折。

再看后台配置关键字段（IMG路径：物料管理 → 采购 → 条件 → 定义价格确定流程 → 定义条件类型）：

• 定价等级（Condition Class）：决定它是“价格类”（如PB00）、“折扣类”（如RA00）还是“运费类”（如FRA1）。系统靠它区分“加钱项”和“减钱项”。
• 计算类型（Calculation Type）：%（百分比）、A（固定金额）、C（按数量）、B（按金额）——选错这里，10%折扣可能变成10元固定减，血泪经验！
• 正/负（Plus/Minus）：直接控制符号。RA00默认是“–”，PB00默认是“+”。如果误把RA00设成“+”，系统会反向加折扣，订单金额越算越大。
• 结构定价（Structure Condition）：勾选后，该条件值不参与后续条件的基数计算（比如运费不基于“折扣后价”，而基于“原价”）。这是控制计算链条的关键开关。

2.2 存取顺序：系统找价格的“导航地图”

存取顺序（Access Sequence）是SAP价格确定里最容易被低估、也最常出问题的环节——它不是“从哪找”，而是“按什么优先级、走哪条路、到哪为止”去找。

打个比方：你要查“某供应商某物料在某工厂的最新单价”，系统不会漫无目的地扫全库。它有一张预设的导航地图（Z002），上面标着：

1. 先查「框架协议项目表（A068）」→ 如果有匹配且在有效期内，立刻用它，停止查找；
2. 没有？再查「合同项目表（A016）」→ 有则用，停；
3. 还没有？查「工厂级信息记录（A017）」→ 有则用，停；
4. 最后查「通用信息记录（A018）」→ 这是兜底项。

注意：图中顺序号35、40、45之间留空，不是bug，是预留“插队位”。比如某天业务说“必须优先查供应商主数据里的全局折扣”，你就能在35和40之间插入新表，不用重排全部序号——这是SAP老工程师留下的生存智慧。

关键配置字段解析：

• 需求（Requirement）：一个ABAP例程编号（如601）。它像一道安检门：只有满足特定条件（比如“采购组织=1000”且“物料组=HALB”），系统才允许进入这张表查找。否则直接跳过。
• 排斥的（Exclusive）：勾选即“一票否决”。一旦某张表查到有效数据，立刻终止整个存取顺序，不再往后查。这是防止“低优先级价格覆盖高优先级价格”的保险栓。
• 必须分配存取顺序：所有带有效期的条件类型（如PB00、RA00）都必须配存取顺序；抬头条件（Header Condition）则严禁分配——因为抬头条件作用于整张单据，不按行项目查表。

2.3 条件记录与条件表：价格数据的“身份证+档案柜”

条件记录（Condition Record）是价格的“实体”，条件表（Condition Table）是它的“分类档案柜”。

• 条件表：定义“用哪些字段组合来唯一标识一条价格”。比如：

  • 表A018（通用信息记录）：供应商 + 物料 + 采购组织 + 信息类别→ 四个字段全匹配，才算同一条记录；
  • 表A068（框架协议项目）：供应商 + 协议号 + 物料 + 工厂→ 多了“协议号”和“工厂”，精度更高，优先级也更高。
    你可以在SE16里打开透明表A018，看到每一行都是这样的结构：应用M（采购）、条件类型PB00、供应商1001、物料MAT-001、采购组织1000、信息类别N（标准）……最后是KNUMH（条件记录号）。

• 条件记录：真正存价格数值的地方。KNUMH就像档案柜里的抽屉编号，系统拿着它去KONP表（时效性条件主表）里找具体内容：

  SELECT KNUMH, KBETR, KPEIN, DATAB, DATBI FROM KONP WHERE KNUMH = '0000123456' AND KSCHL = 'PB00';

  • KBETR：金额（如1000000 = 1000.00元）
  • KPEIN：单位（如1 = 按件，1000 = 按千件）
  • DATAB/DATBI：有效期起止（20240101 → 20241231）

提示：KONP存带有效期的记录（信息记录、框架协议）；KONH存抬头条件（如整单5%折扣）；KONM/KONW存数量/金额阶梯（等级）。它们不是同一张表，不能混查。

2.4 计算方案：价格运算的“菜谱与火候”

计算方案（Calculation Schema）是整个价格确定的“总指挥”，它规定：

• 先算什么，后算什么（步骤Step）；
• 每一步用哪个条件类型（CTYP）；
• 每一步的计算基数是什么（From/To）；
• 哪些必须有，哪些可人工改（Must/Manual）；
• 哪些只统计不参与计算（Statistical）。

标准采购单计算方案RM0000典型结构：

关键逻辑说明：

• 步骤10的PB00是基石：所有后续条件（RA00、FRA1）都默认以它为基数计算（除非显式指定From/To）；
• 步骤40的MWST标为“统计”：它把税额计入凭证打印，但不改变净价，不影响后续SKTO现金折扣的计算基数；
• 步骤20/30/50标“人工”：意味着创建采购订单时，用户可手动覆盖系统自动带出的折扣/运费/现金折扣值；
• “从10到30”：表示SKTO现金折扣的基数 = PB00 – RA00 – FRA1（即税前净价），而不是PB00原始价——这就是业务规则落地的精确表达。

3. 价格确定全流程：从创建订单到生成最终金额的七步推演

价格确定不是“一键生成”，而是一场由系统主导、规则驱动、多层校验的精密推演。它发生在你点击ME21N创建采购订单、输入物料和供应商、按下回车的瞬间。下面以标准采购订单为例，还原这背后完整的七步逻辑链，每一步都对应后台配置的真实节点。

3.1 第一步：锁定计算方案（Pricing Procedure）

系统不猜，只匹配。当你在ME21N输入采购组织1000、供应商VC532667后，SAP立刻执行：

1. 查OVKK表（采购组织方案组分配）→ 得到采购组织1000所属方案组STD；
2. 查OVKJ表（供应商方案组分配）→ 得到供应商VC532667所属方案组VEND-A；
3. 查OVKQ表（方案组组合表）→ 输入STD+VEND-A→ 输出计算方案RM0000。

这就是为什么改一个采购组织的方案组，会影响所有该组织下的订单定价——它锁死了整张单的“计算基因”。

3.2 第二步：加载计算方案结构

系统调出RM0000的完整步骤定义（见2.4节表格），明确知道要依次处理PB00、RA00、FRA1等共7个条件类型。此时，它还只是“知道要算什么”，还没开始算。

3.3 第三步：逐个条件类型执行存取顺序

对每个条件类型，系统启动独立的“寻价引擎”：

• 对PB00：调用其存取顺序Z002→ 按序检查A068、A016、A017、A018等表 → 在A018中找到供应商VC532667+物料MAT-001+采购组织1000的记录 → 取出KBETR=1000000（1000.00元）→ 校验DATAB≤当前日期≤DATBI→ 有效 → 写入凭证行项目PB00值。
• 对RA00：调用其存取顺序（可能是Z003）→ 查供应商主数据折扣表A005→ 找到VC532667的全局折扣2%→ 写入RA00值-20.00（基于PB00的2%）。
• 对FRA1：调用存取顺序Z004→ 查工厂1001的运费表A021→ 找到MAT-001运费50.00→ 写入。

关键细节：如果某条件类型未配置存取顺序（如PBXX），系统不会查找，而是留空或等待人工输入——这就是PBXX和PB00的根本区别。

3.4 第四步：处理等级（Scale）与动态基数

当遇到数量阶梯价时，系统不直接取值，而是实时计算：

• 行项目数量输入600EA；
• 系统查PB00的等级基础=C（按数量），等级类型=A（FROM）；
• 在KONM表中扫描该条件记录的所有等级行：
  • KSTBM=1→KSTBW=99→KBETR=1000000（100~999元）
  • KSTBM=100→KSTBW=999→KBETR=990000（990.00元）
• 因600落在100~999区间，最终PB00取990000。

注意：组条件（Group Condition）会让系统先累加所有行项目数量（如两行各300EA=600EA），再查等级——避免单行不达标而漏享优惠。

3.5 第五步：应用计算方案公式

系统按步骤顺序执行运算：

• 步骤10：PB00 = 990.00
• 步骤20：RA00 = PB00 × 2% = 19.80 → 净价 = 990.00 – 19.80 = 970.20
• 步骤30：FRA1 = 50.00 → 含运费价 = 970.20 + 50.00 = 1020.20
• 步骤40：MWST = 1020.20 × 13% = 132.63（统计，不改变净价）
• 步骤50：SKTO = 970.20 × 2% = 19.40（现金折扣，基于税前净价）

最终凭证显示：

• 总价（PB00）：990.00
• 折扣（RA00）：-19.80
• 运费（FRA1）：+50.00
• 现金折扣（SKTO）：-19.40
• 有效价（Effective Price）：990.00 – 19.80 + 50.00 – 19.40 =1000.80

3.6 第六步：有效期与定价日期校验

全程贯穿时间判断：

• 所有查到的条件记录，必须满足DATAB ≤ 定价日期 ≤ DATBI；
• 定价日期默认=凭证日期，但可在ME21N初始屏幕手动改为交货日期或收货日期；
• 若供应商主数据中维护了定价日期类别02（按交货日期），则系统自动取交货日期校验——这对长周期订单（如设备采购）至关重要。

3.7 第七步：写入凭证并触发后续

价格确定完成后，系统：

• 将所有条件值（PB00、RA00等）写入采购订单抬头/行项目的EKPO/EKKO表；
• 更新订单价格历史（表EKBE），为下次订单提供参考；
• 若启用了信息记录自动更新（OMG1），且本次价格优于现有信息记录，则自动创建新版本信息记录；
• 触发财务过账准备（如FR1运费对应总账科目600100）。

这就是为什么一个采购订单保存后，财务能立刻看到明细分录——价格确定不是孤立步骤，而是业务流与财务流的交汇点。

4. 抬头条件、组条件与项目条件：价格作用范围的“三权分立”

在多行项目采购订单中，价格条件不是“一刀切”，而是按作用范围分权治理：项目条件管单行、组条件管多行、抬头条件管整单。这种设计让SAP能同时支持“单品促销”“整单返点”“按量阶梯”等复杂商务场景。但初学者极易混淆三者边界，导致价格算错、审计难溯。

4.1 项目条件（Item Condition）：单兵作战，各行其价

项目条件作用于采购订单的单个行项目，每个行项目独立计算、独立存储。

• 典型条件类型：PB00（总价）、PB01（净价）、RA00（行项目折扣）；
• 特点：
  • 每行都有自己的PB00值，互不影响；
  • 可设置不同工厂、不同交货日期、不同货币；
  • 等级计算基于本行数量/金额，不跨行累加。

示例：订单含两行：

• 行1：纸巾100箱 → PB00=1000.00，RA00=-20.00（2%）；
• 行2：洗衣液50箱 → PB00=800.00，RA00=-16.00（2%）；
  → 两行折扣互不干扰，即使总采购量达150箱，也不触发“满100箱减5元/箱”的额外优惠。

4.2 组条件（Group Condition）：协同作战，聚沙成塔

组条件将多个行项目视为一个整体，先聚合关键值（数量/金额/重量），再统一计算条件。

• 配置方式：在条件类型定义中勾选Group Condition（图23）；
• 聚合基础：默认按行项目净价（NETWR）加总，也可配置为按数量（MENGE）或体积（VOLUM）；
• 典型场景：
  • “整单采购满10万元返点2%” → 聚合所有行项目净价；
  • “按总重量计运费” → 聚合所有行项目毛重；
  • “数量阶梯价” → 聚合所有行项目数量，突破单行阈值。

示例：订单含两行：

• 行1：纸巾80箱 → 单价100元；
• 行2：纸巾40箱 → 单价100元；
  → 若PB00设为组条件，系统先累加数量80+40=120箱，查等级表得“100~999箱单价99元”，则两行PB00均取99元，而非单行100元。

提示：组条件的聚合发生在凭证保存时，非创建时。所以创建过程中看到的PB00仍是单行值，保存后才刷新为组值——这是新人最常踩的“所见非所得”坑。

4.3 抬头条件（Header Condition）：全局统帅，一令到底

抬头条件作用于整张采购订单所有行项目，值统一、逻辑统一、不拆分。

• 典型条件类型：RB00（整单折扣）、FRB1（整单运费）、SKTO（整单现金折扣）；
• 存储位置：不存于行项目表EKPO，而存于抬头表EKKO的KOMK结构；
• 分配方式：
  • 若为固定金额（如整单减500元）：可平均分摊到每行，或按行项目净价比例分摊；
  • 若为百分比（如整单98折）：直接乘以所有行项目净价总和。

示例：订单含三行，净价合计10,000元：

• 抬头条件RB00=2% → 系统计算10,000 × 2% = 200元；
• 按比例分摊：行1净价4,000元 → 分摊80元；行2净价3,500元 → 分摊70元；行3净价2,500元 → 分摊50元；
  → 最终每行有效价 = 行净价 – 分摊额。

注意：抬头条件不能配置存取顺序（系统报错），因为它不按行项目查表，而是直接读取抬头级条件记录（表KONH）。

4.4 常见误区与易混概念辨析

5. 特殊场景与配置陷阱：那些让采购员半夜改单的“玄学时刻”

再严谨的配置，在真实业务面前也会遇到“计划赶不上变化”的时刻。下面这些特殊场景，是SAP采购价格确定中最容易引发争议、最常被忽略、也最考验配置功底的“玄学地带”。它们不常出现，但一旦触发，轻则价格算错被财务退回，重则供应商索赔——必须提前布防。

5.1 贵金属条件：价格随市波动，系统自动抓取

贵金属（金、银、铂）采购价每日浮动，无法用静态条件记录维护。SAP提供贵重金属条件类型（如PM00），其核心是外挂价格源：

• 后台配置（OMJJ）：为条件类型PM00指定外部价格源（如交易所API、Excel导入模板）；
• 创建采购订单时，系统不查A018，而是实时调用接口获取当日金价；
• 价格自动写入PB00，且带DATAB=DATBI=当日，确保单据价格可追溯。

实战教训：某公司未配置价格源，直接人工输PB00，结果月底金价大涨，供应商拒供。后来强制所有贵金属订单启用PM00，价格源对接上海黄金交易所，再没发生过履约纠纷。

5.2 交货成本：运费、保险、关税，谁承担？怎么算？

交货成本（Delivery Cost）不是简单加一笔钱，而是涉及贸易术语（Incoterms）的责任划分：

• FOB（离岸价）：运费由买方承担 → 条件类型FRA1（运费）应配置为项目条件，按行项目重量/体积计算；
• CIF（到岸价）：运费由卖方承担 →FRA1应设为抬头条件，且不计入采购成本，仅作统计；
• DDP（完税后交货）：关税由买方承担 → 需配置ZTAX（关税）条件类型，关联海关税率表。

关键配置点：

• 在计算方案中，FRA1的From/To必须设为10（PB00），确保运费基于净价计算；
• 若运费按体积计，需在条件类型中设置Condition Base Value为VOLUM，并在计算方案中启用Condition Base公式。

5.3 基于重量/体积的条件：物流成本的精准计量

当运费、仓储费按实际装载量结算时，“按件计价”失效。SAP通过条件基（Condition Base）实现：

• 后台配置（OV32）：为条件类型FRA1指定Condition Base为VOLUM（体积）或BRGEW（毛重）；
• 创建订单时，系统自动读取物料主数据中的VOLUM/BRGEW值；
• 计算：FRA1金额 = 体积 × 单位运费（如0.5m³ × 200元/m³ = 100元）。

注意：物料主数据中VOLUM/BRGEW必须维护准确，否则运费偏差直接传导至采购成本。某公司曾因未维护体积，按件计运费，实际装柜超载被船公司罚款。

5.4 条件排除程序：当“不适用”比“适用”更重要

有时业务规则是“排除法”：比如“此折扣不适用于危险品物料”“此运费不适用于海外仓”。SAP用条件排除程序（Exclusion Procedure）解决：

• 后台配置（OV31）：为存取顺序分配一个排除程序（如EXCL01）；
• 程序逻辑（ABAP）：检查行项目物料组是否=HAZ（危险品），若是则跳过当前条件表；
• 效果：即使A018中有危险品的折扣记录，系统也视而不见。

这是规避合规风险的硬核手段。某化工企业强制所有危险品采购启用EXCL01，彻底杜绝了折扣误用。

5.5 配置陷阱：那些看似合理却致命的错误

6. 什么时候该用这套机制？什么时候该绕开它？

SAP采购价格确定不是万能钥匙，它强大，但也沉重。我见过太多团队把简单问题复杂化：为了一次性采购5个零件，硬生生配了一套含7个条件类型、4级存取顺序、3种等级的计算方案，结果上线后采购员不会用、财务对不上账、审计查三天没理清逻辑。从那以后，我给自己定下铁律：先问业务本质，再选技术路径。下面这张决策表，是我带过的12个采购数字化项目沉淀下来的实战边界。

最后分享一个血泪教训：去年帮某制造企业上线，他们坚持要把“员工内购折扣”也塞进采购价格确定——理由是“都是采购”。结果呢？内购走员工福利系统，价格由HR维护，与采购组织无关；强行配存取顺序，导致采购订单价格被内购折扣污染，财务成本核算全乱。我们花了两周回滚配置，改用独立的福利采购流程，用ZPRC条件类型隔离，才恢复正常。

所以，别迷信“一套配置打天下”。SAP采购价格确定真正的价值，不在于它能堆多复杂的规则，而在于它让你把该标准化的坚决标准化，把该灵活处理的果断剥离出去。当你面对一个新需求，先问自己：这个价格，是否需要被审计追踪？是否需要多部门协同维护？是否会长期复用？如果三个答案都是“是”，那就放心交给条件技术；如果有一个“否”，请先关掉IMG，打开白板，想想更轻量的解法。

希望帮到你。

本文还有配套的精品资源，点击获取