Not For Copy or Distribution

Not For Copy or Distribution

All Specifications, claims, features, representations, and/or comparisons provided are correct to the best of our knowledge as of the
date of publication, but are subject to change without notice. While we will always strive to ensure our documentation is accurate
and complete, this document may also contain errors and omissions of which we are not aware.
THIS INFORMATION IS PROVIDED BY KINAXIS ON AN “AS IS” BASIS, WITHOUT ANY OTHER WARRANTIES OR
CONDITIONS, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABLE QUALITY,
SATISFACTORY QUALITY, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, OR THOSE ARISING BY LAW,
STATUTE, USAGE OF TRADE, COURSE OF DEALING OR OTHERWISE. YOU ASSUME THE ENTIRE RISK AS TO THE RESULTS
OF THE INFORMATION PROVIDED. WE SHALL HAVE NO LIABILITY TO YOU OR ANY OTHER PERSON OR ENTITY FOR ANY
INDIRECT, INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES WHATSOEVER, INCLUDING, BUT NOT LIMITED TO,
LOSS OF REVENUE OR PROFIT, LOST OR DAMAGED DATA OR OTHER COMMERCIAL OR ECONOMIC LOSS, EVEN IF WE
HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR THEY ARE FORESEEABLE. WE ARE ALSO NOT
RESPONSIBLE FOR CLAIMS BY A THIRD PARTY. OUR MAXIMUM AGGREGATE LIABILITY TO YOU AND THAT OF OUR
DEALERS AND SUPPLIERS SHALL NOT EXCEED THE COSTS PAID BY YOU TO PURCHASE THIS DOCUMENT. SOME
STATES/COUNTRIES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR
INCIDENTAL DAMAGES, SO THE ABOVE LIMITATIONS MAY NOT APPLY TO YOU. All product, font and company names are
trademarks or registered trademarks of their respective owners.

Copyright © 2017 ‐ 2017 Kinaxis Inc. All rights reserved. This document may not be reproduced or transmitted in any form
(whether now known or hereinafter discovered or developed), in whole or in part, without the express prior written consent of
Kinaxis.

Kinaxis RapidResponse contains technology which is protected under US Patents #7,610,212, #7,698,348, #7,945,466, #8,015,044,
and #9,292,573 by the United States Patent and Trademark Office. It is also protected under the Japan Patent Office, Japanese
patent #4393993 and the Intellectual Property India Office, patent # 255768. Other patents are pending.

This document may include examples of fictitious companies, products, Web addresses, email addresses, and people. No association
with any real company, product, Web address, email address, and person is intended or should be inferred.

Printed in Canada.
Web site: https://www.kinaxis.com
Contact: Knowledge@kinaxis.com
 Not For Copy or Distribution

1. Welcome to Deployment Overview for Demand Planning

2. Instructor Introduction
3. RapidResponse version used in this course
 Not For Copy or Distribution

1. Alpha Servers available to review resources and follow along

2. Initial login is User ID: first initial + last name + admin
3. User password: password1 (will be prompted to change password)
4. Note about Alpha Servers: they get rebuilt with new builds, SUs, etc without
warning. Best to save off any personal resources you don’t want to lose
5. Review prerequisites to this course
 Not For Copy or Distribution

1. Core objective is to provide an in-depth view of the Demand Planning

application, its configuration and PDRs
2. Note that the Demand Planning Application requires that the S&OP Application
is also installed. All deliverables (unless otherwise noted) from that application
must also be installed and configured for the Demand Planning Application to
function.
3. This course will assume the S&OP Application Deployment Trainings course as
a prerequisite (including all of its prerequisites)
 Not For Copy or Distribution

1. Course broken up into 4 main lessons

 Not For Copy or Distribution

1. The Demand Planning Application is broken down into a series of high-level

process steps performed by multiple roles in an organization
1. Demand Planning represents cross-functional process
2. These steps identify the major functionality within the Application
a. Only the Demand Planning sub-process here is covered. All the rest are
covered by different Applications and will not be covered in this course
3. This course will review the input data, control table settings and other
configuration required to ensure the functionality defined within this process
performs as expected
 Not For Copy or Distribution

1. The Demand Planning Application is broken down further into a series of high-
level process steps
2. These steps identify the major functionality within the Application
a. Those “cross-hatched” steps indicate that, although part of the overall
process flow, that functionality is optional.
3. This course will review the input data, control table settings and other
configuration required to ensure the functionality defined within this process
performs as expected

4. Inputs to the Demand Planning Process:

1. Current Annual Plan.
2. A valid S&OP Cycle started.
3. Assumptions; from previous S&OP cycles
4. Historical Actuals already “cleansed” up to the most recent forecast
period.
5. Raw historical actuals for the most recent forecast period.
6. Forecast Item definitions and configuration. We only expect to adjust
this – not create it. The assumption in the process is that this is a
maintenance cycle and not the initial integration. Setting up the initial
 Not For Copy or Distribution

set of ForecastItems and their associated parameters is a fairly large task that
needs to be done once. After that, the process flow is just maintaining the
definitions.
7. Any newly imported PartCustomer data.
8. Previous Sales, Marketing, Finance forecasts.
9. PartCustomer and forecast detail pricing.
10. Disaggregation configuration (including overrides).
11. Demand Planning ratios
 Not For Copy or Distribution

1) In RapidResponse 2014.2 and earlier, statistical forecasting calculations were

supported by transformation worksheets.
2) This method of generating the statistical forecast is still available, but it is
recommended that you transition to analytics to produce statistical forecasts.
1) Analytics calculations are more efficient, yet simpler to produce than
transformation worksheet calculations, and the calculated data is easier
to maintain.
3) Additionally, as of RapidResponse 2014.4, profile variables are no longer used
to configure statistical forecasting settings or calculate disaggregation rates
4) In order to define the S&OP parameters for forecasting and disaggregation
calculations when using the Analytic, the control table
SOPAnalyticsConfiguration must be populated with one record
1) This table is used primarily to define the default configuration of
forecast disaggregation, but it also includes fields used to define the
forecast
2) If upgrading from 2014.2 or earlier, populate this table with one record
before using analytics to calculate the statistical forecast; recommended
to populate in EnterpriseData and propagate down to child scenarios
5) Forecast categories to be used in disaggregation are passed through in the form
of an analytic variable
 Not For Copy or Distribution

1) ForecastCategoriesForDisaggregation – this is a string containing the name of

forecast category (to identify a record to look up in HistoricalDemandCategory
table). This variable is named RR_Analytics_Disaggregation_ForecastCategory.
2) For the specified category: if there is a header under it matching the owner
PartCustomer, then report this header (otherwise leave it null).
3) The idea here is to identify the category of forecast that you will be using the
disaggregation for.
1) The analytic will look up the category in the HistoricalDemandCategory
and then use the settings to work out how to calculate the disaggregation.
2) The value of the category that becomes important here is category Type.
DisaggregationQuantityRule which can be either “Actuals” or
“ConsensusForecast” and indicate if the disaggregation should be based
on the corresponding set of HistoricalDemandActuals (default) or the
calculated ConsensusForecast (for adjustments).
3) You cannot have a workbook that has multiple editable disaggregation
columns where the disaggregation analytic calculates differently. They are
all either by actual or by consensus forecast.
It means that you cannot edit both a forecast adjustment (by consensus
forecast) and a sales forecast (by actuals) in the same workbook.

1) See Enhancement details http://jira/browse/RR-28144 and Analytic & Data Model

Guide section “Statistical forecasting and disaggregation” (Analytics)
 Not For Copy or Distribution

1) When calculating disaggregation rates in general disaggregation, the algorithm

flow looks as follows:
1) If there are ForecastDisaggregationParameters under the header that
matches the owner part customer (if such a header exists), then use those
parameters to obtain the ActualsCategory and HistoricalIntervalCount.
1) Ie. We will still be using ForecastDisaggregationParameters
(overriding the above default values) if it is defined for some
HistoricalDemandHeader.
2) If there is no such ForecastDisaggregationParameters record, then
look in SOPAnalyticsConfiguration fields to set all necessary
parameters for the calculation.
3) If there are ForecastDisaggregationOverride records under the header
that matches the owner part customer, then use them to replace
calculated rates, but if there are none then find a header related to the
same PartCustomer, as the owner header, under
ForecastDisaggregationOverrideCategory and use
ForecastDisaggregationOverride records under it. If none there either,
then don’t override it.
 Not For Copy or Distribution

1) When calculating disaggregation rates in statistical forecast, repeat the same

algorithm flow for every header under the owner ForecastItemParameters:
ForecastItemParameters  ForecastItem  PartCustomer (Set) 
HistoricalDemandHeader (matched by the forecast category of
ForecastItemParameters)

1) The analytic is owned by ForecastItemParameters table, which has

HistoricalDemandCategory for the statistical forecast and ForecastItem as key
references
2) Collect Actuals: Historical data points are collected from
ForecastItemParametersActual calculated table if they fall between two dates:
1) Before (Exclusive):
SOPAnalyticsConsfiguration.CalcHistoricalEndDate + 0
IntervalsCalendar
2) After (Inclusive): (SOPAnalyticsConsfiguration.CalcHistoricalEndDate
+ 0 IntervalsCalendar) –
ForecastItemParameters.HistoricalIntervalCount in
ForecastItemParameters.Type.IntervalsCalendar
3) The generation of the forecast will start on CalcHistoricalEndDate + 0
IntervalsCalendar (inclusive)
 Not For Copy or Distribution

3) Report Fit Output: New calculated (and cached) table called

StatisticalForecastFitOutput
1) This table is equivalent to the worksheet 2.3 Calculated Fit Output in S&OP
Forecast Item Management workbook.
4) Report Statistical Forecast Points: New calculated (and cached) table
StatisticalForecast
1) This table is equivalent to 2.0 Predict All worksheet in S&OP Forecast Item
Management workbook.
5) Report Fitted Actuals: New calculated (and cached) table
StatisticalForecastPredictActual
1) This table is equivalent to 2.0 Predict Actuals (Fitted row of Actuals and
Forecast) worksheet in S&OP Statistical Forecasting workbook.
6) Report Disaggregated Statistical Forecast Points: New calculated (and NOT cached)
table StatisticalForecastDetail.
1) The table reports Stat Forecast disaggregated to PartCustomer and BaseCalendar
(from StatisticalForecast table).
2) Used in 4.0 Cmd Forecast Detail – Source worksheet replacing all its underlying
worksheets in S&OP Forecast Item Management workbook and eliminates the
worksheet’s dependency on S&OP Disaggregation library workbook.
3) If there is no header defined for every PartCustomer under
ForecastItemParameters.Item, we still disaggregate for that PartCustomer and
leave Header field unpopulated. We will not generate zero records, but we will
populate records with small quantities.
Not For Copy or Distribution
 Not For Copy or Distribution

S&OP analytics changes in 2014.4 affecting disaggregation and statistical

forecasting have resulted in the introduction of several new tables (input, control
and calculated)
1) SOPAnalyticsConfiguration: Was covered in detail in the S&OP deployment
training; additional details related specifically to Demand Planning will be
covered in this training
2) We won’t be covering the calculated tables in this training, but be aware they
exist
3) ForecastItemParametersFitOutput table to be covered in Lesson 1 (Input tables)
Not For Copy or Distribution
 Not For Copy or Distribution

1) Table Notes:
1) Assumption*, CausalFactor*, ForecastDisaggregationParameters,
ForecastItem* and HistoricalDemandCategory are all typically
RapidResponse system of record
2) BillOfMaterial - Planning BOMs in DP/ASP
3) CustomerPrice - Optional when Part.AverageSellingPrice
4) ForecastDetail - For S&OP, Demand Plan and Forecast feeds are
optional if DP is not purchased, mandatory if it is. Closed loop is
performed on the ConsensusForecast that is generated based on the
weighted inputs of ForecastDetail records.
5) HistoricalSupplyActual, HistoricalSupplyCategory,
HistoricalSupplyHeader are needed to render past in the Spend widget in
the Finance dashboard.
6) PartUOMConversion - Only needed if UOM conversion needed
7) PointsProfile and ProfilePoint - support NPI/EOL planning
8) ShipSet - not input, usually auto created when it is used
9) ProductFamily: used in hierarchies; recommend to use this instead of
Part.ProductGrou1, ProductGroup2, etc
 Not For Copy or Distribution

1) Recommended that this table be set to not allow data update to delete records
(found in the table properties in data model) in order to avoid unintentional
cascading deletes of PartCustomer and Historical tables
2) Key Considerations Notes:
1) Different “levels” of Part data can be required based on the depth of
BOM planning; Demand Planning at the FG level may require less Part
master data configuration than planning BOMs 4 levels deep
1) The Demand Planning Application supports each of these use-
cases
2) This should be defined in the Statement of Work (SOW)
2) If the part is to be included in supply planning of any sort, then the
supply policy fields must be populated; example, SafetyStockQty,
AverageQty, SafetyLeadTime, *Cost (vs. *Price), etc.
 Not For Copy or Distribution

