Engineering Data Submission Tool User Guide user guide_v… · Web view2021. 1. 8. · The...

Engineering Data Submission Tool User Guide

Engineering Data Submission Tool User Guide

Version 4

12/30/2020

Revision History:

Date

Version

Author

Description

4/9/2018

1

SPP Staff

Initial Creation

6/19/2018

2

SPP Staff

Update Wording

12/30/2019

3

SPP Staff

EDST 2.3 Release

12/30/2020

4

SPP Staff

EDST 2.5-2.7 Release

Disclaimer:

Southwest Power Pool, Inc.

The information in this document is designed to provide a helpful guide on use of the Engineering Data Submission Tool (EDST). The data used and displayed in figures are fictitious data created for development of this user manual. SPP disclaims liability for any inaccuracies or omissions that may have occurred. The data submitted in EDST is confidential and proprietary information. Distribution of this data should first be approved through SPP Staff.

Page ii

Table of Contents

1Engineering Data Submission Tool Overview1

1.1Overview1

1.2Introduction1

2Getting Started4

2.1Gaining Access to EDST4

2.2Logging In6

2.3Resetting a Password9

3User Interface Layout and Changeset Lifecycle Summary11

3.1User Interface Layout11

3.1.1Navigation Menu11

3.2Home page12

3.3Changeset Status Options and Changeset Lifecycle14

3.4General Layout for Data Maintenance Screens18

3.4.1Basecase Data18

3.4.2Changeset Operations19

3.4.3Changeset Details21

4Menu Navigation Screens29

4.1Administration Screens29

4.1.1Changeset History29

4.1.2User Management30

4.1.3Historical Data32

4.2Model Development33

4.2.1Branches (Transmission Tie Line)33

4.2.2Bus Details33

4.2.3Generators33

4.2.4Load Details33

4.2.5Transactions33

4.2.6Transformers 2 Winding (Transmission Tie Line)34

4.2.7Transformers 3 Winding (Transmission Tie Line)34

4.2.8Two Terminal DC Ties34

4.2.9Transformers 2 Winding , Transformers 3 Winding, Bus, Generator, Branches and Shunt Outages34

4.2.10Changeset Workflow34

4.3Resource Adequacy45

4.3.1Processes considering multiple screens46

4.3.2Capacity Adjustments48

4.3.3Deliverability Study Results53

4.3.4Demand and Energy56

4.3.5Generator Test Results58

4.3.6Plants67

4.3.7Purchases and Sales75

4.3.8Resource Adequacy Requirement90

4.3.9Resource Ownership96

4.3.10Resources108

4.3.11Ten Year Forecast Overview118

4.3.12Contact List122

4.4Postings and Events122

5Data Entry and Validations123

5.1Data Entry123

5.2Semantic Validations123

5.3First and Second-tier Validations124

5.4Model Development Validations125

5.4.1Branches125

5.4.2Bus Details125

5.4.3Generator Data126

5.4.4Load Details126

5.4.5Transactions126

5.4.6Transformers 2 Winding127

5.4.7Transformers 3 Winding128

5.4.8Two Terminal DC Ties129

5.4.9Branch Outages129

5.4.10Bus Outages129

5.4.11Fixed Shunt Outages130

5.4.12Generator Outages130

5.4.13Switched Shunt Outages130

5.4.14Transformer 2 Winding Outages130

5.4.15Transformer 3 Winding Outages131

5.5Resource Adequacy Validations131

5.5.1Demand and Energy131

5.5.2Plants133

5.5.3Purchases and Sales134

5.5.4Resource Ownership139

5.5.5Resources140

5.5.6Generator Test Results141

Appendix 1: List of Acronyms and Initialisms144

Appendix 2: Detailed Changeset Flowchart145

Appendix 3: Resource Adequacy Entities146

Table of Figures

Figure 1: EDST Architecture2

Figure 2: Initial Login Email4

Figure 3: Initial Login – Password Email4

Figure 4: Initial Login – Login Screen5

Figure 5: Security Code Email Notification5

Figure 6: Login Verification Screen5

Figure 7: Initial Login – Click on Username6

Figure 8: Initial Login – Reset Password6

Figure 9: Login Screen7

Figure 10: EDST Login Error Message7

Figure 11: EDST Login Error Number7

Figure 12: Security Code Email Notification8

Figure 13: Login Verification Screen8

Figure 14: EDST Dashboard9

Figure 15: Login Screen – Reset Password9

Figure 16: Enter Email – Reset Password10

Figure 17: Enter New Password – Reset Password10

Figure 18: User Interface Layout – Navigation Menu12

Figure 19: High-level overview of changeset process17

Figure 20: General layout for data maintenance screens18

Figure 21: Basecase Data Section – filter options19

Figure 22: Basecase Data Section – option to add rows to Changeset19

Figure 23: Changeset Operations Layout20

Figure 24: Changeset Details Layout22

Figure 25: Changeset Details – Edit / Delete Record24

Figure 26: Changeset Details – Export Changeset to Excel26

Figure 27: Changeset History – User Changesets29

Figure 28: Changeset History – Selected Changeset Details29

Figure 29: Changeset History – Validation messages30

Figure 30: Changeset History – Attached Documents30

Figure 31: User Management Screen31

Figure 32: Historical Data – Year and Data Set Selection32

Figure 33: Historical Data Grid33

Figure 34: Creation of Changeset – EDST Dashboard35

Figure 35: Creation of Changeset – Changeset Operations Section35

Figure 36: Creation of Changeset – Add Records to Changeset36

Figure 37: Creation of Changeset – Changeset Details36

Figure 38: Create Changeset – Save Changeset37

Figure 39: Adding Records to Changeset – Save Changeset38

Figure 40: Deleting Records from Changeset – Changeset Details39

Figure 41: Warning Validation Message40

Figure 42: Return Changeset to DRAFT – Changeset Details40

Figure 43: Abandon Changeset – Changeset Details41

Figure 44: Adding Records to Basecase Data – Changeset Details41

Figure 45: Removing Records from Basecase Data – Changeset Details42

Figure 46: Flow Chart for Adding a New Plant or Resource47

Figure 47: Capacity Adjustments – Changeset Operations48

Figure 48: Capacity Adjustments – Data Editing Section49

Figure 49: Capacity Adjustments – Submitting Entity Selection50

Figure 50: Capacity Adjustments – Editing Data51

Figure 51: Capacity Adjustments – Return Changeset to DRAFT52

Figure 52: Capacity Adjustments – Abandon Changeset53

Figure 53: Deliverability Study Results – Data Selection Options54

Figure 54: Deliverability Study Results – Export to Excel54

Figure 55: Deliverability Study Results –Summary Table55

Figure 56: Deliverability Study Results – Submitting Entity Summary Table55

Figure 57: Deliverability Study Results – Resource Ownership Summary Table56

Figure 58: Demand and Energy – Changeset Operations56

Figure 59: Demand and Energy – Monthly Submissions57

Figure 60: Demand and Energy – Yearly Submissions57

Figure 61: Demand and Energy – Demand-Side Management Submissions58

Figure 62: Generator Test Results – Basecase Data59

Figure 63: Generator Test Results – Changeset Operations59

Figure 64: Generator Test Results – Action Buttons61

Figure 65: Generator Test Results – Changeset Details – Export Changeset to Excel62

Figure 66: Generator Test Results – EDST Drop Down Menu62

Figure 67: Generator Test Results – Create Changeset63

Figure 68: Generator Test Results – Open Existing Changeset63

Figure 69: Generator Test Results – Creation of Changeset – Add Records to Changeset64

Figure 70: Generator Test Results – Creation of Changeset – Save Changeset64

Figure 71: Generator Test Results – Delete Record from Changeset65

Figure 72: Generator Test Results – Adding Records to Basecase – Changeset Details65

Figure 73: Generator Test Results – Removing Records from Basecase – Changeset Details66

Figure 74: Generator Test Results – Return Changeset to DRAFT – Changeset Details67

Figure 75: Generator Test Results – Abandon Changeset – Changeset Details67

Figure 76: Generator Test Results – Confirm Abandon Changeset67

Figure 77: Plants – Basecase Data68

Figure 78: Plants – Changeset Operations68

Figure 79: Plants – Action Buttons69

Figure 80: Plants – Changeset Details – Export Changeset to Excel70

Figure 81: Plants – EDST Drop Down Menu70

Figure 82: Plants – Create Changeset71

Figure 83: Plants – Open Existing Changeset71

Figure 84: Plants – Creation of Changeset – Add Records to Changeset72

