Attribute Management

This chapter covers the following topics:

Overview of Attribute Management

Attribute mapping enables you to extend your pricing capabilities by using data from a wide variety of non-standard sources to drive your pricing actions. The data sources for the qualifiers and pricing attributes can be from within or outside of Oracle Applications.

Using the attribute management feature, you can complete the following tasks:

Creating new contexts and attributes extends the ability of Oracle Advanced Pricing to provide user-defined data sources to drive pricing actions. The three methods to source data for an attribute are:

Qualifier and pricing attributes are used to define customer or product attributes:

When the pricing engine gets a pricing request, attribute management retrieves all values for the qualifier and pricing attributes that are associated with the transaction. The pricing engine evaluates these values to determine which price lists and modifiers are eligible for the transaction.

For example, the following setup could define a discount for a specific day of the week:

Pricing Action Pricing Rule Data Source Attribute Value
Discount Modifier Qualifier Day of the Week Monday

Note: Upgrade Considerations

Use the attribute management windows in Oracle Advanced Pricing to create and maintain contexts and attributes and to map attributes. In releases earlier than 11i, qualifier and pricing attributes were created in the Flexfields and Value Set windows using the Oracle Flexfield setup features.

Terminology for Attribute Management

Pricing Transaction Entity (PTE)

A PTE is an ordering structure that has associated request types and source systems. Different applications may have different request structures when they make requests to the pricing engine.

Source System

The source system is the application that captures the pricing setup data.

Request Type

The request type identifies the type of transaction that is being priced. Different applications make requests to the pricing engine. Request types of these applications may be different. Some applications may share their request types.

For example, iStore and Order Capture share the same request type. On the other hand, Order Management and iStore have different request structures.

Related Topics

Creating Context and Attributes for Pricing Setup windows

Linking Attributes to a Pricing Transaction Entity

Mapping Attributes of Type ATTRIBUTE MAPPING

Running the Build Attribute Mapping Rules program (Attribute Mapping only)

Creating a New Pricing Transaction Entity

Creating Contexts and Attributes for Pricing Setup Windows

The following sections describe how to create contexts and attributes. First you create a context, then create its attributes to define specific values that define pricing rules. For example, a context of Customer can include pricing attributes such as Customer Name or Customer Class. Using attribute management, you can set up the following contexts and their attributes:

For example, a product context such as Item can be further categorized by attributes such as Item Name and Item Number, while a qualifier context such as Customer can consist of attributes such Customer Name and Customer ID.

Context Type Context Name Attribute
Qualifier Context Customer Customer Name
Product Context Item Joe's Items
Pricing Context Color Blue

Note: The global data element context is not supported for pricing contexts.

Once you create the context, you can create its attributes to define specific values for your pricing rules, determine how the attributes are mapped, decide which attributes can be selected from a list in the pricing setup windows, and determine which ones are used in promotional limits.

The pricing engine evaluates attributes during engine run time to determine which price lists and modifiers are eligible for the transaction. Attribute values can be derived at the order level, line level, or for both order and line levels.

Warning: Pricing attributes for a price list line are not sourced at the ORDER level. Therefore, when setting up a pricing attribute (Context Type: Pricing Context) you should select the LINE level rather than ORDER or BOTH otherwise you cannot view or select that pricing attribute from a price list line. Note: You select a level for the pricing attribute in the Link Attributes window.

To create contexts and attributes using the Attribute Management feature, you must complete one or more of the following setup steps. The steps may vary depending on your requirements and current setup:

  1. Verify the request types and source systems for a given PTE. Otherwise create a new pricing Transaction Entity in QP Lookups.

  2. Create a new context, and then define the attributes for that context.

    Pricing rules such as qualifiers and pricing attributes are used to drive your pricing actions. You can create new contexts and attributes to help set up your pricing rules in the Context Setup window.

    Note: Oracle Advanced Pricing supports the creation of pricing attributes with the same name if they are in different contexts. But the flexfield generation process does not support this and fails when the Build Attribute Mapping Rules program is run. Therefore, you may want to use unique names (not duplicated) when you create attribute names.

  3. Link the attribute to a PTE, and then define properties of the attribute for the given PTE.

    Once you create the context-attribute grouping, you can link it to a specific PTE. For mapped attributes, define Attribute Mapping Rules, and then run the Build Attribute Mapping Rules Program.

  4. Run the Build Attribute Mapping Rules program.

    This step applies only to attributes with the Attribute Mapping Method of Attribute Mapping. Whenever you create or update these attributes or change attribute mapping rules, you should run the Build Attribute Mapping Rules program.

    Tip: If the Build Attribute Mapping Rules program is run when you create the attribute, you will be prompted to run it again when you use the attribute (such as in a formula or as a pricing attribute). Therefore, you may want to run it only once when you use the attribute.

  5. Use the attribute in a valid pricing setup.

  6. Enter an order. Verify that the mapped and user-enter attributes have been correctly passed to the pricing engine from the Pricing Engine Request Viewer.

To create contexts

  1. Navigate to the Context Setup window.

    Context Setup window

    the picture is described in the document text

  2. Complete your entries as required:

    • Type: Select the context type you want to create, such as a Qualifier, Pricing, or Product Context.

    • Code: Enter a Code that is a short name for the context. Once you create the code, you cannot update it.

    • Name and Description: Enter a name and description for the context. The Name you create will be available from the list of values (for the contexts) in sales order, and from the pricing context fields in Price List and Modifier windows. Because new contexts can be introduced by different applications from Oracle Pricing, enter a meaningful description.

    • Seeded box: The Seeded box is selected automatically if the context is a seeded value. It remains selected even if you overwrite a seeded context.

    • Enabled box: Select the Enabled box to make this context available for pricing setup windows. If this box is cleared, the context will not appear in the Context field on the pricing setup windows and all the attributes that are defined for the context will also be unavailable for setup.

  3. When you have completed your entries, enter the attributes for this context in the Attributes region.

