This chapter covers the following topics:
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:
The Oracle Release Management Demand Processor supports three types of inbound demand documents:
Planning/Material Release Schedules
Shipping Schedules
Production Sequence Schedules
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 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:
ASC X12 Planning Schedule With Release Capability (830)
EDIFACT Delivery Schedule (DELFOR)
ODETTE Delivery Instruction (DELINS)
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:
ASC X12 Shipping Schedule (862)
EDIFACT Delivery Just In Time (DELJIT)
ODETTE Delivery Instruction (DELINS)
ODETTE Delivery Just In Time (CALDEL)
ODETTE Kanban Signal (KANBAN)
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:
ASC X12 Production Sequence (866)
EDIFACT Delivery Just In Time (DELJIT)
ODETTE Delivery Just In Time with production sequence (SYNCRO)
ODETTE Delivery Just In Time with packing sequence (SYNPAC)
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.
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.
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:
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.
Examine each trading partner's EDI implementation documentation for Outbound Ship Notice/Manifest for required turnaround data elements.
Identify external data elements that are not represented in the destination columns.
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).
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.
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.
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.
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.
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:
Planning
Shipping
Production Sequence
Code conversion categories used within the Oracle Release Management Demand Processor include the following:
Schedule Type
Purpose Code
Detail Type
Detail Subtype
Date Type
Quantity Type
Unit of Measure
Shipment Delivery Pattern
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.
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.
The following code conversion evaluation procedure is recommended when implementing Oracle e-Commerce Gateway for inbound demand schedules:
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.
Note any external values related to the code conversion Category that are not represented in the seeded code conversion values.
Decide which internal value most closely represents the external value.
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).
Define code conversion values as needed in the Oracle e-Commerce Gateway Code Conversion Values folder window.
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 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:
Internal | External 1 | External 2 | EDI Standard | Trading Partner |
---|---|---|---|---|
Sequenced | DELJIT | 242 | EDIFACT | TP1 |
Shipping | DELJIT | 241 | EDIFACT | TP1 |
Shipping | DELJIT | 242 | EDIFACT | TP2 |
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:
Add: Schedule demand is added to any previously established requirements that fall within the horizons of this message.
Cancellation: Schedule demand included on the message cancels previously established requirements.
Change: Schedule demand supersedes any previously established requirements for only those parts included on the message.
Confirmation: The issuer's transmission to confirm an emergency requirement is communicated but not transmitted.
Delete: Removing a part or shipment requirement sent on a previous transaction. Data for other part numbers previously transmitted and not included in this transmission must be retained.
Original: Initial transmission related to a given transaction.
Replace: Schedule demand supersedes any previously established requirements that fall within the horizons of this message.
Replace All: This enables you to completely replace the existing forecast with the new demand, for all items in the forecast. This is useful for trading partners that drop the demand for an item from one forecast to the next. The purpose code Replace replaces on an item-by-item basis. The Demand Processor deletes the forecast for a given item and inserts new demand for that item without updating the other items on the forecast. If the customer has dropped demand for an item, with the Replace purpose code, it remains in the forecast. With Replace All, it is removed.
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:
Date = Today, Quantity = 50
Date = Tomorrow, Quantity = 0
Existing Order Lines within the schedule horizon from other Shipping Schedules:
Date = Today, Quantity = 10
Date = Tomorrow, Quantity = 20
Resulting Order Lines from Shipping Schedules within the schedule horizon for various Schedule Purpose Codes:
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 |
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 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:
Authorizations
Shipped/Received Information
Other
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 is used by the Demand Processor to determine how the schedule line itself should be interpreted. The following Detail Types are supported:
Past Due Demand
Firm Demand
Forecast Demand
Authorizations
Shipped/Received Information
Other Information
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 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:
Demand Detail Types: Valid Detail Subtypes represent demand bucketing: Day, Week, Flexible, Month, or Quarter.
Authorizations: Valid Detail Subtypes represent type of Authorizations: Finished Goods, Raw Materials, Labor and Materials, Labor, or Prior Cumulative Required.
Shipped/Received Information: Valid Detail Subtypes represent type of information: Shipment, Receipt, or Customer CUM.
Other Information: Valid Detail Subtypes represent type of information: Ahead/Behind, Inventory Balance, or In Holdout.
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.
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
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.
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:
System date (formerly the Schedule Horizon Start Date)
Date type
Lead time
Shipping and receiving calendars
Shipment Delivery Pattern Codes
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.
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.
e-Commerce Gateway
Demand Processor
Demand Processor Exception Report
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.
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:
Inbound EDI Planning Schedules (SPSI)
Inbound EDI Shipping Schedules (SSSI)
Inbound EDI Production Sequence Schedules (PSQI)
The following figure details how you can automate the demand management process.
Automated Demand Management Process
Exceptions relating to inbound demand transactions are generated by either Oracle e-Commerce Gateway or the Release Management Demand Processor.
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:
Trading Partner Not Found - Skip Document
Test/Production Flag Discrepancy - Log Only
Invalid Translator and Location Code Combination - Skip Document
Oracle e-Commerce Gateway performs validation for the following Column Rules, with the corresponding action when violation occurs:
Value is Required - Skip Document
Simple Table Lookup - Skip Document
Valueset Lookup - Skip Document
Null Dependency - Skip Document
Datatype Checking - Skip Document
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.
Exceptions relating to inbound demand transactions can be viewed and corrected within the application that generated them.
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.
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.
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.
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:
Use an appropriately named column if one exists
Use Descriptive Flexfields for data on inbound demand schedules that only need to be carried through Oracle Order Management and Oracle Shipping Execution
Use Trading Partner Flexfields for data on inbound demand schedules that is trading partner-specific in nature and will be referenced in trading partner-specific workflow customizations
The following tables must have the same definition in AOL for Descriptive Flexfield Attributes for the Oracle Release Management Demand Processor:
Headers
RLM_INTERFACE_HEADERS
RLM_SCHEDULE_HEADERS
OE_ORDER_HEADERS
Lines
RLM_INTERFACE_LINES
RLM_SCHEDULE_LINES
OE_ORDER_LINES
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.