# 申请交通费用自动预估概念文档

## 功能一句话

在费用申请预览阶段，系统自动生成交通票价 mock 估算，并叠加现有住宿与补助标准，形成申请预估总费用，替代用户手动填写预估金额。

## 背景与问题

当前申请流程要求用户补充“用户预估费用”。对差旅申请来说，用户在申请阶段往往只能确认出行方式、目的地和天数，交通票价又暂时缺少正式票务接口支持，因此让用户手填金额会降低流程顺畅度。

本期先用系统估算补齐申请金额：

- 交通费用：按火车、飞机、轮船三类 mock 票价生成稳定估算。
- 住宿与补助：前端申请预览继续调用现有差旅规则测算，复用住宿上限和补助标准。
- 后端对话：当没有前端预览上下文时，用同口径的兜底估算生成金额，避免选择交通方式后继续追问金额。

## 目标与非目标

目标：

- 申请预览不再要求用户手动填写预估费用。
- 用户选择火车、飞机或轮船后，系统能生成交通费用估算。
- 预估总费用 = mock 交通费 + 住宿标准小计 + 补助标准小计。
- 预览、提交文本和后端对话统一展示“系统预估费用”。
- 保留用户明确输入金额时的兼容能力，不破坏历史提交链路。

非目标：

- 本期不接入真实机票、火车票、船票接口。
- 本期不做票价实时波动、余票、舱等、席别、折扣和路线中转算法。
- 本期不把 mock 估算作为最终报销金额，报销阶段仍应结合真实票据复核。

## 用户与场景

主要用户：

- 员工：在“申请/事前审批”环节快速发起差旅费用申请。
- 财务/审批人：查看申请金额是否由系统按标准测算生成。

典型场景：

1. 用户输入“去上海出差 3 天，火车”。
2. 系统识别地点、天数、出行方式。
3. 系统 mock 生成火车往返票价。
4. 系统调用现有差旅测算拿到住宿与补助小计。
5. 系统在申请预览中展示系统预估费用，并允许进入确认提交。

## 功能能力

输入：

- 地点：用于差旅规则匹配和交通 mock 城市层级判断。
- 天数：用于住宿与补助小计。
- 出行方式：火车、飞机、轮船。
- 职级：沿用现有差旅测算接口的标准匹配入参。

输出：

- 交通费用口径：说明当前是 mock 票价估算，报销阶段按真实票据复核。
- 规则测算参考：展示交通、住宿、补助拆分与合计。
- 系统预估费用：写入申请金额字段，用于后续申请提交。
- 估算来源字段：记录 mock 交通估算和规则测算结果，便于后续审计解释。

边界：

- 缺少地点或天数时，仍不能完成住宿与补助测算，需要继续补齐基础字段。
- 缺少出行方式时，仍需用户选择火车、飞机或轮船。
- 后端纯对话流程没有前端规则测算结果时，使用保守的 mock 住宿/补助兜底。

## 方案设计

前端：

- 新增申请估算工具模块，集中维护交通 mock 票价、金额格式化和总额合成。
- `expenseApplicationPreview` 在差旅规则测算返回后，将交通 mock 金额叠加到住宿与补助小计。
- 将 `amount` 字段改为“系统预估费用”，并设为非手动必填字段。
- 申请提交文本使用系统生成的金额。

后端：

- 新增申请系统预估服务模块，避免继续向已经超过 800 行的 `user_agent_application.py` 堆业务算法。
- 后端对话在基础字段和出行方式齐全时自动补 `amount`、`transport_policy`、`policy_estimate`。
- 缺失字段追问只保留基础字段和出行方式，不再追问预估金额。

数据与接口：

- 不新增数据库字段。
- 不新增外部接口。
- 申请详情仍通过现有 `risk_flags_json.application_detail` 保存展示字段。

## 算法与公式

交通费用采用稳定 mock：

$$
transport\_amount = round\_10(base(mode, location) \times 2)
$$

其中 `mode` 为火车、飞机、轮船，`location` 用于判断一线/远途/沿海等粗粒度场景，默认按往返估算。

总费用：

$$
estimated\_total = transport\_amount + lodging\_amount + allowance\_amount
$$

前端的 `lodging_amount` 和 `allowance_amount` 来自现有差旅规则测算结果；后端兜底时按 mock 标准生成。

## 测试方案

- 前端单测：验证交通 mock、规则测算合计、行标签和提交文本。
- 后端单测：验证选择交通方式后不再追问金额，而是直接生成预览。
- 编排流测试：验证申请会话从补充出行方式直接进入确认，再提交成功。
- 回归测试：用户明确输入金额时仍能提交，并保留兼容链路。

## 指标与验收

- 用户选择出行方式后，系统不再提示“用户预估费用”缺失。
- 申请预览中出现“系统预估费用”。
- 规则测算参考包含交通、住宿、补助三项拆分。
- 前端定向测试和后端申请流程测试通过。

## 风险与开放问题

- mock 票价不代表真实票价，只适合作为申请阶段预算参考。
- 后端兜底住宿/补助不能完全替代规则中心，前端有规则测算结果时应优先使用规则中心。
- 后续接入真实票务接口后，应替换交通 mock 模块，不改变申请预览和提交的数据契约。
