Comparison of Price Lists and Price Grids

Concept
(the main difference)

Price list items are generated once (then maybe updated after a manual review) but then frozen once the list is approved.

Price grid items are "reused" all the time. Inside the item you have three generations of a price (latest, current/active and previous).

⚠️ However, it is not recommended to store store historical, active and future prices as LPG items. It is good practice to have historical prices stored in Analytics, active prices in LPG and future prices in Price Lists.

History of price records

PLI objects can be used as price records.

Price records history is kept until the price list is erased.

It is a common practice to store the price records in a Data Source (requires IntegrationManager).

No price records are stored in a table, but last 2 approved price records can be read from the line item. But if PGI line is deleted, it is lost forever.

It is a common practice to store the price records in a Data Source and feed it using IntegrationManager. Then you can have a pricing strategy that sets prices from that Data Source or you can use this Data Source in Analytics for reports.

Possibility to change prices

Until the price list is approved

Continuously, at any time

Approval

All items at once

• Auto-approve by the auto-approve logic element

• Manually item by item, at any time (continuously)

• Using mass edit

Frequency of price changes (calculation)

At a defined time of a year (e.g. with a new catalog) 

• Periodically, e.g. every night

• Event based (e.g. after a certain supplier changed prices)

Calculation /
recalculation

Full calculation possible

 Full recalculation possible

 Individual recalculation also possible (e.g. manual overrides)

Partial recalculation is not possible

 Partial recalculation using Groovy not possible

 Partial recalculation using integration possible (Excel Client does this as well)

By manual input in fields which can be manually overridden (immediately)

Full calculation possible

Full recalculation possible

Partial recalculation in the UI possible. Selecting up to 5 items triggers an immediate recalculation, selecting more than 5 items triggers a background job.

 Partial recalculation using Groovy possible

Partial recalculation using integration possible

 By manual input in fields which can be manually overridden (immediately)

Adding items

• Manually, using filters

• Manually, providing a list of SKUs (separated by a new line)

• Manually, using filters

• Manually, providing a list of SKUs (separated by a new line)

• Dynamically, using Dynamic filters

Removing items

 Manually

Manually

Using Dynamic filters

Running simulation

Available

 Directly not possible, only by adding additional elements (= LPG columns) and calculate then by a logic the same way as the system does it in Simulations
OR
needs to be converted to a price list first which can then be simulated

Creating a new price list

• Create a new one

• Copy an existing one

• Create a revision of an existing one

By converting to a price list

Creating a new price grid

Not possible

• Create a new one

• Copy an existing one

Summary ∑

Available in both UI and Groovy

def q = api.getPricelistSummaryQuery()
q.addObjectTypedId(priceListTypedId) 
q.addProjection(fieldLabel1, "SUM")
q.addProjection(fieldLabel2, "AVG")
q.setDoCount(true)
api.runSummaryQuery()

Available in both UI and Groovy

def q = api.getPriceGridSummaryQuery()
q.addObjectTypedId(priceGridTypedId) 
q.addProjection(fieldLabel1, "SUM")
q.addProjection(fieldLabel2, "AVG")
q.setDoCount(true)
api.runSummaryQuery()

Workflows

Available, on the price list level

Available, on the line item level

Assigning to customer

Available

Available

Matrix

Available

Available