企业官网建设流程全解析

简介：面向SAP MM顾问、采购与仓储业务人员及备考相关认证的学习者，这份文档围绕供应商寄售模式在SAP中的配置与操作展开，重点解决寄售库存不即时计价、收货与发票校验路径特殊等实务问题。包内共1个doc文件，约123KB，篇幅紧凑，适合作为流程速查与要点复盘材料。内容从物料主数据MRP2视图的采购类型F、特殊采购类10切入，串联XK01供应商主数据、ME11寄售信息记录、OMEV激活寄售，以及ME51N采购申请、101收料、MMBE库存查看、MB1B 411K转非限制库存和MRKO发票校验等环节；同时提示寄售收货无FI凭证、411K需Consignment信息记录、结算信息记录须含税务信息，并给出412K冲销后再结算的排错思路。已有570人学习，便于读者快速建立端到端流程框架并规避常见配置与结算错误。

1. 寄售库存：为什么 101 收货动作完成了，财务却一分钱都没动

SAP MM 里有一个让新手很不安的现象：寄售采购订单做 101 收货，物料凭证生成了，库存数量也涨了，但 FI 那边干干净净，一张会计凭证都没有。很多人第一反应是系统出问题了，跑去查科目确定、查过账期间、查物料账，翻车翻了一圈才发现——这恰恰是寄售模式的正确行为。

原因不复杂：寄售库存的所有权还在供应商手里，货放在你的仓库，但它不是你的资产，自然不能进你的存货科目、不能产生应付。这笔钱什么时候才动？等你在 MB1B 里敲下 411 K，把寄售库存转成自己的非限制库存那一刻，系统才认账。搞懂这条「所有权与保管权分离」的主线，后面所有的配置、事务代码、报错信息，就都能串起来了。

2. 所有权分离：寄售模式到底在系统里改了什么

2.1 特殊采购类 10 如何把一张普通 PO 变成寄售 PO

寄售在 SAP 里不是一个独立模块，它是通过「特殊采购类型」这套开关体系嫁接进标准采购流程的。物料主数据 MRP2 视图里两个字段决定了一切：

采购类型 F 只是说「这东西是买的」，特殊采购类 10 才是真正的开关。它会在多个层面产生影响：创建采购申请时项目类别默认为 K（寄售），收货时库存进入特殊库存 K（供应商寄售），收货时不生成 FI 凭证，发票校验不走 MIRO 而走 MRKO。

这里有个容易被忽略的设计细节：特殊采购类的作用是「继承」。你在物料主数据上设了 10，新建 PR 时系统会把它带过来，但如果你手工改掉项目类别，后面整条链路就断了。我一般会这么理解：物料主数据定的是默认值，真正生效的是采购凭证行项目上的那个类别字段，两者不一致时以行项目为准——这也解释了为什么很多「明明主数据配对了却不生效」的问题，最后都出在 PR/PO 的行项目上。

2.2 为什么 101 收货不产生会计凭证：库存科目归属的底层逻辑

正常的标准采购流程，101 收货时系统内部要完成一笔记账：

借：库存科目（BSX） 贷：GR/IR 清账科目（WRX） 借：价格差异（PRD，如适用） 贷：库存科目

寄售收货把这一整套跳过了。原因在于寄售库存虽然物理上在你的仓库，但法律上不构成你的资产，不能进资产负债表。SAP 的处理是给它一个独立的特殊库存标识 K，数量记在物料账上，金额完全不进科目体系。

101 收货（移动类型 101 + 特殊库存 K） 物料凭证：生成 ✓ 物料账数量：增加 ✓ FI 凭证：不生成 ✗ GR/IR：不产生 ✗

这意味着两件事。第一，寄售库存在 MMBE 里能看到，但你查库存价值时它是零——零价值库存，这是很多人第一次看到报表时的困惑点。第二，因为你根本没有产生 GR/IR 暂估，所以标准流程里那套「收货后做 MIRO 冲 GR/IR」的逻辑在这里完全不存在，强行对寄售 PO 做 MIRO 是行不通的。

真正的记账点被推迟到了 411 K 转移那一刻。这时货物的所有权从供应商转移到你，系统才做：

411 K 转移（寄售库存 → 非限制库存） 借：库存科目 贷：寄售负债 / 应付暂估科目

这就是「什么时候确认成本」的答案：不是收货时，是消耗或转移时。财务口径上，寄售是一种延迟确认的采购模式，它的价值在于把库存资金占用压到零，代价是账务链路多了一环。

3. 链路搭建：从信息记录到 MRKO 的完整实现路径

3.1 ME11 信息记录：寄售流程里最不能省的一环

标准采购里，信息记录是「有更好、没有也能走」的定价参考。寄售里它是硬性依赖，而且依赖的时点很反直觉——开 PO 时可以没有，收货时必须有。

这个设计有它的道理。寄售 PO 在创建时只是一个「框架约定」，还没有金额发生，系统不强制校验价格来源；但 101 收货时，虽然不产生 FI 凭证，系统仍需知道这批货值多少钱，以便后续 411 转移时能算出正确的入库金额。这个价格从哪来？就从信息记录来。所以你会看到那条经典报错：