Figure 85: Plants – Creation of Changeset – Save Changeset72

Figure 86: Plants – Delete Record from Changeset73

Figure 87: Plants – Adding Records to Basecase – Changeset Details73

Figure 88: Plants – Removing Records from Basecase – Changeset Details74

Figure 89: Plants – Return Changeset to DRAFT – Changeset Details75

Figure 90: Plants – Abandon Changeset – Changeset Details75

Figure 91: Plants – Confirm Abandon Changeset75

Figure 92: Purchases and Sales – Basecase Data78

Figure 93: Purchases and Sales – Changeset Operations78

Figure 94: Purchases and Sales – Changeset Details82

Figure 95: Purchases and Sales – Action Buttons82

Figure 96: Purchases and Sales – Changeset Details – Export Changeset to Excel83

Figure 97: Purchases and Sales – EDST Dashboard84

Figure 98: Purchases and Sales – Creation of Changeset – Changeset Operations84

Figure 99: Purchases and Sales – Open Existing Changeset – Changeset Operations85

Figure 100: Purchases and Sales – Adding Records to Changeset – Basecase Data85

Figure 101: Purchases and Sales – Creation of Changeset – Save Changeset86

Figure 102: Purchases and Sales – Delete Records from Changeset – Changeset Details87

Figure 103: Purchases and Sales – Adding Records to Basecase Set of Data87

Figure 104: Purchases and Sales – Removing Records from Basecase Set of Data88

Figure 105: Purchases and Sales – Changeset Details After Changeset is Submitted88

Figure 106: Purchases and Sales – Confirming Entity Actions – Changeset Details89

Figure 107: Resource Adequacy Requirement – Data Selection Options91

Figure 108: Resource Adequacy Requirement – Export to Excel91

Figure 109: Resource Adequacy Requirement – Capacity Summary Graph92

Figure 110: Resource Adequacy Requirement – Capacity Summary Table92

Figure 111: Resource Adequacy Requirement – Resource Fuel Type93

Figure 112: Resource Adequacy Requirement – PRM Summary93

Figure 113: Resource Adequacy Requirement – Net Peak Demand Summary Graph94

Figure 114: Resource Adequacy Requirement – Peak Demand Summary Table94

Figure 115: Resource Adequacy Requirement – Forecasted Peak Demand Comparison95

Figure 116: Resource Adequacy Requirement – Requirements Summary Table95

Figure 117: Resource Ownership – Basecase Data98

Figure 118: Resource Ownership – Changeset Operations98

Figure 119: Resource Ownership – Changeset Details100

Figure 120: Resource Ownership – Action Buttons101

Figure 121: Resource Ownership – Changeset Details – Export Changeset to Excel101

Figure 122: Resource Ownership – EDST Dashboard102

Figure 123: Resource Ownership – Create Changeset102

Figure 124: Resource Ownership – Open Existing Changeset103

Figure 125: Resource Ownership – Adding Records to Changeset – Basecase Data103

Figure 126: Resource Ownership – Creation of Changeset – Save Changeset104

Figure 127: Resource Ownership – Delete Record from Changeset105

Figure 128: Resource Ownership – Adding Records to Basecase – Changeset Details106

Figure 129: Resource Ownership – Removing Records from Basecase – Changeset Details106

Figure 130: Resource Ownership – Return Changeset to DRAFT – Changeset Details107

Figure 131: Resource Ownership – Abandon Changeset – Changeset Details108

Figure 132: Resource Ownership – Confirm Abandon Changeset – Changeset Details108

Figure 133: Resources – Basecase Data109

Figure 134: Resources – Changeset Operations110

Figure 135: Resources – Action buttons112

Figure 136: Resources – Changeset Details – Export Changeset to Excel112

Figure 137: Resources – EDST Drop Down Menu113

Figure 138: Resources – Create Changeset114

Figure 139: Resources – Open Existing Changeset114

Figure 140: Resources – Creation of Changeset – Add Records to Changeset114

Figure 141: Resources – Creation of Changeset – Save Changeset115

Figure 142: Resources – Delete Record from Changeset116

Figure 143: Resources – Adding Records to Basecase – Changeset Details116

Figure 144: Resources – Removing Records from Basecase – Changeset Details117

Figure 145: Resources – Return Changeset to DRAFT – Changeset Details118

Figure 146: Resources – Abandon Changeset – Changeset Details118

Figure 147: Resources – Confirm Abandon Changeset118

Figure 148: Ten Year Forecast Overview – Data Selection Options119

Figure 149: Ten Year Forecast Overview – Export to Excel119

Figure 150: Ten Year Forecast Overview – Fuel Type Summary120

Figure 151: Ten Year Forecast Overview – Reserve Margin Trend120

Figure 152: Ten Year Forecast Overview – Capacity Summary – Data Calculation Tables121

Figure 153: Ten Year Forecast Overview – Demand Summary – Data Calculation Tables121

Figure 154: Ten Year Forecast Overview – Requirements Summary – Data Calculation Tables121

Figure 155: Data Entry Validations123

Figure 156: Detailed Flowchart of the Changeset Process145

Table of Tables

Table 1: Changeset Operations – Fields and buttons description20

Table 2: Changeset Details – Action column options22

Table 3: Action Buttons and Descriptions25

Table 4: Access Roles and Description31

Table 5: Generator Test Results – Column Names and Descriptions60

Table 6: Plants – Column Names and Descriptions69

Table 7: Purchases and Sales – Column Names and Descriptions78

Table 8: Resource Ownership – Column Names and Descriptions99

Table 9: Resources – Column Names and Descriptions110

Table 10: Model Development Validations – Branches125

Table 11: Model Development Validations – Bus Details125

Table 12: Model Development Validations – Generator Data126

Table 13: Model Development Validations – Load Details126

Table 14: Model Development Validations – Transactions126

Table 15: Model Development Validations – 2 Winding Transformers127

Table 16: Model Development Validations – 3 Winding Transformers128

Table 17: Model Development Validations – DC Ties129

Table 18: Model Development Validations – Branch Outages129

Table 19: Model Development Validations – Bus Outages129

Table 20: Model Development Validations – Fixed Shunt Outages130

Table 21: Model Development Validations – Generator Outages130

Table 22: Model Development Validations – Switched Shunt Outages130

Table 23: Model Development Validations – 2 Winding Outages130

Table 24: Model Development Validations – 3 Winding Outages131

Table 25: Resource Adequacy Validations – Demand and Energy131

Table 26: Resource Adequacy Validations – Plants133

Table 27: Resource Adequacy Validations – Purchases and Sales134

Table 28: Resource Adequacy Validations – Resource Ownership139

Table 29: Resource Adequacy Validations – Resources140

Table 30: Resource Adequacy Validations – Generator Test Results141

Table 31: List of Acronyms and Initialisms144

Table 32: List of Resource Adequacy Entities Categorized by Submitting Entity146

Page iii

Page iv

Engineering Data Submission Tool Overview

Overview

The purpose of this document is to provide SPP data submitters a guide on how to use the Engineering Data Submission Tool (EDST) and manage data used for the transmission planning models, NERC reporting requirements, and SPP Tariff reporting requirements. EDST is a web-based application for storing, coordinating, and facilitating data for multiple departments in the SPP Planning Department. The application provides an effective, controlled, and reliably secure process for data submitters and SPP staff to share and review detailed information. This particular document applies to entities who previously submitted data for the Model Development Working Group (MDWG) submittal workbook and the Resource Adequacy Workbook (RAW).

For easy navigation through this document, it is suggested to use the “Navigation Pane” under the View section of Microsoft Word. Once selected, a menu on the left side will display section-heading links for easy access and navigation.

The document is structured as follows:

1. Overview of EDST – provides background information about the tool

2. Getting Started – describes how a data submitter can gain access and login to the tool

3. User Interface Layout and Changeset Summary – describes the general layout of screens and a high-level overview of the changeset workflow. This section relates to both Model Development and Resource Adequacy

4. Menu Navigation Screens – describes the layout and changeset workflow of the Administrative, Model Development, and Resource Adequacy screens in detail

5. Data Entry and Validations – describes the error and warning messages related to data entry and validations for Model Development and Resource Adequacy

6. Appendix 1 – list of acronyms and initialisms used throughout this document

7. Appendix 2 – detailed diagram of a changeset workflow

8. Appendix 3 – list of Resource Adequacy entities

Google Chrome web browser is preferred for accessing EDST.

Introduction

The purpose of EDST is to provide one location for all data changes as well as the other features listed below.

· Flexibility to manage multiple data entries for one user