• Need AverageSellingPrice field to be populated in order to use any currency

disaggregation or reporting of revenue or margin. Cannot assume CustomerPrice
will catch everything.
 Not For Copy or Distribution

1) PartCustomers must be defined for every required Part and Customer

combination. This is the base table for the S&OP process. It is not enough to
just have the Part and Customer records defined separately. Put careful thought
into what combinations of Part and Customer need to exist in order to support
the S&OP application as this is often an area where records are needlessly
inflated and use AggregatePartCustomers to define aggregate levels for
disaggregation end
 Not For Copy or Distribution

1) Import the ForecastItem reference to the “blank” (null) ForecastItem and let the
Forecast Item Setup dialog or equivalent data change populate it correctly.
Don’t use a “Dummy” ForecastItem.
2) DemandType: if forecast spreading is required, then the DemandType defines
that spreading. Has to be set even though it can be nullable
3) DemandType: As part of the Closed Loop within Cycle script the Consensus
Forecast generated during the S&OP cycle is cross scenario updated in to the
IndependentDemand table the Baseline scenario to be used to drive demand in
non-S&OP child scenarios. Therefore the processing rule for the DemandType
associated with the newly inserted IndependentDemand records should be set to
ignore in S&OP Intermediate to ensure that duplicate demand is not being
driven within the S&OP scenario tree.
1) This also means there should be no ConsensusForecast in Baseline (or
we double-drive there).
2) The IndependentDemand records in Baseline are being copied already
spread but with the same DemandType(-ish [control set min]) as S&OP
and will re-spread (very odd).
3) More on this when we talk about the DemandType control table.
 Not For Copy or Distribution

1) The field DisaggregationCalendar was added to the PartCustomer table in

2014.4 in order to define the periods that the forecast quantities can be
disaggregated into for a part customer. If this field is null, the disaggregation
calendar specified in the SOPAnalyticsConfiguration table is used for
disaggregation.
1) In the case of aggregate PartCustomers, it is possible that a component
PartCustomer has a different DisaggregationCalendar than its aggregate
PartCustomer
2) For aggregate PartCustomers, the DisaggregationCalendar specified on
components will be ignored. Thus, the disaggregation calendar used for
an aggregate will be the value of DisaggregationCalendar for that
record, defaulting to
SOPAnalyticsConfiguration.DisaggregationCalendar if null.
3) ForecastItems may include multiple PartCustomers, including aggregate
PartCustomers. For Forecast Items, we will use the smallest granularity
calendar from the aggregate PartCustomers (if any) and the regular
PartCustomers that do not belong to aggregates. It does not matter what
the DisaggregationCalendars are on the component PartCustomers.

2) Pool: If forecast consumption by Pool is required, then you can set the Pool for
this PartCustomer on this reference. Frequently, the Pool is set to the same value
 Not For Copy or Distribution

as the Customer.Id. If the Pool is not equal to the Customer and one customer should
belong to more than one Pool, then you will need to create new Customer records with the
ID and Pool concatenated or some other mechanism to make them unique by Pool. This is
because the Pool reference in not a key reference on the PartCustomer table.

3) BaseKey: If you can see this… leave it blank. Always. (this is not the droid
you are looking for...)
 Not For Copy or Distribution

1) 2014.4 SU2 has an added enhancement via a new input table that allows the
definition of Aggregate PartCustomers, which allows the creation of
PartCustomer records for a family of products or a product region. It provides a
standard way to group PartCustomers for disaggregation.
1) This can be used to stop the forecast from disaggregating below a
certain level (ie. the product family level), thereby improving
performance and reducing record counts. Why? It is “best practice” to
never disaggregate to the same level of detail as your measured
samples (actuals). You should only disaggregate results to a
“statistically valid” level of summarization.
2) It may be sufficient to have aggregate customer groupings, at a product
family or region level, or even not include the customer at all in
disaggregation. To support this use-case prior to 2014.4 SU2, dummy
Customers are created and PartCustomers are created that reference that
dummy customer. The result of this is that duplicate historical data
exists for the aggregated PartCustomers (ie. those referencing the
dummy Customer) and additional data churn ensues (eg.
HistoricalDemandHeaders are changed in some scenarios to point to the
aggregate PartCustomers)
3) This new enhancement also allows such things as collecting history on
aggregate PartCustomer categories, and adding new PartCustomer
record to aggregate PartCustomer families without having to remove old
 Not For Copy or Distribution

and/or obsolete ones. In this manner, we can still collect and use history from the
old PartCustomer to calculate disaggregation rates, but disaggregate
ForecastDetails to the new PartCustomer (Use case: when phasing in a new
revision for the part, or replacing an obsolete part with a new one)
4) See http://jira/browse/RR-56930 for detailed analytic spec and resource spec

1) The Component field is a reference to a part and customer combination being aggregated
under the PartCustomer value referenced in the Aggregate field
1) If value in Component=Aggregate, the component is assumed not to be
aggregated (as of the EffectiveInDate)
 Not For Copy or Distribution

1) Since PartCustomer table is the base table for S&OP Process, need to define
Customer records as well

2) While we really don’t need to know much about the customers, at least one
aspect of hierarchies is usually associated with customer characteristics. As
such, custom fields or references from either Customer or CustomerGroup are
often required.

3) Customer has a Site which is normally setup as a key reference. This may be
disabled but is disabled for the entire database then. That is, if you setup the
Customer table to be not site-specific, then ALL Customer records MUST
reference the blank Site. Otherwise, none of the Customer records should
reference the blank Site. It’s all-or-nothing. If Customer.Site is not blank, then
PartCustomer records should normally use Customer from the same Site as the
Part. Otherwise you will need to add Customer Site to several PDRs.

4) It is recommended that this table be set to not allow data update to delete
records (found in the table properties of the data model) in order to avoid
unintentional cascading deletes in the PartCustomer, and Historical tables.
 Not For Copy or Distribution

5) Disaggregation of statistical forecast is almost never viable to the same level of detail as
history. Some customer is needed that represents a group that is feasible. This customer is
often not imported. (Reference AggregatePartCustomer)
 Not For Copy or Distribution

• This is second place the system will look for pricing info, if no UnitPrice is
found on IndependentDemand records or ForecastDetail records, this is the next
place to look, after this, Part.AverageSellingPrice is used
 Not For Copy or Distribution

1) If a user is disaggregating a quantity from a higher level with a particular UOM

that is not the Part.UnitOfMeasure, that quantity will only end up disaggregating
to part/customers where there is a valid UOM conversion factor for the UOM
currently chosen. This is reasonable since we can’t assume (i.e. make up) UOM
conversion factors but the fact is that it’s invisible to the user. They don’t know
that the disaggregation is potentially happening to a subset of Part/Customers.
2) Note: Aggregated reports have the same limitation.
 Not For Copy or Distribution

1) The new ForecastItemParametersFitOutput table saves the fit output

generated by StatisticalForecastFitOutput, a calculated table.
1) This table is a full copy of the StatisticalForecastFitOutput table (field-
wise), except its keys are ItemParameters and ValueName
2) The “fit output” consists of statistical model parameters used to
calculate the statistical forecast and various calculated data
characteristics and error measures of the statistical model.
3) The model constants used in the statistical forecast calculations are
provided by this table.
2) It provides the user the ability to override the calculated alpha, beta, gamma,
etc. when the stat forecast is finally generated. Without this table, it would not
be possible
3) This table is applicable in RapidResponse 2014.4 (or later): when the Generate
and Save Forecast command in the S&OP Forecast Item Management
workbook is run, and ForecastItemParameters.Type.ModelConstantUsage is
set to “Use”, fit output is copied from the StatisticalForecastFitOutput table
into this table
4) Note that the old version of S&OP Forecast Item Management workbook will
keep using the old ForecastItemFitOutput table with Generate Forecast
command
 Not For Copy or Distribution

5) Some important field considerations:

1) Class: reports the type of forecast parameter being reported in the record; such as
DataCharacteristic, ErrorMeasure, ModelConstant, ModelOutput, BestFit, etc
2) ForecastModel: defines the statistical model that will be used to calculate the
statistical forecast
3) ValueName: the name of the specific parameter being reported
1) Various names could be reported for a given class
2) Eg. If Class = ‘ModelConstant”, then the ValueName could be “Alpha”,
indicating that the forecast model uses the alpha constant in its
calculations (alpha’s quantity is then populated in the ValueQuantity field)
 Not For Copy or Distribution

1) This table supports S&OP. Identifies each unique part, customer, and historical
demand category combination, and can be used to specify the weights
associated with forecast categories when generating the consensus forecast for a
particular part customer. It is referenced by
HistoricalDemandHeaderTimePhasedAttributes, HistoricalDemandSeries,
HistoricalDemandActual, ForecastDetail, ForecastDisaggregationOverride,
ForecastDisaggregationParameters and CausalFactor.
2) Note that guardrail measures will trigger a review if we exceed 5 non-target
historical demand categories (supply and demand combined)
Note that this means 5 input forecast types of categories (Sales, Marketing,
Finance, etc.). Our standard defines 9 already but we don’t expect them all
to be used.
3) ConsensusForecastWeight: Specifies a weight to apply to the referenced forecast
category for the part/customer combination for categories where
Type.ProcessingRule is Forecast.
When generating the consensus forecast for a given part and customer
combination, the ForecastDetail.Quantity value associated with each forecast
category on a given date is multiplied by the value in this field, and the results
are summed together. As such, only categories where this field is greater than
zero are included in the consensus forecast calculation. For example, if the
Marketing and Statistical forecast categories both had this field set to .5, and all
other categories were set to 0, the consensus forecast would be the sum of fifty-
 Not For Copy or Distribution

percent of each of the marketing and statistical forecasts.

• Default is set to -1 and is ignored. A value from 0 to 1 is used in the calculations
• Note that this field indicates the override for the header for all dates (past to
future). If a specific date range for the override is required, then use the
HistoricalDemandHeaderTimePhasedAttributes table instead.
4) Note that in 2014.4, two fields now support vector data sets:
1. Actuals: Vector Set data type; represents the HistoricalDemandActual records
associated with the historical demand header
2. ForecastDetails: Vector Set data type; represents the ForecastDetail records
associated with the historical demand header
3. Note that that currency for money fields on the vectors MUST be defined through
the header record and never directly on the Actuals or ForecastDetails vectors
themselves
4. Upgrade Note: If you have upgraded from RapidResponse 2014.2 (or earlier) to
RapidResponse 2014.4 (or later) and your company has not converted the five
standard tables to contain vector data, the following differences exist in this table:
• The Actuals field is a set, not a vector set.
• The ForecastDetails field is a set, not a vector set.
 Not For Copy or Distribution

1) This table specifies a time-phased weight to apply to a given forecast category

for the part and customer combination when generating the consensus forecast
and is typically a value between 0 and 1 (default is 0). The assumption is that
records only exist in this table when you want to override the
ConsensusForecastWeight field value of either the HistoricalDemandHeader or
HistoricalDemandHeaderCategory tables; meaning, if you have a record and set
the ConsensusForecastWeight to 0 for a period (inclusive/exclusive) then you
set the ratio to zero for that interval.
2) Treated almost the same way as the
HistoricalDemandHeader.ConsensusForecastWeight field:
When generating the consensus forecast for a given part and customer
combination, the ForecastDetail.Quantity value associated with each forecast
category on a given date is multiplied by the value in this field, and the results
are summed together. As such, only categories where this field is greater than
zero are included in the consensus forecast calculation. For example, if the
Marketing and Statistical forecast categories both had this field set to .5, and all
other categories were set to 0, the consensus forecast would be the sum of fifty-
percent of each of the marketing and statistical forecasts.
3) Note that records in this table are only applicable when the
Header.Category.Type.ProcessingRule is set to “Forecast”
Not For Copy or Distribution
 Not For Copy or Distribution

1) This table was modified for the 2014.4 release and now contains vector data
1) HDAs are stored in RapidResponse as a set of vector data on the
HistoricalDemandHeader table
2) Also note that the currency of these records must be defined through the
Header record and cannot be defined on the specific HDA record in
2014.4.
3) Recall that on vector tables, any field can be key, and there is no limit to
the number of key fields
 Not For Copy or Distribution

