龙阿龙的编程日记
作品软件定制二次开发RSS联系我
返回作品

接单派单系统

创建于 2025 年 1 月 18 日

标签
  • Java
  • Spring Boot 2.7.18
  • MyBatis-Plus
  • MyBatis-Plus-Join
  • MySQL
  • Redis
  • Quartz
  • Redisson
  • Flowable
  • Vue 3
  • Element Plus
  • Vite
  • Pinia
  • TypeScript

项目介绍

这是一个基于芋道 RuoYi-Vue-Pro v2.4.0 二次开发的影视接单派单系统（毕业设计项目，目录 20250118-接单系统，配套论文《基于芋道框架的影视接单系统设计与开发》）。业务场景是”影视制作公司对外接单、对内派单”：发单员把公司接到的视频拍摄、剪辑、制作任务发布成订单，接单员（设计师/剪辑师）缴纳保证金后接单，交付成果后验收结算，出现分歧时走撤单、赔付协商与客服仲裁流程。项目由三部分构成：后端 ruoyi-vue-pro-2.4.0接单系统（yudao-server 单体应用 + 自定义业务模块 yudao-module-ord）、管理后台前端 yudao-ui-admin-vue3（Vue 3 + Element Plus，src/views/ord 按角色组织页面），以及根目录 jiedan.sql 全量数据库脚本（含 ord_ 系列业务表、订单分类种子数据与真实测试账号）。

从 SQL 可以还原真实的开发过程：infra_codegen_table 中记录了 2025-01-19 起用芋道代码生成器生成 ord_order_info、ord_order_type 等表对应的增删改查代码，infra_api_error_log 里则躺着 2025-01-20 到 2025-05-10 的调试报错——比如框架多租户自动追加 tenant_id 条件而表里没有该列、ord_order_type 缺 create_time、ord_balance_record 缺 order_no 等 BadSqlGrammarException，可以看到项目是”边写代码边补表结构”迭代完成的。数据侧 ord_user 中有客服 kf01、接单 jd01 等测试账号，ord_order_info 保留了佣金 1 元、保证金 1 元、服务费 0.08 元的完整测试订单 SPJJ2025051005591895946251608，从”扣除保证金→反还保证金→提现”的资金流水能看出一条订单的完整资金旅程。

项目架构

系统沿用芋道前后端分离与多租户结构，业务全部收敛在自定义模块 yudao-module-ord（api 与 biz 两个子模块），通过 PayOrderApi 与 yudao-module-pay 解耦充值支付能力：

模块技术栈说明
yudao-module-ordSpring Boot 2.7.18、MyBatis-Plus 3.5.9、mybatis-plus-join 1.4.13、Hutool、Quartz业务核心：controller/admin 下按角色拆分发单员（creator）、接单员（handle）、客服仲裁（order-service）、撤单管理（order-cancel）、撤单审核（audit-cancel）、接单大厅（order-center）、验收（check-and-accept）、超管（admin）等一组控制器；service/balanceRecord 统一资金结算；job/OrderStatusJob 是自动完结定时任务
yudao-serverSpring Boot、Spring MVC单体启动入口，端口 48080，/admin-api 管理端接口
yudao-ui-admin-vue3Vue 3.5、Element Plus 2.9、Vite 5、Pinia、TypeScript管理后台，src/views/ord 按角色分组：admin（仲裁、提现审核、订单）、creator（发单、撤单审核、验收）、handle（接单、撤单、完结、充值、提现、资金明细）、orderCenter（接单大厅）、ordertype（订单分类树）
jiedan.sqlMySQL全量库脚本，业务表：ord_order_info（订单）、ord_order_type（订单分类）、ord_user（余额账户）、ord_balance_record（资金流水）、ord_order_take（提现单）、ord_order_recharge（充值单）、ord_check_and_accept 与 ord_check_and_accept_details（验收及附件）

