Release Management Processing Rules

This chapter covers the following topics:

• Overview of Processing Rules
• Establish Release Management Processing Rules
• Processing Rules
• Release Management Processing Rules
• Demand Management
• Demand Fences
• Order Management
• CUM Management
• General
• Consume Demand Hierarchy
• Matching Attributes

Overview of Processing Rules

When managing customer demand, you must consider internal and external business rules. These rules dictate how demand is processed into the order management and production fulfillment cycles. The Release Management Processing Rules window provides a single location for defining and maintaining business rules. The rules apply to inbound schedule lines for calculation of the optimum shipment date, quantity, and sourcing information. Release Management Processing Rules are maintained as follows:

• Ship-From/Customer Rules

• Ship-From/Customer Item Rules

• Ship-From/Ship-To Rules

• Ship-From/Ship-To/Customer Item Rules

Processing Rules are defined in terms of specific ship-from organizations. When all rules are consistent for customer addresses and customer items, only the Ship-From/Customer Rules might need to be defined. Processing rules can now be defined for related ship-to addresses. To override rules from the customer level, enter address information at the Ship-From/Ship-To Rules level. If you want to associate a customer item processing rule to a specific address or customer, define processing rules at the Ship-From/Ship-To/Customer Item Rules level or the Ship-From/Customer Item Rules level.

The Demand Processor uses the following hierarchy when processing rules:

1. Ship-from Ship-to Address/Customer Item rules: Different rules for items within the same customer ship-to address.

2. Ship-from Ship-to Address rules: Different rules for addresses within the same customer, regardless of customer items.

3. Ship-from Customer Item rules: Different rules for items within the same customer, regardless of addresses.

4. Ship-from Customer rules: The same rule for all items within all addresses within the customer.

Prerequisites

To define ship-from customer item information, you must perform the following steps:

• Define Customer Addresses. See: Oracle Receivables User's Guide.

• Define Warehouse/Inventory Organization. See: Using Oracle HRMS - the Fundamentals.

• Define Inventory Items. See: Oracle Inventory User's Guide.

• Define Customer Items. See: Oracle Inventory User's Guide.

• Define Pricing Agreements. See: Oracle Order Management User's Guide.

• Define Price List for the preferred inventory item if you do not want to use a pricing agreement on this item. See: Oracle Order Management Implementation Manual.

• Define Sales Order Header. For some inventory items, you may not want to use a Sales Agreement. See: Oracle Order Management User's Guide.

• Define Sales Agreement. For some inventory items, you may not want to use a Sales Order. See: Oracle Order Management Implementation Manual.

• Optionally, Define Customer Receiving Calendar. See: Oracle Shipping Execution User's Guide.

• Define Warehouse Shipping Calendar. See: Oracle Shipping Execution User's Guide.

Establish Release Management Processing Rules

To establish Release Management Processing Rules in Oracle Release Management, add the CUM Management rule to the customer or customer address. This information can be entered by the warehouse or the inventory shipping organization. For every warehouse that does business with a customer address, you can define the CUM Org Level Setup, CUM Rule. The CUM Management rule does the following:

• Determines the CUM Management method.

• Determines Intransit time.

• Determines the sales order number.

  Demand is loaded to the sales order number defined at the lowest level for the ship-from/ship-to relationship.

• Determines the sales agreement and associated rules.

  Demand is loaded to the release order through the sales agreement defined at the lowest level for the ship-from/ship-to relationship.

• Defines any new shipment delivery pattern codes and override transmitted customer codes.

  Oracle Release Management enables you to override the ship delivery pattern code transmitted on inbound customer demand transactions and to select a different code.

  Use the Ship Delivery Pattern Rules window to create custom pattern codes. You can use these codes to set the default ship delivery pattern code on the processing rules window.

Oracle Release Management enables you to access and process transactions for multiple operating units. Use the Operating Unit field on the processing rules window to select the operating field unit name.

Related Topics

Processing Rules

