审批流落地：请假、报销与通用申请怎么在线化

一、审批为什么总在群里跑

几乎每家公司都有自己的审批规定，但真正执行起来，往往是这个样子：

• 员工请假先给主管发微信，主管回一句"行"，HR 那边完全不知道，月底考勤对不上，两边各说各话。
• 报销单打印出来找三个人签字，第二个人出差了，单子在他桌上压了一周；员工催也不是，不催也不是。
• 群里问"我那个申请到谁了"，没人说得清。谁签过、谁没签，全靠记忆。
• 金额和明细靠手算，算错了到财务才被发现，退回重填一遍，走的流程全部作废。
• 审批完的单据归档在文件柜或某个人的 Excel 台账里，年底想统计"哪个部门的差旅费最高"，得重新数一遍。

这些现象看着是执行不到位，根源其实是同一个：流程活在人的记忆和聊天记录里，没有被做成数据和状态。系统只能记录结果，就无法回答"现在到哪一步了""为什么卡住""当时谁批的"。

要把它做成系统，核心只有两样东西：一张申请单（数据记录什么）+ 一条审批流程（数据按什么规则往下走）。下面按落地顺序讲清楚怎么搭。

二、先分清两层：流程模板 与 申请单

这是整个方案最关键的一个设计决定，做反了后面全是返工。

平台提供的基础能力是工作流（用一份定义描述"步骤、条件、动作"，定义发布后即可执行，支持逐步骤的执行状态与失败重试，也能通过 Webhook 被外部事件触发）。在这之上，一套可复用的审批流程模板把审批场景的常见要素固化下来：节点顺序、审批人来源、或签与会签、条件规则，并把这条流程模板套到任意一张业务单据上。

这两层要分开看：

• 业务单据层：请假单、报销单、采购申请单、通用申请单。它们管的是"这件事本身的内容"——谁申请、申请什么、多少钱、多少天、附件是什么。
• 流程模板层：管的是"这件事该由谁按什么顺序点头"。同一类单据可以配多条流程模板，按金额或天数走不同路径。

分开之后有两个直接好处：

1. 改流程不动数据。 审批层级调整、审批人换人，只改流程模板，申请单上的历史内容一个字都不动。
2. 历史单据永远解释得通。 单据发起时会把当时的流程节点冻结成一份快照，之后流程模板怎么改，都不影响在途和历史单据——半年后回看，能准确说出"这张单当时走的是哪几个节点、按什么规则定的"。

三、申请单的数据怎么建

主表：一次申请活动

给 AI 构建器下指令时，可以直接把这批字段说清楚（不必逐字照抄，但字段背后的用途要交代到）：

两个容易踩的坑：

第一，必填与校验要在建表时就定死。 结束时间必须晚于开始时间、金额必须大于零、票据类申请必须传附件、休假类申请天数不能超过可用额度。这些不是"提醒一下"，而是提交时的硬校验——让错误在员工按下提交的那一刻被发现，而不是在审批人那里。额度类校验可以用申请单与其他台账表的关联实现。

第二，按类型显示不同字段。 一张通用申请表塞进所有字段，结果是请假的人面对一堆报销字段发懵。建成一个申请类型字典 + 一组按类型联动显示的字段，用户体验会完全不同。

明细子表：报销与采购类必须有

报销单、采购申请单这类单据，"一单多行"是常态，光一个总金额字段不够用——审批人需要看到钱花在哪。明细子表一行一条：费用科目或物品名称、单价、数量、金额、备注、附件。

主子表是平台原生的页面形态：主表页面下方直接挂明细表格，新增明细行自动带上主表关联。金额合计与明细行数由系统汇总回写到主表（报销单上的"合计金额""明细条数"就是这么来的），既能给审批人一眼看到总额，也能在流程条件里按金额分支。

字典先把用词统一掉

平台的数据字典能力（把下拉选项集中管理、多个模块共用一套枚举值）在审批场景里至少要建四套：

• 申请类型：请假 / 报销 / 采购申请 / 用章 / 出差 / 加班调休 / 合同会签 / 其他
• 费用科目：差旅 / 招待 / 办公 / 交通 / 通讯 / 培训 / 其他
• 请假类型：事假 / 病假 / 年假 / 调休 / 婚假 / 产假
• 驳回原因与补偿方式：给审批人和 HR 用的固定选项

用词统一是后面所有统计的前提。字典由 HR 或行政定稿后集中维护，页面上这些字段必须是下拉选择而不是自由文本输入框。字典值后续增补不影响历史数据（记录的是值编码），初期不必求全。

四、审批节点怎么配

流程模板配置页上，实际要定的是下面这几件事。建议由业务负责人和 HR 一起定稿，不要交给 IT 拍脑袋。

节点顺序：串行、条件分支、并行

• 串行：部门主管 → 分管领导 → 财务。最简单的形态，绝大多数单据够用。
• 条件分支：按单据上的字段分流。例如报销金额 2000 元以内主管批完即可，超过则增加财务复核；请假 3 天以内主管批，超过加 HR 复核。分支条件写在流程模板上，用的是申请单里已有的字段，所以字段没建对，条件就写不出来——这也是为什么要先建数据。
• 并行：财务与法务同时审，两边都通过才往下走。适用于合同会签这类需要多专业口同时把关的场景。

审批人来源：四种取法，别只会指定到人

这是最容易出错、也最影响长期可用性的一步。四种来源要按场景混着用：

1. 指定人：直接点名。只适合固定岗位的单据，人一离职流程就断。
2. 指定角色：由"角色"承接，例如"财务复核"角色下的任何人都能审。人员变动时只调角色成员，不动流程。
3. 按组织关系取：取申请人的直属主管，或逐级向上。平台的组织架构（部门树 + 用户归属）就是解析这个关系的依据，是"部门主管"这类节点最稳的做法。
4. 发起人自选：发起人在指定范围内选审批人（例如从本部门主管里选），适合跨部门临时事项。范围必须限定，否则等于没有流程。

写指令时的建议是：主流程用角色和组织关系，少用指定到人。

或签还是会签：一句话之差，结果完全不同

• 或签：节点上有多位审批人，任意一人处理即通过。适合"谁有空谁批"的常规事项。
• 会签：节点上所有人都要通过才往下走，一人驳回整单退回。适合需要集体把关的敏感事项。

这两个词必须和业务方逐条确认清楚，配置反了比没有流程更麻烦——会签配成或签，等于少了一道把关；或签配成会签，单据会莫名卡死在等人上。

驳回、撤回与加签

• 驳回：退回到发起人重新填，还是退回上一节点？建议默认退回发起人（避免在中间层来回踢），敏感单据才允许退回上一节点。
• 撤回：发起人在流程尚未推进过第一个节点时可以自行撤回修改；已经有人审过再撤回要留记录。
• 加签 / 转交：审批人休假或需要请他人会看时，允许把当前节点转给他人或加一位协办人，动作要留痕。
• 超时催办：节点停留超过设定时长自动提醒当前审批人，必要时升级提醒其上级。这类"到点自动做某事"的重复性工作，交给平台的定时任务能力，不需要人盯。

版本与默认模板

两个收尾动作不能省：

• 流程模板留版本：模板改动后新发起的单据走新版，在途单据按发起时的快照走完，互不干扰。
• 每个申请类型配一条默认模板：员工发起时不用选流程，"请假"自然走请假流程。流程模板多起来之后，这一步能省掉大量选错流程的麻烦。

五、页面怎么用：四类角色，四种视角

审批系统好不好用，取决于是否给每一类人都做了"只属于他的那一个页面"。

发起人：我的申请 + 一张表单

• 工作台或列表页看到"我提交的申请"，按状态（草稿 / 审批中 / 已通过 / 已驳回）分区。
• 表单按申请类型分组字段，草稿可暂存，提交前校验直接给提示。
• 展开任意一张单，能看到审批时间线：每个节点是谁、什么时候处理、意见是什么。这一块是减少"群里催问"最有效的功能。

审批人：待我审批的工作台

• 进入工作台第一眼是"待我审批 N 单"的角标与列表，按提交时间或紧急程度排序。
• 审批页建议左单据右决策：左侧完整展示申请内容、明细表、附件（票据图片能直接预览，不用下载）、历史审批意见；右侧是意见输入框与"同意 / 驳回 / 转交"按钮。
• 批量审批对同类型的小额单据很实用：列表勾选多条、一次通过，但金额超过阈值的不进入批量范围。
• 待办与已办分成两个列表；已办保留完整记录，随时能回查"我当时为什么批了"。

管理层与行政：统计与在途监控

• 申请量与结构统计：按部门、按月份统计各类型申请数量与金额分布，做预算执行与费用管控的依据。
• 审批效率：统计平均审批时长、各节点停留时长，找出流程里最慢的那一步——通常是某个领导节点堆了太多单。
• 在途单据监控：管理员看到所有"审批中"的单子当前卡在哪个节点、卡了多久，主动催办而不是等员工来问。

平台的报表能力支持分组小计与合计行的呈现，数据量大时用游标分页（一种逐段翻页的取数方式，比一次拉全表更稳）保证页面不卡，需要给外部审核用的报表可以直接导出。

数据可见范围：按角色授权，不靠藏页面

这是审批系统最容易出安全问题的地方。正确的做法是按"数据范围"授权，而不是把菜单藏起来：

• 普通员工：可见范围 = 本人提交的单据 ∪ 本人参与审批的单据。
• 部门主管：本部门及下属部门的单据。
• HR / 财务 / 管理员：全量可见，但操作按权限点区分（能看不一定能改）。

平台的角色与权限体系支持按模块、按操作的粒度授权，也支持按部门等维度限定可见数据范围；审批相关的核心表（用户、部门、角色）是平台的统一底座，审批模块只读取它们，不会各存一份人员名单——组织调整一次，所有流程同时生效。

六、移动端：把审批从"等人回办公室"里解放出来

审批最典型的延误场景是：单子已经在系统里了，但审批人在开会、在路上、在客户那儿，要等回办公室才批。移动端的价值不在"多一个入口"，而在把平均审批时长从"半天"压到"随手"。

PC 端构建好的审批模块会自动同步到移动端，不需要为手机单独再搭一遍。审批人在手机上的实际动线是：

1. 收到站内信或推送提醒，知道有几单待批；
2. 打开工作台，点进待办列表；
3. 打开单据，看申请内容、明细和票据照片；
4. 填写意见，点同意或驳回；
5. 单据立刻流转到下一个节点，发起人的时间线同步更新。

几个值得在建页面时就交代清楚的移动端细节：

• 列表页要能做筛选：待办按类型分组、按时间排序，手机上翻长列表很痛苦，筛选比翻页更重要。
• 票据照片直接预览：报销单最常被反复问的就是"这张票是什么"，附件在手机上要能点开看大图。
• 审批意见输入框别太小：驳回必须写理由，输入体验差会让人写出"不行"两个字。
• 抄送与知会：抄送人只读、不进审批节点，但能在消息里收到通知，用于让财务、HR 同步知晓。
• 消息触达要配置：平台的站内信与通知能力支持消息模板与多渠道发送，把"待你审批"这类模板配好，比让人天天刷系统有效得多。

发起人一侧同样在手机上受益：随手拍张发票、填个金额提交，比回到电脑前补录的准确率高得多。

七、留痕与权限：审批系统的可信度来自这里

审批数据是要拿去当凭据用的——报销凭据、请假凭据、用章凭据。所以"可追溯"不是附加功能，是这套系统能不能立住的前提。

• 操作审计日志：单据的每一次状态变更、每一个字段的改动，都能记录到操作人、时间和改动前后的值。谁把金额从 500 改成 800、谁把"驳回"改成了"通过"，事后查得到。
• 审批意见必填：驳回时强制填写理由，避免出现只有一个"不同意"、没人知道为什么的单据。
• 状态收口：一张申请单的合法路径只有有限的几条（草稿→审批中→通过 / 驳回 / 撤回），其他跳转一律禁止。任何"已经归档但没走完流程"的状态都是漏洞。
• 撤销与终止留痕：发起人撤单、管理员终止流程，都要写成一条记录，而不是让单据凭空消失。
• 组织变动预案：审批人离职或调岗时，他在途节点上的单据怎么办？上线前就要定好规则——是转交给继任者，还是由管理员代批并留说明。这件事没人提前想，出事时最乱。

八、上线前查这九件事

审批模块一旦开始拦人，配置错误会直接影响员工办事。发布前用这份清单过一遍：

1. 默认流程覆盖度：每个申请类型是不是都挂了默认流程模板？漏了的类型会发起即失败。
2. 审批人能不能解析出来：拿真实组织架构逐条试算每个节点，确认"部门主管""某角色"都能落到具体的人。解析不出来 = 单据永久卡死，这是最致命的一类问题。
3. 条件分支的边界值：造三条数据——金额刚好在分档线以下、刚好等于、刚好超过——核对走的分支是否符合约定。
4. 或签 / 会签语义复核：请业务负责人逐节点确认一遍，特别是并行节点。
5. 驳回路径试走：分别测"退回发起人"和"退回上一节点"，看状态与时间线是否正确。
6. 可见范围用小号验证：用普通员工、部门主管两个账号分别登一次，确认看不到不该看的单据。
7. 移动端真机实测：完整走一遍"收到提醒→审批→下一节点收到待办"，弱网环境下也测一次附件上传。
8. 历史数据导入：过去的请假、报销台账如果有 Excel，可以用平台的表格导入能力灌进新表，避免系统上线后出现一段数据空白期。
9. 发布预检：平台的模块发布预检会在提交发布时做一轮静态检查，把报错与警告处理干净再挂菜单，避免线上出现打不开的页面。

九、这套东西能延伸到哪里

审批流是那种"先搭一条、然后自己长出来"的模块。第一版通常只做请假加报销，数据结构立住之后，下面几个方向都很自然：

• 扩到更多单据类型：采购申请、用章借用、出差申请、加班调休、合同会签——它们共用同一个引擎和同一套申请单模板，新增一条流程模板的成本远低于第一次上线。
• 让审批结果驱动下游动作：报销通过后自动生成待付款台账、采购申请通过后自动生成采购订单、请假通过后自动写入考勤台账。这类"满足某条件就自动改另一张表"的联动由平台的规则引擎承担，配置条件和动作即可，不用写代码。
• 超时自动催办与升级：交给定时任务，按节点时长触发提醒，避免单据停在某个人手上无人过问。
• 审批效率复盘：用审批时长数据找出瓶颈节点，反过来优化流程层级——先有数据，才有优化依据。

从一张请假单开始，把这套东西跑顺，比一开始就规划"全覆盖的审批平台"要现实得多。审批流的价值不在于流程有多复杂，而在于每一张单都有据可查、每一个人都知道下一步轮到谁。