Oracle Applications: Release Management User Reference

Oracle Applications: Release Management
Oracle Application User Reference Manual (Release Management)
Plot No. 35/36, Rajiv Gandhi InfoTech Park, Ph33ase I, MIDC, Hinjewadi, PUNE - 411057, India Tel: +91 20 5652 5000, Fax: +91 20 5652 5001 www.kpitcummins.com
KPIT Cummins Infosystems Limited
Table of Contents
1. Introduction .4 Overview of Oracle Release Management 2. Important Set Ups...5 Step1. Oracle Release Management Profile Options Step2. Define Customers, Addresses and Locations Step3. Define Warehouse Shipping Calendars Step4. Define Customer Receiving Calendars Step5. Define Shipment Delivery Pattern Codes Step6. Define Pricing Step7. Define Inventory Items Step8. Define Customer Items and Cross-References Step9. e-Comm Gateway - Trading Partner Set-Up Step10. Define e-Commerce Gateway Code Conversion Values Step11. e-Comm Gateway - Establishing Customer EDI Communication Step12. Enable Inbound transactions for Trading Partners Step13. Define Release Management Processing Rules Step14. RLM: CUM Management Rules Set-Up Step15. Create and Assign CUM Keys Step16. Verify CUM of Ship-From Customer Items Step17. Enter CUM Adjustment Transactions as Needed Step18.Optionally Define Additional CUM Adjustment Reasons Step19. Optionally Define and/or Assign Message Categories 3. Basic Transactions.71 I. Entering an EDI Schedule Manually II. Manually Process an Inbound EDI Schedule
Release Management Detail Document Page 2 of 100
4. Over View Of Reports and Processors82 I. Demand Status Inquiry Report II. Net Change Report III. Release Management Exceptions Report IV. Release Management Retro Billing Report V. EDI Inbound Transactions VI. Release Management Demand Processor 5. Frequent Issues and Resolution...85
1. Introduction
Overview of Oracle Release Management:
Oracle Release Management automates high volume electronic demand management by continually incorporating customer demand into the order and planning processes. Oracle Release Management validates archives, manages, and reconciles customer planning, shipping, and production sequence schedules with timely updates to sales orders, blanket sales agreements, and forecasts. Defining and applying hierarchical processing rules enables you to determine correct quantities, dates, and other valuable information required to ensure on-time delivery of goods to customers. You can electronically collaborate with customers and manage demand more accurately. Oracle Release Management provides a centralized view of current order status.
2. Important Set Ups
Step1. Oracle Release Management Profile Options

RLM: Debug Mode Determines if a debug file is written for running the Demand Processor Available values are: On: Debug mode is on Off or Null: Debug mode is off The default value is Null (Off). This profile is updatable at all levels. RLM: MRP Forecast Selection List Provides a means to specify the forecast source list that will house all the names of forecasts that are candidates for the inbound Automotive forecast demand items to be assigned. The default value is none. This profile can be set at the Site and Responsibility levels. Note: This profile option is required if you import forecast data into Oracle Advanced Planning and Scheduling using the Demand Time Fence Forecast to Planning. See Processing Rules for more information. RLM: MSC/MRP Default Assignment Set Determines if the Supply Chain Sourcing Rules should be used to derive the ship from Organizations. If these rules should be used (the profile option is set to something other than No Sourcing to be applied) the Demand Processor looks for a unique Sourcing rule for the item. If a unique rule is found, then this is the rule that is used. If more than one rule exists for the item, then the Default Assignment Set designated in the profile option is used to determine which rule should be used. The default is No Sourcing to be applied. This profile is updatable only at the site level. RLM: Print Cum Data on Shipping Documents Determines whether or not CUM Data should be printed on shipping documents. Available values are: Yes: CUM Data is printed on shipping documents No: CUM Data is excluded from shipping documents The default is yes. This profile is updatable at all levels.
RLM: Workflow Enabled Determines whether or not the Demand Processor is enabled to run in workflow mode. Available values are: Yes: The Demand Processor is enabled to run in workflow mode No: The Demand Processor is disabled for workflow mode The default is No. This profile is updatable at all levels. Note: This profile option is required if you import forecast data into Oracle Advanced Planning and Scheduling using the Demand Time Fence Forecast to Planning. See Processing Rules for more information.
Other Necessary Profiles The following profile options from other applications that you must set for full Oracle Release Management functionality. You can set or view the following profile options in Oracle Release Management. The table also indicates whether you (the User) can view or update the profile option and at which System Administrator level the profile options can be updated. The System Administrator level includes User, Responsibility, Application, and Site levels. Profile options are either Optional or Required: Required: Requires you to provide a value Optional: A default value is provided that requires change only if you do not want to accept the default
ECE: DSNO Enabled Specifies whether or not the DSNO transaction is enabled. This profile can only be set at the site level. ECE: INO Enabled Specifies whether or not the INO transaction is enabled at the site level. This profile can only be set at the site and responsibility levels. ECE: Input File Path Specifies the directory where inbound data files are expected. This profile can only be set at the site and responsibility levels. ECE: Output File Path Specifies the directory where outbound interface data files are written. This profile can only be set at the site and responsibility levels. ECE: PSQI Enabled Determines whether or not inbound sequenced shipping schedule transaction is enabled. There is no default value. This profile can only be set at the site and responsibility levels. ECE: SPSI Enabled Determines whether or not inbound planning schedule transaction is enabled.
There is no default value. This profile can only be set at the site and responsibility levels. ECE: SSSI Enabled Determines whether or not inbound shipping schedule transaction is enabled. There is no default value. This profile can only be set at the site and responsibility levels. OM: Invoice Numbering Method Determines whether invoice numbers are automatically generated or mapped to the Delivery name.
Step2. Define Customers, Addresses and Locations

