OA差旅报销表单设计器方案：FcDesigner 如何承接联动、计算与权限

OA 差旅报销适不适合用可视化表单设计器，结论可以先说清楚：适合，而且往往比把报销单写死在页面里更经得住改。

一张差旅报销单要同时满足三件事：员工能填完、主管能看懂、财务能核销。字段会随交通方式、出差类型、职级标准变；金额要能合计、能折算、能判断是否超标；同一张单在员工、主管、财务眼里还不能长一样。把这些写进前端模板，第一次能上线，第二次改规则就要排期。把这些交给 FcDesigner 做可视化设计、交给 FormCreate 做动态渲染，改的是配置，不是发版窗口。

本文按典型 OA 差旅报销场景来写，不引用未公开的客户名称和实施数据。流程引擎仍由 OA 自己承担，FormCreate 与 FcDesigner 承接的是表单这一层：采集、校验、计算、按角色呈现。

FcDesigner 和 FormCreate 在 OA 里分别干什么

检索「OA表单设计器」时，容易把设计和运行混成一个词。在 FormCreate 体系里，这两件事是拆开的。

FcDesigner 是基于 Vue 的低代码可视化表单设计器。实施或开发在画布上拖组件、配校验、配联动，输出 JSON。开源即可拖出报销单结构，公式、角色权限、生成 SQL 等见 FcDesigner Pro 文档。

FormCreate 是动态表单渲染器。流程发起页、审批页、详情页加载同一份 JSON，就能渲染、收集、校验、提交。设计一次，多处使用。

对 OA 差旅报销来说，这个拆分很关键：报销规则属于业务配置，审批流转属于流程引擎。表单 JSON 存起来，流程节点只决定「此刻谁来打开这张单、以编辑还是阅读打开」，不必为每个节点再做一套页面。

FormCreate 项目自 2018 年开源，官方介绍历经多次框架重构，GitHub 星标超过 7000。产品由西安锦强未来科技有限公司的 FormCreate 团队维护。这些是公开产品事实，用来判断它是不是「临时封装的拖拽页」足够了。

差旅报销真正难的不是字段多，是它会变

典型中后台里，差旅报销单第一版通常长这样：

• 申请人、部门、出差事由、起止日期、目的地
• 交通方式、费用明细、发票附件、合计金额
• 主管意见、财务核销

上线三个月后，几乎一定会出现这些变化：

1. 交通方式从「飞机 / 火车」扩成高铁、网约车、自驾，每种要补不同凭证字段。
2. 市外出差和海外出差分叉：海外要币种和汇率，合计要折人民币。
3. 财务要会计科目、是否超标、核销状态；员工端不能看见，更不能改。
4. 补贴按天数和职级走，标准一调，写死的计算就要改代码。
5. 领导在手机上批，员工在手机上补发票，PC 上那张密密麻麻的表直接缩小不可用。

如果这些都在 .vue 里用 v-if 和手写计算堆起来，维护权就锁在前端排期上。OA 管理员改不了，业务也等不起。可视化表单设计器要解决的，就是把「变」从代码里搬到配置里。

一张差旅报销单怎么配

下面按一张能跑完报销闭环的表来配，不写接入代码，只把业务结构落到 FcDesigner 能承接的能力上。

1. 先定结构：主表 + 费用明细

主表放一次出差只出现一次的信息：申请人、事由、类型、日期、目的地、交通方式。费用明细用子表或分组：交通、住宿、餐补、其他，每行有日期、金额、发票。

FcDesigner 支持栅格、弹性盒子、表格等布局，也支持子表单和分组。报销单适合「上主表、下明细」：主表用栅格对齐，明细用表格或子表，财务打印和阅读模式都更清楚。

开源设计器即可搭出这一层结构。后面的合计、超标判断、按角色藏字段，是 Pro 里公式计算和角色权限更合适的位置。

2. 交通方式一变，后面的字段跟着变

这是报销单里最常见的数据联动，也是最不该写死在页面里的部分。

交通方式	需要出现的字段	需要的凭证
飞机	航班号、舱位、出发/到达机场	行程单、登机牌或电子发票
高铁 / 火车	车次、座位类型	铁路电子客票
自驾	起止里程、过路费、油费或能源费	发票、通行记录
海外行程	币种、汇率、人民币合计	外币发票及折算说明

