CUM Management

This appendix covers the following topics:

Overview

This appendix addresses the needs for managing and using CUM accounting rules within Oracle Release Management. Although CUM Accounting is not done in many manufacturing environments, it is essential to the automotive industry, which implements cumulative material releasing and material authorizations.

The CUM quantity is the basis for the supplier's cumulative scheduled quantity to which the customer expects shipment compliance. The customer's CUM quantity is included in planning and shipping schedules sent to the supplier, along with identification of the last receipt that updated the customer's CUM. From the customer's CUM, the supplier can accurately determine where they stand in terms of shipping to the scheduled CUM, by comparing their last shipment to the customer's last receipt.

CUM Quantity Example
Quantity Type Month 1 Amount Month 2 Amount Month 3 Amount
Quantity Shipped 50 75 125
CUM Quantity Shipped 50 125 250

CUM Accounting within Oracle Release Management is intended to support the customer's CUM Management requirements. Internal supplier CUM management requirements (CUM by internal part number and CUM rejected) are not a feature of Oracle Release Management.

If CUM Accounting is enabled, CUM quantities are calculated according to the customer's rules, usually as the sum of:

CUM Accounting includes the following CUM management features:

Customer Versus Supplier CUM Synchronization

If CUM Accounting is enabled, it is imperative that the customer and supplier CUM quantities remain in synchronization.

If the supplier is participating in electronic commerce with the customer, the integrity of the CUM can be automatically monitored by both the supplier and customer. On both sides, an investigation of the cause of the discrepancy can be done. An adjustment can be made where needed before the next shipment to the customer.

Supplier Side

If the customer's CUM is included in the inbound electronic planning schedule or shipping schedule, then the customer's CUM can be compared to the supplier's CUM based on the last shipment recognized. If the supplier detects a discrepancy when the demand transaction is processed, an in-house notification can be given.

Customer Side

If the supplier's CUM is included in outbound electronic Advance Ship Notices (ASNs), the customer compares it to his CUM when the ASN is received. If there is a discrepancy, the customer can generate an electronic Receiving Advice or Application Advice transaction to notify the supplier.

To facilitate CUM Accounting, Oracle Release Management supports following features:

For each ship from/ship to/customer item under CUM control, CUM Management can be viewed:

Business Flow

As a supplier, you define the CUM rules for each trading partner. These rules can be set at the ship from/customer level and the ship from/ship to level. An item can be enabled or disabled for CUM management.

Oracle Release Management enables you to inactivate CUM Keys on the CUM Workbench. This 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, 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:

When customers send demand schedules that include CUM information, the Demand Processor will compare the CUM sent in the schedule by the customer with the supplier CUM that exists. A warning is generated if these CUMs do not match.

The Demand Processor converts cumulative quantities to discrete quantities based on Supplier CUM (formerly, based on Customer CUM) and interfaces the demand to Oracle Order Management. The archived schedule contains the customer's CUM and any authorization information sent on the schedule.

Upon shipment, the supplier CUM for the item under CUM management is updated, and the CUM information is sent on the Advanced Shipment Notice (ASN). The CUM history, including all shipments and CUM adjustment transactions, can be viewed on the CUM Workbench.

Tools exist that enable you to create a new CUM Key, either manually or automatically, and adjust previously shipped order lines with a new CUM Key.

Note: By default, a new CUM Key has active status.

The following figure displays the CUM Management process in Oracle Release Management:

CUM Management Process Flow (1 of 2)

the picture is described in the document text

CUM Management Process Flow (2 of 2)

the picture is described in the document text

Using CUM Management

Using CUM Management involves the following:

Define your customer's CUM rule

Receive Inbound Schedules with Cumulative Requirements

Demand Processor - CUM Management Processing

Order Management/Shipping

View and Maintain Supplier CUM

CUM Reset

Define Your Customer's CUM Rule

Each customer can have a different way of calculating CUMs. The customer's CUM rule defines how to calculate the CUM for that customer so the supplier's CUM will be in synchronization. You set up the customer's CUM rule on the Release Management Processing Rules Details form, CUM Management tab. The CUM rule consists of the following components:

All items associated with a Ship-From / Ship-To business entity relationship fall under the same CUM Management rules, however, you can enable a flag on the customer item if you don't want the CUM calculated for this customer item.

Receive Inbound Schedules with Cumulative Requirements

Oracle Release Management enables you to receive electronic demand from your customer. If your customer uses CUMs, the electronic demand may include your customer's current CUM for each item. This information is stored in the Release Management Schedule Archives for each schedule and is also used in the Demand Processor to report any discrepancies between your CUM and your customer's CUM.

The Oracle Release Management supplier CUM shipped is used in the demand processor to derive new and changed demand from your customer (formerly, the customer CUM received was used).

