Product Master Data Management

Get Involved. Join the Conversation.


    Ekansh Jain
    How to decide the Item Class Structure
    Topic posted April 21, 2019 by Ekansh JainBronze Medal: 1,250+ Points, tagged Inventory Cloud, Product Hub, Product Lifecycle Mgt Analytics, Product MDM Analytics, SCM, Setup, Supply Chain Financial Orchestration, White Paper 
    166 Views, 6 Comments
    How to decide the Item Class Structure
    How to decide the Item Class Structure


    My client is requesting us to recommend and help them to decide the item class structure as they are not able to decide the same. 

    I am suggesting few points which can be food for thought for them to decide what kind of item class hierarchy would be suitable for them:

    1. Item class can be decided on the basis on grouping items when NIR process flow is required
    2. Data quality and matching is required
    3. Item number and description need to follow any particular sequence
    4. Item Class can be created for specials
    5. Item class can be created based on organization structure
    6. Item class can be created based on regions where the business operates

    Please let me know if you have any pointers or suggestion which can be helpful to decide the item class structure. If you can suggest any hierarchy that you may have followed in your past implementations then it would be of great help.







    • Lakshaman Singh Parihar

      Item Class Structure should not be tool oriented (1, 2, 3). It can encode geographical organization structure but that is also not a standard. Think more about data and not the tool.

    • Ravi Nadiga

      When creating the Item class hierarchy and defining them, it is important to keep the end in mind. The hierarchy created with the item classes allows for inheritance, and many of the key areas get tied back to the hierarchy.

      It’s easy to create ICs to mirror your product lines, but is that the right way to do it? Items might be classified under various Categories but there will always be a group of items which share the same attribute and these attributes remain regardless of where the item is categorised. 

      For ex: Basic attributes of Desktop item will always remain the same whether it is assigned to Holiday Deals, Special Offers or Thanksgiving Specials. Basic attributes of MP3 players remain the same irrespective of whether its assigned to Music Players or Web Only Offers.


      The hierarchy created with the Item Class allows for inheritance, and many of the key functional areas get tied back to this hierarchy. One question to ask is, will Item A have different data requirements than Item B? If it does have different data requirements, it should be in another IC. Using this question is a good way to determine the structure of the IC hierarchy. At the top of the chain is the Root IC. That way if you have any all-encompansing rules or data that is spread across all items, you can attach it to the Root IC and have it inherited by the lower ICs. 

      For example - Item class Laptops, Notepad, Desktops share some attributes that are common to all Computers. Hence having Computers as the parent of Notepads, Laptops and Desktops will allow easy maintenance. Attributes associated for Computers IC will get inherited down to these item classes. Attributes that are specific to Notepads and Laptops can be associated at thier level. 


      Similarly if you want to keep track of the paper size for your printed materials, you can put the Paper Size attribute at the Printed Goods IC and have it inherited to the Brochures IC and the Posters IC which belong to the parent Printed Goods IC. Any items under Brocures or Posters will have an attribute for Paper Size because of inheritance.


      When defining item classes, one of the easiest ways is to

      •    Create a list of all your items.

      •    Classify the items in unique item classes that suit your business needs.

      •    Consider which item class is a subclassification within an item class. For example, SRAM and DRAM could be a subclassification of the item class Memory.

      •.   List the required and optional item attributes for each item classes.


    • Steven Cascio

      Some additional information:

      When starting your item class design, always start by adding your top most item class as a child of root item class. This will ensure that can expand your item class hierarchy later and take advantage of new functionality such as public item classes in the future.

      If you have a classification hierarchy and taxonomy remember that you do not have to create an item class for each level in your classification hierarchy. The only item classes that need to be created are the one that items will be created for. For example, UNSPS has multiple levels but when implemented only the bottom levels need to be created as item class since this is where the items are created. The remainder of the classification hierarchy can be implemented in a catalog where categories are used to model each level of the classification.

    • Rajeev Rungta


      I have a question on similar lines -

      If the item (ABC123) has been created & transacted and classified with Class A. But in future if the Class A is modified to include sub Class B and sub Class C then it that case can be Item (ABC123) be assigned to Sub Class B and not Sub Class C.


      Thanks, Rajeev