· Traceability and effective reporting of all submitted data changes

· Performs validations on submitted data changes and provides immediate feedback

· Provides role-based security to prevent unauthorized access and modification of sensitive data

· Provides notifications when data changes upon submission, approval, or other actions

· Creates and publishes summary reports

The diagram below shows a high-level representation of EDST’s architecture and flow for reviewing and submitting data. A data submitter reviews and submits data using EDST’s user interface. The associated changes are then stored in the data repository. SPP Staff utilizes EDST’s user interface to review, validate, and approve data changes.

EDST User Interface

Data Submitter

Data Submitter

Data Submitter

Data Submitter

Data Repository

SPP Staff

Submit and review data

Stores all data submissions and changes

Review, validate, and approve data

Figure 1: EDST Architecture

EDST stores data changes using a structured changeset process which has the ability to manage and organize data. The application allows the creation of new database records, modification of existing database records, and the termination of existing database records. Once a change is submitted and approved by SPP Staff, the details of the change are reflected in the database and can be reviewed by SPP Staff and other permitted users. EDST currently supports the following data sets:

· Model Development Working Group data

· Transactions information

· Generator information

· Load mappings

· Branches information

· Transformer information

· Bus information

· Outage information

· Shunt information

· Resource Adequacy data

· Resource information

· Plant information

· Purchases and Sales information

· Demand and Energy information

· Generator Testing information

· Resource Adequacy Requirement summary report

· Ten Year Forecast Overview summary report

· Deliverability Study Results summary report

Getting Started

This chapter provides a high-level overview of new user registration, basic login process, and resetting a password for EDST.

Gaining Access to EDST

Only users submitting data for SPP Planning processes can gain access to EDST. In order to gain access to EDST, one must contact SPP through the SPP RMS system or by email, [email protected] for Resource Adequacy data or [email protected] for MDWG modeling data.

When a new user is registered, they will receive two emails. The first email informs the user of their EDST registration, their username, and includes a link to the site. The second email will only include the password for their new account. The first email mentions the user should change their password once they log into the site. Once logged in, the user must click their username in the upper right corner of the screen to change their password. The steps below detail the process.

1. The user receives an email with the link to login.

Figure 2: Initial Login Email

2. The user receives a second email with a password.

Figure 3: Initial Login – Password Email

3. Click the link and enter the username and password on the EDST login screen.

Figure 4: Initial Login – Login Screen

4. Once a user provides their login ID and correct password, the application sends a six-digit security code to the user’s registered email which is valid for up to 5 minutes. The application displays a verification screen for the user to enter the six-digit code. If a Security Code email is not received, the user should check their junk or spam email folders for the email. Once logged-in, the EDST Home Page will be displayed.

Figure 5: Security Code Email Notification

Figure 6: Login Verification Screen

5. The user will not be prompted to change their password. Navigate to the upper right hand corner of the web page and click on the “Hello USERNAME”. This will prompt the user to reset their password.

Figure 7: Initial Login – Click on Username

6. Enter the current password and the new password twice. Click the “Change Password” button. Once changed, click “Home” in the menu bar to get back to the dashboard.

Figure 8: Initial Login – Reset Password

Logging In

Once the user opens the web page, a login screen is presented. Type in the associated user name and password to login. If a user does not have a username or password, the user can request access to EDST by following the procedure outlined in the prior section “Gaining Access to EDST”.

Figure 9: Login Screen

If an error is displayed on the screen stating, “An error occurred while processing your request”, close the browser tab and open a new one with the EDST URL link. The error is caused by a web browser functionality that stores previous login sessions which can cause “cache” problems. If the error occurs again, the site is temporarily unavailable or the browser “cache” problems are not fully resolved. To address “cache” problems, clear the browser history or reach out to your company’s Information Technology department for help.

Figure 10: EDST Login Error Message

Figure 11: EDST Login Error Number

The application provides two levels of authentication. Once a user provides their login ID and correct password, the application sends a six-digit security code to the user’s registered email which is valid for up to 5 minutes. If a Security Code email is not received, the user should check their junk or spam email folders for the email.

Figure 12: Security Code Email Notification

Figure 13: Login Verification Screen

Once the valid security code is entered and two level authentication is successful, the application displays the dashboard, as shown in Figure 14. Once logged in, a 20-minute timer is activated to automatically log out of the user interface if there is no activity. The timer resets every time the user performs an action. If the user is automatically logged out, do not click the back arrow in the toolbar of the website. A user must log back into the application by re-entering their username and password and follow the login process from the first step in this section.

Figure 14: EDST Dashboard

Resetting a Password

The steps below describe the process for resetting a password.

1. Navigate to the EDST website and click the “Forgot your password?” link below the password box.

Figure 15: Login Screen – Reset Password

2. Enter user’s email address in the Email field and click “Email Link”. The user will receive an email with the statement “Please reset your password by clicking here”. Click the “here” link provided in the body of the email.

Figure 16: Enter Email – Reset Password

3. Enter email in the Email field, a new password in the Password field, and the new password again in the Confirm password field. Click “Reset”. Close the other web page that states “Forgot Password Confirmation. Please check your email to reset your password.”

Figure 17: Enter New Password – Reset Password

User Interface Layout and Changeset Lifecycle Summary

This chapter describes the associated details and changeset workflows of each screen in EDST.

User Interface Layout

The user interface displays two distinct regions: the header at the top called the navigation menu bar and the lower section of each the web page called the work area pane. The contents of the web page change depending on screen selection.

Navigation Menu

The top right side of the navigation menu bar displays the current user and the option to log out of the application. The options on the left side of the navigation menu bar are displayed based on each user’s level of access. For example, users submitting data for Model Development will not have access to Resource Adequacy data unless the user is submitting for both data sets. The options in the menu bar include the following:

a. EDST Home – Home screen of the application.

b. Model Development – Screens relating to the Model Development data:

i. Branches

ii. Branch Outages

iii. Bus Details

iv. Bus Outages

v. Fixed shunt Outages

vi. Generator Outages

vii. Generators

viii. Load Details

ix. Switched Shunt Outages

x. Transactions

xi. Transformers 2 Winding

xii. Transformers 2 Winding Outages

xiii. Transformers 3 Winding

xiv. Transformers 3 Winding Outages

xv. Two Terminal DC Ties

c. Resource Adequacy - Screens relating to the Resource Adequacy data:

i. Capacity Adjustments

ii. Deliverability Study Results

iii. Demand & Energy

iv. Generator Test Results

v. Plants

vi. Purchases & Sales

vii. Resource Adequacy Requirement

viii. Resource Ownership

ix. Resources

x. Ten Year Forecast Overview

xi. Contact List

d. Administration – Screens relating to changeset administration, historical data viewing and user management:

i. Changeset History

ii. User Management

iii. Historical

Navigation Menu Bar

Figure 18: User Interface Layout – Navigation Menu

Home page

The Home page displays a dashboard containing key notifications and a summary of active Changesets and their status specific to each user’s access.

a. Posting Requirements on the Home Screen or the Postings Page

i. Data submitters have the ability to reply to postings

ii. Only SPP can initially post a notification. Data submitters will receive notification of postings through email and will be able to view them once logged into EDST.

iii. When a data submitter first replies to a posting, they may select private or public. Public means the reply comment will go to all data submitters including SPP. Private means only SPP and the data submitter that submitted the comment can see the comment

iv. All comments/replies that stem from the initial reply are either public or private based on the first reply. For example, if the first reply to a notification is private, then all other replies made to that specific first reply will be private as well

v. There is no limit on the number of replies that can be made to posting notifications or replies

vi. Data submitters can create a number of different initial replies to a notification posting

b. Steps to Reply to Postings on the Home Dashboard or the Postings Page

i. Click the Reply button under a notification posting.

Figure 19: Replying to a posting – Home Page

ii. Select Public or Private and the replying entity. Insert a comment. Select Submit

Figure 20: Replying to a posting, privacy setting – Home Page

iii. If desired, reply to the comment you just posted or reply to another posting. The Postings page is the same.

c. Changeset Details Requirements

The Changeset Details section of the EDST Dashboard displays a summary of the user’s changesets. For example, if a user has one changeset on the Purchases and Sales screen in “DRAFT” status, then it will be represented in the Changeset Details grid. The changeset statuses displayed are “PENDING”, “QUEUED”, “APPROVED”, “WARN”, and “DRAFT” for each screen.

i. The blue changeset number hyperlink will take the data submitter to the page and open the selected changeset

