一、立项背景与目标
客户原线下请款审批混乱、账务口径不一,多团费用核算依赖人工Excel,频现金额错算与状态不同步。本项目构建覆盖团单、调度、付款、审批、资源管理五大核心模块的资金调度管理系统,实现请款流程线上化、账务中心化、报表自动化。我负责后端架构设计、数据库建模、核心引擎开发与SQL调优。
二、核心功能模块
1、团单管理:客户信息、团号、行程、人数、发/散团日期、负责人等全生命周期CRUD,是串联调度、请款、核算的业务主线。
2、调度安排:10种费用项(团款/酒店/用餐/门票/用车/导游/地接社/交通票/其他支出/代付)统一建模为"主表+9子表"结构,direction区分收支、金额字段复用,支持录入、编辑、批量保存、状态联动,任意调整自动触发重算。
3、请款审批:成本付款(向供应商)与收款确认(向客户)两类审批流复用同一自研引擎;基于状态机实现模板/实例/任务三层模型,通过回调抽象支持多业务类型。
4、单团核算:自动按团汇总收入、成本、毛利、毛利率;所有金额变更收敛到统一计算工具类,公式 total-progress-requested 覆盖收支两侧;支持Word导出供财务归档。
5、资源管理:酒店、车队、餐厅、票务、地接社等供应商资源的独立CRUD与查询,供调度、请款关联选用。
三、业务流程与功能路径
1、请款发起:提交请款→校验关联团单/调度/资源数据→按direction生成请款单(支出走成本付款、收入走收款确认)→冻结"申请中"金额。
2、审批流转:请款单匹配审批模板→生成审批实例→拆分逐级任务→状态机驱动同意/驳回/转办→全部任务结束触发onApproved/onRejected回调。
3、账务处理:onApproved先释放冻结金额,再将批准实付累加进对应账务字段,保证部分审批时未批准部分不被锁死;工具类按total-progress-requested统一重算。
4、负数调账:团后少付/多付调整需同步放开公式截断、符号校验、回调负向三个环节支持负数调账,调整后自动触发关联重算。
5、报表导出:单团核算导出→内存聚合主表+9子表全部数据→填充原生XML模板生成Word
一、整体架构与设计思路
系统采用前后端分离架构:前端React18+TypeScript+Vite,后端SpringBoot+MyBatis Plus,数据层MySQL+Redis。
后端按团单/调度/付款/审批/资源五大业务模块划分,统一RESTful接口对外。
设计思路:审批引擎化(状态机模板/实例/任务三层模型+回调抽象)、费用统一建模(主表+9子表、direction区分收支)、账务中心化(金额变更收敛到统一计算工具类),让流程与业务解耦、账目口径唯一。
二、我负责的模块与结果
独立负责后端架构设计、40余张数据库表建模及五大模块后端开发:
1、自研审批回调引擎:一套引擎复用成本付款/收款确认两类审批流,新业务类型接入零新增引擎代码;
2、金额计算器与状态机:统一公式total-progress-requested覆盖收支两侧,项目周期内账目零差错;
3、调度统一建模:10种费用类型复用金额字段,任意调整自动触发重算,含负数调账;
4、性能优化:MySQL索引调优,核心报表接口由秒级响应降至500ms内;Redis缓存审批模板与字典,热点接口DB压力明显下降;
5、核心逻辑单元测试覆盖金额计算与状态流转关键路径。
三、我遇到的难点、坑与解决方案
1、负数调账状态机:团后少付/多付调整需同时放开公式截断、符号校验、回调负向三个环节,漏一个即调账失败;方案:设计三环节联动的负数支持机制,并用回归单元测试锁定。
2、部分审批金额一致性:早期只累加批准金额未释放"申请中"冻结额,导致未批准部分被锁死;方案:改为"先释放冻结、再累加实付"两段式事务逻辑,保证账务一致。
3、跨9表报表聚合:单团核算Word导出需内存聚合主表+9子表,且第三方组件存在授权问题;方案:改用原生XML模板渲染,规避授权风险并成功交付导出功能。