简介：本资源是一份面向SAP采购模块初学者与实施顾问的系统性学习文档，聚焦采购价格确定这一核心业务场景，深入解析条件技术在实际配置中的落地逻辑。内容覆盖条件类型（PB00/PB01/PB02）、存取顺序、条件记录与条件表、计算方案、价格确定流程、有效期与定价日期控制、等级结构、信息记录及订单价格历史等关键知识点，并通过目录可见的四章结构（含抬头/组条件、时效性条件维护等进阶内容）实现由原理到实操的完整闭环。资源为单个Word文档（.doc），719KB，结构清晰、术语规范、示例明确，便于对照系统界面理解配置路径与参数含义。目前已有436人学习下载，适合希望夯实SAP MM模块价格主数据基础、提升采购配置能力或备考相关认证的学习者系统研读与实践参考。
1. SAP采购价格确定：不是配几个表就能跑通的黑匣子，而是条件读取顺序、有效期逻辑和计算方案三者咬合的精密齿轮
你有没有遇到过这种场景：在ME21N里创建采购订单，明明信息记录里维护了PB00总价，系统却没自动带出价格，或者带出来的价格明显不对？又或者，改了个折扣条件，结果整张单据的税金、运费全乱了，连小计都对不上？这不是配置漏了字段，也不是权限问题——这是条件技术（Condition Technology）这个SAP底层定价引擎的“时序逻辑”没对齐。它不像普通模块那样点点就通，而是一套由**条件类型（PB00/PBXX/RA00等）、存取顺序（Access Sequence）、条件表（Condition Table）、条件记录（Condition Record）和计算方案（Calculation Schema）**五者严格耦合的决策链。其中任意一环的优先级、有效期范围或计算依赖关系错位，整个价格流就会在后台静默翻车。本文不讲概念复述，只拆解真实项目中高频踩坑的六个核心断点：为什么PB00必须排在PBXX前面？为什么Z002存取顺序里物料信息记录（A018）的顺序号是35而不是1？为什么在ME13里维护的折扣会失效，但在ME21N里又突然生效？所有答案都藏在条件读取的触发时机、有效期匹配规则和计算方案中“从/到”字段的数值绑定逻辑里。适合正在做采购模块上线、价格主数据迁移或后台配置验证的一线ABAP顾问、FICO顾问和采购业务分析师——尤其当你手头正拿着一份4.6C老文档，却要在S/4HANA 2022里复现相同逻辑时，这份笔记就是你的校准尺。
2. 条件类型与存取顺序：PB00为何必须前置、PBXX为何不能配存取顺序？
条件类型不是静态标签，而是动态参与价格计算的“角色卡”。每张卡上写着它能干什么（计算类型）、影响谁（正/负）、怎么算（舍入规则）、是否可人工修改（人工标志），以及最关键的——它能不能被系统自动找到（是否分配存取顺序）。PB00和PBXX这对“双生子”的差异，正是理解整个采购定价逻辑的钥匙。
2.1 PB00与PBXX的本质分工：主价格源 vs 人工兜底值
PB00（Total Price）是系统默认的“主价格条件类型”，它代表的是基于有效历史数据自动推导出的采购总价。这个“有效历史数据”包括：信息记录（Info Record）、框架协议（Contract）、报价（Quotation）中的已维护条件。而PBXX（Manual Net Price）则纯粹是“人工兜底值”——当系统找不到任何有效的PB00条件记录时，才允许用户在采购订单行项目中手动输入一个净价，这个值会被临时挂载到PBXX下。二者在计算方案中的位置绝不能颠倒：
步骤 | CTYP | 描述 | 必须 | 人工 | 从 | 到 -----|------|--------------|------|------|-----|---- 10 | PB00 | 总价 | X | | | 20 | PBXX | 手动净价 | | X | | 30 | RA00 | 现金折扣 | | | 10 | 10提示：如果PBXX排在PB00前面，系统会在第一步就尝试找PBXX，但PBXX根本不存在于任何条件表中（它没有存取顺序），导致整个定价过程在步骤20就中断，后续所有条件（RA00、FRA1等）全部失效。这就是为什么你在ME23N里看到“条件分析”窗口里，PB00后面跟着一串红色叉号的根本原因。
2.2 存取顺序Z002的数字玄学：35不是第35个，而是预留扩展位的“战略空隙”
存取顺序（Access Sequence）是系统读取条件记录的“寻址指令集”。它不决定“用哪个条件”，而决定“先去哪张表找、再去找哪张表”。以Z002为例，其标准配置如下（简化版）：
| 顺序号 | 条件表 | 关键字段组合 | 需求 | 排斥 |
|---|---|---|---|---|
| 10 | A068 | 框架协议项目（工厂相关） | ||
| 20 | A016 | 合同项目 | ||
| 35 | A018 | 物料信息记录（供应商+物料+采购组织） | ✅ | |
| 40 | A025 | 非库存项目信息记录（指定地点） |
这里的关键不是“35”，而是35后面留出的5个空位（35→40）。假设某客户要求新增一个“按供应商等级动态定价”的条件表A999，需要插在A018之后、A025之前。如果原始顺序是35→36，那插入A999就必须把A025的顺序号从36改成37，所有后续条目全要重排——这在生产系统中是灾难性的。而35→40的间隔，让A999可以安全地设为36，完全不影响现有逻辑。更关键的是A018行末的“排斥”勾选：一旦系统在A018中成功读取到一条PB00记录，整个Z002存取顺序立即终止，不再继续扫描A025等后续表。这保证了“信息记录价格”拥有最高优先级，避免被更低优先级的通用条件覆盖。
2.3 条件类型配置实操：等级基础B/C/D与舍入规则的业务映射
在后台路径IMG → 物料管理 → 采购 → 条件 → 定义价格确定流程 → 定义条件类型中，配置PB00时有两大易错参数：
等级基础（Scale Basis）：决定价格阶梯的计量单位。
B（Value）：按采购总金额阶梯（如：满10万打98折，满50万打95折）；C（Quantity）：按采购数量阶梯（如：买1-99个100元/个，买100-999个99元/个）；D/E（Weight/Volume）：按毛重或体积阶梯（适用于物流成本挂钩场景）。
注意：若业务要求“按订单总金额打折”，却误配为
C（数量），系统会把每个行项目的数量单独套用阶梯，导致本该享受大额折扣的整单反而按单行小量计价。舍入规则（Rounding Rule）：
Commercial（商业舍入）：四舍五入到小数点后两位（最常用）；Round up（向上舍入）：0.001→0.01，常用于规避税费临界点；Round down（向下舍入）：0.009→0.00，多见于内部结算避免尾差。
这些参数不是技术开关，而是业务规则的代码化表达。配错一个，下游所有价格单据的金额都会系统性偏移。
3. 条件记录与条件表：KONP/A018透明表结构与跨表关联逻辑
条件记录（Condition Record）是价格数据的实体载体，而条件表（Condition Table）是它的索引目录。二者通过“条件记录号”（Condition Record Number）强关联。理解这个关联，才能诊断“为什么我明明在ME13里维护了价格，ME21N里却不生效”。
3.1 A018条件表：物料信息记录的四维坐标系
A018是采购模块最核心的条件表，其结构定义了“什么条件下能查到PB00价格”。用SE16打开A018，你会看到关键字段：
| 字段名 | 含义 | 示例值 | 是否必填 |
|---|---|---|---|
KNUMH | 条件记录号（主键） | 0000123456 | ✅ |
KUNNR | 供应商编号 | VC532667 | ✅ |
MATNR | 物料编号 | MAT-001 | ✅ |
EKORG | 采购组织 | 1000 | ✅ |
ESOKZ | 信息类别（M=采购） | M | ✅ |
DATBI | 有效期至（YYYYMMDD） | 99991231 | ✅ |
DATAB | 有效期自（YYYYMMDD） | 20230101 | ✅ |
关键逻辑：系统在ME21N中创建订单时，会用当前订单的
供应商+物料+采购组织+信息类别这四个值，去A018中精确匹配。缺一不可。常见翻车点：采购组织填错（如该用1000却用了2000）、信息类别未维护（ESOKZ为空）、或物料编号带前导零（A018中存的是MAT001，而订单里传的是MAT-001）。
3.2 KONP透明表：条件记录的“数据仓库”与时效性存储
A018只是索引，真正的价格数值存在KONP中。KONP的结构揭示了条件记录的完整生命周期：
| 字段名 | 含义 | 示例值 | 说明 |
|---|---|---|---|
KNUMH | 条件记录号（外键，连A018） | 0000123456 | 与A018的KNUMH完全一致 |
KPOSN | 行项目号（空=抬头条件） | PB00通常为空（抬头级） | |
KWERT | 条件金额（单位：本地币） | 10000000 | 实际值=100000.00（除100） |
KRATE | 单价（单位：本地币） | 1000000 | 实际值=10000.00（除100） |
KPEIN | 计价单位数量 | 1 | |
KMEIN | 计价单位 | EA | |
DATBI | 有效期至 | 99991231 | 必须与A018中一致 |
DATAB | 有效期自 | 20230101 | 必须与A018中一致 |
LOEVM | 删除标记（X=已删除） | 软删除，非物理删除 |
血泪经验：KONP中的
KWERT和KRATE字段存储的是“整数放大100倍”的值（即分/美分单位）。如果你用SQL直接查KONP，看到KWERT = 10000000，实际价格是100000.00。很多ABAP报表因忘记除100，导致价格显示错位十倍。此外，LOEVM字段是SAP标准软删除机制——打上X标记后，该记录在前台不可见，但在后台SQL中仍存在，需在SE16中勾选“显示已删除条目”才能看到。
3.3 条件记录的跨表关联：从A018到KONP的完整链路
当系统执行价格确定时，完整的数据流是：
- ME21N获取订单参数：
供应商VC532667 + 物料MAT-001 + 采购组织1000 - 根据Z002存取顺序，查询A018表，匹配
KUNNR=VC532667 AND MATNR=MAT-001 AND EKORG=1000 AND ESOKZ='M' - 找到A018中
KNUMH=0000123456的记录 - 携带
KNUMH=0000123456去KONP表中查询 - 在KONP中找到
KNUMH=0000123456 AND DATBI>=当前日期 AND DATAB<=当前日期的记录 - 提取
KWERT和KRATE，参与后续计算
断点排查口诀：查不到价格？先看A018有没有匹配行；有匹配行但价格不对？再查KONP中对应KNUMH的KWERT值和有效期是否有效。两表任一环节缺失，价格链就断裂。
4. 计算方案与价格确定流程：RM0000如何驱动PB00→RA00→FRA1的计算链条
计算方案（Calculation Schema）是价格确定的“总控程序”，它定义了条件类型的执行顺序、依赖关系和计算逻辑。RM0000（采购单据大）是标准采购订单的默认方案，其设计思想是“先立主干，再添枝叶”——PB00作为基础价格，所有折扣、附加费、运费都必须基于它计算。
4.1 RM0000计算方案的核心字段解析：“从/到”是计算依赖的锚点
在IMG → 物料管理 → 采购 → 条件 → 定义价格确定流程 → 定义计算方案中打开RM0000，重点看以下字段：
| 步骤 | CTYP | 描述 | 从 | 到 | 小计 | 说明 |
|---|---|---|---|---|---|---|
| 10 | PB00 | 总价 | 基础价格，无依赖 | |||
| 20 | RA00 | 现金折扣 | 10 | 10 | ✅ | 从步骤10取值，即用PB00金额计算折扣 |
| 30 | FRA1 | 运费 | 10 | 10 | ✅ | 同样从PB00取值，而非从RA00后的净价 |
| 40 | MWST | 税金 | 10 | 30 | ✅ | 从步骤10到30的小计，即PB00 - RA00 + FRA1 |
关键逻辑：“从/到”字段不是简单的起止步号，而是计算公式的变量声明。
RA00的“从=10”意味着公式为：RA00金额 = PB00金额 × 折扣率；MWST的“从=10, 到=30”意味着公式为：MWST金额 = (PB00 - RA00 + FRA1) × 税率。如果误将RA00的“从”设为20，系统会试图用RA00自身计算RA00，直接报错。
4.2 条件补充计算方案RM0002：为什么ME13里的折扣在ME21N里不生效？
RM0002是“条件补充定价”方案，专用于在信息记录（ME13）、框架协议（ME31K）等主数据中维护补充条件（如RA00折扣、FRA1运费）。它的存在解决了“主价格与补充价格有效期同步”的难题。
RM0002的典型结构：
步骤 | CTYP | 描述 | 必须 | 人工 | 从 | 到 -----|------|----------|------|------|-----|---- 10 | RA00 | 现金折扣 | | | 10 | 10 20 | FRA1 | 运费 | | | 10 | 10注意：RM0002中没有PB00！因为它只负责补充，不负责主价格。
生效逻辑：当在ME13中维护信息记录时，系统会同时调用两个方案：
- 主方案RM0000：确定PB00的值（从A018/KONP读取）
- 补充方案RM0002：确定RA00/FRA1的值（同样从A018/KONP读取，但条件类型不同）
二者共享同一组条件记录（同一
KNUMH），因此PB00、RA00、FRA1的DATAB/DATBI必须完全一致。如果在ME13中只维护了PB00的有效期（20230101-99991231），却忘了给RA00设置相同有效期，那么在ME21N中，PB00能查到，RA00却因有效期不匹配而返回空值，导致折扣失效。
4.3 价格确定的三阶段验证法：从凭证到后台的逐层穿透
当价格异常时，不要直接改配置，按此顺序验证：
前台凭证层（ME23N）：进入采购订单，点击“条件”→“分析”，查看“条件分析”窗口。这里会清晰列出：
- 每个条件类型（PB00、RA00）的来源（如“A018: Info Record”）
- 实际读取的条件记录号（KNUMH）
- 读取状态（绿色√=成功，红色×=失败，黄色! =跳过）
主数据层（ME13/ME31K）：根据“条件分析”中显示的
KNUMH，在ME13中打开对应信息记录，切换到“条件”标签页，确认RA00等补充条件是否存在且有效期正确。后台数据层（SE16）：若前台显示“条件分析”中PB00来源是A018，但金额不对，则：
- 用
KNUMH查A018，确认KUNNR/MATNR/EKORG/ESOKZ是否匹配订单参数； - 用同一
KNUMH查KONP，确认KWERT值和DATAB/DATBI是否在有效期内。
- 用
这三层验证，能90%定位价格问题根源，避免盲目调整后台配置。
5. 避坑指南：采购价格确定中五个高频翻车现场与根治方案
价格确定是SAP采购模块最易出问题的环节，表面看是配置错误，深层往往是业务规则与系统逻辑的错位。以下是我在多个项目中亲手踩过的坑，附带可立即执行的根治方案。
5.1 现象：信息记录中维护了PB00和RA00，但采购订单里只带出PB00，RA00为空
原因：RA00条件类型未分配到RM0002计算方案，或RM0002中RA00的“必须”标志未勾选，导致系统认为该条件可选，即使存在也不强制读取。
解决：
- 进入
IMG → 定义计算方案 → RM0002，找到RA00行； - 勾选“必须”（Required）字段；
- 确保RA00的“从”字段指向PB00所在步骤（通常是10）；
- 关键动作：在ME13中重新保存信息记录，触发条件记录的重新生成（KONP表更新）。
5.2 现象：采购订单价格正确，但打印输出的PDF中折扣金额显示为0
原因：“打印”（Print）标志未在计算方案中为RA00启用，导致该条件值不传递给输出模块。
解决：
- 在RM0000或RM0002中找到RA00行；
- 勾选“打印”（Print）字段；
- 验证方法：在ME23N中点击“条件”→“分析”，查看RA00行末的“打印”列是否为✓。
5.3 现象：按数量阶梯定价（等级基础C）时，两个行项目各80EA，系统未按160EA的阶梯计算
原因：条件类型未设置为“组条件”（Group Condition），导致系统对每个行项目单独应用阶梯，而非累加后统一计算。
解决：
- 进入
IMG → 定义条件类型 → RA00； - 在“控制数据”（Control Data）页签中，勾选“组条件”（Group Condition）；
- 同步操作：在RM0000计算方案中，为RA00行设置“条件基”（Condition Base Value）为
10（即PB00），确保累加基础正确。
5.4 现象：修改信息记录中的PB00价格后，旧采购订单的价格历史（Order Price History）未更新
原因：订单价格历史（OPH）只在采购订单保存时快照一次价格，后续主数据变更不会反向刷新历史。
解决：
- 业务层面：明确告知用户，OPH是“下单时刻”的价格快照，非实时视图；
- 技术层面：如需追溯，使用事务码
MEKA查看“采购订单价格历史”，它独立于信息记录，数据源为EKPO表的NETPR字段； - 规避方案：在创建订单前，务必确认信息记录价格已生效，避免依赖OPH做价格比对。
5.5 现象：S/4HANA中使用新Fiori应用创建采购订单，PB00价格不带出，但GUI版（ME21N）正常
原因：Fiori应用默认使用“新式定价”（New Pricing），其存取顺序逻辑与传统GUI不同，可能未适配Z002。
解决：
- 检查Fiori应用后台配置：
SPRO → SAP S/4HANA → Procurement → Purchasing → Conditions → Define Access Sequences for New Pricing； - 确认新定价专用的存取顺序（如
Z002_NP）已分配给PB00； - 紧急修复：在Fiori采购订单初始屏幕，勾选“使用传统定价”（Use Classic Pricing）选项，强制回退到GUI逻辑。
6. 进阶技巧：用SE16N+SQL快速定位价格失效根因与批量修复方案
当面对数百条失效的价格记录时，手工在前台逐条检查效率极低。我习惯用SE16N结合简单SQL，在5分钟内完成根因定位和批量修复，这套方法已在三个大型项目中验证有效。
6.1 三表联查SQL：精准定位“有索引无数据”的幽灵记录
问题场景：A018中有记录，但KONP中无对应KNUMH，导致价格读取失败。用以下SQL一次性揪出所有“孤儿索引”：
-- 查找A018中有记录但KONP中无对应有效数据的条目 SELECT a~knumh AS 条件记录号, a~kunnr AS 供应商, a~matnr AS 物料, a~ekorg AS 采购组织, a~datab AS 有效期自, a~datbi AS 有效期至 FROM a018 AS a LEFT JOIN konp AS k ON a~knumh = k~knumh AND k~datab <= sy-datum AND k~datbi >= sy-datum WHERE k~knumh IS NULL AND a~datab <= sy-datum AND a~datbi >= sy-datum.参数说明：
sy-datum是ABAP系统当前日期，确保只查“当前有效”的孤儿记录。执行后，结果列表中的每一条，都是需要在ME13中重新维护条件的物料信息记录。
6.2 批量修复脚本：用LSMW自动补全缺失的RA00条件
当发现大量信息记录缺少RA00折扣时，手工补录不现实。我用LSMW（Legacy System Migration Workbench）构建了一个标准模板：
- 数据源：Excel文件，列名为
KUNNR（供应商）、MATNR（物料）、EKORG（采购组织）、RA00_VALUE（折扣率，如5.0表示5%）； - LSMW对象：选择
ME13（维护信息记录）； - 关键映射：
KUNNR→ 信息记录抬头“供应商”MATNR→ 行项目“物料”RA00_VALUE→ 条件“RA00”的“百分比”字段
- 执行模式：选择“Update”（更新），勾选“Skip if condition record exists”，避免重复创建。
效果：一个含1000行的Excel，10分钟内完成所有RA00条件的批量补全，且全程可审计。
6.3 定价日期类别的强制覆盖技巧：绕过凭证日期的硬编码限制
业务需求：所有采购订单必须按“交货日期”（Delivery Date）而非凭证日期定价。但标准配置中，定价日期类别（Pricing Date Category）需在信息记录或供应商主数据中维护，无法在订单创建时动态指定。
我的解决方案：在采购订单增强点EXIT_SAPLMEGUI_001中插入ABAP代码：
* 在ME21N保存前，强制将定价日期设为交货日期 IF sy-tcode = 'ME21N'. LOOP AT gt_eban INTO ls_eban. IF ls_eban-ebelp IS NOT INITIAL. " 获取行项目交货日期（EDATU字段） SELECT SINGLE edatu FROM eban INTO lv_edatu WHERE eban = ls_eban-eban AND ebelp = ls_eban-ebelp. IF sy-subrc = 0. " 强制覆盖定价日期 ls_eban-prsdt = lv_edatu. " PRSDT是定价日期字段 ENDIF. ENDIF. ENDLOOP. ENDIF.效果：无需修改后台配置，所有新创建的采购订单自动按交货日期匹配条件有效期，彻底解决“月底下单、次月交货，却按本月价格结算”的合规风险。
从那以后我每次做采购模块上线，第一件事就是跑一遍三表联查SQL，把A018/KONP的匹配关系清零；第二件事是在LSMW里预置好RA00补全模板，以防主数据迁移遗漏。这些不是银弹，但它们让我在客户质疑“为什么价格不对”时，能立刻拿出证据链，而不是在后台配置里大海捞针。希望帮到你。
本文还有配套的精品资源，点击获取
