Application Summary Document - Sales Operations Planning

RapidResponse
Application Summary
For Sales and Operations Planning
Revision: 8
Date: 29-Aug-2016
FOR INTERNAL USE ONLY

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
Table of Contents
Table of Contents ........................................................................................................................ 2
Document Revision History ....................................................................................................... 3
1 - Introduction ............................................................................................................................ 4
1.1 Objective ......................................................................................................................... 4
1.2 Functionality................................................................................................................... 4
1.3 Measurements ................................................................................................................ 5
1.4 Roles and Responsibilities ........................................................................................... 5
2 - Business Processes .............................................................................................................. 7
2.1 Business Process Flow Diagram ................................................................................. 7
2.1.1 Inputs ........................................................................................................................ 16
2.1.2 Outputs ..................................................................................................................... 17
2.1.3 Scenario Structure .................................................................................................... 17
3 - Resources ............................................................................................................................ 22
3.1 Metrics, Dashboards and/or Scorecards ................................................................... 28
3.1.1 Dashboards .............................................................................................................. 28
3.1.2 Corporate Metrics Scorecard .................................................................................... 28
3.2 Other Resources: Processes, Task Flows, Workbooks ........................................... 29
3.2.1 Processes ................................................................................................................. 29
3.2.2 Taskflows.................................................................................................................. 30
3.2.3 Workbooks ................................................................................................................ 31
4 - Integration Requirements ................................................................................................... 32
4.1 Data and Integration Requirements ........................................................................... 32
4.1.1 Database Scale ........................................................................................................ 32
4.1.2 Configuration Points ................................................................................................. 33
4.1.3 Control Table Configuration...................................................................................... 50
4.1.4 Detailed Data Requirements .................................................................................... 54
4.1.5 Closed Loop and Data Reconciliation ...................................................................... 63
4.2 Data Integrity Requirements ....................................................................................... 67
Copyright © 2016 Kinaxis. All rights reserved. Page 2 of 68

Document Revision History

Version Changes Author Date
1 Initial Revision for 2014.4 Emily Fisk 13‐Feb‐15
2 Updated for 2014.4 SU2 addition of Aggregate Part Emily Fisk 16‐Mar‐15
Customer capabilities
3 Updated Automation to include details to Delete Emily Fisk 17‐Mar‐15
Assumptions
4 Updated all sections to reflect the most current Emily Fisk 8‐Sep‐15
snippet content
5 Updated for 2015.3: new process flows; reference to Emily Fisk 28‐Oct‐15
Application Settings WB instead of Configuration WB
for S&OP settings
6 Updated Roles & Responsibilities; applicable for Emily Fisk 13‐Apr‐16
2015.3 onwards
7 Annual Plan is to be edited in a child of Baseline rather Paul Haviland 27‐May‐16
than S&OP Candidate
8 Updated as per RRP‐78979 Paul Haviland 29‐Aug‐16

1 ‐ Introduction
Sales and Operations Planning is an iterative business management process that aims to achieve focus,
alignment and synchronization across multiple functions of an organization. The S&OP process routinely
reviews customer demand and supply resources, and develops a plan to achieve the organizational
financial and strategic objectives.
The Sales and Operations and Planning Application is outlined below. The scope of this Application is
limited to the following processes and sub‐processes: Overall S&OP Process, Update Annual Plan, S&OP
Supply / Demand Rebalancing and Executive S&OP Meeting. This Application also includes several role
based dashboards and if it is purchased without any other application, the expectation is that the
necessary data will be provided as input to this Application, for example, Demand Plan or Supply Plan
data.
1.1 Objective
The objective of Annual Plan Management is to establish an annual plan against which progress may be
monitored and measured throughout the year. This includes setting financial targets through the year
for various categories and levels of product and/or regions or almost any other hierarchy selection that
measures and categorizes forecasted demand.
These targets include not just an absolute target number but a measure of acceptable variability from
that target. The actuals measured through the year will be compared to the targets and will alert when
results are forecasted to be out of the acceptable tolerance levels (limits).
The unconstrained forecast will be presented as input to the supply‐side of the business to determine if
this can actually be supplied. Operations will evaluate it to determine what can be supplied (as a
separate activity) and will feed that information back into this process to define the constrained
consensus demand plan.
The objective of S&OP Supply / Demand Rebalancing is, therefore, to create the constrained consensus
forecast, and the constrained aggregate supply plan for presentation to the S&OP Executives.
The objective of the Executive S&OP Meeting is to select an achievable sales and operations plan to
execute to.
1.2 Functionality
The functional capabilities of the S&OP application include:
 Set various financial targets and acceptable levels of variability

 Measure progress against those targets
 Identify gaps between the consensus demand plan and aggregate supply plan, and re‐balance by
changing or “shaping” the forecast demand in such a way as to be achievable
 Evaluate multiple supply‐demand balancing scenarios against various company metrics to
enable optimal trade‐offs
 Define and manage the sales and operations planning process activities through a simple
process template and process orchestration

 Enter and maintain S&OP Assumptions
Usually the annual plan is defined at some hierarchy level. As such, hierarchies must be defined to
manage where the targets and limits are entered and maintained.
1.3 Measurements
Standard measures include:
1) Ending Inventory Value: Summary of the value of the projected ending inventory at the end of
each period.
2) Margin %: Summary of the difference between revenue and cost of goods sold by period,
expressed it as a percentage of revenue.
3) Revenue Value: Summary of the revenue for actual orders and forecast, by period.
4) On Time Delivery to Request: Historical and projected percentage, by period, of order lines
available on or before their request date.
5) Key Constraint Utilization %: Summary of the actual load, by period, expressed as a percentage
of the available load for key constraints.
1.4 Roles and Responsibilities
Role Responsibility
S&OP Process Owner Monitors the overall sales & operations planning process to ensure that
decisions are made on time and the process is moving along to
expectations.
Finance Maintains the financial targets and limits in the annual plan. Also monitors
and reports on performance against those targets and maintain the
finance operating plan.
(Demand Planning only) This role also contributes to the demand forecast,
as required.
Demand Planner Owns the consensus demand forecast. It is the demand planner’s role to
add the adjustments and overrides to the consensus plan to create a
realistic forecast that represents all the various parties with vested
interests (finance, sales and marketing as well as operations). Cleaning up
the historical actual data and generation of the statistical forecast, if
applicable, is also the role of the demand planner.
This role is highly collaborative, and will work with the finance, sales,
marketing, supply planning and operations roles.
Sales and Marketing Sales and marketing each have their own view of the forecast demand and
provide input during the executive S&OP review meeting.
(Demand Planning only) As part of the Demand Planning process, these
roles will provide input to the demand forecast to ensure that the resulting
consensus forecast represents their view.
Supply Planner Provides a high level supply plan in response to the consensus plan

generated by the demand planner.
This role collaborates with the both the master scheduler and operations
roles to ensure available material and capacity in support of the supply
plan.
Inventory Planner Evaluates inventory target levels and updates inventory policies to ensure
that service levels and inventory targets are being maintained.
(Inventory Management and MPS only) Inventory Planners define ordering
policies such as safety stock and minimum/maximum ordering quantity,
and control the costs associated with the inventory. They also address
inventory issues related to an achievable master schedule, while
minimizing overall inventory costs but maintaining desired customer
service levels.
(Inventory Management only) They also analyze the excess and obsolete
inventory position, and manage such inventory.
Primarily, the Inventory Planner collaborates with the master scheduler,
material planner and demand planner roles, but may also collaborate with
the customer service representative and finance roles for various activities
within the Inventory Management process.
Operations Evaluates the initial unconstrained consensus demand plan and provides
the constrained supply plan as input to balancing the demand and supply
plans.
(Capacity Planning Constraints, Aggregate Supply Planning and MPS only)
The operations role manages the definition of constraints, and is
responsible for providing input on rates by period and effective dates for
all constraints. They are also responsible for associating specific parts with
constraints.
This role collaborates with the supply planner and the master scheduler to
identify and resolve gating constraints.
Executive (S&OP) Selects and approves the final S&OP plan.

2 ‐ Business Processes
2.1 Business Process Flow Diagram
The following business processes are driven in RapidResponse through the use of TaskFlows. These taskflows allow the user to have a guided
experience through the different business process flows. Details on the taskflows included with this blueprint can be found in section 3.2 Other
Resources.

The overall S&OP process flow shown above includes various roles and functions. The “Update Annual Plan”, “Rebalance Demand to Supply” and
“Executive Review and Approval” are sub‐processes that are expressed in more detail below. The Demand Planning, Aggregate Supply Planning

and Capacity Planning activities can be purchased to support the S&OP process. If they are not purchased, it is expected at a minimum data
feeds are provided for the Consensus Demand Plan and the Supply Plan in order to facilitate the re‐balancing activity.


1. Does Annual Plan require revision?: This decision is generally a question of timing. The annual plan is usually established once per year
and not otherwise touched. There are occasional exceptions, however the criteria for determining this is outside the scope of
RapidResponse. As such, there are no resources defined to help with making this decision.
2. Define and update the Annual Plan: Using the Update Annual Plan task flow, link to S&OP Annual Plan or the S&OP Constraint Annual
Plan (if Capacity Planning Application is purchased) workbook or directly open the S&OP Annual Plan or S&OP Constraint Annual Plan
(if Capacity Planning Application is purchased) workbook, and create a private scenario based on the Baseline scenario to define and
update the Annual Plan.
3. Define and update Limits for the Annual Plan: Also using the S&OP Annual Plan or the S&OP Constraint Annual Plan (if Capacity
Planning Application is purchased) workbook, on the Settings worksheet in the same private scenario define and update Limits for the
AOP that will be used for alerting in subsequent sub‐processes.

4. Update Assumptions: In the same private scenario record Assumptions using S&OP Annual Plan or the S&OP Constraint Annual Plan (if
Capacity Planning Application is purchased) workbook. Review and maintain assumptions using the S&OP Annual Plan or the S&OP
Constraint Annual Plan (if Capacity Planning Application is purchased) workbook.
5. Review Annual Plan: Using the Executive dashboard select the private scenario to review change against appropriate metrics. Commit
the private scenario to Baseline.


1. Compare the Supply Plan and its ability to support the Demand Plan. In cases where it cannot, it is common for the resolution path to
be to "shape" the demand. This may involve emphasizing and de‐emphasizing the forecast for particular regions or products etc. The
result is a constrained demand plan: Using the S&OP Demand Supply Balancing and the S&OP Assumptions workbooks the Demand
Planner will conduct a meeting with all relevant parties to review and re‐balance the demand where necessary.
2. Compare the alternate scenarios with each other based on the defined company metrics. Eliminate unacceptable scenarios and
identify possible candidate scenarios for the constrained demand plan: Using the Corporate Metrics scorecard and the S&OP
Assumptions workbook.
3. Review and Consolidation of Assumptions: Using the S&OP Assumptions workbook.


1. Present Candidate Scenarios including assumptions to Executive S&OP Team: Using the Corporate Metrics scorecard and the S&OP
Assumptions workbook.
2. Compare the alternate scenarios with each other based on the company metrics and assumptions: Using the Corporate Metrics
scorecard and the S&OP Assumptions workbook.
3. Choose and approve an Approved S&OP scenario: This involves promoting the selected S&OP Candidate scenario and deleting the
rejected ones. There are no specific resources required for this once all assumptions are recorded.
2.1.1 Inputs
The targets are not dependent on historical data. Therefore the only real prerequisite data for this is the basic Part / Customer data. Targets for
categories may be defined and are normally maintained only in RapidResponse. If there is target information available from on external source,
it may be imported.
Out of the box, a number of targets and limits may be set up and used for the default “categories” of forecast. Refer to section 4.1.4.1 Annual
Plan Targets and Settings for the complete list.
Limits are expressed as Warning and Critical % of the target. A negative limit means values exceeding the target are desirable.
The inputs for the Update Annual Plan sub‐process include:

 Current Annual Plan
