One of the major downsides with using IR/ISO in 11i and the initial R12 releases was the change management process. Once an IR is approved it is essentially locked down and cannot be updated thereafter. Only cancelations were only allowed if the corresponding ISO was canceled. So if required dates needed to be changed on the IR, the corresponding ISO and the IR itself would have to be canceled and recreated with the proper dates. Terrible!

Additionally, changes to the ISO, which were restricted to cancelations and scheduled ship date changes, would not propagate automatically to the IR and would have to be done manually. In my opinion this was a huge gap in functionality. If cancelations or scheduled ship date changes were made to the ISO, and if the IR was not manually updated to reflect these changes, it would result in a conflicting supply/demand picture between the requesting and source organizations. In other words, the requesting organization would still see the supply quantity or required date of the IR it originally requested, while the source organization would be planning to the revised demand quantity or scheduled ship date on the ISO.

However, in 12.1 Oracle has finally provided some improvements. The “Improved Internal Requisition/Internal Order Change Management” functionality provides automated change control between the two transactions. In this release, changes made to the ISO can now be automatically applied to the IR. Better yet, the IR itself can also be modified after it has been approved, where changes are also propagated to the ISO. Workflow notifications can also be setup to notify the requesting or supplying organizations of such changes. No longer will there be a discrepancy between the IR and ISO!

Another nuisance of the IR/ISO process was that the changes to the IR or ISO could not be initiated from planning. So if planning had recommendations to change or cancel an IR, this would have to be done manually. Likewise, the ISO would also have to be manually updated to ensure both were in sync.

But in 12.1.2, Oracle has added integration between Advanced Supply Chain Planning (ASCP) and Purchasing to provide internal requisition management from the planner’s workbench. The “Release Recommendations for Internal Requisitions” functionality now allows the planner to release scheduled date and cancelations changes to the IR. This perfectly complements the change management functionality introduced in 12.1.

As a consultant who has seen the pain in implementing the IR/ISO process in the past, these are welcomed changes. I would highly recommend any customers who are in need of an integrated supply chain solution to consider these releases.

Approvals in Quoting

You may have heard of Oracle’s Approval Management (AME) module.  AME provides flexible, workflow-based approval capabilities and serves as a one-stop-shop for managing all fixed and dynamic approval hierarchies throughout Oracle EBS.

Lucky for you, the Quoting module is well integrated with AME functionality, allowing approval hierarchies to be dynamically built based on different types of transactional criteria such as operating unit, total quote amount, customer, etc.  Base approval lists can be built manually or can be associated with SQL statements to dynamically generate hierarchies based on employee data.  Quoting also provides security settings that allow skipping an approver in the hierarchy or bypassing the process entirely. 

Needless to say, the tight integration between the Quoting and AME modules provides great out-of-the-box approval functionality that is likely to meet or exceed your business requirements.

Approvals in Order Management

I wish I could say the same about Order Management (OM).  Unfortunately, there’s no out-of-the-box integration between OM and AME.  Compared to Quoting, the approval capabilities are limited and inconsistent depending on what type of transaction you’re performing. 

You’ve probably seen the Approver setups in the OM module by clicking on the “Approvals” button on the order type setup screen; however, these setups pertain only to Negotiations (OM’s version of quoting).  The configuration gives the impression that approval lists can be built for Fulfillment type transactions (orders), but Oracle hasn’t implemented these capabilities into any of the generic OM workflows.

Another setback with Approver setups in OM is that they’re assigned and dedicated to a transaction type.  This can cause issues if you have multiple facilities that each require their own set of approvers, but are under the same operating unit in Oracle and share the same set of order types.  The only work-around for this is to create a separate set of transaction types for each facility, but this can get ugly.  Additionally, the approval lists are fixed, sequential and do not provide any of the dynamic capabilities that are available in the AME module. 

It gets worse for return transactions.  The capabilities are limited to only allowing individual approvals and not approval hierarchies.  The generic return workflows in OM refer to a profile option that allows storage for only one approver.

Approval Enhancements

As you can guess, most of the enhancements I’ve designed and implemented have been to compensate for the limited approval functionality in OM.  Generally there are two approaches, each varying in complexity and produce different results.

As low-cost alternative with quick turnaround, I’ve provided enhancements to the seeded order and return workflows that incorporate the Approver setups in OM.  I say “quick” because Oracle already provides the necessary nuts and bolts to easily “plug” in the approver functionality with minimal customization.  Though the solution is low cost and quick, the functionality will still not provide all the capabilities of the AME module as I mentioned earlier.  However, this may suit your business fine depending upon your requirements.

A fancier approach I’ve taken is to integrate OM with the Approvals AME module entirely.  This way all the capabilities I spoke of earlier in the Quoting module are also made available to OM.  From a technical standpoint it’s definitely more involved than the first enhancement I mentioned, but if your business requires the flexibility, it certainly can provide a great return on investment.

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.

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!

