Integration with other Applications

Publishing Plan Results to Order Management Overview

Advanced Supply Chain Planning (ASCP) can make planning recommendations based on the latest supply / demand picture. With ASCP, these recommendations can be published to Order Management, automatically updating the sales order line(s).

These scheduling attributes can be updated by ASCP:

Order Management provides the following three ways to firm a line. Once the line is firmed, the warehouse cannot be changed by planning output.

Based on the Event

Order Management provides a scheduling parameter for this requirement. A value set containing Schedule, Shipping Interfaced, and None is in this parameter. Based on the requirement, a customer can select the appropriate value for this parameter. The values are:

Schedule: Lines will be firmed once they are scheduled. APS will not be able to make updates to the warehouse after the line is scheduled.

Shipping Interfaced: APS is not allowed to update the warehouse once lines are interfaced to shipping. Lines are firmed one they are interfaced to shipping.

None/Null: APS is not allowed to update the warehouse on the line until it is shipped, closed, fulfilled, or cancelled.

Through the Workflow Block

The purpose of the Wait to Firm - Line process is to hold lines, until they are progressed. During the progress, lines are firmed. A customer can customize their line flow and place this sub process anywhere in the flow based on their need. Lines reaching this sub process will wait till they are progressed by user/system. You can manually progress the lines to continue their process. When the line is progressed, the system will firm the lines and progress to next activity/process. You can also schedule a concurrent program, Progress from Firm Process, to progress the lines.

Wait to Firm - Line

Firm using the Sales Orders Window

Notification

Automatic notifications are sent when a planner changes the dates on the scheduled lines. Using manual notification functionality on the Sales Orders window, Actions > Notifications, you can send manual notifications

Progress from Firm Process Concurrent Program

Order Management provides a concurrent program to progress the lines that are waiting at this sub process. You can schedule this program periodically to progress lines that are waiting at this sub process.

User Procedures

To firm the eligible line using the Sales Orders window:

  1. Navigate to the Sales Orders window.
  2. Enter a line to schedule.
  3. Go to the Shipping tab and check the Firm check box.
  4. Save your work. Note: If you try to firm a non-eligible line for example a return or service external line, you will receive an error message that the line cannot be firmed.

To un-firm the firmed line using the Sales Orders window:

  1. Navigate to the Sales Orders window.
  2. Enter a line to schedule.
  3. Go to the Shipping tab and check the Firm check box to firm the line.
  4. Save the changes.
  5. Uncheck the Firm check box. The line is un-firmed. If you are using a seeded subprocess, Wait to Firm Line, in workflow, you can progress the line from that status in one of two ways: Manually from the Sales Orders window, select Actions > Progress Order. Run the concurrent program, Progress from Firm Process. Note: You cannot unfirm a shipped, canceled, closed, or fulfilled line.

Global Order Promising for ATO Configurations

ATO Models are now enabled with global availability so that entering a source organization is not mandatory.

Global Order Promising (GOP) currently does not automatically select a warehouse based on sourcing rules for an ATO model as it does for standard items. The warehouse must be specified for the ATO Model before scheduling it. This is done so that CTO can provide the mandatory components for ATP based on the specific Bills of Material (BOM) in that organization.

This new functionality will enable you to order an ATO model without specifying a warehouse, regardless of whether the system uses ODS or PDS. In addition, if there is a match for the configured item and if using Planning Data Store (PDS), the system will use the match at the time of scheduling. The new Match functionality is not provided for Operational Data Store (ODS).

Note: The Global Forecasting enhancement is a prerequisite.

Global Order Promising for ATO Configurations Major Features

Net Existing Inventory of Configured Assemblies

With a fully licensed version of planning and PDS, ASCP and GOP can recognize and net existing supply for configured parts that has a BOM that is equivalent to the model and options being ordered. The Match functionality is based on the configured item. Configured items are created as before, either manually or by using a concurrent program.

