189 lines
10 KiB
Markdown
189 lines
10 KiB
Markdown
# 采购主链 RPA 一期开发规划
|
||
|
||
> 用途：作为开发启动前的对齐底稿，明确"先做什么、后做什么、为什么这个顺序、卡在哪里"。
|
||
> 配套文档：《采购主链RPA一期需求文档_三方会审版》（业务规则）、《界面截图证据记录》（字段结构）。
|
||
> 核心原则：**按风险和依赖排序，不按流程顺序**。让开发启动不被 OCR 决策和资料到位阻塞。
|
||
|
||
---
|
||
|
||
## 一、指导原则
|
||
|
||
1. **风险前置**：最可能推翻项目价值的假设（对码命中率），最先验证，且用最小成本验证。
|
||
2. **依赖解耦**：状态中心与 RPA 执行器分层，业务规则和审计口径掌握在项目方手里，RPA 平台可替换。
|
||
3. **单路打通**：先用最顺的一条来源（医药城）跑通端到端骨架，再横向扩展其他来源。
|
||
4. **降难度上线**：一期只做到"录入待保存 + 人工检查"，把"自动保存/签订"做成配置开关（关闭），规避不可逆操作风险。
|
||
5. **阻塞并行**：OCR 信息安全、资料收集这类非技术阻塞，与开发并行推动，不占用开发关键路径。
|
||
|
||
---
|
||
|
||
## 二、三类拦路虎与应对
|
||
|
||
| 类型 | 具体事项 | 应对方式 | 是否阻塞开发启动 |
|
||
| --- | --- | --- | --- |
|
||
| 决策阻塞 | OCR 走线上还是本地部署（信息安全） | 拉法务部+数据中心+业务三方会 | 否（只阻塞线下手工单分支） |
|
||
| 数据依赖 | 对码表、供应商对照表、计划员表、邮箱、测试账号 | 业务方并行收集 | 部分（对码表验证需要） |
|
||
| 技术未知 | 对码命中率、页面稳定性、返利重复导入处理 | 离线脚本 + POC 试出来 | 是（需最先解决对码） |
|
||
|
||
**结论**：只有"技术未知"里的对码命中率必须最先攻，其余两类并行推进，不进关键路径。
|
||
|
||
---
|
||
|
||
## 三、阶段划分与任务拆解
|
||
|
||
### 阶段 0：可行性验证（不写 RPA 代码，最先做）
|
||
|
||
**目标**：验证对码命中率，决定项目价值和后续工作量。
|
||
|
||
| 任务 | 内容 | 产出 | 依赖 |
|
||
| --- | --- | --- | --- |
|
||
| 0.1 收集样本 | 现有货品对码表 + 一批真实历史订单Excel（医药城/小药药各若干天） | 样本数据集 | 业务提供 |
|
||
| 0.2 离线匹配脚本 | 按"通用名+批准文号+规格+厂家"四要素拼接匹配，统计命中率 | 命中率报告 | 0.1 |
|
||
| 0.3 未命中归因 | 分析未命中的规格差异模式（15×2 vs 30片、干一瓶 vs ×1瓶等） | 差异模式清单 | 0.2 |
|
||
| 0.4 对码策略结论 | 精确匹配率、需模糊匹配的规则、需一对多人工的比例 | 对码方案 | 0.3 |
|
||
|
||
**为什么最先做**：如果命中率过低（如 <70%），意味着大量人工介入，需重新评估 RPA 价值主张或先集中精力做"对码表建设工具"。这一步投入最小、结论最快、不需要任何系统账号或RPA环境。
|
||
|
||
**验收**：给出明确的命中率数字和未命中处理成本估算。
|
||
|
||
---
|
||
|
||
### 阶段 1：状态中心骨架 + 医药城端到端最小闭环
|
||
|
||
**目标**：打通"医药城导出 → 对码 → 合同 → 返利 → M5录入待保存"一条可跑的链路。
|
||
|
||
#### 1.1 状态中心骨架
|
||
| 任务 | 内容 |
|
||
| --- | --- |
|
||
| 数据模型 | `job / job_node / user_task / mapping_config / job_artifact / job_event` |
|
||
| 状态机 | 7状态流转 + attempt_no 重试机制（不覆盖历史） |
|
||
| 幂等机制 | 文件哈希、业务键(合同号+类型+供应商+来源)、回调幂等键 |
|
||
| RPA回调接口 | 统一节点契约（jobId/nodeCode/attemptNo/status/businessRefs/artifacts...） |
|
||
| 证据存储 | 目录结构 `job_id/节点编码/attempt_no/`，截图/日志/JSON |
|
||
|
||
#### 1.2 医药城业务节点（RPA执行器）
|
||
| 节点编码 | 内容 | 关键细节 |
|
||
| --- | --- | --- |
|
||
| `ORDER_FETCH` | 登录医药城，选前一天，导出订单明细Excel | 订单状态过滤【待确认】 |
|
||
| `PRODUCT_MATCH` | 四要素对码 → 货品ID/编码，未命中转人工 | 复用阶段0成果 |
|
||
| `SOURCE_ADD` | 未采购过的供应商品种，通知M5新增货源 | — |
|
||
| `CONTRACT_CREATE` | 合同系统建单，选模板，改签约日期=订单日期 | **同供应商同日合并PDF上传** |
|
||
| `CONTRACT_APPROVE_WAIT` | 送审后等待（半小时后查审核状态） | 等待策略可配置 |
|
||
| `REBATE_HEADER` | 返利中心按合同号查总单，填必填项保存 | 查出信息为空，需手工填 |
|
||
| `REBATE_IMPORT` | 细单模板导入（操作码/数量/单价/税率/承付/结算/特定补偿0/细单备注填订单号/货源） | 重复编码处理【待确认】 |
|
||
| `REBATE_SUBMIT` | 提交送审（决定M5能否带出协议） | 关键卡点 |
|
||
| `M5_CREATE_ORDER` | M5-1055新增订单+细单，备注填订单号，选默认正常保管账 | **不点保存**（阶段一） |
|
||
|
||
#### 1.3 人工协同（企业微信/H5 最小版）
|
||
| 任务 | 内容 |
|
||
| --- | --- |
|
||
| 待办推送 | 对码未命中、货源缺失、质管卡住等，推送到企业微信 |
|
||
| H5确认页 | 查看待确认项、一对多选择、人工修改留痕 |
|
||
| 人工检查入口 | M5录入待保存后，人工检查→保存→签订→生成收货通知单 |
|
||
|
||
**验收**：一条真实医药城订单能从导出跑到 M5 待保存，各节点有证据，人工可在H5介入。
|
||
|
||
---
|
||
|
||
### 阶段 2：横向扩展来源 + 完善异常
|
||
|
||
**目标**：接入小药药、线下手工单，补齐异常分流。
|
||
|
||
| 任务 | 内容 | 前置条件 |
|
||
| --- | --- | --- |
|
||
| 2.1 小药药接入 | 逻辑类似医药城，但格式合同不需上传PDF | **需先补小药药界面画面** |
|
||
| 2.2 线下手工单+OCR | OCR识别开单截图→对码 | **OCR信息安全决策通过** |
|
||
| 2.3 异常分流完善 | 对码未命中、货源缺失、合同禁掉失效邮件通知、返利重复、质管卡住转人工 | 邮箱/角色表到位 |
|
||
| 2.4 收货通知单 | `M5_RECEIPT_NOTICE` + `ARCHIVE_JOB` | — |
|
||
| 2.5 订单号追溯 | 返利(物流看)/M5(结算看)订单号贯穿校验 | — |
|
||
|
||
---
|
||
|
||
### 阶段 3：稳定性与自动化开关
|
||
|
||
**目标**：验证准确率，逐步放开自动化。
|
||
|
||
| 任务 | 内容 |
|
||
| --- | --- |
|
||
| 3.1 准确率统计 | 统计各节点自动完成率、人工纠正率 |
|
||
| 3.2 自动保存开关 | 准确率达标后，打开 `M5_MANUAL_CONFIRM` 自动化（保存/签订/生成通知单） |
|
||
| 3.3 重试与超时 | 系统异常自动重试1-2次；节点超时升级；待办30分钟/2小时提醒升级 |
|
||
| 3.4 平台可替换POC | 若需接第二个RPA平台，验证登录/检索/导入/截图/回调用例 |
|
||
|
||
---
|
||
|
||
## 四、技术选型推荐
|
||
|
||
> 以下为推荐方案，**均可根据公司现有技术栈和团队能力调整**。医药商业公司IT环境通常以稳定、可维护为先。
|
||
|
||
### 状态中心（后端）
|
||
| 项 | 推荐 | 理由 | 备选 |
|
||
| --- | --- | --- | --- |
|
||
| 语言/框架 | **Python 3 + FastAPI** | 与对码/OCR脚本同栈，开发快，Pydantic 校验回调契约方便；骨架已跑通（`state_center/`） | Java + Spring Boot（团队偏Java时可平移，契约不变） |
|
||
| 数据库 | **MySQL 8** | 状态中心自有库，只存流程状态+累积别名+证据（对码表在 Oracle，直连查不复制） | PostgreSQL |
|
||
| 状态机 | 轻量自实现（NODE_ORDER 顺序 + 7 状态枚举） | 7状态流转清晰，自实现更可控 | — |
|
||
| 对象存储 | MinIO / 公司现有NAS | 合同PDF、截图、OCR JSON等证据 | 本地文件系统 |
|
||
|
||
### RPA 执行平台
|
||
| 项 | 推荐 | 理由 |
|
||
| --- | --- | --- |
|
||
| 平台 | **国产商业RPA（影刀 / 来也UiBot / 艺赛旗）择一POC** | 5个系统均为国内Web/客户端，国产RPA对中文界面、验证码、客户端控件支持好，有本地部署和技术支持；需求已要求"平台可替换"，先接一个主平台 |
|
||
| 关键要求 | 支持HTTP回调状态中心、截图留证、Excel读写、PDF合并、文件上传 | 对应本项目节点契约 |
|
||
|
||
> 选型建议：让候选平台跑一个POC用例——登录返利中心+检索+模板导入+截图+HTTP回调，通过再定。
|
||
|
||
### OCR（仅线下手工单，取决于信息安全决策）
|
||
| 场景 | 推荐 |
|
||
| --- | --- |
|
||
| 若允许本地部署 | **PaddleOCR（本地）** — 无信息安全顾虑，一次性投入 |
|
||
| 若允许线上 | 阿里/腾讯云OCR — 按量付费，实际用量约十几元/月 |
|
||
|
||
### 企业微信 / H5
|
||
| 项 | 推荐 |
|
||
| --- | --- |
|
||
| 待办推送 | 企业微信应用消息/群机器人 |
|
||
| H5 | 轻量前端（Vue/React）+ 企业微信OAuth身份 |
|
||
|
||
### 部署
|
||
| 项 | 推荐 |
|
||
| --- | --- |
|
||
| 状态中心 | 公司内网服务器/容器，与业务系统同网段便于RPA访问 |
|
||
| RPA运行机 | 独立运行机/虚拟机，7×24或定时任务，保持登录态 |
|
||
|
||
---
|
||
|
||
## 五、关键路径与阻塞项（甘特视角）
|
||
|
||
```
|
||
阶段0对码验证 ──┬──────────────────────────► (决定项目走向)
|
||
│
|
||
业务收集资料 ───┼───(对码表/账号/对照表/邮箱)──► 阶段1需要
|
||
│
|
||
OCR信息安全决策 ┼────────────────► 仅阻塞阶段2.2线下单
|
||
│
|
||
└─► 阶段1 骨架+医药城 ─► 阶段2 扩展 ─► 阶段3 自动化
|
||
```
|
||
|
||
**关键路径**：阶段0对码验证 → 阶段1医药城闭环。
|
||
**不在关键路径的阻塞**：OCR决策（只影响2.2）、小药药画面（只影响2.1）。
|
||
|
||
---
|
||
|
||
## 六、启动前需要业务方立即提供
|
||
|
||
| 优先级 | 事项 | 用于 |
|
||
| --- | --- | --- |
|
||
| P0 | 货品对码表 + 历史订单Excel样本 | 阶段0验证 |
|
||
| P0 | 测试账号（合同系统/返利中心/M5/医药城） | 阶段1开发 |
|
||
| P1 | 供应商对照表（合同类别/结算/合同性质） | `CONTRACT_CREATE` |
|
||
| P1 | 计划员与合同对应关系表 | 待办路由 |
|
||
| P1 | 通知邮箱（禁掉通知、质管缺料，可多人） | 异常分流 |
|
||
| P2 | 小药药平台完整演示/截图 | 阶段2.1 |
|
||
|
||
## 七、需先拍板的决策项
|
||
|
||
1. **OCR信息安全**（最大卡点）：线上是否获批 / 本地部署预算。
|
||
2. **返利中心重复订单**完整处理规则（会议未讲完）。
|
||
3. **医药城订单状态过滤**：只取"待收货"还是含其他。
|
||
4. **加单场景**：父订单号关联、重做逻辑。
|
||
5. **技术栈确认**：上述推荐是否与公司现有栈冲突。
|