Oracle e-Commerce Gateway for Inbound EDI Demand

This chapter covers the following topics:

Overview of Oracle e-Commerce Gateway for Inbound EDI Demand

The Oracle e-Commerce Gateway provides a bridge from the EDI translator of your choice to the Oracle Release Management Demand Processor Open Interface.

This chapter focuses on using the Oracle e-Commerce Gateway for processing inbound EDI demand schedules from your trading partners into Oracle Release Management, and addresses the following areas:

Inbound Demand Transaction Types

The Oracle Release Management Demand Processor supports three types of inbound demand documents:

Specific EDI documents are identified with a specific Oracle e-Commerce Gateway Transaction Type Code and mapped using the corresponding interface data file format. There are several EDI transactions or messages that can be processed as inbound demand, having various functionality and EDI standards.

SPSI for Planning/Release

SPSI is used for Planning Schedules and Material Release Schedules that can include both forecast and firm requirements. The following inbound EDI transactions are loaded into the interface data file using the SPSI code:

SSSI for Shipping

SSSI is used for Shipping Schedules that contain firm delivery information and are intended by the customer to refine requirements already presented in the Planning Schedule. The following inbound EDI transactions are loaded into the interface data file using the SSSI code:

PSQI for Sequencing

PSQI is used for Production Sequence Schedules that contain demand with information to facilitate delivery and use at the customer site, such as specifying the customer production line sequence or the conveyance packing sequence. The following inbound EDI transactions are loaded into the interface data file using the PSQI code:

Process Flow

The EDI translator of your choice creates an interface data file in a specific format for the Oracle e-Commerce Gateway as it translates the EDI demand schedule document.

The Oracle e-Commerce Gateway Inbound Processor reads the demand schedule data in the interface data file and loads it into the Oracle Release Management Demand Processor interface tables using mapping defined in the transaction spreadsheet to populate the columns.

The Demand Processor then verifies the demand schedules, manages the schedule information based on Release Management processing rules, and reconciles the demand with existing sales orders or sales agreement and forecasts.

Using e-Commerce Gateway for Inbound Demand

Features of the Oracle e-Commerce Gateway for Inbound Demand apply to various aspects of processing. This section describes the steps required in each aspect of the process.

Interface Data File Mapping

Trading Partner Interface Data File Mapping Evaluation

Demand Management begins when Oracle e-Commerce Gateway receives an incoming EDI demand document from a trading partner and loads it into the Demand Processor interface tables.

Oracle EDI Translation CAI Partners have developed general EDI translator data maps or templates for the three inbound demand transaction types.

It is important to evaluate the data storage and processing provided by Oracle Release Management for gaps to trading partner specific requirements for Demand, Order, Shipping, and CUM Management.

The following Interface Data File Mapping evaluation procedure is recommended when implementing Oracle e-Commerce Gateway for inbound demand schedules:

  1. Examine each trading partner's EDI implementation documentation for applicable inbound demand transaction in context of the general EDI translator data maps or templates to determine if the default mapping provides a destination column for each element included in trading partner's EDI demand.

  2. Examine each trading partner's EDI implementation documentation for Outbound Ship Notice/Manifest for required turnaround data elements.

  3. Identify external data elements that are not represented in the destination columns.

  4. Decide whether the external data elements are generic in nature (many or all trading partners use the external data) or trading partner-specific in nature (the external data element is unique to one or few trading partner locations).

  5. Decide which interface level and destination column would be most appropriate for the external data element, such as an appropriately named column if one exists, Descriptive Flexfields, or trading partner flexfields.

  6. Decide whether validation logic within Oracle e-Commerce Gateway is desirable for the destination column; if so, define appropriate Column Rules for Rule Based Exception Processing.

  7. Decide whether validation or processing logic within the Oracle Release Management Demand Processor is desirable for the destination column; if so, define appropriate trading partner-specific customizations.

    If external data elements, which are not represented in the destination columns, are identified, refer to Inbound Demand Customization.

Trading Partner Setup

e-Commerce Gateway Trading Partner Setup

Using the Oracle e-Commerce Gateway's Trading Partner form, you define customers that send or receive different EDI documents. For inbound demand, you must define the customer and the corresponding locations as an Oracle e-Commerce Gateway trading partner location and enable the inbound demand documents they will send.

Release Management Trading Partner Processing Rules