注意：寄售采购订单 101 收料时一定要有寄售的信息记录，否则收货无法完成。

ME11 建信息记录时，采购组织数据里的「信息类别」要选寄售（Consignment），不是标准（Standard）。这一步错了，后面全盘皆输——因为系统判断一条信息记录是否可用于寄售，看的就是这个标识。

ME11 创建信息记录 供应商 + 物料 + 采购组织 信息类别：Consignment（不是 Standard） 净价：与供应商约定的结算单价 税码 / 税务信息：必须填，否则 MRKO 结算会出问题

后两个字段的价值在流程末端才体现。净价是 MRKO 结算时的取价依据；税务信息是 MRKO 生成会计凭证时计算税额的依据。很多人前面一路顺畅，卡在 MRKO 报「税务信息缺失」，回头才发现 ME11 建记录时偷懒没填税码。

3.2 OMEV 激活寄售：一个容易遗漏的后台开关

SPRO → 物料管理 → 采购 → 环境数据 → 定义外部采购的缺省值这条路径下有个「使用信息记录激活寄售」的开关，事务代码 OMEV。这个配置控制的是：寄售收货时系统是否强制要求存在寄售信息记录。

逻辑很直白——开关打开，101 收货会去校验寄售信息记录存在与否，不存在就报错拦截；开关关闭，收货放行但价格取不到，后续 411 转移时会出问题。所以正确姿势是打开它，让错误在收货环节就暴露，而不是拖到转移环节才发现价格是空的。

这类「让错误尽早暴露」的配置思路在 MM 里很常见。系统给了你关掉校验的自由，但关掉之后问题不会消失，只会延后爆发，且爆发时的现象更难看懂。

3.3 项目类别 K：采购申请里那个决定命运的字段

ME51N 建采购申请，行项目的「采购凭证中的项目类别」必须是 K。这个字段是全链路的锚点：

PR 项目类别 K → 转 PO 时 PO 行项目类别自动为 K → 收货时移动类型自动带出特殊库存 K → 库存进入供应商寄售，不进自有库存 → 发票校验入口被限制为 MRKO

如果这里填成了标准（空或标准项目类别），转出来的就是普通 PO，101 收货会正常生成 FI 凭证、正常产生 GR/IR，整条寄售链路直接报废。而且这种错误在收货前完全看不出来——PO 建得挺正常，直到你发现 MMBE 里库存进了非限制使用而不是寄售，才知道方向错了。

修正的成本也不低。已经收货的 PO 不能简单改项目类别，通常要走冲销→改单→重收的路径。所以我的习惯是：PR 保存前一定回看行项目的项目类别，这是血泪经验换来的动作。

3.4 MRKO：为什么寄售结算绕开了 MIRO

常规采购的发票校验走 MIRO，三单匹配（PO、收货、发票）。寄售走 MRKO（寄售结算），逻辑完全不同：

MIRO（标准）：基于 PO 收货做匹配，冲销 GR/IR MRKO（寄售）：基于期间内的寄售消耗/转移量结算，不基于 PO 收货

MRKO 的结算对象是「这段时间你实际消耗或转走了多少寄售库存」，按信息记录里的净价计价，一次性生成应付和对应的会计凭证。它的执行界面里要输入供应商、公司代码，系统会列出该供应商所有寄售信息记录及其期间消耗量，你勾选后执行结算。

这个设计的时间维度很重要。MRKO 不是即时结算，是按期间批量跑的——通常是月末。这带来一个操作约束：结算前要确保当期的 411 K 转移都已完成并正确过账，否则结算金额会与实际消耗对不上。而且一旦结算完成，对应的消耗记录就被「锁定」，后续再想调整得走冲销流程。

3.5 411 K 转移：记账真正发生的那一刻

MB1B + 移动类型 411 + 特殊库存 K，把寄售库存转成工厂的非限制库存。这是整个流程里唯一会产生 FI 凭证的环节。

MB1B 移动类型 411 特殊库存标识：K 从：供应商寄售库存 到：自己的非限制使用库存

执行时系统会去查 Consignment 类型的信息记录取价。取不到就报那个经典提示：

Pipeline/consignment movement posted without value

意思是「过账了，但没金额」。这不是硬错误，是警告——凭证能生成，但金额为零，后续 MRKO 结算时会出问题。看到这句提示，正确反应不是忽略，而是回头检查 ME11 的信息记录：信息类别对不对、有效期覆盖不覆盖当前过账日期、采购组织是不是当前这个。

3.6 冲销的顺序约束：为什么不能直接冲 411

这是整套流程里最反直觉的一条约束。411 K 转过来的库存，不能直接冲销凭证，必须先用 412 K 做一笔反向移动，把非限制库存退回到寄售库存，然后才能重新处理。

原因在于 411 K 已经产生了会计凭证，库存科目已经记账。直接冲销会牵扯到已结算期间的问题——如果这笔已经被 MRKO 结算过，冲销链路会变得极其复杂。412 K 的语义是「把货退回寄售状态」，它同时也把账务反向冲回，是一条干净的对称路径。