The inputs for the S&OP Team Supply / Demand Rebalancing sub‐process include:
 Constrained Supply Plan
 Consensus Demand Plan
 A small set of achievable Demand and Supply Plans
The inputs for the Executive S&OP Meeting sub‐process include:

 Consolidated Assumptions
 A small set of achievable Demand and Supply Plans

2.1.2 Outputs
The Annual Plan targets are compared to each forecast category being evaluated when determining the final consensus forecast in the
Consensus Demand Planning process. It is also reported as the target "Annual Plan" in the Finance dashboard.
While there are no predefined alerts defined to automatically report on deviation from the above targets, they may be easily setup.
The targets are stored in the ForecastDetails table under specific HistoricalDemandCategory values. The limits associated with these targets are
defined in the HistoricalDemandCategory directly. These categories (as well as others) have Type.ProcessingRule = “Target”. Section 4.1.3.3
HistoricalDemandCategory describes how to set up the categories.
The outputs of the Update Annual Plan sub‐process include:

 Revised Annual Plan (targets and limits)
The outputs of the S&OP Team Supply / Demand Rebalancing sub‐process include:
 Consolidated Assumptions
The outputs of the Executive S&OP Meeting sub‐process include:

 An approved achievable Sales and Operations Plan (working scenario that will be committed up)
 Cross Scenario update into the Baseline scenario to drive demand within the Master Production Scheduling, Order Fulfillment and
Supply Action Management Applications, when applicable:
o Consensus Forecast records
2.1.3 Scenario Structure

The scenario structure below supports all RapidResponse Applications:

Scenario Purpose Permanent? Shared? Modify/ Auto‐

View? Update?
Enterprise Data Import Data from ERP or Data Integration Server; represents the most Y System/Dat V N/A
recent data extracted from enterprise data sources or Data Integration a Admin
Server data source
Approved Actions Child of Enterprise Data; Scenario to perform automated data Y System/Dat V Y
manipulation and modification of Host system data to support the a Admin
solution
Baseline Child of Approved Actions; Scenario that holds RapidResponse user Y Y M N
maintained system of record master data supporting all Applications;
annual plan targets, manual data modification and maintenance
Also contains Integrated Project Management Project Actuals (working

project plans)
Child scenarios are committed into Baseline (Master Production

Scheduling and Order Management; S&OP Intermediate is not committed
to Baseline) on a scheduled frequency determined at Integration. This is
especially important for data that crosses multiple processes.
Updated on a scheduled frequency determined at integration. It is

View? Update?
important to update upon completion of all Data Change tasks on
Approved Actions.
Prior to update, this scenario is used for the Multi‐scenario comparison of

records, against Approved Actions, to determine reconciliation actions.
History Child of Baseline; This is the root scenario used for the creation of Y Y V N
historical scenarios; daily, weekly, monthly and quarterly.
Deletion of this scenario will result in the inability to automatically create
historical scenarios without modification to the script and related
resources.
S&OP Intermediate Child of Baseline; this scenario is likely available only to S&OP process Y Y M N
owners, and RapidResponse administrators.
Used by Process Owners to start the S&OP Cycle and as part of the
Publish S&OP cycle to update the Current S&OP scenario.
Current S&OP Child of S&OP Intermediate; this scenario represents the current, agreed‐ Y Y V N
upon S&OP Plan. Thought of in another way, it is a snapshot of latest
approved S&OP data.
This scenario is not committed to its parent.

S&OP Archive Child of Current S&OP; This scenario is the archived version of a previous Y Y V N
YYYYMMDD Current S&OP scenario.
It is updated based on the publish S&OP cycle whose frequency is

determined by the customer, but is typically monthly.
S&OP Candidate Child of S&OP Intermediate; This is the working scenario for the S&OP, Y Y M Y
Demand Planning, Aggregate Supply Planning Applications. It is also the
working scenario for Capacity Planning, Inventory Management and
Inventory Planning and Optimization processes as part of an S&OP cycle.
This is the scenario in which the new demand and supply plans are
created, analyzed and brought forward for Executive approval.

View? Update?
This scenario is available on install and is permanent. This scenario is

automatically updated when the S&OP process owner starts a new S&OP
cycle and automatically shared with other people involved in the S&OP
process.
S&OP users collaborate based on this scenario and commit changes back
to it.
Closed‐loop transactions will be executed out of this scenario prior to it

being committed.
Committed into S&OP Intermediate on S&OP Cycle Publish, at the end of

the S&OP planning cycle.
Private Scenario Collaboration and editing scenario(s) for S&OP Candidate; N Y M N
Committing private scenario back into the S&OP Candidate scenario

constitutes completion of collaboration and approval of changes;
It is likely that multiple levels of private scenarios exist under S&OP

Candidate due to collaboration.
Note: The ‘Project Baseline’, ‘Supplier Collaboration Automation’ and ‘Supplier Collaboration’ scenarios are only installed when those
Applications are purchased.
Data Integration Server Recommendations
When working with multi‐server environments containing a Data Integration server (or a server where separate business processes take place),
it is recommended that a minimal scenario tree be maintained and utilized on the Data Integration Server.
The following scenarios would be required:

Data from the ERP system will be regularly updated into Enterprise Data. Any automated data modification would occur in Approved Actions,
with data updated into Baseline where any user data modification occurs. Data update into the Production server (post‐data integration server)
will happen from the Baseline scenario. It is likely that, depending on the process(es) moved to the Data Integration server, additional scenarios
will be required as children of Baseline to accommodate additional processes. If this is the case, scenarios will need to be committed to Baseline
prior to data update so all pertinent data is moved across servers.

3 ‐ Resources
The table below outlines the standard resources provided for each application
Application Process Name Type Com

Common Capacity Planning (Constraints) Constraint Manager Workbook
Aggregate Supply Planning
Master Production Scheduling
Common Capacity Planning (Constraints) Constraint Properties Workbook
Common Capacity Planning (Constraints) Data Integrity ‐ Constraint Workbook
Common Aggregate Supply Planning Data Integrity ‐ Material Workbook

Common All Historical Scenario Workbook
Common Aggregate Supply Planning Inventory Transfers Workbook
Inventory Management
Common Aggregate Supply Planning Inventory Treemaps Workbook
Common Aggregate Supply Planning Inventory Trends Workbook
Common All Maintain Responsibility Workbook
Common Demand Planning NPI Record Creation Workbook
Capacity Planning
Common Inventory Management Periods of Supply Details Workbook
Common Inventory Management Periods of Supply Treemaps Workbook
Common Inventory Management Planning Parameter Workbook
Order Fulfillment
Common S&OP Process Activities Workbook
Common S&OP Process Calendar Workbook
Common S&OP Process Widgets Workbook Workbook
Common S&OP S&OP Annual Plan Workbook
Demand Planning
Capacity Planning
Common All S&OP Assumptions Workbook
Capacity Planning (Constraints)
Common All S&OP Backlog Reports Workbook
Common All S&OP Backlog Treemap Workbook
Common All S&OP Common Expressions Workbook
Common S&OP S&OP Constraint Annual Workbook
Capacity Planning (Constraints) Plan
Common S&OP S&OP Constraint Widget Workbook
Aggregate Supply Planning Detail

Common S&OP S&OP Constraint Widgets Workbook
Common All S&OP Corporate Metrics Workbook
Common All S&OP Data Cleansing Workbook
Common Demand Planning S&OP Demand Metrics Workbook
Common Demand Planning S&OP Demand Plan at Risk Workbook
Treemap
Common Demand Planning S&OP Demand Planning Workbook
Ratios
Common All S&OP Disaggregation Workbook
Common All S&OP Exceptions Workbook
Common Demand Planning S&OP Forecast Accuracy Workbook
Widgets
Common Demand Planning S&OP Forecast Accuracy Workbook
Common Demand Planning S&OP Forecast Details Workbook
Pricing
Common Demand Planning S&OP Forecast Item Workbook
Management
Common All S&OP Forecast Range Workbook
Treemap
Common Demand Planning S&OP Gating Supplies Workbook
Common All S&OP Gross Margin Workbook
Treemap
Common Aggregate Supply Planning S&OP Inventory Metrics Workbook
Common All S&OP Revenue Treemap Workbook
Common Demand Planning S&OP Marketing Forecast Workbook
Common Demand Planning S&OP Sales Forecast Workbook
Common Demand Planning S&OP Statistical Forecasting Workbook

(Automated)
Common Demand Planning S&OP Statistical Forecasting Workbook
Common All S&OP Unit Variance Workbook

Treemap
Common All S&OP Widget Details Workbook
Common All S&OP Widgets Single Workbook
Scenario
Common S&OP S&OP Widgets Dark – Single Workbook
Scenario
Common S&OP S&OP Widgets Dark Workbook
Common All S&OP Widgets Exceptions Workbook
Common All S&OP Widgets Workbook Workbook

Common S&OP S&OP Write History Records Workbook
Demand Planning
Common S&OP Scripts Workbook Workbook
Common Capacity Planning (Constraints) Constraint Usage Widget
Common Capacity Planning (Constraints) Constraint Usage Chart Widget
Common All Ending Inventory Value Widget
Common S&OP Ending Inventory Value Widget
Chart ‐ Dark
Common Inventory Management Demonstrated Service Level Widget
Commit Chart
Commit
Request Chart
Request
Master Production Scheduling Chart
Common Aggregate Supply Planning Excess Value Widget
Common Aggregate Supply Planning Excess Value Chart Widget
Common All Forecast Accuracy Widget
Exceptions
Common Inventory Management Inventory Turns Chart Widget
Common All Key Constraint Utilization Widget
Common All Key Constraint Utilization Widget
Chart
Common All Margin % Widget
Common All Margin % Chart Widget
Common S&OP Margin % Chart ‐ Dark Widget
Common All Obsolete Value Widget
Common Inventory Management Obsolete Value Chart Widget
Common All On Hand by ABC Widget
Common Inventory Management On Hand vs Target Widget
Common All OTD to Request Widget
Common All OTD to Request Chart Widget
Common Aggregate Supply Planning Overloads Widget
Common Aggregate Supply Planning Overloads Chart Widget
Common Inventory Management Periods of Supply by Part Widget
Category Chart

Common All Periods of Supply by Part Widget
Category
Common All Revenue Value Widget
Common All Revenue Value Chart Widget
Common All Revenue Volume Widget
Common All Revenue Volume Chart Widget
Common Capacity Planning (Constraints) Supply Plan Volume Widget
Common Capacity Planning (Constraints) Supply Plan Volume Chart Widget
Common Aggregate Supply Planning Underloads Widget
Common Aggregate Supply Planning Underloads Chart Widget
Common All Maintain Responsibility Task Flow
Common All Reduce Safety Stock Task Flow
Common Inventory Management Inventory Planner Scorecard
Common All Buyers Responsibility
Common All Constraint Planners Responsibility
Common All Inventory Planners Responsibility
Common All Order Fulfillment Responsibility
Common All Production Planners Responsibility
Common Inventory Management A Parts Filter
Common All Active Constraints Filter
Common All All Constraints Filter
Common All All Customers Filter
Common All All Items Filter
Common All All Parts Filter
Common All All Process Instances Filter
Common Integrated Project Management All Projects Filter
Common Capacity Planning (CRP) All Routings Filter
Common Capacity Planning (CRP) All Tasks Filter
Common Capacity Planning (CRP) All Work Centers Filter
Common Inventory Management B Parts Filter
Common All Buy or Transfer Parts Filter
Common All Buy Parts Filter
Common Inventory Management C Parts Filter
Common Inventory Management Finished Goods Filter
Common All Make Parts Filter
Common Aggregate Supply Planning Monitored Constraints Filter
Common Demand Planning NPI Items Filter
Common Aggregate Supply Planning Outsourced Parts Filter
Common Aggregate Supply Planning Outsourced Components Filter
Common Inventory Management Raw Material Filter

Common All Top Level Parts Filter
Common All Transfer Parts Filter
Common Inventory Management Work In Progress Filter
Common Inventory Management Dispose Inventory Form
Common All Finish Activity Form
Common All Insert Model Set and Form
Method
Common All Insert R Parameter Form
Common All Start Activity Form
Common Aggregate Supply Planning Constraint Hierarchy
Common All Customer Hierarchy
Common All Product Hierarchy
Common All Supplier Hierarchy
Common Aggregate Supply Planning Constraint Region Hierarchy
Common All Customer Region Hierarchy
Common All Manufacturing Region Hierarchy
Common All Supplier Region Hierarchy
Common All Dispose Inventory Script
Common All Historical Scenarios Script
Common All Insert Model Set and Script
Method
Common All Insert R Parameter Script
Common All Manage Activities Script
Common All Planners Buyers missing Alert
User ID
Common All Planners Buyers User ID Alert
with no signed in
Common All Historical Scenarios Alert
Common All S&OP Insert Backlog into Alert
History
Common All S&OP Record Outlier Alert
Adjustments
Sales and Operations Planning Sales and Operations Planning Closed Loop within Cycle Workbook
Sales and Operations Planning Sales and Operations Planning Data Integrity ‐ S&OP Workbook
Sales and Operations Planning Sales and Operations Planning Data Reconciliation Within Workbook
Cycle
Sales and Operations Planning Sales and Operations Planning Process Activities Workbook
Sales and Operations Planning Sales and Operations Planning Process Calendar Workbook
Sales and Operations Planning Sales and Operations Planning Process Widgets Workbook Workbook
Sales and Operations Planning Supply Demand Rebalancing S&OP Demand Supply Workbook
Balancing
Sales and Operations Planning Sales and Operations Planning S&OP Executive Exceptions Workbook
Detail

Sales and Operations Planning Sales and Operations Planning S&OP Process Owners Workbook
Exceptions Detail
Sales and Operations Planning Sales and Operations Planning Activities Widget
Executive Exceptions Widget
Sales and Operations Planning Sales and Operations Planning Late Performers Widget
Sales and Operations Planning Sales and Operations Planning Process Owners Exceptions Widget
Sales and Operations Planning Sales and Operations Planning S&OP Process Calendar Widget
Sales and Operations Planning Executive S&OP Meeting Conduct the executive Task Flow
S&OP meeting
Sales and Operations Planning Supply Demand Rebalancing Rebalance Demand to Task Flow
Supply
Sales and Operations Planning Sales and Operations Planning S&OP High Level Process – Task Flow
Demand Planner
Executive
Finance
Inventory Planner
Marketing
Operations
Process Owner
Sales
Supply Planner
Sales and Operations Planning Update Annual Plan Update Annual Plan Task Flow
Sales and Operations Planning Sales and Operations Planning Closed Loop within Cycle Script
Sales and Operations Planning Sales and Operations Planning Data Reconciliation within Script
Cycle
Sales and Operations Planning Sales and Operations Planning Executive Dashboard
Sales and Operations Planning Sales and Operations Planning Process Owner Dashboard
Sales and Operations Planning Sales and Operations Planning S&OP Process Process Template
Sales and Operations Planning Supply Demand Rebalancing Corporate Metrics Scorecard
Executive S&OP Meeting
Sales and Operations Planning Sales and Operations Planning Run Closed loop within Scheduled Task
Cycle Script
Sales and Operations Planning Sales and Operations Planning Run Data Reconciliation Scheduled Task
within Cycle Script
Order Fulfillment Order Fulfillment IndependentDemandChang RI Business
eIDOC Message
3.1 Metrics, Dashboards and/or Scorecards

3.1.1 Dashboards
The following roles have the Executive Dashboard available to them as part of the S&OP Application. By
default the dashboards are not set to refresh automatically. If the customer would like auto‐refresh
turned on it can be done through the dashboard properties.
Executives
Finance
Sales
Marketing
Demand Planner
Supply Planner
Inventory Planner
Operations
The Corporate Metrics tab of the dashboard for all roles report:
 Revenue Value
 Ending Inventory Value
 Margin %
 On Time Delivery to Request
 Key Constraint Utilization
The Process Owner dashboard contains an additional Process Owner Metrics tab which reports:
 S&OP Process Calendar

 Activities
 Late Performers
 Text Widget
The Process Owner role has the Process Owner dashboard available to them as part of the S&OP
Application.
3.1.2 Corporate Metrics Scorecard

The Corporate Metrics scorecard contains the 5 metrics defined in the Corporate Metrics tab of each
role based dashboard. Additional target metrics can be added to this scorecard through the Metrics tab
of the scorecard properties (accessed by users who can author scorecards). When adding a target
metric, the author must ensure the appropriate annual plan category is selected to correspond to the
target metric.
3.2 Other Resources: Processes, Task Flows, Workbooks
3.2.1 Processes
S&OP activities are pre‐defined in the S&OP Process Template, accessed via Processes in the Explorer.
Each of these operations and sub‐processes are laid out in the pre‐defined “S&OP Process”.
By default all activities are set to require status updates from ‘Every user in group’, if the customer
wishes to change this setting, navigate to the Activity Properties > Performers tab and select ‘Any
member of group’ as shown in the following screen shot:
If a portion of the S&OP Process is performed on a “Forecasting” or “Data Integration” server for
performance reasons, updates to the Process Instance should still be performed on the “Planning” or
“Production” server to ensure the necessary team members are updated with progress on the process.
If the Inventory Management Application is not purchased with S&OP, the Manage Inventory activity
should be removed from the S&OP Process Instance Template.
3.2.2 Taskflows
The following Taskflows are provided in support of this application:
 S&OP High Level Process – Finance

o Update Annual Plan (NOTE: if Demand Planning is implemented with S&OP step 8 of this
taskflow should be updated to open the Finance dashboard rather than the Executive
dashboard)
o Input Forecast
 S&OP High Level Process – Sales
o Input Forecast
 S&OP High Level Process – Marketing
o Input Forecast
 S&OP High Level Process – Demand Planner
o Create a Consensus Demand Plan
o Rebalance Demand to Supply
o Executive S&OP Meeting
 S&OP High Level Process – Supply Planner
 S&OP High Level Process – Operations
 S&OP High Level Process – Inventory Planner
 S&OP High Level Process – Process Owner
 S&OP High Level Process – Executive
As part of the S&OP process, the Process Owner is responsible for “Starting” and “Publishing” each
cycle. Upon Starting the process the S&OP Candidate scenario is created and published to the
appropriate S&OP groups (if this is the first cycle, after the first cycle the scenario is permanent) or is
updated from S&OP Intermediate. Upon Publishing the process, the S&OP Candidate scenario is
committed into S&OP Intermediate and a new S&OP Archive YYYYMMDD scenario is created. The
Current S&OP scenario is auto‐updated from S&OP Intermediate.
3.2.3 Workbooks
In addition to those workbook resources found in Section 3 Resources, the following workbooks support
the S&OP Application.
 Process Activities – Workbook used by the Process Owner group to view and manage S&OP
Process Instances they own or in which they are a performer. Can be used to view end to end
process details and schedules, activity properties and late activities or performers
 Process Calendar – Workbook used by the S&OP Process performers (team members) to
manage the status of activities assigned to them as part of an S&OP process instance
 Process Widgets – The source workbook for S&OP Process widgets, contain the visualizations
displayed on the Process Owner dashboard
4 ‐ Integration Requirements
4.1 Data and Integration Requirements
4.1.1 Database Scale
It is imperative that the consultant and customer both understand the database scale that is being
created. This typically needs to be a concern when integrating large amounts of historical data or
performing heavy disaggregation operations, both are items in the S&OP and Demand Planning
Applications, but that does not mean it should not be thought about and considered when deploying
other Applications.
For example, forecasting will create a series of detailed ForecastDetail records for eligible PartCustomer
records from a very high‐level summary perspective. The fact that we are forecasting at a high level does
not mean that we are not creating these detailed records and the scope of this can be easily missed. If
you are forecasting for 200K parts with an average of 200 customers each, then you are forecasting 40M
PartCustomers. Further, if your DisaggregationCalendar is set to weekly and you are forecasting for 2
years, then this will result in 40M * 104 or greater than 4 billion ForecastDetail records. This can be
supported in RapidResponse; however, the performance would be degraded.
With the introduction of vectors, tables that use this data type, don’t have the same record
limitations. For example, the HistoricalDemandSeriesDetail table is a vector on the
HistoricalDemandSeries table. Each HistoricalDemandSeries record can have 4B
HistoricalDemandSeriesDetails in its vector, so there is essentially no practical limit to the number of
detail records contained in a vector table.
As of release 2016.2, RapidResponse supports the concept of large tables, which can hold over 4B
records. This change will allow >4B records in all tables except control tables and the Site table.
With this concept of a large table, RapidResponse will use 64‐bit addressing, instead of 32‐bit
addressing. Only tables that need to be large will switch to this model, since it requires more memory
to store the address pointers. There is nothing for the user or any administrator to do, as this
conversion will be automatic, when needed.
Although this large table support is available and automatic inside RapidResponse, care must be
exercised as this limit is approached. As a small table grows in size (i.e., over time), once that table
exceeds ~3B records, an internal flag is turned on and the table will be converted to a large table the
next time RapidResponse is restarted. (This threshold was chosen to be far enough away from the 4B
‘small table’ record limit that a large surge of records would not be very likely. Exceeding 4B records
while a table is still small would cause disruption to RapidResponse.) During an initial data load, if there
is a chance that more than 4B records need to be loaded into a table, this process may need to be
executed in multiple steps, being sure to restart RapidResponse after the table has exceeded 3.2B
records, but before it exceeds 4B. Alternatively, if you need to start a table out as a ‘large’ table, contact
Support and they will be able to force the internal flag prior to reaching the threshold.
4.1.2 Configuration Points

4.1.2.1 Profile Variables
Many profile variables have been added to configure the S&OP solution. All profile variables have
Variable Name beginning with "DP_". This prefix comes from "demand planning".
 The Application Settings workbook has a worksheet, entitled "Application Variables", for
managing these profile variables. This workbook can be accessed through Administration pane,
System Settings, Application Settings (or through the Explorer).
 Profile variables are used to set target categories. These all have names ending in "Target".
 Profile variables are used to set demand categories. These all have names ending in either
“Category”, “Optimistic” or “Pessimistic” except for one called DP_DemandTypeForConsensus.
Details of these variables can be found in the Demand Planning Application Summary
Document.
Below is a list of the profile variables used to set Target categories, some of which are used in the S&OP
workbooks outlined for this application, but may also be used in additional Pre‐Defined Resources
within RapidResponse. For a complete list of which resources, you can use the Search Resources feature
to perform a search:
No Variable Name Description Default value

1 DP_BacklogPercentTarget Backlog Percent BacklogPercentTarget
Target
2 DP_BacklogValueTarget Backlog Value Target BacklogValueTarget
3 DP_BacklogVolumeTarget Backlog Volume BacklogVolumeTarget
Target
4 DP_BudgetValueTarget Budget Value Target BudgetValueTarget
5 DP_BudgetVolumeTarget Budget Volume BudgetVolumeTarget
Target
6 DP_ConstrainedDemandUnitTarget Constrained Demand ConstrainedDemandUnitTarget
Unit Target
7 DP_ConstrainedDemandValueTarget Constrained Demand ConstrainedDemandValueTarget
Value Target
8 DP_ConstraintUsageTarget Constraint Usage ConstraintUsageTarget
Target
9 DP_DemandPlanAPIVolumeTarget Demand Plan API DemandPlanAPIVolumeTarget
Volume Target
10 DP_DemandPlanValueTarget Demand Plan Value DemandPlanValueTarget
Target
11 DP_DemandPlanVolumeTarget Demand Plan Volume DemandPlanVolumeTarget
Target
12 DP_ExcessUnitTarget Excess Unit Target ExcessUnitTarget
13 DP_ExcessValueTarget Excess Value Target ExcessValueTarget
14 DP_ExpiryValueTarget Expiry Value Target ExpiryValueTarget
15 DP_ExpiryVolumeTarget Expiry Volume Target ExpiryVolumeTarget

16 DP_FGInventoryTarget Finished Goods FGInventoryTarget
Inventory Target
17 DP_FGPeriodsofCoverageTarget Finished Goods FGPeriodsofCoverageTarget
Periods of Coverage
Target
18 DP_FulfillmentRateTarget Fulfillment Rate FulfillmentRateTarget
Target
19 DP_GrossMarginPercentTarget Gross Margin Percent GrossMarginPercentTarget
Target
20 DP_GrossMarginTarget Gross Margin Target GrossMarginTarget
21 DP_InventoryTurnsTarget Inventory Turns InventoryTurnsTarget
Target
22 DP_KeyConstraintUsageTarget Key Constraint Usage KeyConstraintUsageTarget
Target
23 DP_MarginPercentTarget Margin Percent MarginPercentTarget
Target
24 DP_MarketingValueTarget Marketing Value MarketingValueTarget
Target
25 DP_MarketingVolumeTarget Marketing Volume MarketingVolumeTarget
Target
26 DP_ObsoleteUnitTarget Obsolete Unit Target ObsoleteUnitTarget
27 DP_ObsoleteValueTarget Obsolete Value ObsoleteValueTarget
Target
28 DP_OnTimeCommitTarget On Time Commit OnTimeCommitTarget
Target
29 DP_OnTimeRequestTarget On Time Request OnTimeRequestTarget
Target
30 DP_OverloadedConstraintsTarget Overloaded OverloadedConstraintsTarget
Constraints Target
31 DP_PastDueBacklogValueTarget Past Due Backlog PastDueBacklogValueTarget
Value Target
32 DP_PastDueBacklogVolumeTarget Past Due Backlog PastDueBacklogVolumeTarget
Volume Target
33 DP_PeriodEndingInventoryAPIUnitTarget Period Ending PeriodEndingInventoryAPIUnitTarget
Inventory API Unit
Target
34 DP_PeriodEndingInventoryUnitTarget Period Ending PeriodEndingInventoryUnitTarget
Inventory Unit Target
35 DP_PeriodEndingInventoryValueTarget Period Ending PeriodEndingInventoryValueTarget
Inventory Value
Target
36 DP_PeriodsOfCoverageTarget Periods Of Coverage PeriodsOfCoverageTarget
Target
37 DP_RevenueAtRiskTarget Revenue at Risk RevenueAtRiskTarget
Target
38 DP_RMInventoryTarget Raw Material RawMaterialInventoryTarget
Inventory Target
39 DP_RMPeriodsofCoverageTarget Raw Material Periods RMPeriodsofCoverageTarget
of Coverage Target

40 DP_SalesValueTarget Sales Value Target SalesValueTarget
41 DP_SalesVolumeTarget Sales Volume Target SalesVolumeTarget
42 DP_SpendTarget Spend Target SpendTarget
43 DP_StatisticalValueTarget Statistical Value StatisticalValueTarget
Target
44 DP_StatisticalVolumeTarget Statistical Volume StatisticalVolumeTarget
Target
45 DP_SupplyPlanUnitTarget Supply Plan Unit SupplyPlanUnitTarget
Target
46 DP_SupplyPlanValueTarget Supply Plan Value SupplyPlanValueTarget
Target
47 DP_UnconstrainedDemandUnitTarget Unconstrained UnconstrainedDemandUnitTarget
Demand Unit Target
48 DP_UnconstrainedDemandValueTarget Unconstrained UnconstrainedDemandValueTarget
Demand Value Target
49 DP_UnderloadedConstraintsTarget Underloaded UnderloadedConstraintsTarget
Constraints Target
50 DP_WIPInventoryTarget Work In Process WIPInventoryTarget
Inventory Target
51 DP_WIPPeriodsofCoverageTarget Work in Process WIPPeriodsofCoverageTarget
Periods of Coverage
Target
The list of Targets should be defined in the Baseline scenario. If they are defined in a different scenario
the Global Setting “Annual Plan target scenario” needs to be updated to reflect the correct one
otherwise you will get unexpected results in the Corporate Metrics scorecard:
In addition to the above variables, two more variables exist in the Application Variables worksheet of
the Application Settings workbook that set the Warning Limit and Critical Limit default values that are
used for alerting.
On install the default values are set as follows but can be overridden in the S&OP Annual Plan workbook
on the Settings worksheet. During the integration if the default values need to be adjusted navigate to
the Application Variables worksheet within the Application Settings workbook and edit the values as
needed. Out of the box these thresholds are not exposed in the pre‐defined resources; however, they
can be unhidden within any of the workbooks/widgets where Annual Plan targets are shown.
4.1.2.2 Macros
No macros are used in the various S&OP resources.
4.1.2.3 Automation
The following Automation resources are provided with this application:
Name Type Description Expected Frequency

Run Closed Loop Within Scheduled Task Calls Closed Loop Within Prior to Publish S&OP Cycle
Cycle Script Cycle Script
Closed Loop Within Cycle Script Modifies OriginalRecordId on As per Scheduled Task
new ScheduledReceipt
records, performs cross
scenario update of Consensus
Demand Plan to
IndependentDemand table in
Baseline scenario, and
creates Business Messages in
RI to send new/changed
records to ERP system.
Run Data Reconciliation Scheduled Task Calls Data Reconciliation Prior to update of S&OP
Within Cycle Script Within Cycle Intermediate scenario
Data Reconciliation Script Compares S&OP Intermediate As per Scheduled Task
Within Cycle scenario to Baseline,
identifies duplicate records
and deletes duplicates from
S&OP Intermediate scenario.
Start S&OP Cycle Toolbar Button Mechanism for beginning First day of S&OP Cycle
S&OP cycle, it creates and
shares with S&OP Team /
updates the S&OP Candidate
scenario
Start S&OP Sub‐Cycle Toolbar Button Mechanism for beginning Ad hoc when necessary
S&OP cycle that is during an
existing cycle, it creates and
shares with S&OP Team /
updates the new Sub‐cycle
scenario

Publish S&OP Cycle Toolbar Button Mechanism for ending S&OP Last day of S&OP Cycle
cycle, it commits the S&OP
Candidate scenario, updates
the Current S&OP scenario
and creates the S&OP Archive
YYYYMMDD scenarios
The following Automation tasks need to be created to support this application:

Delete Assumptions Scheduled System Defined for a rolling period of Daily
Task time it prunes data in the
Assumption table for any
data meeting agreed‐upon
business conditions (eg.
created greater than ‘n’
calendar periods ago and no
longer effective). Actual
deletion rules to be
determined by business rules
at deployment.
Run in S&OP Intermediate
using the DeleteData
command
4.1.2.4 Pre‐defined Filters

There is a standard filter that is shipped with RapidResponse called “NPI Items”. It is described as
follows:
This filter can be used to focus on items that are newly introduced, or are going to be introduced.
The filter expression is defined as:
HAS PartCustomers [Part.PrimaryPartSource.FirstEffectiveDate >= MRPDate ‐ 1

EffectiveDisaggregationCalendar]
The idea of this filter is to list Part (or PartCustomer) records that have not yet made it into production.
The filter expression is designed to look for parts where the sourcing data has not yet come into effect.
This may not be an appropriate test. For example, if the process for defining these new parts is to create
PartSource records with effectivity that runs from past to future, then the filter expression may need
some other means to identify these parts.
Careful thought needs to be put into what the expression will look like if it needs to be redefined to
meet the customers need. Ideally, NPI parts should be identified by a discrete code value in a field (no
wildcards), preferably in a referenced table.
4.1.2.5 Hierarchies
Hierarchies are used extensively throughout the S&OP, Demand Planning, Aggregate Supply Planning
and Capacity Planning Applications to allow the entry of data values at a specific intersection which then
disaggregates to the lowest level, PartCustomer. As such any hierarchies defined must be compatible
with (have a direct path to) the PartCustomer table.
On install the following hierarchies are available to users:
The Constraint hierarchy consists of the following levels:
 Site
 Constraint Group
 Constraint Name
The Constraint Region hierarchy consists of the following levels:
 Region Group
 Region
 Constraint
The Customer hierarchy consists of the following levels:
 Customer Group
 Customer Name
The Customer Region hierarchy consists of the following levels:
 Region Group
 Region
 Customer
The Manufacturing Region hierarchy consists of the following levels:
 Region Group
 Region
 Site
The Product hierarchy consists of the following levels:
 Product Family (ProductGroup1 field on Part table)

 Part
The Supplier hierarchy consists of the following levels:
 Supplier Group
 Supplier
 Part
The Supplier Region hierarchy consists of the following levels:
 Region Group
 Region
 Supplier
If additional hierarchies are requested by the customer, they can be defined as required; however, if the
intended use is within the context of S&OP or related processes, there needs to be a direct link to the
PartCustomer table to support disaggregation logic.
Warning: do not use concatenated values. If you do, some disaggregation sheets will not work properly
if the sheet displays the “level below” the selected hierarchy. Also the system cannot use the
referenced table to enhance query performance. If you need a user‐friendly value, add a custom field
and do the concatenation in the data load or with a data change
4.1.2.6 Collaboration and Responsibility

Collaboration is achieved through the creation and sharing of scenarios with all responsible parties to
review and determine if the necessary action is acceptable. Therefore in order to collaborate, one first
needs to be able to determine who is responsible for the parts or constraints that require review. To
achieve this, a user must be assigned to a particular part or constraint to be the Responsible individual.
A simplified responsibility model was introduced in 2014.4. A new type of resource is available called
Responsibility Definitions. This resource makes it possible for non‐administrators to assign responsibility
for data. Users or groups can be granted permission to create and share responsibility definitions, the
same as other RapidResponse resource types.
Note that to use this new type of resource, users must be able to view the responsibility scenario. It is
therefore recommended that a responsibility scenario is selected as one that is kept current and can be
shared with all users involved in creating responsibility definitions or assigning responsibility for data.
The responsibility model allows any workbook author to include responsibility information in workbook
columns, and format it so that users can easily contact the person responsible for data. This way, rather
than relying on an administrator to build a responsibility workbook to define which data changes are
important, users can decide on a case‐by case basis what is important.
4.1.2.6.1 Specifying the Responsibility Scenario

The responsibility scenario is used to populate the list of values for each field when users assign
responsibility for data. The user must have at least View access to the responsibility scenario. By
default, Enterprise Data (root) is the responsibility scenario, however it is advisable to specify a different
scenario, such as Baseline, based on the following conditions:
 It must be a scenario that everyone who needs to use responsibility definitions can be given
View access to.
 It must be a scenario that is kept reasonably current, so that when a new record is added,
responsibility for that data can be assigned.
 Choose a permanent scenario to reduce the risk of the responsibility scenario being accidentally
deleted.
System administrators can change the responsibility scenario in the Administration pane > System
Settings > Global Settings, listed in the Responsibility scenario under the Scenarios category:
4.1.2.6.2 Responsibility Definitions

Responsibility Definitions that are accessible to a user are used to view responsibility assignments, or to
assign responsibility data to either themselves or other users.
Ten Responsibility Definitions are installed out of the box:
Each Responsibility Definition is configured with a Base table, and Responsibility table(s) are identified.
For example, the Buyer Responsibility Definition Base table is the Part table, and has its responsibility
table configured as the BuyerCode table:
Multiple Responsibility tables can be identified if multiple variables exist on which to set Responsibilty.
For example, the Sales Responsibility Definition, based on the PartCustomer table, is configured to be
associated with four responsibility tables:
The standard data model contains a UserId field on the PlannerCode and BuyerCode tables that is a
string data type. The Part table references both of these tables, while the Constraint table references
the PlannerCode table. The field on these two tables allows you to assign a user to a specific Planner
code or Buyer code.
4.1.2.6.3 User Set Up For Authoring Responsibility Definitions

In order for a user to be able to author and share responsibility, they must have the appropriate
permissions set by an Administrator. Permissions are set in User or Group Properties > Permissions, as
with other resources:
Responsibility definitions can be shared with users to create or edit responsibility assignments.
4.1.2.6.4 Assigning Responsibility

Responsibility is assigned through the Responsibility Definition. To create a new responsibility
assignment, select the data you wish to assign, then select a user to be responsible for the data.
Responsibility assignments are listed in the Assignments table, which can be seen when the
Responsibility definition is opened.
The Resources workbook now contains a Responsibilities worksheet where all responsibility definitions
are listed.
A Responsibility Roles worksheet has also been added to the RapidResponse Administration workbook.
This worksheet is used to map Responsibility definitions to variables that are used in predefined
resources.
4.1.2.6.5 Collaboration
Once responsibility is assigned, the name of the responsible person can be rendered in a worksheet
using the RESPONSIBILITY function and by formatting the column to ‘Display as User’.
When the user is displayed in a worksheet, you have the ability to hover over the name to display a
contact card with pertinent information about the user, such as, email address, phone number, etc.
There is also the ability to ‘Send a Message’ through the displayed contact card. The message is sent to
the user’s message center and can be sent to the user’s email address if they choose to do so.
To send the message to an email address the individual user sets it up in their user options (assuming
the system administrator has configured their install to send email messages).
In order to initiate collaboration with the users, one would create a scenario and share it with the
appropriate responsible users and include a message about what data they require assistance/feedback
for. To initiate this collaboration with multiple users directly from the worksheet, the user does a multi‐
select on the names in the Responsible column, right clicks and selects “Share Scenario…”.
On install, responsibility is exposed and collaboration through user name is present in a number of
workbooks. In order to view resources where responsibility is exposed and collaboration through user
name is present, use the Tools > Search Resources function, and search for “Responsibility” in
expressions.
Of importance to note when identifying collaborators is that care should be taken to ensure that
multiple collaborators are not working on resolving the same part/component issue, as their changes
could conflict with each other.
The selected collaborators will receive notification that a collaboration scenario has been shared with
them, requiring them to review the data and possibly make changes to it in order to support the
request. Each collaborator should create a child scenario of the parent collaboration scenario in order
to simulate any required actions. If the issue is resolvable, the collaborator should commit the private
scenario with data changes and select to accept the collaboration request, while including any message
required to the requestor.
If the issue cannot be resolved, the collaborator would not commit their private scenario, but would
instead select to reject the collaboration request, including any message required to the requestor. In
this manner, the requestor can keep track of the collaboration progress and which changes can be
made. The private scenario can be deleted once it is no longer required.
If the collaboration was successful and the required changes can be implemented, the collaboration
owner will commit the collaboration scenario into its parent. This should only be done when it is
confirmed that the required actions will be implemented, as the changes may be sent via closed‐loop to
the transactional ERP system.
If the collaboration was unsuccessful and the required changes cannot be implemented, the
collaboration owner will change the status of the collaboration scenario to the appropriate status. Once
the unsuccessful collaboration scenario is no longer required, it should be deleted.
The collaboration scenario owner can decide how to be notified of changes and updates throughout the
collaboration process. This can be done when sharing the scenario by selecting the appropriate check‐
boxes in the “Notify me when” section on the Notify tab of the Share Scenario dialog. It can also be
changed throughout the collaboration process, if required, by accessing the Share Dialog at any time.
The following describes the functionality of each selection and the bulleted points below identify where
the messages appear:
 Anyone responds – responses will be logged in the Scenario Properties Activity Log.
 Everyone has responded ‐ responses will be logged in the Scenario Properties Activity Log.
 Anyone modifies data in this scenario—sends a message to your Message Center when anyone
modifies data in the scenario.
At any time, the collaborators can send a note to the scenario owner indicating progress or issues
arising. This can be done by accessing the collaboration scenario properties and Responding via the
toolbar icon.
An Activity report can also be distributed to highlight scenario changes and activity, by accessing the
collaboration scenario properties and clicking on the ‘Distribute Activity Report’ icon.
4.1.2.7 Miscellaneous
Below is a list of other configuration points to be aware of for this application:
4.1.2.7.1 Configuring for Consensus Forecast and DemandType

DemandType
It is critically important that the DemandType on the PartCustomer be set to something other than null
for all PartCustomer records that are going to calculate a consensus forecast. If this is not done, then the
data change in the “Closed Loop Within Cycle” will fail.
It is equally important that the DemandType used for these PartCustomer records not be used for
imported DemandOrders (imported IndependentDemand records) nor used as any of the
AllocationDemandType values in the SupplyType table. That is, you should see no usage of these
PartCustomer DemandTypes in any scenario above the Baseline scenario for anything except
PartCustomers. In the Baseline scenario and any descendents, you will see them also used on
DemandOrders (IndependentDemand) but only after the data change in the “Closed Loop Within Cycle”
has run and not for any other IndependentDemands. That is, these demand types should only ever occur
in DemandOrders where the Order.Id starts with “CF: “. In no scenario at all should these demand types
show up as dependent demand. The reason there must not be any overlap in the use of these demand
types is that we need to ensure that double‐driving the demand does not happen in either Baseline nor
in the S&OP scenarios by turning them on and off appropriately. All of the other demand types used
must not be touched between the scenarios (they should either drive demand or not, the same way in
both scenario trees).
Also related to avoiding the double‐driving of demand, it is vital that in the S&OP Intermediate scenario
and all descendent scenarios, these PartCustomer DemandType controls all have the ProcessingRule set
to Ignore. In this scenario tree, we want all of the consensus forecast to drive from ForecastDetails and
not from the IndependentDemands that were written to Baseline and subsequently updated into S&OP
Intermediate. For exactly the same reason, however, it is required that these same PartCustomer
DemandType controls all have the ProcessingRule set to SalesForecast in all of the other (non‐S&OP)
scenarios [at least in Baseline down excluding the S&OP branch of scenarios].
It is important to understand that the PartCustomer DemandTypes are always treated as if the
DemandType.ProcessingRule = ‘SalesForecast’ when consensus forecasts are calculated. Therefore,
setting the ProcessingRule to Ignore in the S&OP scenarios for these PartTypes will not prevent them
from driving consensus forecast and real forecasted demands there.
In any of the cases where the consensus forecast is expected to be spread differently than the applicable
DisaggregationCalendar (either defined in the PartCustomer or, if null there, defined in the
SOPAnalyticsConfiguration), it is important that the DemandType.SpreadRule is set to None in the
Baseline scenarios and set to Spread in the S&OP scenarios. This is required because the data change in
the “Closed Loop Within Cycle” will create the IndependentDemand records in the Baseline scenario
already spread and we don’t want to try to spread them again in the Baseline. The selected
SpreadProfile does not need to be different in the scenarios.
HistoricalDemandCategory
The double‐driving forecast demand problem just discussed combined with the fact that PartCustomer
DemandTypes are always treated as if the DemandType.ProcessingRule = ‘SalesForecast’ when
consensus forecasts are calculated, has an implication on the settings of the HistoricalDemandCategory
between Baseline scenarios and S&OP scenarios. We need to ensure that calculated consensus forecast
does not occur in the Baseline scenarios but that it does occur in the S&OP scenarios.
The normal assumption is that there will be no non‐Target ForecastDetail records in any non‐S&OP
scenario. If this assumption is true, then nothing more needs to be done. However, if ForecastDetail
records are brought into RapidResponse at any scenario above the S&OP scenario and the
Header.Category.Type.ProcessingRule for these records is one of Forecast, ForecastOverride,
RebalancingAdjustment or RebalancingForecastOverride, then steps must be taken to prevent them
from producing consensus forecast in the Baseline scenarios but allowing them in the S&OP scenarios.
If the ForecastDetail records in the non‐S&OP scenarios have a Header.Category.Type.ProcessingRule of

only Forecast, you can effectively disable them in the non‐S&OP scenario by setting the
ConsensusForecastWeight to zero and greater than zero in the S&OP scenarios as long as there are no
overrides provided in the HistoricalDemandHeader or HistoricalDemandHeaderTimePhasedAttributes.
However, a safer approach is to completely disable these categories outside of the S&OP scenarios by
changing the HistoricalDemandCategoryType ProcessingRule from anything with a value of Forecast,
ForecastOverride, RebalancingAdjustment or RebalancingForecastOverride to None (only in the non‐
S&OP scenarios). In the S&OP scenarios these HistoricalDemandCategoryType records will be the correct
ProcessingRule of Forecast, ForecastOverride, RebalancingAdjustment or RebalancingForecastOverride.
The following table describes these setting as required:
Table and Field In scenarios above S&OP In S&OP Intermediate and all
Intermediate (Enterprise Data, descendant scenarios (Current
Baseline, etc.) S&OP, S&OP Candidate, etc.)
For all DemandType records used by PartCustomer records
(should never include DemandType records used by DemandOrders where the Id does not start with
“CF:” nor any that have SupplyTypes)
ProcessingRule SalesForecast Ignore
SpreadRule None Set as required for the
Consensus Forecast spreading
beyond the disaggregation
calendar.
For all HistoricalDemandCategory records that could be used to produce a Consensus Forecast in the
S&OP scenarios but have ForecastDetail records in the Baseline scenario. The Type ProcessingRule in
the S&OP scenarios would be one of Forecast, ForecastOverride, RebalancingAdjustment or
RebalancingForecastOverride but there are ForecastDetail records being imported above the S&OP
Intermediate scenario.
Type.ProcessingRule None Forecast, ForecastOverride,
RebalancingAdjustment or
RebalancingForecastOverride as
required.
Or, alternatively… 0.0% > 0.0%
ConsensusForecastWeight (but only for those where the

if the Type.ProcessingRule is Type.ProcessingRule is Forecast).
Forecast
4.1.2.7.2 S&OP Dashboards

The consultant will need to remove certain widgets for the role based dashboards if the customer has
not purchased the related application, otherwise the widget will not render any data. For example, if the
Capacity Planning application is not purchased the Key Constraint Utilization widget on the Corporate
Metrics tab of the role based dashboards should be removed.
4.1.2.7.3 Workbook Links

On install the workbook links off of the Part and Reference Part fields are no longer set up. This should
be reviewed with the customer to come to an agreed upon list of links to be made available for these
fields.
4.1.2.7.4 User Set Up

The user experience for each Application is that upon login the user’s relevant Task Flow and Dashboard
is opened. In order to enable this, when performing the user set‐up in the deployment each user needs
to have the “On sign in” checkbox enabled (found at the bottom of the Resources tab of the User
Properties dialog) and the appropriate task flow selected. The first step in each task flow is to open the
appropriate dashboard.
For example, users in the Process Owner role would have the S&OP High Level Process – Process Owner
task flow selected to open on sign in as shown below:
In support of the S&OP Application, Users in the following groups should have the task flow noted below
set to open on sign in:
 Executives: S&OP High Level Process – Executive

 Demand Planners: S&OP High Level Process – Demand Planner
 Finance: S&OP High Level Process – Finance
 Sales: S&OP High Level Process – Sales
 Marketing: S&OP High Level Process – Marketing
 Supply Planners: S&OP High Level Process – Supply Planner
 Inventory Planners: S&OP High Level Process – Inventory Planner
 Operations: S&OP High Level Process – Operations
 S&OP Team: N/A
 S&OP Process Owners: : S&OP High Level Process – Process Owners
If the customer has purchased other applications in addition to S&OP, then the task flows noted in the
documentation for the individual application should override what is described here.
4.1.3 Control Table Configuration

4.1.3.1 SOPAnalyticsConfiguration
This table supports some of the key S&OP disaggregation and forecasting analytics, and is used to set up
S&OP parameters for disaggregation and statistical forecasting. It was introduced to replace some key
statistical forecasting and disaggregation pluggable functions. As a result, some profile variables that
were used prior to 2014.4 are no longer used, and are replaced by fields in this table. Note however,
that the “old” behavior is still available to existing customers for backward compatibility.
There is no Control Set reference, therefore there is no corresponding worksheet in the Control Sets
workbook, but it can be accessed in the Control Tables workbook.
4.1.3.2 HistoricalDemandCategoryType
This table supports S&OP and is used to define how demand data associated with a given
HistoricalDemandCategory is processed.
Note that the AggregationRule and UnitType fields only function if the ProcessingRule is “Target”.
4.1.3.3 HistoricalDemandCategory
This table is used to categorize values in both the HistoricalDemandActual and HistoricalDemandSeries
tables, identifying categories of forecast demand (sales, customer, stat) as well as categories of actual
demand (shipments, consumption).
The categories of demand must be defined here. There are a standard set of categories defined with a
variety of types, which would be defined in the previous section. Different types have differing
AggregationRule, ProcessingRule and UnitType settings. It is the ProcessingRule that typically defines
the purpose of the category. It can be set to:
• “None”: Use this to ignore standard Target categories that you are not using. This will keep them out
of workbooks and drop‐down lists.
• “Actual”: This is used for storing historical demand actuals. Values in this category can be used in
calculating the statistical forecast.
• “Target”: This is used for defining target metric values against which the S&OP annual plan is
measured.
• “Forecast”: This is used for storing streams of forecast demands or forecast adjustments. Values in
this category can be used in calculating the consensus forecast.
• “ForecastOverride”: This is used for specifying values to override the calculated consensus forecast.
• “ReBalancingForecastOverride”: This is used for specifying values to override the calculated consensus
forecast based on demand and supply balancing.
“Target” is of interest to Annual Planning.
The AggregationRule of “Average” or “Sum” is only applicable to targets, while “None” covers
everything else.
The UnitType (“Quantity” or “Value”) is, similarly, only applicable to targets and determines if the target
is a currency or quantity. This will determine which field in the ForecastDetail and/or
HistoricalDemandSeriesDetail is significant (“Quantity” or “Value”) for the target.
The HistoricalDemandCategory record for targets also defines WarningLimit, CriticalLimit and an
associated DesiredResults value of either “High” or “Low”. These field values are only of significance to
target categories.
The HistoricalDemandCategory defines a default ConsensusForecastWeight number, used for

HistoricalDemandCategory values where the HistoricalDemandCategoryType.ProcessingRule =
“Forecast” which are used in the Consensus Demand Planning sub‐process of the Demand Planning
Application. This field must be set to the default weight that this forecast category should contribute to
the calculated consensus forecast. It should be a number from 0 to 100%. Zero means that, by default,
this category does not contribute to the calculated consensus forecast. Specific PartCustomer/Category
values can override this in the HistoricalDemandHeader. Please note that the ConsensusForecastWeight
is only relevant for historical demand categories where the Type.ProcessingRule is Forecast.
ProcessingRules of ForecastOverride, RebalancingAdjustment and RebalancingForecastOverride will all
assume a weight of 100% regardless of the ConsensusForecastWeight value specified. ProcessingRules of
Actual, None and Target are not able to produce any consensus forecast (weight = 0%).
On install there are 51 Target variables defined in the Application Variables worksheet of the Application
Settings workbook During Base Data Integration the five Historical Demand Categories shown in the
screen shot below need to be created to match the measurements listed in section 1.3 of this
document (see screen shot below for list and default settings) in order to the dashboard widgets to
reflect Annual Plan targets. These targets will show up in the drop list of the Annual Plan Category
variable found in the S&OP Annual Plan or S&OP Constraint Annual Plan workbooks.
Should you require additional targets to be defined for the deployment, you will need to create the
categories in the Historical Demand Category worksheet of the Control Tables workbook. Ensure that
the Type is changed from “None” to one that reflects a HistoricalDemandCategoryType of “Target”,
“TargetSum”, “TargetAvg”, or “TargetValue” to get the appropriate ProcessingRule, AggregationRule
and UnitType.
4.1.3.4 AssumptionType and AssumptionStatus

The required Assumption Types (Categories) and Statuses are listed below.
Assumption Types (labeled Category in the dialogs and reports):
 Finance: Finance Assumption

 Marketing: Marketing Assumption
 Operations: Operations Assumption
 Sales: Sales Assumption
 Inventory: Inventory Assumption
Assumption Statuses:
 Closed
 Open
There is no pre‐defined application resource installed that allows you to edit, delete or add these values
and they are not auto‐created. If you need to add/change them, then you will need to create a
worksheet on the AssumptionType and AssumptionStatus tables.
4.1.3.5 PartType
All Parts for which you require consensus forecast to be generated in S&OP, the Part Types loaded must
have a ProcessingRule of either “MPS” or “MPSConfig”, otherwise the consensus forecast cannot be
generated.
4.1.3.6 AggregatePartCustomerType
Control table added in 2014.4 SU2 to enable or disable records in the AggregatePartCustomer table for
processing when determining disaggregation rates.
Fields of significance include:
 ProcessingRule: indicates whether AggregatePartCustomer records that belong to this type are
used in generating disaggregation rates; can be set to “Ignore” or “Use”
In order for a given AggregatePartCustomer value to be used in calculating forecast disaggregation rates,
it must reference an AggregatePartCustomerType record that has a ProcessingRule set to “Use”.
4.1.3.7 Data Model Defaults
4.1.4 Detailed Data Requirements

4.1.4.1 Annual Plan Targets and Settings
Annual Plan target values can be set using the S&OP Annual Plan workbook. The Annual Plan worksheet
edits the ForecastDetail records for each appropriate category where the category Type.ProcessingRule
= 'Target'.
The Settings worksheet is actually editing the HistoricalDemandCategory record itself for those
Type.ProcessingRule = “Target” categories. Here is where the WarningLimit and CriticalLimit are set for
each target category.
4.1.4.2 Part
If the parts are going to include supply planning of any sort then all the supply policy fields must also be
populated. Reference the MPS and Aggregate Supply Planning Applications for those requirements.
 All Part Types loaded for this must have a ProcessingRule of either MPS or MPSConfig in order
for the consensus forecast to be generated.
 In order to use any of the currency disaggregation or reporting, it is important to populate the
AverageSellingPrice.
 If the part is also going to load backlog (SalesActuals) with forecast consumption of the
consensus forecast, then the following fields need to be populated:
o DemandTimeFence
o BeforeForecastInterval
o AfterForecastInterval
o SpreadForecastInterval
 PartSolution.Part Class: This field is used to classify a part. The part classification is used to help
determine if the proper planning, safety stock and replenishment strategies are set based on the
category of part. It is an enum list field found on the PartSolution table referenced from the Part
table. Valid values are: None, FinishedGoods, RawMaterial, WorkInProgress. It is used to classify
inventory in the ‘Part Class Value’ widget found on the Inventory Planner dashboard.
 PartSolution.Part Strategy: This field is used to identify the manufacturing strategy of a part (eg.
Make‐To‐Stock, Make‐To‐Order, Assemble‐To‐Order). The strategy is used to help determine if
the proper planning, inventory, sales, and supply chain strategies are set based on the
manufacturing strategy of the part. It is a string field found on the PartSolution table referenced
from the Part table. If the customer ERP system does not contain this information it is expected
that it would be maintained by users directly in RapidResponse.
 PartSolution.KeyPart: This is a Boolean field to identify a Part as being a Key or Critical part. Key
Parts are focused on in the S&OP analysis as they have pertinent limitations (long lead times,
single sourced, etc.) to the long term plan.
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.
4.1.4.3 PartSource, Source and Supplier

Although supply planning is optional for this process, the Parts should all have valid PartSources defined
in order for the consensus forecast to be generated.
As mentioned in the section “Pre‐defined Filters”, the effectivity date range of PartSource records can
be significant if the “NPI Items” filter is to be used. In particular, this filter assumes that NPI part records
can be identified by the first effective PartSource (PrimaryPartSource) having an EffectiveInDate value
that is on or after the system MRPDate minus 1 EffectiveDisaggregationCalendar.
Beyond effectivity dates, the other PartSource fields are only of significance to the supply planning
process.
4.1.4.4 PartUOMConversion
If a user is disaggregating a target from a higher level with a particular UOM, that target value will only
end up disaggregating to part/customers (or aggregate 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.
Similarly, if the targets are revenue or cost targets, there must be either a Part.AverageSellingPrice
defined or effective records in the CustomerPrice table or a Part.StdUnitCost for the Part/Customers for
the targets to include those PartCustomers.
4.1.4.5 Customer
The base table for the S&OP process is the PartCustomer table. As such, customers must be defined as
well. 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.
It should be noted here that summary records in the PartCustomer table are typically handled by
creating a summary or decorated Customer Id. These special customers are usually maintained in
RapidResponse and not imported.
Also note that 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.
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.
4.1.4.6 PartCustomer
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.
This applies to any Parts that are going to be used as part of the Inventory Management application
within the S&OP Process context. If PartCustomer records do not exist, the High Inventory Violations
and Low Inventory Violations widgets on the Supply Planner dashboard will not render data. It should
be noted that for these instances the Customer can be defaulted to ‘NoCustomer’ or some other generic
value in order to reduce the number of records generated.
There are a few fields on the PartCustomer table with significance.
 ForecastItem: This is a specific reference to the ForecastItem that will manage the statistical
forecast for this PartCustomer. This is normally maintained by the Statistical Forecasting Setup
dialog (or equivalent) and is left pointing to the blank ForecastItem on import.
 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.
 BaseKey: If you can even see this LEAVE IT BLANK! ALWAYS!!!
 DemandType: This reference to the DemandType may be left out and set to null. It is nullable.
However, if the calculated Consensus Forecast is expected to be spread from the
DisaggregationCalendar to something smaller (Month to Week or Day), then you can set this to
a DemandType with the SpreadRule set to “Spread” and a defined SpreadProfile provided. The
recommended practice is to set this to a valid DemandType.
NOTE: Whatever demand type is assigned, the processing rule should be set permanently to
“Ignore” in the S&OP Intermediate scenario. 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. Setting the processing rule to “Ignore” for the PartCustomer.DemandType.Value in
S&OP Intermediate ensures that duplicate demand is not being driven within the S&OP scenario
tree.
 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 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.
 OrderPriority: You can override the Part.DefaultPriority for forecasts from this PartCustomer
here.
 MinimumShelfLife: You can override the Part.MinimumShelfLife for forecasts from this
PartCustomer here.
4.1.4.7 AggregatePartCustomer
This table was added in 2014.4 SU2 and can be used to group part customers together to define the
level at which forecast disaggregation occurs. Forecasts are generally created for part customers,
however in some cases it might not be necessary to generate a forecast to such a detailed level. For
example, a part’s forecast might be made at an aggregate level for all customers within a given sales
region, or for all parts belonging to a given product family. The AggregatePartCustomer table can be
used to support generating forecasts at higher levels, and is used to link aggregate PartCustomer records
with actual part and customer combinations that are also defined in the PartCustomer table. In cases
where is it not necessary to disaggregate forecast values to the detailed part and customer level, this
can result in fewer records being generated and improved database performance.
Generally, to model this situation, aggregate customer grouping values (eg. customer regions) should be
added to the Customer table (or Part table, if grouping Parts into aggregate groups). Next, appropriate
PartCustomer records should be added to identify the new levels at which the Part(s) should be
aggregated. Finally, the AggregatePartCustomer records can be added to associate the detailed or
component part‐customer combinations with the aggregate part‐customer combinations for which the
forecast should be generated. See the Analytic and Data Model Guide for more details.
Fields with significance:
 Aggregate: Reference to an aggregate PartCustomer record

 Component: Reference to part and customer combination being aggregated under the
PartCustomer value referenced in the Aggregate field
o Setting Aggregate=Component (rather than setting it to null) is the way to indicate that
the component is no longer aggregated.
 EffectiveInDate: Date when the part customer aggregation defined on the record becomes
effective
 Type: Reference to the control setting used to include or exclude aggregate part customers
from disaggregation calculations.
o Note that in order for a given AggregatePartCustomer value to be used in calculating
forecast disaggregation rates, it must reference an AggregatePartCustomerType record
that has a ProcessingRule set to “Use”.
4.1.4.8 HistoricalDemandHeader
This represents a unique combination of each PartCustomer and Category required. In fact, the keys are
the references to PartCustomer and to Category (HistoricalDemandCategory).
The Actuals and ForecastDetails fields are Vector set types.
 Actuals: Vector Set data type; represents the HistoricalDemandActual records associated with
the historical demand header
 ForecastDetails: Vector Set data type; represents the ForecastDetail records associated with
the historical demand header
o 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
Upgrade Note: If you have upgraded from RapidResponse 2014.2 (or earlier) to RapidResponse 2014.4
(or later) and in the process have 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.
The one non‐key field on this record is the ConsensusForecastWeight field. This is the override value for
the HistoricalDemandCategory.ConsensusForecastWeight. If this is set to anything other than ‐1.0, then
the category value has been overridden by this. This field should be defaulted to ‐1.0 and only
overridden for specific headers (Part/Customer/Category). 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.
There is a hidden BaseKey field. If you can even see this LEAVE IT BLANK! ALWAYS!!!
4.1.4.9 HistoricalDemandHeaderTimePhasedAttributes
The purpose of this table is to hold date‐effective overrides for the ConsensusForecastWeight for
specific Part/Customer/Category combinations (HistoricalDemandHeader). There are two keys on this
table along with 3 data fields. Note that this table is generally populated by the S&OP Demand Planning
Ratios workbook. Also note that, generally, a record is created for every DisaggregationCalender in the
worksheet bucket.
Note that records in this table are only applicable when the Header.Category.Type.ProcessingRule is set
to “Forecast”
 Header: This is the key reference to the HistoricalDemandHeader that we are providing date‐
effective overrides for.
 Id: This is a base key string that uniquely identifies this record within the set of records
referencing the same header. The value is not relevant but must be unique within the header.
As such, it is generally set to automatically generate a unique value on record creation.
 EffectiveInDate: The date on which this records ConsensusForecastWeight value becomes
effective. A string version of this might be a good choice for the Id field if you are importing
these records rather than just maintaining them in the S&OP Demand Planning Ratios worbook.
 EffectiveOutDate: The on which this records ConsensusForecastWeight value is no longer
effective.
 ConsensusForecastWeight: This is the final override value and is expected to be somewhere
from 0.0 to 1.0. Zero is a legitimate override to say that this header will not produce consensus
demand for this period. If you don’t want to see the override any longer, then delete the
record(s).
4.1.4.10 HistoricalDemandOrder
This is a new table introduced in the Solutions Namespace in 2014.2. The purpose of this table is to
capture HistoricalDemandActual Order information for calculating Order level on time delivery metrics.
It contains the following fields:
 Id: String key field containing the sales order number or order id.
 Site: Reference to Site table to indicate what site the order belongs to.
 CreatedDate: Date field for capturing the date the order was created in the ERP system.
4.1.4.11 HistoricalDemandActual
These records are associated with a particular HistoricalDemandHeader and they represent some form
of historical demand data, such as shipments. One category of these records is the normal source of
information for history in order to calculate the statistical forecast.
As of 2014.4, HDA records are stored in RapidResponse as a set of vector data on the
HistoricalDemandHeader table.
This table is not keyed. It is not expected that records will be deleted from here (except through a
regular table pruning task) and they cannot be referenced from another table.
There are 2 money fields. Normally, the money fields are expected to be provided in the currency of the
Header.PartCustomer.Part.Site.Currency reference, but you can change that.
 Line: This is an optional string field that may be populated if required by the customer for
reporting. It represents the order line of the sales order and it is not required for calculating on
time delivery as it is assumed the historical demand actual records are already the line level
detail.
 LineCreatedDate: This is an optional date field that may be populated if required by the
customer for reporting. It represents the date the sales order line was created and can be used
for calculating sales order lead times if required.
 Date: This is the primary date field effective for this record. It is the date associated with this
actual shipment. The date used should be consistent with the historical demand series dates.
For example, if the historical demand series dates represent the dates that parts ship from the
dock, then this date should be a dock departure date.
 CommitDate: This is the date the order is committed to ship. It is currently information‐only but
is available for determining some metrics.
 RequestDate: This is the date the customer requested the order to ship. It is currently
information‐only but is available for determining some metrics.
 Quantity: This is the number of parts in this actual shipment.
 Line Quantity: This is an optional field that may be populated if required by the customer for
reporting and it represents the sales order line quantity for the associated sales order line, it
does not always equal the Quantity value on the historical demand actual record.
 UnitPrice: The unit price for the historical demand. This value can be used to calculate revenue
associated with historical actual demand.
 UnitCost: The unit cost for the historical demand. This value can be used in calculating margins
where the margin per unit is calculated as the difference between UnitPrice and UnitCost.
 Route: This is an optional string field that may be populated if required by the customer for
reporting and represents the route the order took during shipping.
 Shipset: This is a string field indicating if the record was part of a shipset and is used in
calculating order level on time delivery.
 Order: This is a reference field to the HistoricalDemandOrder table described in the previous
section.
Note: If no HistoricalDemandActual records are included in the data, the Forecast Value Add widgets
need to be removed from the S&OP Dashboards as they will not render any data. This widget is found
on the Monitoring tab of each dashboard.
4.1.4.12 ForecastDetail
This table holds current forecast data at the detail level (after any disaggregation calculations have been
performed). Each record pertains to a given part, customer, and category combination, and shows
details such as the forecast quantity and date. Different types of forecasts can be stored in this table
such as the statistical forecast, sales forecast, marketing forecast, and so on.
The values shown in this table are based on aggregate values entered or maintained through various
resources in RapidResponse. For example, details of the statistical forecast are based on values
generated by the Save Forecast command in the S&OP Statistical Forecast workbook. Details of other
types of forecast are based on values entered in workbooks belonging to the related constituent group
(for example, values might be provided through the S&OP Marketing Forecast workbook, S&OP Sales
Forecast workbook, S&OP Finance Operating Plan workbook, and so on).
The ForecastDetail table is also used to store targets when the Header.Category.Type.ProcessingRule is
set to “Target”.
As of 2014.4, this table contains vector set data for records in the HistoricalDemandHeader table.
Changes to the ForecastDetail insert definition were introduced:
 The Date field is now a Key field

 The ID field is still, by default, set up as a key field.
 In relevant Application Resources, the “Always generate a unique value for the base key field”
and “Use value determined by RapidResponse” are checked
Upgrade note: If you have upgraded from RapidResponse 2014.2 (or earlier) to RapidResponse 2014.4
(or later) and the deployment has not converted the five standard tables to contain vector data, the
following differences exist in this table:
 The Date field is not a key field.

 The Header field is a reference, not an owning reference
Unlike the HistoricalDemandActual table, this table is keyed and we expect records to be created,
modified and deleted. We need to be able to uniquely identify records. The three keys defined are:
 Header: This is the key reference to the HistoricalDemandHeader which defines the
Part/Customer/Category combination.
 Date: The date of this forecast item. This date ultimately drives MRP if the forecast is used in
the ConsensusForecast.
 Id: This is a base key string that uniquely identifies this record within the set of records
referencing the same header. The value is not relevant but must be unique within the header.
As such, it is generally set to automatically generate a unique value on record creation.
There are two money fields that are normally expected to be provided in the currency of the
Header.PartCustomer.Part.Site.Currency reference. The other (non‐key) fields that need to be
populated on this table include:
 Quantity: The amount of this forecast. For Target records, this is the field that will be used if
the Header.Category.Type.UnitType is “Quantity”.
 Value: The monetary value associated with this forecast. For Target records, this is the field that
will be used if the Header.Category.Type.UnitType is “Value”.
 UnitPrice: Allows for a unique unit price to be specified for this forecast order. For example,
this might be used to reflect the price effective during a sales promotion or prices that vary by
customer. If a non‐negative value is provided here, it is always reported in the
EffectiveUnitPrice field (typically used for revenue calculations). If a negative value is provided
here, the unit price is calculated based on matching records in the CustomerPrice or Part tables.
 ProtectQuantity: Indicates whether the value in the Quantity field is modified when data is
edited in a grouped worksheet. This field is used in the Advanced Data Editing dialog box as part
of the expression that determines which records are not edited when a grouped worksheet is
edited. Valid values are:
o “Y”: the Quantity cannot be modified in summarized worksheets.
o “N”: the Quantity can be modified.
4.1.4.13 CustomerPrice
If prices are defined specific to customers for a part and/or time‐phased, then this information must be
provided in the CustomerPrice table. Note that if the price is not to be associated with a specific
customer (should be applied to all customers) but is still time‐phased, then the customer reference on
this table should be blank.
4.1.4.14 IndependentDemand and DemandOrder

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”.
Other demands that should not consume forecast may be loaded here as well with an
Order.Type.ProcessingRule of “Regular”.
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.
If the backlog is past due, then the date where it consumes forecast from can be either the DueDate of
the backlog or the DataDate depending on the PartType.ForecastConsumptionDateRule and the
Status.ForecastConsumptionDateRule.
4.1.4.15 BillOfMaterial
If forecast and consumption is happening across “planning BOMs”, then the MPSConfig type
BillOfMaterial records must be defined.
4.1.4.16 OnHand
OnHand is only required if you are doing supply planning.
4.1.4.17 ScheduledReceipt and SupplyOrder

Scheduled Receipts are only required if you are doing supply planning. If the Aggregate Supply Planning
application is not purchased, the Supply Plan must be provided as an input to the S&OP Process.
4.1.5 Closed Loop and Data Reconciliation

Each application has the ability to ‘close the loop’ on data to the Host system (ERP), i.e. Send data that is
created/edited within back to the host system automatically so that a user is not updating two systems.
The below table outlines the out of the box supported transactions by application, those that are
identified with an M indicates this is a transaction that must be manually entered in to the ERP system
vs those that are identified with an X which indicates it is a transaction supported through RI; those
marked with a C indicate that the data is used in different scenarios in the tree and updated through a
cross scenario update:
Transaction Type S&OP DP ASP CP IM IPO MPS OF SAM SC IPM

Purchase Req Create X X X X
Purchase Req/Order Change X X X X
Purchase Req/Order Cancel X X X X
Firm Planned Order Create X X X
Work Order Change X X X
Work Order Cancel X X X
Sales Order Date, Qty Change X
Consensus Demand Plan C
Inventory Transfer M M M X
Fixed Safety Stock Qty X X X
Change
Time Phased Safety Stock Qty M M M
Change
Inventory Disposition M M
Transfer Req Create X X X
Transfer Req/Order Change X X X
Transfer Req/Order Cancel X X X
Constraint Property Change M M
Master Data Changes (Safety M M
Stock Policy)
Master Data Changes X
(Planning Time Fence)
Master Data Changes (Planning M
BOM, Part Number of Days
Supply, Part Source Properties,
Order Priority)
Master Data Changes (Sales M
Order Date & Qty, Order
Priority, Delivery Route,
Delivery Destination, Ship Set,
Customer Request Date)
NOTES:
1) If integrating with SAP, Supply Types of ‘FPO’ and ‘NB’ must be created to support Firm Planned
Order create and Purchase Requisition create transactions.
2) In order to update Unit Price on ScheduledReceipts that are created and sent back to the host
system (Firm Planned Order create and Purchase Requisition create transactions above) the
value needs to be provided in the RAW value in the EBM. As such the consultant needs to create
a custom field to hold this information until such time as the ability to generate transactions
from worksheet payloads is available. In conjunction with this the two Business Message
definitions will need to be updated to use the custom field rather than UnitPrice as they are
defined out of the box.
As noted in the Scenario Structure section, these closed loop transactions are initiated from specific
scenarios.
Within an S&OP Cycle, upon publishing the S&OP plan the S&OP Candidate scenario is committed to the
S&OP Intermediate scenario which then updates the Current S&OP scenario. Prior to committing the
S&OP Candidate scenario a scenario compare is performed against the S&OP Intermediate scenario.
Those records that have changed (Consensus Demand Plan, Safety Stock Quantity, or Supply Plan
Records) are captured in the Closed Loop Within Cycle workbook. The Run Closed Loop Within Cycle
Script Scheduled Task is initiated by the Process Owner prior to them publishing the S&OP Cycle. The
Closed Loop Within Cycle script performs three actions:
1) Modifies the OriginalRecordId on newly created scheduled receipt records (this is used for
reconciliation purposes which is discussed further down in this section);
2) Performs a cross scenario update of the Consensus Demand Plan records into the
IndependentDemand table in the Baseline scenario (this is used as the demand to drive
requirements for non‐S&OP applications) and;
3) It triggers RI (Rapid Integration) transactions to be sent back to the host system for
new/changed/cancelled ScheduledReceipts or modified Part.SafetyStockQty records. See figure
1 below.
Outside of an S&OP Cycle, prior to committing the Master Production Scheduling or the Order
Management scenarios a scenario compare is performed against the Baseline scenario. Those records
that have changed (Purchase Requisitions/Orders, Work Orders, Sales Orders, Transfer
Requisitions/Orders, Inventory Transfers, Safety Stock Quantity, or Demand Planning Parameters) are
captured in the Closed Loop Outside Cycle Order Management workbook, Closed Loop MPS workbook
or Closed Loop OF workbook, depending on the application(s) purchased. The Closed Loop Outside
Cycle Order Management Script and Closed Loop MPS Script are scheduled to run on a pre‐determined
schedule depending on the scenario prior to the scenario commit in to Baseline. These scripts perform
two actions:
1) Modifies the OriginalRecordId on newly created scheduled receipt records (this is used for
reconciliation purposes which is discussed further down in this section) and;
2) It triggers RI (Rapid Integration) transactions to be sent back to the host system for
new/changed/cancelled ScheduledReceipts, change/cancelled Sales Orders, modified
Part.SafetyStockQty, new Inventory Transfers, or modified Demand Planning Parameter records.

See figure 2 below.
Those transactions marked as ‘M’ or ‘Manual’ are identified to the user through five workbooks: Manual
Closed Loop Constraint – identifies constraint property edits; Manual Closed Loop Demand Planning –
identifies planning BoM edits; and Manual Closed Loop Inventory Planning – identifies order policy,
inventory disposition and safety stock policy edits; Manual Closed Loop MPS – identifies planning BoM,
Number of Days Supply, Part Source properties, Order Priority edits; and Manual Closed Loop OF ‐
identifies independent demand record edits. If the edited records identified in these workbooks are not
manually entered in to the ERP system prior to the next Data Update, the changes will be lost.
For newly created records that are sent back to the ERP system via RI transactions the records created in
RapidResponse do not exist in the host system until they are sent via RI; therefore, there needs to be a
way to know which records those are once inserted into the ERP System so duplicate records do not
result on the next Data Update in to RapidResponse. In order to identify the record a concatenation of
the RapidResponse Record Id + Date is copied into a field called OriginalRecordId on the applicable table
and is sent on the outbound transaction.
This OriginalRecordId needs to be kept on the record when it is imported into the ERP system therefore
it needs to be defined as a custom field in the host ERP system in every table that will have new records
created via closed loop feeds. Also in the case of creating a new Purchase Requisition or Firm Planned
Order, the host system needs to carry this OriginalRecordId info to the Purchase Order or Work Order if
it is being auto‐generated. Then the OriginalRecordId needs to be included in the data extract for the
inbound transaction. Once the data update is performed reconciliation within RapidResponse is
completed using either the Data Reconciliation Within Cycle or Data Reconciliation Outside Cycle
workbooks.
Within an S&OP cycle this reconciliation is done through a multi‐scenario compare between the Baseline
scenario and the S&OP Intermediate scenario. When the duplicate record is identified a command runs
to delete the record from the S&OP Intermediate scenario, then the S&OP Intermediate scenario can be
updated. See figure 1 above.
Outside an S&OP cycle this reconciliation is done through a multi‐scenario compare between the
Approved Actions scenario and the Baseline scenario. When the duplicate record is identified a
command runs to delete the record from the Baseline scenario, then the Baseline scenario can be
updated. See figure 2 above.
An important note to make about the closed loop and reconciliation processes is that there needs to be
clear definition of where planning/execution is done, RapidResponse or ERP system, otherwise
differences in planning policies, calendars etc. could cause unexpected results from closed loop
transactions.
More detailed information about the closed loop process offered in support of all applications is
outlined in the Closed Loop Process training course. It is mandatory that users implementing this
solution participate in this training course.
4.2 Data Integrity Requirements

The definition of the targets and the limits is not normally based directly on forecast data in
RapidResponse. Rather, it is usually defined by executives based on what they would like to or need to
achieve from a business perspective. The forecasts are then compared to those targets. As such, there is
no real method of checking if the targets loaded in RapidResponse are reasonable except by comparing
them to the evolving forecasts as part of the on‐going standard process.
One sanity check that might be useful (beyond just comparing the forecasts to the targets) would be to
ensure that there are, in fact, ForecastDetails records defined for the required set of target
HistoricalDemandCategory records and that the WarningLimit and CriticalLimit for those category
records are set reasonably:
 Absolute value is near or equal to zero but not exceeding 100.

 Both WarningLimit and CriticalLimit are positive.
 Absolute value of WarningLimit is less than the absolute value CriticalLimit.
The Data Integrity‐S&OP workbook can be used to monitor the accuracy of data that is supporting the
Sales and Operations Planning Application. Review the workbook and worksheet help for more detailed
information on the data integrity checks this resource performs.

Application Summary Document - Sales Operations Planning

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Application Summary Document - Sales Operations Planning

Uploaded by

Copyright:

Available Formats

RapidResponse

FOR INTERNAL USE ONLY

Web site: https://www.kinaxis.com

Copyright © 2016 Kinaxis. All rights reserved. Page 2 of 68

Document Revision History

Copyright © 2016 Kinaxis. All rights reserved. Page 3 of 68

 Set various financial targets and acceptable levels of variability

Copyright © 2016 Kinaxis. All rights reserved. Page 4 of 68

1.4 Roles and Responsibilities

Copyright © 2016 Kinaxis. All rights reserved. Page 5 of 68

Copyright © 2016 Kinaxis. All rights reserved. Page 6 of 68

Copyright © 2016 Kinaxis. All rights reserved. Page 7 of 68

Copyright © 2016 Kinaxis. All rights reserved. Page 8 of 68

Copyright © 2016 Kinaxis. All rights reserved. Page 9 of 68

Copyright © 2016 Kinaxis. All rights reserved. Page 10 of 68

Copyright © 2016 Kinaxis. All rights reserved. Page 11 of 68

Copyright © 2016 Kinaxis. All rights reserved. Page 12 of 68

Copyright © 2016 Kinaxis. All rights reserved. Page 13 of 68

Copyright © 2016 Kinaxis. All rights reserved. Page 14 of 68

Copyright © 2016 Kinaxis. All rights reserved. Page 15 of 68

The inputs for the Update Annual Plan sub‐process include:

The inputs for the Executive S&OP Meeting sub‐process include:

Copyright © 2016 Kinaxis. All rights reserved. Page 16 of 68

The outputs of the Update Annual Plan sub‐process include:

The outputs of the Executive S&OP Meeting sub‐process include:

2.1.3 Scenario Structure

Copyright © 2016 Kinaxis. All rights reserved. Page 17 of 68

Scenario Purpose Permanent? Shared? Modify/ Auto‐

Also contains Integrated Project Management Project Actuals (working

Child scenarios are committed into Baseline (Master Production

Updated on a scheduled frequency determined at integration. It is

Copyright © 2016 Kinaxis. All rights reserved. Page 18 of 68

Prior to update, this scenario is used for the Multi‐scenario comparison of

This scenario is not committed to its parent.

It is updated based on the publish S&OP cycle whose frequency is

Copyright © 2016 Kinaxis. All rights reserved. Page 19 of 68

This scenario is available on install and is permanent. This scenario is

Closed‐loop transactions will be executed out of this scenario prior to it

Committed into S&OP Intermediate on S&OP Cycle Publish, at the end of

Committing private scenario back into the S&OP Candidate scenario

It is likely that multiple levels of private scenarios exist under S&OP

Data Integration Server Recommendations

Copyright © 2016 Kinaxis. All rights reserved. Page 20 of 68

Copyright © 2016 Kinaxis. All rights reserved. Page 21 of 68

Application Process Name Type Com

Common Aggregate Supply Planning Data Integrity ‐ Material Workbook

Application Process Name Type Com

Common Demand Planning S&OP Sales Forecast Workbook

Common Demand Planning S&OP Statistical Forecasting Workbook

Common All S&OP Unit Variance Workbook

Application Process Name Type Com

Application Process Name Type Com

Application Process Name Type Com

Application Process Name Type Com

3.1 Metrics, Dashboards and/or Scorecards

 S&OP Process Calendar

3.1.2 Corporate Metrics Scorecard

3.2 Other Resources: Processes, Task Flows, Workbooks

 S&OP High Level Process – Finance

4.1.2 Configuration Points

No Variable Name Description Default value

No Variable Name Description Default value

No Variable Name Description Default value

The following Automation resources are provided with this application: