yanhui
c5a8b592a1
## 问题 页面「在途加工单 / 已排产」只显示 9 个，且全是 2026-11-03 的僵尸单； 业务在聚水潭看到的是 18 个，且那 9 个早已加工入库完成。 ## 根因 旧数据源是链接服务器快照表 `LS_JS_DMP(192.168.1.209).JSDataMiddlePlatform.dbo.bi_processing_work_orders`： - 表内**无任何时间列**，实测按加工日期自 2026-11-03 10:49 起 **8 天 0 行** （1,370 行 / MAX(Id)=1370 不再增长，而此前每天都有 5~34 行）； - 且**数据陈旧不会报错** —— `workOrderDegraded` 只反映「查询失败」， 停更期间恒为 false，页面完全无告警。 结果：9 行残留「已确认/未入库」把对应成品永久锁成「已排产」压住补货预警， 而 11-04 之后新开的加工单一条都没进库（在途量按 0 算，缺货会被误报）。 ## 改动 数据源改为聚水潭原生加工单三表（业务库本实例，随主库小时级刷新），主键 `po_id` 关联： - `rpt.jst_manufactureInfo` 单头：status / wms_co_id(加工仓) / receipt_wms_co_id(收货仓) - `rpt.jst_manufactureItem` 成品明细：sku_id / qty / io_qty(已入库) / delivery_date - `rpt.jst_manufactureRaw` 原料明细（本次不参与在途核算，配件占用仍走 BOM 单台用量） 口径保持业务确认的语义，只换算字段： - 加工仓：中文名 `加工仓储方` → `wms_co_id = 15718196`（ID 比名称稳定） - 作废：`'作废'` → `'Cancelled'` - 完成：`'全部入库'` → `'Finished'` - 剩余量：`数量 − 已入库数量` → `qty − io_qty` - ETA：`预计加工完成时间` → `delivery_date`（实测 18 单全能解析） - 查询从 `getPool()` 四段名改为 `cloudDatabase.query()`（表名已带 rpt. 前缀，不受 dbo→rpt 重写影响） ## 验证 - 真实库实跑（生产 13333 隧道）SQL 与服务层 `loadPendingWorkOrderIndex()`： 命中 **18 个 SKU / 18 单 / 在途 175 件**，`degraded=false`，ETA 2026-11-24 ~ 11-25； 热态耗时 **0.7~1.5s**（冷启动 5s，结果进 10 分钟缓存）。 - 状态一致性：`Finished` 1,149 单的 1,173 行明细**零剩余**；`Cancelled` 178 单 io_qty 全 0； `Confirmed` 18 单 io_qty 全 0 → 剩余量判据自身即可区分完成，状态只用来剔作废。 - `node --test test/mkhBomService.test.js` **56/56 通过**；全量 505 项 502 通过， 3 项失败均为既有环境问题（secretStore Windows 权限、cloudDatabase 负缓存 TTL、 WST 用例在并发下的时序抖动，单独跑均通过）。 - `check-syntax` 196 文件通过。 ## 风险与回退 - 只换数据源、不动预警优先级与结余口径，接口字段名全部保持不变（`pendingWorkOrderQty/Count/Eta/No`）， 前端零改动。 - 回退：单文件还原 `mkhBomService.js` 即可，无数据迁移、无 DDL。
拼多多自动化运营平台
公开的拼多多业务精简版。欢迎所有人克隆、修改、分发代码并提交 Pull Request，代码按 MIT 许可证开放。
保留商品监控、仪表盘、激励看板、营销活动、推广、商品分析、工单以及在线客户端与执行任务等现有模块。部分菜单仍沿用原项目的占位页面。
已删除市场数据、店铺管理和运营工具整组页面、Claw 对话、skills 管理、平台切换与其他平台演示页，以及对应路由、页面资源、专属配置接口和权限项。首页为仪表盘。保留业务仍使用的模型配置、商品数据查询、桌面会话和自动上架公共服务继续可用；Claw 补全与图搜备用通道已经移除，缺失资料需使用业务接口或手工补充。
本地启动
需要 Node.js 22。团队开发机器无需安装或初始化 MySQL、Redis 及第三方数据库；使用管理员发放的部署 Key，一次注册后自动连接中央系统数据库、公网 TLS Redis 和第三方数据库。完整步骤及安全边界见 远程系统数据库部署。
npm --prefix backend ci
npm --prefix frontend ci
npm run remote:dev
首次启动时填写配置请求地址和部署 Key，系统自动写入被 Git 忽略的本机配置并重启后端。保存一次性显示的管理员账号和密码后直接登录，不需要在本地创建数据库或继续执行设置向导。前端默认访问 http://localhost:5173，API 默认代理到本地后端。
拉取主仓库更新后必须停止旧的 npm run remote:dev 进程并重新启动，保证前后端使用同一版本。MKH 页的强制刷新带有版本协议校验；如果新前端仍代理到未重启的旧后端，页面会停止展示可能过期的库存并明确提示重启，不再将旧值冒充为“最新数据”。
验证与构建
npm --prefix backend run check
npm --prefix frontend run check
前端构建输出位于 frontend/dist。部署时需为单页应用配置路由回退，并代理 /api 与 /cubejs-api 到后端。
启动时会迁移旧侧栏配置，并删除已退役页面的权限、专属设置和专用数据表。上架测算旧偏好表中的商品分析阈值会先迁移到商品分析专用表；其他保留模块的数据不受影响。迁移仅作用于实际配置给此实例的系统数据库。
参与修改
开始开发前请阅读 仓库提交与合并规范（多用户与 AI 开发必读）。准备更新生产服务器时必须继续阅读 服务器部署规范（开发者与 AI 必读）。AI 工具的规则入口为 AGENTS.md。每个任务使用独立目录和分支，通过 PR、同步验证和独立审核合并，禁止强推或覆盖其他开发者的工作。
所有用户均可 Fork 仓库、创建分支并提交 Pull Request。直接推送本仓库需要仓库所有者授予协作者写权限。提交时请说明修改和验证结果，勿提交 .env、密码、令牌、数据库备份或真实业务数据。