企业官网建设流程全解析

前面写的几篇JIT相关分享，一直在后台收到朋友留言，问能不能把SAP MM模块里JIT这块从头到尾串一遍。说实话，JIT在MM里是一个很容易绕晕的专题，因为它横跨了采购主数据、计划协议、物料需求计划、信息输出好几个领域，而且不同行业的做法差异很大。踩了很多坑之后，我打算把从计划协议到JIT供应这条链路完整梳理一遍，结合项目上的配置经验和排错记录，给正在做供应链或者SAP实施的朋友一份可以照着走的实战参考。

1. 先弄清JIT在SAP MM里的定位：为什么是计划协议，而不是采购订单

1.1 从一张标准采购订单说起

在传统MM采购流程里，采购订单是核心单据，一次性或者分批采购，供应商按订单交货。但有一种业务场景，需求和供应商之间是长期、稳定、高频的，比如汽车主机厂和一级供应商之间的零部件供应。车间每天按生产节拍消耗物料，如果每批需求都下一张采购订单，采购员会被单据淹死，计划员也没法及时把看板式的拉料信号传递给供应商。

这时候就需要一套用长期框架协议承载、按需释放供货指令的机制。SAP里的计划协议（Scheduling Agreement）就是这样一种采购单据，它不需要针对每次到货创建PO，而是通过计划行来记录每个时间点的需求数量和到货日期。而JIT，恰恰就是在这个框架协议基础上，把供货节奏细化到以小时甚至分钟为单位的拉动式供应模式。

熟悉SAP的人应该知道，从单据类型上看，计划协议和采购订单是并列的两种采购凭证。你用ME31L可以创建计划协议，用ME33L可以修改，用ME35L可以批量审批。计划协议的每一行都有计划行，这些计划行就是供应商交货的时间表。JIT在这条链路上做的事，就是把MRP算出来的需求，以JIT交付计划的形式，直接释放给供应商，同时触发后续的收货、发货和结算。

1.2 JIT和传统计划协议的核心差异

很多人会把计划协议和JIT当成一回事，其实两者有关联，但落脚点不同。计划协议解决的是“长期框架+分批交付”的问题，JIT解决的是“如何更精细化地指令供应商”的问题。

传统计划协议的计划行，通常只是MRP计算后自动生成的供货时间点，供应商按计划行交货，严格来说还是偏推式。而JIT是明确的拉式逻辑，它基于生产消耗或生产订单的实时需求，生成JIT交付计划并传送给供应商。供应商按JIT呼叫发料，物料到线边后直接上线，库存水平极低，这就是JIT存在的意义。

用生活里的场景打个比方：传统计划协议就像你和食堂阿姨说好，未来一个月每天中午都来吃饭，阿姨会每天准备饭。但具体到今天的菜量、几点来吃、吃几碗，都还是大概估计的。JIT就是到了当天，你给阿姨发一个“11点45分到，一份红烧肉、二两米饭”的通知，阿姨按这个精确指令出餐，既不浪费也不缺量。供应商侧也一样，收到JIT交付计划后，按分钟级的时间窗配送，到厂直接上线，库存周转被压缩到极致。

1.3 什么情况下才需要做JIT

这个判断很关键。我见过不少项目，业务上明明只是月度批量采购，却非要上JIT，最后搞得很痛苦。JIT适合场景有几个典型特征：需求相对频繁、供应商距离近或响应能力强、物料本身价值高或体积大不适合囤库存、生产线有明确的节拍和排序需求。汽车、电子、家电这三大行业是JIT的高频使用区。

如果只是月度下单、周度收货，那用普通的计划协议或框架订单就够了，没必要专门做一套JIT主数据和输出配置。反过来，如果业务方明确要求供应商按“线边呼叫”送货，并且对计划行时间有精确到分钟的要求，那JIT就是绕不开的方案。判断的基准不是系统能不能配，而是业务的供给响应模型是不是真的到了“按需即时拉动”的成熟度。

2. 前置准备：JIT落地前的主数据与基础配置

2.1 这四条主数据缺一不可

JIT真正跑起来之前，有几类主数据必须提前备齐，缺一条都会在测试阶段暴露问题。