Navigation: Order Management SU> Customers > Customer Standard
Enter the Customer Name in the highlighted field below and click on the 'Find' tab at the bottom right hand Side of the screen in Find Customer Form. Before setting up a new customer, always check to see if the customer already exists or Not.
If the customer does not exist the following decision box is displayed. Select 'New'.
DFF
- Enter the customer name in the ' Name ' field - Customer Number: Enter WWID number supplied by CBS - Account Name: Enter the customer short name for the customer account - In the descriptive flexfield (DFF) under the ' Group Report Code ' field enter 'N/A' this is only used by Palmetto for financial reporting purposes. Click on the 'Classification' tab and Enter in the following fields:
Profile Class: This is a default value Reference: This field is also defaulted by Oracle Type: This is used to say is this an internal or external customer - it should be "External" for most customers. Tax Calculation: "Line" Setup New Customer BILL-TO ADDRESS Choose Address Tab and select New Tab at the bottom of the Form
Site Number: The site number is used to identify each entity. Address: Complete all fields related to the Address i.e. Street, City, Post Code etc... - EDI Location: The IT Department will provide the EDI Location Code. This is used as the link between the customer and Cummins Turbo Technologies for inbound and outbound EDI Messages. Entering in the 'Bill-To' address details: Usage: Click on the list of values and select Bill To Location: This is a free text field and you should enter something that relates to the customer address above Primary & Active Flags: Ensure that both the primary and active flags are checked for addresses that are new or current. The active flag will only be de-activated if the address is no longer in use Click on the 'Open' Button located on the bottom right-hand side of the screen. This will open the screen below and defaults to the 'Details' tab
Location Code: The location code you created in the above step will automatically default in this field Tax Code : Select from List of values the appropriate tax code Payment Terms: The Account Manager will be able to advise the agreed payment terms with the customer. Using the list of values select the appropriate payment term code Sales Person: CTT doesnt use sales persons but since it is mandatory field a dummy sales person is set-up in the system. Select the value No Sales Credit from the LOV
Click on the 'Order Management' tab and complete the set ups listed below:
Price List: Select the appropriate customer price list and Save the changes CUSTOMER 'SHIP-TO' ADDRESS
In the 'Customers-Standard' form click the "New" button
Enter the details in the 'Customer Addresses' window as follows:
Site Number: This will be automatically created Address: Complete all fields related to the Address i.e. Street, City, Post Code etc... EDI Location: The IT Department will provide the EDI Location Code. This is used as the link between the customer and Cummins Turbo Technologies for inbound and outbound EDI Messages Usage: Click on the list of values and select Ship To Location: This is a free text field and you should enter something that relates to the customer address above Primary & Active Flags: Ensure that both the primary and active flags are checked for addresses that are new or current. The active flag will only be de-activated if the address is no longer in use Click on 'Open' Button located on the bottom right-hand side of the screen. This will open the screen below and defaults to the 'Details' tab Location Code: The location code you created in the above Step will automatically default in this field
Click on the 'Order Management' tab and complete the set ups listed below:
Freight Terms: Select the appropriate freight term. In CTT it will be collect
FOB: Select FOB (Free on Board) from the list of values. In CTT it is usually Ex-works which signifies that the responsibility transfer happens when we ship the goods Warehouse: Select from LOV the warehouse from where the goods will be shipped to this customer ship-to address. It will default on the sales order Ship Method: This is the customer selected freight carrier Request Date Type: This is also known as the 'Order Date Type' which appears on the Sales Order. This field can either be set to 'Arrival' or 'Ship' based upon what customer uses the request date as. If the customer request date is the date when the customer expects the goods to arrive we should set it as Arrival. If the request date is the date when customer wants the goods to be shipped select Ship as the value Save the changes
Step3. Define Warehouse Shipping Calendars

This is to set up a calendar to represent warehouse shipping days. You can set up one shipping calendar for all warehouses or define separate calendars for each warehouse or group of warehouses. Once you have defined the shipping calendar, assign it to the warehouse on the Assign Calendars window (N)OM Setup shipping Calendars Enter
Enter Name for the Workday Calendar Enter Description for the Workday Calendar Choose Quarterly Type from the List of values Choose Calendar Date Range from and To, date range should be from Monday to Monday
Enter the Exception if any for holidays Save the entries and choose the Build from Tools Menu to build the Calendar
Assigning the Calendar to the Shipping Organization OM Setup shipping Calendars Assign
Choose the Trading Partner Type (Organization) from the Drop Down list Enter the Name of the Trading Partner (Holset US Palmetto Plant) from the List of Values Choose the Calendar usage (Shipping) from the Drop Down List Choose the Calendar Code (HOLSET_US) from the List of Values which is already defined and intended to use for this Trading Partner for Shipping usage Choose the Site Name from the List of Values and it will be defaulted from the Trading Partner Name Choose the Calendar Code for the Site Name Check the Enabled Check Box
Step4. Define Customer Receiving Calendars

This is to set up a calendar to represent customer receiving days. You can set up one receiving calendar individual customers or customer ship-to address or, share the calendar among customers. Once you define the receiving calendar, assign it to the customer or customer ship-to on the Assign Calendars window. (N)OM Setup shipping Calendars Enter Enter Name for the Workday Calendar Enter Description for the Workday Calendar Choose Quarterly Type from the List of values Choose Calendar Date Range from and To, date range should be from Monday to Monday
Assigning the Calendar to the Trading Partner (Customer) (N)OM Setup shipping Calendars Assign
Choose the Trading Partner Type (Customer) from the Drop Down list Enter the Name of the Trading Partner (East Coast Diesel Engine) from the List of Values Choose the Calendar usage (Receiving) from the Drop Down List Choose the Calendar Code (EC Cus Cal) from the List of Values which is already defined and intended to use for this Trading Partner for Receiving Choose the Site Name from the List of Values and it will be defaulted from the Trading Partner Name Choose the Calendar Code for the Site Name Check the Enabled Check Box
Step5. Define Shipment Delivery Pattern Codes

Define your own ship delivery pattern rules on the maintain ship/delivery pattern codes window. This code can be used as a default on the processing rules window for either single or multiple customers. If a customer uses a standard code in a non-standard way, you can build a custom ship delivery pattern code to represent this non-standard use. You can use the EDI Gateway code conversion functionality to map the code to the code you created. (N) RLM Setup Maintain Ship Delivery Patterns
Enter a unique pattern Code Name (A) Enter a Description of the new pattern (1/2 Tuesday and 1/2 Thursday) - Enter daily percentages in the appropriate fields under Weekday Percent ( 50% on Tuesday and 50% on Thursday) These must equal either 100 or zero. Zero is used to indicate a pattern code for Which you dont want to change the requested date the customer transmitted. Oracle Release Management will not change quantities or scheduled ship dates for any demand that uses this pattern code. Select the checkbox if the ship delivery pattern code is Updatable Save your changes
Step6. Define Pricing (Price List Setup)

Price lists relate a selling price to a product. Price lists consist of price list lines, pricing Attributes, a secondary price list and include information such as the price list name, effective dates, currency, rounding factor, and shipping defaults such as freight terms and freight carrier. You can create multiple price lists. Alternatively, you may enter a specific price list on the order header or at the order line level. For each price list, you can also assign a secondary price list, which the pricing engine searches when it cannot find an item on the primary list. Only one secondary price list will be searched for each primary list. There are four ways that you can set up pricing: a. b. c. Do not enter pricing information on the Release Management Processing Rules, and then let Oracle Order Management use its default logic to determine the price. Create a price list in Oracle Order Management, and then enter this price list on the Release Management Processing Rules at the desired level. Create a pricing agreement in Oracle Order Management, and then enter this pricing agreement on the Release Management Processing Rules at the desired level.
d.
Create a blanket sales order in Oracle Order Management, and then enter this blanket sales order on the Release.
(N) Order Management SU > Pricing > Price Lists > Price List Setup
Name: Type in the Price List Name using the standard set by business Price list naming convention: The naming convention for a price list is as follows: <3 digit Inventory Org> <Customer or Group Name> <Currency><Year> Description: Enter a description Currency: Select the Currency using the list of values Effective Dates: Today's date should default into this section Save the changes Click on the 'List Lines' tab
Product Context: Click on the list of values and 'Item' will default into the field Product Attribute: Using the list of values select Item Number Product Value: Type in the Part Number Product Description: The product description will be retrieved and displayed from the master item set up UOM: EA (Each) will default in the field i.e. one of Line Type: Price List Line will default Application Method: Unit Price will default Value: Enter the agreed Selling Price Start Date: Enter a start date Save and close
Step7. Define Inventory Items:

