Modifying the State of a Business Object

The Approve Businessobject command provides a required signature. When a state is defined within a policy, a signature can be required for the object to be approved and promoted into the next state. You provide the signature with the Approve Businessobject command.

The Approve Businessobject command provides a single approving signature. This command does not necessarily mean that the object will be promoted to the next state. It only means that one of the requirements for promotion was addressed. Depending on the state definition, more than one signature might be required.

For example, to approve an object containing an application for a bank loan, you might write this Approve Businessobject command:

approve businessobject "Car Loan" "Ken Brown" A 
   signature "Loan Accepted" 
   comment "Approved up to a maximum amount of $20,000";

In the example, a comment was added to provide additional information regarding the approval.

Use the Ignore Businessobject command to bypass a required signature. In this case, you are not approving or rejecting the signature requirement. Instead, you are specifying that this required signature can be ignored for this object.

In a policy definition, states are created to serve the majority of business objects of a particular type. You might have some business objects that do not need to adhere to all of the constraints of the policy. For example, you might have a policy for developing software programs. Under this policy, you could have objects that contain programs for customer use and programs for internal use only. In the case of the internal programs, you might not want to require all of the signatures for external programs. Instead, you might be willing to ignore selected signatures.

The Ignore Businessobject command controls a single signature. An object is promoted to the next state automatically when all requirements are met if the state was defined with the Promote clause set to true. By ignoring a single signature, it does not necessarily mean that the object will meet all of the requirements for promotion to the next state. It only means that one of the requirements for promotion was circumvented. Depending on the state definition, another user or condition might be required to promote the business object.

For example, assume you have a simple inventory program to track one group's supplies. The program is highly specialized for internal use and will not be used outside the company. According to the policy governing the object, the company president's signature is required before the program can enter the Released state for business objects outside the company. Because no one wants to bother the president for a signature for this program, you decide to bypass the signature requirement with the following Ignore Businessobject command. (The user must have privileges to do this.)

ignore businessobject "Software Program" "In-house Inventory" III 
   signature "Full Release" 
   comment "Signature is ignored since program is for internal use only"

In this example, the comment provides the reason for the bypass is clearly defined so that users understand the reason for the initial bypass of the signature.

The Reject Businessobject command provides a required signature thatsignature is prevents an object from being promoted to the next state.

The Reject Businessobject command provides a single signature. However, this signature does not necessarily mean that the object will be demoted or completely prevented from promotion to the next state. It only means that one of the requirements for promotion was denied. Depending on the state definition, another user might be able to override the rejection.

For example, a bank manager may decide that more clarification is required before approving a car loan. The user can enter this information by writing the following Reject Businessobject command:

reject businessobject "Car Loan" "Ken Brown" A
   signature "Loan Accepted"
   comment "Need verification of payoff on student loan before
      I'll approve a loan up to a maximum amount of $20,000";

The comment lets other users see the reason for the rejection. Since the signature was provided, the object cannot be promoted unless someone else overrides the signature or the reason for rejection is addressed.

The Unsign Signature command is used to erase signatures in the current state of an object. Any user with access to approve, reject, or ignore the signature has access to unsign the signature.

For example, this command unsigns the signature for the "Complete" state for the Engineering Order 000234 1 object:

unsign businessobject "Engineering Order" 000234 1 
   signature Complete;

Errors will occur under the following conditions:

• Attempts to unsign a signature not yet assigned.
• Attempts to unsign all signatures if all are not signed. Any that are signed; however, will be unsigned.
• Attempts to unsign a non-existent signature.
• Attempts to unsign a signature without access.

The Disable Businessobject command holds an object in a particular state indefinitely. The business object cannot be promoted or demoted from that state. Even if all of the requirements for promotion or demotion are met, the object cannot change its state until the state is enabled again.

For example, this command disables an object containing a component design for an assembly:

disable businessobject "Component Design" "Bicycle Seat R21" A 
   state "Initial Release";

Disabling a businessobject does not affect the current access. Any user with access can continue to work on the object in that state.

The Enable Businessobject command reinstates movement of an object. When a business object is in a disabled state, it cannot be promoted or demoted from that state. If you then decide to allow an object to be promoted or demoted, you must re-enable it using the Enable Businessobject command.

When an object is first created, all states are enabled for that object. If a manager or other user with the required authority decides that some states should be disabled, the user can prevent promotion with the Disable Businessobject command. After the command is processed, an object will remain trapped within that state until it is enabled again.

Enabling an object does not have an effect on the remaining states. For example, the Testing state could be disabled at the same time the Initial Release state was disabled. When the Initial Release state is enabled, the object can be promoted into the Testing state. However, once it is in this new state, it again can no longer be promoted or demoted. It will remain in the Testing state until it is enabled for that state.

For example, assume Component Design is disabled. All of the conditions for an Initial Release state have been met and the manager decides it is ready for promotion into the Testing state. Before the object can be promoted; however, it must be enabled. The manager can run the following command:

enable businessobject "Component Design" "Bicycle Seat R21" A state "Initial Release";

The object is enabled and available for promotion or demotion.

The Override Businessobject command turns off the signature requirements and lets you promote the object. Since a policy is a generic outline that addresses the majority of needs, it is possible to have special circumstances in which a user, such as a manager, could decide to skip a state rather than have the object enter the state and try to meet the requirements of the state. This is done using the Override Businessobject command.

For example, assume you have a component that has undergone cosmetic changes only. This component is needed in Final Release although the policy dictates that the component must go through Testing before it can enter that state. Because the changes were cosmetic only, the manager might decide to override the Testing state so that the users can access the component sooner. This could be done by entering a command similar to:

override businessobject "Component Design" "Bicycle Seat R21" state Testing;

If the object is currently in the Initial Release state and a promotion would place it in the Testing state, the override businessobject command promotes the object directly from the Initial Release state into the Final Release state.

The Promote Businessobject command moves an object from its current state into the next state. If the policy specifies only one state, an object cannot be promoted.

The order in which states are defined is the order in which an object will move when it is promoted. If all of the requirements for a particular state are met, the object can change its state with the Promote Businessobject command.

An object cannot be promoted if:

• Its current state is disabled.
• The signature requirements were not met or overridden (ignored).
• There are no other states beyond the current state.

For example, the following command would promote an object containing an application for a bank loan:

promote businessobject "Car Loan" "Ken Brown" A;

The Demote Businessobject command moves an object from its current state back to its previous state. If the policy has only one state or is in the first state, an object cannot be demoted.

If an object reaches a state and you determine that it is not ready for that state, you would want to send the object back for more work. An object cannot be demoted if:

• The current state is disabled.
• The signature requirements for rejection were not met or overridden (ignored).
• There are no other states prior to the current state.

For example, assume you have a component that has undergone cosmetic changes only. The manager decides to send it into Final Release without sending it through testing. Now the manager finds out that the new paint trim might weaken the plastic used in the seat. Therefore, the manager decides to demote the object back into the Testing state. This could be done by entering a command similar to:

demote businessobject "Component Design" "Bicycle Seat R21" A;