Melody 项目故事

一座桥，从图纸到通车 — AutoCount × QianYi WMS 集成插件 / Melodies Distributors

Melody 项目故事：一座桥，从图纸到通车

📊 一张图看懂这个项目

  美乐蒂公司电脑（本地）                                        中国厦门（云端）
  ┌──────────────────────┐                           ┌──────────────────────┐
  │      AutoCount        │                           │      千一 WMS         │
  │  （会计 + 进销存软件） │                           │  （仓库管理系统）      │
  │                       │   ┌──────────────────┐   │                      │
  │  • 采购单 (PO)        │◄──│   WMS Sync Hub   │──►│  • 仓库拣货任务       │
  │  • 拣货单 (Picking)   │   │   插    件        │   │  • 收货 / 入库记录    │
  │  • 商品编码 (SKU)     │──►│ （Prisma 制作的桥）│◄──│  • 库存数量状态       │
  │  • 收货记录 (GRN)     │   └──────────────────┘   │                      │
  └──────────────────────┘         ngrok 隧道         └──────────────────────┘
          账目在这里           （让云端能访问本地电脑）          仓库动作在这里

三句话版本：
- 美乐蒂用 AutoCount（账目软件，记录所有进货、出货、库存）管财务，用 千一 WMS（仓库管理系统）管仓库实体操作。
- 两个系统原本"不认识"对方，每笔数据都要工人手动录入两遍，费时又容易出错。
- Prisma 做的 WMS Sync Hub 插件（一个让两套系统自动互相说话的翻译程序），就是这道故事的主角。

📅 项目大事记

时间 里程碑 状态
2024 年底 Prisma 完成 SME Corp 数字化项目，赢得 Derrick（老板）信任 ✅
2026 年 1 月 选定千一 WMS；Prisma 受委托做 AutoCount 对接插件 ✅
2026 年 3 月 19 日 正式签约 PQ-260203，金额 RM 13,900 ✅
2026 年 5 月 4 日 WMS Sync Hub v1.6.5 上线（支持一张采购单分批收货） ✅
2026 年 5 月 5 日 🔴 BUG-001 爆发 → v1.6.6 1 小时内修复 ✅
2026 年 5 月 18 日 第二期签约：Purchase Return 模块 RM 8,000 ✅
2026 年 5 月 19 日 v1.6.9 上线：Cancel 操作加审计日志 ✅
2026 年 7 月 14 日 系统更新：修复 3 个操作问题 ✅
2026 年 7 月 21 日 Purchase Return 培训完成（3 人参与） ✅
2026 年 7 月 22 日 🟢 Purchase Return 模块正式上线 ✅

🗺️ 速读导航（新读者从这里找你想看的幕）

幕 一句话总结 适合谁看
第一幕 美乐蒂是谁、做什么生意 第一次听说这个客户
第二幕 仓库系统瘫痪，工人回到手写时代 想知道问题有多严重
第三幕 选千一 WMS，但它不认识 AutoCount 想知道为什么要做这个插件
第四～六幕 报价、开发、上线 想了解做了什么
第七幕 ⭐ 🔴 Derrick 录音："一小时解决，否则弃用 WMS" 想看最刺激的那一段
第八幕 事故分析，5 个待办，真正的教训 想知道出了什么事、怎么收尾
第九幕 "不是插件的锅"——人改单才是根因 想知道事故后发生了什么
第十幕 Purchase Return 模块签约 RM 8,000 想了解第二期业务
第十一幕 9 台 PDA 到位，系统平稳运行两个月 想知道日常运作情况
第十二幕 三个小问题，四天解决 想看日常 troubleshooting
第十三幕 DOB 集成被 HRDF 证书卡住 想了解为什么 DOB 还没好
第十四幕 Purchase Return 培训成功举行 想看第二期交付的节点
第十五幕 模块上线；Mr Lee 新需求浮出 最新进展

第一幕：柔佛的 FMCG 批发大佬

FMCG distribution warehouse interior with product shelves
🏭 柔佛 Ulu Tiram 工业区，类似美乐蒂的仓库Photo · Unsplash

在柔佛乌鲁地南（Ulu Tiram）的 Taman Perindustrian Cemerlang 工业区里，有一间叫做 Melodies Distributors（美乐蒂）的公司。

这不是什么小店。他们是 柔佛州数一数二的 FMCG 快消品批发商，1999 年就注册了（SSM: 0476474-M），做了超过 25 年的批发生意。

他们批发什么？——日用品、纸巾、打火机、火柴、罐头食品、汽水饮料、各种杂货。总之，你在便利店、杂货铺看到的那些日常用品，很多就是从美乐蒂的仓库发出去的。

老板叫 Derrick Teo（张远居），在 Ulu Tiram 和 Masai（士年纳）各有一个仓库据点。每天的运营节奏是这样的：

早上——几十辆供应商的货车排队送货，仓库工人验货、扫描、入库、上架。
下午——几百张零售商的订单涌进来，拣货、打包、装车、派送。
每天——成千上万个 SKU（商品编码，每种商品的唯一编号，比如"可口可乐 355ml 罐装"是一个 SKU，"可口可乐 500ml 瓶装"是另一个）在仓库里流转——不同品牌、不同规格、不同批次的牙膏、洗发水、纸巾、可乐……

