Customization Tiers (Price Setting)
If the customer project customizes the accelerator’s logics, it happens in one of the following tiers:
Generally, customization should be done at the top tier, otherwise potential upgrade of the accelerator becomes very complicated.
Tier 1 – Pricing Logics
Tier 1 logics define what data are shown to the user in a price list/grid together with some hidden supporting elements. Logics are implemented (as much as possible) as simple “dispatchers”, to gather required values (inputs) from previous elements and dispatch the calculation to Tier 2 logic.
If you need to make changes, we recommend that they are made on this level, rather than on other levels, because it is the really easy to swap the dispatching code to use/call some custom library.
Upgrades should not cause any complex conflicts even if the underlying Accelerator business logic changes and re-applying your modifications should be easy.
Logics:
ParentPriceListLogic
DependentPriceListLogic
VolumeBreakdownMatrixLogic
Tier 2 – Common Libraries
This is where most Accelerators business requirements are implemented. The libraries are full of detailed utilities that calculate and prepare data for Tier 1 logics. This is where most of the package complexities are handled.
Changes at this tier are possible but not particularly encouraged.
Upgrades of accelerators with modifications in this tier can end up in resolving many conflicts and the process can be quite demanding.
Logics:
PriceBuilderCommonElementsUtil
Tier 3 – External Libraries
These are calculations and utilities that are designed to work also independently from this accelerator. For example, Calculation Engines or Pricefx Groovy Library (SharedLib).
Changes in this tier are not recommended.
Logics:
CalculationEnginesLib
SharedLib from Shared Groovy Library
Tier X – Supporting Logics
These are all the remaining logics that do not directly affect business requirements.
Modifications of these logics are usually not necessary.
Upgrades of accelerators with changes in this tier can end up in resolving many conflicts and the process can be quite demanding.
Logics:
PriceSettingPackageInputConfigurator
PSP_ConfigWizard
PSP_ConfigWizardCommonLib
PSP_ConfigWizardExecutor
PSP_ConfigWizardScreenFactory