MT-Workflow：面向 Odoo 的可视化审批工作流引擎

在 Odoo 项目里，审批常常不是一个孤立功能。

销售订单要确认，采购订单要下单，报价单要发送，费用、合同、付款、库存调整都可能需要先经过内部审核。业务人员真正关心的也不是“系统里有没有一个审批菜单”，而是：当他在原来的业务单据上点击那个熟悉的按钮时，系统能不能自动判断这件事是否需要审批；需要审批时，能不能把流程跑起来；审批结束后，能不能继续执行原来的 Odoo 业务动作。

MT-Workflow 解决的正是这个问题。它是一套面向 Odoo 的高级审批与工作流控制层，把 Odoo 原生业务按钮、BPMN 可视化设计器、审批任务、办理任务、抄送、提醒、超时、流程历史和实例追踪整合在一起，让审批真正嵌入业务，而不是飘在业务之外。

一、它不是另一个 OA，而是 Odoo 内部的工作流控制层

很多审批系统的入口是独立的：用户先去 OA 或审批中心提交申请，审批完成后，再回到 ERP 做业务操作。这种方式能解决“有人审批”的问题，但很容易和业务单据脱节。

MT-Workflow 的思路不一样。它直接运行在 Odoo 内部，围绕真实业务模型、原生按钮、用户、员工、部门、岗位和消息系统来构建流程。

比如销售订单上的“发送”“确认”，采购订单上的“确认订单”，或者其他模型上的 Object Button，都可以被工作流接管。用户仍然在原来的业务单据上操作，系统在按钮执行前判断是否需要审批：

• 如果不需要审批，原按钮照常执行；
• 如果需要审批，先启动工作流；
• 审批通过后，可以让用户手动重试原按钮，也可以由系统自动执行原业务方法；
• 如果自动执行失败，系统记录失败原因，管理员可以继续排查和接管。

这意味着 MT-Workflow 控制的不是一个额外的“审批按钮”，而是 Odoo 原生业务动作的执行时机。

管理员配置流程时，需要明确目标业务模型和触发按钮方法名。例如销售订单确认通常对应 action_confirm，报价发送可能对应 action_quotation_send。流程定义保存启用时，系统会校验业务模型和按钮方法是否存在，避免把流程绑定到错误入口。

二、一个流程定义，描述一个真实业务场景

MT-Workflow 的基础配置对象是“流程定义”。一个流程定义通常对应一个清晰的业务场景，例如：

• 销售订单确认审批；
• 高金额报价发送审批；
• 采购订单确认审批；
• 合同法务审核；
• 付款前财务复核。

流程定义里会配置工作流名称、相关业务模型、优先级、是否启用、触发按钮类型、触发按钮名称、启动条件、审批通过后行为、是否自动跳过已审批人，以及工作流说明。

其中有两个字段很关键。

第一个是启动条件。它使用 Odoo 域表达式来判断某条业务单据是否应该进入该流程。例如：

[('state', 'in', ['draft', 'sent'])]

表示只有草稿或已发送状态的单据才进入审批。

再比如：

[('amount_total', '>=', 10000)]

表示金额达到 10000 以上时才进入审批。

如果同一个模型、同一个按钮配置了多套流程，就必须用启动条件区分，并尽量让条件互斥。更具体的流程可以设置较小优先级数字，兜底流程设置较大优先级数字。

第二个是审批通过后行为。上线初期通常建议使用“审批通过后手动重试”：审批完成后，用户回到业务单据，再点一次原按钮。这样更稳，尤其适合原业务按钮会弹窗、依赖当前上下文、或包含复杂交互的场景。等业务按钮逻辑足够简单、流程也稳定后，再评估启用“审批通过后自动执行”。

三、用 BPMN 设计器把审批链路画出来

MT-Workflow 的核心体验之一，是通过 BPMN 可视化设计器编排流程。管理员和实施顾问不需要把所有审批逻辑写死在代码里，而是可以通过节点、连线和条件把真实业务流程搭出来。

审批节点：谁来同意，几个人同意才算通过

审批节点是最常用的节点。它用于生成审批任务，并决定当前节点需要谁审批、采用什么审批模式、是否允许加签、是否允许上传附件。

审批模式主要有两类。

单人审批或任一审批人：只要任意一名审批人同意，节点就继续向下走。它适合主管审批、多个候选人中任一人确认、轻量放行等场景。

会签：当前节点有多个审批人，需要满足一定通过条件后才能继续。会签可以配置“最小通过人数”。例如 3 位评审人中只要 2 人同意即可继续；如果最小通过人数留空，则表示所有审批人都要同意。

审批节点还可以允许加签。加签适合审批人临时拉入法务、财务、技术专家或其他负责人补充意见。需要注意的是，如果会签节点已经设置了“最小通过人数”，加签只是扩大当前节点可参与审批的人，并不会自动提高原来的通过门槛。例如原本 3 人会签，最小通过人数为 2，后来加签 1 人，系统仍然按累计 2 人同意即可通过来判断。

办理节点：不是审批，而是让人把事情办完

办理节点用于生成办理任务。它和审批节点不同，审批节点回答的是“同意还是拒绝”，办理节点回答的是“这件事是否已经处理完成”。

它适合让申请人补充资料、让业务人员更新单据、让某个部门完成检查、让专人在线下处理事项等场景。

办理节点可以设计成阻塞或非阻塞。阻塞办理表示必须等办理完成后，流程才继续向下走；非阻塞办理则更像并行通知或辅助任务，不阻断主流程继续流转。

抄送节点：让相关人员知道，但不要求处理

抄送节点用于把流程信息发送给相关人员。它不会要求接收人审批，也不会要求接收人办理，只是让他们知道这条流程发生了什么。

它适合管理层知会、相关部门同步、财务备案、项目成员了解进度等场景。和办理节点相比，抄送不承担流程推进责任。

分支节点：根据业务条件走不同路径

真实审批经常不是一条直线。低金额订单可能只需要直属主管审批，高金额订单还要财务复核；普通客户走标准流程，重点客户需要销售总监确认。

这类逻辑可以用分支节点处理。

排他分支表示多条路径中只走一条。它适合“金额超过多少走 A，否则走 B”“特定客户走特殊审批”“不同部门走不同路径”等场景。

排他分支必须设置默认流。默认流是兜底路径：当所有条件都不满足时，流程会走默认流继续向下执行。

并行分支表示多条路径同时执行。它适合销售、财务、法务同时评审，或者多个部门并行检查的场景。并行拆分和并行汇聚通常要成对使用：前面拆出去几条会执行的路，后面就要把这些路收回来。

这里有一个重要限制：排他分支的互斥路径不要直接接入同一个并行汇聚节点。因为排他分支只会执行其中一条路，而并行汇聚会等待所有进入路径完成，这样可能导致流程卡住。

四、人员配置：固定人、用户组、岗位、汇报线

审批节点和办理节点都需要配置处理人。MT-Workflow 支持多种人员来源：

• 指定用户：直接选择一个或多个 Odoo 用户；
• 指定用户组：从某个 Odoo 用户组解析处理人；
• 按职位/范围查找：根据员工职位和部门范围查找；
• 按汇报线查找：沿着发起人的上级关系查找处理人。

固定负责人审批，可以用指定用户。由权限组统一维护的审批人，可以用指定用户组。按岗位找人，比如财务经理、部门负责人、区域销售经理，可以用职位和范围。找直属上级、上上级，则适合用汇报线。

这让同一个流程既能支持简单固定审批，也能支持和 HR 组织架构联动的动态审批。

五、用户侧体验：原按钮上就能看到审批状态

对普通业务用户来说，MT-Workflow 的一个重要优点是入口自然。用户不需要离开业务单据，也不需要先去找某个独立审批应用。

流程启用后，相关业务按钮会出现工作流状态标识。不同状态对应不同提示：有的表示流程可发起，有的表示审批运行中，有的表示历史中已有退回或拒绝记录。用户点击标识可以查看对应流程图或审批状态。

移动端也可以查看审批任务和流程状态。用户可以在手机上处理待办、查看详情、提交意见，并通过底部操作区完成同意、拒绝、转签、加签等动作。

网页端的胶囊操作栏会把流程状态、流程名称、审批动作集中呈现出来，方便用户在业务单据里直接处理当前任务。

移动端也提供类似操作入口，让用户在小屏幕上仍然能完成审批动作。

转签：把当前任务交给别人处理

转签用于把当前审批任务转给其他人。用户可以选择是否“同时转签当前工作流实例中的后续任务”。如果勾选，系统会把当前流程后续任务也自动转签给选中人员。

加签：临时拉入新的审批人

加签用于拉入某个人一起审批。它适合当前审批人认为还需要其他部门、专家或负责人参与判断的场景。

对于会签节点，要特别理解加签和最小通过人数的关系：加签不会自动提高原节点的通过门槛。业务上如果希望加签人必须参与决策，流程设计时就不要把最小通过人数设置得过低。

历史与流程图：审批过程留痕

用户可以查看审批历史，按历史审批人或流程名进行模糊搜索，也可以打开流程图查看当前流程走到了哪里。

网页端流程图支持查看流程结构和运行轨迹，有助于业务人员理解当前卡在哪个节点，也方便管理员排查问题。

六、通知、提醒与超时处理

审批系统不只是生成任务，还要提醒人及时处理。MT-Workflow 支持 Odoo 站内通知、邮件通知和 Chatter 消息，并且可以配置节点到达通知、截止时间提醒、重复提醒和超时动作。

超时配置会在任务创建时计算截止时间。时间单位可以是分钟、小时、自然日或工作日。自然日包含周六周日；工作日按当前逻辑跳过周六周日，但不读取完整企业考勤日历，也不识别国家法定节假日。

超时后动作可以是只记录日志、自动同意、自动拒绝或转交给其他处理人。正式业务中要谨慎使用自动同意和自动拒绝，重要流程更适合使用超时转交或只记录日志，避免无人处理时自动放行业务风险。

提醒和超时不是用户打开页面时实时触发，而是由 Odoo 定时任务检查。常见定时任务包括：

• Workflow: Process Timed-out Approval Tasks：处理审批任务超时；
• Workflow: Process Timed-out Handling Tasks：处理办理任务超时；
• Workflow: Send Pending Task Reminders：发送节点提醒；
• Workflow: Send Pending Digest：发送待办汇总邮件。

因此提醒时间可能会受 cron 执行频率影响，有几分钟偏差是正常的。

七、管理员侧：实例追踪、异常接管和人员替换

流程上线后，管理员需要能够看到所有流程实例，知道每个实例来自哪张业务单据、当前状态是什么、自动执行是否成功、有哪些审批项、办理项、抄送项，以及流程日志里发生了什么。

实例详情里可以查看流程运行记录和日志。审批被拒绝、超时处理、自动执行失败、任务取消等关键事件都应该留下痕迹，方便后续审计和排查。

必要时，管理员可以取消未结束流程。取消会关闭未处理任务和提醒事项，所以生产环境要谨慎操作。

另一个重要能力是批量人员替换。企业里经常会遇到员工离职、长期休假、岗位调整、部门重组等情况。如果流程定义或运行中实例还保留着旧人员，就可能导致审批卡住。

批量人员替换可以处理待审批任务、待办理任务、待抄送事项、实例级转办规则、流程定义中的固定用户，以及运行中实例快照中的固定用户。执行前建议先备份数据库，在测试库验证，并优先选择少量实例试运行。

八、适合哪些业务场景

MT-Workflow 适合那些“业务动作本身在 Odoo 里，但执行前需要经过审批控制”的场景。

典型例子包括：

• 销售订单确认前审批；
• 报价发送前审批；
• 高金额订单增加财务复核；
• 采购订单确认前审批；
• 合同提交法务审核；
• 付款前多级审批；
• 特殊库存调整审批；
• 跨部门并行评审；
• 需要抄送、办理、提醒和超时转交的复杂流程。

如果只是非常简单的固定审批，普通规则型审批模块也许足够。但如果审批链路需要和 Odoo 原生按钮绑定，需要复杂分支、会签、办理、抄送、提醒、超时、历史追踪和管理员接管，MT-Workflow 的价值就会明显体现出来。

九、落地建议

实施时不要一开始就把流程做得很复杂。更稳的方式是：

1. 先配置一条最小流程，只包含一个审批节点；
2. 验证按钮绑定、发起审批、处理审批和查看日志；
3. 再加入办理、抄送和分支条件；
4. 再启用提醒、超时、加签和转签；
5. 最后评估是否启用审批通过后自动执行原按钮。

同时要遵守几个维护原则：

• 一个流程定义只负责一个清晰业务场景；
• 同一按钮的多套流程必须用启动条件清晰区分；
• 流程说明里要记录业务规则、适用范围和变更原因；
• 生产流程调整前，先在测试库跑完整链路；
• 使用 HR 指派时，要确保员工、用户、部门、岗位和汇报线数据完整。

结语

MT-Workflow 的重点不是“多做一个审批中心”，而是把审批变成 Odoo 原生业务动作前后的可配置控制层。

它让业务人员继续在熟悉的单据上操作，让管理员用流程定义和 BPMN 设计器控制审批链路，让审批记录、通知、日志和实例都留在 Odoo 系统内。对于那些已经把销售、采购、库存、财务、合同等业务放在 Odoo 里的企业来说，这种嵌入式审批方式比外置流程更自然，也更容易形成可追踪、可维护、可扩展的业务闭环。