lunanting/cangku
1
0
Fork 1
Code Issues Pull Requests 2 Actions Packages Projects Releases Wiki Activity
230 Commits 78 Branches 0 Tags
Commit Graph

31 Commits

Author SHA1 Message Date
lunanting
d74b4b649a fix: 缺货补货监控改为只统计待发订单（排除已发/取消/拆单/合单），不限日期
All checks were successful
[Do] try bracketed context
Do auto-pass for待发订单 PR
Details
2026-10-22 15:07:29 +08:00
lunanting
c374cbc713 feat: 缺货补货监控改为订单驱动（崔桥当日订单>拣货位库存即需从存储位补货） 
- 货位口径按前缀：XA/XD/XE=拣货位，XX/X9/X5/X4=存储位
- 判断逻辑改为当日订单量>拣货位库存的超出部分=需从存储位补到拣货位的量（上限存储位库存）
- 订单取自 rpt.jst_Orders/jst_qmcust_orderlist（含组合装展开），按最近订单日
- 状态：需补货/存储不足/拣货位充足/今日无单；移除旧的货位清单导入（前缀规则取代）
- 前端列与说明同步更新
 2026-10-22 14:01:35 +08:00
lunanting
55b755c1d9 feat: 新增「缺货补货监控」看板（拣货位缺货 → 从存货位补货） 
数据源：聚水潭「箱及仓位库存」rpt.jst_packInventoryInfo（副本里是视图，
按 SKU+货位聚合单次 35~45s，因此服务端缓存 10 分钟 + 启动预热）。

口径：
- 拣货位：按业务导入的货位清单判定（本地表 bin_replenish_pick_bin，按仓库隔离）；
  副本没有货位类型主数据，未导入时回退为 pack_type='Bin' 的记录，页面明确标注。
- 拣货位库存 / 存货位库存 / 现有库存合计；
- 目标库存 = max(10, 近15天日销 × 目标天数(默认7))；
- 建议补货量 = min(存货位库存, 目标 − 拣货位库存)；
- 状态：拣货位缺货 / 无货可补 / 拣货位偏低 / 未设拣货位 / 正常。
  「未设拣货位」单列，避免把整箱直发商品误报成缺货。

后端：binReplenishService + binReplenishSchema + /api/bin-replenish
（list / export / pick-bins GET-POST-DELETE / ping），建表与预热挂在 localSchema。
前端：/planning/operation/bin-replenish-monitor 页面、侧栏入口、页面权限注册，
含 KPI 卡、状态分段筛选、关键字搜索、目标天数、货位清单导入/清除、服务端导出。
 2026-10-22 11:08:20 +08:00
yanhui
bdc2cf9fd6 feat(wle): 仓储转运异常每天定点推文本到钉钉群 
在「仓储中心物流转运异常」页新增「异常通知」：每天 09:10（可改）把当天核验批次
的异常情况以**文本消息**推到钉钉群，0 条也推（用来确认任务没挂）。

为什么是 text 而不是 Excel 附件：钉钉群自定义机器人 webhook 只支持
text/markdown/link/actionCard，发文件必须走企业内部应用（AppKey/AppSecret/
robotCode/openConversationId 四项凭据 + 应用权限 + 机器人进群）。业务确认
「群里看文本就够，要明细点链接去页面导出」，于是走最轻的 webhook。

后端
- 新增 services/dingtalkRobotWebhookSender.js：POST /robot/send + msgtype=text
  · 加签 urlEncode(base64(HmacSHA256(secret, "timestamp\nsecret")))，timestamp 毫秒
  · text.content 按 UTF-8 **字节**截断到 20000（钉钉硬上限），不切半个汉字
  · webhook 严格匹配 ^/robot/send$ 且必须有 access_token；errcode/errmsg 原样抛
- 新增 services/warehouseLogisticsExceptionNotifySettings.js：
  · webhookUrl 存在 system_config（完整回显，业务要核对）；加签密钥走
    resilientSecretStore，接口只回 configured + 掩码，留空=沿用已存
  · sendTime 非法退回 09:10；maxDetailRows 0~50 默认 30
  · 状态 lastSentDate（按推送日去重）等存 system_config
- 新增 jobs/warehouseLogisticsExceptionNotifyJob.js：
  · buildNotifyText：抬头【仓储物流转运异常】→ 发货/包裹/异常/异常率 → 分类型
    → 剔除数 → 按仓（只列有异常的仓）→ 明细前 N 条 → 页面链接（带 date）
  · 明细行「仓｜内部单号｜快递｜异常类型｜发货时间｜待处理」，字段内换行压平
  · 超长从明细末尾逐条砍并标记 truncated（truncated 只表示被字节上限砍过，
    不表示「按配置只列前 N 条」）
  · 每分钟 tick 比对北京时间 HH:mm == 配置 sendTime，改时间不用重启
