SAP MM | S/4HANA MIGO 频繁报错 M3 682 (批次被锁定)？详解 S4 库存移动的锁机制与破解策略

1. 问题背景

在将系统升级到 SAP S/4HANA，或者在实施高并发的仓储/车间业务时，用户经常会抱怨一个痛点：在执行 MIGO（货物移动）时，经常遇到单据被锁导致无法过账的情况。 尤其是在涉及**批次管理（Batch Management）**的物料时，问题尤为高发。

2. 问题表现

• 前端报错： 用户在 MIGO 界面点击“检查（Check）”或尝试“过账（Post）”时，系统抛出红灯错误：

  消息 ID：M3 682 > 报错内容：物料 XXXX 的批次 YYYY 已被锁定 (Batch is already locked)。

• 诡异现象： 调查后发现，有时另一个用户其实并没有在执行“过账”，他可能仅仅是打开了批次选择的弹窗，或者点击了检查按钮还没保存，居然就把整个批次给锁死了，导致其他车间的同事完全无法对该批次进行任何发料或收货操作。

3. 原因分析：S/4HANA 复杂的“混合锁”机制

这个问题并不是系统 Bug，而是 SAP 在 S/4HANA 中为了优化性能对**锁机制（Locking Mechanism）**进行了重大底层改造。

打个比方：

排他锁（Exclusive Lock, 模式 E）： 就像你把图书馆的书借回家，别人连看都看不了。

共享锁/后继锁（Shared/Late Lock, 模式 S）： 就像你在阅览室看书，别人也可以一起看，只有当你真的要拿笔在书上写字（最终过账更新数据库）的一瞬间，你才把书霸占。

为了提高并发性能，S/4HANA 默认启用了**“后继锁定（Late Lock）”**策略。但这套策略并没有覆盖所有数据维度，这就导致了行为上的割裂：

根据 SAP 官方的底层设计（参考 Note 2319579 和 2338387），MIGO 过账时主要涉及三种锁：

• 工厂数据锁（Material + Plant）： * 表现： 完美支持“后继锁定”。在检查或输入阶段不锁，只有在最终过账时才短暂锁定。

  • 配置： 可通过后台配置（OMJI）自由切换是 E 锁还是 S 锁。

• 会计数据锁（Material + Plant + Valuation Type）： * 表现： 必须硬锁定。因为涉及财务金额的即时计算，只要打开相关弹窗或执行检查，系统就会上排他锁（非评估物料除外）。这是 S/4 的强制要求，无法解除。

• 批次主数据锁（Material + Batch）： （👉 报错 M3 682 的元凶）

  • 表现： 默认情况下，一旦用户点击检查或关闭批次弹窗，系统就会对批次主数据施加排他锁（E）。哪怕用户磨磨蹭蹭半天不过账，这个批次也被他死死占用了。

4. 解决方案

既然明确了 M3 682 报错是因为**“批次主数据过早被加了排他锁”**，解决思路就是将其“降级”或“推迟锁定”。

终极方案：实施标准 BAdI 降级锁模式

SAP 官方早就预料到了这种高并发场景下的痛点，并提供了一个标准的 BAdI 增强点。

• 参考官方 Note： 1949813 - BAdI for batch master locking behavior

• 实施步骤：

  1. 开发顾问根据 Note 1949813 中的指引，实现对应的 BAdI。

  2. 在该 BAdI 中，将批次主数据（Batch Master）的锁定模式从默认的 'E' (Exclusive) 修改为 'S' (Shared)。

  3. 效果： 实施后，用户在 MIGO 界面点击“检查”或操作批次弹窗时，系统只会施加共享锁（相当于解除了排他霸占）。只有在最后点击“过账”按钮的瞬间，系统才会真正锁定批次并更新数据。

补充说明（关于凭证层锁）

• 如果是普通工厂级别的报错（非批次导致），请检查后台配置：IMG -> 物料管理 -> 一般设置 -> 设置：库存移动的物料冻结。确保默认配置为**“后继冻结 (Late Lock)”**。

5. 总结

在 S/4HANA 项目实施中，不要理所当然地认为开启了“后继锁定”配置，所有的锁冲突就迎刃而解了。

工厂库存、财务价值、批次状态，这三者的锁定逻辑在底层是完全独立的。 面对因批次管理带来的 M3 682 并发锁冲突，不要盲目去改写底层 RFC 或做粗暴的异常捕获。利用 Note 1949813 提供的标准 BAdI 调整批次锁级别，才是最优雅、最符合系统架构的破局之道。