Go to primary content
Oracle® Retail Merchandising System Custom Flex Attribute Solution Implementation Guide
Release 15.0
E65438-01
  Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
 
Next
Next
 

2 Planning Custom Flex Attributes

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

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

Users can access the CFAS user interface for these pre-enabled entities using the Options menu from the relevant form window. 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 another 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 form window 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.

  • Labels - Sets the label names for the relevant columns. You must set at least one label for the default language for each label you create. You can choose to create labels for more (alternate) languages based on your business need.

  • Description Code - The function that will display the description of the relevant key. For example, SUPPS_SQL.GET_SUPP_NAME will retrieve the supplier name.

Attribute Group Sets

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 Options menu for each entity. For each entity, you can define up to 10 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 Options 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.

  • 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.

Attribute Groups

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.


Note:

The forms user interface, by design, has a limit of 18 lines in a window. Since the entities already include a set number of entity keys, you will only be able to set up less than 18 attributes per attribute group. For example, the Item Supplier Country Location form has 4 preset keys. You can add only 14 additional attributes to this user interface and this can be a combination of character, number, and date type attributes.

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 Options 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.

  • Validation Function - Validates the information entered before the users save and close the CFAS screen. 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.

  • 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.

Attributes

Attributes are the bottom layer of the CFAS hierarchy. As mentioned above, you can have only 22 attributes per attribute group. Of those 22 attributes, only 10 are allowed to be character based attributes, 10 are number based attributes, and 2 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.

  • 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.

Other Setup Data

As part of planning the attributes, you must also review and set up the following as needed:

Record Groups

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 CFAS maintenance screen for the record groups (Record Groups Maintenance screen) enables you to create the record groups and build simple or complex queries for each record group. Although you can use this screen to write and test the queries, there is no preview feature available for the List of Values (LOV).

Codes

Codes are needed when you select the List Item widget type for the attributes. Codes for CFAS are similar to the codes that are used in other parts of RMS. They are made available separately for the CFAS framework for usability purposes. In case you want to use the codes that are part of the main RMS Codes tables, you can choose to copy over these tables using scripts. To specify separate codes for CFAS manually, use the CFAS maintenance screen for the codes (Codes Maintenance screen). This screen enables you to create the code header and detail records to support the list items for CFAS.

Custom Functions

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 Options 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. Validation at the attribute group level is executed when users switch tabs between attribute groups in the attribute group set screen. 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 forms usually via the OK button in the form (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 - Set the validation at this level, if you want the function to validate attributes within a single attribute group. For example, consider an attribute group that captures the address information. You may need to set the validation at the attribute group level to ensure that the users enter the State information when they select the country as USA.

  • 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.