- api：GET/PUT /notify/settings、GET /notify/state、POST /notify/run
  （dryRun 预览不校验凭据；probe 只发一句测试文本、不查业务数据）

前端
- 「导出」右侧新增「异常通知」（铃铛）弹窗：开关、推送时间、Webhook、加签密钥、
  明细条数、@所有人、页面链接、上次推送结果、三段帮助说明
- 「测试通道」「预览正文」「保存」「立即推送到群」
- 预览改成弹窗内受控区块：本项目跑 React 19 + antd v5，Modal.info 静态方法
  拿不到 context 会**静默不渲染**（只留一行 warning，看着像后端没返回）

同步与兼容
- 新配置首次读取为空 → ready=false，页面提示「Webhook 地址还没配」，不影响页面其它功能
- 定时任务只在 enabled=true 时生效；本地 ENABLE_BACKGROUND_JOBS=false 不跑，用页面按钮验

验证
- backend/test/warehouseLogisticsExceptionNotify.test.js 15/15：正文结构与数字、
  0 条平安消息、条数上限、字节精简、Webhook 校验、加签 crypto 手算对齐、errcode 透传
- 后端全量 465 项 / 463 过（2 项既有环境失败：Windows 权限位、负缓存需隧道故障态）
- 前端 eslint 0、build 成功
- 真数据干跑：144 条异常 / 列 30 条 / 3768 字节 / 20s，按仓包裹数合计 144 对得上
- playwright 真渲染：弹窗字段 Webhook/加签密钥/明细条数/@所有人/页面链接，
  旧字段 AppKey/AppSecret/robotCode/群会话 ID 零残留；预览内联渲染出正文

风险与回退
- 钉钉侧失败只会记 lastState.lastError 并在页面展示，不影响页面取数
- 回退：删除 index.js 里的 startWarehouseLogisticsExceptionNotifyScheduler 注册即可停推送
 2026-10-22 11:00:10 +08:00
yanhui
85e2db9f92 feat: 仓储中心物流转运异常页新增「导出异常明细」（Excel / CSV） 
- 后端新增 GET /api/warehouse-logistics-exception/export：复用列表同一套口径
  （getLogisticsExceptions），只把明细上限从列表 2000 放宽到 5000，不分页，
  判定/剔除逻辑一行未改，避免「导出与页面两套口径」。
- 结果缓存由单槽改为按 `核验日|明细上限` 分键的 Map（上限 8 条）：
  页面按默认条数取、导出按 5000 取，单槽会互相踢掉 —— 导出一次，页面下次
  自动刷新就得重查库（20~40s）。分键后两者互不影响。
- 前端把明细过滤抽成 filterDetailOrders，表格与导出共用同一个函数，
  保证「导出的就是页面看到的」。
- 导出列单独定义 EXPORT_COLUMNS（13 列纯文本标题）：页面列用了 Tooltip，
  直接复用列定义会把表头导出成 [object Object]；运单号/物流状态/最后轨迹
  为空时导出为「无运单号 / 无状态 / 无轨迹」，Excel 里不留空格。
- 导出跟随当前核验日 + 选中仓 + 选中异常类型；文件名带核验日与筛选范围
  （仓储物流转运异常_<核验日>_<仓>_<类型>）；0 行时提示且不生成空文件；
  超过 5000 行时如实提示「已截断」。导出按钮做 loading，防重复点。
- 测试：新增 2 个用例 —— ①导出行数等于异常包裹数、字段齐全、带剔除口径；
  ②缓存按 limit 分键（页面 1000 条那份不被导出 5000 条顶掉）。
  warehouseLogisticsException.test.js 26/26 通过。

口径未变：承运商剔除（顺丰系全剔、京喜京东、睢宁中通按仓、武进安能/中铁/
壹米滴答/自提/线下/商家配送）、订单终止与刷单信誉单剔除、异常 5 类判定，
全部沿用 #71 已合并版本。
 2026-10-22 09:58:22 +08:00
yanhui
db1ba79416 feat: 新增「仓储中心物流转运异常」页面（12 发货仓 · 每日 09:00 核验前一日已发货物流） 
- 后端新增 warehouse-logistics-exception 模块（Registry / Service / Api），
  挂载 /api/warehouse-logistics-exception；前端新增独立页面并接入左侧栏
  「仓储中心物流转运异常」（排在「仓储中心 24 小时发货时效」下面）。
- 核验口径：核验日 09:00 看**前一日已发货**订单的物流记录；12 个发货仓按仓库名
  最长匹配归口（子仓并入主仓，「京仓-横林二仓京东云仓」排除）。
  只统计揽收前的卡点：无物流单 / 未揽收 / 已揽收未中转 / 快递报异常 / 退回；
  运输中、派送中、已签收一律正常（干线与中转轨迹本就不回传，不再按 24h 判停滞）。
  明细按包裹、汇总按内部单号去重；结果缓存 5 分钟，force=1 可绕过。
