Some of the product’s control tables or configuration tables include a status.
In most cases, the status is simply Active / Inactive. The purpose of the status is for an implementation to be able to mark a record as no longer in use (Inactive) and prevent end users from using that control record when attempting to create a master or transaction record governed by the record.
The status is only used on “type” records that a user may have to choose from when creating a new master or transaction record. The add dialogues that prompt for the “type” will only show types that are Active. For example, when adding a new Appeal record, Appeal Types that are inactive are not included in the dropdown list.
Typically the product does not include server validation to prevent a master / transaction record from being added if the “type” record is inactive. This is only an issue when a record is not created by an online user, but rather when a record is created via an algorithm and the “type” is provided as configuration somewhere. For example, if a form rule creates an overpayment process as part of posting a form, the overpayment validation does not check that the overpayment process type is active. The expectation is that if an implementation has decided to make a record inactive, the onus is on the administrative users to checks other configuration that may reference that “type” to change the value. In this case, the admin users should update the form rule to an appropriate overpayment process type.
A status will not typically be found on a configuration object that is implemented via configuration on other objects. For example, when defining an Asset Type, the valid Asset External ID types must be defined on the Asset Type. Asset External ID Type does not have a status because if an implementation determines that a given Asset External ID Type should no longer be used, it will simply not configure any Asset Types to refer to that external id type.
Not all “type” objects have a status. This is a pattern that was established with the introduction of business object driven maintenance objects and user interface. Some older objects that were introduced earlier do not follow this pattern.
Some “type” objects use a BO lifecycle to implement the Active / Inactive states. This was a pattern followed when the business object driven maintenance objects was first introduced. In subsequent releases the current standard of a simple Active / Inactive lookup based status was introduced.
There are some cases where an administrative object may have a more sophisticated lifecycle, for example, the form type status. This occurs when the administrative object itself has some business rules that are driven by a lifecycle, for example when child records need to be finalized and cross-validated before the “type” object may be used for master / transaction records.
Copyright © 2007, 2016, Oracle and/or its affiliates. All rights reserved. Documentation build: 2.5.2016 10:21:45 [T1_1454696505000]