订单分类 ord_order_type 是核心基础数据：顶级分类”视频拍摄 SPPS / 视频制作 SPZZ / 视频剪辑 SPJJ”各配一个订单前缀，下面挂”淘宝拍摄、抖音拍摄、婚礼视频、课件剪辑、录像剪辑”等二级分类；发单时 OrderTypeServiceImpl.getOrderPre 会递归向上找到顶级分类取前缀，再由 OrderUtil.generateOrderNumber 生成”前缀 + yyyyMMddHHmmssSSS 时间戳 + 8 位随机数”的订单号，例如 SPJJ2025051005591895946251608。订单主表 ord_order_info 字段非常完整：佣金 commission、保证金 deposit、交稿期限 submit_time_limit、接单人 handler_user_id、验收结果、撤单原因/处理结果、赔付金额 pay_to_publish_user（付发单人）/ pay_to_handle_user（付接单人）、客服介入理由与处理结果、渠道 channel / 渠道订单号 channel_no / 渠道价格，还预留了客户联系方式（custom、custom_phone、custom_wx）。

核心功能

九态订单状态机。 OrderStatusEnum 定义了完整生命周期：未接单（000）→ 已接单（100）→ 验收中（600）→ 已验收（700），横向还有撤销中（200）→ 已撤销（300）、仲裁中（400）→ 已仲裁（500）/ 仲裁拒绝（550）。状态迁移散落在各控制器中并做了强校验：接单大厅 createHandle 只有 handlerUserId 为空（未被接单）才允许抢单；发单审核 audit 只允许对”撤单中”订单放行，非法状态一律返回”订单状态不是撤单中”；管理员 change 改金额前校验订单必须处于”仲裁中”，且前后赔付金额不能完全一致。

发单、抢单与指派。 发单员 CreatorController.create 发布订单：设置状态为未接单，服务费按”任务佣金的 8%，超过 200 元按照 200 元收取”计算（代码中 commission.multiply(0.08) 后与 200 比较封顶）；如果发单时直接指定了接单人 userId，会校验其余额是否覆盖保证金并直接置为已接单。接单大厅（OrderCenterController.createHandle）是抢单入口：先查订单是否已被接，再校验当前用户 ord_user.balance >= deposit，不足则提示”保证金不足，请充值！“，通过后调用 balanceRecordService.acceptOrder 扣除保证金并写流水，最后回填接单人、接单时间、状态 100。发单人还能 setUser 把未接订单指派给指定用户——校验不能重复指派、目标用户保证金充足，超管（角色 id 含 1）在列表接口中可以看到所有订单，普通发单员只能看到自己 creator 的订单。

验收与自动完结。 接单人交付后进入验收中（600），CheckAndAcceptController.updateCheckResult 处理验收结果：checkResult=200 表示通过——调用 successOrder 结算（返还保证金 + 加佣金 + 扣服务费，三条流水），订单置为已验收（700）并记录验收意见；checkResult=500 表示拒绝，订单退回已接单（100）并记录拒绝原因。验收明细 ord_check_and_accept_details 支持多次上传交付截图/说明（type + url），验收单还支持导出 Excel。若发单方迟迟不验收，OrderStatusJob（Quartz 定时任务）会扫描所有验收中订单，当 submitTime + 7 天 已过时自动置为已验收并执行结算，防止订单无限挂起。

撤单协商与客服仲裁。 接单员 HandleController.createCancel 发起撤单（状态 200），可同时提交付给发单人的赔付金额 payToPublishUser 与付给自己的金额 payToHandleUser；发单员在撤单审核页（CreatorController.audit）选择拒绝（回 100）或同意（回 300），同意时触发 balanceRecordService.cancelOrder 按协商金额双向划转并退回保证金。若协商破裂，接单人可 OrderCancelController.service 申请客服介入（仲裁中 400，需填写赔付方案与服务理由）；管理员在仲裁管理页可 change 直接改双方赔付金额（置 serviceChangeAmountConfirm=0 待确认），或 audit 裁决为已仲裁（500，执行清算）或仲裁拒绝（550）。接单人也可自行 agree 接受仲裁结果或 cancelCancel 撤回撤单申请，撤单失败回到已接单继续履约。

