Files
X-Financial/document/development/申请交通费用自动预估/CONCEPT.md
caoxiaozhu 92444e7eae feat: 扩展风险规则体系、审批动态路由与预算中心列表化改造
- 新增 25+ 条风险规则(预算/报销/申请/通用类),完善风险规则模拟与反馈发布机制
- 引入费用审批动态路由、平台风险分级、预审与风险阶段管理
- 预算中心列表化改造,优化票据夹仪表盘与数字员工工作看板
- 新增 Hermes 风险线索收集器、Agent 链路追踪中心
- 扩展数字员工能力库(18 个领域 Skill)与交通费用自动预估
- 完善报销申请快速预览、权限控制与前端测试覆盖
2026-06-01 17:07:14 +08:00

128 lines
5.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 申请交通费用自动预估概念文档
## 功能一句话
在费用申请预览阶段,系统自动生成交通票价 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 模块,不改变申请预览和提交的数据契约。