This chapter covers the following topics:
The use of Oracle XML Gateway with Oracle Release Management enables you to receive shipping and planning transactions from any trading partner that has the capacity to produce and transmit Open Application Group (OAG)/XML based transactions.
XML transactions are received from trading partners, then are queued and handled by Oracle XML Gateway in the following way:
Validated: Oracle XML Gateway validates the messages.
Map selection: The trading partner is recognized and the appropriate map (the relationship between the source and target data elements) is applied.
Data conversion: The data is converted from the Oracle XML Gateway to the Oracle Release Management tables.
All transactions that have been successfully processed appear on the Release Management Workbench as Available to Process schedules.
You must install and configure Oracle XML Gateway. See: Oracle XML Gateway User's Guide.
The following setup steps are necessary for the use of Oracle XML Gateway with Oracle Release Management:
Message mapping is used by Oracle XML Gateway to populate the Oracle Release Management interface file with the inbound transaction information.
Oracle XML Gateway includes the Oracle XML Gateway Message Designer. The Message Designer is a repository-based tool that is used to define message maps, which represents the relationship between the source and target data elements.
Oracle XML Gateway includes seeded maps for Shipping and Schedule. You modify these existing maps with the Oracle XML Gateway Message Designer with the following:
Define the Data Source and the Data Target
Map the Source Data Structure to the Target Data Structure
Map the Source Data Element to the Target Data Element
See: Oracle XML Gateway User's Guide.
The Define Transaction form is used to cross-reference external codes that identify a transaction in an XML message to its internal code that is recognized by the Oracle application that is processing the transaction.
The following values are seeded within Oracle XML Gateway:
Party Type: Customer
Transaction Type: RLM
Transaction Subtype: SPSI and SSSI
Transaction Description: Planning Schedule Inbound Transaction
Standard Code: OAG
Direction: IN
External Transaction Type: SYNC
Using the Oracle XML Gateway Trading Partner form, you define customers that send or receive XML documents. For inbound demand, you must define the customer and the corresponding locations as an Oracle XML Gateway trading partner location and enable the inbound demand documents that they will send.
Use the following values to define trading partners within Oracle XML Gateway:
Trading Partner Type: Customer
Trading Partner Name: (name of your customer)
Trading Partner Site: (physical location of your customer)
Company Admin Email: (your customer's e-mail)
Transaction Type: RLM
Transaction Subtype: SPSI and SSSI
Standard Code: OAG
External Transaction Type: PLANSCHD and SHIPSCHD
External Transaction Subtype: SYNC
Direction: IN
Map: RLM_SPSI_OAG70_IN and RLM_SSSI_OAG70_IN
The following values are seeded standards within Oracle XML Gateway. You can modify them to meet your specific needs:
Standard Code: OAG
Standard Type: OAG
Oracle XML 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. Oracle XML Gateway code conversion provides a method to cross-reference the codes defined in Oracle Applications to codes used by trading partners.
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.
The following table represents the Oracle XML Gateway Seeded code conversion categories. You can modify them to meet your specific needs:
| Code Conversion Category | XML Element | Interface Column |
|---|---|---|
| RLM_DATE_TYPE | DATETYPE | DATE_TYPE_CODE |
| RLM_DTL_SUBTYPE | FLEXBKTID/BKTYPE | ITEM_DETAIL_SUBTYPE |
| RLM_DTL_TYPE | LINETYPE | ITEM_DETAIL_TYPE |
| RLM_QTY_TYPE | Not on XML Document | QTY_TYPE_CODE |
| RLM_SCHED_TYPE | Not on XML Document | SCHEDULE_TYPE |
| RLM_SCHED_PURP | SYNCIND | SCHEDULE_PURPOSE |
| UOM | QUANTITY.UOM | UOM_CODE |
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 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 can 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.
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.
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.
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.
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.
Unit of Measure (UOM) is used by the Demand Processor to determine how the quantity on a schedule line should be interpreted.
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.
Enable the applicable XML Gateway inbound planning and shipping transactions for each trading partner.
For planning schedules, Oracle XML Gateway uses the PLANSCHD message. SYNC PLANSCHD communicates the requirement information, for example part number and quantity, between a customer and supplier.
SYNC PLANSCHD enables the addition of new requirements and the modification of previously established requirements through various SYNC Indicator values. Existing SYNC Indicator values from OAG release 6.2 include the following:
A: For adding
C: For change
D: For delete
R: For replacement
For shipping schedules, Oracle XML Gateway uses the SHIPSCHD message. SYNC SHIPSCHD enables the following:
Exchange of shipment schedule information
Authorizing a shipment quantity and date for specific trading partners
Authorizing a shipment address for specific trading partners
Typically, the ship schedule is generated by a material planning application and transmitted to an order or material planning application.