Synchronizing CUMs based on cumulative model

If both customers and suppliers use LN to communicate schedule requirements, cumulatives are synchronized based on an order based or receipt based cumulative model, which you can define in the CUM Model used field of the Items - Sales Business Partner (tdisa0510m000) and/or the Sales Contract Line Logistic Data (tdsls3102m000) session.

For more information on how to use these models, refer to Adjusting sales schedules.

Resetting cumulatives

Over time, the cumulatives can be incremented to very high values. To reduce these values, you can reset the cumulatives in the Reset Cumulatives (tdsls3230m000) session. Although this reset is usually performed at the end of the year, the CUMs cannot be reset exactly when the year is changing. As a result, updates can be stored in the cumulative sessions after the reset date. By calculating a reset quantity, these values are also included in the reset process.

To reset the cumulatives successfully, the following conditions must be fulfilled:

  • Suppliers and customers must use the same CUM reset date when resetting the cumulatives in the Reset Cumulatives (tdsls3230m000) and Reset Cumulatives (tdpur3230m000) sessions.
  • Resetting can only take place when the releases sent by the customer, are received and approved by the supplier. If not, suppliers cannot approve releases that are processed after the reset date, because the reset dates are different.
  • Suppliers must not update incoming releases or manually create new releases, because resetting can then result in wrong quantities.
Note: 
  • You cannot reset the sales schedule cumulatives for the sales schedule if a reconciliation record exists with the Dispute status and a Transaction Date before the CUM reset date. You can view sales schedule reconciliation records in the Sales Schedule Reconciliation (tdsls3131m000) session.
  • The cumulatives that are stored in the Sales Schedules (tdsls3111m000) session for a specific sales schedule revision, are not updated during the reset process. They are kept as history information.

Calculating the reset quantity

If you reset cumulatives in the Reset Cumulatives (tdsls3230m000) session, LN first determines the reset quantity.

To calculate the reset quantity:

  1. LN retrieves the reset quantity from the last CUM record prior to the CUM Reset Date that you specified in the Reset Cumulatives (tdsls3230m000) session. Which quantity is the reset quantity depends on the CUM Model used.

    If the CUM Model used is:

    • Order Based, the Prior Required CUM is the reset quantity.
    • Receipt Based, the Received CUM is the reset quantity.

  2. LN creates new cumulative records.

    LN creates a new:

    • Shipped CUM record in the Shipped CUM (tdsls3532m000) session.
    • Invoiced CUM record in the Invoiced CUM (tdsls3533m000) session.

    For the new CUM records:

    • The Cumulative Reset Date is equal to the CUM Reset Date that you specified in the Reset Cumulatives (tdsls3230m000) session.
    • The Status is Reset.

Resetting the shipped CUM

For a new shipped CUM record, LN decreases the following quantities with the reset quantity:

  • Cumulative Shipped Quantity.
  • Received CUM.

If already shipped CUM records exist with transaction dates later than the Cumulative Reset Date, LN copies these records with the following adjustments:

  • The Cumulative Shipped Quantity and Received CUM are also decreased with the reset quantity.
  • The old Cumulative Reset Date is replaced with the new Cumulative Reset Date.

Resetting the invoiced CUM

In case of a new invoiced CUM record, LN decreases the Cumulative Invoiced Quantity with the reset quantity.

If already invoiced CUM records exist with invoice dates later than the Cumulative Reset Date, LN copies these records with the following adjustments:

  • The Cumulative Invoiced Quantity is also decreased with the reset quantity.
  • The old Cumulative Reset Date is replaced with the new Cumulative Reset Date.

Example 1 - Resetting the cumulatives for an Order Based CUM model

  • Reset date = start week 3
  • The schedule lines are generated before the reset takes place
  • Schedule line 2 is received in week 3
  • Schedule line 3 is received in week 5
Week Line 1 Prior required CUM before reset Line 2 Prior required CUM before reset Line 3 Prior required CUM before reset Prior required CUM after reset
1 20 20 - 20 - 20 20
2 20 40 - 40 - 40 40
3 20 60 5 45 - 45 5
4 20 80 5 50 - 50 10
5 20 100 5 55 20 70 30
6 20 120 55 110 5 75 35
7 - - 5 115 5 80 40
8 - - 5 120 5 85 45
9 - - - - 5 90 50
10 - - - - 5 95 55

TOTALS CUM line 1 CUM line 2 CUM line 3 CUMs after reset
Start CUM 0 40 50 10

The reset date starts in week 3. Because of the Order Based CUM model, resetting is carried out based on the prior required cumulatives. At the end of week 2, the reset quantity is 40. As a result, all CUMs are updated by -40 from the CUM reset date (week 3) on.

Example 2 - Resetting the cumulatives for a Receipt Based CUM model

Take the same data from the previous example, but also take into consideration the following data:

Week Received qty. Received CUM before reset Received CUM after reset
1 10 10 10
2 25 35 35
3 20 55 20
4 - 55 20
5 5 60 25

The reset date starts in week 3. Because of the Receipt Based CUM model, resetting is done based on the received cumulatives. At the end of week 2, the reset quantity is 35. As a result, all CUMs are updated by -35 from the CUM reset date (week 3) on.

The totals from example 1 would then arrive at:

TOTALS CUM line 1 CUM line 2 CUM line 3 CUMs after reset
Start CUM 0 40 50 15
Related topics