企业官网建设流程全解析

简介：本资源是一份面向SAP MM模块初、中级实施顾问与企业供应链信息化人员的「供应商寄售全流程实操指南」，聚焦解决寄售模式下物料主数据配置、采购订单创建、寄售库存收发与结算等核心痛点。文档以SAP标准事务代码为线索，系统梳理了从MRP2视图设置（采购类型F+特殊采购类10）、XK01建供应商、ME11维护寄售信息记录，到MIGO收料（101）、MB1B转库（411K）、MRKO发票校验及412K冲销排错等11个关键步骤，覆盖后台配置（OMEV激活）、前台操作与典型报错应对。资源为单文件Word文档（.doc），大小123KB，结构紧凑、术语准确、步骤可复现，适合作为现场实施速查手册或培训补充材料。目前已有570人学习下载，内容兼具理论逻辑与实操细节，尤其对寄售库存无FI凭证、Consignment P-info强制校验、MRKO税务字段要求等易错点有明确提示和解决方案。

1. SAP供应商寄售不是“先收货后付款”的简化版，而是整套库存权属与财务时点分离的管控机制：它让工厂仓库里堆着供应商的货、账上不计成本、系统里能精准追踪每一包寄售物料的归属与结算节点

某制造企业上线SAP后，采购总监拍着桌子问：“为什么我们仓库明明有5000个轴承，MB52查出来却是零库存？”——答案藏在特殊库存标识“K”里。这不是系统坏了，是寄售模式在真实运转：货物理存在你家仓库，法律权属和会计责任仍属于供应商；只有当你用MB1B做411移动、把“寄售库存（Consignment Stock）”转成“非限制使用库存（Unrestricted Use Stock）”那一刻，系统才触发应付账款生成和成本入账。这种“货不动权不动、动则权责同步转移”的设计，本质是SAP MM模块对VMI（供应商管理库存）场景的原生支持，不是打补丁，而是从MRP2视图采购类型“F”+特殊采购类“10”开始就埋下的逻辑根。它解决的不是“怎么少付钱”，而是“如何让采购、仓储、财务三部门在同一个数据源下各司其职又无缝协同”——采购管订单与交付节奏，仓储管实物与位置，财务只对实际消耗行为记账。适用对象非常明确：多级供应商协同的离散制造、备件周转率差异大的设备运维、或需要压降应付账款天数但又不能牺牲交付弹性的采购团队。如果你还在用Excel手工登记寄售台账、靠邮件催供应商开票，这套流程就是你该立刻落地的数字化基线。

2. 寄售主数据配置：从MRP2视图到OMEV激活，每一步都在定义系统如何识别“这是寄售，不是普通采购”

寄售不是操作习惯，是主数据驱动的业务规则。系统不认识“寄售”这个词，它只认MRP2视图里的两个字段值：采购类型必须为“F”，特殊采购类必须为“10”。这两个值像DNA密码，决定了后续所有事务代码的行为边界。漏配一个，整个流程就会在ME51N创建采购申请时卡死——系统根本不会给你显示项目类别“K”的选项。

2.1 MRP2视图采购类型“F”与特殊采购类“10”的强制绑定逻辑

进入MM01维护物料主数据，在“MRP2”视图中设置：

• 采购类型（Procurement Type）：必须选“F”（External procurement，外部采购）
• 特殊采购类（Special Procurement Type）：必须选“10”（Consignment，寄售）

提示：这两个字段是强耦合关系。“F”+“10”是SAP标准组合，不可拆分。若误设为“F”+“50”（Subcontracting），系统会按委外加工逻辑走，后续收料直接生成应付凭证，彻底绕过寄售管控。实测中，某汽车零部件厂因批量导入时模板字段错位，导致37种物料被设为“F”+“50”，结果寄售收料MIGO 101产生FI凭证，财务月结时发现应付账款虚增280万元，返工重置主数据耗时3人日。

2.2 供应商主数据创建：XK01中必须勾选“寄售供应商”标识

使用XK01创建供应商时，关键动作在“采购组织数据”视图：

• 勾选“寄售供应商（Consignment Vendor）”复选框
• 在“采购信息记录”子屏幕中，确保“寄售”（Consignment）字段打钩

XK01 操作路径： Enter → Vendor → Purchasing Organization Data → Consignment Vendor: [✓] → Purchasing Info Record → Consignment: [✓]