对于一个 FMCG 批发商来说，仓库就是心脏。心脏跳得快不快、稳不稳，直接决定了公司能不能准时出货、能不能少出错、能不能赚钱。

第二幕：心脏停了

问题是——美乐蒂的仓库"心脏"，出事了。

他们之前有一套 WMS（仓库管理系统），但这套系统已经全面瘫痪：

想象一下：一个每天要处理几百张订单的批发商，仓库系统完全瘫痪。这意味着什么？

手写。回到手写时代。

工人拿着纸和笔记录收货，拿着纸和笔核对拣货单，拿着纸和笔登记出库。效率暴跌，错误率飙升。送错货、漏发货、库存对不上——这些问题天天在发生。

Derrick 急了。他需要一套新的 WMS，而且要快。

第三幕：两条路，一个选择

Derrick 找到了 Prisma Technology。

其实两家公司是老交情了——2024 年底，Prisma 刚帮美乐蒂做完一个 SME Corp 政府数字化项目（SCM 供应链系统 + CRM 客户管理 + AI 聊天机器人），通过了政府审计。所以 Derrick 信任 Prisma。

Jay（Prisma 创始人）做了调研，带着团队去实地考察。他们研究了一套中国产的网页版 WMS——千一 WMS（QianYi WMS），功能很全：入库、出库、库存盘点、多仓管理，什么模块都有。

Prisma 也提了自己的方案：我们帮你定制一套 WMS，买断制，一次付清。

但 Derrick 的选择很务实：

对于一个仓库已经瘫痪、每天都在亏效率的批发商来说，"快"比"完美"重要一万倍。

所以 Derrick 选了千一。

但千一有一个致命的短板——它不支持 AutoCount。

美乐蒂用了很多年的 AutoCount 会计系统来管采购单、销售单、物料编码、财务账目。千一 WMS 管仓库，AutoCount 管账目——这两套系统之间，没有任何桥梁。

Derrick 也看过另一个供应商，但那家网站打不开，后来说太忙了没法支持。

这时候 Jay 说了一句话，直接定义了这个项目：

第四幕：桥的蓝图

2026 年 3 月 19 日，Dhai（Prisma 的技术负责人）签署了正式报价单 PQ-260203，报价给 Mr. Wong（美乐蒂的技术负责人）：

项目 金额
AutoCount 拣货 & 收货集成插件（对接千一 WMS） RM 12,000
物料编码同步（AutoCount → WMS，单向） RM 1,500
ngrok API 公网暴露（年费） RM 400
总计 RM 13,900

附带 6 个月售后支持 + 4 小时培训。客户已经接受并付款。

报价单上写了三个流程，对应三个最直白的画面：

那条看不见的隧道叫 ngrok（一种网络工具，作用是给装在公司内部电脑里的软件"开一扇网络窗户"）。AutoCount 装在美乐蒂公司的本地电脑上，外网访问不到；千一 WMS 在中国厦门，是公网云端的系统。ngrok 在美乐蒂电脑上"打了一个洞"，让远在中国的千一 WMS 可以通过这个洞"打电话"进来。

第五幕：前方的暗礁

项目看起来结构清晰、范围明确。但真正的挑战，往往藏在报价单写不到的地方。开发前，我们列了七块暗礁——其中有几块，后来真的撞上了。

第六幕：桥造好了

四月、五月初，桥一段一段地通车了。

到这个时候，桥看起来已经稳了。办公室和仓库说同一种语言。Derrick 的批发业务每天数百单的吞吐量在新系统上跑得起来。

但桥真正的考验，从来不是通车那天，而是通车之后第一次堵车的时候。

那一次，发生在 2026 年 5 月 5 日的早上。

📖 前情提要：第一至六幕发生了什么？

如果你是第一次看这个故事，或者已经忘了前面，这里是五分钟速成版：

美乐蒂（Melodies Distributors） 是柔佛数一数二的日用品批发商，每天发出几百张零售订单。老板叫 Derrick Teo。

他们的仓库系统彻底坏了——入库功能坏、出库功能坏、手持扫描枪也报废了。工人只好回到纸和笔记录货物的时代，每天出错不断。

Derrick 选了来自中国的 千一 WMS（仓库管理系统，就是管理仓库所有货物进出的电脑程序）来救场。但千一不认识他们用了多年的 AutoCount（一款马来西亚常用的账目软件，记录公司所有的进货、出货、库存、账目）。两套系统各管各的，数据还是要工人手动录入两遍。

Prisma Technology 的 Jay 说了一句话定义了这个项目：
"不管你找谁做 WMS，到头来都得跟 AutoCount 对接。"

Prisma 的 Dhai（技术负责人）花了两个月做出 WMS Sync Hub 插件（一个安装在 AutoCount 里的小程序，让两套系统自动互相说话），负责三件事：① 拣货单自动从 AutoCount 推到仓库工人的手机扫描枪 ② 供应商送货时自动生成收货记录回传 AutoCount ③ 新商品编码自动同步两边。报价 RM 13,900，签约了。

5 月 4 日，v1.6.5 上线。

接下来：上线的第二天早上，麻烦来了。

第七幕：五月五日的早上

Early morning light through window — urgency
⏰ 2026 年 5 月 5 日清晨，柔佛还在睡Photo · Unsplash

5 月 5 日清晨，柔佛还在睡。Melodies 的 WhatsApp 群"Integration (Wms x Melodies x Autocount)"忽然热闹起来。

01:21（UTC+8 上午 9:21），Derrick 在群里第一次发声：

"是不是 overnight 就会被 cancel？"
"昨天他们 import 进 DMS 做到晚上，结果今天取消了，又叫我们重新做过。"
"不可以用系统 call 回拯救？"

仓库的 Melodies staff 7391 跟着补刀：

"照着流程去 pick 货，是什么情况这个单会 close 呢？"

千一支持那边一开始的判断是"人为取消"——AutoCount 后台有人按了取消。但当 7391 解释清楚——"我们手动导入进去的是另一块文件（这个没有做 AutoCount 推送），所以我们手动去 OMS 操作，有自动推送的是 PICKLIST"——案情就开始拐弯了。

01:50，Derrick 录了一段 11 秒的语音说得更清楚："我们刚才是重新导入新的，不是昨天那些新的，今天新的。刚刚导入也是不能，也是 cancel。"

紧接着又补一段 15 秒："我们现在遇到问题的不是 Picking List 做好 Integration 的那一个部分哦。我们是有 DOB 的东西的，DOB 的东西 Integration 还没有做好，所以 DOB 的我们是 Manual 导入进去的，现在 Manual 导入进去的不能用。"

02:05，7391 录了一段 72 秒的关键语音，把现象说穿了：

"WMS 有给我们就是可以用 Almond S 的方式自己把那个订单导入进去嘛。然后 LS 这个公司的话我们还是用这个操作……可是同时我们也是有用这个 OMS 一起把另外一张单进来，可是一进来它就马上 close 掉了……LS 这边是没有问题的，可是美乐这边一进来就 close，不到一秒就 close 了，我完全做不到订单。"

紧跟着：

"所以这个东西会影响到我们这边吗？因为 LS 没有问题，因为 LS 没有 plugin integration，可是美乐有 plugin integration，自己手动去 OMS 进的单都会帮我自己 close、自己 cancel。"

这一句话把问题指了名。有插件的租户出问题，没插件的租户没事。问题就在我们这座桥上。

02:10，Derrick 又一段 37 秒的语音——这是整个事件最重的一段：

"这个问题可以帮我们赶一下，因为昨天已经一整天没有试货了，已经没有出货了，然后今天再不出货，顾客就不能够接受了。所以 Warehouse 他们要运作，我跟他们说给我们多一个小时——一个小时里面解决了，如果没有解决的话，他们又会放弃开跑这个 WMS。我们周末点的货全部都报废了。"

一个小时。仓库要弃用 WMS 的一个小时倒数计时已经按下去了。

02:13，Derrick 直接 @ Dhai："kindly check if your integration affect or not"。
02:13，Dhai 一个字回过去："Checking"。

02:15，千一支持给出了一个具体单号："800286103"。
02:18，Dhai 反问："800286103 的 picking list no 是什么"。
02:27，Melodies 3948 答："没有 picking list，做不到 picking list 的。所以我们才会用手动上传的方式。"
02:27，Dhai："明白"。

那两个字背后是 root cause 已经被锁定。

我们这座桥的对账逻辑（英文叫 reconciliation，就像你每月核对银行账单，把两边的记录比对一遍找出差异）是这么写的：定时拉取全部的 WMS 订单，跟 AutoCount 的状态对一遍，对不上的——比如 WMS 里有但 AutoCount 里没有的——就当成"该取消"的处理。

听起来合理。但 5 月 5 日的清晨揭穿了一件事：WMS 里的订单不止来自一条路。

路径 描述 AutoCount 那边有没有记录？
Path A AutoCount 开拣货单 → 插件推送 → 千一 WMS 有
Path B DOB 类订单（AutoCount 不开拣货单）→ 员工手动导入 OMS 模板 → 千一 WMS 没有
Path C 仓库工人直接在千一 WMS 界面上手动建单 没有

旧版本的对账逻辑只懂 Path A。Path B 和 Path C 的订单——它们在 AutoCount 里"找不到"，于是被插件标记成"该取消"，一秒之内自己被自己 cancel 掉。订单 800286103，以及 5 月 4 日深夜批量导入的那一整批，就是这么没的。

02:35，Dhai 在群里发了一段最关键的话：

"非常抱歉造成不便 🙏
WMS Sync Hub v1.6.6 已经更新好。
之前那批被误取消的 WMS 订单（800286103 等），是因为 plugin 检测 AutoCount 跟 WMS 两边状态对不上时，误把外部的订单也当成"该取消"的处理。
新版本已经修好……plugin 现在只会处理它自己推到 WMS 的订单，不会动你那边在 WMS 自己建的或其他来源的单。
再次抱歉，谢谢你的耐心 🙏"

修复的核心很短一句话：对账范围 = 插件自己推过的订单，仅此而已。插件不再当 WMS 的霸主，它只管自己的孩子。

Jay 隔了一分钟跟一句："麻烦测试了让我们知道🙏🏼"。