Matching Attributes

Overview of CUM Workbench

Overview of Shipment Delivery Rules

Release Management Demand Processor

Processing Rules

The summary window displays the processing rules and enables you to create new and modify existing rules if you have sufficient security access.

The Release Management Processing Rules window contains the following regions:

• Operating Unit: Lists the name of the operating unit.

  This field displays names of all the operating units for which you have sufficient security access.

• Ship-From Organization: Lists the name and shipping organization code

  These fields are automatically populated if you query an existing record.

• Ship-To Customer: Lists the customer name and number

  This field displays the names and numbers of all the related Ship-to customers. These fields are automatically populated if you query an existing record.

• Alternate tabbed: Includes the Ship to Address, and the Customer Items tabs.

  The alternate tabbed region Ship-To Addresses tab displays the EDI location codes, cities, and addresses for the corresponding customer. The Items At Address Level region displays the processing rules defined for customer items for the selected address. The region includes the following fields:

  • Customer Item

  • Inventory Item

  • Description

  • Commodity Code

  Customer Item displays the customer item, inventory item, description, and commodity code for the corresponding customer selected previously.

Release Management Processing Rules Window

Find Processing Rules

Find Processing Rules Window

This window enables you to query the processing rules using specific selection criteria.

Query the processing rules using a range of criteria:

• Operating Unit: To query processing rules, the operating unit code is defaulted. This represents the supplier's operating unit. You can switch to another operating unit if you have sufficient security access.

• Ship From Org: To limit the query to processing rules for a single organization, enter the organization code that represents the supplier's ship-from location.

• Customer Name/Number: Enter the customer name or number to limit the query to processing rules for a single customer. If you do not specify a customer, all processing rules matching your other selection criteria will appear in the summary window.

• Ship-To Location: Enter the customer shipping address code to limit the query to processing rules for a single customer shipping address. You can also query using a related customer shipping address code. If you do not enter a ship-to location code, demand for all shipping addresses associated with the specified selection criteria will appear in the summary window.

• From Cust Item and To Cust Item: Enter the customer item to limit the query to processing rules for a single customer item. If you do not enter a specific customer item, all processing rules matching your other selection criteria will appear in the summary window.

Note: The following fields are disabled if the operating unit is not defined: Ship-to Location, Address, From Cust Item, To Cust Item.

Related Topics

Matching Attributes

Release Management Processing Rules

Release Management Processing Rules

The Release Management Processing Rules Details window enables you to view details of the processing rules for the selected record in the summary window. You can view referenced information in the following fields:

• Operating Unit

• Customer

• Ship-to Location , City, Address

• Customer Item

Demand Management

The Demand Management tab displays the following information:

• Consume Demand Hierarchy

  See: Consume Demand Hierarchy and Consume Demand Hierarchy Example

• ATS PreHorizon Disposition

  See: Authorized to Ship (ATS) Pre-Horizon Disposition Rule Application

• ATS PreHorizon Cutoff Days

• Use Cust Ship Delivery Pattern

• Default Ship Delivery Pattern

• Demand Tolerance

  See: Tolerance Changes

• Standard Pack Round To

• Standard Pack Quantity

  Important: The Default Ship Delivery Pattern field is mandatory if the Use Customer Ship Delivery Pattern checkbox is not selected.

  Release Management Processing Rules Details Window

  

Demand Fences

The Demand Fences alternate region displays the following information:

• The Frozen, Roll Forward frozen fence, Firm, and Forecast fences to Oracle Order Management.

  See: Demand Fences

• The Forecast fences to Oracle Planning for planning, shipping, and sequenced schedules.

  See: Demand Fences

Release Management Processing Rules Details Window

Order Management

The Order Management alternate region displays the following information:

• Sales Order

  See: Sales Order

• Sales Order Type

• Pricing Agreement

• Purchase Order

• Effective Dates

• Future Pricing Agreement

• Purchase Order

• Effective Dates

• Price List

