chengma
|
d64579e9b3
|
feat: 增加顺运宝批量 AI 规格匹配 (#202)
|
2026-08-14 10:30:08 +08:00 |
|
chengma
|
aac289a4d3
|
feat: 实现 AI 规格候选匹配与审计 (#201)
|
2026-08-14 10:08:32 +08:00 |
|
chengma
|
8f2b3f725d
|
feat: 支持顺运宝多订单号搜索 (#217)
|
2026-08-13 14:58:19 +08:00 |
|
chengma
|
313e9f9151
|
feat: 收敛店铺管理和蝦皮分类搜索 (#212 #213)
|
2026-08-13 11:47:56 +08:00 |
|
chengma
|
8f707722ba
|
feat: 建立全局店铺跨渠道管理 (#208 #209 #210 #211)
|
2026-08-13 11:15:54 +08:00 |
|
chengma
|
ad1ccc2c60
|
feat: 完善 SYB 蝦皮主数据与软删除 (#203 #204 #205)
|
2026-08-13 10:39:21 +08:00 |
|
chengma
|
761058efc1
|
feat: 删除已停用的同步店铺 (#197)
|
2026-08-13 08:48:02 +08:00 |
|
chengma
|
8a8fff8480
|
feat: 按允许店铺筛选顺运宝同步 (#196)
|
2026-08-12 18:48:31 +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
|
9d4d6fc1e5
|
feat: 增加顺运宝店铺筛选 (#151)
|
2026-08-11 14:39:13 +08:00 |
|
chengma
|
c05c4fafdb
|
feat: 展示顺运宝观测规格 (#140)
|
2026-08-11 10:46:11 +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
|
4433e3af37
|
feat: 完成规格映射与采购任务创建 (#69)
|
2026-08-09 22:55:14 +08:00 |
|
chengma
|
c6ef54dce1
|
feat: 建立顺运宝采购处理状态 (#67)
|
2026-08-09 22:32:19 +08:00 |
|
chengma
|
05a54b044d
|
feat: 统一顺运宝日期同步并记录历史 (#59)
|
2026-08-09 18:22:58 +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 |
|