第一类是供应商主数据。供应商需要在采购视图里维护好，并且要把供应商和工厂、采购组织的关系建立清楚。JIT场景下，供应商主数据的“JIT标志”通常要在采购数据里勾选，这个标志决定了系统在后续流程中是否允许对该供应商使用JIT相关的输出类型。

第二类是物料主数据。MM模块JIT对物料主数据的依赖非常高，尤其是MRP视图里的采购类型、特殊采购类、计划交货时间、GR处理时间这几个参数，直接影响计划行的生成精度。另外，如果要做JIT的精细化管理，物料主数据里还需要维护好JIT相关的控制字段，这些字段决定了该物料是否允许按JIT交货计划模式运作。

第三类是工厂参数。JIT运行基于工厂级的设置，所以工厂必须启用JIT相关的控制，比如允许对特定供应商使用JIT交付计划，设置JIT运行的时间单位等。这些不是在物料层面单独放开的，是在工厂维度和供应商维度同时满足，JIT才会被激活。

第四类是计划协议。计划协议的框架编号在JIT流程里是贯穿始终的。JIT交付计划不会单独生成一张新单据，而是挂在计划协议行项目下面，作为计划行的细化版本存在。这就是为什么JIT不能脱离计划协议单独运行——JIT只是计划协议计划行的“精确化触发”，框架本身依然是计划协议。

2.2 必须提前理清的三个号码范围

SAP的JIT交付计划在系统里有独立的单据号码范围。我遇到过一个坑：配置手册里只写了计划协议号段，没提JIT号段，结果生产机上一跑JIT，系统直接报“号码范围未定义”，卡了一个下午。

JIT相关的号码范围主要涉及三类单据：JIT交付计划本身（JIT Call）、JIT交付计划的确认回传（Confirmation）、以及JIT运行相关的监控凭证。这些号段通常在IMG里通过VN1、VN2这些事务码维护，前提是SAP的JIT相关组件已经被激活。如果你的系统里连JIT号码范围的事务码都找不到，先检查一下行业解决方案里是不是激活了“JIT”这个业务功能，很多S/4 HANA的默认激活范围并不会自动带出JIT的全部功能。

2.3 激活JIT功能的IMG路径怎么走

JIT功能激活后，需要到IMG里做基础设置。核心路径是“物料管理-基于消耗的计划-JIT调用”，这里有一个总开关叫做“激活JIT调用”。这个开关勾上之后，你才能看到后续的JIT控制参数文件、JIT交付计划输出、JIT结算等配置项。

另外，JIT通常会和“交货计划”的日程行（Schedule Line）联动，所以你在配置计划协议计划行类型的时候，一定要确认分配给计划协议的计划行类别是支持JIT日程的。如果计划行类别没有打开日程行维护的开关，JIT呼叫生成时会提示找不到可用的计划行类型。这个点非常隐蔽，很多顾问前期忽略，测试阶段才暴露。

2.4 一些隐蔽但影响全局的配置细节

JIT控制参数文件是JIT运行的核心参数载体，事务码一般是JITCC，或者通过事务码JIT3里的“配置JIT调用控制参数文件”进入。参数文件里需要定义的东西很细，包括：JIT交付计划的编号策略、打印/输出格式、计划时间单位（是精确到分还是小时）、是否允许JIT状态回传、是否生成两次供货JIT（即前二次调用）等等。

这些参数看着不复杂，但直接影响业务侧的操作体验。比如时间单位如果配置成“天”，供应商收到的JIT交付计划只有日期没有具体时分，那JIT的意义就大打折扣了。再比如JIT确认回传的时间间隔，如果配置不合理，供应商通过SRM或EDI回了确认，但系统里迟迟没收到状态更新，计划员就会一直打电话跟供应商核对“到底送不送、送多少”。

在S/4 HANA环境里，还可以考虑启用Fiori的JIT处理应用，用App来替代部分ECC时代的GUI事务码。JIT相关的Fiori应用在S/4里已经有了标准覆盖，如果你项目上正在做S/4升级，这是一个值得调研的方向。

3. 核心流程实操：从计划协议创建到JIT供应的完整闭环

3.1 第一步：用ME31L创建计划协议并维护计划行

计划协议有两种类型，一种是针对外部供应商的标准计划协议，事务码是ME31L或ME32L维护；另一种是寄售补货计划协议，事处码一般是ME31K。JIT场景下，绝大多数用的是标准计划协议。

