# 洁达选品：改造商城查价工程（概要）

| 文档属性 | 内容 |
| --- | --- |
| 版本 | 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 个品种跑通的截图或结果文件

详细到函数、表头、命令、测试步骤，见详细方案。