11g Release 7 (11.1.7)
Part Number E20385-07
Home
Contents
Book
List
Contact
Us
|
Oracle® Fusion Applications Materials Management and Logistics Implementation Guide 11g Release 7 (11.1.7) Part Number E20385-07 |
Home |
Contents |
Book List |
Contact Us |
 Previous |
 Next |
This chapter contains the following:
Transactional Attributes: Explained
FAQs for Define Advanced Items
Attributes that exist for each instance of an item and the values for the attributes can be different.
For example:
The number of megabytes (MB) or gigabytes (GB) of e-mail storage on a digital subscriber line (DSL) account.
The monogram text on a shirt pocket.
The color of a music player.
These attributes are defined at the item class and their attribute value is captured at the time of a transaction by downstream applications. The metadata values of these attributes are maintained at the item class. Order orchestration and order capture systems are two examples of downstream use. All transactional attributes must be associated with a value set.
The following metadata values can be defined for an attribute.
Required: Indicates whether the attribute value is required at the transaction.
Default Value: Indicates the default value of the attribute.
Value Set: Indicates the value set associated with the attribute.
Read Only: Indicates whether the attribute value is read only.
Hidden: Indicates whether the attribute is not shown.
Active: Indicates whether the attribute is active or inactive.
Transactional attributes are inherited across the item class hierarchy. The metadata is data-effective. Changes in the metadata will be reflected immediately at the item level. For example:
Any of the metadata of a transactional item attribute belonging to a specific domain, if modified in the child item class would break the inheritance. Any changes done at the parent item class for this transactional item attribute would not get inherited. Multiple records with same date range can exist if they belong to different domains. For example, the transactional item attribute Memory is associated with aDomain and order capture. Each of the domains may use a different set of metadata for its own purpose. Hence, for the same date range, two different records can exist. Only Start Dates for a transactional item attribute would be entered by a user. End date would be calculated automatically based on the next Date Effective record.
Users can modify (either Start Date and metadata) of a future effective record. Records with Starting date as Past cannot be modify or edited.
Only start dates can be set to permit updating by a user, and the end date of a record will automatically be pulled from the next record.
Any changes performed in the parent item class would be inherited by the child item class. If the corresponding record is modified in the child, then these changes will not be inherited.
Item pages provide a mechanism with which to customize the user interface.
Pages and attribute groups enable you to structure your data.
Benefits include:
You can combine and sequence attribute groups into pages.
There is no limit on the number of attribute groups associated with a page
Pages can be created at item class and are inherited down the item class hierarchy.
Attribute groups can be added to pages sequentially and based on this sequence, these attribute groups are shown in items
Attributes groups can be added for an inherited page at the child item class.
Functional Item pages are another type of special pages which are used to associate pages already created for use in the application. Application scope indicates the application which uses these pages and the usage indicates the specific use of the configured pages.
You can associate attributes for the purpose of standardization and matching, to be performed when items are created. You restrict the attributes to be processed for standardization or matching or both. Selecting Standardization allows the data quality engine to return the standardized values for these attributes. Matching allows the data quality engine to return any existing items which matches the value of these attributes and are potential duplicates.
Sequential lifecycles phases enable you to track and control the lifecycle phases of items. Each phase represents a set of tasks and deliverables that are required before promoting the item to the next phase. You can associate lifecycle phases to an item class which are created elsewhere. Lifecycle phases are inherited down the item class hierarchy and new lifecycle phases can be added to child item classes. For example, the lifecycle phases for a computer component item class might be: Concept, Prototype, Production, and Retirement.
Template is a defined set of attribute values used during item creation. When you apply a template to an item, you overlay or default-in the set of attribute values to the item definition. For example, every time users in a particular organization create new items, the attributes, as defined and approved by the organization appear in the appropriate fields. No user guesswork is required, and time is saved during the creation of items with a similar form, fit and function. Templates are created for each item class. Templates are specific to organization. Templates are inherited down the item class hierarchy. You can define both operational attributes and user defined attributes for each template.
Search formats provide a convenient way to save frequently used search criteria. Search formats created at item class will be available to all users. Search formats are always created in the context of item class. Display formats enable you to predefine search display views. You can use these views to look at different sets of item attributes that are returned by the search. Display formats created at item class will be available to all users. Display formats are always created in the context of item class.
An import format identifies the base and user-defined attributes in an item class that are imported into the application using a spreadsheet. Consequently, when you import item business entities from a spreadsheet, the items are all imported into the particular item class defined in the import format. These imported item business entities inherit all the attribute groups defined for the specific item class. You cannot edit the layout of an import format once it is created.
When you are ready to create or edit an item class, you must decide whether to allow items to be created under the item class.
To create an item class, perform the following steps:
Create a list of all items.
Classify or categorize these items (item classes).
Define any parent-child relationships (item class hierarchy).
Gather the unique types of specifications required for each type of classification at a high level (user-defined attribute groups).
Gather the unique specifications required within the group (user-defined attributes).
If there are specified values that must be used, define them (value sets and values).
Item classes can be used for classification purposes and in some case, item creation may not be allowed. By optionally setting the Item Creation Allowed attribute to No, item creation under an item class can be prevented. However, a child item class of such an item class may be allowed for item creation. For example:
This prevents items from being created in Computers and Desktops, but allows items to be created for Green Desktops and Gaming Desktops. Optionally, specify a date on which the item class will become inactive. You cannot specify an inactive date that is later than the inactive date of an item class parent, nor can you specify an inactive date that has already passed. Also, all children of a parent item class with an inactive date should be made inactive at the same time or earlier.
Attachment categories enable you to categorize and classify attachments to an item. To classify item attachments, associate attachment categories with item catalog categories. Associated attachment categories are inherited down through the item class hierarchy.
Version control allows new versions to be created for all items in an item class. An integrated workflow definition permits the creation of custom new item request definitions. This workflow definition establishes a multistep process for routing the definition and approval of items. When a new item is created, various people in the organization use the workflow to define aspects of the item, like base operational attributes, user-defined attributes, structures, attachments, categories associated, and organization assignments.
Note
Versioning an item and creating a new item request are independent of each other. Versions can be added to a new item request and routed for approval if there is a business need.
When setting up definition steps for a new item request at the item class, you can identify various item details as mandatory, at each step. Definition of entire entity can be made mandatory or just certain attributes. This ensures that the item information required for a downstream step is defined and available for use.
Required attributes can be inherited from parent and assignee access is validated.
You can control item creation, viewing and update access by assigning a role on the item class to a principal or group of users. Security allows a person or a group to have privileges to an item of item class in each organization. This is inherited and hence a person who has a privilege in a parent item class will automatically have the same privilege in the child item classes.
The item class hierarchy provides a logical classification and grouping of similar products, and also acts as a template for product definition by enabling the association and inheritance of data elements and policies that are shared by products.
To create an item class, select a parent item class on the Item Class Search Results page and select Create. Provide the required information, and optionally include additional details, such as attribute groups, pages, templates, and search and display formats.