• Sales Agreement

  See: Sales Agreement

• Release Rule

• Release Time Frame

• Unit of Measure

• Intransit Time, Unit of Measure, Calculation Basis, and Exclude Non-Workdays

The intransit calculation is based on the date given on the Shipped/Received record in the schedule. The intransit calculation in the processing rule determines how shipments need to be reconciled. The intransit calculation is based on the following: (1) Receipt, (2) Shipment, (3) Customer CUM, (4) Shipped Lines, (5) Match on Partially Shipped Lines, (6) None.

• Receipt

• Shipment-

• Customer CUM- Customer CUM reconciles intransit shipments based on Customer’s CUM being correct

• Shipped Lines- Shipped lines reconciles intransit shipments by matching incoming lines to actual shipped lines

• Match on Partially Shipped Lines- Match on Partially Shipped Lines reconciles intransit shipments within mandatory and optional matching attribute by not updating the order line if it the incoming requirement is less than the original quantity but not zero. If the incoming requirement is zero, then the order line is deleted. If the incoming requirement is greater than the original quantity, then it matches incoming lines to actual shipped lines as in Shipped lines. The reconciliation does not take place across matching attributes.

• None-

The Exclude Non-Workdays option indicates whether to include or exclude non-workdays when applying intransit time to calculate the ship date. When the option is set to exclude non-workdays, the Demand Processor evaluates the warehouse shipping calendar to determine which days of the week should be used to calculate intransit time.

Release Management Processing Rules Details Window

CUM Management

The CUM Management alternate region displays the following information:

• Cum Management Type

• Cum Org Level

• Shipment Rule Code

• Yesterday Time Cutoff

• Disable Auto-create CUM Key

Note: The Disable Auto-create CUM Key checkbox is not selected by default.

Release Management Processing Rules Details Window

General

The General tab displays the followingoptions and fields:

• Default Ship From

  See: Ship From Derivation

• Assigned Supplier Code

• Inactive Date

• Notes

• Customer Contact

• Supplier contact

Release Management Processing Rules Details Window

To enter processing rules at the customer level:

1. Navigate to the Release Management Processing Rules window.

2. Select the Customer Name or Number from the list of values.

3. Click Customer Rules to display the Release Management Processing Rules Details window by default at the customer level.

4. Enter processing rules as desired.

5. Click OK to return to the Release Management Processing Rules window.

6. Save your work.

To enter processing rules at the ship-to address level:

1. Navigate to the Release Management Processing Rules window.

2. Select the Customer Name or Number from the list of values.

3. Within the Ship To Address tab, select the Address from the list of values.

4. Click Address Rules to display the Release Management Processing Rules Details window by default at the address level.

5. Enter processing rules as desired.

6. Click OK to return to the Release Management Processing Rules window.

7. Save your work.

To enter processing rules for items at the address level:

1. Navigate to the Release Management Processing Rules window.

2. Select the Customer Name or Number from the list of values.

3. Within the Customer Items tab, select the Customer Item from the list of values.

4. Click Item Rules to display the Release Management Processing Rules Details window by default at the address item level.

5. Enter processing rules as desired.

6. Click OK to return to the Release Management Processing Rules window.

7. Save your work.

To enter processing rules at the customer item level:

1. Navigate to the Release Management Processing Rules window.

2. Select the Customer Name or Number from the list of values.

3. Within the Customer Items tab, select the Customer Item from the list of values.

4. Click Item Rules to display the Release Management Processing Rules Details window by default at the customer item level.

5. Enter processing rules as desired.

6. Click OK to return to the Release Management Processing Rules window.

7. Save your work.

Related Topics

Matching Attributes

Processing Rules

Overview of CUM Workbench

Overview of Shipment Delivery Rules

Consume Demand Hierarchy

Consume Demand Hierarchy logic controls the reconciliation of demand from lower ranking schedules. Demand from a new, higher ranking schedule matches across attributes.

