This appendix covers the following topics:
This appendix describes how changes to the product hierarchy affect sales forecasting. These are the general guidelines for product hierarchies and forecasting:
The administrator can map a node at any level in the product hierarchy to a Forecast Category. However, Oracle Sales recommends that the administrator map each Forecast Category to those products in hierarchy nodes that do not have a parent. This ensures that the forecast roll-up is based on the highest level of the product category.
The administrator can end-date a Forecast Category mapping at any time. It is recommended that the administrator end-date the mapping on a date that is a common denominator for all periods. End-dating mappings in the middle of a period causes the loss of saved and direct report submitted data.
It is possible to submit a forecast after a forecast period has ended. Users often perform this action to reconcile the forecast with actual orders. If a product category was end-dated prior to the current date, the user cannot adjust the product category forecast for the end-dated product category. In this case, the user should reconcile the individual opportunities in the product category, save the changes, and regenerate the forecast using Current Opportunity defaulting. Upon completion, the user can resubmit the corrected forecast.
Note: If you want the user to be able to reconcile the forecast for an extended length of time after the period has ended, the administrator should end-date the mapping on a date soon after the reconciliation period is over. However, this causes the forecast to include Product Categories for the new period until that specified end-date.
The administrator can map a new product category to a forecast category. Depending on the start date designated in the forecast category mapping, this change might occur mid-period or at the beginning of the next period.
When mapping a Product Category to a Forecast Category, the administrator should give a start date that reflects the first date of the upcoming period. This prevents confusion, as newly mapped product categories are included in a user's forecast the next time they access the forecast for the given Forecast Category.
The administrator can add a new product category within the PLM hierarchy. This product category can be added as the parent of an existing product category.
If adding a new product category, as the parent of another forecastable product category, to the PLM hierarchy, the administrator must:
End-date the previously forecastable product category with the current date
Add the new product category to the Forecast Category mapping with the current date as the Start date.
Failure to perform these steps causes double counting and the forecast shows incorrect data.
The administrator can move a child product category within the hierarchy, so that it is no longer a child, and is therefore forecastable. The Oracle Sales Administrator must then make this product category forecastable by mapping it to a Forecast Category.
Refer to Product Category Added to Forecast Category for guidelines.
If the administrator moves a product category and its children, making it the child of a non-forecastable product category, there is no change to the forecast category and mappings.
The administrator is not prevented from moving a forecastable product category under another forecastable product category, thereby making it a child. If this action is performed, the parent and child are both mapped to the same forecast category which causes double counting in the Opportunity Forecast Summary and Forecast Worksheet. Therefore, the system administrator must end-date the mapping of the child product category to the Forecast Category immediately after the product hierarchy is changed.
When end-dating the child category, the system administrator should instruct users to view their latest submission and add the child node's forecast values to the existing forecast values of the parent node, as the saved forecast data for the child node is lost.
The administrator can disable a forecastable product category within the hierarchy at any time by entering a Disable date.
The system administrator should not end-date the product category - forecast category mapping until the end of the period. If the mapping is disabled, the product category is dropped from the forecast and a user cannot add the Product Category to an opportunity in the future, but lines created before the mapping was disabled are still valid.
The administrator can set a Not Visible flag for a product category within the hierarchy.
Refer to Forecastable Product Category Disabled Within the Product Hierarchy for guidelines.
The administrator can entirely delete a product category from the product hierarchy, but must end-date the product category forecast category mapping, as the product category is no longer valid for opportunities in the pipeline.
The system administrator should end date the product category to forecast category mapping immediately after the product category is deleted from the hierarchy, as opportunity lines that carry that product category become invalid and are no longer forecastable.