资金账户与流水。 资金全部走 ord_user.balance 余额账户 + ord_balance_record 流水，BalanceRecordServiceImpl 是唯一结算入口：acceptOrder 扣保证金（“扣除保证金”）；successOrder 依次写”反还保证金、佣金、手续费”三条流水；cancelOrder 按赔付方向做四类划转——赔给接单人的钱从发单人余额扣、赔给发单人的钱从接单人余额扣（发单人余额不增加，即由平台收走）、最后退还接单人保证金，全程 @Transactional 保证余额与流水一致。充值走 HandleController.createOrderRecharge：先插充值单再调 payOrderApi.createOrder 创建支付单，支付模块回调 update-paid 时校验支付单存在、已支付、金额一致、商户单号二次匹配后置为已支付；提现由接单人提交 orderTake（金额必须大于 0、不能超过余额、不能有未审核的重复申请），管理员 auditCashOut 审核通过后扣余额，流水标记”提现”。

功能截图

暂无运行截图。

快速上手

  1. 初始化数据库：执行根目录 jiedan.sql（全量库脚本，含框架表、ord_ 业务表与测试数据），修改 yudao-server/src/main/resources/application-local.yaml 中的 MySQL、Redis 连接配置。

  2. 启动后端与前端：

cd "ruoyi-vue-pro-2.4.0接单系统"
mvn -pl yudao-server -am package -DskipTests
java -jar yudao-server/target/yudao-server.jar   # 端口 48080

cd yudao-ui/yudao-ui-admin-vue3
npm install
npm run dev   # http://localhost:8080，默认账号 admin / admin123
  1. 体验完整流程：先用管理员维护”订单分类”（或直接用种子数据里的视频拍摄/制作/剪辑分类）→ 发单员在”发单管理”发布订单（填佣金、保证金、交稿期限，可勾选直接指派接单人）→ 接单员在”接单大厅”看到未接订单，确认弹窗提示”订单佣金为 X 需要扣除押金为 Y 确认接单吗？“，余额不足先充值 → 接单后在”接单管理”提交交付成果并上传截图 → 发单员在”验收管理”通过/拒绝，通过后接单员资金明细里出现”反还保证金、佣金、手续费”三条流水 → 可再体验撤单申请、发单人审核、客服仲裁与提现审核闭环。

总结

这个项目把”接单派单”这类撮合交易的通用骨架做得很完整，值得借鉴的点有三个：一是按角色拆控制器的组织方式——发单员、接单员、客服、超管各自拥有独立的 Controller 与前端目录，列表查询天然带上 handler_user_id = 当前登录用户 之类的数据权限过滤，权限边界清晰；二是状态机驱动的订单流转——九个状态分布在 6 个控制器中各自校验、各自推进，配合”验收 7 天自动完结”的 Quartz 兜底任务，既灵活又不会让订单卡死；三是资金流水与业务解耦——所有扣款、结算、赔付都收敛在 BalanceRecordServiceImpl 一个类里，每次变动同时写余额与流水，撤单/仲裁的赔付方向（赔接单人的钱从发单人扣、赔发单人的钱从接单人扣）用注释写得很直白。当然也能看到二次开发的真实痕迹：OrderInfoServiceImpl 还是代码生成器留下的空壳，部分校验（如重复接单）依赖业务代码而非数据库锁，错误日志里全是”表缺列”的修复记录——这恰恰是它作为学习项目最真实的一面：一个从芋道脚手架一步步长出完整业务闭环的过程，对想用低代码脚手架快速搭建撮合/派单类系统的开发者很有参考价值。