客服完成 Credit Memo，款也退了，但商品可销售数量没有增加。有人直接把 Source Quantity 加回去，第二天 ERP 同步又覆盖。退款、退货和库存回补是相关但不同的业务动作，必须先确认这张 Credit Memo 是否要求 Return to Stock。

先还原订单履约状态

记录 order、invoice、shipment、credit memo 的 ID 与时间，商品是否已发货、从哪个 Source 发货、退款数量和是否勾选 Return to Stock。未发货订单的取消与已发货订单的退货，库存事件不同；虚拟商品也不存在物理回库。

部分退款尤其要按 item 检查。订单买 5 件、发 3 件、退 2 件时，系统不能凭总数猜回哪个仓库。后台操作界面可能只显示数量，但 MSI 需要明确 Source 上下文。

MSI 中 Source Quantity 与 Salable Quantity 分开变化

下单 reservation 先影响 salable，发货再扣 Source Quantity 并做补偿。退款回库可能增加具体 Source 的物理数量，同时通过事件影响可销售状态。用服务接口或只读查询按 SKU、stock、source 和订单 reservation 对账，避免只看商品编辑页总数。

php bin/magento inventory:reservation:list-inconsistencies
php bin/magento queue:consumers:list
php bin/magento indexer:status inventory

若回库事件已产生但前台未变化，检查库存消费者与索引；若根本没有事件，回到 Credit Memo 参数、插件和订单状态。

ERP/WMS 集成决定谁是物理库存事实源

部分项目规定 Magento 只申请退货，仓库验收入库后由 WMS 增加数量。此时退款当刻不回库存可能是正确设计。必须和业务确认“退款即回库”还是“验收后回库”，并保证两边不会各加一次。

Webhook 和队列要用 creditmemo_id、order_item_id 等稳定键保证幂等。外部回调重放时，不能重复增加库存。失败消息应可重试且保留状态。

完整验收要覆盖四条路径

未发货取消、已发货全额退货、部分退货、不回库退款分别测试。每条路径对比 Source Quantity、Salable Quantity、reservation 合计、订单状态和 ERP 记录。最后再下一个测试订单，确认恢复的库存确实可售且不会超卖。退款金额正确只是财务闭环，库存还需要自己的闭环。