The chapter discusses:
Price determination.
Period-to-date pricing.
Cost-plus pricing.
Weight and volume pricing.
Tiered pricing.
This diagram provides an overview of how list price and net price are determined for each transaction line during the transaction process.
Price determination process (1 of 2)
Price determination process (2 of 2)
During order entry, when the customer service representative (CSR) creates or modifies a sales order, quote, or contract (when using PeopleSoft Contracts), Enterprise Pricer is called.
First, Enterprise Pricer uses this process to determine the list price for the transaction line:
Find all price rule conditions that match the transaction line.
Check whether the transaction line is list price protected.
For example, in a given sales order, if the order line product price is derived from the buying agreement and the buying agreement price is a list price and List Price Protected is set to Yes, then the list price determination step is skipped and the system moves on to determine the net price for the transaction line.
If the transaction line is not list price protected, find a price list for the product on the transaction line.
The best (lowest) price for price lists associated with price list fields is selected if Consider All Prices is defined for the application.
The base product price is selected for the list price if the system finds no price defined for the product in the price lists.
This is always the default.
Second, Enterprise Pricer determines the net price for the transaction line:
Check to see whether the transaction line is price protected.
If Price Protected is set to Yes then price formulas (adjustments) are not applied to the transaction line. The net price determination step is skipped and the system sets the list price and the net price to the same value on the transaction line.
If Price Protected is set to No, then retrieve the stored conditions that match the transaction line and match those conditions to their associated price formulas from the price rules.
Apply the arbitration plan to filter the list of formulas to only those that apply to the transaction line.
The selected formulas are ones that either end in a decision node or end at the leaf level of the decision tree.
After the list of price formulas is narrowed to only the formulas that apply to the transaction line, sort the formulas according to the hierarchy outlined by the arbitration plan.
Note. For PeopleSoft Order Management transactions (sales orders and quotes), when a buying agreement is in effect for the sold to customer or pricing customer group, the system skips the list price determination process because the list price is established by the buying agreement. If adjustments to the buying agreement are allowed, Price Protected is set to No and Enterprise Pricer determines net price with applicable adjustments using the appropriate arbitration plan. If adjustments to the buying agreement are not allowed, Price Protected is set to Yes and the list price and the net price returned to the transaction line are equal to the price specified on the buying agreement.
The Price and Availability component enables you to price a transaction without actually creating the sales order or quote. You can enter the same information as on the sales order or quote. You can select a base price from the PeopleSoft Inventory Business Unit base price or let the system automatically select a base (list) price from the price lists. The system then applies all price rule formula adjustments. As in sales order processing, Enterprise Pricer returns an audit list of the price rules and formulas that are applied at pricing time.
Batch pricing for the sales order or quote works the same way as the online pricing of the sales order or quote. Depending on how you set up online pricing installation options, pricing during order entry will occur in the background or when you save or click the price order button from the Order Entry page or the Shipment Schedules page.
Note. The entire sales order or quote, including previously entered lines, is priced every time a line or schedule is priced. This includes applying new adjustments or removing prior adjustments, unless they are price protected.
This section discusses:
Reprice or charge orders.
Period-to-date caps.
Period-to-date adjustment review.
Period-to-date pricing dates.
Period-to-date pricing setup.
Use period-to-date pricing to calculate price adjustments based on sales order totals across a predefined time frame, as opposed to within a single sales order. Price adjustments are applied only to the current sales order or sales order line, but the criteria used to determine a price formula match include order totals for multiple sales orders for the current sold-to customer.
Only the current sales order is repriced. When a sales order is repriced, it takes into account only those period-to-date sales order totals that were entered prior to repricing. Any change to a sales order that affects period-to-date pricing is reflected in the current sales order and in any subsequent repricing or new sales orders.
A warning message appears if a sales order is entered that goes over the last price formula for a period-to-date adjustment. You can split the sales order line into two lines to receive as much of an adjustment as possible. A price formula cap is the highest formula value of the last price formula associated with the price rule.
For example: a period-to-date price rule is created for customer USA01 and Product ID 10001. The price formula is for 1 USD to 10,000 USD. The existing sales orders for this customer and product total 9,000 USD. A new sales order for customer USA01 and product 10001 is entered with an order quantity of 10, which puts the cumulative orders over 10,000 USD. If there are no other price formulas on this price rule (over 10,000 USD), a warning is issued to the CSR that 1,000 USD is left on the period-to-date price rule. The CSR can create two order lines to maximize the adjustment for the customer:
One for 1000 USD or less.
One for the remaining quantity.
You can review the period-to-date price adjustments for a sales order from the Price Rule Audit page on the order line or schedule. The period-to-date adjustments appear with the other standard price adjustments and is flagged as a period-to-date adjustment.
You can preview other price adjustments for period-to-date pricing on the Price and Availability page by entering a PeopleSoft Order Management business unit and sold to customer along with the product, quantity, and other order information.
Period-to-date totals are derived from the ORD_SCH_ARCH table. If you are archiving sales orders, leave them in the ORD_SCH_ARCH and ORD_PPRC_SET tables until the current period for period-to-date pricing has expired. Canceled schedules are not included.
Also, do not archive the ORD_SCH_ARCH table if you use the new One-Time-Only or Maximum Quantity price rule features.
To set up period-to-date pricing so that price adjustments are based on a customer's period-to-date sales order totals:
Define the pricing year using the Sales Calendar page.
Select the calendar to use on the Order Management Setup Business Unit page.
If PeopleSoft Promotions Management is installed, you are prompted to use period-to-date pricing after saving the business unit. The system searches for the Calendar ID in PeopleSoft Promotions Management.
Select the period-to-date option on the Price Rule - Formulas page.
Note. If PeopleSoft Promotions Management is installed and you want to use period-to-date pricing, you can select the Period To Date Totals Only check box in the Promotion Limitations group box when defining merchandising activities for a customer promotion or in the Allowance Limitations group box when defining discounts for a national allowance.
You can now price based on a price other than a list price, such as cost or alternate cost. Previously, all pricing calculations, such as discount or surcharge, were based on list price. The list price came either from the price list or the list price of the product. Now the system must first determine the base price for pricing calculations.
If the order line is associated with a buying agreement, the base is always the buying agreement price.
With cost-plus pricing, you can set up a price rule to indicate the pricing base based on certain conditions. If there is no such price rule matched to the transaction line, the list price is used as the base price. If there are matching price base price rules, the order's arbitration plan is used to filter and sort the matching rule to determine the base. If there is no match in the arbitration plan, the list price (the default) is used).
The arbitration plan should have a node with a price rule type of “pricing base,” ideally as the first top-level node in the tree. It can have only one of these decisions as its child:
Use Highest Base: Compare list price and cost and use the larger as the pricing base.
Use Lowest Base: Compare list price and cost and use the smaller as the pricing base.
Use Cost as Base: Use cost as pricing base.
Use List Price as Base: Use list price as pricing base.
Use Alt Product Cost: Use an alternate product cost as pricing base.
After determining the base, the other matching price rules are processed and the selected base is used for all the pricing calculations. However, several additional flags on the price rule specify whether or not the rule applies to transaction lines with a specific pricing base:
Applicable to List Price flag: When enabled, indicates that the price rule applies to transaction lines using list price as the pricing base.
Applicable to Buying Agreement: When enabled, indicates that the price rule applies to transaction lines using a buying agreement as the pricing base.
Applicable to Cost Base: When enabled, indicates that the price rule applies to transaction lines using cost as the pricing base.
Applicable to Alt Cost Base (Applicable to Alternate Cost Base): When enabled, indicates that the price rule applies to transaction lines using alternate cost as the pricing base.
For example, if the pricing base for a specific transaction line is cost, a matching price rule that is not applicable to cost as a base is ignored.
To encourage customers to order in full truck, pallet, or container, you can monitor and offer order discounts based on the weight or volume of the order when setting up price rules. You must also use estimated shipments if pricing by weight or volume.
You can enter the weight and volume option (arbitration plan) on the General Information - Sold to Options page. The weight and volume option is used as the default weight and volume arbitration plan on the sold to section of the Order Entry Form page during order entry. If there isn't a weight and volume option entered on the Order Entry Form page, a warning message appears, alerting the clerk that weight and volume pricing is used for the PeopleSoft Order Management business unit and to select a weight and volume option for the system to calculate the weight and volume pricing.
You can view the weight and volume pricing adjustments on the Estimated Shipments Page. Use the Shipment Price Adjustments Page to view the price rule information for weight and volume pricing.
Note. Weight and volume is calculated when the order is saved. If weight and volume was calculated manually, it is recalculated at save time.
See Also
Maintaining Order Header and Line Information
This section discusses:
Single-tiered pricing rule.
Multiple-tiered pricing rules.
Discounted giveaways and “buy one, get one free” rules.
Different product pricing and ordering units.
Mathematical expressions in a price rule.
Tiered pricing enables different pricing on portions of a schedule. It is used with quantity or price formula breaks. The formula breaks should not overlap. Tiered rule pricing is only available for price rules with a Price Action Type of Discount/Surcharge and Price Override.
Consider this example: We have a price rule and schedule set up for selling sinks.
Price rule: Sinks Rule 1
Price action type: discount/surcharge
Rollup flag by: schedule
Condition: Product ID=10050–10060 (these items are all sinks)
Formulas:
Formula range ID |
Minimum and maximum quantities |
Discount |
1 |
1 to 10 |
5 percent |
2 |
11 to 20 |
10 percent |
3 |
21 to 99 |
20 percent |
The schedule line lists a quantity purchase of 25 sinks. The first 10 sinks get a 5 percent discount. The next 10 sinks get a 10 percent discount. The rest of the sinks get a 20 percent discount. Three pricing schedules are generated for the same order schedule.
There are instances where multiple-tiered rules are applied to the same schedule. Because different price rules use different quantity breaks, the quantities are merged by net price. With a cascading adjustment method, subsequent adjustments are applied to the existing price schedules. Additional pricing schedules are created as needed.
For example, assume we have already created the price rule described in the previous section. Now we add an additional price rule:
Price rule: Sinks Rule 2
Price action type: discount/surcharge
Rollup flag by: schedule
Condition: Product ID=10050–10060 (these items are all sinks)
Formulas:
Formula range ID |
Minimum and maximum quantities |
Discount |
1 |
1 to 15 |
1 percent |
2 |
16 to 30 |
2 percent |
Based on this tiered rule, the first 15 sinks receive a one percent discount. The rest of the 10 sinks get a two percent discount. The quantities and the related adjustments from both price rules are calculated first then merged by net price.
These are the quantities and related adjustments from the price rule “Sinks Rule 1.”
Quantity group |
Quantity |
Discount |
Formula |
A |
10 |
5 percent |
1 |
B |
5 |
10 percent |
2 |
C |
5 |
10 percent |
2 |
D |
5 |
20 percent |
3 |
These are the quantities and related adjustments from the price rule “Sinks Rule 2.”
Quantity group |
Quantity |
Discount |
Formula |
E |
10 |
1 percent |
1 |
F |
5 |
1 percent |
1 |
G |
5 |
2 percent |
2 |
H |
5 |
2 percent |
2 |
Comparing the results from both price rules we know that the first 10 sinks get a five percent discount from the Sinks Rule 1 and a one percent discount from the Sinks Rule 2 for a total of six percent discount and end up with the same net price. Similarly, the next five sinks, get a 10 percent discount from the Sinks Rule 1 and a one percent discount from the Sinks Rule 2 for a total of 11 percent discount and end up with the same net price. Grouping the quantity by same net price will give us the final pricing schedules:
Pricing schedule |
Quantity |
Discount |
Formulas |
Quantity group |
1 |
10 |
–6 percent |
–5 percent Sinks Rule 1, Formula ID 1, and –1 percent Sinks Rule 2, Formula ID 1 |
A and E |
2 |
5 |
–11 percent |
–10 percent Sinks Rule 1, Formula ID 2, and –1 percent Sinks Rule 2, Formula ID 1 |
B and F |
3 |
5 |
–12 percent |
–10 percent Sinks Rule 1, Formula ID 2 and –2 percent Sinks Rule 2, Formula ID 2 |
C and G |
4 |
5 |
–22 percent |
–20 percent Sinks Rule 1, Formula ID 3, and –2 percent Sinks Rule 2, Formula ID 2 |
D and H |
Promotional pricing efforts are attempts to attract new customers, to get customers to try new products, or to liquidate excess inventory. A common promotion is to offer a free or discounted product if the customer purchases a particular product, often called a Buy-One-Get-One or BOGO. Enterprise Pricer enables you create BOGO price rules and also to create price rules that allow the customer to buy one product and get a different product at a discounted rate.
Enterprise Pricer enables you to define complex BOGO and BOGO-like promotions. You can specify the quantity of the giveaway and indicate the discount, surcharge, or price. Some sample types of promotional discounts that are possible include:
Buy one of product A, get one of product B free.
Buy two of product A, get four of product B at a 50 percent discount, and any additional purchases of product B at 10 percent off.
Buy one of product A, get one of product B at 50 percent discount per line.
Buy six of product A, get three of product B at 10 percent discount per order.
Buy five pounds of product A, get 10 pounds of product B at 20 percent off.
See Also
Numerous industries have a different ordering unit of measure and pricing unit of measure. For example, in the paper industry typically orders are made in rolls. However, the product is priced per hundred-weight (CWT). Enterprise Pricer 8.9 enables you to order in one unit of measure but define a different pricing unit of measure for the price rule. This enables the pricing engine to calculate the item price using a different unit of measure from the order unit of measure. When the order line is processed, the price based on the order UOM appears on the sales order page. Pricing results based on the pricing UOM appear on the Pricing Detail page.
Achieving pricing goals specific to the needs of an organization is a crucial element to success in selling products. Sometimes this requires the ability to define organization-specific formulas that use a series of different operands. Enterprise Pricer enables you to create mathematical expressions in the price rule that is used to calculate the net price for a given product. This allows you to define complex promotional discounts where you specify the adjustment, override price, giveaway quantity using a custom mathematical expression. For example: a 5 percent discount plus a 5 USD discount to all orders of product 10050 during the ordering period February 1, 2005 to December 31, 2005.
With Enterprise Pricer, you can:
Define custom mathematical expressions, using the expanded set of pricing operands.
Use the expanded list of variables known to Enterprise Pricer (net price, list price, and so forth).
Define pricing variables for use with one or more price rule.
Call an external process to run when a price rule applies to an order line.
Cap the mathematical expression calculations, for example, (List Price *.95) or USD 1000, whichever is smallest.
Note. You cannot define a mathematical expression that combines quantity and price for giveaways unless you add an additional field to the system.
Using Indexes in Pricing Calculations
In PeopleSoft Contracts, IndexStartValue, IndexEndValue, and IndexStartAmount are pricing variables that are used in the mathematical expression attached to price formula. They are used for price index calculations. IndexStartValue and IndexEndValue are price index values effective on IndexStartDate and IndexEndDate that are automatically retrieved by the Enterprise Pricer during the pricing process from RT_RATE_TBL.
Note. IndexStartValue, IndexEndValue, and IndexStartAmount are used together. If one is used, you cannot use any other pricing variables.
The RT_RATE_TBL table is used to maintain the price index data:
Field Name |
Description |
Used By Enterprise Pricer |
RT_RATE_INDEX |
Market Rate Index |
Identify the index. Its category must be “Economic Indicator,” as defined in table RT_INDEX_TBL. |
TERM |
Term |
N/A |
FROM_CUR |
From Currency Code |
Both currency codes, FROM and TO must be the same. They match the transaction’s currency. |
TO_CUR |
To Currency Code |
Both currency codes, FROM and TO must be the same. They match transaction’s currency. |
RT_TYPE |
Rate Type |
N/A |
EFFDT |
Effective Date |
Used to select effective index value. |
RATE_MULT |
Rate Multiplier |
Index value. |
RATE_DIV |
Rate Divisor |
N/A |
SYNCID |
Synchronization ID |
N/A |
LASTUPDDTTM |
Last Update Date/Time |
N/A |
As an example, suppose these market rates exist:
Market Index |
Effective Date |
Rate (Index Value) |
CPI |
January 1, 2000 |
1200 |
CPI |
July 1, 2000 |
1280 |
CPI |
January 1, 2001 |
1300 |
CPI |
July 1, 2001 |
1320 |
GOV |
January 13, 2000 |
100.20 |
GOV |
June 20, 2000 |
100.40 |
GOV |
December 11, 2000 |
100.80 |
GOV |
March 1, 2001 |
101.10 |
Then a rate renewal takes place:
Current Offering Amount |
Start Date |
End Date |
Renewal Basis |
Price Index |
Additional Percent |
Price Cap Basis |
Cap Percent |
10,000 |
February 1, 2000 |
January 31, 2001 |
Index+additnl percent |
CPI |
2 |
Percent |
5 |
10,000 |
February 1, 2000 |
January 31, 2001 |
Additnl percent |
GOV |
1.5 |
Index + Addtnl percent |
1 |
You can set up price rule formulas to address the rate change:
Formula ID |
Adjustment Flag |
Numeric Value |
Text Value (Math Expression) |
Market Rate Index |
Select Small/Larger |
1 |
Percentage and Math Expression |
5 |
IndexStartAmount * (1 + (IndexEndValue – IndexStartValue)/IndexStartValue + 2 / 100) |
CPI |
Smaller |
2 |
Percentage and Math Expression |
1.5 |
IndexStartAmount * (1 + (IndexEndValue – IndexStartValue)/IndexStartValue + 1 / 100) |
GOV |
Smaller |
3 |
Percentage and Math Expression |
2 |
IndexStartAmount * (IndexEndValue / IndexStartValue) |
GOV |
Larger |
The starting values are:
IndexStartAmount = 10000.
StartDate = February 1, 2000.
EndDate = January 31, 2001.
The first formula is processed in this manner:
For the CPI market rate index, the Market Rate Table is used to find the index values for the start and end date, 1200 and 1300. The mathematical expression is evaluated as:
IndexStartAmount * (1 + (IndexEndValue – IndexStartValue)/IndexStartValue + 2 / 100) = 10000 * (1 + (1300 – 1200) / 1200 + 2 / 100) = 10000 * (1 + 0.0833 + 0.02) = 11033
The percentage calculation is, 10000 * (1 + 5 / 100) = 10500
Because the formula indicates to take the smaller of the two values (11033 and 10500), 10500 is the result of the formula.
The second formula is processed in this manner:
For the GOV market rate index, the Market Rate Table is used to find the index values for the start and end date, 100.20 and 100.80. The mathematical expression is evaluated as:
IndexStartAmount * (1 + (IndexEndValue – IndexStartValue)/IndexStartValue + 1 / 100) = 10000 * (1 + (100.80 – 100.20) / 100.20 + 1 / 100) = 10000 * (1 + 0.0060 + 0.01) = 10160
The percentage calculation is 10000 * (1 + 1.5 / 100) = 10150
Because the formula indicates to take the smaller of the two values (10160 and 10150), 10150 is the result of the formula.
The third formula's processing uses index values to perform different types of calculations:
For the GOV market rate index, the Market Rate Table is used to find the index values for the start and end date, 100.20 and 100.80. The mathematical expression is evaluated as:
IndexStartAmount * (IndexEndValue / IndexStartValue) = 10000 * (100.80 / 100.20) = 10000 * 1.0060 = 10060
The percentage calculation is 10000 * (1 + 2 / 100) = 10200
Because the formula indicates to take the larger of the two values (10060 and 10200), 10200 is the result of the formula.
See Also