The Demand Processor recognizes three types of inbound demand schedules: Planning, Shipping, and Sequenced. When demand from more than one of these schedule types exists on the sales order or sales agreement, demand from lower ranking schedules is overlaid or consumed by demand on a new, higher ranking schedule. This 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 Schedule Purpose code from Inbound Demand is Replace, Replace All, or Change. The demand overlay or consumption depends on the existing demand scheduled ship date and bucket type in context of the schedule horizon:

• Existing demand is overlaid if the request date and period of time represented by the corresponding bucket type falls completely within the schedule horizon.

• Existing demand is consumed if the request date with bucket type includes a period of time after the schedule horizon end date.

You define the Consume Demand Hierarchy code in the Release Management Processing Rules at the Ship From/Customer or the Ship From/Address levels. You may assign the value that reflects trading partner business practices as to how the inbound demand schedules relate to one another for demand consumption. The choices for Consume Demand Hierarchy code and the corresponding demand consumption rules are:

• Planning, Shipping, Sequenced

  • Planning Schedule does not overlay other schedules.

  • Shipping Schedule overlays Planning but not Sequenced.

  • Sequenced Schedule overlays Shipping and Planning.

• Planning, Sequenced, Shipping

  • Planning Schedule does not overlay other schedules.

  • Sequenced Schedule overlays Planning but not Shipping.

  • Shipping Schedule overlays Sequenced and Planning.

• Shipping, Planning, Sequenced

  • Shipping Schedule does not overlay other schedules.

  • Planning Schedule overlays Shipping but not Sequenced.

  • Sequenced Schedule overlays Planning and Shipping.

• Shipping, Sequenced, Planning

  • Shipping Schedule does not overlay other schedules.

  • Sequenced Schedule overlays Shipping but not Planning.

  • Planning Schedule overlays Sequenced and Shipping.

• Sequenced, Planning, Shipping

  • Sequenced Schedule does not overlay other schedules.

  • Planning Schedule overlays Sequenced but not Shipping.

  • Shipping Schedule overlays Planning and Sequenced.

• Sequenced, Shipping, Planning

  • Sequenced Schedule does not overlay other schedules.

  • Shipping Schedule overlays Sequenced but not Planning.

  • Planning Schedule overlays Shipping and Sequenced.

Consume Demand Hierarchy Example

Suppose you recently received six replacement schedules from your 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 chart illustrates the results of Consume Demand Hierarchy logic for today's demand line:

Consume Demand Hierarchy

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	3	Sequenced
Planning 2	Today	5	Today	3	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.

ATS Pre-Horizon Disposition Rule Application

