Price Lists

After reading this article you will be able to:

  • Explain how to implement the generation of Price List.

  • Explain how to implement the logic.

Scenarios (Reasons) for Price List Generation

Sample User Stories for Creation of Global / Local Price List

  • As a Pricing Manager, I want to define a standalone/global Price List at a Product SKU level, so I can Create a centralized reference price list as the base to derive other sub-global prices.

  • As a Pricing Manager, I want to define a local Price List based on prices from a Global Price List at a Product SKU level, so I can set prices at local levels based on adjustments.

Sample Strategies for Pricelist Calculation

  • As a Pricing Manager, I want to set price with a "cost-plus" strategy with costs and "plus" (e.g., margin %) defined on Product attributes where the calculation can be performed with one of the following methods: 1) cost * (1 + margin %), 2) cost + margin, 3) cost / (1 - margin %), so I can produce a cost-plus price as a reference point and one of the price setting fallback strategies.

  • As a Pricing Manager, I want to set price based on competition data, with one of the following methods: 1) max, 2) avg (simple average), 3) min, so I can produce a competitive price as a reference point and one of the price setting fallback strategies.

  • As a Pricing Manager, I want to set price based on price of another Product (anchor price) and apply +/- factor if needed, so I can maintain a logical relationship between an anchor SKU and a follower SKU.

What is a Price List

Price List is a document with product prices. The prices found in the price list are typically valid only from certain date (target date).

Figure 1. Screen with list of existing Price Lists
Figure 2. Screen with line items of the particular Price List

Process Flow of Price List Generation

The process of Price List is described on the picture below. Overall the process works in the same way also for a Price List Simulation, which is technically quite similar to a Price List.

Data Structure

Header contains the information common for the whole Price List, like:

id – Unique identifier of the Price List.

label – The name of the Price List.Can be used to find line items in specific Price List identified by its name.There can be more Price Lists with the same name but valid from different target dates.

targetDate – Used to identify the first day of validity of the prices in the Price List.During calculation of the Price List this date decides which data to use for its calculation.

configuration – Stores the information provided by Pricing Manager during creation of the Price List.

approvalState – Status of the Price List document - not approved / approved / denied.

workflowStatus – Draft / Submitted / Denied / Approved / No approval required / Withdrawn / Invalidated

Line Item

Line Item contains information specific for an SKU (or eventually for sku in combination with second dimension "key2").

sku – ID of the product, for which we calculate the price.

key2 – Used only in a "matrix" Price List (i.e., when the 2nd dimension is used - e.g., Country, Volume Tiers, …​)

resultPrice – The price of the product.The price calculated by the logic is stored to calculatedResultPrice and then also to resultPrice, but the resultPrice can be manually overridden by the user (e.g., Pricing Manager) via the UI.

currency – In which currency the calculated price is (or eventually all the prices on the line item).

unitOfMeasure – What the unit of the calculated price is (i.e., is the calculated price per "unit", "barrel", "liter", "package", …​ ).

attribute1..100 – Columns which store the values calculated by the logic and returned from the logic via its element results.

Configuration/Implementation of Price List

The configuration/implementation of Price List typically consist of creation of:

  • Data tables - With drivers for the calculation (usually Company Parameter tables, but sometimes also Product Extensions or others). Which tables you need depends on the actual project requirement.

  • Calculation logic - A logic, which will be executed for every single line item of the Price List.

  • Default logic to be used for calculation of the line item.

  • Limit list of logics available to business users.

Price List Logic

Typical Tasks

The calculation logic always calculates values/prices for one line of the Price List.

  1. Read additional inputs from User - Besides the inputs required by the system, the logic can ask the user (usually a Pricing Manager) to enter additional information needed to calculate the Price List. These input fields will be rendered bellow the standard system input fields. The user will enter the values only once, and then their values will be available to the logic for each SKU processed.

  2. Read SKU & TargetDate from the Context.

  3. Read data from tables.

  4. Calculate the prices.

  5. Return the calculated values via Element results - also the formatting of the results.

Price List Logic Specifics

Logic Type – Generic (Default/null).

You can use the same logic without any changes also for Price List Simulation. With minor (or no) changes, you can use it also for Live Price Grid or LPG Simulation.

Context information

  • api.product("sku") - SKU being calculated.

  • api.targetDate() - Target Date of the Price List.

  • api.currentItem() - Complete current line item. Warning: This only works in the 2nd and next passes (not in the 1st pass).

  • previousContext() - Previous Revision line item of the same SKU - via

Element’s Display Mode – To make the element’s result available for the user, set the Display Mode to "Everywhere" (or "Price List").Remember, the user will be able to select the results (from the list of those made available via Display mode ) which will get to the actual generated Price List.

Mapping of the Logic’s Results to the Price List Line Item

The mapping is driven by:

  • Out-of-the-box mapping.

  • The user’s selection of logic’s elements (during the 2nd step "Set Parameters" of Price List creation).

The business user (usually Pricing Manager) can map, which values from the logic will be stored to the Price List Line Item (PLI):

  • Attributes - Which elements' results will get to the Price List line item attribute columns. Only the values from checked elements will be stored into the PLI.

  • Result Price - Which element’s result will be stored to resultPrice column.

  • Dynamic UOM - Result of which element will be stored in the UOM column.

  • Dynamic currency - Result of which element will be stored in the ccy column.

The system does the following:

  1. Executes the Logic.

  2. Gets the results from the Logic execution.

  3. Creates new Price List Line Item.

  4. Maps the information to the Price List Item:

    1. Copies the information from Product Master to the Price List Line Item.

    2. Stores the logic element results to the Attribute columns of the Price List Line Item.

    3. Stores the result of element (specified by user in definition) to the Result Price column.

    4. If specified by the user during definition, it also:

      1. Overrides the Currency column with the value provided by logic element result.

  5. Stores the Price List Line Item to the database.

Selection of Logic to Be Used for Price List Generation

Which logic will be used for calculation of Price List Line Item depends on two things:

  • Name of the logic.

  • Validity of the logic.

Name of the logic is decided in the following way:

  1. If the user did not specify a logic in the definition, then default logic is used.

    1. "Old" default is available in Administration  Logics  Calculation Logic  Generic Logic  Default Pricing Logic. But this default is only for backwards compatibility now, do not use it in new projects.

    2. Default is in Administration  Configuration  Price Setting  Defaults for Price Lists and LPGs  Default logic for Price Lists.

  2. If the user specified in the 2nd step of the definition a logic, then that logic will be used (i.e., it overrides the default logic).

  3. If there’s a Product specific logic defined (in Product Master’s column "Pricing Logic"), then it is always used when calculating that product.

You can have more versions of the same logic (with the same name) valid from different dates. The proper logic is selected based on the Target Date of the Price List and Valid From of the Logic.

Limit the List of Logics Available to Business Users

The amount of generic logics can grow significantly. So when the business user is selecting a logic from the list of logics, the list can be quite overwhelming.

You can limit the list of logics available to the business user via settings at Administration  Configuration  Price Setting  Defaults for PriceLists and LPGs  Price List Default Logics.

Creation of Price Lists

A Price List can be created in several ways:

  • Generate a Price List (described in this Handbook).

  • Convert "Price List Simulation" to a Price List - select an existing Price List Simulation and click the button "Convert to Price List".

  • Convert a Live Price Grid (LPG) to a Price List - select an LPG and click then button "Convert to Price List".

Revisions of Price Lists

The Price List versions are called Revisions.

The user can make a Revision by selecting a Price List and clicking on the "Revision" button.

Groovy API to Find a Price List Header or Line

Approval Workflow for Price List

Found an issue in documentation? Write to us.