chengma
|
07ca1b0afb
|
feat: 支持蝦皮批量创建 PDD 采集任务 (#185)
|
2026-08-12 16:12:35 +08:00 |
|
chengma
|
4c5f0610fd
|
feat: 明确顺运宝复用 PDD 关联 (#183)
|
2026-08-12 15:13:08 +08:00 |
|
chengma
|
889f568554
|
feat: 增加蝦皮店铺名称搜索 (#182)
|
2026-08-12 15:09:35 +08:00 |
|
chengma
|
253be7cb61
|
fix: 采购价格上限按数量计算总价 (#181)
|
2026-08-12 14:43:18 +08:00 |
|
chengma
|
f693d2a6fc
|
fix: 统一顺运宝单条采集客户端选择 (#174)
|
2026-08-12 09:56:15 +08:00 |
|
chengma
|
9ad067503e
|
feat: 任务改用采集采购独立序号 (#172)
|
2026-08-12 09:21:21 +08:00 |
|
chengma
|
5528b4b874
|
fix: 修复顺运宝采购完成状态与重复采购 (#169)
|
2026-08-11 18:05:27 +08:00 |
|
chengma
|
9e328984e9
|
fix: 修复顺运宝采集任务孤儿状态 (#165)
|
2026-08-11 17:00:33 +08:00 |
|
chengma
|
df1287f8eb
|
feat: 展示任务PDD店铺和客户端名称 (#158)
|
2026-08-11 15:49:01 +08:00 |
|
chengma
|
b527204204
|
feat: 支持顺运宝批量创建采集任务 (#153)
|
2026-08-11 14:59:26 +08:00 |
|
chengma
|
9d4d6fc1e5
|
feat: 增加顺运宝店铺筛选 (#151)
|
2026-08-11 14:39:13 +08:00 |
|
chengma
|
c39f5a7912
|
feat: 增加蝦皮店铺图片筛选 (#150)
|
2026-08-11 12:04:38 +08:00 |
|
chengma
|
38d6a0a04b
|
feat: 展示蝦皮主图和店铺 (#142)
|
2026-08-11 11:18:51 +08:00 |
|
chengma
|
4259be0e55
|
feat: 支持无SKU目录导入策略 (#141)
|
2026-08-11 11:03:18 +08:00 |
|
chengma
|
c05c4fafdb
|
feat: 展示顺运宝观测规格 (#140)
|
2026-08-11 10:46:11 +08:00 |
|
chengma
|
0588ef18c8
|
refactor: 切换蝦皮数据到目录接口 (#135)
|
2026-08-11 10:16:48 +08:00 |
|
chengma
|
3ac4467f6c
|
feat: 增加商品目录导入记录 (#134)
|
2026-08-11 10:11:15 +08:00 |
|
chengma
|
273bcc14a6
|
feat: 实现商品目录批量导入接口 (#133)
|
2026-08-11 10:06:10 +08:00 |
|
chengma
|
a9f22b9b0e
|
feat: 按创建人隔离采集采购任务 (#127)
|
2026-08-10 23:10:28 +08:00 |
|
chengma
|
a7bc9a940a
|
feat: 采购详情展示 PDD 核单结果 (#125)
|
2026-08-10 19:59:47 +08:00 |
|
chengma
|
546d9ef7e2
|
fix: 允许已采集 PDD 商品重新采集 (#121)
|
2026-08-10 19:38:40 +08:00 |
|
chengma
|
10bb892e6c
|
feat: 移除 Client 真实采购手工授权 (#114)
|
2026-08-10 18:37:35 +08:00 |
|
chengma
|
a26219091a
|
fix: 简化真实采购创建并恢复客户端选择 (#112)
|
2026-08-10 18:15:28 +08:00 |
|
chengma
|
66565d50cc
|
feat: 采购价格仅展示选定规格 (#113)
|
2026-08-10 17:56:03 +08:00 |
|
chengma
|
e1b32ea024
|
feat: 固定创建真实采购任务 (#112)
|
2026-08-10 17:52:48 +08:00 |
|
chengma
|
7106f6b024
|
feat: 顺运宝下一步支持单条建采购任务 (#106)
|
2026-08-10 16:34:55 +08:00 |
|
chengma
|
188725ff64
|
feat: 支持批量导入 PDD 商品链接 (#104)
|
2026-08-10 16:14:24 +08:00 |
|
chengma
|
3aaa40cfe0
|
feat: 增加真实采购任务安全模式 (#98)
|
2026-08-10 15:11:38 +08:00 |
|
chengma
|
775e38894e
|
feat: 顺运宝支持输入 PDD 商品 ID (#95)
|
2026-08-10 14:26:03 +08:00 |
|
chengma
|
5a77bde534
|
feat: 增加规格匹配建议与决策审计 (#90)
|
2026-08-10 12:41:17 +08:00 |
|
chengma
|
d1165b9e17
|
feat: 重构顺运宝规格主链路 (#88)
|
2026-08-10 12:24:23 +08:00 |
|
chengma
|
13cfced80d
|
feat: 迁移 Admin Repository 到 MySQL 8 (#79)
|
2026-08-10 02:21:31 +08:00 |
|
chengma
|
d99c81310d
|
feat: PDD 批量采集支持可选客户端 (#74)
|
2026-08-10 00:49:51 +08:00 |
|
chengma
|
4433e3af37
|
feat: 完成规格映射与采购任务创建 (#69)
|
2026-08-09 22:55:14 +08:00 |
|
chengma
|
518e6df349
|
feat: 统一蝦皮与顺运宝 PDD 关联入口 (#68)
|
2026-08-09 22:40:58 +08:00 |
|
chengma
|
57a6484fd5
|
docs: 澄清顺运宝规格状态语义 (#67)
|
2026-08-09 22:34:22 +08:00 |
|
chengma
|
c6ef54dce1
|
feat: 建立顺运宝采购处理状态 (#67)
|
2026-08-09 22:32:19 +08:00 |
|
chengma
|
155dd3b4a2
|
feat: 统一 Admin 主列表分页 (#64)
|
2026-08-09 21:51:20 +08:00 |
|
chengma
|
919522ff79
|
fix: 修复顺运宝分页总数误判 (#60)
|
2026-08-09 19:01:04 +08:00 |
|
chengma
|
05a54b044d
|
feat: 统一顺运宝日期同步并记录历史 (#59)
|
2026-08-09 18:22:58 +08:00 |
|
chengma
|
4b5cd13807
|
fix: 增强顺运宝同步完整性保护 (#58)
|
2026-08-09 17:17:42 +08:00 |
|
chengma
|
008bb87620
|
feat: 支持管理员自助修改密码 (#57)
|
2026-08-09 16:49:28 +08:00 |
|
chengma
|
2cce9e3888
|
fix: 用户密码最小长度调整为六位 (#55)
|
2026-08-09 16:14:58 +08:00 |
|
chengma
|
e0c0dac7a0
|
feat: 增加客户端采购员归属管理 (#54)
|
2026-08-09 16:02:25 +08:00 |
|
chengma
|
eea0d65ef8
|
feat: 实现 Admin 采购员账号管理 (#51)
|
2026-08-09 13:50:55 +08:00 |
|
chengma
|
0a7db404a1
|
feat: 实现 Admin 首次初始化与网页登录 (#50)
|
2026-08-09 13:36:41 +08:00 |
|
chengma
|
a18d4e67ae
|
feat: 顺运宝支持指定日期同步 (#53)
|
2026-08-09 13:24:02 +08:00 |
|
 chengmaandClaude Opus 5
|
5e426cacf6
|
feat: 顺运宝货运单同步 (#46)
顺运宝模块此前是骨架,「同步」点了提示"待接入"。5195 个蝦皮商品已经
进系统,但货运单(真实订单)一条都没有,后面的规格匹配无从谈起。
按接口契约(docs/admin/08,从 4 份 HAR 还原)实现:配置、登录(界面
手工输验证码)、会话缓存到 SQLite、按日期范围增量同步、落 syb_orders。
shopee_sku_id 绝不被同步覆盖。它是规格匹配的结果,顺运宝那边根本没有
这个值(只给 11 位商品ID,蝦皮規格ID 是 12 位)。同步写进去就是写空,
把人工攒的匹配成果洗掉且不报错。它只出现在 INSERT 列清单里,不在
DO UPDATE SET 里;repository 层和 service 端到端各有一个测试守着。
增量从「上次同步日期当天」重拉,不是第二天。created 筛选粒度是日期而
last_synced_at 精确到秒,从第二天拉会漏掉当天晚些时候创建的单且不报错。
宁可重复拉(upsert 幂等)也不能漏。中途失败不更新 last_synced_at,
否则下次跳过这段区间,漏的单永远补不回来。
日期运算用 UTC+8,不是 UTC。审查时从 HAR 确认 created 是当地时间:
抓包于 2026-07-28T03:31:45Z(= 11:31 UTC+8),同一响应里 created 是
"2026-07-28 10:37:59";若它是 UTC 则等于 18:37 UTC+8,比抓包晚 7 小时,
订单创建于未来,不成立。用 UTC 算会在本地 00:00-08:00 把"今天"算成昨天,
当天早晨的单这轮拉不到。用 time.FixedZone 写死,不用 LoadLocation——
那要读系统 tzdata,Windows 默认没有,打包成 exe 会失败。
金额一律取 detail/listByStock 的值:08 §5.1 实测同一响应里 amtOrder
在列表接口是分、escrowAmount 却不是,单位不统一,取错差 100 倍。
迁移 v5 纯追加(syb_session、syb_sync_state、syb_orders.product_spec),
v1-v4 逐字未动,CheckSchema 覆盖新表新列。
会话有效性判断把「网络故障」和「明确未登录」的分类集中在 Client.do()
一处——网络抖一下就判定登出的话,验证码会弹个不停,还会丢掉有效会话。
测试全部用 httptest 假服务端,不打真实站点。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-09 11:49:13 +08:00 |
|
 chengmaandClaude Opus 5
|
edfe39cc35
|
feat: 蝦皮数据页分页与状态筛选 (#43)
导入真实样本后 /shopee 一次吐 3.4MB / 5195 行。但只加分页会把问题从
「5195 行糊在一起」变成「260 页里藏着 6 个」——那 6 个待补规格的商品
仍然找不到。所以分页和状态筛选一起做。
HTML 3.4MB → 16.7KB。
状态条显示全量而不是本页:「共 5195 个商品 · 第 1/260 页」。
显示「共 20 个商品」会让操作员以为总共就 20 个。筛选后显示筛选结果
总数:「待补规格:6 个商品」。
列表查询和 COUNT 共用同一套筛选条件拼装。分开写两份 WHERE,迟早
有天忘了给 COUNT 也加条件,页码算错而且没人发现(#19 踩过一次)。
page 越界兜到最后一页而不是显示空表格——空表格会让操作员以为数据没了。
总数为 0 时显示「第 1/1 页」,不出现「第 1/0 页」。
「待补规格」用 EXISTS 不用 JOIN+DISTINCT:一个商品有多个失败 SKU 时
JOIN 会出重复行,DISTINCT 又让 LIMIT/OFFSET 的行为难推理。
分页控件是 <a href> 纯 GET,浏览器前进后退和书签都正常。首末页用
<span class="disabled"> 禁用,语义上不再是链接,不只靠颜色区分。
这是全项目第一个分页页面,通用逻辑单独放 service/pagination.go 供
后面四页复用,规则写进 05 §3.2 而不是蝦皮页那一节(#34 踩过这个错)。
05 §3 的每页条数从「建议 50」改为「统一 20」并写明理由。
实现踩到 html/template 的 URL 上下文转义:夹在字面量 & 中间的动态内容
会被整体当成一个参数值转义,?/= 变成 %3F/%3D 让链接失效。改为在 Go 里
把整段 URL 拼好,模板作为单个 pipeline 输出,并加了回归测试。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-08 11:40:07 +08:00 |
|
 chengmaandClaude Opus 5
|
64d5e74d0d
|
feat: 蝦皮数据页改为商品级列表与规格弹窗 (#41)
原来是 SKU 级一行,问题不在行数(6092→5195 只少 15%),在语义错了:
pdd_goods_url / pdd_goods_id 在 shopee_products 上,是商品级字段。
商品 24420648774 有 62 个 SKU,列表里 62 行显示同一个 PDD 链接,
将来双击任意一行编辑的也是同一个字段,操作员会以为改的是这一行。
加了两列,都是防止聚合后丢信息:
「SKU 数」—— 只显示颜色数和尺码数会严重误导。实测 602 个商品(11.6%)
的颜色数×尺码数大于实际 SKU 数,最悬殊的 26886533818 是 15×5=75 但
实际只有 28 个。蝦皮报表只含有销售成绩的 SKU,数据本来就不全。
「待补」—— 原来解析失败的行整行标黄,聚合成数量后这个信号会丢。
23 条失败分布在 6 个商品里,其中 4 个是「部分失败」:数字看着正常,
坏数据被吃掉,永远没人去补。现在待补>0 整行标黄。
颜色数/尺码数只统计 parse_ok=1,否则空值会被算进 DISTINCT 多出
一个「空颜色」。
弹窗只读,待补的行显示 spec_raw 原文——不显示的话人工不知道该填什么,
保留原文这个设计就白做了。复用 #18 的弹窗机制,app.js 未改动。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-08 11:12:25 +08:00 |
|