在 FcDesigner 里，这些用条件显示和数据联动配：选飞机才出现航班号，选自驾才出现里程。不必为每种交通方式做一张独立表单，也不必在流程里拆成多条分支只为了多几个字段。

海外行程再加一层：外币金额 × 汇率，用公式折成人民币后再进入合计。公式写在字段上，汇率调整不用改页面。

3. 金额不要人口算，让公式算

报销争议很少出在「事由写得不好」，更多出在合计不对、补贴口径不一致、超标没有提前标出来。

典型计算可以全部做成字段公式，而不是提交后再让后端「再算一遍才算数」——后端仍要做最终校验，但填的时候就该让员工看见结果。

• 明细合计：对费用明细金额做 SUM
• 出差天数：结束日期减开始日期，再按你们是否含当天的口径取整
• 补贴：天数 × 补贴标准
• 报销总额：明细合计 + 补贴（再按是否含税决定口径）
• 是否超标：总额与职级标准比较，超标则提示或阻断提交

FcDesigner Pro 的公式按字段引用，用法接近表格函数，内置 SUM、ADD、IF 以及角色判断函数 HAS_ROLE、HAS_PERMISSION。条件必填也可以挂在公式或逻辑条件上：选了飞机就必须填航班号，有住宿费就必须上传发票。

这里有个实施上的分寸：公式负责填报当时的可见计算；财务制度和发票真伪仍归审核和财务系统。表单设计器不是费控中台，但可以把费控规则的「第一道显示」做在单上，减少退回。

4. 同一张单，三种角色三种样子

差旅报销最容易被做成「一张大表所有人都能看见」，然后靠口头约定「财务那几项你们别填」。约定一定会破。

更稳的做法是同一份 JSON，按角色控制显隐、禁用、必填。FcDesigner Pro 支持在设计器里预置权限树和角色树，运行时注入当前用户的 $roles、$permissions，逻辑条件和公式就能判断。

典型切法：

角色	能看见	能编辑	打开方式
员工	出差信息、明细、发票、自己的合计	提交前可改；打回后按节点再开放	编辑
主管	员工已填内容、合计、是否超标提示	通常只开「审批意见」；金额默认禁用	阅读模式 + 意见
财务	以上全部 + 会计科目、核销状态、超标处理	只开核销相关字段	阅读模式 + 核销区

阅读模式是这一步的配套能力：审批和归档不再复制一张「详情页」，同一套规则切换查看态。员工改字段、主管看字段、财务补核销，页面还是那一套。

设计器里的「组件操作权限」和运行态的「角色权限」不是一回事。前者管谁能在画布上改组件，后者管谁打开表单时能看见、能改哪一项。OA 实施要把两件事分开配，避免把「业务授权」做成「只有管理员能设计表单」。

5. PC 上设计，手机上也能填

差旅发生在路上。补发票、看审批，很多人第一入口是手机。

FcDesigner Pro 支持把 PC 端设计的表单规则在移动端渲染为 Vant 风格。实施上不必维护两套报销单：PC 负责把明细和发票一次填完，移动端保证「补一张发票、看一眼进度、主管点同意」走得通。多端不是把 PC 表单缩小，而是同一份规则按端呈现。

字段仍要克制。手机上不要把会计科目和职级标准表一起塞进去；用角色权限把财务区藏掉，移动端会干净很多。

6. 设计稿要能落到库表，而不是只落到截图

OA 报销单最终要入库、要导出、要对账。只把 JSON 存成配置不够，明细行还得有表。

FcDesigner Pro 可以根据当前表单字段生成建表 SQL，也可以对比历史结构生成变更语句。主表一张、明细一张，和「上主表、下子表」的设计是对齐的。生成结果需要人工确认后再执行，尤其是必填与 NOT NULL、字段改名与历史数据。它减少的是「前端改完了，后端还在等表结构」的空档，不是取代 DBA。

JSON 本身建议作为表单版本来存：哪次审批用的是哪一版规则，要能回放。这和库表是两件事：库表存业务数据，JSON 存当时的表单定义。

这条链路怎么接到现有 OA 里

