The Price Setting Package supports multiple price lists / price grids. Each of the lists is connected with one of the dependency levels: DependencyConfiguration PP. This is set on the PL/PG level as an input parameter, after choosing the proper logic. This structure is responsible for the following features:

• Dependency mapping – Allows having more than one data entry for each product, depending on the calculation context (e.g. different costs for web shop and brick and mortar shop),

• Data fallback mechanism – Allows incomplete data in case of granular pricing. This way only unique data needs to be put to the most granular dependency levels; the rest will fallback to the master dependencies.

• Lookup keys config fallback mechanism – Allows incomplete configurations for dimensional configurations. The mechanism is similar to the data fallback mechanism, with some more intuitive tweaks to configurations.

• Master price adjustments – Allows centralized approach to pricing where prices from the master price list are important for the dependent logic.

• Grouping transaction data – Allows the master price list to be completely valid. Transaction data of the dependent price lists will usually be (except for the HQ mode described below) also part of the master dependency.

In this section:

Introduction to Parent Selection Algorithm

This section explains how parent selection algorithm works and how to alter it using PSP Configuration, without needing to customize the algorithm's code, as that would be too low-level.

You need only to configure the hierarchy on the partition, and the algorithm will be applied automatically:

• Parent level prices are always selected from the parent PL/PG.

• Pricing Configuration Lookups automatically use fallback mechanism via the vLookupHierarchic function.

• Data Lookups may or may not use this feature, depending on the "Yes"/"No" value in the LookupConfiguration PP → isUsingDependencyLevelHierarchy column.

• Transactions will always use this structure to include “children” transactions in the calculation.

Independent Logic

To set up independent price lists / price grids, the “IndependentPriceListLogic” logic must be used to run calculations. As the name suggests, these PGs/PLs are independent objects and all the calculation results depend only on the package configurations. This mode can be used to handle the simplest scenarios where only one dependency level exists or as a root for more complex independent-dependent hierarchies.

Dependent Logic

To set up dependent price lists / price grids, the “DependentPriceListLogic” logic must be used to run calculations. During PG/PL configuration you will be asked to select both current dependency level and parent dependency level. This connection will be used throughout the whole calculation to base prices on parent prices or to utilize hierarchical data fallbacks.

Dependency Mapping

To understand how to create distinct entries of the same product data which are unique in the context of a defined dependency level, see DependencyMappingConfig PP.

HQ Dependency Mode

If two dependencies have the same dimension and one depends on another, then we call such relationship an HQ relationship. HQ dependency levels will be skipped when looking for fallbacks but the master price might be looked up from such dependency.

Price Adjustments

Dependent price lists / price grids can use their master result prices as base for their own prices. Parent price is always taken from the first found master in the hierarchy but there are two exceptions:

• Parent logic does not expect a master price.

• If there is no master price list configured for the dependency level, then the master dependency is skipped. Such master dependency is called “virtual” and it exists only for fallback purposes.

Data Lookup Fallbacks

Fallbacks follow the following rules:

• Check if the current dependency level is complete.

  • If yes, abort the algorithm.

• Look up the master dependency level.

  • If the master dependency level does not exist, add empty mapping data as a possible fallback and abort the algorithm.

  • If the master dependency level is not in the HQ relationship with the current level, then add a master as a possible fallback.

• Repeat with the master dependency level as the current dependency level.

Example without the isComplete flags:

Open

Example with the isComplete flags:

Open

Lookup Keys Config Fallbacks

Comparison with data fallbacks:

• There is no need to configure dependency mapping for config tables.

  • Dependency mapping is always set to:

    • Dependency Property: DependencyLevelName

    • Mapping type: Table

  • Config tables have pre-generated price parameters.

• There is always a global, per-instance PP with fallback. It can be “turned off” by leaving it empty.

Example:

For a given configuration, when looking up the CostPlus config for a web channel of a local store, the algorithm will look for configs in PPs in this order:

• WebchanneloflocalstoreCostPlus

• WarsawCostPlus

• PolandCostPlus

• CostPlus

Transaction Data Fallback

Transaction data from PSP Transaction Module is a special case. More information can be found here.