Viseq
用户指南审批、待办与通知

处理任务、审批与工作交接

分别安排通用任务、处理原业务审批和阅读通知,核对负责人、决定与原业务结果。

需要审批的业务,应先在原业务提交真实申请,由相应审批人作出决定,再回原单据处理后续。审批通过、通知已读和业务完成是不同结果。

业务申请在原单据提交,按适用流程形成审批待办,当前审批人核对后决定,结果回原业务,再办理采购付款等后续;通知阅读独立于业务完成

谁负责什么

岗位工作内容需要核对的结果
业务申请人准备并提交真实业务单据,说明申请依据原单据状态、关联审批及后续动作
当前审批人核对业务内容、提交版本、当前节点和处理意见本人决定、节点和整体审批结果
审批配置人员配置已发布模板、适用条件并预览后续申请采用的流程,历史审批不被改写
接手业务人员在原采购、销售、财务等入口继续执行订单、付款或其他实际业务结果
通知接收人阅读消息,按需进入原对象消息阅读状态与原对象当前状态分别明确

查看权限、审批权限、模板配置权限和原业务权限分别核对。管理员或“全部审批”查看者不自动成为任何节点的审批人。

按当前工作阅读

“待我审批”是分配给本人的审批队列;通知中心的“任务”分类是消息分类,不是一份可以代替所有业务状态的统一完成清单。现场任务、财务待处理等继续在各自业务入口办理。

“流程模板”“适用条件”“审批预览”是同一配置页的并列入口,可按当前目标进入。确需按条件分流时,先发布正确模板,再发布相应策略,使用实际条件预览,最后从原业务提交并核对采用的流程;预览和配置保存都不产生一笔真实业务审批。

完成时看两个结果

先看审批记录是否有最终决定、对应处理意见和历史,再看原业务是否已应用结果、是否还有明确后续动作。采购申请批准后仍可能等待创建采购订单,付款申请批准后仍未发生出款。

消息已送达或已读不能替代这些检查。结果同步中或来源无法核实时,先读原记录并明确接手人,不重复提交来消除等待状态。规则与 FAQ集中解释边界。

Last updated on

On this page