- 剔除口径（业务 2026-10-21 / 10-22 定版，剔掉的既不算异常也不算发货分母）：
  · 承运商：顺丰系全部（唯品顺丰 / 顺丰干配 / 顺丰大件各账号）、武进安能、中铁、
    壹米滴答、京喜京东（快递·快运）、自提、线下、商家配送；
  · 有条件剔除：睢宁中通只在睢宁仓考核，其它仓异地打单的剔出；
  · 订单已终止：状态含取消/作废，或标签含「发货后取消」「作废」「拦截」；
  · 刷单 / 信誉单：订单标签含「刷单」「转空包」。
  「武进安能」「京喜京东」均按精确粒度匹配，不泛化成「安能」「京东」，避免误剔
  常州安能新、京东自营快递亿家达等正常账号。
- 时区：模块内统一用 Asia/Shanghai 取「今天」，避免生产容器 Etc/UTC 导致核验批次错位。
- 页面：分仓统计卡 + 异常类型筛选 + 明细（承运商 / 运单号 / 物流状态 / 异常标签 /
  最后轨迹 / 发货时间 / 待处理小时），页脚展示剔除口径与本批剔除量；
  物流快照停更按黄/红两级告警，并标注「历史批次按当前物流快照重算」。

验证（本地隔离环境，非生产库）：
- node --test backend/test/warehouseLogisticsException.test.js → 24/24 通过
- npm --prefix frontend run check → 通过
- 本地真实数据接口实测：顺丰系、睢宁中通（异地仓）明细 0 条残留
 2026-10-22 09:07:49 +08:00
yanhui
893f4d6aca feat: 新增「仓储中心24小时发货时效」侧栏（11 个主仓 · 12:00/16:00 双轮核验） 
需求（yanhui 2026-10-20）：在 MKH-BOM 列表左侧加一栏「仓储中心24小时发货时效」，
下列 11 个主仓（横林二仓、横林三仓、横林二仓品牌仓、崔桥工厂仓、崔桥工厂品牌仓、
崔桥工厂半成品仓、新苏北仓、睢宁仓、山东青岗集仓、山东品牌仓、河南洛宁仓），
从系统库存抓取已发货/未发货订单，按订单创建时间判定发货是否及时：
· 每天 12:00 核验「当天创建时间 7:00 之前」的订单是否已完成发货
· 每天 16:00 核验「当天创建时间 16:00 之前」的订单是否已完成发货

已确认的三条设计决策：
1. 子仓归属 → 连子仓一起算（京东云仓/自营仓/运营C专用仓/唯品仓等并入主仓）
2. 崔桥工厂半成品仓 → 系统无同名仓，先留空占位（不映射到配件仓 15718196）
3. 展示结构 → 只显示超时未发

实现要点
- 仓库归属用「关键词最长匹配」（不写死 wms_co_id），新增子仓只要名字含主仓关键词
  就自动归入，缓存 1h。实测 28 个子仓全部正确归入 11 个主仓，132 个代发仓零误并。
- 12:00 之前**不做核验**：resolveActiveRound 返回 null，服务层直接返回 notStarted，
  既不查订单表（接口 165ms）也不回填昨天的数据。前端显示「未到核验时间」+
  「12:00 开始首轮核验（核验当日 07:00 前创建的订单）」，11 个仓结构保留、数字显示「—」。
- 订单取数：两张表店铺互斥（jst_Orders = 京东/拼多多/抖音/得物/唯品会，
  jst_qmcust_orderlist = 天猫/淘宝/1688），并行分开查 + Node 侧按 o_id 去重合并，
  用 Promise.allSettled 保证单表失败时另一表数据仍可用（detailDegraded 标记）。
- 三态判定 pending / shippedLate / onTime：send_date 与出库表 io_date 取先到的发货痕迹，
  避免上游 send_date 回写滞后导致「已发的被判成没发」。
- 状态过滤：排除 Cancelled / Merged / **Split**（拆单父单永不发货，不排除会捞出一年前
  1.3 万条历史单），Question 仍计入待发。
- freshness 字段如实报告出库表最新 io_date，前端「发货数据可能滞后」告警，
  不拿一份可能滞后的数据去考核仓库。

排除的两次错误优化（均在代码注释里留了实测数据与复测脚本路径）
1. 用 created 替代 order_date 做窗口过滤（快 10 倍）—— 已证伪：2581 行里完全相等的只有 4 行，
   差 >1h 的 412 行，198 行跨日；典型形态 order_date=10-18 23:58 而 created=10-19 04:00:08
   （上游凌晨 4 点批量补录，created 是灌库时间不是下单时间）。业务口径是「订单创建时间」，
   只有 order_date 正确。
