Skip to main content

Complete items

Complete Items

The Complete Item entity is an internal aggregation of an Item and its current Price Specifications and Item Identifiers.

Normally, these entities flow through Hii Retail separately, but for some legacy integrations, it's beneficial to have a “complete item” in a single payload. This allows legacy systems to receive all relevant data in one message. Any related change (item, price, or identifier) triggers a complete item update.

Complete Item is not an entity you can input directly.

If you use a legacy on-premise POS (e.g., ERPOS, RSPOS, SuperPOS), or Edge deployment, Complete Item may be relevant.

Complete Items is a premium feature. Contact your account manager for details.

Complete Items for Business Unit Data​

For Business Unit-specific data, all related Price Specifications and Item Identifiers for an Item are aggregated into a single payload.

Aggregation is asynchronous and order-independent, but both the Item and a valid SALES Price Specification must exist before distribution.

If either is missing, a Customer Notification event is emitted after 10 minutes. See External Events Service.

Any update to the Item or its parts triggers a Complete Item update.

Complete Items for Business Unit Group Data​

For Business Unit Group data, constructing a Complete Item is more complex. For example, Items may be defined at the Europe level, Identifiers per country, and Prices per region or store type.

The inheritance calculation determines the correct combination for each Business Unit.

A common denominator algorithm calculates the largest group of Business Units sharing the same combination. Any update triggers recalculation and updates only the affected Business Units.

Hybrid solutions (mixing group and unit-specific data) are possible but should be avoided if possible.

  • And lastly the prices are defined per:
    • Profile house (5)
      • And Regions (1 - 10 per country)
        • And Size (minimart -> maximart)
          • And location (city vs. rural) of the store/business unit

Imagine the nodes in the list above as parent to child relationship, and think about the amount of possibilities a Business Unit will have when all the levels of this hierarchy CAN contain an entity.

The inheritance calculation involved to find the correct definitions for a single Business Unit is significant.

To achieve this a common denominator algorithm will calculate every combination of Item, Price Specification and Item Identifier and maintain the largest number of Business Units this combination applies to.

This Common Denominator is the basis for the construction of the Complete Item.

Whenever there is an update of an existing entity or a new one is added, the entire calculation must be executed again. If for example a Price Specification is introduced to a level where it never existed, all underlying Business Units would need to be updated, but not the ones above. They should still have the same price.

This means a new Common Denominator will need to be created for the affected Business Units, and the existing one updated where those Business Units must be removed.

It is even possible to have business unit specific definitions when primarily managing data on group levels. This is more advances, and a hybrid solution that we recommend you try to avoid if possible.