(N) Inv Super User Items Master Items
Enter the Item Number and Description Go to Tools Menu and Choose Copy from Choose the Template from the list of Values Press Done Button, the selected template will be applied to the Item
Once the Template is applied the Item is to be assigned to the Organization where in you want to use the Item. Go to Tools Menu and select Organization Assignment Organization assignment Form Opens and Check the Assigned check box opposite to the Organization where you want to use the Item
Step8. Define Customer Items and Cross-References

Customer Item Cross References is the cross references between your inventory items and the customer item numbers. This cross reference is vital as parts are entered using the customers part number and Oracle needs to know what Internal part number it relates too. It is also a vital set-up as part of enabling EDI communication between Organization and the customer. (N) Order Management User Items Customer Item Customer Item
Select the Organization from Find Organizations popup Window for which You are setting up the cross references.
- Click on 'New' button to set up a new item part number cross reference.
In the 'Commodity' tab enter or select the customer in the 'Customer Name' Field from the List of Values. Enter the "customer item number" in the 'Customer item' field.
Enter/select the commodity code in the 'Code' field. The commodity code is used to group customer items and is set-up separately in the inventory module. Each local function will have their own commodity codes.
Click on the 'Address' radio button , to flag the customer item for the Address Level The customer item can be set-up at three levels. o Customer: The customer item defined at customer level will be used for all the ship-to addresses for that customer o Customer ship-to address: The customer item defined at a ship-to address level can be used for that address only o Address category (group of addresses) level: Some of the globally operating customers might be calling or naming the same item differently across its various operations. Thus the customer might have different names for the same customer item across its various ship-to entities and it becomes necessary to define the customer item at ship-to address level
Click on the 'Cross Reference' tab
Item: Enter/select the part number Rank: Enter 1 Active flag: Select the flag to make the customer item effective Save and close
Ranks are used if there can be alternate or substitute inventory items for the customer item. Thus the substitute items can be entered in the same form and given ranks which will identify which item will be given priority over the other. As an example where it can be used: if the ordered item is not available when placing a sales order then the substitute item can be used in lieu, if the customer agrees.
Querying Customer Item Cross References (N) Order Management User Items Customer Item Customer Item Cross References
Choose the Customer Item from list of values for which Cross References defined - Press Find Button
Customer Item and its Cross Reference Item will be Displayed as in the above Form
Step9. e-Comm Gateway - Trading Partner Set-Up

In the Oracle e-Commerce Gateway, the term "Trading Partner" refers to an entity such as a customer, supplier or bank - at a particular location or address - with which you exchanges routine commercial documents via EDI. Since a given entity may have several locations, you must define one Trading Partner for each customer address, supplier site, or bank branch as required for processing by the Oracle e-Commerce Gateway. Trading Partner data must be set up both in your EDI translator software and in the Oracle e-Commerce Gateway. The set up parameters are quite different to satisfy their particular needs. In the Oracle e-Commerce Gateway, Trading Partner data is used to: Link a particular address location in Oracle Applications to the Trading Partner definition in the Oracle e-Commerce Gateway Provide a means of telling the EDI Translator which Trading Partner data maps and mailbox are to be used (outbound transactions) Enable specific transactions for Trading Partners Determine if the EDI status of a Trading Partner is Test or Production
(N) e-Commerce gateway SU > Setup > Trading Partners
Enter the customer 'Group' name and description Save the Form Press New Button
Partner: Enter the name and a description for the trading partner (i.e. the customer) Customer: Enter/select the customer name from the List of Values (LOV) Site: Select the customer site again from the LOV EDI Location: EDI location will default from the customer set-up and is supplied by the IT team. Click on the Details tab and enter details as follows.
NOTE: By selecting the appropriate 'Transactions' we can enable ASN,
Invoices and Order Acknowledgements to be sent to the customer via EDI.
Transaction:
This is the type of transaction the customer
may use Type: This will default based on the Transaction selected above Translator Code: The customer will provide the translator code (example: HOEiDLFVOL01622) Document Standard: Select one of the standards advised by the customer Map: This will default based on the combination of Transaction/Document Standard Enabled Flag: Double check the flag field is ticked, otherwise that particular transaction type will be no be active Save and close
Step10. Define e-Commerce Gateway Code Conversion Values

The Oracle e-Commerce Gateway Code Conversion Module is a flexible and extremely powerful feature used to reconcile (convert) values from your trading partners application or industry standard to values stored within Oracle Applications.
Code conversion is a common problem in any integration scenario where coded values such as Unit of Measure Code or Currency Code are represented differently in each of the applications being integrated. Many times, rules for performing these conversions can become quite complicated. If you are integrating with trading partners using multiple applications and/or standards, a simple lookup table with to and from columns will not be sufficient. Advanced code conversion rules based on trading partner, industry standard, or transaction directions are required to support these complex application integration relationships. Code conversion rules in Oracle e-Commerce Gateway are defined as a set of to and from values plus additional attributes to determine specific code conversion processing behavior. Key features of the Oracle e-Commerce Gateway Code Conversion Module include: User defined code conversion categories (e.g. UOM, Currency Code). User defined activation/assignment of code conversion for specific data elements. Code conversion based on a user defined multi-level hierarchy. Code conversion based on trading partner standard (e.g. ASC X12, EDIFACT). Code conversion based on direction of transaction (inbound, outbound, or both). One-to-Many, Many-to-One conversions.
To enable code conversion for specific data elements within a transaction, there are three easy setup steps: Define Code Conversion Category
Define Code Conversion Values Assign Code Conversion Category
Define Code Conversion Category allows you to enter all of the categories applicable to your business processing environment. A category is defined as a group of code conversion rules applicable to a single data element. Many predefined categories are included in Oracle e-Commerce Gateway. You may choose to implement these predefined categories or define your own. Assign Code Conversion Category associates a category (including all rules associated with that category) with a specific data element in a transaction. This assignment will enable code conversion for the transaction/data element.
Inbound Code Conversion Processing During inbound transaction processing, inbound files are processed based on the interface file definition in Oracle e-Commerce Gateway. The interface file definition, as defined in the Interface File Definition form, will determine file layout and structure. It will also identify External Values (1-5) used for inbound code conversion processing. Code conversion category data entered in the Assign Code Conversion Category form determine which fields require inbound code conversion processing. Key values are also derived from data in this form. Inbound code conversion processing uses: Code Conversion Category based on Assign Code Conversion Category definitions. Direction based on transaction type. Key (1-5) values from the interface file. Code Conversion External Values (1-5) from the interface file.
Outbound Code Conversion Processing During outbound transaction processing, code conversion category data entered in the Assign Code Conversion Category form determine which
fields require outbound code conversion processing. Key values are also derived from data in this form. Outbound code conversion processing uses: Code Conversion Category based on Assign Code Conversion Category definitions. Direction based on transaction type. Key (1-5) values from the transaction record. Internal Values from the transaction record.
Defining Code Conversion Categories: A category is a label assigned to a group of code conversion rules in the Code Conversion Values window. For example, the UOM category contains all units of measure code conversion rules.
(N) e-Commerce Gateway SU Setup Code Conversion Define Code Conversion Category
- Navigate to the Code Conversion Categories window - Enter the category code and description - To assign code conversion values to key attributes (such as a trading partner), enable one or more search keys Assign code conversion categories (N) e-Commerce Gateway SU Setup Code Conversion Assign Code Conversion Category
- Navigate to the Assign Categories window - Select a transaction (DSNO) - Select a map ID (WSH_DSNO_FF) - Select an output level that represents a level in the hierarchy of data for that Transaction (1: Delivery) - Assign a code conversion category to activate code conversion for the view or Application open interface column (FOB) - Specify a column (Key 1 through Key 5) to define each key. This is used during Code conversion processing to derive key values
Step11. e-Comm Gateway - Establishing Customer EDI Communication

