采购订单审批经常被当成工作流问题来讨论，但在 SAP 里，它同时也是一个非常具体的配置问题和系统行为问题。很多审批不生效、审批错误、修改后不重新审批的问题，根源都在细节里。
哪些字段可以决定采购审批策略
标准采购订单审批策略主要基于 CEKKO 中的抬头字段，例如公司代码、采购组、采购组织、采购订单类型、采购订单不含税总金额、供应商、国际贸易条款、工厂、物料组、采购版本号等。需要更多字段时，可以通过增强扩展。
如果要使用行项目字段，就必须理解系统的汇总逻辑。以工厂为例，如果采购订单所有行项目的工厂相同，系统可以把这个工厂带到抬头层面；如果行项目里有多个工厂，系统可能给工厂赋空值，再按空值去找审批策略。
有些字段还要特别注意数据库里的真实值。成本中心、物料编码、版本号、供应商等字段可能需要前导零；项目类别也可能要用内部编号，而不是用户界面看到的外部代码。
审批策略为什么不生效
排查时，一个很实用的动作是用 CL20N 或 CL30N 检查分类和值，确认是否能找到正确且唯一的审批策略。很多问题不是审批流本身的问题，而是分类分配、特征值输入或后台配置不一致。
真正复杂的是：审批后的修改
采购订单已经审批后，到底能不能改？如果允许改，改完是否重新触发审批？如果要重新触发，哪些字段、哪些场景才算需要重新审批？这才是很多项目里真正容易出问题的地方。
SAP 通过可变性（Changeability）控制这类逻辑。标准逻辑会区分采购订单金额变大、字段变化导致新的审批策略，以及采购订单已经输出给供应商这类特殊场景。
例如，采购订单总金额变大时，可以触发重新审批；采购组从 A1 改成 A2，如果仍然对应同一个审批代码，策略可能不变；但如果从 A1 改成 B1，导致审批代码变化，采购订单状态就可能被重置为未审批。
采购订单输出后，问题又变了
采购订单成功输出，意味着订单可能已经通过打印、邮件或 EDI 发给供应商，甚至供应商已经开始发货。此时再修改采购订单、取消审批或重新审批，业务含义已经不同。
如果忽略输出状态，系统可能出现两类问题：要么合理修改被挡住，要么已经发给供应商的订单被修改了却没有足够控制。部分项目会使用标准可变性 5 或 6，部分项目则会通过增强，把交货日期、付款条款、数量、库存地点等字段变化配置成重新审批条件。
所以，采购订单审批不应该只设计“谁审、几级审”。更关键的是：哪些字段决定审批，哪些修改会重置审批，订单已经发给供应商之后又该如何控制。