Revising Existing Business Objects

The ability to create revisions can be granted or denied depending on the object's state and the session context. For example, let's assume you are an editor working on a cookbook. A cookbook is composed of Recipe objects. Recipe objects are created by the Chef who writes the recipe, perhaps in the description field of the object. He then promotes the Recipe to the "Test" state, where he makes the dish and tastes it. At this point, he either approves it and sends it to the next state (perhaps "Submitted for Cookbook"), reassigning ownership to you (the editor), or he may want to revise it by incorporating different ingredients or varying amounts. Therefore, the "Test" state would have to allow revisions by the owner. The Recipe object could then be revised, the new revision starting in the first state of the lifecycle. Once the Recipe is approved, revisions should not be allowed; so, the "Submitted for Cookbook" state would not allow revisions.

To maintain revision history, the new object should be created with the revise businessobject command even though it is possible to create what looks like a new revision by manually assigning a revision designator with the Add or Copy Businessobject command. However, you can add existing objects to a revision chain, if necessary. For more information, see About Revision Sequences.

This table shows the differences between using the revise businessobject and copy businessobject commands. For more information, see MQL Command Reference: Revise Business Object.

Differences/Similarities between Clones and Revisions
Property	Copy or Clone	Revision
Attributes	Values are initially the same but can be modified as part of the clone command.	Values are initially the same but can be modified as part of the revise command.
Files	Files can optionally be copied to the Clone upon creation when the copy command specifies to do so.	Files are referenced from the original unit until it is necessary to copy them when the revise command specifies to do so.
	For more information, see MQL Command Reference: Handling Files.
Connections to other objects	Depends on the Clone Rules (Float, Replicate, One) set by the Business Administrator.	Depends on the Revision Rules (Float, Replicate, None) set by the Business Administrator.
Connection to Original	No implicit connection.	Implicit connection can be viewed in Revision chain.
History	The create entry shows the object from which it was cloned. If you copy an object using MQL, you can optionally include the original object's history log.	The create entry shows the object from which it was revised and original shows that it was revised.

Not all business objects can be revised. If revisions are allowed, the Policy definition can specify the scheme for labeling revisions. This scheme can include letters, numbers, or enumerated values. You could have revisions with labels such as AA, 31, or "1st Rev."

If the REVISION_NAME is omitted, the app automatically assigns a designator based on the next value in the sequence specified in the object's policy. If there is no sequence defined, an error message results.

If there is no defined revision sequence or if you decide to skip one or more of a sequence's designators, you can manually specify the desired designator as the REVISION_NAME.