不改流程引擎，也能先把报销单从代码里拆出来。典型交付顺序如下。

业务先出规则，再进设计器。 把交通方式枚举、补贴口径、超标是否允许提交、财务可见字段，写成一页规则。规则不定，拖组件只会把混乱可视化。

用 AI 表单助理出第一版，人再改。 把「差旅报销：主表 + 费用明细 + 按交通方式联动 + 合计」描述给 AI 表单助理，让它生成初始结构，实施再补校验、角色和公式。第一版不求完美，求把字段讨论变成可以点的画布。

JSON 入库，流程节点只负责打开方式。 发起节点用编辑态渲染，审批节点用阅读模式，财务节点打开核销区。流程仍用现有 OA 或 Flowable 一类引擎。FormCreate 官方站点也展示过与工作流结合的开源后台，说明这是常见接法，而不是让表单设计器去当 BPM。

标准组件先用满，个性字段再扩展。 日期、金额、上传、下拉、子表，设计器内置组件就能覆盖报销的主体。部门选择、职级带出补贴标准、发票识别，用自定义组件或远程数据接入。FcDesigner 支持自定义组件和自定义模板，可以把「费用明细三列」做成可重复拖入的模板，避免每个子公司的报销单从零搭。

先验证开源，再决定 Pro。 开源 FcDesigner 已经能拖拽、校验、布局、多语言、输出 JSON，用来证明「报销单可以配置化」足够。公式计算、角色权限、阅读模式、PC 到移动端、生成 SQL、AI 助理，是把典型报销闭环收干净时更常落到 Pro 上的能力。开源和 Pro 不是两套世界观，是同一条设计-渲染链路上深度不同。

这样做之后，OA 侧真正少掉的工作

收益不要用空口径讲，回到报销这条线。

开发不再为「加一个舱位字段」开迭代。字段、联动、提示文案在设计器改，JSON 发布后下一次打开表单即生效。

财务和人事可以参与定字段，而不只是提需求等还原。画布是共同语言：这个字段给员工看还是给财务看，当场就能试。

审批页和填报页不再分叉。阅读模式让详情、审批、归档共用规则，减少「填报是一版、审批是另一版、对不上」的事故。

移动端补交材料不必另做一套表。同一份规则按端渲染，路上的人和工位上的人用的是同一张单。

以上是典型场景里可预期的分工变化，不是某家客户的实施报告。具体能少几人天，取决于你们现在有多少报销变体写在代码里。

常见问题

FcDesigner 是什么？和 FormCreate 有什么区别？

FcDesigner 是可视化表单设计器，FormCreate 是动态表单渲染器。前者产出 JSON，后者消费 JSON。OA 差旅报销里，设计器给实施和开发改单，渲染器给流程页面用单。

OA 差旅报销为什么不适合把表单写死在页面里？

因为报销规则会随交通方式、地域、职级、财务科目持续变。写死在页面里，每次变化都要改前端、回归、发版。用表单设计器后，变化落在 JSON 配置上，流程节点保持稳定。

只用开源版，能不能做差旅报销？

能做出可填、可校验、可提交的报销单，并接入现有审批流。若要把合计公式、按角色藏财务字段、阅读模式审批、移动端补发票、由表单生成库表这些一次配齐，需要看 FcDesigner Pro 的对应能力。

表单设计器能替代 OA 流程引擎吗？

不能，也不该。FcDesigner 解决「单长什么样、谁能改哪一项、金额怎么算」。谁批、几级批、超时谁来，仍是流程引擎的事。两者通过「节点打开哪一版 JSON、用编辑还是阅读」衔接。

差旅报销表单设计器要不要按子公司各做一套？

优先做一份标准报销单，用联动和权限消化差异。只有口径彻底不同（例如海外公司会计科目完全另一套）时，再拆 JSON 版本。自定义模板可以沉淀「费用明细」这类重复块，而不是复制整张单。

如果你正在给现有 OA 换差旅报销单，不必先上全量低代码。拿现行规则在 FcDesigner 里搭主表和明细，把交通方式联动和合计先配通，用 FormCreate 接到发起节点上。跑通一张单，再决定哪些变体收进同一份 JSON，哪些必须分版本。