Demand Processor - CUM Management Processing

Automatic Adjustments to the Customer's Demand Based on In-transit Shipments

The Demand Processor compares your customer's last received shipment with the last shipment you sent them to determine if there are in-transit shipments that are not accounted for in the customer's CUM. If so, it will automatically adjust the incoming demand so that the in-transit shipment is accounted for.

If they send CUM quantities, the calculation of the discrete quantities is based upon the supplier CUM (which already incorporates intransit quantities).

CUM Discrepancy Check

As part of Demand Processor, the CUM that the customer sent for an item is compared to the calculated CUM that resides in the Oracle Applications, reflecting the shipments and CUM adjustments that make up supplier's CUM for the customer's item. If the CUMs are discrepant, the Demand Processor indicating the discrepancy generates a warning exception. You then use CUM Adjustments to correct your CUM or communicate the discrepancy to your customer for further investigation.

The Demand Processor also notifies of any change in CUM key values detected in the inbound demand transaction based on the business entity's CUM Management rules, such as change of Cumulative Start Date, Record Year code, or Purchase Order. The Demand Processor will also issue a warning if the CUM Management Type is by Purchase Order Only or By Date and Purchase Order, and there is no PO on the inbound schedule

Note: The Cum Discrepancy Check is performed by the Demand Processor only if the CUM Received information is transmitted by the customer on their schedule. Also, if there is not a corresponding CUM key on file, CUM Discrepancy Check will not be performed.

Calculate Discrete Quantities Using the Supplier CUM Shipped

If the customer has indicated their demand in terms of cumulative rather than discrete quantities, a discrete quantity will be calculated so that it can be imported into Oracle Order Management and Oracle Advanced Planning and Scheduling. The CUM to discrete calculation uses the supplier CUM shipped, existing on the CUM key, to calculate the first discrete bucket.

Formerly, the Demand Processor used the CUM Shipped/Received records on the schedule, plus a calculation for in-transit quantities, to determine the first discrete bucket. With this change, the calculation is simplified, and does not depend on the customer sending CUM Shipped/Received information in the schedule, thereby ensuring a more accurate CUM to discrete calculation.

Order Management/Shipping

CUM Calculation on Your Shipments

For any items under CUM management, an API is executed after a shipment has been confirmed to calculate the CUM. This API assigns a CUM key ID to each sales order line that was shipped, thereby enabling the item's CUM to be dynamically calculated for use by the Demand Processor and the CUM Management Workbench. It also calculates the supplier's YTD CUM, and updates the shipped order line with this information

CUM Calculation for CUM enabled items includes the following events:

CUM Calculation

CUM Calculation is performed when the CUM Discrepancy Check is performed in the Demand Processor and when reporting on shipment of customer demand after the correct CUM key has been determined wherever CUM must be shown (Shipping documents and electronic ASN).

When the CUM Management style CUM By Date Only is enabled, the supplier CUM will be calculated according to the Shipment Inclusion Rules from shipments and CUM adjustments dated since the current Cumulative Start Date associated with the Customer Ship-To/Ship-From Terms relationship or the Ship From/Customer Item relationship

When the CUM Management style CUM By Date and Record Year is enabled, the supplier CUM is calculated according to the Shipment Inclusion Rules from shipments, and CUM adjustments dated since the current Cumulative Start Date and referencing the same Record Year as the customer demand being shipped indicates.

When the CUM Management style CUM By Date and Purchase Order is enabled, the supplier CUM is calculated according to the Shipment Inclusion Rules from shipments, and CUM adjustments dated since the current Cumulative Start Date. The same Customer Purchase Order Number is referenced as the customer demand being shipped indicates.

When the CUM Management style CUM By Purchase Order Only is enabled, the supplier CUM is calculated according to the Shipment Inclusion Rules from shipments, and CUM adjustments associated with the same Customer Purchase Order Number as the customer demand being shipped indicates.

Adjustments are immediately included in the CUM quantity, regardless of the transaction date associated with them.

Shipment Inclusion Rules do not apply to CUM Adjustment transactions.

Note: The Cumulative Start Date and Purchase Order Date is derived from the latest customer inbound schedule.

Automatic CUM Key Creation

The CUM key is not associated with sales order line demand until Ship Confirmation (i.e. it is not calculated by the Demand Processor, since attributes affecting the CUM key could be modified before shipment). The Demand Processor does not create a new CUM key, but it will issue a warning exception for this situation if the customer demand schedule includes CUM information.

If a new CUM key is automatically created, the data required for the CUM management type is obtained from a combination of the sales order line and the archived schedule.

View and Maintain Supplier CUM

View Item CUM Information Within Oracle Release Management Forms and Reports

