一、什么是 Workflow（工作流）？
可以把 Workflow（工作流）理解成一张“审批路线图”。
一张单据从创建到完成，通常不会一步到位，而是会经过几个阶段：
-
State（状态）：单据当前停在哪一步
例如：Draft（草稿）、Pending Manager Approval（待经理审批）、Pending Finance Approval（待财务审批）、Approved（已批准）、Rejected（已驳回） -
Transition（流转）：让单据从一个 State（状态）走到另一个 State（状态）的动作
例如：Submit（提交）、Approve（批准）、Reject（驳回）、Withdraw（撤回）
以采购订单为例：
Draft（草稿）
-- Submit（提交） -->
Pending Manager Approval（待经理审批）
-- Approve（批准） -->
Pending Finance Approval（待财务审批）
-- Approve（批准） -->
Approved（已批准）
Pending Manager Approval（待经理审批）
-- Reject（驳回） -->
Draft（草稿）一句话理解：
State（状态）是单据停在哪一步，Transition（流转）是单据怎么走到下一步。
二、ERPNext Workflow（工作流）的一个关键限制
ERPNext 的 Workflow（工作流）是按 Document Type（单据类型） 生效的。
也就是说：
同一个 Document Type（单据类型），同一时间通常只能启用一套 Workflow（工作流）。
例如：
如果你给 Purchase Order（采购订单） 设置了一套审批流程，那么所有公司使用 Purchase Order（采购订单）时，默认都会走这一套流程。
ERPNext 标准 Workflow（工作流）本身不是按 Company（公司）分别隔离的。
这意味着：
- 公司 A 的 Purchase Order（采购订单）要走这套流程
- 公司 B 的 Purchase Order（采购订单）也要走这套流程
- 不能简单地给公司 A 和公司 B 各自启用一套完全独立的 Workflow（工作流）
对于单公司来说，这通常不是问题。
但如果是多公司，而且每个公司的审批规则不同，就需要额外设计。
三、国内企业实际怎么用？
模式一：OA 审批 + ERPNext 补录
这是国内企业比较常见的做法。
审批在企业微信、钉钉、飞书等 OA 系统里完成，ERPNext 主要负责后续的财务、库存、采购、销售等数据落地。
例如：
- 请购审批在 OA 完成
- 付款审批在 OA 完成
- ERPNext 里只录入 Purchase Order（采购订单）、Purchase Invoice（采购发票）、Payment Entry（付款记录）等单据
适合场景：
- 中小企业
- 老板习惯在手机上审批
- 公司已经有成熟 OA 系统
- ERPNext 主要用于财务、库存、采购、销售存档
优点：
- 员工接受度高
- 老板审批方便
- ERPNext 配置压力小
缺点：
- 审批记录和 ERPNext 单据不完全在一个系统里
- 后期如果要做审计追溯，需要打通 OA 和 ERPNext 数据
模式二：ERPNext 内全流程审批
所有审批都在 ERPNext 里完成。
例如：
Purchase Order（采购订单）创建后，经过：
Draft（草稿）
→ Pending Manager Approval（待经理审批）
→ Pending Finance Approval（待财务审批）
→ Approved（已批准）适合场景：
- 外资企业
- 财务主导 ERP 实施的企业
- 对审计合规要求较高的企业
- 希望审批记录全部留在 ERPNext 里的企业
优点：
- 数据完整
- 审批记录清晰
- 权限、流程、单据状态统一
缺点：
- 前期设计要求更高
- 员工需要适应 ERPNext 的操作方式
- 流程如果设计太复杂，容易影响使用体验
模式三：混合模式
这是我更推荐的一种方式。
业务审批可以放在 OA 系统里完成，ERPNext 只在关键节点做控制。
例如：
- OA 负责日常审批
- ERPNext 负责金额上限校验
- ERPNext 负责预算余额校验
- ERPNext 负责供应商、付款、库存等关键数据校验
- ERPNext 只在重要单据上启用简单 Workflow（工作流）
这种方式比较适合国内企业。
因为很多公司已经习惯用企业微信、钉钉、飞书审批，如果强行把所有审批都搬到 ERPNext 里，用户接受度不一定高。
更现实的做法是：
OA 负责“人找人审批”，ERPNext 负责“系统规则校验”。
四、多公司场景怎么处理？
如果是多公司，而且每个公司的审批规则不同，可以考虑下面几种方案。
方案 A：使用 Condition（条件）
在 Workflow Transition（工作流流转）里，有一个字段叫：
Condition（条件）
可以在里面写 Python 表达式，用来判断当前这个 Transition（流转）是否可用。
例如：
doc.company == "Company A"意思是：
只有当当前单据的 Company（公司）等于 "Company A" 时，这个 Transition（流转）才会显示或生效。
实际例子：
doc.company == "Shenzhen Yuan Technology Co., Ltd."这种方式适合：
- 公司数量少
- 审批规则差异不大
- 只是某些按钮、某些步骤不同
优点：
- 不需要开发
- 直接在 ERPNext 界面里配置
- 上手快
缺点：
- 公司一多，Condition（条件）会越来越复杂
- 所有公司的 State（状态）和 Transition（流转）都混在一套 Workflow（工作流）里
- 后期维护容易出错
简单理解：
小差异可以用 Condition（条件），大差异不要硬塞在一套 Workflow（工作流）里。
方案 B：使用 Server Script（服务器脚本）
ERPNext / Frappe 提供 Server Script（服务器脚本）功能。
可以通过 Document Event（文档事件） 类型的 Server Script（服务器脚本），在单据保存、提交、取消等动作发生时，按 Company（公司）做额外校验。
例如：
- 公司 A 的采购订单超过 10 万必须经理审批
- 公司 B 的采购订单超过 5 万必须财务审批
- 某些公司不允许直接提交
- 某些公司必须填写指定字段后才能提交
这种方式适合：
- 不想改代码文件
- 规则比 Condition（条件）复杂
- 需要在保存或提交时做强制校验
优点：
- 不需要开发自定义 App
- 可以在系统界面中维护
- 比 Condition（条件）更灵活
缺点：
- 脚本多了以后也需要管理
- 不适合特别复杂的审批体系
- 对实施人员的技术能力有一定要求
方案 C：自定义 App
如果多公司审批规则非常复杂，推荐使用自定义 App 来处理。
思路是：
-
给 Workflow（工作流）增加一个自定义字段
例如：For Company（适用公司） -
根据单据上的 Company（公司），匹配对应公司的 Workflow（工作流）
-
控制哪些 Transition（流转）按钮可以显示
-
控制用户实际点击审批按钮时，是否允许执行
这种方式通常需要在自定义 App 的代码里处理。
常见会涉及：
hooks.pyget_transitionsapply_workflow- 权限判断
- 公司匹配逻辑
适合场景：
- 多公司数量较多
- 各公司审批规则差异很大
- 需要每个公司维护独立 Workflow（工作流）
- 对长期维护有要求
优点：
- 结构清晰
- 各公司流程互不干扰
- 适合长期维护
缺点：
- 需要开发
- 需要测试
- 后续升级 ERPNext 时要注意兼容性
简单理解：
规则简单，用 Condition（条件）；规则复杂，用自定义 App。
五、Condition（条件）里公司名称怎么填？
在 Condition（条件）里写：
doc.company == "某个公司名称"这里的 doc.company 取的是 Company（公司）这个 DocType（单据类型）里的 Name（名称 / 主键） 字段。
不是你随便写的显示名称，也不是简称。
确认方法：
- 打开 ERPNext
- 进入 Company（公司）列表
- 打开对应公司
- 看页面 URL 最后一段
- 或者看列表里的 Name（名称） 字段
例如，Company（公司）的 Name（名称）是：
Shenzhen Yuan Technology Co., Ltd.那么 Condition（条件）就应该写：
doc.company == "Shenzhen Yuan Technology Co., Ltd."如果写错了，Condition（条件）就不会生效。
六、Workflow（工作流）设计不要太复杂
ERPNext 的 Workflow（工作流）更适合按 Role（角色）来设计，而不是按某一个具体的人来设计。
例如，不建议这样设计：
张三审批 → 李四审批 → 王五审批 → 赵六审批更建议这样设计：
Department Manager（部门经理）
→ Finance Manager（财务经理）
→ General Manager（总经理）这样做的好处是：
- 人员变动时，不需要频繁修改 Workflow（工作流）
- 只需要调整用户的 Role（角色）
- 流程更稳定
- 权限更清晰
七、实用分级原则
| 风险级别 | 推荐方式 |
|---|---|
| 低风险单据 | 1 级审批，甚至免审批，重点是留痕 |
| 中风险单据 | 2 级审批，按 Role（角色）分工 |
| 高风险单据 | 加强关键节点控制，例如金额阈值、预算校验、付款校验 |
例如：
低风险
办公用品采购、小额费用报销。
可以只做简单审批，甚至只做记录。
中风险
常规采购订单、普通付款申请。
可以设置部门经理和财务经理两级审批。
高风险
大额采购、大额付款、固定资产采购、合同付款。
可以增加：
- 金额阈值
- 预算余额校验
- 指定 Role（角色）审批
- 必填附件
- 付款前校验
八、常见错误做法
错误一：流程设计太复杂
有些企业一开始就想把所有特殊情况都放进 Workflow（工作流）里。
结果流程变成：
员工提交
→ 主管审批
→ 部门经理审批
→ 财务专员审批
→ 财务经理审批
→ 副总审批
→ 总经理审批
→ 董事长审批看起来很严谨，实际很难用。
最后用户不愿意录单，审批人也不愿意点。
错误二：按人设计，而不是按 Role（角色）设计
不要把 Workflow（工作流）设计成某个人专属审批。
应该尽量用 Role（角色）。
例如：
推荐：
Purchase Manager（采购经理）
Finance Manager（财务经理）不推荐：
张三
李四因为人会变，Role（角色）相对稳定。
错误三：把 OA 的复杂流程原样搬进 ERPNext
很多国内企业的 OA 流程非常复杂。
如果原样搬到 ERPNext，往往会导致：
- 配置复杂
- 用户难用
- 维护困难
- 出问题不好排查
更好的方式是：
OA 继续做复杂审批，ERPNext 只做关键控制和数据落地。
九、总结建议
| 场景 | 建议方案 |
|---|---|
| 单公司 | 直接配置 Workflow（工作流） |
| 多公司，但规则一致 | 使用同一套 Workflow（工作流），统一 Role（角色） |
| 多公司，规则有少量差异 | 使用 Condition（条件）控制 Transition（流转） |
| 多公司，规则差异复杂 | 使用自定义 App 按 Company（公司）匹配 Workflow（工作流） |
| 企业已有 OA 审批 | OA 做审批，ERPNext 做录入、存档和关键校验 |
| 审计要求高 | 尽量在 ERPNext 内完成完整 Workflow（工作流） |
十、一句话建议
ERPNext Workflow（工作流）不要一开始就设计得太复杂。
更实用的思路是：
小企业重在简单可用，中型企业重在角色清晰，大型或多公司企业重在规则分层。
对于国内企业来说，比较稳妥的做法是：
OA 负责日常审批，ERPNext 负责财务、库存、采购、销售等核心数据落地，并在关键节点做规则校验。
这样既符合国内企业的使用习惯，也能发挥 ERPNext 在业务数据和财务管理上的价值。