Let’s say that we have a requirement to qualify Modifier discounts against specific customer account numbers. Oracle provides us with a Qualifier for a customer’s Party ID, but does not provide a Qualifier for account number – we’ll need our own custom API to accomplish this.

Before we start, let’s not forget that a sales order could have multiple customer’s associated with the transaction. Remember that we can have up to three customers on a sales order that represent the selling, billing, and shipping organizations (there are even more when factoring in deliver to and installed at, but for this example let’s focus on the main three). The business requirements behind the discount could determine that we only need one of the three, but let’s assume that discounts could be applied to any of the selling, billing, and shipping customers. Hence, we’ll need three Qualifiers to represent each.

Let’s start by navigating to Setup > Attribute Management > Contexts and Attributes to choose our Context and create our core Attribute information. Since this Attribute will be mapped to a value stored on the customer master record, it’s most appropriate to place our attribute under the Customer context.

Next, let’s add three Attribute records under the Attributes block with the appropriate Codes, Names, and Descriptions that will represent our sold to, bill to, and ship to customer account numbers. I’ve also decided to use a seeded Customer Account Value Set to validate our attributes against a valid list of customer account numbers.

Lastly, we’ll need to assign an available column. As in my previous example, I’d recommend selecting a column that is a distance away from the last column that is being used to avoid any conflicts (in case Oracle decides to introduce new qualifying attributes in the future).

Now let’s navigate to Setup > Attribute Management > Attribute Linking and Mapping to map our Customer Account attributes. Select Order Fulfillment for Pricing Transaction Entity and Qualifier Context for Context Type, choose Customer as the Context, and click the Link Attributes button.

Once the Link Attributes form is open, we’ll add three new records for our Attributes. Since customer information is stored on the header AND line detail of a sales order transaction, our Level will be Both, followed by Attribute Mapping as our Attribute Mapping Method since we’re going to be referencing a PL/SQL function to retrieve our customer account number values.

After saving your changes, we’ll want to begin mapping all three attributes. Let’s start with the Customer Sold To Account Number by clicking on the corresponding record and clicking the Attribute Mapping button. Once the Attribute Mapping form appears, select the ONT reference record for Order Management.

Since we indicate Both as our reference level, we’re required to provide mapping references for both the Header and Line Source setups. At this point we know that our Source Type will be a PL/SQL API for each, but now here comes the hard point – exactly what PL/SQL will enable us to retrieve the Customer Sold To Account Number?

Going back to our Customer Party ID example, we see that this Qualifier is mapped to an Oracle seeded function called QP_SOURCING_API_PUB.GET_PARTY_ID.

QP_SOURCING_API_PUB.GET_PARTY_ID(OE_ORDER_PUB.G_HDR.sold_to_org_id)

QP_SOURCING_API_PUB.GET_PARTY_ID(OE_ORDER_PUB.G_LINE.sold_to_org_id)

We’ll need to create our own similar function in order to retrieve the sold to customer account. At a table level, since the order header (OE_SALES_ORDER_LINES_ALL) and order lines (OE_SALES_ORDER_LINES_ALL) contain direct references to the sold to customer (SOLD_TO_ORG_ID), and since the customer account number is stored directly in the customer master view (HZ_CUST_ACCOUNTS), we can build an almost identical query compared to what the seeded Customer Party ID function.

So given the SOLD_TO_ORG_ID of the sales order transaction, we can create a function that accepts SOLD_TO_ORG_ID as a parameter and retrieves the customer account number. We’ll need to build our own package which includes this function, so I created a package called XQP_SOURCING_API_PUB. This package will contain all of our custom functions needed to retrieve custom Qualifier values:

CREATE OR REPLACE PACKAGE BODY APPS.XQP_SOURCING_API_PUB AS

FUNCTION GET_SOLD_TO_ACCOUNT_NUMBER(p_sold_to_org_id IN NUMBER)
RETURN varchar2
IS

l_sold_to_account_number varchar2(30);

