1. Field Service 中最重要的流程是工作订单流程，以下是工作订单流程中重要的节点，如图1-1
图1-1
2. 图1-2 说明了构成工作订单流程的实体、属性和关系，本篇文章将重点围绕此图做示例介绍
图1-2
3. 工作订单流转流程如图1-3所示
图1-3
图1-4
4. 工作订单系统状态
工作订单系统状态的value值不可更改，
否则会影响系统本身关于工作订单的流转的自定义设置，
可扩展的在于其标签值，可以根据业务需求进行修改
工作订单子状态不在工作订单实体中记录，
它们与工作订单系统状态相关，并提供工作订单系统状态的更多详细信息。
工作订单子状态针对各个组织自定义创建
5. 接下来围绕工作订单的生命周期来理解工作订单的流转
5.1 工单状态----未计划
1）工单创建之初的状态即为未计划。那么，工单创建的源头在哪呢？在什么场景下需要去创建工单呢？一般而言，工单创建主要来自于以下三个方面：
①根据协议定期自动生成
②客户服务中心根据客户的来电等渠道，根据客户提供的信息生成一个case，而后根据具体的业务需要判断是否将case转换为工单
③由商机而来，按销售/日程安排
④计划外的，按现场代理或集中日程安排
2）工单创建需要完善哪些信息呢？需要根据具体的业务去判断，根据官方文档来看，首先我们需要了解工单的实体、属性和关系
①工作订单的属性
| 逻辑名称 | 说明 | 类型 |
| msdyn_customerasset | 主要事件客户资产【与报告的此事件相关的客户资产】 | lookup |
| msdyn_primaryincidenttype | 事件类型【报告的主要事件类型】 | lookup |
| msdyn_primaryincidentestimatedduration | 主要事件预计持续时间【显示解决此事件的预计时间。】 | |
| msdyn_primaryresolution | 主要解决方案 | lookup |
| msdyn_pricelist | 价目表【用于控制添加到此工作订单的产品/服务的定价的价目表。默认情况下，系统将使用在帐户上指定的价目表】 | lookup |
| msdyn_priority | 优先级【工作订单的优先级。将在安排资源时考虑】 | lookup |
| msdyn_estimatesubtotalamount | 估算小计金额【输入此工作订单的总预计帐单金额的摘要】 | |
| msdyn_totalestimatedduration | 估计的总持续时间【根据与工作订单上工作订单事件不相关的工作订单事件和工作订单服务任务的估计持续时间计算得出。应为只读。】 | |
| msdyn_functionallocation | 功能位置【工作订单的功能位置】 | lookup |
| msdyn_agreement | 协议【显示链接到此工作订单的协议。】 | lookup |
| msdyn_opportunityid | 商机【与工作订单关联的商机的唯一标识符。】 | lookup |
| msdyn_substatus | 子状态【工作订单子状态】 | lookup |
| msdyn_completedon | 完成时间【当在工作订单上使用预订时，将基于相关预订中的最新结束时间自动填充此字段。否则，将基于系统状态的变化填充此字段。】 | |
| msdyn_timegroup | 完成首选项 | lookup |
| msdyn_workorderarrivaltimekpiid | 工作订单到达时间 KPI | lookup |
| msdyn_workordertype | 工作订单类型 | lookup |
| msdyn_systemstatus | 系统状态【跟踪当前系统状态。】 | |
| msdyn_billingaccount | 记帐帐户【要记帐的帐户。如果记帐帐户已在服务帐户上设置，默认情况下将会填充它。否则，记帐帐户将与服务帐户相同。】 | lookup |
| msdyn_firstarrivedon | 首次到达时间【当在工作订单上使用预订时，将基于相关预订中的最早实际到达时间自动填充此字段。】 | |
| msdyn_serviceterritory | 服务区域【此工作订单关联到的服务区域。默认情况下，这将设置为在服务帐户上定义的服务区域】 | lookup |
| msdyn_serviceaccount | 服务帐户【要接受服务的帐户】 | lookup |
②工作订单的主要关系
③ 在工单中添加任意数量的任务、产品和服务
备注：添加产品时，切记，如果希望保留工作订单的产品，设置 已分配 为 是。
考虑使用事件类型以向您的工作订单添加更多详细信息和说明。 在从事件创建工作订
单时，产品、服务任务和特征将自动添加。 否则，在创建工作订单时，可以手动添加
[在工单中，新建事件时，选择相应的事件类型，该事件类型中的产品、服务、服务任务都会被自动添加到工单中！！]5.2 工单状态----已计划
当工作订单创建成功后，需要为工作订单预定资源，Field Service 提供标准工作订单系统状态和预订状态，两者之间存在相应的关联。
①当工单预定资源后，预定状态为“已计划”，预定成功后，工单状态即为“已计划”
②资源的预定，即日程安排，可参考图1-4
资源的预定参考的要素：
1）距离
旅行英里数更新，计算为从先前位置到预订位置（通常是工作订单位置）的行驶距离
2）客户的要求，例如客户指定某某工作人员服务
3）资源要求，即特征，表明完成该任务需要工作人员具备哪些技能等
4）要求上门时间，例如客户要求今天下午三点上门，那么要筛选满足此要求的工作人员
5）......
诸如此类，都应该作为预定资源所需要考虑的，无论是手动调派还是系统自动调派，
这一块都需要根据具体的业务需求来增加调派的影响因子③在资源预定时，相关数据会自动计算和填充，工作订单的状态会随着预定状态的变更有相应的改变。
5.3 工单状态----正在进行
此时工单状态与预定状态的对应关系如下：
工单状态 预定状态
进行中 正在旅行
进行中 正在进行
进行中 正在休息
如果单个工作订单有多个预订，且至少有一个预订正在旅行或正在进行，
相关工作订单的状态将为开启 - 正在进行。
在相关工作订单上，第一个到达时间字段将更新为预订的实际到达时间。
出行途中：
1）可预订资源预订（“预订”）的开始时间将更新为当前时间。
2）预订时间戳已创建。
正在进行：
1）实际到达时间字段将更新为从移动应用或日程安排板（而不是窗体）更改预订状态的日期和时间。
2）相关工作订单上的第一个到达时间(工作订单)字段将更新为预订的实际到达时间。
如果手动或以其他方式编辑了实际到达时间，第一个到达时间将更新。
如果有多个预订，此字段将更新为第一个预订的实际到达时间。
第一个到达时间值会考虑脱机情况，将在技术人员同步其移动数据后正确计算。
3）实际旅行持续时间字段更新，计算为预订状态处于正在旅行状态的总时间。
4）预订时间戳已创建。
在休息时：
1）预订时间戳已创建5.4 工单状态----已完成
当工作完成时，现场技术人员将预订状态更改为已完成
工单状态 预定状态
已完成 已完成
如果单个工作订单有多个预订，在所有相关预订进入已完成（包括已取消的预订）状态后，
相关工作订单的状态将为开启 - 已完成。
除工作订单系统状态更新预订状态外，反之还将触发许多流程和数据更新：
1）如果适用，使用的工作订单产品将转换为新客户资产。
这转换通过将已发布的产品记录中的转换为客户资产字段设置为是来完成。
2）如果适用，差旅费项目将被添加到工作订单产品中
3）结束时间已更新
4）正在进行的持续时间总计更新，计算为预订状态处于正在进行状态的总时间
5）总休息持续时间更新，计算为预订状态处于正在休息状态的总时间
6）总成本更新，定义为内部的资源预订成本，计算为实际旅行持续时间、
正在进行的持续时间总计和总休息持续时间的总和与资源的小时费率相乘
7）总记帐持续时间更新，计算为正在进行的持续时间总计和总休息持续时间的总和。
8）预订日记帐已创建。 预订日记帐使用时间戳来计算特定预订的工作持续时间、旅行时间和休息时间。
预订日记帐还根据可预订资源记录中定义的资源的小时费率计算内部的资源预订成本
9）预订时间戳已创建。
10）相关工作订单上的完成时间(工作订单)字段将更新为预订的结束时间。
如果手动或以其他方式编辑了预订结束时间，完成时间将更新。
如果有多个预订，此字段将更新为最后一个预订的结束时间，这意味着与工作订单相关的最近完成的预订。
完成时间值会考虑脱机情况，将在技术人员同步其移动数据后正确计算。5.5 工单状态----已发布/已取消
至5.4，现场技术人员的工作已完成，接下来就是后勤人员将检查完成的工作订单以确保数据输入正确、与客户沟通、审查调查结果等，具体取决于组织的特定业务需求。 最后一步是将工作订单系统状态更改为已结束 - 已发布
将工作订单系统状态更改为已结束 - 已发布仅由办公室工作人员在 Web 界面执行。
实际上，现成的资源安全角色不允许现场技术人员在 Field Service Mobile
应用中编辑工作订单系统状态字段
已结束 - 已发布：
预订状态不能将工作订单系统状态更改为已结束 - 已发布。
如果有任何状态为未完成或未取消的预订，将系统状态更改为已结束 - 已发布会将这些预订更新为已取消状态。
已结束 - 已取消：
如果工作订单系统状态更改为已结束 - 已取消，状态为已计划的所有预订都将更改为已取消。
如果存在正在进行的预订，您无法取消工作订单。 完成的预订保持“已完成”状态。
开启 - 未计划：
如果预订状态是取消，并且是唯一预订，工作订单系统状态将还原到开启 - 未计划。
如果多个预订中的一个被取消，工作订单系统状态将根据其余未取消的预订还原为开启 - 已计划、开启 - 正在进行或开启 - 已完成。已结束 – 已发布，将触发许多流程和数据更新：
1）为使用的工作订单产品和服务开单帐户生成发票
2）为与工作订单和预订相关的时间和材料成本创建实际记录。
确认生成的发票帐户，将创建已记帐产品和服务的实际销售额。
3）结束者字段更新
4）结束日期字段更新以上就是工作订单系统状态与预定状态之间的互动关系，这两个状态，在自定义开发中，应禁止编辑。根据业务具体需求来看，工单的创建来源是多方面的，我们可以通过协议、商机、案例、人工录入等方式。当工单创建后，相关人员需要完善工单信息，例如事件，通过事件中的事件类型自动填充工单的产品、服务、服务任务、特征等信息，即为接下来的派工完善所有的应当完善的信息，该部分将有后勤办公室人员负责。同时，我们应该避免的是，工单的操作人员与执行人员应当属于两种不同的角色和权限，现场的执行人员不应拥有操作工单状态的权限。至此，工单信息完善，进入派单环节。
派单环节即是将工作订单分派给技术人员，该环节涉及到派单规则，即我们要明确影响派单的因子，通过程序辅助选择将工单分派给最适合的资源。
当技术人员被分派工作订单后，技术人员可以选择拒绝和接受，接受自不用说，按照程序的步骤往下走即可；若是拒绝，工作订单将打回到派单池中，即工单状态变更为“未计划”。值得思考的是，技术人员拒绝派单的原因可能是各种各样的，我们需要思考的是当技术人员拒绝派单时，我们是否需要将其与kpi进行挂钩，即一定的奖惩制度，是否会影响下一次的派单呢？换句话说，拒绝是否作为影响派单的因子作为下一次派单的依据？这需要根据具体的业务来实施。
当技术人员接受派单后，技术人员需要根据派单信息来执行相应操作，例如出发去客户现场，例如某个时间点到达指定现场，例如在工作过程中由于各种原因暂停工作，或是休息，例如完成任务等，应当说，当技术人员接受派单后，程序应当记录技术人员的一系列动作包括动作发生的时间，方便为后期进行数据统计，进行kpi等提供基础。
此时，技术人员已经完成了派单工作，至此，工单状态已是“已完成”。至此，技术人员的参与结束，相干后勤办公室人员重新接管，他们需要对工单进行审查、回访等，以结束该工单。
6. 工作订单子状态
工作订单子状态存在的意义是什么？例如，当一条工单记录生成后，我们需要判断该工单是否具备派单的成熟条件。并不是每一条工单生成后调度员都可以进行派单。工单子状态的存在帮助组织用于判断额外的信息。
名称：Estimate。
系统状态：开启 - 未计划。 当现场服务组织构建估计工作订单时，通常是在将其计划给资源之前。
子状态将与开启 - 未计划系统状态相关。
默认子状态：如果您希望当工作订单的系统状态为开启 - 未计划时默认填充此子状态，则选择此项。
由于工作订单在状态时的给定系统状态是开启 - 未计划 ，此子状态会在所有新创建的工作
订单上填充，但可以手动更新。 如果全部或大部分工作订单首先源自估计，
则应将此字段设置为是，让工作订单创建者少一个手动填充的字段。
如果仅估计几个工作订单，则设置为否
下次创建工作订单时，此子状态将自动填充或在子状态查找中提供。
此子状态让调度员和其他利益干系人可以了解此工作订单“正在工作”，且未与客户达成一致。7. 预定状态与工单状态
当技术人员在执行工单时，我们需要了解，技术人员不可能在各个环节都与我们设置的参数保持一致，此时，我们需要创建更多预定状态来说明此时技术人员的状态。例如，当技术人员收到派单后出发，按系统计算，正常到达的时间为30分钟，恰逢当天节假日，路上堵车，不出意外肯定是超出了时间，此时我们需要在预定状态中加一个推迟的状态，以允许技术人员选择，告知调度员；以此类推，其实在各个环节我们都可以设置相应的预定状态以帮助技术人员更好的汇报此时此刻的动作以及原因。
值得注意的是，当我们新建预定状态时，我们需要了解其状态与工单系统状态的对应
