付款申请表单设计器方案：FcDesigner 如何承接付款类型、金额档位与审批角色
流程管理系统里，付款申请是那种「看着简单、越做越复杂」的单据。申请人选一个付款类型，后面跟着的字段、要挂的合同发票、要走的审批层级就全变了：货款要关联采购合同和到票，服务费要关联验收，预付款要算比例，保证金要盯退回条件。金额过了一档，还要多走一级审批。
这些如果写死在流程里，每加一种付款类型、每调一个金额档位，就要改前端、改流程、重新发版。把这张单交给 FcDesigner 做可视化设计、交给 FormCreate 做动态渲染，付款类型和金额档位就从代码和流程分支里抽出来，变成配置。
FcDesigner 和 FormCreate 在流程里分别干什么
FcDesigner 是基于 Vue 的低代码可视化表单设计器。实施在画布上拖组件、配校验、配联动，输出 JSON。开源即可搭出付款单结构，公式、角色权限、生成 SQL 等见 FcDesigner Pro 文档。
FormCreate 是动态表单渲染器。发起、审批、财务、出纳各节点加载同一份 JSON。流程引擎仍管谁在哪个节点打开、走哪条分支；表单管这张单长什么样、谁能填哪一项。
对付款申请来说，这个拆分很关键：付款规则（类型、档位、关联单据）属于业务配置，审批流转属于流程引擎。表单 JSON 存起来，流程节点只决定「此刻谁来打开、以编辑还是阅读打开」。
付款申请真正难的不是字段多，是它随类型和金额变
典型付款申请第一版通常长这样：申请人、部门、付款类型、金额、收款方、事由、审批意见。上线之后，几乎一定会出现这些变化：
- 付款类型从「货款 / 服务费」扩成预付款、保证金、退款，每种要补不同字段、挂不同单据。
- 金额分档：低于某档部门批，超过某档财务批，再高要高管会签。档位一调，流程分支要改。
- 货款要挂采购合同和发票，服务费要挂验收单，预付款要算比例——关联单据不同，校验也不同。
- 收款方要对公账户，户名、账号、开户行要校验，不能手输错一位。
- 财务要核发票和科目，出纳只看可付的部分，申请人看不到这些。
如果这些都写死在页面和流程里，维护权锁在前端和流程配置上，财务调一个档位也要找开发排期。
一张付款申请单怎么配
1. 先定结构：主表 + 收款与关联单据
主表放一次付款只出现一次的信息：申请人、部门、付款类型、金额、币种、事由、付款方式。收款方单独成组：户名、账号、开户行。关联单据另成一组：合同号、发票号、验收单号。
FcDesigner 支持栅格、表格布局，也支持子表单和分组。付款单适合「上主表、中收款、下关联」，审批和打印都更清楚。开源设计器即可搭出这一层结构，后面的档位判断和角色切分是 Pro 更合适的位置。
2. 付款类型一变，后面的字段跟着变
这是付款申请里最不该写死在页面里的部分。
| 付款类型 | 需要出现的字段 | 要挂的单据 |
|---|---|---|
| 货款 | 采购合同号、到票金额、税率 | 采购合同、发票 |
| 服务费 | 服务合同号、验收结论、服务周期 | 服务合同、验收单 |
| 预付款 | 合同总额、预付比例、预付金额 | 合同、预付款条款 |
| 保证金 | 保证金用途、退回条件、到期日 | 协议、收据 |
| 退款 | 原收款凭证、退款原因 | 原支付记录 |
在 FcDesigner 里用条件显示和数据联动配：选货款才出现采购合同号，选预付款才出现预付比例，选退款才出现原收款凭证。预付款再算一层：合同总额乘比例得预付金额，用公式算，不手填。
3. 金额档位驱动审批，不是写死在流程里
付款审批的层级基本由金额决定。档位不该散落在流程图的每个分支里，而应挂在单上：金额超档，表单就提示「需财务会签」或「需高管审批」。
FcDesigner Pro 的公式按字段引用，内置 SUM、ADD、IF 以及角色判断函数 HAS_ROLE、HAS_PERMISSION。条件必填也挂在逻辑上：选预付款必须填比例，选退款必须填原收款凭证。
分寸要守：公式负责填报当时的可见计算和提示，付款最终是否放行仍归财务和出纳。表单设计器不是资金系统，但能把「金额超档」「关联单据不齐」挡在提交之前。
4. 关联单据要校验，不能付款无凭据
付款申请和报销最大的不同，是它通常要挂凭据：合同、发票、验收单。这些不能只靠上传附件，还要能被校验。
合同号做成远程数据带出：输入合同号，带出对方、合同金额、已付、未付，付款金额不能超过未付余额。发票金额和付款金额要对上。服务费没有验收结论就不能提交。用自定义组件或远程数据接到字段上，而不是把合同台账复制进表单。
5. 同一张单，申请人、财务、出纳三种样子
付款申请最容易被做成「一张大表所有人都能改」，然后靠口头约定「财务那几项你们别动」。约定一定会破。更稳的做法是同一份 JSON，按角色控制显隐、禁用、必填。FcDesigner Pro 支持预置权限树和角色树，运行时注入 $roles、$permissions。
| 角色 | 能看见 | 能编辑 | 打开方式 |
|---|---|---|---|
| 申请人 | 类型、金额、收款方、关联单据 | 提交前可改；打回后按节点开放 | 编辑 |
| 部门主管 | 申请内容、金额、是否超档提示 | 通常只开审批意见 | 阅读模式 + 意见 |
| 财务 | 以上 + 发票、科目、核销状态 | 只开核销相关字段 | 阅读模式 + 核销区 |
| 出纳 | 收款方、金额、付款方式 | 只开付款执行和凭证 | 阅读模式 + 付款区 |
阅读模式是这一步的配套：审批、财务、出纳不复制详情页，同一套规则切换查看态。设计器里的「组件操作权限」和运行态的「角色权限」要分开配，别把「只有管理员能设计表单」当成「出纳不能改金额」。
6. PC 设计，移动端审批，落到库表
付款审批常发生在手机端：主管在路上批，出纳不在工位。FcDesigner Pro 把 PC 端规则在移动端渲染为 Vant 风格，不必维护两套单。手机上只保留金额、付款类型、审批意见和凭证查看，财务科目和收款方明细留在 PC。
设计稿要落到库表。FcDesigner Pro 可按字段生成建表 SQL，主表一张、关联单据和收款方各一张，生成结果人工确认后再执行。JSON 按版本存：哪次付款用的是哪一版规则，要能回放。
这条链路怎么接到现有流程引擎里
不改流程引擎，先把付款单从代码里拆出来。
业务先出规则，再进设计器。 付款类型枚举、金额档位、关联单据校验、谁能看收款方，写成一页规则。规则不定，拖组件只会把混乱可视化。
用 AI 表单助理出第一版，人再改。 把「付款申请：主表 + 收款方 + 按付款类型联动 + 金额档位」描述给 AI 表单助理，生成初始结构，实施再补校验、角色、公式。
JSON 入库，流程节点只负责打开方式。 发起节点编辑态，审批节点阅读模式，财务节点核销区，出纳节点付款区。流程仍用现有 BPM 或 Flowable 一类引擎。
标准组件先用满，个性字段再扩展。 日期、金额、下拉、上传、子表覆盖主体；合同带出、账户校验、发票识别用自定义组件或远程数据接入。「收款方三件套」可以做成自定义模板，避免每张付款单从零搭。
先验证开源，再决定 Pro。 开源 FcDesigner 已能拖拽、校验、布局、输出 JSON；档位公式、角色权限、移动端、生成 SQL、AI 助理，是把付款闭环收干净时更常落到 Pro 的能力。
这样做之后，流程侧真正少掉的工作
开发不再为「加一种付款类型」或「调一个金额档位」开迭代。字段、联动、档位、提示在设计器改，JSON 发布后下一次打开即生效。
财务可以自己定档位和校验，画布上当场能试：金额超档，高管审批提示出不出来；选预付款，比例字段该不该必填。
申请、审批、财务、出纳不再分叉成四套页面。阅读模式让各节点共用规则，减少「申请是一版、财务看到的是另一版」的事故。
移动端审批不必另做一套表。同一份规则按端渲染，路上的人和工位上的人用的是同一张单。
以上是典型场景里可预期的分工变化，不是某家客户的实施报告。具体能少几人天，取决于你们现在有多少付款变体写在代码里。
常见问题
FcDesigner 能替代付款流程引擎吗？
不能。FcDesigner 管单长什么样、谁能填哪一项、档位怎么判。谁批、几级批、超时谁来，仍是流程引擎的事。两者通过「节点打开哪一版 JSON、用编辑还是阅读」衔接。
付款申请为什么不适合写死在页面里？
付款类型、金额档位、关联单据会随业务持续变。写死在页面里，每次变化都要改前端和流程、重新发版。用表单设计器后，变化落在 JSON 配置上，流程节点保持稳定。
金额档位和流程分支有什么区别？
档位是业务规则，挂在单上做提示和校验；流程分支是流转路径。把档位做成配置，流程图保持简单，调档位不用重画流程。
只用开源版能不能做付款申请？
能做出可填、可校验、可提交的付款单，接入现有审批流。档位公式、按角色藏字段、移动端审批、生成库表这些一次配齐，需要看 FcDesigner Pro 的对应能力。
收款方账户校验怎么做？
对公账户校验用自定义组件或远程数据接到字段上，户名、账号、开户行做格式校验，必要时对接银行或主数据。设计器管字段和校验，账户数据仍归财务主数据。
如果你正在给流程管理系统换付款申请，不必先上全量低代码。拿付款类型枚举和金额档位，在 FcDesigner 里搭主表和收款方，把类型联动和档位判断配通，用 FormCreate 接到发起节点上。跑通货款和服务费两种类型，再决定哪些变体收进同一份 JSON，哪些必须分版本。