ii. WARN changesets will have a small yellow icon beside the changeset number link. When selected, the yellow, triangle icon will pop up a notification box and display the WARN validation details from the Changeset History screen.

iii. Data submitters with Resource Adequacy (RA) and Model Development (MD) Access can use the drop down option in the top right corner to toggle between RA and MD changesets and postings.

Figure 21: Changeset Details – Home Page

Changeset Status Options and Changeset Lifecycle

The following is a list of possible statuses for a changeset as well as a high-level overview of the changeset process. Additional information on changeset workflow for each screen can be found in section 4.2 for Model Development and 4.3 for Resource Adequacy.

a. DRAFT – This is the initial state of a changeset. The records of a changeset are editable in this state. All saved changes to changesets are preserved between sessions. User can submit the changeset after all edits are complete and saved successfully or abandon the changeset.

b. SUBMITTED – This state reflects that the author of the changeset has successfully finished constructing the changeset and submitted data in the changeset for additional validations. The changeset is ready to be reviewed by SPP Staff for action unless the changeset requires counterparty confirmation. Changesets are no longer editable after entering “SUBMITTED” status unless the changeset is returned to “DRAFT” status.

The user can click the “Submit Changeset” button to transition a changeset to “SUBMITTED” or “WARN” state. Update to “SUBMITTED” state will automatically trigger second-tier validations in the application for the Changeset and examine the proposed data changes. The changeset status become “WARN” if the proposed data changes do not pass validations.

c. PENDING – This state requires confirmation of the data by another party before it is queued for SPP Staff to review. Changesets transition to “PENDING” state once the originator clicks the “Submit Changeset” button. This is only true for those data sets that require third-party confirmation outside the submitter and SPP Staff.

A counterparty can acknowledge or modify a record within a changeset of “PENDING” status. A notification email is sent to the counterparty that a data set is pending their approval. This notification will not occur unless validations pass on the author’s submission. This prevents a counterparty acknowledging a record that did not pass data validations. The status of the changeset will remain in “PENDING” state while the entities are acknowledging the changes made to records in the changeset until the changeset is either returned to “DRAFT” status, abandoned, or queued for approval.

d. QUEUED - This state reflects the changeset is available for SPP Staff to review. SPP Staff review the changes submitted, the results of second-tier validations, and transitions the changeset to another state. SPP Staff has the ability to transition the changeset from “QUEUED” state to:

i. APPROVED, if there are no errors

ii. REJECTED, if SPP does not agree with the changes submitted or if there are errors during second-tier validations and the data submitter wishes to delete the changeset.

iii. DRAFT, if SPP decides to return the changeset to the submitter for minor corrections.

e. APPROVED/REJECTED: The final state of a changeset depending upon whether SPP staff approved or rejected the changeset.

f. WARN – This state indicates that there were second-tier validation issues of WARN severity in at least one record of the submitted changeset. The data submitter must revert the “WARN” changeset back to “DRAFT” status, correct the errors, and re-submit to SPP for approval. SPP Staff has the ability to transition the changeset from “WARN” state to:

i. REJECTED, if there are errors during second-tier validations that should not be overwritten.

ii. APPROVED, if there are warnings and SPP decides to override the warnings. SPP will acknowledge the warnings, and an audit trail will be maintained for such overrides along with user ID, date, and time.

iii. DRAFT, if SPP decides to return the Changeset to the submitter for minor corrections

g. ERROR – This state indicates that there were first-tier validation issues of ERROR severity in at least one record of the submitted data. SPP Staff has the ability to transition the changeset in ERROR state to:

i. REJECTED, if there are errors during second-tier validations that should not be overwritten.

ii. DRAFT, if SPP decides to return the Changeset to the submitter for minor corrections

The following flowchart depicts a high-level overview of changeset workflow. For a detailed flowchart of a changeset’s progression to various states based upon data submitter or SPP Staff actions, see Appendix 2: Detailed Changeset Flowchart.

Figure 19: High-level overview of changeset process

General Layout for Data Maintenance Screens

Most screens in EDST facilitate data submissions with corresponding changeset workflows. All Model Development screens as well as the Resource Ownership and Purchases and Sales screens for Resource Adequacy follow the general layout below for data maintenance screens. The other Resource Adequacy screen layouts are described in Section 4.3.

Figure 20: General layout for data maintenance screens

Basecase Data

The basecase data section displays data that is active or approved for the current submittal year and corresponds only to data on the selected screen. The data in this section is read-only which means the user cannot perform any direct edits to the data. To modify or update the basecase data, a user must submit changes through the changeset process. The user can only view records to which they have access to view.

The grid shows 50 rows on every web page by default but it can be altered to a different number by clicking the small drop down box located at the bottom right of the basecase data section. The grid lists an option to filter the rows for any criteria. A user can type a string, number, or select from a dropdown list (depending upon the corresponding column type) to filter rows that match the provided character set. Once a filter is applied, the grid displays an option to clear the filter that can be done by selecting the “Clear Filters” link in the bottom right of the basecase data section. The user can also define more complex filter criteria using the “Create Filter” option provided at the bottom left corner of the section. The “Export to Excel” button supports the feature to export the basecase data to an Excel workbook. This function applies to all Model Development and Resource Adequacy screens except the Capacity Adjustments and Demand & Energy screens.

Figure 21: Basecase Data Section – filter options

To sort the data for any given column, double click on the column header. This will sort the data by that column in ascending or descending order.

Users can add the rows from basecase grid to the Changeset grid in order to modify the existing data. The left-most column displays a checkbox for each data row of the basecase grid. Users can select the checkboxes for desired rows and add them into the Changeset Details section (explained in Section 3.4.3). Two buttons are displayed once a user selects a row from the basecase data grid: Clear Selection or Add Rows to Changeset. These buttons allow the user to add the selected rows to Changeset grid or to clear the selection of records from the basecase data section.

Figure 22: Basecase Data Section – option to add rows to Changeset

Changeset Operations

The Changeset Operations section located in the middle of the screen provides options to open an existing changeset or create a new changeset. The table below lists the data fields and descriptions for the Changeset Operations section.

Table 1: Changeset Operations – Fields and buttons description

Data Field

Description

Changeset Name

Name given to a changeset by the user; only used when creating a changeset; required to create a changeset; any value or character can be entered; limited to 32 characters

Comments

Comments provided on a changeset by the user; only used when creating a changeset; not required to create a changeset; any value or character can be entered; limited to 255 characters

Changeset Status

Current status of a changeset; field is read-only and cannot be edited; auto generated when a changeset is created or an existing changeset is opened; updated throughout the changeset process based on the actions taken; list of statuses is located in section 3.3

Changeset Number

Number of a changeset; field is read-only and cannot be edited; auto generated when a changeset is created or an existing changeset is opened; changeset number convention is submittal year followed by a generated number in the queue. For example: if the current submittal year is 2018 and it is the first changeset generated for that year, the changeset number will be 2018000001

Open Existing Changeset

Pre-populated option to select changesets that are currently created; list is populated with changesets that contain records related to the user’s responsible or submitting entities; naming convention is Changeset Number, Changeset Name, Changeset Status, Comments, and Author of the changeset

Create Changeset

Button used when creating a changeset; user must enter changeset name before creating a changeset; unavailable when an existing changeset is opened

Clear Changeset

Button used to clear the currently opened changeset; does NOT delete changeset

The figure below shows an example layout for the Changeset Operations section.

Figure 23: Changeset Operations Layout

Create or Open a Changeset

This option provides the user the ability to create a new changeset or open an existing changeset. The description below provides a brief overview on how to create a changeset. For additional information on changeset creation and changeset workflow, refer to section 4.2 for Model Development and 4.3 for Resource Adequacy.

Ensure the Changeset grid is empty, and there is no active changeset. Type any Changeset Name and Comments in the text. Click the button “Create Changeset”. A message box will display on the screen indicating a changeset was successfully created. Click “OK” on the message box. The changeset is automatically opened and records can be added to the Changeset Details section after the changeset has been created.

The application generates a changeset number and it populates the unique number in the changeset number text box. The changeset status displays as DRAFT. The changeset number and changeset status boxes cannot be edited by the user at any time. In order for a changeset to fully and successfully be created, a changeset must be saved to the database by clicking the “Save Changeset” button after data has been added to the Changeset Details section.

To complete the creation of the changeset, click the “Save Changeset” button in the bottom left of the web page. A message box will display on the screen indicating a changeset was successfully saved. Click “OK” on the message box. If first-tier validation errors occur, correct the errors until the changeset is saved successfully. Refer to section 5 for information on how to correct first-tier validation errors.