2. 「UNION ALL 一条 SQL 慢 5~8 倍」—— 被后续实测推翻（46.3s vs 并行 48.2s，基本持平）。

验证
- 新增 backend/test/warehouseShipTimeliness.test.js，10 条用例全绿，覆盖：
  最长匹配不误并、子仓命名、山东/河南高频前缀不误并、占位仓、12:00 前返回 null、
  12:00 轮窗口 00:00~07:00、16:00 轮窗口 00:00~16:00、状态排除表、三态分桶互斥、
  跨表重复 o_id 去重、round.windowEnd 必须带出（否则前端渲染成「核验 前」）。
- check-syntax 185 文件通过；全量 node --test 415 项 / 413 过 / 2 fail，
  两条失败均为已知环境因素（负缓存带 TTL 因 .env 有 CLOUD_DB_* 短路；
  resilientSecretStore 的 Windows 权限断言，基线恒失败）。
- 真渲染验收（组件级沙盒 + 真实接口数据）：两态均 0 控制台错误；
  已核验态 358 单超时未发、8 个仓有数字、点仓切换选中/再点取消均正常；
  多分辨率验证 1920/1600 侧栏 208px、1440/1366 收窄 176px、列表始终竖向。
 2026-10-20 11:23:08 +08:00
youruo
70550b5499 feat: 新增二级页面「拣选库位动销分析」（大货库存监控） 
- 后端：pickingBinSalesAnalysis 配置/服务/路由，仓位库存取 rpt.jst_packInventoryInfo
  （bin_group 空值=拣选位、存货=存货位），销量按「SKU 占用同类仓位数平均分摊」，
  恒等式「全部库位销量之和 = 有库位 SKU 销量之和」差异为 0
- 动销等级（近 N 天日销，默认 15）：爆款>=20、热卖款 10-20、平销款 3-10、
  滞销款-1 1-3、滞销款-2 (0,1)、销售=0
- 前端：大货库存监控下新增二级菜单 + 页面（等级卡片、仓库/类型/天数/仓位筛选、
  分页表格、xlsx 导出），路由/菜单/页面权限四处注册
- 测试：后端 8 项单测通过；前端 lint/test/build 通过
 2026-10-07 16:59:39 +08:00
youruo
2c8ed86c26 feat: 库存动销分析「销售=0」档支持导出 SKU 明细 
- 后端新增 GET /api/stock-sales-analysis/zero-sales-export：
  复用与页面完全一致的分档口径（同一段 gradeCase 表达式 + 「有库存或有销量」过滤），
  输出仓库/SKU编码/SKU名称/库存数量/销量/统计天数/统计基准日的 SKU 级明细；
  支持.days 统计窗口、wmsCoId 逗号分隔过滤（仅允许仓库清单内的 ID，防任意拼参）、
  format=xlsx|csv，复用通用导出服务 exportWorkbook
- services 新增 fetchZeroSaleSkuRows：SKU 级「销售=0」查询，LEFT JOIN rpt.jst_sku 取名称，
  按仓库+库存倒序排列
- 前端工具栏新增「导出销售=0」按钮：跟随当前统计天数与仓库筛选，
  文件名含业务日期与仓库范围，失败时解出错误体给出可读提示
- 测试补充 3 条：防呆抛错、空参短路、SQL 口径与参数传递断言

验证：后端 syntax 通过、单测 8/8（全量 389 条仅既有 Windows 环境项失败）；
前端 eslint/build/test 21/21 通过；
本地实测：全仓导出 3641 行、26 仓、销量列全为 0；
单仓（崔桥半成品包装 694 行）与页面「销售=0」SKU 数一致；
浏览器实测点击下载真实文件名「库存动销分析-销售0明细-20260926.xlsx」
 2026-09-27 17:47:45 +08:00
youruo
f20bd3a487 feat: 侧边栏新增二级「库存动销分析」页面 
按《仓库库存动销分析.xlsx》：
- 一级菜单「大货库存监控」下新增二级「库存动销分析」（路由 /planning/operation/stock-sales-analysis）
- 表头与表格结构按需求表：仓库 | 动销等级 | SKU数量 | SKU占比 | 库存数量 | 库存占比 | 销量，
  每仓 6 个动销等级（爆款/热卖款/平销款/滞销款-1/滞销款-2/销售=0）+ 1 行汇总，仓库列跨行合并
- 分档口径：日销 = 统计窗口内已发货件数 ÷ 窗口天数（7/14/30 天可选，默认 30），
  库存取 rpt.jst_inventoryInfo 实时库存，销量取 jst_Orders×jst_OrderItem 按 send_date
  （排除 Delete/Cancelled，与每日进销存发货口径一致），只统计有库存或有销量的 SKU