If unshipped firm demand exists on the sales order or sales agreement dated before the system date, it is managed according to the value of the Authorized to Ship (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. 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, and Cancel All. If the values are Remain on File and, Remain on File with Reconciliation, then no action occurs. If the values are Cancel after N Days and Cancel All, then the existing ATS demands with start date time are deleted.

Note: If you are using Remain on File with Reconciliation and you do not want the past due sales order demand removed, you need to use either a processing constraint in Order Management or a Frozen Fence.

The value you select depends on how the incoming new demand schedule affects past due demand. Some customers change the date of the past due demand to the current or future date, some leave it as it was originally sent, and some delete it and increase the requirements for dates within the new schedule horizon.

Tolerance Changes

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

When the Demand Processor 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 the quantity change does exceed a tolerance, the system processes the change and issues a warning on the exception report.

Demand Fences

You use demand fences to manage the demand on Planning, Shipping, and Sequenced schedules.

The demand fences apply based on the system date. Due demand is determined according to whether it is before the system date, not whether it is before the Schedule Horizon Start Date.

If demand fences are defined, they 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.

Manually entered schedules are not affected by Frozen, Firm, and Demand Fences. Demand fences are defined as follows:

• Frozen: A frozen fence prevents new demand in the Demand Processor from changing the existing sales order demand. 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, regardless of the customer-specified status on the schedule.

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

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

Each type of demand schedule has its own set of frozen, firm, and forecast fences. You can customize demand fence processing to supplier relationships at any of the four levels at which processing rules can be defined.

The following rules apply when you enter From and To Fence Days for a specific schedule type:

• Frozen, firm, and forecast fences cannot overlap or have gaps.

• When multiple fences are defined, firm fences must follow frozen fences and forecast fences must follow firm fences.

• You must enter a From Day before you can enter a To Day.

• A To Day must be greater than or equal to a From Day.

• A NULL From Day means the fence does not apply. The status of demand on the schedule or another fence will be updated to the sales order.

• A ZERO From Day means no demand of this category will be updated to the sales order.

• ZERO is not allowed for Frozen From Day.

• NON-ZERO NUMBER in From Day and To Day means that an effective date range will be calculated using the system date, starting on the From Day and ending on the To Day.

Roll Forward Frozen Fence

The Roll Forward Frozen Fence rule is defined at all Processing Rules levels, by schedule type. Each transaction and schedule type has a flag that indicates if requirements should or should not be rolled forward outside the frozen fence. The following example illustrates the Roll Forward Frozen Fence:

Planning no Frozen Fence defined

• Consume Demand Hierarchy = Planning, Shipping, Sequenced

• ATS PreHorizon Disposition = Remain on File

• Default Ship Delivery Pattern = None

• Intransit Calculation Basis = None

• Planning no Frozen Fence defined

• Shipping with Frozen Fence from 1 to 3 days and Roll Forward Frozen Fence = Yes

a. First Schedule

• Horizon start date = 11-Nov-2002

• Horizon end date = 30-Nov-2002

• System Date = 18-Nov-2002

• Schedule Type = Planning

• Purpose Code = Replace

Line	Detail Type	Sub type	QTY Type	QTY	UOM	Date Type	Start Date
1	Firm	Day	Actual	100	Ea	Ship	14-Nov
2	Firm	Day	Actual	100	Ea	Ship	18-Nov
3	Firm	Day	Actual	100	Ea	Ship	25-Nov

b. Result in Sales Order

Because no frozen fence days were set in the planning schedule, the Demand Processor created each line of the planning schedule in the sales order.

Line	Ship From	Item	Qty Type	QTY	Request Date
1	M2	MT100	Actual	100	14-Nov-2002
2	M2	MT100	Actual	100	18-Nov-2002
3	M2	MT100	Actual	100	25-Nov-2002

c. Second Schedule

• Horizon start date = 11-Aug-2004

• Horizon end date = 30 Aug-2004

• Schedule Type = Shipping

• System Date = 18-Aug-2004

• Purpose Code = Replace

Line	Detail Type	Sub type	QTY Type	QTY	UOM	Date Type	Start Date
1	Firm	Day	Actual	100	Ea	Ship	14-Aug
2	Firm	Day	Actual	115	Ea	Ship	18-Aug
3	Firm	Day	Actual	25	Ea	Ship	22-Aug
4	Firm	Day	Actual	25	Ea	Ship	25Aug

d. Result of Frozen Fence and Roll Forward in Sales Order

Line	Ship From	Item	Qty Type	QTY	Request Date
1	M2	MT100	Actual	100	14-Aug-2004
2	M2	MT100	Actual	100	18-Aug-2004
3	M2	MT100	Actual	15	21-Aug-2004
4	M2	MT100	Actual	25	22-Aug-2004
5	M2	MT100	Actual	25	25-Aug-2004

Explanation of Frozen Fence and Roll Forward in Sales Order Results

The results of the frozen fence and roll forward sales order example are:

• Line 1 was unchanged because it was past due.

• Line 2 was unchanged because it was within the frozen fence. August 18, 19, and 20 are frozen according to the processing rules.

• Line 3 was inserted (first day after frozen fence) to reflect the increase in demand requested on the schedule for frozen days.

• Lines 4 and 5 were updated with the new quantities requested on the schedule for the 22-Aug and 25-Aug dates.

Sales Order

A default sales order is defined and will be used by the Demand Processor to load the demand to the sales order number.

Sales Agreement

A sales agreement is defined as a sales order for a customer that has specific characteristics related to a purchasing agreement between a customer and a vendor. These characteristics may include the date range of the agreement, the items included, the price of the items, and the quantity of each item that the parties committed to, as well as other attributes such as , freight and payment terms.

Once a sales agreement is entered for a customer, multiple releases sales order (shipments) against the sales agreement are processed over a period of time within Oracle Order Management.

The benefits expected with the integration of sales agreement in Oracle Release Management are the possibility of:

• Purging of closed release orders.

• Accumulating actual activity versus agreed activity.

The sales agreement data is defined at all Processing Rules levels with:

• Sales Agreement Number, which will be used as the pricing condition.

• Release Rule, which indicates how items should be combined in the Release Order.

• Release Time Frame, which indicates what the time frame of validity is for an automatically created Release Order.

• Unit of Measure for Release Time Frame in weeks.

Ship From Derivation

To derive the Ship From data and apply the associated Processing Rules, the Demand Processor searches for the Ship From data in several places:

• Ship From derived through the Assigned Supplier Code in the processing rules

• Ship From uniquely defined in the processing rules

• Default Ship From established in the processing rules

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

Oracle Release Management uses the Default Ship From field 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 items.

Matching Attributes

Oracle Release Management enables you to choose specific matching attributes to uniquely identify demand. These matching attributes are used by the Demand Processor to determine if the inbound demand is new demand or a change or changes to existing demand. Flexible matching logic enables you to match incoming demand with existing demand by defining criteria at the address or customer level, thereby enabling you to address the needs of specific business relationships. Additionally, you can reset these values to predefined system defaults at any time. In the matching attributes window, you can view the set of Demand Processor mandatory and optional matching attributes for the current business relationship.

In this window, you can also enable optional attributes that make it possible to customize the matching logic to data elements sent by trading partners on planning/release, shipping, and sequenced schedules.

Evaluate the data elements your trading partners send with item information on planning/release, shipping, and sequenced schedules to determine whether optional matching attributes should be enabled. Enable those attributes included on the demand schedule from the customer that are unique and should not be combined on the same shipment line.

Important: Oracle Release Management supports only attribute 1 to attribute 15 for matching with the order line.

Demand Processor warns if the trading partner demand contains multiple demand lines that have the same Matching Attributes enabled.

A data element can be a matching attribute if any of the following statements is true:

• It is required as turnaround data by the trading partner.

• It is a CUM Key component and the trading partner requires CUM Management.

• Demand associated with a different value for this data element is considered unique by the trading partner.

Additionally, a data element can be a critical attribute if both of the following statements are true:

• It is required as turnaround data by the trading partner.

• It is enabled as a Within Like Schedule Type matching attribute.

If a matching attribute is needed, set the flags for matching Within Like Schedule Type and matching Across Schedule Type according to the needs of the business relationship:

• Within Like Schedule Type: Select the Within Like Schedule Type checkbox if the data element is a Matching Attribute when processing demand for this business relationship and the existing demand comes from the same schedule type.

• Across Schedule Type: Select the Across Schedule Type checkbox if the data element is included on all types of demand schedules for this business relationship and is a Matching Attribute when processing demand, regardless of the type of demand schedules from which the existing demand originated.

• Critical: Select the Critical checkbox if the data element should always have a value as turnaround data. If this box is selected and the attribute is missing on demand, the Demand Processor will issue a warning exception to identify the discrepancy. Before you can enable the data element as a Critical Attribute, you must first enable it as a Match Within Attribute.

To enable optional Matching Attributes:

Matching Attributes Window

1. Navigate to the Matching Attributes window.

2. Select the check boxes corresponding to those matching attributes that you want to enable.

3. Save your work.

Related Topics

Processing Rules

Overview of CUM Workbench