# 纪要：RPA 与订单中心接口口径

- 时间：2026-09-29～30
- 材料：`RPA与订单中心接口设计_20260922.xlsx`、`API鉴权.doc`、`docs/合同返利系统字段映射_20260911.xlsx`、方案 v20260924
- 开发对照：`docs/RPA订单中心接口开发口径_20260930.md`

---

## 一、接口怎么理解

四个口不是四条流程一对一。1 是选品收件，2 是加购/支付回传，3 是合同和返利共用的行级下发，4 是合同/协议结果回写。

对码不在本方。接口 1 的 `goodsId` 进来就已经有了。

表 1 是收件箱：订单中心推 → 本方接口写入表 1 → 选品捞待处理。不是手填。

---

## 二、已锁定论

### 合单

福建确认一天两班（中午、下午）。Albert：未处理行按供应商汇总，一个供应商一份合同、一份返利。

锁定：

- 按 `supplierId` 合，不用 `omsId`，不用名称
- 任务启动冻结快照，新进数据下一班
- 头字段取该班该供应商第一行（同一班账期不一致也照录，算对方发数）
- 下午再来的另开一份，不改上午已录合同
- 带合同号的协议重录不进按供应商合

### 选品 / 加购 / 支付

- 搜商城用条形码
- 规则不过：表 1 失败 + 表 2 `status=2` + 原因；默认对方**不重推**该 `omsId`（口头再跟对方确认，开发按已锁）
- `status` 只用于加购。支付：有单号就推 `operateType=2`，没付不推，没有支付失败
- 入站一单一个品种；多平台凑数量时同一 `omsId` 多行、`multi_platform_flag=1`、必须同包回（已进表 2）
- 付款仍是采购员两班；支付回传另排，选品不等

### 合同 / 返利回写（业务确认）

合同选 A：提交后回起草；成功=返利中心能搜到合同号。搜不到下一班再搜，不重录合同。

返利选 A 的字面、按现场做：据说无审批流，点送审即成功，点完就回成功并带协议号。以后若开审批流再改。

查号挂在返利班，不单开查状态任务。合同班只录+提交+回起草。

这期不做「合同审完订单中心再推返利包」。二次推只用接口已写的「协议失败带合同号重录」。

暂存号不用于返利。返利用正式合同号去搜。

### 这期范围

- 只做账期。`customerType` 预留，对方固定传 1。预付项目组不做。
- 平台字典：66 = 1 药城，48 = 药帮忙
- 返利总单默认值跟映射表，不跟方案 5.5
- MDM 码对方说默认必填，按必填做；示例没带先不管
- 失败行数量/单价必填、总价舍入：先不管，真数据出问题打回订单中心

### 联调

- Token 测试地址已有；测试用户名 `rpa`（密码不入库）
- 接口 2、4 路径暂时空着，先造数

---

## 三、讨论过程中澄清过的误解

1. 接口 3 一次可以很多行，那是批量收件，不是「已经合成一份合同」。合单是本方按供应商做的。
2. 供应商编码不是小药药商家名。这期用对方给的 MDM/供应商字段填页面。
3. 接口 4 示例是 RPA 把结果推出去，不是「合同审批完通知订单中心再推返利」。
4. `contractStatus=2` 不是让本方重复录合同，是提交后按班次去返利**查号**。
5. 审批/驳回不是本方作业；但合同成功码按接口仍要查号，不能理解成「填完报成功」。
6. 加购「跳过」最后不单开状态码，用失败+原因；和多平台同包回不是一件事。

---

## 四、后置（不挡造数）

- 接口 2、4 真实 URL；`orgSecret` 是否要带；订单中心调本方 1、3 的鉴权
- 只凑到一部分数量时，多平台报文怎么组
- 返利测试环境确认：点送审后协议号是否立即可见
- 加购业务失败不重推：口头跟对方确认一句

开发以口径文档为准。本文只记为什么这么定。