OA合同会签表单设计器方案：FcDesigner 如何拆开业务、法务和财务
业务要填标的和对方信息，法务要看条款、管辖和用印，财务要看金额、收付款和发票抬头。如果给每个角色做一张页面，三张单很快对不齐；如果做成一张所有人都能改的大表，约定「法务那几项你们别动」一定会被打破。把这张单交给 FcDesigner 做可视化设计、交给 FormCreate 做动态渲染，改类型、改权限、改必填，动的是配置。
FcDesigner 和 FormCreate 在会签里怎么分工
检索「OA表单设计器」或「合同审批表单」时，容易以为设计器要连会签顺序一起管。在 FormCreate 体系里，设计和运行是拆开的。
FcDesigner 是基于 Vue 的低代码可视化表单设计器。实施在画布上拖出合同单、配联动和权限，输出 JSON。开源即可搭结构，公式、角色权限、生成 SQL 等见 FcDesigner Pro 文档。
FormCreate 是动态表单渲染器。发起、会签、归档都加载同一份 JSON。流程节点只决定谁在这一刻打开、以编辑还是阅读打开。
谁先签、是否会签并签、超时谁来，仍是流程引擎的事。表单设计器不替代 BPM。它解决的是：销售合同和采购合同不要做成两套页面；法务打开时不要看见「随便改金额」的输入框。
FormCreate 项目自 2018 年开源，官方介绍历经多次框架重构，GitHub 星标超过 7000。产品由西安锦强未来科技有限公司的 FormCreate 团队维护。
合同会签真正难的不是字段多，是一张单上有三种立场
典型中后台里，合同单第一版通常长这样：
- 合同名称、对方、类型、金额、起止日期
- 正文附件、会签意见
- 用印、归档编号
上线一个季度后，几乎一定会出现这些变化：
- 合同类型从「销售 / 采购」扩成框架、补充协议、保密协议、劳动合同，每种要补不同条款字段。
- 金额超过某一档，财务要看收付款计划和税率；低于该档，这些字段不该出现。
- 法务要管辖地、争议解决、是否格式合同；销售端不能改，甚至不该看见完整条款区。
- 补充协议要挂原合同编号，新签则不要这个字段。
- 对方是个人还是企业，证件和开票信息不一样。
- 移动端只适合补意见和看摘要，PC 上那张带标的明细的表不能原样缩小。
如果这些都写在页面里，每多一种合同就多一串 v-if。法务改一句提示文案也要找前端。会签单比报销单更不适合锁在代码里，因为它同时服务三个部门，任何一个部门改口径都会把另外两个部门的页面带崩。
一张合同会签单怎么配
下面按一张能跑完「起草 → 会签 → 归档」的表来配，不写接入代码。
1. 先定结构：主表 + 标的明细 + 意见区
主表放一份合同只出现一次的信息：名称、类型、对方、金额、币种、起止日期、是否补充协议。标的明细用子表或表格：名称、数量、单价、税率。意见区单独成组：会签结论、意见、附件。
FcDesigner 支持栅格、弹性盒子、表格布局，也支持子表单和分组。合同单适合「上身份、中标的、下意见」。打印和阅读模式都会清楚很多。开源设计器就能搭出这一层。金额是否超档、谁能改条款，再交给 Pro 的公式和角色权限。
2. 合同类型一变，后面的字段跟着变
这是会签单里最不该写死的部分。
| 合同类型 | 需要出现的字段 | 通常要的附件 |
|---|---|---|
| 销售合同 | 客户、回款计划、开票信息、质保期 | 合同正文、报价或订单 |
| 采购合同 | 供应商、付款条件、到货/验收 | 合同正文、比价或询价 |
| 框架协议 | 有效期、结算周期、是否开口合同 | 框架文本 |
| 补充协议 | 原合同编号、变更范围、变更后金额 | 补充协议、原合同 |
| 保密协议 | 保密期限、范围、是否双向 | 协议文本 |
| 劳动合同 | 岗位、试用期、薪资结构（常要更严的权限） | 合同文本、录用审批 |
在 FcDesigner 里用条件显示和数据联动：选补充协议才出现原合同编号，选销售才出现回款计划，选采购才出现验收条款。不必为每种合同做一张独立表，也不必在流程里为了多几个字段拆成多条分支。
对方主体也要联动：企业出现统一社会信用代码和开票抬头，个人出现证件类型和证件号。这类分叉写在页面里最容易漏，配在设计器里可以当场试。
3. 金额不要只当普通数字
合同金额后面通常挂着三件事：是否触发更高一级会签、财务能不能看见收付款、标的明细加起来是否对得上主表。
典型计算和判断可以做成字段公式：
- 标的合计：明细里数量 × 单价，再
SUM - 含税总额：合计 ×（1 + 税率）或按行税率再汇总
- 是否超档：总额与公司规定的会签档位比较，超档则提示「需财务会签」
- 变更差额：补充协议里变更后金额减原金额
FcDesigner Pro 的公式按字段引用，用法接近表格函数，内置 SUM、ADD、IF 以及 HAS_ROLE、HAS_PERMISSION。条件必填也可以挂上去：有标的就必须有税率，选了补充协议就必须填原合同编号。
分寸仍然要守：公式负责填报当时的可见计算和提示。合同效力、用印、财务入账仍归法务和财务系统。表单设计器不是合同中台，但可以把「明细对不上主表」「该财务看的档却没露出财务区」挡在提交之前。
4. 同一张单，业务、法务、财务不该长一样
会签最容易被做成「所有人打开都是同一张可编辑大表」。业务改了管辖地，法务改了金额，事后对账会对出三份故事。
更稳的做法是同一份 JSON，按角色控制显隐、禁用、必填。FcDesigner Pro 支持预置权限树和角色树，运行时注入 $roles、$permissions，逻辑条件和公式就能判断。
| 角色 | 能看见 | 能编辑 | 打开方式 |
|---|---|---|---|
| 业务起草 | 对方、标的、金额、商务条款摘要 | 提交前可改；打回后按节点再开放 | 编辑 |
| 法务 | 全文条款、管辖、争议解决、是否格式合同 | 通常只开条款区和法务意见；金额默认禁用 | 阅读模式 + 条款区 |
| 财务 | 金额、税率、收付款、开票信息 | 只开财务区和核销意见 | 阅读模式 + 财务区 |
| 已归档查看 | 当时那一版全部内容 | 全部禁用 | 阅读模式 |
阅读模式是会签的配套能力。法务和财务打开的是「看单 + 写意见」，不是再复制一张详情页。业务改字段、法务看字段、财务补收付款，页面还是那一套规则。
设计器里的「组件操作权限」和运行态的「角色权限」不要混。前者管谁能在画布上改组件，后者管谁打开会签单时能看见、能改哪一项。实施上要把两件事分开，避免把「只有管理员能设计表单」当成「法务不能改金额」。
5. PC 上设计，手机上只做会签动作
合同正文和标的明细发生在工位上。会签意见经常发生在路上。
FcDesigner Pro 支持把 PC 端设计的规则在移动端渲染为 Vant 风格。实施上不必维护两套合同单：PC 负责把类型、对方、明细一次填完，移动端保证「看摘要、写同意或驳回、补一句意见」走得通。
字段要克制。手机上不要把管辖条款和税率表一起塞进去。用角色权限把条款区和财务区按端收起来，移动端会干净很多。正文附件仍要能打开，但编辑正文不是手机节点该做的事。
6. 设计稿要落到库表，也要留下当时的 JSON 版本
合同要归档、要检索、要对补充协议。只把 JSON 当配置不够，主表和标的行还得有表。
FcDesigner Pro 可以根据当前字段生成建表 SQL，也可以对比历史结构生成变更语句。主表一张、明细一张，和「上主表、下标的」是对齐的。生成结果需要人工确认后再执行，尤其是金额精度、必填与 NOT NULL、字段改名与历史合同。它减少的是「前端改完了，后端还在等表结构」，不是取代 DBA。
JSON 建议按版本存。哪一次会签用的是哪一版规则，要能回放。合同和报销一样：库表存业务数据，JSON 存当时的表单定义。补充协议去挂原合同时，读的是库表里的编号，打开当时那张单，读的是当时那版 JSON。
这条链路怎么接到现有 OA 里
不改会签顺序，也能先把合同单从代码里拆出来。
业务先出规则，再进设计器。 把合同类型枚举、金额档位、谁能改条款、补充协议是否必须挂原合同，写成一页规则。规则不定，拖组件只会把三部门的分歧可视化。
用 AI 表单助理出第一版，人再改。 把「合同会签：主表 + 标的明细 + 按类型联动 + 业务/法务/财务三视图」描述给 AI 表单助理，让它生成初始结构，实施再补校验、角色和公式。第一版不求完美，求把部门之间的字段争论变成可以点的画布。
JSON 入库，流程节点只负责打开方式。 起草节点用编辑态，法务和财务节点用阅读模式加各自的可写区，归档节点全阅读。会签顺序、会签还是或签，仍用现有 OA 或 Flowable 一类引擎。
标准组件先用满，个性字段再扩展。 日期、金额、上传、下拉、子表就能覆盖合同单的主体。合同编号生成、对方主数据带出、电子签章，用自定义组件或远程数据接入。FcDesigner 支持自定义组件和自定义模板，可以把「标的明细四列」做成可重复拖入的模板，避免销售合同和采购合同从零搭两遍。
先验证开源，再决定 Pro。 开源 FcDesigner 已经能拖拽、校验、布局、输出 JSON，用来证明「合同单可以配置化」足够。公式、角色权限、阅读模式、PC 到移动端、生成 SQL、AI 助理，是把会签闭环收干净时更常落到 Pro 上的能力。
这样做之后，会签真正少掉的工作
开发不再为「加一种补充协议」开迭代。类型、联动、提示文案在设计器改，JSON 发布后下一次打开即生效。
法务和财务可以参与定字段，而不只是提需求等还原。画布上当场能试：这个条款给不给销售看，金额超档后财务区出不来。
起草页、会签页、归档页不再分叉成三套模板。阅读模式让详情和会签共用规则，减少「起草是一版、法务看到的是另一版」。
移动端补意见不必另做一套表。同一份规则按端渲染，路上的人和工位上的人用的是同一张合同。
以上是典型场景里可预期的分工变化，不是某家客户的实施报告。具体能少几人天，取决于你们现在有多少合同变体写在代码里。
常见问题
合同会签和差旅报销，用设计器时差别在哪？
报销难在明细和计算会变。会签难在同一张单上有三种立场。两者都适合配置化，但会签更依赖角色权限和阅读模式，报销更依赖子表和公式。
表单设计器能替代会签流程吗？
不能。FcDesigner 解决单长什么样、谁能改哪一项、金额怎么校验。谁先签、是否会签并签、超时谁来，仍是流程引擎的事。两者通过「节点打开哪一版 JSON、用编辑还是阅读」衔接。
每种合同都要做一份 JSON 吗？
优先做一份标准合同单，用类型联动和权限消化差异。只有口径彻底不同（例如劳动合同的字段和权限完全另一套，且不能出现在商务合同里）时，再拆 JSON 版本。自定义模板用来沉淀「标的明细」这类重复块，而不是复制整张单。
只用开源版，能不能做合同会签？
能做出可填、可校验、可提交的合同单，并接入现有会签流。若要把金额档位、按角色藏条款、阅读模式会签、移动端补意见、由表单生成库表一次配齐，需要看 FcDesigner Pro 的对应能力。
电子签章、合同编号生成要不要做进设计器？
编号和签章通常是业务系统能力，用自定义组件或远程数据接到表单上即可。不要指望设计器内置一套合同中台。设计器管字段和呈现，编号规则和签章证书仍归原系统。
如果你正在给现有 OA 换合同会签单，不必先上全量低代码。拿现行合同类型，在 FcDesigner 里搭主表和标的明细，把类型联动和三角色视图先配通，用 FormCreate 接到起草节点上。跑通销售和补充协议两种，再决定哪些变体收进同一份 JSON，哪些必须分版本。