Application Summary Document - Master Production Scheduling

RapidResponse
Application Summary
For Master Production Scheduling
Revision: 1
Date: 28-Feb-2016
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 ......................................................................................................................... 5
1.2 Functionality................................................................................................................... 5
1.3 Measurements ................................................................................................................ 5
1.4 Roles and Responsibilities ........................................................................................... 6
2 - Business Processes .............................................................................................................. 8
2.1 Business Process Flow Diagram ................................................................................. 8
2.1.1 Inputs ........................................................................................................................ 22
2.1.2 Outputs ..................................................................................................................... 22
2.1.3 Scenario Structure .................................................................................................... 23
3 - Resources ............................................................................................................................ 26
3.1 Metrics, Dashboards and/or Scorecards ................................................................... 26
3.1.1 Dashboard ................................................................................................................ 26
3.1.2 Scorecard ................................................................................................................. 26
3.2 Other Resources: Processes, Task Flows, Workbooks ........................................... 27
3.2.1 Task Flows ............................................................................................................... 27
3.2.2 Workbooks ................................................................................................................ 27
4 - Integration Requirements ................................................................................................... 29
4.1 Data and Integration Requirements ........................................................................... 29
4.1.1 Database Scale ........................................................................................................ 29
4.1.2 Configuration Points ................................................................................................. 29
4.1.3 Control Table Configuration...................................................................................... 45
4.1.4 Detailed Data Requirements .................................................................................... 55
4.1.5 Closed Loop and Data Reconciliation ...................................................................... 61
4.2 Data Integrity Requirements ....................................................................................... 65
Copyright © 2016 Kinaxis. All rights reserved. Page 2 of 66

Document Revision History
Version Changes Author Date
1 Initial Draft for 2015.3SU6 Emily Fisk Feb‐2016

1 ‐ Introduction
This application covers Master Production Scheduling (MPS) in the context of daily/weekly planning
processes. This process assumes planning for the Finished Good level of the product structure. The
finalized Supply Plan generated within an S&OP cycle is used as a reference point for the MPS planning
process. Below is a list of Application interactions included in this application.
Application User Interfacing Data Touch Points

Aggregate Supply Master Schedulers need to disaggregate the supply Supply Plan
Planning plan.
Capacity Planning Master Schedulers need visibility into capacity when Constraints / CRP
analyzing the MPS, its feasibility and repressiveness
to change. CTP Calculation is needed to commit
orders.
Demand Planning Master Schedulers may need to disaggregate the Forecast / Independent
demand plan. Master Schedulers may be responsible Demands
for scheduling SO and consuming Independent
Demand Forecast. Master Schedulers may need to
provide feedback to Demand Planners on Material
not forecasted in the Demand Plan or EOL/NPI items.
S&OP Much of the MPS Process may require feedback into Supply Plan / Forecast
the S&OP plan especially if Capacity or material
constraints affect revenue.
Inventory Visibility to inventory targets, current levels, excess, Item master information /
Management obsolete and safety stock is required to make Source information, On hands,
decisions in MPS Scheduled Receipts, Demands
Scenario, Changes made in MPS could result in Closed loop Common infrastructure
Responsibility, actions to ERP or order fulfillment ‐ New orders,
Collaboration & changed orders, scheduling / commit of customer
Closed Loop orders. Collaboration between the different groups is
needed as well as Responsibility definitions to enable
the collaboration.
Order Fulfillment Master Schedulers commit orders. The Master Independent Demands
Scheduler needs to be in communication when
committing a customer order, allocating supply to
orders and coordinating EOL/NPI items.
Supply Action Master Schedulers need to work with the Material Dependent Demands /
Management Planners to expedite, de‐expedite and align Scheduled Receipts
material. They also may need to make changes to
item attributes directed by MS.

1.1 Objective
The objective of the Master Production Scheduling application is to establish a realistic plan of the
proper mix and production rate, in order to achieve operational goals, such as resource/machine
utilization, inventory targets and projections, and contractual negotiations with suppliers, while
supporting the Demand and/or Supply Plan.
The Master Production Schedule (MPS) is reviewed at the detailed part level. The MPS will drive the
production planning and purchasing functions to support the achievement of the MPS through the MRP
process. It is generated for the short term horizon (usually 1‐3 months depending on production lead
times) in weekly, sometimes monthly, buckets. The MPS looks to achieve a smooth demand signal for
production planning through spreading (month to week) or manual adjustments of unconsumed
forecast / sales orders. The finalized MPS is used as input for the Supply Plan in the next S&OP planning
cycle.
1.2 Functionality
The functional capabilities of the Master Production Scheduling application include:
• Material and capacity* constrained master scheduling

• Identification of gating material and capacity constraints* through multi‐level supply chains
• Visibility into demand driving supply decisions
• Firming of Planned Requirements
• Analysis of inventory projections versus targets
• Cross‐location inventory visibility
• Identification of MPS impact on key organizational metrics, such as revenue and inventory
values
• Simulation and collaboration to resolve gating issues
• Calculation of projected available balance (Available to Promise)
• Forecast consumption reporting and analysis
• Use of Planning BOMs and ability to configure changes
• Ability to adjust part planning parameters
• Ability to adjust sourcing parameters such as lead times and production lot sizes
• Ability to synchronize master schedule changes with ERP
• A waterfall view of MPS against Actual Production (including accuracy reporting)
*Requires Capacity Planning
1.3 Measurements
In addition to the standard corporate measures of revenue, margin, inventory value, and on‐time
delivery metrics associated specifically with master production scheduling, the following measures are
also included in the application’s out‐of‐the‐box dashboards. This allows for focused management of the
performance measures that are most applicable to the function at hand.

Measures presented in the Master Scheduler dashboard include:
MPS Risks
1) MPS Exceptions: A summary of the quantity of master production scheduling‐related
exceptions presented in the current master production schedule.
2) Late Revenue Caused by MPS Orders: A summary of the revenue that is expected to be late due
to late MPS parts. Only reports late revenue within the MPS Window. Only renders data for the
MPS parts for which the User is responsible. The amount of late revenue is plotted in the period
that the demand is due.
3) Constraints Impacting MPS: A summary of the quantity of MPS Parts that will be late due to
insufficient load available at a constraint. Only reports constraints that are causing lateness
within the MPS horizon. Only renders data for the MPS parts for which the User is responsible.
The constraint causing the highest quantity of MPS parts to be late will be represented on the
top row of the chart. Constraints Impacting MPS will only apply to constrained constraints.
There may be overloaded constraints that are “Load only” which will impact the actual
execution but won’t show up here. This also doesn’t reflect CRP capacity overloads.
4) Component Shortages Impacting MPS: A summary of the quantity of MPS Parts that will be late
due to late components. Only reports components that are causing lateness within the MPS
horizon. Only renders data for the MPS parts for which the User is responsible. The component
causing the highest quantity of MPS parts to be late will be represented on the top row of the
chart.
5) Component Shortages by MPS Start Date: A summary of the days to MPS start date that an
MPS part will be late, due to late components. Only reports components that are causing
lateness within the MPS horizon. Only renders data for the MPS parts for which the User is
responsible. The component causing lateness for the earliest scheduled build of the MPS part
will be represented on the top row of the chart.
Performance Metrics:
1) Master Scheduling Summary: A summary of the master production schedule for MPS parts, and
visual comparison of supply and demand within the current planning horizon. It is a graphical
representation of the Master Scheduling workbook at the family level in Summary form.
Stacked Bar represents the MPS Supply & Planned Orders. Lines represent the Demand and
Aggregate Supply Plan. Only reports Supplies within the MPS horizon.
2) Misaligned MPS Parts to Demand: A summary of the quantity of MPS Parts whose availability is
later than the required date. Reports MPS parts where the Supply DueDate is late to its Demand
Date within a defined tolerance.
3) MPS Attainment %: A summary of the count of on‐time MPS orders as a function of the total
count of MPS orders, represented as a %
4) Number of Constraints Overloads/Underloads: A summary of the count of constraints which
are either overloaded or underloaded, based on the load from the master production schedule.
1.4 Roles and Responsibilities
Role Responsibility
Master Scheduler Establishes the anticipated end item build schedule by disaggregating the supply

plan and planning supply orders to satisfy customer demand. The master
scheduler is responsible for establishing a plan to build the correct amount of
each Finished Good item at the best time for it to be built. Secondary goals
include minimizing inventory levels, maximizing productivity and maximizing
customer service levels. Collaboration will be required with multiple roles within
the organization.
Operations The Operations Planner manages the definition of constraints and can change
Planner capacity or recommend moving load to alleviate an overload or underload
condition. The Master Scheduler collaborates with the operations planner to
address capacity issues in the master schedule.
Material Planner The Material Planner manages the detailed plan for components and raw
materials going into the master scheduled item. The Master Scheduler
collaborates with the material planner to address material issues in the master
schedule.
Production Supervises, establishes and coordinates the production schedules in a factory
Planner environment. Ensures the flow of materials, parts and assemblies between or
within departments. The Master Scheduler will collaborate with the Production
Planner to ensure that scheduled production can achieve the Master Production
Schedule.
Inventory Planner The Inventory Planner will define ordering policies such as safety stock,
minimum/maximum ordering quantity, define targets level and will and control
the costs associated with the inventory. The Master Scheduler will collaborate
with the Inventory Planner to address inventory issues in the maintenance of an
achievable master production schedule, minimizing inventory but retaining the
desired customer service level.
Customer Service The Customer Service Rep (CSR) is responsible for communication with the
Representative customer, with respect to order information and commit dates. The Master
Scheduler will collaborate and communicate with the CSR to address supply
issues impacting customer orders.

2 ‐ Business Processes
2.1 Business Process Flow Diagram
The overview process flow below depicts the high level process flow related to Master Production Scheduling. Within this process flow, there
exist multiple sub‐processes, which are explained in more detail in the sections that follow. It should be noted that, while the “Aggregate Supply
Planning”, “Order Fulfillment”, “Capacity Planning” and “Inventory Management” business processes are depicted in the below process flows,
they are explained in detail in their own Business Process Flow documents. They are included here to show the relationship between these
process and business functions with those of the MPS process.