To provide guidance in establishing Customer EDI communication, EDI initiation request can come from two sources. 1. From the customer directly 2. From Customer Service Representatives
OBTAIN CUSTOMER EDI INFORMATION The following information is needed prior to the initiation of a customer EDI trading partner master. a. Customer Name i.e. Customer EDI Trading Partner ID b. Customer EDI Qualifier c. Customer Number as entered in Oracle Customer Standard. d. Customer EDI 3rd party VAN e. Customer EDI contact name, phone number, email address f. Facility EDI Trading Partner ID g. Customer 'Ship-To' site & location. (The 'site' used on the sales order)
Step 12: Enable Inbound transactions for Trading Partners

Once data file directories, trading partner information, code conversions, and optional customizations of interface data file formats have been performed, use Oracle applications Standard Request Submission to run extract programs for outbound transactions and import programs for inbound transactions. Enable Inbound Planning (SPSI), Shipping (SSSI) and Production Sequence Schedules (PSQI) for each applicable Trading Partner. Specify which EDI Standard is used for the transaction.
Step13: Define Release Management Processing Rules

The Demand Processor is an Oracle Open Interface that provides complete defaulting, derivation, and validation for inbound demand schedules regardless of their source. The Demand Processor can process customer demand schedules from diverse sources including:
EDI planning, shipping, and production sequence schedules processed through the Oracle e-Commerce Gateway XML planning and shipping schedules processed through the Oracle XML Gateway Manually entered schedules via Oracle Release Management Workbench External system schedules loaded into the Demand Processor Interface via a custom process
Processing Rule Setup: (N)Release Management SU> Set up >Processing Rules
Select the Organization in the 'Ship from Org' field and click on the 'New' button if you are setting up the Processing Rules for the first time. If you are
making an amendment also enter in the customer name in the 'Customer Name' field and click on 'Find'.
The RLM schedule 'Processing Rules' are defined as Customer Rules, Address Rules and/ or Item Rules. This means a processing rule set up at the customer level can be defaulted to all its associated addresses. A processing rule set up at address level can be defaulted to all associated items for that address. A processing rule set up at item level will impact that particular item only. At CTT for EDI schedules we use one Sales Order for each customer item number that will be ordered. The majority of the Processing Rules is set-up at the ADDRESS LEVEL and will be defaulted to all associated items set up under that particular address. However: Matching Logic is set at the 'Customer Rules' level. As we use one sales order per part number we will need to go in to each 'Item Rule' to change the Sales Order Number the item will appear on when exported to the Order Management Module. Enter in the following details: Enter the following details:
Code: Enter/select the ship from Org Name: Enter/select the customer name Location Code: Place the cursor in the Location Code field and select the customers Location Code from the LOV. The location code is the EDI location code entered at the time of creating the customer ship-to address at the time of customer set-up. It is used to link the inbound EDI in the Trading Site to RLM. Customer Item: Enter the customer items in the 'Items at Address Level' field. Click on 'Save'. Customer Level Matching Logic: Click on the 'Matching Logic' button for the customer (next to the 'Customer Rules' button).The matching logic is used to match the incoming
schedule in Release Management with the previous schedule processed in Order Management.
Leave the mandatory attributes as displayed. These are defaulted by Oracle. Under 'Optional Match Attributes' make sure the check boxes for 'Customer Request Date' are ticked as shown above. Address Level Click 'OK' and on the main form click on 'Address Rules' button
A pop-up box will appear asking if you want to default from the settings above (ie any settings you created at the customer level to also be used at the Address level and click on Yes'. Click on the 'Demand Management' tab and enter the details as follows.
Consume Demand Hierarchy: This setting may be customer/ trading partner specific. However if the customer does not specify the
recommended setting is: "Planning, Shipping and Sequenced". It signifies the priority of the incoming replacement schedules over the existing schedules. The higher ranking schedules are replaced by the lower ranking ones. What this means is that if you get multiple schedule types from a given trading partner the sequenced schedule will have the highest priority and will overlay any shipping or planning schedule you may have already received from the customer and likewise you get a shipping schedule it will have higher priority than the planning schedule ATS Pre-horizon Disposition: This setting also can be customer/ trading partner specific. However if the customer does not specify the recommended setting is: "Remain on file" The purpose of this field is to control what Oracle does with demand that is already in OM with a date earlier then the current date (ie past due/ back order demand) . This can be a dangerous set-up because it can cause demand to be removed from the order board if not set up correctly. It is important to work with the customer to understand how they wish their EDI to be handled. The GIEA Program Office will work any local team if needed. For any Cummins entity that is a customer of CTT the correct setting is "Remain on file". Default Ship Delivery Pattern: Specifies the shipping pattern so that the demand processor calculates and suggests the day on which shipping can be done. Click On Demand Fences Tab:
Enter the time fences as per business rules. This setting is dependent upon the customer and the local entity rules. Below is an explanation of the various Demand Fences we have available. Frozen: A frozen fence prevents new demand in the Demand Processor from changing the existing Sales Order demand. If you use the frozen time fence - no change in demand will be allowed and any customer schedule with any change in this period will be rejected. Because a customers schedule can be rejected it is recommended that if you use this setting it is kept to a maximum of 5 days. Firm: A firm fence overrides the customer demand status by updating to the Sales Order within Order Management as firm demand (available to ship) for any given date. Oracle will do this regardless of the customerspecified status on the inbound schedule. Forecast (Order Mgt.): A forecast fence places the demand on to the Sales Order within Order Management as forecast demand (not available to ship). Again Oracle does this regardless of the customer-specified status on the inbound schedule. Forecast (Planning): A forecast fence to planning overrides the customer demand status by updating Oracle's Advanced Planning and Scheduling as Forecast, regardless of the customer-specified status on the schedule. (ie the demand is deemed forecast and goes directly into a forecast planning set and not on to a sales order). Note: Manually entered schedules are not affected by Frozen and Firm Demand Fences.
Click on the 'Order Management' tab:
Sales Order: Do not enter any value here as we set this at the 'Item Level' Intransit Time: Enter in "0" as intransit's will either be calculated using CUM Management or within Oracle Order Management. Intransit Calculation Basis: If the customer sends CUM Data this should be set to "Customer CUM" otherwise set it to 'Shipped Lines'. PLEASE NOTE: If the customer does not send CUM data, set the intransit Calculation Basis to "Shipped Lines" but do not use the 'frozen time' fence or an error will occur. Due to how Oracle calculates customer schedules; it will appear that the order board has 'dropped' customer demand.
CUM Management: Click on the 'CUM Management' Tab (Customers who send CUM data with Schedules). CUM Management is allows CTT to 'net-off' those parts that have been dispatched and are currently on route to the customer however the customer schedule still reflects the items as outstanding. CUM management therefore prevents Oracle thinking the customer still wants these parts adding the demand to the order board - therefore over stating the demand.
CUM Management Type: Select "CUM By Date/PO". The option you choose will depend upon how your customer sends the information however most customers use the 'CUM by Date/PO' setting. This means the CUM total the customer transmits will start on a particular date for a particular PO. The customer will re-set this annually. It is therefore paramount that reset their total within Oracle according or else there will be a miscalculation of CUM. CUM Org Level: Select from the LOV the appropriate CUM org level. In our case it will be "Ship-To/Ship-From". Shipment Rule Code: Select "As of Current Shipment". This will take into consideration all outstanding in-transit's in the Cumulative Management suite. General Tab: Click on the 'General' Tab.
Assigned Supplier Code: Enter supplier code in the Assigned supplier code field. This will be given to CTT by the customer as it represents a number the customer uses to identify CTT supplier. Click on 'OK' and 'Save'.
Item Level On the main form screen click on 'Item Rules' button and the following box will appear; click 'Yes' and the 'Address Level' set-ups will default to the 'Item level'.
Click on 'Order management' tab and enter the Sales Order number in the 'Sales Order'.
Please Note: CTT has one sales order per part number, so this final step is required for every item entered. Click on the 'OK' button and save.
Step14: RLM: CUM Management Rules Set-Up

To demonstrate the necessary steps to setup Cumulative Management for EDI customers. CUM Management is there to handle the difference in time from when an order is shipped and when it is received in by the customer. It does this by netting off goods shipped to date to the customer against the quantity the customer says they have received. (N) Release Management SU > CUM workbench
In the 'Find CUM Details' window enter in the following details: Ship from Org: Select CPP Unit Customer Name: Enter/select from the LOV Click on 'Find'
Enter/select the customer items and click on 'Cum Key' button. The following screen appears.
Click on the 'Create Cum Keys' button. Ensure the following fields are populated:
CUM Management Type: Defaulted from processing rules set-up.
CUM Org level: Defaulted from processing rules set-up. Customer UOM: Defaulted from processing rules set-up. Site Use Location: Defaulted from processing rules set-up. CUM Start Fate: Enter in the CUM start date. Cust Purchase Order: Enter in the customer purchase order number. Click OK and Save. A note APP-RLM-22633: A new CUM Key ID is created appears and Click OK.
The following screen shows new active CUM key with qty and CUM start date.
Making an Adjustment to the CUM To enter or amend the cumulative quantity click on "Enter Adjustments" button on the bottom right hand corner of the screen. Note: The Cumulative quantity is the quantity that has been shipped to the customer. The CUM qty will be re-set at the start of every year- or in synchronization with the customer re-setting their CUM Key Total (i.e. the total quantity the customer has received to-date). The need to re-set or make adjustments can come about if there is a mismatch between the quantity that is in transit, the quantity the customer recognizes as having received and the quantity that has been shipped.
Enter the Adjustment Quantity (if you wish to reduce an existing cumulative quantity, enter a minus sign before the figure. i.e. -30 to reduce by 30). Using the list of values, select a 'Reason Code' for the adjustment.
Click on OK The adjusted qty appears on the CUM key details form as follows.
Save and Close the Form
Step 15: Create and Assign CUM Keys

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
Step 16: Verify CUM of Ship-From Customer Items

For each Ship-From Customer Item under CUM Management, verify the CUM shipped quantity against internal shipment records and external systems
(e.g. 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)
Step 17: Enter CUM Adjustment Transactions as Needed

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 (e.g. some shipments pertaining to the CUM Period were not made under Release 11 Oracle Shipping); The Customer Item ID was not associated with the Release 11 Oracle Shipping detail, which would prevent a CUM Key from being assigned.
Step 18: Optionally Define Additional CUM Adjustment Reasons

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 organizations cumulative shipped
quantity is out of sync with the customers cumulative shipped/received quantity. Damaged Goods: Indicates that this adjustment corrects the ship-from Organizations cumulative shipped quantity to reflect goods damaged while in transit that must be replaced without reducing the customers additional demand. Lost Shipment: Indicates that this adjustment corrects the ship-from organizations cumulative shipped quantity to reflect goods lost while in transit that must be replaced without reducing the customers additional demand.
Step 19: Optionally Define and/or Assign Message Categories

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. Define Message Categories 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. Setup Message Categories 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
3. Basic Transactions I. Entering an EDI Schedule Manually
To demonstrate the necessary steps to create a manual EDI schedule within Release Management. Note: If the customer drops in demand via EDI inside the frozen time fence, those orders will create exceptions within the Release Management Workbench; when the EDI schedule is processed. An alert will be sent to the CSR and the CSR in turn can send a notification to Materials to approve the customer 'drop-in'. If approval is given a manual release will have to be created by the CSR so that the customer demand will appear on the order board within Order Management. (N) Release Management SU > Release Management Workbench > Public Queries
Click on the "+" icon on the toolbar to create a new manual schedule and follow steps listed below.
Schedule number: This is a free text field and is used to identify the schedule. The following naming convention should be observed: customer short name _ day _ month _ year Type: Using the List of Values select "Planning/Release". Purpose: If this is a new schedule then the schedule purpose is "ADD". However if the schedule is an update then the purpose is "REPLACE". Horizon Dates: These are the start and end dates for the schedule. A Calendar Option is available using the list of values. Horizon 'End Date': This should be greater than the required dates (to be on the safe side select 12 months on). Customer Name: Using the List of Values select the appropriate customer (taken from the customer standard) Customer Number: This will default in based on the customer from the customer standard. Address: Using the list of values select the correct Ship To Address. If this is a manual release for an EDI Customer you can leave the Customer Address blank and enter in the Location code instead. You should only select a ship to address associated with the customer Bill-To. Picking the wrong ship to address not associated with a customer bill-to will cause the schedule to fail when submitted to the demand stream processor. Click on the 'Lines' radio button at the top of the screen. Trading Partner Code: Select the Trading Partner Code from the List of Values (for Inbound it is CPPiDLFJEP).
Trading Partner Location: Select the Trading Partner Location from the List of Values. Click on the 'Lines' radio button at the top of the screen
Org: Enter/select the Organization (eg; CPP = Palmetto, TSH = GOMS, WTP = Wuxi). Ship To: Click on the LOV and select the ship-to address for the customer. Cust Item: Enter the customer item. When adding or replacing an EDI schedule the norm is just to add firm demand, however occasionally forecast will also need to be entered. To add Firm or forecast demand, place your cursor in the 'Line' field and enter the following details: Detail type: Select whether you are entering: Frozen, Firm or Forecast demand. The two types we use are Firm or MRP forecast. The Firm demand once processed shall go on the order board within Order Management whilst the MRP Forecast will go to the forecast set and used for MRP Planning. Sub Type: This is the buckets of demand and can be: Day, Weekly or Monthly. From the LOV select "Day" for firm demand and what ever is appropriate for the MRP forecast.
Qty Type: There are two types 'Cumulative' or 'Actual'. If you are using CUM management for any customer the Qty Type is "Cumulative," for all other customers select "Actual" from the LOV. Qty: Enter total number required. Date Type: Select either "Deliver" or "Ship" depending on whether customer needs the goods to be delivered by or shipped on the specified day. Start Date: The start date will be populated dependent upon the Horizon Dates and the Sub-Type however it can be over written accordingly. Now click on 'Save'. The line number(s) will be generated and visible on your screen. Go to the 'Tools' menu, choose 'Submit Demand Processor', and then this screen below appears. Select 'OK', followed by clicking the 'Submit' button.
In the toolbar select 'View' then 'My Requests' and click on the 'Find' button to see if the demand process has completed successfully.
To view a processed schedule navigate back to the Schedule Summary (N) Release Management Workbench > Public Queries > Schedules Processed
In the 'Schedule Summary Form' select from the left hand menu "Schedules processed". Your customer schedule should be displayed. If you do not see it, select "Schedules with Error" from the left hand menu and complete following steps.
Click on the 'Exceptions' radio button to view the 'Warnings and Error Messages'.
Click on the 'pencil' icon in the toolbar to see the complete exception notification in full.
Work on the error(s) and re-submit to the demand stream processor.
II. Manually Process an Inbound EDI Schedule (Processing an EDI file into Release Management)
To demonstrate the necessary steps to manually process a Customer / Trading Partner inbound EDI order file into the Release Management Workbench. Also demonstrated is the necessary steps to process a Customer / Trading Partner EDI File schedule that is in the Release Management Workbench. Any errors or exceptions will need to be resolved prior to the Materials Department processing of MRP so all customer order demand has been loaded into the sales orders and forecast set. (N) Release Management User>Process Inbound Transactions
Select "Single Request" and click on 'OK'
Click on the LOV by the 'Name' field the 'Parameters' window opens
Enter the following details:
Inbound File Path: Enter the directory path to where the inbound file is stored. Inbound File Name: Enter the inbound file name. Transaction Type: Select transaction type from list of values.e.g for inbound planning schedule it is "SPSI". Map Code: Enter the map code.e.g for Inbound Planning schedule the map code might be "RLM_SPSI_FF". Execute DSP flag: Enter "No" if we want to run demand processor separately.
Click on the 'OK' button.
Click on 'Submit' button and then go to the menu option 'View' on the tool bar, 'View Requests' and check that your request completed successfully. This does not process the customer schedule it only brings the customer demand schedule into the Release Management Workbench. Go to the menu option 'View' on the tool bar, 'View Requests' and check that your request completed successfully. NOTE: This does not process the customer schedule it only brings the customer demand schedule into the Release Management Workbench.
Go to the Release Management Workbench to view the Schedule Summary
4. Overview of Reports and Processors

I. Demand Status Inquiry Report The Demand Status Inquiry Report reports on netted demand, in the context of CUM Management and current resource authorizations issued by trading partners. Use this report to get a detailed picture of sales order demand or blanket sales agreement demand for a particular warehouse, customer, customer ship-to, or item in Order Management. The Demand Status Inquiry Report prints the Firm and Forecast Requirements from Order Management. This report includes information such as the customer item, requirement date, order number, address abbreviation, unit of measure, required quantity, shipped quantity, cancelled quantity, pick released quantity, back-ordered quantity, invoiced quantity, job number, production sequence number.
II. Net Change Report The Net Change Report will display any changes that a trading partner has made to requirements based on a comparison of any two schedules. Use this report to track increases or decreases in requirements from the trading partner. This better enables you to monitor requirement fluctuations for seasonal or sporadic changes. With this report, you can monitor changes by customer, customer ship-to, item, or item range. You can define a percentage of change acceptable and report only those items which change outside of the tolerance limits. The information contained in this report is obtained from archived schedule data within Release Management. This report can only be run for those schedules which have been successfully validated and archived. III. Release Management Exceptions Report The Release Management Exceptions Report provides explanatory information for errors generated when a problem is encountered during demand processing. Some examples of exceptions generated when requirements have not been met are:
Customers, billing and shipping addresses must exist in Accounts Receivables, Orders, including sales order and Order Type, or Blanket Sales Agreement and Blanket Agreement Type, must already exist in Order Management, Items must be active items defined in Inventory, Forecast names must be defined in Advanced Planning and Scheduling, Redundant firm requirements are encountered, or Discrepancy in the CUM. This report prints a report cover page section and a report main section which Includes: Request ID and schedule header identifiers, Sales order number, sales order type and message category, or Blanket sales agreement number, blanket sales agreement type, and message category Schedule line identifiers and exception message text, Optional detailed exception text IV. Release Management Retro Billing Report The Release Management Retro Billing Report identifies adjustments to already invoiced items. This report enables you to generate a list of invoices that may be eligible for retroactive billing. Based on old price versus new price, this report identifies the variance and possible associated adjustments. After invoicing, you must manually adjust the customers account balance to reflect the price change, and you may need to notify the customer via credit or debit memos. V. EDI Inbound Transactions The EDI Inbound Transactions concurrent program enables you to process an EDI transaction and load Release Management interface tables manually. VI. Release Management Demand Processor Release Managements processing engine, the Demand Processor is an Open Interface that provides complete defaulting, derivation, and validation
for inbound demand schedules regardless of their source. The Demand Processor can process customer demand schedules from diverse sources, including: EDI planning, shipping, and production sequence schedules processed through the e-Commerce Gateway XML planning and shipping schedules processed through the XML Gateway Manually entered schedules via the Release Management workbench External system schedules loaded into the Demand Processor Interface via a custom process
The Demand Processor performs the following: Defaulting, Derivation, and Validation of schedule Archive validated schedule Manage New Demand: CUM discrepancy check, cumulative to discrete demand quantity conversion, application of Supply Chain Sourcing Rules, application of delivery pattern rule and lead time offset to calculate ship/delivery dates, check customer's receipt or shipment to calculate in-transit, application of frozen, firm and forecast fences, aggregation of demand, and rounding to standard pack quantity using the Processing Rules in effect for a particular ship-from, customer, ship-to, or customer item. Reconcile Old/New Demand: cancellation of old demand notauthorized-to-ship before the system date (formerly Schedule Horizon Start Date), processing appropriate for schedule purpose code, getting eligible and matching existing demand, performing reconciliation of customer and supplier shipments, reconciliation of Past Due firm demand, reconciliation of Restricted demand, matching of old/new demand, and updating the sales order or the release orders forecast. The Demand Processor generates appropriate warning and error exceptions and informational messages during each step.
5. Frequent Issues and Resolution

1. Functional Description from bug The CUM key and quantity not getting updated from Release Management (RLM) during Interface Trip Stop process, while interfacing shipped delivery detail, when Earliest Ship Date is not null on Order Lines Technical Description from Bug The flow is: With a not null value of Earliest_Ship_Date in OM, while ITS is run for a shipped delivery detail, it will complete the OM interface and then a call to RLM is made, which in turn will call OM process order group API to update the RLM specific attributes on OM order line for a RLM sourced order line. While RLM calls OM process order api, it was setting the p_x_line_tbl with default value of G_MISS_LINE_TBL and then populating the RLM specific attributes to be updated on order line, in which there Earliest_Ship_Date was not included, but even in G_MISS_LINE_TBL, this attribute was not present, resulting in a NULL value of it instead of FND_API.G_Miss_Date when called from RLM. Later, during the processing for an Update operation, in OE_Order_Pvt.Lines, while a call to OE_Line_Util.Complete_record was made, Earliest_Ship_Date was not included because of which, Earliest_Ship_Date (with an expected value of G_MISS_DATE from RLM) could not get original non-null database
value
copied
to
it.
Due to this, later in the OE_Line_Util.Apply_Attribute_Changes procedure, when a comparision was done between the new and the old picture of earliest_Ship_Date, it was different (null in new picture and not-null value in old database picture) and a Shipping Delayed request got logged, which resulted a call to Update_Shipping_Attributes shipping api, and that failed for update request because it was already interfaced to OM. Solution: To implement the solution, please execute the following steps: The following action plan must be applied and tested in a TEST environment prior to applying it in a PRODUCTION instance. 1. Apply patch 8479339 - CUM Key and Quantity not getting updated from Release Management (RLM) during Interface Trip Stop processing for a shipped delivery detail when Earliest Ship Date is not null on Order Lines 2. Confirm that that the correct file versions have been installed. OEXPORDB.pls 115.44.11510.12 OEXPORDS.pls 115.154.11510.15 OEXULINB.pls 115.596.11510.77 OEXULINS.pls 115.81.11510.6 the following commands can be used to verify this: strings -a $ONT_TOP/patch/115/sql/OEXPORDB.pls|grep '$Header' strings -a $ONT_TOP/patch/115/sql/OEXPORDS.pls|grep '$Header' strings -a $ONT_TOP/patch/115/sql/OEXULINB.pls|grep '$Header' strings -a $ONT_TOP/patch/115/sql/OEXULINS.pls|grep '$Header' 3. Once the patch has been installed: Run EITHER: a. Depart Ship Notice Outbound (DSNO) - concurrent process for the order line OR b. Interface Trip Stop for the delivery This will ensure that the Cumulative values are updated in RLM 2. How to generate a debug file for Release Management (RLM)
This note will briefly explain what an RLM debug file is and how to create it. Often when troubleshooting Oracle Release Management (RLM) issues, support/Development will request an RLM debug file. This note will briefly explain what an RLM debug file is and how to create it. The RLM debugging utility captures debugging information for either the inbound schedules via the DSP or of the outbound DSNO process for CUM Enabled customers. This is done by the use of a profile option called RLM DEBUG. The value for this profile determines when to create the rlmdebugxxxxx file. If the profile value is set to 'ON' then the debug messages from all the packages in Demand Processor or CUM Management will be sent to an rlmdebug file. TO RUN RLMDEBUG: Navigation Path: System Administration Responsibility -> Profile/System -> Query for RLM: Debug Mode profile. Set up the profile option RLM: Debug Mode = ON. The output file is called rlmdebugxxxxxx and it will be located in the directory specified by the ECE: Output file path suffixed by the concurrent request_id e.g. sqlcom/outbound/rlmdebugXXXXXXX TO RUN RLMDEBUG and OMDEBUG Navigation Path: System Administration Responsibility -> Profile/System Query for RLM: Debug Mode profile. Set up the profile option RLM: Debug Mode = On. Query for OM: Debug Mode profile. Set up the profile option OM: Debug Mode = 5. The output file is called rlmdebugXXXXXXX and it will be located in the directory
specified by the ECE: Output file path suffixed by the concurrent request_id e.g. sqlcom/outbound/rlmdebugXXXXXXX Search the rlmdebugXXXXXXX for "Om Debug File name" to locate the associated OM Debug file. TO TURN RLMDEBUG ON FOR OUTBOUND CUM ISSUES: Set profile options RLM: Debug to ON and WSH: Debug to On. Then re-run Interface Trip Stop (All). Provide the ITS log file and the RLM Debug log file. TO TURN RLMDEBUG OFF: Set RLM:Debug Mode = No Set OM: Debug Mode = 0 (if it was used) Set WSH: Debug off (if it was used) 3. LOV on RLM Processing Rules Item Address Level Not Working Symptoms Created three booked order headers for the same customer shipto/billto relationship, then tried to setup RLM Processing Rules so that every item is sent to its own order. The RLM Processing Rules Sales Order LOV does not show all created booked orders. The FRD log shows the Error Message: FRM-40350: Query caused no records to be retrieved. Cause System will default blanket number if customer PO number and customer match on the order header and blanket agreement during an SO copy. Since the RLM Processing Rules will only show Sales Orders in the Sales Order LOV that are not tied to a Blanket Release, the copied SOS with the defaulted blanket number do not show in the Sales Order LOV.
Fix Remove the PO Number via the orders work bench form, so any matching blanket agreement is not defaulted during a Sales Order copy. This will allow all possible Sales Orders to be listed in the Sales Order LOV on the RLM processing rules form. 4. Original Exception Messages are purged when Schedule was resubmitted Applies to: Oracle Release Management - Version: 11.5.10.2, this problem can occur on any platform. Problem Statement: On 11.5.10.2 in Production: Find when processing partially processed RLM Schedules, the original RLM exception messages get purged from the RLM_DEMAND_EXCEPTIONS table when DSP is re-submitted. Only leaving exceptions relevant to the last DSP run. Expected Behavior: Expect only error Exception Messages be removed. -- Steps to Reproduce: The issue can be reproduced at will with the following steps: Release Management Responsibility 1. Submit DSP (completes partially processed) 2. Review Exception Messages 3. Submit DSP for the same schedule 4. Review Exception Messages in the form 5. Review Exception Messages on the RLM_DEMAND_EXCEPTIONS table 6. Run DSP Exception Report based on Trading Partner and Creation Date -- Business Impact: The issue has the following business impact: Due to this issue, users need to be able to run the daily RLM Exception Report at will, and be able to see all exceptions from all runs of a particular schedule on a given day. Cause
Original exceptions are deleted when a partially processed schedule is resubmitted. This issue has been fixed in the file RLMDPWPB.pls version 115.92.11510.9 This is explained in the following bug: BUG 6403006 : ORIGINAL EXCEPTION MSGS WERE PURGED WHEN PARTPROC SCHEDULE WAS RE-SUBMITTED. Solution: To implement the solution, please execute the following steps: 1. Download and review the readme and pre-requisites for Patch.6403006. 2. Ensure that you have taken a backup of your system before applying the recommended patch. 3. Apply the patch in a test environment. 4. Confirm the following file versions: RLMDPWPB.pls 115.92.11510.9 You can use the commands like the following: strings -a $XX_TOP/filename |grep '$Header' 5. Retest the issue. 6. Migrate the solution as appropriate to other environments. 5. How to Create a Release Management CUM Debug for outbound ASN Applies to: Oracle Release Management - Version: 11.5.9 to 12.1 Information in this document applies to any platform. Goal How to create an RLM Debug for CUM errors during Interface Trip Stop? Solution Set RLM: Debug to ON Set WSH Debug to ON Re-run the ITS (All), choose Debug level as 1 (ON) in ITS.
The correct RLM debug log file will be named rlmdebug + requestID of Interface Trips Stop concurrent program. Example: Suppose the Interface Trips Stop Request Id is 3048515 (View in Application> view request form). The rlmdebug file name will be rlmdebug3048515. Once the debug file is opened the first few lines will be like file name ==> debug3048515 Starting debugger ==> 03-MAY-2007 02:26:40 AM Entering UPDATECUMKEY (05/03/2007 02:26) 6. Functionality of DISABLE AUTO-CREATE CUM KEY Applies to: Oracle Release Management - Version: 11.5.10 Information in this document applies to any platform. Goal: What is the functionality of "DISABLE AUTO-CREATE CUM KEY" option in processing rule? Solution: This comes into picture in a CUM enabled scenario & ITS(Interface Trip Stop) is invoked. When ITS is running, it calls the RLM code to update the CUM key if CUM calculation is used (setup). In case a matching CUM key is not found, it then tries to create a new CUM key and associate the shipped quantity with this CUM key. Matching CUM key is the existing active cum key defined for the same Customer- Ship From - Ship To - Item with attributes ( Purchase order, Date, Date&Record year, Date&PO etc as chosen in the setup) matching that of the item being shipped. If Disable Auto Create CUM key is set (i.e., automatic CUM key creation is not allowed), a new CUM key will not be created 7. Calculation for Quantities Loaded into the Sales Orders are Wrong
Applies to: Oracle EDI Gateway - Version: 11.5.10.This problem can occur on any platform. Symptoms: On 11.5.10 in Production: Find that when using Intransit Calculation Basis of "Shipped Lines" and have existing OM Lines in a Picked status, new incoming demand that should update the Picked Lines are being added in duplicating demand. EXPECTED BEHAVIOR Expect that since DSP cannot update the Picked Line the incoming demand should not be added. STEPS to Reproduce: The issue can be reproduced at will with the following steps: 1. Release Management 2. Release Management Processing Rules defined with Intransit Calculation Basis of "Shipped Lines" and with an SDP 3. Bring in new demand that will match a line that is Picked 4. The duplicate line is added back in. BUSINESS IMPACT The issue has the following business impact: Due to this issue, demand is being duplicated. Over stating the demand and over shipping product Cause: The issue is caused by the following setup: Dealing with demands falling prior to sysdate ATS Pre-Horizon Disp code Action Remain on File - Nothing. Cancel All - Remove/Delete the existing ATS demands with start date time (industry_attribute2) < Sysdate. Cancel After N Days - Remove/Delete the existing ATS demands
with start date time (industry_attribute2) < Sysdate-N days. * The deleted demands will not be reconciled. * The deletion happens only if the incoming schedule has got a higher precedence. For the following processing/reconciliation, the existing old demands with Industry Attribute2 falling within the following date ranges, are picked up. This issue is described in Bug 5115165: QUANTITIES LOADED INTO SALES ORDERS ARE DUPLICATED. Solution: To implement the solution, please execute the following steps: 1. Go into the responsibility: Release Management. 2. Navigate to Setup > Processing Rules. Change the ATH Disposition Code to Remain on File 3. Navigate to RLM Workbench> Schedules Waiting to be Processed. 4. Change Horizon Start Date to an earlier date. 5. Please retest the issue. 6. Migrate the solution as appropriate to other environments, if the issue is Resolved 8. Using Release Management with Internal Part Number but No Item Cross Reference Applies to: Oracle Release Management - Version: 11.5.10 Information in this document applies to any platform. Goal: Attempting to Import record into RLM using EDI SPSI 830 with an internal part number, but no cross reference.
Solution: There is currently no functionality within Order Management/RLM to obtain this feature. Consider using MTL_CI_INTERFACE to Import Customer Item Cross Reference. Possible workaround if user does not have the Customer Items Defined 1. First populate the MTL_CI_INTERFACE table ->Use Manufacturing and Distribution Manager Responsibility -> Special menu View -> Requests -> Submit a new request for program 'Import Customer Items' 2. Next populate the MTL_CI_XREFS_INTERFACE table -> Use Manufacturing and Distribution Manager responsibility -> Special menu View -> Requests -> Submit a new request for program 'Import Customer Item cross references'
9. Manual Cancellation Schedule doesnt cancel the Sales Order Line on the Order Board. Root Cause: While processing the Manual Schedule for Cancellation when there is a matching schedule for the date system will also consider the time stamp. Customer will send Demand Schedule through EDI and EDI sends the Schedule without time stamp. When you enter Manual Cancellation schedule System automatically provides the time stamp. So, make sure that there is no time stamp (Delete the time Stamp) mentioned in the Manual Schedule. 10. RLM Customer request date not match in OM, schedules processed in Error Problem Description: Customer have defined the holiday and wanted that request date in OM should fall same as in RLM even though its a holiday. Schedules processed in Error: Calculate Schedule Ship date API returned following warning: calculated ship date based on delivery date type code and lead time has moved.
Root Cause: Standard functionality: Request dates in OM changes as the demand processor found any nonworking days. 11. Replace all schedule wiped out all SO lines Problem Description: Processed a Replace All schedule and observed that all SO lines are cancelled/deleted. Root Cause: 1. Demand is outside Frozen period, so wiped out 2. Demand Fences set up in processing rule for this item is Incorrect. 12. Schedule processed with Error Calculate Schedule Ship date API failed with Following error: The lead time specified is null. Root Cause: RLM Intransit lead time for error item was null.
13. Shipments not updating CUM Key quantity. Delivery stuck in Interface Trip Stop. Root Cause: Manual add schedule was entered with 2 CUM lines for one time with different time stamp. Hence, when DSNO ran it fetched 2 lines for CUM ID and errored.

Oracle Applications: Release Management User Reference

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oracle Applications: Release Management User Reference

Uploaded by

Copyright:

Available Formats

Oracle Applications: Release Management

Oracle Application User Reference Manual (Release Management)

KPIT Cummins Infosystems Limited