办公杂事还在群里喊人签字？RuoYi Office OA 协同办公产品介绍：9 个业务域、1 套审批流、双端可办
办公杂事还在群里喊人签字？RuoYi Office OA 协同办公产品介绍：9 个业务域、1 套审批流、双端可办
🌐文档地址：http://ruoyioffice.com | 📦源码1·GitHub：ruoyi-office | 📦源码2·GitCode：ruoyi-office | 📦源码3·Gitee：ruoyi-office | 💬微信：17156169080（备注「RuoYi Office」）
▲ 一眼看懂：9 个 OA 业务域共用一套审批流与台账，发起 → 审批 → 资源占用/回收 → 留痕 → 复盘
“盖个章而已，群里 @ 一下不就行了？”——大多数公司的 OA 就是这么起步的：用印在群里喊，会议室靠白板划，公车靠行政记本子，公文靠微信转 Word，报销靠翻聊天记录找截图。RuoYi Office 的 OA 协同办公要解决的，不是“再加一个审批入口”，而是把公文、会议室、公车、用印、用品、出差、汇报、云盘、工单这 9 件日常，收进同一套组织、同一套审批流、同一套台账里——谁申请的、谁批的、批完资源给谁了、什么时候还回来，随时可查。
引言：日常办公的“碎事”，到底难在哪？
日常办公的痛点不是单点功能缺失，而是碎事太多、载体太散、责任无痕。
| 痛点 | 群聊 / Excel / 纸单 | 系统化协同 |
|---|---|---|
| 审批找人 | 群里 @ 领导，回复“同意”截图当凭证 | 单据按流程自动流转到当前审批人 |
| 资源撞档 | 会议室白板被涂改，两个部门同时“订” | 时间段冲突校验，占用即锁定 |
| 归还失控 | 车借出去没人跟，钥匙不知在谁手上 | 借出 → 预计归还 → 实际归还闭环 |
| 公文散落 | 发文 Word 在微信，收文靠转发 | 发文自动生成收文，归档台账统一检索 |
| 费用扯皮 | 出差回来才对票，超标才发现 | 出差申请与报销双单联动，先约束再核销 |
| 责任无痕 | “我记得跟你说过” | 单据编号 + 审批记录 + 操作日志可追 |
一句话结论：OA 做得好不好，不看功能条数，而看「碎事能不能收进同一条链路：统一发起入口 → 统一审批流 → 资源占用与回收 → 台账可查」——RuoYi Office 的 OA 就是按这条链路组织的。
一、产品定位：把 9 件办公日常收进一个办公台
RuoYi Office OA 协同办公是一体化企业管理平台中的协同域，与人力、合同、CRM、ERP、项目、资产共用同一套用户、组织、权限、字典与工作流底座。它不是独立的“OA 小系统”，而是平台内一组共享底座的业务域：
| 业务域 | 解决的日常 | 关键设计 |
|---|---|---|
| 公文管理 | 发文、收文、外来文、归档 | 发文审批通过自动生成收文；套红成稿；归档台账 |
| 会议室管理 | 预定、冲突、到点提醒 | 时段冲突校验 + 审批占用 + 提醒推送 |
| 车辆管理 | 用车申请、派车、还车 | 车辆台账 + 用车单 + 还车里程/费用回填 |
| 印章管理 | 印章台账、用印申请 | 现场用印 / 借用印章两种用印方式 |
| 办公用品 | 物品台账、领用发放 | 消耗品与借用品分治，入库/领用/发放三段 |
| 出差管理 | 出差申请、差旅报销 | 出差单与报销单联动，先申请后核销 |
| 工作汇报 | 日报、周报、月报 | 统一汇报单 + 汇报类型 + 统计视图 |
| 企业云盘 | 文件共享、目录权限 | 目录树 + 权限控制 + 在线预览 |
| 内部工单 | IT/行政报修与服务请求 | 工单受理、处理、SLA 时效 |
| 角色 | 关心什么 | 模块怎么答 |
|---|---|---|
| 普通员工 | 少填表、少找人、手机能办 | 移动端发起申请，待办统一在工作台聚合 |
| 部门负责人 | 批得快、看得清本部门情况 | 待办列表 + 单据详情 + 部门筛选台账 |
| 行政 / 综合办 | 资源不撞档、台账对得上 | 资源台账 + 占用状态 + 归还与库存核对 |
| 管理层 / 审计 | 谁批的、批完怎么执行的 | 单据编号 + 审批记录 + 操作留痕 |
二、核心设计：三条贯穿 9 个业务域的主线
2.1 统一审批流：单据只管业务字段，流程交给引擎
结论先说：OA 里所有需要签字的动作都走同一套 Flowable 流程引擎，业务模块不自己实现审批。BPM（Business Process Management，业务流程管理）在这里的职责很清楚：谁审、按什么条件分支、会签还是或签，全部在流程设计器里配，改流程不改代码。
带来的直接好处是一致性：用印、用车、出差、公文、汇报的审批体验完全一样——同一个待办中心、同一套审批操作（同意/驳回/加签/转办）、同一份审批记录。
业务单据（用印/用车/出差/公文…） └─ 提交 → 绑定流程实例（Flowable） └─ 审批节点按组织/角色/条件路由 └─ 终态回调 FlowBillService ├─ 通过：写业务后置动作（占用资源 / 生成下游单据） └─ 驳回：单据回到可编辑，资源不占用为什么不让每个模块各写一套审批？十来个业务域各写一遍，等于把“审批人怎么定”这件事复制十遍——换一次组织架构就要改十处代码。
2.2 资源占用与回收：状态由单据驱动，不靠人工改字段
OA 里大半的模块本质是资源调度：会议室是时间资源，公车是车辆资源，印章是可借出的实物，办公用品是库存。这类模块最容易出问题的地方不是“申请填不填”，而是占用了之后谁负责还。
统一处理原则：
| 资源 | 占用动作 | 回收动作 | 防错手段 |
|---|---|---|---|
| 会议室 | 审批通过锁定时段 | 到点释放 / 取消释放 | 同室同时段冲突校验 |
| 公车 | 派车绑定车辆与司机 | 还车登记里程、费用 | 车辆状态互斥，避免重复派车 |
| 印章 | 借用印章出库 | 归还登记 | 预计归还时间 + 未还提醒 |
| 办公用品 | 领用申请扣减 | 借用品归还入库 | 消耗品/借用品分治，库存不为负 |
关键在于：状态不是管理员在列表里手改一列，而是单据审批通过后由系统改。这样“会议室为什么被占”“这台车现在在谁手上”都能追到具体单号。
2.3 台账与编号：每类单据一条可检索的账
每个业务域都有自己的台账，并采用统一的编号规范：模块前缀 + 日期 + 当日序号。比如OA101-2026040900001是用车申请、OA103-2026031400002是用印申请、OA105-2026032200001是发文、OA111-2026032200002是工作汇报。
编号规则：OA1xx（业务域） + yyyyMMdd（日期） + 5 位当日序号 OA101 用车 OA103 用印 OA105 发文 OA106 收文 OA107 外来收文 OA111 工作汇报 序号侧用原子递增保证唯一，支持 PC / App 并发提交编号不是形式主义：审计要查“3 月 14 号那次用印”，行政报“上季度用车多少单”，都靠这条编号 + 台账筛选完成，不用翻聊天记录。
三、系统截图：真实数据长什么样
▲ 公文归档台账：发文、收文、外来收文三类归档在同一张台账，文号、密级（公开/绝密）、紧急程度（普通/加急/特急）、责任部门与经办人可筛可导出
▲ 用印申请单：单据编号、单据状态（未提交/审批中）、印章编号与名称、用印类型、用印方式（现场用印/借用印章）、预计用印与归还时间同屏可见，借用印章会挂归还预期
▲ 用车申请单：141 条单据按状态（审批中/审批通过/审批不通过/已返回）流转，车牌、出车与回车时间、起止地点一目了然，还车后回填实际信息
▲ 办公用品台账：左侧类别树（文具类/打印耗材/生活用品/电脑办公/办公设备电器/财务用品），右侧物品卡片区分「消耗品 / 借用品 / 资产品」管理类型，并带参考单价与库存
四、业务闭环怎么串起来（三条最短路径）
比看功能清单更直观的是看链路。以下三条是 OA 里最高频的闭环：
① 用印：申请 → 审批 → 用印 → 归还
员工提交用印申请（选印章 + 用印方式 + 预计时间） → 部门负责人/印章保管人审批 → 现场用印：登记用印完成 → 借用印章：出库绑定借用人 → 预计归还时间 → 归还登记 → 台账记录本次用印事由、次数、经办人② 公文：发文成稿 → 审批 → 自动生成收文 → 归档
起草发文（套用模板 / 套红成稿） → 会签与签发审批 → 发布：按分发范围自动生成收文任务 → 接收部门签收认领 → 批示办理 → 办结 → 归档台账（发文/收文/外来收文统一检索）③ 出差：出差申请 → 行程执行 → 差旅报销
出差申请（行程、同行人、预算） → 审批通过后行程生效 → 回来后发起差旅报销，引用出差单 → 费用明细分类核销 → 财务复核 → 台账留存三条链路共用同一套审批引擎与组织数据，因此员工只需要记住一件事：所有申请都在同一个入口发起，所有待办都在同一个工作台处理。
五、双端体验：PC 管理端 + 移动端 App
OA 是最需要移动化的业务域——审批人常常不在工位上。RuoYi Office 采用「一套后端 + 双端」的方式：
| 维度 | PC 管理端（Vue3 + Ant Design Vue） | 移动端（UniApp + Vue3） |
|---|---|---|
| 定位 | 台账管理、批量操作、统计导出 | 发起申请、随手审批、消息触达 |
| 典型场景 | 行政维护车辆/印章台账、公文套红成稿 | 打车前发起用车、路上批用印、看待办 |
| 数据来源 | 同一套/admin-api接口 | 同一套接口，字段与状态完全一致 |
| 部署 | Web 静态资源 | H5 / 微信小程序 / App 多端打包 |
因为共用同一份单据与状态定义，不存在“App 上批过了 PC 上还显示待批”这类双写不一致问题。
六、快速体验
在线演示
- 🌐 Web 演示：http://ruoyioffice.com/web/（账号
admin/ 密码admin123） - 📱 App 演示：http://ruoyioffice.com/app/
推荐体验路径
- 登录后进入OA → 印章管理 → 用印申请单，新建一笔用印申请，选择「借用印章」，观察预计归还时间字段。
- 到流程中心 → 我的待办审批这笔单据，感受“业务单据 + 统一审批”的一致体验。
- 进入OA → 车辆管理，先看车辆台账，再看用车申请单的状态流转与还车回填。
- 打开OA → 公文管理 → 归档台账，按密级/紧急程度筛选，理解发文与收文如何统一归档。
- 进入OA → 办公用品管理 → 办公用品台账，注意「消耗品 / 借用品」两种管理类型的差别。
- 用手机打开 App 演示地址，在移动端发起一笔用车申请并审批，对照 PC 端状态是否同步。
本地启动（约 10 分钟）
# 后端：Spring Boot 3.5 + Java 17，默认端口 48080，API 前缀 /admin-apimvn cleaninstall-DskipTests-Pboot# 前端：Vue3 + Vite 6，默认端口 5800，代理到 localhost:48080/admin-apipnpminstall&&pnpmdev:antd源码仓库
| 仓库 | 地址 |
|---|---|
| GitHub | https://github.com/yuqing2026/ruoyi-office |
| GitCode | https://gitcode.com/zhouzhongyan/ruoyi-office |
| Gitee | https://gitee.com/yqzy1688/ruoyi-office |
说明：平台基础协同能力与演示环境可在线体验；更完整的企业级扩展能力、行业适配与持续交付，可加微信咨询商业版与私有化方案。
常见问题（FAQ）
RuoYi Office 的 OA 协同办公具体包含哪些模块？
包含公文管理（发文/收文/外来文/归档）、会议室管理、车辆管理、印章管理、办公用品管理、出差与差旅报销、工作汇报（日报/周报/月报）、企业云盘、内部工单 9 个业务域，共用同一套组织、权限与审批流。
审批流程能不能按公司自己的规则改？
可以。审批基于 Flowable BPMN 2.0 引擎，审批人、条件分支、会签/或签、加签转办都在流程设计器中配置，常见调整不需要改代码。
会议室和公车会不会出现两个人同时订到？
不会。这两类属于资源型模块，提交时按时间段做冲突校验，审批通过即锁定占用，取消或到点后释放，状态由单据驱动而非人工改字段。
手机上能审批和发起申请吗？
可以。移动端基于 UniApp + Vue3，与 PC 管理端共用同一套/admin-api接口和状态定义，支持 H5、微信小程序与 App 打包，审批结果双端实时一致。
单据编号是怎么生成的，会不会重复？
按「模块前缀 + 日期 + 当日序号」规则生成（如用车OA101-2026040900001、用印OA103-2026031400002），序号侧用原子递增保证唯一，适配 PC 与移动端并发提交。
数据能放在自己公司的服务器上吗？
可以。技术栈为 Spring Boot 3.5 + MySQL + Redis，支持单体或微服务两种部署模式，可完全私有化部署在企业自有服务器或内网环境。
结语
办公杂事之所以让人烦，很少是因为“少了一个功能”，更多是因为每件事都有自己的载体：群聊、白板、本子、Excel、微信转发的 Word。RuoYi Office 的解法不复杂：把 9 件日常收进同一套组织与审批流，让资源占用与回收由单据驱动，让每类单据都有一条可检索的台账。
如果你正被“群里喊签字、会议室撞档、公车不知在谁手上、公文找不到最终版”困扰，不妨用admin/admin123进演示环境走一遍用印和用车，感受“同一个入口、同一套审批、同一本台账”能省掉多少来回。
留个话题给你：你们公司最难管的办公杂事是哪一件——用印、公车，还是会议室？评论区聊聊你们现在是怎么处理的。
💡想要体验 RuoYi Office 的强大功能？
🌐在线演示：http://ruoyioffice.com/web/（账号 admin / admin123）
📦源码仓库：GitHub | GitCode | Gitee
💬技术咨询：添加微信17156169080，备注「RuoYi Office」
⭐如果觉得不错，请给个 Star 支持一下！