Forecast V2 Revision

The basic idea behind this redesign is to decrease vertical scrolling and make the forecasting screen look better. By default, we will now show Forecasts and Commitments for People and Forecasts only for Expenses (because Expense Commitments can not be edited, while People Commitments can be). Across the top of each forecasting block will be Show/Hide Forecasts, Show/Hide Commitments, and Show/Hide Actuals (as toggles where the titles change based on the state of the screen).

People Commitment Rows, when changed, will have a darker color background and different icon. If the line is reverted, the "Edited" treatment is removed.

Add a Legend for the Forecast, Commitment and Actual icons.

Page Mockup:

Further details:

Page Layout: This page consists of a main grid/form for forecasting, a forecasting totals block that follows the user as they scroll down, and a "To Be Hired" block that contains To Be Hired templates (grad student, research assistant, research scientist, etc.). The forecasting form/grid is further broken down into GL sections, one for each of the high level CEMIT or Approved GLS. Each GL block contains a subtotals block within it.

Functional Summary: On first entry, the left nav. is hidden, the name (chosen when creating) is applied and description is blank, GL blocks: People, Expenses, (further defined into subsets: M&S, Travel, Equipment, SubAwards and other) and Revenue are open, and the people are shown in their data range view. Within each block the default view is: Forecasts and Commitments for People and Forecasts only for Expenses (because Expense Commitments can not be edited, while People Commitments can be). If the user wants, they can close or open each block of existing commitments, actuals, and forecasts.

In addition and not shown in the image is a "Add new row" button on each block. If a user wants to add a To Be Hired, they click on them and a new row is added that contains the defaults from the To Be Hired they clicked on, which can then be edited.

Any time a user creates a new forecast, they are taken here with the name and description open for editing. If they are editing an existing forecast, they also come here and again the name and description are open for editing. If a user edits the title, this does NOT create a new forecast, it just edits the existing name (we maintain a unique forecast id under the hood). A forecast is saved in a special table in the backend, one per user. This table allows users to edit one forecast as much as they want without committing it. When they click Save, the system will validate the forecast and save it if it passes validation.

Description of the Page: This page gives a user the ability to edit a particular cost object forecast. Users can add a line (person, TBH, expense or revenue) then edit it. In addition to adding new lines, users can edit existing speculations.

A forecast can be published (copied) to the following three places: the PI Workset/Scenario, the Department Workset/Scenario, or the Common/MIT ALL Scenario.

Table 1: Common User Interface Elements for the Forecasting Detail Page

This table includes all elements that appear on this page. Flag elements that have appeared on other pages.

Element	Control	Functional Description	Technical Rules
Name field	text input	User stores and edits Forecast name	Defaults to "MIT-All Forecast", key is COMMON (which is MITALL)
Show/hide forecasts, actuals and commitments	checkbox	User clicks on it to show or hide existing commitments	Defaults to forecast checked for people, expenses, revenue blocks, commitments also checked for people
People name field	text input	User can search for person (autocomplete)	After third keydown, set timeout for 300 miliseconds, if no further keydown, execute search call (wait until the user pauses).
Appointment field	dropdown list (select)	Until you choose a person, the only thing in the Appointment field is a dropdown that says "Choose person first." If you choose a person, the appointment field gets filled with the one or more appointments they have. If they choose a TBH, the appointment is filled in by the choice.	Disable all subsequent fields until an appointment or TBH is chosen.
Start Date	text input	need to find out rules	Need to find out the rules (currently validates via an input mask and initial values are set)
End Date	text input	need to find out rules	Need to find out the rules (currently validates via an input mask and initial values are set)
% (Allocation)	text input	User enters number	Required field. Floating number rounded to nearest two decimals (percentage), hidden until appointment is chosen
Pay Rate	text input	Number populates from system once People name and Appointment is selected	Floating number rounded to nearest two decimals, hidden until appointment is chose. Should be 0 for TBH.
On Campus?	check box	User indicates if appointee is on campus. (pre-populates)
Tuition	text input	Number populates from system once Person name and Appointment is selected	Floating number locked to two decimals (money), hidden until appointment is chosen. For non-students and others, when the field is N/A, it is not editable.
All Expenses: Expense category	dropdown list (select)	User choose an expense category from 5 options.	Required field within All Expenses. Alternatively, the category is pre-populated within the specific subset tabs.
Name field: Expenses	text input	User enters name in field	Required field.
Name field: Revenue	text input	User enters name in field	Required field.
Item cost	text input	User inputs total cost amount	Required field. Floating number locked to two decimals (money).
Rolls Off?	check box	User checks box or not
Revenue amount	text input	User inputs total amount	Required field. Revenue amount appears negative since it is incoming.
Comment	text area	User enters description. User can grow text box if wanted	Not required. Shrink text area to make inline row, let them expand it they want.
Add Row	button	Adds new forecast row of the same type below existing lines
Save button	button	Saves forecast to back end. Gives user Saved feedback via Growl	Always appears.
Share Button	button	Takes user to authorizations tab.	Disable button when forecast is "dirty", enable it when button is saved "clean"
Publish Button	button	Opens dialog that asks user where do they want to publish to: PI, Department or MITALL	Disable button when forecast is "dirty", enable it when button is saved "clean". See spec at top of page.