02:37，Derrick 抱着最后一点侥幸问千一支持 Ethan："可以不可以帮我们按掉症？取消，我们就不用重新再导入，可以吗？"
02:38，Ethan 回："这个不行，只能重新导入或者重新从 AutoCount 下发。"

被取消的订单救不回来。800286103 那一批，只能按千一支持发的模板格式重新导入一遍，从头跑。

桥没塌——但桥上掉下去的那一车货，找不回来了。

第八幕：桥还要再加固

v1.6.6 上线了。Derrick 那"一个小时倒数"挡住了。但事情远没结束。

桥要继续加固，留下五件待办（详见 06-next-actions.md）：

# 待办 谁来做
F1 把 800286103 和 5 月 4 日深夜那批订单重新导入或从 AutoCount 重新下发——按千一支持给的模板格式 Melodies + 千一
F2 把 Path A / B / C 三条路写成 SOP，让 Melodies 员工不再混淆"自动推送的"和"手动导入的" Prisma（Dhai/Jay）
F3 跟千一一起，把 DOB 这类目前不在 AutoCount 自动推送范围内的订单类型梳理出来，单独估价当 Phase 2 千一 + Prisma
F4 端到端验证 v1.6.6 的对账范围过滤——从 AutoCount 推一张、在 WMS 手动建一张、跑对账、确认手动那张不被取消 Prisma（Dhai）
F5 把 07-system-analysis.md 的订单流程图跟新的 12-architecture-diagram.md 对齐——12 是权威 Prisma

这场事故留下来的真正教训，不是某一行代码。

是这座桥从来不只走一条路。Path A 是我们设计的路，Path B 和 Path C 是客户原本就在走的路。一座桥要安全，必须看得见所有进入它的路口，包括那些它"不打算管"的路口——尤其是那些路口。

Melodies 跟 Prisma 的关系，靠的是 2024 年那个 SME Corp 项目结结实实做完的信任。今天早上 02:10 那 37 秒的语音，把这份信任放在了刀尖上。v1.6.6 把它接住了。

但只要 Path B、Path C 在生产里还会再悄悄断一次，这份信任就会再被放回刀尖。

所以 F4 不能拖。F2 不能拖。F3 越早跟客户对齐越好——客户已经在催 DOB 自动化了。

桥还在原地。从图纸到通车，再到第一次堵车之后还能继续跑——这才是 Melody 项目真正的故事。

下一章，由下一次报警的人来续。

📖 前情提要：第七至八幕发生了什么？

2026 年 5 月 5 日早上，仓库工人发现导入的订单一进系统就自动被"取消"了。

根因（通俗解释）：插件的"核对逻辑"是这样设计的——定时把千一 WMS 里的所有订单拿出来，跟 AutoCount 那边核对一遍，如果千一里有一张订单但 AutoCount 那边查不到对应记录，插件就认为"这张单是多出来的，应该取消"，然后帮你取消掉。

听起来合理。但它忽略了一件事：WMS 里的订单不是只从一个地方来的。 除了 AutoCount 推过来的，还有员工手动导入的"DOB 订单"，以及仓库工人直接在系统里建的单。这两类订单，AutoCount 那边根本没有记录——于是插件把它们全当成"多余的"，在不到一秒内自动取消了。

就像一个机器人保安，把所有"进门时没刷主门卡"的人都赶出去——但其实有些人走的是侧门，有合法通行证，只是保安不认识那道门。

Derrick 录了一段 37 秒语音，内容是："给我们一个小时。一小时内解决了就继续用 WMS，解决不了，仓库就放弃 WMS。"

Prisma 的 Dhai 在 1 小时内 修复并上线 v1.6.6：插件只核对"自己推过去的订单"，不再管其他来源的单子。事故平息，但被误取消的订单找不回来了，只能重新导入一遍。

第九幕：桥通车之后的两个礼拜（2026-05-06 → 2026-05-20）

v1.6.6 把那一个小时倒数挡下来之后，群里没有再安静。桥还在跑，每天都有新的小石子从车轮底下蹦出来。两个礼拜下来，故事从"插件可不可靠"，悄悄变成了"人在桥上干了什么"。

5 月 6 日——一个新症状冒头。 Malvyn 在群里发图："没有 order 的货，也 scan 进去了"——仓库 checker 扫到了系统里根本不存在订单的货。一开始所有人都怀疑是不是插件又乱来了。

5 月 7 日——PDA 扫描枪事件。 新到的手持扫描枪扫不出 2D 条码。千一一句话切中："卸载重装试下 安装的时候所有权限要都给"。同一天 Malvyn 下单 9 台 PDA（8+1 备用） ——硬件铺开的节奏起来了。

5 月 8 日——5 月 6 日那个症状的真相。 群里有人把诊断写明白："可能是有人在 import 進去了 wms 後又在 autocount 那邊改單……可以去 autocount 的 audit trail 那裡 key in 那個 purchase return 的單號查一查"。AutoCount 的审计日志最后揭出了凶手——是用户 CHOOML 和 CHANWL，在 WMS 已经导入之后，又跑去 AutoCount 手动改单。换句话说：不是插件的错，是人在桥上偷偷改路标。 这一发现，等同于把 F4 那块石头从心口卸了下来——v1.6.6 的对账范围过滤一直在守着，问题出在桥的范围之外。

