weaver-work-cli 0.1.40 → 0.1.44

package/skills/weaver-e10-yepiaotong/references/reim-matching-rules.md

@@ -1,6 +1,6 @@
 # 发票与事前申请匹配规则
 
-本文档定义发票与事前申请怎么关联。只比较两边的日期。一张发票在时间上只落在一条事前申请里就直接绑定；落在多条里，或日期缺失对不上，列给用户选。不用费用类型、金额、申请人或标题关键词决定绑哪一条。
+本文档定义发票与事前申请怎么关联。按出差流程查的票直接绑那条出差流程（场景D），其余只比较两边的日期。一张发票在时间上只落在一条事前申请里就直接绑定；落在多条里，或日期缺失对不上，必须问用户确认是哪一条，问清楚之前不往下走（见「多条事前申请无法确认时，必须问用户」）。不用费用类型、金额、申请人或标题关键词决定绑哪一条。
 
 ---
 
@@ -19,13 +19,8 @@
 
 1. 已有发票数据（通过 `invoice.list` 获取，**或用户直接提供**，含 `invoiceDate`, `amount`, `expenseType`, `sellerName` 等）
   - 如果用户已直接给出发票数据，无需调用 `invoice.list`
-2. **预筛选**：利用发票日期缩小事前申请查询范围
-  - 提取发票数据中最早和最晚的 `invoiceDate`
-  - 事前申请日期必然 ≤ 开票日期，因此：
-    - `cusCreateDateEnd` = 最晚 invoiceDate（CLI 会再 + 1 天后发给接口；不按开票日收窄上界时不要传，交给东八区当天 + 1 天）
-    - `cusCreateDateStart` = 最早 invoiceDate 往前推 90 天
-3. 调用 `invoice.reim.requests.list`（带日期筛选条件）获取候选列表
-4. 按下面的时间规则关联；不确定时先问用户，再往下填单
+2. 调用 `invoice.reim.requests.list` 获取候选列表。用户没指定日期时**不传** `cusCreateDateStart` / `cusCreateDateEnd`，由 CLI 按默认窗口查（最近 7 天，查不到自动放宽到最近 1 个月；话费传 `scene="phone"`，查最近 90 天），见 [reim-api-reference.md](reim-api-reference.md)「默认日期窗口」
+3. 按下面的时间规则关联；不确定时先问用户，再往下填单
 
 ### 场景B：先有事前申请 → 筛选并匹配发票
 
@@ -33,8 +28,8 @@
 2. **预筛选**：利用事前申请日期缩小发票查询范围（使用**消费日期** `consumption_tm_begin` / `consumption_tm_end`）
   - 提取事前申请列表中最早的 `createTime`
   - 消费日期必然 ≥ 事前申请日期，因此：
-    - `consumption_tm_begin` = 最早 createTime 对应的秒级时间戳（00:00:00）
-    - `consumption_tm_end` = 当前日期 23:59:59 的秒级时间戳
+    - `consumption_tm_begin` = 最早 `createTime` 的日期部分（`YYYY-MM-DD`）
+    - `consumption_tm_end` = 今天（`YYYY-MM-DD`，CLI 按当天 23:59:59 换算）
 3. 调用 `invoice.list`（带消费日期筛选条件）获取候选列表
 4. 按下面的时间规则关联；不确定时先问用户，再往下填单
 
@@ -42,7 +37,11 @@
 
 两者并行获取时不做预筛选，获取全量数据后在匹配阶段统一过滤。
 
-三种场景使用同一套时间规则，只是取数和预筛选不同。
+场景 A ~ C 使用同一套时间规则，只是取数和预筛选不同。
+
+### 场景D：按出差流程查的票 → 直接绑这条出差流程
+
+发票是按 [reim-workflow.md](reim-workflow.md)「按出差流程查票」用出差流程的起止日期（前后各 1 天）查出来的：**不走下面的时间规则**，每张发票都绑这条出差流程。出差流程常在出差后才补发起，发起日晚于开票日也照样绑定；也不再拿其他事前申请来比。
 
 ---
 
@@ -57,37 +56,71 @@
 - `invoiceDate` ≥ 事前申请发起日（含同一天）
 - `invoiceDate` ≤ 事前申请发起日 + 90 天
 
-**话费报销**没有 90 天上限：只要 `invoiceDate` ≥ 事前申请发起日（含同一天）即可。查询仍按 [reim-phone-subsidy-rules.md](reim-phone-subsidy-rules.md) 回溯 3 年。关联时不看标题里有没有「话费」。
+**话费报销**没有 90 天上限：只要 `invoiceDate` ≥ 事前申请发起日（含同一天）即可。查询按 [reim-phone-subsidy-rules.md](reim-phone-subsidy-rules.md) 传 `scene="phone"`（默认最近 90 天）。关联时不看标题里有没有「话费」。
 
 每张发票单独判断：
 
 | 时间上能对上的事前申请 | 怎么处理 |
 | --- | --- |
 | 正好 1 条 | 直接绑定。不问「要不要关联」，也不用费用类型、金额、申请人或谁更近去改绑 |
-| 2 条及以上 | 不确定。把这几条的名称和发起日期列出来，让用户选一条。选定前不要往下填「相关流程」 |
+| 2 条及以上 | 无法确认，按下面「多条事前申请无法确认时，必须问用户」问清楚。选定前不要往下填「相关流程」 |
 | 0 条 | 这张发票不绑定。非差旅 / 外出可以继续报销。差旅 / 外出仍按 [reim-workflow.md](reim-workflow.md) Step 4.7 让用户选事前申请 |
-| 发票没有 `invoiceDate` | 不确定。列出本次查到的事前申请，让用户选 |
+| 发票没有 `invoiceDate` | 无法确认，列出本次查到的事前申请，按下面同一套规则问 |
 
-一条事前申请可以绑多张发票。一张发票只能绑一条。多张发票都不确定、候选又是同一批时，一次问完：用户可以说「都用某一条」，但这一条必须落在该发票的时间候选里，否则指出哪张对不上，再问。
+一条事前申请可以绑多张发票。一张发票只能绑一条。
 
 不要打分，不要看置信度，不要因为标题含「交通」「差旅」就选中某一条。
 
 ---
 
