ARTICLE DETAIL

资讯详情

深耕编程入门与网站建设的一线实战洞察。

SAP MM采购核心:采购申请与计划协议全解析

SAP MM采购核心:采购申请与计划协议全解析 每个做过几年SAP MM项目的人可能都遇到过这样的场景用户拿着一堆术语过来问“采购申请为什么不能直接发给供应商”“计划协议到底怎么建能不能一次定一年的货量然后分批要货”“交付计划行又是干什么用的”。说实话这几个概念在采购模块里属于基础中的基础但恰恰越基础的东西越容易在项目上线初期被忽略等用户真正开始用系统了各种问题才一个一个冒出来。这篇文章我就围绕采购申请Purchase Requisition简称PR、采购计划协议Scheduling Agreement简称SA以及交货计划行Delivery Schedule Lines这三个点把它们的定位、关键操作、后台配置逻辑和我在项目中踩过的坑一起梳理一遍。适合刚接触SAP MM的顾问、企业内部负责采购运维的关键用户以及所有想把采购流程理清楚的人。我会把事务代码、配置路径、常见报错都写清楚尽量让你能直接照着操作。1. 采购申请PR在整个采购链路中的定位内部需求凭证不是外部采购凭证1.1 采购申请的本质先分清PR、PO、合同、计划协议这四张单据很多刚上线的用户会把采购申请和采购订单混为一谈觉得“我都在系统里录了要买东西的单子为什么还要再转一次”。这个误解是很多问题的根源。事实上采购申请是一张纯内部使用的需求凭证它表达的意思是“我们内部哪个部门、在什么时候、需要什么物料、需要多少”它不对供应商构成任何法律上的承诺也绝对不能直接发给供应商。采购订单PO才是真正对外承诺采购的单据它代表企业与供应商之间已经达成的购销约定有明确的物料、数量、价格、交货条款供应商据此备货和发货。合同Contract则是更上层的框架约定通常约定一段时间内的总数量或总金额但它本身不触发收货后续还需要通过采购订单去“调用”合同。采购计划协议Scheduling Agreement则是框架约定加执行计划的结合体它既约定了总的供货范围又能通过交货计划行指定具体哪天送多少货。用一句话概括就是PR是“我要买”PO/SA是“我买了、你送”合同是“我们约了一个总盘子后面我通过PO或SA来用”。理解这层关系后面看采购的单据流就不会乱。1.2 采购申请的三种典型来源MRP、手工、其他模块采购申请从哪里来我见过的大部分项目里来源无非三类。第一类是MRP运行后自动产生这也是最核心的来源。生产计划、安全库存、预测需求等经过MRP运算后系统发现现有库存和计划收货不足以覆盖需求就会生成计划订单计划订单再通过“转采购申请”的动作变成PR。常见的场景比如生产订单跑完MRP后原材料缺料系统就会给你生成一串采购申请。这类PR的特点是数量和时间都是MRP算出来的最好不要手工乱改否则MRP的逻辑就白跑了。第二类是手工创建通过事务代码ME51N直接录入。这个场景适用于非生产性采购比如办公用品、备品备件或者MRP没有覆盖到的零星采购。手工创建的PR灵活但相应地更依赖创建人对业务的理解很容易出现需求日期填错、科目分配选错这类问题。第三类是其他模块触发的比如设备维修工单PM里产生备件需求项目PS网络活动中产生物资需求系统会通过预留Reservation直接转成采购申请。这一类PR的特点是它关联了后续的成本对象比如工单号、WBS元素收货时费用会直接结算到对应对象上。1.3 采购申请的生命周期状态从创建到归档采购申请不是一创建就完事了它有完整的状态流转。新创建的PR处于“未审批”状态时一般只是草稿性质不能用来转采购订单。如果启用了审批策略PR会进入审批流程经过相应审批人释放Release后状态变成“已审批”。只有已审批的PR才能被后续的采购单据参考。审批完之后采购员通过ME57或者后台批量程序把PR转成采购订单或计划协议此时PR的状态会变成“已转订购”并在采购订单历史里能关联看到。如果某条PR最终没有使用可以手动删除系统会留下删除标记不能再用它转单。这里有个细节PR转单之后它并没有消失而是和后续产生的PO/SA建立了关联关系。后续收货、发票校验时你都可以通过“采购订单历史”一路追回到最初是哪一笔采购申请带来的需求。这个追溯链条对财务和审计都很重要。2. 用ME51N手工创建采购申请时最值得细抠的字段2.1 物料、数量与固定数量标记不要小看这几个基础字段手工创建PR很简单ME51N进去输入物料号、数量、交货日期、工厂保存就完事了。但实际项目里很多问题恰恰出在这些“简单字段”上。物料编号首先要保证在这个工厂下是有效的。如果物料主数据没有扩展到对应工厂系统会直接报错。另外要注意物料类型和采购类型比如R呼呼物料无物料号的直接采购和标准物料在PR里的处理方式就不一样R呼呼物料不需要输入物料号而是直接输入物料描述、物料组、科目分配等信息。数量字段有一个“固定数量”的选项很多人不留意。如果勾选了固定数量那么后续ME57转单时系统不会自动拆分数量采购订单必须按这个固定数量来建哪怕当前库存已经有一部分了。这在某些行业是有用的比如整箱采购、最小包装量采购。但如果你没这个业务诉求建议不要勾否则转单时经常发现数量对不上还得回头改PR。逾期交货和过量交货的容差在后台有配置默认情况下PR转PO时PO的数量不应该超过PR的数量如果超过会提示错误。但这个容差范围是可配置的在采购申请的单据类型里可以设定比如允许超出5%这要根据业务来定。2.2 需求日期与采购组业务节奏和权责归属需求日期Required Date不是随便填的。MRP跑出来的PR需求日期来自计划订单的“基本开始日期”加上物料主数据的“采购提前期”等参数它代表的是物料真正需要到货的日子。手工创建PR时如果需求日期是当天但供应商的常规提前期是两周那么即使PR立刻审批、立刻转单采购员也没办法在当天把货催到这就是典型的“需求日期不真实”。系统里有一个参数可以设置创建PR时是否考虑计划交货时间。在后台的采购申请自定义设置里“采购申请处理时间”和“计划交货时间的设置”会一起参与日期的自动计算。也就是说你录入需求日期和确认日期Confirmed Date时系统会结合物料的计划交货时间反推“应该什么时候把PR交到采购员手里”。这个逻辑在项目上线前务必要跟用户讲清楚不然很多人随手填一个当天的日期之后采购催货催得飞起还说系统不支持。采购组Purchasing Group则是内部权责划分的关键字段。它决定了这个PR由哪个采购员/采购部门负责后续的报表分析、审批策略、货源确定都会参考采购组。同一个物料在不同采购组下可能有不同的货源清单和采购信息记录所以这个字段填错后面可能连供应商都选不对。2.3 科目分配类别决定这笔采购最终计入哪里手工创建PR时有一个项目行里的“科目分配类别”字段Account Assignment CategoryAAC这个字段决定了采购订单收货时财务上的库存/费用科目是如何确定的。常见的科目分配类别有U未知一般用于资产采购/K成本中心/P项目/F订单等等。如果是直接消耗性采购比如办公用品通常选K并填入成本中心收货时费用就计入对应成本中心。如果是设备采购选了资产相关的科目分配类别系统还会要求填资产号后续发票校验按资产入账。一旦科目分配类别设置错误后果往往是收货时财务过账报错或者费用记到了不该记的成本中心里。这里我额外说一下科目分配类别在后台是可以自定义的不同行业有不同约定但基本原理都一样它决定了这笔采购是进库存有物料号、可入库还是直接费用化无库存管理以及成本和哪个成本对象挂钩。项目上线时关键用户需要针对每一类采购场景明确用什么科目分配类别否则你的财务顾问会一天到晚收到收货过账报错的邮件。2.4 货源确定信息记录、货源清单如何影响后续转单PR创建之后采购员转单时会面临一个问题这个物料找哪个供应商买系统是通过货源确定Source Determination来帮忙决定的依据的是采购信息记录Info Record和货源清单Source List。如果在物料-工厂层级维护了货源清单并且勾选了“固定货源”Fixed Source那么ME57转单时系统会强制使用这个货源供应商不能改。如果只是维护了信息记录系统会按价格、交货时间等条件自动推荐供应商但采购员可以手工换。如果两个都没有维护系统会提示“找不到货源”此时要么手工补信息记录要么临时指定供应商并创建信息记录。有一种情况很常见后台配置里勾选了“必须维护货源清单才能创建采购订单”的选项。如果这个开关打开了那么没有货源清单的物料采购员根本没法创建采购订单。这个开关在业务上是一种强管控手段适合采购品类比较固定的企业但如果你上线的公司采购品类很杂建议先不开否则用户会天天来求助“为什么我建不了订单明明有信息记录”。PR字段里的“货源确定”标签页其实已经把系统算出的来源显示出来了用户和顾问都应该养成在这里确认一下的习惯。3. 采购申请如何走向采购订单和计划协议审批与转单全流程3.1 审批策略后台配置与PR版本的关系采购申请要不要审批、由谁审批、金额超过多少需要更高层级审批这些逻辑都由审批策略Release Strategy控制。后台配置路径在SPRO里物料管理 - 采购 - 采购申请 - 审批过程 - 带分类的审批过程。审批策略通过特征Characteristics类来控制例如根据“科目分配类别金额”的组合来决定走哪条审批路径再配置审批组、审批代码、审批标识和每一步的审批人。这里有一个特别容易踩的坑审批策略的版本问题。如果后台改了一个审批策略它只会对之后创建的单据生效已经存在的旧PR不会自动套用新策略除非你去后台手动调整“审批版本”并重新触发审批。很多时候用户说“我改了策略为什么这个PR还是老审批流”就是这个原因。审批操作本身是ME54N单张审批或者ME55批量审批。审批人在我的收件箱里也能看到待审批的PR。如果一个PR审批流程没走完它不允许被转成采购订单系统会有明确提示。这里我建议项目上要设计好审批层级的数量和金额阈值层级太多会让采购效率变得很低层级太少又可能让管控流于形式。3.2 手工转单与批量转单ME57、ME56、ME59N怎么选PR审批完之后下一步是转成采购订单或计划协议。转单的操作入口有好几个它们适用场景不同。ME57是“分配和处理采购申请”既可以为单条PR创建采购订单或计划协议也可以批量处理多个PR是日常用得比较多的功能。在ME57里选中PR后点击“分配”系统会弹出售源清单你指定供应商、信息记录、采购订单类型然后回车就会生成一张新的采购订单。如果PR行项目需要转成计划协议也可以在分配时选择对应的协议编号前提是已经有一个可用的计划协议。ME56是“分配货源”它不做转单动作只是把合适的供应商预先分配到PR上这样后续ME57转单时就不用手工指定。适合采购员和货源策略制定者分开角色的团队。ME59N是批量创建采购订单的旧事务代码在ECC时代很好用但在S/4 HANA里逐渐被新的Fiori应用和ME57N之类的功能取代。我的建议是新项目上直接让用户用ME57做主入口批量场景用ME57的批量选择功能即可免得教了旧事务代码之后用户自己都搞不清哪个是标准做法。转单时还有一个常见动作叫“后台批量转单”通过程序RM06EE00采购申请-采购订单可以定时把符合条件的PR自动转成PO。如果公司采购业务量大、采购员工作负荷高可以考虑启用但前提是PR创建时的数据质量要足够高否则自动转出来的订单肯定各种问题还得人工返工得不偿失。3.3 S/4 HANA里转单的变化和常见报错S/4 HANA对采购申请部分最大的变化是简化了数据模型部分表被融入了新表结构如PR相关的表从EBAN向新模型迁移但对最终用户来说操作层面的感知没有翻天覆地。要注意的是旧版ME59N等事务代码在S/4里逐渐被标记为废弃Fiori的“管理采购申请”“创建采购订单”应用会成为主流。如果客户用的是S/4 HANA Fiori的界面那么培训材料就要跟着Fiori的逻辑来写而不是照抄ECC时代的PUI操作。转单报错里出现频率最高的是“无法找到货源”。刚才说过这是货源清单/信息记录缺失。其次是“采购申请已被释放”或“只能由审批人创建订单”这类权限/状态问题通常和审批流程没走完有关。还有一种是“数量超过未清量”当你试图给某个PR创建多张采购订单数量加总超过了PR原始数量时系统会拦截。处理办法是回到PR上把数量调大或者调整足够交货容差或者先把之前创建错的PO取消掉。4. 采购计划协议Scheduling Agreement框架协议加计划行的组合玩法4.1 计划协议、采购订单、合同三张单据的边界到底在哪采购计划协议是SAP采购里非常典型的、也是很多用户听不太懂的单据类型。先说它与采购订单的区别采购订单是一次性的执行单据物料、数量、交期都写在上面供应商照单交货计划协议则是一个长期的约定它本身有总的数量约定但重点在于后续通过“交货计划行”来不断细化每次的交货时间和数量。它与合同的区别在于合同只是框架不能直接收货必须先通过采购订单或计划协议去“调用”合同而计划协议可以直接维护计划行、直接产生收货不需要再额外转一个PO。也就是说计划协议本身就是可以执行采购的单据合同则只是一份“意向书”。所以计划协议特别适合供需关系长期稳定、供应商相对固定、交货频次高的业务场景例如原材料长期供应、JIT/JIS供货、汽车行业的零部件配套等。在这些场景里你不可能每次要货都重新发一张PO而是希望和供应商约定一个总协议然后以天甚至以小时为单位更新要货计划。4.2 ME31L创建计划协议抬头、行项目与计划行的三层结构计划协议用事务代码ME31L创建修改和显示分别是ME32L和ME33L。创建时需要先选择协议类型最常用的是LPA标准计划协议系统还有JIT相关的计划协议类型比如JCHA之类后续讲JIT时再说。创建计划协议的第一层是抬头Header数据供应商、采购组织、采购组、协议有效期、付款条款、交货条款等这些信息和采购订单的抬头类似但它多了一个“总体交货计划”相关的标记。第二层是行项目Item物料号、数量、价格、工厂、库存地点等信息。第三层就是“计划行”Schedule Line也就是这个协议的执行明细——哪一天送多少货。保存之后系统会生成一个计划协议号。之后采购员每次给供应商下达要货指令都是在ME32L里进入协议在计划行栏里增加新的一行填写交货日期和数量保存并发送给供应商。这里要特别提示计划协议上的计划行内容是可以频繁更新的而且系统会记录变更历史所以不用担心“改乱了怎么办”一切都可追溯。4.3 计划行类别和未清计划交货计划行的底层逻辑计划行不仅仅是一行“日期数量”它背后有一个“计划行类别”Schedule Line Category的概念。计划行类别决定了这个计划行是否有交货功能、是否参与MRP、是否需要在收货时做科目分配等。系统里的计划行类别字段叫“SGrp”Schedule Line Category key常见的比如CP计划协议行固定LA计划协议行与生产/库存相关LE与库存直接相关等等。每个计划协议类型会默认一套计划行类别后台可以通过OMET配置计划协议的计划行类别组合。“未清计划”Open Delivery Schedule是一个很重要的业务概念。当你给一个计划协议创建了多个计划行比如每周一、周三各送一批系统在协议行项目上会汇总出一个“未清计划”数量它代表供应商还没有交货的所有计划行数量的合计。每次供应商交货入库后对应的计划行未清数量减少未清计划也随之更新。如果某个时刻计划行数量合计为0那这个协议项下就没有待交的货了。业务上常说的“清计划”就是让供应商把未清计划里的货交完或取消多余的未来计划行。5. MRP如何自动驱动交货计划行以及运行不起来时怎么排查5.1 MRP生成计划行的前置条件计划协议不只可以手工维护计划行还能让MRP自动帮你维护。生产需求变化后MRP运算会直接在计划协议里增加、减少或调整计划行这就是计划协议相比采购订单最大的优势之一。但MRP自动更新计划行是有前提的不是随便一个计划协议都能自动跑。首先这个计划协议要分配了正确的协议类型比如LPA这样的可计划类型其次协议行项目上的“MRP类型”字段要是PD等允许MRP控制的类型最关键的是后台需要给相应的MRP组设置“计划协议计划行”的参数文件告诉系统计划行应该如何维护。后台配置路径大致在SPRO - 物料管理 - 基于消耗的计划 - 计划 - 定义每个MRP组的计划行参数文件。这里的参数文件会控制计划行是按“总需求”还是“按每个需求”维护以及超过一定期限的计划行是否要自动缩短或删除等。如果MRP组没有分配参数文件MRP跑出来是什么都不会写到计划协议里的。5.2 计划行参数文件与维护方式的配置在配置计划协议的计划行参数时最核心的几个参数包括计划行维护方式是只在协议上维护一个汇总计划行还是针对每一天单独生成一行、计划行的删除规则未来多长时间之外的计划行可以自动删除、以及计划行是否允许包含多个工厂等。我实际项目里最常用的是“按日类型”维护计划行也就是说MRP每天运行后系统会把那天的需求作为一条独立的计划行写入协议。这样供应商拿到手的交付计划非常清晰今天是12月1日你看到12月5日需要200件、12月8日需要300件每一行就是一次的送货指令。另一个参数是“计划行截止日期”或者叫“装箱/冻结期”超过这个期限的计划行不会自动被MRP修改这是为了防止供应商已经按旧计划备料你这边却把计划改了导致对方扯皮。这个逻辑非常像我们平时改需求单时要区分“已确认不可改”和“未来可调整”的部分。5.3 计划行“没反应”的三步排查法很多顾问和用户都遇到过这种情况MRP运行完毕查看MD04物料需求清单发现计划协议明明挂着但协议的计划行就是没有新增或更新。我总结了一个三步排查法。第一步检查计划协议行项目的MRP类型是否允许MRP控制。如果MRP类型设置成了ND不参与MRP那无论怎么跑计划协议都不会有反应。第二步检查物料主数据的MRP组是否分配了计划行参数文件。这一步是最容易被忽略的很多物料主数据里MRP组是空的或默认组后台却只给某个特定MRP组配置了参数自然跑不出来。第三步检查计划协议的“入库计划行维护”标记。在协议行项目里有一个字段控制“允许计划行由MRP维护”不同协议类型的默认值不一样如果被设成了固定/不可更新MRP跑出来的需求就不会写入。排查顺序就是从协议本身的设置、再到物料主数据、再到MRP组的后台配置按这个顺序查绝大多数“MRP不更新计划行”的问题都能定位。6. 计划协议的收货操作与JIT这类特殊场景6.1 收到货后计划行如何扣减MIGO 101收货背后的逻辑计划协议的收货和采购订单收货大同小异MIGO事务代码移动类型101选择“采购订单”或“计划协议”作为参考凭证输入协议号和行项目、计划行系统会带出未清数量你按实际到货数量收货即可。这里有个关键机制收货时如果这个协议行下有多个计划行系统默认按计划行的顺序扣减未清数量同样的“超额交货容差”规则也适用于计划行。如果一个计划行的未清数量是100但你实际到了120系统会提示你是否允许超出容差超出的部分是否也收货。如果超过了后台设定的过量容差百分比系统直接拦截。另外计划协议收货后后续的发票校验MIRO同样是参考协议号来做供应商按照你发送的计划行开票财务按MIRO里对应行的收货数量做发票校验。从这个角度看计划协议在采购到付款的链条上和采购订单走的是完全等同的路径。计划协议还有一个功能叫作“预先发货通知ASN”的集成供应商可以在Web界面或EDI里维护哪些计划行已经发货、发了多少对应的SAP系统会更新计划行的“已发货”状态这样企业内部的库存计划能提前看到在途量。如果你的供应商支持EDI或供应商门户这个功能非常值得用能显著降低采购员的电话沟通成本。6.2 JIT计划协议高频小批量供货场景下的特殊玩法JITJust In Time在SAP MM采购里的实现本质上就是“计划协议高频计划行”的组合但它的玩法更贴近生产拉动的逻辑。在传统计划协议里计划行可能是按周维护的但在JIT场景里计划行可以精细到小时级而且通常由生产线实际消耗触发。SAP里JIT的运作模式大概是这样生产部门把需求通过JIT调度比如JIT3/JIT1运行转换成对供应商的“JIT调用”JIT Call系统会在计划协议中生成相应的计划行并且通过EDI、传真或打印的方式把这个较短的交付需求发给供应商。供应商按照JIT计划行的节拍送货有时一天要送好几次直接把货送到生产线边。这就非常依赖计划行的准确性和实时性容不得半点手工差错。JIT计划协议的类型和标准计划协议不同后台配置也更复杂涉及到JIT相关控制参数、调用行类别、包装指令、交付指令等等。如果你们公司没有JIT的业务诉求我建议不要轻易启用JIT功能因为配置复杂、运维门槛高但如果业务确实有高频小批量的供货需求JIT计划协议带来的收益又是非常明显的它能把采购、物流、生产三个环节的信息实时串起来。7. 几年SAP项目做下来这几个和PR/计划协议有关的坑印象最深7.1 审批策略更新后旧PR不触发新审批这个坑几乎每个项目都会遇到。上线初期用户觉得审批金额太低要求把某条审批策略的金额阈值从5000提到20000。配置顾问改了后台测试了一笔新PR没问题就告诉用户改好了。结果第二天用户说“我们有一笔12000的PR还是走了老审批流被卡住了”。原因就是新策略只对新单据生效旧PR已经按创建那一刻的策略版本绑定了审批流程改后台是影响不到它的。那时候我们的处理办法是让用户在后台把审批版本的“生效日期”调到之前或者用事务代码O1PL等工具手动调整这单PR的审批版本让它重新套用新策略。类似的逻辑在所有启用了审批策略的单据类型里都存在所以如果你要调整审批策略一定要盘点一下当前有没有未完成的单据会受波及别只顾着跑新测试。7.2 计划协议改了数量MRP又自动“补”了一行这是一个让用户非常崩溃的场景。采购员在ME32L里把某一个计划行的数量从500改成300觉得已经和供应商确认好了。结果当天晚上MRP一运行系统根据生产需求又自动新增了一个200的计划行采购员第二天一看数量总和还是500又得和供应商重新对一遍。这其实是计划行参数文件的设置问题。MRP是按需求总量来维护计划行的你手工改了一个计划行但总需求没有变MRP重新运行后就会尝试把差异部分补回来相当于系统并不知道你是“故意”要削掉200的。解决办法是在计划行上勾选“固定计划行”的标记或者调整参数文件让MRP在某个时间窗口内不修改已确认的计划行。这个机制本身没问题关键是用户要理解“MRP维护的是总需求不是某一行的数量”不然天天和系统打架。7.3 转计划协议时货源清单提示错误处理思路还有一个很常见的报错场景ME57里选好PR指定计划协议号系统提示“无法为物料分配货源检查货源清单”。很多用户以为是计划协议自己建错了其实问题多半出在货源清单的材料上没有把这笔采购申请指定的“计划协议”作为一个合法货源。处理思路很简单在ME01货源清单维护里把对应的计划协议号维护进取勾选“固定/可用”即可如果公司希望严格控制还可以在货源清单中指定这个计划协议的采购组、工厂等维度。反过来讲如果某个物料允许所有供应商都可以报价那也不一定非要在货源清单里维护只要后台不强制货源清单ME57会自动去信息记录里找供应商。但计划协议这种长期固定的供货关系我建议还是把货源清单建清楚避免采购员每次转单还要纠结供应商选哪个。还有一类问题也经常遇到计划协议审批流没走完采购员就尝试下达交货计划系统会说计划协议未被释放不允许发送计划行。这时别想着绕过老老实实走完审批流程把计划协议的状态释放到允许交货计划行的层级。这个和PR审批是同一个思路区别只在于计划协议释放的层级更多——抬头释放、行项目释放、计划行释放可能分别控制做后台配置时要把这三层的关系理清楚免得出现“协议头释放了但行项目没释放”这种半吊子状态。最后再分享一个小技巧如果你们公司有大量长期供货的物料计划协议维护完记得定期用ME33L里的“清单显示”功能导出每个协议的计划行状态看看哪些行长期未收货、哪些行已经被清掉这种例行的“协议健康检查”能帮你提前发现很多潜在的缺料或者呆滞风险。文章里说的这些配置和排查方法都是我在实际项目里一遍遍验证过的照着做大概率能少走不少弯路。
返回列表