weaver-work-cli 0.1.29 → 0.1.32

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

@@ -1,13 +1,13 @@
 # 发票与事前申请匹配规则
 
-本文档定义发票与事前申请流程的智能匹配逻辑。匹配的目的是将每张发票绑定到最合适的事前申请，为后续填单提供绑定关系数据。
+本文档定义发票与事前申请怎么关联。只比较两边的日期。一张发票在时间上只落在一条事前申请里就直接绑定；落在多条里，或日期缺失对不上，列给用户选。不用费用类型、金额、申请人或标题关键词决定绑哪一条。
 
 ---
 
 ## 核心时间关系
 
-> **事前申请日期一定在开票日期之前。**
-> 即：`事前申请.createTime ≤ 发票.invoiceDate`
+> **事前申请发起日期不晚于开票日期。**
+> 即：`事前申请.createTime 的日期部分 ≤ 发票.invoiceDate`。**同一天算对上**，默认允许绑定。
 
 这是匹配和预筛选的基础约束。
 
@@ -22,249 +22,108 @@
 2. **预筛选**：利用发票日期缩小事前申请查询范围
   - 提取发票数据中最早和最晚的 `invoiceDate`
   - 事前申请日期必然 ≤ 开票日期，因此：
-    - `cusCreateDateEnd` = 最晚 invoiceDate
+    - `cusCreateDateEnd` = 最晚 invoiceDate（CLI 会再 + 1 天后发给接口；不按开票日收窄上界时不要传，交给东八区当天 + 1 天）
     - `cusCreateDateStart` = 最早 invoiceDate 往前推 90 天
 3. 调用 `invoice.reim.requests.list`（带日期筛选条件）获取候选列表
-4. 执行匹配算法，输出绑定关系
+4. 按下面的时间规则关联；不确定时先问用户，再往下填单
 
 ### 场景B：先有事前申请 → 筛选并匹配发票
 
 1. 已获取事前申请列表（含 `requestname`, `createTime`, `creatorId` 等）
-2. **预筛选**：利用事前申请日期缩小发票查询范围（使用**开票日期** `date_begin` / `date_end`）
+2. **预筛选**：利用事前申请日期缩小发票查询范围（使用**消费日期** `consumption_tm_begin` / `consumption_tm_end`）
   - 提取事前申请列表中最早的 `createTime`
-  - 开票日期必然 ≥ 事前申请日期，因此：
-    - `date_begin` = 最早 createTime 对应的秒级时间戳（00:00:00）
-    - `date_end` = 当前日期 23:59:59 的秒级时间戳
-3. 调用 `invoice.list`（带开票日期筛选条件）获取候选列表
-4. 执行匹配算法，输出绑定关系
+  - 消费日期必然 ≥ 事前申请日期，因此：
+    - `consumption_tm_begin` = 最早 createTime 对应的秒级时间戳（00:00:00）
+    - `consumption_tm_end` = 当前日期 23:59:59 的秒级时间戳
+3. 调用 `invoice.list`（带消费日期筛选条件）获取候选列表
+4. 按下面的时间规则关联；不确定时先问用户，再往下填单
 
 ### 场景C：并行获取
 
 两者并行获取时不做预筛选，获取全量数据后在匹配阶段统一过滤。
 
-三种场景使用相同的匹配规则，仅数据获取和预筛选策略不同。
+三种场景使用同一套时间规则，只是取数和预筛选不同。
 
 ---
 
-## 匹配维度（按优先级排序）
+## 关联规则（只看时间）
 
-### 维度1：费用类型匹配（权重最高）
+比较日期，不比较钟点。事前申请发起日取 `createTime` 的日期部分，发票日期取 `invoiceDate`。
 
-根据发票的 `expenseType` 或 `consumeContent` 与事前申请的 `requestname` / `requestnametitle` 进行费用类型关联。
+> **同一天视为对上，默认允许绑定。** 事前申请发起日与开票日期是同一天时（例如事前申请 `2026-10-27 17:30` 发起，发票开票日期 `2026-10-27`），不要因为发票没有钟点、「无法判断先后」就不绑定或改成问用户。
 
+一张发票算进某条事前申请，必须同时满足：
 
