Modifiers

This chapter covers the following topics:

Overview of Modifiers

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
Discount Yes Yes Yes Yes No
Surcharge Yes Yes Yes Yes No
Other Item Discount No No Yes Yes No
Terms Substitution No No Yes Yes No
Item Upgrade No No Yes Yes No
Price Break Yes Yes Yes Yes No
Promotional Good No No Yes Yes No
Coupon Issue 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.

Pricing for Hierarchical Item Categories

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.

Using the HTML User Interface with Modifiers and Modifier Lines

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:

Modifier List Types

Modifier Line Types

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:

Related Topics

Oracle Advanced Pricing User's Guide, Modifiers

Implementation Planning

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
Bucket 2 Null Null Null Null Null $765

Note: Key to Table Short Names

Adj. = Adjustments

Modifier Levels and Application Methods

The pricing engine uses modifier levels to determine pricing request eligibility for specific modifiers and to determine at which level the modifier should be applied: Order, Line, or Group of Lines.

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.

Key Implementation Decision: How do I assign modifier application methods?

You can select from the available application methods to create different pricing actions:

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.
Discount Yes Yes Yes Yes Yes Yes Yes Yes
Surcharge Yes Yes Yes Yes Yes Yes Yes Yes
Freight/ Special Charge Yes Yes Yes Yes No No Yes Yes
Other Item Discount (Get) Yes No Yes No Yes No Yes No
Price Break Yes Yes Yes Yes Yes Yes Yes Yes
Promotional Good (Get) Yes No Yes No Yes No Yes No

Note: Key to Table Short Names

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.
Discount Yes Yes Yes Yes Yes Yes Yes Yes
Surcharge Yes Yes Yes Yes Yes Yes Yes Yes
Other Item Discount (Get) Yes No Yes No Yes No Yes No
Price Break Yes Yes Yes Yes Yes Yes Yes Yes
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.
Discount Yes Yes No No No No No No
Surcharge Yes Yes No No No No No No
Freight/ Special Charge No No No No No No Yes Yes

Considerations for Group of Lines Behavior

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:

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:

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
1 Shampoo Shampoo 1 70
2 Shampoo Shampoo 2 40
3 Conditioner Conditioner 30

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:

As a result of this check, the modifier Modifier_Shampoo1 is given because the:

Modifier_Shampoo2 applied to Shampoo order

Before Modifier_Shampoo2 can be given, the order lines are evaluated in the following way:

As a result of this check, the modifier Modifier_Shampoo2 is not given because the ordered quantity is not greater than 100.

Related Topics

Functional Areas for Source System region

Other Modifier Considerations

Key Implementation Decision: How will my customer and product hierarchies affect the structure of my modifiers?

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.

Excluding Items and Item Categories

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.

Unit of Measure (UOM)

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:

Pricing Phase

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.

Precedence

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.

Incompatibility Level

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.

Buckets

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.

Null Bucket

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:

  1. Calculates percent discounts using the list price.

  2. Sums all bucket modifier values to create a bucket subtotal.

  3. Applies the subtotal after the last numbered bucket.

Suppose that the following buckets are set up, each with a different adjustment:

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

Key Implementation Decision: How many bucket levels do I need?

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.

Manual Modifiers

If a manual modifier is applied for a given bucket, all modifiers in subsequent buckets will get re-evaluated.

Pricing Controls

The following pricing controls can be set up to define how the modifier and modifier lines are applied:

Modifier Type Setup

Manual Modifiers

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:

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.

Other Item Discount

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.

Get Region and Benefit Items

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.

Promotional Goods

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:

Method 1

  1. Set up two modifiers:

    • Modifier A: Buy 1 PC and get 1 free mouse.

    • Modifier B: Buy 1 PC and get free speakers.

  2. Make the two modifiers incompatible with each other and set the precedence so that the modifier with the higher precedence will be automatically applied.

Method 2

  1. Set up two Other Item discount modifiers:

    • Modifier A: buy 1 PC and buy 1 mouse, then get the mouse free.

    • Modifier B: buy 1 PC and buy speakers, then get the speakers free.

  2. 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 standalone 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 the application does not apply the additional order level modifiers.

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.

Promotional Service Items

After you define a line level promotional modifier for an item (for example, a PC) in the Define Modifier window, you can add a service item (for example, warranty for a specific period) as a 'promotional get item' for the parent item. Use the Get region in the Define Modifier Details window of the parent item to specify the following for the promotional get item:

Promotional Subscription Service Items

After you define a line level promotional modifier for an item (for example, a PC) in the Define Modifier window, you can add a subscription service item (for example, a year of support) as a "promotional get item" for the parent item. Use the Get region in the Define Modifier Details window of the parent item to specify the following for the promotional get item:

Term Substitution

Payment, freight, and shipping terms can be substituted using the terms substitution modifier.

Item Upgrade

For item upgrade modifiers, the relationships between items and upgraded items must be defined in Oracle Inventory.

Price Breaks

Price breaks can be created for both price list lines and modifier lines with the Pricing Context of Volume.

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
100-200
200-300

Important: Copying price breaks created in a release before Release 12: When you copy a price break (for example, by copying a price list or modifier list with price breaks) from a pre-Release 12 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):

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.

Types of Price Breaks

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:

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 the Modifiers chapter in this guide.

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.

Coupon Issue

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.

Ask For Promotions

You can create “Ask For” promotions by selecting one of the following when setting up a modifier:

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.

Recurring Modifiers

You can mark modifiers as recurring in the break type field on the modifier summary tab. The following modifier types enable recurring:

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.

Setting up Accrual Discounts

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:

Fields reserved for future use:

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
List Price n/a n/a n/a n/a $100.00
1 7% discount $7.00 n/a $7.00 $93.00
1 10% accrual n/a $10.00 n/a $93.00
2 10% accrual n/a $9.30 n/a $93.00
2 $5 discount $5.00 n/a $5.00 88.00

Accounting Limitations

Redeeming Accruals

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:

Using Accumulated Range Breaks

Accumulated range breaks extend the regular range break feature of modifiers by using an “accumulation value” to start a break point instead of zero.

The pricing engine evaluates regular breaks and accumulated range breaks differently:

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:

Setting Up Runtime Sourcing 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:

  1. Define and write function Get_numeric_attribute_value for package QP_RUNTIME_SOURCE, following the specification (provided).

  2. Compile the source into the database.

  3. Define a pricing attribute under VOLUME context with Mapping Method RUNTIME SOURCE in Attribute Mapping.

  4. Enable the profile QP: Accumulation Attribute Enabled.

  5. 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.

To set up runtime sourcing:

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:

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:

To apply runtime sourcing:

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.