# 福建洁达采购 RPA 概要设计 | 文档属性 | 内容 | | --- | --- | | 版本 | V3.1 | | 日期 | 2026-09-13 | | 状态 | 设计评审稿;未实施代码或建表 | | 适用系统 | 当前 AutoRpa 状态中心、RPA 执行程序及福建洁达采购业务 | | 本版核心关系 | 订单中心一次推送合同/返利共用数据;合同先处理,返利按自己的排期读取同一份数据 | | 文档范围 | 概要设计、表与状态详细设计、接口及时序、异常恢复、运维查询、实施与验收 | | 替代关系 | 整合原 Codex 设计稿 V1.9 和技术实现说明 V2.3;旧方案仅供历史参考 | **阅读顺序:** 业务评审看第 1–3 章;开发看第 4–9 章;运维看第 10 章;实施验收及未决问题见第 11–12 章。 > 详细的数据模型、接口字段、状态、时序、异常、运维和验收见[《福建洁达采购 RPA 详细设计》](./2026-09-13-jieda-rpa-detailed-design.md)。 ## 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 参考材料 | 材料 | 用途 | | --- | --- | | [合同系统录入流程](/Users/yuuuu/Documents/AutoRpa/资料/合同系统录入流程.md) | 合单、尽调、提交、回写;页面步骤指向 rpa_yisaiqi | | [选品条件 20260902](/Users/yuuuu/Documents/AutoRpa/资料/采购平台选品条件优先项_20260902.txt) | 自营仓、盈利、效期、库存和仓库顺序 | | [合同返利字段映射 20260911](/Users/yuuuu/Documents/AutoRpa/资料/合同返利系统字段映射_20260911.xlsx) | 两个工作表的 46 个 RPA 字段及 Sheet3 导入列 | | [仓库一期技术设计](/Users/yuuuu/Documents/AutoRpa/资料/采购主链RPA一期设计文档.md) | 参考概要/详细设计、实体、接口、状态和审计的组织方式;不沿用其旧业务范围 | | [现有数据库结构](/Users/yuuuu/Documents/AutoRpa/state_center/sql/schema.sql) | 判断 job、节点、待办、日志及证据记录可复用部分 | 本次会话的业务确认优先于旧文档。下文表名、内部代码、API 路径及列类型为本方建议,正式外部字段名、节点代码和现场 Oracle 结构仍需按第 12 章核对。 ## 2. 概要设计:架构与分工 ### 2.1 总体架构 ```mermaid 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 合同与返利的关联 ```mermaid 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 个月、库存满足采购数量四项都通过后,按下列仓库顺序选择。不合格记跳过,平台技术错误记失败。 广东壹号药业有限公司、昆山亿方药业有限公司、湖北亿昊药业有限公司、天津壹号药业有限公司、重庆亿昊药业有限公司、重庆壹号医药有限公司、湖南壹号药业股份有限公司、辽宁亿昊药业有限公司、河南壹号医药有限公司、甘肃壹号云医药有限责任公司企业店、陕西壹号药业有限公司。