-| 发票线索                                                  | 匹配的事前申请关键词                    |
-| ----------------------------------------------------- | ----------------------------- |
-| expenseType 含"交通"/"市内交通" 或 sellerName 含"滴滴"/"曹操"/"高德" | requestname 含"交通"/"差旅"        |
-| expenseType 含"住宿" 或 sellerName 含"酒店"/"宾馆"/"民宿"        | requestname 含"住宿"/"差旅"        |
-| expenseType 含"餐饮" 或 sellerName 含"餐饮"/"饭店"/"美团"        | requestname 含"餐饮"/"招待"/"业务招待" |
-| expenseType 含"办公" 或 consumeContent 含"办公用品"/"文具"       | requestname 含"办公"/"采购"        |
-| expenseType 含"通讯" 或 sellerName 含"中国移动"/"中国联通"/"中国电信"  | requestname 含"通讯"/"话费"        |
+- `invoiceDate` ≥ 事前申请发起日（含同一天）
+- `invoiceDate` ≤ 事前申请发起日 + 90 天
 
+**话费报销**没有 90 天上限：只要 `invoiceDate` ≥ 事前申请发起日（含同一天）即可。查询仍按 [reim-phone-subsidy-rules.md](reim-phone-subsidy-rules.md) 回溯 3 年。关联时不看标题里有没有「话费」。
 
-### 维度2：时间范围匹配
+每张发票单独判断：
 
-> **前提：事前申请日期一定在开票日期之前（或同日）。**
+| 时间上能对上的事前申请 | 怎么处理 |
+| --- | --- |
+| 正好 1 条 | 直接绑定。不问「要不要关联」，也不用费用类型、金额、申请人或谁更近去改绑 |
+| 2 条及以上 | 不确定。把这几条的名称和发起日期列出来，让用户选一条。选定前不要往下填「相关流程」 |
+| 0 条 | 这张发票不绑定。非差旅 / 外出可以继续报销。差旅 / 外出仍按 [reim-workflow.md](reim-workflow.md) Step 4.7 让用户选事前申请 |
+| 发票没有 `invoiceDate` | 不确定。列出本次查到的事前申请，让用户选 |
 
-```
-判定规则：
-  事前申请发起日期 = createTime 的日期部分
-  发票日期 = invoiceDate
-  
-  硬约束：invoiceDate >= createTime（发票日期不早于事前申请日期）
-  → 不满足此条件的直接排除，不参与评分
-  
-  匹配条件（满足硬约束后）：
-  invoiceDate 在 [createTime, createTime + 90天] 范围内
-  
-  更精确的匹配（如 requestnametitle 中包含日期范围信息）：
-  invoiceDate 在 [起始日期, 结束日期 + 7天] 范围内
-  
-  时间距离越近，匹配分越高：
-  - invoiceDate 在 createTime 后 7 天内 → 加满分
-  - invoiceDate 在 createTime 后 7~30 天 → 加大部分分
-  - invoiceDate 在 createTime 后 30~90 天 → 加少量分
-
-  **话费报销例外**：话费补贴事前申请可能在审批通过后长期有效，
-  不受 90 天窗口限制。只要 invoiceDate >= createTime 即可匹配，
-  不因时间距离远而降分。详见 reim-phone-subsidy-rules.md。
-```
-
-### 维度3：金额校验
-
-发票金额不应大幅超出事前申请中的预算金额。
-
-```
-判定规则：
-  从 requestnametitle 中提取"报销总金额"字段
-  如果能提取到金额：invoice.amount <= 预算金额 * 1.2（允许20%浮动）
-  如果无法提取金额：跳过此维度
-```
-
-### 维度4：部门/人员匹配
+一条事前申请可以绑多张发票。一张发票只能绑一条。多张发票都不确定、候选又是同一批时，一次问完：用户可以说「都用某一条」，但这一条必须落在该发票的时间候选里，否则指出哪张对不上，再问。
 
-发票所属人员应与事前申请的发起人一致或同部门。
-
-```
-判定规则：
-  当前用户 = 事前申请.creatorId → 自动满足
-  不同用户时需额外确认
-```
+不要打分，不要看置信度，不要因为标题含「交通」「差旅」就选中某一条。
 
 ---
 
-## 匹配算法
-
-### 计分规则
-
-
-| 维度     | 匹配                                 | 得分   |
-| ------ | ---------------------------------- | ---- |
-| 费用类型匹配 | 完全匹配                               | +40  |
-| 费用类型匹配 | 部分匹配（同大类）                          | +20  |
-| 时间范围匹配 | invoiceDate 在 createTime 后 7 天内    | +30  |
-| 时间范围匹配 | invoiceDate 在 createTime 后 7~30 天  | +20  |
-| 时间范围匹配 | invoiceDate 在 createTime 后 30~90 天 | +10  |
-| 时间范围匹配 | invoiceDate < createTime（不满足硬约束）   | 直接排除 |
-| 金额校验   | 不超预算                               | +20  |
-| 金额校验   | 超预算20%以内                           | +10  |
-| 部门匹配   | 同一人                                | +10  |
-
+## 怎么问用户
 
