PR 70007 – MarkeTrak Enhancements Detailed Business Requirements

Detailed Business Requirements:

PR 70007 – MarkeTrak Enhancements

Version 1.0

1

© 2006 Electric Reliability Council of Texas, Inc. All rights reserved.

Last Updated: 12/10/2018

PR 70007 – MarkeTrak Enhancements Detailed Business Requirements

Document Revisions

Date / Version / Description / Author(s)
1.0 / First draft / Jennifer Frederick

© 2006 Electric Reliability Council of Texas, Inc. All rights reserved.

Last Updated: 12/10/2018

PR 70007 – MarkeTrak Enhancements Detailed Business Requirements

Sign-Offs – Approval(Required) Please enter person’s name in front of title.

Business Owner (Mgr)

Name______Date______

Sign-Offs – InformedPlease enter person’s name if front of title.

Project Sponsor (Dir)

Name______Date______

Divisional Project Organization (DPO) Manager

Name______Date______

IT Director

Name______Date______

IT Manager

Name______Date______

Testing Analyst

…Name______Date______

© 2006 Electric Reliability Council of Texas, Inc. All rights reserved.

Last Updated: 12/10/2018

PR 70007 – MarkeTrak Enhancements Detailed Business Requirements

© 2006 Electric Reliability Council of Texas, Inc. All rights reserved.

Last Updated: 12/10/2018

PR 70007 – MarkeTrak Enhancements Detailed Business Requirements

Table of Contents

1.Project Overview

2.Requirements Overview

3.Business Requirements

3.1.Requirement 1 - Market: Make the order of all buttons consistent on all sub-types

3.2.Requirement 2 – Market: Create a Parent Project Type for DEV Issues

3.3.Requirement 3 – Market: Make all transitions consistent within MarkeTrak

3.4.Requirement 4 – Market: Create Bulk Insert Templates

3.5.Requirement 5 - Market: Add Bulk Insert Number to Issues

3.6.Requirement 6 – Market: Modify Search Arrow next to ID Search

3.7.Requirement 7 – Market: Do not allow changes to the Title Field on MarkeTrak Issues

3.8.Requirement 8 – Market: Do not capture Non-ERCOT Owner during “Begin Working” unless the owner field is empty

3.9.Requirement 9 – Market: Require Comments for Siebel Chg/Info Sub-types

3.10.Requirement 10 – Market: Add Service Period Start Date Field to Missing Transaction, Projects, Siebel Chg/Info, Other, and REP of Record Sub-types. Add Service Period Stop Date Field to REP of Record and Usage and Billing Sub-types.

3.11.Requirement 11 – Market: Add ISA Field to Submit for 997, Projects, and Other Sub-types

3.12.Requirement 12 – Market: Add a new required field to the Reject Sub-type to provide the Reject Reason

3.13.Requirement 13 – Market: Update Transaction Types during “Submit” and Add New Required Tran Type during “Re-Assign” for Missing Transaction

3.14.Requirement 14 – Market: Add Columns to Escalation Email Attachment

3.15.Requirement 15 – Market: Validate ESI ID/TDSP Association

3.16.Requirement 16 – Market: Changes to Usage and Billing Sub-type

3.17.Requirement 17 – Market: Reporting Improvements

3.18.Requirement 18 – Market: Standardize Sub-type Names within DEV LSE Issues

3.19.Requirement 19 – ERCOT: Populate ERCOT Owner and Siebel Status/Sub-status on ERCOT Initiated Issues

3.20.Requirement 20 – ERCOT: Provide “First Touched Date”

3.21.Requirement 21 – ERCOT: Siebel Status/Sub-status Auto Update Upon Completion

3.22.Requirement 22 – ERCOT: Validation of CR for Siebel Change

3.23.Requirement 23 – ERCOT: Add ability to turn on/off Automation for IAG and DEV

3.24.Requirement 24 – ERCOT: Change the layout of the DEV Analysis Fields on GUI Screen for applicable DEV LSE Sub-types

4.Use Cases

4.1.Use Case 1 (Requirement 25) – Market: Inadvertent Gain