• Sequence on HistoricalDemandSeries allows for multiple captures per day (if

needed); not recommended. Highest number is last capture per AsOfDate.
• Key contributor to database size is number of categories * number of AsOfDates
maintained * number of capture dates (BeginDate) per AsOfDate.
1) This table was modified for the 2014.4 release and now contains vector data
1) The HistoricalDemandSeriesDetail (HDSD) table contains vector set
data for records in the HistoricalDemandSeries table
2) Also note that the currency of these records must be defined through the
owning (Series) record and cannot be defined on the specific HDSD
record in 2014.4.
 Not For Copy or Distribution

1) I really don’t know how this table gets populated with this historical spend.
2) However, without data in the HistoricalSupplyActual, there will be no historical
(past due) spend reported.
3) This table was modified for the 2014.4 release and now contains vector data
1) HSAs are stored in RapidResponse as a set of vector data on the
HistoricalSupplyHeader table
2) Also note that the currency of these records must be defined through the
Header record and cannot be defined on the specific HSA record in
2014.4.
 Not For Copy or Distribution

1) The ForecastDetail table supports S&OP Process

2) Different types of forecasts (Sales, Marketing, Statistical, Finance, etc.) are
stored in this table in addition to Targets, including Annual Plan targets
3) Values shown in this table are based on values entered or maintained in
RapidResponse
1) E.g. statistical forecast details are based on values generated by the Save
Forecast command of the S&OP Statistical Forecasting (Automated)
workbook
4) Consensus Forecast values calculated based on weighted combinations of
different streams (categories) of forecast data in this table can be seen in the
ConsensusForecast table.
5) Used through-out the whole S&OP process to hold all future-looking forecasts,
targets, overrides and adjustments.
6) This table was modified for the 2014.4 release and now contains vector data
1) It contains vector set data for records in the HistoricalDemandHeader
table
 Not For Copy or Distribution

1) New field added to ForecastItem table in 2014.4:

1) EffectiveDisaggregationCalendar: The disaggregation calendar used
when disaggregating forecast quantities for this part customer.
PartCustomer.DisaggregationCalendar is used when defined; otherwise,
the disaggregation calendar specified in the SOPAnalyticsConfiguration
table is used for disaggregation.
 Not For Copy or Distribution

1) Note on Outliers:
1) Outliers are still applicable in 2014.4 but not to stat forecasting.
2) MEIO and SEIP will continue to use Part/Customer/Category
adjustments but the stat forecasting will take outlier corrections from the
new ForecastItemParametersOutlier table.

1) Historical demand must also be adjusted for outliers, or instances when the
demand quantity is out of the typical range for a forecast item.
2) Outliers are still applicable in 2014.4 but not to stat forecasting.
1) MEIO and SEIP will continue to use Part/Customer/Category
adjustments but the stat forecasting will take outlier corrections from the
new ForecastItemParametersOutlier table.
2) Making outlier adjustments at the forecast item parameters level means
that forecast items used with more than one forecast category in
ForecastItemParameters can use a different set of outlier adjustments for
each category.
3) Because outlier adjustments used to be grouped with data errors and causals,
customers using Version 2014.4 (or later) must ensure that any outlier records
have been copied from CausalFactorDetail to ForecastItemParametersOutlier if
they would like to make outlier adjustments at the forecast item level
 Not For Copy or Distribution

• Disaggregation is done by the data found in the cell (by default), but uses these
when defaults are needed.
• If there is data, then adjust existing data proportionally.
• Else, if there is relevant ForecastDisaggregationOverride data, use that to
determine ratios.
• Else, if there is ForecastDisaggregationParameters data, use that to
determine the appropriate historical demand actuals to use to the
determine the ratios.
• Else, use the SOPAnalyticsConfiguration to determine the appropriate
historical demand actuals to use to the determine the ratios.
• Note that this setting can be overridden for a PartCustomer by
setting the DisaggregationCalendar on the PartCustomer table.
It’s the Aggregate PartCustomer that gets to specify this.
• If the above set of conditions still return no data to disaggregate by, then just
spread the numbers evenly.
• The Quantity field is basically a quantity-shipped that should be used when
working out the disaggregation ratio for this header and date. It’s like saying,
when I am disaggregating on this date, pretend that I had this quantity in my
HistoricalDemandActuals lookup to determine this headers proportion.
• Disaggregation override will work on both component PartCustomers and
 Not For Copy or Distribution

aggregate PartCustomers.
• If an override is specified for a component PartCustomer, the given quantity will
be used instead of the PartCustomer’s normal quantity when aggregating that
record.
• If an override is specified for an aggregate PartCustomer, the given quantity will be
used instead of the quantity calculated from all the PartCustomer’s components.
 Not For Copy or Distribution

1) Significant in generating a statistical with NPI or EOL profiles.

2) PointsProfile: contains the names of all profiles (curves) used in generating
statistical forecast for NPI or EOL items
3) ProfilePoint: contains the data points for the profiles (curves) stored in the
PointProfile table
 Not For Copy or Distribution

1) For supply planning, all Parts need to have valid PartSources defined
2) The effectivity date range of PartSource records can be significant if the “NPI
Items” filter is to be used.
1) In particular, this filter assumes that NPI part records can be identified
by the primart PartSource having a FirstEffectiveDate value that is on
or after the system MRPDate - 1 EffectiveDisaggregationCalendar
(formerly used profile variable $DP_BaseCalendar); this can become
problematic if EffectiveInDate is Past and EffectiveOutDate is Future
3) Also, since it is taking the EffectiveDisaggregationCalendar from all of the
PartCustomers for the part, it means that it just needs one case to make it pass.
That is, if one of the PartCustomers is disaggregating by Month and the rest by
Week and the primary PartSource is first effective 3 weeks ago but still after
MRPDate - 1 Month then this part is still considered to be an NPI Item.
 Not For Copy or Distribution

1) IndependentDemand table hold records for demand that is not related to demand
for any other part
2) DemandOrder table contains all the header information for IndependentDemand
records
3) It is expected that all (or most) forecast will be generated from the
ForecastDetails. However, backlog (current customer orders) that consumes this
forecast must be defined in the IndependentDemand table with an
Order.Type.ProcessingRule of SalesActual.
4) Other demands that should not consume forecast may be loaded here as well
with an Order.Type.ProcessingRule of Regular.
5) Occasionally, one DemandOrder is required to have lines (IndependentDemand
records) that are a mix of backlog that can consume forecast and others that may
not. When this is true, define a set of DemandStatus values that can be set on the
IndependentDemand records with ForecastConsumptionOverride set to either
Normal or DoNotConsume, as required
Not For Copy or Distribution
Not For Copy or Distribution
 Not For Copy or Distribution

This slide covers the Control table settings that are especially important from a
Demand Planning implementation perspective; it is not an exhaustive list; other
tables will require configuration as dictated by each Project
 Not For Copy or Distribution

1) New table introduced in 2014.4 for S&OP parameters, replacing some profile
variables used in disaggregation and statistical forecasting, supporting S&OP
analytic disaggregation and forecasting
1) RunDate: Current system date, used to calculate historical end date,
forecast start date and forecast end date. Reference to a Calendar that
holds one date (like the RunDate or DataDate calendar).
1) Recommended to set to one of the most representative RunDate
calendars.
2) CycleCalendar: was $DP_CycleForecastCalendar; represents the
calendar reflecting the S&OP cycle (frequently set to Month); used to
calculate historical end date, forecast start date and forecast end date
1) Normally, it would be something like Month.
3) ForecastStartOffset: Offset from the calculated historical end date to
start report disaggregation rates (in CycleCalendar), expected to be
either 0 or 1, default = 0.
1) We might want to set the ForecastStartOffset to 1 instead of 0.
2) The 0th CycleCalendar is the currently active one and it has
some actuals.
3) Frequently, we may want to NOT generate a forecast for this
interval but also not delete previous forecast for it.
 Not For Copy or Distribution

4) We would start forecasting for next month but leave the forecast for this
month alone.
1) ForecastEndOffset: Offset from calculated forecast start date to finish reporting
disaggregation rates, expected to fall in between 12-24 in most cases, default = 1.
Just bear in mind that it is expressed in CycleCalendar intervals.
2) CalcHistoricalEndDate: a calculated date field which represents the date to stop
collecting historical data (exclusive), calculated as RunDate.FirstDate + 0
CycleCalendar
 Not For Copy or Distribution

1) CalcForecastStartDate: calculated date to start reporting disaggregation rates

(inclusive), calculated as CalcHistoricalEndDate + max(0,
ForecastStartOffset)CycleCalendar
2) CalcForecastEndDate: calculated date to stop reporting disaggregation rates
(exclusive), calculated as CalcForecastStartDate + max(1,
ForecastEndOffset)CycleCalendar
3) DisaggregationCalendar: was $DP_BaseCalendar; is the base calendar for
storing forecast disaggregation; references Calendar table
1) Try not to set this to anything like daily. Week is better or Month is best
(but not normally small enough). It is how often the disaggregation rate
will be reported.
4) DisaggregationHistoricalIntervalCount: was $DP_HistoricalIntervalCount;
Default number of DisaggregationInnerCalendar (before ForecastStartDate) to
collect historical actuals and causal factors to calculate rates
5) DisaggregationInnerCalendar: was $DP_InnerCalendar; default inner
calendar; references Calendar
6) DisaggregationOuterCalendar: was $DP_OuterCalendar; default outer
calendar; references Calendar
1) Unless there is seasonality in your disaggregation ratios, these two
intervals (inner and outer) should be set to the same calendar and should
 Not For Copy or Distribution

never be smaller than the base disaggregation calendar.

7) DisaggregationActualsCategory: was $DP_DefaultDisaggregationActuals; default
disaggregation actuals category; references HistoricalDemandCategory
1) set this to the HistoricalDemandActuals category that will normally be used as a
disaggregation reference.
8) ForecastDisaggregationOverrideCategory: This is new and a reference to a
HistoricalDemandCategory. This will be the default category that contains any
disaggregation overrides regardless of the category being disaggregated. It means that,
using this, you can specify disaggregation overrides that apply to all categories rather than
having to set it up for Statistical, Sales, Marketing and Finance separately. Reference
http://jira/browse/RR-28144
 Not For Copy or Distribution

1) Note that there is currently no PDR to view this table, n the 2014.4 release, there
is no access to the AggregatePartCustomer table in either the Control Tables or
Control Sets workbooks; this will be remedied in 2015.3 (See
http://jira/browse/RR-60866)
 Not For Copy or Distribution

1) This table supports Demand Planning and is used to define how demand data
that is associated with a given HistoricalDemandCategory value is processed
2) Key control table considerations:
1) ProcessingRule: Categories which specify how the historical demand
category data is used in RapidResponse processing (ie. the purpose of
the category); values include:
1) Actual: category used to store historical demand actuals; can be
used in calculating statistical forecast
2) Forecast: category used to store forecast streams or forecast
adjustments; can be used to calculate consensus forecast
3) ForecastOverride: category to override consensus forecast
quantity for a given date.
ForecastDetails in this category will often need to preserve
zeros. This means unchecking “Delete detail records with
zero...” and checking “Allow zero values...”
4) Target: category used to define metric values used in the Annual
Plan
5) RebalancingForecastOverride: overrides the ForecastOverride;
recorded during rebalancing steps of the process
6) RebalancingAdjustment: incremental adjustments to the
 Not For Copy or Distribution

RebalancingForecastOverride – adds to the RebalancingForecastOverride

7) None: default setting meaning this category is informational only. Not
used for anything except custom reporting.
1) DisaggregationQuantityRule: New field in 2014.4; the value that determines
whether historical actuals or the consensus forecast should be used to calculate
forecast disaggregation rates; can be set to Actuals (use historical actuals for
disaggregation) or ConsensusForecast (use consensus forecast for disaggregation)
1) Suggest that this be set to ConsensusForecast for adjustments and
overrides, and left as Actuals for all other categories that are edited.
2) AggregationRule: when the ProcessingRule = “Target”, this rule defines how
targets are aggregated; must be Average or Sum to be active
1) Average: targets are aggregated as average values
2) Sum: targets are aggregate sum of values
3) None: HistoricalDemandCategory is not used for aggregating targets
3) UnitType: when the ProcessingRule = “Target”, specifies if the demand data
(historical demand or forecast) targets are currency or quantity
1) Quantity: Values in the Quantity fields of the ForecastDetail and
HistoricalDemandSeriesDetail tables are used as targets for historical
demands and forecasts
2) Value: Values in the Value fields of the ForecastDetail and
HistoricalDemandSeriesDetail tables are used as targets for historical
demands and forecasts
3) If target is a currency target, should be set to Value, otherwise Quantity
 Not For Copy or Distribution

1) Note that these fields were largely covered in the S&OP Application
deployment training.
2) We are mostly interested in ProcessingRule values of Actual, Forecast,
ForecastOverride
 Not For Copy or Distribution

