报销管理系统产品系统Vibe Coding

立项原因
1. 业务痛点（为什么要做）
- 报销依赖手工 ：员工填 Excel + 纸质单据 + 微信/邮件流转，单据易丢失、状态无法追踪，"我的单子到哪一步了"全靠口头问
- 审批不透明 ：三级审批（部门→总经理→财务）无线上留痕，审批意见散落在聊天记录里，事后无法回溯
- 打款手工录入 ：财务确认打款后，还要再登录 1889buy 财务系统 重复录入一遍 资金账号、金额、备注，重复劳动且容易抄错
- 发票与非发票混打 ：两种打款方式不区分，对账时分不清哪笔走的支付宝、哪笔走的银行转账
- 无统一台账 ：员工、部门主管、财务各看各的 Excel，数据口径不一致，月度汇总靠人工拼接
2. 项目目标（做了什么）
- 全流程线上化 ：员工在线填单→提交→三级审批→财务审核→打款确认，每一步状态可查、日志可追
- 审批电子化 ：每级审批意见、操作人、时间全部落库，支持配置角色和"同一审批人自动跳过"
- 打款自动化 ：确认打款时自动拉取 1889buy 资金账号列表，财务选择账号后一键同步到外部财务系统， 省掉手工二次录入
- 发票/非发票分类型管理 ：两种打款独立确认、独立记录资金账号，对账清晰
- 移动端支持 ：h5 端可随时审批、查看进度，不依赖 PC
3. 预期收益
- 效率 ：报销单从提交到打款周期从平均 5-7 天压缩到 1-2 天
- 准确 ：外部财务系统打款流水自动同步，消除二次录入错误
- 透明 ：员工可实时查进度，减少"我的单子到哪了"的反复询问
- 可审计 ：每笔报销的审批轨迹、打款流水、外部同步状态全部留痕，月度对账从人工拼接变成查表即可

1. 立项背景和目标
公司原有报销依赖 Excel 手工填写+邮件流转，审批无状态追踪、发票与非发票打款混在一起无法区分，财务打款后还需手动在 1889buy 财务系统重复录入，重复劳动且容易出错。项目目标是建设一套覆盖报销全生命周期的管理系统，实现审批电子化、打款自动化、与外部财务系统实时同步。

2. 核心功能模块
报销单管理：草稿/提交/撤销/重新申请，发票与非发票项区分录入
三级审批流程：部门主管→总经理→财务审核，每级可配置角色，支持自动跳过同一审批人
确认打款：发票/非发票分类型独立确认，打款时必须选择资金账号（从 1889buy 实时拉取），非发票还需选择打款方式（微信/支付宝/银行）
财务接口同步：确认打款后自动调用外部 1889buy 资金账号接口，将打款流水同步到外部财务系统
接口调用流水：每次调用外部财务接口无论成功失败都落库，用于对账和问题排查
3. 业务流程
员工登录→创建报销单→提交→部门审批→总经理审批→财务审核→财务进入"待打款"列表→选择打款类型（发票/非发票）→选择资金账号→确认打款→本地更新报销状态+写审批日志+调外部财务接口+写接口流水→全部打款完成后报销单状态变为"已打款"。

前后端分离架构：
后端：.NET 8 Web API，分层结构（Controller→Service→Repository），SqlSugar ORM + MySQL，自定义 Redis Token 认证（handler 从 Redis 读取 CurrentUserDto 构造 Claims）
前端：Vue 3.5 + TypeScript + Element Plus 2.14 + Pinia 3 + Vue Router 5，PC 端和 H5 移动端共用一套 API
外部集成：通过 HttpClient 调用 1889buy 财务系统 asmx 接口，资金账号列表用 GET，打款同步用 JSON body + text/plain Content-Type
2. 我负责的模块和结果
报销审批核心流程：三级审批状态机实现，含自动跳过同一审批人逻辑，覆盖员工端提交、审批端处理、财务端审核，累计支持 50+ 日活用户
资金账号打款功能：从 1889buy 拉取资金账号列表，打款时前端下拉选择、后端校验必选，发票/非发票独立确认，累计对接 52 个外部资金账号
财务接口流水落库：新建 reimburse_fund_log 表，每次外部调用无论成功失败均独立连接写入，不受打款主事务回滚影响，已记录 100+ 条调用流水
3. 遇到的难点和解决方案
难点一：外部 1889buy 接口文档与实际不符。文档写 Body 格式是 x-www-form-urlencoded，实测 JSON+text/plain 才能被正确解析（form 方式参数解析不到返回"远程超时"，msgpack 方式参数校验直接被跳过）。方案：用 Postman 逐轮对照实验（换 Content-Type、换 body 格式、换 opid/agentid 值），定位到 JSON body + text/plain