同一天，群里也补了一条 PDA SOP：拣货拣到一半要退出怎么办？"要退出，就是 back，然后随便选一个号码，按 confirm"。F2 的一小块拼图补上了。

5 月 14 日——v1.6.8 上线，新 bug 浮出水面。 Dhai 在 LS 部署了 WMS Sync Hub v1.6.8。同一天他抓到一条新症状："2 item codes that are unable to create GRN via WMS Sync Hub. Other than these two items, all other items are able to sync back…will investigate further"。这就是 BUG-002——两个特定物料编码走不通 GRN 创建的路。同一天他也把用户手册挂上线：https://wmssynchubdocs.bold-feather-8495.workers.dev/——F2 终于有了正式的文档落脚点。

5 月 18–19 日——一个用户手滑，引出 v1.6.9。 Jin Yee 报告一张拣货单不见了——PN-26050868（RAHMAT BERSIH，4 支 ZAITUN 牙膏）。Dhai 翻日志："User-initiated cancel"——有人在插件里点了"取消"。同胞单 PN-26050867 因为已经发货所以躲过一劫。

第二天 Dhai 直接发版 v1.6.9：

"v1.6.9 修补：以后没推过 WMS 的 picking note 完全不会出现在 Cancel list 里, 而且每次按 Cancel 都会记录用户名、机器名、时间。"

两件事一次做完：没推过 WMS 的拣货单从 Cancel 列表里彻底拿掉；每一次 Cancel 都留下取证级的日志。 然后 Dhai 远程进 LS 把 PN-26050868 救回来，叮嘱："必须用 scanner 在 scan 一次让 picked qty restore 回来。"

5 月 20 日——BUG-003 当天出现。 Malvyn 报 SKU MPSNSW65HCS 显示零库存。千一支持很快定位："单据 800297796 之前拣货到一半被取消 又推送了一次，wms 占用了之前的库存"。一张订单拣到一半被取消再推一次，WMS 会把库存还锁在已取消的那张单上。临时解法是手动关掉那张作废单，然后重新生成拣货任务。千一支持承认："oms 库存同步有点延迟, 这里我让开发看下"——开发已经介入。

这两个礼拜的整体走向，从插件本身的稳定性，悄悄换轨到人在桥上的行为——手动改单、手动取消、取消再推送。v1.6.9 的审计日志，是第一块"鉴识"层的钢筋。它上线的同一周，就抓住了第一个目标。

桥还在跑。但桥要变聪明了——它得记住每一辆车是谁开上去的、什么时候开的、按了哪个按钮。

第十幕：桥要加一条新车道——Purchase Return 加购模块

跟客户群里灭火的同一段时间，Prisma 内部群 PS20 (Internal) Melodies QYWMS AC Integration 里在悄悄做另一件事：把第一笔 RM 13,900 之外的下一张单谈下来。

范围：把"退货流"接上桥

新模块叫 Purchase Return（采购退货）加购模块。流程在 2026-05-11 由 Dhai 写出 9 步草案，2026-05-12 经 Jas 编辑定稿：

  1. 零售商打电话来要退货
  2. 用户在插件里建一张 "Purchase Return Shell"
  3. 插件推一张 inbound ASN（到货通知）到千一 WMS
  4. 司机去把货收回来
  5. 仓库工人在 WMS 扫码 inbound
  6. 千一回调插件，把那张 Shell 单锁住
  7. 插件把 Purchase Return 单据写回 AutoCount
  8. 写回时默认不勾"post to stock"（不直接动库存）
  9. 财务人工复核后再过账

这是桥的第二条车道——第一条是出货（picking → 拣货），第二条是回流（returns → 退货）。

报价：RM 8,000 总价 + HRDF 巧妙拆分

2026-05-18 15:56 MYT，Jas 在群里上传了两份报价 PDF，文件名都是 MR CHANG - WMS INTEGRATION QUO RM8,000.00：

定价逻辑是 Dhai 在 2026-05-13 11:12–11:16 MYT 提出的：

"their want to add on module in plugin. We will Quote Them RM 5000 for add on moudle. But this time their ask 'can claim HRDF?'"

"IDEA 1: 1. PAY FULL PAYMENT FOR RM 3000 FOR ADD ON MODULE. (ONE BILL) 2. CLAIM HRDF RM5000 (SECOND BILL). IDEA 2: 1. PAY FULL PAYMENT FOR RM 3000 FOR ADD ON MODULE. (ONE BILL) 2. CLAIM HRDF RM8000 (SECOND BILL) 3. REFUND RM3000 TO MELODIES."

翻译成生意话：软件开发收 RM 3,000 现金走第一张账单；HRDF 培训补贴 RM 5,000 或 RM 8,000 走第二张账单，由客户拿政府补贴报销。HRDF 培训规模 Dhai 建议 15 人 × RM 200 = RM 3,000 的训练费基础。

老板拉了一下缰绳

2026-05-13 11:05，Teo Kae Shyong（Prisma 老板/会计）发了一句话，把 HRDF 这条线压回了道德边界：

"Have you said all these to them? If not, do not offer using HRdF Training to cover the software dev cost."

"在没和客户讲清楚之前，不要拿 HRDF 培训去包装软件开发的成本。"