-### 置信度等级
+只在不确定时暂停。列出发票号码、开票日期，以及每条候选的 `requestname` 和发起日期，让用户按序号或名称选。
 
+```markdown
+这张发票在时间上对上了 2 条事前申请，请选一条：
 
-| 总分    | 置信度    | 处理方式            |
-| ----- | ------ | --------------- |
-| ≥ 70  | high   | 直接绑定，展示给用户确认    |
-| 40-69 | medium | 建议绑定，高亮提示"建议核实" |
-| < 40  | low    | 不自动绑定，放入未匹配列表   |
-
-
----
-
-## 匹配约束
+| # | 发票号码 | 开票日期 | 可选事前申请 | 发起日期 |
+| --- | --- | --- | --- | --- |
+| 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. **一对多关系**：一条事前申请可绑定多张发票，但一张发票只能绑定一条事前申请
-2. **不强制匹配**：不确定时宁可不匹配，让用户手动选择
-3. **优先级冲突**：当一张发票可匹配多条事前申请时，选择总分最高的；分数相同时选时间最接近的
-4. **无事前申请**：发票可以不绑定事前申请，直接用于报销（`preApprovalId` 为 null）
+用户选定后，用 `{requestname}({requestid})` 写入对应明细「相关流程」。
 
 ---
 
-## 匹配输出格式
+## 关联结果
 
 ```json
 {
   "matchResults": [
     {
       "invoiceId": "1295366637717012482",
-      "invoiceInfo": "滴滴出行 ¥108.2 2024-12-30",
+      "invoiceInfo": "滴滴出行 ¥108.2 2026-07-30",
       "preApprovalId": "1298294241967177729",
       "preApprovalWorkflowId": "1181057526276915214",
-      "preApprovalName": "交通费报销-后端开发111-2026-07-31",
-      "matchConfidence": "high",
-      "matchScore": 85,
-      "matchReasons": ["费用类型匹配：交通费", "时间范围匹配", "同一申请人"]
+      "preApprovalName": "交通费报销-后端开发111-2026-07-25",
+      "matchReason": "开票日期 2026-07-30 只落在 2026-07-25 这一条的 90 天内"
     }
   ],
-  "unmatchedInvoices": [
+  "pendingChoice": [
     {
       "invoiceId": "INV003",
-      "invoiceInfo": "文具 ¥35.00 2026-07-28",
-      "reason": "未找到匹配的事前申请"
+      "invoiceDate": "2026-07-30",
+      "candidates": [
+        {"requestId": "REQ001", "requestName": "交通费报销-后端开发111-2026-07-01", "createTime": "2026-07-01"},
+        {"requestId": "REQ002", "requestName": "上海出差申请-后端开发111-2026-07-20", "createTime": "2026-07-20"}
+      ]
     }
   ],
-  "unmatchedApprovals": [
+  "unmatchedInvoices": [
     {
-      "requestId": "REQ003",
-      "requestName": "采购申请-XXX",
-      "reason": "无匹配的发票"
+      "invoiceId": "INV004",
+      "invoiceInfo": "文具 ¥35.00 2026-07-28",
+      "reason": "开票日期没有落在任何事前申请的时间范围内"
     }
   ]
 }
 ```
 
----
-
-## 匹配流程伪代码
-
-```
-function matchInvoicesWithApprovals(invoices, approvals):
-    results = []
-    unmatchedInvoices = []
-    
-    for each invoice in invoices:
-        bestMatch = null
-        bestScore = 0
-        
-        for each approval in approvals:
-            score = 0
-            reasons = []
-            
-            // 维度1：费用类型
-            if matchExpenseType(invoice, approval):
-                score += 40
-                reasons.push("费用类型匹配")
-            elif partialMatchExpenseType(invoice, approval):
-                score += 20
-                reasons.push("费用类型部分匹配")
-            
-            // 维度2：时间范围
-            if invoiceDateInRange(invoice.invoiceDate, approval):
-                score += 30
-                reasons.push("时间范围匹配")
-            elif invoiceDateInFloatRange(invoice.invoiceDate, approval, 3):
-                score += 15
-                reasons.push("时间范围浮动匹配")
-            
-            // 维度3：金额校验
-            budgetAmount = extractBudget(approval.requestnametitle)
-            if budgetAmount and invoice.amount <= budgetAmount * 1.2:
-                score += 20
-                reasons.push("金额校验通过")
-            elif budgetAmount and invoice.amount <= budgetAmount * 1.5:
-                score += 10
-                reasons.push("金额略超预算")
-            
-            // 维度4：同一申请人
-            if currentUserId == approval.creatorId:
-                score += 10
-                reasons.push("同一申请人")
-            
-            if score > bestScore:
-                bestScore = score
-                bestMatch = {approval, score, reasons}
-        
-        if bestScore >= 40:
-            confidence = "high" if bestScore >= 70 else "medium"
-            results.push({invoice, bestMatch, confidence})
-        else:
-            unmatchedInvoices.push(invoice)
-    
-    return {results, unmatchedInvoices}
-```
-
----
-
-## 从 requestnametitle 提取信息
-
-事前申请的 `requestnametitle` 格式通常为：
-
-```
-交通费报销-后端开发111-2026-07-31 (相关客户:XXX, 相关项目:XXX, 承担主体: XXX, 流程编号:Weaver-FYBX202607000069, 报销总金额:14.47 , 费用承担公司:XXX)
-```
-
-可提取的信息：
-
-
-| 信息    | 提取方式                 | 用途     |
-| ----- | -------------------- | ------ |
-| 费用类型  | 标题开头（如"交通费报销"→"交通费"） | 费用类型匹配 |
-| 申请人   | 标题第二段（如"后端开发111"）    | 人员校验   |
-| 日期    | 标题第三段（如"2026-07-31"） | 时间匹配   |
-| 相关客户  | 非出差：固定填 `"100504500000311504"`（泛微上海）；**出差流程：必须由用户提供具体客户，未提供不允许报销** | 填单时使用  |
-| 相关项目  | 括号内"相关项目:"后面的值       | 填单时使用  |
-| 报销总金额 | 括号内"报销总金额:"后面的数字     | 金额校验   |
-| 流程编号  | 括号内"流程编号:"后面的值       | 参考信息   |
+`pendingChoice` 非空时先问用户，不要把这些发票当成已绑定。
 

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

@@ -86,7 +86,7 @@
 | 明细里 `createForm` 返回的可写金额字段（申请金额等；实报金额、人民币金额不可写，不传） | 填本规范算出的**实报金额**，不要填发票原价 |
 | 主表金额字段（仅当出现在 `createForm` 的 `fields` 里时才传） | 各行实报金额之和 |
 | 费用类型（科目） | 通讯科目，写成 `"{科目名称}(100502270000000010)"`（`invoice.reim.row-info` 的 `subjectId` 已是通讯类时可直接用，名称取 `subjectName`） |
-| 费用说明 | 写清所属月份、可报销账单金额、岗位上限、实报金额，例如 `2026-08话费 账单280 上限200 实报200`（禁止 `*` 号） |
+| 费用说明 | **不传。** 由「相关发票」联动带出，不要写成月份、账单或实报金额说明 |
 
 > 这是「金额一律填发票 `amount`」的**唯一覆盖规则**，只适用于本规范命中的话费报销。发票原始 `amount` 仍须原样保留在上下文中，不得改写发票数据本身。
 
@@ -109,7 +109,7 @@
 
 ```
 cusCreateDateStart = 最早发票 invoiceDate 往前推 1095 天（3 年）
-cusCreateDateEnd   = 最晚发票 invoiceDate
+cusCreateDateEnd   = 最晚发票 invoiceDate（CLI 会再 + 1 天后发给接口）
 ```
 
 示例（发票日期 2026-09-20）：
@@ -117,7 +117,7 @@ cusCreateDateEnd   = 最晚发票 invoiceDate
 ```json
 {
   "pageNo": 1,
-  "pageSize": 20,
+  "pageSize": 100,
   "requestname": "话费",
   "cusCreateDateStart": "2023-09-20",
   "cusCreateDateEnd": "2026-09-20"
@@ -130,10 +130,10 @@ cusCreateDateEnd   = 最晚发票 invoiceDate
 
 默认匹配规则要求 `invoiceDate 在 [createTime, createTime + 90天]`。**话费报销不适用此窗口**，因为一次审批可覆盖数年的月度报销。
 
-话费报销匹配时：
-- **取消 90 天窗口限制**：只要 `invoiceDate >= createTime`（发票日期不早于事前申请日期）即可匹配
-- 费用类型匹配仍然生效：`requestname` 含「话费」「通讯」即为匹配
-- 金额校验仍然生效（按月度上限核算后的实报金额与事前申请预算比较）
+话费报销关联时：
+- **取消 90 天窗口限制**：只要 `invoiceDate >= createTime 的日期部分`（发票日期不早于事前申请发起日期，同一天也算）即可进入候选
+- 查询时用 `requestname="话费"` 缩小列表；关联本身不再看标题、费用类型或金额
+- 时间上只剩 1 条 → 直接绑定。还剩多条 → 把名称和发起日期列给用户选
 
 ---