Work Type Specification handling and validation section

Work Type Specification associated with a Work Request MAY be updated during Work Request lifetime. However, Work Type Specification MUST NOT change in a way that is backwards incompatible with its previous version, would this result into loss of visibility of some Work Order data, or would otherwise void integrity of the existing data in the associated Work Request Status Record.

Detailed rules of Work Type Specification update handling and validation are discussed in Section 8.5

Proposed new text for the section:

5.1.2.6 Work Type Specification change constraints

Work Type Specifications stored in the "system.workTypes" repository MAY be updated at any time via Reference Data Management. However, the Implementation MUST retain internally and apply to a Work Request the version of the Work Type Specification that was used at the time the Work Request was initially created or last updated. Therefore, from Work Request perspective the associated Work Type Specification may only change when the Work Request itself is updated.

When an existing Work Request is updated, the associated Work Type Specification MUST NOT change in a way that would void integrity of the existing data in the associated Work Request Status Record or otherwise contradict the current Work Request state. Specifically, the following change constraints MUST be honored. If the constraints are violated then the Implementation SHOULD reject Work Request update with error code ILLEGAL_WTS_UPDATE (See Section 8.6).

* Existing Activities MUST NOT be removed.

* If Task Status was Closed before the update then new Activities MUST NOT be added.

* Status Category of State associated with the current Step of each existing Activity MUST NOT change.

BR, Johannes

--
Johannes Lehtinen
gsm +358 40 734 7049
Rossum Oy

ffm message