ME31L创建计划协议时，选择供应商、工厂、采购组织，然后输入物料、数量、交货日期。注意这里的“数量”只是计划的初始数量，后面MRP运行后系统会根据需求自动刷新计划行。计划行里的“交货时间”字段很关键，这对应的是JIT交付计划的时间点，可以精确到秒。如果你发现ME31L里计划行没法维护精确时间，检查一下计划和工厂日历的时间粒度设置，以及物料主数据MRP1视图里的“计划交货时间”是否维护。

计划协议创建之后，还需要在协议行项目上维护“JIT交货计划”标识。这个标识如果不打，后续运行JIT呼叫时，系统会认为该计划协议不支持JIT，直接报错或者静默不生成呼叫。我见过一个项目，顾问遗漏了这个标识，结果MRP跑完了，JIT交付计划一张都没出来，排查了很久最后发现就是这个勾没打上。

3.2 第二步：MRP运行生成精确计划行

计划协议创建好后，日常的补货逻辑就交给了MRP。JIT场景下，MRP的运算结果会直接生成新的计划行，计划行上会有精确的到货时间。这里建议用MD01或者MD02运行MRP时，重点关注计划协议的“计划行”更新结果，用MD04去看物料供需情况最直观。

在MD04的库存/需求清单里，可以看到计划协议行项目下的计划行，每一行都有日期、数量和收货状态。JIT模式下，这些计划行就是后续JIT交付计划的源头。如果你发现MRP运行后计划协议的计划行没有按预期的JIT时间点生成，先排查一下物料主数据里的“MRP类型”是不是可以维护计划行，以及计划协议里是否勾选了“无需MRP”之类的反向选项。

有时候MRP算出来的计划行时间是系统按计划交货时间偏移出来的，但如果业务上需要的是按车间呼叫的实际时间，那MRP只能作为粗排，真正的精细时间要靠JIT交付计划的下达来修正。这就好比火车先有运行图，但真正到点开车、到站停车，还需要调度命令细化。

3.3 第三步：JIT交付计划生成与释放

计划行准备就绪后，JIT的核心动作就是把计划协议的计划行“转换”成JIT交付计划并释放给供应商。这一步在系统里通常通过事务码JIT1或JIT2来操作。JIT1是直接创建JIT交付计划，JIT2是处理JIT交付计划的状态更新。

运行JIT交付计划时，系统会按你在JIT控制参数文件里设置的时间窗口，从计划协议的计划行里抓取满足条件的需求，生成一条JIT交付计划记录，同时触发输出类型（通常是EDI或者打印）。这里有个细节：JIT交付计划生成后，计划协议原计划行的状态会变为“已消耗”或“已确认”，避免同一需求被重复释放。如果你看到计划协议计划行数量一直没变化，检查JIT交付计划的释放逻辑或者计划行状态更新条件。

释放JIT交付计划时，输出方式有两种主流方式。一种是通过SAP的输出控制（NACE）配置输出类型，比如JIT调货EDI输出到供应商系统；另一种是直接打印标准的JIT交付计划单据，传真或扫描给供应商。在汽车行业，大多数总装厂会用EDI方式，直接把JIT交付计划推送到供应商的SRM或者MES系统，全程无纸化。如果项目预算有限，先做打印方案也是可以的，核心是输出类型要绑定在JIT交付计划的“输出”里。

3.4 第四步：供应商确认与JIT状态管理

JIT不只是发出去就结束了，供应商的确认回传也是JIT流程里非常重要的一环。供应商收到JIT交付计划后，需要通过EDI、供应商门户或人工方式，返回一个确认信息，告诉主机厂“这份JIT我收到了，计划在某时送达多少数量”。这个确认信息在SAP里会更新JIT交付计划的状态，状态从“已释放”变成“已确认”。

在SAP系统里，JIT交付计划的状态更新通常用事务码JIT2或者通过EDC/IDoc的入站处理自动完成。如果供应商是通过EDI/IDoc回传的，那就要确保IDoc的端口配置、合作伙伴配置文件都正确。失效的IDoc或者错误的合作伙伴参数，都会导致确认状态更新失败。有一个现场问题排查技巧：用WE02或WE05去看IDoc状态，如果IDoc状态卡在51（已应用但未处理）或者64/65之类的异常状态，那就是出站或入站处理的配置不对，优先检查伙伴参数里JIT相关消息类型和处理的分配。