The Oracle Release Management Processing Rules form enables you to define processing rules for customers, and optionally for their related ship-to locations and customer items when the customer level rules are inappropriate. Processing rules relate to Demand Management, Demand Fences, Order Management, CUM Management, and General Rules. Based on related customer setup in Oracle Order Management, you can enter addresses of related customers in Ship-to field here. See: Oracle Release Management User's Guide.

Demand Processor Uses Both Setups

The Demand Processor verifies schedule information based on the Oracle e-Commerce Gateway Trading Partner setup in conjunction with Oracle Release Management Processing Rules.

Code Conversion Setup

Oracle e-Commerce Gateway utilizes code conversions to determine the corresponding internal value used within the Oracle Release Management Demand Processor for several external data elements occurring on the inbound demand schedule. They are applicable to all inbound demand schedule types, including:

Code conversion categories used within the Oracle Release Management Demand Processor include the following:

Seeded code conversion values are provided to link external codes used in ASC X12 and EDIFACT EDI standards with the corresponding internal value used within the Oracle Release Management Demand Processor.

Code Conversion Search Keys

You can identify unique conversion codes at the customer, customer site, or up to five levels of a search key. For example, a customer with multiple ship-to locations, each having unique carrier codes, all of which must be converted to internal carrier codes.

For more information on how to effectively use search keys, see: Oracle e-Commerce Gateway Implementation Manual.

Trading Partner Code Conversion Evaluation

The following code conversion evaluation procedure is recommended when implementing Oracle e-Commerce Gateway for inbound demand schedules:

  1. Examine each trading partner's EDI implementation documentation for each applicable inbound demand transactions to determine if the seeded values will handle the trading partner's EDI demand properly in the Demand Processor.

  2. Note any external values related to the code conversion Category that are not represented in the seeded code conversion values.

  3. Decide which internal value most closely represents the external value.

  4. Decide whether the code conversion is generic in nature (all trading partners that use this code have the same meaning for it) or trading partner-specific in nature (trading partner locations that use this code have different meanings for it).

  5. Define code conversion values as needed in the Oracle e-Commerce Gateway Code Conversion Values folder window.

Schedule Header Mandatory Code Conversion Categories

There are two code conversion categories that provide internal values which occur at the header level and are mandatory for all inbound demand schedules: Schedule Types and Purpose Codes.

Schedule Type (RLM_SCHED_TYPE)

Schedule Type is used by the Demand Processor to differentiate which demand details are applicable for matching across and matching within schedule types, and to identify the hierarchical reconciliation with other schedule data.

Additional internal values are not allowed for this code conversion category. However, new generic and trading partner-specific external values can be cross-referenced to existing internal values.

The following example illustrates a situation where seed data for Schedule Type is not adequate. Trading partner TP1 uses the EDIFACT DELJIT message for two different schedule types; they assign element 1001 of the BGM segment with a value of 241 for Shipping Schedules and 242 for Sequenced Production Schedules. Trading partner TP2 uses 242 with DELJIT to indicate a Kanban Shipping Schedule. The necessary code conversions for RLM_SCHED_TYPE could be set up using trading partner keys as follows:

Schedule Type Examples
Internal External 1 External 2 EDI Standard Trading Partner
Sequenced DELJIT 242 EDIFACT TP1
Shipping DELJIT 241 EDIFACT TP1
Shipping DELJIT 242 EDIFACT TP2

Schedule Purpose Code (RLM_TRX_PURP)

A Schedule Purpose Code is used by the Demand Processor to determine how new demand is reconciled to old demand of the same schedule type. The Demand Processor interprets demand for each item within the schedule horizon date range based on the value of the Schedule Purpose Code.

Additional internal values are not allowed for this code conversion category; however, new generic and trading partner-specific external values can be cross-referenced to existing internal values.

The Demand Processor recognizes the following internal purpose code values:

Oracle e-Commerce Gateway also provides the ability to define trading partner-specific code conversions for the external schedule purpose code values. This feature is useful when the trading partner uses a code that does not have a seeded code conversion or there is a difference between the standard meaning of the purpose code in the Demand Processor and the specific use by a trading partner. For example, your trading partner sends X12 schedules with a purpose code 07 meaning Duplicate. This schedule would generate a fatal error and would not be processed. However, if you define trading partner-specific code conversion for the external code 07 that maps to Confirmation (one of the seven valid internal purpose codes) the schedule would be processed as a Confirmation.

