Manage Transactional Attributes

A transactional attribute is an attribute that gets its value during a transaction at runtime instead of during setup at design time. Use it when you can't predict what value the attribute will have at runtime.

What makes a transactional attribute different from other types of attributes is that a transactional attribute doesn't usually have a set of predefined values. Instead, the value of a transactional attribute is often different for each transaction, and you usually don't know what that value is until your end user does the transaction.

Here are some examples where you might want to use a transactional attribute:

Greeting cards. The text is unique each time that you have a transaction for that item.
Digital artwork. Your customer uses a color picker to pick a color for the item from over 16 million different values.
Auto service. You record the mileage and the license plate number each time you service your customer's car. The mileage is unique for each transaction. The license plate number is unique for each customer.
Window shades. The height and width of each shade is unique for each customer.

An application that's downstream of the Product Information Management work area captures the value for the transactional attribute during the actual transaction. For example, Oracle Order Management is a downstream application. Let's say you sell configurable greeting cards where your customer can select different card sizes, style, artwork, font, the greeting, and so on. The Order Entry Specialist, an end-user, creates a sales order in Order Management, adds a greeting card to an order line, and uses a transactional attribute to enter a unique greeting that the customer dictates. The greeting is different for each card.

Use a transactional attribute when you can't predict what value the attribute will have at runtime, or when maintaining values for it isn't realistic. In the digital art example, you could theoretically create a list of values that contains the 16,777,216 possible color values, but that's not realistic. Instead, consider each of those values as unique, and use a transactional attribute to capture it at runtime.

Sometimes you have to make a judgment call on whether to use a transactional attribute. In the window shade example, assume you sell shades in 1/8" increments, from 8 inches up to 120 inches wide. Instead of using a transactional attribute for the width, you could use an inches attribute and a fractions attribute. The list of values for the Inches attribute would contain 112 values, and the list of values for the Fraction attribute would contain 8 values. That's a realistic scenario.

Note

You must associate each transactional attribute with a value set.
You specify a transactional attribute on the item class.

You use the item class to specify attributes for the transactional attribute. Here are some of the attributes of a transactional attribute.

Attribute	Description
Required	Specify whether the downstream application must include a value for the transactional attribute.
Default Value	Specify the default value of the transactional attribute.
Value Set	Value set that you can use with the transactional attribute.
Read Only	Specify whether the downstream application can only read the transactional attribute or can change its value too.
Hidden	Specify whether to show or hide the transactional attribute.
Active	Specify whether the attribute is active or not active.

A transactional attribute is also known as a transactional item attribute, or TIA. They mean the same thing.

Inheritance

Transactional attributes are inherited across the item class hierarchy. If you change the parent item class, then the child item class immediately inherits that change. For example:

Metadata of a transactional item attribute is part of a domain. If you modify the metadata in the child item class, then you'll break the inheritance. Any change you make at the parent item class for the transactional item attribute won't 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 a Domain and order capture. Each of the domains may use a different set of metadata for its own purpose. So, two different records can exist for the same date range. You would enter only a start date for a transactional attribute. Product Information Management will automatically calculate the end date according to the next Date Effective value.
You can modify the Start Date or the metadata of a future effective record. If the starting date has already occurred, then you can't modify the record.

Pages and Attribute Groups

Use pages and attribute groups to structure your data.

Combine and sequence attribute groups into pages.
There's no limit on the number of attribute groups that you can associate with a page
Create a page for an item class and inherit it further down in the item class hierarchy.
Add an attribute group to pages sequentially. Use the sequence to determine how to display attribute groups in an item.
Add an attribute group for an inherited page in a child of the item class.

A Functional Item page is another type of page that you can use to to associate a page in the application. The application scope identifies the application that uses these pages.

Data Quality

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.

Lifecycle Phases

Sequential lifecycle 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.

Templates

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 and Display Format

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.

Import Format

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 can't edit the layout of an import format once its created.