This chapter covers the following topics:
Modifiers are pricing actions that drive your pricing processes in addition to price lists, formulas, and agreements. Modifiers can adjust net price either up or down. Modifier actions include discounting, adding surcharges, charging for shipping, changing order terms (payment, freight, or shipping method) or adjusting price based on promotional pricing actions.
Key Implementation Decision: How do I use modifiers in pricing actions? Which modifiers best demonstrate my pricing processes?
Oracle Advanced Pricing provides seeded modifier lists and modifier line types. The modifier list types are: discount, surcharge, deal, promotion, and freight and special charges.
The following table displays modifier types that you can create within a modifier list.
|Modifier Type (Top row)||Discount List||Surcharge List||Deal (must be associated with a promotion)||Promotion||Freight and Special Charges List|
|Other Item Discount||No||No||Yes||Yes||No|
|Freight and Special Charge||No||No||No||No||Yes|
Important: You can view or update modifier lists only for your pricing transaction entity.
To view and update the modifier list, the pricing transaction entity (PTE) for the modifier list and the PTE set for the profile option QP: Pricing Transaction Entity must match.
You can only view or update a modifier list in your source system. To update the modifier list, the source system for the profile option QP: Source System Code and the modifier list must match.
You can set up prices and modifiers based on hierarchical item categories and flattened item categories. You can define category-based pricing for hierarchical categories for price lists or modifiers; however, for you to do this, a default hierarchical category set (catalog) must be set for the functional area of the source system creating the data. For more information, see Pricing for Hierarchical Item Categories.
Oracle Advanced Pricing provides an HTML-based user interface (UI) that features guided steps, user-friendly pages, and shortcut links for setting up and maintaining modifiers, price lists, and qualifiers.
In the HTML user interface, you can create the following modifier list and modifier line types:
Note: You must use the Oracle Forms-based user interface to create a Freight and Special charge List.
Once you have created a modifier list, you can add modifier lines that define the type of price adjustments and benefits that the pricing engine applies to pricing requests. The following modifier line types are available in the HTML UI:
Discount: Creates a negative price adjustment.
Promotional Goods: Adds a new item to the order line with a price adjustment or benefit when the customer orders a particular item on the same order.
Price Break: Applies a variable discount or surcharge price adjustment to an eligible break type. You can use both point and range type breaks.
Surcharge: Creates a positive price adjustment. For example, a 10 percent handling charge is applied to a customer order.
Oracle Advanced Pricing User's Guide, Modifiers
As you analyze and understand a client's business pricing scenario, you need to address some key implementation decisions to develop a logical pricing solution. These decisions will be discussed throughout the chapter. Visualizing the price bands of an organization may assist you in developing an effective implementation plan for Oracle Advanced Pricing.
The following example provides a visual guide for mapping the modifiers of an organization to the components of Oracle Advanced Pricing.
The source pricing data is based upon the assumptions that item Super Wine has an item category of Wine. An order for a quantity 15 was placed on 15-Jun-2000 for a customer XYZ Corporation, who belongs to a customer class VIP.
|Bucket||Pricing Phases||Incompat. Group||Qualifiers/ Product Attributes (Precedence)||Modifiers/ Price List||Discount||Sub Total|
|Base Price||List Line Base Price||EXCLUSIVE||Customer Class - VIP (310)
Item Code - Super Wine (220)
|Corporate List - $1000||Null||Null|
|Base Price||List Line Base Price||EXCLUSIVE||Item Category - Wine (290)||Preferred Vendors - $800||Null||Null|
|Base Price||List Line Base Price||Null||Null||Null||Null||$1,000|
|Bucket 1||List Line Adj.||Level 1||Item Quantity > 10 (800)
Item Code - Super Wine (220
|4th July Promotion 10%||$100||Null|
|Bucket 1||List Line Adj.||Level 1||Customer Class - VIP (310)||Summer Promotion 15%||Null||Null|
|Bucket 1||List Line Adj.||Level 2||Customer id - XYZ Corp (260)||VIP discount $40||$40||Null|
|Bucket 1||List Line Adj.||Level 2||Customer id - XYZ Corp (260)||Weekday Discount $20||Null||Null|
|Bucket 1||All Line Adj.||Level 1||Item Category - Wine (290)||General Discount - $20||$10||Null|
|Bucket 1||All Line Adj.||Exclusive||Order Date < 01-Dec-2000 (510)||Seasonal Discount - $10||Null||Null|
|Bucket 1||Header Level Adj.||Level 1||Null||Preferred Customer 10%||100||Null|
|Bucket 1||Line Charges||Level 1||Null||Handling Charge $20||$20||Null|
|Bucket 1||Header Level Charges||Level 1||Null||Null||Null||Null|
|Bucket 1||Header Level Charges||Null||Null||Null||Null||$750|
|Bucket 2||Adj.||Level 2||Null||High usage surcharge 2%||($15)||Null|
|Bucket 2||All Line Adj.||Level 2||Null||Null||Null||Null|
|Bucket 2||Header Level Adj.||Level 2||Null||Null||Null||Null|
|Bucket 2||Line Charges||Level 2||Null||Null||Null||Null|
|Bucket 2||Header Level Charges||Level 2||Null||Null||Null||Null|
|Bucket 2||Header Level Charges||Level 2||Null||Null||Null||Null|
Note: Key to Table Short Names
Adj. = Adjustments
Line: Applies only to a specific order line.
Group of Lines: Applies to groups of lines in the order.
Order: Applies to an entire order.
For example, a volume-based discount modifier applied at the line level will consider only volume on the qualifying line. A volume-based discount modifier applied at the group of lines level will process the volume across all qualifying lines on the pricing request.
You can select from the available application methods to create different pricing actions:
Amount: Creates a fixed price adjustment on each unit for the amount that is specified in the value field.
Percentage: Creates a percentage price adjustment on each unit for the percentage that is specified in the value field.
New price: Overrides the selling price of the item and makes it the new price.
Lumpsum: Creates a price adjustment for the entire sum amount of the line.
The application methods that are available depend on the modifier line type and level selected. This can be found on the Discounts/Charges tab. You can use a formula to drive the value of your pricing action.
The following tables depict the application methods allowed based on various modifier levels (the application method is listed in the top row).
Modifier Application Methods: Line Level
|Modifier Line type (column below)||Per. Value||Per. Form.||Amt. Value||Amt. Form.||New Price Value||New Price Form.||Lmpsm. Value||Lmpsm. Form.|
|Freight/ Special Charge||Yes||Yes||Yes||Yes||No||No||Yes||Yes|
|Other Item Discount (Get)||Yes||No||Yes||No||Yes||No||Yes||No|
|Promotional Good (Get)||Yes||No||Yes||No||Yes||No||Yes||No|
Note: Key to Table Short Names
Amt. = Amount
Form. = Formula
Lmpsm = Lumpsum
Per. = Percent
Modifier Application Methods: Group of lines Level
|Modifier Line type (column below)||Per. Value||Per. Form.||Amt. Value||Amt. Form.||New Price Value||New Price Form.||Lmpsm. Value||Lmpsum. Form.|
|Other Item Discount (Get)||Yes||No||Yes||No||Yes||No||Yes||No|
|Promotional Good (Get)||Yes||No||Yes||No||Yes||No||Yes||No|
Modifier Application Methods: Order Level
|Modifier Line type (column below)||Per. Value||Per. Form.||Amt. Value||Amt. Form.||New Price Value||New Price Form.||Lmpsm. Value||Lmpsm. Form.|
|Freight/ Special Charge||No||No||No||No||No||No||Yes||Yes|
The following section outlines special considerations when applying discounts at the Group of Lines level for the following modifier types: Discounts, Other Item Discount, Price Break Header, and Promotional Goods.
For modifier types at the Group of Lines level, be aware of the following considerations:
You can select only the Volume Type of Item Quantity and Item Amount.
If some excluded items or item categories are set up, then order lines that are based on an excluded item or item category that qualify for this modifier, are not considered for group of lines calculation.
Example: Group of Lines processing and Excluded Items
To demonstrate how a modifier evaluates order lines at the “group of lines” level (with an excluded item), two modifiers have been set up:
Modifier_Shampoo1 is set up without any excluded items.
Modifier_Shampoo2 is set up with an excluded item “Shampoo1.”
The setup for both modifiers is summarized in the following table:
|Modifier Name||Level||Item Category||Volume||Excluded Item|
|Modifier_Shampoo1||Group of Lines||Shampoo||> 100 Qty||None|
|Modifier_Shampoo2||Group of Lines||Shampoo||> 100 Qty||Shampoo1|
Suppose that a customer then placed an order for two shampoo items (Shampoo1 and Shampoo2) and conditioner as outlined in the following table:
|Order Line ID||Item Category||Item||Quantity|
Both modifiers Modifier_Shampoo1 and Modifier_Shampoo2 are then applied against the Shampoo order. However, each modifier evaluates the group of lines differently based on the modifier setup (one modifier considers the exclude item and the other does not) as described in the following outline.
Modifier_Shampoo1 applied to Shampoo order
Before Modifier_Shampoo1 can be given, the lines from the Shampoo order are evaluated:
Order lines 1 and 2 qualify for Modifier_Shampoo1 because the items are from the Item Category of Shampoo.
The quantity of the order lines 1 and 2 that qualify are summed to determine whether the ordered quantity is greater than 100. The sum is 110 which is greater than 100.
As a result of this check, the modifier Modifier_Shampoo1 is given because the:
Item category for the considered items is Shampoo.
Ordered quantity of the lines for Item Category shampoo is greater than 100.
Modifier_Shampoo2 applied to Shampoo order
Before Modifier_Shampoo2 can be given, the order lines are evaluated in the following way:
Order line 2 qualifies for Modifier_Shampoo2.
Order line 1 is rejected because the item Shampoo1 is an exclude item (see the set up for Modifier_Shampoo2 where Shampoo1 is listed as the Exclude Item, and is therefore excluded).
The quantity of order line 2 (the only order line that qualifies so far) is summed to determine whether the ordered quantity is greater than 100. The sum is 40 which is less than 100.
As a result of this check, the modifier Modifier_Shampoo2 is not given because the ordered quantity is not greater than 100.
Using qualifiers, you can tie the structure of your modifiers to your customer hierarchy. For more information about this topic, see Implementation Methodology.
You can set up modifiers for item number, item category, or all items. Through pricing attributes, you can further define your product hierarchy.
By selecting exclude, you can exclude individual items or item categories from being applied to a modifier. If an item is in an excluded item category and in an non-excluded item category, the excluded item category is honored. if a hierarchical category is specified in excluded items, then any items that belong in the child categories will be excluded, as well as any end items that are associated with that category.
For example, a modifier for all items excludes item category "IC 1." You have an item Z that is in IC1, IC2, and IC3. When the engine assess that Item Z is in IC1, the modifier is not applied, even though the item is in IC2 and IC3.
No UOM conversions are available for modifiers. The pricing engine evaluates only modifier lines that have matching UOMs or null value that is selected for the pricing UOM. For example, item A has a UOM of each with primary UOM checked for the price list line. The ordered UOM for item A is dozen. The engine will therefore consider only modifier lines with each or with null values. UOM is not a mandatory field for modifier types other than price breaks.
Note: The UOM is not mandatory for promotional modifiers if the volume type is Item Amount. The UOM is mandatory only in the following cases:
List line type is Promotional Goods, Other Item Discount, or Item Upgrade and the volume type is not Item Amount, Period1 Item Amount, Period2 Item Amount, or Period3 Item Amount.
The Modifier line volume type is Item Quantity.
The pricing phase determines when the pricing engine applies a modifier. For example, modifiers in the list line adjustment phase are applied only after leaving the line. Modifiers in the all lines adjustment phase are applied only after saving the line. Consider unnecessary pricing engine calls that can affect performance.
The values for precedence will default based on the setup of the product attribute (such as item number and item category) and any qualifier attributes that are defined in the Context and Attributes window. For more information, see Implementation Methodology and Precedence and Best Price.
You can make modifiers incompatible with each other by placing them in the same incompatibility group level. When this is done, the pricing engine applies only one modifier per phase to the order line or order. For more information on incompatibility levels, see Precedence and Best Price.
Pricing buckets control how discounts and other benefits are calculated across phases. Grouping discounts and benefits into buckets helps determine the net selling price across all pricing phases.
Modifiers that are assigned to a Null bucket are applied last and always adjust from the list price. Order level modifiers must be in the Null bucket. The pricing engine uses the following steps when calculating the selling price for Null buckets:
Calculates percent discounts using the list price.
Sums all bucket modifier values to create a bucket subtotal.
Applies the subtotal after the last numbered bucket.
Suppose that the following buckets are set up, each with a different adjustment:
Null bucket: a 50% discount is assigned to the Null bucket.
Bucket 1: a 10% discount is assigned.
Bucket 2: a 10% surcharge is assigned.
The buckets are used to calculate the price for an SP ATO Model with a list price of $55. The following table shows how the final price is calculated:
|Bucket||Modifier Adjustment||Calculated Price||Final Price|
|Bucket 1||10% discount||55 - (10%*55)||$49.50|
|Bucket 2||10% surcharge||49.5 + (10%*49.5)||$54.45|
|Null bucket||50% discount. Note: The modifiers are applied last and taken out of the list price.||54.45 - (50%*55)||$26.95|
Determine the number of buckets that you need by counting subtotals on your client's invoice. Control the modifier calculation sequence by adding the numbers between beginning list price and final net price. Plan the assignment of discounts to buckets based on these subtotals.
The null bucket calculates the modifier off of the list price and then applies the adjustment to the last bucket's subtotal. Order level modifiers are always in the null bucket.
Oracle Advanced Pricing does not restrict the number of buckets that you can define.
If a manual modifier is applied for a given bucket, all modifiers in subsequent buckets will get re-evaluated.
Incompatibility occurs when the pricing engine finds more than one modifier to return but only one can be applied. The engine resolves this incompatibility using either precedence or best price.
Automatically Apply: Select Automatically Apply to have the modifier applied automatically by the pricing engine. Certain modifiers must be applied automatically and in these cases, you cannot change the value.
Customer Must Ask For List (or Ask For): Modifiers with the Customer Must Ask For List box selected are given only if requested by the user through calling applications. This field can be used when the list type is Promotion or Deal.
Override: Select Override to enable the modifier adjusted price to be manually overridden. If this box is not selected, then the modifier adjusted price cannot be overridden. The Override box appears only for those types of modifier that supports override.
Effectivity dates at the modifier list and modifier line: Effectivity dates on the modifier line must fall in between the effectivity dates for the modifier list.
Additional date types for order date and requested ship date: These are additional parameters that can be set to control the effectivity of the modifier list.
The Comparison Value field: This field holds the approximate value for the benefit item(s) for item upgrade, term substitution, coupon issue, other item discount, and promotional good. This value is used during best price processing (the field does not impact Oracle General Ledger).
Calculate Price flag: This is passed by the calling application to enable the calling application to fully or partially freeze a price request. Depending on the value of the flag, the price can be completely frozen, or additional modifiers can be applied in certain phases.
Warning: Do not change the Calculate Price field to Calculate Price on a free good item.
You can define manual adjustments for discounts, surcharges, freight charges, and point price breaks. To override the selling price directly on the order line, you must define a manual discount or a manual surcharge. Remember the following guidelines when defining manual adjustments:
The Automatic box must be cleared.
The Override box must be selected for overrideable manual adjustments.
Buckets are available for manual modifiers.
Manual adjustments are applied based on pricing phase.
The engine returns manual discounts based on the value that is defined in the profile option QP: Return Manual Discounts.
If the profile option is set to Y, then all manual discounts are returned and all automatic discounts that are not considered are returned as manual discounts. This is the default.
If the profile option is set to N, then all manual and automatic discounts undergo incompatibility processing and one per incompatibility group is returned.
Discounts (automatic or manual) that are deleted as part of incompatibility processing are returned as manual discounts.
For manual discounts that use formula calculation, all attributes for the formula must be sent to the pricing engine in the pricing request. The engine returns the manual discount, which can be applied to the order line.
On the Manual Adjustments field for the unit selling price on the sales order line, only line and line group manual adjustments appear.
After applying manual adjustments to the line the calculate_price_flag remains Y. If you do not want other adjustments applied to the line, set the calculate_price_flag to P or N. If you want to apply order level manual adjustments, do so through the View Adjustments screen. If the calculate_price_flag on any of the lines is P or N, order level adjustments cannot be applied to the order. If no applicable manual adjustments are available for a line, a note appears that indicates that no applicable discounts are available.
To apply a manual adjustment in Oracle Order Management, see the Oracle Order Management Suite Implementation Manual, or the Oracle Order Management Suite User's Guide.
For an other item discount to apply, all items must be correctly sequenced on the order. The pricing phase must be tied to an event that considers all lines in the order. Other item discounts may not be manual or overrideable. Other item discounts ignore incompatibility for the get line.
Benefit items in the Get region can be defined only at the item level. Users should not enter values for the get price and get UOM fields. The price of the benefit item should be on the order.
Because the pricing engine does not support recurring other item discounts, get quantity should be 1. The engine will apply the discount to all quantities of the item. For example, for every 5 pastries and 2 cookies you order, you get 2 cookies at 50% off. Using this modifier, if you order 10 pastries and 4 cookies, you receive 4 cookies at 50% off. Similarly, if you order 10 pastries and 3 cookies, all 3 cookies are 50% off.
If you discount using the percent application method, percent is based on the bucket value that is defined in the modifier summary tab. For example, if the other item discount is in bucket 2, then a 5% discount is given after all adjustments for bucket 1 are applied to the get item.
A promotional good such as Buy 1 PC and get a free mouse, or buy 1 PC and get free speakers can be set up in the following ways using modifiers:
Set up two modifiers:
Modifier A: Buy 1 PC and get 1 free mouse.
Modifier B: Buy 1 PC and get free speakers.
Make the two modifiers incompatible with each other and set the precedence so that the modifier with the higher precedence will be automatically applied.
Set up two Other Item discount modifiers:
Modifier A: buy 1PC and buy 1 mouse, then get the mouse free.
Modifier B: buy 1 PC and buy speakers, then get the speakers free.
Make these two modifiers incompatible with each other and then set the precedence. When the PC is ordered and the mouse or speakers are added to the order, one of these items is free.
Note: In the Get region of the Define Modifier Details window, only price list lines that are stand-alone price list lines are displayed in the list of values. All service items and all price break lines (headers and children) are not displayed and cannot be selected from the list of values.
Benefit items that are set up in the Get region can only be defined only at the Item level.
The pricing engine returns an additional order line for the promotional good and sets the Calculate Price Flag to No. Additional modifiers are not applied to the line unless the flag value is changed to Yes or P. This prevents negative selling prices on free good items. If order lines exist where the Calculate Price flag is set to No, then additional order level modifiers are not applied.
Note: Promotional goods are not supported at the Order level.
Warning: Do not change the Calculate Price Flag to Calculate Price on a free good item.
Payment, freight, and shipping terms can be substituted using the terms substitution modifier.
The modifier level is always line or order level.
Define product attribute by item number or item category for a term substitution modifier at the line level.
Promotional upgrade is the relationship type.
The UOM for the upgraded item will be the same as the UOM of the original item.
The pricing engine recognizes only the original item for additional modifiers. It never recognizes the upgraded item.
Price breaks have the following characteristics:
|Price Break Characteristic||Example|
|Consist of price break lines without gaps between subsequent break ranges.||0 to 100 (greater than 0 but less than or equal to 100).
100 to 200
200 to 300
Note: For example, a quantity of 100.0 would be eligible for the first price break range (0-100); however, a quantity of 100.1 would be eligible for the second price break range (100-200).
|The Value From of the first break range starts with 0.||0 to 100|
|The Value From of the current price break matches the Value To from the previous break (applies to breaks other than the first break range).||0-100
Important: Copying price breaks created in a release before R12: When you copy a price break (for example, by copying a price list or modifier list with price breaks) from a pre-R12 release, the price breaks are updated to the price break format that is described in the preceding section. You need to review the changes to ensure that the converted price break setup meets your pricing objectives.
If the ordered quantity does not fall in the price range of the price list, the price is still calculated and defaulted in the sales order line. Therefore, ensure that the price ranges are set up correctly to get the pricing results you desire. For example, suppose you create the following range price breaks for price list Item AS54888 (Application Method is Unit Price):
Value From/To: 0 to 5 Price: 1.00 each
Value From/To: 5 to 7 Price: .75 each
If Price Type is Point: The price is not returned if the ordered quantity does not fall in the price range of the price list.
If Price Type is Range: A price of 0 is retrieved for the ordered quantity that does not fall in the price range.
For example, if a Sales Order for 10 items of AS54888 were placed, the price would be calculated as follows (Price Type is Range):
(5*1) + (2*0.75) + (3*0)/10 = 0.65 Unit Price
Notice that the last 3 items fall out of the price range and therefore a unit price of 0 is returned. Therefore it is important that the price breaks are set up correctly to get the desired price results.
When setting up price breaks, you can choose from either point or range breaks to determine price break processing:
Point Price Break
Consider the following example discount rules:
Item quantity ordered 0-10: 1% discount
Item quantity ordered 10-50: 2% discount
Item quantity ordered 50-999: 5% discount
If this is a line level price break and the ordered quantity is 55, then a 5 percent discount is applied to the order line. If this is a group of lines modifier, the total quantity over all the group of lines on the order receive the discount.
Range Price Break
Using the point price break example, if the ordered quantity is 55, then the first 10 items ordered receive a 1% discount, the next 40 receive a 2% discount, and the remaining 5 receive a 5% discount. The discount is then averaged and applied to the order line.
Accumulated Range Breaks
Accumulated range breaks extend the regular range break feature for modifiers. You can use accumulated range breaks to enable calling applications such as Oracle Order Management to pass accumulation values to the pricing engine using accumulation attributes. For more information about setting up and using accumulated range breaks, see Using Accumulated Range Breaks.
Important: For Oracle Order Management, when you split a line, the selling price changes if the volume falls into a different price bracket. At that point, the outcome depends on the value of the Calculate Price Flag prior to the split. To prevent the price from automatically changing, set the Calculate Price Flag field to freeze price prior to splitting the line.
Two modifier lines must be set up when you are defining a coupon issue in the modifiers window. The price adjustment or benefit is linked to the coupon issue. When you are setting up the coupon issue line, a modifier number is mandatory. The pricing engine uses the number to generate a unique number series for the coupon which it passes to the calling application. The customer quotes the number when redeeming the coupon in the calling application.
You can create “Ask For” promotions by selecting one of the following when setting up a modifier:
Customer Must Ask For List box (HTML UI)
Ask For box: (Forms-based UI)
Note: This field can be used when the list type is Promotion or Deal.
When the Ask For box is selected, the customer must “ask for” the promotion by supplying a promotion name or number.
The pricing engine validates order eligibility for the asked for promotion after the order is sent to the pricing engine.
You can also set up both automatic and manual asked for promotions. The methods in which the calling application applies asked for promotions depends on the calling application.
You can mark modifiers as recurring in the break type field on the modifier summary tab. The following modifier types enable recurring:
Promotional good (additional buy items do not recur)
The following example illustrates a recurring coupon issue: for every 5 items ordered, get a coupon for 10% off a future order. If you order 15 items, then you receive 3 coupons.
Both monetary and non-monetary accruals can be created through the modifier setup window. Accruals are given as a percentage, amount, or lumpsum and do not affect order line selling price. Accruals can have expiration dates attached to them and do not appear as chargeable items on invoices. Accrual accumulation is stored in the OE_Price_Adjustments table. You can make reference to accruals may be made by selecting the Accrual flag.
Remember the following when setting up accrual discounts:
Select the Accrual box on the Discounts/Charges tab.
Benefit quantity and benefit UOM are of the benefit that you want to accrue.
Note: For Coupon Issue modifiers, the Benefit Quantity and Benefit UOM fields are not supported.
Expiration date specifies when the accrued transactions expire (optional).
For the expiration period and expiration type, the expiration period begins when the item begins to accrue. The pricing engine will calculate the expiration date.
Note: The expiration period and expiration type fields cannot be entered if expiration date has been entered.
Accrual conversion rate is used to specify the conversion of the benefit UOM to the primary currency. The following example illustrates a conversion rate: if one air mile is 0.50 currency units, the accrual conversion rate is 0.50. The UI window exists for marking accruals as redeemed.
Fields reserved for future use:
Percent Estimated Accrual Rate
Buckets with Monetary Accruals
Because accruals do not affect selling price on the order line, the pricing engine does not include accruals in bucket calculations. The engine uses bucket numbers to determine the price with which to calculate accrual value. The following table illustrates this concept.
|Bucket||Modifier||Price Adjustment||Accrual Amount||Bucket Subtotal||Selling Price|
Accrual discounts are accounted for in the same manner as regular discounts in Oracle Advanced Pricing, Oracle Order Management, and Oracle Accounts Receivable. Oracle General Ledger account information is currently not used in Oracle Advanced Pricing modifier and accrual redemption forms.
Oracle General Ledger account information from Oracle Order Management cannot be passed to Oracle Accounts Receivable without a workaround (for example, Oracle Trade Management) using standard memo lines for auto invoicing. Discounts are expensed as a sales expense and accruals are deferred expense. Each implementation will require establishment of Oracle General Ledger accounts and mapping information flow of accounting for discount expenses.
No interface exists for Oracle Accounts Receivable and Oracle Accounts Payable to research available accruals, balance, and decrementing for payments.
Currently only net revenue is posted to the Oracle General Ledger. This posting occurs between Oracle Order Management and Oracle Accounts Receivable products.
Accruals can be reviewed and marked as redeemed in the accrual redemption screen. This screen is an online view that reflects all accrual records from transactions. It can be used to view all redeemed and unredeemed records, or you can view using a more specific query, such as modifier number, customer, or redeemed only.
Querying any customer name or customer number returns all redeemed and unredeemed records for the customer regardless of modifier number. Querying by modifier returns specific modifiers with records for all customers who qualify for it.
Transaction type and source system are populated by any automated redemption processes. This reflects both manual redemption and those created by other transaction sources such as Oracle Accounts Receivable, Oracle Accounts Payable, or other source systems. You can manually update accrual redemption by keying in:
Transaction reference: credit memo, check number, or write off codes
Payment system: Oracle Accounts Receivable, Account Payable, or other system
Redeemed date (defaults as current date, but can be changed by user)
The pricing engine evaluates regular breaks and accumulated range breaks differently:
Accumulated range breaks: The accumulation value is used as the starting point when th epricing engine is evaluating a break.
Non-accumulated (regular) price breaks: Regular breaks are evaluated starting from zero.
Calling applications, such as Oracle Order Management, pass accumulation values to the pricing engine using accumulation attributes. The accumulation attributes are used in modifier setups, and are attached to a modifier price break header.
For example, an order for a quantity of five of Item XYZ with an accumulation value of 8 would be priced at the appropriate range break(s) for the 9th through 13th items.
With accumulated range breaks, orders can be priced starting at higher-ranged breaks while with regular breaks, all orders start at the lowest break. See the Oracle Advanced Pricing User's Guide for examples and additional information about accumulated range break features.
The following methods are used to pass the accumulation value to the pricing engine:
Attribute Mapping: This is the conventional method of passing attributes in a pricing request.
Runtime Sourcing: This is set up in the Attribute Management feature to source an accumulation attribute at runtime. Runtime occurs when the modifier is selected and breaks are evaluated. However, unlike attribute mapping, runtime sourcing is used only for accumulated range breaks.
Unlike attribute mapping, runtime sourcing can be used only for accumulated range breaks. During accumulated range break calculations, the pricing engine calls the Runtime Sourcing application programming interface (API) to acquire an accumulation value for the accumulation attribute (defined as RUNTIME SOURCE in the Attribute Mapping setup).
The RUNTIME SOURCED API is a PL/SQL function that returns the accumulation value. It is similar to Get_Custom_Price API in that the user must write the function, but is used only for accumulation. It is different from a standard attribute mapping rule because sourcing is done at runtime in the middle of calculation. Runtime sourcing is best used when runtime information (modifier-related values like qualifiers, product, and pricing attributes) is needed to derive an accumulation value.
The following list outlines the general steps for implementing and using runtime sourcing:
Define and write function Get_numeric_attribute_value for package QP_RUNTIME_SOURCE, following the specification (provided).
Compile the source into the database.
Define a pricing attribute under VOLUME context with Mapping Method RUNTIME SOURCE in Attribute Mapping.
Enable the profile QP: Accumulation Attribute Enabled.
Define a modifier price break with this attribute attached in the Accumulation Attribute field.
When the modifier is selected, runtime sourcing is called to obtain an accumulation value before the adjustment amount is calculated.
The specification for the function Get_numeric_attribute_value is provided in the package QP_RUNTIME_SOURCE (located in the file QPXRSRCB.pls). You must write the corresponding body with the following parameters:
p_list_line_id: the list line ID of the modifier being applied.
p_list_line_no: the list line number of said modifier.
p_order_header_id: the ID that is assigned to the order, if supported by the calling application. This value may be null.
p_order_line_id: the ID that is assigned to the request line of the order.
p_price_effective_date: the price effective date that is given in the order.
p_req_line_attrs_tbl: a table of records of the request line attributes.
p_accum_rec: a record structure pertaining to the accumulation attribute.
The p_req_line_attrs_tbl table structure parallels that of the one that is found in package QP_FORMULA_PRICE_CALC_PVT.
The p_accum_rec record contains three fields, but can be expanded for any future requirements:
p_request_type_code: the request type code that is specified in the pricing request.
context: the accumulation attribute context, currently hard-coded as VOLUME.
attribute: the segment name designation of the accumulation attribute.
The Runtime Sourcing API returns the accumulation value for each line being priced. The accumulation can be done per order or across orders. Therefore, you must write code logic that returns the correct value based on any or all of the input parameters.
This user-defined logic can be based on any number of input parameters. For example, to accumulate based on the order item, then you need to evaluate only the attribute corresponding to Item Number on the request line needs to be evaluated. If the requirements call for a complex derivation involving multiple input parameters, the API enables this too, provided that you correctly implement the logic in the PL/SQL code.
By design, accumulation is done by the calling application and not by the pricing engine. Accumulation values are stored in user-defined tables, so any SQL queries within Get_numeric_attribute_value should be performed on these tables to get the values. Furthermore, leave any UPDATE, INSERT, or DELETE statements outside of runtime sourcing, because those operations should be done within the calling application itself.
Sample Runtime Sourcing Code
The following example shows sample code for the function body. In this scenario, the user is accumulating based on a combination of customer class and order type. Here, we define customer class as context CUSTOMER, attribute as PRICING_ATTRIBUTE31, order type as context ORDER, and attribute as PRICING_ATTRIBUTE40. Also, for illustrative purposes, the accumulation values are stored in a user-defined table called accum_val_tbl. Performance considerations are not taken into account here.
FUNCTION Get_numeric_attribute_value( p_list_line_id IN NUMBER, p_list_line_no IN VARCHAR2, p_order_header_id IN NUMBER, p_order_line_id IN NUMBER, p_price_effective_date IN DATE, p_req_line_attrs_tbl IN ACCUM_REQ_LINE_ATTRS_TBL, p_accum_rec IN ACCUM_RECORD_TYPE ) RETURN NUMBER IS v_cust_class VARCHAR2(240); v_order_type VARCHAR2(240); v_req accum_req_line_attrs_rec; i NUMBER; accum_value NUMBER BEGIN -- this loop extracts the customer class and the order type that is -- passed on the request line. We only use the p_req_line_attrs_tbl -- input parameter here. i := p_req_line_attrs_tbl.FIRST; WHILE I IS NOT NULL LOOP v_req := p_req_line_attrs_tbl(i); IF (v_req.context = 'CUSTOMER' AND v_req.attribute = 'PRICING_ATTRIBUTE31') THEN v_cust_class := v_req.value; ELSIF (v_req.context = 'ORDER' AND v_req.attribute = 'PRICING_ATTRIBUTE40') THEN v_order_type := v_req.value; END IF; i := p_req_line_attrs_tbl.NEXT(i); END LOOP; -- supposing the customer class and order type are not null, now -- query the user-defined table for the stored accumulation value -- and return this value. SELECT value INTO accum_value FROM accum_val_tbl WHERE customer_class = v_cust_class AND order_type = v_order_type; RETURN accum_value; END Get_numeric_attribute_value;
In this example, the Customer Class and Order Type are extracted from the request line and used in the query to accum_val_tbl which stores an individual accumulation value for every customer class/order type pair. Once the value is selected, the function returns it to the pricing engine to continue the calculation. Depending on how many distinct pairs exist, this function (using the way the data is stored in the table) will return a different and correct accumulation value for each pair that is passed in the request line.
You can write the runtime sourcing function in many ways, and the implementation depends on the scenario and requirement. The logic can be as simple or complex as required within the limits of the PL/SQL language. Regardless, the function must process that logic and query the appropriate data table for the corresponding accumulation value before returning the number.