3.5 第五步：收货、发票校验与JIT结算

JIT的最终闭环还是落在收货、发票和结算上。供应商按JIT交付计划送到工厂后，仓库或产线做收货，移动类型通常是101（采购订单收货）或者103+105（收货到冻结库存再转到非限制库存）。收货过账后，库存进入可用状态，财务侧形成应付暂估。

发票校验这一环，JIT和普通采购区别不大，仍然用MIRO来处理。但如果供应商是按JIT交付计划逐笔对账的，那发票校验时可以参照计划协议号、逐行核对JIT交付计划数量和收货数量。我建议在项目里为JIT供应商单独设一个发票校验的容差配置，因为JIT送货批次多、单批金额可能不大，如果按常规的金额容差设置，很容易因为小额差异被卡住，影响月底对账。

JIT结算的方式有两种可选。一种是对JIT交付计划结算，系统会汇总计划协议的计划行，生成结算凭证；另一种是直接将收货数量作为结算依据，按收货值结算。选哪种，取决于你项目上财务和采购对账的颗粒度要求。如果是按月汇总对账，模式一更常见；如果是按批次精细对账，模式二更直接。

3.6 一个典型的JIT全流程跑通示例

假设某汽车零部件厂的物料A，供应商是B公司，采用JIT供货，流程大致是这样：

计划员在ME31L里创建一份计划协议，编号，行项目里维护物料A，初始数量写一个月预估用量，同时勾选JIT交货计划标志。系统里MRP运行后，MD04里能看到物料A的计划协议计划行，按天或按班次生成了到货需求。到了需要精确给供应商下达指令的时刻，计划员运行JIT交付计划生成，系统抓取未来数小时内的计划行，生成一条JIT交付计划，同时通过输出类型把消息推送出去。供应商B收到JIT交付计划，在系统里反馈确认，主机厂生产计划员通过JIT监控界面看到状态已确认。到货时，仓库按JIT交付计划对应的收货单做101收货，货物直接拉到线边。月底，财务汇总计划协议下的收货和发票，做发票校验和结算，整个JIT闭环完成。

这个流程看起来简单，但每个环节都有配置项在起作用。缺少任何一个前置设置，这个闭环都可能跑不通。

4. 常见问题与排查技巧实录

4.1 JIT交付计划无法生成

这是出现频率最高的问题。排查时先看计划协议行项目是否勾了JIT标志，再看计划行是否有有效的计划行日期和数量，接着确认JIT控制参数文件是否存在并分配给了物料或供应商，最后看输出类型有没有正确配置。

这里有一个容易忽略的点：JIT交付计划生成时，系统是按“计划行日期”来抓数据的。如果计划协议的计划行日期是过去的时间，系统会认为没有可用的JIT需求，直接不生成交付计划。所以遇到这种情况，先回去看MD04里的计划行日期，不要一上来就怀疑配置问题。

4.2 供应商确认状态一直没有更新

分成两种情况：EDI自动回传的，优先检查IDoc状态和合作伙伴参数，尤其是JIT消息类型在出站参数里是否指定了处理程序。人工确认的，检查一下是不是确认事务码用错了，或者JIT交付计划的状态已经被人为改过，导致系统不接受新的确认。

还有一点，有些项目会启用JIT交付计划的“两次JIT”模式，也就是提前发一个预告（前次JIT），临近再发一个精确确认（二次JIT）。在这种模式下，确认状态更新的逻辑会复杂很多，如果配置了两次JIT，但供应商只回了一次确认，系统可能不会把状态推到最终确认。这种问题排查起来更费时间，所以配置之前就要和业务确认清楚JIT的调度模式，不要套默认值。

4.3 输出类型没有触发或重复触发

输出没触发，先看输出确定（NACE）里JIT交付计划的输出类型是否在正确的调用点配置了，JIT相关输出通常在调用点“JIT调用”上。再看输出类型的条件记录里，供应商、采购组织、工厂这些组合条件是否都命中了。

重复触发的情况也见过不少。比如一张JIT交付计划生成了两次，供应商收到两份一模一样的指令，这种情况多半是计划行状态没有在第一次JIT生成后被正确锁定。解决思路是在JIT控制参数文件里勾选“已释放计划行作为已消耗”，确保同一计划行只能参与一次JIT交付计划生成。