Users can also open an existing changeset at any time. The dropdown “Open Existing Changeset” provides list of all changesets that current user can access. After a changeset is selected, the rows included in the changeset are displayed in the Changeset Details section.

Changeset Details

The Changeset Details section displays records associated with an existing changeset. Non-editable fields have a gray background and editable fields have a background color of white. The following sections describe key columns noted in the Changeset Details grid. For additional information on data specifics, refer to section 4.2 for Model Development and 4.3 for Resource Adequacy.

Figure 24: Changeset Details Layout

Action column

The application provides three types of actions for each record in the Changeset Details section. The three types of actions are: modify, add, and remove. A user with modify only access will not have options to add or remove records. The table below lists each action and the associated descriptions for each item.

Table 2: Changeset Details – Action column options

Action

Description

Modify

When a user selects rows from the basecase data section and adds them to the Changeset Details section, the “Action” column for that record indicates “MODIFY” to reflect a modify action. This option is used to update data for an existing record.

Add

Users can click the “+ sign” icon that says “Add Row” button on top left corner of the Changeset Details section to add a new row in the grid. This allows users to create a new record. The Action column status is automatically set to “ADD” when creating a new record in the changeset. If a user attempts to change a newly record from “ADD” to “MODIFY” or “REMOVE”, the application will give an error upon saving the changeset and must be changed back to “ADD” because the record has not been approved by SPP Staff to be added to the basecase set of data. To complete the addition of the created record to the basecase set of data, the record must go through the changeset process.

Remove

Users select the “REMOVE” action for removing a record from the basecase set of data. It does NOT delete the record from the opened changeset. The “REMOVE” option can only be selected on an existing record in the basecase set of data by changing the Action column from “MODIFY” to “REMOVE”. If a user attempts to change a newly added record from “REMOVE” to “ADD”, the application will give an error upon saving the changeset and must be changed back to “REMOVE” or “MODIFY”. To complete the deletion of the record in the basecase set of data, the record must go through the changeset process. The changeset workflow for this process is in Section 4.2.10.8.2 for Model Development and Sections 4.3.8.2 and 4.3.6.2 for Resource Adequacy.

Disposition column

The Disposition (DISP) column for each record in the Changeset Details section reflects the current state of each record and is not editable by a user. The possible DISP statuses are listed below.

· In Progress – record is in an editable state

· Complete – changes are valid and saved in database

· Warn – There is a data validation issue associated with the corresponding record, which must be corrected before SPP Staff approves the changeset with the WARN records

· Error – There is a data validation issue associated with the corresponding record which must be corrected before the user can save the changeset or before SPP Staff approves of the record

· Countered – record has a countered value from a confirming entity; only applicable for records that require two-party confirmation before submitting the changeset to SPP Staff for approval. The changeset workflow for this process is in Section 4.2.10.8.3 for Model Development and Section 4.3.6 for Resource Adequacy.

Changeset ID columns

The column “Changeset ID” displays the non-editable changeset unique identifier for the currently active changeset. The “Previous Changeset ID” column stores the changeset unique identifier for the previous changeset that modified the corresponding record. If the “Previous Changeset ID” is the current submittal year followed by six zeros (i.e. 2018000000), the record has been “rolled over” from the previous year and waiting review by the data submitters. The “roll-over” process is described in Section 4.2 for Model Development and 4.3 for Resource Adequacy.

Record Key

The Record Key displays this unique identifier for each record in the data repository. This field is not editable by a user, as it is the primary key for identification.

Edit or Delete record

The left most column for each record displays an option to delete the record from the changeset (“Trash can icon”). The delete icon does not remove the record from the basecase set of data. To mark a record for deletion from the basecase set of data, the “REMOVE” action in the Action column should be selected and submitted for approval using the changeset process. To edit data fields, click in any field with white color background. A background color of gray indicates a field is not editable, and a background color of green indicates a value has been modified.

Figure 25: Changeset Details – Edit / Delete Record

Save changes / Cancel changes

Once the user edits a field for a record in the current Changeset, the section displays options to save or cancel the changes located in the bottom right corner of the Changeset Details section. The user must select one of these options to save or cancel the changes, which apply to all changes made to the records within the changeset. All action buttons under the grid remain disabled until one of these actions are performed.

Acknowledgement (RE/CE) columns

Two EDST screens, “Transactions” for Model Development and “Purchases and Sales” for Resource Adequacy, require special processing as two end users must agree on the data entered in the record before being submitted to SPP Staff for approval. The Responsible Entity column is related to the entity submitting the records and the Confirming Entity is the entity confirming changes made to the record.

The two distinct acknowledgement (ACK) columns indicate if a user agrees with the proposed edits to each record. Each record must have an indicator of “YES” in the ACK column in order for SPP to approve the record. If a changeset is queued for approval before both parties acknowledge the change, the changeset status will be WARN and the submitting entity must return the changeset back to Draft and re-submit the changeset. For transactions with external entities, a user would select SPP as the Confirming entity as SPP would act on behalf of the external entity. Additional information on data specifics and changeset workflow for the confirming entity process can be found in section 4.2 for Model Development and 4.3 for Resource Adequacy.

Action buttons

The buttons displayed at the bottom of the web page are used to transition a changeset from one state to another and are described in the table below.

Table 3: Action Buttons and Descriptions

Button Name

Description

Save Changeset

This option is enabled after a user makes changes to records in the Changeset Details section. The user can click this button to store the changes to the data repository. The saving of the changeset results in population of the DISP column with “In Progress” status. The changeset is only created/saved if a confirmation message is received indicating the changeset has been successfully saved. This button is in enabled state only for changesets in “DRAFT” state. For all other states of the changeset, this button remains disabled.

Submit Changeset

A user can continue to make additional changes after saving the changeset until submission. The Submit button transitions a changeset state from “DRAFT” to QUEUE, PENDING, WARN or ERROR depending upon the result of second-tier validations and the type of data in the records. The application disables this button when the Changeset is not in an editable state or when no change has been saved in the Changeset.

Return to Draft

This button facilitates revoking a data submission and returns the changeset back to “DRAFT” status before it is approved by SPP Staff and the originator of the changeset is notified that the changeset is available for further edits. SPP Staff or the data submitter can select this button to return the Changeset state to “DRAFT” any time after the changeset has been submitted for approval. This button remains disabled when the Changeset is in “DRAFT” state.

Abandon Changeset

The author of a changeset can use his button to delete a changeset. After the button is selected, the changeset is deleted/erased from the data repository and the changes made to the records in the changeset are not updated to the basecase set of data. The abandon option is available any time after a changeset has been created. The button is not available after a changeset has been submitted to SPP for approval. If the user desires to abandon a changeset after submitting it for approval, the changeset must be returned to “DRAFT” status before abandoning.

Queue Changeset

This button is only available for Transactions and Purchases and Sales screens. The changeset transitions to “PENDING” once the first and second-tier validations are successful. The counterparty (Confirming Entity) is notified about the data submission, and the counterparty can then review and acknowledge the submission. The Queue Changeset button becomes available after the author of the changeset has submitted the changeset to the countering entity and both entities acknowledge all entries in the changeset. Once all records are in acknowledged state, the author of the changeset can queue the changeset that transitions the status to “QUEUE” state by selecting the Queue Changeset button. SPP Staff is notified for further action to accept, reject, or return the changeset to Draft.

Export Changeset Details to Excel

The “Export Changeset To Excel” button displayed at the bottom of the web page is used to export the records in the existing changeset to an Excel document.

Figure 26: Changeset Details – Export Changeset to Excel

Bulk Upload

a. Bulk Upload Requirements

i. Data submitters can import excel files into EDST

ii. Upload template must be in the same format as it was when it was downloaded from EDST

iii. Templates can be downloaded from either the basecase or the changeset details sections on each screen

iv. Once uploaded, data submitters will still have to submit the edits through the changeset process in the changeset details section

v. Data submitter will have to save the downloaded file to their personal computer to make changes.

vi. Only the author of changeset can upload the changes

vii. Will receive an error message if the data cannot be uploaded

viii. Edited cells will highlight a different color (green) on the screen after uploading. If there is a red cell that is blank, the data for those cells did not get uploaded properly. This is because there was an error with the import function, the data is not in the correct format within the cell, or the data was deleted prior to being saved on a personal device

ix. The upload option is available for all Model Development screens and only the Plants, Resources, Resource Ownership, and Purchases and Sales screens for Resource Adequacy.

b. Option 1: Steps to Perform a Bulk Upload through the Changeset Details section

