|
|
1bb1c80816
|
fix(发货数据): 两种导出模式对齐工作平台取值逻辑
按工作平台 OmsDataDay 源码 + 9.1-9.16 逐单对比反推，合并/明细基础信息一致率均达 99.9% 以上。
取数范围
- 换单配对：快递明细旧单号在出库单查不到时，配同订单下未被占用的出库单新单号
- 作废重出：同单号/同订单多张出库单时优先有效单、再取最新 io_date
- 订单已取消/已拆分/已合并的快递明细不出行；订单标签含"线上发货"同样排除
- 合包/拼单：按 单号+订单号 定位出库单；同单号不同交易单号的出库单照常补出
- 发货明细无单号：出库单单号 -> 订单单号 -> 空，不再借运费表里其它包裹单号
- 自动发货仓虚拟/补差单：单号已被别的包裹输出则留空
- @ 去重只在同一交易单号、本次同步时间段内比对，剩余 @ 前缀统一去掉
字段取值
- 发货时间取出库单 io_date；平台取视图 shop_site（无则映射）；省市区取视图
- 合并商品名称/供应商取包裹内最后一个商品（原为 MIN）；名称 & 转 ^
- 明细体积：数量×长×宽×高，代发仓非标准承运商不乘数量，指定快递为 0（config detail_volume）
- 组合件合并值单独存 m_* 列（新迁移），合并导出优先使用
- 仓库 {未指定发货仓} 导出为空；明细 0 尺寸/体积导出为空
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014nvGZkg27YMEdhry6eiuwf
|
2026-10-07 13:45:27 +08:00 |
|
|
|
842cb642e6
|
fix(发货数据): 修正线上发货误排 + 出库单兜底，补齐漏拉
对照工作平台 9.1-9.16 导出逐单比对，漏拉(带快递单号) 2384 -> 95，多拉 45 -> 46。
- excludedByLabel：原先凡含"线上发货"一律排除，把京东云仓/京仓(CLPS/ECLP)
真实发货也误排了。改为只排除"线上发货且非云仓/京仓"(刷单/批发/纯售后)。
实测 2112 个线上发货出库单：误排 2、误收 0。
- 新增 syncOutbound 兜底 pass：按出库单 io_date 窗口(按主键 Id 分段)扫描，
把 express/autoship 都未处理的包裹按发货数据视图补吐(工厂代发仓/自有仓
出库单无订单行，或同订单其它包裹在发货明细而本包裹不在)。
防重复按 io_id + 快递单号(去@)，express/autoship 处理过的(含按标签排除的)
都登记跳过；同样套用标签规则，跳过取消/删除、无单号、无商品。
- 出库单表头缺失交易单号/省市区/店铺/快递名称时，从发货数据视图兜底。
新补 652 单：交易单号/省 99.4%，条码/仓库 99.8%，平台/供应商/体积 100%。
已知未收：314 个"简尚-自动发货仓"信誉订单虚拟条码(X00006)，只存在于视图，
无快递单号/运费/金额，源数据无发货时间。
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014nvGZkg27YMEdhRy6EiUwf
|
2026-10-07 13:41:14 +08:00 |
|
chenxi
|
2a30d9bac3
|
Merge remote-tracking branch 'origin/main'
|
2026-10-07 13:20:37 +08:00 |
|
chenxi
|
35ee115522
|
淘系支付宝账户筛选栏样式对齐淘系微信账户
改用与 AccountBills 相同的筛选栅格与容器查询（≤1200px 两列、≤600px 单列，
发生时间整行），替换原来 7 列一行排开的布局。
|
2026-10-07 13:20:30 +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 |
|
|
|
e8b8b816f4
|
修复「是否种菜订单」映射读取为空：补 deleted_at 列并改用表查询
新建的 jst_order_label_planting_rules 缺 deleted_at，而模型基类带 SoftDeletes，查询报错被兜底成空映射，
页面全部显示「否」。补迁移 2026_10_07_130000（建表迁移同步补上）并把服务改为 DB 表查询。
|
2026-10-07 11:20:03 +08:00 |
|
|
|
96b8f503c6
|
账单明细：平台筛选改为按账户/数据来源分类（与店铺收款账户账单页签一致）
- 平台下拉改为淘系支付宝/淘系微信/拼多多/京东账单/京喜账单/京东网银钱包/抖音/得物
- 京东账单与京喜账单同表，按店铺前缀切分；财务备注/财务类型仍按店铺前缀匹配映射表
|
2026-10-07 11:12:24 +08:00 |
|
|
|
d877735507
|
聚水潭订单标签明细：新增「是否种菜订单」列
下单时间后面新增「是否种菜订单」列，逐行按（公司 + 标签）匹配财务维护的映射表：命中为是、未命中为否。
- 新表 jst_order_label_planting_rules + 模型 + 缓存服务，导入命令 jst-order-labels:import-planting-rules（读「判断种菜单.xlsx」）
- 导出 CSV 同步新增该列，页面/导出同口径
- 本地构建通过；改动/新增 PHP 文件 php -l 通过
|
2026-10-07 11:14:04 +08:00 |
|
|
|
5b95b655bb
|
运费对账：全量汇总缓存 1 小时，避免每 15 分钟重跑两分钟的重查询
无筛选的全量汇总约 110~200 秒，按原来的 900 秒缓存会让常看这个页面的人
反复等两分钟；带筛选的汇总走索引很快，保持 15 分钟。
|
2026-10-07 11:01:29 +08:00 |
|
chenxi
|
1a024c2b26
|
Merge remote-tracking branch 'origin/main'
|
2026-10-07 10:55:58 +08:00 |
|
chenxi
|
d7582cdb46
|
修复业绩明细导出：补平台筛选 + 改游标流式输出
导出补齐平台筛选，并把 chunk(1000) 的 OFFSET 轮询改为 cursor() 单查询流式输出。
|
2026-10-07 10:55:52 +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 |
|
|
|
40832546da
|
聚水潭订单标签明细：店铺/标签筛选改为可搜索多选
店铺名称、标签由原生单选 select 改为项目已有的「可搜索多选」组件（可打字搜索、全选/清空、勾选一条或多条），
结果按 shop_name[]/label[] GET 提交；控制器支持数组并与旧单值参数兼容，店铺 whereIn 精确匹配、多个标签 OR 包含匹配，
页面/分页/导出同口径。生产数据实测：多选店铺 951=951、多选标签 39575=39575、旧单值 92=92 均与独立 SQL 一致。
|
2026-10-07 10:54:07 +08:00 |
|
chenxi
|
2341a839f3
|
Merge remote-tracking branch 'origin/main'
|
2026-10-07 10:41:06 +08:00 |
|
chenxi
|
0bb4df6512
|
业绩明细扩展到店铺收款账户账单全部平台页签
按页签配置来源表与列映射（得物用 bill_date、京东系列/抖音用 order_no+income、
京东与京喜按店铺名拆分、京东/抖音只取活动代）；单号查询同时带原始号与核心号
以匹配拼多多的日期前缀单号；镜像表增加平台维度与平台列/筛选。
|
2026-10-07 10:41:00 +08:00 |
|
|
|
4258bd4e0e
|
侧边栏权限：新增一级菜单「种菜数据汇总」不再被旧权限集合隐藏
种菜明细表 / 聚水潭订单标签明细 原本挂在「账单流水数据」下，移入新一级菜单「种菜数据汇总」后，
按页面键保存过精确权限的访问组（总账组/结算组/税务组）里没有新 section，导致菜单不显示、直达链接 403。
按既有 company-management 兼容做法：能看「账单流水数据」即可见「种菜数据汇总」。
生产数据实测（临时容器、同镜像、只读）：修复前 12 个访问组账号全部看不到，修复后 21 个账号全部可见。
|
2026-10-07 10:27:20 +08:00 |
|
|
|
fb15402003
|
feat: 店铺维度报表无业绩月份列默认隐藏 (#281)
|
2026-10-07 10:01:13 +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 |
|
|
|
cd641ddfbd
|
每日账单脚本：远端失败重试 + 不再把失败当成功
- 新增 erp-remote.ps1：上传与远程执行统一重试（默认 3 次，重试前重新上传 CSV）
- run-erp-daily.ps1：导出失败重试一次；导出/转CSV/笔数核对/上传/导入回验失败都不写状态、不归档，退出码 1，下次自动重导
- 实测：真实 SSH 断连两次后第 3 次重试成功（8002 笔 / 283870.49 / 46435.6）；连续失败的一次按新逻辑记失败并 exit 1
|
2026-10-07 10:02:00 +08:00 |
|
chenxi
|
b9c2b73655
|
修复业绩明细月份选择器禁用 7 月的问题
data-min-month 由写死的 2026-08 改为镜像中实际最早账期（YYYY-MM），
避免把已同步的 7 月禁用导致无法查询。
|
2026-10-07 09:51:26 +08:00 |
|
chenxi
|
278f641018
|
业绩明细账单侧筛选改为「总账备注」口径
账单侧改为按总账备注命中「订单/收入/交易收入/订单收入/商家结算款/跨境订单结算款/消费订单」，
复用 AccountLedgerRemarkMap + LedgerRemarkFilter，与店铺收款账户账单页同一口径，
淘系页签按店铺名前缀分淘宝/天猫/阿里巴巴取各自账单项目；统计条新增「收入为 0 的账单行」。
|
2026-10-07 09:39:06 +08:00 |
|
|
|
ac21fc4079
|
淘系支付宝账户账单：筛选项整理为一行
原 4 列网格会折成两行；改为单行 7 列（原始店铺/总账备注/账单项目/数据源渠道/收支类型/发生时间/关键词），与其它账户页签一致；窄屏 ≤1400px 回落 4 列、≤1100px 两列、≤600px 单列。
|
2026-10-07 09:19:00 +08:00 |
|
|
|
5ef4119a3d
|
feat: 主体维度经营报表无数据月份列默认隐藏 (#280)
|
2026-10-06 23:51:16 +08:00 |
|
|
|
5d7bc3f2c4
|
feat: 税金预测表页面标注逻辑配置入口
|
2026-10-06 23:18:53 +08:00 |
|
|
|
bfc119608f
|
feat: 新增税金预测表逻辑配置页面
|
2026-10-06 23:18:53 +08:00 |
|
|
|
35fe10bc69
|
feat: 新增税金预测表页面与取数口径说明
|
2026-10-06 23:17:16 +08:00 |
|
|
|
8419d4097c
|
feat: 内部流转报表导入工作簿数据并支持查询导出
- 新增共享镜像表 business_internal_flow_records 与整份替换导入命令 internal-flow:import
- 按 Excel 表头展示抬头、标签、预计9月销量、开票、所需进项成本、收票、剩余缺口与开票比例
- 复用公司基础信息的字段查询、表头排序、筛选字段与导出 Excel 交互
- 新增导入与页面测试，覆盖合计行跳过、重导入替换、筛选排序与未导入空状态
|
2026-10-06 22:08:08 +08:00 |
|
|
|
5f1fc25578
|
修复：未带「总账备注」筛选时 filteredQuery 读取未定义键
选择总账备注才生成 bill_items；未选择时该键不存在，直接读取会触发 Undefined array key，使唯品会MP/唯品会JX 页签的常规请求报错。改为 ?? [] 读取。
|
2026-10-06 20:03:58 +08:00 |
|
|
|
e777e75176
|
店铺违规信息预警：统一表头映射，支持查询、导入导出与每日同步
|
2026-10-06 19:02:22 +08:00 |
|
|
|
13a9697447
|
店铺收款账户账单新增「总账备注」筛选；每日账单脚本支持胜算异步分片导出
- 所有账户页签在「店铺」右侧新增「总账备注」下拉：按（平台+账单项目）翻译成账单项目集合过滤，页面/列设置/导出同口径；淘系支付宝、淘系微信同页签混多平台时按店铺名前缀细分
- 每日账单脚本：胜算超出同步导出上限（url=null+taskId）时自动从「异步导出下载管理」取回本次任务全部分片并合并成一份 CSV，导入前按页面笔数核对（不一致则跳过导入）
- 实测：京东 7 月异步导出两片 219158+235846=455004 笔 / 收入 17695094.84 / 支出 8035128.21，与已导入口径一致
|
2026-10-06 18:46:57 +08:00 |
|
|
|
78857a51d9
|
feat: 店铺维度报表按主体期间拆分并支持期初数据维护
- 改为按期初数据+系统主体+爬虫新主体生成主体期间，一行一期间，修复流程历史重复行
- 变更日当天归新主体、老主体失效显示变更日前一天；关店和其他非正常状态两列显示 -
- 期初数据首次打开固化为系统库设置，可在「规则信息 → 店铺维度报表逻辑配置」在线增删改
- 爬虫店铺主体按税号归一，首次抓到的新主体写入期间变更表并自动生成新期间
- 新增期间变更表迁移与 crawl_shop_company 镜像数据集
|
2026-10-06 18:42:12 +08:00 |
|
|
|
f774e75fce
|
每日账单脚本：胜算该区间无数据时按跳过处理（不算失败）
|
2026-10-06 17:46:31 +08:00 |
|
|
|
73af15f2db
|
加固每日账单导出：设置日期前先关授权弹窗并逐次校验日历面板
|
2026-10-06 17:42:10 +08:00 |
|
|
|
80978061de
|
新增统一脚本：聚胜算每日账单（头条放心购 / 京东日账单）导出并导入（scripts/erp-daily-bills）
|
2026-10-06 17:33:19 +08:00 |
|
|
|
2c1ac0bb3b
|
总账备注映射导入支持 --sheet 选择工作表（补齐京东网银钱包/淘系微信两处空列数据）
|
2026-10-06 17:26:41 +08:00 |
|
|
|
d6b0b7f1d7
|
feat: 接入退货取件管理镜像、实际运费核算与 XLSX 导出
|
2026-10-06 16:05:59 +08:00 |
|
|
|
4523682d1e
|
feat: 逆向物流报价页接入计费规则与费率表
|
2026-10-06 16:01:35 +08:00 |
|
|
|
c04054ca0b
|
修复「总账备注」在共享镜像页签不生效（mirrorIndex 漏补装饰）
|
2026-10-06 15:54:52 +08:00 |
|
chenxi
|
7d2980d5e3
|
Merge remote-tracking branch 'origin/main'
|
2026-10-06 15:41:58 +08:00 |
|
|
|
44a2664372
|
发布脚本：头条放心购原始账单镜像每天 09:30 定点刷新（店铺收款账户账单·抖音账户数据到齐）
|
2026-10-06 15:42:58 +08:00 |
|
|
|
e147c90a2c
|
店铺收款账户账单新增「总账备注」列（按平台+账单项目映射表取值）
- 新增 ec_account_ledger_remarks 映射表与 account-ledger-remarks:import 导入命令（平台/账单项目/总账备注）
- 新增 AccountLedgerRemarkMap：按店铺名前缀识别平台，无前缀时用页签默认平台；缺失匹配保持空白
- 全部账户页签（含淘系支付宝自有列定义）在「店铺/店铺名称」右侧新增「总账备注」列，页面/列设置/导出共用同一份列定义
- 控制器在分页与导出流读取时补齐 payload.ledger_remark，不改动上游账单与共享镜像数据
- 用例：新增 AccountLedgerRemarkMapTest；修正唯品会 JX/MP 列清单断言
|
2026-10-06 15:42:57 +08:00 |
|
chenxi
|
98cea16655
|
Merge remote-tracking branch 'origin/main'
# Conflicts:
# config/business_navigation.php
|
2026-10-06 15:41:47 +08:00 |
|
|
|
6af12c030e
|
财务经营报表：新增账单明细页（多选筛选/日历选择/四项汇总/按列导出与进度/收款明细同款分页），科目映射表字段改名财务备注与财务类型
- 账单明细：7 个平台账单分支下推查询，按 active_generation 取当前版本（修正抖音重复计数），跨月大数据量由 73s 降到 1-2s
- 筛选：平台/店铺/账单项目/财务类型多选下拉（打字模糊搜索+滚动），日期改日历选择
- 导出：全部筛选结果 CSV 流式下载并按显示列最小取数，带进度轮询；列设置按账号存本机
- 分页：每页 10/20/50，首页/上下页/末页，第 X-Y 条/共 N 条
- 科目映射表：字段改名财务备注/财务类型（导入兼容旧名）
|
2026-10-06 15:35:16 +08:00 |
|
chenxi
|
e0f89288d2
|
业绩明细取数口径改为「一个店铺 + 一个订单号 + 一个商品金额」
- 账单侧：账单项目扩到 11 类（交易收款、1688 增值服务系列、交易分账_货款、其它交易收款、
先采后付账单付款、百补超级版消费者实付款、店铺过户），按「店铺 + 订单号」聚合收入与收款笔数
- 订单侧：销售全量按「店铺 + 线上订单号」先聚合求和（goods_count>0 有效行），
一单多品/多子订单在聚合阶段合并，商品金额只挂一次
- 匹配：单号清洗（去日期前缀/空格/横杠）后按核心号 + 店铺匹配；店铺以账单「线上真实店铺」
优先，下划线归一为横杠；订单侧单号一致但店铺不同或同号多店铺时标注异常
- 输出列：发生时间 → 店铺名称 → 线上单号 → 收入金额 → 商品金额 → 差额（收入−商品金额）
→ 匹配状态 → 异常标注；镜像表改为该行口径
- 统计：账单收款笔数、账单订单数、已匹配、未匹配、一单多笔、账单收入合计、
订单商品金额合计、差额合计（已匹配）
- 未匹配分类：空单号 / 格式不一致 / 订单无商品金额 / 订单表无此单，并可按异常标注筛选
8 月淘系支付宝：118,500 笔收款 → 111,427 行，已匹配 101,005、未匹配 10,422
（订单无商品金额 8,352 / 订单表无此单 2,046 / 空单号 24），一单多笔 6,758。
|
2026-10-06 14:43:49 +08:00 |
|
chenxi
|
08aaed9241
|
业绩明细新增「店铺收款匹配订单明细」页面及同步命令
- 以店铺收款账户账单（账单项目=交易收款）为基数，按线上单号关联经营分析副本库
的发货明细与销售全量，补出发货仓库、商品编码、商品数量、商品金额
- 匹配键：账单 online_order_no = 发货明细 so_id = 销售全量 sourceno（淘宝/天猫主订单号）；
同一订单多笔收款按订单号汇总，商品金额取 goods_count>0 的有效行
- 新增镜像表 store_receipt_order_match_rows 与命令
store-receipt:order-match:sync <YYYY-MM>（分批查询上游，订单号每批 1000 条）
- 页面：月份/店铺名称/线上单号/匹配状态筛选、匹配统计条、分页、CSV 导出
- 修正宽精度迁移在 sqlite 测试库上执行 MySQL 改写语句导致测试全线失败的问题
|
2026-10-06 13:42:30 +08:00 |
|
chenxi
|
ffd851fc0c
|
四项全0时加权取两位舍入后的更改价格，修复 72.00495→72.01 偏差
|
2026-10-05 12:07:12 +08:00 |
|
chenxi
|
1ab9a45d1d
|
金额/单价列精度提升到 8 位小数（展示仍两位），修复原始价格精度丢失导致的 1 分钱差异
|
2026-10-05 11:11:58 +08:00 |
|
