Powered by Blogger.

Friday, August 4, 2017

Tag: , , , , , ,

Oracle Retail Merchandising System (RMS) - Exploring Merchandise Hierarchy

Welcome again Oracle Retail fans. This post is a continuation of Oracle Retail Merchandising System Deep Dive article. You may want to visit Oracle Retail Merchandising System Overview article before proceeding on this article, however, it is not completely necessary.

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:

  1. 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
  2. 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.

In next article, we are going to dive more in Oracle Retail Merchandising Systems and understand all about Suppliers and Partners in RMS

You may also want to refer to parent article Oracle Retail Merchandising Systems - Deep Dive. Do drop a note/comment in case you have any question, comments or feedback. 

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 :

Kshama said...

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.

Nagesh Mishra said...

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

Kshama said...

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

Unknown said...

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