Overview

The application considers the End-of-Life (EOL) date during forecast generation and disaggregation. The discontinued planning items do not receive forecast values beyond their EOL period, while active items continue to receive the applicable forecast.

Support End-of-Life (EOL) Date

End-of-Life (EOL) Date

• The application supports EOL (End-of-Life) Date as a standard attribute for planning items.
• The EOL Date identifies the bucket from which a planning item is no longer considered for forecast generation.
• The EOL Date can be enabled for applicable Master Data Entities, such as:
  • Product
  • Customer
  • Location
  • Source
• When an EOL Date is available for a planning item:
  • The application considers the item for forecast generation only until the applicable EOL period.
  • From the corresponding EOL bucket onward, the application excludes it from forecast generation.
  • The EOL Date therefore determines when the planning item stops participating in future forecast generation.

Validate Discontinued and EOL Items During Forecast Generation

• During forecast generation, the application evaluates the applicable Is Discontinued status and EOL Date for the planning items included in the selected forecast filter criteria.
• The application uses this information to determine whether each planning item is eligible to participate in forecast generation.
• If a planning item is already discontinued, where Is Discontinued = Yes:
  • The item is excluded from forecast generation.
  • The item remains excluded irrespective of whether an EOL Date is available.
  • The EOL Date does not change this behavior when the item is already marked as discontinued.
• When an item is marked as Is Discontinued in a past or current bucket:
  • Its historical information is also ignored when generating forecasts at higher hierarchy levels.
  • The discontinued item does not contribute its historical information to the applicable higher-level forecast generation.

Forecast Generation at the Product/Leaf Level

• When the application generates a forecast at the Product/leaf level, the application evaluates the Is Discontinued status and EOL Date for each applicable planning item.

• The application determines each item's forecast eligibility based on this information.

• When the EOL Date is in a future bucket:

  • The item remains eligible for forecast generation until its applicable EOL period.
  • The application generates forecast values for the item only up to the EOL period.
  • From the EOL period onward, the application does not generate forecast values for the item.
  • Forecast values for the post-EOL periods remain blank (or Untouched).
  • This ensures that the leaf-level forecast stops when the planning item reaches its EOL period.

Forecast Generation at an Aggregate Level When EOL Is in the Future

• The EOL behavior is also applied when a forecast is generated at a higher Product hierarchy level, such as:

  • Sub-family
  • Family

• When the forecast is generated at an aggregate level:

  • The application continues to use the applicable historical data to generate the aggregate forecast.
  • The aggregate-level forecast can continue to be generated across the complete forecast horizon.

• When an underlying planning item has already reached EOL:

  • If the item's EOL occurs in the current bucket or a past bucket, the item no longer participates as an active item in future forecast generation.
  • The application does not treat the item as an active planning item for future forecast generation.

• When an underlying planning item has a future EOL Date:

  • The item can continue to be considered while generating the aggregate-level forecast.
  • Since the EOL Date occurs in a future bucket, the item remains applicable until it reaches its EOL period.
  • The aggregate forecast can therefore continue to be generated across the complete forecast horizon.

EOL Validation During Forecast Disaggregation

• When a forecast is generated at a higher hierarchy level, such as Family or Sub-family, and is subsequently disaggregated to lower-level planning items, the application evaluates the EOL Date of each individual planning item.

• EOL validation is applied individually to the underlying planning items during forecast disaggregation.

• When a planning item has a future EOL Date:

  • The item continues to receive its applicable disaggregated forecast values until the EOL period.
  • Forecast values are disaggregated to the item only up to its applicable EOL period.
  • From the EOL period onward, the application does not disaggregate forecast values to the item.
  • The disaggregated forecast for the item is either 0 or Untouched for the applicable post-EOL periods.

• When a planning item has already reached EOL:

  • No future forecast values are disaggregated to the item.
  • The item does not receive a portion of the aggregate forecast for the post-EOL periods.

• For other active planning items:

  • Active items continue to receive their applicable disaggregated forecast values.
  • EOL handling for one planning item does not prevent other eligible planning items from receiving their applicable forecast values.

Aggregate Forecast vs. Disaggregated Forecast

• When a forecast is generated at an aggregate level, such as Family or Sub-family, the generated aggregate forecast and the total forecast disaggregated to the underlying planning items may not always be equal.

• The aggregate forecast can be higher than the sum of the final disaggregated forecast values.

• This difference can occur when one or more underlying planning items reach their EOL Date during the forecast horizon.

• When an underlying item reaches EOL:

  • The application stops assigning forecast values to that item for the applicable post-EOL buckets.
  • The portion of the aggregate forecast that would otherwise be assigned to the EOL item is not assigned to that item after EOL.
  • The application does not redistribute this post-EOL portion to the remaining active planning items as part of EOL handling.
  • The remaining active items continue to receive their applicable disaggregated forecast values without receiving the EOL item's portion.
  • Note: The application doesn't clear or Zero the forecast after the EOL Period.

Let’s consider the example below.

• Oct–Dec 2026 represents the historical period. When generating the Sub-family-level forecast, consider historical data from all three products, including Product B.

• The forecast starts in Jan 2027, and the Sub-family forecast is 300 units per bucket.

• Product B has an EOL in March 2027. Therefore, it continues to receive its disaggregated forecast through March.

• From April 2027 onward, Product B is discontinued and has a forecast of 0.

• Product B's historical data remains unchanged and can still be used as historical input to generate the aggregate forecast.

• The 100 units that would have been assigned to Product B after EOL are not redistributed to Product A or Product C.

• Therefore, from April onward, the aggregate Sub-family forecast remains 300, while the total disaggregated forecast becomes 200.