| Oracle® Retail Merchandising System Custom Flex Attribute Solution Implementation Guide Release 16.0 E84911-04 |
|
 Previous |
 Next |
| Oracle® Retail Merchandising System Custom Flex Attribute Solution Implementation Guide Release 16.0 E84911-04 |
|
Previous |
Next |
Adding attributes to different entities within RMS is one of the most common customizations. Some attributes are added just for reporting purposes, and some for integrating with other systems, and some for driving processing in RMS. This chapter describes how you can plan and organize the CFAS attributes. It also provides information on the process for creating attributes during an implementation and maintaining attributes when they have been implemented. It includes the following sections:
Before you started adding attributes in the system, you must first set up a plan to structure the attributes and determine how they will be created. When structuring the attributes, you must ensure that they are organized in a manner that makes sense from a business process perspective. For example, combining the attribute groups and attributes together that will be maintained by the same resources in to the same attribute group sets. You must also organize it in such a way that allows for future growth and updates of attributes based on the business changes, especially since there are limits at the group set and attribute level.
Entities are the functional areas in RMS with which the CFAS is associated. In the current release, the following functionalities (entities) are pre-enabled and support addition of new attributes:
Supplier
Store
Physical Warehouse
Virtual Warehouse
Department
Class
Subclass
Item (includes access from main Item dialog as well as Quick Item Add)
Item/Location
Item/Supplier
Item/Supplier/Country
Item/Supplier/Country/Location
Address
ELC Components
VAT Codes
Purchase Order Header
RTV Header
Deals Header
Transfer Header
Partner
Order Details
Cost Changes
Diff Types
Users can access the CFAS user interface for these pre-enabled entities using the More Actions menu from the relevant entity screen. A single menu option is included for each attribute group set associated with the entity. The screens for each of these pre-enabled entities also includes some validation logic to ensure that the required information is entered before opening the attribute screens (for example, for orders, the supplier and dates information must be entered before opening the CFAS User Interface). It will also include validation logic to check the mode (Edit or View) in which the CFAS user interface must appear. This is based on the mode from the relevant entity screen from where the CFAS user interface is accessed.
|
Note: Additional customization is required when there is a need to have a particular attribute group accessed in a different manner (for example, if an order is approved, access the group set's attributes in view mode). |
When planning the entities, in order to properly validate and display the information in the screens, you must determine the following for each entity:
Validation Function - Validates the information entered before the users save and close the CFAS screen. A validation function is not mandatory and may be needed when further validation is required beyond that set at the attribute level. In such a case, you will need to write a custom package function for the validation function based on your business need.
Once you determine the entities that must have the custom flex attributes set up, the next step in the planning process is to determine the attribute group sets required for each entity.
Attribute group sets are at the top level of the flex attribute hierarchy and this is the level that appears in the More Actions menu for each entity. For each entity, you can define up to 99 attribute group sets.
When planning the attribute group sets, in order to properly validate and display the information in the screens, you must determine the following for each group set:
Display Order - The order in which the attribute group set will appear in the More Actions menu of the relevant entity.
View Name - The name that will be used for the database view that will be created for this group set. A view is a required information for each group set and is used to facilitate querying attribute information for the group set.
Staging Table Name - The name that will be used for the staging table that will be created for this group set. Although staging table information is optional, it is recommended that you provide staging table name to support data loading from integrated system in the future. In case a staging table is defined, each attribute group set can have one staging table defined and mentioned in the Attribute Group Set Maintenance form. Once activation process is complete, you cannot update the staging table information from the user interface.
Qualifier Function - Validates whether all the required information has been entered on the entity screen from where the CFAS screen is accessed. This occurs before the CFAS screen opens. A qualifier function is not mandatory, but may be required when a special validation is needed beyond ensuring that the primary key is entered. In such a case, you will need to write a custom package function for the qualifier function based on your business need.
For more information, see Custom Functions.
Default Function - Sets the default values for the attributes in the group set when the CFAS screen opens. A default function is not mandatory and you will need to write a custom package function based on your business need.
Validation Function - Validates the information entered before the users save and close the CFAS screen. A validation function is not mandatory and may be needed when further validation is required beyond that set at the attribute level. In such a case, you will need to write a custom package function for the validation function based on your business need both for attribute group set and attribute group.
Labels - Sets the business name for the group set. The label is the title that will appear in the Option menu for the entity when the attribute group set is accessed. You must set at least one label for the default language for each group set you create. You can choose to create labels for more (alternate) languages based on your business need.
Once you determine the attribute group sets needed for each entity, the next step is to determine how the attributes will be organized within these sets. The attributes themselves are organized into groups, which is the middle layer of the CFAS hierarchy. Although you can create as many attribute groups as you want for each group set, you can only have 22 attributes in each attribute group.
When planning the attribute groups, in order to properly validate and display the information in the screens, you must determine the following in addition to the attributes themselves:
Display Order - The order in which the attribute group set will appear in the More Actions menu of the relevant entity.
View Name - The name that will be used for the database view that will be created for this group. Similar to the view defined at the group set level, this view will contain all attributes in the group. A view is a required information for each group and is used to facilitate querying attribute information for the group.
Labels - Sets the business name for the group and will be the name that appears on the screen. You must set at least one label for the default language for each group set you create. You can choose to create labels for more (alternate) languages based on your business need.
|
Note: From Release 16,the Validation Function column from attribute group has been removed. Any validation function requires for attribute group needs to be added in attribute group set Validation Function. |
Attributes are the bottom layer of the CFAS hierarchy. As mentioned above, you can have only 25 attributes per attribute group. Of those 25 attributes, only 10 are allowed to be character based attributes, 10 are number based attributes, and 5 are date attributes. You must consider this set limit when planning the attributes to be included in each group. Additionally, you must also determine and consider the following information when planning the attributes:
Data Type - Indicates the type of data for the attribute. You can set this as a Number, Varchar, or Date.
Widget Type - Indicates the type of the field that will appear for the attribute. You can select one of the following options:
Text Item - You can use this type for both Number and Varchar data types. When used, the attributes field will appear as a text box on the screen.
List of Values (LOV) - You can use this type for the Varchar data types only. A list of values appears as a text box and an LOV button. If you choose to use this widget type, you must also specify a record group. For more information, see Record Groups.
List Item - You can use this type for the Varchar data type only. When used, the attributes field will appear as a drop-down list box on the screen. If you choose to use this widget type, you must also specify a code type. For more information, see Codes.
Check box - You can use this type for Varchar data type only. When used, the attributes field will appear as a check box on the screen.
Display Sequence - Indicates the order in which the attributes will appear in the attribute screen, from top to bottom. Attributes will appear in a single column on the screen.
Enabled - Indicates whether the attribute appear as enabled or disabled (greyed out); only enabled attributes can be updated in the attribute screen. For attributes where you want the users to enter information, you must set them as enabled. For attributes that will display a default value (using a default function) that cannot be changed, you will need to set them as disabled.
Validation Function - Validates the information for the attribute at the field level. A validation function is not mandatory, but may be needed when further validation is required beyond that set at the attribute level. In such a case, you will need to write a custom package function for the validation function based on your business need.
Maximum Length - Indicates the maximum number of digits or characters that are allowed in the attribute, as well as the width of the attribute on the screen. You must specify this information for the attributes with Number or Varchar data types. This may not apply when you choose a List Item or Check box as the widget type. The maximum length for the List Item widget type is automatically set to 6 and the maximum length for the Check box widget type is automatically set to 1. For attributes with Number data type, you must enter the full length of the number. This includes the length to be allowed after the decimal point and positive/negative sign (if negative numbers are allowed). For example, if a particular attribute needs to allow for five digits with up to two digits after the decimal point and allow negative integers, you will need to specify the length as 9 (1 character for positive/negative sign, 5 digits before the decimal point, 1 decimal point, and 2 digits after the decimal point).
|
Note: If you choose a record group, the maximum length will be automatically selected based on the value in the first column of the record group query. |
Minimum/Maximum Value Allowed - Applies to attributes with Number or Date data types. Indicates the minimum and maximum numeric or date value that can be entered for the attribute. Although this is not mandatory, you must consider this as part of the planning process. For date widgets, the minimum and maximum definition is the number of days. For example, if an attribute was added for an item that was Ecommerce Launch Date and the attribute was set like this:Lowest Allowed Val: 0Highest Allowed Val: 365If the current VDATE is 22-SEP-2016, then the min/max setup would not allow this attribute to be earlier than 22-SEP-2016or greater than 22-SEP-2017.
Required - Indicates whether the attribute will be considered as a mandatory field and trigger the standard CFAS validation. Once an attribute is activated, it is recommended that you avoid changing this information.
As part of planning the attributes, you must also review and set up the following as needed:
Record groups are needed when you select the List of Values widget type for the attributes. Record groups need to be set up ahead of time and it requires you to be familiar with writing PL/SQL queries. Each record group must contain just two data elements—an ID and a description, in this specific order (for example, supplier and supplier name). The RMS application already includes set record groups for the attributes associated with the pre-enabled entities. But, you may need to create additional record groups to support the attributes you add, based on your business need. The Data Loading screen for CFAS upload/download enables you to create the record groups and build simple or complex queries for each record group.
From 16 CFAS will start using the RMS Codes table to define the codes.
There are three types of custom functions that CFAS is designed to support. For all of these function types, you will need to write a custom package function based on the CFAS standard in order to perform the functions described below.
Custom functions are not mandatory, but may be required when the custom attributes need anything other than the standard validation that is done based on the attribute setup (for example, ensuring that required attributes are entered).
Qualifier Function
Qualifier Functions are at the attribute group set level only and are used to ensure that all the required information is entered or available before the users open the CFAS screen from the More Actions menu. The base validation ensures that the basic information (usually the primary key) for the entity is entered before launching the CFAS screens. In case you want to ensure such a validation based on any other information, you can create a qualifier function. Qualifier functions are not mandatory.
For example, in the Ordering dialog, you may use a qualifier function to ensure that at least one item is added to the order before accessing one of the CFAS screens from the Order Header screen.
Default Function
Default Functions are also only at the attribute group set level. These types of functions are used to set the default values for the attributes in the attribute group set based on some previously determined criteria. For example, copying information from the subclass level to the item level when the same attributes are set up for both the entities.
Default functions are not mandatory. Once implemented, the default function will run each time the users open the relevant screen. You must ensure that the custom function is written in such a manner that it only sets the default values when attributes are set up for the first time in an entity. For example, when the user changes the value to something other than the default, the value will not be overwritten the next time the screen is opened.
Validation Function
Validation functions can be defined at the entity, group set, group, and attribute level. Validation functions are not mandatory. These functions enable you to add additional validation into the attribute screens above the default validation provided with the base functionality. The default validation in the screens is based on how the attributes are created (for example, required attributes are entered; dates do not exceed the maximum allowable value, and so on).
For more information on the existing validation functions in the CFAS user interface and setting up your own custom validation functions, see CFAS User Interface Validation Routines.
Since the validation functions work slightly different based on the level at which it is set, determining the level for the validation is an important part of the planning process. Validation at the attribute group set level is executed when users click the OK button on the attribute group set screen. Any Validation function which are required for groups needs to be incorporated here. It will also be executed for the attribute group currently being displayed when users click the OK button. Validation at the attribute level is executed when users navigate to other attribute fields by pressing the Tab key.
The following examples illustrate some validation scenarios that will help you determine the validation level based on your business need:
Entity - Entity level validation is the highest level and triggered by the pre-enabled base RMS screens usually via the Save button in the screen (to check if there are missing required attributes).
Attribute Group Set - If the validation requires the attributes to be added in more than one group to perform the validation, set the validation at this level. For example, consider a scenario where you have set up store attributes with one group set that includes the alternate address information for a store and another group set the indicates that the store has an offsite backroom. In case you want to check and ensure that the store with an offsite backroom also has the alternate address entered, you may need to set the validation at the attribute group set level.
Attribute Group - From 16 we are not supporting validation functions at the attribute group level.
Attribute - Set the validation at this level to perform validations at the field level. For example, consider that you created an item level attribute called Related Item. To ensure that it is a valid item number in the system, you may need to set a relevant validation function at the attribute level.
Other Custom Functions
The custom functions described above are all related to setting up the attributes when a new entity is created or updated. They do not include the facility to use the attributes anywhere within the RMS application or external systems. In order to use the custom attributes for driving functionality within the RMS application, you may need to create additional custom functions. Such custom functions will need to leverage the views (to query data) that are created as part of the attribute setup process.