4.2.Use Case 2 (Requirement 26) – Market: Premise Type Field

4.3.Use Case 3 (Requirement 27) – Market: Add Close” Capability for Submitting MP for the Day to Day and Inadvertent Gain Workflows

4.4.Use Case 4 (Requirement 28) – Market: Various Changes to Cancel with Approval

4.5.Use Case 5 (Requirement 29) – Market: Various Changes to Cancel Without Approval

4.6.Use Case 6 (Requirement 30)– Market: Add “New Total” Required Field to Certain DEV IDR Sub-types

4.7.Use Case 7 (Requirement 31) – Market: Change the format of Service History with DUNS for Effected Period and add it to “Submit” when submitter is a TDSP for given DEV LSE Sub-types. Add Logic to determine under which circumstances this field is necessary.

4.8.Use Case 8 (Requirement 32) – Market: Capture Modify/Reassign StartTime and/or StopTime fields on DEVLSE Issues and Make Them Available on the Issue

4.9.Use Case 9 (Requirement 33) –Market: Provide Update Via API Whenever a Market Participants Visibility to an Issue Has Been Removed

4.10.Use Case 10 (Requirement 34) – Market: Special Character Requirements

4.11.Use Case 11 – Market: Not Allow Changes to the Title Field

4.12.Use Case 12 (Requirement 35) – Market: Add Close Capability for Submitting MP for all DEV Workflows

4.13.Use Case 13 – Market: Email Escalation Notices – Add Additional Column in the Attachment

4.14.Use Case 14 (Requirement 36) – Market: Add Email Button and Email Capture

4.15.Use Case 15 (Requirement 37) – Market: New Premise Type and Service Address Subtypes

4.16.Use Case 16 – Market: New Service Address Subtype

4.17.Use Case 17 – Market: Restrict Transaction Types for D2D Missing Transaction Issues

4.18.Use Case 18 – Market: Add service History StartTime and StopTime for REP of Record

4.19.Use Case 19 – Market: Add REF ID to Missing Transactions Sub-type

4.20.Use Case 20 – Market: Miscellaneous Changes to Usages and Billing

4.21.Use Case 21 (Requirement 38) – Market: Add New D2D Sub-type titled “Safety Net Order”

4.22.Use Case 22 (Requirement 39) – Market: Add New D2D Sub-type titled “Service Order – 650”

4.23.Use Case 23 (Requirement 40) – Market: Add New D2D Sub-type titled “Move Out With Meter Removal”

4.24.Use Case 24 (Requirement 41) – ERCOT: Correct logic used in the StartTime fields on DEVLSE Issues

4.25.Use Case 25 (Requirement 42) – ERCOT: Correct logic used in the StopTime fields on DEVLSE Issues

4.26.Use Case 26 (Requirement 43) – ERCOT: IAG Analysis Automation

4.27.Use Case 27 (Requirement 44) – ERCOT: DEV Analysis Automation

5.Appendices

1

© 2006 Electric Reliability Council of Texas, Inc. All rights reserved.

Last Updated: 12/10/2018

PR 70007 – MarkeTrak Enhancements Detailed Business Requirements

1.Project Overview

1.1.Background

(Purpose for Project or triggering circumstances)

1.2.Stakeholders

(Stakeholders involved with these requirements; link stakeholder with their requirement)

1.3.Business Drivers (Market, ERCOT or IT)

SCR 749 – MarkeTrak Enhancements

1.4.Anticipated Business or IT Benefits

  • Improve productivity for Market Participants
  • Provide increased monitoring capabilities for Market Participants and reduce number of escalated issues
  • Require CRs to provide additional information at creation of issues to minimize TDSP processing time

2.Requirements Overview

(Include all the following requirements: usability, availability, reliability, performance, GUI, user licenses, data types and amounts, interfaces/interactions, help/systems, and operational requirements, system security/mechanisms, etc.)