i. Create a changeset, add records to the changeset from the basecase, and click the Save Changeset button.

ii. Click “Export Changeset to Excel” and open the excel file.

iii. Make the desired updates and save it to your personal device. Close out of the file after saving. Data submitters should only update fields that can be edited through the user interface in the changeset details section.

a. Data submitters can modify the changeset “Actions” within the excel file instead of manually updating the actions within the changeset details section i.e., ADD, REMOVE, MODIFY

iv. Click the “Import Changeset Updates” button and select the file that was just saved. The file name will appear at the bottom.

v. Click the Upload Button. Click Save changeset.

vi. Continue with the changeset process described in Appendix 2: Detailed Changeset Flowchart

c. Option 2: Steps to Bulk Upload data updates through the Basecase section

i. Click “Export BaseCase to Excel” and open the excel file.

ii. Make the desired edits and save it to your personal device. Close out of the file after saving. Data submitters can remove records from the excel file that they do not want to include in the changeset process.

a. Data submitters cannot modify the changeset “Actions” within the excel file instead data submitters must manually update the changeset “Actions” within the changeset details section i.e., ADD, REMOVE, MODIFY

iii. Create a changeset then Click the “Import Changeset Updates” button and select the file that was just saved. The file name will appear at the bottom.

iv. Click the Upload Button. Click Save changeset.

v. Continue with the changeset process described in Appendix 2: Detailed Changeset Flowchart

Menu Navigation Screens

Administration Screens

This section provides information about user management, role management, and changeset management. The following administrative screens apply to both Model Development and Resource Adequacy data submitters.

Changeset History

All the created changesets are available for review in the Changeset History screen.

User Changesets

Provides a list of all changesets that are available for a user to review, as well as the option to abandon a changeset. The changeset author, changeset status, creation date, applicable screen, and changeset ID are notable information columns provided in this section.

Figure 27: Changeset History – User Changesets

Selected Changeset Details

The column “ID” provides a hyperlink that will display the changeset details for a given record.

Each column value in the changeset is compared against the corresponding record from the basecase and the differences are highlighted in green.

Figure 28: Changeset History – Selected Changeset Details

Validation Messages

Displays validation messages (if any) related to the selected changeset. It also provides the user with the ability to acknowledge a validation message. This section is useful for changesets in “WARN” or “ERROR” status so users can view details about data that may have been submitted incorrectly. Section 5 lists warning messages and descriptions for Model Development and Resource Adequacy validations.

Figure 29: Changeset History – Validation messages

Attached Documents

Provides a list of documents that are associated with a changeset. Only SPP Staff has the ability to upload documents which will be used as verification documentation in a case when SPP Staff needs to override a changeset in WARN status or modify an entity’s data.

Figure 30: Changeset History – Attached Documents

User Management

Users can access the user management screen to modify details for their account, such as email address, phone numbers, and comments. The application displays other information for the account, like submitting entity relationship and roles for users in a read-only mode. Only SPP Staff can manage details such as Active Indicator, Competitive Indicator, Non-competitive Indicator, Roles, and Assigned Entities. If a user desires to change this information, they must contact SPP Staff.

Figure 31: User Management Screen

Access Roles

Access to information is restricted based upon user role and responsible entity relationships which are assigned by SPP Staff. Data submitters should contact SPP Staff if their role or assigned entity needs to be changed. Each user can be associated with one or more responsible entity, and one or more roles. The table below shows a list of user roles in EDST.

Table 4: Access Roles and Description

User Role

Data Set

Applicable User

Access Level

Accessible Screens

Member Resource Adequacy

Resource Adequacy

Data Submitter

Read \ Write

Data management, Summary report, and Admin screens

Member RA – Reports Only

Resource Adequacy

Data Submitter

Read Only

Summary report and Admin screens

Member Resource Adequacy – Read Only

Resource Adequacy

Data Submitter

Read Only

Data management, Summary report, and Admin screens

Member Modeler

Model Development

Data Submitter

Read \ Write

Data management and Admin screens

Member Modeler – Read Only

Model Development

Data Submitter

Read Only

Data management and Admin screens

Member Modeler – Transactions

Model Development

Data Submitter

Read \ Write

Transactions and Admin screens

Member RA Resp. Entity Only – RO

Resource Adequacy

Data Submitter

Read Only

Purchases and Sales, Plants, Resource Ownership, Resources

Member RA Del. Study Report Only

Resource Adequacy

Data Submitter

Read \ Write

Deliverability Study Report

Historical Data

EDST stores finalized basecase data on all previous submission years for reference and compliance purposes. After selecting the applicable table and year, the user can either display the data in a grid form on the screen or export it to an Excel spreadsheet.

Figure 32: Historical Data – Year and Data Set Selection

The historical base grid displays all records for the chosen year for the selected table based on the individual’s permissions. The historical grid has column filtering features that are similar to the basecase data sections on the data management screens.

Figure 33: Historical Data Grid

Model DevelopmentBranches (Transmission Tie Line)

PC to PC branch and transformer ties that shall be coordinated before submission to SPP.

Bus Details

List of all buses in the models that includes long names, voltage level, area, owner, and EIA plant codes.

Generators

Required generator data that is not otherwise captured in the models.

Load Details

Identify loads not served by native Control Areas.

Transactions

Firm and non-firm reservations with other entities that shall be coordinated before submission to SPP.

Transformers 2 Winding (Transmission Tie Line)


Transformers 3 Winding (Transmission Tie Line)


Two Terminal DC Ties


Transformers 2 Winding , Transformers 3 Winding, Bus, Generator, Branches and Shunt Outages

Outages known during the annual model building process for buses, generators, branches, transformers, and shunts with a duration of at least six months shall be modeled. Data submitters are responsible for annotating known outages to be modeled within EDST, as well as ensuring that the known outages are correctly modeled in the appropriate season(s) when the known outage is scheduled.

Changeset Workflow

This section discusses common changeset workflows for EDST users.

Create or open a Changeset

The steps below describe common steps for creating a new changeset. A user usually performs this workflow for submitting data for their respective entities. This changeset workflow applies to all changeset flows on the Model Development screens.

1. After logging into EDST, open the corresponding screen using the menu navigation bar. A user can select applicable screens under the Model Development menu options at the top of the web page.

Figure 34: Creation of Changeset – EDST Dashboard

2. After navigating to a screen under the Modeling Development option, type any Changeset Name and Comments in the text boxes provided in Changeset Operations pane, which is located in the middle of the web page for most screens. Click the button “Create Changeset”. A message box will display on the screen indicating a changeset was successfully created. Click “OK” on the message box.

If opening an existing changeset, click the drop down arrow under the “Open Existing Changeset” option provided in Changeset Operations pane. Select the desired changeset to be viewed. The naming convention is Changeset Number, Changeset Name, Changeset Status, Comments, and Author of the changeset in the list of existing changesets. After a changeset is selected, the rows included in the changeset are displayed in the Changeset Details section.

Figure 35: Creation of Changeset – Changeset Operations Section

3. The application generates a Changeset Number and it populates the unique number in the Changeset Number text box. The Changeset Status displays as “DRAFT”. The changeset number and changeset status boxes cannot be edited by the user at any time. Note: In order for a changeset to fully and successfully be created, a changeset must be saved to the database by clicking the “Save Changeset” button after data has been added to the Changeset Details section.

4. Data can be added to the Changeset Details section by selecting data rows from the basecase grid and adding the selected rows into Changeset grid. Data rows in the basecase grid can be selected by clicking the checkbox in the first column of the grid.

5. Once the desired rows are selected, click the “Add Selection to Changeset” button at the top of the grid. The selected rows are now added to the “Changeset Details” section at the bottom of the screen and ready to be edited. The action column in the Changeset Details section for the selected rows is automatically set to “Modify”. The disposition of each record is set to “DRAFT” status.

Figure 36: Creation of Changeset – Add Records to Changeset

Figure 37: Creation of Changeset – Changeset Details

6. To complete the creation of the changeset, click the “Save Changeset” button on the bottom left of the screen. A message box will display on the screen indicating a changeset was successfully saved. Click “OK” on the message box. If first-tier validation errors occur, correct the errors until the changeset is saved successfully. Reference section 5 for information on first-tier validation errors. The disposition of each record in the Changeset Details section is set to “IN PROGRESS” status.

Figure 38: Create Changeset – Save Changeset

Adding records from Basecase to a Changeset

1. After logging into EDST and navigating to a screen under the Modeling Development option, open an existing changeset that is in Draft status or create a new changeset.

