维护请求、工单任务与工单池：一组设施记录怎样分层关联

在Dynamics 365 Supply Chain Management的Asset Management资料中，维护请求首先是一条通知经理或计划人员的信息：某项资产可能需要维护或修理，但此时尚未创建工单。原文使用notes或declarations描述它，内容被认为有效之后，才可以据此形成工单。[4] 这使“有人提出一个问题”与“已有承载工作的工单”成为两个可分别保存的对象。

请求的类型也不全是一个已经确认的故障。微软在概述中列出维护请求、备注、纠正或改进、投资，以及Depot repair等类别。最后一种另有具体解释：资产从另一地点送来接受工作，完成后再送回原处。[4] 这些名称记录提出的信息属于什么情形，并没有报告实际工作已经执行。概述还将与工作人员所关联功能位置有关的请求单列为一个查看范围，其中既包括该位置的请求，也包括安装在这些位置的资产所带请求。

从请求到工单，资料给出明确的关联方向。每条维护请求只能关联一个工单；反过来，一个工单可以包含多条维护请求，即使这些请求针对不同资产。[2] 因此，按工单汇集资料时，同一行工单名称之下可能出现几个不同资产的请求。把请求条数直接当成工单条数，就会抹去原文允许的这种合并关系。这里说明的是数据关系，没有为实际设备安排工作。

工单内部又有自己的组织单位。另一份概述说，每个工单有工单类型，例如预防维护、纠正维护或检查；工单包含一个或多个work order jobs，每个任务再联系一项资产及相关任务类型，一个工单可以涉及多项资产。[1] 工单类型描述整张单所属类别，任务则把具体工作联系到资产。资产本身可以是机器或机器部件，也可以处在层级结构中并关联功能位置。资产层级与工单任务清单由此不是同一份树形目录。

资料同时保留了工单之间的联系和独立性：一个工单可以关联另一个工单，任务类型也可能含有后续工作；不过，文档说各工单一般没有相互依赖，可以各自改变生命周期状态并分别排程。[1] “一般”是这里的重要限定。记录上有关联，并不自动意味着所有关联工单只能一起变化；这段概述也没有给某一企业的实际工单证明依赖关系。

工单池再在工单外面增加一层集合。微软列出的分组依据包括工作班组、技能类别、物理地点，以及一周或其他时间安排。同一个工单可以进入多个工单池。[3] 这些集合依据可以同时存在：按地点整理与按班组整理，并不要求把原工单复制成两个独立工作对象。技能类别中的电工和管道工是资料举例，不是对某位工作人员资质的认定。

池的记录还有编号、名称和Active状态；池内列出的工单可带Sort order，表达组内次序。文档关于Delete work order relations的说明，则将被移除的对象写成工单与池的关联行，并举保留空池、以后再放入其他工单的情形。[3] 因而，池内不再列出某工单，与工单本体被删除，是两个不同命题。请求提供待处理信息，工单和任务联系资产，工单池按共同特征组织已有工单，三层分别回答不同的记录问题。本文只解释公开文档的对象关系，不执行软件设置、维修、采购或载荷计算；页末日期为更新日期，首次发布日期未确认。