Requirement # / Description of Requirement
Requirement 1 / Make the order of all buttons consistent on all sub-types
Requirement 2 / Create a Parent Project Type for DEV Issues
Requirement 3 / Make all transitions consistent within MarkeTrak
Requirement 4 / Create Bulk Insert Templates
Requirement 5 / Add Bulk Insert Number to Issues
Requirement 6 / Modify Search Arrow next to ID Search
Requirement 7 / Do not allow changes to the Title Field on MarkeTrak Issues
Requirement 8 / Do not capture Non-ERCOT Owner during “Begin Working” unless the owner field is empty
Requirement 9 / Require comments for Siebel Chg/Info Sub-types
Requirement 10 / Add Service Period Start Date Field to Missing Transaction, Projects, Siebel Chg/Info, Other and REP of Record Sub-types. Add Service Period Stop Date Field to REP of Record and Usage and Billing Sub-types
Requirement 11 / Add ISA Field to Submit for 997, Projects, and Other Sub-types
Requirement 12 / Add a new required field to the Reject Sub-type to provide the Reject Reason
Requirement 13 / Update Transaction Types during “Submit” and Add New Required Tran Type during “Re-assign” for Missing Transaction
Requirement 14 / Add Columns to Escalation Email Attachment
Requirement 15 / Validate ESI ID/TDSP Association
Requirement 16 / Changes to Usage and Billing Sub-Type
Requirement 17 / Reporting Improvements
Requirement 18 / Standardize Sub-type Names within DEV LSE Issues
Requirement 19 / Populate ERCOT Owner and Siebel Status/Sub-status on ERCOT Initiated Issues
Requirement 20 / Provide “First Touched Date”
Requirement 21 / Siebel Status/Sub-status Auto Update Upon Completion
Requirement 22 / Validation of CR for Siebel Change Issues
Requirement 23 / Add ability to turn on/off Automation of for IAG and DEV
Requirement 24 / Change the layout of the DEV Analysis Fields on GUI Screen for applicable DEV LSE Sub-types
Requirement 25 / Inadvertent Gain
Requirement 26 / Premise Type Field
Requirement 27 / Add Close capability for Submitting MP for the Day to Day and Inadvertent Gain Workflows
Requirement 28 / Various Changes to Cancel With Approval
Requirement 29 / Various Changes to Cancel Without Approval
Requirement 30 / Add “New Total” Required Field to certain DEV IDR Sub-types
Requirement 31 / Change the format of Service History with DUNS for Effected Period and add it to “Submit” when submitter is a TDSP for given DEV LSE Sub-types. Add Logic to determine under which circumstances this field is necessary.
Requirement 32 / Capture Modify/Reassign StartTime and/or StopTime fields on DEVLSE Issues and make then available on the issue
Requirement 33 / Provide update via API whenever a Market Participants Visibility to an Issue has been removed
Requirement 34 / Special Character Requirements
Requirement 35 / Add Close capability for Submitting MP for all DEV Workflows
Requirement 36 / Add Email Button and Email Capture
Requirement 37 / New Premise Type and Service Address Sub-types
Requirement 38 / Add new D2D Sub-type titled “Safety Net Order”
Requirement 39 / Add new D2D Sub-type titled “Service Order – 650”
Requirement 40 / Add New D2D Sub-type titled “Move Out with Meter Removal”
Requirement 41 / Correct logic used in the StartTime fields on DEVLSE Issues
Requirement 42 / Correct logic used in the StopTime fields on DEVLSE Issues
Requirement 43 / IAG Analysis Automation
Requirement 44 / DEV Analysis Automation

2.1.User Documentation and Help System Requirements

(Describes the specifications, if any, for user documentation [help systems, help about notices, etc.})

3.Business Requirements

This section outlines Market Requirements for PR 70007 that do not require a Use Case because there is no change to the existing Workflow.

3.1.Requirement 1 - Market: Make the order of all buttons consistent on all sub-types

3.1.1.Description:

Currently there is no standard format for the order of the transition buttons on the MarkeTrak tool. The Market is requesting the following standard order be used for these buttons:

  1. Positive Path
  2. Negative Path
  3. Always Present

Within each category buttons should be listed in alphabetical order. When a button is not applicable to the current screen, it should not be displayed.

3.2.Requirement 2 – Market: Create a Parent Project Type for DEV Issues

