简介SAP SD 可用性检查与需求传递3.0归纳文档面向SAP SD顾问、MM/PP协同人员及正在做销售与分销模块自学的读者聚焦销售订单与交货环节的可用性检查配置及需求向MRP传递的完整逻辑。资源为1个PDF文件压缩包约1.77MB内容按专题整理便于在项目配置与自学复盘时快速查阅。文中从检查组与检查规则入手串联OVZ2、OVZ9、OVZG、OVZH、OVZ8、OVZK等配置路径并说明订单可用性检查、交货可用性检查、ATP逻辑、RLT及一次性交货、全部交货、交货建议等业务控制方式同时梳理需求分类、计划行类别、交货项目类别与需求传递流程帮助读者理解可用性检查在SD、MM、PP模块间的集成关系与常见配置要点。全篇以流程图和Tcode路径为主线已有1007人学习适合希望把可用性检查与需求传递一次性梳理清楚并用于实际配置核对的从业者。1. 客户的催货电话打进来之前SAP SD 可用性检查应该先给出答案销售在 VA01 里敲完数量一回车系统甩出一个比客户要求晚两周的确认日期——这个动作背后就是 SAP SD 的可用性检查Availability Check。它只回答一个问题客户要货的那一天这个物料在这个工厂里还剩多少可承诺的量。需求传递Transfer of Requirements回答的是另一个问题这张订单一确认它该不该变成 MRP 眼里的一个需求进而被采购、生产和计划看到。这两个动作经常被当成一回事实际上它们各有各的开关。上线后遇到的「库存明明有订单还是被推期」「MD04 里翻不到销售需求」「采购提前买了不该买的料」十有八九是这两条链路里某一环配错了。下面按「物料检查组 → 检查规则 → 检查范围 → 需求类型 → 需求类别 → 计划行类别」的顺序把配置、下单验证、排错和进阶控制依次拆开讲做 SD 的顾问能直接抄配置做 MM/PP 的能看懂需求为什么出现在自己的清单里。2. SAP SD 可用性检查的配置链路检查组、检查规则与检查范围2.1 物料主数据 MRP3 的检查组01、02 与留空代表什么可用性检查的起点不在销售订单里而在物料主数据的 MRP3 视图。字段名叫「可用性检查」存在 MARC-MTVFP 里取值就是检查组。它决定两件事这个物料在 SD 侧做不做检查以及可用量按什么时间粒度汇总。常见取值三种。01 是按日汇总检查同一物料同一天的所有需求合并成一天的量系统按天算净需求确认日期通常落到天02 是逐笔需求单独检查粒度更细会结合工作日历、计划交货时间和收货处理时间来算具体日期按单生产或者交期紧的场景更常用。留空表示该物料在 SD 侧不做可用性检查销售订单行直接确认——但需求传递仍然可以发生这两件事是解耦的。提示检查组维护在工厂层同一个物料在 1000 工厂做检查、在 2000 工厂不做检查是完全合法的配置也正是「换个工厂下单就正常了」这类问题的根源。项目上线前的数据清理阶段我一般会跑一个报表把没维护检查组的物料全捞出来比一个个 ME03 翻快得多。REPORT zsd_atp_check_mtvfp. DATA: lt_marc TYPE TABLE OF marc, ls_marc TYPE marc. SELECT-OPTIONS: s_werks FOR marc-werks OBLIGATORY. MTVFP 就是 MRP3 视图的「可用性检查」字段即检查组 SELECT matnr werks mtvfp FROM marc INTO TABLE lt_marc WHERE mtvfp space 检查组为空SD 侧不会做 ATP AND lvorm space 排除打删除标记的物料 AND werks IN s_werks. IF lt_marc IS INITIAL. WRITE: / 所选工厂下没有检查组为空的物料. RETURN. ENDIF. LOOP AT lt_marc INTO ls_marc. WRITE: / ls_marc-matnr, ls_marc-werks, 检查组为空订单会被直接确认. ENDLOOP.这段代码的关键在 WHERE 条件mtvfp space是主条件lvorm space是为了不把已停用物料算进清理清单否则报表出来几百条你还要手工剔。跑出来的清单要么去补检查组要么确认这个物料本来就不参与 ATP两种处理都比留着空白强。2.2 检查规则怎么分配检查范围决定净需求算哪些单据检查组解决「做不做、多细」检查规则解决「按什么业务场景做」。配置路径是销售和分销 → 基本功能 → 可用性检查和需求传递 → 可用性检查 → 分配检查规则到销售凭证类型把规则分配给凭证类型销售订单类型一般配 A交货单配 B生产订单配 PP常见做法如此具体看你系统的规则清单。这样一来同一张销售订单在 SD 侧和后续交货环节用的是不同规则检查结果允许不一致。真正决定 ATP 算得准不准的是检查范围它由「检查组 检查规则」的组合共同决定在后台按组合维护勾选哪些单据参与净需求计算。这里勾错一个业务上就是真金白银的差异。检查范围要素打开后的效果什么时候该关掉非限制库存最基础的供给一般必勾几乎不关采购订单 / 采购申请收货在途和已申请的量算作未来供给采购申请尚未审批时不希望被占用可只留采购订单计划订单 / 生产订单生产侧的在制量计入供给计划订单只是粗能力预估、变动频繁时慎用销售订单需求已确认未发货的需求参与占用一般不关否则会出现超卖交货需求已创建交货单但未过账的需求占用库存一般不关相关预留 / 依赖需求按单生产的上层需求占用下层与按单生产MTO策略相关差异的典型表现是只勾了库存、没勾采购订单收货下周明明有采购到货ATP 也不认客户订单被硬推到下下周。反过来把没审批的采购申请也算成供给销售会一直超卖等到采购申请被拒才发现没货。这两类投诉我都见过处理方式都是回到这个勾选界面按业务实际的「承诺口径」重新对一遍。2.3 用 CO09 验证可用性检查是否生效配置改完不要直接拿真实订单试。CO09可用性总览是专门用来单点验证的工具输入物料、工厂、检查规则、需求日期范围和单位它会列出可用量、已确认量、ATP 数量以及按天或按需求列出的分配明细。它是从 SD 视角算的跟 MD04 从 MRP 视角看的清单互补。验证顺序建议固定成三步先看 CO09 里有没有把这个物料算进来如果完全没有结果回到 2.1 检查检查组再看可用量的组成对不对如果采购订单没被算进去回到 2.2 检查检查范围最后拿一张测试订单按客户的要求日期下单看确认日期是否和 CO09 推算的一致。三步走不通的基本能定位到具体是哪一层配置没生效。3. 需求传递的完整链路需求类型、需求类别与计划行类别3.1 项目类别 → 需求类型 → 需求类别三层确定关系可用性检查管的是「能不能承诺」需求传递管的是「承诺之后要不要变成 MRP 的需求」。链路比 ATP 长一层销售订单行先拿到项目类别VOV7 维护TAN、TAK 这类项目类别在配置里被分配一个需求类型分配界面的常见事务码是 OVZI需求类型本身在 OVZG 里定义需求类型再挂到一个需求类别上OVZH 定义。层级维护对象决定什么项目类别VOV7 / 表 TVAP用哪个需求类型、是否与采购/生产联动需求类型OVZG / 确定表归入哪个需求类别取值如 KE、KV 一类以你系统为准需求类别OVZH需求传递开关、是否消耗计划独立需求、按库还是按单计划行类别VOV6是否做可用性检查、是否需要采购申请或计划订单需求类别是这条链路上权力最大的一层。它决定需求到底传不传勾了传递订单确认后才会在 MRP 里出现不勾SD 侧该做 ATP 还做但 MD04 里看不到这张订单采购和生产不会被动起来。它还决定需求是消耗计划独立需求按库存生产常见还是不消耗按单生产常见。注意需求类型、需求类别的取值在不同行业方案和项目里被改写过别背代码号。打开 SE11 看 T459K 这类配置表的字段结构比记住某个具体值靠谱得多。REPORT zsd_show_table_fields. DATA: lo_descr TYPE REF TO cl_abap_structdescr, lt_comp TYPE abap_compdescr_tab, ls_comp TYPE abap_compdescr. 用 RTTI 把配置表的字段列出来避免靠记忆猜字段名 lo_descr ? cl_abap_structdescrdescribe_by_name( T459K ). lt_comp lo_descr-components. LOOP AT lt_comp INTO ls_comp. WRITE: / ls_comp-name, ls_comp-type_kind, ls_comp-length. ENDLOOP.把表名换成 T459A、TVEP、TVAP同样能列出字段。做配置对照之前先看结构能省掉大量「SELECT 报字段不存在」的返工。3.2 计划行类别 VOV6 里的两个开关可用性检查与需求传递销售订单项目的计划行存在 VBEP 里计划行类别在 VOV6 维护常见取值 CP正常交货、CN、BN 一类。它管三个层面这一计划行要不要做可用性检查、交货时用哪个移动类型、如果要产生后续单据那么是采购申请还是计划订单。可用性检查的开关在这里的体现最直接计划行类别上的可用性检查标识留空ATP 就完全不触发CO09 里再怎么测都不会有反应。这也是「同样的物料、同样的订单类型换个计划行类别结果就变了」的原因。另一个开关决定需求是否传递、以及是否要生成采购申请或计划订单第三方销售、按单采购这类场景基本都靠它。同一个项目可以有多条计划行这是分批交货的实现方式近期一批、远期一批每条计划行各自做检查、各自给出确认数量。客户要求的 100 个被拆成「下周 60、下月 40」就是部分确认的结果不是系统出错。3.3 需求落到哪里VBBE、VBEP 与 MD04 的对照需求传递完成后会落到 VBBE单笔需求记录MRP 在算净需求时读的就是它。三个地方要对得上VBEP 是计划行本身含确认日期和确认数量VBBE 是传递出去的需求记录MD04 是把库存、采购、生产、销售需求放在一张清单里的 MRP 视图。REPORT zsd_order_req_trace. PARAMETERS: p_vbeln TYPE vbeln_va. DATA: lt_vbep TYPE TABLE OF vbep, lt_vbbe TYPE TABLE OF vbbe, ls_vbep TYPE vbep, ls_vbbe TYPE vbbe. 计划行确认了什么 SELECT vbeln posnr etenr edatu wmeng bmeng FROM vbep INTO TABLE lt_vbep WHERE vbeln p_vbeln. 需求记录传出去了什么。字段名以 SE11 里 VBBE 的定义为准 SELECT * FROM vbbe INTO TABLE lt_vbbe WHERE vbeln p_vbeln. WRITE: / 计划行 / 确认日期 / 确认数量. LOOP AT lt_vbep INTO ls_vbep. WRITE: / ls_vbep-vbeln, ls_vbep-posnr, ls_vbep-etenr, ls_vbep-edatu, ls_vbep-bmeng. ENDLOOP. WRITE: / 需求记录 / 物料 / 工厂 / 需求日期. LOOP AT lt_vbbe INTO ls_vbbe. WRITE: / ls_vbbe-vbeln, ls_vbbe-posnr, ls_vbbe-etenr, ls_vbbe-matnr, ls_vbbe-werks, ls_vbbe-mbdat. ENDLOOP.VBEP 有值、VBBE 没值说明 ATP 做了但需求没传往需求类别的传递标识上查VBBE 有值、MD04 看不到往物料 MRP 类型和工厂层配置上查。4. 从下单到备货确认日期被推后与需求不传递的实战排查4.1 确认日期被推后的五个高频原因被推期是可用性检查最常见的投诉但原因分散在配置和数据两头逐个排除比拍脑袋改配置快。现象首要排查点处理动作库存有货却推期检查范围是否包含未清销售需求、交货需求打开对应要素重新算净需求采购即将到货仍推期检查范围是否包含采购订单收货勾上采购订单必要时含采购申请只是个别客户被推期该客户的历史未清订单是否占用了同一批库存用 CO09 看需求明细里的占用来源换工厂下单就正常物料在目标工厂的检查组是否为空补 MRP3 视图的可用性检查字段全部日期都往后跳一天检查组是 01按日还是 02按需求收货处理时间按业务需要的粒度调整检查组前两条属于配置问题改完对已有订单不生效需要靠后续重排或者手工重算确认日期后三条属于主数据问题补完之后新订单立刻正常。4.2 需求没进 MD04按链路逐段排需求传递没生效排查顺序要和配置顺序反过来走从最靠近结果的一端开始。第一步看 VBBE 有没有记录用 3.3 的报表没有记录说明传递环节断了继续往下。第二步看计划行类别上的需求传递标识是否为空。这一步最容易被忽略因为订单在 SD 侧看起来一切正常确认日期也有。第三步看需求类别上的传递标识以及这个需求类别是不是「不参与 MRP」的那一类。有些项目专门建了一类只做 ATP、不传需求的类别用于样品、赠品、内部消耗这类场景配错了就会让正常业务订单也不进 MRP。第四步回到物料主数据MRP1 视图的 MRP 类型如果是 ND无 MRP需求会被直接拦掉VBBE 里可能仍然有记录但 MD04 里不会形成计划。这种情况在「这个料不用跑 MRP采购自己看着买」的项目里经常被埋进去事后非常难查。第五步确认工厂和存储地点。销售订单行的工厂字段如果被用户改成了另一个工厂需求就落到那个工厂去了MD04 在原来的工厂里当然看不到。4.3 MD07 集中监控与超额确认的控制点MD07集中库存需求清单适合每天批量跑一遍按工厂、MRP 控制者或者物料范围筛选一次看全部物料的供需情况比一个个 MD04 快得多。日常运维里我一般让关键用户每天早上跑一次 MD07 看缺料预警销售侧的异常需求也在同一张清单里暴露出来。超额确认是另一个要盯的点。ATP 允许确认数量超过可用量系统里有对应的控制好处是接单灵活坏处是超卖风险直接转嫁给生产和采购。判断标准是业务能承受多少延期而不是技术能不能配。提示把检查范围、检查组、需求类别这三个配置项截图存档每次有人投诉交期问题先拿这三张图跟现状对一遍比翻配置记录快。5. 进阶用 ATP 用户出口和重排把确认结果控在自己手里5.1 ATP 用户出口里能改什么不能改什么标准 ATP 算出来的确认日期和数量不满足业务规则时用户出口是第一个选项。函数组 V03A 下有 ATP 相关的出口常见的是 EXIT_SAPLV03A_001、002 这一类用 SE37 查它当前的实际接口和参数不同版本会有差异。典型用途是按客户优先级、按信用等级、按物料组重新分配有限的可用量比如把同一批库存优先承诺给战略客户。 结构示意真实参数名、内表名以 SE37 里 EXIT_SAPLV03A_001 的定义为准 INCLUDE zxv03u01. DATA: ls_line TYPE ty_confirm. 遍历 ATP 给出的确认行按业务规则重排日期或数量 LOOP AT it_confirm INTO ls_line. 高优先级客户在系统给的确认日期基础上再提前 实际项目里要用工作日历函数换算不能直接减天数 IF ls_line-prio 01 AND ls_line-edatu IS NOT INITIAL. ls_line-edatu ls_line-edatu - 7. MODIFY it_confirm FROM ls_line. ENDIF. ENDLOOP.两条纪律必须守住出口里不要写大表的 SELECTATP 在保存订单时每次都会调性能问题会直接反映到用户端不要在出口里更新数据库确认结果由系统自己落库手工插一脚会导致 VBEP 和 VBBE 对不上这种数据不一致事后极难修复。5.2 重排 V_V2 与 aATP 的边界配置改完、库存到货之后已有订单的确认日期不会自动变好需要用 V_V2 做重排backorder rescheduling把受影响的订单按新的供给情况重新确认一遍。跑之前先限定销售组织、日期范围和凭证类型全量跑一次在订单量大的系统上会很慢而且会改动大量订单业务侧要有心理准备。做到 S/4HANA 上传统的检查组、检查规则、需求传递这套配置依然生效同时在它之上多了一层替代确认策略、产品分配、预测性可用性检查这类能力。判断用不用新特性的标准很实际如果痛点是「同一批货给谁」和「产能怎么在订单之间分配」值得评估如果只是想把交期算准把检查范围和需求类别这两处配对比什么都管用。真要动手优化之前先让 CO09 的确认结果、VBBE 的需求记录和 MD04 的清单三处对齐再谈策略调整否则问题只会在采购和计划那边以另一种形式冒出来。本文还有配套的精品资源点击获取