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

MT-Workflow面向 Odoo 的可视化审批工作流引擎针对odoo17、18、19在 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 的价值就会明显体现出来。九、落地建议实施时不要一开始就把流程做得很复杂。更稳的方式是先配置一条最小流程只包含一个审批节点验证按钮绑定、发起审批、处理审批和查看日志再加入办理、抄送和分支条件再启用提醒、超时、加签和转签最后评估是否启用审批通过后自动执行原按钮。同时要遵守几个维护原则一个流程定义只负责一个清晰业务场景同一按钮的多套流程必须用启动条件清晰区分流程说明里要记录业务规则、适用范围和变更原因生产流程调整前先在测试库跑完整链路使用 HR 指派时要确保员工、用户、部门、岗位和汇报线数据完整。结语MT-Workflow 的重点不是“多做一个审批中心”而是把审批变成 Odoo 原生业务动作前后的可配置控制层。它让业务人员继续在熟悉的单据上操作让管理员用流程定义和 BPMN 设计器控制审批链路让审批记录、通知、日志和实例都留在 Odoo 系统内。对于那些已经把销售、采购、库存、财务、合同等业务放在 Odoo 里的企业来说这种嵌入式审批方式比外置流程更自然也更容易形成可追踪、可维护、可扩展的业务闭环。