Oracle Release Management Demand Processor

This appendix covers the following topics:

Overview of Oracle Release Management Demand Processor

This appendix focuses on using the Demand Processor, the starting point of the Oracle Release Management solution for meeting two key industry needs:

  1. Customers and suppliers must reduce lead time across their supply chain. (Oracle EDI communications address this need.)

  2. Suppliers must maintain an accurate and timely picture of customer demand to enable shipment of the correct quantities in the correct shipment sequence at the correct time.

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:

Once the inbound demand schedule is loaded, the Demand Processor verifies and processes its contents into Oracle sales orders or release orders, and forecasts using predefined Oracle Release Management business rules, trading partner processing logic, and comprehensive exception reporting. Oracle Release Management both ensures the quality of demand data and helps to decrease the lead time in the order fulfillment process.

Two integrated Oracle products provide seamless processing for electronic inbound demand: Oracle e-Commerce Gateway and Oracle Release Management. The EDI translator of your choice provides translation for incoming EDI documents and interfaces them to Oracle e-Commerce Gateway in an appropriate flat file format. Oracle Release Management receives demand schedules from Oracle e-Commerce Gateway, verifies them, and imports them into Oracle sales orders or release orders, and forecasts.

A combination of integrated Oracle products provides seamless processing for XML inbound demand: Oracle XML Gateway, Oracle Advanced Queuing, Oracle Workflow/Business Event System (BES), Oracle Transportation Agent (OTA), and Oracle Release Management.

Through Oracle XML Gateway, Oracle Release Management receives demand schedules, verifies them, and imports them into Oracle sales orders or release orders, and forecasts.

Business Flow

The Demand Management process begins when an inbound demand schedule is loaded into the Oracle Release Management Demand Processor interface tables and the schedule is selected for processing. Oracle Release Management Demand Processor enables the supplier to accomplish the following tasks:

The following figure shows the inbound demand processing flow:

Inbound Demand Processing Flow

the picture is described in the document text

Using Demand Management

Demand Management allows for both manual and automated processing of demand files. This section describes the manual process and the steps required to automate the process.

Load Inbound Demand Schedules

Demand Management begins either when Oracle e-Commerce Gateway receives an incoming EDI demand document from a trading partner, when Oracle XML Gateway receives an incoming XML demand document from a trading partner, or when you create a manual schedule using the Oracle Release Management Workbench. All are loaded into the Demand Processor interface tables.

The Demand Processor

Oracle Release Management's processing engine, the Demand Processor, completes into the following procedures:

The Demand Processor generates appropriate warning and error exceptions and informational messages during each of these procedures.

Demand Processing

the picture is described in the document text

Running the Demand Processor

Launch the Demand Processor in one of these ways:

  1. Use the Submit Demand Processor option under the Tools Menu option in the Oracle Release Management Workbench form to launch the Demand Processor for the interface schedule that you are viewing or have entered.

  2. Use the Process Inbound Demand Transactions option from the Oracle Release Management menu to process the schedule through the Oracle e-Commerce Gateway and directly to the Demand Processor.

  3. Use the Demand Transactions option from the Oracle Release Management menu to submit one or more schedules already in the interface tables to the Demand Processor using flexible parameters for schedule selection and related processing options.

To decrease the schedule processing time, you can run the Demand Processor in parallel mode. To accomplish this, indicate, in the submission parameters the maximum number of desired child requests. For a given schedule, the Demand Processor spawns child processes that might process one or more sales orders and blanket orders at a time depending on the number of child processes specified in the parameter and the number of sales orders and blanket orders associated with that schedule.

Viewing Exceptions

Oracle Release Management stores the exceptions encountered during Demand Processing and provides various means of viewing them:

Viewing Demand Information

Oracle Release Management enables you to view customer demand information on the Oracle Release Management Workbench form, Demand Status Inquiry Report, Demand Status Report, and the Schedule/Release Report.

In addition, you can view resulting sales order or release order and forecast lines using forms and reports provided by Oracle Order Management and Oracle Advanced Planning and Scheduling.

Oracle Release Management Workbench

To support analysis of the complete schedule and existing demand situation, the Oracle Release Management Workbench provides visibility to all interfaced transaction and archived customer demand schedules, the current Sales Order demand or release order demand, and additional Oracle Release Management information. You can:

See Oracle Release Management User's Guide.

Firm and Forecast Demand in Order Management

By passing demand into Oracle Order Management, you can view both firm and forecast demand on the sales order forms. Because open sales orders or release orders may accumulate many lines, you must pay special attention to the method of sorting and querying sales order lines or release orders. Oracle Application's folder technology improves access to the required information.

You can also review Oracle Release Management information on the sales order lines or release order lines in the Oracle Order Management's Sales Order form that is linked to the Oracle Release Management Workbench via the Demand button. These attributes, which appear on the Others tab of the Sales Order form, Lines Items window, include:

Oracle Release Management Sales Order Information
Attribute Attribute
Customer Job Production Line
Model Serial Number Customer Dock
Intermediate Ship To Customer Production Sequence
Bucket Type (using Forms folders technology) Customer Item Revision
Industry Attribute 1: Model Year Industry Attribute 2: Customer Request Date
Industry Attribute 3: Customer Schedule Reference Industry Attribute 4: Pull Signal Reference Number
Industry Attribute 5: Pull Signal Start Serial Industry Attribute 6: Pull Signal End Serial
Industry Attribute 7: Calculated CUM When Shipped Industry Attribute 8: CUM UOM
Industry Attributes 9 – 14 Industry Attribute 15: Original Ship From Org ID

Forecast Demand in Planning

By passing demand into Oracle Order Management, you can consume internal forecasts with your trading partner's external firm and forecast demand. Forecast consumption replaces internally forecasted demand with actual order demand. Each time you create an order line, you create an actual demand that can be firm or forecast. If the actual demand is already forecasted, the Planning Manager decrements forecast demand by the order quantity to avoid counting the same demand twice. Forecast consumption relieves forecast items based on the order line schedule date. When an exact date match is found, consumption decrements the forecast entry by the order quantity. Other factors that may affect the forecast consumption process are backward and forward consumption days and forecast bucket type. When you create a new forecast, especially from an external source, you can also apply consumption that has already occurred for other forecasts to the new one.

Alternatively, by optionally passing forecast demand into Oracle Advanced Planning and Scheduling, you can view forecast demand on the planning forms.

Demand Status Inquiry Report

To support analysis of the existing demand situation, Oracle Release Management's Demand Status Inquiry Report provides a consolidated view of the current demand picture for both firm and forecast demand. You run this report to show customer, destination, item, date range, and order number.

The report gives the required, shipped, picked, canceled, backordered, and invoiced quantities, pegging demand to the shipping status. The customer's job number and the production sequence number for the customer demand display on the report.

Compare Schedule to Demand Report

To support analysis between the quantity in processed schedule and the quantity in Order Management, Oracle Release Management's Compare Schedule to Demand Report provides a reporting tool that facilitates the comparison of the Processed and Partially Processed Schedule to the sales order demand. This report compares the requested quantity of an item in the Processed Schedule to the quantity that was interfaced into the Sales Order for the given requested date.

The Sales Order lines reflect the demand for an item for a given schedule processed by the Demand Processor. The discrepancy between the item quantity in the given processed schedule and the quantity that was interfaced into the sales order may be due to:

Schedule / Release Report

To support the analysis of the schedule's content, Oracle Release Management's Schedule / Release Report provides a reporting tool to print raw or processed schedules.

The report is similar to what is presented on the Release Management Workbench. For large schedules, this facilitates the reconciliation process.

Automating Demand Processing

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

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

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

EDI Demand Processing Automation

the picture is described in the document text

Demand Processing Logic

Oracle Release Management's Demand Processor proceeds through the following steps to bring an inbound demand schedule into the system and update the demand on an order line or forecast.

Demand Processing Logic

the picture is described in the document text

Load Demand Schedule Interface

Open Interface

Oracle Release Management Demand Processor is an open interface that can accept schedules to be processed from various sources, including those:

After the inbound demand schedule is loaded, the Demand Processor concurrent program is launched.

e-Commerce Gateway Trading Partner Setup

Oracle e-Commerce Gateway's Trading Partner form enables you to define customers that send or receive different EDI documents. For inbound demand, you must define the customer as an Oracle e-Commerce Gateway trading partner and enable the inbound demand documents that will be sent. The validation procedure checks to ensure that this customer, customer ship-to address, and customer bill-to address can receive the incoming EDI document type.

e-Commerce Gateway Code Conversions

Oracle e-Commerce Gateway uses code conversions to determine the corresponding internal value for several external data elements occurring on the inbound demand schedule before the schedule is loaded into the Demand Processor interface tables. These elements include Unit of Measure, Schedule Type, Detail Type, Detail Subtype, Date Type, Quantity Type, and Purpose Code.

XML Gateway Trading Partner Setup

Oracle XML Gateway's Trading Partner form enables you to define customers that send or receive different XML documents. For inbound demand, you must define the customer as an Oracle XML Gateway trading partner and enable the inbound demand documents that will be sent. The validation procedure checks to ensure that this customer, customer ship-to address, and customer bill-to address can receive the incoming XML document type.

XML Gateway Code Conversions

Oracle XML Gateway uses code conversions to determine the corresponding internal value for external data elements occurring on the inbound demand schedule before the schedule is loaded into the Demand Processor interface tables. These elements include Unit of Measure, Schedule Type, Detail Type, Detail Subtype, Date Type, Quantity Type, and Purpose Code.

Demand Processor

Demand Processor Phases

Oracle Release Management's Demand Processor uses several distinct phases:

Schedule Processing Order

The customer can generate multiple demand schedules in a short time. For example:

Oracle Release Management processes multiple EDI and XML customer demand schedules in the chronological order in which they were generated to net the requirements correctly. Many schedules have a generation date without the corresponding generation time.

EDI

If schedules for the same Trading Partner Translator Code and Trading Partner Location Code with a lower schedule processing sort order have not yet been processed, a newer schedule cannot be processed. The sort order depends on whether or not EDI Control Numbers are populated:

The ordering of schedules is consistent with the validation sequence.

The following chart shows the Demand Processor Order Rules that safeguard the processing order if EDI Control Number columns are not populated and multiple schedules of the same type but with different purpose codes generated on the same day exist for the same Trading Partner Translator Code and Trading Partner Location:

Demand Processing Order Rules
Purpose Code Do Not Process If These Exist In the Interface Table Processing Order When Multiple Schedules Exist
Add No restriction 1
Confirmation No restriction 2
Original No restriction 3
Replace No restriction 4
Replace All No restriction 5
Cancellation Add, Original, Replace, Change, Delete 6
Change Add, Original, Replace, Cancellation, Delete 7
Delete Add, Original, Replace, Cancellation, Change 8

Validate Demand

Oracle Release Management provides data validation and derivation of the demand schedule against the existing Oracle applications data. The processing engine, the Demand Processor, validates demand data against Oracle Applications such as the customer, customer item number, item unit of measure, and Oracle Release Management Processing Rules. The Demand Processor flags any problem records with data inconsistencies and derives internal identifiers, such as the customer item ID, and values such as the most preferred inventory item number.

Only valid data will be eligible for further processing; erroneous data will remain in the interface tables until errors are corrected or transaction data is deleted.

Apply Defaults

Oracle Release Management Processing Rules provide many appropriate default values for missing data. In addition, if the schedule horizon start and end dates are not specified, the Validation procedure will calculate them based on the earliest and latest demand lines on the schedule.

Derivation

All required internal IDs are derived from codes and numbers provided.

Derive Ship From

To derive the Ship From value and apply the associated Processing Rules, the Demand Processor uses:

Assigned Supplier Code: In this field, you enter the code that the customer sends in the electronic schedule to represent you as a supplier (for example, DUNS number). Oracle Release Management searches for a match on the supplier assigned code and thereby determines the ship from inventory organization.

Default Ship From: Oracle Release Management uses this ship from value to determine the ship from inventory organization Processing Rules to apply when the customer sends no supplier assigned code on the schedule, or for global available to promise.

Data Validation

Various types of validations are performed on the schedule header and lines:

Customer Relationships

The Demand Processor supports Customer Relationships defined in Oracle Receivables. The Demand Processor derives the related bill-to for the ship-to being processed if this relationship is set up in Oracle Receivables, and inserts this information on the sales order line or release order line.

Forecast Validation

If the optional Forecast Fence is enabled, the Demand Processor validates that a Forecast Designator is defined for the Customer/Ship To/ Bill To or Customer/Ship To or Customer. Incoming forecasts must have a customer and can have a ship to address, a bill to address, neither, or both. The Validation procedure searches for an exact match of the incoming data against the forecast designators defined in Oracle Advanced Planning and Scheduling's forecast source list. The Demand Processor search sequence is as follows:

  1. Find a Forecast Name that has the same Customer, Ship-To, and Bill-To.

  2. If no match is found, find a Forecast Name that has the same Customer and Ship-To.

  3. If no match is found, try to find a Forecast Name that has the same Customer.

  4. If no match is found, create an error message.

  5. The Demand Processor generates a Fatal Error if no Forecast Designator is found, or if Multiple Designators are found for the same Customer/Ship-to combination.

Schedule Exceptions

The Demand Processor generates three types of exception messages: information, warning, and error.

Information

Information messages are not caused by any exception condition, but are useful for schedule interpretation. They do not affect the demand processing.

Warning

Warnings are caused by minor exception conditions and are informational only. They do not affect the demand processing. However, if a warning condition arises, you might need to take subsequent action before shipping.

Error

Errors halt demand processing for the associated schedule as a whole or for all details related to the associated schedule item, depending on whether the error is encountered at the schedule header or line level. If an error condition arises, you must resolve the data issues causing the error, using the Oracle Release Management Workbench or another application form, and rerun the Demand Processor on the corrected schedule.

Information and Warning exceptions do not affect the demand processing, but Error exceptions halt demand processing.

If Error exceptions occurred, you must take corrective action as soon as possible and re-submit the schedule for demand processing.

Archive Schedule

Schedule archiving correlates with each schedule item's eligibility for further processing. For a schedule to be fully processed, the schedule header and all corresponding lines must pass validation. If only Information and Warning exceptions are generated on a schedule, it passes validation. However, one or more fatal errors on the header will result in the header failing validation- and one or more fatal errors on a line associated with a schedule item will result in the schedule item failing validation.

A schedule can be archived in part or in full. The Validation procedure passes or fails a schedule on an item-by item basis. For example, a schedule with 50 lines containing 10 lines of demand for each of 5 customer items is processed. During validation, the header and 49 lines pass validation, but 1 line fails. As a result, the 10 lines of demand for the customer item having the error fail validation together and remain only in the interface table. The remainder of the schedule is archived and continues to be processed.

Depending on the level at which any fatal errors are detected, the schedule is either not archived, partially archived, or fully archived:

In the Oracle Release Management Workbench, the entire schedule appears as a unit, even if part of the schedule remains in the Demand Processor interface tables. The Process Status on the header and each line indicate the current error level and status.

Archived schedules may be selected for the Oracle Release Management Net Change Report.

Test Transactions

Test transactions are validated and archived, but no further processing occurs. This Demand Processor feature facilitates setup and implementation for inbound demand schedules of new trading partners. The Test field on the Schedule Header is selected for test transactions.

Manage New Demand

If the schedule has at least one schedule item that passed validation, the Demand Processor then moves to the procedure Manage New Demand. This procedure has several steps that update the interface tables to reflect Oracle Release Management business rules applicable to the new schedule lines. Any changes to sales order lines or release order lines in Oracle Order Management and forecasts in Oracle Advanced Planning and Scheduling are based on these updates.

Flexible Oracle Release Management Processing Rules

Oracle Release Management provides a variety of attributes that enable you to tailor Demand and Order Management to the needs of your supplier/customer relationship. It also provides flexibility in the levels at which you define these attributes. Oracle Release Management Processing Rules can be defined at the following levels:

Cumulative to Discrete Quantity Conversion

A schedule might be issued with cumulative demand quantities in context of the cumulative received quantity at the time the schedule was generated by the customer. In this case, the Quantity Type on each line specifies Cumulative. The Demand Processor derives discrete quantities for each demand line by first sorting them in ascending start date order and then backing out the cumulative receipt quantity and prior demand quantities.

Apply Supply Chain Sourcing Rules

Supply Chain Sourcing Rules can be defined to split demand on a schedule between multiple ship-from locations, or to change the ship-from location on a schedule when the supplier wants to override the ship-from location on the schedule. The Demand Processor supports rules for Make At or Transfer From sourcing.