-## 怎么问用户
+## 多条事前申请无法确认时，必须问用户
+
+> **确认不了是哪条事前申请，就停下来问用户，问清楚之前不往下走。** 不调用 `invoice.reim.workflow.resolve`、`workflow.createForm`、`workflow.createRequest`，也不先建草稿再改。不要按费用类型、金额、标题关键词、「谁更近」或「最新那条」自己挑。
+
+### 哪些情况算无法确认
+
+| 情况 | 例子 |
+| --- | --- |
+| 一张发票按时间对上 2 条及以上 | 开票日期 07-30，落在 07-01 和 07-20 两条的 90 天内 |
+| 发票没有开票日期，而本次查到了事前申请 | OCR 没识别出日期 |
+| 差旅 / 外出某行没绑定，而差旅 / 外出事前申请有多条 | 见 [reim-form-fill-rules.md](reim-form-fill-rules.md#差旅--外出明细相关流程硬拦截) |
+| 用户点名了事前申请，但对上多条或一条都对不上 | 「用上海出差那个申请」，标题含「上海出差」的有 2 条 |
+| 话费报销时间上还剩多条 | 见 [reim-phone-subsidy-rules.md](reim-phone-subsidy-rules.md) |
+
+一张发票只对上一条时仍直接绑定，不问。
+
+### 怎么问
 
-只在不确定时暂停。列出发票号码、开票日期，以及每条候选的 `requestname` 和发起日期，让用户按序号或名称选。
+- **一次问完**：本次所有不确定的发票放在同一个问题里，不要一张一张问。候选是同一批时合成一张表。
+- **每条候选写清楚，方便区分**：序号、`requestname`、发起日期（`createTime` 的日期部分）、流程状态（`flowStatus=6` 写「已完成」，其他写「未完成」）、能对上哪几张发票。名称完全相同时再补 `requestid`。
+- **给一个「都不是」的出口**：非差旅 / 外出选「都不是」→ 该发票不绑定，继续报销；差旅 / 外出选「都不是」→ 请用户给出正确的事前申请名称再查，用户拒绝就结束报销。
+- 宿主有提问 / 选择弹框时用弹框，每条候选一个选项，再加「都不是」；没有弹框就用下面的表格。
 
 ```markdown
-这张发票在时间上对上了 2 条事前申请，请选一条：
+下面的发票对上了多条事前申请，我确认不了该用哪条，请告诉我每张发票用哪一条（回复序号即可，例如「都用 2」或「36901189 用 1，36901190 用 2」）：
 
-| # | 发票号码 | 开票日期 | 可选事前申请 | 发起日期 |
+| # | 事前申请 | 发起日期 | 状态 | 能对上的发票 |
 | --- | --- | --- | --- | --- |
-| 1 | 36901189 | 2026-07-30 | 交通费报销-后端开发111-2026-07-01 | 2026-07-01 |
-| 2 | 36901189 | 2026-07-30 | 上海出差申请-后端开发111-2026-07-20 | 2026-07-20 |
+| 1 | 交通费报销-后端开发111-2026-07-01 | 2026-07-01 | 已完成 | 36901189（07-30）、36901190（08-02） |
+| 2 | 上海出差申请-后端开发111-2026-07-20 | 2026-07-20 | 已完成 | 36901189（07-30）、36901190（08-02） |
+
+都不是的话，回复「都不是」，或告诉我正确的事前申请名称。
 ```
 
-用户选定后，用 `{requestname}({requestid})` 写入对应明细「相关流程」。
+### 怎么理解用户的回答
+
+| 用户回答 | 处理 |
+| --- | --- |
+| 序号、完整名称或 `requestid`，能唯一对上一条 | 按用户说的绑定 |
+| 「都用 N」 | 每张发票都用第 N 条。某张发票时间上对不上第 N 条 → 指出是哪张、为什么对不上，只就这张再问 |
+| 名称片段，在候选里只对上一条 | 按它绑定，回显时写出完整名称 |
+| 按描述能推出唯一一条（「最新那个」且发起日期各不相同） | 这是推断出来的，先回显完整名称请用户确认一次，确认后再绑定 |
+| 含糊或对上多条（「上海那个」而候选里有 2 条上海；「最新那个」但最新的有 2 条同一天） | 不猜。把仍可能的候选再列一次，请用户回复序号 |
+| 「随便」「你定」 | 不替用户选。说明绑错事前申请会影响报销工作流和审批，请用户回复序号 |
+| 「都不是」或给了列表外的名称 | 按「都不是」处理；给了名称就用 `invoice.reim.requests.list` 的 `requestname` 查一次，查到唯一一条且时间对得上就用它，否则再问 |
+| 只回答了一部分发票 | 已回答的先记下，没回答的发票再问一次，不要默认成同一条 |
+
+用户明确选定后（序号、完整名称、`requestid`，或确认了推断的那条），在下一条回复开头用一句话回显绑定结果（如「已按你的选择：36901189、36901190 → 上海出差申请-后端开发111-2026-07-20」），然后直接往下走，不再追问「确认吗」。选定的事前申请用 `{requestname}({requestid})` 写入对应明细「相关流程」。
 
 ---
 

package/skills/weaver-e10-yepiaotong/references/reim-phone-subsidy-rules.md

@@ -10,7 +10,7 @@
 | 判断依据 | 条件 |
 |----------|------|
 | 报销工作流名称 `workFlowName` | 含「话费补贴标准审批流程」或「话费报销」 |
-| 事前申请名称 `requestname` / `requestnametitle` | 含「话费补贴」或「话费报销」 |
+| 事前申请名称 `requestname` | 含「话费补贴」或「话费报销」 |
 | 用户表述 | 明确说「话费报销」「话费补贴」 |
 
 > 通讯类发票（`expenseType` 含「通讯」、销方为「中国移动 / 中国联通 / 中国电信」）若已匹配到上述流程，同样适用。
@@ -101,30 +101,20 @@
 
 ---
 
-## 事前申请查询：必须回溯 2~3 年
+## 事前申请查询：传 `scene="phone"`，默认查最近 90 天
 
-话费补贴的事前申请（「话费补贴标准审批流程」）可能在很早以前发起，审批通过后长期有效，每月按标准报销。
-
-**默认 90 天回溯窗口不适用于话费报销。** 识别为话费报销后，`invoice.reim.requests.list` 的 `cusCreateDateStart` 必须至少往前推 **3 年**（1095 天）：
-
-```
-cusCreateDateStart = 最早发票 invoiceDate 往前推 1095 天（3 年）
-cusCreateDateEnd   = 最晚发票 invoiceDate（CLI 会再 + 1 天后发给接口）
-```
-
-示例（发票日期 2026-09-20）：
+识别为话费报销后，`invoice.reim.requests.list` 传 `scene="phone"` 和 `requestname="话费"`。用户没指定日期时**不传** `cusCreateDateStart` / `cusCreateDateEnd`：CLI 取东八区当天为结束日、往前 90 天为开始日（结束日发给接口时再 + 1 天）。
 
 ```json
 {
   "pageNo": 1,
   "pageSize": 100,
   "requestname": "话费",
-  "cusCreateDateStart": "2023-09-20",
-  "cusCreateDateEnd": "2026-09-20"
+  "scene": "phone"
 }
 ```
 
-> 如果 3 年内仍查不到，可继续问用户是否有更早的事前申请，但不要猜测或跳过。
+> 90 天内查不到时，告诉用户最近 90 天没有话费事前申请，问用户是否有更早的事前申请、大概什么时候发起的；用户给了时间再传 `cusCreateDateStart` 查，不要猜测或跳过。
 
 ### 匹配时间窗口同步放宽
 
@@ -133,7 +123,7 @@ cusCreateDateEnd   = 最晚发票 invoiceDate（CLI 会再 + 1 天后发给接
 话费报销关联时：
 - **取消 90 天窗口限制**：只要 `invoiceDate >= createTime 的日期部分`（发票日期不早于事前申请发起日期，同一天也算）即可进入候选
 - 查询时用 `requestname="话费"` 缩小列表；关联本身不再看标题、费用类型或金额
-- 时间上只剩 1 条 → 直接绑定。还剩多条 → 把名称和发起日期列给用户选
+- 时间上只剩 1 条 → 直接绑定。还剩多条 → 按 [reim-matching-rules.md](reim-matching-rules.md#多条事前申请无法确认时必须问用户) 问用户用哪一条，问清楚前不往下走
 
 ---
 
@@ -144,6 +134,6 @@ cusCreateDateEnd   = 最晚发票 invoiceDate（CLI 会再 + 1 天后发给接
 3. 确认用户岗位对应的月度上限；未确认则暂停询问
 4. 按账单构成剔除赠送套餐、家庭宽带，算出可报销账单金额
 5. 按 `min(可报销账单金额, 上限)` 得到实报金额，展示给用户确认
-6. 查询事前申请时使用 **3 年回溯**（`cusCreateDateStart` 往前推 1095 天），用 `requestname="话费"` 缩小范围
+6. 查询事前申请时传 `scene="phone"`（CLI 默认查最近 90 天），用 `requestname="话费"` 缩小范围
 7. 匹配到事前申请后，用户确认，才允许进入 [reim-workflow.md](reim-workflow.md) Step 5（`workflow.createRequest` 存草稿）。建单后对比每行实报金额与联动带出的金额，告诉用户
 8. 材料不齐、岗位未确认、账单构成无法拆分、或用户拒绝 → **结束流程，禁止创建**

package/skills/weaver-e10-yepiaotong/references/reim-workflow.md

@@ -1,7 +1,7 @@
 # AI 报销单自动填单 — 工作流编排
 
 > 本文件是报销自动填单的完整工作流参考。
-> 发票、事前申请、预填信息等数据准备走本技能的 `weaver-work-cli --json invoice run <operation>`；**报销单的创建与修改统一走 `weaver-e10-workflow` 技能**（`workflow.createForm` / `workflow.createRequest` / `workflow.edit*`），命令契约与返回处置见 [`../../weaver-e10-workflow/references/workflow-create.md`](../../weaver-e10-workflow/references/workflow-create.md) 与 [`workflow-edit.md`](../../weaver-e10-workflow/references/workflow-edit.md)。
+> 发票、事前申请、工作流等数据准备走本技能的 `weaver-work-cli --json invoice run <operation>`；**报销单的创建与修改统一走 `weaver-e10-workflow` 技能**（`workflow.createForm` / `workflow.createRequest` / `workflow.edit*`），命令契约与返回处置见 [`../../weaver-e10-workflow/references/workflow-create.md`](../../weaver-e10-workflow/references/workflow-create.md) 与 [`workflow-edit.md`](../../weaver-e10-workflow/references/workflow-edit.md)。
 > 所有调用都必须通过 CLI 执行，不能直接 curl E10 接口。
 
 ---
@@ -40,47 +40,32 @@
 | 发票金额 | 价税合计 `info.comm_info.price.total` | 主表金额字段（可写时）按它求和；明细金额不传，由发票联动带出。**不是** `price.amount` / `invoice.get` 的 `amount`（都是不含税） |
 | 明细可写列 | 相关发票（+ 绑定事前申请时的相关流程） | 明细每行只写这两列，币种、金额、日期、科目等其余列都不传，由发票联动带出，见 [reim-form-fill-rules.md](reim-form-fill-rules.md#费用明细字段规则) |
 | 报销方式默认值 | `"银行（个人报销）"` | Select 传选项名；表单默认带出时不传 |
-| 全额红冲状态值 | `status = 8` | `comm_info.pro.status`；此类发票必须过滤，不允许报销 |
 | 相关凭证 typeCode | 17, 18, 57, 58 | 不能独立成行；明细「相关凭证」不赋值，由发票联动带出 |
 | 直接上级取值 | `directSuperior` | ⚠️ **不是 `allSuperiors[0]`**（后者是上级链最高层） |
 | 总部费用报销 | `总部费用报销(100003460000000060)` | 费用明细 `subFormId` = `100003690000000011`（字段清单以 `createForm` 实际返回为准） |
 
 ---
 
-## 时间戳内联计算（零工具调用）
+## 查票日期
 
-> **所有日期 → 秒级时间戳的转换由 AI 直接计算，无需调用外部脚本。**
+日期一律直接传 `"YYYY-MM-DD"`，CLI 按东八区换算（消费日期的结束日按当天 `23:59:59`），**不要自己算时间戳**。
 
-### 计算公式（UTC+8 时区）
-
-```
-日期 → 秒级时间戳：
-  起始时间 = Date("YYYY-MM-DD 00:00:00 +08:00") 的 Unix 秒数
-  结束时间 = Date("YYYY-MM-DD 23:59:59 +08:00") 的 Unix 秒数
-
-默认查询（最近一周）：
-  begin = 今天00:00:00秒时间戳 - 7 * 86400
-  end   = 今天23:59:59秒时间戳
-
-扩大到一个月（fallback）：
-  begin = 今天00:00:00秒时间戳 - 30 * 86400
-  end   = 今天23:59:59秒时间戳
-
-用户指定日期范围：
-  begin = 指定起始日 00:00:00 秒时间戳
-  end   = 指定结束日 23:59:59 秒时间戳
-```
+| 场景 | `consumption_tm_begin` | `consumption_tm_end` |
+| --- | --- | --- |
+| 默认（最近一周） | 今天 - 7 天 | 今天 |
+| 一周没票，扩到一个月 | 今天 - 30 天 | 今天 |
+| 用户指定日期范围 | 指定起始日 | 指定结束日 |
 
 ### 发票查询默认入参
 
-CLI 已默认 `sreim="3"`、`bill_type=0`、`page_size=10`。报销查票时默认按**消费日期**筛选，只传日期范围；也可直接传 `"YYYY-MM-DD"`，由 CLI 转成秒级时间戳（结束日按当天 `23:59:59`）：
+CLI 已默认 `sreim="3"`、`bill_type=0`、`page_size=10`。报销查票时默认按**消费日期**筛选，只传日期范围：
 
 ```json
 {
   "page_size": 20,
   "start_pos": 0,
-  "consumption_tm_begin": "{begin}",
-  "consumption_tm_end": "{end}"
+  "consumption_tm_begin": "2026-07-24",
+  "consumption_tm_end": "2026-07-31"
 }
 ```
 
@@ -111,7 +96,7 @@ CLI 已默认 `sreim="3"`、`bill_type=0`、`page_size=10`。报销查票时默
 
 **正确的行为：**
 
-- 按内联公式计算时间戳参数，调用 `invoice.list` 获取发票数据
+- 按「查票日期」取最近一周，调用 `invoice.list` 获取发票数据
 - 最近一周无结果 → 自动用一个月参数再查
 - 直接调用 `invoice.reim.requests.list` 获取用户的事前申请
 - **获取到发票后，先展示发票汇总信息（张数、基础信息），明确告知用户查询范围，询问用户确认是否报销**
@@ -126,7 +111,8 @@ CLI 已默认 `sreim="3"`、`bill_type=0`、`page_size=10`。报销查票时默
 | "帮我报销" / "我要报销" | 查**最近一周**发票 → 无结果则查**最近一个月** → **展示发票汇总，询问确认** → 确认后走后续流程 |
 | "报销打车费" | 设置 `content="滴滴"` 筛选交通类 → **展示发票汇总，询问确认** → 确认后走后续流程 |
 | "报销上周的发票" | 设置时间范围为上周 → **展示发票汇总，询问确认** → 确认后走后续流程 |
-| "报销上周去北京的费用" / "报销去重庆的发票" | 按**出差时间 + 城市**查票：目的城市的票，加上出差期间**出发城市（没说默认上海）**的打车票（见 Step 1A「出差 / 城市意图查票」）→ **展示发票汇总，询问确认** → 确认后走后续流程 |
+| "报销我的出差" / "按出差流程报销" / "报销 10 月 26 号武汉出差" | 先找**出差流程**，按它的起始日期前 1 天 ~ 结束日期后 1 天查票，这段时间可报的发票**全部列入**（见 Step 1A「按出差流程查票」）→ **展示发票汇总，询问确认** → 确认后走后续流程 |
+| "报销上周去北京的费用" / "报销去重庆的发票" | 同上先找出差流程；**找不到出差流程**才按**出差时间 + 城市**查票：目的城市的票，加上出差期间**出发城市（没说默认上海）**的打车票（见 Step 1A「出差 / 城市意图查票」）→ **展示发票汇总，询问确认** → 确认后走后续流程 |
 | "报销发票号码 xxx" | 设置 `number="xxx"` 精确匹配 → **展示发票汇总，询问确认** → 确认后走后续流程 |
 | 用户直接提供了发票数据 | **跳过 Step 1A** → **展示发票汇总，询问确认** → 确认后继续后续流程 |
 | 用户提供了 fileId | 先调用 `invoice.reim.file-ocr.preview`（Step 0）→ **展示发票汇总，询问确认** → 确认后继续 |
@@ -151,6 +137,7 @@ CLI 已默认 `sreim="3"`、`bill_type=0`、`page_size=10`。报销查票时默
 |----------|---------|
 | "帮我报销" | 1A → **1C（发票确认）→ 用户确认** → 1B → 2 → 2.5 → 3 → 4 → 5 |
 | "报销打车费" / "报销上周的" | 1A（加筛选条件）→ **1C → 用户确认** → 后续同上 |
+| "报销我的出差" / "报销去北京出差的费用" | 1A「按出差流程查票」→ **1C → 用户确认** → 跳过 1B、2（全部绑这条出差流程）→ 2.5 → 3 → 4 → 5 |
 | 提供 fileId | Step 0 → **1C → 用户确认** → 1B → 后续同上 |
 | 直接给发票数据 | **1C → 用户确认** → 1B → 后续同上 |
 
@@ -175,9 +162,9 @@ CLI 已默认 `sreim="3"`、`bill_type=0`、`page_size=10`。报销查票时默
 - 发票列表有数据 → **先展示发票汇总信息（Step 1C），告知用户查询范围，等用户确认后再往下走**
 - 最近一周无结果 → **自动 fallback 到最近一个月再查一次，不需要问用户**
 - 事前申请有数据 → 只按开票日期和事前申请发起日期关联（只比日期，同一天算对上）。一张发票时间上只落在一条里 → 直接绑定，不问「是否关联」
-- 一张发票时间上落在多条事前申请里，或发票没有开票日期 → 把候选列给用户选，选定前不往下填「相关流程」
+- 一张发票时间上落在多条事前申请里、发票没有开票日期、或用户点名的事前申请对上多条 → 确认不了是哪条，必须问用户，一次列出候选让用户选定；选定前不往下走（不 `workflow.resolve`、不建单），回答含糊就再问，不替用户选。见 Step 2
 - 事前申请为空，或时间上一条都对不上 → 非差旅 / 外出时跳过关联，直接用发票数据填单。差旅 / 外出必须先让用户选定事前申请，明细「相关流程」不能空
-- **只有在必须用户做选择时才暂停**（如：一张发票在时间上对上多条事前申请、发票列表为空无法继续、**相关客户 / 相关项目还没在建单前一次问齐**、**差旅 / 外出明细「相关流程」还没有事前申请**、话费材料不齐）；**不询问合同号**；**创建报销单不再问「存草稿 / 提交审批」，直接存草稿**。明细「费用说明」不自己生成，不要为了它暂停问起点和终点
+- **只有在必须用户做选择时才暂停**（如：一张发票在时间上对上多条事前申请、发票列表为空无法继续、**相关客户 / 相关项目还没在建单前一次问齐**、**差旅 / 外出明细「相关流程」还没有事前申请**、话费材料不齐）；**不询问合同号**；**创建报销单不再问「存草稿 / 提交审批」，直接存草稿**
 - **⚠️ 严禁篡改任何原始数据值**
 
 ---
@@ -200,10 +187,9 @@ Step 2.5: invoice.reim.workflow.resolve → 获取报销工作流 ID 与名称
 Step 2.6: 按工作流分组（多个工作流 → 多组，各组独立执行后续步骤）
          ↓  ↓  ↓ (每组)
   ┌──────────────────────────────────────────────┐
-  │ ▼ 并行组 A（同时发起）                          │
+  │ ▼ 并行（同时发起）                              │
   │ Step 3:   workflow.createForm（载入报销表单）     │
-  │ Step 3.6: invoice.browse-field.data（发票对象）   │
-  │ 交通类额外: invoice.get × M                     │
+  │ Step 3.5: invoice.browse-field.data（发票对象）   │
   └──────────────────────────────────────────────┘
          ↓ (全部返回后)
 Step 4: 组装 createRequest 的 data (reim-form-fill-rules.md)
@@ -225,8 +211,7 @@ Step 6 (可选): workflow.editLoad / editPrepare / editApply → 用户修正（
 | 并行组 | 可并行的操作 | 说明 |
 |--------|------------|------|
 | **Step 1 并行** | `invoice.reim.requests.list` 与 Step 1C 发票展示 | 用户确认期间预取事前申请 |
-| **Step 3 并行** | `workflow.createForm` + `invoice.browse-field.data` + `invoice.get` × M | 全部互相独立，**必须同时发起**。建单不再调用 `invoice.reim.row-info-batch` |
-| **交通类行程** | 多张交通发票的 `invoice.get` | 各发票独立，强制并行 |
+| **Step 3 并行** | `workflow.createForm` + `invoice.browse-field.data` | 互相独立，**必须同时发起** |
 
 > **`createForm` 不跨组复用**：它返回的 `continuation` 与本次单据绑定，**每个报销单各调一次 `createForm`**，不能拿上一单的 `continuation` 再发起。
 
@@ -242,7 +227,7 @@ Step 6 (可选): workflow.editLoad / editPrepare / editApply → 用户修正（
 | 部分成功 | 用成功的继续，提示失败项 |
 | **全部失败** | **暂停询问用户**，确认后才继续 |
 
-> CLI 详情见 [reim-api-reference.md](reim-api-reference.md#0-文件ID转发票识别)
+> CLI 详情见 [reim-api-reference.md](reim-api-reference.md#0-文件id转发票识别)
 
 ---
 
@@ -254,33 +239,57 @@ Step 6 (可选): workflow.editLoad / editPrepare / editApply → 用户修正（
 
 | 方式 | 适用 | 说明 |
 | --- | --- | --- |
-| `invoice.reim.candidates.list` | 按日期范围批量报销（推荐） | 自动翻页、自动过滤红冲票，并把发票分成 `available`（可报）/ `assigned`（已挂单）两组；**只从 `available` 里选**。见 [reim-api-reference.md](reim-api-reference.md#1b-报销候选发票分类) |
-| `invoice.list` | 按关键词 / 号码 / 类型筛选 | 需自己过滤红冲票 |
+| `invoice.reim.candidates.list` | 按日期范围批量报销（推荐） | 自动翻页，并把发票分成 `available`（可报）/ `assigned`（已挂单）两组；**只从 `available` 里选**。不带 `ext`，按城市 / 行程查票时不用它。见 [reim-api-reference.md](reim-api-reference.md#2-报销候选发票分类) |
+| `invoice.list` | 按关键词 / 号码 / 类型 / 城市 / 行程筛选 | 带 `extInfo`（城市、备注、起止地） |
 
 ### 默认查询策略（用户未指定日期时）
 
-1. 按内联公式计算最近一周时间戳 → 调用
+1. 按「查票日期」取最近一周 → 调用
 2. 有结果 → Step 1C 展示汇总，告知"查询的是最近一周"
-3. 无有效发票 → 计算最近一个月时间戳 → 再次调用
+3. 无有效发票 → 扩到最近一个月 → 再次调用
 4. 有结果 → Step 1C 展示汇总，告知"最近一周没找到，已扩大到一个月"
 5. 仍无结果 → 告知用户未找到发票，建议指定日期范围
 
+### 按出差流程查票（出差报销优先）
+
+用户要报销出差（「报销我的出差」「按出差流程报销」「报销 10 月 26 号武汉出差」「报销上周去北京的费用」）时，**先找出差流程，用它的起止日期查票**；找不到出差流程才按下一节「出差 / 城市意图查票」。
+
+1. **找出差流程**：`invoice.reim.requests.list` 传 `{"requestname":"出差"}`，不传日期，由 CLI 按默认窗口查（最近 7 天，查不到自动放宽到最近 1 个月）。用户说了出差时间时，传 `cusCreateDateStart` = 出差开始日。出差流程常在出差后才补发起，不要按发起时间排除。
+2. **读起止日期**：对候选（按 `createTime` 倒序，最多 5 条）**并行**调用 `workflow.summary`，取「起始日期」「结束日期」「出差城市」，见 [reim-api-reference.md](reim-api-reference.md#读取出差流程的起止日期workflowsummary)。只读，不标记已读；不要用 `workflow.detail`。
+3. **确定是哪条出差流程**：
+
+   | 情况 | 怎么做 |
+   | --- | --- |
+   | 用户说了日期 / 城市 / 标题，只对上 1 条（日期有重叠、城市相同、标题包含） | 直接用 |
+   | 用户没点名，候选只有 1 条 | 直接用 |
+   | 对上多条，或用户没点名而候选有多条 | 一次列出候选（序号、标题、起止日期、出差城市、状态）请用户选，**不替用户选**；选定前不查票 |
+   | 一条都没有 | 用户提到了城市 → 按下一节「出差 / 城市意图查票」；没提城市 → 告诉用户最近一个月没找到出差流程（用户指定了时间就说那段时间），请用户给出差日期 |
+   | 选中的流程读不到起始 / 结束日期 | 如实告诉用户，请用户直接给出差日期，再按第 4 步查 |
+
+4. **查票**：`invoice.reim.candidates.list`，`consumption_tm_begin` = 起始日期**前 1 天**，`consumption_tm_end` = 结束日期**后 1 天**（按日历进位，如 10-31 后 1 天是 11-01）。
+5. **这段时间内 `available` 的发票全部列入报销**：不再按城市、费用类型、销方筛，出发城市的打车、目的城市的酒店餐饮、其他票都算。`assigned`（已挂在别的报销单上）不列入，在表格下一句说明「另有 N 张已挂在其他报销单上，没有重复列入」。用户可以在 Step 1C 去掉个别发票。
+6. **Step 1C 开头说明**：「按出差流程「{标题}」（{起始日期} ~ {结束日期}，{出差城市}）前后各放宽 1 天，查了消费日期 {开始} ~ {结束} 的发票，共 N 张可报：」
+7. **事前申请就用这条出差流程**：用户确认后**跳过 Step 1B 和 Step 2 的时间匹配**，每一行明细「相关流程」都写 `{requestname}({requestid})`。出差流程常晚于开票才发起，不要用「发起日不晚于开票日」卡掉。Step 2.5 `invoice.reim.workflow.resolve` 传这条的 `requestid`。
+8. `available` 为空 → 告诉用户查了哪段时间、没有可报的发票（有 `assigned` 时说已挂单几张），然后停下，不自己放宽时间。
+
 ### 出差 / 城市意图查票
 
-用户提到了去某个城市（「去北京」「重庆的发票」）时，**不能只按开票日期筛**：出差的票常在回来后才开，用户说的"上周"是出差时间，不是开票时间。
+**按出差流程找不到出差流程时**才走本节。用户提到了去某个城市（「去北京」「重庆的发票」）时，**不能只按开票日期筛**：出差的票常在回来后才开，用户说的"上周"是出差时间，不是开票时间。
 
 0. **先定出发城市**：用户说了从哪出发（「从杭州去北京」「杭州出发」）→ 用用户的；**没说 → 默认上海**，不要问用户。目的城市就是出发城市（如没说出发地却说「去上海」）时，不再单独找出发地的票，按目的城市筛即可。
 1. **时间范围（消费日期 `consumption_tm_begin` / `consumption_tm_end`）**
    - 用户说了出差时间（「上周」「10月12日到15日」）→ 从**出差开始日前 1 天**查到**今天**（去车站 / 机场的打车可能在出发前一天晚上）
    - 没说时间 → 最近一个月；没有与该城市相关的票 → 扩到最近 90 天
-2. **按目的城市逐张筛**（不按 `content` 关键词筛，城市不在消费内容里）：
+2. **按目的城市逐张筛**（不按 `content` 关键词筛，城市不在消费内容里）。`invoice.list --view summary` 已直接给出 `ext` 里的 `city`、`comment`（备注，常写出差地和行程，如「2026/10/25上海-武汉 CZ3580」）、`expenseNote`（费用说明，如「上海-武汉」）、`from` / `to`、`stationGetOn` / `stationGetOff`，先看这些，判断不了再调 `invoice.get`：
 
    | 发票 | 怎么判断与目的城市相关 |
    | --- | --- |
-   | 火车票 / 机票 | 出发站或到达站所在城市是目的城市（列表项带 `from` / `to` 时直接用，没有再调 `invoice.get`）；站名换成城市（「北京南」→ 北京） |
-   | 酒店 / 餐饮 | 销方名称或地址里的城市 |
-   | 打车 / 网约车 | 销方名称里的城市（「重庆滴滴出行科技有限公司」→ 重庆）；或行程单起止点所在城市 |
-   | 其他 | 销方名称或地址里的城市；判断不了的不算相关 |
+   | 火车票 / 机票 | 出发站或到达站所在城市是目的城市（`from` / `to`、`stationGetOn` / `stationGetOff`；代订机票看 `comment` / `expenseNote` 里的「上海-武汉」）；站名换成城市（「北京南」→ 北京） |
+   | 酒店 / 餐饮 | `city`，或销方名称、地址、`comment` 里的城市 |
+   | 打车 / 网约车 | `city`；或 `from` / `to` 起止点所在城市；或销方名称里的城市（「重庆滴滴出行科技有限公司」→ 重庆） |
+   | 其他 | `city`、`comment`，或销方名称、地址里的城市；判断不了的不算相关 |
+
+   注意 `city` 是开票方所在城市：携程等平台代订机票时 `city` 是上海，目的地要看 `comment` / `expenseNote`。
 
 3. **按出差时间再筛一次**：用户说了出差时间时，火车票 / 机票的乘车日期、酒店入住日期要落在出差时间内（前后各放宽 1 天）；打车票和其他票只要开票日期不早于出差开始日即可。
 4. **把出发城市的打车票一起筛进来**（去车站 / 机场、回程到家的打车）：同期查到的票里，同时满足下面三条的也算本次出差的票：
@@ -288,8 +297,8 @@ Step 6 (可选): workflow.editLoad / editPrepare / editApply → 用户修正（
    | 条件 | 怎么判断 |
    | --- | --- |
    | 是打车类交通票 | 出租车、网约车、打车（滴滴、高德、曹操、T3、享道、强生等出行平台，或消费内容是客运 / 运输服务）。出发城市的酒店、餐饮、其他票**不算** |
-   | 在出发城市 | 销方名称或地址里的城市是出发城市（「上海强生出租汽车有限公司」→ 上海）；或行程单 / `from` / `to` 起止点在出发城市（「虹桥火车站」「浦东机场」）；或 `info.province` 是出发城市。销方是「北京小桔科技有限公司」这类全国平台、列表又没有起止点时，调 `invoice.get` 看 `from` / `to` 再判断 |
-   | 消费日期落在出差时间内 | 消费日期取 `info.modify_info.cstm`（`candidates.list` 没有这个字段，用 `invoice.list` 或 `invoice.get` 取）。出差时间：用户说了 → 用用户的，前后各放宽 1 天；没说 → 取第 2 步已筛出的目的城市票里最早到最晚的日期（火车票 / 机票用乘车日期），前后各放宽 1 天 |
+   | 在出发城市 | `city` 是出发城市；或 `from` / `to` 起止点在出发城市（「虹桥火车站」「浦东机场」）；或销方名称里的城市是出发城市（「上海强生出租汽车有限公司」→ 上海）；或 `province` 是出发城市。销方是「北京小桔科技有限公司」这类全国平台、又没有 `city` 和起止点时，调 `invoice.get` 再判断 |
+   | 消费日期落在出差时间内 | 消费日期取 `invoice.list` 的 `items[].modify_info.cstm`（秒级时间戳；`candidates.list` 和 `--view summary` 都没有这个字段，用 `--fields fid,modify_info.cstm` 取）。出差时间：用户说了 → 用用户的，前后各放宽 1 天；没说 → 取第 2 步已筛出的目的城市票里最早到最晚的日期（火车票 / 机票用乘车日期），前后各放宽 1 天 |
 
    - **第 2 步一张目的城市的票都没有时，不单独拿出发城市的打车票凑出差报销**，按第 6 步停下。
    - 判断不了城市、但消费日期落在出差时间内的打车票，不自动算进来，在第 5 步的提示里单独说一句「另有 N 张同期打车票看不出是不是在 {出发城市}」。
@@ -304,11 +313,6 @@ Step 6 (可选): workflow.editLoad / editPrepare / editApply → 用户修正（
 | `date_begin` / `date_end` | 开票日期范围 | 用户明确说"开票日期"时 |
 | `create_tm_begin` / `create_tm_end` | 录入/创建日期范围 | 用户明确说"录入日期"/"创建日期"时 |
 
-**⚠️ 数据过滤（红冲票排除）：**
-- `candidates.list` **自动过滤** `status=8` 的全额红冲发票（过滤张数在 `summary.filteredRedReversedCount` 中报告）。
-- 使用 `invoice.list` 时，**必须在进入任何后续流程前先过滤掉 `info.comm_info.pro.status == 8` 的发票**，并向用户报告："已自动排除 N 张全额红冲发票"。
-- 全额红冲发票不允许报销，**不能让红冲票进入匹配/组装环节**。
-
 关键返回字段映射见 [reim-api-reference.md](reim-api-reference.md#1-获取发票数据)。
 
 ---
@@ -347,7 +351,11 @@ Step 6 (可选): workflow.editLoad / editPrepare / editApply → 用户修正（
 
 通过 `invoice.reim.requests.list` 获取。
 
-默认入参：`{"pageNo": 1, "pageSize": 100}`。不传 `pageSize` 时 CLI 也按 100 填入。不传 `cusCreateDateEnd` 时，CLI 按东八区当天 + 1 天填入。传入时 CLI 用该日期再 + 1 天后发给接口，调用方传业务结束日本身，不要自己再加 1 天。用户没有指定结束日期、也不按发票日期收窄上界时，不要传该字段。
+默认入参：`{"pageNo": 1, "pageSize": 100}`。不传 `pageSize` 时 CLI 也按 100 填入。**发起日期窗口由 CLI 内置**，用户没指定日期时 `cusCreateDateStart` / `cusCreateDateEnd` 都不要传，也不要按开票日期自己推算：
+
+- 结束日：用户指定的日期，没指定为东八区当天；发给接口时 CLI 再 + 1 天，调用方不要自己加。
+- 开始日：结束日前 7 天；第 1 页查不到时 CLI 自动放宽到结束日前 1 个月再查一次。话费报销传 `scene="phone"`，开始日为结束日前 90 天，不再放宽。
+- 返回的 `data.query` 写明实际用的窗口；翻页时把 `data.query.cusCreateDateStart` 原样传回。
 
 ### Step 1 执行顺序与预筛选策略
 
@@ -355,9 +363,10 @@ Step 6 (可选): workflow.editLoad / editPrepare / editApply → 用户修正（
 
 | 场景 | 筛选方式 |
 |------|----------|
-| 先有发票 → 筛选事前申请 | `cusCreateDateEnd` = 最晚 invoiceDate，`cusCreateDateStart` = 最早 invoiceDate - 90天 |
-| 先有发票 → **话费报销** | `cusCreateDateEnd` = 最晚 invoiceDate，`cusCreateDateStart` = 最早 invoiceDate - **1095天（3年）**，且加 `requestname="话费"` 缩小范围（见 [reim-phone-subsidy-rules.md](reim-phone-subsidy-rules.md)） |
-| 先有事前申请 → 筛选发票 | `consumption_tm_begin` = 最早 createTime 秒时间戳 |
+| 先有发票 → 筛选事前申请 | 不传日期，用 CLI 默认窗口（最近 7 天 → 1 个月） |
+| 先有发票 → **话费报销** | 传 `scene="phone"`（最近 90 天）和 `requestname="话费"`（见 [reim-phone-subsidy-rules.md](reim-phone-subsidy-rules.md)） |
+| 先有事前申请 → 筛选发票 | `consumption_tm_begin` = 最早 `createTime` 的日期部分 |
+| 按出差流程查票 | 不再查事前申请，直接用选中的出差流程（见 Step 1A「按出差流程查票」） |
 | 并行获取 | 不做预筛选，Step 2 匹配时统一过滤 |
 
 ---
@@ -382,19 +391,20 @@ Step 6 (可选): workflow.editLoad / editPrepare / editApply → 用户修正（
 
 > `preApprovalName` 要保留：填明细「相关流程」时写成 `{preApprovalName}({preApprovalId})`。主表「事前申请流程」不赋值，保留空值。
 
-### 时间对上多条时必须问用户
+### 多条事前申请无法确认时必须问用户
 
-一张发票同时落在 2 条及以上事前申请的时间范围内，或发票没有开票日期：**停在这里**，把候选的名称和发起日期列给用户选。不要按费用类型、金额、申请人或「谁更近」自己选。用户选定前不要进入 Step 2.5 之后的填单。
+一张发票同时落在 2 条及以上事前申请的时间范围内、发票没有开票日期、或用户点名的事前申请对上多条：**停在这里，问清楚是哪一条**。不要按费用类型、金额、申请人、标题关键词或「谁更近」自己选。用户选定前不要进入 Step 2.5（`invoice.reim.workflow.resolve` 要用选定的事前申请 ID），更不能先建草稿再改。
 
-```markdown
-这张发票在时间上对上了 2 条事前申请，请选一条：
+怎么问、怎么理解用户的回答，按 [reim-matching-rules.md - 多条事前申请无法确认时，必须问用户](reim-matching-rules.md#多条事前申请无法确认时必须问用户)：
 
-| # | 发票号码 | 开票日期 | 可选事前申请 | 发起日期 |
-| --- | --- | --- | --- | --- |
-| 1 | 36901189 | 2026-07-30 | 交通费报销-后端开发111-2026-07-01 | 2026-07-01 |
-| 2 | 36901189 | 2026-07-30 | 上海出差申请-后端开发111-2026-07-20 | 2026-07-20 |
-```
+- 所有不确定的发票**一次问完**；每条候选列出名称、发起日期、状态、能对上的发票，同名时补 `requestid`
+- 给「都不是」的出口：非差旅 / 外出 → 该发票不绑定；差旅 / 外出 → 请用户给出正确的事前申请，拒绝就结束
+- 用户回答含糊（名称片段对上多条）或说「你定」→ 不替用户选，再列一次候选请用户回复序号；能按描述推出唯一一条（「最新那个」）→ 回显完整名称请用户确认一次
+- 选定后在回复开头回显一句绑定结果，然后直接往下走，不再问「确认吗」
+
+其他情况：
 
+- 按出差流程查的票 → 不做时间匹配，全部绑这条出差流程
 - 每张发票时间上都只有 1 条 → 直接绑定，不展示、不问「是否关联」
 - 时间上一条都对不上 → 非差旅 / 外出不绑定，继续填单；差旅 / 外出按 Step 4.7 让用户选
 
@@ -420,7 +430,7 @@ Step 6 (可选): workflow.editLoad / editPrepare / editApply → 用户修正（
 3. **发票费用类型匹配**：用 `expenseType` 与候选 `workFlowName` 做关键词匹配
 4. **通用兜底**：归入 workFlowName 含"日常"/"通用"/"报销"的；仍无法区分归入第一个
 
-每组独立执行 Step 3 → 3.5 → 3.6 → 4 → 5，不能省略任何字段。
+每组独立执行 Step 3 → 3.5 → 4 → 5，不能省略任何字段。
 
 ---
 
@@ -441,7 +451,7 @@ weaver-work-cli --json workflow run workflow.createForm --input-json '{"workflow
 ```
 
 > ⚠️ **AI 报销调用 `createForm` 时不传 `userQuestion`**（`workflow-create.md` 里「强烈建议每次都传」**不适用于报销**），也**不用 `workflow.createRequestDirect`**（一步发起）。
-> 传了 `userQuestion` 会让流程侧的智能填参按用户原话算 `data`：发票字段只给 `"invoice"` 占位符、承担主体会按用户口述填（与「合同联动为准」冲突），标题也不按本技能格式；同时 `historyRequestData` 不再返回。报销的 `data` 一律按本技能 Step 4 的规则自己组装。费用说明不在这份 `data` 里。
+> 传了 `userQuestion` 会让流程侧的智能填参按用户原话算 `data`：发票字段只给 `"invoice"` 占位符、承担主体会按用户口述填（与「合同联动为准」冲突），标题也不按本技能格式；同时 `historyRequestData` 不再返回。报销的 `data` 一律按本技能 Step 4 的规则自己组装。
 > 万一返回里还是带了 `data`（例如别的环节传了 `userQuestion`），**忽略它**，照常按 Step 4 组装；此时没有 `historyRequestData`，费用承担公司交给 `missingFields` 提醒。
 
 从返回里取：
@@ -456,20 +466,11 @@ weaver-work-cli --json workflow run workflow.createForm --input-json '{"workflow
 
 - `NEEDS_CLARIFICATION`（`workflow_not_exist` / `no_create_right`）→ 按 `workflow-create.md` 如实告知用户，停止本组。
 - 大表单超线（stdout 只有一句话 + `resultFile`）→ 按 `workflow-create.md` 读一次 `resultFile`，不要重跑。
-- **不再需要** `invoice.reim.form.structure`：字段清单由 `createForm` 给出。
 - **相关客户、相关项目必须先** `invoice.reim.field.search` 再写入：用户给了名称时，用本次对应字段 id + 工作流 id 模糊搜索。`match=unique` 直接填 `selected` 的 `名称(ID)`；`match=multiple` 把 `items` 列给用户选；`match=none` 请用户换更完整的名称。**不要**把未消歧的简称直接丢给 `createRequest` / `editPrepare`。已是完整 `名称(ID)`（含默认「泛微上海」、已确认的历史值）时不必再搜。见 [reim-form-fill-rules.md](reim-form-fill-rules.md#相关客户模糊搜索)。客户和项目必须在 **Step 4.5 建单前**问清，禁止空着先建草稿。
 
 ---
 
-## Step 3.5: 获取发票预填信息（`invoice.reim.row-info-batch`）
-
-> **报销建单不再调用。** 明细只写「相关发票」（及「相关流程」），`row-info-batch` 返回的日期、科目、凭证、费用说明都属于发票联动带出的列，AI 不写。只在用户单独要查某张发票的预填信息时使用。
-
-- `itineraryData`（行程单逐段明细）**暂不拆行**，仍一张发票一行，见 [reim-form-fill-rules.md](reim-form-fill-rules.md#4-行程单多段行程暂不拆行)。不要为了费用说明额外调用 `invoice.get`。
-
----
-
-## Step 3.6: 取发票对象（`invoice.browse-field.data`）
+## Step 3.5: 取发票对象（`invoice.browse-field.data`）
 
 发票字段（`EinvoiceComponent`）只接受发票对象，不接受文本或裸 ID。把本组所有**发票**的 `fid` 一次传入；凭证不传（明细「相关凭证」不赋值，由发票联动带出）：
 
@@ -491,7 +492,7 @@ weaver-work-cli --json invoice run invoice.browse-field.data --input-json '{"fid
 
 ---
 
-## Step 3.7（兜底）: 当前人员及上级（`invoice.reim.employee-superiors`）
+## Step 3.6（兜底）: 当前人员及上级（`invoice.reim.employee-superiors`）
 
 承担主体、报销人上级等人员字段通常由表单默认值带出，**默认不调用**。只有以下情况才调用一次（同一会话可复用）：
 
@@ -609,11 +610,11 @@ weaver-work-cli --json invoice run invoice.browse-field.data --input-json '{"fid
 ## Step 4.7: 差旅 / 外出明细「相关流程」必须赋值
 
 > **差旅 / 外出报销时，每一行明细「相关流程」都必须是 `{requestname}({requestid})`。任一行没有值，禁止进入 Step 5。**
-> 完整规则见 [reim-form-fill-rules.md - 差旅 / 外出明细相关流程](reim-form-fill-rules.md#差旅外出明细相关流程硬拦截)。
+> 完整规则见 [reim-form-fill-rules.md - 差旅 / 外出明细相关流程](reim-form-fill-rules.md#差旅--外出明细相关流程硬拦截)。
 
 **如何判断（满足任一）：** `workFlowName` 含「差旅」「出差」或「外出」；事前申请名称含「出差」「差旅」或「外出」；用户明确说「出差报销」「差旅报销」「外出报销」。
 
-取值：该行已绑定的事前申请 → 本次只有一条差旅 / 外出事前申请时未绑定的行也用它 → 多条未绑定则让用户指定 → 一条都没有则先列出事前申请让用户选。用户说「不填」、拒绝或不选 → **结束报销**。主表「事前申请流程 / 相关流程」不赋值，保留空值。
+取值：该行已绑定的事前申请 → 本次只有一条差旅 / 外出事前申请时未绑定的行也用它 → 多条未绑定则按 Step 2「多条事前申请无法确认时必须问用户」问清楚每行用哪条 → 一条都没有则先列出事前申请让用户选。用户说「不填」、拒绝或不选 → **结束报销**。主表「事前申请流程 / 相关流程」不赋值，保留空值。
 
 ---
 
@@ -676,8 +677,8 @@ weaver-work-cli --json workflow run workflow.createRequest --input .\reim-create
 
 ### 5.3 填写结果检查
 
-> 草稿已经落库后再查，不因此重开一张报销单。完整口径见 [reim-form-fill-rules.md - 填写结果检查](reim-form-fill-rules.md#填写结果检查)。
-> **相关客户、相关项目本应在 Step 4.5 建单前问清。** 这里只处理合同联动把已确认的客户 / 项目冲空了。明细「费用说明」「费用明细」「相关凭证」仍空时只告知「发票联动没有带出」，不要补写。
+> 草稿已经落库后再查，不因此重开一张报销单。
+> **相关客户、相关项目本应在 Step 4.5 建单前问清。** 这里只处理合同联动把已确认的客户 / 项目冲空了。明细除「相关发票」「相关流程」外的列仍空时只告知「发票联动没有带出」，不要补写。
 
 `CREATED` / `CREATED_SUBMIT_FAILED`（单子已在）时，贴完 `finalMarkdown` 后**必须**按下表检查，不能只贴草稿链接就结束。`BROWSER_FILL` 没有落库单据，跳过。`partial` / `write_uncertain` 先按原规则停住，不做这项检查。
 
@@ -687,11 +688,7 @@ weaver-work-cli --json workflow run workflow.createRequest --input .\reim-create
 | --- | --- | --- |
 | **相关客户没有值** | **任何报销单**。主表「相关客户」为空（明细的相关客户不检查、不写）。非出差且已是「泛微上海」不算 | 合同联动把建单前已确认的客户冲空了 |
 | 相关项目没填写 | 主表「相关项目」为空，且用户没有说过「不填」（明细的相关项目不检查、不写） | 合同联动把建单前已确认的项目冲空了 |
-| 明细「费用说明」 | 表单有这一列，落库后仍空 | 发票联动没有带出。只告知，不要补写，也不要让用户填，不要自己生成 |
-| 明细「费用明细」 | 表单有这一列，落库后仍空 | 发票联动没有带出。只告知，不要补写，也不要让用户填 |
-| 明细「相关凭证」 | 表单有这一列，落库后仍空 | 发票联动没有带出。只告知，不要补写，也不要让用户挂行程单 |
-| 明细「费用类型（科目）」 | 落库后仍空 | 发票联动没有带出。只告知，不要补写，也不要让用户选科目 |
-| 明细其他列（费用日期、金额、币种等） | 落库后仍空 | 发票联动没有带出。只告知，不要补写 |
+| 明细其他列（费用类型（科目）、费用说明、费用明细、相关凭证、费用日期、金额、币种等） | 表单有这一列，落库后仍空 | 发票联动没有带出。**只告知**：不补写、不自己生成、不让用户填或选，也不向用户要行程单 |
 
 表里各项都有合格值时，不要再补一句「检查通过」。有缺项时，在 `finalMarkdown` 后面一次说完。**相关客户、相关项目若本轮 Step 4.5 已经确认过，直接用已确认的 `名称(ID)` 走 Step 6 写回，不要再问。** 明细除「相关发票」「相关流程」外的列只告知，不写回。只有建单前漏问了（不应发生）才补问客户和项目：客户不接受「不填」，项目可以说「不填」。例如：
 
@@ -710,9 +707,9 @@ weaver-work-cli --json workflow run workflow.createRequest --input .\reim-create
 
 ## Step 6（可选）: 修改已创建的报销单
 
-通过 `weaver-e10-workflow` 的 `workflow.editLoad`（传 Step 5 返回的 `requestId`；Step 5.3 已经读过则可复用那次 `context`）→ `workflow.editPrepare`（`data` 写法同 Step 4，只传要改的字段）→ 用户确认 → `workflow.editApply`。详见 [`workflow-edit.md`](../../weaver-e10-workflow/references/workflow-edit.md)。明细「费用说明」「费用明细」不在修改范围内。
+通过 `weaver-e10-workflow` 的 `workflow.editLoad`（传 Step 5 返回的 `requestId`；Step 5.3 已经读过则可复用那次 `context`）→ `workflow.editPrepare`（`data` 写法同 Step 4，只传要改的字段）→ 用户确认 → `workflow.editApply`。详见 [`workflow-edit.md`](../../weaver-e10-workflow/references/workflow-edit.md)。明细只能改「相关发票」「相关流程」；只有用户明确要求改某行科目时，才按 [reim-expense-subject-rules.md](reim-expense-subject-rules.md) 改「费用类型（科目）」。
 
-Step 5.3 里用户刚给出的行程、客户名称、相关项目，就是这次修改的确认：`editPrepare` 后直接 `editApply`，不要再问「是否保存」。
+Step 5.3 里写回已确认的客户 / 项目、或用户刚给出的客户名称和相关项目，就是这次修改的确认：`editPrepare` 后直接 `editApply`，不要再问「是否保存」。
 
 - 流程已流转到不可编辑节点时 `editApply` 返回"失去操作权限"，如实转述
 - 只读字段会被拒绝（`notEditable`），如实转述，不要换字段 id 绕过
@@ -723,8 +720,7 @@ Step 5.3 里用户刚给出的行程、客户名称、相关项目，就是这
 
 **需暂停询问用户的情况：**
 - 发票列表为空 → 提示"未找到未报销的发票"，结束
-- 总部费用报销的客户或项目还没一次问齐 → 见 Step 4.4 / 4.5；**禁止先建空草稿再问，也不要改去问合同号**
-- 相关客户或相关项目还没在建单前确认 → 见 Step 4.5；**禁止先建空草稿再问**
+- 相关客户或相关项目还没在建单前一次问齐 → 见 Step 4.4 / 4.5；**禁止先建空草稿再问，也不要改去问合同号**
 - 话费报销缺少账单截图、账单构成或岗位标准 → 见 Step 4.6
 - 差旅 / 外出任一明细行「相关流程」还没有事前申请 → 见 Step 4.7；**禁止先建空草稿再补**
 - `createRequest` 返回 `NEEDS_INPUT` / `NEEDS_CONFIRMATION` 且本技能规则补不上 → 按 `workflow-create.md` 问用户