|
|
af8f1403fb
|
修复运费对账汇总卡死与订单店铺候选查询过慢
- 运费对账全量汇总：哈希关联的 join buffer 从 16MB 提到 128MB（空间上限 384MB）。
300 万行明细 × 400 万行最新关联表在 16MB 下会退化成磁盘多趟扫描，实测超过
max_statement_time(300s) 也跑不完，页面「记录数/运费合计」永远停在计算中；
调整后约 110 秒出结果并写入缓存。
- 订单售后费用明细店铺候选：改回两个来源各自 DISTINCT 后在 PHP 合并（UNION 会
把两个上百万行结果一起物化去重排序）。同时完整候选只算一次并缓存 24 小时，
冷缓存时先返回毫秒级的店铺目录，完整列表放到响应结束后补齐，避免页面为了
下拉候选把工作进程占住两分钟。
|
2026-10-07 10:52:36 +08:00 |
|
|
|
cf7924fdc6
|
订单售后费用明细：合并淘系（天猫/淘宝）订单来源
聚水潭把淘系订单放在 jst_qmcust_* 系列；页面镜像已接入后，报表改为两套来源合并：
- 订单、明细、售后分别按来源取数（ops_jst_orders* 与 ops_jst_qmcust_*），列映射一致；
淘系明细没有 send_warehouse，用订单上的 wms_co_id 兜底
- 每套来源各自下推筛选条件并按当前页各取所需行数再合并，避免整表物化后排序
- 店铺候选同时包含两类店铺（天猫-/淘宝- 前缀）
- 镜像数据集登记：jst_qmcust_orderlist/_item、jst_qmcust_refundlist/_item 及分层策略
- 用例：淘系订单与售后进入报表、店铺候选包含淘系、双源多店铺筛选
|
2026-10-07 10:00:20 +08:00 |
|
|
|
eda10bd740
|
订单售后费用明细：店铺筛选改为可点选的多选模糊查询
- 店铺名称由单个输入框改为可点选的多选下拉：候选里可按关键字模糊筛选、多选、全选当前结果/清空
- 提交 shop_name[]，多个店铺取并集逐个模糊匹配；保留旧的单值 shop_name 兼容
- 候选来自订单镜像中真实出现过的店铺，缓存 1 小时；单次最多 50 个店铺，超出在面板内提示
- 补充仓库层与页面层用例
|
2026-10-07 10:00:20 +08:00 |
|
|
|
7f71e49c5f
|
fix: keep empty bill offset amounts unknown
|
2026-09-14 11:59:29 +08:00 |
|
|
|
31eaf55ed5
|
账单冲减/售后明细：接入 500112 冲减收入取数（暂用退货红冲金额）
- OrderDataRepository 与 OrderDataMirrorRepository 的 afterSales() 现对 account_500112 取数：\n 暂以「退货红冲金额(reversal_order_amount，即负值商品金额的绝对值)」作为收入冲减口径。\n- 该字段此前在 expenseFields() 中仅被列示、从未取值，故本地恒为 null；\n 其余 account_* 科目字段仍为空，待科目归集（金蝶/外部科目源）整体接入。\n- 取数口径为临时占位，待财务确认最终规则后替换（集中在一处，易于调整）。\n- 账单冲减子页面本页 500112 合计已可正常汇总。
|
2026-09-14 11:45:35 +08:00 |
|
|
|
be670ad988
|
feat: stage tiered business data storage (#104)
|
2026-09-07 11:55:37 +08:00 |
|
|
|
b1bfbe2400
|
perf: avoid promotion sku map scans
|
2026-09-01 13:23:31 +08:00 |
|
|
|
344b8331f4
|
perf: avoid filesort on order mirror pages
|
2026-09-01 13:18:19 +08:00 |
|
|
|
173d218d68
|
perf: hydrate order sku details after pagination
|
2026-09-01 13:01:43 +08:00 |
|
|
|
d62ad27d0f
|
fix: centralize shared business data and remove local sqlite path
|
2026-09-01 11:34:37 +08:00 |
|