When scheduling an order for a model and options, GOP matches for existing configurations inventory prior to the ATP call. If a match is found, the promised availability considers the matched configuration supply in addition to building the model and options. Once the configuration is linked to the sales order line, ATP promises availability based on the configuration instead of the model and options (if the date for the configuration is better than that for the model and options).

Formerly, if users were using predefined configurations, they could not promise an accurate delivery to their customers. Now they can check to see if there is any on hand or on order for a match that is not consumed by other orders before checking the availability of making a new item. ATP considers existing reservations in this process.

Note: The Match functionality is available with PDS, but not with ODS.

Allow Multiple Sources for an ATO Model, GOP Determines the Best Source During Scheduling

For both PDS (Planning Data Store) and ODS (Operation Data Store), GOP can determine the best source (customer specific) for an ATO Model based on internal and external capacity in Oracle ASCP. GOP can determine the best source if the warehouse is not specified.

Splitting of the ATO Model, Beyond Configuration Creation

The seeded constraint for not allowing an ATO model split once the configuration is created has been changed to enable this, since CTO can create a configuration item before booking.

Allow the Change of Warehouse on a Scheduled ATO Model

The seeded constraint to restrict the change of warehouse on an ATO model has been converted from a seeded constraint to non-seeded constraint.

Allow an Unscheduling Operation on an ATO Model, beyond the Configuration Creation

The constraint for not allowing the unscheduling of an ATO model once the configuration item is created, is no longer mandatory.

ATP Check Display Changes

If an Availability check is made on the ATO Model, Order Management will display only the ATO Model and not its child lines. Child line details can be seen by navigating to ATP Details window.

Similarly, if the ATO Model is part of a set, all the lines from that set except ATO child lines are displayed.

Enable Configuration Actions Before Booking the Order

Once the GOP for ATO Model is installed, you can link the configuration item after scheduling, making following actions available once the ATO model is scheduled:

Push Group Changes for Models

Push group logic will be implemented for the ATO Models once GOP for the ATO Model is implemented. If the ATO Model is added to an existing set, the system sends the complete ATO Model to ATP for the set date. If the scheduling succeeds, the ATO Model is placed into the set. If not, based on the push group date value, the complete set is pushed for the next available date or fails the request to add the ATO Model to the set.

If a new option is added to the ATO Model, that is already in the set, it re-schedules the complete ATO model for the set date and based on the results, will either push the complete set for the new date or fail the addition based on the push group profile value.

User Procedures

Note: Note: Set the profile option for BOM: Match Existing Configurations to Yes if you are using PDS. Without setting this profile, there will be no difference in functionality between ODS and PDS.

PDS or Planning Data Store: Represents all the information within Oracle ASCP which encompasses those in the ODS and other output tables from planning. PDS based ATP implies ATP based on planning output.

ODS or Operation Data Store: Represents all the information that acts as destination for the collected data from each of the data sources (both Oracle Applications or legacy systems). This acts as the input for the snapshot portion of the planning process. ODS based ATP implies ATP based on collected data.

To perform availability using multiple sources for ATO Models:

  1. Navigate to the Sales Orders window.
  2. Create a sales order.
  3. Configure an ATO Model without a warehouse.
  4. Make sure the sourcing rules have been specified in APS.
  5. Check the availability for the ATO Model.
  6. The system will provide the availability details from multiple sources, either before or after there is a configured item. If using PDS and if the item is ATPable, the Availability picture will take into account any existing matches.

To provide a warehouse for an ATO Model based on the sourcing rules:

  1. Navigate to the Sales Orders window.
  2. Create a sales order.
  3. Configure an ATO Model without a warehouse.
  4. Make sure the sourcing rules have been specified in APS.
  5. Schedule an ATO Model, either with or without the configured item.
  6. The warehouse is derived based on the planned output and sourcing rules.

Inbound Purchase Order Changes

The inbound purchase order change transaction is an electronic data interchange transaction supported by Order Management and Oracle e-Commerce Gateway.

Oracle e-Commerce Gateway reads a transaction interface data file from the translator and writes the data into Order Management's Open Interface tables for processing by the Order Import program. Order Import validates the data and populates the Order Management tables with validated data. The validation is based on the same business rules applied to the data as if entered interactively and then imported into the system.

