This chapter covers the following topics:
The following list represents the setup steps, required and optional, for Oracle Release Management. Each step is described in detail in the following sections:
Step 15: Enable e-Commerce Gateway SPSI, SSSI, PSQI transactions
Step 16: Optionally Define Additional e-Commerce Gateway Column Rules
Step 17: Optionally Utilize RLM Trading Partner or Descriptive Flexfields
Step 18: Define Sourcing Rules for Advanced Planning and Scheduling
Step 19: Optionally Define Additional CUM Adjustment Reasons
Step 26: Enable XML Gateway Planning and Shipping Transactions
Oracle Applications Release 12 should be installed according to your specific business needs, including Oracle Release Management and Oracle e-Commerce Gateway for SPSI, SSSI, PSQI, DSNO, and INO transactions. Other Oracle applications have specific setup procedures that must be completed before proceeding.
During implementation, you set a value for each user profile option to specify how Oracle Release Management controls access to and processes data.
Related Topics
Oracle Release Management Profile Options.
Refer to the Receivables and Order Management setup steps in their respective implementation manuals.
Within Oracle Shipping Execution, define your Warehouse Shipping Calendar. Then associate this calendar with a particular warehouse. These calendars are used by Oracle Release Management to determine an appropriate ship date.
See: Oracle Order Management Implementation Manual.
Within Oracle Shipping Execution, define each Customer Receiving Calendar. Then associate this calendar with a particular customer or customer site. These calendars are used by Oracle Release Management to determine an appropriate ship date. You can also define a generic Customer Receiving Calendar and assign it to multiple customers.
Important: This is an optional step.
See: Oracle Order Management Implementation Manual.
Using the Maintain Ship/Delivery Pattern Codes form, verify that seeded Ship/Delivery Pattern Codes are present, and optionally define your own trading partner-specific patterns that can vary from the seeded values. Seeded codes cannot be modified.
Verify system-defined codes that include all ASC X12 (element 678) and EDIFACT (code 2015) Shipment Delivery Pattern Codes that represent either a pattern of specific days of a week or no pattern.
There are four ways that you can set up pricing:
Do not enter pricing information on the Release Management Processing Rules, then let Oracle Order Management use its default logic to determine the price.
Create a price list in Oracle Order Management, then enter this price list on the Release Management Processing Rules at the desired level.
Create a pricing agreement in Oracle Order Management, then enter this pricing agreement on the Release Management Processing Rules at the desired level.
Create a sales order in Oracle Order Management, then enter this sales order on the Release. The status of the sales agreement must be set to active after saving. You can do this by clicking Actions, selecting Progress Order, and setting the status to active.
Within Oracle Inventory, define the inventory items that will be processed by Oracle Release Management.
Within Oracle Inventory, define the customer items that will be processed by Oracle Release Management, their corresponding inventory items, and preference ranking.
Using the Oracle Release Management Processing Rules form, define the Oracle Release Management attributes associated with each Ship-From/Ship-To business entity for which Oracle Release Management will process demand. If terms are not defined at the optional lower levels, they will default from higher levels.
There are four levels where processing rules can be defined:
Ship-From/Customer (mandatory)
Ship-From/Customer Item (optional)
Ship-From/Ship-To (optional)
Ship-From/Ship-To/Customer Item (optional)
There are five categories of processing rules attributes:
Demand Management
Demand Fences
Order Management
CUM Management
General
Using the CUM Upgrade program, assign the correct CUM key to each shipment line for each Ship-From Customer Item if:
The Ship-From/Ship-To business entity is under CUM Management.
The Ship-From Customer Item CUM Management flag is ON.
Shipment date falls on or after the start date of the current CUM period.
For each Ship-From Customer Item under CUM Management, verify the CUM shipped quantity against internal shipment records and external systems (for example, CARaS if this is an Automotive Upgrade, or a legacy system if this is a new installation). Manually verify the following:
The CUM shipped quantity was calculated accurately based on the CUM Management Rule defined for the Ship-From/Ship-To business entity.
The CUM shipped quantity matches the external system CUM shipped quantity after CUM keys are assigned.
The CUM key is active (by default for a new CUM key).
If a CUM Adjustment is needed to synchronize the CUM shipped quantity of a Ship-From Customer Item under CUM Management with that of the external system, use the Customer CUM Workbench form to enter a CUM Adjustment for Starting CUM Value.
This step is needed if:
The CUM shipped quantity does not match the external system CUM shipped quantity after CUM keys are assigned.
The Customer Item ID was not associated with the Release 12 Oracle Shipping detail, which would prevent a CUM key from being assigned.
It might be necessary to define additional code conversions for UOM (unit of measure), a category used in multiple Oracle e-Commerce Gateway transactions.
Existing UOM code conversions should be evaluated to ensure that you have defined all internal and external values to be used on inbound demand transactions. Additional values might be required, both generic and trading partner-specific.
Any new internal value must also be set up within Oracle Inventory, for example UOM conversions.
RLM_SHP_DEL_CODE specifies the days for routine shipments and deliveries. The seed data for Oracle e-Commerce Gateway Code Conversion includes both ANSI X12 (ele. 678) and EDIFACT (code 2015) Shipment Delivery Pattern Codes.
You can define additional generic or Trading Partner-specific Shipment Delivery Pattern Codes. This code conversion enables you to define customer-specific internal Shipment Delivery Pattern Codes using the Release Management Maintain Ship/Delivery Pattern Codes form. They are then mapped to external EDI values using customer keys in Oracle e-Commerce Gateway as needed.
It might be necessary to define trading partner-specific values of Oracle Release Management Data Elements requiring code conversion that are used for inbound demand.
For example, one customer might consider a purpose code of Change to mean a Replacement of a subset of items on a previous schedule; another customer might consider a purpose code of Change to mean a Net Change of all data on a previous schedule. To ensure that the Demand Processor will handle the data from the first situation correctly, a trading partner-specific code conversion for RLM_TRX_PURP must be defined to link the external purpose code of Change to the internal purpose code of Replacement.
The following RLM code conversions are defined for inbound demand, and are used for SPSI, SSSI, and PSQI transactions. New internal values cannot be added, but new generic and trading partner-specific external values can be cross-referenced to existing internal values:
RLM_SCHED_TYPE
RLM_DTL_TYPE
RLM_DTL_SUBTYPRLM_DATE_TYPE
RLM_QTY_TYPE
RLM_TRX_PURP
RLM_SHP_DEL_CODE
Examine each trading partner's EDI Implementation Guide for applicable inbound demand transactions to determine if the seeded values will handle the trading partner's EDI demand properly in the Demand Processor.
For example, Modern Truck 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. If Modern Truck is one of your trading partners, additional code conversions for RLM_ SCHEDULE_TYPE could be set up as follows:
| Internal | External 1 | External 2 | EDI Standard |
|---|---|---|---|
| Sequenced | DELJIT | 242 | EDIFACT |
| Shipping | DELJIT | 241 | EDIFACT |
However, if another trading partner uses 242 with DELJIT to indicate a Kanban Shipping Schedule, you should set up these code conversions using trading partner keys. If not, define trading partner-specific external values for applicable internal values using the Define Code Conversions form.
If you are upgrading from Release 11 to Release 12, enable applicable Oracle e-Commerce Gateway inbound demand transactions (SPSI, SSSI, and PSQI) for each trading partner.
If you are utilizing the Oracle Release Management trading partner Layer, it might be necessary to define additional e-Commerce Gateway Column Rules and corresponding Actions for specific trading partner requirements regarding inbound demand transactions (SPSI, SSSI, and PSQI). Each trading partner implementation guide should be evaluated for gaps between the standard processing and trading partner requirements. See: Oracle e-Commerce Gateway User's Guide.
Evaluate the data storage and processing provided by Oracle Release Management for gaps in trading partner specific requirements for Demand, Order, Shipping, and CUM Management.
If data storage gaps exist, evaluate where the required data should be stored:
Use Descriptive Flexfields for data on inbound demand schedules that needs to be carried through Order Management and Shipping.
Use Trading Partner Flexfields for data on inbound demand schedules that will be referenced in trading partner-specific Workflow customizations.
If processing gaps exist, evaluate where customization of the workflow is needed to accommodate the requirement. See: Oracle Automotive Trading Partner Toolkit User's Guide for details about trading partner specific processing.
The following tables must have the same definition in AOL for Descriptive Flexfield Attributes for the RLM Demand Processor:
Headers
RLM_INTERFACE_HEADERS
RLM_SCHEDULE_HEADERS
OE_ORDER_HEADERS
Lines
RLM_INTERFACE_LINES
RLM_SCHEDULE_LINES
OE_ORDER_LINES
In Oracle Advanced Planning and Scheduling, use the Define Supply Chain Sourcing Rules form to define any sourcing rules required to split demand into multiple inventory organizations. The Demand Processor will use the sourcing rules to split the requirements accordingly.
If you would like to use additional CUM adjustment reasons that are not in the list below, define additional reasons using the Define Transaction Reasons form within Oracle Inventory.
The seeded CUM adjustment reasons are:
Starting CUM: Indicates that this adjustment is the initial cumulative shipped quantity for this CUM entity.
CUM Adjustment: Indicates that the customer has requested a CUM Adjustment because the ship-from organization's cumulative shipped quantity is out of sync with the customer's cumulative shipped/received quantity.
Damaged Goods: Indicates that this adjustment corrects the ship-from organization's cumulative shipped quantity to reflect goods damaged while in transit that must be replaced without reducing the customer's additional demand.
Lost Shipment: Indicates that this adjustment corrects the ship-from organization's cumulative shipped quantity to reflect goods lost while in transit that must be replaced without reducing the customer's additional demand.
Oracle Release Management exception messages can be assigned to message categories that are used to organize the messages in the Exception Report. There are six predefined message categories and new message categories that can be defined and assigned to exception messages as needed.
Using the Application Developer responsibility, navigate to the Application Object Library Lookups form. Query RLM_MESSAGE_CATEGORY Lookup Type. Enter a new code and message. Define as many message categories as needed.
Navigate to the Message Categories form under the Release Management responsibility. On this form you will see all of the Release Management exception messages. The following columns of information are displayed:
Number: The exception number
Text: The text of the exception message
Message Category: The category currently assigned to the message
The following message categories are currently available:
Action messages
Default
Data related issues
Matching criteria related issues
Non-matching criteria related issues
Quantity changes
Newly defined message categories are also available in the list of values.
The Demand Processor will utilize customer, ship-to, bill-to, and warehouse data provided on the inbound schedule to derive the appropriate forecast name for interfacing planning data to Oracle Advanced Planning and Scheduling. The profile option RLM: MRP Forecast Selection List is used to identify the source list consisting of forecast names. The Forecast Source List contains the forecast names and their corresponding inventory organizations.
For each inventory organization that represents a Ship From/Warehouse, create the forecast set and individual forecast name with Customer, Ship-To, and Bill-To attributes. It is not required that all three attributes be specified. It is required, however, that only one forecast name representing a unique criteria combination be included in the Forecast Source List. The Demand Processor searches for the forecast name in the source list in the following way:
For the Ship From specified on the schedule line, look for a forecast name that has the same Customer, Ship To and Bill To.
If no match is found, find a forecast name that has the same Customer and Ship To (Ship To and Forecast Name cannot be null).
If no match is found, find a forecast name that has the same Customer.
If no match is found, issue an error message.
Specify the Forecast Source List that contains all of the forecast names that are candidates to be assigned the inbound forecast demand. It is required that at least one forecast name representing a unique combination of criteria be included in the Forecast Source List. For example, if two forecast names have the same Customer, Ship To, and Bill To and both Forecast Names were included in the Forecast Source List, this is an error. The Demand Processor does not know which forecast name to use.
Although both Forecast Sets and forecast names can be included on a source list, only forecast names should be included in the Forecast Source List. The Demand Process only looks at forecast names and does not expand a Forecast Set to the forecast names associated with it.
Under the System Administrator Responsibility, navigate to the Profile Options form. Set the site value for RLM: MRP Forecast Selection List to the Forecast Source List defined above.
Use the following values to define transaction types 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
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 email)
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
Use the following values to define standards within Oracle XML Gateway:
Standard Code: OAG
Standard Type: OAG
Oracle XML Gateway code conversion provides a method to cross-reference the codes defined in Oracle Applications to codes used by trading partners. See: Oracle XML Gateway User's Guide.
Enable the applicable XML Gateway inbound planning and shipping transactions for each trading partner.