CURSOR get_sold_to_account_number_cur (l_sold_to_org_id NUMBER)
IS
SELECT account_number
FROM hz_cust_accounts
WHERE cust_account_id = l_sold_to_org_id;

BEGIN

OPEN get_sold_to_account_number_cur (p_sold_to_org_id);
FETCH get_sold_to_account_number_cur INTO l_sold_to_account_number;
CLOSE get_sold_to_account_number_cur;
RETURN l_sold_to_account_number;

EXCEPTION
WHEN OTHERS THEN
RETURN NULL;

END GET_SOLD_TO_ACCOUNT_NUMBER;

END XQP_SOURCING_API_PUB;

Let’s compile and confirm that our PL/SQL runs successfully. We need to also be sure to include the package specification before compiling the above source.

Now that we have our function, we need to complete our Attribute Mapping setup by including in the User Value field the PL/SQL reference to this function both in the Header and Line setups. Our function accepts the SOLD_TO_ORG_ID as a parameter, so by using the G_HDR and G_LINE record structures, we can pass this value as our parameter.

XQP_SOURCING_API_PUB.GET_SOLD_TO_ACCOUNT_NUMBER(OE_ORDER_PUB.G_HDR.sold_to_org_id)

XQP_SOURCING_API_PUB.GET_SOLD_TO_ACCOUNT_NUMBER(OE_ORDER_PUB.G_LINE.sold_to_org_id)

Finished! Let’s go to the Tools file menu and select “Build Attribute Mapping Rules” to confirm our setups are correct.

We’ve successfully built our Sold To Customer Account Qualifier, but we still need separate PL/SQL functions for the customer bill to and ship to account Qualifiers. On the OE_ORDER_HEADERS_ALL and OE_ORDER_LINES_ALL tables we have a reference to the BILL_TO_ORG_ID and INVOICE_TO_ORG_ID columns, but these ID’s refer to the site usage records in HZ_CUST_SITE_USES. With that said, our queries for these functions will be slightly different than the sold to function.

FUNCTION GET_SHIP_TO_ACCOUNT_NUMBER(p_ship_to_org_id IN NUMBER)
RETURN varchar2 IS

l_ship_to_account_number varchar2(30);

CURSOR get_ship_to_account_number_cur (l_ship_to_org_id NUMBER)
IS
SELECT c.account_number
FROM hz_cust_acct_sites a,
hz_cust_site_uses b,
hz_cust_accounts c
WHERE
a.cust_acct_site_id = b.cust_acct_site_id
AND b.site_use_id = l_ship_to_org_id
AND b.site_use_code = ‘SHIP_TO’
and a.cust_account_id = c.cust_account_id;

BEGIN
OPEN get_ship_to_account_number_cur (p_ship_to_org_id);
FETCH get_ship_to_account_number_cur INTO l_ship_to_account_number;
CLOSE get_ship_to_account_number_cur;
RETURN l_ship_to_account_number;
EXCEPTION WHEN OTHERS THEN

RETURN NULL;
END GET_SHIP_TO_ACCOUNT_NUMBER;

FUNCTION GET_INVOICE_TO_ACCOUNT_NUMBER(p_invoice_to_org_id IN NUMBER)
RETURN varchar2
IS

l_invoice_to_account_number varchar2(30);

CURSOR get_bill_to_account_number_cur (l_invoice_to_org_id NUMBER)
IS
SELECT c.account_number
FROM hz_cust_acct_sites a,
hz_cust_site_uses b,
hz_cust_accounts c
WHERE a.cust_acct_site_id = b.cust_acct_site_id
AND b.site_use_id = l_invoice_to_org_id
AND b.site_use_code = ‘BILL_TO’
and a.cust_account_id = c.cust_account_id;
BEGIN
OPEN get_bill_to_account_number_cur (p_invoice_to_org_id);
FETCH get_bill_to_account_number_cur INTO l_invoice_to_account_number;
CLOSE get_bill_to_account_number_cur;
RETURN l_invoice_to_account_number;