此步骤不是可选项。未勾选会导致ME11创建信息记录时无法选择“寄售”类型，进而阻断后续所有寄售单据生成。某电子代工厂曾因新供应商入职培训疏漏，连续5单寄售采购申请被系统拒绝，报错“Vendor not flagged for consignment”，根源即在此处。

2.3 信息记录创建：ME11中寄售信息记录的四个硬性参数

寄售信息记录（Info Record）是寄售结算的唯一计价依据，必须通过ME11创建，且仅限寄售类型。核心参数如下表：

注意：寄售信息记录不参与价格比较（Price Comparison），其价格仅用于MRKO结算。若此处价格填错，后续MRKO生成的应付凭证金额将直接错误，且无二次修正入口——必须删除重建信息记录并冲销已结算凭证。

2.4 后台配置激活：OMEV中开启寄售功能开关

寄售不是默认启用的功能，需通过后台配置显式打开。路径：
SPRO → 物料管理 → 采购 → 信息记录 → 使用信息记录激活寄售
事务码：OMEV

在OMEV界面中：

• 选择对应采购组织
• 勾选“允许寄售信息记录（Consignment Info Records Allowed）”
• 保存配置

此配置是全局开关。未执行OMEV激活，即使主数据全部正确，ME51N也无法选择项目类别“K”，系统报错“Consignment not allowed for this purchasing organization”。某化工企业曾因配置遗漏，导致新上线的华东采购组织无法处理寄售业务，被迫临时启用“普通采购+手工挂账”过渡方案，造成3个月财务对账混乱。

3. 寄售单据流实战：从ME51N采购申请到MRKO结算，每个事务码背后都有不可妥协的时序约束

寄售流程不是线性流水线，而是一套带状态锁的闭环。跳过任一环节或颠倒顺序，系统立即报错。以下按真实操作时序展开，每步附关键校验点与失败回溯方法。

3.1 ME51N创建寄售采购申请：项目类别“K”是唯一入口

进入ME51N创建采购申请，关键操作：

• 在项目行输入物料号后，项目类别（Item Category）必须手动改为“K”（系统默认为“0”普通采购）
• 若下拉菜单无“K”选项，立即检查：①物料MRP2视图是否为“F”+“10”；②供应商是否勾选“Consignment Vendor”；③OMEV是否激活

ME51N 操作要点： Item → Item Category → [K] Consignment → Account Assignment → Blank (寄售不分配科目) → Delivery Date → Required (影响寄售库存有效期)

逻辑说明：“K”类别强制系统将该申请关联至寄售信息记录，而非普通采购订单。此时不校验价格，只校验供应商与物料的寄售资质。若此处误选“0”，后续转PO时虽可强行修改，但收料MIGO 101会因缺少寄售信息记录而报错“Consignment info record missing”。

3.2 采购订单创建：ME21N中寄售PO的三个反常识特征

将ME51N采购申请转为采购订单（ME21N）时，寄售PO呈现三大特征：

1. 无需信息记录即可创建：系统允许空P-info建单，但收料时强制校验
2. 订单类型固定为“KON”：非用户选择，系统自动赋值
3. 行项目无价格字段：价格由MRKO结算时从信息记录读取，PO中留空

ME21N 创建寄售PO关键点： Header → Document Type → KON (系统自动) Item → Item Category → K (继承自采购申请) → Net Price → Blank (灰色不可编辑) → Info Record → Optional (但强烈建议填写，避免收料失败)

参数说明：寄售PO的“KON”类型是SAP预置，不可修改。若手动改为“NB”（标准采购），系统将按普通采购逻辑走，收料即生成FI凭证，彻底破坏寄售财务隔离原则。某家电厂曾因测试环境误操作，将寄售PO类型改为NB，导致当月寄售收料全部计入应付账款，财务被迫手工调整分录。

3.3 MIGO 101收料：寄售库存入库的零财务凭证真相

寄售收料必须用MIGO（推荐）或MB01，移动类型为“101”。核心事实：101收料不生成任何财务凭证（FI Document），仅更新库存数量与特殊库存标识。

MIGO 操作路径： Good Receipt → Purchase Order → Enter PO Number → Item → Movement Type: 101 → Special Stock Indicator: K (系统自动填充) → Quantity → Enter received amount → Post

逻辑说明：MIGO 101的本质是“库存位置变更”，将供应商名下的寄售库存（特殊库存K）记入本工厂仓库。系统仅更新库存台账（如MSEG表），不触碰总账（BKPF表）。若此处意外生成FI凭证，必是主数据配置错误（如物料主数据未设“10”）或移动类型误选（如选了103/105）。

3.4 MMBE库存查询：读懂寄售库存的三重维度

寄售库存状态必须用MMBE查看，而非MB52。MMBE可穿透显示：

• 库存类型（Stock Type）：显示“Consignment”
• 特殊库存（Special Stock）：显示供应商编号（如V000123）
• 库存地点（Storage Location）：具体仓库编码

MMBE 查询要点： Material → Enter material number → Plant → Enter plant code → Execute → Check tab "Special Stock" → Column "Vendor" shows consignment supplier ID → Column "Stock Type" = "Consignment"

血泪经验：某项目上线初期，仓库管理员坚持用MB52查寄售库存，反复报告“系统没库存”，实际是MB52默认过滤掉特殊库存。直到用MMBE切到“Special Stock”标签页，才看到供应商V000123名下有12000件寄售物料。从此我要求所有仓管员桌面贴纸：“查寄售，必开MMBE，必点Special Stock”。

4. 寄售库存转移与结算：MB1B 411移动与MRKO结算的权责切换临界点

寄售流程的财务分水岭，就在MB1B 411移动这一刻。此前货是供应商的，此后货是工厂的，系统自动完成权属与会计责任的双重切换。这一步出错，后续MRKO必然失败。

4.1 MB1B 411移动：从寄售库存到非限制库存的强制转换

MB1B执行411移动时，系统强制要求：

• 移动类型（Movement Type）：必须为“411”
• 特殊库存标识（Special Stock）：必须为“K”
• 信息记录（Info Record）：必须存在且类型为“Consignment”

MB1B 操作路径： Transfer Posting → Material → Enter material number → Plant → Enter plant code → Storage Location → Enter storage location → Movement Type: 411 → Special Stock: K → Vendor → Enter supplier ID (e.g., V000123) → Quantity → Enter amount to transfer → Post

逻辑说明：411移动的本质是“库存所有权转移”。系统执行时：①扣减供应商V000123名下的寄售库存；②增加本工厂的非限制库存；③自动生成会计凭证（Debit: Inventory, Credit: GR/IR Clearing Account）。若此处未填写供应商ID，系统报错“Pipeline/consignment movement posted without value”，因无法确定权属方。

4.2 MRKO结算：寄售专用发票校验的不可替代性

寄售结算必须用MRKO，绝不可用MIRO。MRKO的核心逻辑是：按信息记录价格 × 411移动数量，生成应付账款凭证。

MRKO 操作路径： Consignment Settlement → Select vendor → Select plant → Select material (optional) → Execute → System lists all unsettled consignment issues → Select line → Settle

参数说明：MRKO不依赖采购订单，只读取411移动记录与寄售信息记录。若信息记录中未维护税务信息（如税码MWST），MRKO报错“Tax data missing in info record”，必须返回ME12补充维护。某项目曾因此卡住整月结算，根源是信息记录税务字段为空。

4.3 412K冲销：当411移动错误时的唯一合规修正路径

若411移动数量填错（如多转100件），严禁用MBST冲销！必须用MB1B执行412K移动（反向411）：

MB1B 冲销路径： Transfer Posting → Movement Type: 412 → Special Stock: K → Vendor: Same as original 411 → Quantity: Negative value of original error → Post

原理：412K是411的镜像操作，系统自动反向生成凭证。若用MBST冲销，仅消除库存变动，不还原GR/IR科目，导致财务账实不符。某汽车 Tier1 供应商因误用MBST，造成GR/IR科目长期挂账47万元，审计时被列为重大内控缺陷。

5. 避坑指南：寄售流程中五个高频翻车现场与血泪解决方案

寄售流程看似步骤清晰，实则处处是隐性校验点。以下五条均为一线实施中真实发生的“玄学报错”，按现象→原因→解法结构整理，每条都经至少3个项目验证。

5.1 现象：ME51N中项目类别“K”灰显不可选