正确顺序： 411 K（寄售 → 非限制，产生 FI） ↓ 发现问题 412 K（非限制 → 寄售，反向冲回 FI） ↓ 修正后重新 411 K，再 MRKO 结算 错误做法： 直接 FB08 / MBST 冲销 411 K 的物料凭证

4. 避坑清单：寄售流程里那些反复出现的排查点

4.1 101 收货报「必须有寄售信息记录」

现象：寄售 PO 做 MIGO 101 收货，系统拦截，提示需要寄售信息记录。

原因有三种可能：一是信息记录压根没建；二是建了但信息类别选成了 Standard 而非 Consignment；三是采购组织或供应商与 PO 不一致。系统校验的是精确匹配，供应商、物料、采购组织三者任一不同都算没有。

解决：ME13 显示信息记录逐项核对，重点看信息类别字段。确认无误后重收货。如果 OMEV 开关没打开，这个校验反而不会触发，问题会拖到 411 环节，所以务必确认后台开关是开的。

4.2 411 K 报 Pipeline/consignment movement posted without value

现象：MB1B 411 K 过账成功，但弹出警告，转移后库存金额为零。

原因：系统取不到寄售信息记录的价格。常见于信息记录有效期已过（比如信息记录只维护到上季度末，当前过账日期超出范围），或信息类别不对。

解决：MB1B 界面里手工输入金额，或者补建/延长信息记录有效期后重新过账。前者是应急，后者才是根治。如果已经过账成零金额，需要 412 K 退回后重做。

4.3 MRKO 结算报税务信息缺失

现象：MRKO 执行时提示消息类型问题，或结算后凭证税额为零。

原因：ME11 建信息记录时税务信息字段没填，或者填了但税码在当前期间无效。这条在项目正文里明确提到了——「在寄售信息记录里一定要包含税务信息」。

解决：ME12 修改信息记录补全税码，确认税码在目标期间有效。如果是消息管理层面的提示（比如提示被配置成了错误级别），需要检查 OMRM 消息控制，把对应消息调整为警告而非错误。

4.4 寄售库存进了非限制使用而不是寄售

现象：101 收货后 MMBE 查询，库存显示在「非限制使用」而非「供应商寄售」。

原因：PO 行项目的项目类别不是 K。多是 PR 建的时候没设对，或者有人手工把项目类别改回了标准。

解决：确认 PO 行项目的项目类别。已经收货的要先冲销收货，改项目类别后重收。这类错误发现得越晚成本越高，所以前面强调 PR 保存前回看。

4.5 寄售 PO 试图走 MIRO 被拒

现象：对寄售 PO 执行 MIRO，系统找不到可校验的收货行。

原因：寄售收货不产生 GR/IR，MIRO 的三单匹配没有匹配对象。这是设计使然，不是 bug。

解决：改走 MRKO。寄售结算与 PO 收货解耦，是按期间消耗量结算的，入口只能从 MRKO 进。

5. 设计取舍：延迟记账换来的资金效率，以及它的代价

寄售这套机制的本质是一次记账时点的后移。标准采购在收货瞬间就把库存和负债同时记上，寄售则把这笔账推到消耗或所有权转移那一刻。这个取舍在业务上换来的是库存资金占用的释放——货在你的仓库里周转，但钱还挂在供应商账上，你的资产负债表上不体现这笔存货。

代价则集中在三处。

第一是流程链路的加长。标准采购是 PR→PO→收货→MIRO 四段，寄售变成 PR→PO→收货→411 转移→MRKO 结算五段，多出来的 411 和 MRKO 都需要人的判断：411 取价对不对、MRKO 期间结没结干净。

第二是价格依赖的刚性。寄售 PO 在创建时不校验信息记录，把校验压力全部压到收货和转移环节。这个设计让 PO 建得快，但把风险后置了。我个人的偏好是宁可让系统在前端就报错——所以我会把 OMEV 打开，并在 PR 保存前强制检查项目类别，把问题挡在最便宜的环节。

第三是冲销链路的复杂。411 K 一旦牵扯到已结算期间，回退成本很高，必须走 412 K 这个对称动作，而不能简单冲销凭证。这套「对称移动类型」的设计在 MM 里是通行的——不让你做单向删除，逼你走反向业务动作，保证账务可追溯。

如果想验证自己对这套机制的理解是否到位，有个简单的自测方法：拿一笔寄售收货，从头到尾查三个数据——MMBE 里库存落在哪个特殊库存标识下、MB51 里 101 凭证的 FI 凭证号是不是空的、411 K 产生的会计凭证借方贷方分别是什么科目。这三个点串起来，寄售的所有权流转逻辑就闭环了。

那之后我每次配寄售流程，都会先确认三件事：物料主数据的特殊采购类是 10、信息记录的信息类别是 Consignment 且带税码、OMEV 的开关是开的。这三个前置动作能挡掉后面八成的报错，比事后排查省太多时间。希望帮到你。

需要说明的是，这份流程文档把从主数据到 MRKO 结算的每一个事务代码、每一步的前置条件和后置影响都记了下来，包括那些只在特定情况下才触发的报错和冲销约束，适合放在手边当操作基线逐条比对。

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