企业合同起草电子化设计：从模板套用、占位域填充到在线成稿归档

🌐 演示地址：http://ruoyioffice.com | 📦 源码1·GitHub：ruoyi-office | 📦 源码2·GitCode：ruoyi-office | 📦 源码3·Gitee：ruoyi-office | 💬 微信：17156169080（备注「RuoYi Office」）

“合同模板发你邮箱了，甲方名称、金额、日期自己改一下”——这句话背后藏着企业合同最大的隐患：模板满天飞、版本对不齐、关键字段填错、改完的稿子谁也说不清是不是最终版。合同的价值在于严谨，而"发个 Word 各自改"恰恰把严谨交给了运气。合同起草电子化，本质是把"写合同"这件事从自由发挥变成模板驱动、字段受控、正文可追溯的标准动作。 本文以 RuoYi Office 的合同起草能力为样本，拆解一份合同正文如何从模板套用、占位域填充一路走到在线成稿与归档，面向法务、实施顾问与做合同系统选型的同学。

📌 本文聚焦「合同起草成稿」这一段（模板→正文→产物）。合同的 9 状态生命周期、审批签署与台账履约，另见《合同管理全生命周期设计》一文，此处不再展开。

▲ 合同起草电子化全景：① 选用合同模板（关联分类/类型）→ ② 按占位域定义填充字段值 → ③ 在线拟稿（富文本 / OnlyOffice）→ ④ 生成正文 HTML + Word/PDF 双产物 → ⑤ 提交审批、归档留痕，正文与台账贯通

引言：合同起草，难在"受控"

"写份合同"听着简单，做成企业级能力要回答一连串问题：

难点一：模板满天飞。销售 A 用的是三年前的老模板，法务改过的新版没人同步，同一类合同在公司里存在好几个版本，风险条款各不相同。

难点二：关键字段靠手填。甲乙方名称、金额、起止日期、信用代码——这些字段散落在正文各处，手工替换极易漏改、错改，一份合同里甲方名字前后不一致是常事。

难点三：改完的稿子说不清。Word 传来传去，“合同终版”"合同终版2""合同终版最终版"满桌飞，到底哪份是提交审批的那份，谁也不敢拍板。

难点四：正文和系统两张皮。合同正文在 Word 里、合同信息在系统里，履约、审批、归档时又要重新对一遍，正文与业务数据完全脱节。

RuoYi Office 的解法是把起草做成"模板套用 + 占位域填充 + 在线拟稿 + 双产物成稿 + 归档"的受控链路。下面拆开看。

一、功能拆解：合同起草电子化的组成

一份合同正文从无到有，涉及这几块能力：

价值在于：把合同起草从"自由改 Word"，升级为模板受控、字段结构化、正文可追溯的标准动作。

二、数据模型：起草单承载正文与字段值

合同主表 contract_info 是起草成稿的载体，它把"选了哪个模板、填了哪些字段、生成了什么产物"全部结构化沉淀：