EXCEPTION WHEN OTHERS THEN

RETURN NULL;

END GET_INVOICE_TO_ACCOUNT_NUMBER;

Let’s also include these functions in our XQP_SOURCING_API_PUB package and compile our functions.

After confirming successful compilation, we can add similar function references in the Attribute Mapping setups for the Bill To Customer Account and Ship To Customer Account Qualifiers.

SCHQP_SOURCING_API_PUB.GET_SHIP_TO_ACCOUNT_NUMBER(OE_ORDER_PUB.G_HDR.ship_to_org_id)

SCHQP_SOURCING_API_PUB.GET_SHIP_TO_ACCOUNT_NUMBER(OE_ORDER_PUB.G_LINE.ship_to_org_id)

SCHQP_SOURCING_API_PUB.GET_INVOICE_TO_ACCOUNT_NUMBER(OE_ORDER_PUB.G_HDR.invoice_to_org_id)

SCHQP_SOURCING_API_PUB.GET_INVOICE_TO_ACCOUNT_NUMBER(OE_ORDER_PUB.G_LINE.invoice_to_org_id)

Once we’ve entered the references into the User Value fields, let’s build the attribute mapping rules for each to confirm the setups are successful.

All finished! Now if you go to Modifier setup form, you should see Sold To Customer Account Number, Bill To Customer Account Number, and Ship To Customer Account Number as available Qualifiers under the Customer context.

Without a doubt, the combination of Qualifier Attribute Mapping setups with PL/SQL creates flexible functionality for establishing how and when pricing Modifiers should be applied – empowering the implementer to meet the most complex of discounting and surcharge requirements.

Oracle provides a wide array of Qualifiers to evaluate a sales transaction, but situations often arise where Qualifiers are needed for attributes that aren’t available out of the box. However, with a few configurations and little bit of PL/SQL knowledge, you can create your own Qualifier attributes.

But before we begin, it helps to look at some commonly used Qualifiers to see how they’re configured, and ultimately how Oracle is able to source the information. Let’s start by going to the Oracle Pricing Manager responsibility, navigate to Setup > Attribute Management > Contexts and Attributes. From this form, we’ll be able to see the starting point from where the Qualifier attributes are created.

Click the Search (flashlight) icon and select context type of Qualifier Context and code of Order. After you make the selection, you’ll see the seeded qualifying attributes listed under the Attributes block of the form.

As an example, let’s look at the Order Type attribute, which represents the Order Type field of the sales order header. Here you’ll see the basic information that is associated with this Qualifier, most notably the Column Mapped, which indicates where in the Qualifier attribute structure to store the referenced value, and the Value Set, which is used to validate this value. The Value Set is important because when assigning this Qualifier to a Modifier, this is the Value Set that will be used to validate the input accepted when comparing this Qualifier to a value. In this case, when we reference the Order Type qualifier, the “QP_ORDER_TYPES_ALL” value set will only compare this qualifier to valid order types; not line types, random text, numeric inputs, etc.

To see how this attribute is mapped to the actual Order Type field on the sales order, we need to return back to the menu and navigate to Setup > Attribute Management > Attribute Linking and Mapping. Enter Order Fulfillment for Pricing Transaction Entity and Qualifier Context for Context Type. You’ll notice that the same listing of contexts is displayed under the Contexts block.

Select the ORDER code record and click the Link Attributes button. A form will display a listing of all the same attributes we saw from the Contexts and Attributes form, but with information as to where the Attributes are sourced from.

Looking at the Order Type attribute, you’ll see that Level for this attribute is BOTH. This indicates that the Order Type can be referenced from the header or the line details of the corresponding transaction. Other options for Level include LINE, which indicates that the source is at the line detail level, and ORDER, which indicates the attribute can be sourced at header level of the transaction.