The following illustration shows the rule for each purpose code and how it affects the resulting demand picture for a particular Ship From/Ship To/Customer Item, assuming that all Match Within Attributes are identical and aggregation of like demand occurs:

New Demand received on a Shipping Schedule:

Existing Order Lines within the schedule horizon from other Shipping Schedules:

Resulting Order Lines from Shipping Schedules within the schedule horizon for various Schedule Purpose Codes:

Example of Purpose Code Rules

Purpose Code Rule Example
Replace, Change, Original Add Cancellation, Delete Confirmation
New demand replaces old demand within the schedule horizon New demand is added to old demand if it exists New demand is matched to and subtracted from old demand New demand does not update old demand
Date = Today, Quantity = 50 Date = Today, Quantity = 60 Date = Today, Quantity = 0 Date = Today, Quantity = 10
Date = Tomorrow, Quantity = 0 Date = Tomorrow, Quantity = 20 Date = Tomorrow, Quantity = 20 Date = Tomorrow, Quantity = 20

Schedule Line Mandatory Code Conversion Categories

There are code conversion categories that provide internal values that occur at the line level and are mandatory for all inbound demand schedules.

Date Type (RLM_DATE_TYPE)

Date Type is used by the Demand Processor to determine how the start and end date on each schedule line should be interpreted.

For Demand Detail Types (Past Due, Firm, and Forecast), the Date Type is critical because it indicates whether the schedule demand is shipment based or delivery based. The Demand Processor has a procedure that calculates shipment dates based on the system date (formerly the Schedule Horizon Start Date), date type, lead time, shipping and receiving calendars, and Ship/Delivery Pattern Codes.

The following Detail Types are information and not used in processing:

Additional internal values are not allowed for this code conversion category. However, new generic and trading partner-specific external values can be cross-referenced to existing internal values.

Detail Type (RLM_DTL_TYPE)

Detail Type is used by the Demand Processor to determine how the schedule line itself should be interpreted. The following Detail Types are supported:

Additional internal values are not allowed for this code conversion category. However, new generic and trading partner specific external values can be cross-referenced to existing internal values.

Detail Subtype (RLM_DTL_SUBTYP)

Detail Subtype is used by the Demand Processor to determine how the schedule line should be interpreted in context of its corresponding Detail Type.

Additional internal values are not allowed for this Code Conversion Category. However, new generic and trading partner specific external values may be cross-referenced to existing internal values.

Each Detail Type has a corresponding list of valid Detail Subtypes:

Quantity Type (RLM_QTY_TYPE)

Quantity Type is used by the Demand Processor to determine how the quantity on a schedule line should be interpreted in context of its Detail Type and Detail Subtype. There are two valid internal values for Quantity Type: Actual and Cumulative.

If Demand schedule lines have a Cumulative Quantity Type, the Demand Processor calculates actual quantity based on the corresponding Cumulative Shipped/Received Quantity and other Demand schedule lines.

Additional internal values are not allowed for this code conversion category; however, new generic and trading partner-specific external values can be cross-referenced to existing internal values.

Unit of Measure (UOM)

UOM is used by the Demand Processor to determine how the quantity on a schedule line should be interpreted.

UOM category is used in several other Oracle e-Commerce Gateway transactions. If you have other EDI transactions implemented within the Oracle e-Commerce Gateway, you probably already have the necessary UOM code conversions in place.

Since new EDI transactions are being implemented, it might be necessary to define additional code conversions for UOM.

Existing UOM code conversions should be evaluated to ensure that all internal and external values to be used on inbound demand transactions are defined. Additional values might be required, both generic and trading partner-specific.

When any new Oracle Inventory UOM conversion is defined, corresponding UOM code conversions for each EDI standard must also be defined

Schedule Line Optional Code Conversion Categories

Ship Delivery Pattern (RLM_SHP_DEL_CODE) is a code conversion category that provides an optional line level internal value applicable to demand Detail Types only.

Ship Delivery Pattern (RLM_SHP_DEL_CODE)

This code category specifies the days for routine shipments and deliveries. The Demand Processor has a procedure that calculates shipment dates based on the following:

The internal value of this code conversion is the key of the Release Management Shipment Delivery Pattern Codes table. The internal value is used when the Release Management Processing Rules indicate that the EDI pattern should be used rather than the default Shipment Delivery Pattern Codes.