3.2.1.Description:

Currently MarkeTrak Users must run reports on each DEV Sub-type separately and then combine the reports in order to get a report on all DEV Issues.

Creating a Parent Project Type for DEV Issues would allow users to pull one report on all DEV Issue for which their DUNS number is associated.

3.3.Requirement 3 – Market: Make all transitions consistent within MarkeTrak

3.3.1.Description:

Make all transitions from “Unexecutable” to “Complete” use the “Accept” transition.

Make all transitions from “Pending Complete” to “Complete” use the “Complete” transition.

3.4.Requirement 4 – Market: Create Bulk Insert Templates

3.4.1.Description:

Currently Market Participants must create their own templates for Bulk Inserts.

The Market is requesting that ERCOT create all necessary Bulk Insert Templates and incorporate all changes made through PR 70007.

3.5.Requirement 5 - Market: Add Bulk Insert Number to Issues

3.5.1.Description:

For issues submitted through Bulk Insert functionality the Bulk Insert Number should be automatically populated to the Issue Information on the GUI.

The addition of the Bulk Insert Number will allow for grouping of and reporting on issues submitted through Bulk Insert.

3.6.Requirement 6 – Market: Modify Search Arrow next to ID Search

3.6.1.Description:

Currently the search arrow, which is used to initiate a search on the ID Number provided, is not clearly identifiable. The arrow should be made to stand out more by making it larger or bolder.

3.7.Requirement 7 – Market: Do not allow changes to the Title Field on MarkeTrak Issues

3.7.1.Description:

Currently the MarkeTrak tool allows the user to update the Title Field upon create. This causes some difficulty when trying to report off the Title Field. The Market is requesting that the Title Field auto populate, like it does now, but never allow the use to update the field.

GUI:

  • Title field is present and automatically populated but is not updateable

API

  • Remove title field from Issue Create request

Bulk Insert:

  • Remove title field from Bulk Insert

3.8.Requirement 8 – Market: Do not capture Non-ERCOT Owner during “Begin Working” unless the owner field is empty

3.8.1.Description:

Currently the MarkeTrak tool assigns the Owner of an issue when “Begin Working” is selected. This causes it to overlay any information that may have been populated in the Owner Field.

When “Begin Working” is selected, MarkeTrak should only assign owner if the owner field is already blank.

3.9.Requirement 9 – Market: Require Comments for Siebel Chg/Info Sub-types

3.9.1.Description:

Comments are required to have enough information to be able to research and reply to the issue.

GUI:

  • Mark Comments as Required during “Submit”

API: Update Submit

Bulk Insert: Update to reflect that Comments are required

3.10.Requirement 10 – Market: Add Service Period Start Date Field to Missing Transaction, Projects, Siebel Chg/Info, Other, and REP of Record Sub-types. Add Service Period Stop Date Field to REP of Record and Usage and Billing Sub-types.

3.10.1.Description:

Currently the only required field is ESI ID. This is not enough information to research these issues.

-GUI:

  • Add a new field to Submit for Service Period Start Date
  • Optional for the following sub-types:
  • Missing Transaction
  • Projects
  • Siebel Chg/Info
  • Other
  • Required for the following sub-types:
  • REP of Record
  • Usage and Billing
  • Add a new field to Submit for Service Period Stop Date as optional to the following sub-types:
  • REP of Record
  • Usage and Billing

-API:

  • Update Submit and Issue Detail

-Bulk Insert:

  • Update all sub-types involved

3.11.Requirement 11 – Market: Add ISA Field to Submit for 997, Projects, and Other Sub-types

3.11.1.Description:

Currently there is not enough information provided to research these issues.

-GUI:

  • Add a new field to Submit for ISA
  • Optional for the following sub-types:
  • Projects
  • Other
  • Required for the following sub-types:
  • 997

-API:

  • Update Submit and Issue Detail

-Bulk Insert:

  • Update all sub-types involved

3.12.Requirement 12 – Market: Add a new required field to the Reject Sub-type to provide the Reject Reason

3.12.1.Description:

Currently there is not enough information provided to research these issues.

-GUI:

  • Add a new required drop down field to Submit for Reject Code
  • TX SET Reject Codes should be used for the Drop Down
  • Update Field: Revise Comments to Required instead of Optional

-API:

  • Update Submit and Issue Detail

-Bulk Insert:

  • Update Reject Sub-type

3.13.Requirement 13 – Market: Update Transaction Types during “Submit” and Add New Required Tran Type during “Re-Assign” for Missing Transaction

3.13.1.Description:

-GUI:

  • Transition: Submit and Re-Assign
  • Tran Type drop down shall be limited to:
  • All types of 814 transactions
  • 867_04
  • The following Transaction Types should not appear in this drop down list:
  • “All”
  • 867_03 Monthly
  • 867_03 Final
  • All types of 810s
  • All types of 650s
  • Help language should be added to explain what information should be populated in the Original Tran ID Field when submitting an issue

-API:

  • Update to support field changes

-Bulk Insert:

  • Update to support changes to submit drop down

3.14.Requirement 14 – Market: Add Columns to Escalation Email Attachment

3.14.1.Description:

Add additional columns to escalation email attachment that would display all MP Owners associated with each issue. This would eliminate opening each issue to find out the name of the person who is assigned to work the issue.

MarkeTrak tool will provide additional information in the escalation attachment to provide the names of all owners associated with each issue.

If no owner is assigned the field will be null. (,,)

-GUI:

  • No impact

-API:

  • No impact

-Bulk Insert:

  • No impact

3.15.Requirement 15 – Market: Validate ESI ID/TDSP Association

3.15.1.Description:

Add validation during Submit for any issue where an ESI ID is present and the TDSP is the Submitting MP or the Assignee to validate that the ESI ID populated is associated with that TDSP.

Currently some issues are being submitted incorrectly and this validation would help prevent this from happening.

MarkeTrak should return a warning message that “The ESI ID provided is not associated with this TDSP in ERCOT systems”

-GUI:

  • Warning returned

-API:

  • Update to allow for by-pass of this validation

-Bulk Insert:

  • Update to allow for by-pass of this validation

3.16.Requirement 16 – Market: Changes to Usage and Billing Sub-type

3.16.1.Description:

Make the following changes to the Usage and Billing Sub-type

  • Limit the types of transactions that can be submitted as Usage and Billing issue by restricting the transaction types listed in the drop down box to 810s and 867 Monthly Usage
  • Add an additional drop down box to designate whether the missing transaction is tied to an IDR or NIDR account
  • Make the Original Tran ID field optional except for 867_03 Final
  • Add a drop down box to designate whether the transaction is missing or is being disputed by the CR
  • Make the Transaction Date field required

-GUI:

  • Transition: Submit
  • Update Field: Revise Transaction Type Drop Down Box to include single selection as follows:
  • 867_03 Monthly 00
  • 867_03 Monthly 01
  • 867_03 Monthly 05
  • 867_03 Final
  • 810_02
  • 810_03
  • New Required Field: Add Drop Down Box to indicate either IDR or NIDR
  • Min/Max length: 4
  • Type: Alphanumeric Drop Down
  • Permitted Values & Defs:
  • IDR
  • NIDR
  • Default Value: Blank
  • Screen Location: Issue
  • Read Only (Y,N): N
  • Updateable – when, who: N
  • Automatically populated (Y,N): N
  • Field Screen Title: IDR/NIDR
  • Update Field: Revise Original Tran ID field to Optional instead of Required on all Tran Types except for 867_03 Final
  • Help language should be added to explain what information should be populated in the Original Tran ID Field when submitting an issue
  • Update Field: Revise Transaction Date field to Required instead of Optional
  • New Required Field: Add Drop Down Box to indicate either Missing or Dispute
  • Type: Alphanumeric Drop down
  • Permitted Values & Def:
  • Missing
  • Dispute
  • Default Value: Blank
  • Screen Location: Issue
  • Read Only (Y,N): N
  • Updateable – when, who: N
  • Automatically populated (Y,N): N
  • Field Screen Title: Missing/Dispute

API: Update Submit Request and Issue Detail