- 后端 /api/stock-sales-analysis：单条 SQL 一次覆盖全部仓库×等级，5 分钟缓存 + refresh=1 强制重算；
  返回逐仓 + 全仓合计、占比、无数据仓数量
- 前端页面：统计天数/仓库筛选、口径说明弹窗、合计行高亮、无数据仓计数提示
- 页面权限：前后端 sidebarPages 注册 pageKey=stock_sales_analysis，默认 planning 角色可见

验证：后端 syntax + 单测 5/5；前端 eslint、build、npm test 21/21；
本地接口 30 天窗口实测 27 仓（崔桥汇总 2080 SKU / 90822 件 / 54076 件销量），
占比逐仓闭合为 100%；浏览器实测侧边栏入口、表头、197 行渲染与截图均正常
 2026-09-27 16:29:58 +08:00
youruo
0e77a70c33 feat: 每日进销存支持导入聚水潭官方进销存校正数据 
业务库只能还原 4/12 个流水列且口径与聚水潭不一致（采购按单据日期、销售按订单发货日期，
jst_salesOutboundInfo.qty 全为 0），调拨/盘点/加工/其它出入库无单据表，故以官方导出为准：

- 新增本地表 daily_inventory_official（biz_date + warehouse 存期初/12 流水列/期末）
- 新增解析与导入服务：xlsx 解析、仓库 ID 映射、「期初+流水=期末」恒等式校验
- GET /api/daily-inventory 支持 ?date= 指定业务日，官方值优先、缺失回退推算并返回来源标记
- 新增 POST /api/daily-inventory/official-import（xlsx 上传/JSON）与 GET /official 查询
- 导入后回写本地库存快照（官方期初→上一日期末、官方期末→当日期末），使推算也对齐
- 前端：业务日切换、官方/推算来源标记、导入弹窗、口径说明同步更新
- 仓库清单补入「简尚-横林三仓主仓」（聚水潭导出中存在）
- 命令行导入：npm run inventory:import-official -- <日期> <xlsx>
 2026-09-27 14:16:06 +08:00
youruo
3bfc48b8b3 Merge branch 'codex/daily-inventory-snapshot-0924' into codex/daily-inventory-notify-0924 
冲突文件：backend/src/index.js
处理理由：采用已解决好与他人 PR #40/#41 冲突的分支 A 版本，再补回本分支的通知接口
require、/api/daily-inventory-notification 路由注册与调度器启动，双方行为均保留。
 2026-09-26 12:18:11 +08:00
youruo
734b974f45 Merge branch 'main' into codex/daily-inventory-snapshot-0924（同步 PR #40/#41） 
冲突文件：backend/src/index.js
处理理由：main 侧（他人 PR #40、#41）新增崔桥工厂仓客退三类路由 require 与注册、统一 404 与 JSON 错误处理中间件；
本分支仅新增每日进销存快照任务的 require 与 startDailyInventorySnapshotScheduler() 调用。
采用 main 版本文件并补回本分支两处改动，双方行为均保留。
 2026-09-26 12:16:30 +08:00
lunanting
b0f56b27f5 客退看板首仓改为崔桥工厂仓（数据源：崔桥工厂客退临时上架仓） 
按 2026-09-25 业务口径，第一张子看板由「横林二仓客退数据监控」改为
「崔桥工厂仓客退数据监控」，取数仓位同步改为聚水潭「崔桥工厂客退临时上架仓」。

- 仓库配置：简尚-崔桥工厂仓 wms_co_id=15038426，客退位 customize_qty_1
- key 由 henglin2 改为 cuiqiao，同步改路由 / 侧边栏 / 路由映射 / 权限条目
- 旧路径 returns-inventory/henlin2* 保留为重定向，避免历史链接 404
- 核销看板（returnMonitorService）仍指向横林二仓，前端入口已下线，本次未动

副本取证：该仓客退位当前只有 2 编码 / 2 件（退货单有量：ERP 3115 条 +
奇门 1812 条），属「客退上架库存未同步进副本」，页面需靠导入功能补数据。
 2026-09-25 14:16:11 +08:00
lunanting
90fa54bd8c Merge branch 'main' into codex/cangku-returns-monitor-001 (sync 41 commits, keep both sides) 2026-09-24 15:37:59 +08:00
youruo
56fba389e4 feat: 每日进销存增加定时截图通知 
设置（仅管理员）
- 可配置是否启用、通知时间（默认 01:00 Asia/Shanghai）、多名通知用户
- 收件人在后端规范化：去空、去重、限长限量，配置持久化到 system_config
- 接口不返回通知中心密钥与对象存储密钥，只给是否已配置与脱敏预览

