Complete items

Complete Items

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

In general these entities flow through Hii Retail as separate entities, but for some legacy integration it is beneficial to have a “complete item” in a single payload. This allows legacy integrations to skip assembly of this information, and simply subscribe to changes for the “item”. Any related change on prices or identifiers will trigger a complete item update whenever the change is of relevance.

Complete Item is not an entity that exists as a possible input payload

If you have a legacy on-premise POS application like ERPOS, RSPOS or SuperPOS the Complete Item might be a relevant feature for you. Especially if you are using Edge deployment and/or in-store hardware as a distribution point for local POS applications.

The Complete Items is a premium feature that you must subscribe to. Contact your account manager for further details on how to get this feature.

Complete Items for Business Unit specific data

Complete Item construction for data that always exists per Business Unit is fairly straight forward. All related Price Specifications and Item Identifiers that reference a certain Item by its id will be aggregated onto a larger payload that contains all the individual pieces in a single message.

The aggregation of the Complete Item is asynchronous and does not rely on any kind of order, but there is a requirement that both the Item and a valid SALES Price Specification must exist before the information is considered complete enough to distribute further.

Should either the sales price or the item information be missing, a Customer Notification event will be emitted after 10 minutes of not receiving the missing data. See the External Events Service for further details.

Any consecutive update to the Item or any of its relevant parts will result in the Complete Item to be updated and forwarded to downstream consumers.

Complete Items for Business Unit Group data

Constructing a Complete Item from data that is maintained on a Business Unit Group level is a lot harder than Business Unit Specific data. It requires significantly more processing to construct.

An imagined scenario is to have Business Unit Group hierarchies defined for an international retailer where:

• Items are defined for Europe (covers 10.000 business units)

• Item Identifiers for those Items are defined per country (200-1500 business units per country)

• 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.