Table X: Validation Rules for [name of page] Page

Valida	Message
cell A1	Lorem ipsum dolor sit amet
cell B1	Consetetur sadipscing elitr
cell C1	Sed diam nonumy eirmod tempor inviduant ut labore
cell D1	Labore et dolore magna aliquyam erat, sed diam voluptua

Repeat for each screen of the application.

DISP handling:

Breakdown of people line types
DISP	Description	changePerson	changeAppt	editAppt	changeSpeculation
ACT	Historical info from SAP	N	N	N	N
COMM	Commited info from ESDS	N	N	N	Y
FORC	Forecasted person from RAFT	Y	Y	N	Y
TBH	TBH – synthetic person defined in RAFT	N	N	Y	Y



Notes
An edited COMM is currently returned as a FORC. This will be corrected

ChangePerson = change the name/personnel key
ChangeAppt = select a different appt from a list of appts.
EditAppt = Edit the appt information (salary, pay_rate)
ChangeSpeculation = Edit the allocation %

Publish Dialog Description:

The publish dialog has three modes: PI, Department and Common. PI and Department each have two submodes: Overwrite Existing Forecast and Create New Forecast. Publishing to Common ALWAYS is an overwrite of the existing single forecast. Publishing is a one time copy of the forecast information on a single cost object. The source cost object and the destination cost object MUST be the same to copy a forecast. What differs is whether the forecast ALREADY EXISTS on the destination cost object, in which case the user will be overwriting it, or if it does not exist, the user is ADDING it to the existing forecasts on that cost object.

Code Flow Chart for Publish Dialog:

Get forecast name from Forecast Model, display it in Source Forecast/ Forecast Name field.
Get forecast cost object name from raft.data.CostObject.COTITLE, display it in Source Forecast/ Forecast Cost Object field.
Get forecast workset name from raft.data.Workset.title, display it in Source Forecast/ Forecast Workset field.
If raft.data.CostObject.Forecasts[] has at least one forecast with a workset_category of Department, show these three radio buttons: PI, Department, Common, else show: PI and Common. Put change event listener on the radio buttons.

1. PI RadioButton Clicked

Show Overwrite Existing and Create New buttons. Add click listeners to both.
Show Overwrite Destination Forecast in dialog. Add click listener.

1a. PI Overwrite Destination Forecast Button Clicked

Display in Destination Forecast the Name of the PI, which is raft.data.CostObject.SUPERVISOR.
Get forecast cost object name from raft.data.CostObject.COTITLE, display it in Destination Forecast/ Forecast Cost Object field.
Get the list of forecasts to display by calling GET: /rest/v2/costobject/:id/scenario and looking for workset_category == PI. All PI Forecasts should be listed in the Destination Forecast List.
On click, call publish/share forecast with the selected forecast key as the destination scenarioKey, and the rest of the data from above as needed. If successful, close dialog, else show error in dialog somewhere.

1b. PI Create New Forecast Button Clicked

Display in Destination Forecast the Name of the PI, which is raft.data.CostObject.SUPERVISOR.
Get forecast cost object name from raft.data.CostObject.COTITLE, display it in Destination Forecast/ Forecast Cost Object field.
Insert a Forecast Name field. Need to check with Amon if publish call can make a new Forecast on the fly. May also need a forecast description field in the dialogue.
Add a Copy Forecast button and an event listener.
When user clicks on it, call publishForecast, if successful, close dialog, else, show error.

2. Department RadioButton Clicked

