137 lines
6.2 KiB
Markdown
137 lines
6.2 KiB
Markdown
# 洁达选品：改造商城查价工程（概要）
|
||
|
||
| 文档属性 | 内容 |
|
||
| --- | --- |
|
||
| 版本 | V1.0 |
|
||
| 日期 | 2026-09-14 |
|
||
| 状态 | 本期实施依据；Windows 机按本文和详细方案改同事原工程 |
|
||
| 基线工程 | 同事「1号药城与药帮忙货品价格库存下载」`isa-rpa` Python 应用（`main.py`） |
|
||
| 详细方案 | [2026-09-14-jieda-procure-crawler-detail.md](./2026-09-14-jieda-procure-crawler-detail.md) |
|
||
| 业务口径 | [洁达四流程概要 V3.1](./2026-09-13-jieda-rpa-overview-design.md) 的 **BR-02 / BR-03 / 第 3.2 节** |
|
||
| 选品条件原文 | [采购平台选品条件优先项 20260902](/Users/yuuuu/Documents/AutoRpa/资料/采购平台选品条件优先项_20260902.txt) |
|
||
|
||
本期只做 **PROCURE 选品加购的第一刀**：在原查价工程上改，不接状态中心、不接 Oracle、不改合同/返利。先跑通「登录搜品 → 按行判定 → 合格加购」。
|
||
|
||
---
|
||
|
||
## 1. 要做成什么
|
||
|
||
一次脚本运行：
|
||
|
||
1. 读入待选品行（批准文号、销售价格、采购数量）。
|
||
2. 浏览器登录 1 号药城、药帮忙各一次，拿 cookie/token。
|
||
3. 按批准文号打现有搜索接口，拉候选（商家、价、效期、库存）。
|
||
4. 用洁达选品规则，每个平台每行最多选出 **1 家仓**。
|
||
5. 合格则加入该平台购物车；不合格记跳过；查询失败记失败。
|
||
6. 写出结果表。人工付款仍由业务在平台做，脚本不等、不点支付。
|
||
|
||
完成标准：Windows 机用 5～20 个品种能稳定跑完；结果表能看出每行 `ADDED / SKIPPED / FAILED`；合格行购物车里能看到对应商品和数量。默认 `--dry-run` 只判定不加购，确认规则后再关。
|
||
|
||
## 2. 为什么改原工程，不另起
|
||
|
||
原工程已经有：双平台登录、搜索 API、1 号药城价格解密、按文号缓存、接口重试。缺的是选品决策和加购。合同那套 Studio 逐步点击不适合一千个品种。
|
||
|
||
原工程里必须删掉的：
|
||
|
||
- `filter_rows_by_purchase_price_band`（采购价 ±10%）
|
||
- 把所有命中行倒进 Excel 当最终答案
|
||
- 用「采购价格」做是否合格的依据
|
||
|
||
保留的：登录、`query_yaoex_products`、`query_ybm_products`、`decrypt_yaoex_price`、密码箱、重试。
|
||
|
||
## 3. 架构
|
||
|
||
```text
|
||
Excel 输入（本期）
|
||
→ 登录一次 / 平台
|
||
→ 搜索接口（按批准文号，带缓存）
|
||
→ 选品规则引擎（纯 Python，两平台同一套）
|
||
→ 加购适配器（先接口，抓不到再点页面；仅合格行）
|
||
→ 结果 Excel（每行一个平台一个结论）
|
||
```
|
||
|
||
平台只负责登录、搜索、读商品、执行加购。**不能改规则优先级。**
|
||
|
||
本期输入仍用桌面 Excel，是为了在 Windows 上先试，不堵在 Oracle。列必须有 **销售价格**，不能再用采购价冒充。下一期再把输入/回报换成状态中心领取。
|
||
|
||
## 4. 按行怎么跑
|
||
|
||
一行输入 × 一个平台 = 一条结论。一次脚本把两个平台都跑完。
|
||
|
||
```text
|
||
登录两个商城（各一次）
|
||
for 每一行输入:
|
||
for 平台 in [1号药城, 药帮忙]:
|
||
搜批准文号
|
||
规则选出 0 或 1 个仓
|
||
合格 → 加购（dry-run 则跳过动作）→ ADDED
|
||
无合格仓 → SKIPPED + 原因
|
||
接口/登录级错误 → FAILED + 原因（不是 SKIPPED）
|
||
写结果表，退出
|
||
```
|
||
|
||
**两边都合格就两边都加购。** 同一销售行可能进两个购物车。若业务要互斥，只改这一条策略，不要改规则引擎。
|
||
|
||
登录失败整批中止。单个文号查询失败只失败该平台该行，继续后面的行。
|
||
|
||
## 5. 合格标准（两平台同一套）
|
||
|
||
按批准文号查询，不配规格、厂家、包装。前 4 项必须同时过，再按仓库名单取第一家。
|
||
|
||
| 顺序 | 条件 | 判定 |
|
||
| --- | --- | --- |
|
||
| 1 | 自营仓 | 商家名规范化后，必须落在下列 11 家里 |
|
||
| 2 | 价格 | `(销售价格 - 平台价) / 销售价格 >= 0.05`，即平台价 ≤ 销售价 × 0.95。基准是输入里的**销售价格** |
|
||
| 3 | 效期 | ≥ 12 个月 |
|
||
| 4 | 库存 | 平台库存 ≥ 本行采购数量 |
|
||
| 5 | 仓库距离 | 在 1～4 都过的候选里，按下列顺序取第一家 |
|
||
|
||
仓库顺序（不可改、不可按页面默认排序）：
|
||
|
||
1. 广东壹号药业有限公司
|
||
2. 昆山亿方药业有限公司
|
||
3. 湖北亿昊药业有限公司
|
||
4. 天津壹号药业有限公司
|
||
5. 重庆亿昊药业有限公司
|
||
6. 重庆壹号医药有限公司
|
||
7. 湖南壹号药业股份有限公司
|
||
8. 辽宁亿昊药业有限公司
|
||
9. 河南壹号医药有限公司
|
||
10. 甘肃壹号云医药有限责任公司企业店
|
||
11. 陕西壹号药业有限公司
|
||
|
||
商家名先去掉 `[自营]`、首尾空格再比。对不上名单 = 本候选淘汰，不是整行失败。对不上的原始商家名写入结果，方便以后补别名。本期不做模糊匹配。
|
||
|
||
效期：接口已带「12 个月」过滤，代码仍要再验。解析不了的效期，该候选淘汰。
|
||
|
||
查询失败、登录失败、加购后不确定是否进车，记 `FAILED` / `UNKNOWN`，**禁止记成 SKIPPED**。
|
||
|
||
## 6. 加购
|
||
|
||
原工程没有购物车代码。合格之后才加购，数量 = 本行采购数量。
|
||
|
||
1. 用 F12 抓「加入购物车」请求（详细方案有步骤）。
|
||
2. 抓到则复用登录态打接口。
|
||
3. 抓不到则只对合格行点页面，禁止一千条都去点搜索。
|
||
4. `--dry-run` 默认开启：只写「将加购」不真正加。Windows 先用 dry-run 对规则，再用 1～2 行关 dry-run 验车。
|
||
|
||
脚本不打开结算、不点支付。
|
||
|
||
## 7. 本期不做
|
||
|
||
- 状态中心领取 / start / complete / fail
|
||
- Oracle 接口表、行 job
|
||
- 平台订单导出、合同、返利
|
||
- 人工付款、待复核清单替代加购（新方案是合格就加购）
|
||
- 把查价 ±10% 留作并行规则
|
||
|
||
## 8. Windows 交付物
|
||
|
||
- 改过的 `isa-rpa` 工程（可运行）
|
||
- 输入模板（含销售价格、采购数量、批准文号）
|
||
- 结果表（每行每平台：结论、原因、选中商家、平台价、效期、库存、是否 dry-run）
|
||
- 加购接口记录（URL、方法、关键字段；或「改用页面点击」的说明）
|
||
- 用 5 个品种跑通的截图或结果文件
|
||
|
||
详细到函数、表头、命令、测试步骤，见详细方案。
|