The seed data for Oracle e-Commerce Gateway Code Conversion includes both ANSI X12 (ele. 678) and EDIFACT (code 2015) Shipment Delivery Pattern Codes, which have a meaning that can be expressed in terms of percentages on specific days of a week. Codes that reflect ambiguous days of the week (such as Monday through Thursday), and specific weeks of the month are not included in seed data.

Additional internal values are allowed for this code conversion category. First, define the Shipment Delivery Pattern Code in the Release Management Shipment Delivery Pattern Codes form. Secondly, define generic or trading partner specific Code Conversions in Oracle e-Commerce Gateway as needed to map them to external EDI values.

Process Automation

Running the Oracle e-Commerce Gateway for Inbound Demand

You can use the Oracle Standard Report Submission form to launch a concurrent program in Oracle e-Commerce Gateway for a specific interface data file containing a single transaction type.

Multiple inbound demand schedules of the same transaction type can be included in an interface data file.

It is recommended that you launch the complete group of processes for inbound demand to avoid any delay in visibility of the updated trading partner demand in Oracle Order Management.

If you run the e-Commerce Gateway and Demand Processor in a group, the concurrent processes execute sequentially, displaying the status of each concurrent request underneath the parent request.

Automating Demand Processing

The steps for receiving inbound EDI demand schedule transactions in Oracle e-Commerce Gateway and loading them from Oracle e-Commerce Gateway to Oracle Release Management can be automated.

To automate Oracle Release Management's demand processing, submit up to three periodic concurrent requests for report sets to process the Oracle e-Commerce Gateway inbound demand schedule and subsequently run the Demand Processor. You need one periodic concurrent request for each schedule type, which your trading partners communicate to you:

The following figure details how you can automate the demand management process.

Automated Demand Management Process

the picture is described in the document text

Exception Management

Inbound Demand Exception Messages

Exceptions relating to inbound demand transactions are generated by either Oracle e-Commerce Gateway or the Release Management Demand Processor.

e-Commerce Gateway

Oracle e-Commerce Gateway has Rule Based Exception Processing for inbound transactions. Using Process Rules and Column Rules for inbound demand transactions, Oracle e-Commerce Gateway validates schedule data being processed in the staging tables in the interface data file, before loading it into the Demand Processor Interface tables. When these rules are violated, exceptions are logged.

Oracle e-Commerce Gateway performs validation for the following Process Rules, with the corresponding action when violation occurs:

Oracle e-Commerce Gateway performs validation for the following Column Rules, with the corresponding action when violation occurs:

Release Management Demand Processor

The Demand Processor generates exceptions that occur while the interface schedule is being validated, processed, archived, and reconciled with existing demand. See: Overview of Oracle Release Management Demand Processor, Oracle Release Management User's Guide.

Viewing Exceptions and Correcting Exception Conditions

Exceptions relating to inbound demand transactions can be viewed and corrected within the application that generated them.

Oracle e-Commerce Gateway

Two types of data rule exceptions can be found during data validation: processing rules and column rules. After running the inbound transaction process or resubmitting transactions for revalidation, you can view exceptions in the View Staged Document window.

Oracle Release Management Demand Processor

Exceptions generated by or the Release Management Demand Processor can be viewed on the Demand Processor Exceptions Report, or online using the Release Management Workbench. Exception conditions can be corrected by following the specific instructions in the message text.

Inbound Demand Customization

Oracle e-Commerce Gateway enables you to make changes because the Oracle e-Commerce Gateway Inbound Engine is generic in nature and data driven. The program itself does not require changes. See: Oracle e-Commerce Gateway User's Guide.

Change Seed Data

If you need to populate a new column in the interface tables, change the default mapping, or if data storage gaps exist, the following options for destination column exist in the Release Management Demand Processor Interface tables:

The following tables must have the same definition in AOL for Descriptive Flexfield Attributes for the Oracle Release Management Demand Processor:

Implementing Flexfields on Inbound Demand Schedules

This section applies to implementing descriptive and trading partner flexfields on inbound demand schedules.

To comply with trading partner requirements to handle additional data on inbound demand transactions, customize the Oracle e-Commerce Gateway inbound demand interface data file definition and/or the generic inbound processor at predefined stages. Flexfields (attributes) are user-defined fields in Oracle Applications. They are found in inbound and outbound transactions. You must modify the general EDI translator data maps or templates to use flexfields. See: Oracle Application Object Library User's Guide.