Show Overwrite Existing and Create New buttons. Add click listeners to both.
Show Overwrite Destination Forecast in dialog. Add click listener.

2a. Overwrite Destination Forecast button clicked

Display the Word "Department" in the Destination Workset
Get forecast cost object name from raft.data.CostObject.COTITLE, display it in Destination Forecast/ Forecast Cost Object field.
Get the list of forecasts to display by calling GET: /rest/v2/costobject/:id/scenario and looking for worksetCategory == Department. All Department Forecasts should be listed in the Destination Forecast List.
On click, call publish/share forecast with the selected forecast key as the destination scenarioKey, and the rest of the data from above as needed. If successful, close dialog, else show error in dialog.

2b. Create new Forecast button clicked

Display the word "Department" in the destination workset
Get forecast cost object name from raft.data.CostObject.COTITLE, display it in Destination Forecast/ Forecast Cost Object field.
Display an input field, labeled "Destination Forecast Name"
Display a button below it labelled Add New Forecast and an event listener for it.
When user clicks on Add New Forecast, call copyForecast to the Department Workset with the current cost object as the source and destination cost object and the new forecast name as the destination forecast (call may not accept a blank, so we have to talk to Amon) (see 1b 3). If successful, close dialog, else, show error.

3. Common RadioButton clicked

Add Overwrite Common Forecast button and Cancel Button(there is one and only one forecast per Cost Object in the Common area).
Show Destination Forecast area, set Destination Workset to Common
Set Destination Cost Object to the same as Source Cost Object.
Set Destination Forecast to "Name of Cost Object" + Forecast.
Put warning message in Dialog: "Warning: Copying this forecast to Common will overwrite the existing forecast. You will be overwriting the existing forecast information that ALL MIT authorized users view for this cost object. Are you sure you want to overwrite the forecast for this Cost Object?
Overwrite Common Forecast calls publishForecast with source workset, cost object and scenario id as sources and Common as destination. If success, close dialog, if failure, show dialog in error.
If user clicks Cancel button, close dialog and empty form fields.

Sharing Dialog

The sharing dialog opens when the user clicks on the Share Forecast button. It is built as follows:

Set up the source forecast information the same as we do for Publish.
Make the get call to list worksets for sharing CALL WILL BE LISTED HERE. Remove the Source Workset from the list.
Display the resulting list to the user.
User selects one of the worksets and clicks Share Forecast.
Call the standard publishForecast call with appendCO = true and the destination workset set to the one the user chose.

Version 1 Docs (deprecated)

Page Mockup:

Page Layout: This page consists of a main grid/form for forecasting, a forecasting totals block that follows the user as they scroll down, and a "To Be Hired" block that contains To Be Hired templates (grad student, research assistant, research scientist, etc.). The forecasting form/grid is further broken down into GL sections, one for each of the high level CEMIT or Approved GLS. Each GL block contains a subtotals block at the bottom.

Functional Summary: On first entry, the left nav is hidden, the name and description are blank, all GL blocks are open, and the people are shown in their data range view. If the user wants, they can close each block of existing commitments. Above each existing commitment in each GL block is an empty row so users can immediately begin forecasting. When a user gets to the last input field in the row, a new blank row is automatically added. In addition and not shown in the image is a "Add new row" button on each block. If a user wants to add a To Be Hired, they click on them and a new row is added that contains the defaults from the To Be Hired they clicked on, which can then be edited.

Any time a user creates a new forecast, they are taken here and have to supply a new name and description. If they are editing an existing forecast, they also come here but the name and description are open for editing. If a user edits the title, this does NOT create a new forecast, it just edits the existing name (we maintain a unique forecast id under the hood). A forecast is saved in a special table in the backend, one per user. This table allows users to edit one forecast as much as they want without committing it. When they click Save, the system will validate the forecast and save it if it passes validation.

Description of the Page: This page gives a user the ability to edit a particular cost object forecast. Users can add a line (person, TBH, expense) then edit it. Users can edit existing speculations that came from SAP as People Commitments from ESDS and as Blanket POs or Manual Commitments for expenses.

A forecast can be published (copied) to the following three places: the PI Workset/Scenario, the Department Workset/Scenario, or the MIT ALL Scenario.

Specify user all actions available on the page. Specify destination of navigation buttons or hyperlinks. Insert one or more annotated screen mock ups to show the page in representative states.