定时任务
- 单实例锁（MySQL GET_LOCK），按配置时间触发，命中后 30 分钟内失败最多补跑 3 次
- 服务端签发 15 分钟短时效 JWT 作为专用身份，令牌只写入浏览器 localStorage
- 等数据真正渲染完成（有数据行、无加载中、无错误提示）才截图，展开滚动容器后整页截图
- 对象键形如 daily-inventory/2026-09-25/daily-inventory-20260925-010000.png
- 截图上传成功后才逐用户发通知，单人失败不影响他人；正式推送按「业务日期+收件人」幂等
- 立即测试走同一链路但幂等键带随机数，不影响次日正式推送
- 每次执行记录时间、截图地址、通知对象、成功状态与失败原因

测试
- 覆盖收件人去重、通知时间校验、幂等键、业务日期与对象键、重试退避（17 项）
 2026-09-24 11:22:51 +08:00
youruo
9dbe2793a5 feat: 每日进销存改为全部从数据库取数 
- 期初数量改由本地快照表 daily_inventory_snapshot 提供（上一业务日期末），
  每日 01:30 定时任务落库，接口侧缺失时补写兜底，逐日自动滚动
- 新增 dailyInventorySnapshotDb / dailyInventorySnapshotJob 与手动补跑脚本
- dailyInventoryBaseline 瘦身为纯仓库映射，去掉所有硬编码业务数值
- 12 个流水列因业务库缺单据表返回空值，前端灰底显示「—」
- 修复 qty 全为 0 的仓库期末显示 null 的缺陷
- 新增 docs/库存流水单据表需求.md 给 DBA
 2026-09-24 11:20:30 +08:00
youruo
855586d5de feat: 新增每日进销存（大货库存监控） 2026-09-23 17:37:44 +08:00
lunanting
592c52f891 refactor: 移除大货库存监控功能（26 仓） 
应用户要求下线该功能组，侧边栏不再显示「大货库存监控」及 26 个仓库二级菜单。

移除内容：
- 前端页面 LargeStockMonitor、18 列定义、API 封装与样式
- 路由 /planning/large-stock-monitor/:warehouseSlug 与权限点 large_stock_monitor
- 侧边栏菜单组 stock-monitor-large 与 SIDEBAR_ROUTE_MAP 26 条映射
- 后端 /api/large-stock-monitor 路由挂载、largeStockMonitor.js、
  largeStockMonitorConfig.js、largeStockMonitorFlow.js 及端到端校验脚本

验证：
- 全仓无 largeStockMonitor 残留引用；后端 346 用例 345 通过
  （1 项失败为 resilientSecretStore.test.js，Windows 权限语义基线既有失败）
