Inheritance logic

Inheritance in Hii Retail Master data processing

Hii Retail follows a basic inheritance principle where information created and assigned higher up in a hierarchical structure will be inherited down to underlying entities.

To achieve this we have the hierarchical structure called Business Unit Groups which should be maintained as new Business Units are created, removed and moved.

When an entity is associated with a Business Unit Group, by setting the BusinessUnitGroupId property on the entity to the correct Id inside the hierarchy, the data will be inherited down to all underlying Business Units.

This logic can be applied on any level within the hierarchy. Information applied on a lower level will be applied from this level and downwards. This means that you can apply different information to different groups of Business Units, and be more specific on some groups than others.

Overrides

The inheritance described above applies to most entities and follow the same rules. There might be some variations that we will explain here.

The inheritance will make it easy to propagate the same details of an entity to all Business Units, but in some cases this might not be the required behavior. Sometimes you might need to replace the entity for parts of the hierarchy, or there is a need to force an entity to all underlying Business Units even if they have one defined lower in the hierarchy. This is typically used for entities like Price Specifications.

Item example

This example shows that an overall definition of an Item can be applied to the entire organization, but variations can be applied to certain parts and not others.

You might want to use a specific version of the Item for some Business Units since these have a more demanding audience or they might have different legal requirement that must be fulfilled. Or more commonly, it might be that a particular chain/branch in your organization have additional information needed to satisfy some hardware in their stores. It might even be as simple as having different language in different parts of the organization.

Price Specification example

For example you might want to enforce a version of an entity to a group of Business Units even if they have a version defined closer in the Business Unit Group hierarchy. This is illustrated in the example above for Business Unit Group 110 where the general price is $90, inherited from Business Unit Group 10, but Business Unit 11nn has also a locally defined price of $90, which is overridden by the price defined as IsMandatory = true on Business Unit Group 110.

Cross entity inheritance

Some entities also propagate inherited data onto other entities. This is rare, but possible on for example Item Categories.

This capability allow you to assign default properties to an Item Category that will eventually also be inherited to all underlying Items for this Item Category.

Item Categories example

This example illustrates that your Item Category hierarchy can be set up to contain some default information that is essential for all Items in that category. This might be something like Minimum Temperature for all refrigerated Items (Milk, yoghurt, cheese, etc.) or it might be specific content for all LED TVs like Screen size (inches), Resolution, VESA mount, etc. It might even be legal requirements that only apply for specific Items like Age Restriction for all Alcoholic beverages or tobacco products.