Pricing AutoPilot Processes
These processes are applicable to only the Pricing module.
|
Process
|
Description
|
||
|---|---|---|---|
|
Price Streams and Offsets
|
For OEM clients that want to use price streams to price multiple price points for a single part that are offset from a reference point.
Analyzes the pricing stream setup and then calculates the corresponding price offsets, cost offsets, demand history splits (percentages) per each pricing stream. The pricing stream results are persisted to the SKU pricing stream value table and are used by other downstream processes and functionality to calculate new prices, margins, revenues, and profits at the pricing stream level, which are then aggregated and persisted to the SKU level.
|
||
|
Pricing Monthly Financial
|
Calculates the following monthly financial values for the price stream level: Average Cost, Average Price, Volume, Average Revenue, Average Profit, and Average Margin Percentage. Also calculates the following annual financial values for SKU level: Volume, Average Revenue, and Average Profit.
The Pricing Monthly Financial process is a required process and is intended to be run following the Price Streams and Offsets process. The main purpose of the Pricing Monthly Financial process is to provide the most accurate results for each SKU's stream level monthly volume, revenue, and profit. The secondary purpose of the process is to sum the Monthly data and provide each SKU's annual volume, revenue, and profit. The volume, revenue, and profit outputs become inputs for other processes in Pricing Management and are also viewable on some pages and on some reports.
Process outputs can be see on the Monthly Financial History page. To open the page, from the Pricing Worksheet, click Monthly Financial History.
The date range input, in months, to be executed by the process is configurable by a global setting. During initial startup, all valid historical data should be processed to prime the system. Post implementation startup, the global setting should typically be set to process only 1 prior month (the default) unless special circumstances dictate otherwise.
Valid values include positive integers 0 through 120; 10 years is the max date range.
|
||
|
Price Chain Survey Data Inheritance
|
Analyzes parts in chains and if a part is in a chain, then this process borrows market data from other parts in the chain to spread survey data evenly across the chain for a specific location.
Runs immediately before the Market Statistics Engine process.
|
||
|
Demand History Management
|
Generates Outliers in the demand history.
|
||
|
Market Statistics Engine
|
Calculates the market data statistics for each part market SKU that has supporting survey data. Calculates market data statistics (minimum price, average price, median price, maximum price, Q1 price, and Q3 price) for the Market, Competitive, or Comparable categories.
Expired survey data is not included in the process calculations. Survey Detail Perishable Date is the date that the survey detail record will expire. The value is entered through the Perishable Date field when entering detail for the survey part record.
The Market Statistics AutoPilot process uses the survey data expiration waterfall to determine what survey data is expired versus active.
The survey data expiration waterfall uses two levels of control to determine the expiration of survey data. The survey data expiration waterfall works as follows:
• Waterfall Level 1
If a survey detail record has a Survey Detail Perishable Date <> null, then the application honors this value in the expiration decision logic independent of the global setting.
If Survey Detail Perishable Date > Today's System Date, then the survey detail record is still active and should be included in the Market Statistics calculations.
Else it is expired and should not be included in the Market Statistics calculations.
For example: New survey data comes into a client. The client loads a survey detail record and wants the survey detail record to perish 1 year from today, this is 1 year into the future. If today's date is 1/21/2009, then the SA should load the Survey Detail Perishable Date as 1/21/2010. This means that the survey detail record will be active for one year and then expire on 1/21/2010 based on its own Perishable Date.
• Waterfall Level 2
If the survey detail record's Perishable Date is set to null, then Servigistics compares the Price Date to the Global Expiration Date, where:
Global Expiration Date = Today's System Date - Days ( GS PRC_MARKET_SURVEY_AGE_FILTER)
For example:
Global Expiration Date = (1/21/2009) - Days(12 months)
Global Expiration Date = (1/21/2009) - (365 days)
Global Expiration Date = 1/21/2008
If the Survey Detail record's Price Date is greater than its Global Expiration Date, then the survey detail record is considered active and IS included in the Market Statistics calculations.
If the Survey Detail record's Price Date is less than its Global Expiration Date, then the survey detail record is considered expired and is NOT included in the Market Statistics calculations..
|
||
|
Price Elasticity Engine
|
Analyzes and calculates elasticity, elasticity data stage, the Volume (price) curve equation and price calibration recommendations. For part chain data conditions, this process also rolls up elasticity to the top most part in the chain using Volume weighted average cost and weighted average price.
|
||
|
Group Price Analysis
|
Calculates group price analysis results, which includes part type, part family, part line, and part class group statistics per pricing market. Examples of statistics include Group Average Cost, Group Average Price, Group Average Margin, Group Weighted Average Price, Group Weighted Average Margin, Group Market Statistics, Group Revenues, and Group Profits.
|
||
|
Price Group Elasticity Engine
|
Calculates part type, part family, part line, and part class group statistics per pricing market. Examples of statistics include Group Average Data Stage, Group Average Elasticity, Group Elasticity Curve Equation.
|
||
|
Pricing Engine
|
Calculates the new recommended prices for the configured pairs based on user specified pricing strategies. For example:
• Markup, margin, or cost plus strategy
• Price alignment by group strategy
• Market sensitive price alignment strategy
• Elasticity price optimization strategy
• Direct pricing strategy
Additionally, the process:
• Runs pricing policy simulations.
• Calculates recommended price and estimated volume by pricing policy simulation.
• Calculates margin, revenue, and profit results by pricing policy simulation.
• Applies price rules using reference point by strategy code.
• Applies minimum and maximum price thresholds in sequence for parts in selected strategy codes.
• Applies rounding rules to recommended prices.
This can also be used to automatically approve prices that satisfy the auto-upload test conditions.
|
||
|
Price Offset Management
|
Generates custom prices by applying defined offsets to the Standard Prices to calculate the custom prices.
|