4.4 JIT相关表与常用报表

JIT问题定位时，有几个表和事务码值得记住。JIT交付计划抬头和行项目的数据存储在JITDD和JITDI等表里，业务人员常用的JIT监控是事务码JIT3或者JIT4，可以看JIT交付计划的整体状态和释放明细。想追溯JIT交付计划和计划协议之间的关联，可以在事务码JIT3里通过计划协议号反查，也可以在ME32L里选中计划协议行，看行项目明细里的JIT交付计划记录。

如果项目上线后需要做JIT运行审计，比如查哪些计划行被释放过、供应商确认状态如何，直接通过这些表写报表会比在GUI里翻找高效得多。我在项目上实现过一个JIT状态监控报表，核心逻辑就是抓JITDI表的状态字段，和计划协议的ME5J计划行做关联，半小时能搞定，对业务日常监控帮助很大。

4.5 多工厂、跨公司JIT的特殊处理

JIT如果只在一个工厂内部跑，相对简单。但如果集团下有多个工厂，共享同一批供应商，有些工厂做JIT，有些工厂不启用，那配置上就需要按工厂隔离。供应商主数据里JIT标志如果开了全局，所有工厂都会受影响。正确做法是利用采购组织+工厂层级的条件，把JIT控制参数文件和输出类型控制在特定范围内，避免“误伤”非JIT工厂。

跨公司的场景更复杂，涉及到公司间交易、定价、发票等逻辑，JIT本身不会改变这些基础逻辑，但因为JIT交货频次高，如果每笔跨公司JIT都要出一次公司间发票，财务的发票量会非常大。实务上可以考虑启用在途库存和寄售JIT的组合方案，把跨公司JIT的财务处理频次降下来。这块如果项目涉及，建议财务顾问和MM顾问一起评审，不要单边拍板。

4.6 上线切换时JIT数据的迁移思路

JIT上线切换，除了主数据迁移，还有一个核心问题：未完成JIT状态的切换。如果旧系统里已经发出了一部分JIT交付计划，供应商也已经按计划备货了，不好在切换日直接清零重跑。

我建议的做法是，在切换前跑一次JIT交付计划全量清单，区分“已确认未交货”“已交货未开票”“未释放”三种状态，分别处理。已确认未交货的，在新系统里重新创建计划协议并手动补释放JIT交付计划；已交货未开票的，财务按收货做暂估和发票校验；未释放的，直接批量运行JIT交付计划生成，不用手工逐条去调。这个切换方案虽然前期准备工作量大，但能最大程度保证切换日后的JIT供应不断档。

5. 经验心得：JIT实施中最值得留意的三个原则

第一，JIT不是一个纯MM模块的独立功能，它和PP、SD、LE、FICO全链路耦合。项目上排计划的时候，JIT相关的设计评审一定要拉上PP顾问和LE顾问一起，否则物流执行环节或者生产排程环节和JIT交付计划之间很容易出现断层。

第二，JIT的配置规模不一定要大，关键在精准。很多项目一上来就配了一堆JIT控制参数文件、输出类型、状态处理逻辑，结果业务上只有少数几条产线在用。配置越多，后面运维的复杂度越高。我一般建议先在试点产线跑通，再横向复制，不要一次性全域铺开。

第三，JIT上线最大的难点其实不在SAP配置，而在供应商的响应能力。SAP里的JIT交付计划只是一个指令下发工具，供应商能不能按分钟级的时间窗送达，取决于供应商内部的计划体系、物流能力和备货策略。SAP顾问能做的，是把指令清楚、稳定、及时地发到供应商侧，后续的供应链协同能力，需要采购部门和供应商一起推动建设。

最后再分享一个我个人的操作习惯：JIT配置完成后，一定会在测试环境做一次从计划协议创建到供应商确认回传的端到端验证，而且特意把每步之间的时间间隔调成最小，观察计划行状态变化是否满足预期。这一步虽然耗时，但很多在配置界面里看不出的隐性逻辑问题，都会在这轮验证里现出原形。JIT这种业务流程，一旦上线，就是在真实的供应链节奏里跑，容错率很低，前期的校验工作做得越细，后期的运维就越省心。