However, as of recently, Oracle has offered a patch (5192725) which allows for the use of the credit card fields in OM without the need to install iPayment. The application of this patch alone is not enough, as there are other tweaks that need to take place to make it all work. At any rate, I take this as a great act of generosity on Oracle’s part – it’s not often they provide us the choice to implement a module!

The first step (of course) is to apply the patch. If you look up the patch in Metalink the given description is kind of hazy, but this was the patch recommended to me by Oracle. It appears to incorporate several fixes for Family Pack J. As with any patch, be sure to thoroughly test the patch first before applying to your production instance.

Next, we need to create our receipt class in AR which will classify the receipts that are generated from processing a credit card payment in OM. To do this navigate to the appropriate AR responsibility, than Setup > Receipts > Receipt Classes.

To start, let’s name our receipt class “Credit Card”, since this receipt class will be used specifically for receiving credit card prepayments. Additionally, we’ll want to specify “Automatic” to indicate this will be an automatic transaction that will be generated from OM.

As you continue entering the other key information, the most important field to note is the “Payment Type” field located under the “Automatic” tab. Prior to the introduction of this patch, we would select a type of “Credit Card” in order to enable the use of the credit card functionality with iPayment. But for our purposes, leave this field BLANK. With the application of patch 5192725, this is now the key indicator which will tell the credit card processor in OM to avoid making any calls to the iPayment module.

Once you have saved your “Credit Card” receipt class, you can continue with the remaining AR setups that are standard to any receipt class; most notably, the document sequence (which should be set to Automatic) and your receivables activity.

After completing all the AR setups, our next step is to configure Order Management to use this receivables class when initiating a credit card prepayment. We do this by setting the “OM: Payment Method For Credit Card Transactions” to the “Credit Card” receipt class. But before we do this, there is one small tweak we need to make. Prior to the introduction of this patch, this profile limited assigning receipt classes to only those which were setup with a “Payment Type” of “Credit Card”. Since our receipt class does not have a type assigned, we’ll need to change the validation behind this profile so that it allows assignment of “Credit Card” and “None” payment types.

To do this, you’ll need access to Application Developer to open the profile definition. After logging into this responsibility, navigate to NAVIGATION_PATH and query for the “OM: Payment Method For Credit Card Transactions” profile. Upon opening the responsibility, you’ll notice a SQL validation section. Copy and paste the below code into this box:

SQL=”SELECT NAME \”Receipt Method\”
, RECEIPT_METHOD_ID
INTO :VISIBLE_OPTION_VALUE
, ::PROFILE_OPTION_VALUE
FROM AR_RECEIPT_METHODS
WHERE SYSDATE >= NVL( START_DATE, SYSDATE )
AND SYSDATE <= NVL( END_DATE,SYSDATE)
AND (PAYMENT_TYPE_CODE IN (’CREDIT_CARD’,'NONE’)
OR PAYMENT_TYPE_CODE IS NULL)
”
COLUMN=”\”Receipt Method\”(50)”

Notice the above SQL opens up the restriction so that the profile will allow both “Credit Card” and “None” types of payments. After pasting the code, save your changes, and navigate to your System Administrator responsibility (if you happen to be so lucky) and set the “OM: Payment Method For Credit Card Transactions” profile to our receipt class.

Now we’re in business! Let’s test our solution…

To start, enter a sales order header with data you have handy. In the “Others” tab, the key fields to note are:

• Payment Term – make sure this is set to a term setup for prepayment. If not, revert back to your OM setups to ensure a prepayment term is established.
• Payment Type – this will be entered as “Credit Card”
• Credit Card Number
• Card Holder
• Card Expiration Date
• Approval Code – this should be the approval code issued by your 3^rd party processor upon successful confirmation of the card

Notice that when you’re entering the credit card number that it’s fully visible. Depending upon how you’ve setup the credit card number encryption, this data will save and be replaced by ‘*’’s for extra security. It’s important that you communicate to your users that before saving this information that they must perform there offline processing so that they can reference the full credit card number!

The offline credit card processor typically provides an approval code which indicates the credit card screening was successful. Enter this approval code into the “Approval Code” field. Otherwise, in the situation where the credit card has failed, you can leave this field blank and the order will be automatically placed on “Prepayment Hold” which will prevent further processing of the order until the transaction is revisited and the hold is released.

After performing the offline processing, you can than proceed with entering your order lines, again, using test data you have handy.

After completing order line entry, it’s now time to put our solution to the test! Upon booking the order, Order Management will interface a prepayment receivable in AR indicated that the sales order has been prepaid. Results of this activity can be evaluated in the Order Messages window that appears after clicking the “Book” button. If you see a message stating “Receipt number XXX has been processed”, your test was a success!

Your next step is to revert back to Accounts Receivable to verify the receipt is complete and generates the proper accounting. Aside from this validation, you’re now in the position to capture credit card information in Order Management and process offline -without the need of iPayment!