8.8 KiB
福建洁达采购 RPA 概要设计
| 文档属性 | 内容 |
|---|---|
| 版本 | V3.1 |
| 日期 | 2026-09-13 |
| 状态 | 设计评审稿；未实施代码或建表 |
| 适用系统 | 当前 AutoRpa 状态中心、RPA 执行程序及福建洁达采购业务 |
| 本版核心关系 | 订单中心一次推送合同/返利共用数据；合同先处理，返利按自己的排期读取同一份数据 |
| 文档范围 | 概要设计、表与状态详细设计、接口及时序、异常恢复、运维查询、实施与验收 |
| 替代关系 | 整合原 Codex 设计稿 V1.9 和技术实现说明 V2.3；旧方案仅供历史参考 |
阅读顺序： 业务评审看第 1–3 章；开发看第 4–9 章；运维看第 10 章；实施验收及未决问题见第 11–12 章。
详细的数据模型、接口字段、状态、时序、异常、运维和验收见《福建洁达采购 RPA 详细设计》。
1. 设计依据与范围
1.1 已确认业务规则
| 编号 | 规则 |
|---|---|
| BR-01 | 四条脚本分别运行，自动时间和频率不同，也支持业务点击；一次 HTTP 接收不等待四条流程全部执行 |
| BR-02 | 选品读取未处理销售明细，在 1 号药城和药帮忙均按同一套采购条件执行：按批准文号查询，依次校验自营仓、盈利、有效期、库存，再按仓库距离选择；合格加购物车，不合格跳过，处理完本批结束；不等待人工付款 |
| BR-03 | 本业务相同批准文号只有一个规格，不增加规格、厂家、包装或单位换算匹配 |
| BR-04 | 平台订单导出到各平台对应共享文件夹，按订单中心接口格式组装并推送；对码由订单中心内部处理 |
| BR-05 | 订单中心一次传来的完整业务数据供合同、返利共用，不拆成两次独立供数，不重复保存两份相同头明细 |
| BR-06 | 接收时检查上游应传的必填字段，缺项当次返回失败和字段位置；通过并落表后返回成功 |
| BR-07 | 合同保存成功后调用订单中心链路接口更新对应节点；返利读取同一份接口数据，并使用本方已取得的合同号 |
| BR-08 | 手工单暂不做；合同/返利字段、固定值及原业务人工分支按提供材料执行 |
| BR-09 | RPA 将平台订单的对码原始信息随订单报文传给订单中心；订单中心返回或后续提供标准货品结果，本方不自行判断货品编码 |
1.2 参考材料
| 材料 | 用途 |
|---|---|
| 合同系统录入流程 | 合单、尽调、提交、回写；页面步骤指向 rpa_yisaiqi |
| 选品条件 20260902 | 自营仓、盈利、效期、库存和仓库顺序 |
| 合同返利字段映射 20260911 | 两个工作表的 46 个 RPA 字段及 Sheet3 导入列 |
| 仓库一期技术设计 | 参考概要/详细设计、实体、接口、状态和审计的组织方式；不沿用其旧业务范围 |
| 现有数据库结构 | 判断 job、节点、待办、日志及证据记录可复用部分 |
本次会话的业务确认优先于旧文档。下文表名、内部代码、API 路径及列类型为本方建议，正式外部字段名、节点代码和现场 Oracle 结构仍需按第 12 章核对。
2. 概要设计：架构与分工
2.1 总体架构
flowchart TB
OC[订单中心] -->|销售数据 / 合同返利共用数据| API[FastAPI 接收校验]
API -->|校验成功同事务落表| IFDB[(Oracle 接口头明细及接收记录)]
S[四条独立排期 / 点击脚本] --> RPA[RPA 执行程序]
RPA <-->|领取数据 / 回报结果| SC[状态中心]
SC -->|读取同一份输入| IFDB
SC <--> BDB[(Oracle 作业、节点、调用记录)]
RPA -->|查品加购 / 导出订单| PL[采购平台]
PL --> F[对应共享文件夹]
F -->|组装报文并推送| OC
RPA -->|录入保存| CT[合同系统]
RPA -->|保存后调用链路接口| OC
RPA -->|同一接口数据加合同号| RB[返利中心]
UI[运维列表 / 详情 / 日志] --> SC
接口数据与业务处理记录分开：Oracle 接口表回答“订单中心传了什么”，Oracle 业务记录回答“本方做到哪一步、结果是什么、谁操作过”。 RPA 通过状态中心读取接口数据，数据库连接集中在后端。
2.2 接口表与业务表的选择
| 方式 | 特点 | 本期选择 |
|---|---|---|
| 仅一张接口表加一个 processed 标志 | 简单，但合同处理后可能被整体标记完成，返利漏取；也无法表达多次失败尝试 | 不采用 |
| 接口表再完整复制成合同表、返利表 | 三份字段容易不一致，需要额外同步 | 不采用 |
| 接口头明细保留一份输入，业务作业/节点保存独立状态与结果 | 合同、返利通过相同 INPUT_ID 关联；历史操作复用现有日志 | 采用 |
现有 job / job_node 就是本期业务处理表，无需再复制合同、返利输入。为无 job 的接收失败补接收记录；为跨导出文件识别同一订单，补逐订单推送台账。这两项有明确查询及防重用途。
2.3 模块职责及运行方式
| 模块 | 职责 |
|---|---|
| FastAPI | 校验、保存接收数据、取数、原子领取、保存回报、查询及运维动作 |
| Oracle 接口库 | 接收尝试、销售头明细、合同/返利共用头明细；成功输入保留原值 |
| Oracle 状态中心 | 各流程 job、节点尝试、业务编号、订单推送状态、操作日志、证据索引 |
| 四条 RPA 脚本 | 本批逐条执行；平台订单和合同链路接口由对应脚本通过适配器调用并回报 |
| 现有 Web | 接收查询、共用数据处理总览、节点尝试、文件和运维动作 |
四条脚本分别配置时间、频率及本轮条数上限，单执行机每条脚本设单实例启动控制。FastAPI 常驻。脚本启动时调用后端登记未建立的 job，再领取本流程数据；订单导出先生成并登记 export_batch_id，恢复失败批次沿用该 ID；本批结束释放本机运行锁。没有数据时记录本轮零条并退出，不新增第五条业务或后台维护流程。
3. 概要设计：业务流程与完成边界
| 流程 | 输入 | 正常处理 | 完成含义 |
|---|---|---|---|
| PROCURE | 销售接口表的一条明细 | 按批准文号查询，按采购条件加购或跳过 | 该行处理完；不代表付款成交 |
| ORDER_PUSH | 对应平台导出的订单文件 | 保存共享目录、提取对码原始信息、组装、推送、记录回执 | 应推送订单确认接收；不等待内部对码 |
| CONTRACT | 共用订单接口头明细 | 录入并保存合同，保存合同号，更新订单中心链路 | 保存及链路更新分别记录；链路失败不重建合同 |
| REBATE | 同一共用订单接口头明细＋本方合同保存结果 | 按合同号查协议、填总单、导细单、提交 | 返利提交成功；不要求订单中心再次推数据 |
3.1 合同与返利的关联
flowchart TD
I[一次推送：INPUT_ID = I001] --> C[合同 job：INPUT_ID = I001]
I --> R[返利 job：INPUT_ID = I001]
C --> CS[合同保存成功：合同号 HT001]
CS --> CH[合同链路更新]
CS -->|提供合同号| R
R --> RS[返利提交结果]
合同、返利是两个独立作业，绑定同一 INPUT_ID 和 INPUT_VERSION。合同保存号只从对应合同 job 取得，不能按同品种或同一天猜配。
返利默认在“合同已确认保存成功且合同号存在”后可领取；链路回传结果另列显示，不擅自把链路成功增加为返利前置条件。若目标返利协议暂不可查，记录等待原因，下次返利运行再查询。是否必须审批通过由目标系统及接口方确认，不新增审批动作。
3.2 选品规则
1 号药城和药帮忙共用以下选品判断逻辑。平台只负责登录、搜索、读取商品信息和执行加购，不能改变判断优先级。自营仓、5% 以上盈利、有效期大于等于 12 个月、库存满足采购数量四项都通过后，按下列仓库顺序选择。不合格记跳过，平台技术错误记失败。
广东壹号药业有限公司、昆山亿方药业有限公司、湖北亿昊药业有限公司、天津壹号药业有限公司、重庆亿昊药业有限公司、重庆壹号医药有限公司、湖南壹号药业股份有限公司、辽宁亿昊药业有限公司、河南壹号医药有限公司、甘肃壹号云医药有限责任公司企业店、陕西壹号药业有限公司。