128 lines
5.3 KiB
Markdown
128 lines
5.3 KiB
Markdown
|
# 申请交通费用自动预估概念文档
|
|||
|
|
|
|||
|
|
## 功能一句话
|
|||
|
|
|
|||
|
|
在费用申请预览阶段，系统自动生成交通票价 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 模块，不改变申请预览和提交的数据契约。
|