原因：采购组织未在OMEV中激活寄售功能，或当前登录用户无OMEV配置权限。
解决：①以配置用户登录，执行OMEV，勾选“Consignment Info Records Allowed”；②检查用户角色是否含“S_PROFC”（配置权限）；③重启SAP GUI使配置生效。

5.2 现象：MIGO 101收料时报错“Consignment info record missing”

原因：寄售PO创建时未关联信息记录，且系统配置为“收料强制校验P-info”（OME9中“Check info record at GR”勾选）。
解决：①返回ME22N修改PO，在行项目中补填寄售信息记录号；②或临时在OME9中取消勾选“Check info record at GR”（仅限测试环境）。

5.3 现象：MB1B 411移动时报错“Pipeline/consignment movement posted without value”

原因：未在MB1B界面输入供应商编号（Vendor），系统无法定位寄售权属方。
解决：①在MB1B“Vendor”字段手动输入供应商ID；②确认供应商主数据中“Consignment Vendor”已勾选；③检查物料主数据MRP2视图是否为“F”+“10”。

5.4 现象：MRKO结算时报错“Tax data missing in info record”

原因：寄售信息记录（ME12）中未维护税务信息，税码字段为空。
解决：①用ME12打开该信息记录；②进入“Tax”标签页；③在“Tax Code”字段填入有效税码（如MWST）；④保存后重新执行MRKO。

5.5 现象：MRKO结算后，GR/IR科目余额不为零

原因：411移动与MRKO结算数量不一致，或同一物料存在多笔411移动但MRKO只结算部分。
解决：①用MR51查看该供应商所有寄售结算清单；②用MMBE核对411移动总量；③在MRKO中勾选“All items”强制结算全部未清项；④若仍有差异，用FB03查GR/IR凭证，定位未清项来源。

6. 进阶验证技巧：用三张标准报表交叉验证寄售全流程数据一致性

寄售流程的终极验证，不是看单据是否成功提交，而是三张报表的数据能否严丝合缝对齐。这是我从某跨国制造集团学到的硬核方法，现在每次上线新工厂必跑这三张表。

6.1 第一张表：MMBE —— 查寄售库存的“物理存在性”

MMBE是寄售库存的权威台账。重点验证：

• “Special Stock”标签页中，供应商ID、物料号、数量三者与采购合同一致
• “Stock Type”列必须为“Consignment”，非“Unrestricted”或“Blocked”
• “Storage Location”必须为实际收货仓库，非虚拟库位

验证逻辑：MMBE数据来自库存主表MARD与特殊库存表MSEH，是实物层面的最终体现。若此处数据异常，说明MIGO 101或MB1B 411未正确执行。

6.2 第二张表：MRKO结算清单 —— 查结算的“财务发生性”

MRKO执行后，用事务码MR51查看结算清单：

• 输入供应商、工厂、日期范围
• 检查“Settled Qty”（已结算数量）与“Open Qty”（未清数量）之和，是否等于MB1B 411移动总量
• 核对“Settlement Value”（结算金额）是否等于信息记录价格 × 结算数量

MR51 关键字段解读： Settled Qty → 实际结算数量（应=411移动量） Open Qty → 未结算数量（应=0，否则MRKO未跑全） Settlement Value → 应付金额（=Info Record Price × Settled Qty）

验证逻辑：MR51数据源自结算凭证表RBKP与RBDR，是财务层面的法定记录。若MR51中“Open Qty”大于0，说明MRKO未覆盖全部411移动，GR/IR科目必有挂账。

6.3 第三张表：S_ALR_87012327（寄售结算分析）—— 查权责的“时间一致性”

这是SAP寄售专用分析报表，路径：
SAP Menu → Logistics → Materials Management → Purchasing → Information System → Reports → Consignment Settlement Analysis

报表输出核心字段：

验证逻辑：此报表自动关联MIGO、MB1B、MRKO三类凭证，是端到端的完整性校验。若“Difference”非零，说明某个环节数据未落库或凭证未过账。某项目曾用此表发现MIGO 101凭证未过账（状态为“Saved”非“Posted”），及时补过账避免月结延误。

从那以后我每次上线寄售模块，都强制走一遍这三张表的交叉验证：先跑MMBE看库存是否落库，再跑MR51看结算是否完成，最后用S_ALR_87012327扫差额。三张表全绿，才敢签字确认寄售流程上线。这套方法看似笨重，却帮我在过去三年规避了7次重大财务对账事故。希望帮到你。

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