Next to the Level is the Attribute Mapping Method, which indicates the method in which the Attribute is sourced. In this case, the method for Order Type is ATTRIBUTE MAPPING, which indicates a more technical reference is required to source this value (i.e. PL/SQL, system variable, etc.). Other Attribute Mapping Methods include RUNTIME SOURCE, indicating that the attribute will be populated by the QP_CUSTOM package, and USER ENTERED, indicating that the value will be populated by the user (this is more common for Pricing Attributes rather than Qualifier Attributes).

To see the kind of Attribute Mapping reference that exists for Order Type, click on the Attribute Mapping button. What you’ll see is a listing of mapping setups for the Order Type attribute broken down by application. Oracle accepts an attribute mapping by application because from a data structure standpoint, the reference to Order Type can be different in Order Management then other modules like Telesales, Service Contracts, etc.

To view the source mapping for Order Management, click on the record indicating ONT for request type and take note of the settings for Header Level and Line Level Attribute Mappings on the bottom half of the form. Here’ you’ll see the actual PL/SQL references that are being made to retrieve the Order Type. Note the Seeded/User Source Type and Seeded/User Value String settings for each:

Reference Type:        PL/SQL API
User Value:                OE_ORDER_PUB.G_HDR.order_type_id

This shows us that this attribute is sourced via a PL/SQL API and calls the PL/SQL string OE_ORDER_PUB.G_HDR.order_type_id. The G_HDR record structure is seeded by Oracle and contains data for the sales order header transaction that is being actively processed and evaluated. It is accessible globally from where the Pricing Engine is executing the PL/SQL code contained in the User Value field. So by accessing this global record structure, Oracle was able to map the Order Type transaction ID to the Order Type attribute – making this information available to Qualifier and Modifier setups in Advanced Pricing.

Other more advanced Qualifier examples exist which show direct calls to seeded PL/SQL functions. Starting again from the Setup > Attribute Management > Attribute Linking and Mapping navigation path, check out the Party ID located under the CUSTOMER context and take a look at the User Value String under the same Link Attributes form we were just in.

Since the customer party ID cannot be directly sourced from sales order transaction, Oracle had to develop a quick function call that references the SOLD_TO_ORG_ID of the sales order to retrieve the Party ID from the HZ table structure (QP_SOURCING_API_PUB. GET_PARTY_ID). Notice that since customer information is stored on both the header and the lines of a sales order transaction that Oracle utilizes the G_HDR and G_LINE global record structures to pass the sold to customer information to the seeded API.

QP_SOURCING_API_PUB.GET_PARTY_ID(OE_ORDER_PUB.G_HDR.sold_to_org_id)

QP_SOURCING_API_PUB.GET_PARTY_ID(OE_ORDER_PUB.G_LINE.sold_to_org_id)

Opening up a TOAD session and running the describe command on the QP_SOURCING_API_PUB package shows the details of this function in addition to other functions developed by Oracle to retrieve other data mapping sources used by other seeded Qualifiers.

Given what we’ve seen so far, the configuration aspect of a Qualifier is quite simple, but it takes just a bit of PL/SQL knowledge to actually map your Qualifier to a source. You don’t quite need to be an expert per say, but have just enough technical know-how to be “dangerous”.

Now that we have a decent idea of the inner workings of a Qualifer, let’s walk through the steps again and try to create our own. Say for example that a business requirement has come up which calls for a discount to be applied based on a value stored in a Descriptive Flexfield segment (we’ll pretend it’s ATTRIBUTE10 of the sales order header).

We first begin by navigating to Setup > Attribute Management > Contexts and Attributes to choose our Context and create our core Attribute information. Since this Attribute will be mapped to a value stored on the sales order header, it’s most appropriate to place our attribute under the Order context.

Next, let’s add a record under the Attributes block and provide our Attribute with a Code, Name, and Description.

After identifying our Attribute, we’ll need to choose our Value Set. Let’s assume that this is a Yes/No field that will be validated against the “QP: Yes/No” value set. We’ll also need to assign an available column. I’d recommend selecting a column that is a distance away from the last column that is being used to avoid any conflicts (in case Oracle decides to introduce new qualifying attributes in the future).