public class ContractInfoDO extends TenantBaseDO {    private String contractName;              // 合同名称    private Long categoryId;                  // 合同分类    private Long templateId;                  // 选用的合同模板    private Integer templateVersion;          // 选用的模板版本号    private String contentHtml;              // 填充后的合同正文（在线编辑最终稿）    @TableField(typeHandler = JacksonTypeHandler.class)    private Map<String, Object> fieldValuesJson; // 占位域填充值（key -> value）    private String contractDocUrl;          // 生成的 Word 文件 URL    private String contractPdfUrl;          // 生成的 PDF 文件 URL    private String signedFileUrl;           // 正式签署件 URL}

关键字段解读：

为什么正文（contentHtml）和字段值（fieldValuesJson）要分开存？ 因为"填了什么"和"正文长什么样"是两件事：字段值结构化存下来，既能在正文里替换占位域，也能同步回合同主数据（金额、甲乙方），还能在后续变更时对比"改了哪个字段"。正文与字段解耦，是合同数据能被系统复用、而不是烂在一坨 HTML 里的关键。

三、起草流转：从模板到成稿

一份合同正文的成稿过程，是一条从范本到定稿的受控流转线：

关键在于占位域填充：模板里预置了 {合同金额}、${签订日期} 这类占位标记，起草时按字段定义收集值，一次性回填到正文，杜绝"这里改了那里忘改"。填完的字段值随正文一起沉淀，正文因此不再是一份"死"的 Word，而是可追溯、可复用的结构化数据。

四、页面深拆：从起草列表到台账

合同起草列表：所有在起草/编辑中的合同集中管理，是正文成稿的工作台入口。

▲ 合同起草列表：起草态合同集中呈现，从这里进入在线拟稿页完成正文填充与编辑

合同台账列表：审批通过后的合同以资产态进入台账，正文产物与合同信息一体留存。

▲ 合同台账：成稿并审批通过的合同进入台账，正文 Word/PDF 与合同主数据一并归档

关联业务合同：CRM 等业务模块的合同同源共管，起草能力全局复用。

▲ 业务侧合同：CRM/采购等场景的合同复用同一套起草与模板能力，正文标准统一

五、选型视角：起草电子化的价值在"受控 + 打通"

合同工具很多，起草电子化真正的分水岭在两点：

一句话：合同起草的价值不在"能打字"，而在"让每一份正文都从受控范本长出来、每一个字段都结构化可追溯、每一份定稿都和业务数据连着"。模板守住条款一致、占位域守住字段准确、双产物守住定稿唯一、系统打通守住数据一体——这四点是"发 Word"永远给不了的。

六、方案亮点

七、常见问题 FAQ

Q1：占位域是怎么定义和填充的？
 模板里预置占位域定义（字段名、类型），起草时按定义收集字段值存入 fieldValuesJson，再一次性回填正文，避免手工在正文里逐处替换。

Q2：正文既有 HTML 又有 Word，以哪个为准？
 取决于编辑模式：富文本模式以 contentHtml 为最终稿；OnlyOffice 高保真模式以回存的 contractDocUrl（Word）为准，并可导出 PDF。系统按模板的编辑器类型统一，不会两套并存混乱。

Q3：能锁定正文不让业务随意改吗？
 可以。模板可设"生成正文是否允许二次编辑"，为不可编辑时，由该模板生成的合同正文在起草页只读，仅可生成不可修改，保障标准条款不被篡改。

Q4：起草的正文怎么进入审批和台账？
 起草完成提交后进入合同审批流程，审批通过的合同以资产态进入台账，正文产物随之归档，形成"起草—审批—台账"的连续链路（生命周期细节见另一篇专文）。

Q5：不同业务模块的合同能共用起草能力吗？
 可以。合同起草与模板是独立的合同模块能力，CRM、采购等业务侧合同可复用同一套模板与占位域，保证全公司合同正文标准一致。

Q6：换了模板版本，老合同会受影响吗？
 不会。合同正文引用的是起草时的模板版本号（templateVersion），模板后续升级不影响已成稿合同，历史正文保持稳定可追溯。

结语

合同的严谨，不该寄托在"业务自己改 Word 别改错"上。RuoYi Office 把合同起草做成"模板套用 + 占位域填充 + 在线拟稿 + 双产物成稿 + 归档"的受控链路，用模板版本守住条款一致、用占位域守住字段准确、用正文与字段解耦让合同数据可复用可追溯。对法务和实施顾问来说，起草电子化的意义，不是"少发几封带附件的邮件"，而是让每一份合同正文都从标准范本长出来、都和业务数据连在一起——这才是合同数字化真正的起点。

🌐 演示地址：http://ruoyioffice.com | 📦 源码·Gitee：ruoyi-office | 💬 微信：17156169080（备注「RuoYi Office」）