2. Data can be added to the Changeset Details section by selecting data rows from the basecase by clicking the checkbox in the first column of the basecase grid. Records can only be added to changesets in “DRAFT” status.

3. Once the desired rows are selected, click the “Add Selection to Changeset” button at the top of the grid. The selected rows are now added to the “Changeset Details” section at the bottom of the screen and ready to be edited. To clear the selection of rows, click “Clear selection”. The action column in the Changeset Details section for the selected rows is automatically set to “Modify”. The disposition of each record is set to “DRAFT” status.

4. Once the record is added to the changeset, it is recommended to select the “Save Changeset” button in the bottom left of the screen(Figure 39), so the addition of the record is successfully saved to the changeset. A message box will display on the screen indicating a changeset was successfully saved. Click “OK” on the message box. If first-tier validation errors occur, correct the errors until the changeset is saved successfully. Reference section 5 for information on first-tier validation errors. The disposition of the record in the Changeset Details section is set to “IN PROGRESS” and is ready to be edited.

Figure 39: Adding Records to Changeset – Save Changeset

Editing data in a Changeset


2. Edit data in the cells provided in the Changeset Details section of the screen. The cells being edited will be changed to the color green. Click “Save Changeset” to save changes to the changeset. If first-tier validation errors occur, correct the errors until the changeset is saved successfully. Reference section 5 for information on first-tier validation errors. Data in grayed-out cells cannot be edited. These values are either auto-populated by the database for record information purposes or data that can only be edited by SPP Staff. If data in these cells need to be altered, the user can export Changeset Details section to Excel, make suggested edits to the grayed-out cells, and send the data changes to SPP Staff or insert comments in the Comments column.

Deleting records from a Changeset


2. Data can be deleted from existing changesets by clicking the “Trash” icon in the first column of the Changeset Details section. Only the author of the changeset can delete rows from the existing changeset. Records can only be deleted from changesets in “DRAFT” status.

Figure 40: Deleting Records from Changeset – Changeset Details

3. Click “Save Changeset” to save changes to the changeset. If first-tier validation errors occur, correct the errors until the changeset is saved successfully. Reference section 5 for information on first-tier validation errors.

Submitting a Changeset for Approval


2. Once the data in records are updated and the changeset is successfully saved, click the “Submit Changeset” button. SPP Staff will be notified of the submission and will review the edits in the changeset. A message will display at the top of the screen indicating the changeset has been successfully submitted. Second-tier validations are performed on data in the changeset. If there are no errors, a message will display on the screen indicating the changeset was successfully submitted. If there are errors, a message will display on the screen indicating the changeset is in a WARN status. Navigate to the Changeset History screen under the Administration menu and select the changeset in warning status to view additional information about the warning. Reference section 5 for information on second-tier validation errors.

Figure 41: Warning Validation Message

Upon review, SPP has the capability to Approve, Reject, or Send the changeset back to Draft status. If the changeset is approved, the basecase data will be updated with the changes. If the changeset is rejected, the changeset will be deleted and the basecase data will not be updated. If the changeset is returned to Draft, the data submitter can make edits to the changeset again and re-submit the changeset for approval. An email notification will be sent to the data submitter(s) after the action taken by SPP Staff.

Returning a Changeset to DRAFT

1. After submitting a changeset for approval, a changeset can be returned back to Draft status to edit data and re-submit the changeset. After opening an existing changeset, navigate to the bottom of the Changeset Details screen. Click “Return to DRAFT” to return the changeset to Draft status. Only changesets in “PENDING”, “QUEUED”, or “WARN” status can be returned to Draft status.

Figure 42: Return Changeset to DRAFT – Changeset Details

Abandoning a Changeset


2. Click the “Abandon Changeset” button to delete the changeset. A changeset can only be abandoned in “DRAFT” or “PENDING” status. If the changeset has been Submitted or Queued, the changeset must be returned to “DRAFT” status before abandoning the changeset.

Figure 43: Abandon Changeset – Changeset Details

3. A message will display at the top of the screen requesting confirmation to abandon the changeset. Click “OK” to abandon the changeset or “Cancel” to cancel the action.

4. If “OK” is selected, another message will display at the top of the screen confirming changeset is abandoned and deleted. Click “OK” to close the message.

Uncommon Changeset Workflows

Adding new records to the Basecase


2. Click the “+” button at the top left of the Changeset Details section. A new record should be populated in the Changeset Details section and the Action column automatically set to “ADD”. Populate data in fields indicated by red highlights.

Figure 44: Adding Records to Basecase Data – Changeset Details

3. Click the Save Changes link at the bottom right of the Changeset Details section and the “Save Changeset” button at the bottom left of the screen to save the changes. If first-tier validation errors occur, correct the errors until the changeset is saved successfully. Reference section 5 for information on first-tier validation errors.

4. Submit the changeset for approval by SPP Staff in order to successfully add the record to the basecase set of data.

Permanently remove records from the basecase


2. Change the value in Action column from “Modify” to “Remove” on the records to be removed from the basecase.

Figure 45: Removing Records from Basecase Data – Changeset Details

3. Click the Save Changes link at the bottom right of the Changeset Details section and the “Save Changeset” button at the bottom left of the screen to save the changes. If first-tier validation errors occur, correct the errors until the changeset is saved successfully. Reference section 5 for information on first-tier validation errors.

4. Submit the changeset for approval by SPP Staff in order to successfully remove the record from the basecase set of data.

Changesets with confirming entity application

The steps below describe common steps for confirming entries for records that require counterparty acknowledgement. Records that require two-party confirmation are defined between two entities, and both parties need to confirm the changes before SPP reviews and approves/rejects the Changeset. Data submitters perform this workflow on Changesets located in the Transactions screen under Model Development. Data submitters will only be able to view and change records they have access to view.

1. After logging into EDST and navigating to a screen under the Modeling Development Adequacy option, open an existing changeset that is in Draft status or create a new changeset.

2. Add existing records from the basecase or create new records in the Changeset Details section. Click the “Save Changes” link in the bottom right of the Changeset Details section and the “Save Changeset” button at the bottom left of the screen when making any edits to the data. If first-tier validation errors occur, correct the errors until the changeset is saved successfully. Reference section 5 for information on first-tier validation errors.

3. After all changes are made, click “Submit Changeset” to submit the changeset to the confirming entity. A message will display at the top of the screen indicating the changeset has been successfully submitted. The changeset status is changed from “DRAFT” to “PENDING”. The author of the changeset has the options to return the changeset to “DRAFT” status or Queue the changeset. You cannot queue the changeset without the confirming entity acknowledgement of the changes in the changeset. An email notification is sent to the confirming entity indicating they need to log in and review the changeset. The “Responsible Acknowledgement Indicator” is automatically set to “YES”.

Mirror transactions of the records in the changeset are created in the database when the changeset is successfully saved. This is done because row-level security is established on the Submitting and Responsible Entity columns in the tool to prevent entities from viewing other records not related to them.

4. The confirming entity now logs in and reviews the changes made to the Pending changeset in the Transactions screen. The confirming entity will review the mirror transaction and make the necessary changes to the records in the changeset. The only information that can be edited by the confirming entity is the seasonal MW values in the yearly capacity columns. Updating the “Responsible Acknowledgement Indicator” to “YES” is required to have both parties confirm the changes before being queued for review by SPP Staff.

5. Click the “Save Changes” link in the bottom right of the Changeset Details section and the “Save Changeset” button at the bottom left of the screen. A message will display at the top of the screen indicating the changeset is saved successfully. The “Save Changeset” button also submits the changeset. An email notification is sent to the original author of the changeset, and the original record is updated with the updated information of the mirror transaction. The changeset is still in “PENDING” status until the author of the changeset queues the changeset for review.

If the confirming entity changes the capacity values, the disposition of the modified records will be changed to “COUNTERED” and will require acknowledgement from the author of the changeset. For the countered records, the acknowledgement indicator pertaining to the confirming entity is automatically set to “YES”.

6. The entity who originated the changeset now logs-in and reviews the changes made to the Pending changeset in the Purchases and Sales or Transactions screen. The record dispositions in the Changeset Details section are listed either as “COUNTERED” or “IN PROGRESS”. At this point, the entity who originated the changeset can only update the acknowledgement indicator of the “COUNTERED” records to “YES”. The capacity values cannot be countered again. If the values are still incorrect, the changeset can be returned to DRAFT status or abandoned.

7. The author of the changeset can either Queue, Abandon, or return the changeset to DRAFT status.