Now let’s navigate to Setup > Attribute Management > Attribute Linking and Mapping to map our newly created Attribute to a source. Let’s again select Order Fulfillment for Pricing Transaction Entity and Qualifier Context for Context Type, choose ORDER as the Context, and click the Link Attributes button.

Once the Link Attributes form is open, we’ll add a new record to map our Attribute. By selecting the list of values for the Code, our new attribute should appear in the list. If our attribute is the only attribute under the Order context that is not mapped, it should default to our Attribute automatically.

Assuming that we’ll want this Qualifier accessible from the header and line details of a sales order transaction, we’ll select BOTH as our Level, followed by Attribute Mapping as our Attribute Mapping Method.

Save your changes, and click on the Attribute Mapping button. Since our Qualifier is referencing the Flexfield segment within the Order Management module, let’s again select the ONT reference record, but this time populate “Advanced Pricing” for the Application Name.

Moving along to the Header and Line Level setups, we want to indicate that our User Source Type will be a PL/SQL API for both, followed by the appropriate PL/SQL string in the User Value String field.

You might be asking, “How do we determine what PL/SQL string to use?”

If we refer back to the Order Type attribute example, the G_HDR record structure is the global structure that is populated with the current sales order header transaction data. If you’re familiar with the OE_ORDER_HEADERS_ALL table, you’ll know that all we need to do is reference G_HDR.ATTRIBUTE10 to retrieve our Flexfield segment. Since we’re referring to the Flexfield segment stored on the order header, the User Value String values for both the Header and Line Levels will be the same.

OE_ORDER_PUB.G_HDR.attribute10

This example was fairly straight forward since the Flexfield segments are easily identifiable and stored directly in the G_HDR record structure. However, if in other situations you’re unsure of which column actually stores the data you wish to reference, you may have to query data against the OE_ORDER_HEADERS_ALL or OE_ORDER_LINES_ALL tables to determine where your data is stored. And in cases where the value isn’t found in these tables, then you may have to develop a custom API similar to how the Party ID Qualifier is implemented (I’ll post an example of how to do this in a future article).

Now that we’re finished with our setups, we can save our changes.

After saving your work, let’s navigate to the Tools file menu and select Build Attribute Mapping rules. This will compile our Attribute Mapping setups with our PL/SQL reference in place. If any typos or incorrect syntax is made in the User Value, you’ll find out from the results of the compilation.

Assuming that you’ve enter the PL/SQL string correctly, you should receive a message indicating the Attribute Mapping Rules have been built successfully.

Upon clicking OK closing the Attribute Mapping form you may receive the following warning message:

Oracle is screaming at us because we chose to only map our attribute for the Order Management application and not the other applications that are listed under the Application Types. For the purposes of this demonstration, we can click OK and be done with hit. However, if you’re organization is utilizing Advanced Pricing from elsewhere (Service Contracts, Telesales, etc.), then I would recommend that you also provide source mappings for those dependent applications as well.

Sweet! Now you have a Qualifier that references a sales order header Flexfield attribute! You should now be able to view this Qualifier when setting up List or Line Qualifiers from the Modifier setup form as shown below.

Now even though we’ve built and compiled our attribute mapping, Oracle may still warn you that the Qualifier you’ve reference hasn’t been mapped. If this is the case, you can run the Build Attribute Mapping Rules concurrent request and this should take care of the issue.

As I mentioned, this Qualifier serves as a good example for when the data is readily accessible via the G_HDR or G_LINE global record structures, but stay tuned for another example which will show how we can create our own custom PL/SQL function to source an Attribute.

Oracle does provide the ability to recognize freight as revenue, which in turn calculates tax on the charge, but this doesn’t happen until the order has been interfaced to Receivables (AR). For some corporations, that calculation needs to happen at the time of order entry.   Additionally, some clients who utilize iPayment to authorize a credit card charge in OM and apply the fully transact the charge when the order is interfaced to AR will also encounter issues because the authorized amount, which doesn’t include the tax on freight, is less than the actual charge amount on the AR side, causing the credit card transaction to fail entirely.  

