Calculate prices

Calculate Price Specifications

In Hii Retail we can ingest several Price Types, and we can calculate the correct Price Specification for individual Business Units.

If you maintain Price Specifications for groups of Business Units, we will use our general inheritance logic and processing capabilities for Price Specifications to calculate the correct price for each Business Unit.

Price Specification inheritance

Price Specifications are inherited in the same way as most other entities, but in addition it has some capabilities specific to Price Specifications. Let's look at these differences.

One major difference for Price Specifications is the IsMandatory property. This can be set to true when the intention is to override information set lower in the hierarchy. This is a capability that is intended for organizations managing their master data on a central level, and not for individual Business Units.

In effect you can force a price onto underlying business units so that even local prices are overridden, which can be useful when business units have little or no control over their own data.

Price Specification processing capabilities

In Hii Retail we receive Price Specifications either for a Business Unit or for a Business Unit Group. This information will be preserved and used for further calculations.

Please take note of how to work with the Price Specification id property.

We recommend to have a unique id for each Price Specification.

Consider this in the same way as you would a primary key (PK) in a relational database. If you make a new one, it is a new row in the database, if you use an existing one it is considered an update of a existing row.

This is particularly important if you schedule prices for future activation. See more under Future Price Specifications

Here is a visualization of how Price Specifications will be calculated, and made available to a given Business Unit, when Price Specifications are provided on Business Unit Groups and on Business Units.

Note the usage of the isMandatory property to reverse the inheritance and force prices down in the hierarchy. It might also be worth noting that Price 3 never comes into effect for the Business Unit.

Current Price Specifications

A Price Specification input that has a validFrom that applies now; basically a date and timestamp that is now or earlier, will be treated as a new Price Specification that should be applicable immediately.

This will trigger 2 updates. One for the existing current Price Specification that is valid in for example POS and the new Price Specification input itself.

The previous Price Specification will be marked as isCurrent: false and will be removed as the current price for the given Item. The incoming Price Specification will be marked as isCurrent: true and will be shipped to all downstream consumers.

Future Price Specifications

If a Price Specification has a ValidFrom date that is in the future, a schedule to activate this Price Specification is created.

The Price Specification itself is handled as normal and output for others to consume the information. This data will be marked with isCurrent: false since it is not a current Price Specification update.

When the date and time for the future Price Specification to become active is reached, it is sent through the same business logic as described for a Current Price Specification update, and it will be marked with isCurrent: true

Please note that future prices MUST be updated by their id. It is NOT possible to update future Price Specification based on their validFrom date.

When a Price Specification ends

Price Specifications can have a validTo date and time. This is used to end the lifetime of a specific price.

Hii Retail will automatically fallback to the last known, valid Price Specification when a Price Specification ends.

Hii Retail will also make sure that an Item will never end up without an active SALES Price Specification, so even if the current Price Specification for an Item has a validTo specification, it can not be removed unless there is another valid Price Specification to activate in its place.

Please note that Price Specifications with a validTo greater than 5 years ahead will be treated as if no validTo is specified. This is done to reduce the amount of unwanted schedules.

We recommend to NOT provide a validTo if the intention with the Price Specification is to last forever

Price Specification cleanup

The most common integration patterns will send a new Price Specification (with a new id) every time the CURRENT Price Specification changes. This is expected, and handled, in Hii Retail.

Please note that this is not the case for Price Specification scheduled for future activation.

This, in turn, requires cleanup, since Price Specifications can change a lot for certain Items and retailers.

The cleanup procedure will make sure that nothing is removed if it is eligible to become the current price again

Hii Retail will remove all Price Specifications that have passed their validTo date and time and Price Specifications that are replaced and are older than 30 days.

Model and variant item pricing

When using Model and Variant items, it is possible to adjust the prices for all variants by adjusting on the model item.

For example a Nike Air Max shoe should be €149,-. You will then apply this price to the Nike Air Max model item. All size and color variants of the Nike Air Max shoe will be updated to €149,-.

However, if the orange, size 14, variant is not really popular in demand and it is decided that it needs a separate price. You can specifically apply a different price to this variant. This must be done after the price update for the model.

All variants can be priced individually as with any other item. This extended functionality in Hii Retail, is the ability to adjust for ALL variants at once using the model item, and by sending a single price update, instead of multiple.