|
|
951fde9c46
|
账单页签:总账备注下拉候选合并科目映射表的财务备注
- 之前候选只来自总账备注映射表,科目映射表里新加的备注在下拉里选不到
- 现在两个来源取并集,改完映射表下一次请求即可筛选
|
2026-10-10 11:20:18 +08:00 |
|
|
|
dd03037105
|
账单页签/账单明细:财务备注按科目映射表关键词取最具体规则
- 行内财务备注把 channel/business_type/order_type 等业务字段纳入关键词匹配(得物退款行可识别)
- 「总账备注/财务备注」筛选折算 SQL 时支持同一账单项目多条规则的关键词条件与兜底反向条件
- 与业绩明细、科目映射表口径对齐(得物退款行统一显示/筛选为退款)
|
2026-10-10 11:13:46 +08:00 |
|
|
|
217b953a03
|
唯品会JX账户:科目映射与总账备注按行内「账单项目」匹配
- AccountLedgerRemarkMap:JX 页签取 payload.second_remark 作为映射的账单项目,
与「科目映射表」里按账单项目(处罚款/客服特殊退款-仅退款/盘盈盘亏…)维护的规则对齐
- AccountBills:总账备注筛选对 JX 改为按行内账单项目过滤,其余页签不变
- 测试同步(总账备注筛选按账单项目命中)
|
2026-10-09 16:57:28 +08:00 |
|
|
|
499a9e12a6
|
唯品会JX账户:「账单项目」筛选改为按行内账单项目过滤
- 筛选下拉与筛选条件都取 payload.second_remark(处罚款 / 客服特殊退款-仅退款 / 盘盈盘亏 …),与页面「账单项目」列同源
- 唯品会MP页签维持按账单项目列过滤;导出走同一套过滤逻辑
- 同步更新 JX 页签测试(筛选选项与导出断言)
|
2026-10-09 16:36:09 +08:00 |
|
|
|
f82856a6f7
|
唯品会JX账户:列名「二次备注」改为「账单项目」
- 与费用规则里「账单项目」的叫法统一(该列即账单项目/业务备注,用于匹配科目映射表)
- 同步更新列名断言
|
2026-10-09 16:29:18 +08:00 |
|
|
|
9ce9ee74eb
|
唯品会JX账户:表头改为「明细类型/二次备注/总账备注/订单号SO/收入/支出/合计」模板
- 按财务给的「唯品会JX汇总10.9」模板调整页签列:类型→明细类型、销售订单号→订单号/SO、
含税金额→合计金额,总账备注与二次备注紧跟明细类型,收入/支出保持独立列
- 同步更新 VipshopJxReceivingBillsTest 的列名断言(原先还在断言已改名的「订单结算时间」)
|
2026-10-09 15:58:01 +08:00 |
|
|
|
0f7f72be71
|
账单明细联动:行数为0的取值不展示,联动结果缓存放宽到5分钟
|
2026-10-09 11:19:21 +08:00 |
|
|
|
cfdda94da8
|
账单明细:财务备注/财务类型筛选按平台限定,修同项目跨平台串行(优惠收入带出冲减收入)
|
2026-10-09 10:36:27 +08:00 |
|
|
|
a0faaa116b
|
Merge remote-tracking branch 'origin/main' into feature/yueyang-billing-details-filters
|
2026-10-09 10:33:35 +08:00 |
|
|
|
65112a2bff
|
店铺账号密码:状态映射缓存键升到 v4,强制刷新流程状态
换成 jiansun 实时 OA 流程表后,旧的 v3 缓存(30 分钟)里还留着 7 月之后
审批状态为空的结果,页面会继续显示横杠;升版缓存键让所有环境重新计算。
|
2026-10-09 10:32:00 +08:00 |
|
|
|
f56bd9d3ea
|
账单明细:新增财务备注筛选、筛选联动(行数为0的取值不展示)、行距放宽
|
2026-10-09 10:30:43 +08:00 |
|
|
|
473b6f4ebb
|
修复流程审批状态取不到:OA 流程表改用 jiansun 的实时副本
原来取的是中台库 dbo.flow_flow,那份数据停在 2026-07-16,7 月之后的申请
(比如 shp20260716165004772 京喜-清木居工厂店 关店流程)审批状态全是空的,
而工作平台显示「流程中」。
jiansun.dbo.flow_flow 是实时表(今天还在更新,10543 行),同名单据里
flowStatus=1、当前审批人=山时。已登记并完成首次全量 + 建 flowId 索引;
中台那份旧副本改为停止同步(数据保留)。
流程统计页与店铺账号密码的「流程类型 / 审批状态 / 流程状态」两处取值都跟着换成实时表。
|
2026-10-09 10:25:43 +08:00 |
|
|
|
b4821ca933
|
唯品会MP/JX账户:订单结算时间改为「账单期间」,筛选项也按账单期间过滤
1) 两列改名:AccountBillColumns 里唯品会两个页签的「订单结算时间」→「账单期间」(金额式账期月份,如 2026-07),列类型从 date 改 text 避免被当日期格式化;
2) 筛选标签:DATE_FILTER_LABELS 里 vipshop / vipshop-jx 从「结算时间」改成「账单期间」;
3) 筛选真正生效:这两个页签的 start/end 不再过滤 occurred_at,改为按 payload.settle_period(YYYY-MM)与所选区间取月份交集,页面列表与导出同步生效。
同步更新 AccountBillsTableTest 的断言。
|
2026-10-09 09:35:16 +08:00 |
|
|
|
03b728a0fc
|
Merge remote-tracking branch 'origin/main' into fix/yueyang-offset-signed-amount
# Conflicts:
# app/Console/Commands/SyncStoreReceiptOrderMatches.php
|
2026-10-08 16:24:38 +08:00 |
|
|
|
6255179bf5
|
导出任务取消:点击后立即置为「已取消」,后台下一个检查点停止并删除半成品文件
|
2026-10-08 15:34:01 +08:00 |
|
|
|
ad65f0cc75
|
导出任务:新增「取消」(后台检测取消标记后停止并删半成品文件)
|
2026-10-08 15:31:10 +08:00 |
|
|
|
4d5b9bf440
|
导出任务:按自增顺序取数提速、时间统一北京时间、运行中显示「取数中」
|
2026-10-08 15:22:06 +08:00 |
|
|
|
daf3fd64d8
|
店铺收款账户账单:导出进度改成科目映射表「操作记录」同款弹窗(撤掉独立页面)
|
2026-10-08 15:12:41 +08:00 |
|
|
|
d69a7d2ca7
|
店铺账号密码:把流程类型和审批状态两列都拉过来
上一版只带了「流程状态」(关店流程的审批状态)。改成按 ERP 店铺名取该店铺
最近一单申请流程(开店/变更/关店/主体注销自动),同时给出流程类型与审批状态,
列位置仍在「店铺状态」后面;两列都可搜索多选筛选、可排序。
线上:966 个账号店铺里 396 家最近一单是关店流程;状态文案与流程统计页一致。
状态映射缓存从 10 分钟放宽到 30 分钟(全量算一次要几秒,数据变化很慢)。
|
2026-10-08 15:12:41 +08:00 |
|
|
|
e01b575e74
|
店铺收款账户账单:导出改成独立「导出进度」页面(任务列表+下载),修正任务页签标签
|
2026-10-08 15:08:05 +08:00 |
|
|
|
c88c0f165e
|
店铺账号密码:新增「流程状态」列(取店铺关店流程)
按 ERP 店铺名关联 jiansun.dbo.fys_shopInfo_flow 的关店流程(flowType=10),
同一店铺取最近一单,状态用 OA 流程表的审批状态文案(流程中/完成/拒绝/撤回…)。
列加在「店铺状态」后面,同时做成可搜索多选筛选,并支持按流程状态排序。
线上:966 个账号店铺里 486 个有关店流程(流程中 352 / 完成 46 / 撤回 14 / 拒绝 2 /
其余审批状态暂缺),列值缓存 10 分钟。
|
2026-10-08 14:51:44 +08:00 |
|
|
|
30f69f2af9
|
店铺收款账户账单:导出改成后台任务 + 导出进度列表(状态/下载),不再依赖页面停留
|
2026-10-08 14:49:11 +08:00 |
|
|
|
885961084e
|
流程统计:接入店铺申请流程(开店/变更/关店)共享镜像
数据源:jiansun.dbo.fys_shopInfo_flow(申请单明细,4572 行,含店铺/平台/负责人/利润中心/商标/变更原因/关店原因等)
+ 中台库 dbo.flow_flow(按 flowId 关联审批状态与当前审批人),两个数据集已登记并完成首次全量。
- 新增 ShopInfoFlowMirrorRepository:左连接两套镜像,支持单据编号/申请人/申请日期/当前审批人/
ERP店铺名称/店铺运营负责人/利润中心/商标号等文本筛选,流程类型、审批状态、平台为可搜索多选。
- 审批状态文案取自 OA 前端字典:0暂存/1流程中/2拒绝/3完成/4撤回/5待签署/6已签署/7待审批;
流程类型:8店铺开店/9店铺变更/10店铺关店/12主体注销自动流程。
- 页面按目录表渲染(查询条件、筛选字段、导出),列与外部店铺申请页对齐。
- TableRegistry 登记为只读上游页,镜像未就绪时页面给提示而不是报错。
|
2026-10-08 14:38:16 +08:00 |
|
|
|
29defd2025
|
店铺收款账户账单导出:改成后台导出 + 页面进度条(带 token 轮询,页面可自由切换)
|
2026-10-08 14:31:32 +08:00 |
|
|
|
39f7797a35
|
店铺收款账户账单导出:大账期先发文件头并禁止代理缓冲(下载立刻开始),页面加导出中提示与大账期确认
|
2026-10-08 14:16:12 +08:00 |
|
|
|
69f3d9228f
|
店铺账号密码:授权状态 / 店铺状态筛选改成可搜索多选
复用已有的 CaiWuMultiSelect 组件(按钮 + 复选面板 + 全选/清空),勾选结果提交为
authorization_status[] / store_status[],多个取值取并集;一个都不勾=全部。
- 目录表的筛选控件在 query 表单外(靠 form 属性关联),给多选组件补了 formId 选项,
生成的隐藏 input 带上 form,保证能随查询表单提交。
- pageFilters 支持数组筛选值(去重、最多 50 个);仓库侧筛选统一按列表处理,
单选(旧链接)和多选都兼容。
|
2026-10-08 13:48:51 +08:00 |
|
|
|
401dfb089a
|
店铺账号密码:上游新增字段自动跟随(镜像补列 + 页面自动多出这一列)
新增 business-mirror:follow-upstream-columns:先把数据字典刷新到最新,再把上游
视图里新增、当前数据集还没同步的字段追加进镜像定义并立刻建列,下一次常规同步
就会带回数据。只做新增,不删除/不改写已有字段;字段名带 password/secret/token/
cipher/credential 等敏感关键字的一律跳过。已登记到发布 cron(每天 06:40)。
页面侧:config/upstream_mirrors.php 的 auto_follow_columns 用「页面 => 数据集」
登记,FollowedUpstreamColumns 服务把 followed_columns 变成表格列;这类列只展示、
不生成查询条件(后端还没有对应筛选口径)。
数据集自带的数据变动仍然由每分钟的 business-mirror:sync-tables 增量同步。
|
2026-10-08 13:19:53 +08:00 |
|
|
|
627fa966ef
|
店铺账号密码:新增授权状态、店铺状态两列(在账号分组名称后面)
两列都来自已有的共享镜像,按店铺名关联(下划线、空格统一成短横线):
- 授权状态:聚水潭店铺档案 jst_shopInfo 的授权到期时间;无到期时间为未授权,
已过期为已过期,其余为已授权。
- 店铺状态:店铺档案 fys_shopInfo.shopState,0 正常 / 3 关闭中 / 6 已关闭,
与店铺基础信息页口径一致。
两列同时做成下拉筛选(已授权/已过期/未授权、正常/关闭中/已关闭),并支持按业务
顺序排序;映射结果缓存 10 分钟,避免每次列表都全表读两张档案表。
线上命中率:账号表 966 个店铺,授权状态命中 963、店铺状态命中 948。
|
2026-10-08 11:39:34 +08:00 |
|
|
|
dcdea11f0f
|
fix(发货数据): 快递公司/仓库按实际出库单取,同步命令内存上限调至 4G
- 发货明细(jst_order_express_details)可能停在作废前的旧分配(如先分工厂代发仓、后改外采由总仓出库;或换单后仍是旧快递公司),
工作平台按实际出库单显示。快递公司与出库单不一致或为空时改用出库单 logistics_company,
仓库按出库单 wms_co_id 映射(从快递公司一致的明细行学习仓库名,扫描结束统一回填)。
- 9 月核对:快递名称不一致 434/331,612,仓库不一致 85,其中外采快递、线下快递、换单类为此原因。
- jushuitan:sync-shipping 内存上限 1536M -> 4096M:整月窗口重跑在扫描后段内存耗尽(退出码 255)。
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014nvGZkg27YMEdhry6eiuwf
|
2026-10-08 10:52:27 +08:00 |
|
|
|
471aa714e8
|
fix(发货数据): 以本地全量核对通过的版本替换 #282 的同步实现
#282 的整合版在本地全量同步中发现问题,改用已与工作平台逐单核对通过的实现(保留 #283/#284 及 main 其它改动):
- 订单元数据只缓存精简字段(状态仅存取消/拆分/合并,标签只存是否线上发货),全表扫描后释放;
#282 缓存完整标签会在全表扫描时内存超限导致同步中途退出
- 按规则排除的包裹(取消/拆分/合并/线上发货)清除本窗口旧记录
- 剩余 @ 前缀统一去掉(工作平台导出无 @)
- 自动发货仓虚拟/补差单:单号已被其它包裹实际输出时留空(对齐工作平台)
- 出库映射保留作废单但排在有效单之后;换单按出库单号顺序一对一配对
测试:同步单测相应调整(作废单排序、多候选配对)。
验证:本地清空 8.15-9.30 后全量同步 9.1-9.16,与工作平台对比两边共有包裹 195,555,带单号漏拉 1 单。
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014nvGZkg27YMEdhry6eiuwf
|
2026-10-07 16:33:23 +08:00 |
|
|
|
ae694004cf
|
总账备注匹配:账单项目自动去 wx 前缀再查一次
先原样匹配,不中则去掉开头 wx 前缀(wx基础软件服务费 → 基础软件服务费)再匹配;原样命中优先,不影响既有结果。
科目映射表优先级链路与回落原总账备注链路都按此顺序匹配。
|
2026-10-07 15:58:42 +08:00 |
|
|
|
0933941533
|
总账备注取科目映射表:平台/账单项目键做大小写与空格归一
科目映射表平台写「唯品会JX」、页签内部键「唯品会jx」,原样索引匹配不到;统一小写去空格后索引与查找。
|
2026-10-07 15:30:56 +08:00 |
|
|
|
1cbc8312a6
|
店铺收款账户账单:总账备注优先取「科目映射表」的财务备注
账单项目在「科目映射表」里能匹到(同平台+同项目)时,总账备注取该规则的「财务备注」;
多规则时按业务备注/商品名称关键词取最具体的一条;匹不到则保留原有总账备注映射。规则按平台+项目预索引,避免逐行扫全表。
|
2026-10-07 15:24:58 +08:00 |
|
chenxi
|
73617e4899
|
Merge remote-tracking branch 'origin/main'
|
2026-10-07 14:50:18 +08:00 |
|
chenxi
|
57c1ea7046
|
抖音账户关键词框与其它页签统一(去掉匹配方式下拉)
关键词改为单输入框;后端对 15~30 位纯数字按等值匹配(记录编码/订单号)快速返回,
其余仍为包含匹配,避免抖音账户全表扫描导致的长等待。
|
2026-10-07 14:50:07 +08:00 |
|
|
|
4b3baeaaf0
|
拼多多完整账单导入:账单项目为空时按「收支方向 + 业务描述」回填
源文件偶发账单项目为空的行;导入时在 activate 之前用同代已有口径回填(方向+描述取众数),
找不到口径的行保持原样。生产已用同一规则回填历史 10 行(技术服务费 4 / 交易收入 4 / 优惠券结算 1 / 提现 1),
拼多多页签总账备注为空从 10 行降到 0。
|
2026-10-07 14:36:34 +08:00 |
|
|
|
c4a976751d
|
修复订单售后页面一直转圈:店铺候选改成定时预热
上一次把店铺候选的完整计算放在 app()->terminating() 里,但服务器是 mod_php,
响应要等整个请求(含终止回调)结束才算完成,浏览器就一直转圈、侧边栏停在骨架屏。
线上实测:发布后第一个打开订单售后费用明细的人,页面会卡两分钟以上。
改成:页面只返回毫秒级的店铺目录兜底,完整候选(目录 ∪ 订单镜像店铺)由新增的
order-data:warm-shop-candidates 每小时预热一次,并在发布脚本的 cron 里注册。
|
2026-10-07 14:21:36 +08:00 |
|
|
|
a9da8d4447
|
修复发货镜像字段校准与合并列表耗时 (#283)
|
2026-10-07 14:08:20 +08:00 |
|
|
|
916fb30f37
|
修复批量筛选:纯数字单号当数组键会被 PHP 转成 int
batchValues() 原来拿值本身当数组键去重,纯数字订单号(如 3317080368285022883)会被
PHP 转成 int,后续 whereIn 就成了数字和长文本比较,走不上 so_id / outer_oi_id 的
前缀索引,实测退化成全表扫描(70 秒以上)。
改成键加 v 前缀、返回原字符串,ctype_digit 显式传字符串。新增用例覆盖前导零单号
0001234 与 1234,防止再回归。
|
2026-10-07 14:05:53 +08:00 |
|
|
|
e5922dd78e
|
订单售后费用明细 / 商品推广费用明细:订单号和商品编码支持批量查询
两个页签的「订单号」「商品编码」改成多行输入框,可以直接粘一整列:
每行一个,或用逗号、空格、分号、顿号分隔,一次最多 50 个值,多值取并集。
- 订单号批量:先去两套来源解析候选 o_id(单表、等值 IN,走各自前缀索引),
再按订单过滤;单个订单号仍保留「从头匹配」的模糊语义。
线上实测 20 个真实单号解析 0.01 秒。
- 商品编码批量:每个编码在 商品/款式/店铺编码(推广页为 item_id)里匹配一组,
多组 OR;仍受统计日期/订单日期范围约束。
- 非淘系旧查询路径同步支持批量,保持两套口径一致。
|
2026-10-07 13:55:02 +08:00 |
|
|
|
6c054c7081
|
整合发货补漏与导出口径修复,保留主线同步保护 (#282)
|
2026-10-07 13:52:18 +08:00 |
|
|
|
4b97b30a3a
|
商品推广费用明细:店铺筛选改成和订单售后费用明细一致的多选控件
- 把「店铺名称:可点选的多选 + 模糊搜索」抽成公共组件
partials/order-data-shop-picker.blade.php,订单售后费用明细改为引用它,
商品推广费用明细用同一个控件(原来是一个纯文本输入框)。
- 推广页提交 shop_name[](多个取并集),后端镜像查询和非淘系旧查询都改成
按多个店铺 OR 匹配,仍兼容原来的单个 shop_name。
- 推广表的店铺名带下划线(天猫_卓禾家具旗舰店),和订单镜像的「天猫-…」
不是同一套命名,所以候选单独取自 ops_item_sales_cost_ratio 当前统计日期
出现过的店铺,按日期缓存 24 小时(单次约 0.4 秒、约 400 个店铺)。
|
2026-10-07 13:39:25 +08:00 |
|
|
|
d76b102bca
|
总账备注平台口径:1688 / 新佰广 前缀按阿里巴巴匹配
新佰广1688、1688xxx 店铺名不带「阿里巴巴」前缀,之前落到页签默认平台(淘系支付宝=淘宝),
1688 系账单项目匹配不到总账备注;新增两条前缀映射(1688、新佰广 → 阿里巴巴)并补单测断言。
|
2026-10-07 13:20:06 +08:00 |
|
|
|
af83d75a00
|
订单售后费用明细:订单号查询改为先解析候选订单再过滤
订单号原来在「订单 ⋈ 明细」关联后做三列 %x% 匹配,没有日期条件时优化器会放弃
索引,淘系那套 520 万订单 × 680 万明细必须全表扫描,线上实测单条跑到 19 分钟
还没结束(还占满 Apache 工作进程)。
改成两段式:先用带前缀索引的单表查询把订单号解析成两套来源各自的候选 o_id
(线上订单号 / 子订单号从头匹配、内部订单号按数值等值),再让分支按 o_id 过滤。
两套来源分开解析,避免两侧 o_id 撞号。候选超过 500 条或订单号不足 4 个字符时
退回原来的包含匹配,保持既有行为。
顺带给 jst_OrderItem 补 outer_oi_id 前缀索引(非淘系子订单号原来要扫 70 秒),
已在生产建好索引。
|
2026-10-07 11:31:56 +08:00 |
|
|
|
96b8f503c6
|
账单明细:平台筛选改为按账户/数据来源分类(与店铺收款账户账单页签一致)
- 平台下拉改为淘系支付宝/淘系微信/拼多多/京东账单/京喜账单/京东网银钱包/抖音/得物
- 京东账单与京喜账单同表,按店铺前缀切分;财务备注/财务类型仍按店铺前缀匹配映射表
|
2026-10-07 11:12:24 +08:00 |
|
|
|
5b95b655bb
|
运费对账:全量汇总缓存 1 小时,避免每 15 分钟重跑两分钟的重查询
无筛选的全量汇总约 110~200 秒,按原来的 900 秒缓存会让常看这个页面的人
反复等两分钟;带筛选的汇总走索引很快,保持 15 分钟。
|
2026-10-07 11:01:29 +08:00 |
|
|
|
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 |
|
|
|
83e5108ce6
|
订单售后费用明细:重置后不再自动带日期
- 点“重置”或提交空日期时,不再回填近 7 天默认区间,日期框保持为空并做不限日期查询
- 首次进入页面仍保留近 7 天默认区间;导出文件名在无日期时显示“不限日期”
- 补充过滤归一化与页面渲染用例
|
2026-10-07 10:00:20 +08:00 |
|
|
|
eda10bd740
|
订单售后费用明细:店铺筛选改为可点选的多选模糊查询
- 店铺名称由单个输入框改为可点选的多选下拉:候选里可按关键字模糊筛选、多选、全选当前结果/清空
- 提交 shop_name[],多个店铺取并集逐个模糊匹配;保留旧的单值 shop_name 兼容
- 候选来自订单镜像中真实出现过的店铺,缓存 1 小时;单次最多 50 个店铺,超出在面板内提示
- 补充仓库层与页面层用例
|
2026-10-07 10:00:20 +08:00 |
|