1) This table is used to categorize values in the ForecastDetails,

HistoricalDemandActual and HistoricalDemandSeries tables, identifying
categories of forecast demand (sales, customer, stat) as well as categories of
actual demand (shipments, consumption)
2) Standard sets of categories are defined in this table, typically at integration;
additional values might be entered into this table to support new streams of
forecast data
3) The Historical Demand Category values in this table are defined by Types
(configured in HistoricalDemandCategoryType) , with their respective
Processing Rules to indicate how they are used in RapidResponse processing
4) ConsensusForecastWeight: the weight value used to calculate the amount of
each forecast stream to be used in Consensus Demand Planning if
Type.ProcessingRule is Forecast.
1) Should be a value between 0 and 1 (0-100%) to define the weight given
to the category in the calculation of the consensus forecast
2) Zero means the category is not included in the calculation of the
consensus forecast
3) For a given part + customer combination, the ForecastDetail.Quantity
value for each forecast category is multiplied by this value and summed
4) For time-phased forecast weights by customer, the
 Not For Copy or Distribution

ConsensusForecastWeight field on the

HistoricalDemandHeaderTimePhasedAttributes table overrides this value
5) CriticalLimit, WarningLimit and the associated DesiredResults are also here but
associated with targets only – covered by the S&OP Application.
 Not For Copy or Distribution

1) There is also FcstOverride and ReBalancingForecastOverride that may

be used in S&OP Demand Supply Balancing. Anything with the
appropriate ProcessingRule can be selected in the workbook.
 Not For Copy or Distribution

1) Read up on the various FitMeasures on WikiPedia if you’re interested. The

default FitMeasure is MeanAbsolutePercentageError or MAPE.
 Not For Copy or Distribution

1) AdditiveHoltWintersMethod was introduced to 2014.4. The regular

HoltWintersMethod is multiplicative.
2) In 2014.4, there is also a Crostons Predict Rule on this table to either produce a
lower constant forecast level (Constant) or to make the forecast regularly
sporadic as well (Sporadic).
1) Prior to 2014.4, Crostons produces constant results.

3) Look at: http://people.duke.edu/~rnau/411diff.htm

1) Check out the “famous forecasting quotes” in the first paragraph.
 Not For Copy or Distribution

1) If you set ModelConstantUsage to Use instead of Calculate, then

RapidResponse does not bother to calculate Alpha, Beta, Gamma, Phi, Theta
etc. values and just uses whatever is there. This is a very bad idea unless you
really have a PhD in statistics ... And then, you should know better.

2) The stat forecast will do its calculations using the IntervalsCalendar bucketing
but the resulting ForecastDetails (when generated) will get disaggregated and
spread to the calendar defined by the
SOPAnalyticsConfiguration.DisaggregationCalendar or (if not null)
PartCustomer.DisaggregationCalendar (was $DP_BaseCalendar profile
variable) and using the Inner/OuterCalendars defined in
DisaggregationInnerCalendar and DisaggregationOuterCalendar (previously
ForecastDisaggregationParameters or the
$DP_InnerCalendar/$DP_OuterCalendar profile variables).

1) TrendDecayFactorRule (Use/Ignore) has also been added to 2014.4 to

determine if a decay factor is added to the double exponential smoothing, Holt-
Winters multiplicative, or Holt-Winters additive statistical forecasting methods
to dampen or eliminate a forecast trend. The decay factor is specified in the new
TrendDecayFactor field on the ForecastItemParameters table. Valid values are:
• Use—The decay factor should be added to the forecast calculation.
 Not For Copy or Distribution

• Ignore—The decay factor should not be added to the forecast calculation.

4) CrostonsPredictRule: The value that determines if Croston’s statistical forecasting
method should report constant or
sporadic predictions of future demand. Valid values are:
• Constant—Croston’s method should report constant predictions, or forecast
values that are spread over all time periods.
• Sporadic—Croston’s method should report sporadic predictions, or forecast
values that appear only at calculated intervals. (new behavior)
 Not For Copy or Distribution

1) Out of the box, there is a selection of installed Assumption Types and

Assumption Statuses
2) Assumption Types (aka Categories in dialogs and reports):
1) Finance: Finance Assumption
2) Marketing: Marketing Assumption
3) Operations: Operations Assumption
4) Sales: Sales Assumption
3) 2 Assumption Statuses: Closed, Open
4) There are no out-of-the-box Application resources that allow the editing of
existing, or creation of new, assumption types or statuses. To edit or add Types
or Statuses, you will need to create a worksheet based on the AssumptionType
and/or AssumptionStatus tables.
5) Assumptions are maintained within RapidResponse.
6) Unless you need to add a new reference, there is no schema implications:
1) If you need a new one, AssumptionBy<newTable> only
 Not For Copy or Distribution

1) ForecastConsumptionOrder is Normal, Forward, Backward,

AlternatingForward, AlternatingBackward or NormalNested
Not For Copy or Distribution
 Not For Copy or Distribution

1) AllotmentOrder is a simple quantity field that indicates demands with a lower

number will get supply before those with a higher number if priority, due and
earliest expiry dates are the same.
2) Demand Planning is expecting that the forecasts will generate SalesForecast
ProcessingRule data. However, SalesActuals can consume this. FromPart is not
covered here.
3) Normally, the PlanningRule would be set to Full. For some forecasts, it might be
set to Partial if you need to ignore the forecast if there is no available supply in
the same forecast interval. This is one of the very few cases where
RapidResponse will intentionally ignore demands.
4) SpreadRule and SpreadProfile are important to set if spreading is required. If
this needs to be done on ConsensusForecast, then it is important that the
PartCustomer reference the correct DemandType.
5) KindPriority is not used by the analytics nor existing applications at all. It was
put in place for an early Order Promising application.
 Not For Copy or Distribution

1) SpreadRule and SpreadProfile are important to set if spreading is required. If

this needs to be done on ConsensusForecast, then it is important that the
PartCustomer reference the correct DemandType.
1) RR-56609 raised to prevent double spreading of forecast in Baseline
scenario
2) Heads up that this is a possible SET of DemandType records.
3) It is best if these PartCustomer DemandType values are not types that are used
by either other DemandOrders nor SupplyTypeAllocationDemandType.
4) Don’t worry that the ProcessingRule is set to Ignore in the S&OP Intermediate
scenario because ConsensusForecast will still use it.
5) We don’t want spreading happening in the Baseline scenario as the
IndependentDemand records created there are already spread. Don’t re-spread
them.
6) Note that the PartCustomer.DemandType must not be null if the “Run Closed
Loop Within Cycle Script” automation is going to successfully run the “Demand
Plan Cross Scenario Update” command.
1) You must have a non-null reference on the PartCustomer.DemandType
for any PartCustomer that will create the ConsensusForecast or the
“Closed Loop Within Cycle” workbook needs custom work.
7) Also note that the default DemandStatus will be used for all of the created
 Not For Copy or Distribution

IndependentDemand records. Make sure that the ForecastConsumptionDateRule

(FromPartType), ForecastConsumptionOverride (Normal) and ProcessingRule (Current)
values are set as required for this DemandStatus.
1) Default defined in data model: []{? Value='Current' 0 1, Value}
1) If you need to keep OrderPriority, Pool or MinimumShelfLife on these demands, then
extend the “Closed Loop Within Cycle” workbook to obtain this from the PartCustomer.
 Not For Copy or Distribution

1) Only really applicable to SalesActuals and perhaps Regular

IndependentDemands as far as Demand Planning is concerned.
2) The two ForecastConsumption* fields are only relevant if the
IndependentDemand.Order.Type.ProcessingRule is SalesActual.
1) The Override provides the ability for a single line on a DemandOrder to
not consume forecast when the DemandType would otherwise suggest it
could.
2) The DateRule allows past due (before DataDate) SalesActuals to either
consume forecast as though it were due on the DataDate or on the
DueDate.
1) New values are RequestDate, RequestOrDataDate
3) ModelUsage was new in 2014.1 (Berlin) to allow the Model on the
IndependentDemand record to be ignored.
4) Also note that the default DemandStatus will be used for all of the created
IndependentDemand records. Make sure that the ForecastConsumptionDateRule
(FromPartType), ForecastConsumptionOverride (Normal) and ProcessingRule
(Current) values are set as required for this DemandStatus.
1) Default defined in data model: []{? Value='Current' 0 1, Value}
Not For Copy or Distribution
Not For Copy or Distribution
Not For Copy or Distribution
 Not For Copy or Distribution

1) No macros are used in the Demand Planning application set.

Not For Copy or Distribution
 Not For Copy or Distribution

1) Not an exhaustive list but most of the important demand categories.

2) Represent default values in most cases as things like Actual and Statistical
categories are specified directly in the ForecastItemParameters (etc.)
3) Optimistic and Pessimistic categories are hidden by default but may be exposed
and used (optionally)
1) If you need additional categories for a customer, we recommend co-
opting these Optimistic/Pessimistic categories for that purpose rather
than just adding new ones.
4) Note that the forecast override category is not defined here. It is specifically
setup as a workbook variable in the S&OP Consensus Demand Planning
workbook.
 Not For Copy or Distribution

1) The SOPAnalyticsConfiguration fields provide all the defaults for

disaggregation, and can be overridden
2) DisaggregationInnerCalendar and DisaggregationOuterCalendar (pre-
2014.4 was DP_Inner/OuterCalendar) are about seasonal disaggregation and
should be set to the same calendar name here (by default). Set both to Month
unless ALL products have seasonality in disaggregation.
1) The ForecastDisaggregationParameters table can (should) override
these values when there is seasonality to be used in the disaggregation.
3) CycleCalendar (pre-2014.4 was DP_CycleForecastCalendar): represents how
often we run an S&OP cycle really. Used all over to filter current
window/interval behavior. Treat this current cycle different because it is part
actual, part forecast.
4) CalcForecastStartDate: start forecasts after the current cycle forecast calendar.
5) CalcHistoricalEndDate: stop looking at actuals starting on this date. Avoid
looking at current month. Partial complete.

1) DP_HideRangeForecasting: Yes. If No, then the Optimistic/Pessimistic

categories are exposed in the workbooks. Heads up for this if you co-opt these
categories. This exposes all 6 categories, ie. You say yes, all are exposed even
though you may only be interested in co-opting 1 or 2 of them, so have to go
 Not For Copy or Distribution

and re-hide the others or change the worksheet/columns to not use the variable.
2) DP_AssumptionComponentsLimit: 100 ; used to limit numbers of assumptions
displayed, or, more correctly, the parts that assumptions are reported for. Either the
assumptions are reported for just the parts in the hierarchy/filter selection or, alternatively,
it may report assumptions for all of the components of those parts. The Assumptions
worksheet shows whether or not this limit has been exceeded.
1) The value displayed indicates whether the assumptions associated with all
components of the selected hierarchy and filter are shown, depending on a
predefined component assumptions limit. Values are:
1) Included - The assumptions associated with all components in the bill of
material for the selected hierarchy and filter are displayed.
2) Excluded - The assumptions associated with all components in the bill of
material for the selected hierarchy and filter are not displayed. This occurs
when the predefined component assumptions limit is exceeded.
3) DP_ConsensusDemandOrderNumber: used to report an order number for consensus
demand that will distinguish it from IndependentDemand orders.
4) DP_DemandTypeForConsensus: HistoricalDemandCategory represents the name of
captured “Demand Plan” in HistoricalDemandSeries. Note: This is NOT a DemandType.
 Not For Copy or Distribution

1) Accessed from the Administration pane, System Settings, Configuration

 Not For Copy or Distribution

1) Some automation resources are already covered by the S&OP Application; these
are all prerequisite to Demand Planning application
 Not For Copy or Distribution

1) S&OP Delete Adjustments and Overrides deletes all records with

Header.Category IN ($DP_AdjustmentsCategory,
$DP_PromotionalAdjustmentsCategory) OR
Header.Category.Type.ProcessingRule = 'ForecastOverride‘.
1) Wipes out ALL previous adjustments and overrides.
2) Future effective overrides might want to be kept in some projects. The
S&OP Consensus Demand Planning workbook would need adjusting in
this case in order to adjust the filtering to only run on past due overrides
2) S&OP Insert Demand Planning History copies the ConsensusForecast records
into the HistoricalDemandSeries and Details.
1) Also copies damn near all ForecastDetails into the
HistoricalDemandSeries and Details.
3) S&OP Insert Statistical Forecast actually creates the statistical forecast in the
ForecastDetails table for the current data settings.
1) Usually just one statistical forecast category. If multiple, this can run
then one-at-a-time or all-at-once.
2) Similar to running the “Generate and Save Forecast...” command on
S&OP Forecast Item Management workbook but not limited to
hierarchy selection or filter.
4) The “Closed Loop within Cycle” (covered by the S&OP Application) task has
 Not For Copy or Distribution

