工作状态示例

示例

首先，用户在模型中输入数据。

• 此示例将使用实体成员“L1”的子项数据。

• 未设置锁定，因此可以随意输入数据。

锁定由所有者设置

1. 所有者“TestUserE”可以设置其自有实体“L9100”，并设置父项级别非所有者维成员“2017 年 1 季度”。

2. 但是，所有者无法查看实体“L9100”和“2017 年 1 季度”的当前状态，因为该状态扩展到非所有者维的子成员（未存储非所有者维的父成员）。

3. 所有者可以按照叶成员“2017 年 1 月”查看单个状态。

所有者必须按顺序设置控制者工作状态。上载可设置为“提交”，而非“流水账”，因为“上载”后的下一工作状态为“提交”。

反之亦然：所有者无法设置无序的控制者所有者工作状态。不能将“流水账”设置为“已开始”，因为此设置违反了两项规则：

• “流水账”之前的状态为“提交”。因此，该设置为唯一有效选择。

• “上载”是控制者为管理者工作状态，并且介于“提交”和“已开始”工作状态之间。所有者不能跳过由管理者控制的工作状态。

锁定由管理者 1 设置

由于第一个状态是控制者所有者状态，此状态定义为开启（未设置锁定），因此，下一步是让管理者进入“上载”的锁定状态。

1. 作为“TestUserD”登录，即“L9100”的管理者（“L9000”的所有者）。

2. 请不要在数据区域选择“包括所有子项”。作为管理者，只要状态设置成控制者为管理者，您就可以更新单个成员的状态

3. 在设置锁定后，无法更新数据，因为此状态锁定手动数据输入。

锁定由管理者 2 设置

1. 作为“TestUserrC”登录，即“LD1”的管理者（“L9000”的所有者）。

2. 尝试为 “L9000” 的特定子项（例如，“L9100”）设置控制者为管理者工作状态

   • 只有直接父项可以设置单个子项。出现错误：User is not an owner/manager, work status cannot be updated。

   • 如果在数据区域中选择“包括所有子项”，那么可以设置所有子项（多级别设置）。

控制者规则

1. 父项“L9000”设置为未设置锁定。

2. 如果父项所有者试图将工作状态设置为“批准”，则此设置违反控制者规则，因为批准是“管理者”工作状态。出现错误：The Controlledby rule is violated。

自下而上规则

• 父项“L9000”设置为未设置锁定。

• 子项“L9100”设置为上载；其他子项设置为“无”。

1. 父项“L9000”的所有者试图将工作状态设置为已开始，控制者为所有者。

2. 此操作失败，因为违反了自下而上规则：父项的状态不能高于其子项。出现错误：The Bottom-up rule is violated。

推式 1

• “L9000” 是父项所有者（管理者），可以在数据区域中使用“包括所有子项”设置其所有子项的工作状态。

1. 管理者可以跳过工作状态，但这些工作状态的控制者必须是管理者。

2. 如果管理者选择的工作状态的控制者是所有者，那么此操作违反控制者规则。

3. 如果用户设置的工作状态既不是特定成员或特定成员子项的所有者，也不是这两项的管理者，那么会出现错误：User is not an owner/manager, work status cannot be updated。

推式 2

• “L9000” 是父项所有者（管理者），可以在数据区域中使用“包括所有子项”设置其所有子项的工作状态。

  • 当选择“包括所有子项”时，不设置父成员工作状态。

  • 仅“L9000”的父项（“LD1”）可以设置控制者为管理者的工作状态。

反转

• 假设为“2017 年 1 季度”（一月、二月和三月）批准了“LD1”的所有子项。

1. 子成员的所有者不可设置低于其父成员的工作状态。否则，会违反“自下而上”规则。

2. 父成员可以将状态反转为任何控制者为管理者的工作状态。

所有区域必须符合规则

• 假设为“2017 年 1 季度”（一月、二月和三月）“LD1”的所有子项都设置为批准。

1. 父成员将一月份的所有叶成员都设置为未设置锁定。

2. 父成员将其他月份设置为批准。

3. 一个维的所有者试图将 1 季度设置为已开始。该设置将失败，因为其违反一月的自下而上规则。