- 前端 lint + 测试 + 构建通过，产物中 LargeStockMonitor chunk 已消失
- 运行时验证：/api/large-stock-monitor/* 返回 404，页面与登录不受影响
 2026-09-23 16:07:04 +08:00
lunanting
2bc949099b feat: 新增大货库存监控（26 仓） 
按「库存监控」表格在侧边栏增加一级/二级菜单与共用页面
（路由 /planning/large-stock-monitor/:warehouseSlug）。

后端：
- 新增 largeStockMonitorConfig.js：26 仓配置，含 wms_co_id / 快照仓名 / routeKey / slug 映射
- 新增 largeStockMonitor.js：config / overview / sku-list 三个接口
- 新增 largeStockMonitorFlow.js：采购进仓、采购退货、销售出仓、销售退货四类单据流水取数
- 新增 verify-large-stock-monitor.js：26 仓端到端校验脚本
- index.js：挂载 /api/large-stock-monitor 路由

口径说明：
- 库存周转天数 = 月度发货总件数 / 月度日均库存件数 × 100%，下沉到 SQL CASE WHEN 计算
- 四级分级（滞销预警/慢流/呆滞/僵尸）按库龄 + 周转率双维度判定
- 期末数量取聚水潭实际库存 jst_inventoryInfo（按 wms_co_id 单仓），
  不用 pm_stockMonitor.jsStock —— 后者 warehouse 是「归属仓」口径，
  会把已调拨到外仓的货仍计在本仓名下（崔桥工厂仓因此虚高约 2.2 万）
- 截止时刻统一为快照日次日 01:00（跑批时点），库龄/分级均以此为基准，不再用 GETDATE()

前端：
- 新增 LargeStockMonitor 页面、18 列定义、API 封装与样式
- 路由与侧边栏：26 条二级菜单 + 权限点

冲突处理：
- 主仓库已下线 /api/dashboard（backend/src/api/dashboard.js 被移除），
  相应删除 dashboardRoutes 的 require 与挂载，避免后端启动时 require 失败崩溃
- 保留主仓库新增的「模块化库存监控」菜单组及其子项
 2026-09-23 13:42:58 +08:00
lunanting
b3f4d1af64 feat: 客退数据监控五仓看板与本地运行稳定性加固 
功能：
- 退货库存预警：横林二仓/苏北/睢宁/山东青岗集/河南洛宁 五张看板，
  按各仓客退上架仓对应的自定义库存位取数（各仓位不同：横林/苏北/睢宁 c1，山东 c2）
- 支持导入聚水潭「箱及仓位库存」导出文件覆盖创建时间、件数、供应商
  （副本只有仓库级数量，没有箱级维度，真实上架时间只能靠导入）
- 退货入库核销与每日库存监控：状态落本地系统库，含定时任务与差异清单
- 服务端导出（xlsx/csv），不受列表分页与展示上限约束

稳定性：
- 前端幂等请求在后端重启窗口内自动退避重连，不再直接抛 500
- 后端补齐统一 JSON 错误兜底与 /api JSON 404，异常不再返回 HTML
- 隧道 ssh 改为绝对路径解析并隐藏窗口，避免非交互式启动 ENOENT 与黑窗弹窗
- 业务库 DATETIME 按北京时间解析（useUTC: false），修复时间显示整体 +8 小时

合并：与上游「隧道断线自愈 + 配置负缓存」为同一问题的两份实现，
本分支采用上游方案（带 TTL 的负缓存 + 统一失效函数 + 单测）。
 2026-09-23 11:32:16 +08:00
134
b8e60a19d2 fix: MKH刷新改用实时订单库存口径 2026-09-23 11:12:08 +08:00
134
fa91b9242c fix: 根治MKH同步后旧请求覆盖最新数据 2026-09-23 11:05:28 +08:00
yanhui
b7aca2343b feat(配件库存监控/MKH-BOM): 新增「采购在途」数量列与在途明细弹窗，补货预警改按结余库存判定 
配件库存监控：
- 列表「实时库存」后新增「采购在途数量」列，口径 SUM(MAX(0, jst_purchaseItem.qty - inQty))
- 顶部「实时库存合计」后新增可点击「采购在途」卡片，弹窗展示在途明细
  （商品编码/商品名称/采购数量/已入库/在途数量/计划到货日期/采购单号），支持关键词、排序、分页
- 新增后端接口 GET /api/modular-stock-monitor/purchase-in-transit
- 筛选器品类改直查 jst_sku 主表，避免新增 OUTER APPLY 拖慢筛选
- 采购在途列仅取数展示，不参与 ORDER BY / 聚合（规避 MSSQL 对 OUTER APPLY 列的灾难性执行计划）

MKH-BOM 补货预警：
- 日销驱动与已排产分支改用「结余库存 = 现有库存 - 待发货件数」判定可用天数与预警等级
- 建议补货量按 ceil(3 天日销 + 待发货件数 - 现有库存) 计算
- 新增 scope=work-order 范围筛选；列表新增「结余库存」列
- 打印模板剥离公司名前缀，打印字号调大

测试：mkhBomService 单测新增结余库存缓冲/紧张用例与回归用例
 2026-09-18 17:44:01 +08:00
yanhui
be52bdd0b5 feat(配件库存监控/MKH-BOM): 两页面新增「同步最新数据」按钮 
需求：配件库存监控、MKH-BOM 资料两个页面各加一个同步按钮，任何时候点击都能
立即拉取最新数据，不必等凌晨 00:00 的定时刷新。

后端：
- mkhBomService 新增 clearMkhBomCache()：清空本页全部服务端缓存
  （businessBom / officialBomIndex / officialBomDetail / productBom /
  mkhProduct / replenishIndex / workOrderIndex / pendingOrderIndex /
  componentStock / componentLocation），返回 syncedAt + 各缓存清除条目数。
- modularStockMonitorService 新增 syncModularStock()：本页无进程内缓存
  （每次请求直连副本库），同步动作 = 重新解析并返回最新监控日，前端据此重拉列表。
- 新增接口 POST /api/mkh-bom/sync、POST /api/modular-stock-monitor/sync。

前端：
- api/mkhBom.js 新增 syncMkhBom；api/modularStockMonitor.js 新增 syncModularStock。
- 两个页面工具栏各加「同步最新数据」主按钮（SyncOutlined，带 loading 态），
  点击 → 调后端 sync → 成功后重新拉列表（MKH-BOM 页同时清空展开明细缓存
  detailCache，避免看到旧的配件明细）→ 提示「已同步最新数据」；
  失败时展示后端返回的错误信息。

口径说明（重要）：
- 两页数据来自副本库 JSReportReplica，由上游聚水潭同步；应用层无法触发上游拉取。
  本按钮的作用是「清服务端缓存 + 直连副本库重取最新」，保证看到的不是
  2~15 分钟前的缓存结果，而不是重新跑一遍上游同步。
- 后端已内置的 dailyRefresh（cron 0 0 * * *，Asia/Shanghai）刷的是
  summary_daily_* / summary_monthly_* 汇总表，不覆盖这两页数据源，
  与本按钮既不重复也不冲突，可并存。

验证：
- 后端 4 个改动文件 node --check 全部通过。
- 前端 4 个改动文件（含 2 个 jsx）用 @babel/parser 解析全部通过。
- 实测：syncModularStock 返回 monitorDate=2026-09-16；
  clearMkhBomCache 返回 syncedAt 与各缓存清除条目数。
- 单测 mkhBomService.test.js 40/40 通过，无回归。
- 前端 lint/build 未运行：frontend/node_modules 仍是之前被中断 npm ci 破坏的
  坏目录（frontend/node_modules_broken_0917/，未纳入提交）。
  合并前需在本机 npm ci 恢复后，打开两个页面确认按钮渲染与点击效果。
- 后端改动需重启服务后才生效。
 2026-09-17 18:14:57 +08:00
yanhui
fe831c32fd feat: MKH-BOM 补货预警排除在途加工单、缺货通知推送、导出功能 
- 补货预警：接入加工单(链接服务器 bi_processing_work_orders)，有未完成加工单则不预警，新增在途加工量列
- 新增每日 09:00 缺货/预警通知推送（cron + 统一通知中心 + 幂等键）
- 新增导出：商品清单 / 配件明细，XLSX / CSV，按当前筛选条件全量
- 配件仓位：新增 loadComponentLocations 批量加载器（导出/列表展开共用）
 2026-09-17 10:01:13 +08:00
yanhui
445347e664 feat: 启用运营分析模块，新增模块化库存监控与 MKH-BOM 资料 
本次将此前被列入退役名单的运营分析相关模块恢复为可用，并新增「模块化库存监控」
一级菜单及其两个子页面。

主要变更：
1. 恢复启用：商品监控、激励看板、营销活动、推广模块、商品分析
   - retiredFeatures 移出对应退役名单与清表语句，改为正常保留
   - 补齐后端路由、前端页面与 API 封装、侧边栏配置、桌面客户端能力项
   - 同步更新 retiredFeatures / retiredRoutes / retiredNavigation / desktopSessionService 测试
2. 新增「模块化库存监控」一级菜单
   - 配件库存监控：仅取「简尚-崔桥工厂半成品包装项目仓」SKU 的实时库存、
     当日入库/出库、近 7 日日均发货量、库存可用天数与预警（库存可用天数 ≤ 7 预警）
   - MKH-BOM资料：按商品编码展示配件明细、数量、仓位、库存，支持 A4 纵向打印
3. 新增产品资料系统数据库（PostgreSQL）连接模块：读取系统库 database_configs 中
   name = product_information_database 的配置，凭据只从配置读取，不落代码
4. 新增系统设置页配置项：商品标签配置、部门商品标签配置、部门SKU负责人配置
5. 旧 /api/dashboard 接口迁移至 /api/productAnalysis，仪表盘预览页改用新接口，
   相应移除 dashboard 路由模块及其测试
6. 修复 retiredRoutes 测试在 Windows 下挂起超时的问题：该测试用
   parent.filename.endsWith('/api/planningUpload.js') 判断是否注入 mock，
   而 Windows 的 filename 为反斜杠路径，导致判断恒为 false、mock 全部失效、
   真实模块去连中央系统库而挂起（Linux CI 正常）。改为平台无关的路径匹配。
7. .gitignore 忽略本地验证产物（outputs/、.git-status.txt）

验证：
- 前端：lint / test（16 项）/ build（含 planning entry 校验）全部通过
- 后端：语法检查 149 个文件通过；测试 38/39 通过
- 已知未通过项：resilientSecretStore.test.js 断言密钥备份文件权限为 0o600，
  Windows 下 chmod 无法表达该权限（实际为 0o666），属既有的平台相关失败，
  与本次改动无关，本次未修改该文件
- 说明：本机 frontend/ 下存在未纳入版本库的旧依赖备份目录 node_modules_old_*，
  会污染 ESLint 扫描（十余万条第三方报错），故 lint 步骤以
  --ignore-pattern node_modules_old_*/** 排除后执行，其余步骤与仓库 check 一致

未提交内容：本地验证截图 outputs/ 与 .git-status.txt 已被 .gitignore 排除。
 2026-09-15 16:53:12 +08:00
lunanting
d9ebbba61e refactor: remove commerce monitoring feature suites 2026-09-12 18:49:37 +08:00
lunanting
36948c98ca refactor: remove store and operations feature suites 2026-09-12 17:50:26 +08:00
lunanting
3239d6a558 feat: bootstrap local instances from central system database 2026-09-12 16:06:01 +08:00
lunanting
ec8949cfbf Initial public PDD edition without market, Claw, skills or platform switching 2026-09-12 11:51:44 +08:00