简介一份面向东风汽车SAP实施项目最终用户的培训手册聚焦生产管理模块中的MD61事务代码解决独立需求整车、大总成及大改装任务创建的操作问题。文档以步骤化方式讲解从SAP轻松访问进入MD61、填写初始屏与计划表字段到保存需求的完整流程并针对需求计划号、物料、量份、装备日期、客户订单号等核心字段提供了填写规范、必填属性说明与实际示例同时涉及Navigator项目管理、系统安全机制及用户培训等配套知识体系较为完整。资源包共1个docx文档大小约581KB内容既有操作路径又有字段说明适合东风商用车技术中心业务人员、SAP PP模块顾问及相关最终用户作为实操参考或培训材料。目前已有354人学习/浏览具备不错的借鉴价值。1. MD61创建独立需求整车厂计划员每天都要碰的PP操作为什么最容易“录了等于没录”在东风汽车这类整车厂的SAP实施项目里MD61创建独立需求是每个生产计划员几乎每天都要碰的动作却也是PP模块中最容易“录了等于没录”的操作版本选错、期间文本没设对、策略组不匹配数字敲上去了MRP跑完结果照样不对。MD61是计划独立需求PIR的标准创建入口本质是把年度排产、月度预测这些规划数据写成MRP能读取的需求单据后续生产订单下达、物料采购建议都从这里开始。下面要讲的内容适合三类人先对号入座刚接PP模块的计划员、要写最终用户手册的顾问、做数据维护的ERP专员。目标是把操作路径、字段含义、批量导入和常见翻车点一次讲透照着做至少不会出现“需求录了但MRP不理你”的情况。2. 独立需求是怎么被MRP吃掉的从MD61填一个数字开始把需求链路讲透2.1 计划独立需求和销售订单需求的本质区别一个管预测一个管实际很多人第一次接触MD61心里最大的疑问是销售订单不是已经在系统里了吗为什么还要单独录一个需求这个问题的答案决定了你有没有真的理解独立需求。VA01创建销售订单之后SD模块会把订单需求传递给PP模块MRP运行时会把它作为客户需求参与计算这是“实际需求”来源。而MD61录进去的计划独立需求Planned Independent Requirement简称PIR不挂在任何客户、任何销售凭证下面它是计划员自己填的“我们预计要卖多少”的数字。两份需求可以同时在同一个物料上存在但MRP拿到它们之后是按不同规则来用的。在整车厂里PIR对应的是主生产计划层面的预测数量。比如某个车型一年规划卖五万台这是从年度经营计划里拆出来的不是某张具体销售订单。计划员会用MD61把这五万台按月份拆进去MRP据此算出发动机、变速箱这些长周期件该什么时候采购、采购多少。如果只依赖销售订单一个尚未签下来的预测需求是没法驱动备料的等订单真正落下来再去买发动机生产周期根本来不及。反过来如果只依赖PIR客户订单集中砸进来时MRP会把订单需求在PIR之外再算一遍库存容易重复采购。这个区别用一个对比表格看更清楚需求来源对应事务码是否有客户凭证参与MRP的前提在整车厂里的典型用途计划独立需求MD61 / MD62 / MD63无物料主数据策略组允许PIR参与年度排产、月度预测、长周期备料客户需求VA01 / VA02有策略组设置为MTO或MTS模式下对PIR做消耗实际订单、客户定制车的物料拉动理解这个区别之后再去看那些“MD61录了需求但MRP不跑”的报障一半以上都能猜到原因要么策略组不让PIR参与要么需求录到了某个不被MRP评估的版本上。不是MD61这个事务码坏了是需求源根本没被MRP当成有效输入。2.2 独立需求在MRP里的流转毛需求、净需求、计划订单怎么被算出来MRP的运行逻辑可以压缩成一句话把所有的需求加起来减去所有的供应剩下的缺口就是MRP要帮你解决的问题。以一颗需要按预测备料的零件X为例。某月计划员在MD61里录了1000只的独立需求。此时MRP会去读这个物料的所有供应工厂现有库存300只生产部门已经下达的生产订单还有500只采购在途有200只。需求减去供应1000减去300、500、200刚好等于0那么MRP不会给这个月生成任何新的计划订单或采购申请。如果采购在途不是200而是只有150缺口就是50只。MRP再按物料主数据里设置的批量规则批量越大MRP越倾向于合并成一个大订单生成一张50只的计划订单。这张计划订单如果是自制件就会继续向下展开对它的下层原材料产生“相关需求”也就是下面一颗颗螺丝、一块块钢板的采购申请来源。这个流转用几个供需项目就能表达得很清楚供需项目来源本例数量MRP如何处理独立需求MD61录入1000作为毛需求工厂库存MMBE查询300抵消需求已下达生产订单COOIS查询500抵消需求采购在途ME2M查询150抵消需求净需求缺口计算得出50触发计划订单毛需求、净需求这些词计划员在MD04库存/需求清单里会直接看到。MD04每一行会标明这条需求的类型独立需求来自MD61相关需求来自上层订单展开客户需求来自销售订单。刚上手的人先把MD04每一行的含义看懂再谈批量维护几百个物料号的事情否则就是拿着一堆数字在猜系统行为。整车厂里还有一层容易被忽略的关系独立需求通常只维护在最终产品或者关键总成上而不是维护在每一颗零件上。发动机、车桥这些关键总成可以做独立需求但一颗螺栓的需求量不是计划员用MD61录出来的它是整车计划订单展开后自动算出来的相关需求。实施团队在写最终用户手册时一定要把这一层写清楚否则计划员会以为每个物料都要手工维护一遍工作量失控数据也容易重。2.3 整车厂为什么离不开独立需求MTS/MTO混合场景下的选择逻辑商用车企业的生产模式几乎都是按库存生产MTS和按订单生产MTO混合的独立需求的价值正是在这种混合场景里体现出来的。标准车型、售后备件这类需求量大且稳定的物料适合按库存生产。物料主数据里配策略组10MD61录入滚动预测MRP持续补货车间按计划生产入库销售订单来了直接从库存发货。这时独立需求是整个计划链的源头没有它MRP就没有需求驱动。特种改装车、出口定制车这类客户要求明确的订单适合按订单生产。物料主数据配策略组20MRP只看销售订单MD61录的PIR基本不参与需求计算。这个场景下如果计划员还用MD61录入预测跑完MRP发现系统没反应别奇怪这是配置有意为之不是故障。还有一类零件需要特别处理总装车间的排产可能是按订单的但车身、底盘这些共用件的采购却需要提前按预测备料。这类场景常用策略组40直接在销售订单的最终装配层做按单生产下层的共用件仍然通过PIR驱动MRP。整车厂真正复杂的计划管理就在这种MTS和MTO交错的边界上。所以独立需求不是用来替代销售订单的它解决的是“销售订单还没来但生产必须提前动起来”的问题。SOP产销协同评估时计划员把下个季度的预测在MD61里调整一遍再跑一次MRP看哪些物料出现缺口这就是最简单也最常用的场景推演。比在Excel里算半天再手工去查库存靠谱得多。PP模块最终用户手册里把MD61这一节作为重点也是因为它是计划链的源头源头错了后面的采购、生产、库存全跟着错。3. 用MD61创建独立需求的标准路径字段、期间和批量维护一次说全3.1 MD61主界面逐字段拆解物料、工厂、版本、数量类型别选错MD61的标准进入方式有两种从SAP菜单走“后勤 - 生产 - 物料需求计划 - 计划 - 需求 - MD61创建”或者直接输入事务码MD61回车。更建议把MD61放在计划员的收藏夹或角色菜单里减少输入路径的次数。进入MD61后先看到的是初始屏幕。这个屏幕决定你要维护哪个物料、哪个工厂、按什么粒度录入。字段不多但每个字段选错都会影响最终结果初始屏幕上的“版本”默认是00在绝大多数实施项目里最终用户不需要改动它。“期间文本”决定后面录入数量时系统按一个月、一周还是一天展开一排期间默认常设为MON月。如果项目没有做过用户参数定制每次打开MD61都要手工填工厂这已经在很多企业里成为计划员输错工厂的主要原因后面第6章会讲怎么用用户参数把这个字段默认带出来。填完物料和工厂点击回车进入明细屏幕。明细屏是一张按期间横向展开的表格1月一列、2月一列每一列下面填数量。这个界面里最容易忽略的是“固定”标识一旦勾上该期间的独立需求就被锁定MRP对它的处理方式会发生变化。整车厂滚动预测阶段不建议使用固定标识真有必须锁定的需求由主计划员单独处理不要把这个权限下放到所有计划员手里否则后期调整需求时会出现一堆“系统改不动”的报障。MD61关键字段最终用户取值如下屏幕位置字段名称最终用户通常取值说明初始屏幕物料具体物料编号建议先在MM03确认该物料工厂视图已扩展初始屏幕工厂计划工厂编号可用用户参数默认带出减少手输错误初始屏幕期间文本MON月还有WOC周、TAG日日常预测用MON初始屏幕版本00项目未配置多版本时只允许用00明细屏幕数量按排产数量填写单位是物料主数据里的基本计量单位明细屏幕固定标识不勾选勾了之后MRP不会自动调整该期间需求3.2 用期间文本控制月/周/日需求MRP的期间到底是按什么算的MD61里的“期间文本”Period Text决定了独立需求按什么时间粒度展开。实际项目中我发现很多计划员对这个字段的理解停留在“随便选一个”的层面等到MRP结果不对才回来看这个字段已经晚了。常见的期间文本有三种。MON表示按自然月展开适合做月度滚动预测WOC表示按周展开适合做近几周的详细排产TAG表示按日展开适合车间的日计划排序但因为需求被摊到每一天如果误用MRP算出来的数量会异常膨胀。日常预测最稳妥的组合是期间文本MON、期间数12也就是从起始日期开始往后看十二个月每个自然月一行数量。一个容易出错的操作是“起始日期”的选择。如果期间文本是MON起始日期最好填当月第一天比如20260501表示从2026年5月开始。填成20260515系统会把5月分成不完整的一段6月起再按整月拆最后你看到的数量分布跟排产口径完全对不上。类似这种细节我一般会直接写进最终用户手册的操作要求里并且要求计划员养成习惯凡是手工用MD61录入月度需求一律按“月初第一天”作为起始日期。还有一个概念需要澄清独立需求的期间跟财务账期没有直接关系。MRP有自己的期间逻辑它按照工厂日历、期间文本和起始日期来拆分需求。如果物料主数据里维护了计划日历碰上节假日MRP还会按日历把需求落在对应的工作日上。计划员不需要把这里面的每个算法都弄明白但至少要知道你在MD61里填的“数量”落到MRP计算时是按期间归集的而不是按你录入的日期精确匹配到某一天。3.3 从Excel清单批量导入独立需求LSMW录制MD61的字段映射和注意事项整车厂的滚动预测经常一次要维护几百个物料号的月度需求让计划员在MD61里一条条敲既不现实也容易出错。常见做法是计划员在Excel里维护预测清单再由数据专员通过LSMWLegacy System Migration Workbench做批量导入本质上是把MD61的屏幕操作录制下来用批处理的方式回放。Excel清单的维护格式我建议固定成五列不要多加任何字段方便映射和排查列字段格式要求A物料编号文本格式18位防止科学计数法B工厂文本格式C版本统一填00D起始期间8位日期文本如20260501E数量数字保留两位小数LSMW的操作步骤按这个顺序走不会乱。第一步创建项目对象类型选择Batch Input Recording源结构就按上面这五列定义。第二步用SHDB开始录制由一个人手工完整操作一次MD61录入流程录下来的屏幕序列就是后面回放的模板录的时候宁可多录几步也不能漏掉任何一次回车确认。第三步做字段映射把Excel里的物料号、工厂、数量对应到录屏的屏幕字段上这一步是翻车高发区因为MD61明细屏里的“数量”是按期间一列一列的每个期间都要单独映射一次漏一个就错位一个。第四步用三条数据在前台试运行一条正常数据、一条错误数据、一条边界数据跑完看屏幕和报错。第五步放后台批量跑用SM35监控会话运行状态失败的会话双击进入逐条分析。批量导入最典型的两个坑都出在Excel格式上。物料号如果设置成常规格式超过一定位数的数字会自动变成科学计数法SAP按这个值去读物料主数据必然报“物料不存在”。日期如果用Excel内置日期格式录屏回放的时候系统收到的值跟SAP要求的显示格式不一致会话同样会中断。这些错误在试运行阶段基本都能发现就怕有人跳过试运行直接批量跑最后半截成功半截失败排查起来更费劲。LSMW做MD61批量导入是很成熟的做法很多实施团队都在用但它对使用者有个前提要求至少能看懂SM35会话列表里的错误信息。把SM35的查看方法写进最终用户手册比出问题再找顾问更高效。更简单的替代方案是用ABAP报表直接调用BAPI创建计划独立需求但这对最终用户来说维护成本太高不是首选。4. 三个必调的参数版本、策略组、MRP组独立需求能不能跑起来全看它们4.1 版本号的坑MRP默认只评估00版本你录在01版本上当然没反应MD61屏幕上的“版本”字段可能是计划员最容易随手改又最不该改的地方。很多用户看到默认值00以为版本越大越新改成01、02结果MRP跑完MD04里完全看不到这笔需求。原因其实不复杂SAP里计划独立需求允许维护多个版本每个版本可以承载不同场景的数据比如00版本放生产计划01版本放销售预测02版本放财务预算。但MRP运行时的标准行为是默认只评估00版本其他版本必须通过配置或者MRP运行参数显式指定才会参与计算。版本的定义位置在IMG路径“生产 - 物料需求计划 - 需求管理 - 计划 - 定义版本”下面。标准安装里版本00是MRP评估版本而版本01经常被用于客户独立需求。如果实施项目没有专门规划过多版本方案最终用户手册就应该写死一句话MD61创建独立需求版本一律填00。不要给用户讲版本背后的复杂机制讲得越多操作越乱。多版本方案本身不是不能用整车厂如果想在同一个物料上分别管理销售预测和生产计划可以给这两个场景各配一个版本MRP取其中一个作为需求源。但多版本带来的代价是数据维护翻倍MD04和MD07里看到的需求数量还要额外带版本条件去区分计划员很容易把两个版本的数据加起来当成总需求造成重复采购。SAP这些配置在用户眼里就是个黑匣子版本这种参数尽量保持单一、简单先把单版本跑顺多版本等业务真的提出明确需求再做。4.2 策略组决定独立需求是被消耗还是被忽略MTS与MTO的差异化配置物料主数据MRP视图里的“策略组”是决定MD61录进去的需求到底有没有用的关键参数。它的本质是告诉MRP这个物料的需求是按预测算还是按实际订单算还是两者都要算。策略组10是按库存生产的典型配置MRP会把MD61的独立需求和销售订单同时纳入计算销售订单会自动去消耗对应的计划独立需求。东风汽车的售后备件、标准通用件用这个策略组最合适。策略组20是按订单生产MRP只认销售订单MD61录的预测不参与MRP计算专用改装件、客户定制件用这个。策略组40是最终装配按订单生产总装层看销售订单下层共用件仍然可以靠独立需求驱动备料适合整车排产这种既有预测又有实际订单的混合场景。策略组是物料主数据层面的字段不是在MD61界面上能改的。所以出现“MD61录了需求但MRP没反应”这类报障时排障顺序应该是先查物料主数据的策略组确认是不是用了20这种不评估PIR的策略再回来检查MD61录入版本和期间。很多顾问一上来就重新跑MRP跑了三遍还是老样子最后发现物料的策略组配置压根就不对前面全是白忙。策略组里还有一组消耗参数是另一个容易出问题的位置。消耗模式1表示只向前消耗也就是销售订单只能冲减过去期间已经录好的PIR模式2表示只向后消耗销售订单会去冲减未来期间的PIR模式3是双向消耗。消耗期间定义了允许冲减的时间窗口长度。这个配置直接影响MRP计算结果如果1月的PIR是1000实际1月只出货600消耗模式2加消耗期间2个月那么2月和3月的PIR会被这600继续冲减如果消耗期间设得太短剩余PIR就一直挂在账上MRP持续给出偏高的采购建议。这块配置的参数组合实施顾问必须和业务确认清楚不能直接沿用某个模板值。4.3 MRP组和计划时界的边界作用独立需求在短期计划窗口里不能乱动MRP组在物料主数据MRP视图中维护它是一组MRP控制参数的集合最终影响MRP如何创建和删除计划订单。对计划员日常操作来说MRP组里最值得关注的是“自动创建计划订单”和“自动删除计划订单”这两个开关以及计划时界的设置。计划时界Planning Time Fence是一段被冻结的时间窗口由策略组里的装配提前时间加上安全缓冲组成。它的作用很直接在时界内MRP不会因为独立需求的变动就随意修改已经生成的计划订单。整车厂通常把计划时界设成一到两周这样计划员周一调整了预测车间里已经排好的生产订单不会马上被推翻生产线才稳得住。这个机制带来一个非常常见的用户困惑计划员在MD61里把某个月需求从1000改成1500跑完MRP再看MD04生产订单还是1000对应的数量没变。用户以为系统出了问题反复跑MRP结果都一样。实际上生产订单落在了计划时界之内MRP认为这个期间的订单已经锁定不能自动调整。最终用户手册里这个提示一定要加修改独立需求后先看对应期间是否落在计划时界内落进去了生产订单不会自动跟着变需要主计划员人工干预。另外MRP组里还有一个容易混淆的地方独立需求管顶层相关需求管下层。一颗螺丝钉的采购申请不是MRP直接读MD61读出来的而是上层生产计划订单展开后作为相关需求计算出来的。MM模块的采购员看到采购申请时已经是被MRP展开过的结果。这条链路不用给计划员讲太细但一定要让他们知道MD61维护的是最顶层的需求越往下层越是系统自动算出来的不要试图用MD61去逐颗维护物料需求那是把MRP当手工台账用了。5. 避坑指南MD61建独立需求最常翻车的5个现场和排查方法5.1 现象MD04里看不到独立需求MRP怎么跑都没变化这是最频繁的一类报障用户说“我明明录了系统就是没反应”。排查第一步用MD61回读物料和工厂看之前录入的需求是否还在同时确认版本号是不是录到了00以外的版本。第二步切到明细屏幕看数量到底落在哪个期间起始日期填错的话数量会分配到过去或者很远的一个时间段。第三步用MM03进物料主数据MRP视图查看策略组是否允许PIR参与MRP计算如果策略组配的是20按订单生产独立需求不参与MRP是完全正常的。按这三个顺序查完绝大多数问题都能定位。MD61本身出故障的概率极低绝大多数所谓“录不进去”都是版本、期间、策略组三个字段中的某一个不对。以下排查顺序可以直接做成手册附录步骤操作判断要点1MD61回读是否录在了非00版本2MD61明细屏期间是否准确数量单位是否为基本计量单位3MM03查看策略组策略组是否允许PIR参与4MD02重跑MRP本次MRP是否正常结束5MD04查看是否出现独立需求行、计划订单行5.2 现象独立需求录完但物料缺料一查发现预测被销售订单冲销得过头了这种问题发生在策略组10的物料上。销售订单消耗PIR是正常逻辑但消耗模式或消耗期间配置不当会导致PIR被大量冲销MRP看到的净需求随之变小采购建议跟着缩水最终车间缺料。比如3月的PIR录了10004月来了500的销售订单消耗模式是2且消耗期间只有1个月这500只能冲减4月本月的PIR冲完了继续冲5月的看起来没毛病。但如果消耗期间设置过短比如没有给未来期间留下足够的冲销窗口预测余量会长期滞留在过去期间不参与计算。解决方式是顾问在IMG里把消耗期间调长通常按月计算设3个月比较稳妥或者改用模式3的双向消耗让实际订单在预测前后都能找到可消耗的PIR。排查这个现象时还有一个隐蔽分支要查同一个物料是否存在两条相似记录分别在不同版本里各录了一份预测。比如有人用00录了一份另一个用户不知道又用01录了一份MRP默认只算00不会重复计算但MD61回读时会看到两笔数据容易误判。如果项目里确实开放了多个版本就要对最终用户强调版本不搞清楚账就算不清。5.3 现象删除独立需求后跑完MRP计划订单又自动冒出来MD61删除需求的操作用得不熟经常出现“删了跟没删一样”的效果。最常见的原因是没选对的版本和期间。MD61删除时系统要求重新选择物料、工厂、版本、期间文本如果回读时版本选成了00但当初录入的是01删除的就是另一批数据原来的需求还好好躺在系统里。另一个更隐蔽的原因是计划订单被固定了。如果某张计划订单在创建后被用户勾选了“固定”标识MRP即使发现需求已经消失也不会自动删除这张订单因为固定状态代表人工锁定。这时去MD04看计划订单还在数量还是原来的数用户会以为是删除操作失败。解决方法是先取消计划订单的固定标识再跑一次MRP多余的订单就会由MRP按自动删除策略处理掉。整车厂里这类问题的高发期在月底滚动预测切换时旧预测要清掉新预测要导入一旦删除操作没做干净MRP结果就会把新旧两批需求叠在一起。我的建议是月底做切换时统一用“先清零再重录”的流程不要在旧预测上改来改去改到后面没人知道哪些期间是旧的、哪些是新的这种乱账比少录一个物料更难收拾。5.4 现象LSMW批量导入只有一部分物料成功另一部分无记录用LSMW跑MD61批量导入最常见的结果是“部分成功、部分失败”。第一类原因是Excel格式问题物料号列没设文本格式被Excel转成科学计数法SAP找不到对应物料日期列用了Excel日期类型录屏回放时日期格式对不上会话中断数量列带了空格或全角字符系统报错。这些格式问题在试运行阶段就能暴露但有的数据专员嫌试运行麻烦直接后台批量跑出错后只能翻SM35会话清单逐条看。第二类原因是物料主数据工厂视图没有扩展。录屏回放时系统会按屏幕逻辑检查物料在指定工厂是否存在工厂视图没扩展屏幕会直接报错并终止会话。这一点靠改Excel格式解决不了需要在MM03里逐个确认物料的工厂状态。实操经验是批量导入前先把Excel里的物料号全量导出来用MM03或者报表批量查一遍工厂视图确认都有数据再跑。LSMW失败排查的通用顺序是SM35打开失败会话看错误信息定位到具体物料和字段回到Excel改数据重新生成的批处理会话再跑。不建议直接修改LSMW的映射来迁就错误数据那样只会把正确数据也带偏。SD顾问常说一句话前半段数据的质量决定后半段排产的稳定。LSMW导入也是这个道理Excel清理干净导入成功率基本接近百分之百。5.5 现象月需求被录成日需求MRP跑出来的数量翻了30倍这是我见过最典型的MD61误操作而且一旦发生影响会迅速扩散到采购和供应商端。某个计划员在期间文本里选了TAG日起始日期填的是月初期间数填了30也就是往后30天每天录了500。MRP把这30天的需求加总相当于这个月出现了15000的需求而业务预期可能只有5000。采购看到MRP生成的采购申请数量异常放大下一步就会去给供应商下大额采购单。这个问题的止损流程是先把错误版本的独立需求全部清零在MD61里选中所有期间把数量改成0重新跑一次MRP确认多余的计划订单被清掉再用期间文本MON重新录入正确需求。一定不能直接在原记录上把日需求改成月需求因为期间拆分逻辑已经变了改出来的数据依然不对。预防的办法最终用户手册上要写清楚两个默认值日常预测一律用MON版本一律用00。同时给计划员的MD61界面做好用户参数默认值把期间文本默认成MON这样即使计划员想改成TAG也要先意识到自己在改什么。把容易出错的操作从默认路径上移走比靠自觉和培训更可靠。6. 进阶用法把MD61从“录单工具”变成滚动预测工具的3个技巧6.1 用MD62批量调整需求不要每个物料都删了重录滚动预测调整时最耗时的不是新增需求而是调整已有需求。MD62更改独立需求支持按物料、工厂、版本把某个期间的数量直接修改也可以把上期剩余预测批量转移到新的月份。实际项目里的经验是每月滚动时先把上个月尚未消耗的PIR用MD62转移到新预测起点再根据最新销售情况微调数量比全部删除后重新录一遍效率高得多也方便追溯调整痕迹。6.2 用MD63配合MD07核对总量别只信Excel计划员中有个普遍习惯把所有预测都放在Excel里维护SAP里的数字反而成了“二手数据”时间一长两边就对不上。我习惯每个月在预测切换前用MD63导出当前所有关键物料的独立需求总量再用MD07看物料组的独立需求、客户需求合计两边一比对多出来或者少掉的物料一眼就能发现。MD07就是不少人搜过的“sap md07”它的本质是需求汇总报表跟MD61正好配套使用。核对这一步不能省不然等到MRP跑完、采购订单发出去再发现数量不对就晚了。6.3 在SU01里预设用户参数让MD61打开就是当前工厂和版本最终用户最常见的低级错误就是每次打开MD61都要重新输入工厂、选择期间文本选得多了就错。实施期间给计划员在SU01或SU3里维护用户参数把工厂、MRP区域这类常用值设成默认值MD61一打开就直接带出当前工厂期间文本固定为MON版本固定为00用户基本没有机会碰到那些容易翻车的选项。很多“录了等于没录”的报障根源不是用户不会操作而是系统给了用户太多不必要的选项。把默认值锁好比在手册里写十遍注意事项更有用。这些年处理过的MD61相关故障最后绕回来几乎都集中在版本、期间文本、策略组这三个点上。所以我现在写最终用户手册一定会把“版本等于00、期间文本等于MON、起始日期为月初”这三句话印在操作步骤的最前面再让用户动鼠标。希望帮到你。本文还有配套的精品资源点击获取