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.

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.

Step 1 – Bringing Awareness

To effectively bring awareness, the objective is to influence the business users’:

• Thinking – Helping them to understand the main objectives and the changes that may be needed to meet these objectives.
• Feelings – Associating the concept of change with positive feelings. Communicating the overall change effort as a fun and interesting project, using all influences possible to prevent users assuming change is a negative.
• Actions – Keeping people engaged and actively participating in the change effort. Though you cannot control one’s actions directly, your influence on their feelings has an impact on their actions.

Step 2 – Understanding Change and Committing

This phase deals with helping users to understand the specific changes that are coming and the reality of these changes. It’s important to enforce these changes through positive influence without causing any sharp resistance from the users. Effective listening and communication skills to ensure these changes are understood by all. During this phase, you must guide the user community through the decision making process on key business changes while setting expectations on the results and impacts of these decisions.

Step 3 – Preparation

Once the changes are defined and processes around these changes are established, business users that are impacted need preparation in the form of competency building, skill set training, and self-confidence. Through the preparation process there will be training sessions, proof of concepts, process testing, etc. This is all necessary to ensure that the business can operate in the new environment and that all details are reviewed, issues are exposed, and issues are resolved.

Step 4 – Launch

Once the business community is fully prepared and testing of the new process confirms satisfactory results, it’s time to bring the new process alive. Prior to enabling the new process, the project and user communities must be fully confident and ready for the launch and the short-term support required. As the new process lives, adaptations may be needed to address the immediate issues and process short comings.

Step 5 – Discipline and Enforcement

After brining alive the new process, the next step is to make sure the establish procedures are being followed by the user community. This is accomplished through positive recognition when a user excels at their new role while also holding users accountable by upper management when procedures are not followed. Emphasis should be placed on following the new process throughout the process transformation lifecycle.

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

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

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

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

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

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

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

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

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

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

QP_SOURCING_API_PUB.GET_PARTY_ID(OE_ORDER_PUB.G_HDR.sold_to_org_id)

QP_SOURCING_API_PUB.GET_PARTY_ID(OE_ORDER_PUB.G_LINE.sold_to_org_id)

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

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

CREATE OR REPLACE PACKAGE BODY APPS.XQP_SOURCING_API_PUB AS

FUNCTION GET_SOLD_TO_ACCOUNT_NUMBER(p_sold_to_org_id IN NUMBER)
RETURN varchar2
IS

l_sold_to_account_number varchar2(30);

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

BEGIN

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

EXCEPTION
WHEN OTHERS THEN
RETURN NULL;

END GET_SOLD_TO_ACCOUNT_NUMBER;

END XQP_SOURCING_API_PUB;

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

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

XQP_SOURCING_API_PUB.GET_SOLD_TO_ACCOUNT_NUMBER(OE_ORDER_PUB.G_HDR.sold_to_org_id)

XQP_SOURCING_API_PUB.GET_SOLD_TO_ACCOUNT_NUMBER(OE_ORDER_PUB.G_LINE.sold_to_org_id)

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

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

FUNCTION GET_SHIP_TO_ACCOUNT_NUMBER(p_ship_to_org_id IN NUMBER)
RETURN varchar2 IS

l_ship_to_account_number varchar2(30);

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

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

RETURN NULL;
END GET_SHIP_TO_ACCOUNT_NUMBER;

FUNCTION GET_INVOICE_TO_ACCOUNT_NUMBER(p_invoice_to_org_id IN NUMBER)
RETURN varchar2
IS

l_invoice_to_account_number varchar2(30);

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

EXCEPTION WHEN OTHERS THEN

RETURN NULL;

END GET_INVOICE_TO_ACCOUNT_NUMBER;

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

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

SCHQP_SOURCING_API_PUB.GET_SHIP_TO_ACCOUNT_NUMBER(OE_ORDER_PUB.G_HDR.ship_to_org_id)

SCHQP_SOURCING_API_PUB.GET_SHIP_TO_ACCOUNT_NUMBER(OE_ORDER_PUB.G_LINE.ship_to_org_id)

SCHQP_SOURCING_API_PUB.GET_INVOICE_TO_ACCOUNT_NUMBER(OE_ORDER_PUB.G_HDR.invoice_to_org_id)

SCHQP_SOURCING_API_PUB.GET_INVOICE_TO_ACCOUNT_NUMBER(OE_ORDER_PUB.G_LINE.invoice_to_org_id)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

QP_SOURCING_API_PUB.GET_PARTY_ID(OE_ORDER_PUB.G_HDR.sold_to_org_id)

QP_SOURCING_API_PUB.GET_PARTY_ID(OE_ORDER_PUB.G_LINE.sold_to_org_id)

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

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

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

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

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

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

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

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

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

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

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

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

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

OE_ORDER_PUB.G_HDR.attribute10

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

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

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

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

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

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

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

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

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

But doing this isn’t as simple as saying good bye to your consultants once process design is complete. Extra steps must be taken by project management to ensure that your internal IT staff are connected and engaged throughout gap analysis, requirements gathering, and process design. If your IT organization is to “take the ball and run”, it’s extremely important that they understand the design and can speak for it long after the consultants have left.

In addition to keeping your resources engaged, they must also be trained or have the experience necessary in carrying out the implementation. An investment in training will better prepare your staff for the implementation activities, while also leading to decreased consulting costs further along the project timeline (not to mention minimizing needs for consulting in future projects). So be ready to supplement some of your cost savings in consulting with additional funding towards training.

Also be ready to conduct a focused knowledge transfer session once gap analysis and process design is complete. It’s obvious that your internal resources will need all the knowledge and know-how to implement the solutions proposed by your outside consultants, so it’s important to execute a formal knowledge transfer session that involves transition of all documentation and related materials. Project metrics should be established that measures the progress and success of the knowledge transfer activities.

By following all these points, you place your IT organization in a position to implement your ERP system independently without extensive involvement of any outside consulting. Keep in mind that while this approach will most definitely minimize the need for any consulting involvement during implementation, it doesn’t eliminate the need. Therefore, it’s important to have a go forward plan established the keeps the lines of communication open between your IT organization and the consultants.

Outsourcing design and insourcing implementation efforts is a model that many businesses, and even some consulting organizations, have embraced. Lexerd Group, an IT consulting firm based in the east coast United States, is one of the first to offer services that are centered on the “outsourcing/insourcing” model. Lexerd Group’s Proof of Concept service offers their clients software expertise, requirements gathering, gap analysis, and solution design, followed by a specialized transition session which transfers process blueprints and a go-forward implementation strategy to their clients.

Read more about Lexerd Group’s unique Proof of Concept consulting services at http://www.lexerdgroup.com/proof-of-concept.

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.