To create attributes

  1. In the Context Setup window, select the context to which you want to add attributes.

  2. Then, in the Attributes region, complete your entries for the selected attribute:

    • Code: Enter a unique short name for the attribute (the code name is used internally). Once created, it cannot be updated.

    • Name and Description: Enter a display Name and Description for the attribute. Since new attributes in the attribute mapping manager can be introduced by different applications other than Pricing, entering an attribute description is informative.

      Note: You can update seeded names and descriptions; however, if the original seeded values are changed, they can be restored using the Restore Defaults button.

    • Precedence: Enter a numeric Precedence value that can be evaluated during incompatibility processing. For example, if two incompatible discounts qualify for the same item, the discount with the higher precedence is given (the lower the number the higher the precedence, so a precedence of 1 is selected before 2). Precedence numbers in the series of 5s and 10s are reserved for seeded qualifiers/pricing attributes and should not be used. The precedence is restricted to a maximum of 3 digits (any number between 1 and 999).

    • Application Name: Enter the name of the application that created this attribute. If an application name is not entered, the system defaults Oracle Pricing as the creator of the attribute.

    • Column Mapped: Select a value to map the attribute to a column in the pricing tables. You can select from the names of the unused columns only:

      • Columns QUALIFIER_ATTRIBUTE1 through QUALIFIER_ATTRIBUTE30 are reserved for seeded qualifier attributes.

      • Columns 1 to 100 are available and you should use pricing attributes 1 to 30 as user-entered pricing attributes. Columns 1 - 30 are available only for user Datamerge.

      • The Pricing Manager user's list has unused columns between 31 and 100.

    • Value Set: Select a value set to define the valid values for an attribute. The Datatype field displays the format type of the selected value set such as numeric (Number) or alphabetic (Char). Alternatively, to create a new value set or view an existing one, click Value Sets. Once you have created a new value set, you can select the newly created value from the Value Set field.

      Note: You cannot set up dependent value sets for any attributes. A value set for an attribute can be replaced only by a value set with the same datatype as the one being replaced.

    • Seeded box: The Seeded box is selected automatically if the context is a seeded value. It remains selected even if you overwrite a seeded context.

    • Required: Select Required to make the attribute a required value in pricing windows. For required attributes, a user must enter the specified attribute, for example, every time he or she creates a sales order line.

      Note: Previously the Required box was updated in the Segments (Pricing Contexts) window, and reflected in the flexfield. However, these updates will not be updated in attribute management. Therefore the Required box should be selected in attribute management.

    • Party Hierarchy Enabled box: Hierarchies consist of tiered relationships where one party is ranked above another, for example, a corporate hierarchy where different companies are related as parent, subsidiary, headquarters, division and so on. Select this check box if the qualifier attribute references Oracle TCA (Trading Community Architecture) parties and if price lists or modifiers with this qualifier attribute need to be made available to the party hierarchy. This enables you to cascade a discount or price list to subsidiaries and branches by setting up a qualifier at the top level rather than creating multiple qualifiers, one for each subsidiary or division.

      If the Party Hierarchy Enabled check box is selected for an attribute that is not based on TCA Parties, a warning appears. This enables the check box to be set for user-defined attributes that use custom tables with a party_id reference. Setting this flag for any other attributes can yield incorrect pricing results if qualifiers reference an attribute with Applies To Party Hierarchy selected. Once this check box is selected, you cannot deselect it if any qualifier references an attribute that has Applies To Party Hierarchy selected.

      The following seeded qualifier attributes are based on Oracle TCA parties:

      • Customer Party (qualifier context = Party Information (ASOPARTYINFO)

      • Party Id (qualifier context = Customer (CUSTOMER)

      • Buying Groups (qualifier context = Customer Group (CUSTOMER GROUP)

      • Supplier (qualifier context = Party Information (PARTY)

      • Buyer (qualifier context = Party Information (PARTY)

      Note: The profile option QP: Pricing Party Hierarchy Type governs the relationship type for the TCA Party seeded qualifier attributes and for user-defined qualifier attributes that are enabled for party hierarchy. The Party Hierarchy Enabled check box is available for Oracle Advanced Pricing users, not for Basic Pricing users. For more information, see Oracle Advanced Pricing Implementation Guide, Profile Options.

  3. Once you have created the context and its attributes, you can link an attribute grouping to a specific Pricing Transaction Entity (PTE).

    Attribute Levels and Restrictions in Pricing Setup windows

    The following sections describes the attributes (and associated restrictions) that appear in the list of values based on the attribute level that is assigned to the attribute.

    • Price Lists window

      • In the Qualifiers tab, the list of values displays qualifier attributes with the attribute level of LINE or BOTH. This occurs because an order line may qualify for a price list based on a qualifier attribute for the order line or both the order header and order line.

      • The values for the pricing attributes appear at the line attribute level.

    • Modifier List Setup window

      • The values for qualifier attributes in the Qualifier - Line Level Qualifiers window displays qualifier attributes with attribute levels of ORDER or BOTH if the modifier level is Order.

      • The values for the qualifier attributes in the Line Qualifiers window displays qualifier attributes with attribute levels at LINE or BOTH if the Modifier Level Code is Line or Line Group.

      • The values for the qualifier attributes in the List Qualifiers window displays qualifier attributes with attribute levels at LINE, ORDER or BOTH.

      • The values for pricing attributes display pricing attributes with attribute level at the LINE level.

    • Qualifier Group Setup window

      The values for the qualifier attributes on the Qualifier Group Setup window displays all levels of qualifier attributes. The following conditions apply to the forms-based user interface: A qualifier group cannot have one qualifier attribute with the level Order and another qualifier attribute with the level Line with the same qualifier grouping number. All the qualifiers within a qualifier grouping number must have the attributes with the level either as Order or Both or as Line or Both.

    • Formula Lines and Factors List

      Because a formula can be applied either at order level or at line level, you cannot at definition time restrict the attributes appearing in the lists based on the attribute level. The list of values has no level-based restrictions.

    Pricing Attributes and Flexfields tables

    Oracle Order Management (OM) uses the flexfield structure for pricing attributes; therefore, for pricing attributes to display in Oracle Order Management UIs, these definitions need to be stored in the flexfield tables as well. All definitions of contexts and attributes are stored in pricing (QP) tables; however, the same data is also stored in flexfield tables if the context type is Pricing Attribute. So when a context of type Pricing Attribute is created using the Contexts and Attributes window, the context is also created as a flexfield pricing context in the flexfield tables.

    However, you must set up pricing attributes from the Context and Attributes setup menu not in flexfields, because if a pricing attribute is set up in the flexfield tables, the setup data will not be available in the QP tables (because data is not copied from flexfield tables to QP tables). So even though the pricing attribute appears in Order Management windows, the pricing engine cannot view the attribute.

    The following steps describe how the context of type Pricing Attribute is registered as Flexfield Pricing Contexts in the flexfield tables after being created in the Contexts and Attributes window:

    1. A context of type Pricing Attribute is registered automatically if the mapped column is greater than PRICING_ATTRIBUTE30.

    2. Once the context of type Pricing Attribute is created and registered, the system automatically compiles the flexfield in the background. You can follow the stage of compilation by viewing your concurrent requests.

    3. Descriptive flexfields in Advanced Pricing for Pricing Context gets mapped to Pricing Context and Product Context (context=ITEM only). All qualifier context gets mapped to Qualifier Context.

    A context of Pricing Attribute and its related attributes will get updated and deleted in the flexfield (and the Context and Attributes window) if it meets the deletion criteria.

Related Topics

Overview of Attribute Management

Linking Attributes to a Pricing Transaction Entity

Creating a New Pricing Transaction Entity

Restoring Seeded Data Using the Restore Defaults button

Deleting Contexts and Attributes

You can delete contexts and attributes except under the following conditions:

To delete contexts

You cannot delete a context if it has one or more attributes.

To delete attributes

Attributes that are already used in pricing setup windows cannot be deleted.

Linking Attributes to a Pricing Transaction Entity

A PTE consists of a group of applications that point to the same setup data and attributes, and includes request types and source systems. The source system is the application that captures the pricing setup data and the request type identifies the type of transaction that is being priced.

Once you create a context and its attributes, you link them to a specific PTE. For a given PTE, this combination becomes available in the pricing setup windows. Each PTE has its own unique combination of attributes.

The following table displays the seeded PTEs and their request types and source systems in Oracle Advanced Pricing:

Pricing Transaction Entity (Code) Source Systems Request Types
Complex MRO (CMRO) AHL AHL
Demand Planning (DEMAND) QP MSD
Intercompany Transaction (INTCOM) INV, QP IC
Logistics (LOGSTX) FTE FTE
Order Fulfillment (ORDFUL) AMS, ASO, OKC, OKS, QP ASO, OKC, OKS, ONT
Procurement (PO) PO PO

To link attributes to a PTE

  1. Navigate to the Advanced Pricing - Pricing Transaction Entity-Attribute Linking window.

    Pricing Transaction Entity-Attribute Linking window

    the picture is described in the document text

  2. Complete your entries in the Advanced Pricing - Pricing Transaction Entity-Attribute Linking window:

    • Pricing Transaction Entity: Select a PTE.

    • Context Type: Select the context type such as Pricing Context, Product Context, or Qualifier Context.

    • Show Linked Contexts check box: Select the Show Linked Contexts box to display only those contexts that are assigned to the selected PTE. The contexts that match the criteria for the selected PTE and context type appear in the Contexts region.

  3. Select a context whose attributes you want to link to a PTE. If the Assigned to PTE box is not checked, attributes have not been created or selected for that context in the given PTE.

  4. Click Link Attributes to display the Link Attributes window.

    Link Attributes window

    the picture is described in the document text

    • Code: Enter a short name for the attribute.

    • Level: Select an attribute Level: ORDER, LINE, or BOTH (Order and Line levels).

      For example, for an attribute agreement ID, if the level is ORDER then only the agreement ID at the header level will be attribute mapped. The agreement ID on order lines will not be attribute mapped. This level is also used to selectively display pricing attributes and qualifiers in the Pricing Setup list of values.

      Important: Pricing attributes for a price list line are not sourced at the ORDER level. Therefore, when setting up a pricing attribute (Context Type: Pricing Context) you should select the LINE level rather than ORDER or BOTH otherwise you cannot view or select that pricing attribute from a price list line.

    • Attribute Mapping Method: Select an attribute mapping method to define how you want the attribute to derive its value:

      However, do not change the mapping method from USER ENTERED to ATTRIBUTE SOURCING for the seeded attributes Item Quantity and Item Amount (pricing context of Volume).

      • ATTRIBUTE MAPPING: Attribute mapping is required. After you complete the remaining entries in the Link Attributes window, click Attribute Mapping to define the attribute mapping rules for the selected attribute.

        Note: If ATTRIBUTE MAPPING is selected then the Attribute Mapping button is enabled. If USER ENTERED or CUSTOM SOURCED is selected, then the Attribute Mapping button is grayed out.

      • CUSTOM SOURCED: User provides a code. For more information, see Oracle Advanced Pricing Implementation Guide, Using Custom Sourced Attributes.

      • RUNTIME SOURCED: The pricing engine derives a runtime sourced value using a custom API. This method is used to source an accumulation attribute at runtime. During accumulated range break calculations, the pricing engine calls the Runtime Sourcing API to acquire an accumulation value for the accumulation attribute (defined as RUNTIME SOURCE in the Attribute Mapping setup). For more information about using runtime sourcing for accumulation attributes, see Oracle Advanced Pricing Implementation Guide, Setting up Runtime Sourcing for Accumulated Range Breaks.

      • USER ENTERED: The attribute value is entered by the user; therefore attribute mapping is not required. However, if USER ENTERED is selected and the context type is Pricing, you must complete the following steps to view this attribute in the Order Management Sales Order pad:

        i. Navigate to the Flexfields window.

        ii. Select the Freeze Flexfield Definition box.

        iii. Click Compile to compile the flexfield.

        The attributes ITEM AMOUNT and ITEM QUANTITY are user-entered but are sourced internally by the pricing engine.

        Note: If a change is made in the Flexfields window and you click the Compile button, the corresponding change will not be visible in the Flexfield window in integrating applications until a responsibility switch or relogin has been made.

        For example, if you select the Required Flag for a pricing attribute in the attribute manager setup window, the attribute will not appear as a mandatory field (in yellow) in the Pricing Attributes flexfield window in the Sales Order pad, until a responsibility switch or relogin has been made. This occurs because the information is based on cached information. Therefore you need to log in again or switch responsibility to refresh the cached information and update the values.

    • LOV (list of values) Enabled: Select LOV Enabled to display the attribute in the list of values of modifier, qualifier, price list, and formula windows. If LOV Enabled is not selected, the attributes will not be available in these windows. However, existing modifiers that are defined using that attribute will act the same way:

      • If LOV Enabled is selected and the Attribute Mapping Enabled box is cleared, then even though the attribute is available for setup, a mapping rule is not created. So if the attribute is used in the qualifier, modifier, price list, and formula setup windows, an error occurs.

      • The LOV Enabled box is selected for all seeded attributes to make them available in the LOVs from price list, qualifier, modifier, formula and other setup windows. This box will be unaffected whenever data upgrade scripts are run.

    • Use in Limits box: If Use in Limits is selected, the attribute can be selected from the Attribute list of values in the Limits setup windows (including the Other Attributes window).

    • Attribute Mapping Enabled box: If you selected ATTRIBUTE MAPPING as the attribute mapping method, select the Attribute Mapping Enabled box so that the concurrent program Build_context API can successfully map the attribute.

      If the box is cleared, the attribute will not be mapped. This box is cleared for all seeded attributes to prevent the mapping of unwanted attributes.

      The Column Mapped value is a default value.

    • Used in Setup box: The Used in Setup box indicates whether the attribute is used in an active pricing setup such as a price list, modifier, formula, qualifier, or limit. The setting for the Used In Setup box (selected or cleared) depends on the profile option QP: Build Attributes Mapping Options and the Active box values:

      If the setting for QP: Build Attributes Mapping Options is: Then...
      Yes (map attributes used in active pricing setup) The Used In Setup box is set to Yes, only when an attribute is used in the active pricing setup.
      No (map all attributes) The Used In Setup box is set to Yes when an attribute is used in both the active and inactive pricing setup.
      No The Used In Setup box is set to No when an attribute is used in the inactive pricing setup.

      Note: The Used In Setup box may not always reflect the exact status of current attribute usage for some attributes. For example, if an attribute is deleted, the Used In Setup box may appear as “selected” even though the attribute has been deleted. This occurs because the status is not updated automatically.

      However, when the concurrent program Build Attribute Mapping Rules is run, the Used In Setup box is updated to reflect the exact status of the attribute usage.

    • Attribute Mapping Status check box: The Attribute Mapping Status check box is selected (or cleared) automatically by the concurrent program, which generates the Build_Contexts API for mapped attributes. The Attribute Mapping Status check box is cleared in the following cases:

      • After you define the attribute mapping for new attributes (but before you run the concurrent program).

      • When an attribute mapping rule is modified.

      • If the Attribute Mapping Status box is cleared and 1) Attribute Mapping Method is ATTRIBUTE MAPPING and 2) Attribute Mapping Enabled is selected, then the concurrent program must be run to regenerate the Build_Contexts api. The Attribute Mapping Status box is selected when the concurrent program is run successfully. The field is not navigable.

      Note: A warning box displays if you try to use new attributes with the Attribute Mapping Method as ATTRIBUTE MAPPING and the Mapping Status box as No.

    The Pricing Transaction Entity-Attribute Linking window displays the newly created context; the Assigned to PTE box indicates that the attributes have been assigned to this PTE. The attributes that you created can be viewed in the pricing setup windows.

    • For CUSTOM SOURCED, RUNTIME SOURCED, and USER ENTERED attributes, once you have completed your entries, the attribute is now linked to a Pricing Transaction Entity.

    • For ATTRIBUTE MAPPING attributes, click Attribute Mapping to define the Attribute Mapping rules for the selected attribute.

    Optionally, click Contexts to add a new context or to update, enable, or view an existing context.

Related Topics

Mapping Attributes of Type ATTRIBUTE MAPPING

Using Custom Sourced Attributes

Running the Build Attribute Mapping Rules program

Mapping Attributes of Type ATTRIBUTE MAPPING

This section applies only to attributes whose Attribute Mapping Method is ATTRIBUTE MAPPING.

After you have linked the context and attribute(s) to a PTE, you can complete the attribute mapping process in the Attribute Mapping window. Mapping an attribute enables the pricing engine to derive values for an attribute that is used in modifiers, price lists, or qualifiers.

Attribute mapping provides additional flexibility for the pricing engine: for example, the value for Customer Region can be derived from a OE_ORDER_PUB.G_HDR.sold_to_org_id in Order Management; however this same element can also be derived from ASO_PRICING_INT.G_HEADER_REC.cust_account_id in Order Capture.

Whenever you create or update these ATTRIBUTE MAPPING attributes or change attribute mapping rules, you should run the Build Attribute Mapping Rules program.

Note: You do not need to run the Build Attribute Mapping Rules program for attributes for which the Attribute Mapping Method is USER ENTERED or CUSTOM SOURCED.

To map attributes of type ATTRIBUTE MAPPING

  1. In the Link Attributes window, click the Attribute Mapping button to display the Attribute Mapping window. Complete your entries as required:

    Attribute Mapping window

    the picture is described in the document text

    Application Name: Select the name of the application that created the mapping rule. If an application name is not selected, the system defaults Oracle Pricing as the creator of the mapping rule.

  2. Complete your entries in the Header Level region:

    Note: The fields in the Header Level region are enabled only if the Attribute Mapping level (defined in the Assign Attributes window) for the attribute is Order or Both. The fields are grayed out if the level is Line.

    • Global Object name (display-only): Defaults with the value defined in the Request Types tab of the Pricing Transaction Entity - Source System and Request Types window.

    • Seeded Source Type: Appears if the record is seeded. This field is view-only and cannot be updated. To modify seeded mapping, you can enter data into the corresponding User Source Type.

    • User Source Type:

      • PL/SQL API: Attribute can be sourced directly from a global structure that is defined for the given source system. For Oracle Order Management, all the record structures are defined in the package OE_ORDER_PUB. For example, if you want to use the payment term ID as the source value for the new segment that you have defined, enter G_LINE.payment_term_id in the function name. You have two record structures available.

        • OE_ORDER_PUB.G_LINE contains all the possible values of a sales order line.

        • OE_ORDER_PUB.G_HDR contains fields from Order headers. The structure of the Line_rec_type and header_rec_type can be obtained from the Manufacturing Open Interface Manual. (For IStore/OC the equivalent global structures are defined in the package ASO_PRICING_INT.)

      • PL/SQL API Multi-Record: You can write a custom API (must be a function) that returns multiple values. The output of your function can be only a table of VARCHAR2s, for example, to get the inventory categories for an item. For more information, see seeded sourcing for Item Categories or customer class as an example of multi-Value pl/sql API.

      • Constant Value: Constant: Enter a constant value that will always be mapped to this attribute for the given condition.

      • Application Profile: Select the profile option from where you want to get the default value for this attribute. A LOV will provide a list of valid profile options such as OE: Item Validation Organization.

      • System Variable: Enter the system variable that will be mapped to the attribute for the given condition such as SYSDATE.

        The Seeded Value String fields displays the seeded value string of the record. This field is view-only and cannot be updated. To modify a seeded value string, you can enter data into the corresponding user value string.

    • User Value String: Enter a user value string.

      For example, the user value string for pulling the schedule ship date (Schedule Date) from Order Management is OE_ORDER_PUB.G_LINE.SCHEDULE_SHIP_DATE.

    • Seeded box: Indicates whether the mapping rule is seeded.

    • Enabled box: Select the Enabled box to enable attribute mapping rules for various Request types for qualifier, product, or pricing attributes. Alternatively, clear the Enabled box to disable the attribute mapping rules for the Request types for that pricing transaction entity (PTE)

      Note: When you select or clear the Enabled box, a dialog box advises you to run the Build Attribute Mapping Rules program for the change to take effect.

  3. In the Line Level region, complete your entries if the attribute level, which is defined in the Assign Attributes window, is LINE or BOTH. This region will be grayed out if the selected attribute level is ORDER. The field descriptions are the same as described for the Header level region.

  4. After you have completed your entries in the Attribute Mapping window, run the Build Attribute Mapping Rules program.

Related Topics

Running the Build Attribute Mapping Rules Program (Attribute Mapping only)

Linking Attributes to a Pricing Transaction Entity (PTE)

Running the Build Attribute Mapping Rules Program (Attribute Mapping Only)

This section applies only to attributes with the following setup criteria:

You should run the concurrent program Build Attribute Mapping Rules program (attribute mapping method must be Attribute Mapping and the Attribute Mapping Enabled check box must be selected) every time you:

Any new attributes that are used after the program was last run are mapped dynamically to prevent any attributes from not getting mapped. Although the attributes are mapped dynamically and can be used in pricing setups, you should run the Build Attribute Mapping Rules program for better performance.

Warning: Because the Build Attribute Mapping Rules program changes the status of database objects, do not run this program during peak hours.

What happens when the Build Attribute Mapping Rules program is run?

When you run the concurrent program Build Attribute Mapping Rules, it dynamically generates the package QP_BUILD_SOURCING_PVT which contains attribute mapping calls to build attribute mapping rules for attributes. This package contains only the rules of used attributes (Qualifiers and Pricing Attributes that are used in any pricing setup) that can be mapped at run-time.

The program generates the attribute mapping rules for all the attributes that have the Attribute Mapping Enabled box selected. When the Build Attribute Mapping Rules program runs successfully, the Attribute Mapping Status box is selected for those attributes for which an attribute mapping rule is generated.

The Build Attribute Mapping Rules program displays a status message to advise whether the program finishes successfully. The window automatically re-queries the database if the Build Attribute Mapping Rules process is successful and moves focus to the Attribute Mapping Status box.

Note: If an error in the build sourcing occurs, then all newly-created attribute mapping rules will fail and continue to fail until the error is resolved.

How attribute mapping works at run time

The calling application calls QP_Attr_Mapping_PUB.Build_Contexts, which starts the attribute mapping routines and returns the attributes to the calling application.

  1. The calling application appends the user entered attributes and "asked for" qualifiers to this request.

  2. The calling application then calls the pricing engine with these mapped attribute values.

  3. The pricing engine also appends a few internally mapped attributes to this request.

  4. The pricing engine processes the request and returns the results to the calling application

The PTE helps narrow the data that the search engine evaluates. The search engine evaluates only the setup data that is generated by all the source systems that are defined for that PTE. It also makes contexts of one PTE unavailable to other pricing applications families.

Checklist for building attribute mapping rules

After you successfully map an attribute, a message advises you that the attribute mapping rule was generated successfully. However, sometimes you may find that the new Attribute Mapping box for that attribute remains cleared when it should be selected. This may occur when you create a new attribute, link it to a PTE successfully, and then map it using the Build Attribute Mapping Rules from the Tools menu.

To ensure a successful mapping and to avoid the situation described previously, you must ensure that the following conditions are met:

To run the Build Attribute Mapping Rules Program

You can use this task flow for attributes with the following criteria:

When the Build Attribute Mapping Rules program is run, it generates a source code for a new qualifier or pricing attribute (for which attribute mapping is defined) and generates a source code for attributes for which attribute mapping rules are modified:

Note: Because this program changes the status of database objects, you should run this program during off peak hours.

  1. Ensure that this attribute has been used in a valid pricing setup such as modifiers or price list. Set up a modifier and attach the newly created qualifier/pricing attribute.

    For example, for this qualifier to be mapped by Oracle Order Management, you need to regenerate the attribute mapping package by running the program Build Attribute Mapping Rules

  2. Confirm that the program has finished successfully.

    This program needs to be run when a qualifier is used for the first time to setup a modifier or a price list. For example, if you are using Customer Class as a qualifier for the first time in your install, you need to run this program.

  3. Navigate to the Pricing Transaction Entity - Attribute Linking window.

  4. Find the PTE.

  5. In the Context Type field, select the Context Type from LOV.

  6. Navigate to Tools and select Build Attribute Mapping Rules to run the Build_context api, which will generate a mapping rule code only for those attributes that have the Attribute Mapping Enabled box selected.

  7. Check whether the program has finished successfully. If it has, the Attribute Mapping Status box is selected for the attributes for which a mapping rule code is generated.

    Note: When the concurrent program Build Attribute Mapping Rules is run, the Used In Setup box is updated to reflect the status of the attribute usage. When the attribute is removed, the Used In Setup box will remain selected.

  8. Enter the order

  9. Verify through the Pricing Engine Request Viewer window that the attribute has been correctly sent to the pricing engine. You can also verify whether the pricing engine used the correct attributes while pricing. For more information, see: Pricing Engine Request Viewer.

    Note: Before running the Build Attribute Mapping Rules program, set the profile option QP: Build Attributes Mapping Options to the desired setting.

    • When the profile option is set to Yes, mapping rules can be generated for attributes that are used in active pricing setup.

    • When set to No, mapping rules are generated for attributes in both active and inactive setups.

To run the Attribute Mapping Rules Error Report

If you run the Build Attribute Mapping Rules program and it generates attribute mapping messages, you can run the Attribute Mapping Rules Error Report to generate a list of all invalid attribute mapping rules and any warnings. Other status messages are also provided. See Oracle Advanced Pricing User's Guide, Reports and Concurrent Programs, for more information.

  1. Navigate to the Pricing Transaction Entity - Attribute Linking window.

  2. Select Build Attribute Mapping Rules from the Tools menu to run the Build Attribute Mapping Rules program. This generates a mapping rule code only for those attributes that are used in the pricing setup and have the Attribute Mapping Enabled box selected.

    If the program runs successfully, the Attribute Mapping Status box is selected for attributes that were successfully mapped.

Creating Source Systems

In the Source Systems window, you can view request types and source systems, and add or update associations between a request type and its source system. A request type refers to the type of transaction that is being priced, such as an Order Management Order or Intercompany Invoicing that requests pricing or other information from a source application such as Oracle Pricing or Oracle Inventory. A source system defines the application that generates setup data such as Oracle iStore, Oracle Pricing (pricing setup data includes modifiers, formulas, and so on) and Oracle Marketing. A request type could be paired with one or more source systems depending on your business requirements. For example, the request type Order Management Order can be associated with source systems Oracle Marketing, Order Capture, and Oracle Pricing.

Request types and source systems can be grouped and associated with a PTE. PTEs are useful for narrowing the data that the search engine examines because it needs to evaluate only the setup data that is generated by the source systems that are defined for that pricing transaction entity. The same PTE ensures that the applications sharing the same data always give the same price for an item irrespective of the request type. All applications belonging to the same pricing transaction entity have the same set of attributes available to them. Attributes (see the attributes section) can be linked to one or more pricing transaction entities.

Creating a New Pricing Transaction Entity

A pricing transaction entity (PTE) contains a group of applications that share the same setup data and attributes. For example, Oracle Istore and Oracle Order Management belong to the same pricing transaction entity because both are Order Fulfillment systems and share the same setup data. Conversely, Oracle Transportation Execution resides in a different pricing transaction entity and has its own attribute and setup information.

Using PTEs provides the following advantages:

Important: The profile option, QP: Pricing Transaction Entity, defines the current PTE in use. Set the profile option to the appropriate value before creating or querying any setup data in the pricing application because only those contexts and attributes that are assigned to the current PTE can be selected from the pricing setup windows. When you query setup data, only those contexts and attributes that are assigned to the current PTE appear.

Oracle Advanced Pricing provides the following seeded PTEs:

If required, additional PTEs can be created.

When to define a new PTE

Although Oracle provides seeded PTEs, you can set up additional PTEs to group source systems and request types. When a new request type is created - for example, a new ordering structure is added - your business must decide if the request type will use the same set of source systems in the existing PTE. A new PTE needs to be created only if the new request type uses a different ordering structure and a different set of source systems. Request types have to be unique across PTEs.

Example of a PTE

The following graphic displays the Order Fulfillment PTE. Within this PTE, the request types such as Oracle iStore and Oracle Order Management evaluate pricing data.

Pricing Transaction Entity - Order Fulfillment

the picture is described in the document text

Global Structures

The following table shows examples of the global structures at the order level and line level for the different request types of the Order Fulfillment PTE.

PTE Request Type Order Level Global Structure Line Level Global Structure
Order Fulfillment Order Capture ASO_PRICING_INT.G_HEADER_REC ASO_PRICING_INT.G_LINE_REC
Order Fulfillment Oracle Contracts Core OKC_PRICE_PUB.G_CONTRACT_INFO OKC_PRICE_PUB.G_CONTRACT_INFO
Order Fulfillment Order Management Order OE_ORDER_PUB.G_HDR OE_ORDER_PUB.G_LINE
Intercompany Transaction Intercompany Invoicing INV_IC_ORDER_PUB.G_HDR INV_IC_ORDER_PUB.G_LINE

To create a new PTE

  1. Navigate to the Pricing Lookups window.

  2. Query on QP_PTE_TYPE as lookup type to display the existing PTEs.

  3. Enter a code (short name), meaning, and description for the new PTE.

  4. Select Enabled.

  5. Save the record.

Pricing Transaction Entity - Source System and Request Types window

  1. Navigate to the Pricing Transaction Entity - Source System and Request Types window to complete your entries. In this window, you can review, update, or create new request types, source systems, and functional areas for a given PTE:

    • Name: Displays the short name for the PTE, for example, ORDFUL (Name) and Order Fulfillment (Description).

    • PTE Parameters button: Click PTE Parameters to search and update parameter values for the PTE. For more information about pricing parameters, see Overview of Pricing Parameters.

    • Code (Source Systems tab): Short name for the source system application.

      A source system defines the application that generates setup data such as Oracle iStore, Oracle Pricing and Oracle Marketing. The Source Systems tab lists the related source system(s) for the selected PTE.

      Note: A source system cannot be deleted if it is used in a setup for a given PTE.

    Request Types tab

    A request type identifies the type of transaction that is being priced. For example, Oracle Order Management is a request type that requests a price from the pricing application (the source).

    • Header or Line Structure, Header and Line View, or both: For you to map the data, a request type can have a global record structure or a view defined. You can either enter global structures for a header and line or view names for header and line. If data is entered in any of the following fields, a list of values (LOV) based on this data will appear in the ValueString field of the Attribute Mapping setup window. If no data is entered in any of the following fields, no LOV will be provided in the Value String field of the Attribute Mapping setup window.

      • Header Structure: The global structure for the header.

      • Line Structure: The global structure for the line.

      • Header View name: View name for the header.

      • Line View name: View name for the line.

    • Enabled: Select to activate the request type.

    • Request Type button: Click to view or update parameter values for the selected request type. For more information about pricing parameters, see Overview of Pricing Parameters.

    Note: A request type cannot be created for more than one PTE. A request type cannot be deleted if a mapping rule is defined for it.

    Functional areas for Source System region

    Each PTE must have at least one enabled functional area and related category set. You can use the category set and its related hierarchy of categories to define price list lines or modifiers. For example, the functional area of Order Management has a category set of inventory items, so you could either define a modifier at the category set level or for a category within the category set. Other examples of category sets include Inventory for Oracle Inventory, and the category set Purchasing for Oracle Purchasing (these products must be installed for their category sets to be available). The following example shows the functional areas and category combination for the Advanced Pricing source system in the Order Fulfillment PTE:

    Advanced Pricing source system
    Functional Area Category Set
    Product Reporting Product
    Purchasing Purchasing
    Order Management Inv. (Inventory) Items

    • Functional Area: Advanced Pricing provides seeded functional areas for each source system in a PTE. You can also add new functional areas. Each seeded functional area is assigned a seeded category set that cannot be updated.

    • Category Set: A default category set is provided for each functional area. For example, if the functional area is Order Management, then the default category set is Inventory Items. This is a read-only value. The category set for the associated functional area can be updated from the Default Category Set window.

    • Enabled: You can select or deselect the Enabled check box to activate or inactivate a functional area. If the functional area is disabled, the pricing engine will not evaluate pricing data for the functional area being disabled (unless this functional area is attached to more than one source system). If this functional area is attached to more than one source system for a given PTE, the pricing engine will still evaluate the pricing data.

Related Topics

Viewing Parameter Definitions

Viewing Parameter Values

Using Custom Sourced Attributes

For attributes with CUSTOM SOURCED defined as the attribute mapping method, the user must provide the code package procedure for the attribute. Attribute mapping is not required because the attribute will be sourced by Get Custom attributes. The user code is written in the package procedure QP_CUSTOM_SOURCE.Get_Custom_Attribute_Values. The attribute manager API program (Build_Contexts) calls this procedure to pick up custom-sourced attributes if the profile option QP_CUSTOM_SOURCED is set to Yes. The input parameters to QP_CUSTOM_SOURCE are Request Type code and Pricing Type. Typical values of Request Type codes that can be passed are ONT, ASO, OKC, IC, FTE, and MSD. By using the Request_Type_Code, you can control how the attributes are sourced based on the PTE of the calling application.

Confirm that the profile option QP: Custom Sourced is set to Yes. The Build Contexts program builds the contexts from the dynamic package that is generated by the Build Attribute Mapping Rules program and from the custom package that is created by the customers. Attributes can also be passed to the pricing engine directly without an attribute mapping rule. In such cases, the Attribute Manager API calls a custom API, QP_CUSTOM_SOURCE, where the user has manually defined the attributes being passed and coded the sourcing of their values.

The pricing type can be H (Header) or L (Line) which defines the level of the attribute mapping rule. These attributes and their values are passed to the pricing engine in the same manner as the attributes that are sourced through attribute mapping rules.

Example using QP_CUSTOM_SOURCE

The following example explains how you could code the body of QP_CUSTOM_SOURCE for a particular case. In this case, two segment mapping columns, QUALIFIER_ATTRIBUTE31 and PRICING_ATTRIBUTE31, which belong to contexts CUST_SOURCE_QUAL_CON and CUST_SOURCE_PRIC_CON respectively and are linked to PTE Order Fulfillment, will have Custom Sourced values as 10 for ORDER as well as LINE attribute mapping levels. You must ensure that the attribute mapping method for both these PTE-Attribute links is CUSTOM SOURCED in the Link Attributes window.

CREATE or REPLACE PACKAGE body QP_CUSTOM_SOURCE AS 
/*Customizable Public Procedure*/ 
PROCEDURE Get_Custom_Attribute_Values 
     (  p_req_type_code  IN VARCHAR2  
     ,p_pricing_type_code  IN VARCHAR2
     ,x_qual_ctxts_result_tbl    OUT QP_ATTR_MAPPING_PUB.CONTEXTS_RESULT_TBL_TYPE
     ,x_price_ctxts_result_tbl   OUT QP_ATTR_MAPPING_PUB.CONTEXTS_RESULT_TBL_TYPE 
)       is     
Begin    
  If p_req_type_code = 'ONT' and p_pricing_type_code in ('L','H') then
      x_qual_ctxts_result_tbl(1).context_name := 'CUST_SOURCE_QUAL_CON'; 
      x_qual_ctxts_result_tbl(1).attribute_name := 'QUALIFIER_ATTRIBUTE31'; 
      x_qual_ctxts_result_tbl(1).attribute_value := '10'; 
      x_price_ctxts_result_tbl(1).context_name := 'CUST_SOURCE_PRIC_CON';         
      x_price_ctxts_result_tbl(1).attribute_name := 'PRICING_ATTRIBUTE31'; 
      x_price_ctxts_result_tbl(1).attribute_value := '10';                            
  end if;
end Get_Custom_Attribute_Values;  
END QP_CUSTOM_SOURCE;
/

Restoring Seeded Data Using the Restore Defaults Button

A seeded context is a system value that is not created by the user. A Seeded check box next to a context indicates whether the context is seeded or not (when the check box is selected, the context is seeded). When a Seeded context is selected, the Name and Description fields display the seeded values in the Context Setup window.

However, if you change the seeded values in the Name and Description fields, the new values are displayed, but the original seeded values are preserved in the hidden Seeded Name and Seeded Description fields.

To restore the original seeded values for a context, click Restore Defaults. The Name and Description fields will display the original seeded values rather than the changed values.

Note: The Restore Defaults button replaces values in all the fields with seeded values. The Restore Defaults button is grayed out for non-seeded attributes and for seeded attributes for which seeded values have not been changed by the user so far.

You can restore the default seeded settings in the following windows:

Context Setup

If a seeded context has been changed, you can restore the original seeded value by clicking the Restore Default button. The seeded context values appear in the Name and Description fields; however, if you change the seeded values, the new values appear but the original seeded values are preserved in hidden seeded name and seeded description fields respectively.

For attributes, the Restore Default button restores any changed values to the original seeded values of an attribute. So if a seeded attribute has been changed, the values can be restored to their original condition. Precedence, name, valueset, and datatype window fields display the seeded values in place of user entered values.

For seeded attributes, the Precedence, Name, Valueset, Datatype, and Required fields display the seeded values. However, if you change the seeded values, these fields will show the new user-entered values. The seeded values will be preserved in separate fields that are named as seeded precedence, seeded name, seeded valueset, seeded datatype, and seeded precedence. These seeded fields will always be hidden.

Note: Please note that this button will replace values in all the fields with seeded values.

Link Attributes

For seeded attribute, the Attribute Mapping Method column will have its seeded value. However, if the user changes the attribute mapping method, this field will show the user entered value and the seeded value will be preserved in a separate field named as seeded Attribute Mapping Method. These seeded Attribute Mapping Method fields will always be hidden.

The Restore Default button restores the original seeded attribute mapping method of an attribute. If you overwrite a seeded attribute but later want to restore the seeded values, you can do so by clicking this button.

This button will be grayed out for non-seeded attributes. This button will continue to remain gray for seeded attributes, if the user-entered attribute mapping method remains the same as the seeded attribute mapping method.

Note: The attribute Total Item Quantity is seeded only for Oracle Transportation Execution (FTE). However, you can manually link an attribute to the Order Fulfillment PTE, and create a corresponding sourcing rule for attributes such as Total Item Quantity.

Attribute Mapping

For all seeded Attribute Mapping rules, the Restore Defaults button restores the seeded Source type and the seeded Value string as User source type and User value string respectively. If the seeded source type and the seeded value string are the same as the user source type and user value string, the Restore Defaults button will be grayed out.

Troubleshooting While Setting Up Attributes

Scenario 1

This warning message will appear on setup windows when the user tries to use in the setup, any newly added attribute having Attribute Mapping Method = ATTRIBUTE MAPPING for which the Attribute Mapping Enabled flag is not Y.

Message: This Attribute (with Context: &CONTEXT and Attribute: &ATTRIBUTE) will not be mapped since it is not Attribute Mapping Enabled.

Scenario 2

This warning message will appear on setup windows when the user tries to use in the setup, any newly added attribute having Attribute Mapping Method =ATTRIBUTE MAPPING for which Attribute Mapping Status flag is not Y.

Message: Warning: This Attribute (with Context: &CONTEXT and Attribute:&ATTRIBUTE) has not been mapped yet. Please Build Attribute Mapping Rules.

Scenario 3

The Attribute Mapping level for this attribute was defined as BOTH. In such cases, the user is expected to enter an Attribute Mapping rule, one each for the header and line level. If the user enters only one level, pricing inconsistencies will occur.

Message: This attribute must have an attribute mapping rule both at Header as well as Line levels.

Scenario 4

For a given PTE, the user must enter Attribute Mapping rules for all the request types that belong to that PTE. In case the user does not enter for all of them, different Request types for the same PTE may not be able to fetch the same price.

Message: You must map this attribute for all the Request types.

Troubleshooting in Pricing Setup windows Related to Attribute Management

Scenario 1

You try to attach a combination of qualifier with the attributes that have Attribute Level of LINE and ORDER within the same qualifier grouping number of a qualifier rule on the Qualifier Rules window.

Message: Qualifier Attribute with an attribute level of LINE cannot be present in combination with a Qualifier Attribute with attribute level of ORDER, within a Qualifier Grouping No of a Qualifier Rule.

Scenario 2

This error message will appear on the Qualifiers tab of the Modifiers window when a user tries to attach a combination of qualifier attributes that have attribute level of LINE and ORDER within the same qualifier grouping number.

Message: There is a mix of LINE and ORDER qualifier attribute level for list line ID &LIST_LINE_ID and qualifier grouping number &QUALIFIER_GRP_NO. Ensure that all the qualifier attributes should be either of level LINE/BOTH or ORDER/BOTH for a given list line ID and qualifier grouping number.

Troubleshooting During Pricing Setup

While you are defining Qualifier or Pricing attributes in the Pricing Setup windows, only those attributes with the LOV Enabled box selected appear in the LOVs on these windows. If basic pricing is installed, only those attributes that have been set up with the AVAILABLE_IN_BASIC box selected appear in the LOVs on the various Pricing Components setup windows. However, all attributes that are set up are available to Advanced Pricing users, subject to meeting the other attribute level conditions.

You need to set the profile QP: Pricing Transaction Entity to the correct value before creating or querying any setup data in the pricing application. You should not change this profile often because you will see the other context-attributes combinations for a different PTE when querying on the pricing setup windows. If this happens, you will see the internal ID code.

Troubleshooting During Integration or Runtime

The following section provides answers to common troubleshooting questions that you may have during integration or runtime.

Viewing Attributes

Question 1

Why do I not see the pricing contexts and attributes that I defined in the pricing setup windows?

Answer: The following conditions must be met:

Question 2

What happens if I do not set the Profile QP: Pricing Transaction Entity correctly?

Answer: This profile indicates the current PTE in use. Only those contexts and attributes that are assigned to the current PTE will be available in the LOVs on the setup windows.

Querying up setup data displays the description to be shown only for those contexts and attributes that are assigned to the current PTE.

Entering Orders

Question 1

When you enter an order line in the Sales Order Pad, the following error appears:

FND_AS_UNEXPECTED_ERROR (PKG_NAME=oe_order_adj_pvt) (PROCEDURE_NAME=oe_line_adj.calculate_adjustments) (ERROR_TEXT=calculate_adjustments#130 ORA-06508: PL/SQL: could not find program unit being called).

Answer: Check in dba_errors for this package in or to determine which attribute mapping API is causing the error. If this is a custom API then correct the API. If this is the seeded API then determine whether a correction patch is available.

Question 2

The context of an attribute that was successfully mapped did not show up in the Pricing Context list of values on the Order Management Sales Pad.

Answer: One of the following solutions may resolve the issue:

Additional Attribute Management Considerations

The following table outlines some problems and solutions that are related to attribute management:

Probable Cause How to Debug
QP_Attr_Mapping_PUB.Build_Contexts package is invalid due to incorrect mapping of data attributes mapping. Check in dba_errors for this package in or to determine which attribute mapping API is causing the error. If this is a custom API, then correct the API. If this is the seeded API then determine whether a correction patch is available.
Concurrent Program Build Attribute Mapping Rules failed with error. Run the following statement and examine the output: select text from dba_errors where name =QP_BUILD_SOURCING_PVT. Verify that custom sourcing causes this error.
Getting error while running Build Attribute Mapping Rules concurrent program ORA-06502: PL/SQL: numeric or value error: character string buffer too small ORA-06512: at APPS.QP_ATTR_MAPPING_PUB, line 1445 ORA-20000: ORA-04021: timeout occurred while waiting. This occurs when someone makes a pricing call while the concurrent program is running. Do not run the Build Attribute Mapping Rules concurrent program when active users are calling pricing engine.
While entering the order line in the Sales Order Pad, you receive the following error: END_AS_UNEXPECTED_ERROR (PKG_NAME=oe_order_adj_pvt) (PROCEDURE_NAME=oe_line_adj.calculate_adjustments) (ERROR_TEXT=calculate_adjustments#130 ORA-06508: PL/SQL: could not find program unit being called). Run the following statement and examine the output: select text from dba_errors where name = QP_BUILD_SOURCING_PVT; Determine whether any custom sourcing causes the errors. If the seeded sourcing rule causes this error, determine whether a patch is available to correct the seeded rule. If the error is "Encountered the symbol _ when expecting…" then determine the relevant patch to be applied.

Upgrading Considerations

When upgrading from releases before 11.5.7/Patch G, the upgrade program will do the following:

  1. Upgrade Contexts and Attributes

  2. Upgrade source systems and request types

  3. Create PTEs and attribute links

  4. Upgrade attribute mapping rules

  5. Assign PTEs to existing modifiers

    Pre H Release Post H Release
    Request Types and Source Systems common for all applications Request Types and Source Systems grouped by PTE
    Context and Attributes created and maintained in Flexfields Context and Attributes created and maintained in pricing (QP) tables
    All attributes available to all applications for pricing setup Attributes available to applications based on PTE. Attributes can now be enabled for LOV and limits
    Attributes have one sourcing rule used by all request types Attributes may have one or more attribute mapping rules for different request types
    Only one ordering structure, for example, Order Fulfillment. At least four seeded PTEs, with provision for expanding.

Table Upgrade

Contexts fnd_descr_flex_contexts qp_prc_contexts_b
Context fnd_descr_flex_contexts_tl qp_prc_contexts_tl
Attributes fnd_descr_flex_column_usages qp_segments_b
Attributes fnd_descr_flex_col_usage_tl qp_segments_tl
Source System and Request Types qp_price_req_sources qp_pte_source_systems
Source System and Request Types qp_price_req_sources qp_pte_request_types_b/tl
Attribute Linking oe_def_attr_condns qp_pte_segments
Attribute Linking ak_object_attributes qp_pte_segments
Attribute Linking oe_def_condn_elems qp_pte_segments
Attribute Mapping Rules oOe_def_attr_def_rules qp_attribute_sourcing

Upgrading Context and Attributes

This section describes how to upgrade contexts and attributes from the current flexfield structure to a set of new normalized pricing (QP) tables.

Upgrading Contexts

If your contexts are currently stored in qualifier contexts and pricing contexts flexfields, the upgrade program will copy all the contexts from these flexfields to the new pricing (QP) tables. All the Qualifier Contexts flexfield qualifiers will be copied as qualifier contexts.

All the Pricing Attribute flexfield qualifiers except ITEM will be copied as pricing attribute contexts. ITEM Qualifier will be copied as Product context. All contexts that are created in the flexfields by user 1 will be treated as seeded data. All other information, such as name and description in various languages, and enabled flag are available in the flexfields.

Upgrading Attributes

For every context that is created in the new system from the flexfields, attributes are available in the flexfield usage tables. These attributes will be copied under the corresponding context in the new system. Some attributes in the flexfield usage tables do not have value sets, because some attributes use key flexfields for their valid values. All other information such as names, mapping columns, and precedence are available in flexfield usage tables.

Upgrading Source System and Request Types

Currently, all the source systems and request types are mapped as many-to-many relationships. Seeded request types are provided to include additional relationships between request types.

Attribute management uses the pricing transaction entity feature which consists of an ordering structure comprised of associated request types and source systems. When you are upgrading, a new set of PTEs are created in the target system. In addition to the seeded PTEs, you can create more PTEs depending on the customer's own request types and source systems.

Mapping of Seeded Request Types and Source Systems

A pre-determined process is available to associate request types and source systems with these PTEs. These request types and their associations will act as seeded data. Please refer to the previous sections on Seeded Pricing Transaction Entity, Source Systems, and Request Types.

Whenever a request type is created in the target system by the upgrade program, the default global structure that is associated with them will be as shown in the following table:

Request Types Global Structure Name: Header Level Global Structure Name: Line Level
ASO ASO_PRICING_INT.G_HEADER_REC ASO_PRICING_INT.G_LINE_REC
OKC OKC_PRICE_PUB.G_CONTRACT_INFO OKC_PRICE_PUB.G_CONTRACT_INFO
IC INV_IC_ORDER_PUB.G_HDR INV_IC_ORDER_PUB.G_LINE
ONT OE_ORDER_PUB.G_HDR OE_ORDER_PUB.G_LINE
FTE None None
MSD None None

Creating PTE and Attribute Links

Currently, all the attributes that are available in the existing flexfield may already be attribute mapped. In the new data model, each attribute must be linked to one or more PTEs, before it can have attribute mapping rules:

1) Attributes that are Attribute Mapping enabled or already mapped

Such attributes will be associated with a source system in the current system as per defaulting rules. At this point, the upgrade program has already created all the PTE-Request Types-Source Systems associations (with data) in the target system. The upgrade program will determine the PTE(s) that this source system is associated with and will create as many PTE(s) and attribute links in the new PTE-Attribute mapping table.

For example, suppose Segment-1 is associated with QP Source System, as per the defaulting condition templates. The upgrade program will create three links for this attribute, represented as three rows in the new PTE-Attribute mapping table as shown in the following table:

Pricing Transaction Entity Attribute
1 Unassigned-2 Segment-1
2 Order Fulfillment Segment-1
3 Intercompany Transaction Segment-1

The three rows get created because Source System QP is attached to PTEs Unseeded-2, Order Fulfillment and Intercompany Transaction.

2) Attributes that are not Attribute mapped

Some attributes may not have an attribute mapping rule. These are attributes for which there are no transactions in price lists, modifiers, and formulas. Such attributes will be linked to all the PTEs that you created so far (including the seeded ones) in the PTE Attribute Mapping Table.

Upgrade Attribute Mapping Rules

When you are upgrading, all the attributes that have default Attribute Mapping rules defined in the current system will have the same Attribute Mapping rules redefined in the new model. Every attribute that is present in the PTE Attribute Mapping table may have an Order level mapping, a Line level mapping, or both, depending on how the attributes were defined in the current system, for example, Header only, Line only or Header and Line.

Note: If the Attribute Manager Loader or the Attribute Manager Upgrade program encounters an existing attribute in one of the following situations, it will bypass the upload or upgrade of that attribute:

However, unlike the current system, every attribute that will have an attribute mapping rule will ideally have as many sets of attribute mapping rules as the number of Request types that are associated with the PTE for that attribute in the PTE attribute mapping table. At this point, the upgrade program may not create all the attribute mapping rules for all the request types. Depending on the attribute, given the application that created it, the upgrade program will create attribute mapping rules for the request types as shown in the following table:

Source Systems Request Types
QP ONT
OKC OKC
ASO ASO
AMS ONT, ASO

Only the seeded PTE-Attribute combinations from the PTE attribute mapping table that were created for use in basic pricing can have default attribute mapping rules. Also, all the attributes that have defaulting rules and belong to Source System FTE, will not have attribute mapping rules.

Assigning PTE to Existing Modifiers

Attribute mapping identifies the PTE from which the related modifier lists, price lists, and formulas were created (in addition to the source system, which was used so far). A new column PTE_CODE has been added to the QP_LIST_HEADERS_B table, which stores the PTE. The upgrade program updates the PTE_CODE for every modifier list, price list, or formula based on the following logic:

After the upgrade program creates all the PTE-Request Types-Source Systems associations (with data) in the target system, the upgrade program determines the PTE(s), for every modifier from its source system. If the source system is associated with one PTE only, the PTE_CODE will be updated with that PTE. If the source system is associated with more than one PTE, Order Fulfillment will be chosen over other PTEs.

Sample Code

-- Please note, the cursor cs_item_cost may need to be modified 
-- before use in your environment.

CREATE OR REPLACE
PACKAGE MY_CUSTOM_SOURCING AUTHID CURRENT_USER AS
-- please see package body for version, history and notes.
-- Package globals...G_Organization_id NUMBER := FND_PROFILE.VALUE('QP_ORGANIZATION_ID');
-- Cached in and out values for each sourcing routine.
TYPE Item_Info_Rec_Type IS RECORD
( inventory_item_id  VARCHAR2(240)
, item_cost NUMBER
);
G_Item_Info   Item_Info_Rec_Type;
FUNCTION Get_Item_Cost (p_item_id IN NUMBER) RETURN VARCHAR2;
PRAGMA RESTRICT_REFERENCES (Get_Item_Cost,WNDS);
END MY_CUSTOM_SOURCING;
/
--------------------------------------------------CREATE OR REPLACE
PACKAGE BODY MY_CUSTOM_SOURCING AS
/* Package Body version 1.01 - 30th January 2001 */
-- This is the package body for Simon's example of
-- Advanced pricing 11i's custom sourcing routines used for
-- retrieving additional information from the apps tables into pricing
-- data structures.
-- standard functionality is not feasible.
-- To marginally improve performance on successive pricing calls,
-- we cache the most recent details from the sourcing functions
------------------------------------------------------------
-- so that the cursors are not run every time if the requests
-- are the same. These cached values are stored in package-wide 
-- variables.
------------------------------------------------------------
FUNCTION Get_Item_Cost (p_item_id IN NUMBER) RETURN VARCHAR2 IS
-- Function to retrieve an item cost from cst_item_costs
-- note, this returns null is a cost is not found 
-- so that the calling app can handle this.
-- Note, Use your own cost type id from cst_cost_types.
-- I've used 1 just for testing.
CURSOR cs_item_cost(cp_item_id IN NUMBER) IS
  SELECT    cic.item_cost 
    FROM    cst_item_costs cic
    AND     cic.cost_type_id      = 1 
    AND     cic.organization_id   = G_organization_id;
 v_cost cst_item_costs.item_cost%TYPE := NULL;
BEGIN
  IF p_item_id = G_Item_Info.inventory_item_id THEN
-- if the requested item is already cached then do nothing yet.
    NULL;
  ELSE