Needless to say, it’s a pain, and a blatant functionality gap.   However, with a slight customization, a semi-acceptable solution can be found by harnessing some of the functionalities available in Advanced Pricing.

Going back to Oracle’s recommended solution of adding an order line item for freight if it is to be taxed – the main issue with this work around is that it’s not automatically added to the order.   For high-volume order entry environments, this is an absolute necessity.   One of the great advantages of modifiers in Advanced Pricing is the ability to allow charges and adjustments to be automatically applied to an order based on qualifying events.   This is an important piece of functionality that is lost using Oracle’s line item workaround.

However, there is a functionality in Advanced Pricing, often not used, that can automate the entry of an order line.   The “get item” functionality under the “Promotion” modifier type allows you to add items to a sales order based on the qualifiers you set.   This functionality is typically used for a “buy one, get one free” scenario, but can be used in this situation to add a freight order line automatically to a sales order.

The only setback to this functionality is that the pricing capabilities are limited.   When setting up a “get item” modifier, you cannot attach a formula.     The functionality only allows you to obtain a fixed list price from a price list or generate a new price.   This may be OK if you’re organization charges a fixed amount for freight, but for those who calculate freight based on the selling amount, this is very bad.   Out of the box, there is no way to get around this.   Even applying a modifier on top of the order line that is added by the “get item” modifier doesn’t work, because when the line item is added, the Calculate Price Flag is set to “Partial Pricing”.   What “Partial Pricing” means is that it will obtain the price that is established in the “get item” setup, but it will neglect any modifiers or adjustments applied to that order line.   The only way around this is to manually set the Calculate Price Flag to “Calculate Price”, then re-price the line.  

While setting the Calculate Price Flag manually works, this defeats the purpose of adding the freight line automatically to the order.   The point of this exercise is to add the line with the price automatically calculated so that there’s no need for the users to perform this step in a high volume order entry environment.   This is where that “slight” customization as I mentioned earlier comes in.

If setting the Calculate Price Flag to “Calculate Price” after the line has been automatically added solves the issue, then why not have a concurrent request, which runs as often as the business desires, perform this action so that the price of the freight order line is correctly calculated?   This is exactly what we did with my last client and it ended up working quite well, but with one little exception.

Being that this is a line item, there is no way to prorate the freight in the event there is partial or multiple shipments for a given order.   Depending on the nature of your business, this may not be acceptable.   There’s a couple of way to address this:

• Restrict partial shipments from occurring by enabling header level invoicing or utilizing fulfillment sets.   This will ensure that all line items are fulfilled before issuing an invoice.   However, if you’re organization requires that an invoice be generated for each shipment, this would not be an acceptable solution.
• If the first option doesn’t fit your business model, you can place an automatic invoicing hold on the freight line item that is only released when the entire order is shipped.   What this does is allow items that are shipped partial to generate an invoice, but delays the billing of freight until the last shipment is made.   The automatic hold can be done as a hold source, but releasing the hold would need to be another one of those “slight” customizations you would need.   However, if you’re organization needs to include freight charges with every delivery, this solution wouldn’t work for you either.
• If neither of the above option is acceptable, and you need the whole shebang, than a more complex customization is needed that splits the freight item for each shipment.   So for example, you have a 10 line item sales order where your freight charge is $50.   During the first shipment, 5 of the 10 lines are shipped out there door.     What the customization would do is split the freight line item into two lines 0.5 quantities, which in affect would split the price in half.   Only one of the split lines would be processed with the shipment, the other split line would be placed on hold.   For this to happen, you’re item would need to be setup as “OM Divisible” enabled, which indicates that fractional quantities are allowed.

Getting around this issue is not easy, but can be possible.   If you’d like to obtain a copy of my code which resolves the pricing issues with adding line items automatically using the “get item” functionality, feel free to contact me.

Also, to find out how to calculate freight, charges, or adjustments based on the total order amount, check out this article.