这句话很重要——它把"巧妙拆分"和"误导报销"之间那条线划清楚了。Jay 后续问 Teo 倾向哪一个 idea，先推 Idea 1 走全额 RM 3,000 + HRDF RM 5,000 这条干净路。

状态：Derrick 已经签字

2026-05-18 15:56 MYT，Jas 在内部群确认：

"Melodies there confirmed the PR Modules already... i'll ask them pay for this one 1st (full payment)"

Derrick 已经签字接受。 等着 Melodies 把 RM 3,000 第一张账单付掉，Dhai 那边准备 HRDF 培训计划和议程，再走第二张账单的补贴申请。

同期的两件交付内部事

故事意义

第一张单 RM 13,900 是"把桥建起来"。第二张单 RM 8,000（净拿 RM 3,000，HRDF 报 RM 5,000）是"在桥上再加一条反向车道"。

更重要的是，这笔单子的谈判方式：拆账单、用 HRDF 报销软件开发——这是马来西亚中小企业项目里很常见的做法，但很容易越界。老板那一句"在没和客户讲清楚之前不要做"，把这一单的姿态摆正了。

Melodies 这条客户，从 2024 年那个 SME Corp 项目开始，已经做到 2026 年的第二笔加购。这就是"信任会复利"的样子。

📖 前情提要：第九至十幕发生了什么？

v1.6.6 之后的两周，排查出一个"幽灵扫描"现象：有货物被扫描进了 WMS，但订单根本不存在。所有人第一反应都是"是不是插件又出问题了"。

但查了 AutoCount 的审计日志（系统自动记录"谁在什么时候改了什么"的流水账，就像银行的交易记录）之后，找到了真凶：两个员工（CHOOML 和 CHANWL）在货物已经录入 WMS 之后，跑回去手动修改了原始单据。这就造成了两边数据对不上。不是代码的问题，是人的操作习惯。

v1.6.9（5 月 19 日）上线，加了"取消审计日志"：每次用户点"取消"，系统都会记下是谁、在哪台电脑、什么时候点的。就像在关键按钮旁装了一台监控摄像头，上线当周就"抓住"了第一个案子（一张拣货单被用户手动误取消）。

同一时期，Prisma 把第二笔生意谈下来了：Purchase Return（采购退货）模块 RM 8,000。桥要加一条反向车道——不只是货物从仓库出去，还要支持货物从客户那边退回来。

第十一幕：桥在跑，日子继续（2026-05-21 → 2026-07-12）

Warehouse worker using handheld barcode scanner
📱 9 台 PDA 手持扫描枪铺到仓库里Photo · Unsplash

v1.6.9 上线之后，两件事悄悄发生了。

第一件：桥真的稳下来了。五月下旬到七月初，"Integration (Wms x Melodies x Autocount)"群没有再响起那种让人心跳加速的紧急求救。Derrick 没有再录过像 02:10 那 37 秒一样的语音。对于一个每天处理数百张订单的 FMCG 批发商来说，这已经是最好的消息——没有消息就是好消息。

第二件：9 台 PDA 手持扫描枪到货，铺到了仓库里。仓库工人第一次不用趴在电脑屏幕前找货，而是举着枪走到货架前扫码。桥不只是在软件层面通了——它开始被人手里的硬件支撑起来了。

与此同时，桥的第二条车道——Purchase Return 采购退货模块——在 Prisma 内部群 PS20（Internal Melodies QYWMS AC Integration）里紧锣密鼓地开发。Dhai 已经把开发环境（C:\Dev\WMSSyncHub，机器 192.168.1.92 和 192.168.1.151）和他平时用的 AI 提示词文档 PROMPT_USUALLY_DHAI_USE.md 一起交接给了 Yashini。桥要多一个人来铺了。

Prisma 也给这个项目建了一个专属的文档门户：melody.wenjyue.com——从这里开始，所有关于 WMS Sync Hub 的文档、版本说明、SOP，都往这里汇。

这段时间，群里偶尔会有一两条消息——千一那边的系统维护通知、Malvyn 问一个操作细节、Mr Wong 确认一张单的状态。没有大事。桥在跑。

第十二幕：七月的三块小石子（2026-07-13 → 2026-07-16）

七月里，群里终于又热闹了一些。但这次不是大事故，是三块从车轮底下蹦出来的小石子——每一块都有名字，每一块都在 4 天内被清掉了。

第一块：拣货任务"拣到一半，退不回来"

七月十三日凌晨，一张拣货任务被执行了一半，用户想把它退回去重新来——但系统日志显示这张单已经被操作过，无法回退。LS WMS 团队在群里给出结论：

「这个任务看了下日志是有被操作过的……如果从 OMS 导入，需在 OMS 取消后重新导入。」

Derrick 确认了逻辑：「Cancel 掉，重新做，对吗？」

——答案是肯定的。这一条，跟 5 月 5 日那次 BUG-001 的余波是一脉相承的：已经触发了操作的单，没有"撤销"键，只有"重来"路。

第二块：Storage 页面报错

七月十五日，有用户点开 Storage 页面，直接弹错误。

「为什么我按 Storage 就会出这个？」

LS WMS 团队的回复来得很快：「系统昨晚（7 月 14 日约 8 点）已经做了 update，按照提示 refresh 一下页面就好。」

用户试了，回了一句：「OK 谢谢。」

System update 不通知就上线，用户不知道要刷新——这是 SaaS 系统的老毛病，跟代码本身无关。

第三块：WMS 物料类型对不上 AutoCount

七月十六日是这一周最有内容的一天。Malvyn 发了截图——WMS 里某批物料（AYAM.B 系列 SKU）的 Item Type 跟 AutoCount 那边不一致，同一个商品，两边分类不同。

Mr Chang 排查之后，在群里写出了根因：

「主要原因：1. sync 那栏没有打勾。2. status = E（表示异常状态）。
解决方案：进入 WMS SyncHub 页面，在 sync 栏（左边第 1 栏）打勾那些 AYAM.B items，点击 Sync Now → items 的 Item Type 就会 sync 去 WMS。」

片刻后，他又跟了一句：「我有试了这个 Item，已成功 update 了。」

用户跟进：「所以全部显示这个说明的都要重新 SYNC 对吗？」

还有一个衍生问题：没有勾选任何物料直接操作，系统弹出权限提示，用户不知道下一步。Chang 的建议：「你试看用 Retry Failed Item。」

三块石子，四天，全清。七月十四日那一次 system update 把这三个问题的根源一并扫掉了。

教训还是那一条：日常运营中，人的操作习惯（没刷新缓存、Sync 栏漏勾、没选就提交）能造成跟代码 bug 一模一样的症状。日志和 SOP，是区分「代码坏了」和「人做错了」的唯一工具。v1.6.9 的审计日志，这个月继续立功。

第十三幕：DOB 的门，还没开（2026-07-17）

如果说三块小石子是技术层面的顺利收尾，那七月十七日这一天，是一扇门打开了又关上。

DOB 订单的集成——Path B 那个一直悬着的缺口，F3 待办——在 5 月 5 日那次事故之后两个多月，终于等来了一个直接的答案。

七月十七日上午 8 点，Derrick 在群里问：

「@202559381885131（DOB）integration 还没有做好？」

回来的话很平：「要 training 啊，等 HRDF。」

Derrick 追了一句：「所以 after 21/7 就可以 start 用？或者还在 training 而已？」

这一次的回答，把两层卡点都摊开了：

「那个 integration 的哦，21/7 应该来不及，HRDF 有问题，如果很 urgent 你们要不要直接用？」

HRDF 有问题——Purchase Return 那笔 RM 8,000 的单子，有一部分要走 HRDF 人力资源发展基金的培训报销。HRDF 申请需要特定的培训资质认证，认证流程卡住了，没拿到批准，正式培训就没法按计划开。

Mr Chang 接着提了一个过渡方案：

「我是 OK，要先办一个 online 的先？」

回复来了：「你可以的话，我这边加 Liting Chan 就好了。」

这是务实的选择：桥不等证书开通，先把人教会怎么走，再补手续。DOB 集成本身还在开发，但采购退货那条车道，可以先开培训。

第十四幕：七月二十一日下午两点，开课（2026-07-20 → 2026-07-21）

Team video call training session on laptop
💻 2026-07-21 14:00 — Google Meet 培训开始Photo · Unsplash

七月二十日早上，群里开始谈时间。

Chang 问：「照样明天 2pm？或其他哪一个时间你们比较方便？」

Derrick 回了，然后确认参与者：「Melodies 3 PAX：Mr Wong、Jing Wen + Mei Khim。」

之后他补了一句话，语气直接：「你没有回答。我这里通知了，Melodies 两个人上课。」——是催 LS 那边确认，不是在跟 Chang 说话。

同一天上午 7:49，Chang 在群里发出正式会议邀请：

MELODIES PURCHASE RETURN
Tuesday, July 21 · 2:00 – 3:00pm
Time zone: Asia/Kuala_Lumpur
Google Meet: https://meet.google.com/djv-qdcb-hpg

七月二十一日上午 5:47（距离会议还有 8 小时），Chang 发出最后提醒，点名 6 个人。Derrick 回了一个 👍。

下午 2 点整，培训开始。

Melodies 这边来了三个人：Mr Wong（技术负责人）、Jing Wen（郑静汶）、Mei Khim（美金）。入会时有人电脑卡了，Derrick 在群里问：「can us phone？」 Chang 说：「we'll start 1st。」

这是整个项目最重要的一个节点之一——不是因为技术上有多难，而是因为那套 2026-05-11 由 Dhai 写出 9 步草案、2026-05-12 经 Jas 定稿的流程：

  1. 零售商打电话退货
  2. 用户在插件里建 Purchase Return Shell
  3. 插件推 inbound ASN 到千一 WMS
  4. 司机去收货回来
  5. 仓库工人在 WMS 扫码 inbound
  6. 千一回调，锁住 Shell 单
  7. 插件把 Purchase Return 写回 AutoCount
  8. 默认不勾"post to stock"，财务人工复核后再过账
  9. 财务复核完成，过账

……今天第一次坐到了真实用户面前，变成了三个人的操作演练。

下午 3 点，培训结束。Chang 开了 Q&A 环节，发出备用会议链接 jsf-ihbc-xfd，让还有问题的人进来问。

桥的第二条车道，从图纸变成了可以踩油门的路。

第十五幕：权限开，新战场浮出（2026-07-22）

培训结束后的第二天，2026 年 7 月 22 日，事情一件接一件地发生。

早上 3 点 06 分，Chang 在群里厘清了权限现状：Melodies 那边的 Admin 和 WMSSync 两个账号已经开通了 Purchase Return 模块权限，但 LS 那边还没有——他建议 LS 内部先讨论，再告诉他是要自己维护权限，还是叫他来开。

Dhai 回：「ok, we discuss first。」

早上 5 点 25 分，Mr Wong 发来了正式请求，用英文写，简洁明确：

「Hi Chang,
LS would like to start the DOB purchase return process together with Melodies, please open the access for LS admin team as well.
Thanks.」

早上 6 点 16 至 18 分，Chang 开通了权限，并发出截图确认：

「i set for these 2 users (Admin and WMSSync) only
the other users i think better ur site maintain… 🙏🙏」
「now LS also can see this Purchase Return module（Admin and WMSSync only）」

早上 9 点 07 分，Mr Wong 对着群里的 Melodies 联系人正式下达指令：

「@60137300121
Please liaise with Melodies team and LS can start the DOB purchase return process.」

Purchase Return 模块，正式上线。

但桥开通的同一天下午，新的矛盾浮出来了。

下午 12 点 19 至 22 分，Dhai 在群里问了一个问题：

「请问一下如果一张订单有 3 种货品没有库存了，当我们在上传该订单时有办法让系统自动删除那 3 种货品并上传到 WMS 吗？」

他接着补了一句业务背景：

「因为我们现在很花时间在修改订单，如有库存不足的货品该订单无法上传到 WMS。」

LS 系统那边的回答在 12 点 31 分 到达，一句话：

「这个做不到。系统只会校验是否库存充足，不会删除订单明细。」

WMS Sync Hub 现在的设计逻辑是：校验但不删除。它告诉用户「这一行库存不足」，但不替用户做业务决策——删还是不删、改数量还是等货——这些判断权在人手里，不在系统里。

下午 1 点 44 分，Derrick 把他的理解写清楚了：

「要 edit 系统里的订单，save 了，才重新上传 wms，才可以下一步。
原本没有 wms 的 step，SO 也是要 edit 了，才可以转去 inv。相当于系统的 item 和 inv 的 item 是需要相同的。所以有没有 wms，都是要 edit so 的。」

这是 Derrick 自己把账算清楚了——有没有 WMS，编辑这一步都跑不掉。WMS 没有让流程变慢，是原本就有的合规步骤。

下午 2 点 12 分，Dhai 转述了更上层的声音：

「Mr Lee 讲要求他们系统做掉这些东西，因为现在就是做这些东西我们要花很多时间做。」

Mr Lee 的诉求合理：销售订单里如果有 SKU 库存不足，能不能让系统自动剔掉那几行，只推有货的部分进 WMS？省掉人工核对和手动修改的时间。

下午 2 点 38 分，Derrick 的判断来了，一句话：

「auto 应该是做不到吧。」

这一句不是在关门——而是在把这个需求放进「Phase 2 还是 Phase 3」的盒子里。Derrick 做了 25 年批发，他知道「做不到」和「现在不做」是两件事。

与此同时，还有一个问题悬在空中：WMS Sync Hub 的正式 go-live 日期，已经问了 8 天，还没有答案。 Jay 在内部对 Dhai 发了问，但 Dhai 和 Derrick 还没有正式对上这个时间点。

尾声：桥还在原地，路还在延伸（2026-07-23）

从 2026 年 1 月 Derrick 和 Jay 第一次坐下来谈，到 2026 年 7 月 22 日 Purchase Return 模块权限正式开通——这座桥，走了整整半年。

阶段 时间 交付 金额
Phase 1 2026-03 → 2026-05 Picking + GRN + Item Sync + ngrok RM 13,900
Phase 2 2026-05 → 2026-07 Purchase Return 模块 + 培训 RM 3,000（净）+ HRDF RM 5,000

但桥要去的地方，还没有终点：

一座桥，从图纸到通车，再到第一次堵车，再到开出第二条车道，再到有人想在桥上加一套自动分流系统——Melody 项目的真实故事，就是这么一帧一帧走过来的。

项目文档：melody.wenjyue.com

下一章，还是由下一次群里响起消息的那个人来续。

证据来源：WhatsApp 群"Integration (Wms x Melodies x Autocount)"120363425694826375@g.us（2026-07-13 → 2026-07-22，80 条消息）+ Notion Daily Briefs（2026-07-18、07-20、07-21、07-22）

↑ index · wiki/index · now · decisions

See also: 01-project-overview · 02-client-profile · 03-stakeholders · 04-project-history · 05-technical-scope · 06-next-actions · 07-system-analysis · 08-autocount-sdk-reference · 09-tunnel-architecture · 10-qianyi-wms-reference · 11-bugs-and-fixes · 12-architecture-diagram · raw/2026-05-05_whatsapp-integration-chat · wiki/whatsapp-timeline-2026-07-13-22

Melody WMS Sync Hub  |  Prisma Technology  |  melody.wenjyue.com  |  内部文档，请勿外传  |  Photos: Unsplash