significant implications on the use of DemandType as already discussed.

 Not For Copy or Distribution

1) These automation tasks are not provided with PDRs. They must be created for
each integration as Scheduled System Tasks.
1) Reference the RapidResponse Administration Guide, looking at the
chapter on “Commands and scheduling system tasks”.
2) Specifically, look at the arguments for the DeleteData and
DeleteEnterpriseData commands: scenario, table, filter
2) Failure to create these clean-up tasks will result in accumulation of historical
data that will, eventually, bring down the data server. It could take a while.
3) Delete ForecastDetail records:
1) For ForecastDetail (forecast) records that are contained within
RapidResponse as the system of record, in order to regularly prune
unneeded records.
2) Defined for a rolling period of time it prunes data in the ForecastDetail
table for any data meeting agreed-upon business conditions (eg. created
greater than ‘n’ calendar periods ago for relevant
HistoricalDemandCategory values such as SalesForecast,
MarketingForecast, etc.)
3) Run in S&OP Intermediate using the DeleteData command.
4) Note that for forecasts that are imported, the import process would take
care of pruning.
 Not For Copy or Distribution

4) Delete ForecastDisaggregationOverride records:

1) ForecastDisaggregationOverride contains data by future date to override the
forecast disaggregation rates based on history. Any disaggregation overrides in
the past are not required and should be pruned on a regular basis
2) Defined for a rolling period of time it prunes data in the
ForecastDisaggregationOverride table for any data meeting agreed-upon business
conditions (eg. created greater than ‘n’calendar periods ago (ie. past))
3) Run in S&OP Intermediate using the DeleteData command
5) Note that Cross Application training already covered the “Closed Loop within Cycle”
automation which copies the consensus forecast from the S&OP scenarios into the
Baseline scenario as IndependentDemand.
 Not For Copy or Distribution

1) For detailed information about configuring the DeleteData scheduled system

task:
1) See the RapidResponse Administration Guide (found at
https://help.kinaxis.com ); Search for DeleteDate to view task
argument examples
2) Community space explaining commands
https://community.kinaxis.com/docs/DOC-6208
 Not For Copy or Distribution

1) Pre-defined filters out of the box on install

2) Of relevance to Demand Planning:
1) NPI Items: used to filter on parts that will be or are newly introduced,
where the sourcing data has not yet come into effect
1) If default expression needs to be reconfigured to meet customer
needs (eg. PartSource records have effectivity that runs from
Past to Future therefore may need some other way to ID the
parts), best practice is to ensure the parts are identified through a
discrete code value in a field (ie. no wildcards) preferably in a
referenced table
2) This is of particular interest when you use the “NPI Record
Creation” workbook and insert new “Source” (PartSource)
records.
1) If the record that you selected as a copy or, if you had no
record for it to clone, has the “In Date” set to Past, then
this part will not show up in the filter.
Not For Copy or Distribution
 Not For Copy or Distribution

1) Important to note: the Application Resources are decoupled from the

RapidResponse Analytics, in that functionality to support a particular Analytic
(eg. Expiry) may not be built into the out-of-the-box Application Resource and
will need to be added to cover specific use cases.
2) The S&OP Process Template is also required for the Demand Planning
Application but it is covered by the S&OP Application and will not be covered
here.
3) There are many (>100) widgets available but only the above 17 widgets are
used in the 4 dashboards as defined.
4) They are derived from the following workbooks:
1) S&OP Consensus Demand Planning Widgets
2) S&OP Constraint Widgets
3) S&OP Forecast Accuracy Widgets
4) S&OP Widgets – Single Scenario
5) S&OP Widgets Workbook
 Not For Copy or Distribution

1) The S&OP High Level Process – [role] task flows are written for each major
supply chain management role, to guide the user through their activities in the
S&OP Process specifically if the customer purchased only S&OP. For
Demand Planning, you should use the task flows that do not have “High Level”
in the name if they are available for the role.
2) The task flows need to be configured to launch at user sign in
3) Configuration is done at the User level, in User Properties
4) In each of these task flows, the first step has been configured to launch the
appropriate Dashboard
1) In this case, for the S&OP Process- [Role] task flows, the [Role] Metrics
Dashboard is launched
2) When S&OP and another Application is purchased (eg. Demand
Planning), the S&OP Process- [Role] task flow is configured to launch
the appropriate role-based dashboard that provides additional widgets,
obtained only when that Application is purchased (eg. Demand Planner
dashboard has a tab of Demand Planner-related widgets when the
Demand Planning application is purchased)
5) Where applicable, the S&OP Process – [Role] task flows contain links to sub-
process task flows such as Condition Sales Data, Create a Consensus Demand
Plan, Manage NPI/EOL Items, etc.
 Not For Copy or Distribution

6) Some new task flow functionality introduced in 2014.2 includes the ability to link and
launch a task flow from a task flow, and additional actions around scenarios (create,
share, update, commit, delete)
 Not For Copy or Distribution

1) List of task flows installed with Demand Planning Application

2) These are reported with indents to show the relationships of each task flow.
3) Note that there is an assumption that the S&OP Application has installed other
task flows for various other roles.
4) Also note that portions of these tasks flows may need to be specifically deleted
if related applications are not purchased. Examples: Inventory management or
Aggregate supply planning.
 Not For Copy or Distribution

1) Table indicates which task flows should be configured to open on sign-in, based
on the group the User belongs to
1) Eg. User belongs to Finance group should launch the S&OP Process-
Finance task flow

2) IN PRODUCT DEMO: Show the S&OP Process- Demand Planner task flow
1) Highlight that it opens the appropriate dashboard when it launches
2) Highlight that the Configure the statistical forecast sub-process task
flow is linked
3) Highlight that an action has been included (Publish the statistical
forecast)
 Not For Copy or Distribution

1) Default data settings for dashboard widgets are configured in the Widget
Properties (not dashboard properties)
2) By default, dashboards are configured to remember user settings and open with
those, after the initial opening of the dashboard
 Not For Copy or Distribution

1) If the Capacity application is not purchased, then the Key Constraint Utilization
Chart widget will need to be removed from all of the Corporate Metrics
dashboard tabs.
 Not For Copy or Distribution

1) The Demand Planner dashboard contains two tabs:

1) The Demand Planner Metrics tab is specific to this role, and contains
widgets that are relevant to the demand planner and help in determining
the accuracy of history and forecast as well as the current consensus
forecast. They are:
1) Data Errors / Outliers (note that there is not a measure for other
causals such as promotions.
2) Forecast Value Add
3) Forecast Accuracy Exceptions
4) Consensus Demand Plan
2) The Corporate Metrics tab is general across all roles, and contains
widgets relevant to supporting 5 main Corporate Metrics
1) These are discussed in more detail in the S&OP Application.
2) Data Settings can be manipulated to display what is required; default data
settings are configured on the individual widgets
3) IN PRODUCT DEMO: Open Demand Planner dashboard to display widgets
 Not For Copy or Distribution

1) The Data Errors / Outliers widget shows if there are forecast items that require
data cleansing from missing data or outliers.
2) Clicking on any column will allow the Demand Planner to edit data errors,
outliers and causals for the forecast item history, if required.
1) Note that causals are not reported in any of the widgets.
3) Widget data settings are set within the Widget properties, where the
workbook/worksheet and any filtering is defined
4) Note that “Sigmas” defines outliers (number of standard deviations).

1) IN PRODUCT DEMO: In the Dashboard pane, find the Data Errors / Outliers
Widget
1) Open the widget properties to display where the data settings are defined
 Not For Copy or Distribution

1) The Forecast Value Add widget shows the value add of the forecast stream as
compared to a naive forecast.
1) Clicking on any column will allow the Demand Planner to see more
forecast accuracy measures for the forecast item.
2) The Forecast Accuracy Exceptions widget is simply another worksheet showing
a count of Forecast Items where the column error measure exceeds a maximum
defined in the S&OP Forecast Accuracy Widgets workbook.
1) It summarizes where the error measure is above the critical limit for the
forecast category.
2) The accuracy is calculated by comparing the previous 12 months of
forecast data to the selected actual demand category.
3) Clicking on any of the drill-to-detail values will open the S&OP
Forecast Accuracy workbook to the Forecast Accuracy worksheet.

3) IN PRODUCT DEMO: In the Dashboard pane, find the Forecast Value Add
Widget
1) Drill to the Forecast Value Add worksheet
 Not For Copy or Distribution

1) The Consensus Demand Plan widget shows the value of the existing demand
plan (consensus) forecast.
1) Clicking on any data will allow the Demand Planner to see more detail
on the consensus demand plan.
2) Historical data is reported with a grey background.
 Not For Copy or Distribution

1) The Finance dashboard contains two tabs:

1) The Finance Metrics tab is specific to this role, and contains widgets
that are relevant to the finance planner and help in determining the
accuracy of the financial forecast as well as the projected spend and
current backlog. They are:
1) Backlog Value
2) Spend
3) Finance Plan Forecast Accuracy (MAPE)
2) The Corporate Metrics tab is general across all roles, and contains
widgets relevant to supporting 5 main Corporate Metrics
1) These are discussed in more detail in the S&OP Application.
 Not For Copy or Distribution

1) The Backlog Value widget shows the revenue on actual orders by

period. Historical data is displayed with a gray background..
1) Clicking on any data will allow the Finance planner to see the
summarized revenue for actual orders for drill date month, and
expresses it as a percentage of the forecast revenue.
2) Single-clicking on a segment of a treemap will drill further into the
segment until there is no more detail in the source worksheet.
3) Double-clicking on any of the segments can drill to further detail
showing the specific backlog order details from the Backlog Details
worksheet in the S&OP Backlog Reports workbook.
 Not For Copy or Distribution

1) The Spend widget summarizes the material cost, by period, for the forecast.
Historical data is displayed with a gray background.
1) The SpendTarget category may have a Type of None on installation and
may need to be changed to TargetValue in order to maintain it in the
S&OP Annual Plan workbook.
2) Clicking on any data will allow the Finance planner to see the material
spend (purchase costs) that go into the independent demands and
forecasts that comprise the bucket.
2) Note that this is the only place in the Demand Planning Application where the
HistoricalSupplyActual is required.
 Not For Copy or Distribution

1) The Finance Plan Forecast Accuracy (MAPE) widget shows the mean absolute
percent error for the forecast by period and the actual demand for the period.
The mean absolute percent error for each time period is the average of the
absolute value of the percent difference between the forecast and actual demand
for the given time period, and the eleven periods before it.
1) This makes use of the Statistical Errors By Date function setting the
number of samples to 12 (the eleven periods before it).
2) There is no drill to details for this widget. This was the intent. It was felt
that these roles (Finance, Sales, Marketing) wouldn’t be mature enough
users to look at forecast value add details nor would they want to.
3) The widget definition determines the forecast category that is being
compared to the actuals category.
 Not For Copy or Distribution

1) The Marketing dashboard contains two tabs:

1) The Marketing Metrics tab is specific to this role, and contains widgets
that are relevant to the marketing planner and help in determining the
accuracy of the marketing forecast as well as the projected forecast and
relative revenue by product family. They are:
1) Forecast Accuracy Exceptions (as defined in the Demand
Planner dashboard)
2) Marketing Forecast Accuracy (MAPE)
3) Revenue by Product Family (pie chart) ; note: revenue is based
on consensus demand rather than Marketing
4) Marketing Forecast
2) The Corporate Metrics tab is general across all roles, and contains
widgets relevant to supporting 5 main Corporate Metrics
1) These are discussed in more detail in the S&OP Application.
 Not For Copy or Distribution

1) The Marketing Forecast Accuracy (MAPE) widget shows the mean absolute
percent error for the forecast by period and the actual demand for the period.
The mean absolute percent error for each time period is the average of the
absolute value of the percent difference between the forecast and actual demand
for the given time period, and the eleven periods before it.
1) This makes use of the Statistical Errors By Date function setting the
number of samples to 12 (the eleven periods before it).
2) There is no drill to details for this widget.
3) The widget definition determines the forecast category that is being
compared to the actuals category.
 Not For Copy or Distribution

1) The Revenue by Product Family widget shows the relative revenue for the
forecast and actual orders for the end of the selected horizon for individual
product families as compared to each other.
1) Top five are shown separately with the rest under Others. The count of
top “five” is hard-coded in the “1.1 Revenue by Family Top” worksheet.
2) Clicking on any data will allow the Marketing planner to see the
Revenue Treemap by Product Family treemap.
1) The size of the treemap segments correspond to relative revenue
amounts while the color corresponds to a percentage of Annual
Plan.
3) Only the drill-to-details reports are affected by the Annual Plan or
targets (DemandPlanValueTarget).
4) Revenue is based on consensus demand rather than the Marketing
forecast.
 Not For Copy or Distribution