The profile option RLM: MSC/MRP Default Assignment Set is used to determine if the Supply Chain Sourcing rules should be used to derive the ship from organizations. If these rules should be used (if the profile option is set to a value 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, the system uses this rule. If more than one rule exists for the item, the Default Assignment Set designated in the profile option is used to determine which rule should be used.

Once the Assignment Set is determined, the sourcing level and the highest rank sourcing rule for the item is determined. If multiple ship-from locations are defined with the same rank, then the new demand is split between multiple sources accordingly.

To prevent the Sourcing Rules from being applied more than once when an item is setup as Global Available to Promise, the Demand Processor does not apply the Sourcing Rules. These rules are applied when the ATP engine is called at the time of scheduling.

Calculate Scheduled Ship Date

The Demand Processor calculates the most accurate Scheduled Ship Date based on information on the schedule and available options defined for the customer/supplier relationship in Oracle Release Management Processing Rules.

If delivery dates are specified on the schedule, corresponding scheduled shipment dates must be calculated. The Demand Processor uses several Oracle Release Management Processing Rules that can be defined for use when calculating valid shipment dates:

The ship delivery pattern code is applied to the demand.

The transportation lead time is used to offset the due date and, finally the warehouse shipping calendar is interrogated to determine the correct Scheduled Ship date that apply to the demand. The Exclude Non-work days flag in the processing rules indicates whether to include or exclude non-workdays when applying Intransit Time to calculate the ship date. When the flag is selected, the Demand Processor ignores the non-working days during the transit time offset calculation. When the flag is cleared, the Demand Processor first deduces the lead time and, if the resulting day is a non-working day in the ship-from calendar, it goes backward one day at a time until it finds a working day.

When the inventory item is set up for Global Available to Promise, the Demand Processor does not apply the Calculate Schedule Ship Date logic to the demand. Rather, the scheduled Ship Date and Ship From are determined when the demand is scheduled in Oracle Order Management and the Global Available to Promise engine is applied to the sales order lines.

When you define your Oracle Release Management Processing Rules, you can specify a default ship delivery pattern rule at the customer, address, and customer item levels. This default ship delivery pattern rule is used if you have indicated not to use the ship delivery pattern transmitted by the customer demand. You can select from the ship delivery pattern rules that were defined using the Maintain Ship Delivery Pattern Rules form.

When a customer transmits buckets other than daily or weekly, Oracle Release Management divides these buckets into weekly buckets and applies the specified pattern code to give you a clear picture of future forecasted demand. This functionality gives your suppliers a clear picture of when material is required. Monthly, Quarterly, and Flexible bucket types will be converted to Weekly buckets.

Calendars are defined in Oracle Shipping Execution. You can define shipping calendars for your warehouses and inventory organizations, and you can set up receiving calendars for your ship-to addresses.

Apply Frozen, Firm, and Forecast Fences

Demand fences are used to better manage the demand on Planning, Shipping, and Sequenced schedules. Using Oracle Release Management Processing Rules, you can define the following demand fences for each schedule type:

Optionally, demand fences can be defined at the following levels:

If defined, demand fences override the firm/forecast status of the schedule line and determine which demand is available to be updated, which is authorized to ship, and which is not authorized to ship, which goes to planning.

All types of fences are applied based on system date. Formerly, the fences were applied according to the Schedule Horizon Start Date. In this way, the application of the fences is not subject to potentially unpredictable Schedule Horizon Start Dates sent by the customer.

Past due demand is determined according to whether it is before the system date, not whether it is before the Schedule Horizon Start Date. Manually entered schedules are not affected by Frozen, Firm, and Forecast fences.

Frozen

A frozen fence prevents new demand in the Demand Processor from changing the existing Sales Order demand (the new demand is not updated to the sales order and a warning is issued if frozen demand has been changed on the schedule).

Firm

A firm fence overrides the customer demand status by updating to the sales order as Firm (Authorized to Ship, ATS), regardless of the customer specified status on the schedule.

Forecast to- OM

A forecast to OM fence overrides the customer demand status by updating to the sales order as Forecast (Not Authorized to Ship, NATS), regardless of the customer-specified status on the schedule. When either an OM or PLN forecast fence is specified, requirements dated later are dropped. When a forecast fence is not specified but a firm fence is, requirements dated later than the firm fence are updated to the sales order based on the customer specified status.

Forecast to - PLN

A forecast to PLN fence overrides the customer demand status by updating to Oracle Advanced Planning and Scheduling as Forecast, regardless of the customer-specified status on the schedule. When either an OM or PLN forecast fence is specified, requirements dated later are dropped. When a forecast fence is not specified but a firm fence is, requirements dated later than the firm fence are updated to the sales order based on the customer specified status.

Roll Forward Frozen Fence

Note that the Roll Forward Frozen Fence check box can be selected to ensure that you do not miss a customer's request for an increase in demand. If this parameter is enabled, the increased quantity is added to the demand on the first day after the frozen fence. A decrease in demand within the frozen fence results in only a warning on the Exceptions Report.

The following diagram illustrates a few of the many possible demand fence scenarios that can be defined in Oracle Release Management Processing Rules. The value of From/To Fence Days for each fence determines the position of applicable fences on the system date (formerly Schedule Horizon Start Date) line governing how demand on the schedule is updated to Oracle Order Management or Planning:

Demand Fence Scenarios

the picture is described in the document text

Firm and Forecast Demand Processing

This identification triggers the placement of demand to sales order lines and optionally planning forecasts:

Aggregate Validation

The Demand Processor checks the new demand lines to see if they might be aggregated by using both the Mandatory and Optional Matching Within Attributes that are enabled. It issues a warning if the new incoming demand contains multiple demand lines that have the same Matching Attributes enabled and the same Item Detail Type (Past Due, Firm, Forecast OM, and Forecast MRP). This situation commonly occurs when the Matching Attributes that are selected do not uniquely identify the demand lines.

For example, Item IT01 has two demand lines for a quantity of 10. The two lines have the same original customer request date and different dock codes. If Original Customer Request Date is enabled as an optional matching attribute, the Demand Processor will aggregate the two lines and process a line for a quantity of 20. This table illustrates that the dock code for the first demand line is overridden because dock code is not set up as a matching attribute:

Demand Lines Example
Item Original Customer Request Date Dock Code Quantity
IT01 2-December DCK01 10
IT01 2-December DCK02 10

The Demand Processor logs an exception against item IT01 for duplicate demand and advises the user to check if the matching criteria were appropriately chosen. An example of the warning message is: multiple demand lines have the same Matching Attributes combination with different Customer Dock Codes. Check if the Matching Criteria were appropriately chosen for ship from M2 / ship to 1000 / item IT01.

The user corrects this condition by enabling both the original customer request date and the dock code as optional matching attributes, and then the data is processed correctly and no detail is lost.

This situation could happen for any of the matching attributes. The Demand Processor recognizes such cases of duplicate demand during Aggregate Validation and logs the appropriate exceptions.

However, the Demand Processor will raise a warning (rather than an error) to allow the users to decide which matching attribute they really want. If the Demand Processor had raised an error, then the users would be forced to enable specific matching attributes to let the Demand Processor continue its process. It is possible that the customer sent a schedule with incorrect demand, and you do not want to change your matching attributes.

Aggregate Demand

The application of Ship/Delivery Pattern Codes may result in multiple demand lines with the same Scheduled Ship Date. The Demand Processor combines like demand using all Mandatory Matching Attributes plus enabled Match Within Attributes associated with the lowest applicable level Processing Rules relationship.

Optional Match Within Attributes can be defined in Oracle Release Management Processing Rules at the Ship From/Customer and Ship From/Address levels.

Standard Pack Rounding

The Demand Processor rounds up inbound demand to standard pack quantities if Standard Pack Rounding is enabled in Oracle Release Management Processing Rules for the customer, address, or item being processed.

Rounding to Standard Pack Quantity

If the customer item has standard pack rounding enabled, the Demand Processor rounds up all demand quantities to reflect multiples of the standard pack quantity after Ship/Delivery Pattern Codes are applied and demand is aggregated, in case demand quantity no longer reflects standard packaging.

Standard pack rounding can be enabled and the standard pack quantity defined in the Oracle Release Management Processing Rules. The quantity of future demand is adjusted to maintain demand quantity integrity throughout the schedule horizon. However, as a result of these calculations, the last demand detail might be temporarily overstated until future schedules extend the horizon.

Note: A discontinued part with no future demand could ultimately result in an over-shipment.

CUM Discrepancy Check

If CUM management is enabled, the CUM key is active for the customer destination and the ship from organization, and a non-zero Shipped/Received line with subtype Customer CUM is specified on the inbound demand schedule, then the Demand Processor performs a CUM Discrepancy Check. A warning exception is issued if the supplier CUM-shipped quantity in Oracle Release Management and the customer CUM quantity on the schedule do not match.

Oracle Release Management enables you to inactivate CUM keys on the CUM Workbench, which allows you to inactivate CUM keys that were created in error or that you no longer need. If shipment or adjustment transactions exist for the CUM key, then before inactivating the CUM key, the system will issue a warning and ask for verification that you still want to inactivate this CUM key.

Inactive CUM keys are not considered for:

Reconcile Old and New Demand

Reconciliation by Scheduled Item

In Oracle Release Management, demand reconciliation tasks are performed for each Ship From/Ship To/Customer Item combination on the schedule. For planning and shipping schedules, the Scheduled Item equates to a Ship From/Ship To/Customer Item; for a sequenced schedule, this equates to a single production sequence number.

Any existing sales order line that has not been progressed past scheduled and is not included on the incoming schedule is removed from the sales order.

If any Scheduled Items were not included on the schedule, any existing sales order lines associated with them remain intact. In the case of a Replace schedule, the Demand Processor will compare the new schedule to the previous schedule, and issue a warning for the item that was not included on the new schedule. The Net Change Report can also be used to determine if any items were dropped from or added to a schedule.

Customer/Supplier Shipment Reconciliation

The first step in reconciling the existing sales order lines with the new schedule is to determine any in-transit shipments were made that are not yet recognized by the customer in the new schedule.

In-transit quantities are supplier shipments that occured after the last customer recognized shipment on the schedule. They must be applied to new customer requirements to avoid overstating the demand. In-transit quantity calculations are used for reconciling schedule demand with orders in Oracle Order Management.

The following options are available for the In-Transit Calculation Basis parameter:

The reconciliation takes into account the matching criteria. To manage demand more effectively, all the enabled optional matching attributes are considered along with the mandatory matching attributes for shipment reconciliation.

Matching Attributes for Demand Reconciliation

The concept of matching attributes is critical to the demand reconciliation procedure. Non-matching old demands are dropped and not reconciled. Matching attributes uniquely identify customer requirements. The two types of Matching Attributes are Mandatory and Optional.

Mandatory matching attributes are always enabled. Demand Processor errors are generated when matching attributes are not populated.

Optional matching attributes are defined in Oracle Release Management Processing Rules at the Ship-From/Customer and Ship-From/Address level according to the needs of the business relationship. Optional matching attributes are described in the following paragraphs:

Match Within

When reconciling demand from the same schedule type, enable if the data element is a matching attribute. For example, new demand from a shipping schedule being reconciled with existing demand from a shipping schedule.

Note: Always enable as Match Within the attributes that are used by your trading partner in CUM Management (Record Year or Purchase Order, if applicable.

Match Across

When reconciling demand from different, less granular schedule types (according to the Schedule Consumption Hierarchy defined for the business relationship), enable if the data element is a matching attribute. For example, new demand from a shipping schedule being reconciled with existing demand from a planning schedule.

Critical

Enable if the data element should always have a value for turnaround data or CUM Management. If enabled and the attribute is missing on demand, the Demand Processor will issue a warning exception.

This table shows Mandatory Matching Attributes and their default settings for Matching Within, Matching Across, and Critical:

Default Settings for Mandatory Matching Attributes
Attribute Match Within Match Across Critical
Bucket Type Always Enabled Always Enabled Always Enabled
Customer Always Enabled Always Enabled Always Enabled
Customer Item Always Enabled Always Enabled Always Enabled
Intermediate Ship To Always Enabled Always Enabled Always Enabled
Inventory Item Always Enabled Always Enabled Always Enabled
Sales Order /Sales Agreement Always Enabled Always Enabled Always Enabled
Ship From Always Enabled Always Enabled Always Enabled
Ship To Always Enabled Always Enabled Always Enabled

The following table shows Optional Matching Attributes and the default settings for Matching Within, Matching Across, and Critical:

Default Settings for Optional Matching Attributes
Attribute Match Within Match Across Critical
Start Date/Time Enabled by Default Enabled by Default Not Enabled by Default
Customer Request Date/Time Enabled by Default Enabled by Default Not Enabled by Default
Customer Dock Code Enabled by Default Enabled by Default Not Enabled by Default
Customer Item Revision Enabled by Default Enabled by Default Not Enabled by Default
Customer Job Number Enabled by Default Enabled by Default Not Enabled by Default
Customer Model Serial Number Enabled by Default Enabled by Default Not Enabled by Default
Customer Production Line Enabled by Default Enabled by Default Not Enabled by Default
Customer Production Sequence Enabled by Default Enabled by Default Not Enabled by Default
Pull Signal Reference Number Enabled by Default Enabled by Default Not Enabled by Default
Pull Signal Starting Serial Number Enabled by Default Enabled by Default Not Enabled by Default
Pull Signal Ending Serial Number Enabled by Default Enabled by Default Not Enabled by Default
Purchase Order Number Enabled by Default Enabled by Default Not Enabled by Default
Record Year Enabled by Default Enabled by Default Not Enabled by Default
Industry Attributes 9-15 Not Enabled by Default Not Enabled by Default Not Enabled by Default
Industry Attributes 1-15 Not Enabled by Default Not Enabled by Default Not Enabled by Default

Matching Within the Same Schedule Type

Use all Mandatory Matching Attributes and all enabled Optional Match Within Attributes to match existing sales order lines associated with the same Schedule Type to the demand from a new schedule for reconciliation in context of the schedule Purpose Code and schedule horizon dates.

For example, using Match Within Attributes, the Demand Processor controls matching of existing sales order lines from a Production Sequence schedule when reconciling new demand on a Production Sequence schedule in context of the schedule Purpose Code and schedule horizon dates.

The following results can occur when matching within same schedule type:

Matching Across Schedule Types

Existing sales order lines associated with other Schedule Types are matched to the demand from new schedule using all Mandatory Matching Attributes and all enabled Optional Match Across Attributes for reconciliation within the schedule horizon dates according to the Schedule Consumption Hierarchy.

For example, Matching Across logic is used to reconcile existing Sales Order lines from a Planning/Release schedule when the Demand Processor is working with new demand on a Production Sequence schedule. This assumption is that the Planning/Release schedule is less granular than the Production Sequence schedule according to the Schedule Consumption Hierarchy.

If you have established optional OM or PLN Forecast Fences for demand management in the Oracle Release Management Processing Rules and a customer demand dated within the Forecast Fences, the Demand Processor will update Order Management or MRP Planning as specified. However, for demand dated after the Forecast Fences, the Demand Processor will drop those demand lines. They will not be updated to Order Management or MRP Planning.

Matching Applicable to OM Forecast Fence

If you established optional OM Forecast Fences for demand management in the Oracle Release Management Processing Rules, the demand within the fence date range will be updated to the sales order. The status of the demand on the schedule within the fence date range will be overridden to be Not Authorized to Ship (NATS), not eligible for any Order Management processing related to shipment.

Demand is matched using Matching Attributes on a line by line basis.

Matching Applicable to PLN Forecast Fence

If you established optional PLN Forecast Fences for demand management in the Oracle Release Management Processing Rules, the demand within the fence date range will be updated to Oracle Advanced Planning and Scheduling.

Demand is not matched using Matching Attributes on a line by line basis because Oracle Advanced Planning and Scheduling does not support the same attributes into MRP as does Order Management. MRP supports a replacement at the item level based on Forecast Designator for the Customer/Ship To combination. Therefore, the schedule horizon dates are not considered.

The Demand processor converts the incoming demand quantity in terms of the Primary UOM code defined for the item when the incoming UOM code and Primary UOM code mismatch in case of demand interfacing to MRP. In MRP the demand must always be in Primary UOM.

Schedule Purpose Code Interpretation

The Oracle Release Management Demand Processor interprets demand for each item on a schedule within the horizon date range based on the value of the Schedule's Purpose Code. The purpose code can be one of the following:

Purpose Code Rules

The schedule purpose code determines how new demand is reconciled to old demand of the same schedule type once the logic for Matching Within Same Schedule Type has identified the existing demand which is eligible for reconciliation.

The following example shows the rule for each purpose code and how it affects the resulting demand picture for a particular Ship From/Ship To/Customer Item. This example assumes that all Match Within Attributes are identical and like demand is aggregated.

New Demand received on a Shipping Schedule:

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

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

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

Managing Old Demand before System Date

Demand dated before the system date (formerly, dated before the Schedule Horizon Start Date) is managed depending on whether it is Authorized To Ship (ATS) or Not Authorized To Ship (NATS). ATS represents firm demand, whereas NATS represents forecast demand.

NATS Pre-Horizon Forecast Demand Cancellation

If any unshipped forecast demand exists on the sales order dated before the system date (formerly, dated before the Schedule Horizon Start Date), it is automatically canceled because it is no longer relevant. You must use the Release Management Line Workflow to use NATS.

ATS Pre-Horizon Disposition Rule Application

If any unshipped firm demand exists on the sales order dated before the system date (formerly, dated before the Schedule Horizon Start Date), it is managed according to the value of ATS Pre-Horizon Disposition Code.

Oracle Release Management enables you to control how the Demand Processor handles unshipped firm (ATS) Sales Order demand dated before the system date (formerly, dated before the Schedule Horizon Start Date). For each Ship-From/Customer or Ship-From/Address relationship you can select the appropriate value for ATS Pre-Horizon Disposition Code by selecting from the following options:

The value you select depends on how your customer's new demand schedules reflect past due demand. Some customers change the date of the past due demand, some leave it as it was originally sent, and some cancel it and increase their requirements for dates within the new schedule horizon.

Consume Demand Hierarchy

Oracle Release Management provides the ability to tailor the way the Demand Processor nets inbound demand from different schedule types for each Ship-From/Customer or Ship-From/Address relationship. The user selects a Schedule Consumption Hierarchy that ranks each schedule type from least granular to most granular. Consume Demand Hierarchy logic controls the reconciliation of demand from lower ranking schedules with demand from a new, higher ranking schedule using Match Across Attributes.

The Demand Processor recognizes the following types of inbound demand schedules:

When demand from more than one of these schedule types exists on the sales order, demand from lower ranking schedules is overlaid or consumed by demand on a new higher ranking schedule. This functionality is based on the applicable value of the Consume Demand Hierarchy Code in context of the new schedule's horizon start and end dates.

Consume Demand Hierarchy logic is used only when the new schedule's Purpose Code is Replace, Replace All, Add, or Change; other purpose codes are excluded. Whether the demand is overlaid or consumed depends on the existing demand scheduled ship date and bucket type in context of the schedule's horizon:

Consume Demand Hierarchy Code is defined in Oracle Release Management Processing Rules at the Ship From/Customer or the Ship From/Address levels. You may assign the value that reflects the trading partner's business practices as to how the inbound demand schedules relate to one another for demand consumption. The following list shows the choices for Consume Demand Hierarchy Code with their corresponding demand consumption rules:

Planning, Shipping, Sequenced (Default)

Planning, Sequenced, Shipping

Shipping, Planning, Sequenced

Shipping, Sequenced, Planning

Sequenced, Planning, Shipping

Sequenced, Shipping, Planning

Consume Demand Hierarchy Example

For example, suppose we recently received six replacement schedules from our trading partner, and each one includes a daily bucket with a demand requirement for today. This trading partner setup has the default Consume Demand Hierarchy Code of Planning, Shipping, Sequenced.

Because the different schedules have the same date and bucket type for today, only one sales order line will reflect today's demand, and the quantity and schedule type will change to reflect the most recent schedule that updated it.

The following table shows the results of Consume Demand Hierarchy logic for today's demand line:

Consume Demand Hierarchy Logic
Schedule Reference Schedule Ship Date Schedule Quantity Sales Order Line Scheduled Ship Date Sales Order Line Demand Quantity Sales Order Line Schedule Type
Planning #1 Today 1 Today 1 Planning
Shipping #1 Today 2 Today 2 Shipping
Sequenced #1 Today 3 Today 3 Sequenced
Shipping #2 Today 4 Today 4 Sequenced
Planning #2 Today 5 Today 5 Sequenced
Sequenced #2 Today 6 Today 6 Sequenced

Notice that the second shipping and planning schedules did not update the sales order line because they have a lower hierarchy than the sequenced schedule.

Tolerance Changes

You may define positive and negative demand tolerances specific to the Ship-From/Customer, Ship-From/Address, Ship From/Address/Customer Item, or Ship From/Customer item relationship in Oracle Release Management Processing Rules.

When the Demand Processor's Reconcile Old and New Demand procedure finds a match with an existing demand record and attempts to make a change to quantity, a calculation is made to verify that the change quantity does not violate the lowest applicable level of tolerances. If the calculation determines that the quantity change does exceeds a tolerance, Oracle Release Management processes the change but raises a warning on the Exceptions report.

Order Management Workflow Status

Depending upon how far the existing sales order lines have progressed in their Order Management workflow, it might not always be possible to update the demand according to information on the new schedule due to conflict with rules governing restricted demand.

The update success or failure of incoming demand changes and replacements on existing sales order lines in Oracle Order Management depends on the workflow status of the line, the type of schedule, and Order Management processing constraints.

If an attempted change or replacement fails, warning exceptions are issued. Manual intervention is then needed to examine the exceptions and decide how to incorporate the schedule changes into the existing sales order lines to reflect the customer's preferences.

Roll Forward Frozen Fence

If the customer has sent an increase in demand within the Frozen Fence, you can check the Roll Forward Frozen Fence parameter to automatically have the Demand Processor put this increased quantity in the first day after the frozen fence. Note that this only affects an increase in quantity. If the customer decreases the quantity within the Frozen Fence, the Demand Processor issues a warning but makes no change to the quantity.

When the Roll Forward Frozen Fence parameter is cleared, if the customer increases or decreases the quantities within the Frozen Fence, the Demand Processor issues warning messages and makes no change to the quantities.

Compare Replacement Schedules

For replacement schedules, the Demand Processor compares the parts on the schedule being processed with the parts from the previous schedule of similar type from the same trading partner. If the Demand Processor finds a case for which a part was on a previous schedule and not yet shipped, but it is not on the current schedule, an informational message is generated in the Oracle Release Management Exceptions report.

Sales Order and Demand Processing

Sales Agreement Processing

Sales agreement processing is the same as Sales Order Processing (see below) with the addition of two rules (Release Rule and Time Frame) that dictate how and when release orders are created The impact to the reconcile process is that with the use of sales agreement, existing demand can be spread across several release orders.

If the Release Rule is Release Combines Items:

With this rule, all items on a sales agreement will share the same release orders. For all items on the sales agreement, the Demand Processor looks for an existing Release Order for the same customer information, and ensures that the requested date of the demand is between the start and end effective date of the release order. If it finds a release number that matches these criteria, it adds the new demand to the release order. If it does not find a release order that matches these criteria, it creates a new release order.

If the Release Rule is Release Per Items:

With this rule, each item on the sales agreement will have a separate release order from other items on the sales agreement. For each item, the Demand Processor looks for an existing Release Order for the same customer and customer item, and ensures the requested date of the demand is between the start and end effective date of the release order. If it finds a release number that matches these criteria, it adds the new demand to the release order. If it does not find a release order that matches these criteria, it creates a new release order.

If the Release Rule is Release Across Items:

With this rule, all items on the sales agreement that share the same date of demand will have a single release order. The Demand Processor looks for the earliest date of demand across items to create the Release Order.

The Demand Processor processes schedules in a consistent order. While evaluating an unprocessed schedule, a schedule whose attributes are less than the one currently being processed, the processing is stopped. While evaluating a processed schedule, a schedule whose attributes are more than the one currently being processed, the processing is stopped.

Sales Order Processing

When the schedule now accurately reflects the incoming demand picture according to the business rules defined in Oracle Release Management Processing Rules, the Demand Processor updates the sales order lines.

Industry Specific Attributes

By extending Oracle Applications with industry specific attributes, Oracle Release Management captures information specific to an industry and passes this information to sales order lines. This information is, visible on the Sales Order form.

Sales Order Processing

This section describes how the Order Processing procedure updates sales order lines in Oracle Order Management.

Source Document References

A critical component of Order Processing is the link between the sales order line and the demand schedule line from which the sales order demand came or was updated. When Oracle Order Management interfaces a new sales order line, the Source Document References identify the corresponding schedule header and line, thus providing a link between the Oracle Release Management table and the Oracle Order Management's sales order lines. Information from the schedule can be retrieved for CUM Management and the electronic shipment notice.

A sales order line updated by the Demand Processor does not necessarily have only one corresponding schedule line. The trading partner's Optional Match Within Attributes can result in aggregation of demand when multiple demand lines have different values for matching attributes which are not enabled. The trading partner's Ship Delivery Pattern can result in either splitting or aggregating of demand, depending on the bucketing of the demand on the schedule.

For example, you are processing a planning schedule with demand expressed in weekly buckets and the trading partner's Ship Delivery Pattern specifies shipment of equal quantity on Monday and Wednesday. Each schedule line with weekly demand will be split into two sales order lines each containing 50 percent of the shipment quantity for the week: one for Monday and the other for Wednesday. Conversely, when you are processing a shipping schedule from the same trading partner with demand expressed in daily buckets, each schedule line with daily demand will be aggregated forward to ship on the specified days. Monday and Tuesday demand will be scheduled to ship on Monday, and Wednesday, Thursday, and Friday demand will be scheduled to ship on Wednesday.

Process Order

After completing the demand reconciliation procedure, the Demand Processor calls Oracle Order Management's Process Order API that applies all Order Management business rules to all Sales Order updates. At this point, errors can occur that would prevent processing. If this happens, the Process Order API sends error messages back to the Oracle Release Management Exceptions Report.

Demand Reporting

You can view processed demand in Oracle Release Management's Demand Status Inquiry. You can peg demand to the sales order line or forecast and view the current shipping status of the transaction.

Forecast Processing

Forecast Processing

MRP supports a replacement at the item level based on Forecast Designator for the Customer/Ship To combination; therefore, the schedule horizon dates are not considered.

Three types of MRP Planning updates are based on the schedule purpose code:

Responding to Schedule Exceptions

Schedule exceptions have three levels of severity: Information, Warnings, and Fatal Errors.

Information

Information exceptions are generated when the demand schedule contains a situation that is noteworthy but neither a warning nor an error should be noted. For example, when a schedule with a confirmation purpose code is processed, an information exception is generated. A confirmation schedule is usually issued by the trading partner as an audit trail following a sudden verbal change in near-term firm demand for the next shipment.

Assuming that actual demand was already been manually adjusted, this exception does not require user action upon the schedule.

Warnings

Warning exceptions are generated when minor problems that do not halt processing are noted. The demand schedule continues to be processed as long as fatal errors are not encountered.

Evaluate and make corrections necessary to reduce the number of exceptions on future demand schedules.

Fatal Errors

Fatal errors at the schedule header level halt further processing for the entire schedule.

Fatal errors at the schedule line level halt further processing for related lines only. If the demand schedule has no fatal header errors, any scheduled items without fatal errors will continue processing.

Fatal errors at either level must be immediately corrected and the schedule re-submitted to the Demand Processor.

The process of correcting errors on a schedule involves these steps:

  1. Identify errors and their causes

  2. Examine the schedule

  3. Correct the erroneous data

  4. Re-submit the schedule to the Demand Processor

Identify Errors and Causes

Review Demand Processor Exceptions

If exceptions are generated while processing the schedule, the Oracle Release Management Exceptions Report will contain the information. Using this report, do the following:

  1. Identify any fatal errors on the Exceptions report. These require immediate action.

  2. Identify the cause of each fatal error.

Possible Exception Causes

Demand Processor Exceptions could be caused by various situations, including:

Examine Schedule

Before a customer schedule can update the sales order and planning systems, it must be validated, archived, and completely processed by the Demand Processor.

Two important fields enable the you to determine when Demand Processor activity took place and to distinguish between schedules that are processed, unprocessed, or in a suspended state because they contain validation errors that prevent process from completing. These fields are maintained at two levels, for schedule headers and corresponding schedule lines:

Processed Status

Processed Status indicates how far the schedule has progressed in the processing steps done by the Demand Processor. It is maintained at two levels, for schedule headers and each corresponding schedule line.

Schedule lines are grouped by schedule item. A schedule might pass or fail validation item by item if the header does not have a fatal error. If some of the lines belonging to a particular schedule item have fatal errors, all rows belonging to that schedule item fail validation and no further processing is done on them until the errors are corrected.

Header Level Processed Status

The Processed Status of a schedule header reflects the status the entire schedule. Schedule Header Processed Status can have any of the following values:

Line Level Processed Status

The Processed Status of a schedule line reflects the status of that line only. The Processed Status is the same for all lines associated with the same schedule item. Line Processed Status can have any of the following values:

Processed Date

Processed Date indicates the most recent date and time when the Demand Processor activity corresponding to the Processed Status took place. It is maintained at two levels; for schedule headers and each corresponding schedule line. You can track the flow of error correction processing using Processed Date.

Tracking Processed Status and Processed Date Example

You can track Processed Status and Processed Date to identify how and when lines in the schedule were processed. In this example, we are following the processing of a schedule that has five lines of demand for each of three schedule items, A, B, and C.

When the schedule is initially loaded into the Demand Processor Interface tables, the header and all 15 lines will have a Processed Status of Available to Process and a Processed Date indicating the system date and time when the schedule was loaded.

When the Demand Processor begins to process this schedule, the header and all lines will have a Processed Status of In Process and Processed Date indicating the system date and time when Demand Processor started to work with the schedule.

When the Demand Processor validation process is completed, the Processed Status and Processed Date will be updated on the header and all lines to reflect the results of the validation and the date and time when validation was completed. The header and schedule items A and B successfully passed validation, but schedule item C failed. At this point, the header has a Processed Status of In Process, the five lines for schedule item A and the five lines for schedule item B have a Processed Status of In Process, and the five lines for schedule item C have a Processed Status of Processed with Error.

Since the lines for schedule items A and B are eligible for update, they will be processed through the Manage New Demand and Reconcile Demand routines. The lines for schedule item C, however, will be ignored.

When the Demand Processor has completed managing and reconciling the demand for schedule items A and B, the Processed Status and Processed Date are updated on the header and the lines for items A and B. Now, the header has a Processed Status of Partially Processed With Errors, the 10 lines for schedule items A and B have a Processed Status of Processed Successfully, and the Processed Date indicates when the Demand Processor completed updating the Order Entry and Planning systems. However, the Processed Status and Processed Date of the five lines for schedule item C were not changed after validation. They still have a Processed Status of Processed with Error, and the Processed Date still indicates the date and time when validation was completed.

If the user now examines the current demand for items A, B, and C, they will find that the demand reflects the new schedule only for items A and B.

The user now examines the Error Exceptions associated with schedule item C, makes the necessary corrections, and resubmits the schedule to the Demand Processor. No fatal errors are detected, and schedule item C now processes successfully.

When the Demand Processor begins to re-process this schedule for schedule item C, the header and all lines for schedule item C will have a Processed Status of In Process and a Processed Date indicating the date and time when Demand Processor started to work with the schedule again. The lines for items A and B are not updated.

When the Demand Processor has completed managing and reconciling the demand for schedule item C, the Processed Status and Processed Date are updated on the header and the lines item C. When the entire schedule has been fully processed, the header has the Processed Status of Processed Successfully and the Processed Date reflects the second run. The 10 lines for schedule items A and B have a Processed Status of Processed Successfully and a Processed Date that reflects the first run. The five lines for schedule item C have a Processed Status of Processed Successfully and a Processed Date that reflects the second run.

If the user now examines the current demand for schedule items A, B, and C, they will find that the demand now reflects the new schedule for all three schedule items.

View Schedules in Oracle Release Management Workbench

The Oracle Release Management Workbench has powerful query tools to help you find your demand schedules.

Queries

You can use a variety of query criteria to retrieve both regularly issued and special interim schedules. For example, if you want to find all schedules generated today for a particular customer, select the customer and enter the system date in the Generation Date From field, and then execute the query. From the schedule header information that appears in the Schedule Summary window, you can select the desired schedules and view their details.

Pre-Seeded Queries

Queries, which contain date ranges, have been pre-seeded in the Oracle Release Management Workbench. These queries have dynamic date calculation, executing based on today's date or this week's date range. The pre-seeded queries are:

Saved Queries

You can save queries to facilitate the retrieval of schedules for which you have responsibility. If the saved query contains date ranges, you might need to adjust the dates before executing the query. You could create saved queries for schedule groupings such as:

The newest planning, shipping, or sequenced schedule for a particular customer, ship to location, and organization.

Correct Erroneous Data

Correction Depends on Cause of Exception

Demand Processor Exceptions are corrected by taking appropriate action based on the cause of the exception.

Appropriate action may include one or more of the following:

Response to Errors

In case of fatal errors, the processing is halted and must be restarted as soon as possible. All schedule information needed to query and correct the erroneous data is provided on the report. An immediate response is needed for Fatal Errors.

At times, more than one way of correcting data may be available so that the schedule can be fully processed. This information will be included in exception message text.

Error Correction Example

A set of 12 demand details for a particular ship from / ship to / customer item all have the same invalid unit of measure. Only one exception, rather than 12 exceptions, will be generated for the invalid unit of measure.

To correct the situation that caused the invalid unit of measure exception, the user could take either one of two actions:

Response to Warnings

In case of warnings, all schedule information needed to clarify the situation is provided in the report.

No immediate action is required for the schedule itself because the warning did not halt processing.

However, the condition that triggered the warning should be analyzed and corrected if possible, to reduce the number of warnings in future schedules from the same trading partner. A variety of responses could be applicable:

Responding to Informational Messages

In case of informational messages, all schedule information needed to clarify the situation is provided on the report.

Re submit the Schedule to Demand Processor

Running the Demand Processor

You can re-submit the corrected schedule to the Demand Processor via:

Oracle Release Management Setup Issues

Oracle Release Management Processing Rules Order of Precedence

Attributes used to control Demand Processor actions can be defined at multiple levels within Oracle Release Management. When new Processing Rules are defined, defaults are provided from the next higher level. These defaults can be accepted or overridden, with a different value. However, when a higher value is changed, corresponding lower level values are not automatically updated.

The Demand Processor determines the lowest defined level of all processing attributes using the following order of precedence for Processing Rules:

  1. RELEASE MANAGEMENT Ship From/Address/Customer Item Terms

  2. RELEASE MANAGEMENT Ship From/Address Terms

  3. RELEASE MANAGEMENT Ship From/Customer Item Terms

  4. RELEASE MANAGEMENT Ship From/Customer Terms

The following charts show this order of precedence using the example of Planning Fence Days. The first chart shows customer level terms, the second chart shows address level terms, the third chart shows customer item level terms, and the fourth chart shows the terms that the demand processor uses:

Processing Rule Order of Precedence: Customer Level Terms
Attribute Value for Customer Level Terms
Planning Fence Days 0
Frozen From 1
Frozen To 2
Firm From 3
Firm To 14
OM Forecast From 15
OM Forecast To 25
PLN Forecast From 26
PLN Forecast To 80
Processing Rule Order of Precedence: Address Level Terms
Attribute Value For Address A Terms Value for Address B Terms
Planning Fence Days 0 No terms
Frozen From 1 No terms
Frozen To 3 No terms
Firm From 4 No terms
Firm To 21 No terms
OM Forecast From 22 No terms
OM Forecast To 40 No terms
PLN Forecast From 41 No terms
PLN Forecast To 60 No terms
Processing Rule Order of Precedence: Customer Item Level Terms
Attribute Value For Address A, Customer Item 1 Terms Value for Address A, Customer Item 2 Terms Value for Customer Level, Customer Item 1 Terms Value for Customer Item 2 Terms
Planning Fence Days 0 No terms 0 No terms
Frozen From <null> No terms <null> No terms
Frozen To <null> No terms <null> No terms
Firm From 1 No terms 1 No terms
Firm To 14 No terms 14 No terms
OM Forecast From 15 No terms 0 No terms
OM Forecast To 40 No terms <null> No terms
PLN Forecast From 41 No terms <null> No terms
PLN Forecast To 110 No terms <null> No terms
Processing Rule Order of Precedence: Demand Processor Uses
Attribute Value For Address A, Customer Item 1 Terms Value for Address A Terms Value for Customer Level, Customer Item 1 Terms Value for Customer Terms
Planning Fence Days 0 0 0 0
Frozen From <null> 1 <null> 1
Frozen To <null> 3 <null> 2
Firm From 1 4 1 3
Firm To 14 21 14 14
OM Forecast From 15 22 0 15
OM Forecast To 40 40 <null> 25
PLN Forecast From 41 41 <null> 26
PLN Forecast To 110 60 <null> 80

Consume Demand Hierarchy

The demand Processor recognizes three types of inbound demand schedules:

When demand from more than one of these schedule types exists on the sales order, it is overlaid, or consumed, when a new schedule is processed. It is overlaid based on the value of the Consume Demand Hierarchy Code, while matching on the Match Across Attributes.

When your customer does not use a particular schedule type, choose a value that reflects the desired order of demand consumption for applicable schedule types. For example, when the default Consume Demand Hierarchy value Planning, Shipping, Sequenced is selected:

Note: Changing the value of the Consume Demand Hierarchy Code after demand schedules have been processed is not recommended.

Sales Orders and Forecast Sets

Oracle Release Management requires established sales orders and forecast sets to capture the incoming demand. During the setup process, you must identify these sales orders and forecasts so Oracle Release Management can associate firm and forecast demand appropriately.

Note: Changing the value of the sales order number after demand schedules have been processed is not recommended. Sales order number is a mandatory matching attribute, and changing its setup value will cause the Demand Processor to miss demand on the old sales order when attempting to reconcile old and new demand. The result will be duplicated demand on the old and new sales order.

Booking Order and Order Type

Open, booked orders in Oracle Order Management act as a repository for firm demand transactions. These sales orders remain open to capture demand changes and subsequent requirements. Demand can be sent to different sales orders based on the customer, ship-to address, or item. The number and frequency of sales order setup is dependent upon your requirements.

Depending upon the workflow used for the sales order, you might need to create an activity or order hold that prevents the sales order from automatically closing when all the lines are closed. Without this activity or hold, the Oracle Order Management Close Open Orders process could accidentally close a sales order, preventing any demand transactions from being captured for this order number.

In addition, the sales order should not have a header level purchase order number since multiple purchase orders can now be referenced on a single sales order. Oracle Release Management captures the purchase order number on demand transactions at the line level.

Forecast Interface to Planning

Similar to the sales orders, forecast designators require setup to capture forecast demand transactions. You identify these forecast designators both in the Oracle Advanced Planning and Scheduling Source List and in an Oracle Release Management System Profile. Oracle e-Commerce Gateway does not reference the forecast designator information.

Forecasts Setup

You must define forecast designators, forecast sets, and a forecast source list in Oracle Advanced Planning and Scheduling. The source list must also be specified in the Oracle Release Management system profile to provide the link from the Demand Processor to the correct forecast designator. You can define forecasts at the customer, customer/ship-to, and customer/ship-to/bill-to levels. When defined correctly, the Demand Processor will send transactions to the forecast designator that matches the incoming demand information.

CUM Management and Sourcing Rules

You must coordinate the setup of CUM Management with your supply chain sourcing rules. If you perform CUM Management across Ship Froms (CUM Organization Level set to Ship To/All Ship Forms) you should define sourcing rules that will split the demand across Ship Froms. If you do not perform CUM Management across Ship Froms, you should not have sourcing rules enabled for an item. Since your customer maintains a CUM by Ship From, when you receive a schedule all demand should be placed against the Ship From that they referenced. Otherwise, you will have multiple CUMs based on the multiple Ship Froms that result from the split due to sourcing rules.

Troubleshooting Illustrations

This section describes how you can use Oracle Release Management tools to resolve specific problems related to demand schedule processing. It provides specific examples of demand management processing results that may be helpful when troubleshooting.

Optional Matching Attributes

Oracle Release Management Flexibility

Oracle Release Management provides a great deal of flexibility that enables you to manage demand appropriately for different trading partners. However, it must be carefully set up to reflect the customer's presentation of demand, especially when enabling Optional Matching Attributes. Once established, modifications to Optional Matching Attributes setup can cause unexpected results when new demand transactions are processed against existing demand.

The Demand Processor gives different updated demand results depending on various combinations of these factors:

Matching and CUM Management

These two Optional Matching Attributes are also used as CUM Key components for certain types of CUM Management:

Three demand management factors are important in the context of CUM Management:

Business Relationship Level for CUM Management Setup

The definition of CUM Management attributes and Optional Matching Attributes must be set up at the same business relationship level. If applicable to the type of CUM Management used by your trading partner, always enable the attributes that are used as CUM Key components at the same business relationship level as the CUM Management definition. For example:

Active Status for CUM keys

Oracle Release Management enables you to inactivate CUM keys on the CUM Workbench. This action enables you to inactivate CUM keys that were created in error and to inactivate CUM keys you no longer need. If shipment or adjustment transactions exist for the CUM key, the system will issue a warning before inactivating the CUM key, and ask for verification that you still want to inactivate this CUM key.

Inactive CUM keys are not considered for the following:

CUM Key Components as Optional Matching Attributes

Optional Matching Attributes that are also used as CUM Key components must be synchronized with the CUM Management Type. If applicable to the type of CUM Management used by your trading partner, always enable as a Match Within Attribute the attributes that are used as CUM Key components at the same business relationship level as the CUM Management definition. For example:

Matching Versus Ship From/Ship To/Customer Item Demand Reconciliation

In Oracle Release Management, demand reconciliation tasks are performed for each Ship From/Ship To/Customer Item combination on the schedule. For planning and shipping schedules, the Scheduled Item equates to a Ship From/Ship To/Customer Item. For a sequenced schedule, it equates to a single production sequence number.

e-Commerce Gateway Integration

Unexpected results in the Demand Processor may be caused directly or indirectly by changes to Oracle e-Commerce Gateway components.

These functional areas should be evaluated as the potential cause of problems when troubleshooting:

Inbound Demand Flat Files

Oracle e-Commerce Gateway receives inbound demand transactions from the EDI translator software of your choice as SPSI, SSSI, or PSQI flat files. It loads them as interface schedules into Oracle Release Management.

Inaccurate mapping of schedule data to the flat file can be responsible for unexpected results in the Demand Processor.

If your EDI Translator is an Oracle CAI Partner, default mapping to these flat files may be available for you. However, each trading partner's schedules must be mapped using the default, which introduces the risk of mapping error. Also, the flat file format can be customized within Oracle e-Commerce Gateway, potentially taking it out of sync with the EDI Translator mapping.

If you customize the flat file format within Oracle e-Commerce Gateway, carefully synchronize mapping to your trading partner's schedules with your EDI Translator.

Code Conversions

Oracle e-Commerce Gateway utilizes code conversions to determine the corresponding internal value for several external data elements occurring on the inbound demand schedule before the schedule is loaded into the Demand Processor interface tables. These include Unit of Measure, Schedule Type, Detail Type, Detail Subtype, Date Type, Quantity Type, and Purpose Code.

If you define specific code conversions applying to trading partners or groups of trading partners using search keys, carefully coordinate corresponding mapping to your trading partner's schedules with your EDI Translator and verify that the internal code conversion value accurately reflects the intent and value of the external data element.

Inaccurate mapping of schedule data to specific external code conversion attributes can be responsible for unexpected results in the Demand Processor. For example, if the Detail Type for inventory balance information was inaccurately mapped as Firm Demand, the demand picture would be overstated, introducing a risk of unauthorized shipment.

Trading Partner Definition

By defining trading partner locations within a trading partner group, you establish a link between the business entity defined in the Oracle Applications and the trading partner definition in the EDI translator. For each trading partner, you enable the inbound demand transactions.

Buyouts and mergers may result in changes to customer business relationships. Corresponding changes to Oracle Receivables and Oracle Order Management setup for customers, addresses, and site uses required by these new relationships must be evaluated for their effect upon the Trading Partner Definition and all Trading Partner Specific code conversions in the Oracle e-Commerce Gateway.

In addition, Oracle Release Management Processing Rules must be evaluated for their effect when changes are made to Oracle Receivables and Oracle Order Management setup for customers, addresses, and site uses.

Processing Rules Hierarchy

Implementation of Processing Rules Hierarchy

If the Demand Processor is giving unexpected results, the problem may be caused by a particular processing rule overriding the expected value.

Suppose you change the Default Ship Delivery Pattern Code on the Ship From/Customer Terms to reflect a new customer delivery policy, but neglect to make corresponding changes at the corresponding Ship From/Address Terms or Ship From/Customer Item Terms level. When the next schedule is processed, the old Default Ship Delivery Pattern Code was still used, although you expected the new one to be reflected.

Attributes used to control Demand Processor actions can be defined at multiple levels within Oracle Release Management. It is important to understand that Oracle Release Management Processing Rules at each level are considered to be a complete group of terms for that level. In addition, some attributes can be defined in other Oracle applications.

The Demand Processor determines the lowest defined level and uses all attributes stored at that level, but it does not evaluate each attribute individually across levels. Defaults from the next highest level are initially provided when a new lower level is being entered.

Care should be taken to evaluate the impact on lower levels if a higher level attribute is subsequently changed, since the new attribute value does not automatically cascade down to lower levels. It must be specifically updated at each level to which it applies.

For example, if Ship From/Customer Item Terms are being defined for a Customer Item associated with a particular address, defaults are taken from the corresponding Ship From/Address Terms. If the customer policy requires a change at the Ship From/Address level, all corresponding Ship From/Customer Item Terms that should reflect that change also need to be updated.

The order of precedence for Demand Processor processing attributes is:

  1. Release Management Ship From/Ship To/Customer Item Processing Rules.

  2. Release Management Ship From/Address Processing Rules.

  3. Release Management Ship From/Customer Item Processing Rules.

  4. Release Management Ship From/Customer Processing Rules.

See Oracle Release Management User's Guide.

Trading Partner Toolkit

Trading Partner Specific Attributes and Processing

By extending Oracle Applications with trading partner specific attributes, Oracle Release Management captures information specific to a trading partner and passes this information to sales order lines.

The workflow can be customized to recognize these attributes and perform additional processing using them. Although the Trading Partner Architecture (TPA) layer itself does not have additional matching logic, various parts of the code are enabled in TPA and become available to Layer developers to change if desired.

SeeOracle Automotive Trading Partner Toolkit User's Guide.

Profile Options

RLM: Debug Mode: Use this profile option to obtain details from the Demand Processor. The Debug Mode is especially useful when implementing new trading partners. The Debug report enables you to follow the overall processing steps of Demand Processor, enabling you to follow the logic that was applied for any given requirement. For example, if you received an error message for a particular customer item, you can find the customer item in the debug report and understand why the Demand Processor raised an exception. This report also provides valuable information to Oracle Support and Oracle Development. However, running the Demand Processor with Debug Mode on does adversely affect the performance of the Demand Processor.

XML Gateway Integration

Unexpected results in the Demand Processor might be caused directly or indirectly by changes to components of Oracle XML Gateway.

Evaluate the following functional areas as potential problem causes when troubleshooting:

Code Conversions

Oracle XML Gateway uses code conversions to determine the corresponding internal value for external data elements occurring on the inbound demand schedule before the schedule is loaded into the Demand Processor interface tables. These values include Unit of Measure, Schedule Type, Detail Type, Detail Subtype, Date Type, Quantity Type, and Purpose Code.

If you define specific code conversions using search keys that apply to trading partners, carefully coordinate corresponding mapping to your trading partner's schedules and verify that the internal code conversion value accurately reflects the intent and value of the external data element.

Inaccurate mapping of schedule data to specific external code conversion attributes can be responsible for unexpected results in the Demand Processor. For example, if the Detail Type for inventory balance information is inaccurately mapped as Firm Demand, the demand picture would be overstated, introducing a risk of unauthorized shipment.

Trading Partner Definition

For each trading partner, you enable the inbound demand transactions. The security profile MO: Default Operating Unit is used to determine which Operating Unit will be stamped on the XML message.

Buyouts and mergers may result in changes to customer business relationships. Corresponding changes to Oracle Receivables and Oracle Order Management setup for customers, addresses, and site uses required by these new relationships must be evaluated for their effect on the Trading Partner Definition and all Trading Partner specific code conversions in Oracle XML Gateway.

In addition, Oracle Release Management Processing Rules must be evaluated for their effect on changes made to Oracle Receivables and Order Management setup for customers, addresses, and site uses.