Integrating master data

Integrating Master Data

When integrating master data, the basic information for the entities themselves is kept to a minimum. This is done intentionally to allow different types of items, price specifications, etc. for different purposes, and because legacy ERP and PIM models tend to grow over time and get bloated with data that is no longer as relevant. Customers typically use different kinds of ERP or PIM systems and conforming to one Item-model that would satisfy all possible sources would be impossible. This is why we have boiled the Item down to what it absolutely needs to be to represent a physical object or service that can be found in the retail domain.

The extensibility of the model allows Hii Retail to consume any data from eny ERP system, and hence allow all customers to provide us data.

The limiting factor becomes the end consumers of the data, such as a POS or an app. Luckily this is customer specific and we can provide this flexibility to each customer based on their needs.

Currently the integration is done through REST APIs, where you can send your data in the specified format.

The usual integration scenario for master data can be illustrated in the following way:

In Hii Retail we have based a lot on the GS1 standards, and modeled the entities closely to the real world data structures a retailer manages.

This means that we have entities like Items, Prices and Promotions to represent the master data that exists in a store and the concepts used to sell and distribute these. It also means that the model tries to represent the entities as they exist in the physical world. Hence an Item has a name, a description, a type, a category, a net content, a unit of measure, etc. It does not, however, have a supplier nor a price defined on the entity itself as these are handled separately for the purpose they represent.

This means that an Item will have a completely separate data flow from prices. The Price Specification flow will handle several price types and prices for different time periods.

The same goes for Suppliers or Business Partner (Supplier and Manufacturer). An Item can have many suppliers and you only know which supplier is relevant when you know where to order the Item from. The supplier is connected to the replenishment process and will be found there.

Depending on your requirements for Hii Retail services some or all of the entities must be integrated.

This means that if you only need simple Item representation for accessing item names and item description, you might only need to provide the item entity as input to Hii Retail. On the other hand, if you maintain your entire master data registry in Hii Retail, you probably need to provide all entities.

This also means that if you only need very simple Items in Hii Retail, but still need to represent a supplier with your Item information, you can extend the entity using Additional Properties as you wish.

This concept of extensibility is of course open to extensive use of Hii Retail services too. The Additional Properties should be used when there is a need for extending the information beyond what the default entity provides.

We also recommend to provide a unique Correlation-Id in all requests to Hii Retail. This is header-information that all APIs accept, and we use it internally to trace the data through all downstream services.