1) The Marketing Forecast widget shows the revenue in the marketing forecast by
period. This time, it is based on the marketing forecast rather than the
consensus forecast.
1) History is displayed with a grey background.
2) Clicking on the current scenario data (rather than the Annual Plan or the
Previous Forecast) will allow the Marketing planner to see and edit the
Marketing forecast using the S&OP Marketing Forecast workbook. The
Proposed Plan should be editable for a user belonging to the Marketing
user group.
 Not For Copy or Distribution

1) The Sales dashboard contains two tabs:

1) The Sales Metrics tab is specific to this role, and contains widgets that
are relevant to the sales planner and help in determining the accuracy of
the sales forecast as well as the projected forecast and relative revenue
by product family. They are:
1) Forecast Accuracy Exceptions (as defined in the Demand
Planner dashboard)
2) Sales Forecast Accuracy (MAPE)
3) Revenue by Product Family (pie chart); note: revenue is based
on consensus demand rather than Sales (as defined in Marketing
dashboard)
4) Sales Forecast
2) The Corporate Metrics tab is general across all roles, and contains
widgets relevant to supporting 5 main Corporate Metrics
1) These are discussed in more detail in the S&OP Application.
 Not For Copy or Distribution

1) The Sales Forecast Accuracy (MAPE) widget shows the mean absolute percent
error for the forecast by period and the actual demand for the period. The mean
absolute percent error for each time period is the average of the absolute value
of the percent difference between the forecast and actual demand for the given
time period, and the eleven periods before it.
1) This makes use of the Statistical Errors By Date function setting the
number of samples to 12 (the eleven periods before it).
2) There is no drill to details for this widget.
3) The widget definition determines the forecast category that is being
compared to the actuals category.
 Not For Copy or Distribution

1) The Sales Forecast widget shows the revenue in the sales forecast by period.
This time, it is based on the sales forecast rather than the consensus forecast.
1) History is displayed with a grey background.
2) Clicking on the current scenario data (rather than the Annual Plan or the
Previous Forecast) will allow the Sales planner to see and edit the Sales
forecast using the S&OP Sales Forecast workbook. The Proposed Plan
should be editable for a user belonging to the Sales user group.
 Not For Copy or Distribution

1. Allows the demand planner to compare and evaluate key corporate performance
metrics from alternate scenarios against the annual plan and each other. The user
can see the impact of different scenarios on overall high level corporate metrics
and make a selection about which scenario to choose.
 Not For Copy or Distribution

1) Should open the scorecard and run it once.

2) Also, demo the Global Settings and show where the Annual plan target scenario
is set.
3) By default, scorecard shows results as Differences for a 12 month horizon as
defined in Scorecard Settings
4) Metrics derived from the S&OP Corporate Metrics workbook for the Corporate
Metrics items but the extra “Revenue at Risk” comes from “S&OP Demand
Metrics”
 Not For Copy or Distribution

1) Displays the difference between the revenue at risk for this metric horizon.
2) The Annual Plan in this case is based on the Revenue At Risk Target.
1) This means the
HistoricalDemandCategory.Value='RevenueAtRiskTarget' and the
associated profile variable is $DP_RevenueAtRiskTarget

3) NO IN-PRODUCT DEMO as it’s virtually identical to anything seen in S&OP

Application training
 Not For Copy or Distribution

1) Drilling into the Margin % metric opens three detailed worksheets

2) Revenue: by Period by Demand Displays the total and late value for each
IndependentDemand sorted by period in which one of the following values has
changed from scenario to scenario: Available Date, Quantity, Late Quantity,
Revenue, or Revenue at Risk
1) Note: Available Date here seems to be group Min which does NOT give
you the date you expect the demand to be delivered. It is when you
expect SOME of it to be delivered.
3) Revenue: by Manufacturing Region Displays the total and late value for each
IndependentDemand, sorted by part region, in which one of the following
values has changed from scenario to scenario: Quantity, Late Quantity,
Revenue, or Late Revenue.
 Not For Copy or Distribution

1) Drilling into the Margin % metric opens three detailed worksheets

2) Revenue: by Customer Region Displays the total and late value for each
IndependentDemand, sorted by customer region, in which one of the following
values has changed from scenario to scenario: Quantity, Late Quantity,
Revenue, or Late Revenue.
 Not For Copy or Distribution

1) There are other workbooks used by this application but they are described in
other applications. For example, the “Process Calendar” and “S&OP Demand
Supply Balancing” workbooks are described in the S&OP Application or have
been covered by the discussion on widgets.
2) These 13 are unique to the Demand Planning Application (including Stat
Forecasting). (You’ll all be asleep before we get through these ones anyway!)
1) We will cover these in the order we would encounter them within
specific role task flows (more or less).
2) Statistical forecasting workbooks will be covered last.
 Not For Copy or Distribution

1) *Recommended* For a full listing of ALL workbooks affected, and the changes
made to each workbook, see the PDR specification contained at
http://jira/browse/RR-53460
2) Changes include (but not limited to):
1) Removing profile variables and replacing with corresponding
SOPAnalyticsConfiguration table worksheet and related fields
2) Addition of new workbook variable
RR_Analytics_Disaggregation_ForecastCategory
3) Deleted worksheets related to disaggregation
4) Changed insert for ForecastDetail
5) Use of new tables: StatisticalForecastDetail,
ForecastItemParametersFitOutput, etc
Not For Copy or Distribution
 Not For Copy or Distribution

1) If the user belongs to the Finance group, then the Proposed Plan row in this
report is editable.
2) This is the primary resource used in the Task Flow called “Input Forecast –
Finance”.
3) The planner can either use this workbook with units or with their chosen
currency.
 Not For Copy or Distribution

1) There is a control on the toolbar allowing the planner to compare the “Proposed
Plan” to either the “Active Plan” or the “Annual Plan” (as defined above). This
comparison row has a special background color. Values in the “Difference” row
are highlighted in red if they deviate from the selected plan by more than the
specified tolerance threshold. This “tolerance threshold” is specified in the Data
Settings dialog.
2) Finally, the number displayed in the “Assumptions” row indicate the total
number of assumptions effective for the period. Clicking on this number will
open a worksheet listing those specific assumptions.
3) If the Finance planner is editing in either revenue or units there will be a second
worksheet available to them in the top pane that will report a bucketed detailed
view of the Finance Operating Plan broken out by one level below the selected
hierarchy level. (Next slide shows this.)
 Not For Copy or Distribution

1) The intent of this worksheet is to provide an easy way to edit the details more
directly. This has been designed to be able to import the Finance Operating Plan
from a similarly formatted Excel worksheet. There is a version of this for units
and for revenue. This is used for importing at higher level of hierarchy which
can be disaggregated on import
 Not For Copy or Distribution

1) The current pricing is reported in this worksheet along with the ability to set
new prices for the Part/Customer starting on an effective date.
2) Provides unit price overrides by customer over time
 Not For Copy or Distribution

1) Really, the only calculation here is the Available Date, Days Late and Revenue
and those are pretty obvious.
 Not For Copy or Distribution

1) The Demand Plan is derived from both history and projected consensus forecast.
1) Historically, it is taken from the last recorded series of
HistoricalDemandSeriesDetail records where the Category is set to
$DP_DemandTypeForConsensus (DemandPlan).
2) For future values, it is taken from the calculated ConsensusForecast.
2) The Actual Demand is also derived from both history and projected actual
demands.
1) Historically, it is taken from the HistoricalDemandActual records where
the Category is set to $DP_ActualsCategory (Shipment).
2) For future values, it is taken from the IndependentDemand records
where Order.Type.ProcessingRule in ('SalesActual','Regular') and
EffectiveDemand > 0. This is the same set of data as the Backlog
Details.
3) The Unconsumed row is simply the difference between Demand Plan and
Actual Demand.
1) This does NOT report anything to do with forecast consumption.
Instead, it is just the difference between Demand Plan and Actual
Demand. It is suggesting that Regular demand is consuming the forecast
and there is no provision for the defined consumption windows. This is
likely to be confusing to some users so be prepared to explain this.
 Not For Copy or Distribution

RR-56970 has been denied so the label stays.

4) The Past Due row is talking about records stored in the HistoricalDemandActual table
where the Header.Category is set to $DP_PastDueBacklogCategory (PastDue) and the
Date + 1 S&OP cycle forecast calendar is before the forecast start date.
1) This usually means anything from the previous months (or S&OP planning cycle)
and earlier that was not shipped on time.
2) This is purely a historical measure and does not include any projected lateness or
misses.
3) This data is recorded automatically by the S&OP Insert Backlog into History
scheduled task which calls the Write Backlog data change in the S&OP Write
History Records workbook and includes all IndependentDemand records where
(DueDate < Part.PlanningCalendars.RunDate.FirstDate + 0
SOPConfiguration!CycleCalendar) and EffectiveDemand > 0 and
Order.Type.ProcessingRule = 'SalesActual'.
Not For Copy or Distribution
 Not For Copy or Distribution

1) This is the primary resource used in the Task Flow called “Input Forecast –
Marketing”.
2) The planner can either use this workbook with units or with their chosen
currency.
 Not For Copy or Distribution

1) There is a control on the toolbar allowing the planner to compare the “Proposed
Plan” to either the “Active Plan” or the “Annual Plan” (as defined above). This
comparison row has a special background color. Values in the “Difference” row
are highlighted in red if they deviate from the selected plan by more than the
specified tolerance threshold. This “tolerance threshold” is specified in the Data
Settings dialog.
2) Finally, the number displayed in the “Assumptions” row indicate the total
number of assumptions effective for the period. Clicking on this number will
open a worksheet listing those specific assumptions.
3) If the Marketing planner is editing in either revenue or units there will be a
second worksheet available to them in the top pane that will report a bucketed
detailed view of the Marketing Forecast broken out by one level below the
selected hierarchy level.
 Not For Copy or Distribution

1) The intent of this worksheet is to provide an easy way to edit the details more
directly. This has been designed to be able to import the Marketing Forecast
from a similarly formatted Excel worksheet. There is a version of this for units
and for revenue.
 Not For Copy or Distribution

1) The current pricing is reported in this worksheet along with the ability to set
new prices for the Part/Customer starting on an effective date.
 Not For Copy or Distribution

1) This is the primary resource used in the Task Flow called “Input Forecast –
Sales”.
2) The planner can either use this workbook with units or with their chosen
currency.
 Not For Copy or Distribution

1) There is a control on the toolbar allowing the planner to compare the “Proposed
Plan” to either the “Active Plan” or the “Annual Plan” (as defined above). This
comparison row has a special background color. Values in the “Difference” row
are highlighted in red if they deviate from the selected plan by more than the
specified tolerance threshold. This “tolerance threshold” is specified in the Data
Settings dialog.
2) Finally, the number displayed in the “Assumptions” row indicate the total
number of assumptions effective for the period. Clicking on this number will
open a worksheet listing those specific assumptions.
3) If the Sales planner is editing in either revenue or units there will be a second
worksheet available to them in the top pane that will report a bucketed detailed
view of the Sales Forecast broken out by one level below the selected hierarchy
level.
 Not For Copy or Distribution

1) The intent of this worksheet is to provide an easy way to edit the details more
directly. This has been designed to be able to import the Sales Forecast from a
similarly formatted Excel worksheet. There is a version of this for units and for
revenue.
 Not For Copy or Distribution

1) The current pricing is reported in this worksheet along with the ability to set
new prices for the Part/Customer starting on an effective date.
Not For Copy or Distribution
 Not For Copy or Distribution

1) The result of this “cleansing” will have an effect on disaggregation of the

Finance, Sales and Marketing forecasts as well as affecting the calculated results
of the statistical forecast (and its associated disaggregation).
2) This is the first step in the S&OP Cycle (not the S&OP Process). That is, once
the S&OP Process Owner starts a new S&OP Cycle, then this will be the first
task that must be completed using the S&OP Data Cleansing workbook.
1) Who can tell me what action or task is being done between starting the
S&OP Process and starting the S&OP Cycle?
1) Updating the annual plan in the Baseline scenario.
 Not For Copy or Distribution

1) Cleansing of data should be done in the following order: Data Errors, Causals,
Outliers
2) If it is clear that there is missing data but the correct values are not known, the
user may elect to simply copy the “Suggested Adjustment” quantity into the
“Demand Adjustment” in order to (at least temporarily) set the effective
historical quantity to a moving average quantity.
1) The number of intervals used in the moving average calculation is
defined as a workbook variable and is, by default, set to 3.
2) The calendar for these intervals is defined by the
ForecastItemParameters Type.IntervalsCalendar.
3) Adjustments are inserted into the CausalFactorDetail table (rather than directly
editing historical demand actuals) with a CausalFactor.Category of
‘DemandAdjustment’.
 Not For Copy or Distribution

