The purpose of this article is to provide you a complete detail and all about RMS Merchandise Hierarchy in RMS Foundations. This article also covers each and every detail required for Oracle Retail Merchandising Systems (RMS) Certification (Pearson Vue Exam Number 1Z0-453) preparations with respect to Merchandise Hierarchy.
I’ll be taking you through following details for Location Management under RMS Foundations:
- Merchandise Hierarchy
- Creation and Maintenance of Merchandise Hierarchy
- Company
- Division
- Group
- Department
- Class
- Subclass
- User Defined Attributes Defaults
- Store/Department Area
- Up Charges
- Merchandise Hierarchy Defaults
- Transit Times
- Apply Tax Codes
- Item Reclassifications
1. Merchandise Hierarchy
The Merchandise Hierarchy allows users to create the relationships necessary to support the product management structure of a company. The Merchandise Hierarchy allows users to group items by Division, Group, Department, Class, and Subclass.
RMS Merchandise Hierarchy functionality includes:
• Creation and Maintenance of Merchandise Hierarchy
• Merchandise Hierarchy Reclassification
• Buyer / Merchandiser Relationships
• User Defined Attributes
• Store/Department Area
• Up Charges
• Merchandise Hierarchy Defaults
1.1 Creation and Maintenance of Merchandise Hierarchy
The RMS hierarchy levels from the top down are Company, Division, Group, Department, Class, and Subclass. Each level of the Merchandise Hierarchy is connected to a higher level with the exception of Company. A Subclass must belong to a single Class. A Class must belong to a single Department. A Department must belong to a single Group. A Group must belong to a single Division and finally, a Division must belong to a Company. The six hierarchy levels are static and do not allow for the addition or removal of a level.
Levels of the Merchandise Hierarchy are assigned an ID (4 digits) along with a description. The Department, Class, and Subclass combinations are used to define the roll-up levels available within the RMS Stock Ledger.
Following are descriptions of each of the Merchandise Hierarchy levels in RMS:
Company
The Company is the highest level in the Merchandise Hierarchy. There is only one Company in RMS. The Company level defaults from the Organizational Hierarchy for the Merchandise Hierarchy.
Division
A Division is the second level of merchandise classification and can be used to signify the overall types of merchandise. There can be multiple divisions in a Company.
The application allows up to 9999 divisions. Divisional Attributes
• Buyer
• Merchandiser
• Total market amount
• (used for reporting)
Field
|
Required
|
Functionality
|
Division ID
|
Yes
|
Unique numeric ID assigned to a Division, up to 4 digits.
|
Division Name
|
Yes
|
Name used to best describe the Division.
|
Buyer ID
|
No
|
Identifies the Buyer assigned to the Division.
|
Merchandiser ID
|
No
|
Identifies the Merchandiser assigned to the Division.
|
Total Market Amount
|
No
|
Contains the total market amount which is expected for this Division. Reference information only.
|
Group
A Group is the third level of classification in the Merchandise Hierarchy and segments the Divisions. A Group can belong to only one Division. There can be multiple Groups in a Division.
The application allows up to 9999 groups. Group attributes:
– Buyer
– Merchandiser
Field
|
Required
|
Functionality
|
Group ID
|
Yes
|
Unique numeric ID assigned to a Group, up to 4 digits.
|
Group Name
|
Yes
|
Name used to best describe the Group.
|
Division ID
|
Yes
|
Unique numeric ID assigned to a Division, up to 4 digits.
|
Buyer ID
|
No
|
Identifies the Buyer assigned to the Group.
|
Merchandiser ID
|
No
|
Identifies the Merchandiser assigned to the Group.
|
Department
A Department is a primary level in RMS from Stock Ledger perspective. This is the level of the Merchandise Hierarchy where it is required to define the merchandise type (consignment, concession or regular) and the budget and profit calculations are assigned. A Department can belong to only one Group. There can be multiple Departments in a Group. The application allows up to 9999 departments.
Department attributes:
• Profit calculation type - Determines whether profit is calculated using cost based or the retail method of accounting
• Direct Cost - Actual cost of the merchandise will be used to calculate the profit of merchandise within this department
• Retail Inventory - Cumulative mark-up percentage will be used to calculate the profit of merchandise within this department
• OTB calculation type - Determines whether the open to buy budget of a department is controlled using the cost or retail value of purchases
• Direct cost - Open to buy budget is cost based
• Retail inventory - Open to buy budget is retail value based
• Markup calculation type - Determines whether the markup on items are calculated as a percentage of the cost or retail price
• % Cost - e.g. Markup % cost (markup) of 300% on cost price of $5 would give a retail price of $20
• % Retail - e.g. Markup % retail (margin) of 75% on a cost price of $5 would give a retail price of $20
• Purchase type
• Normal - Purchased from a supplier before being offered for sale.
• Consignment - Purchased from the supplier only when the goods are sold to the customer.
• Concession - The merchandise is not owned by the retailer but items are ordered, invoiced and recorded in the stock ledger.
• Total market amount
• User defined attributes
• Ability to set as mandatory for all items in this department
• Ability to set a default value
• Department/store area
• Tracks total area of department per store
• Tracks effective date for use in major floor moves
• Can be used for reporting purposes
• Default VAT codes
• For each VAT region a default VAT code for the department must be specified
• Buyer
• Merchandiser
Field
|
Required
|
Functionality
|
Dept ID
|
Yes
|
Unique numeric ID assigned to a Department, up to 4 digits.
|
Dept Name
|
Yes
|
Name used to best describe the Department, entered by the user.
|
Group ID
|
Yes
|
Identifies the Group to which the Department belongs.
|
Markup Calculation Type
|
Yes
|
Determines which method of calculating a proposed Retail Price during the Item Creation process.
|
Profit Calculation Type
|
Yes
|
Defines the method of accounting used for the Department within the RMS Retail Stock Ledger.
|
Open To Buy Calculation Type
|
Yes
|
Determines whether RMS Open-To-Buy functionality will be based upon Cost or Retail Price.
|
Purchase Type
|
Yes
|
This is the type of merchandise held in the Department (Concession, Consignment, or Normal).
|
Buyer
|
No
|
The Buyer ID associated to the Department.
|
Merchandiser
|
No
|
The Merchandiser ID associated to the Department.
|
Markup % at Cost
|
Yes
|
It is in this field where a default percentage value is added at the Department level to generate an initial or suggested Retail Price.
|
Markup % at Retail
|
Yes
|
Contains the budgeted intake percentage for the Department. (Markup Percent of Retail).
|
Total Market Amount
|
No
|
Total Market Amount is a projection in dollars by Department that is used in Oracle Retail Data Warehouse reporting.
|
Max Average Counter
|
No
|
Maximum Average Counter is used in RPM for smoothed average sales in determining applicability for a Retail Price change.
|
Average Tolerance Percent
|
No
|
Average Tolerance Percent is used in conjunction with the Maximum Average Counter in RPM for smoothed average sales.
|
Class
A Class further defines the type of merchandise sold in the Department. A Class can belong to only one Department. There can be multiple Classes in a Department. The application allows up to 9999 classes. Class attributes:
User defined attributes
Field
|
Required
|
Functionality
|
Dept ID
|
Yes
|
Unique numeric ID assigned to a Department, up to 4 digits.
|
Class ID
|
Yes
|
Unique numeric ID assigned to a Class, up to 4 digits.
|
Class Name
|
Yes
|
Name used to best describe the Class.
|
Subclass
A Subclass further defines the type of merchandise sold in the Class. A Subclass can belong to only one Class. There can be multiple Subclasses in a Class. The application allows up to 9999 subclasses. Subclass attributes:
User defined attributes
Field
|
Required
|
Functionality
|
Dept ID
|
Yes
|
Unique numeric ID assigned to a Department, up to 4 digits.
|
Class ID
|
Yes
|
Unique numeric ID assigned to a Class, up to 4 digits.
|
Subclass ID
|
Yes
|
Unique numeric ID assigned to a Subclass, up to 4 digits.
|
Subclass Name
|
Yes
|
Name used to best describe the Subclass.
|
1.2 User Defined Attributes Defaults
The User Defined Attributes (UDA) feature provides a method for defining attributes and associating the attributes with specific items, items on an item list, or items in a specific department, class, or subclass. When a UDA is associated to a Merchandise Hierarchy level, the UDA can be set as "Required" or "Not Required." In addition, a UDA value can be defaulted at these Hierarchy levels, so that each new item attached to the Hierarchy level will be given the UDA automatically. Using UDAs associated or defaulted at the Merchandise Hierarchy levels will streamline item setup and reduce the data entry of having to add a UDA to each individual item. When assigning UDAs at the Department or Class level, all lower levels within the Department or Class will also assume the same assignment.
1.3 Store/Department Area
This functionality holds the square footage area dedicated to a given Department within a given store as of an effective date and is available for extract to a Data Warehouse for reporting.
1.4 Up Charges
Up Charges are expenses or fees that are applied to the movement of merchandise between locations – e.g. transfers/allocations between a Warehouse and Stores. They are used to calculate an item's estimated landed cost (ELC). These default values can be set at a Department, Class, or Subclass based on Cost Zone Structures.
1.5 Merchandise Hierarchy Defaults
The Merchandise Hierarchy Defaults can be set down to the Department, Class, and / or Subclass. These defaults drive what information types may or may not be "Available" / "Unavailable" as well as "Required" / "Not Required" during the Item setup process.
Similar to assigning UDAs, when assigning Merchandise Hierarchy Defaults at the Department or Class level, all lower levels within the Department or Class will also assume the same assignment. Additionally, when an item is reclassified, the item must be assigned any required information of the new Department / Class / Subclass prior to being reclassified.
For example, a default setting may indicate items in a selected Department cannot be approved unless they have a valid Ticket Type assigned. Alternatively, the Substitute Items option used for Replenishment can be made unavailable for items in different
1.6 Transit Times
Transit Times are defined at the Department level and are used in determining the time it takes to move product through the supply chain.
1.7 Apply Tax Codes
Contains tax information at the department level to default to the items within the department. This provides the ability to assign default Geo Code configurations at a department level which are defaulted to the item level
2. Item Reclassifications
Item reclassification allows moving an item or item list from one department/class/subclass to another. Reclassification can be done for a staple SKU, fashion style, pack item, or a list of items.
• An effective date can be specified for the reclassification. The actual process is done the night before the effective date
• Some of the checks done before an item can be put on a reclassification are as follows
– Item cannot be moved across consignment and non-consignment departments.
– Item should not already be part of another reclassification event
– When the new hierarchy has any required UDAs attached, the item being moved into the same will need to have all the UDA’s associated
• When an item is successfully reclassified
– Stock ledger transactions are written to move the inventory from the existing dept./class/subclass to the new hierarchy.
– OTB is updated where applicable.
– Records are sent to the POS system for updating the same at the store
This was all about various aspects of Merchandise Hierarchy in RMS. Looking for more or think anything else too needs to be covered. Please do let me know.
Note: source of images are Oracle/Google
About
Nagesh Mishra
Nagesh Mishra - A Passionate Oracle Retail Certified Professional with more than 17 years of overall experience in IT industry and more than 15 years of domain expertise in Oracle Retail Applications. Worked extensively in diversified fields of Product Implementation, Business Consulting, Pre-Sales, Application Software Development, Maintenance and Support and Re-Engineering Oracle Retail projects.
4 comments :
Hi Nageshwar,
Here the definitions of concession and consignment items are not corrected. They are mistakenly interchange. Please correct.
Concession Items are items that are not owned by the retailer but captured for future use.Supplier rent a space from retailer, and retailer never own the items.
Consignment Items are items that are purchased from supplier only when the items are sold to customer.
Good catch Kshama. There was a typo and it has been corrected now. Feedback from people like you can make such platforms more successful. For more detail on items, you may want to refer below article
https://oretail.blogspot.com/2017/08/oracle-retail-merchandising-system-rms_15.html
Hi Nageshwar,
Thanks for the appreciation. The material provided by you is outstanding and very helpful in studying MOM modules under one roof.
As I can see that REIM module is not included in the blog. Let me know if I can be of any help in this as I have years of experience in REIM.
Regards
Kshama
Nagesh, Just wanted to thank for your wonderful documents on RMS.Helped me to quickly understand the RMS concepts. Wonderfully written content, precise and to the point.
Thank you.
Regards
Prabhu
Post a Comment