The Release Management Workbench displays sales order information with the appropriate item CUM information. Also, the Demand reports and the Horizontal Demand window in the Release Management Workbench displays CUM information with future and historical visibility.

View CUM Information for an Item on the CUM Workbench

The CUM Management Workbench displays the shipment transactions and adjustments that make up an item's CUM. A complete history of all the CUM keys for the customer item can also be viewed in this form, on the CUM Details window.

Oracle Release Management enables you to inactivate CUM keys on the CUM Workbench. This 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, before inactivating the CUM key, the system will issue a warning, and will request verification that you still want to inactivate this CUM key.

Inactive CUM keys are not considered for the following:

Also, the Demand Status Inquiry Report displays CUM information for the customer item enabled for CUM Management.

Create a New CUM Key When the Customer Resets the CUM

Occasionally (usually annually), customers might reset their CUM. When they do this the Demand Processor issues a warning exception stating that CUM key relevant data changed on the latest incoming customer schedule. You can then choose to manually create a new CUM key on the CUM Management Workbench form, on the Create CUM keys window, or let the system create it automatically with the next shipment.

You can also inactivate CUM keys on the CUM keys Details window by clearing the Active flag and adding information in the Comments field.

Manual Versus Automated CUM Key Creation

To invoke an automated CUM Reset, you must create a new CUM key. To do so, you must first either change the value of any of the CUM key variables on the Processing Rules Setup form or process a new customer schedule with changed CUM key data. Then a new CUM key must be created either manually on the CUM Management Workbench form or automatically at the time of the next shipment.

For example, when the CUM start date is a factor and it has changed on the latest customer schedule, the Demand Processor will issue a warning and a new CUM key will be created with the next shipment.

If you want to reset the CUM key on previously shipped order lines, you must launch the concurrent program; Adjust CUM Transactions CUM key ID. See: Optionally adjust the CUM key identifier on shipment transactions.

The following identifies what happens when the CUM is reset (when a new CUM key is created) based on CUM Management Type:

Perform a CUM Adjustment Transaction to Set the Current CUM

The CUM Adjustments feature on the CUM Workbench form enables you to adjust the CUM for a particular item. You can use this feature to manually set the initial CUM figure for the item after you manually created the new CUM key or when you cut over to the Oracle Release Management Application.

Note: Cum Transactions CUM key Adjustment concurrent program is for assigning a CUM key ID to Oracle shipments and it should not be used for adjusting a particular CUM.

CUM Reset

Optionally adjust the CUM Key identifier on shipment transactions

When a customer resets the CUM, they can back date the CUM start date so that it is in the past. When this happens, you might need to reset the CUM Key ID on the shipments and CUM adjustment transactions that have occurred since the start of the new CUM rule. Use the CUM Transactions CUM Key Adjustment concurrent program for this. It requires a CUM start date along with some other CUM Key relevant information as parameters. The program not only resets the shipment transactions and CUM adjustment transactions that are affected, but also recalculates the CUM for the old and new CUM Keys.

Special Considerations

There are certain issues that you should be aware of when using CUM Management.

CUM Management and Sourcing Rules

When you are using the Ship to/Ship from - CUM Organization Level, you should not make use of any Sourcing Rules at the same time or you will either have to constantly manually adjust the CUM Quantity or receive CUM Discrepancy Exceptions from the Demand Processor.

Return Material Authorizations

Return Material Authorizations (RMAs) do not automatically update the CUM. If you want to adjust the CUM for an RMA, you must perform a CUM Adjustment Transaction using the CUM Management Workbench.

DSP - CUM Discrepancy Warnings

Since the two CUM key attributes, CUM Start Date and Customer Purchase Order Number, are derived from the latest customer schedule received, changes to either of these two values will automatically result in a CUM Reset/New CUM Key Creation at the time of the next shipment. Therefore, it is recommended that you check the Demand Management Exception Report for CUM key Discrepancy Warnings regularly. In cases where there are doubts whether the change of one of these values might be a mistake in the inbound schedule, the customer should be contacted before shipping any items for that particular schedule.

If you did ship an item with the wrong CUM key being applied, you must first create a new CUM key (either manually or automatically after the customer sends a new schedule with the correct CUM relevant data) and then run the Adjust CUM Transactions CUM Key ID program.

Manual Schedule Entry

As previously mentioned, the two CUM key attributes, CUM Start Date and Customer Purchase Order Number, are derived from the customer schedule (as opposed to other CUM Management setups like CUM Org Level, etc.) that are set up in the Processing Rules form. Because changes to either of these two values will automatically result in a CUM Reset/New CUM key Creation at the time of the next shipment, you should be very carefully when entering these values manually. Always make sure that the entered values correspond to the current CUM key unless you explicitly want to establish a new CUM Rule/Key.