It’s common in the industry my client serves to contact past customers to “borrow” stocked parts previously sold to them to service another customer in an emergency situation.   In this example, my client received an order from Customer A for an emergency part.   If my client were to go through the normal SCM channels the part would never make it in time for Customer A.  

As a last resort my client decided to research sales made for this same part and discovered that they sold this exact part to Customer B in recent months.   They contacted Customer B and learned that this part was still in stock.   Customer B allowed my client to borrow this part for the emergency situation as long as it was replaced within an acceptable timeframe.

Now with an available part on-hand they could provide the emergency part to Customer A.   Aside from any expediting fees that Customer A is charged, one would think that the price of this part would be the same as sold to Customer B.   However, this was not the case.   The salesman at the time figured he could gain a higher margin on Customer A and take advantage of the emergency situation.   With no pricing policies in place and no oversight to the situation, the salesman was able to make the call and increase the price by a substantial amount.

The salesman was aware that Customer A and B were both generally in the same industry, but they were also located in different countries, which he thought would minimize the risk of the two finding out.   And so what if they were?   When was the last time you saw the price of a spare part in a company’s financial statement?

While all of this was true, what the salesman didn’t know was that Customer B was a sister company of Customer A.   Although Customer A had already placed an order from my client, they were still investigating other options they had in getting the emergency part as quickly as possible.   So, of course, Customer A decided to contact their sister company, Customer B, to see if they had a similar part in stock.   Customer A was thrilled to hear that Customer B had the part, but through the course of their discussion, discovered that they were substantially over charged for the part.   They were more shocked when they discovered that they both purchased the part from the same vendor – my client.

Upset with the situation, Customer A calls my client to find out why there was such a drastic difference in the price.   Of course, the salesman is unable to explain the situation, and as result Customer A cancels their order and instead borrows the part from their sister company Customer B.   Also disgusted with the situation, Customer B cancels their replacement order and decides to go to another vendor.

Because of poor policy and lack of controls in their systems, the salesman was able to make this price change without any oversight.   What was intended to be a several thousand dollar gain resulted in a several million dollar loss – not to mention the lost opportunities of any future sales to Customers A and B – which I don’t even want to think about how much that adds up to.   A proper pricing policy and a system, such as Oracle Advanced Pricing, with the necessary controls to enforce this policy would have ultimately prevented this situation.

Click here to learn more on the importance of implementing a solid pricing policy.

These can be tough questions to answer depending on the pricing policies your company enforces. Surprisingly, many of today’s global corporations still manage pricing of their products and services independently at a regional level. Even companies that are running a global ERP system have implemented their pricing strategy in this fashion.

For some companies this isn’t necessarily bad. It could have been that it made good business sense at the time to keep pricing controlled independently at each of your regional operations. For example, your organization may have a subsidiary in China that manufactures and sells a product that’s only offered domestically because there’s no market for it anywhere else.

But for most global supply chain companies this isn’t the case. The organization you work for most likely manufactures and distributes products across multiple factories, which are then shipped to distribution centers and/or clients all over the world. If your company operates at this scale, there’s a good chance that your pricing strategy remains separate and potentially inconsistent across the board.

Let’s take for example this situation; as a sales manager, you have just sold a high-powered engine for big bucks from your office in Louisville, Kentucky to a client headquartered in Germany. You call up your colleague, Adolph, at the Berlin branch to relay the good news. However, Adolph tells you that his division recently increased the price for this model engine and has sold it for nearly 25% more to one of your client’s competitors. When you find this out you may be upset for two reasons:

1.) You could have just sold the same engine for 25% more and made a heck of a lot more money, not to mention a higher commission.

2.) Your company may lose a customer (not to mention a friend), because when Adolph’s client finds out your company just sold one of their major competitors the same engine for less, they’re not going to be very happy (and neither is Adolph).