The following flows are followed to process a change request in Order Management:

Change Sequence

You can control the sequence of processing of multiple changes to a line such as, if you have multiple Oracle e-Commerce Gateway headers changing one order line. You control the sequence of processing the Oracle e-Commerce Gateway lines by specifying values in a column called CHANGE_SEQUENCE. These lines will be processed in the ascending value of the change sequence numbers.

Once a change is applied, Oracle e-Commerce Gateway updates the sequence number in the base tables against the appropriate order and line number. Any future Oracle e-Commerce Gateway processing compares incoming change sequence numbers against this sequence number to determine the process. The change sequence number in the base tables indicates the last change sequence number that was applied to an order or line.

Similarly, the change sequence number in the base order line table indicates the last change sequence number that was applied to that line of an order.

Different lines may have different change sequence numbers since a change sequence may or may not apply to all the lines of an order. But the change sequence number at the order header level will always be the latest change sequence that was applied to an order or any of its lines. At any point in time, the change sequence at any line of an order cannot be greater than the change sequence at the order header.

If an error is encountered while processing changes for any of the lines in a change sequence, the entire change sequence will not process. Either all the changes under a change sequence are processed or none.

The change sequence numbers must be ascending. You can force processing of out of sequence change request by setting OE_HEADERS_ INTERFACE.FORCE_APPLY_FLAG to Yes. The default value is No.

For example, if the base order header table has a change sequence number of 5, the last change sequence that was applied to the order was 5. The following table describes how different actions are performed for obtaining different change sequences:

Change Sequences Example
Change Sequence Number Force
Apply Flag
Ready
FLag
Action by Oracle e-Commerce Gateway
4 N Y Error. The change sequence number 4 is less than the change sequence number in the master table 5.
6 N Y Processes
8 N Y Error. Waits for transaction with the change sequence number 7.
8 Y Y Processes since Force Apply Flag is set to Yes.

Change Request Types

For header level changes, a full order cancellation can be performed. You can set the CANCELLED _FLAG to Y in the order headers interface table to cancel the entire order.

For ship-to location changes, you can provide the new ship-to-location code in SHIP_TO_ORG_ID column in the order headers interface table to be applied to an existing order. This defaults the value for any new shipment. You can change this attribute for all outstanding shipments of that order. In the Sales Orders window, if you change this attribute at the header level, all outstanding line shipments will not change automatically.

Line/Shipment Level Changes

Order Management supports a two-level data where the shipments of a line are treated as a separate lines with the same line number, but a different shipment number. All the operations completed at the line level are completed at the shipment level.

Change Acknowledgements

Order Management maintains a different set of tables for acknowledgement data. After a change request is processed, the acknowledgement data is written to the acknowledgement tables.

The following table describes Inbound Order Header level Acknowledgement Codes, associated definitions, and whether or not the Acknowledgement Code enables the Change Request functionality in Oracle Purchasing for a order header linked to a purchase order.

Inbound Order Header Level Acknowledgement Codes
X12
CODE
DEFINITION Determine in PO Change Request Process
AC ACKNOWLEDGE - WITH DETAIL AND CHANGES NO
AD ACKNOWLEDGE - WITH DETAIL, NO CHANGES NO
AE ACKNOWLEDGE - WITH EXCEPTION DETAIL ONLY NO
AH ACKNOWLEDGE - HOLD STATUS NO
AK ACKNOWLEDGE - DETAIL OR CHANGE NO
AP ACKNOWLEDGE - PRODUCT REPLENISHMENT NO
AT ACCEPTED YES
NA NO ACKNOWLEDGEMENT NEEDED NO
RD REJECT WITH DETAIL YES
RF REJECT WITH EXCEPTION DETAIL ONLY NO
RJ REJECT, NO DETAIL YES
RO REJECTED WITH COUNTER OFFER NO
ZZ MUTUALLY DEFINED NO