1) If the event that created the actual history is not something that would have been
forecasted normally or would be an event that should not be included in
statistical forecasting, then it should be effectively removed from the history
before we would use the history for either statistical forecasting or for
disaggregation. This is done using the Causals worksheet.’
1) Obviously, there is no “suggested quantity” here. Who knows how much
of the shipments were due to these promotions, etc. if it is not already
provided. The human has to have more information.
2) Adjustments are inserted into the CausalFactorDetail table (rather than directly
editing historical demand actuals) with a CausalFactor.Category of either
‘Promotion’ or ‘Demo/Test’ depending on which column the adjustment is
entered on.
3) There is, in fact, an additional type of causal that can be entered as well by
simply un-hiding the ExtraCausal column in the worksheet. This give a 3rd
category value of ‘ExtraCausal’ but the column header can be edited to make it
represent anything you might need.
 Not For Copy or Distribution

1) Finally, once the data errors and special event causals have been dealt with
using the previous two worksheets, we should have a more statistically valid set
of history to work with. It is entirely possible at this point that there is still some
form of event that was not forecasted or even foreseeable that is affecting the
history. Perhaps events such as natural disasters or economic down-turns might
cause an unexpected surge or dip in the historical demands.
1) We can use the third Outliers worksheet to detect and compensate for
these additional historical data anomalies.
2) ForecastItems where the bucketed historical data is outside the range of
some number (sigma) of standard deviations from the moving average
(same one as the Data Errors worksheet uses to get the Suggested
Adjustment).
3) You pick the number of sigmas to use in the workbook Data Settings
dialog (1 to 4)
2) As of 2014.4, outlier adjustments are copied into the
ForecastItemParametersOutlier table (see 3.8 Edit Outlier worksheet): outlier
adjustments will never get disaggregated to PartCustomer or aggregates. They
will only get disaggregated to the ForecastItem, therefore they have no impact
on how disaggregation works. Outliers will be used in the generation of the
Statistical Forecast if the CausalFactorCategory.ProcessingRule = ‘All’ or ‘SOP’
1) Prior to 2014.4, adjustments are inserted into the CausalFactorDetail
 Not For Copy or Distribution

table (rather than directly editing historical demand actuals) with a

CausalFactor.Category of ‘Outlier’.
 Not For Copy or Distribution

1) Note that calling these “accuracy” measures is somewhat misleading. Some of

measures of variability (stability) and several others are measures measures of
curve-fitting and really don’t measure real accuracy at all.
Not For Copy or Distribution
 Not For Copy or Distribution

1) Truly, I do not expect anyone to remember all of this. However, the little notes
afterwards about the meaning of the number reported can be useful in helping
you to interpret them.
 Not For Copy or Distribution

1) % Error (MAPE): The average of the absolute value of the percentage

difference between the forecasted actuals and actual demand. The background
color of the error measure value depends on the limits entered in the Data
Settings dialog:
1) Green—Less than or equal to the % Error (MAPE) Warning Limit (set
in the Data Settings dialog)
2) Yellow—Greater than the % Error (MAPE) Warning Limit and less than
or equal to the % Error (MAPE) Critical Limit
3) Orange—Greater than the % Error (MAPE) Critical Limit
2) Volume Error: Total forecast quantity for the next 6 months multiplied by the
MAPE.
3) Value Error: The total forecast value for the next 6 months multiplied by the
MAPE.
4) Forecast Model: The forecast model used to calculate the statistical forecast.
5) In this case, the reported MAPE (Mean Absolute Percent Error) is the one that
was calculated and stored in the ForecastItemParametersFitOutput table when
the statistical forecast was last generated. It is not being recalculated at this time
 Not For Copy or Distribution

1) To evaluate if each forecast stream is more or less accurate than the naïve
forecast, the value add is calculated. This is defined as the difference in mean
absolute percent error of each forecast stream and the mean absolute percent
error of the naive forecast.
2) The naïve forecast for a period is the actual value from a previous period for the
category selected.
3) This time, we are comparing a particular forecast stream from some number of
intervals prior to the occurrence of the “actual” to determine the MAPE. That is,
if we are looking for the forecast error related to last April’s “actual” shipment,
we could look at the forecast made in the previous March (Offset=1), or the
previous February (offset=2) or even the forecast made 1 lead-time before the
“actual” and rounded back to the previous CycleCalendar (Month). It will be
this forecast that is compared with the actual to get the errors and return the
MAPE calculation.
4) You can add and remove categories to the charts to compare them.
5) This is ALL historical measures.
 Not For Copy or Distribution

1) The accuracy is calculated by comparing the forecast to the selected category of

actual demand and providing a summary for the previous 12 months. There are
six measures reported:
1) MAPE: The average of the absolute value of the percentage difference
between the forecast and actual demand.
2) MAE/Mean: The average of absolute differences between the forecast
and actual demand divided by the average actual demand.
3) Bias - (MPE): The average of the percentage difference between the
forecast and actual demand. This can be positive or negative.
4) Stability - (MAPD): The average of the absolute percentage deviations
between a forecast value and the median forecast value in the series.
This is always a positive value. Note that this does not represent "error".
A larger number here indicates that the forecast is expected to be more
variable than a smaller number. If the forecast were to be the same
number for the entire 12 months (naive) then this value would be zero.
5) Mean Error - (ME): The average of the difference between the forecast
and actual demand. This can be positive or negative.
6) Mean Abs Error - (MAE): The average of the absolute value of the
difference between the forecast and the actual demand.
2) Each measure in this report has a background color that is determined by the
 Not For Copy or Distribution

value of the measure and the corresponding warning and critical limits for the measure
that are set up in the Data Setup dialog.
 Not For Copy or Distribution

1) The background color of the values in the quantity by Date column signified the
following:
1) • Yellow: forecast demand
2) • Blue: actual historical
3) • Red: forecast for the current period that was set in a previous cycle.
Offset 1 establishes the number of periods in the past to use.
4) • Purple: forecast for the current period that was set in a previous
cycle. Offset 2 establishes the number of periods in the past to use.
5) • Green: forecast for the current period that was set in a previous
cycle. Offset 3 establishes the number of periods in the past to use.
2) This is a very familiar view for looking at a set of time-series data like forecasts.
The top pane shows the actuals and forecasts. The bottom pane shows the
difference between the forecast quantity and the last baseline forecast quantity.
If the forecast is a baseline forecast, then the actual forecast quantity is shown,
and all subsequent values are the difference between the last baseline and the
forecast on the given as of date. Baseline are the bolded row.
 Not For Copy or Distribution

1) Date: The date of the last period in the interval reported.

2) Tracking Signal: The sum of the differences between the forecast and actual
values divided by the mean absolute deviation (MAD). The movement of the
tracking signal is compared to the control limits specified in the Data Settings.
As long as the tracking signal is within these limits, the forecast is considered in
control. Values outside this range indicate that the model used should be
reevaluated.
 Not For Copy or Distribution

1) In the Create a Consensus Demand Plan task flow, the first active step (step 6) is
to adjust the consensus demand weights based on the reviews that the Demand
Planner has done in the preceding steps. This comes down to a judgment call on
the part of the Demand Planner as to which forecasting category or categories
should be used to drive the calculated unconstrained consensus demand plan.
 Not For Copy or Distribution

1) An interesting thing to note about this worksheet is that it only shows values for
already existing Part/Customer/Category headers.
1) For example, in the above screen shot, you will not see a Finance
category for Part LCD-3735 in Site SOP030 although you do see it for
the same Part in Site SOPDC-Europe. There is no “header” record for
Finance in Site SOP030.
2) In order to edit those default values, a header record needs to be created.
3) A data command is provided to do this. Running this command will add
in any missing header records for whatever node is selected in the
associated filters and hierarchy.
2) The drop-list of “categories” is not a complete list of
HistoricalDemandCategory values:
1) ($DP_HideRangeForecasting = 'Yes'
And (Value IN $DP_BudgetForecastCategory,
$DP_MarketingForecastCategory, $DP_SalesForecastCategory,
$DP_StatisticalForecastCategory))
OR
($DP_HideRangeForecasting = 'No'
and (Value IN $DP_BudgetForecastCategory,
$DP_MarketingForecastCategory, $DP_SalesForecastCategory,
$DP_StatisticalForecastCategory, $DP_BudgetForecastOptimistic,
 Not For Copy or Distribution

$DP_BudgetForecastPessimistic, $DP_MarketingForecastOptimistic,
$DP_MarketingForecastPessimistic, $DP_SalesForecastOptimistic,
$DP_SalesForecastPessimistic))
2) It should never include override, adjustment, actuals or target categories. It should
only include forecast categories that have a Type.ProcessingRule of Forecast and
contains records that could drive consensus forecast.
 Not For Copy or Distribution

1) An interesting thing to watch for in this worksheet is the “Total” effective ratio.
If, for example, you were to set the ratios to 50% and 25% and 35% the total
becomes highlighted and 110%. This is flagged as unexpected but it will still
work. It’s just that the calculated consensus forecast ends up being inflated
beyond 100%. Similarly, the total could end up adding up to something less
100% in which case the forecast is smaller than the inputs. This might be useful
if, for example, Sales is always the best forecast source but they are always 10%
high. In this case, maybe you really do want to drive the consensus forecast
entirely from Sales but only something like 90% of it. It will be highlighted but
it will work.
2) The bottom pane shows worksheets displaying the effective ratio, input
forecasts and resulting calculated consensus forecast by period for each of the
categories along with the total. One worksheet shows this in units while the
other displays in revenue. These are the views that show the forecasts per
category and resulting consensus demand based on the edited (or default) ratios
in the top pane.
 Not For Copy or Distribution

1) This workbook is the resource used by the Demand Planner in the development
of the unconstrained demand plan.
1) It is used to “adjust” the demand plan to the from the default calculated
consensus forecast.
2) The workbook also contains the command to delete existing adjustments
and overrides.
2) In addition, you can use this workbook to compare the statistical forecast
generated for a product with the dependent demand calculated as a result of
exploding through a planning BOM.
3) In 2014.4, The workbook variable ForecastCategory was renamed to
RR_Analytics_Disaggregation_ForecastCategory. This workbook variable must
be present in order for the Analytics to return results.
 Not For Copy or Distribution

1) The only part of this worksheet that is editable is the “Adjustments” row (by
default).
1) However, an author can un-hide the “Promotional Adjustments” and
“Forecast Override” rows which are also editable.
2) Disaggregation for these rows is typically driven by the calculated
consensus forecast in order to only make adjustments to those
Part/Customer/Categories that are actually contributing to the demand
plan.
3) Adjustment categories have a
HistoricalDemandCategoryType.ProcessingRule of Forecast and a
ConsensusForecastWeight of 100%.
4) However, the Override category will have a
HistoricalDemandCategoryType.ProcessingRule of ForecastOverride
and the weight is, therefore, irrelevant.
5) It is NOT generally recommended that you un-hide the “Forecast
Override” row here. Leave that function for the “S&OP Demand
Supply Balancing” workbook (covered in the S&OP Application).
1) The “S&OP Demand Supply Balancing” workbook actually
uses a HistoricalDemandCategoryType.ProcessingRule of
ReBalancingForecastOverride for this purpose.
 Not For Copy or Distribution

2) The ReBalancingForecastOverride is a final adjustment AFTER the

override has been applied. For example, a forecast that has been explicitly
overridden with a quantity of 100 can be further “adjusted” by this
category by adding or subtracting some quantity to the override.
1) There are a variety of drill-to-details capabilities exposed here as well.
1) The four row headers “Finance”, “Sales”, “Marketing” and “Statistical”
will each open a workbook corresponding specifically to those forecast
categories (“S&OP Finance Operating Plan”, “S&OP Sales Forecast”,
“S&OP Marketing Forecast” and “S&OP Statistical Forecasting”) in
view only mode for the Demand Planner.
2) The other row header drill-to-details is on the “Unconstrained Demand
Plan” header and will open the “S&OP Demand Planning Ratios”
workbook to give the planner a chance to adjust the weights or ratios from
each forecast demand stream that will drive the calculated consensus
forecast.
3) Within the data, there are two additional drill-to-details links. The data in
the “Demand at Risk” row will open the “S&OP Demand Plan at Risk
Treemap” workbook to get more details about the consensus demand plan
that is at risk of not being fulfilled by the supply plan.
4) Finally, the number displayed in the “Assumptions” row indicate the total
number of assumptions effective for the period. Clicking on this number
will open a worksheet in the bottom pane listing those specific
assumptions.
Not For Copy or Distribution

1) Also available in the bottom pane, are a variety of charts

showing the consensus demand plan, demand plan history,
confidence intervals and dependent demand plan (for
MPSConfig driven forecast).
1) As with other places in our reports, the confidence
interval charts only show one side of the interval (either
the upper bound or the lower bound). The other side is in
the underlying report but would need to be un-hidden by
an author.
Not For Copy or Distribution

1) In order to expose the upper bounds of the confidence interval,

you need to unhide the 3 columns in the component worksheets
and select them on the graph.
1) Confidence Interval – Revenue Chart
2) Confidence Interval – Units Chart
Not For Copy or Distribution
 Not For Copy or Distribution

1) This presentation is NOT trying to replace that one (yet). Please refer to it.
2) In particular, discussions about disaggregation and alternative ForecastItem
setup techniques are assumed to be understood.
Not For Copy or Distribution
 Not For Copy or Distribution

1) RR-56815 created to add DemandType to the insert definition.

 Not For Copy or Distribution

1) It is capable of calculating and storing the statistical forecast. However, the

expectation is that this workbook is mostly used simply to define all of the
required settings and let the S&OP Statistical Forecasting (Automated)
workbook perform the actual generation of the statistical forecast.
2) Recall ForecastItem = a collection of PartCustomers that will be forecast
together
 Not For Copy or Distribution

1) *Note that in 2015.3, the statistical forecasting dialog will be replaced by the
forecast item attribute approach to set up forecast items*
2) This dialog gives the Demand Planner the opportunity to create/maintain the
definitions of the existing Forecast Items.
3) It is expected that this will need updating only very infrequently. Once the
forecasting levels are defined, they should not need a lot of maintenance.
4) However, correcting the PartCustomer relationship to the ForecastItems is
something that will need to be done prior to each new generation of statistical
forecast as new PartCustomers may now exist or characteristics of existing
PartCustomers may have changed.
5) Another feature of the dialog is to disable/enable generation of the statistical
forecast for specific ForecastItems. This can also be done from the Forecast
Item Configuration worksheet.
 Not For Copy or Distribution

1) *Note that in 2015.3, the statistical forecasting dialog will be replaced by the
forecast item attribute approach to set up forecast items
2) The dialog becomes unmanageable after about 10,000 and actually crashes after
65,535.
3) The rest of the workbook is still required and useful regardless of which of the
three methods are used.
4) Bear in mind that the Check Forecast Items workbook becomes useless if the
fully automated approach is used. An equivalent workbook can be created that
does the same reporting but runs many orders of magnitude faster by using the
CalcForecastItem calculated field on the PartCustomer table.
5) Also note that, losing the dialog (preferred option), the user will need to be able
to “disable” Forecast Items back on the Forecast Item Configuration worksheet.
 Not For Copy or Distribution

1) If the setup dialog is not used, then the user can still enable/disable
ForecastItems using the little graph icon above.
2) We’ve seen the need to extend functionality which leads to customizing the
Change Forecast / Do Not Forecast worksheet.
3) Note that the Forecast Item Configuration worksheet is on the
ForecastItemParameters table. Only the Change Forecast / Do Not Forecast
worksheet is on the ForecastItem. So, editable custom fields on the ForecastItem
directly need to be edited there.
4) Older versions of the Forecast Item Configuration worksheet will hide the
forecast category and the actuals category. Make sure to un-hide them.
 Not For Copy or Distribution

1) Un-hide the Settings (Details button) to see Control Set reference and showing
the detailed including the Trend Decay Factor.
1) If the Type TrendDecayFactorRule is Use, then the factor here is
editable
2) Whatever Models are desired must be setup.
1) When you choose Crostons, there is another setting on the Type that is
the CrostonsPredictRule. You can't tell here if it is Constant or Sporadic
so you need to name the type appropriately.
3) The Fit Measure is only applicable when BestFit is selected. Defines “Best”.
4) If Model Constant Usage is set to Use instead of Calculate, it means the planner
must provide Alpha, Beta, Gamma, SmoothedValue, TrendValue,
SeasonalIntervalCount, MovingAverageIntervalCount etc. directly (rather than
letting RapidResponse calculate it) in the ForecastItemParametersFitOutput
table using the Model Constants worksheet. Very bad call unless you
understand the math VERY well. If you do, then you probably know better than
to do this anyway. If the customer asks for this ability, then try to push back and
contact your SSA. Elliott can also help you to push back.
 Not For Copy or Distribution

1) There can be rules and data changes established to move specific PartCustomer
records between HO and GS; dynamic.
2) AggregatePartCustomer feature in release 2014.4 SU2, http://jira/browse/RR-
56930
3) AggregatePartCustomer is available now and should be used instead of the
History-Only and Generate-Statistical forecast items.
 Not For Copy or Distribution

1) Creates any required HistoricalDemandHeaders to hold the statistical forecast

2) Deletes pre-existing ForecastItemParametersFitOutput records (that are for
Calculate ForecastItemParameters.Types selected).
3) Creates a new set of those ForecastItemParametersFitOutput records based on
the statistical parameters specified.
4) Finally, creates/updates/deletes the statistical ForecastDetails records for the
selection
5) You can then review the results in the Forecast Review worksheet.
6) The normal creation of the statistical forecast will be done by the S&OP Insert
Statistical Forecast scheduled task which executes the “Save Forecast”
command from the S&OP Statistical Forecasting (Automated) workbook
against the whole database.
1) If there are multiple statistical forecast categories, this command can be
run for one category at a time or for all of them at once.
 Not For Copy or Distribution

1) In 2014.4, based on the ForecastItemParametersFitOutput table

1) Not the same restriction on string to numbers. With the new
ForecastItemParametersFitOutput, the field type is quantity and not
string. It does not need to parse it any longer.
2) Remember to resist this required functionality. It’s a bad idea. However, typos in
these fields can result in very odd results (and/or errors).
Not For Copy or Distribution
Not For Copy or Distribution
 Not For Copy or Distribution

Note that this is still applicable for 2014.4 and earlier, but will become obsolete
in 2015.3
1) Special transformation functions are called to determine the appropriate
ForecastItem for every PartCustomer based on the information saved in the
ForecastItem Path, PathLevels, PathExpression and FilterExpression fields.
2) These are the “errors” worksheets that used to be in the S&OP Forecast Item
Management workbook that always performed so poorly.
3) For large datasets, don’t EVER open this. Highly recommend that you avoid the
use of the Statistical Forecasting Setup dialog in those cases.
4) If ForecastItems are defined and assigned automatically (highly recommended)
then this workbook is not required. When required, it should be noted that the
performance for a large number of ForecastItems (greater than a few thousand)
is going to be very slow.
5) The first worksheet reports all PartCustomer records associated with the blank
ForecastItem. The worksheet will perform a calculation to determine which
ForecastItem path that each of these PartCustomer records should be
referencing.
6) The second worksheet is reporting PartCustomer records that are currently
associated with a (non-blank) ForecastItem where the expressions found in the
ForecastItem Path, PathLevels, PathExpression and FilterExpression fields
would indicate that it should be associated with a different ForecastItem. Again,
 Not For Copy or Distribution

the worksheet will perform a calculation to determine which ForecastItem path that each
of these PartCustomer records should be referencing.
7) Correcting both of these conditions is done simply by opening the Statistical Forecasting
Setup dialog and pressing OK or by selecting the “Automated Forecast Setup” command
button in the S&OP Forecast Item Management workbook. Both actions are manual
operations and cannot be automated.
8) Note that there is a corresponding worksheet still in the S&OP Forecast Item
Management workbook that is exposed in the bottom pane by selecting the Input Errors
worksheet from the top pane. This worksheet is called Forecast Items with No
Item/Customers. This worksheet shows all ForecastItem records except the blank (empty)
one and any of the “Other” forecast items that contain no PartCustomer records. These are
not really errors but may be eligible to be deleted.
 Not For Copy or Distribution

1) Really do not expect this workbook to be modified at all.

2) Possibly some data changes to setup the ForecastDisaggregationParameters for
specific categories.
3) There are three primary tables of data being maintained by this workbook:
ForecastDisaggregationParameters, ForecastDisaggregationOverride and
AggregatePartCustomer.
4) Disaggregation ALWAYS spreads to the DisaggregationCalendar (pre-2014.4
was $DP_BaseCalendar) interval regardless.
 Not For Copy or Distribution

1) Prior to 2014.4, disaggregation of forecast was driven by a set of Historical

Demand Actuals with a category defined by the profile variables:
$DP_DefaultDisaggregationActuals (ActualDemand),
$DP_HistoricalIntervalCount (12), $DP_InnerCalendar (Month) and
$DP_OuterCalendar (Month).
2) In 2014,4, the following from the SOPAnalyticsConfiguration table is used:
1) DisaggregationActualsCategory (Actual Demand)
2) DisaggregationInnerCalendar (Month)
3) DisaggregationOuterCalendar (Month)
 Not For Copy or Distribution

1) In 2014.4 SU2 new worksheet added to S&OP Forecast Disaggregation

workbook called “Aggregate Part Customers”
1) Only visible when the view selector is set to “Configuration”
2) Based on AggregatePartCustomer table
2) Specific to 2014.4: In this worksheet, if you try to add an Aggregate Part
Customer, it fails because the insert definition used does not specify the Type.
1) The AggregatePartCustomerType has a ControlSet key reference which
would be established by the Component.Part.Site selected if it is not
explicitely defined in the insert dialog.
2) In the absence of anything in the insert dialog, the engine will attempt to
create the AggregatePartCustomer with a Type.Value set to the default
value defined for the AggregatePartCustomerType.Value field (probably
blank if not overridden) and a Type.ControlSet matching the
Component.Part.Site.ControlSet.
3) In order to be successful, it would need that default (blank) type in all
ControlSets
4) Therefore there needs to be a default (blank if necessary)
AggregatePartCustomerType defined in all Control Sets.
5) This will be addressed in a PDR DR for 2015.3 (see
http://jira/browse/RR-63108)
 Not For Copy or Distribution

1) Make sure that you just pick the set you want to override on the hierarchy and
the Category on the toolbar.
2) Then run the command to create the override records for the
Part/Customer/Categories.
3) Then edit the Inner/Outer Calendar, Actuals category and amount of history to
look for in the bottom pane.
4) Creating/editing the ForecastDisaggregationParameters records.
5) This applies ONLY to the selected category UNLESS there is a setting in the
SOPAnalyticsConfiguration record for the
ForecastDisaggregationOverrideCategory. If you are editing this category then
you are editing overrides for all other categories that don’t have specific
overrides for themselves.
1) Prior to 2014.4, you needed to override each category individually. Now,
if you are editing overrides for the category defined by the
SOPAnalyticsConfiguration table in the
ForecastDisaggregationOverrideCategory reference then you are editing
overrides for all other categories that do not have specific overrides.
 Not For Copy or Distribution

1) At least one of the selections must be something other than zero.

2) Most editing of the forecast data will only use these disaggregation override
values if there is not already data in the edited bucket.
 Not For Copy or Distribution

1) To revert to default, delete the records in the bottom pane.

2) Actually, can be used without Statistical Forecasting but it is expected that these
cases will only use the SOPAnalyticConfiguration settings.
3) Note that we do NOT have a workbook for importing the disaggregation rates
in from an Excel sheet.
 Not For Copy or Distribution

1) This is the only view that shows the actuals with the fitted actuals along side the
forecast.
 Not For Copy or Distribution

1) This is really the only report that shows the fitted actuals for the forecast items.
2) It also has the calculated fit output and output errors.
 Not For Copy or Distribution

1) While the top pane just provides all of the ForecastItemParametersFitOutput

data, the bottom pane is most useful is showing how the statistical forecast is
disaggregated to PartCustomers.
2) If you see too many cases where some of the PartCustomers are getting very
tiny fractions of total demand, then you may need to define using
AggregatePartCustomers rather than HO/GS. A PartCustomer with a tiny
amount should probably not be an aggregate.
Not For Copy or Distribution
 Not For Copy or Distribution

1) Provide details where to find documentation and results

2) For results, see Cross Application Training 2014.4

3) SHOW:
1) Use Cases and resources tested (open first link) to Test Script Summary
tab, to show the tests and use-cases (ie. what portions of the application
we tested)
2) Confluence space containing test scripts (open second link)
3) Test results file (open 3rd link or 4th link); will likely need to explain
interpretation of results
Not For Copy or Distribution
Not For Copy or Distribution
Not For Copy or Distribution
Not For Copy or Distribution
Not For Copy or Distribution