A day in the life of an Oracle Applications Consultant

Thursday, January 06, 2005

GET_CUSTOM_PRICE - Do’s and Don’ts

Suv Biswas has posted a very good article written on how to use GET_CUSTOM_PRICE (it is listed under Advanced Pricing section). It gives you a step by step tutorial on how to use GET_CUSTOM_PRICE. I have used this feature in multiple implementations. At one of the client sites, I had some come up with some Dos and Don’ts for the developers using GET_CUSTOM_PRICE. I have re-written it to fit the format of this blog, I think that it would be a nice extension to Suv’s article, I also hope that it might come in handy (and save some time) for those trying to use this functionality.


=> Don’t use global memory structures like OE_ORDER_PUB.G_LINE, ASO_PRICING_INT. G_LINE etc in Get Custom Price.
Since these structures are used to source Pricing and Qualifier Attributes (seeded or custom), there is a tendency to use these in GET CUSTOM PRICE as well. However there are two major differences between the way Sourcing rules for Pricing and Qualifier Attributes are used and the way GET_CUSTOM_PRICE is used.

a) When any module calls Pricing for more than one line it calls QP in a batch. The calling application loads all the pricing and qualifier attributes before the call to QP. As a result when the sourcing for these attributes is called it has access to the global structures (like OE_ORDER_PUB.G_LINE etc.). A structure with all these attributes is used as an input to QP Call.

So when GET_CUSTOM_PRICE gets called, OE_ORDER_PUB.G_LINE (in our example) has information for any one line (typically the last line). The reason is simple. Pricing Attributes and Qualifier Attributes are input parameters for QP.

b) In a lot of implementations, more than one application would use the same Price List (or Modifier). for example, Quoting, iStore and OM would often use the same Price List and Modifiers. You will notice, that while there is an option for writing different sourcing rules for different calling application there is no such thing for GET_CUSTOM_PRICE. The reason is simple (as explained in previous point). The pricing and qualifier attributes are loaded by the calling application. QP just concerns itself with Pricing and Qualifier Attributes which in effect are input parameters to QP. It is specifically done so that various modules can call QP and it is not tightly coupled with any one.

=> Make sure that the pricing attributes used in GET_CUSTOM_PRICE is either used somewhere in an active pricing setup in Setups or the profile option “QP: Build Attributes Mapping Options” is set to No (or QP: Check For Active Flag is set to No).

The profile option “QP: Build Attributes Mapping Options” controls whether all or only the used pricing/qualifier attributes are sourced. Setting the profile option to “No” is pretty wasteful, since there are more than 200 seeded pricing and qualifier attributes and it is highly unlikely that you use more than 50. You might end up creating a dummy price list to use the pricing and qualifier attributes that are not used anywhere else but are used in GET_CUSTOM_PRICE.

=>  If you are using GET_CUSTOM_PRICE in various Pricing Formulae for different functionality, set a flexfield aside to identify the formula.

One of the inputs to GET_CUSTOM_PRICE is pricing_formula_id, but the value of this is likely to change between development, test and production instances, so it is, obviously, not advisable to hard code the pricing_formula_id in the function. The pricing formula name field is update-able, it is possible for someone to inadverdently change it, for the users to demand a more friendly name. The additional advantage of using the flexfield value is that if you have more than one formula using the same functionality you don’t have to code for it.

=>  Minimize number of Loops

One has to loop through the structure “p_req_line_attrs_tbl” to get to the required value. Say :

  FOR i IN 1..p_req_line_attrs_tbl.COUNT
  if p_req_line_attrs_tbl(i).attribute_type = ‘PRICING’ and
    p_req_line_attrs_tbl(i).context = ‘PRICING ATTRIBUTE’ and
    p_req_line_attrs_tbl(i).attribute = ‘PRICING_ATTRIBUTE31’ then
      if X_FORMULA_TYPE = ‘A’then
        x_return_value := xxxx_get_price_details_a ((to_number(p_req_line_attrs_tbl(i).value)));
      elsif X_FORMULA_TYPE = ‘B’ then
        x_return_value := xxxx_get_price_details_b ((to_number(p_req_line_attrs_tbl(i).value)));
        end if;
  end if;

in this case PRICING_ATTRIBUTE31 is setup to source line_id, so we find the required value in p_req_line_attrs_tbl(i).value
If get_custom_price is being used in more than one formula, then make sure that (a) the loop runs only once and (b) you exit the loop as soon as you are done. PL/SQL can be pretty slow, and the time consumed is difficult to find as it does not appear in your standard TKPROF output. Another reason why (as covered in the next point) the value of “QP: Pass Qualifiers to Get_Custom_Price API” should be set to No unless you really require it.

=>  Set correct value for “QP: Pass Qualifiers to Get_Custom_Price API”.

Qualifier Attributes are not automatically available to GET_CUSTOM_PRICE. If you want to use value of a qualifier attribute, make sure that the value of profile option “QP: Pass Qualifiers to Get_Custom_Price API” to ‘Yes’. As explained in the previous point, set the value to No unless it is really required to be ‘Yes’.