a. If the “QUEUE Changeset” button is selected, the changes are submitted by the entity and will be reviewed by SPP Staff for approval. Second-tier validations are now performed on data in the changeset. If there are no errors, a message will display on the screen indicating the changeset was successfully submitted and the status of the changeset will be updated to “QUEUED”. Both entities, along with SPP Staff, will receive an email notification of the action. If there are errors, a message will display on the screen indicating the changeset is in a “WARN” status. Navigate to the Changeset History screen under the Administration menu and select the changeset in warning status to view additional information about the warning. Reference section 5 for information on second-tier validation errors. It is recommended to return the changeset to “DRAFT” status, correct the validation errors, and repeat steps 2 through 6 of this section.

b. If the “Return to DRAFT” button is selected, the changeset is returned back to DRAFT status and steps 2 through 6 of this section must be repeated. Both entities will receive an email notification of the action. A message will display at the top of the screen indicating the changeset has been successfully returned to DRAFT status.

c. If the “ABANDON Changeset” button is selected, the changeset will be abandoned and deleted from the database. Both entities, along with SPP Staff, will receive an email notification of the action. A message will display at the top of the screen indicating the changeset has been successfully abandoned.

8. Upon review, SPP has the capability to Approve, Reject, or Send the changeset back to Draft status. If the changeset is approved, the basecase data will be updated with the changes. If the changeset is rejected, the changeset will be deleted and the basecase data will not be updated. If the changeset is returned to Draft, the data submitter can make edits to the changeset again and re-submit the changeset for approval. An email notification will be sent to both parties after the action taken by SPP Staff.

Resource Adequacy

All Resource Adequacy screens facilitate data submission for the Resource Adequacy process or provide the ability to generate reports. Each year, the previous year’s data is rolled over and available to be re-submitted for approval before the submission deadline. All data for each submission year starts in an unapproved state until data is approved by SPP. A submitting entity can re-submit changes as long as the submittal window is open. The Resource Adequacy window for data submissions is October 1st to February 15th of the following calendar year. The “cure period”, during which entities can cure capacity deficiency or make minor adjustments to data is February 16th to May 15th of every year. Resource Adequacy data in EDST will NOT be editable from May 16th to September 30th.

Resource Adequacy data focuses on information submitted for the summer and winter seasons. The Summer Season is defined as June 1st to September 30th and the Winter Season is defined as December 1st to March 31st of the following year. For example, the 2018 summer and winter season timeframes would be June 1, 2018 to September 30, 2018 and December 1, 2018 to March 31, 2019, respectively.

There is one submitting entity and one responsible entity for each record in EDST. The Responsible Entities are the Load Responsible Entities or Generator Owners and the Submitting Entity is the entity submitting the Responsible Entity’s data. There can be multiple Responsible Entities assigned to one Submitting Entity but there cannot be multiple Submitting Entities for one Responsible Entity. For example, if a Market Participant has three Load Responsible Entities assigned to them and wishes to submit information for all three Load Responsible Entities separately, the Submitting Entity would be the Market Participant and the Responsible Entities would be the Load Responsible Entities. The Resource Adequacy Report and Ten year Forecast Overview Report screens are aggregated at the Submitting Entity level. Market Participants who are not Load Responsible Entities, but are responsible for Load Responsible Entities defined through the Resource Adequacy process, will have access to view only the Resource Adequacy Requirement and Ten Year Forecast Overview report screens for their respective Load Responsible Entities.

Relationships between the Submitting and Responsible entities must be defined before October 1st each year, as described in Attachment AA of SPP’s Tariff. This is due to the previous year’s data being available to the Submitting Entity before the rollover of data occurs from the previous submission year. Data is rolled over annually on October 1st so entities will have pre-populated records to edit instead of having to re-enter all records from the previous year. If a relationship is changed after October 1st, the rolled-over values for the Demand and Energy and Capacity Adjustments screens will not be available. A list of Resource Adequacy entities and the corresponding Submitting and Responsible Entity relationships are provided in Appendix 3: Resource Adequacy Entities. Row-level security is defined on the Responsible Entity and Submitting Entity levels. For example, entity A’s records are only viewable by entity A as long as entity A is listed as the Submitting or Responsible Entity. No other entity can view entity A’s data.

All data must be approved by SPP for each submission year. The basecase data sections for the “Purchases and Sales” and “Resource Ownership” screens contain either records that have been rolled over from the previous submittal year or new records that have been added through the changeset process. Every year when the previous year’s data is “rolled over” to the current submittal year, the status of all records are set to “Unapproved”. The “Previous Changeset ID” column can identify the “Unapproved” records. The changeset ID begins with the current submittal year followed by six zeros. For example, if the current submittal year is 2019, the rolled-over “Unapproved” records for the 2019 submittal year would be identified by “2019000000” in the “Previous Changeset ID” column of the basecase data section. SPP Staff must approve all records for every submittal year, regardless of whether they were approved the previous year. This requirement is in place for SPP Staff to verify entities have “submitted” data for the Resource Adequacy process prior to February 15th every year. Records can be approved by submitting changesets for approval by SPP Staff. Once the changeset is approved, the values in the associated records are updated in the basecase data section and the “Previous Changeset ID” column is updated with the changeset ID approved by SPP Staff.

For details on the data requirements, qualifications, and data descriptions associated with the Resource Adequacy process and EDST, refer to the Resource Adequacy Instruction Manual on the SPP website under the Resource Adequacy page (https://www.spp.org/engineering/resource-adequacy/).

Processes considering multiple screens

This section outlines the workflow of processes that consider multiple Resource Adequacy screens to accomplish the task.

Adding a new plant or resource to the EDST

A new plant must be created in the Plants screen before adding a resource and a resource must be added in the Resources screen before a record in Resource Ownership. The flow chart in Figure 46 outlines the creation of a new plant or resource in EDST.

Figure 46: Flow Chart for Adding a New Plant or Resource

Below are the steps to add a new plant or resource to EDST and include the new capacity in the Resource Adequacy report screens.

1. Check to see if the new plant is currently viewable on the Plants screen. If not, reach out to SPP to see if the plant exists in EDST. (The plant may already exist but is currently viewable by a different submitting entity.) Once SPP verifies the plant does not exist, create a new plant in the Plants screen using the changeset process in section 4.3.5.2. The new plant record must be approved by SPP before adding the new record in the Resources screen or else the new plant will not display in the plants drop down list in the Resources screen.

2. Check to see if the new resource is currently viewable on the Resources screen. If not, reach out to SPP to see if the resource exists in EDST. (The resource may already exist but is currently viewable by a different submitting entity.) Once SPP verifies the resource does not exist, create a new resource in the Resources screen using the changeset process in section 4.3.9.2. The new resource record must be approved by SPP before adding the new record in the Resource Ownership screen or else the new resource will not display in the Resource ID drop down list in the Resource Ownership screen.

3. After the plant and resource has been added, add a record in the Resource Ownership screen through the changeset process in section 4.3.8.2 if the submitting entity partially or fully owns the resource. If the capacity is being purchased and is owned by a different submitting entity, the purchase should be entered in the Purchases and Sales screen through the changeset process in section 4.3.6.2.

Capacity Adjustments

The Submitting Entity and Responsible entity relationships applied on the Capacity Adjustments screen is also applied to the Demand and Energy screen. (i.e. The data submission by Submitting Entity must be grouped, contain the same Responsible Entities, as Demand and Energy.) A list of Submitting Entity to Responsible Entity relationships are in Appendix 3: Resource Adequacy Entities.

Screen Layout and Data Details

The data submitter can switch back and forth from changeset to basecase data by clicking the appropriate buttons at the top of the screen in the Changeset Operations section. If the basecase set of data is open on the screen, the “Show Basecase” button will be unavailable. If the changeset is open on the screen, the “Open Changeset” button will be unavailable. If there is a changeset in progress (such as in “DRAFT”, “WARN”, or “QUEUED” status), the “Create Changeset” button will be unavailable because only one changeset can be opened and edited at a time.

Figure 47: Capacity Adjustments – Changeset Operations

The basecase data that has been approved by SPP Staff is the data that will be used in the calculations provided in the Resource Adequacy summary report screens. In order to determine if SPP Staff have approved a basecase set of data, select an entity from the Submitting Entity drop down list and click the “Show Basecase” button. After successfully opening the basecase, the “Status” box in the

Engineering Data Submission Tool User Guide user guide_v… · Web view2021. 1. 8. · The...

Documents

Transcript of Engineering Data Submission Tool User Guide user guide_v… · Web view2021. 1. 8. · The...