1. Start MPS Process: Each Master Scheduler will create a working private scenario that is based off of the 'Master Production Scheduling'
scenario.
2. Review and Adjust Planning Parameters: See detailed Adjust Planning Parameters Sub‐Process flow.
3. Align and Firm Up MPS: See detailed Align and Firm up MSP Sub‐Process flow.
4. Investigate Solutions to Resolve Issues: See detailed Resolve Issues Sub‐Process flow.
5. Finalize and Publish MPS: Each Master Scheduler should commit the working scenario to the 'Master Production Scheduling' scenario. An
automation chain should be created to
a. Capture the manual and automated closed loop transactions in the Closed Loop MPS and Manual Closed Loop MPS workbooks and
then
b. Commit Master Production Scheduling to Baseline.

Important to Note: Assume that even is a company does not buy Supply Planning or Demand Planning they input Supply Plan or Planned
Orders will align to demand plan.

1. Review Planning BOMs: Create a new private scenario that is based off of the working scenario created for the Start the MPS process.
Review current Planning BOM using the Planning Parameters workbook and Planning BOM worksheet.
2. Do Planning BOMs need to be edited?: If no skip to Step 4, otherwise go to step 3
3. Edit Planning BOMs: In the Planning Parameters workbook, in the Planning BOM worksheet, do one of the following:
a. You can add an new option by clicking Insert Record on the workbook toolbar
b. You can delete an existing option by selecting it and clicking Delete Record on the workbook toolbar and
c. You can edit option ratios by clicking the Planning BOM Option Ratios tab and editing the options. You can also adjust effective
dates and quantity from the Planning BOM worksheet.
4. Review Planning Parameters: In the Planning Parameters workbook, Part Properties worksheet, review the planning parameters
5. Do Parameters Need Editing?: If no go back to Master Scheduling process, otherwise go to step 6
6. Is this NPI / EOL item? If no skip to Step 8, otherwise go to step 7
7. Go to NPI / EOL / Engineering Change set up Process: In the BOM Analysis workbook, in the Indented BOM worksheet, review the Effective
In, Effective Out, and QuantityPer for both old and new part and review impact on excess inventory. If you determine that the effective
dates and quantities need to change, collaborate with others and follow the engineering change process that is established by your company
8. Can Master Scheduler make the Edit? Determine in Master Scheduler can edit the planning parameter or constraints, If not go to step 9,
otherwise go to step 10.
9. Collaborate with Responsible or Impacted Role: For planning parameters, go to Planning Parameters workbook, Part Properties worksheet
and click on the Responsible column and send message. For Constraints, go to Master Scheduling Workbook, Overloaded Constraint Details
worksheet and click on the Responsible column and send message.
10. Edit Planning Parameters: In to Planning Parameters workbook, make the appropriate changes:
a. In the Part Properties worksheet, edit the Number of days of supply or safety stock by clicking the value in the Safety Stock–
Quantity column. (It includes adding a range of coverage record to time‐phased safety stock in the Change Time‐Phased Safety
Stock worksheet and clicking Insert Record and
b. In the Sourcing Properties worksheet, edit any of the following parameters: Lot Size (Min, Max, Mult), Lead Time, Planning Time
Fence, Yield, and Effective dates, and
c. In the MPS Settings worksheet, adjust any of the following MPS Planning Windows for a part: Planning, Frozen, and Auto‐Firm.
11. Review constraints: Review the MPS orders for which you are responsible for master scheduling to determine if any overloaded constraints
are causing them to be late. In the Master Scheduling workbook select the following options from the workbook toolbar:
a. Overloaded Constraints is selected from the Show parts with list to display only the MPS parts that are impacted by an overloaded
constraint.
b. Available Date is selected from the Display by list to filter the MPS orders by their available date.
c. In the Overloaded Constraints row for a part, click the value in the period bucket that has the overloaded constraint and review the
overloaded constraint in the Overloaded Constraint Details worksheet.

12. Resolve overloaded constraint by pre‐building: You can review the constraint details to determine if you can pre‐build to resolve the
overloaded constraint. Pre‐building, which involves building early using available capacity, allows you to shift load from later, overloaded
periods. You can pre‐build MPS parts only if you haven't converted the planned orders to scheduled receipts. If you have determined that
the cumulative load usage for a constraint in a given period is under 100%, pre‐building might be a viable option if the constraint is
constrained and level‐load is enabled.
a. In the Overloaded Constraint Details worksheet, in the row that corresponds to the overloaded constraint, click the name in the
Overloaded Constraint: Name column.
b. In the Constraint Manager workbook, review the values in the Over/Under Load rows to identify any overloaded constraints that
are underloaded in earlier periods.
c. In the Constraint column, click the name of the constraint, and then choose Constraint Properties from the menu that appears.
d. In the Constraint Properties workbook, in the Constraint Summary worksheet, verify the value in Pre‐Plan? column for the
constraint to determine if the constraint allows pre‐building. The word “Edit” displays in the cell if pre‐planning is an option.
e. If the constraint allows pre‐building, click “Edit” in the column to display all part sources that have source constraints that are using
the selected constraint.
f. In the Manage Pre‐Plan Limit‐View worksheet, find the row that corresponds to the part from which you want to pre‐build.
g. In the Pre‐Plan Limit column for the part, type the number of calendar days to specify the pre‐build period. If the value in the cell is
negative, there is no limit.
13. Review impact of all changes: To review impact on excess inventory, projected delivery, inventory levels, go to Master Scheduler Scorecard.
14. Are changes acceptable?: Using the Master Scheduler scorecard, you can compare the adjustments that you made to the planning BOMs
and planning parameters to ensure that they are aligned with key corporate metrics. If yes, commit the private scenario to the working
scenario and go 'Align and Firm MPS' Sub‐Process flow. If no, go back to step 1

1. Does Due Date and Quantity meet Demand?: Create a new private scenario that is based on the up‐to‐date working scenario. Starting from
the MPS Dashboard, Misaligned MPS Part to Demand widget drill to the Master Scheduling workbook Details View worksheet. On a part
by part basis, review the DueDate and Quantity against the Demand for the time period in question. In the Misaligned to Demand row for
the part, you can click a value in the period bucket that corresponds to the misalignment. This opens the Supply Details worksheet. You can
review notes from this worksheet. If no misalignment is found skip to step 9. When misalignment is found, go to step 2.
2. Do Notes exist? In Master Scheduling Workbook, Supply Detail worksheet with the details expanded, review if notes exist. If yes go to step
3, otherwise step 4.
3. Do Notes indicate further action? Review to determine if misalignment is an intentional exception (e.g. Adjustments to support Aggregate
Supply Plan, adjustments to support Inventory Targets, approved demand changes pending, known supply change not reflected in parent
order). If further action is needed got to step 4, otherwise step 9.
4. Is the SR released or in Frozen zone? In Master Scheduling Workbook, in the Details View worksheet, review if MPS Supply order is in the
orange Frozen Zone. If yes go to step 5, otherwise go to step 7.
5. Collaborate with Production Control: Collaborate to determine if alignment can be done within the rules established by your
organization.
 Important to Note: This will likely require adhoc meetings and collaboration with the production floor and you may need to obtain
the required level of approval to make the change.
6. Can order be moved as result of collaboration? If yes go to step 7, otherwise step 8
7. Align Due Date and Quantity to Demand as needed: Using the Master Scheduling workbook, in the Misaligned to Demand row for the part,
click the value in the period bucket that corresponds to the misalignment. In the Supply Details worksheet align DueDate and/or Quantity to
meet demand inside the MPS window.
8. Add note and Notify Demand Planner / Customer Service: If result of the collaboration is the supply can't be moved, then add a note to the
MPS Supply Order Line in the Supply Details worksheet. In the Supply Details worksheet, in the row that corresponds to the order with the
misaligned demand, click the order number in the Order: Number:Line column to open the Supply Order Analysis workbook. Click the
Supply Consumption worksheet. Notify the CSR and/or Demand Planner as necessary using the Responsible columns and attach a PDF file
using the Attach Report functionality.
9. Has MPS Horizon moved into a new Supply Plan period?: If no, go to Step 11. If yes, go to step 10.
10. Run Automation to firm up last period: Using the Master Scheduling workbook in Summary view, review the planned orders that fall into
the MPS Auto Firm Window (green zone). Run Toolbar automation command Auto Firm MPS.
11. Are inventory Targets or Supply Plan being met?: If Aggregate Supply Plan is used, then review the Aggregate Supply Plan, Delta and Cum
Delta rows in the Master Scheduling workbook Summary View. If Aggregate Supply Plan is not used review the Inventory Targets Annual
Plan, Delta and Projected Inventory rows in the Master Scheduling workbook Summary View. If an assumption exists, click on the
Assumptions count in the Assumptions line in the appropriate period bucket, and review the Assumptions Details worksheet.
12. Adjust MPS to Inventory Targets or Supply Plan as needed: On a part by part basis, if changes are needed to meet the ASP or the inventory
targets within your company’s tolerance policies, adjust the MPS as needed using the Master Scheduling workbook, Summary View in the

MPS Supply row, click the value that corresponds to the period bucket column that needs adjusting. This opens the Part Details worksheet in
the bottom pane to adjust at the part level all orders proportionally or in the MPS Supply row, click the value that corresponds to the period
bucket column that needs adjusting to drill to the Supply Details worksheet to adjust a specific order for that part.
13. Commit changes: Commit the private scenario to the working scenario.

1. Is the Part MPS Achievable?: For MPS Parts that are Achievable (Available Date is later than or equal to Due Date), skip to Step 14. For
late parts, open the up‐to‐date working scenario that includes the changes that were committed during the Align and Firm MPS sub
process. Using the Master Scheduling workbook in Details View worksheet, choose Late Supply and Available Date from the list
boxes. On a part by part basis, choose a period with late supply and click on the Late Supply quantity to open up Supply Details
worksheet. Review late Scheduled Receipts (MPS Supply avail date is later then MPS Supply due date), on an order by order basis.
2. Simulate Feasible Resolution Options: Create additional scenario(s) based on the up‐to‐date working scenario. This allows you to
compare alternate resolutions.
3. Review MPS order to determine cause of lateness: Using the Master Scheduling workbook in the Details view, Supply Details
worksheet Link on supply order to navigate to the Supply Order Analysis workbook, set focus on an using the Set Selected Order
button in order to drill down to see the gating supplies. In the Late Supply worksheet, uses the Responsibility column to collaborate with
the responsible Buyer(s)/Material Planner(s) or Operations Planner(s). This triggers a multi‐step process including sharing of
collaboration scenario, notification to responsible user(s), review by user(s), Acceptance of Rejection of adjustment.
a. Collaborate on Material Misalignments (expedite shortages)
b. Collaborate on Capacity
4. Transfer Inventory: In the Master Scheduling workbook, Details View worksheet, review the Stock in Other Sites column for a part to
determine if there is stock at another site. If yes, click the link in the Stock in Other Sites column to open the Inventory Transfers
workbook and evaluate if the inventory in other sites is worth considering to improve or resolve this issue. In the Inventory Transfers
Workbook, evaluate if the OH quantity is needed for planned demand at that site. If inventory transfer is feasible given your
organizations business processes, collaborate with responsible Master Scheduler. In the Projected Inventory worksheet, in the row that
corresponds to the site with the available inventory, in the Responsible column, click the User Contact Information button next to the
responsible person's name. If acceptable, make the transfer. On the workbook toolbar, click the Transfer Inventory button.
5. De‐expedite Another MPS Order to free up Material or Capacity: If you cannot transfer inventory from another site, you can analyze
other MPS orders to determine if you can de‐expedite a driver order to resolve gating supplies or constraints. For example, you can look
into de‐expediting a supply order that pegs to forecast or to safety stock. If you are responsible for master scheduling the MPS part, you
can proceed with de‐expediting the order. However, you may determine that you need to collaborate with another master scheduler to
de‐expedite an order for which they are responsible for master scheduling.
a. Analyze MPS orders to determine if you can de‐expedite
i. In the Master Scheduling workbook, in the Details View worksheet, make sure select Late Supply is selected from the
Show parts with list. Search for the part with the late supply.
ii. In the Late Supply row for a part, click the value in the period bucket that has the late supply.
iii. In the Supply Details worksheet, in the row that corresponds to the late supply order, click the link in the Order ‐
Number ‐ Line column to open the Supply Order Analysis workbook.
iv. In the Late Supply tab, select the row that corresponds with the order that is causing the problem. For example, the
order at the lowest level of the component tree with the highest number of days late.

v. In the Supply Consumption worksheet, on the workbook details toolbar, click Details>> to display the Parent Order and
Driver Order columns.
vi. Review the Driver Order ‐ Type column to determine if earlier supply of the late component part is pegging to a driver
order that you could de‐expedite.
vii. Do one of the following:
1. If you find a driver order with a type that allows for de‐expediting, continue to the Determine who is
responsible for the MPS order section that follows.
2. If you cannot find an order that you can de‐expedite, go to Split the scheduled receipt.
3. If the order is a customer order, Collaborate with a customer service representative.
b. Determine who is responsible for the MPS order
i. In the row that corresponds to the driver order you want to de‐expedite, select the cell In the Driver Order ‐ Number ‐
Line column, and then click Edit menu, Copy. You want to identify the demand that is consuming earlier supply of the
late component.
ii. In the Driver Order ‐ Part column, click the link for the top‐level component part and choose Planning Sheet from the
menu that appears.
iii. In the Pegged Supply Allocation worksheet, click in the Search row cell above the Driver Order ‐ Number ‐ Line column,
click Edit menu, Paste to enter the driver order number, and then press Enter.
iv. In the Component: Responsible column, determine who is responsible for the master scheduling the part.
v. Do one of the following:
1. If you are responsible for master scheduling the MPS part, go to the De‐expedite MPS order section that
follows.
2. If you are not responsible for master scheduling the MPS part, collaborate with a master scheduler.
c. De‐expedite a driver order
i. In the Pegged Supply Allocation worksheet, in the row that corresponds to the supply order that you want to de‐
expedite, select the cell in the Supply Order Number ‐ Line column, and click Edit menu, Copy.
ii. In Supply Order Analysis workbook, in the All Orders worksheet, click in the Search row cell above the Order ‐ Number ‐
Line column, click Edit menu, Paste to enter the order number, and then press Enter.
iii. On the workbook toolbar, choose the site where the part is being master scheduled from the Site list.
iv. In the All Orders worksheet, in the row that corresponds to the MPS order that you want to de‐expedite, click the down
arrow beside the Date ‐ Due.
v. In the Calendar dialog box, click the date you want to set.
vi. On the File menu, click Save Data.
vii. In the Master Scheduler workbook, review the MPS to determine if de‐expediting the order has impacted the other MPS
orders.

viii. Do one of the following:
1. If you resolved the issue, go to step 10.
2. If you did not resolve the issue, you can delete the working scenario so the change is not committed to the MPS,
create a new working scenario, and then go to step 6.
6. Split Scheduled Receipt: Using the Master Scheduling workbook (or Supply Order Analysis workbook), review the Late Supply
column in the Supply Details worksheet for the order to determine if the order is a candidate for splitting (Note: Considerations for
splitting a line would be based on your company policies). You need to verify if incremental availability is applied to the part In the
Supply Details worksheet, in the Part column, click the part name link and select Planning Parameters, click the Part Properties tab to
review the value in the Incremental Rule column to determine if it is set to On or Off. Click to Split Line toolbar button to launch the Split
Supply dialog and add Due Dates and Quantity lines as needed.
7. Change Order Priority: Using the Master Scheduling workbook and the Supply Details worksheet, review order Priority column and
change priority as needed based on your company policies. Once changed review the Dates ‐ Available Date column to validate that it
improves your Supply order availability. (Note: Changing an order priority is an advanced Master Scheduling option and should be used
with extreme care. It is important to have a full understanding of how priorities work and to review the impact on other scheduled
receipts and demand orders.)
8. Collaborate with Order Fulfillment to adjust competing demands: If none of the resolution options are feasible, you need to
collaborate with the customer service representative (e.g. move Due Date, split orders or change priority for MPS independent
Demand.) In the Supply Order Analysis workbook, in the Supply Consumption worksheet, in the Driver Order ‐ Responsible column for
the part, click the User Contact Information button next to the responsible person's name. This triggers a multi‐step process including
sharing of collaboration scenario, notification to responsible user(s), review by user(s), Acceptance of Rejection of adjustment.
9. Is Impact acceptable?: Using the Master Scheduler Scorecard to review. Compare any of the private scenarios that you created to the
Master Production Scheduling scenario. This allows you to decide which scenario(s) best resolve the issue(s). Commit the acceptable
scenario(s) to the working scenario, and delete other scenario(s).
10. Is Issue resolved?: If Yes, skip to Step 14. If No, go to Step 11.
11. Set MPS Due Date to available date: Using the Master Scheduler workbook, in the Supply Details worksheet change the DueDate to
align with the AvailableDate.
12. Does this impact a customer order?: Using Supply Order Analysis workbook, in the Supply Consumption worksheet, view the customer
orders that the supply is pegged to. If Yes, go to Step 13, if No, skip to Step 14.
13. Feedback to Customer Service Rep. that customer demand can't be met: From Supply Order Analysis workbook, Supply Consumption
worksheet, use the Responsible column to share the scenario and send message to the CSR.
14. Are all issues in Master Scheduling control resolved?: If Yes, review the Master Scheduler dashboard and commit the working scenario.
If not go back to Step 1 for the next MPS part.

2.1.1 Inputs
The inputs for the MPS process include:
 Approved Consensus Demand Plan / Independent Forecast
 Customer Sales Orders
 Dependent Demand
 Current MPS ‐ Open Orders (WO, PO, Intersite with in‐transit, Firm MPS and Planned Orders)
 On Hand Inventory
 Approved Supply Plan
 Historical Supply Data
 Capacity Planning (Constraint) Data
 Part Planning Properties
 BOMs, Planning BOMs
 Engineering Changes
 Annual Plan Targets
 Assumptions
2.1.2 Outputs
The outputs for the MPS process include:
 Approved Master Production Schedule (firm planned order changes)
 Closed loop transactions back to host system, when applicable:
o Part Planning Properties
o Planning BOM changes
o Constraint Adjustments
o Inventory Transfers
o MPS quantity and date changes
o MPS New scheduled Receipts
o Purchase Order / Work Order quantity and date changes on sub‐assemblies or components

2.1.3 Scenario Structure
The scenario structure below supports all RapidResponse Applications:
Scenario Purpose Permanent? Shared? Modify/ Auto‐

View? Update?
Enterprise Import Data from ERP or Data Integration Server; represents the most Y System/Data V N/A
Data recent data extracted from enterprise data sources or Data Integration Admin
Server data source
Approved Child of Enterprise Data; Scenario to perform automated data Y System/Data V Y
Actions manipulation and modification of Host system data to support the 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

View? Update?
Integration. This is especially important for data that crosses multiple
processes.
Updated on a scheduled frequency determined at integration. It is

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.
Master Child of Baseline; this is the working scenario for the Master Production Y Y M N
Production Scheduling (MPS) Application.
Scheduling
Any collaboration activity as part of the MPS cycle would be a child of
this scenario, with approved changes committed back into it.
Committed into Baseline on a scheduled frequency determined at

Integration, for update of other scenarios and closed‐loop transactions;
Typically weekly commit.
Prior to commit, this scenario is used in multi‐scenario comparison,

against Baseline, to identify the candidate records for closed‐loop
transactions.
Scheduled update on a frequency determined at Integration, typically

once per week when the MPS cycle begins
Private Collaboration and editing scenario(s) for Master Production Scheduling; N Y M/V N

View? Update?
Scenario committing private scenario back into Master Production Scheduling
scenario constitutes completion of collaboration and approval of
changes;
It is likely that multiple levels of private scenarios exist under Master

Production Scheduling 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
3.1 Metrics, Dashboards and/or Scorecards
3.1.1 Dashboard
The following role has a Dashboard available to them within the Master Production Scheduling
application. By default the dashboards are not set to refresh automatically. If the customer would like
the auto‐refresh turned on it can be done through the dashboard properties.
Master Scheduler
The MPS Risks tab reports:
 MPS Exceptions: Scenario Compare

 Late Revenue Caused by MPS Orders
 Constraints Impacting MPS
 Component Shortages Impacting MPS
 Component Shortages by MPS Start Date
The Performance Metrics tab reports:
 Master Scheduling Summary

 Misaligned MPS Parts to Demand
 MPS Attainment %
 Number of Constraints Overloads/Underloads
The Corporate Metrics tab reports:
 Revenue
 Ending Inventory Value
 Margin %
 On Time Delivery to Request
 Key Constraint Utilization
3.1.2 Scorecard
The following role has a Scorecard available to them within the Master Production Scheduling
application.
Master Scheduler
The metrics contained within the Master Scheduler scorecard are:
 On Time to Commit
 Revenue
 Margin %
 Key Constraint Utilization
 Ending Inventory
3.2 Other Resources: Processes, Task Flows, Workbooks
3.2.1 Task Flows
The following task flows are provided in support of this application:
 Master Production Scheduling

o Adjust Planning BOMs, Parameters and Constraints
 Review and Adjust Planning BOMs
 Review and Adjust Planning Parameters
 Review and Resolve Constraints
o Align and Firm MPS
o Resolve MPS Issues
3.2.2 Workbooks
In addition to those workbooks referenced in the Business Processes section of this document, the
following workbooks are provided in support of this application:
 Manual Closed Loop MPS – This workbook is used to report changes that were made to various
planning parameters during the Master Production Scheduling process that might need to be
manually adjusted in the host ERP. The workbook is designed to report changes to:
o Planning BOM: Effective In/Out, Option Ratio, Quantity Per
o Part Properties: Number of Days Supply
o Time‐Phased Safety Stock: Date, Quantity, Days
o Sourcing Properties: Lot Size Quantity Min/Max/Mult, Fixed Lead Time, Scrap, Effective
In/Out
o Order Priority
o Inventory Transfer: Quantity, Cost, Shipping Date, Transit Time
o Pre‐Plan Limit
 Closed Loop MPS – This workbook is used in the automated closed‐loop process, and identifies
records that have been modified through the Master Production Scheduling process and will be
closed‐looped via automated transactions. It is the source workbook for those automated
transactions. The workbook is designed to report changes to:
o Planned Order Create
o Transfer Order Change, Cancel
o Transfer Requisition Create, Change, Cancel
o Work Order Change, Cancel
o Purchase Order Change, Cancel
o Purchase Requisition Create, Change, Cancel
o Safety Stock Qty Change
o Planning Time Fence Change
 Data Reconciliation MPS – This workbook is used to verify for duplicate scheduled receipt and
inventory transfer records that exist or may have been introduced. It is used in the closed‐loop
reconciliation process.
 Data Integrity – Material – While there isn’t a Data Integrity workbook designed specifically for
the MPS Application, the Data Integrity – Material workbook can be used.
 Write History Records – This workbook is used in the process to write the MPS Plan records to
historical tables. Uses the Supply Plan Category value = ‘MPSSupplyPlan’ for MPS orders
 Supply Waterfalls – This workbook is used to review historical actual supply and forecast over
time. Macro configuration is required to include the MPS plan. See the Macros section.
The following workbooks support dashboard widgets and scorecard metrics:
 MPS Late Revenue Treemap

 MPS Attainment Treemap
 MPS Exceptions Details
 MPS Exceptions Widgets
 MPS Widget Details
 MPS Widgets‐ Single Scenario
 MPS Widgets Workbook
 S&OP Corporate Metrics
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 Business
Services, but that does not mean it should not be thought about and considered when deploying other
business service blueprints.
Prior to release 2014.1 RapidResponse supports approximately 1B input records on all input tables in all
scenarios. As of release 2014.1 RapidResponse supports approximately 4B input records on all input
tables in all scenarios. You do not want to come anywhere near this number for just one table.
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 (pre 2014.4, was $DP_BaseCalendar) 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 CANNOT be supported in RapidResponse and even if it could the
performance would be unusable
In addition to the input record limits mentioned above, there is a 4 billion Record ID limit per table
across all scenarios that can impact our customers on Historical and ForecastDetail tables. An input
record is assigned a record ID at creation that is simply a counter for each table. The Record ID values
are not reused and (except in one very special case) they are not recovered by a server restart or data
update operation. So, if you were to import or create 600M input records on a table (like ForecastDetails
or, more often, HistoricalDemandSeriesDetail or HistoricalDemandActuals), and then delete them and
bring in another set on the next cycle, you would never hit the 4 billion records at any given time.
However, you would still be consuming the record IDs 600M at a time. Therefore, on your 7th update
cycle, you would crash the RapidResponse server, having exhausted all available Record IDs.
4.1.2 Configuration Points

4.1.2.1 Profile Variables
The following profile variables are used in this application to support the setting and displaying of target
values on the Master Scheduler Dashboard. Target categories are defined in the RapidResponse
Application Settings workbook > Application Variables worksheet.
No Variable Name Description Default Value

1 $MPS_AttainmentPercentTarget MPS attainment target for MPSAttainmentPercentTarget
use in the MPS Attainment %
widget
2 $DP_DemandPlanValueTarget Demand Plan Value Target DemandPlanValueTarget
for use in the Revenue Value
widget
3 $DP_MarginPercentTarget Margin % Target for use in MarginPercentTarget
the Margin % widget
4 $DP_OnTimeRequestTarget On Time to Request Target OnTimeRequestTarget
for use in the OTD to
Request widget
5 $DP_PeriodEndingInventoryValueTarget Period Ending Inventory PeriodEndingInventoryValueTarget
Value Target for use in the
Ending Inventory Value
widget
6 $DP_KeyConstraintUsageTarget Key Constraint Utilization KeyConstraintUsageTarget
Target for use in the Key
Constraint Utilization widget
The following profile variables are used in this application to support the rendering of other data
elements in the Master Scheduler Dashboard, and are defined in the RapidResponse Application
Settings workbook > Application Variables worksheet.

1 $DP_ConsensusDemandOrderNumber Used to report on Revenue Demand Plan
Exceptions in the MPS
Exceptions widget
2 $MPS_Orders Historical Supply Category MPSOrders
value for MPS orders; Used
in the MPS Attainment %
reporting
3 $MPS_Plan Supply Plan Category value MPSSupplyPlan
for MPS orders; Used in the
Write History Records
workbook to write MPS
orders to history
The following profile variables are used in this application to support the rendering of the Overloads and
Underloads and MPS Exceptions on the Master Scheduler Dashboard, and display counts of overloaded
or underloaded constraints exceeding either a Warning level or a Critical level. They are defined in the
Macros and Profile Variables workbook > Profile Variables worksheet. They are applicable if the
Capacity Planning (Constraint) application is being utilized.
Variable Name Type Value

1 $OverloadsWarning Permanent 95
2 $OverloadsCritical Permanent 98
3 $UnderloadsWarning Permanent 40
4 $UnderloadsCritical Permanent 20
The following profile variables are used in this application to support the setting and displaying of target
values on the Master Scheduler Scorecard. Target categories are defined in the RapidResponse
Application Settings workbook > Application Variables worksheet.

1 $DP_OnTimeCommitTarget On Time Commit Target OnTimeCommitTarget
2 $DP_DemandPlanValueTarget Demand Plan Value Target DemandPlanValueTarget
3 $DP_MarginPercentTarget Margin Percent Target MarginPercentTarget
4 $DP_KeyConstraintUsageTarget Key Constraint Usage Target KeyConstraintUsageTarget
5 $DP_PeriodEndingInventoryValueTarget Period Ending Inventory PeriodEndingInventoryValueTarget
Value Target
6 $DP_ExcessValueTarget Excess Value Target ExcessValueTarget
The following profile variables are miscellaneous “Other” configuration variables related to Master
Production Scheduling resources. Each needs to be configured.

1 $DP_AssumptionComponentsLimit Assumption Components Limit; used 100
in Master Scheduling workbook for
Assumption Details
2 $DefaultCriticalLimit Default Critical Limit %; Used in 5
Constraint widgets
3 $DefaultWarningLimit Default Warning Limit %; Used in 0
Constraint widgets
4 $DP_SupplyPlanCategory Supply Plan Category; Used in SupplyPlan
Master Scheduling and MPS widgets
workbooks to denote Supply Plan
records
4.1.2.2 Macros
The following macros are indicated for use in the Master Production Scheduling application, and can be
configured in the Macros and Profile Variables workbook:
No Macro Name Expression Description

1 ShipmentType_Supply() ‘MPSOrders’ Used in the Supply Waterfall workbook to also show the
‘MPSOrders’ as the actuals; If the $MPS_Orders profile
variable default Value is changed to something other than
‘MPSOrders’, this macro expression will need to be
changed accordingly.
2 SupplierFcst_Type() ‘MPSSupplyPlan’ Used in the Supply Waterfall workbook; If the $MPS_Plan
profile variable default Value is changed to something
other than ‘MPSSupplyPlan’, this macro expression will
need to be changed accordingly.
4.1.2.3 Automation
The following automation resources are provided with the Master Production Scheduling application:
Name Type Description Expected Frequency

Auto Firm MPS Scheduled Task Runs the command “Auto At minimum, at the
Firm MPS” contained beginning of the MPS
within the Master planning process
Scheduling workbook,
which converts MPS part The Master Scheduling
Planned Orders that are workbook command
within the “Auto Firm MPS” can be
AutoFirmWindow to MPS run on an ad‐hoc basis,
supply orders (Scheduled from directly within the
Receipts) with Id like workbook
“MPS*” .
Defined to modify data in

the Baseline scenario by
default, for All Part and All
Sites.
Write MPS Plan to Scheduled Task Runs the “Write Historical At minimum, at the end
History MPS Plan” contained of the MPS planning
within the MPS Write process, after the
History Records workbook, approved MPS plan has
which takes the records been finalized and
from the MPS Plan published, prior to
Records worksheet (where beginning a new
Category = $MPS_Plan) planning cycle.
and writes them into
history.
Defined to modify data in

the Baseline scenario for
All Parts and All Sites.
The following Automation tasks need to be created to support this application:
Name Type Description Expected Frequency

Delete Historical Supply Scheduled System Defined for a rolling period of Daily
Series Task time it prunes data in the
HistoricalSupplySeries and
through cascading deletes
the
HistoricalSupplySeriesDetail
tables for data older than ‘n’
calendar periods, typically
12‐24 months.
Run in Baseline using the
DeleteData commans
Delete Historical Supply Scheduled System Defined for a rolling period of Daily
Actuals (Optional) Task time it prunes data in the
HistoricalSupplyActual table
for data older than ‘n’
calendar periods, typically
12‐24 months.
Run in Enterprise Data using
DeleteEnterpriseData
command
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 Baseline using the
DeleteData command
4.1.2.4 Alerts
Seven standard Alerts are included for the Master Production Scheduling application. They support
Manual Closed‐Loop operations, and provide an ability to alert the user(s) to changes that were made to
various properties and parameters as part of the MPS process that might need to be changed in the
source ERP system. If applicable, these will need to be configured for scheduling and notification.
They are:
 Manual Inventory Transfer Adjustments

 Manual Order Priority Adjustments
 Manual Part Properties Adjustments
 Manual Planning BOM Adjustments
 Manual Pre‐Plan Limit Adjustments
 Manual Sourcing Properties Adjustments
 Manual Time‐Phased Safety Stock Adjustments
4.1.2.5 Pre‐defined Filters

There are no new pre‐defined filters for the Master Production Scheduling application. Standard,
existing filters are used in the application resources.
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.6 Hierarchies
Hierarchies are used extensively throughout the S&OP, Demand Planning, Aggregate Supply Planning,
Capacity Planning and Master Production Scheduling applications to allow the entry of data values at a
specific intersection, and allow the forecast detail records to then disaggregate 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.7 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.7.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.7.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.7.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.7.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.7.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.8 Miscellaneous
Below is a list of other configuration points to be aware of for this application:
4.1.2.8.1 Insert Definition for Scheduled Receipts

Scheduled Receipt quantities are editable within the Master Production Scheduling application, and new
ScheduledReceipt records can be inserted. The custom insert definition specifies that the Order.Type
define a data value as determined by RapidResponse (screenshots below). The SupplyOrder default for
the Type field is []{? Value='Default' 0 1, Value}. At configuration, it should be ensured that either the
SupplyType has a value of “Default” in every control set, or the insert definition is changed to reflect the
correct supply type instead of Default.
4.1.2.8.2 Late Supply Tolerance
Some of the Master Production Scheduling resources use value in the MPSConfiguration.Tolerance,
MPSConfiguration.ToleranceCalendar and MPSConfiguration.ToleranceInterval fields in order to
determine whether a supply is considered late and used to report whether the master schedule is being
achieved. It is important to configure these fields. For more information, see the Control Table
Configuration section.
The following resources reference Tolerance:
Master Scheduling Workbook, MPS Attainment Treemap, MPS Metrics, MPS Widgets Workbook and
MPS Widget Details
4.1.2.8.3 Corporate Metrics and Performance Metrics tabs of Dashboard

The consultant will need to remove certain widgets for the role based dashboard if the customer has not
purchased the related application (eg. Key Constraint Utilization, Number of Constraints
Overloads/Underloads if Capacity Planning is not purchased), otherwise the widget will not render any
data.
4.1.2.8.4 On Time Delivery Measures

The Corporate Metrics measures found on the Master Scheduler dashboard by default report On Time
Delivery to Request (OTD Request), and is consistent across all applications that report Corporate
Metrics.
Specifically for the Master Production Scheduling application, the measure of On Time Delivery to
Commit was deemed likely more relevant to the Master Scheduler. As such, the OTD Commit metric
was included in the Master Scheduler scorecard.
Changes to either the Corporate Metrics tab of the Master Scheduler dashboard or the Master
Scheduler scorecard will be required if the customer wants equivalent measures across both resources.
4.1.2.8.5 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.8.6 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 Master Schedulers role would have the Master Production Scheduling task
flow selected to open on sign in as shown below:
In support of the Master Production Scheduling Application, Users in the following groups should have
the task flow noted below set to open on sign in:
 Master Schedulers: Master Production Scheduling
4.1.3 Control Table Configuration

4.1.3.1 PartType
The PartType table contains the values that control how a part is processed. For all Parts for which a
consensus forecast is generated in S&OP, the Part Types loaded must have a ProcessingRule of “MPS”.
Master Production Scheduling resources are primarily filtered on “MPS” Type parts.
Fields of particular interest to Master Production Scheduling may include:
 AllocationQuantityRule: Generally, set to Use in order to satisfy as many demands on time as

possible (by satisfying the smaller quantities first). However, it can be set to Ignore if the
Order.Id has more significance to priority than the quantity.
 ATPCTPRule: Specifies, for each part type, where excess supply is allocated, and how to
calculate for available to promise (ATP). Please note that this setting is really only valid when the
ProcessingRule is also either MPS or MPSConfig. Valid values are:
o Earliest: As a rule, we recommend setting this to Earliest so that new orders can be
promised as early as possible. This is most unlikely to result in a similar ATP to other
systems though.
o Latest: Latest is the setting that most closely matches the more traditional ATP
recommendations. It still does not match it, but it is closer.
 AvailableRule: Specifies how the availability for the part is determined. Valid values are:
o Ignore: You would set this to Ignore for such types as floor stock or any other type of
part that should not impact the availability of its parent supplies.
o Normal: Otherwise, if availability from this part should alter the availability of parent
supplies, then this should be set to Normal.
Important to note that any expiring parts should have this field set to “Normal”
 CommitLevel: Specifies, for each part type, how priority is applied to netting (supply planning)
and CTP (available date calculations) and how order commitments are maintained. Valid values
are:
o High: Priority is used in both netting and CTP with this setting unless MLS is enabled for
this part or the SafetyStockRule is either OrderPointAverage, OrderPointOver or
OrderPointUnder. If the part is enabled for MLS or is an Order Point part type, then it
will be treated like a MediumExplodePriority. It is appropriate for assemblies where
demand priority is important to use and/or is important to propagate to dependent
parts. This may include but is not limited to parents of constrained components. It
generally only applies to purchased parts if there is a constraint associated with its
sources. It is frequently important to make or transfer parts even if they are not
associated with specific constraints.
o MediumExplodePriority: With this setting, CTP allocates supply availability by priority,
netting does not plan by priority but it can propagate the priority to the dependent
parts. This setting is often used for MLS or OrderPoint assemblies that are either
constrained themselves or have components where priority planning is important.
Other examples include parts that have part sources with constraint and might have
components with constraint, but are either set to use lot sizing policies, configured as
the primary product in a coproduct/byproduct structure, or configured as the primary
component in a BOM level part substitution relationship
o Medium: With this setting, CTP allocates supply availability by priority but netting does
not plan by priority nor does it propagate priority to the components. It is appropriate
for parts with only buy sources (with or without constraint) or make sources with no
constraint
o Low: appropriate for parts where all part sources have no active constraint and where
any make sources have unlimited availability. Essentially, this turns off priority planning
for the part completely and all demands are assumed to have a priority as defined by
the DefaultPriority.
 DaysSupplyRule: This field defines the period considered when accumulating demands for
planned order generation when using Days of Supply. Valid values are:
o ByPeriod
o ByPeriodWithPriority
o FromDemand
o FromSupply
Important to note this setting applies to parts subject to days of supply logic, where
UseDaysSupply = “Y”.
Important to note this setting prevents netting from processing demands in priority order.
Netting can (optionally) propagate priorities through this part but will not create supply based
on the priorities of the demands.
 DefaultPriority: This specifies the effective priority of all demands on this part if the
CommitLevel is Medium or Low, or it specifies the effective priority of demand generated only
by safety stock if the CommitLevel is higher than that.
 ProcessingRule: Specifies, for each PartType, a processing rule that describes the logic used for
netting calculations. For the Master Production Scheduling application, we expect only MPS
parts. Valid values are:
o Ignore
o MPS
o MRP
o MPSConfig
 SupplyAllocationRule: Specifies how supplies are allocated to demands during pegging. Valid
values are:
o ByAvailable: This should be the default setting. It is particularly important if there are
priorities being planned anywhere.
o ByMRPPlan: This setting might be used if trying to match a host system supply/demand
allotment for the validation operation.
 UseDaysSupply and DaysSupplyPrioritySource
4.1.3.2 PartSourceType
This control table defines the characteristics of each potential supply source (for example, Make, Buy,
and Transfer). For example, it controls the effectivity of sourcing features and determines the type and
status of planned orders when supplies are required using this source. This table is referenced from the
PartSource table.
 CostRule: Specifies how the enterprise system calculates the effective cost of a part. Valid
values are:
o UnitCost—sets the PartSource.EffUnitCost to a fixed value equal to the value imported
into the PartSource.UnitCost field or Part.StdUnitCost if UnitCost is 0.
o MaterialLaborOverheadCosts—calculates the PartSource.EffUnitCost by adding the
material, labor, and overhead costs.
 Important to note that that if the PartSourceTimePhasedAttributes table has an
effective record for the part source then its values are used instead of those
defined on the PartSource record
 Important to note that this setting also impacts the calculation of the
NewPurchaseCost fields found on many tables in the data model
 EffectivityRule: Specifies the effectivity rule that is used by the enterprise system to interpret
the dates on PartSource records (which are time phased). Valid values are:
o InclusiveExclusive *recommended
o Always
o Inclusive
o Exclusive
o Never
 PlannedOrderSupplyStatus: Specifies how to control Order.Line level configuration settings
(such as the generation of dependent requirements) for planned orders. References the
SupplyStatus table.
 PlannedOrderSupplyType: Specifies, for planned orders, how to control order level
configuration settings (such as rescheduling logic and whether the order is a Make, Buy or
Transfer). References the SupplyType table.
 PlannedOrderToSRSupplyType: Specifies the supply type to use when converting planned
orders to scheduled receipts, and used when assigning a part source to a scheduled receipt.
o It is likely that the Type values will be different between PlannedOrderSupplyType and
PlannedOrderToSRSupplyType in order to distinguish between a calculated planned
order versus a planned order that was converted to a Scheduled Receipt
 PlannedOrderToSRSupplyStatus: Specifies the supply status to use when converting planned
orders to scheduled receipts, and used when assigning a part source to a scheduled receipt.
 TransitRules: Specifies how the enterprise system calculates lead time. Lead time values are
considered in calculating a “start date” (PlannedOrder.StartDate or ScheduledReceipt. Valid
values are:
o Cumulative: Essentially, use this one if the Dock‐To‐Stock, TransitTime and PreShipLT
time is not included in the Fixed‐Lead‐Time (rough rule of thumb).
o Inclusive: Essentially, use this one if the Dock‐To‐Stock, TransitTime and PreShipLT time
is included in the Fixed‐Lead‐Time (rough rule of thumb).
Important to note that the Constraint‐related fields (eg. ConstraintDateRule, ConstraintMinimumRule,

ConstraintMultipleRule, etc.) would become of importance in the configuration of the Capacity Planning
application.
4.1.3.3 BOMType
This control table specifies the different types of bill of material records and the processing rules for
them. The BOMType.Value is a text string assigned to each parent‐child record in the BillOfMaterial
table. Each BOMType.Value defined represents a set of configuration rules that control the behavior for
that parent‐child relationship.
Since Master Production Scheduling is done at the end item level, this is relevant for planning BOMS.
 DateRule: Specifies which date to test for in determining bill of material date effectivity. Valid
Values are:
o AnchorDate
o BlowThroughCalcDueDate
 Important to note that unless the assembly is a phantom, this option is identical
to CalcDueDate.
o CalcDueDate
o CalcDockDate
o CalcStartDate
o Ignore (Default)
 EffectivityRule: Specifies for each BOMType how ranges of units and dates are interpreted
when determining effectivity. This field applies to all effectivity rules. Valid values are:
o InclusiveExclusive *recommended and default
o Never
o Always
o Exclusive
o Inclusive
 MPSConfigDemandSource: Specifies which components on the BillOfMaterial table are
considered when looking for component actual sales to consume assembly forecast within a
PlanningBOM relationship. Four conditions must be satisfied for this to occur:
o The assembly part has a PartTpe.ProcessingRule of ‘MPSConfig’
o The BillOfMaterial record defining the relationship between the Assembly and
components must have a BOMType.MPSConfigDemandSource set to ‘Y’
o The component has independent demand records where the
DemandType.ProcessingRule is ‘SalesActual’
o The Assembly has independent demand records where the DemandType.ProcessingRule
is ‘SalesForecast’ or ‘ProductionForecast’
o Important to note that this setting is ignored on all BOMType records that define a co‐
product or by‐product configuration
 RatioRule: Specifies how the BillOfMaterial.OptionRatio is used. Valid values are:
o Ignore
o Fraction (default)
o Percent
 RoundingRule: Specifies for each BOMType the rules for rounding numbers in calculations.
Valid values are:
o None (default)
o Up
o Down
o Nearest
o QtyPerOrder
4.1.3.4 MPSConfiguration
*New to 2015.3* Control table that contains settings that support the Master Production Scheduling
application. It is expected that this table be configured for the MPS application, and will contain exactly
one record, which can be modified on a scenario by scenario basis. The settings in this table act as
global defaults, some of which can be overridden at the Part level using corresponding fields in the
PartSolution table.
The settings are used in multiple resources, including Master Scheduler dashboard widgets and Master
Scheduling workbook, but do not impact any analytic calculations.
 AutoFirmWindow: Defines the auto‐firm window, which is the period within the MPS planning
horizon where planned orders are converted into firm MPS orders. The value identified in this
field is added from the start of the latest SOPAnalyticsConfiguration.CycleCalendar interval that
is contained in the MPS horizon.
o Should be expressed in CycleCalendar units
o This value is used as a global default for all parts where the
PartSolution.MPSAutoFirmWindow is set to ‐1.
o If a non‐negative value is provided in the PartSolution.MPSAutoFirmWindow, it is used
for the part and overrides the value provided in this table.
o Used in the Master Scheduling workbook command “Auto Firm MPS”
 Calendar: Reference to the Calendar whose intervals define the bucket size in the MPS
application (eg. Weekly)
 FrozenWindow: Indicates the length of the MPS frozen window in Calendar intervals. The MPS
frozen window is the period of time in which is it strongly recommended that changes not be
made to MPS orders, usually for lead time or cost reasons.
o The value provided in this field is used as a global default for all parts where the
PartSolution. MPSFrozenWindow is set to ‐1.
o If a non‐negative value is provided in the PartSolution.MPSFrozenWindow, it is used for
the part and overrides the value provided in this table
o Used in several MPS resources, including Master Scheduling workbook, MPS Widgets
workbook, Planning Parameters workbook.
 Horizon: Indicates the length of the MPS planning horizon in Calendar intervals.
o The value indicated here defines the intervals after the CalcStartDate, which make up
the planning horizon.
o From a business process perspective, it is assumed that all MPS orders within this
horizon are fully under the control of the master scheduler.
o The value provided in this field is used as a global default for all parts where the
PartSolution.MPSHorizon is set to ‐1.
o If a non‐negative value is provided in the PartSolution.MPSHorizon, it is used for the
part instead of the value provided in this table.
 RunDate: Used to determine the starting point for the MPS Planning Horizon. This field is a
reference to the calendar used to set the current system date.
 Tolerance: Specifies whether tolerance settings contained in the ToleranceInterval and
ToleranceCalendar fields are used by MPS resources in determining whether a supply is
considered to be late. Valid values are:
o N (default); Tolerance settings are not used and a supply is considered late if its
available date is after the due date of the demand it satisfies
o Y; Tolerance settings are used and a supply is considered late if its available date is
greater than the number of ToleranceCalendar intervals after its demand due date.
 ToleranceCalendar: A reference to the calendar that determines how the ToleranceInterval
value is interpreted
 ToleranceInterval: Specifies the maximum limit on lateness for MPS orders
o Used in MPS resources to report whether the master schedule is being achieved, where
if an MPS order is more than this number of ToleranceCalendar intervals late, then it is
considered outside of tolerance and reported as late.
 StartOffset: Specifies the number of Calendar intervals after the current system date on which
to begin the MPS planning horizon
4.1.3.5 SOPAnalyticsConfiguration
Control table that contains settings that support S&OP, demand and supply planning. It is primarily used
to set up parameters for disaggregation and statistical forecasting, however there are field(s) that are
used in defining calendar intervals for the MPS application.
Fields of interest to the MPS application include:

 CycleCalendar: Specifies the calendar that reflects the S&OP cycle used to calculate the
historical end date, the forecast start date, and the forecast end date.
o Typically Monthly calendar
o Used in conjunction with the MPSConfiguration.AutoFirmWindow value to define the
length of the auto‐firm window.
o Used in Master Scheduling and MPS Widgets workbooks
 CalcForecastStartDate: A calculated field, specifies the calculated date to start reporting
disaggregation rates (inclusive)
o Used in Master Scheduling and MPS Widgets workbooks
4.1.3.6 SupplyType
Defines processing rules for handling a particular supply order and its associated line items. For
example, can allocations be generated for the line items. Also used by the PartSourceType control table
to define characteristics for processing planned orders using this part source.
 ProcessingRule: Specifies a processing rule for each scheduled receipt. The processing rule
controls, at the order number or header level, both the reschedule recommendations as well as
whether the supply is ignored. Valid values are:
o ExplodeOnly
o Ignore
o InTransit
o InTransitExact
o NonReschedulable
o RecommendOnly
o Reschedulable (Default)
 Source: Specifies a source for each SupplyType. The Source value works in conjunction with the
BillOfMaterials to control the generation of dependent requirements (allocations) on
components. It also works in conjunction with the PartSource, in the case of ‘Transfer’, to
handle inter‐site requirements. Valid values are:
o Make
o Buy
o Transfer (Default)
4.1.3.7 SupplyStatus
Defines processing rules for handling a particular line item (scheduled receipt). For example, a line item
can be reschedulable. Used by the PartSourceType control table to define characteristics for processing
planned orders using this part source. Referenced by the ScheduledReceipt table.
 AvailableDateLimit: A supply order’s AvailableDate is limited by constraint and material

availability, as well as the absolute limit set by Part.PlanningCalendars.DataDate. Subject to
these limitations, this field determines the earliest date that RapidResponse can set the
available date for supply orders. Valid values are:
o Now
o CalcStart
o Due
 IgnoreSupply: Specifies whether any type of supply should not be considered in netting and
explosion. Valid values are:
o Y
o N
 IncrementalSplit: For parts that have incremental availability calculations turned on, this field
allows those calculations to be turned off on a supply‐by‐supply basis. Valid values are:
o FromPart: incremental availability calculations are performed for this supply based if
turned on (set by the Part.IncrementalRule), otherwise incremental availability
calculations are not performed for this supply; this is the default setting
o Off
 RescheduleRule: Specifies the reschedule rule to be applied to the ScheduledReceipt record
(referencing the SupplyStatus table). This value overrides what has been set at the order level
using the SupplyType.ProcessingRule. Valid values are:
o FromOrder
o NonReschedulable
o Reschedulable
o Received
o RecommendOnly
o RecommendIfType
o Scheduled
 SplitLateSupply: Provides the option to split the on‐time portion of a planned supply from the
late portion. In other words, plan a portion of the supply on time even if the entire order cannot
be planned on time. This field only affects orders using at least one constraint that is
constrained.
 State: Specifies whether dependent requirements are generated. Used in conjunction with
SupplyType.Source to control the generation and timing of allocations.
 YieldRule: Specifies whether supplies use the yield ratio and coproduct yield ratio defined on
the part source. For example, this setting might be used for scheduled receipts at a later stage of
production where the yield factor no longer applies.
4.1.3.8 AvailableRule
This control table controls how available dates for a part’s supplies and demand are calculated. The
default rule of determining available dates using all capable‐to‐promise rules can be ignored for parts
that are considered unimportant in the calculation of availability using this table. The values in this table
are only applicable for parts whose Part.AvailableRule reference field is populated. Otherwise, the
part’s availability rule comes from the PartType.AvailabilityRule.
 ProcessingRule: Specifies how the availability of a part’s supplies and demands is calculated.
Valid values are:
o FromType (default)
o Ignore
o Normal
4.1.3.9 OrderPolicy
This control table specifies the rules for determining the size and dates for placing orders.
Fields of particular interest in Master Production Scheduling may include:
 LotSizeLastOrder: specifies whether to apply lot‐sizing rules (minimum order quantity,

maximum order quantity, multiple order quantity) to the last planned orders in the horizon
 OrderGenerationRule: controls how planned orders are generated; default is set to AnyTime
 PTFRule: specifies the planning time fence (PartSource.PTFDate) rule for each order policy, to
be used in determining planned order due dates
 UseFixedLeadTime: specifies, for each order policy, whether to consider the fixed lead time
(PartSource.FixedLeadTime) during MRP processing in the calculation of
ScheduledReceipt.CalcStartDate, PlannedOrder.StartDate, or both.
 UseVarLeadTIme: specifies for each order policy whether to use variable lead time in netting
calculations, used in calculating ScheduledReceipt.CalcStartDate or PlannedOrder.StartDate
 YieldUsage: specifies how to interpret yield values at the part level
4.1.3.10 OrderPriority
The OrderPriority table might become important in prioritizing the order in which demands are satisfied
or to prioritize the order in which supplies are consumed.
If the customer plans with order prioritization, it’s important that this table be verified and configured
appropriately based on the business rules.
Fields of particular interest may include:
 AllocationRule
 MaintainCommitments
 PeriodEffective
 PlanningPriority
 TwoDatePlanningRule and TwoDatePriorityLimit (New to 2015.3)
4.1.3.11 OnHandType
This control table specifies whether the stock or inventory is considered in netting and specifies the
rules for determining the availability of OnHand records in netting.
 ProcessingRule: Specifies whether the stock is used in netting. Valid values are:
o Nettable — considered in inventory netting calculations.
o NonNettable — not considered in inventory netting calculations.
4.1.3.12 SourceRule
This control table determines how PartSource values are interpreted when a part has more than one
active part source eligible to satisfy a given requirement. It can be used to determine how the target
percentage splits between suppliers are interpreted and thus used to determine the amount of the
planned requirements are sourced from each.

 AllotmentRule: indicates how a planned requirement is sourced when multiple eligible part
sources with the same priority exist
 PriorityRule: specifies how the PartSource.Priority field is interpreted when sourcing planned
requirements by priority
4.1.3.13 AssumptionType and AssumptionStatus

These would typically have been configured as part of the S&OP Application configuration. The installed
lists of Assumption Types (Categories) and Statuses are given below. There is no PDR installed that
allows you to edit, delete or add these values and they are not auto‐created. If you need to change
them, then you will need to create a worksheet on the AssumptionType and/or AssumptionStatus
tables.
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
4.1.3.14 HistoricalDemandCategory
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 HistoricalDemandCategoryType.
In order to determine Supply Plan records, and write the Supply Plan records to history, the Supply Plan
category must be defined, where Value = $DP_SupplyPlanCategory as outlined in the Profile Variables
section. It would typically have a ProcessingRule set to “None”.
Supply Planning targets (eg. SupplyPlanUnitTarget) are set in HistoricalDemandCategory as well, with
ProcessingRule set to “Target”.
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.
4.1.4 Detailed Data Requirements

4.1.4.1 Part
This table is typically set up as part of an initial RapidResponse deployment. If the parts are going to
include supply planning of any sort then all the supply policy fields must also be populated. Part supply
policy fields must be populated. Some general notes:
 All Part Types loaded for this must have a ProcessingRule of either MPS or MPSConfig in order
for the consensus forecast to be generated, and be used in supply planning.
 AverageSellingPrice: In order to use any of the currency disaggregation or reporting, it is
important to populate the AverageSellingPrice.
 SourceRule: If there are multiple active part sources defined for a part, the SourceRule
reference defines rules outlining how the source is chosen when satisfying a planned
requirement
 AvailableRule: This reference overrides the setting that comes from the
PartType.AvailableRule, and allows the control at a part level
 DemandTimeFence: field indicates the number of units of time after the
Part.PlanningCalendar.RunDate.FirstDate to establish a fence for controlling the use of
unconsumed forecast demands.
o Within the demand time fence, any unconsumed forecast is ignored and not planned for
by Netting; that is, it does not contribute to the total demand picture
o Outside the demand time fence, any unconsumed forecast does contribute to the total
demand and will be planned for by Netting.
o The demand time fence applies only to SalesForecast, not Production Forecast.
 IncrementalRule: Controls whether incremental availability calculations can be performed for
orders for this part (Referenced table: IncrementalRule)
 PartClass: *New field in 2015.3* Indicates the name of the part class, if any, associated with
this part. These classes are used by within the MPS application to classify parts and assign
planning, safety stock and replenishment strategies. Examples of values include Finished Goods,
Work In Progress, Raw Materials, Spare Parts
o It references the nullable Class table (new to 2015.3) and is in the Solutions namespace
o Replaces the PartSolution.PartClass field in previous versions, in order to facilitate
configuration of classes of parts. This option still exists for backward compatibility.
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 deleted in the
PartCustomer, and Historical tables.
4.1.4.2 PartSolution
This table stores application‐specific Part information, and is used in resources specific to Master
Production Scheduling (and Order Fulfillment). Note that the values in this table have no impact on
analytic results. New fields were added in 2015.3 to support the MPS application.
Fields of interest in the Master Production Scheduling application include:
 MPSAutoFirmWindow: Specifies the number of calendar intervals, expressed in

SOPAnalyticsConfiguration.CycleCalendar units, after the end of the MPS planning horizon
where a part’s planned orders get converted into firm MPS orders (via command).
o This field can be used to override the global default setting found in the
MPSConfiguration.AutoFirmWindow field, on a part by part basis.
o A value of 0 indicates that the part does not have an auto‐firm window. A value of ‐1 in
this field indicates that the global setting (MPSConfiguration.AutoFirmWindow) should
be used.
o Default value is ‐1
o The part’s effective MPS auto‐firm window, from either the PartSolution or
MPSConfiguration tables, is then reported in
PartSolution.EffectiveMPSAutoFirmWindow
o Used in the Master Scheduling workbook command “Auto Firm MPS” and can be
configured by the user in the Planning Parameters workbook
 MPSFrozenWindow: Specifies the length of the MPS frozen window for this part, expressed in
MPSConfiguration.Calendar intervals. Recall, the MPS frozen window is the period of time in
which changes to MPS orders are strongly discouraged, due to a variety of business factors such
as order lead times, costs.
MPSConfiguration.FrozenWindow field, on a part by part basis
o A value of 0 indicates that the part does not have a frozen window. A value of ‐1
indicates that the global setting (MPSConfiguration.FrozenWindow) should be used.
o The part’s effective MPS frozen window, from either the PartSolution or
MPSConfiguration tables, is then reported in PartSolution.EffectiveMPSFrozenWindow
o Used in the Master Scheduling and MPS Widgets workbooks
o Can be configured by the user in the Planning Parameters workbook
 MPSHorizon: Specifies the length of the MPS planning horizon for the part, expressed in
MPSConfiguration.Calendar intervals, where orders within this window are assumed to be fully
under the control of the Master Scheduler
MPSConfiguration.Horizon field, on a part by part basis.
o A value of 0 indicates that the part does not have an MPS planning horizon. A value of ‐
1 indicates that the global setting (MPSConfiguration.Horizon) should be used.
o The part’s effective MPS horizon, from either the PartSolution or MPSConfiguration
tables, is reported in PartSolution.EffectiveMPSHorizon
o Used in the Master Scheduling and MPS Widgets workbooks
o Can be configured by the user in the Planning Parameters workbook
 DemandPlannerCode, MasterSchedulerCode, InventoryPlannerCode: Specify the Demand
Planner, Master Scheduler and Inventory Planners responsible for the part
o Used for collaboration in Master Production Scheduling resources
 PartClass: 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.
o Note that in 2015.3SU6, there is reference to a new Class table on the Part table, which
will allow customer‐specific and easier customization of inventory part classes beyond
the 3 (former) Enum values of Raw Material, WIP, Finished Goods. (RR‐66358)
o Planning Parameters uses this new reference to Class table.
o This Enum field will remain for backward compatibility.
 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.
 KeyPart: This is a Boolean field to identify a Part as being a Key or Critical part within a
BillofMaterial. Key Parts are focused on in supply planning analysis as they have pertinent
limitations (long lead times, single sourced, etc.) to the long term plan.
o Referenced in the Planning Parameters workbook, to filter values and parts displayed
4.1.4.3 Class
New nullable table introduced in the Solutions namespace in 2015.3SU6. It is used to define standard
part classes (Finished Goods, Work in Progress, Raw Materials, Spare Parts, etc.) and custom classes
(Consumables). Its intent is to provide functionality similar to the Solutions::PartSolution.PartClass field,
where categories of parts can be identified and used in reporting. It provides more flexibility in
configuration, as it is not an enum field. It is a reference from the Mfg::Part.PartClass field.
Fields of interest in Master Production Scheduling might include:
 Value: specifies the category of parts; it is expected that these values will vary by business, but
will likely consist of FinishedGoods, RawMaterials, WorkInProgress, SpareParts, Consumables,
etc.
The Solutions::PartSolution.PartClass Enum field still exists to provide backward functionality, but it is
expected that part Class values be configured in this table. Resources within the Master Production
Scheduling application have been configured to display the values defined in this table.
It is important that the Class.Value categories be configured at Integration, or the resources referencing
this won’t be populated, and widgets won’t render correctly. The main reference is found in the
Planning Parameters workbook.
4.1.4.4 PartSource
All parts should have valid Part sources defined, with supply planning fields populated. Some fields of
interest to Master Production Scheduling include:
 MaximumQty, MinimumQty, MultipeQty: needed to define order quantities, lot sizing for
allocation and availability calculations
 PlanningTimeFence: required to determine the timing of generation of new planned orders
 OrderPolicy: reference to OrderPolicy table required to specify rules for determining size and
dates for placing orders
 Priority: required to dictate the selection of a PartSource to supply a requirement; important
when there are multiple active PartSources that can either provide the supply on time or equally
late
 FixedLeadTime, DockToStockLeadTime, VarLeadTime, SafetyLeadTime: used when determining
planned order due dates
 Target: required to determine the percentage split of planned requirements among active part
sources (of the same priority)
 EffectiveInDate and EffectiveOutDate: define the period over which the part source record is
valid
4.1.4.5 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. Hierarchies require the presence of valid PartCustomer records.
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.
 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
DP_BaseCalendar 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.
 Pool: If forecast consumption by Pool is required, then you can set the Pool for this
PartCustomer on this reference. Usually, we expect the Pool to be 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 decorated to
include the 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. Used for allocating limited supply to demands.
 MinimumShelfLife: You can override the Part.MinimumShelfLife for forecasts from this
PartCustomer here.
4.1.4.6 Customer and CustomerGroup

With PartCustomer being a base table, there is a need to define Customer records as well.
At least one aspect of hierarchies is usually associated with customer characteristics, resulting in custom
fields or references from either Customer or CustomerGroup tables.
4.1.4.7 BillOfMaterial
A fundamental table used to show parent and component relationships, and is used in both demand and
supply planning.
Some fields of interest to Master Production Scheduling may include:

 EffectiveInDate and EffectiveOutDate: specify the dates on which the BillOfMaterial record will
become effective and cease to be effective, respectively.
 LeadTimeOffset: Specifies the number of time units, defined by the
Assembly.PlanningCalendars.TimeUnits field, to offset the required DueDate of the
components used in the assembly. This is especially useful for long assembly operations.
 QuantityPer: Specifies the amount of the component that is required to build each finished
assembly.
Note that the Master Production Scheduling application does not, at this time, support Feature BOMs.
Those records where PartType.FeatureBOMRule and/or BillOfMaterial.FeatureRule are filtered out of
the Master Scheduling resources.
4.1.4.8 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 where there is a valid UOM conversion factor for the UOM
currently chosen.
Similarly, if the targets are revenue targets, there must be either a Part.AverageSellingPrice defined or
effective records in the CustomerPrice table for the Part/Customers for the targets to include those
PartCustomers.
4.1.4.9 OnHand
This table stores the amount of inventory and other details for a part in a particular location, including
the reference to the OnHandType table and associated processing rule. It is used to determine the
available On Hand quantities during the supply planning process.
4.1.4.10 Source and Supplier

The Source table stores information about deliveries, and includes information pertaining to pre‐ship
lead time and transit lead time. This table is referenced from the PartSource table.
The Supplier table is the repository for supplier information, such as a vendor for a purchase order. The
Site field is optional, and can be configured to either uniquely identify records or be ignored in queries.
4.1.4.11 ScheduledReceipt and SupplyOrder

The SupplyOrder table is a repository for supply order information. Often supply orders are written up
for multiple parts on a single order form. The header information is the common information about the
whole order. Individual line items are entered in the ScheduledReceipt table.
The ScheduledReceipt table contains supply for a single part that has an assigned due date. This table is
used during the supply planning process to determine scheduled supply available to satisfy demand.
Some fields of interest in Master Production Scheduling may include:
 Part
 Site
 DueDate
 StartDate
 Qty
 Order
 Line
 OriginalRecordId
4.1.4.12 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.13 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.
This table is also used to store Target records, such as annual plan targets, when the
Header.Category.Type.ProcessingRule = “Target”.
4.1.4.14 HistoricalDemandHeader
This table identifies each unique part, customer and historical demand category combination. Typically
it is referenced by multiple groups of historical demands, forecasts and other items, including
ForecastDetails records.
4.1.4.15 HistoricalSupplyHeader
This table identifies each unique part, supplier, and historical supply category combination. Each of the
entries in this table are typically associated with multiple historical supply series or historical supply
actual records.
 References the HistoricalSupplyCategory and PartSupplier tables
4.1.4.16 HistoricalSupplyCategory
This table identifies different categories of historical supply series and historical supply actuals, in the
HistoricalSupplySeries and HistoricalSupplyActual tables.
4.1.4.17 HistoricalSupplyActual
HistoricalSupplyActual records are stored as a set of vector data on the HistoricalSupplyHeader table.
Note that that currency of these records must be defined through the Header and can’t be defined on
the specific HSA record.
Fields of interest in the Master Production Scheduling application include:
 OrderDueDate: Specifies the DueDate associated with the historical supply order.
o Contained within the Solutions namespace
o Should be populated for the MPS application in order to properly report on MPS
attainment details (widget and treemap)
4.1.4.18 HistoricalSupplySeries and HistoricalSupplySeriesDetail

These tables contain one record for each HistoricalSupplyHeader and particular AsOfDate (the date
when the supply records were generated) and Sequence (in cases where multiple series were generated
on the same date). Each historical supply series entry corresponds to a collection of points that make up
one set of historical supplies (for a given part, supplier, category, and as‐of date).
The records from these tables are used in the reporting of the Supply Plan in the Master Production
Scheduling workbook and Master Scheduling Summary widget, in addition to reporting MPS plan
records to history in the Write History Records workbook.
4.1.4.19 PlannerCodes
This table contains a list of valid planner codes, which are used to identify a person or job responsibility
for a part. Responsibility is used heavily in the Master Production Scheduling application, in the
resolution of MPS issues, therefore valid planner codes should be populated.
4.1.4.20 Constraint, ConstraintAvailable, ConstraintGroup, SourceConstraint

Note that if Capacity Planning (Constraints) is purchased, the Constraint‐related tables above will be
required. The detailed data can come into RapidResponse via data extract if the data is stored in an
external source system, or maintained in RapidResponse. Please see the Capacity Planning (Constraint)
application summary document for detailed configuration notes.
This includes the configuration of Constraint.KeyConstraint field, in order to properly report on Key
Constraint overloads and underloads in the MPS widgets.
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 Data Integrity‐ Material workbook can be used to monitor the accuracy of data that is supporting
the Master Production Scheduling application. Review the workbook and worksheet help for more
detailed information on the data integrity checks this resource performs.

Application Summary Document - Master Production Scheduling

Uploaded by

Document Information

Original Description:

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 - Master Production Scheduling

Uploaded by

Copyright:

Available Formats

RapidResponse

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

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

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

Application User Interfacing Data Touch Points

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

• Material and capacity* constrained master scheduling

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

1.4 Roles and Responsibilities

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

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

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

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

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

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

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

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

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

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

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

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

Copyright © 2016 Kinaxis. All rights reserved. Page 22 of 66

Scenario Purpose Permanent? Shared? Modify/ Auto‐

Also contains Integrated Project Management Project Actuals (working

Child scenarios are committed into Baseline (Master Production

Copyright © 2016 Kinaxis. All rights reserved. Page 23 of 66

Updated on a scheduled frequency determined at integration. It is

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

Committed into Baseline on a scheduled frequency determined at

Prior to commit, this scenario is used in multi‐scenario comparison,

Scheduled update on a frequency determined at Integration, typically

Copyright © 2016 Kinaxis. All rights reserved. Page 24 of 66

It is likely that multiple levels of private scenarios exist under Master

Data Integration Server Recommendations

Copyright © 2016 Kinaxis. All rights reserved. Page 25 of 66

The MPS Risks tab reports:

 MPS Exceptions: Scenario Compare

The Performance Metrics tab reports:

 Master Scheduling Summary

The Corporate Metrics tab reports:

The metrics contained within the Master Scheduler scorecard are:

 Master Production Scheduling

The following workbooks support dashboard widgets and scorecard metrics:

 MPS Late Revenue Treemap

4.1.2 Configuration Points

No Variable Name Description Default Value

No Variable Name Description Default Value

Variable Name Type Value

No Variable Name Description Default Value

No Variable Name Description Default Value

No Macro Name Expression Description

Name Type Description Expected Frequency

Defined to modify data in

Defined to modify data in

Name Type Description Expected Frequency

 Manual Inventory Transfer Adjustments

4.1.2.5 Pre‐defined Filters

The filter expression is defined as:

HAS PartCustomers [Part.PrimaryPartSource.FirstEffectiveDate >= MRPDate ‐ 1

On install the following hierarchies are available to users:

The Constraint hierarchy consists of the following levels:

The Constraint Region hierarchy consists of the following levels:

The Customer hierarchy consists of the following levels: