企业官网建设流程全解析

简介：这份资源围绕SAP MM模块中的供应商寄售业务展开，面向已具备一定物料管理基础、需要掌握寄售采购全流程配置与操作的SAP顾问及企业关键用户，帮助理清寄售模式下库存不计成本、按实际耗用结算的特殊处理逻辑。资源包共1个doc文档，约123KB，以文字形式系统梳理从物料主数据维护、供应商与信息记录创建，到寄售功能激活、采购申请与订单、101收料、411K库存转移及MRKO发票校验的完整链路，并针对412K冲销、消息管理报错等常见问题给出排错思路，便于对照实操与查漏补缺。目前已有567人学习，适合作为寄售流程的案头参考。

1. 寄售库存：为什么收了货却不记成本

SAP MM 里有一个反直觉的现象：采购订单做了 101 收货，物料凭证生成了，库存数量也上去了，但 FI 那边干干净净，一张会计凭证都没有。很多刚接触 sapmm 的开发者第一次看到这个结果，第一反应是系统出 bug 了，或者以为凭证被冲销了。其实这正是供应商寄售的核心设计——货进了你的仓库，但所有权还在供应商手里，你只是提供了一个存放地点，所以存货不记成本，负债也不成立。

这个机制解决的是一个很现实的供应链问题：需求波动大、原材料价值高、又不想压库存的场景下，让供应商把货提前放到你的仓库里，用多少结算多少。SAP 用「特殊库存 K」这个标识把寄售库存和自有库存隔离开，数量可见、金额为零，直到你用 411 K 把它转成自由库存，系统才认为这批货真正属于你，这时候才产生会计凭证、才形成对供应商的负债。搞懂这条「所有权转移线」在哪里被触发，就搞懂了整个寄售流程的底层逻辑。

2. 特殊库存 K：寄售库存为什么能「有量无值」

2.1 库存视图的分层：数量账与价值账的分离

SAP 的库存管理在底层把「数量」和「价值」拆成了两套账。MMBE 里看到的库存是数量视图，它来自物料凭证的逐笔累加；而 FI 里的存货科目余额是价值视图，它来自会计凭证。普通采购订单 101 收货时，系统同时写数量账和价值账，所以你会看到物料凭证和会计凭证成对出现。寄售采购订单的项目类别是 K，这个类别在收货时被系统识别为「非估价收货」，于是只写数量账，价值账那一侧直接跳过。

常见的实现思路是，系统在收货过账的定价过程中检查移动类型的「价值更新」标识，同时检查采购订单行项目的项目类别是否属于寄售类。两个条件同时命中，过账程序就不调用 FI 接口，物料凭证的会计凭证字段为空。这不是漏了，是设计上就不该有。所以你在 MIGO 里做 101 收寄售订单，看到「物料凭证已过账」但点不进会计凭证，属于正常行为，别去翻消息日志找错误。

2.2 特殊库存标识 K 在表结构里怎么落地

寄售库存之所以能和自有库存分开管理，靠的是库存段上的特殊库存标识。物料凭证行项目里有一个字段记录特殊库存类型，寄售对应 K，同时还会记录供应商编号，因为同一物料可能来自多个供应商的寄售，必须按供应商维度分开计量。这就解释了为什么 MMBE 里寄售库存会单独一行显示，且带供应商信息。

-- 从物料凭证行项目看寄售库存的标识落地（表名按常见命名示意） SELECT mblnr, -- 物料凭证号 zeile, -- 行项目 matnr, -- 物料号 werks, -- 工厂 lgort, -- 库存地点 sobkz, -- 特殊库存标识，寄售为 K lifnr, -- 供应商，寄售库存按供应商分开 menge, -- 数量 dmbtr -- 金额，寄售收货时通常为 0 FROM mseg WHERE sobkz = 'K' AND mblnr = '4900000001';

这段查询的关键在sobkz和lifnr两个字段。sobkz = 'K'是寄售库存的身份标识，系统所有库存计算、可用性检查、MRP 净需求计算都会先按这个标识分组。lifnr非空说明寄售库存是「按供应商隔离」的，同一个物料两个供应商各放一批寄售，数量不会混在一起。dmbtr为 0 或空，正是「有量无值」在数据层的直接体现。理解这三个字段，你就明白为什么寄售库存既不能被普通预留消耗，也不会进入存货估值。

2.3 物料主数据里的两个开关：采购类型 F 与特殊采购类 10

寄售流程能不能跑起来，第一步卡在物料主数据的 MRP2 视图。采购类型填 F，特殊采购类填 10，这两个字段组合起来告诉系统：这个物料默认走寄售采购。采购类型 F 的作用是让系统在创建采购申请、采购订单时默认带出寄售相关的项目类别；特殊采购类 10 则进一步限定为供应商寄售这种具体形态。

这里有个容易忽略的细节：这两个字段是「默认值来源」，不是「强制约束」。你完全可以在采购申请里手工把项目类别改成 K，即使物料主数据没配 F/10。但反过来，如果主数据配了 F/10，创建采购申请时系统会自动把项目类别带成 K，减少手工出错。我一般建议主数据配好，因为寄售物料往往长期走寄售，默认值能省掉大量重复操作，也避免有人误建成普通采购订单导致收货时产生会计凭证、把寄售货记成了自有存货。

3. 信息记录：寄售流程里最容易被低估的主数据

3.1 为什么寄售订单开立时可以不校验信息记录

普通采购订单创建时，系统会强制校验信息记录是否存在，没有价格就报错。但寄售订单不一样，开 PO 的时候可以没有信息记录，直到 101 收货才校验。这个差异不是随意设计的，而是和「何时需要金额」有关。普通采购在下单那一刻就锁定了采购价格，后续收货按订单价格估价；寄售在收货时货还不属于你，不需要估价，所以下单阶段不需要价格。等到 411 K 把寄售转自有库存时，才需要知道「这批货值多少钱」，这时候才去信息记录里取付款单价。

这个设计带来的直接后果是：寄售订单可以先把数量、交货期谈好，价格后补。但代价是，如果你忘了维护信息记录，收货可能过得去，到 411 转移那一步就会翻车。所以流程上 ME11 建信息记录要尽早做，别等到转库存时才想起来。

3.2 信息记录的「寄售激活」：OMEV 到底改了什么

建完信息记录还不算完，后台还有一个开关 OMEV（物料管理 → 采购 → 使用信息记录激活寄售）。这个配置的作用是让系统在采购订单收货时，主动去信息记录里确认「这是一条寄售类型的信息记录」。如果不激活，系统可能不认这条信息记录的寄售属性，导致收货或后续转移时取不到价格。

常见的实现思路是，OMEV 控制的是一个工厂或采购组织级别的标志位，打开后，系统在处理项目类别 K 的收货时，会额外做一次信息记录的类型匹配。信息记录本身也有一个「寄售」标识，ME11 创建时要选对信息记录类别。这两处必须对齐：信息记录是寄售类型，OMEV 又激活了寄售校验，收货才能顺利通过。只做一半，就会出现「信息记录明明存在，系统却说找不到」的玄学现象。

3.3 信息记录里的税务信息：MRKO 结算的前置条件

寄售的发票校验不走 MIRO，走 MRKO。MRKO 的逻辑是：扫描一段时间内所有 411 K 转移产生的「应结算金额」，按供应商汇总，生成一张结算凭证。它不依赖采购订单收货，而是依赖信息记录里的价格和税务信息。如果信息记录里税务代码、税分类没维护，MRKO 跑的时候要么算不出税额，要么直接报错。

-- 信息记录中与寄售结算相关的关键字段（表名按常见命名示意） SELECT infnr, -- 信息记录号 lifnr, -- 供应商 matnr, -- 物料 ekorg, -- 采购组织 netpr, -- 净价，411 转移时取此价格 waers, -- 货币 mwskz, -- 税码，MRKO 结算必需 knumh -- 条件记录号，指向定价条件 FROM eina WHERE infnr = '5300000001';

netpr是 411 K 转移时计入存货成本的单价来源，mwskz是 MRKO 计算税额的依据。这两个字段任何一个为空，结算链路就断了。很多「MRKO 跑出来金额为零」的问题，根子不在 MRKO 本身，而在信息记录的税码没填。所以建信息记录时，价格和税码要一次性配齐，别分两次补。

4. 从 101 到 411 K：所有权转移那一刻发生了什么

4.1 101 收货：只写数量账的过账路径

寄售订单的 101 收货，项目类别 K 让过账程序走了一条「跳过估价」的分支。物料凭证写入了数量、特殊库存标识 K、供应商编号，但金额字段为空，FI 接口没有被调用。这一步的结果是：MMBE 里寄售库存增加，FI 里没有任何动静。你可以理解为，系统在数量账上记了一笔「代管物资入库」，价值账上什么都没记。

这一步的验证方法很简单：MIGO 过账后看物料凭证抬头，会计凭证那一栏是灰的或者为空；再去 MMBE 看，寄售库存行有数量，非限制库存行没变。如果这时候 FI 里冒出了会计凭证，说明项目类别不是 K，或者物料主数据的特殊采购类没配对，货被当成自有库存收了，这是典型的配置翻车。

4.2 411 K 转移：触发估价的临界点

411 K 是整个流程的分水岭。移动类型 411 本身是「转移过账」，加上特殊库存标识 K，含义变成「从寄售库存转到自有非限制库存」。这一步系统必须回答一个问题：转过来的货值多少钱？答案来自信息记录的净价。于是过账程序调用估价，生成会计凭证：借存货科目，贷寄售暂估或GR/IR 相关科目。从这一刻起，货才算你的，负债才成立。

-- 411 K 转移后的物料凭证，此时金额字段应有值 SELECT mblnr, zeile, sobkz, -- 转移后特殊库存标识应为空 menge, dmbtr, -- 此时应有金额，来自信息记录净价 bwart -- 移动类型 411 FROM mseg WHERE mblnr = '4900000002' AND bwart = '411';

对比 101 那条记录，dmbtr从空变成有值，sobkz从 K 变成空，这两个变化就是所有权转移在数据层的证据。如果 411 过账时系统提示「Pipeline/consignment movement posted without value」，意思就是它找不到寄售类型的信息记录来取价，这时候要回头检查 ME11 的信息记录类别和 OMEV 的激活状态，而不是去改移动类型配置。

4.3 为什么 411 必须有 Consignment 类型的信息记录

411 K 取价时，系统不是随便找一条信息记录就行，它要求信息记录的类型与「寄售」匹配。普通采购信息记录即使价格填了，也可能不被认。原因是系统在估价时按「采购类型 + 特殊库存」的组合去定位价格来源，寄售转移对应的是寄售类信息记录。这个匹配逻辑保证了价格来源的可追溯性：你转的是寄售货，取的就该是寄售协议价，而不是普通采购价。

我一般会这么理解：信息记录在这里扮演的是「寄售协议」的角色，它约定了供应商放货到你仓库期间，你实际耗用时的结算单价。411 转移相当于「确认耗用」，所以必须引用这份协议。协议不存在或类型不对，系统就拒绝估价，宁可报错也不让你用错误的价格入账。

5. 避坑与排查：寄售流程里那些血泪经验

5.1 现象：101 收货生成了会计凭证，寄售库存没增加

原因通常是采购订单行项目的项目类别不是 K，或者物料主数据的特殊采购类没配 10，系统把订单当成了普通采购。收货时走了估价路径，货进了自有库存，FI 也记了账。

解决：先查采购订单行项目的项目类别，确认是 K；再查物料主数据 MRP2 视图的采购类型和特殊采购类。已经错误收货的，需要用 102 冲销后重新按正确类别建单，别试图用 411 去补救，方向反了。

5.2 现象：411 K 过账报「Pipeline/consignment movement posted without value」

原因是系统在转移时找不到可用的寄售信息记录，取不到付款单价。常见于信息记录没建、建了但类型不对、或者 OMEV 没激活寄售校验。

解决：按顺序查三处——ME11 里信息记录是否存在且为寄售类型；信息记录的净价和税码是否维护；OMEV 配置是否已激活。三处对齐后重新过账 411。这个报错是典型的「配置链路断了一环」，别只盯着移动类型看。

5.3 现象：MRKO 结算金额为零或直接报错

根子多半在信息记录的税务信息缺失。MRKO 按信息记录的价格和税码计算应结算金额，税码为空时算不出税额，结算凭证生成失败或金额异常。

解决：回到 ME11 补维护税码和税分类，确认信息记录的有效期覆盖结算期间。补完后重新跑 MRKO。注意 MRKO 是按期间汇总的，补数据后要确认结算期间没有跨期错位。

5.4 现象：想直接冲销 411 K 的凭证，系统不让或者冲完账不平

411 K 产生的会计凭证涉及存货和暂估科目，直接冲销容易把已经结算过的期间搅乱。正确做法是用 412 K 做反向转移，把自有库存退回寄售库存，再做后续的发票校验调整。

解决：先 412 K 冲销转移，再处理 MRKO 的结算差异。这条顺序不能反，反了会出现库存和负债对不上的情况，对账时非常难受。

5.5 现象：寄售订单收货时提示找不到信息记录，但 ME11 里明明有

可能是信息记录的采购组织、供应商、物料三者与订单不完全匹配，或者信息记录已过期。寄售收货的校验比普通订单更严格，因为它要在收货时确认寄售协议有效。

解决：用 ME13 按订单上的供应商、物料、采购组织精确查信息记录，核对有效期和类型。不匹配的补建或修正，别用改订单供应商的方式绕过，那会把库存的供应商维度搞乱。

6. 设计取舍：为什么 SAP 要把寄售做成「两段式」而不是一步到位

寄售流程最值得琢磨的设计取舍，是它把「收货」和「所有权转移」拆成了两步，而不是在收货时就直接确认负债。这个选择背后是对「风险与责任」的划分：货在你仓库里但没耗用之前，灭失风险、质量责任、资金占用都还在供应商那边，你的报表上不该出现这笔存货和负债。101 只记数量，411 才记价值，正好对应这个业务事实。

代价是流程变长、主数据依赖变重。信息记录要在收货前就位，税码要提前维护，OMEV 要激活，任何一环缺失都会在 411 或 MRKO 阶段暴露。这其实是把「配置正确性」的校验推迟到了真正需要金额的时刻，用运行时的报错换取收货阶段的轻量。对比普通采购「下单即锁价」的一步到位，寄售选择了「用时才定价」的灵活，牺牲的是流程的确定性。

验证这套机制是否配对，我习惯用一条最小链路走通：建寄售物料主数据 → 建供应商 → ME11 建寄售信息记录 → OMEV 激活 → ME51N 建项目类别 K 的申请 → 转 PO → MIGO 101 确认无会计凭证 → MB1B 411 K 确认有会计凭证且金额等于信息记录净价 → MRKO 结算确认税额正确。这条链路任何一步的结果和预期不符，就停在那一步查配置，不要往下走，否则错误会层层累积，最后对账时变成黑匣子。

还有一个容易被忽视的取舍是「按供应商隔离库存」。寄售库存必须带供应商维度，这让同一物料多供应商寄售成为可能，但也意味着库存查询、MRP、可用性检查都要多一个分组维度。系统宁可让数据结构复杂一点，也要保证「谁的货是谁的」这件事在账上清清楚楚，因为结算时 MRKO 就是按供应商汇总的，隔离做不干净，结算必然出错。

从那以后我每次配寄售流程，都会先把信息记录的价格和税码当成硬性检查项，过一遍再往下走，因为 411 和 MRKO 阶段的报错，十有八九能追溯到这两处没配齐。希望帮到你。

本文还有配套的精品资源，点击获取