The previous way of setting organization context in 11i was to execute the following statement:

dbms_application_info.set_client_info(ORG_ID);

However, in R12, the new way of setting the organization context is as follows:

mo_global.init(’AR’);
mo_global.set_policy_context(’S',ORG_ID);

The ‘S’ parameter indicates a single organization context. Replace ORG_ID with the ID of the operating unit you wish to use. You can also set a context for multiple operating units by setting the security profile. This is done by executing the following statement:

mo_global.set_org_access(NULL,SECURITY_PROFILE_ID,’ASO’);

Replace SECURITY_PROFILE_ID with the ID of the appropriate security profile.  ‘ASO’ represents the application short name associated with the responsibility you’ll be using.

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.

Multiple Operating Unit Access – In 11i, a responsibility could only be tied to a single operating unit. However, in R12, responsibilities can be assigned to one or more operating units by assigning the responsibility to a security profile. This is a great enhancement for businesses where users require multi-organization access.

Credit Card Entry Enhancements - An additional field has been added to the order entry screen to capture the security code typically located on the back of a credit card. Additionally, the credit card number is encrypted at the database level and stored within the Payments (formally iPayments) module. I’ll put out a more detailed article that talks about the drastic changes to the iPayments module.

Reoccurring Charges - Functionality has been added to the TSO (Telecommunications Service Ordering) module which allows reoccurring billings. This is perfect for subscriptions and other like services.

Partial Period Revenue Recognition – A joint OM and AR enhancement, partial period revenue recognition is a set of new revenue recognition rules in AR which allow for revenue recognition on a daily basis. Previously in 11i revenue recognition could only be done on a monthly basis.

Pay Now or Pay Later – Upfront billing in Order Management can now be done and can be configured based on pricing charges, taxes, deposits, installment billing, and prepayments.

Mass Scheduling Changes – The scheduling concurrent request can now pick up lines that have errored in the scheduling workflow activity. It also can now pick up lines that are in Entered status – both converted and manually entered orders.

Customer Acceptance Process - Oracle R12 now provides the ability to introduce a customer acceptance step prior to invoicing. By setting up a deferral reason in AR, invoicing can be deferred until acceptance has been captured.

Tax Updates – Additional tax fields have been added to the order entry screens that provide more flexibility with Vertex.

Architectural Changes to Inventory - in 11i, Discrete and Process Inventory modules were entirely separate entities. Oracle has converged these modules into one data structure, where functionalities from both modules have combined to be available to both. This doesn’t mean much from an OM perspective, but technical changes have been performed to the Pick Release and Ship Confirmation processes to work with the new combined inventory model.

Architectural Changes to OM, Install Base, and Service Contracts Integration – My understanding is that there is no functionality changes, but from a technical standpoint Oracle has implemented a best practice approach  to OM to Install Base and OM to Service Contracts touchpoints to ensure API calls are used rather than direct queries.

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.

For corporations which conduct sales in the U.S. and in other locations across the world, the complexity increases because every country has their own set of embargo laws. For example, a U.S. based company cannot sell to an Iranian company because of U.S. regulation, but on the other hand, if the same organization has a location or distribution warehouse in France, their French location could sell to that same Iranian customer. Granted, this situation is also dependent on the citizenship of the individual conducting the sale – an employee sitting at a desk in France can’t make the same sale to Iran if they hold U.S. citizenship.

By now I think you get the point – keeping track and enforcing export compliance procedures can be quite complex. If your business operates an international sales organization and has difficulty enforcing and adapting to the ever changing embargo regulations at a global level, then the Oracle Export Compliance module, in conjunction with Kewill export compliance screening, can provide just the tools you need to ensure your sales organization remains compliant.

A Brief Look at the Technology

Out of the box, Oracle provides a workflow process in Order Management that establishes an XML based connection to a selected 3^rd party compliance screening service. Kewill, a commonly used screening service in the Oracle community, maintains an elaborate database of the latest export compliance regulations. Upon entering and booking a sales order, Oracle sends various information about the sale order transaction to Kewill, who then accepts and evaluates the sale based on the most current and up-to-date export compliance laws.

Once Kewill determines whether or not the sale is compliant, the results are sent back to Oracle Order Management. If the result is found to violate export compliance laws, the sales order goes on export compliance violation hold and awaits review by an individual in the organization who is given the property authority to either process the order or cancel the sale.

Additionally screening can be performed during the pick release and shipment confirmation processes to ensure that changes that are made to a sales order after booking are also captured and screened prior to sending the product out the door.

The technology around the communication between Oracle and Kewill services is fairly straightforward, but the actual screening performed by Kewill can be quite complex. As I mentioned earlier, international embargo laws vary country, so to deem a transaction compliant there are many pieces of information to consider. What country is the customer located? Do the billing and shipping locations for the customer differ? Or is the billing customer entirely different than the shipping customer?

What about your facilities – is the location of your shipping warehouse different than the location from where the order is being processed? Does the citizenship of the individual entering the transaction qualify to make the sale?

As you can see, the situation can get quite complex. How these questions are answered determines the set of export compliance laws that need to be evaluated. Lucky for you, Oracle Export Compliance and Kewill takes care of this complexity for you.

For more information regarding the Oracle Export Compliance product visit http://www.oracle.com/products/export/index.html.

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.

For starters, you must evaluate the skills and expertise that is required from the technical resources that are needed. Generally speaking, most offshore developers I’ve worked with have an outstanding technical background. They know and understand database architecture, coding standards and syntax, and have an expertise in the many software tools that are necessary to get the job done. Irrespective of citizenship or other factors, these skill sets alone are great for development work on small, independent software systems where there are minimal dependencies. Some examples of an independent software environment could be:

• A small to mid-size business running a custom-built, homegrown system.
• A standalone software system used to collect and report on transactions specific to a department and/or sub-division.

If your software system fits this profile, than an offshore resource could most certainly meet your needs.

Where additional precaution is needed is in the implementation of a company-wide ERP system. When doing any kind of customizing to an enterprise software application, it’s critical that the technical resources you seek not only have sound technical skill sets, but also a strong functional understanding of the application. The technical resource at minimum should know:

• How the application module was designed to work out-of-the-box.
• The inter-dependencies of the modules. In other words, how a particular module fits into the entire application framework.
• The adverse affects of changing module design based on these inter-dependencies.

Now I’m willing to admit that it’s unrealistic to expect a technical guru to write complex code all while he or she is reciting the user documentation, but general functional knowledge is a definite requirement to ensure that you’re project staff and offshore resources can communicate on the same wavelength.

I’ve observed that the services provided by an offshore outfit are usually sound from a technical standpoint. However, from a functional standpoint, the level of expertise is up for debate. When first introduced to the model, many experts (including myself) had the expectation that the technical resources provided would have some degree of functional knowledge of the respective system. This expectation often led to a major misunderstanding of what an offshore outfit is able to offer. What was thought to be a team of techno-functional resources turned out to be a team of highly skilled coders with less than desirable knowledge of the application.

Anyone who has worked in the ERP world knows that communication is key to running an effective software implementation project. If this line of communication breaks, a rippling effect is sent throughout the entire team – placing the quality of work and the success of the project at risk. If the project staff and the outsourcing group do not have the same collective understanding of the functional requirements, a severe breakdown in communication between these groups occurs and results in technical objects not being delivered according to the communicated (or understood) specification. I like to call this the Techno-Functional Gap, and without a doubt, it is the main reason why the outsourcing model has failed.

Before making the decision to go offshore, it’s extremely import to consider how the techno-functional gap will be bridged among your project staff and the offshore resources. Ultimately what you want to avoid is a purely functional consultant with no technical background writing design specifications for an offshore programmer without any functional knowledge of the application. Both resources may have their respective strengths, but if a common understanding cannot be met, there’s an increased risk of the requirements being poorly communicated by your staff or misunderstood by the outsourcing group.

An easy way to measure this risk is to first evaluate the skill sets of your current staff. Depending on how weak or strong the technical background of your staff is determines the kind of functional background that’s needed from your offshore resources. By building a skill set matrix which rates your staff’s functional and technical strengths, your organizational needs become more clear. So for example:

In the above chart I took two example project resources: one from the sales team and one from the finance team. I then attempted to rate each of their functional and technical skill sets on a scale of 1 to 10, where 10 indicates strong knowledge and 1 represents little to none.

Looking at this chart, we see our finance resource has a very strong functional background with above-average technical skills. Therefore, we may be able to settle for an offshore resource with minimal functional skill sets. On the other hand, we see that our sales consultant has a strong functional background, but has no technical experience. With no technical background, we must be cautious in our choice of offshore developers to pair up with our sales resource. For this resource, it would be wise to find a developer that has average to strong functional knowledge of the system.

This is a very basic example, but it shows how effective this technique can be in ensuring that the project staff is paired up with the appropriate outsourcing resources.

For complicated or critical custom components that will be vital to your business process, I would suggest pairing up resources that have overlapping techno-functional skills. Matching resources with overlapping skill sets will ensure a seamless communication of requirements and effective coordination in testing the complexities of the customization. Simply put, for high-risk technical objects, it’s better to over-communicate than to under-communicate.

In addition to skill set pairing, I would also make sure that a collaborative work environment is put in place so that the project team and outsourcing groups can seamlessly share, distribute, and organize project deliverables amongst each other.

In the past, I’ve seen many clients allow the outsourcing partner to take full responsibility in managing and versioning all deliverables, from documentation to technical objects, as way a way to reduce overhead and take advantage of the cost effective labor. However, like the skill set gap, the collaboration gap creates another disconnect between the developers and the project staff. This led to the internal team having several issues with:

Assessing documentation and other deliverables.  

• Identifying the state of the test environments and knowing which instance had the code ready for testing.
• Identifying code versions and knowing which version of the code they were testing.

These uncertainties usually led to the project team managing their own versions of the documentation and code. Then, as you would suspect, this led to confusion among both groups as to who had the latest version.

Remember, having an offshore group isn’t just about assigning technical development to a separate group sitting at a 14 hour plan ride away; it’s about assigning the project team and the outsourcing group joint responsibility to meet the requirements outlined by the business. It’s a collaborative effort – and being this is a collaborative effort, it’s important to provide the work environment necessary for both groups to work as a single, integrated unit.

It’s important to ensure that some kind of tool or shared network space is in place so that all information associated with the offshore efforts is easily accessible to your staff and the outsourcing partner. There are many tools out there to help streamline the collaborative process. From my past experience, Microsoft SharePoint has proven to be a great tool that allows you to organize your deliverables by team, milestone, etc. through an easy to use web interface. The application allows you to grant access to members of the project so that documents are controlled both from a rights and versioning standpoint. Now I’m only using SharePoint as an example and I’m not trying to sell you the application. However, whatever tool you choose to implement, it’s important that everyone from the team has access to this collaborative workspace and follows all organizational and versioning policies instituted within the team.

So far I’ve discussed the importance of establishing open communication and a collaborative work environment between your staff and the outsourcing partner to minimize the immediate risks, which are misinterpreted requirements and poorly designed custom objects leading to failures within the project and exposed risks to the business if implemented. But in addition to the immediate risks, the long term (or post project) risks also need to be evaluated. Remember, in most cases, the point of bringing on an outsourcing partner is to utilize their resources for the short-term. Once the implementation project is completed, the idea is to relieve the offshore resources and allow your internal project staff to continue supporting the system.

However, if clear communication and group collaboration is not in place, then you may want to extend that contract with your outsourcing partner for much longer than you originally anticipated. If you’re internal staff is not up-to-speed with the work performed by the offshore team, than your group will not be able to effectively support any customizations to the system without the involvement of the outsourcing partner. Too many times in my career have I seen outsourcing contracts extended not because delays to the project schedule, but because the client was not prepared to take on the responsibilities of supporting and maintaining the system.

So in addition to communication and collaboration, a knowledge transfer plan needs to be in place to ensure that your staff is given the information and tools necessary to continue supporting the work delivered by your offshore resources. Do not make this effort secondary to all other activities that may appear to take higher priority. This should be a dedicated phase within your project schedule and should be accounted for in the budget. The less time you set aside for knowledge transfer, the more time you will most likely need to sign up for offshore support. Also keep in mind that the more integrated your project team and the outsourcing partner become, the less time it should take to transfer knowledge. On the flip side, if the work of the outsourcing group was performed independently with no interaction with your staff, then knowledge transfer will most likely be a nightmare.

Like anything in business, it’s not just about cutting costs, but being able to cut costs without sacrificing the quality of work or exposing your organization to potential risk. Outsourcing can be a working, efficient component of your ERP project team so long as the appropriate offshore resources are paired with your staff, the lines of communication are open, and an environment is provided to promote group collaboration. When evaluating your offshore options, make sure to take all these factors into consideration. You may find that the cost risk or the overhead in building an integrated environment may far exceed hiring some permanent hands. Most importantly, it’s important that your IT organization practices what you preach. In other words, do not expect to bring your business into an integrated EPR system environment if your project organization cannot operate as an integrated entity itself.

Perhaps, but before you go down this path there is another factor that should be taken into consideration: ensuring the order fulfillment process as a whole remains seamless and intact. What is the impact to the order entry, scheduling, pick release, on-hand availability and reservation processes if an interface is built to an outside WMS? The answer to this question is especially important in a high-volume environment where your organization fulfills hundreds to thousands of orders a day.

Generally, when an interface between Oracle (or any order processing system for that matter) and a Legacy WMS is built, a division of duties is established. Oracle is given the responsibility to capture orders and release these orders for shipment when ready. The Legacy WMS system is responsible for accepting shipment requests, processing these shipments, and sending the results of the shipment back to Oracle. Essentially, the Pick Release process in Oracle is the “throw” to Legacy WMS, and the Ship Confirmation step is the “catch”.

Since the nature of both system’s responsibilities require access to inventory data, your organization must understand that not only are you building a shipping interface, but you are committing to maintain two sets of inventory data that may require several interfaces. Oracle will need access to on-hand balance and reservation information so that order processors have insight to product availability and so that the system knows what orders are eligible for shipment. The Legacy WMS will of course require inventory data to maintain on-hand balance and deduct balances upon shipment. Oracle inventory data, to a degree, will need to be in synch with inventory data in Legacy.

To what degree must be decided. Your organization may determine that both sets of inventory do not require real-time synchronization. For example, you may decide that manual adjustments made to inventory in Legacy may only need to be interfaced through a daily polling process that posts these updates to Oracle. If this direction is taken, then you will need to decide how your shipping interface will handle exceptions that may result from an on-hand balance delta between Oracle and Legacy inventory.

How can an inventory delta occur? Well, let’s say at the time we place an order for an item in Oracle there is 1 quantity available for reservation. However, during the day a warehouse worker reviews the item and determines that it fails to meet quality standards and as a result he/she performs a manual transaction in the Legacy WMS to issue that quantity to scrap. Because Oracle is unaware that this transaction occurred, the interface will continue to release the ordered item for shipment – even though there isn’t enough quantity on-hand in Legacy.

In this situation, you will need to ensure that this situation (among many others) can be handled by the interface. From a business prospective, a decision needs to be made to determine how exactly this delta should be handled. For example, you may want to leave the interfaced transaction in an error status and continue to retry until inventory is made available. Or you may want to cancel the transaction entirely. Whatever that action may be, it’s important that there is visibility to these kinds of inventory deltas.

If your organization decides that Oracle inventory and Legacy inventory requires real-time synchronization, your interface will still need the ability to handle situations that result in inventory deltas. Let’s face it – we’re all human. Any level of time and effort that is put into a real-time interface could still result in situations unaccounted for. And as best practice, an error handling procedure should still be implemented, especially in an environment where you require real-time synchronization.

Attempting to identify all scenarios that require a communication between Oracle and the Legacy WMS can get pretty crazy. Here are some examples of scenarios that would need to be included:

• Order cancelations in Oracle
• Shipment cancelations in Legacy
• Manual inventory transactions in either system
• Inventory location transfers, but this is only important if your organization is utilizing hard reservations at order time, which in this case you should seriously rethink using an interface.
  
• Split and partial shipment scenarios

We could go on and on with the list of scenarios to cover – these are just a small fraction of what can occur. And as I mentioned, even if you think you’ve listed all scenarios, you still need an error resolution process.

I can’t stress more the importance of error resolution in the event of an inventory delta. Whether it’s an automated or manual solution is not important, but the most important point is making sure that if an unidentified inventory delta situation occurs that the interface can be capture and handle this error. At minimum, if the error cannot be handled, at least provide the tools necessary to bring visibility to the situation. Trust me – there is nothing worse than going live with an interface and experiencing errors that were unaccounted for.

This all may come off as something you probably learned in a beginner’s course for software design, but I’ve seen and witnessed the aftereffects of an unsuccessful inventory interface launch with some very reputable clients. What results is the very situation that the client wanted to avoid in the first place – a chaotic situation that requires the involvement of lots of time and resources that the organization did not budget for but has no choice to deploy in order to fix an interface that is the backbone of their business.

Some brief examples I’d like to share…

Example #1

Working with a life sciences client to implement Oracle Order Management a few years back, the organization decided to keep their existing mainframe inventory system with the idea of avoiding risk and cutting costs. The consulting group at the time recommended against this decision, but the client continued on and even decided to take on the effort using internal resources.

In a nutshell, the core exchange of the interface was centered on the Pick Release and Ship Confirmation processes. Testing was lackluster and didn’t cover all scenarios such as partial line shipments or order cancelations. More importantly, there lacked a substantial volume test.

What resulted at go-live was a disaster. Because of the bugs around partial line shipping, some orders were shipped two, three, and occasionally four times over. It took a team of 10-12 people during go-live to identify the dozen situations that were causing the Pick Release failures and shipping issues. Overall, it had taken a year+ to stabilize the situation and resulted in an exceeded IT budget and sales losses to the client. A team still exists today in maintaining and monitoring this interface.

Example #2

A publishing organization implementing Oracle decided to build an interface to their existing warehouse system. Aside from its age, this system was a beta version of the vendor’s product. It was heavily customized and interfaced to dozens of other order processing systems already. Cost and risk were definitely a factor.

Results at go-live were also poor. Multiple or no shipments were occurring. Since shipment sets in Oracle were not in synch with the activity that occurred in the legacy system, it caused many issues. An extensive amount of resources were needed to help stabilize the situation. Over time, the client became limited to the amount of functionality that could be used in Oracle. For example, for an order that had several shipping locations, separate orders had to be created for each shipment vs. establishing different shipping addresses at the order line level.

Additionally, the client implemented a daily process that “synchronizes” the Oracle on-hand balances with Legacy on-hand balances if a delta occurs (scary). Overall, it has taken nearly 2 years to stabilize the situation and currently has resources dedicated to the effort today.

As you can see, clients typically downplay the risk exposed to the rest of the fulfillment process when implementing an inventory interface to “protect” the shipping operation. Even worse, these organizations had made the decision to keep the legacy WMS because it was determined that the implementation effort in replacing the system was to costly compared to building the interface. Looking at this short-term, this may be true. But like most system interface projects, the cost of maintaining such a beast can greatly exceed the cost of implementing a new WMS over time (at least based on my experience).

If you’re an organization that is the process of deciding upon an inventory and shipment interface or a new WMS, I hope you can take the above situations into consideration. In going with the direction of an interface, you must also take into account:

• Increased Go-Live Risk – In case the situation gets ugly, you’ll need extra time and resources to correct and stabilize the situation. Also will need to factor in any impact to the business and sales it may cause.
• A New Department - The interface itself will be a unique process that will require several individuals who understand and are familiar with the process and include expertise in both the Oracle and Legacy inventory systems.
• Difficulty or Inability to Upgrade/Change - Being that the interface will be a delicate process requiring much involvement from both systems at a technical level, any changes to the table structure on the Oracle side as a result of an upgrade or customization could result in breaking this interface. Likewise, any changes done to the legacy side could also adversely affect this interface. With that said, expect all upgrade efforts to your system to exponentially increase.

My position should be pretty clear from all my ranting – DON’T DO IT! Or at least if you do, thoroughly evaluate the alternative of implementing a new WMS. Hopefully through the experiences I’ve shared, you’ll find that both options are exposed to the same level risk, but that the long term cost benefits of implementing a new WMS will prevail.

However, after a few more hours of searching, I was able to find a good, fairly working example on Metalink note 292743.1.   While this example was presented to show how to create an RMA order header using OE_Order_PUB.Process_Order, the script can be easily modified to create orders of all types simply by choosing an order type ID that is of type ORDER or RETURN depending on your requirement.  

Additionally, to create a sales order header, at minimum you’ll need to specify a customer, price list, currency and any required descriptive flexfield values dictated by your setups.   You may also need a customer purchase order number if you’re order type has been setup to require it before booking.   The code excerpt below shows this information along with other required data that is needed to produce an order header:

l_header_rec.operation := OE_GLOBALS.G_OPR_CREATE;
l_header_rec.order_type_id := 100000;
l_header_rec.sold_to_org_id := 1000;
l_header_rec.price_list_id := 100;
l_header_rec.pricing_date := SYSDATE;
l_header_rec.transactional_curr_code := ‘USD’;
l_header_rec.flow_status_code:=’ENTERED’;
l_header_rec.cust_po_number := ‘123′;
l_header_rec.attribute1   := ‘ABC’;

The script also doesn’t create any order lines, so this code would also have to be added.   All that the OE_Order_PUB.Process_Order API needs to create an order line is an ordered item, quantity, and any required descriptive flexfield values that may be needed.

l_line_tbl(1).inventory_item_id := 201775;
l_line_tbl(1).ordered_quantity := 1;
l_line_tbl(1).attribute1 := ‘ABC’;

At the beginning of the script you will also need to add an API call to dbms_application_info.set_client_info to set the organization context as well as initializing the user, responsibility, and application under which the order(s) will be created.

dbms_application_info.set_client_info(100000);
…
fnd_global.apps_initialize(l_user, l_resp, l_appl);

Since I want this script to create not just one order, but many orders, I needed to insert a loop into the script with parameters that let me control how many orders to create, and whether to enable or disable debug.   For good performance and to avoid exceeding any buffer limitations, a debug “switch” is a good things to have, especially when creating hundreds or even thousands of sales orders.    

l_debug_level number := 0;   — OM DEBUG LEVEL (MAX 5)
l_no_orders number := 100;       — NO OF ORDERS
…
for i in 1..l_no_orders loop — BEGIN LOOP
…
if (l_debug_level > 0) then
      DBMS_OUTPUT.PUT_LINE (’debug message here’);
end if;
…
end loop; — END LOOP

With these modifications in place, I now have a working script that will create a mass amount of sales orders for the volume test I need.   I hope this comes in handy for you!

What good is a new laptop if I can’t use the tools to do my job!

Fortunately, after hours of tweaking, I was able to narrow down the root cause to two main issues:

Internet Explorer 7 Quick Tabs Conflict

The new Quick Tabs introduced in IE 7 do not play well with many Java-based applications – one of them being JInitiator. After my IE sessions continued to crash, I began randomly playing with the IE view settings and found that disabling the Quick Tabs bar solved the problem. To disable Quick Tabs, open an Internet Explorer 7 session and navigate to View > Quick Tabs.

After disabling Quick Tabs, close your browser session and start a new one. Assuming this is your only software conflict, this should do the trick. Unless…

ThinkPad Security Solution Conflict

Lenovo offers the ThinkVantage Productivity Center with all their notebooks. One of the neat features of the Productivity Center is the Client Security Solution. Not only does this solution allow you to store passwords to all your applications and websites safely and securely, but it auto-logs into the apps for you too. Couple this with the new finger print reader and you have an amazingly effective, yet secure, password manager.

Unfortunately, an IE 7 add-on that the Client Security Solution uses to capture and store Internet based login information conflicts with JInitiator. The only apparent fix for this is to disable the Password Manager feature of the Client Security Solution entirely.

To do this, click the big blue ThinkVantage button on your notebook – the Productivity Center menu will appear.

Next, hover over ThinkVantage Technologies, then select Client Security Solution – the solution menu window will appear. Click the Password Manager and you should see a screen like this:

Clicking the “Disable” button will shutdown the manager.

Next, we need to disable the IE 7 add-ons that were installed by the Client Security Solution. To do this, open an IE 7 session and navigate to Tools > Manage Add-ons > Enable or Disable Add-ons. The Manage Add-ons window will appear.

In the manager you will notice two Lenovo-based add-ons:

• CPwmIEBrowserHelper Object
• ThinkVantage Password Manager

Select each of these add-ons and click the “Disable” radio button below so that both add-ons show up under the “Disabled” list as such:

Once you’ve finished, click OK, close all of your applications, and restart your notebook. After you log back into Windows, open an Internet Explorer session and try logging back into Oracle Apps. Again, assuming there are no other software conflicts with JInitiator, this should do the trick.

It’s unfortunate that all the features of IE 7 and ThinkVantage can’t be fully utilized, but like all initial software release, these kind of bugs usually happen and eventually get resolved through patches, upgrades, etc. Maybe Windows, Oracle and IBM can collectively provide a fix so that all three applications can play nicely together.

Did I just write that?