This appendix covers the following topics:
This appendix focuses on using the Demand Processor, the starting point of the Oracle Release Management solution for meeting two key industry needs:
Customers and suppliers must reduce lead time across their supply chain. (Oracle EDI communications address this need.)
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:
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
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.
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:
Process customer demand schedules loaded via Oracle e-Commerce Gateway or Oracle XML Gateway for Inbound Demand or manual schedule entry, order in which they were generated by the customer
Process schedules manually entered on the Oracle Release Management Workbench
Validate customer demand schedules for data errors and generate exceptions as needed
Archive customer demand schedules for future reference
Net customer demand schedules to existing demand according to schedule type, schedule purpose code, and flexible Oracle Release Management Processing Rules
Resubmit corrected erroneous schedules for processing
Provide timely visibility to current customer firm and planning requirements
The following figure shows the inbound demand processing flow:
Inbound Demand Processing Flow
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.
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.
Oracle Release Management's processing engine, the Demand Processor, completes into the following procedures:
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, application of frozen, firm and forecast fences, aggregation of demand, and rounding to standard pack quantity.
Reconcile Old/New Demand: Processing appropriate for schedule purpose code, getting eligible and matching sales order lines, performing reconciliation of customer and supplier shipments, cancellation or reconciliation of Past Due sales order lines, reconciliation of Restricted demand, matching of new demand to existing sales order lines, and updating the sales order or the release orders forecast.
The Demand Processor generates appropriate warning and error exceptions and informational messages during each of these procedures.
Demand Processing
Launch the Demand Processor in one of these ways:
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.
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.
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.
Oracle Release Management stores the exceptions encountered during Demand Processing and provides various means of viewing them:
View the exceptions for a schedule online using the Oracle Release Management Workbench.
Run the Oracle Release Management Exceptions Report as a separate concurrent process by specifying flexible report parameters.
Exceptions for a schedule are automatically purged when this schedule is re-processed. If errors and warnings still exist with the schedule, new exception messages are generated.
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.
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:
Save and execute queries
View customer demand schedules
View Demand Processor Exceptions
Correct errors on customer demand schedules
View archived customer demand schedules
View horizontal picture of customer demand from schedule
View current customer demand
View horizontal picture of current customer demand with Ahead/Behind status
View customer item information
View shipment history
View authorization history
See Oracle Release Management User's Guide.
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:
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 |
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.
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.
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:
Applicable Schedule Type, Horizon, and Purpose Code
Applicable Frozen, Firm, and Forecast Time Fences
Applicable Shipment/Delivery Codes
In Transit time
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.
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:
Inbound EDI Planning Schedules (SPSI)
Inbound EDI Shipping Schedules (SSSI)
Inbound EDI Production Sequence Schedules (PSQI)
The following figure details how you can automate the EDI demand management process:
EDI Demand Processing Automation
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
Oracle Release Management Demand Processor is an open interface that can accept schedules to be processed from various sources, including those:
Loaded electronically via Oracle e-Commerce Gateway, which receives inbound demand transactions from the EDI translator software of your choice as SPSI, SSSI, or PSQI flat files
Loaded electronically via Oracle XML Gateway as XML files
Loaded manually via schedule entry using Oracle Release Management Workbench
Loaded programmatically via a custom interface with a legacy system
After the inbound demand schedule is loaded, the Demand Processor concurrent program is launched.
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.
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.
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.
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.
Oracle Release Management's Demand Processor uses several distinct phases:
The Validation procedure validates the schedule in the demand interface table and derives some values and internal identifiers
The Archive procedure places the validated schedule in the permanent historical tables for future reference.
The Manage New Demand procedure prepares the new demand for reconciliation by converting of cumulative quantity, applying sourcing rules, calculating ship dates, applying demand fences, aggregating demand, rounding to standard pack, and identifying CUM discrepancies.
The Reconcile Old/New Demand procedure compares the demand lines to the existing order lines in Oracle Order Management, and makes the required changes in the order lines to process the new schedule in context of its purpose code and horizon, and to consume existing demand of less granular schedules accordingly.
The Process Order procedure integrates the demand updates with the sales order or the release order and its workflow.
The Forecast Processor optionally updates Oracle Advanced Planning and Scheduling's forecasts.
Exceptions generated during any of these phases appear in the Exceptions report.
The customer can generate multiple demand schedules in a short time. For example:
An original shipping schedule is issued on 1-Oct at 07:45, a cancellation shipping schedule is issued on 1-Oct at 7:48, and another original shipping schedule is issued on 1-Oct at 07:50. To net correctly, they must be processed in order: first original, cancellation, and second original.
A replacement planning schedule issued on 1-Oct at 07:00 is followed by another replacement planning schedule issued on 1-Oct at 09:00. To net correctly, they must be processed in order: first replacement and then second replacement.
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:
If EDI Control Number columns are populated, unprocessed schedules are sorted in the following order: Trading Partner Translator Code, Trading Partner Location Code, Schedule Generation Date/Time, EDI Control Number 2, EDI Control Number 3, Schedule Type, Schedule Reference Number, Schedule Purpose, and Creation Date.
If EDI Control Number columns are not populated, unprocessed schedules are sorted in the following order: Trading Partner Translator Code, Trading Partner Location Code, Schedule Generation Date/Time, Schedule Type, Schedule Reference Number, Schedule Purpose, and Creation Date.
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:
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 |
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.
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.
All required internal IDs are derived from codes and numbers provided.
To derive the Ship From value and apply the associated Processing Rules, the Demand Processor uses:
Ship From value derived from the Assigned Supplier Code in processing rules
Ship From value uniquely defined in processing rules
Default Ship From value selected in processing rules (if multiple processing rules are found)
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.
Various types of validations are performed on the schedule header and lines:
All mandatory columns must contain a valid value.
Relationships between customer and supplier locations must be valid and active.
Sales Order number, pricing agreement or price list, and assigned must be valid and active.
Sales agreement number, release rules associated, and assigned must be valid and active.
Optional Matching Attributes enabled as Critical Attributes will generate a warning exception if the attribute is not populated.
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.
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:
Find a Forecast Name that has the same Customer, Ship-To, and Bill-To.
If no match is found, find a Forecast Name that has the same Customer and Ship-To.
If no match is found, try to find a Forecast Name that has the same Customer.
If no match is found, create an error message.
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.
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.
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:
If the schedule header and all lines associated with all schedule items passed validation, the schedule is fully archived.
If the schedule header passed validation and some schedule items passed validation, the schedule is partially archived. The header and the lines associated with the schedule items that passed validation are archived, and the lines associated with the schedule items that failed validation remain only in the interface table.
If the schedule header has fatal errors, the schedule is not archived.
If the schedule header passed validation but all schedule items have one or more fatal errors, the schedule is not 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 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.
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.
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:
Ship From/Customer (mandatory)
Ship From/Customer Item (optional)
Ship From/Address (optional)
Ship From/Address/Customer Item (optional)
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.
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.
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:
Ship/Delivery Pattern Codes
In-Transit Lead Time
Ship From Calendar by Organization/Warehouse
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.
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:
Frozen fence
Firm fence
Forecast to OM fence
Forecast to PLN fence
Optionally, demand fences can be defined at the following levels:
Ship From/Customer
Ship From/Customer Item
Ship From/Ship To
Ship From/Ship To/Customer Item
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
This identification triggers the placement of demand to sales order lines and optionally planning forecasts:
Firm demand (ATS) is interfaced to sales order lines depending on how demand is categorized on the schedule and how frozen and firm fences are set up.
Forecast demand is interfaced to either sales order lines (NATS) or Planning depending on how demand is categorized on the schedule and how forecast fences are set up.
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:
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.
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.
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.
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.
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:
CUM processing by Demand Processor.
CUM key adjustment program.
CUM calculation at Ship Confirm.
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.
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:
None: Select this option if you do not want any intransit calculations to take place. This is the default.
Schedule Based Information: Select this option for last receipt information (Receipt) or last shipment information (Shipment) or Customer CUM as intransit calculation basis.
Shipped Lines: Select this option for the calculation to consider a new demand line as intransit if a matching shipped order line is found.
Match on Partially Shipped Lines: Select this option if you do not want to update your order line that is partially shipped, and the incoming requirement is less than the original quantity, but not zero.
Last Receipt Information: Select last shipment information on the schedule, or None for the In-transit Calculation Basis parameter in the Processing Rules. The Demand Processor uses this parameter to calculate the intransit shipments and subtract the intransit quantity from the customer's requirements. The default is None.
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.
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:
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:
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 |
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:
An exact match indicates that the new demand line is either identical to a previously transmitted demand line or non-key attributes were modified.
A mismatch indicates that the new demand line occurs in any of the other key attributes, which means this is a new requirement record.
If everything matches except for the planned shipment date, then this is a roll-forward requirement for a previously transmitted demand line.
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.
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.
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.
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:
Add
Cancellation
Change
Confirmation
Delete
Original
Replace
Replace All
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:
Date = Today, Quantity = 50
Date = Tomorrow, Quantity = 0
Existing Order Lines within the schedule horizon from other Shipping Schedules:
Date = Today, Quantity = 10
Date = Tomorrow, Quantity = 20
Resulting Order Lines from Shipping Schedules within the schedule horizon for various Schedule Purpose Codes:
Replace 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 |
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.
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.
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:
Remain on File
Remain on File with Reconciliation
Cancel after N Days
Cancel All
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.
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:
Planning
Shipping
Sequenced
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:
Existing demand is overlaid (replaced) if its scheduled ship date and period of time represented by its corresponding bucket type falls completely within the schedule's horizon
Existing demand is consumed if its scheduled ship date with bucket type includes a period of time after the schedule's horizon end date
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 Schedule does not overlay other schedules
Shipping Schedule overlays Planning but not Sequenced
Sequenced Schedule overlays Shipping and Planning
Planning Schedule does not overlay other schedules
Sequenced Schedule overlays Planning but not Shipping
Shipping Schedule overlays Sequenced and Planning
Shipping Schedule does not overlay other schedules
Planning Schedule overlays Shipping but not Sequenced
Sequenced Schedule overlays Shipping and Planning
Shipping Schedule does not overlay other schedules
Sequenced Schedule overlays Shipping but not Planning
Planning Schedule overlays Shipping and Sequenced
Sequenced Schedule does not overlay other schedules
Planning Schedule overlays Sequenced but not Shipping
Shipping Schedule overlays Planning and Sequenced
Sequenced Schedule does not overlay other schedules
Shipping Schedule overlays Sequenced but not Planning
Planning Schedule overlays Sequenced and Shipping
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:
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.
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.
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.
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.
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 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.
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.
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.
This section describes how the Order Processing procedure updates sales order lines in Oracle Order Management.
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.
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.
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.
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:
Schedule Purpose = Add. Add new lines to the forecast designator specified on each individual line.
Schedule Purpose = Delete/Cancel. Delete all records for the inventory item within the forecast designator.
Schedule Purpose = Replace/Change/Original. Replace all records for the inventory item within the forecast designator.
Schedule Purpose = Replace All. Enables you to completely replace the demand for all items in the forecast designator. As explained previously, the purpose code Replace replaces on an item-by-item basis. The Demand Processor deletes the forecast for a given item and then inserts new demand for that item, without updating the other items on the forecast. With Replace All, the Demand Processor first deletes demand for all items in the forecast designator and then inserts the new schedule forecast demand.
Schedule exceptions have three levels of severity: Information, Warnings, and Fatal Errors.
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.
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 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:
Identify errors and their causes
Examine the schedule
Correct the erroneous data
Re-submit the schedule to the Demand Processor
If exceptions are generated while processing the schedule, the Oracle Release Management Exceptions Report will contain the information. Using this report, do the following:
Identify any fatal errors on the Exceptions report. These require immediate action.
Identify the cause of each fatal error.
Demand Processor Exceptions could be caused by various situations, including:
Missing or inaccurate Oracle Receivables setup; for example customers, addresses, site uses
Missing or inaccurate Oracle Order Management setup; for example. Sales Order, Pricing Agreement, Price List
Missing or inaccurate Oracle Inventory setup; for example, Inventory Item, Customer Item, or Unit of Measure
Missing or inaccurate Oracle Release Management Processing Rules setup
Missing or inaccurate mandatory schedule data elements
Incorrect mapping of schedule data elements to the appropriate Oracle e-Commerce Gateway flat file for inbound demand schedules
Missing or improper code conversion in the Oracle e-Commerce Gateway for inbound demand schedules
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 Date
Note: The Oracle Release Management Workbench can also display customer demand schedule transactions before they have been validated, archived, and processed by the Demand Processor. The schedule status and processing time-stamp enable the user to distinguish processed schedules from unprocessed ones.
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.
The Processed Status of a schedule header reflects the status the entire schedule. Schedule Header Processed Status can have any of the following values:
Available To Process: Indicates the schedule has not yet been validated, archived, or managed through the Demand Processor.
In Process: Indicates the schedule has not yet been completely processed through the Demand Processor and should not be viewed.
Processed with Error: Indicates the schedule has been validated and has fatal errors that prevented any further processing of the header or any corresponding lines through the Demand Processor. This schedule did not update the netted demand.
Processed Successfully: Indicates the schedule and all its corresponding lines were completely and successfully processed through the Demand Processor and have updated the netted demand.
Partially Processed With Errors: Indicates the schedule has some lines that were fully processed and some that were not. Check the status of the corresponding lines.
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:
Available to Process: Indicates the schedule line has not yet been validated, archived, or managed through the Demand Processor.
In Process: Indicates the schedule line has not yet been completely processed through the Demand Processor, and should not be viewed.
Processed with Error: Indicates the schedule line has been validated and at least one schedule line in the schedule item group has fatal errors that prevented any further processing of the schedule item group through the Demand Processor. This schedule item group did not update the netted demand, but it is possible that other schedule item groups on this schedule were completely processed.
Processed Successfully: Indicates all lines in the schedule item group processed completely and successfully through the Demand Processor and have updated the netted demand.
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.
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.
The Oracle Release Management Workbench has powerful query tools to help you find your demand schedules.
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.
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:
This week's planning, shipping, or sequenced schedules.
Today's planning, shipping, or sequenced schedules.
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.
All schedule types for a particular customer, ship to location, and organization
All schedules with a particular status (for example, Error, Available to Process)
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:
Oracle Receivables set-up (for example, customers, addresses, site uses)
Oracle Order Management set up (for example, Sales Order, Pricing Agreement, Price List)
Oracle Inventory set up (for example, Inventory Item, Customer Item, Unit of Measure)
Oracle Release Management Processing Rules set up
Adding or correcting schedule data fields using the Oracle Release Management Workbench
Correcting the EDI Translator mapping of schedule data elements to the appropriate Oracle e-Commerce Gateway flat file for inbound demand schedules
Adding or correcting Code Conversions in the Oracle e-Commerce Gateway for inbound demand schedules
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.
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:
Change the UOM to be a valid value on each schedule line where it occurs using the Oracle Release Management Workbench
Define the UOM and corresponding UOM conversions in the Oracle Units of Measure form in Oracle Inventory
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:
For some warnings, such as invalid external Unit of Measure, you may need to implement trading partner specific code conversions in the e-Commerce Gateway
For some warnings, such as Pricing Agreement exceptions, you may need to update the Oracle Release Management Processing Rules that reference the attribute, the base table, or both where the attribute is defined
For some warnings, such as Tolerance Limits, you may need to take subsequent action on the sales order line before shipping
For some warnings, such as CUM Discrepancy, you may need to investigate the difference between supplier and customer cumulative quantities, and possibly make a CUM adjustment before the next shipment
In case of informational messages, all schedule information needed to clarify the situation is provided on the report.
You can re-submit the corrected schedule to the Demand Processor via:
Submit Demand Processor option under the Tools menu on the Oracle Release Management Workbench form
Standard Report Submission form
Demand Transactions option from the Oracle Release Management menu
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:
RELEASE MANAGEMENT Ship From/Address/Customer Item Terms
RELEASE MANAGEMENT Ship From/Address Terms
RELEASE MANAGEMENT Ship From/Customer Item Terms
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:
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 |
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 |
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 |
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 |
The demand Processor recognizes three types of inbound demand schedules:
Planning Schedule (830/DELFOR/DELINS)
Shipping Schedule (862/DELJIT/DELINS)
Sequenced Schedule (866/DELJIT/SYNCRO & SYNPAC)
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:
Planning Schedule does not overlay other schedules
Shipping Schedule overlays Planning but not Sequenced
Sequenced Schedule overlays Shipping and Planning
Note: Changing the value of the Consume Demand Hierarchy Code after demand schedules have been processed is not recommended.
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.
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.
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.
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.
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.
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.
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:
Whether or not a particular attribute is enabled as an Optional Matching Attribute in Oracle Release Management Processing Rules
Whether or not enabled Optional Match Within Attributes correspond to enabled Optional Match Across Attributes
Whether or not successive inbound demand schedules are consistent in the presentation of demand using the Optional Matching Attribute
Whether or not Oracle Release Management Processing Rules are modified for Optional Matching Attribute after demand transactions have been processed
These two Optional Matching Attributes are also used as CUM Key components for certain types of CUM Management:
Record Year
Purchase Order
Three demand management factors are important in the context of CUM Management:
Business relationship level for CUM Management Setup
Active status for CUM keys
CUM Key Components as Optional Matching Attributes
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:
If the CUM Management is defined at the Ship-From/Customer level, enable Optional Matching Attributes at the Ship-From/Customer level
If the CUM Management is defined at the optional Ship-From/Address level, enable Optional Matching Attributes at the Ship-From/ Address level
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 processing by Demand Processor
CUM key adjustment program
CUM calculation at Ship Confirm
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:
If the CUM Management Type is CUM By Date and Record Year, enable Record Year as a Match Within Attribute
If the CUM Management Type is CUM By Date and Purchase Order, enable Purchase Order as a Match Within Attribute
If the CUM Management Type is CUM By Purchase Order Only, enable Purchase Order as a Match Within Attribute
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.
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
Code conversions
Trading partner definition
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.
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.
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.
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:
Release Management Ship From/Ship To/Customer Item Processing Rules.
Release Management Ship From/Address Processing Rules.
Release Management Ship From/Customer Item Processing Rules.
Release Management Ship From/Customer Processing Rules.
See Oracle Release Management User's Guide.
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.
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.
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
Trading partner definition
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.
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.