The following table describes Order Line level Acknowledgement Codes, associated definitions, and whether or not the Acknowledgement Code enables the Change Request functionality in Oracle Purchasing for sales order lines linked to a purchase order.

Order Line Level Acknowledgement Codes 2
X12
CODE
DEFINITION Determine in PO Change Request Process
AC ITEM ACCEPTED AND SHIPPED NO
AR ITEM ACCEPTED AND RELEASED FOR SHIPMENT NO
BP ITEM ACCEPTED - PARTIAL SHIPMENT, BALANCE
DR ITEM ACCEPTED - DATE RESCHEDULED YES
IA ITEM ACCEPTED YES
IB ITEM BACKORDERED YES
IC ITEM ACCEPTED, CHANGES MADE (IF THERE ARE MORE THAN ONE CHANGE YES
ID ITEM DELETED YES
IP ITEM ACCEPTED, PRICE CHANGED YES
IQ ITEM ACCEPTED, QUANTITY CHANGED YES
IR ITEM REJECTED YES
IS ITEM ACCEPTED, SUBSTITUTION MADE YES
SP ITEM ACCPETED, SCHEDULE SHIP DATE PENDING (Oracle Order Management Schedule Ship Date.) YES

Purge Change Requests

Once a request is processed successfully, the request is deleted from the Order Import tables. However, if there is an error, you need to resolve the exception then revalidate the transaction or you can delete the request if the error cannot be resolved for any reason. Otherwise, the request remains in the Order Import tables indefinitely.

Inbound PO Change Data Elements

Change Request Rejections

The REJECT_FLAG in the lines interface table specifies any reject lines. If a line is rejected, it will also be acknowledged and then deleted from the Order Import tables.

Change Request Status

Order Import interprets the statuses in the table in the business needs section the following way:

Change Request Type Codes

The CHANGE_REQUEST_CODE in the order header and lines interface tables specifies the type of the request. These are reference only codes and are retained in the Order Management tables. These codes assists you in determining the type of change.

Customer and Supplier Items/Parts

Order Management cross references between your customer and supplier part numbers. The customer part number takes priority over the supplier item number when both numbers are provided.

Customer Line Number

The CUSTOMER_LINE_NUMBER column in the order lines base table specifies the line number in the customer's purchasing system. This is a display only field and no processing will be based on this attribute. You can enter and update the customer line number on-line. The customer line number is copied to new line records if you split the shipments.

Customer Shipment Number

The CUSTOMER_SHIPMENT_NUMBER column specifies the order lines base tables to specify shipment number in your customer's purchasing application. This is a display only field and no processing is based on the attribute. You can enter and update the customer shipment number on-line. If you split the shipment, the customer shipment number will be copied to the new shipment record.

Operations Code

You can set the OE_ HEADERS_INTERFACE.OPERATION_CODE to Update or Delete if you are trying to update or delete an order respectively.

Original System Data

You can identify which order is the change request for by providing the same value in ORIG_SYS_DOCUMENT_REF and ORDER_SOURCE_ID columns in the Order Import tables as in the same column in the base order header table. This is often the customer's purchase order number. If an existing order does not have any value in this column, you will not be able to process change requests against that order.

Line/Schedule Level

You can identify which line is the change request coming against by providing the same value in ORIG_SYS_LINE_REF, ORDER_SOURCE_ID, and ORIG_SYS_DOCUMENT_REF columns in the interface tables as exists in the same column in the base order lines table. This is often the customer's purchase order line number concatenated with the shipment number or current customer request date. A complex ORIG_SYS_LINE_REF may be the concatenation of the customer line number + current request date + ship to address ID.

If an existing line does not have any value in this column, you will not be able to process change requests against that order.

Order Source ID

You can set the ORDER_SOURCE_ID to 6 in the Order Import tables. ORDER_SOURCE_ID 6 is the code for the Order Source, EDI.

Payment Term

The CUSTOMER_PAYMENT_TERM_ID column contains the payment term derived by data in the transaction. If this is different from the one derived by Order Management, a warning is displayed. You can change the payment term in the Sales Orders window.

The CUSTOMER_ITEM_NET_PRICE column in the order lines table contains the price sent by the customer. If this price is different from the price calculated by the system, Order Management provides you with a warning. You can then change the price using the Sales Orders window.

Outbound Purchase Order Acknowledgements

The outbound Purchase Order Acknowledge process generates data that is used to notify your customers of the latest status of their orders. This includes following information from Order Management:

These acknowledgements reflect the status given to the original purchase order, purchase order changes due to your customer's purchase order change request, or your changes. You may need to change shipment quantities or change shipment dates. All purchase order acknowledgements must contain adequate data to allow your customers' process to match the acknowledgement data from Order Management back to the purchase order in their purchasing application.

Three processes are involved in processing and extracting all purchase order acknowledgements from Order Management.

Original Purchase Order Acknowledgements

After the new order has been created, booked and scheduled dates are determined, the PO acknowledgement records are flagged that this is the first time that the order is acknowledged. Erroneous new orders that have been marked as rejected are also flagged for the original PO acknowledgement. The original purchase order acknowledgement data with the flag is written to the acknowledgement tables.

Purchase Order Change Acknowledgements

The purchase order change acknowledgement data is written to the acknowledgement tables:

Change Request Types

Order Management accepts the following types of change requests that will initiate a purchase order acknowledgement:

Sales Orders Window

The Sales Orders window is used to create new sales orders and change existing orders. If you entered or changed a sales order which is not acknowledged, such as, all the lines are not booked or the scheduled dates are not entered, the Process Order API is to create or update the sales order in the OM base tables, which In turn will call Acknowledgement Process to call acknowledgement. As all the lines are not Booked and Scheduled no acknowledgement records will be created in Acknowledgement tables at all.

Acknowledgement Process

The acknowledgement process determines whether Oracle e-Commerce Gateway is installed and if the Trading Partner sold to site is enabled for the acknowledgement transaction. If the Trading Partner is enabled for the specific transaction, the acknowledgement process verifies if the conditions for the acknowledgement are satisfied such as, if an order is booked or a schedule date is set up.

Note: The Trading Partner site for the acknowledgement is the site identified as the SOLD_TO customer. Add SOLD_TO code for the SITE_USE_CODE lookup type for the receivables setup (quick code). Add SOLD_TO usage for the customer and set one primary usage for it.

Rejected Orders in the Order Import

Rejected changes are included in the acknowledgement process. The acknowledgement API picks up all rejected records from the Order Import interface tables.

When Acknowledgement Process is called from Order Import, all the records of the set are rejected such as, all records of the headers and lines have a REJECT_FLAG set to Yes. You must reject all the data since the data cannot be corrected. The acknowledgement process creates acknowledgements for all rejected data for the set. A verification for the data change is performed, if the acknowledgement is called from the Process Order API.

Note: The Process Order API calls the acknowledgement process which finds the required data and sends all the data simultaneously.

If the enabled condition is satisfied, then a new order can be entered using the Sales Orders window. The OE_Acknowledgement_PUB API will not create any records in the acknowledgement table until the order has a status of Booked. Unless all the lines of header are Booked and have Schedule Ship Date data, data will not be created in the acknowledgement tables. If the new orders are entered using the Sales Orders window, the API will be called and records will be created in acknowledgement tables.

You can correct the Lines Forever record or mark the record as Rejected by using the Order Import Corrections window.

The following table displays combinations of possible conditions, status flags and what updates are made to the action table in respect to the acknowledgement:

Action Table Conditions, Status Flags, Updates Example
Condition ERROR_FLAG REJECT_FLAG Acknowledgement
1 Yes No No record created.
2 No No Record created.
3 Yes Yes Record created.
4 No Yes Record created.

Only those lines satisfying Condition 2 are used to call Process Order API in order to create records in the base order table. Once Process Order API successfully creates the records, the OE_Acknowledgement_PUB API acknowledges all lines that can be corrected and query interface tables to find records with REJECT_FLAG set to Yes to acknowledge the lines that cannot be corrected as rejected lines.

If the changes are entered in the Sales Orders window, the Process Order API writes records to the acknowledgement tables. When you save the order, choose the Acknowledge button in the Sales Orders window and Order Management checks for when the Oracle e-Commerce Gateway Enabled Trading Partner, booking and schedule ship date will be performed. Save the new or updated order.

The following table provides several example conditions within the Order Import Interface table, and the associated database updates to both Order Management base tables and Acknowledgement tables based upon the condition.

Example Conditions within Order Import Interface Table
Order Import Interface Table Condition Base Table Acknowledgement Table
O1 - Order changes can be corrected. O1 O1
O2 - Order changes cannot be corrected. No record created. No record created.
O3 - Bad Order (cannot be corrected) No record created. O3 - Lines cannot be corrected and are acknowledged.
O4 - Three lines that can be corrected and two lines that cannot be corrected. O4- Three lines that can be corrected. O4 - Acknowledgement of three lines that can be corrected and two lines that cannot be corrected.

Outbound PO Acknowledgement Data Elements

Acknowledgement Indicators

Acknowledgement data such as first acknowledgement and last acknowledgement date, and acknowledgement codes are recorded in the Sales Orders master table. Acknowledgement indicators exists at the header and line levels only.

The following table describes Outbound Order Line level Acknowledgement Codes, associated definitions, and whether or not the Acknowledgement Code enables the Change Request functionality in Oracle Purchasing for a order header linked to a purchase order.

Outbound Order Line Level/Acknowledgement Codes
X12 Code Definition Determine in Po Change Request Process
DR Item Accepted - Date Rescheduled Yes
IA Item Accepted Yes
IB Item Backordered Yes
IC Item Accepted, Changes Made (If there are more than 1 change) Yes
ID Item Deleted Yes
IQ Item Accepted, Quantity Changed Yes
IR Item Rejected Yes
IS Item Accepted, Substitution Made Yes
SP Item Accepted, Schedule Ship Date Pending (Oracle Order Management Schedule Ship Date) -

Line Item Status

Order Management maintains a Line Item Status code to return in the Purchase Order Change Acknowledgement transactions. The following code indicates the status of the Purchase Order Change Request after the request is applied to the sales order.

Header Level Acknowledgement Code

The process retains a Purchase Order Change Request Status code at the header level in order to return it in the Purchase Order Change Acknowledgement transaction.

The following table describes Outbound Order Header level Acknowledgement Codes, associated definitions, and whether or not the Acknowledgement Code enables the Change Request functionality in Oracle Purchasing for a order header linked to a purchase order.

Outbound Order Header Level/Acknowledgement Codes
X12 Code Definition Determine in Po Change Request Process
AC Acknowledge - with Details and Changes No
AD Acknowledge - with Detail, No Change No
AE Acknowledge - with Exception Detail Only No
AH Acknowledge - Hold Status No
AK Acknowledge - Detail or Change No
AP Acknowledge - Product Replenishment No
AT Accepted Yes
NA No Acknowledgement needed No
RD Reject with Detail Yes
RF Reject with Exception Detail Only No
RJ Reject - No Detail Yes
RO Rejected with Counter Offer No
ZZ Mutually Defined No

Oracle e-Commerce Gateway Transactions

The purchase order and purchase order change acknowledgement process supports data for the following EDI standard transactions. This data can be extracted from Order Management acknowledgement tables and copied to the transaction interface file by the Oracle e-Commerce Gateway.

The following table provides e-Commerce Gateway Transaction Codes, X12 data values, and EDIFACT values for two purchase order transactions.

e-Commerce Gateway Transaction Codes
Transactions Direction e-Commerce Gateway Transaction Code X12 EDIFACT
Original Purchase Orders Acknowledgement Outbound POAO 855 ORDRSP
Purchase Order Change Acknowledgement Outbound POCAO 865 ORDRSP

The first time that orders are acknowledged they are flagged as the original acknowledgement. These original acknowledgements are extracted by the POAO transaction process in the Oracle e-Commerce Gateway.

All subsequent acknowledgements for the given purchase order are flagged for the purchase order change acknowledgement extract for the POCAO transaction.

The translator maps the data to the chosen EDI standard transaction from the data in the Oracle e-Commerce Gateway transaction files. The translator determines which EDI standard transaction to map the data for the given Trading Partner.

The POAO and POCAO processes set the acknowledgement flag so that next POAO and POCAO extract processes do not retrieve the acknowledged order again. Also the order purge process can delete the data. The POAO and POCAO processes update the dates on the order's and order line's master tables to indicate when the acknowledgement is extracted.

For additional details, see:

Oracle e-Commerce Gateway User's Guide

Oracle e-Commerce Gateway Implementation Manual

Vertex Engine-Related Updates

Order Management has been enhanced to better support the tax vendor Vertex through integration with Oracle E-Business Tax. Since E-Business Tax allows legal entity-related tax setup and Order Management requires that all lines in the same order belong to the same legal entity, please make sure your Receivables transaction type, invoice source and non delivery invoice source in the line type refer to the same legal entity as the order type. Also the Receivables tax setup submenu included in Order Management setup menu has changed to not allow setup of tax Codes, Authorities, Sales Tax Rates, Exceptions, Exemptions, Tax Groups, General Ledger Tax Assignments and Tax Reporting Ledger. For more details about tax setup and migration, please refer to Oracle E-Business Tax User Guide and Financials Functional Upgrade document.

Also some of the Order Management windows have additional/renamed fields as a result of the Vertex uptake. Additionally profile options have been changed. These changes to Order Management are described in the sections below:

Order Header: The fields Tax Exempt Number, Tax Handling and Exempt Reason remain the same.

Note: When the profile option EBTAX: Allow Override of Customer Exemptions is set to Yes, you can enter values in the Exemption related fields.

Order Line: The field Tax Code in the Order Line has been renamed to Tax Classification Code. The field Tax Group is no longer used. When the profile option EBTAX: Allow Override of Tax Classification Code is set to Yes, you can enter values in the Tax Classification Code field.

Additionally when you click Actions > View Tax Details, the Tax Details window displays the following fields: Tax Regime, Tax, Tax Status, Tax Rate Code, Rate, Amount. The Order Information Portal shows similar tax-related fields in the Additional Details page.

Tax calculation takes place depending on the tax event (Entered, Booked, Invoiced) specified in the Transaction Type window. Use Actions > Calculate Tax to ensure that the tax calculation is carried out. In case you update information in the sales order line, the tax engine is called again and the tax is recalculated. Also if you change the tax classification code, the tax is recalculated.

International Trade Management

International Trade Management, includes Export Compliance Screening (ECS) which is comprised of Denied Party Screening (DPS), License Determination, and Embargo etc.

Note: This depends on the services supported by the vendors. This can be any number. Each check helps to ensure that exporters are shipping within government regulations.

International trade requires adherence to individual country specific rules, regulations, and duties applicable between countries of trade when processing orders for export. International Trade Management (ITM) utilizes software applications to assist with the facilitation of international trade by providing the latest details surrounding the complex set of rules and guidelines surrounding international trade. Each rule or guideline surrounding international trade ensures that exporters are shipping products in compliance with existing government regulations. By interfacing your order processing routines with ITM vendor software applications, you can:

United States exporters are required by the United States government to perform due diligence when exporting products or services. Oracle Order Management, utilizing the features of the Oracle ITM Adapter and integration to third party ITM vendor software applications, provides you with the necessary application tools to perform Export Compliance screening.

Export Compliance Screening

Export Compliance Screening is an optional procedure within an order flow enabling you to determine the eligibility of shipments for adherence to statutory government requirements surrounding the export of products. The United States Bureau of Export Administration and several other countries maintain referenceable Denied Party Listings (DPL) which provide a complete listing of entities that goods cannot be exported to.

Export Compliance screening enables export compliance prior to shipment, alerting users to possible problems that might halt export shipments due to government regulations. Oracle Order Management automatically enables you to manage your export compliance screening compliance strategies through the use of:

Within Order Management, Export Compliance Screening occurs at the order line level by inserting the Export Compliance Screening subprocess after booking but prior to the Create Supply or Ship Line workflow subprocesses for an order line flow. Export Compliance Screening validates the order line item by shipment location; sales orders are validated against the DPL based upon the Ship From country for each order line.

Prerequisites

  1. Verify seeded Order Management ITM line workflows meet your business processes for compliance, or create new line workflows for your ITM screening processing.
  2. Create new or update existing Order Management transaction types to enable your ITM order and line workflows.
  3. Register users and perform the necessary setup to enable XML communications between the Oracle ITM Adapter and your third party ITM vendor. See: Oracle Shipping Execution User's Guide, International Trade Management, Setup Process

Generic Export Compliance Major Features

Generic Export Compliance Screening

Generic Export Compliance is generic term applicable for all the export related compliance checks. These include Denied Party Screening, Embargo Country Screening, License Determination, Document Generation etc. The partner ITM application evaluates the transaction for export compliance and responds to Oracle Applications with the overall compliance pass or fail status for each of the order line.

Note: The US Government often updates the Denied Party List, and partner ITM applications may update this information every seven days.

General Flow of Data for Generic Export Compliance

Note: Generic Export Compliance Screening will have two results: Success or Failure. The screening types will depend upon the types supported by the vendor and the setup. The ITM Adapter response will send a result of success or failure. A new hold EXPORT COMPLIANCE HOLD is seeded that is a generic type of hold. This hold is applied on an order line when compliance fails.

Note: Denied party screening done in earlier releases will remain intact.

If the screening type is a denied party and the compliance fails, a Denied Party Hold will be applied on the line and if the generic screening fails, the new Export Compliance Hold will be applied.

Following holds can defined.

Hold Type: Import/Export Compliance

Hold Defined: Export Compliance Hold

Holds information can be checked from the Additional Line Information Window in the Sales Orders window.

Holds provide security to apply/release by responsibility. Holds can be released from the Sales Orders window for a single line or multiple lines by using multi-select functionality.

Pick Release honors generic holds.

Holds Functionality provides the following Reports:

To resolve the order when it is on Export Compliance Screening hold:

  1. Navigate to the Sales Orders window.
  2. Enter the order header and line information.
  3. Book and schedule the order.
  4. Pick Release, and Ship Confirm. If screening fails a Hold is applied on the line and the block is released, an Alert is sent from Workflow.
  5. The hold is reviewed. If it is determined to be a False Positive, the Hold is removed and the line can be Pick Released and Ship Confirmed. If it is determined to be, non-compliant you must decide whether to cancel the line or the order.

Export Compliance Screening Workflow

Export Compliance Screening has been implemented as a sub-process that can be inserted into existing lines workflow.

Export Compliance Screening - Line Level

Line Flow - Generic, With Export Compliance Workflow process

The Line Flow - Generic, With Export Compliance line flow is seeded for Oracle Order Management.

Line Flow - Generic, With Export Compliance Workflow

Export Compliance Screening Activity will populate the Generic Adapter Interface Tables and wait for the Export Screening to complete. After the records are processed, they are analyzed. If the screening was successful, then the Export Compliance Screening activity is completed with Complete result.

Once an order with an order type that enables export compliance screening has been Booked and the records received (interfaced) by the Oracle ITM Adapter, Order Management will set the order line status to Awaiting Export Screening, and the workflow is then set to a status of Wait (activity). All records with this status are then processed by the Oracle ITM Adapter and sent electronically to the ITM vendor software application or your choice (determined during your ITM setup). ITM vendor software applications then process the records for compliance.

Once records have been processed for compliance, the results are returned to the Oracle ITM Adapter, which then updates corresponding Oracle Adapter response tables and a call is placed to Order Management to progress order lines past the Wait activity. Order and lines will then continue within their respective line flows, dependent upon the return values from your ITM vendor software application. The return values from your ITM vendor software application are interpreted by the Oracle ITM Adapter, which can return one of the following values to the Export Compliance Screening workflow subprocess: