A CFAS Use Cases

Because CFAS is so custom, there is no functionality in RMS—online or batch, that actually uses these attributes to drive any processing. This will require additional customization to RMS. However, leveraging the CFAS functionality to support customizations should make the customization process less complex. This chapter describes some examples of common RMS customizations and how you can leverage the CFAS framework instead, with or without additional custom processing added, to facilitate the business process. This chapter includes the following sections:

• External Application Attributes

• Alternate Hierarchies

• Ranging and Grading

• Electronic Data Interchange (EDI)

• Difference Between CFAS and User Defined Attributes (UDAs)

External Application Attributes

Because RMS is often the foundation data master for a retailer, it is also often the place where attributes that are needed by other applications are created and maintained, even those that are just informational in RMS. For example, common customizations are to add item, supplier, store, and warehouse attributes to RMS that are then sent to other applications to drive processing in those applications. You can set up and maintain such attributes with CFAS. The integration that is built for this purpose would then be built to use the Views defined at the attribute group or attribute group set to query the information from RMS.

Alternate Hierarchies

Alternate hierarchy functionality is something that is available in the RPAS applications and has often been requested in RMS. You can use the CFAS framework to support this functionality by creating an attribute group titled Alternate Hierarchy and then including attributes such as Division, Group, Department, Class, and Subclass. To set the valid values for each of these attributes, you can choose to use the base merchandise hierarchy tables or define new ones using the Codes table based on your business need.

In case you want more than one alternate hierarchy, you can create an attribute group set called Alternate Hierarchy and then create multiple identical attribute groups for each alternate hierarchy required. By setting up alternate hierarchies in this manner, you can then build reporting based on these hierarchies.

Note: Creating reports or any other functionality that is driven off these alternate hierarchies will require further customization.

Ranging and Grading

The ability to better control grading stores and then using that to range items to the stores based on certain attributes in RMS is also a frequently requested functionality. The CFAS framework provides a way to achieve this ability. You can add a Grade attribute to both stores and items. Then, you can build custom processes to use these attributes to range items to locations, set up replenishment parameters, and so on. Although this will involve further customization, leveraging the CFAS framework will reduce the effort involved.

Electronic Data Interchange (EDI)

For some retailers, there is a requirement to send additional information with the purchase order (PO) using EDI, than the current feature available in RMS. In order to meet this requirement, you can create the custom attributes on the PO header using the CFAS framework, and then make the custom modifications to send these attributes through EDI.

Difference Between CFAS and User Defined Attributes (UDAs)

For items, you now have two different ways (CFAS and UDAs) to create custom attributes without making code changes. The table below highlights some of the key differences that you must consider when identifying attributes that need to be created in RMS.

Feature	CFAS	UDAs
Has explicit data objects in database	Yes - views and staging tables are created using attribute names in the database for querying and uploading purposes, respectively.	No - UDAs are held on UDA tables and accessed by a UDA code.
Can be interfaced to/from external systems	Yes - using views to query the attributes and using the staging tables to upload.	Partially - UDAs can be interfaced, but it requires hard coded values in queries and uploads to ensure the correct UDA mapped in integration.
Available for use in RMS functions	No.	Yes - UDAs can be used for several item related functions, such as building criteria based item lists, mass updates and addition to tickets.
Able to be added by end user	No - requires DBA involvement to run scripts.	Yes.
Can be defaulted from department, class and subclass levels	Partially - functionality allows for a utility to default values, but would require a custom package created to define.	Yes.
Can defined as required	Partially - functionality allows for a utility to default values, but would require a custom package created to define.	Yes - at department, class and/or subclass level.
Allows for attribute validation	Partially - simple functionality for minimum/maximum value is supported; the functionality also allows for a utility to validate the attribute (as well as across attributes), but this would require a custom package to be defined.	Partially - LOV UDAs are validated against pre-defined valid values.
Limit to number of attributes that can be defined	No - only 10 group sets can be defined and only 22 attributes can be included in each attribute group, but there is not a limit to the number of attribute groups that can be created.	Yes - maximum of 99,999 UDAs can be defined.
Sent to RDW	No.	Yes.