公文管理别再用 Word 传来传去:套红模板、发文自动拆收文、归档台账的闭环设计
🌐 演示地址:http://ruoyioffice.com | 📦 源码1·GitHub:ruoyi-office | 📦 源码2·GitCode:ruoyi-office | 📦 源码3·Gitee:ruoyi-office | 💬 微信:17156169080(备注「RuoYi Office」)
▲ 公文不是"写个 Word 群发一下",而是"套红模板 → 发文审批 → 自动拆收文 → 收文办理 → 归档台账"一条链。发文审批通过的那一刻,主送和抄送部门的收文记录就自动生成了,不用再手动一个个通知。
引言:公文一乱,企业的"正式表达"就不可信了
公文是企业对内对外的"正式表达"——通知、决定、批复、函。可一旦用 Word 文件传来传去,问题就来了:
- 每个人手里一套红头格式,字号、机关名、文号各写各的;
- 发文发给哪几个部门,靠手动建群、@人、发附件,漏一个是常事;
- 收到的文件办没办、谁在办、办完没有,没人跟得住;
- 年底想归档,发文收文散在各个聊天窗口和邮箱里,根本凑不齐。
公文的麻烦,本质是格式不统一 + 流转不闭环 + 归档不集中。RuoYi Office 把公文做成一条完整的链:套红模板统一格式,发文走审批,审批通过自动拆出收文,收文办结后自动进归档台账。
一、套红模板:把"红头格式"一次性立标准
公文的第一道坎是格式。RuoYi Office 用套红模板把红头样式固化下来:机关 / 公司名称、名称字号、发文字号前缀、印章图片、红头分隔线(单线 / 双线)都在模板里配好,发文时直接套用,不用每个人自己排版。

▲ 套红模板管理:机关名称、字号、发文字号前缀、印章、分隔线样式集中维护。发文时套用模板,红头格式全公司一致,告别"每个人一套 Word 模板"。
二、发文 + 审批:正文用富文本,按国标版式预览,生成 PDF
发文是公文的"出口"。在发文单里填标题、密级、紧急程度、主送 / 抄送部门、签发人,正文用富文本编辑器直接写(而不是再传一个 Word 附件),然后走"部门负责人 → 分管领导 → 签发人签发 → 办公室编号发文"的审批链。

▲ 公文发文列表:完整文号(如"无办发〔2026〕2号")、标题、密级、紧急程度、审批状态一列可见。发文走分级审批,到"办公室编号发文"节点才正式编号,文号不会乱发。
正文写完后,系统能按 GB/T 9704—2012 党政机关公文格式做版式预览,并一键生成正式公文 PDF(后端用 HTML 模板转 PDF),既保证了在线编辑的便捷,又保证了最终成文的规范性。这一点比"在线编辑 Word"更轻、更可控,也更适合做权限和留痕。
三、发文自动拆收文:审批通过的那一刻,通知就发出去了
这是整套公文设计里最值得一提的一环。发文审批通过后,系统会按主送 / 抄送部门自动生成对应的收文记录——主送部门收到的是"需要办理"的收文,抄送部门收到的是"仅知悉"的收文,附件也一并复制过去。
也就是说,发文人不需要再手动建群、@人、发附件。审批一通过,该收到这份文的部门,工作台里就自动出现了待签收 / 待知悉的收文。这就是"发文—收文"之间最容易断掉、却被系统自动接上的一环。

▲ 公文收文列表:来文文号、标题、收文部门、承办人、办理状态一目了然。收文支持签收认领、领导批示、承办办理,"待签收 → 已签收 → 办理中 → 已办结"全程可跟踪。
收文这边有一套清晰的办理状态:待签收 → 已签收 → 办理中 → 已办结。关联发文生成的收文支持"抢单式"签收认领,谁认领谁办,办理过程留痕。
四、归档台账:办结即归档,不用再手动"整理一遍"
很多系统的归档是一个独立的"再操作一遍"的动作,公文管理最怕的就是这个——办完了没人去归档。RuoYi Office 的做法更聪明:归档台账不是一张要手动录入的表,而是对发文、收文、外部收文的聚合查询。
- 发文 审批通过,自动进入归档台账;
- 收文 办结,自动进入归档台账;
- 外部来文 审批通过,自动进入归档台账。

▲ 归档台账:发文、收文、外部收文办结后自动汇入,按文号、标题、密级、日期、部门、承办人集中检索和导出。归档不是"再录一遍",而是流程走完自然沉淀的结果。
这样一来,"公文散落在各个聊天窗口和邮箱"的问题就被根治了:所有正式公文,只要走完流程,就自动汇聚到一个可检索、可导出的台账里。
说明:当前公文模块聚焦"收发文流转 + 自动归档台账"。如果需要更进一步的借阅审批、密级借阅留痕等档案管理能力,可以基于现有归档台账和审批引擎二次开发扩展——把"借阅申请"做成又一个走审批的单据即可,底座是现成的。
五、为什么放进一体化平台做
公文连着组织、审批、文件、移动端,单独做一个公文系统反而割裂。RuoYi Office 把它放进一体化平台,意味着:
- 主送 / 抄送部门、签发人、承办人直接用系统组织架构选,不用维护两套通讯录;
- 发文、收文、外部收文都走全局 Flowable 引擎,和其他审批共用一套流程底座;
- 公文附件复用统一文件服务,正文 PDF 自动归档;
- PC 起草发文,移动端签收、批示、办理,领导在外也能批公文;
- 基于 Spring Boot + Vue3,密级、文号规则、办理节点都能按企业制度二开。
六、适合谁
| 适合 | 不太适合 |
|---|---|
| 有正式发文、需要红头格式和文号规范的企业 / 机关 | 完全不发正式公文、口头通知就够的小团队 |
| 收发文量大、需要跟踪办理进度的办公室 | 只想要一个网盘存文件、不需要流转的场景 |
| 想让发文自动通知到部门、减少手动转发的组织 | 已用成熟 OA 公文且无迁移意愿 |
| 需要公文自动归档、可检索可导出的单位 | — |
公文管理做得好不好,看的不是能不能写文件,而是"发文有没有自动到达、收文有没有人办、办完有没有归档"。当这三件事被一条流程串起来,企业的"正式表达"才真正变得可信、可查、可追溯。
💡 想要体验 RuoYi Office 的强大功能?
🌐 在线演示:http://ruoyioffice.com/web/(账号 admin / admin123)
📦 源码仓库:GitHub | GitCode | Gitee
💬 技术咨询:添加微信 17156169080,备注「RuoYi Office」
⭐ 如果觉得不错,请给个 Star 支持一下!

318

被折叠的 条评论
为什么被折叠?