In this scenario, you had no clue that the operations in Germany had increased their price for the engine you just sold. If you hadn’t spoken to Adolph, you would have never of found out about this price increase. The price you used was a figure based on the policies that were established within your local operation. And the policy you referenced was based on the marginal figures and market conditions within your specific region – all of which may not have been consistent with the German policies.

An even worse situation could be that both you and Adolph quoted the engine to the same customer for different prices. For example, a solicitation is issued by a potential client looking for the same engine offered by your company. Both you and Adolph spot this RFP and, without knowing, you each send your own formulated quote. And because of separate pricing policies, the quoted prices differ. This could definitely raise a few eye brows from a client prospective and puts your company at serious risk of losing the contract.

The problem in both of these cases is that the US and German pricing policies are completely separate, and there’s no procedure in place to communicate any price change between the two operations. This may have happened for many reasons – maybe when the German operation was first established or acquired an initial procedure wasn’t put in to ensure pricing consistency. It’s also possible that competition between the two operations is quite heated and as a result neither division wishes to share any information that could potentially give the other a competitive edge.

If you’re truly operating a global supply chain company you don’t want situations like these to occur. Ideally what your organization wants is a central point of reference where the entire company can obtain an accurate and consistent price – no matter what continent you’re selling from or who you’re selling to. This referenced price should take into consideration several factors such as the line of product being sold, the regional manufacturing and/or purchasing costs, expectations in margin, and selling conditions at a domestic and international level.

This central point of reference cannot be established through implementation of an IT system alone – it takes people to execute this philosophy. Essentially what is needed is a core “pricing think tank”. The members of this committee should be representative of your organization across the globe and have long-term experience within the organization, a strong understanding of the organization at a regional and international level, and proven marketing and financial leadership. The establishment of a “pricing think tank” is a very important first step towards the globalization of your organization’s pricing policy.

But this can also prove to be a difficult task. As I mentioned earlier, competition to sell may be intense between your operations. Thus, sales managers are reluctant to share any information related to revenue and margin to the rest of your internal operations. Though spurring internal competition to increase sales can be effective to a certain extent, there  are some negative side effects as a result.   For instance,  it steers the focus of your people away from customer satisfaction to focus on financial metrics. While your organizations strive to make better numbers than the rest of the company, it often leads to a communication breakdown between operations and creates an extremely difficult obstacle in the road to building a centralized “pricing think tank”.

So how can this challenge be overcome?

One approach is to change the metrics that are used to measure your company’s performance. For instance, instead of using sales, margins, or revenues to measure and reward operations and individuals within the organization, try customer satisfaction. Redirect the focus of your people to minimizing customer complaints, increasing repeat customer sales, and striving to receive positive feedback from clients. And make it a common effort across all your operations. Setting such an environment may not eliminate internal competition completely, but it will ease the tension amongst your operations.

Once you get past the obstacle of establishing your organization’s “think tank”, your next major challenge is to ensure the lines of communication remain open and a policy is established that enforces the communication of changes to any and all pricing trends through the committee. Also make sure the group establishes a procedure around how to calculate and maintain the pricing information. In establishing global policy, here are some questions your committee should answer:

• Can the pricing information be maintained through a centralized source or should it be segregated by region?   If segregated, how will communication of price changes ensure that these changes take effect across the board?
• Can pricing information and changes be formulated in some fashion?   For example, what factors determine price?   And can these factors be represented in a global calculation?
• How do exchange rates affect pricing?
• What constitutes a price change? And how often can this price change occur?
• Can an IT system be put in place to implement such a strategy?

Now I’ll be the first to admit that establishing a global pricing strategy is easier said than done. And it doesn’t happen over night. An effort of this magnitude will most likely require the need of a strong change management team. And if your company plans to utilize an information technology system to implement this strategy, they will also need individuals that have a good understanding of your business and the application. What I can say is that it is, can, and has been made possible. And in the long run this strategy will open your organization to complete visibility of your pricing policy, increased customer satisfaction, and fully realized margins.

Stay tuned for a future article that will discuss how this global pricing strategy can be implemented using Oracle Advanced Pricing.