1. MarkeTrak Enhancements Conceptual Design Review Presented By ERCOT

2. 2 2 PR70007_01: ERCOT Conceptual Design Overview Overview: The ERCOT Conceptual Design Overview provides high-level details for the conceptual design approach with system and user impacts identified. Objective: The objective of the Conceptual Design Overview is to confirm consensus between ERCOT and Market Participants on conceptual design approach and provide system and user impacts to aide in planning of resources and schedules necessary for implementation.

3. 3 3 Requirement 1 Description: Make the order of all buttons consistent on all sub-types GUI Changes: –Update will be made to put all buttons in the same order across all sub- types. Any button not active for the given state (workflow) will not appear. Buttons will display in the following order as determined by the Task Force: 1.Positive 2.Negative 3.System User Impacts: –Push Buttons may appear in a different order than prior to implementation of MarkeTrak Phase 2 API – No changes Bulk Insert – No changes

4. 4 4 Requirement 2 Description: Create a Parent Project Type for DEV Issues GUI Changes: –A new “DEV” parent project type will be added User Impacts: –When a user goes to build a listing report in MarkeTrak, the Report Project field will list/show “DEV” as a parent to all the DEV issue types/sub-types. Selecting “DEV” in the Report Project field will allow the user to build a report against all DEV issue types/sub-types. API – No Change Bulk Insert – No Change

5. 5 5 Requirement 3 Description: Make all transitions consistent within MarkeTrak GUI Changes: –Update workflows to consistently Implement the “Accept” and “Complete” Transitions User Impacts: –Push button names will change to “Accept”, if not already named “Accept”, when transitioning from “Unexecutable (PC)” state to the “Complete” state. –Push button names will change to “Complete”, if not already named “Complete”, when transitioning from any “Pending Complete” state to “Complete” state.

6. 6 6 Requirement 3 - continued Description: Make all transitions consistent within MarkeTrak API Changes –No change because transition is already in acceptable transition name permitted values. User Impacts –Backend system may need to be updated to use the correct transition name when transitioning between “Unexecutable (PC)” and “Complete” states and any “Pending Complete” and “Complete” states Bulk Insert – No change

7. 7 7 Requirement 4 Description: Create Bulk Insert Templates and default Submit Validation Flags for API and Bulk Insert to “Off” GUI – No change API Changes: –Update the validation flag elements of the API WSDL User Impacts: –The API WSDL will assume “false” if any of these validation flags are null.

8. 8 8 Requirement 4 - continued Description: Create Bulk Insert Templates and default Submit Validation Flags for API and Bulk Insert to “Off” Bulk Insert Changes: –Create Bulk Insert Templates and post to ERCOT website –Update processing flags to default to “Off” User Impacts: –If any processing flag is “blank” the processing will assume validation is “Off”

9. 9 9 Requirement 5 Description: Add Bulk Insert Number to Issues GUI Changes: –A new field will be added to all MarkeTrak workflows to provide the “Bulk Insert Parent Issue ID” User Impacts: –A new read only field will appear in the Issue Information Section –If a user is looking at a “child” issue built via Bulk Insert, the field will be populated with the parent Bulk Insert Issue ID. –The field will be available for use in Report criteria and Report results.

10. 10 Requirement 5 - continued Description: Add Bulk Insert Number to Issues API Changes: –Update API WSDL to support new field User Impacts: –New field, BIParentIssue will appear in the QueryResponseIssuetype complex element of the API WSDL –Market Participant’s API backend systems may need to be modified to map the new element on Query Detail Response Bulk Insert –No impact to the Bulk Insert process for Market Participants

11. 11 Requirement 6 Description: Modify Search Arrow next to ID Search GUI Changes: –Modify the search arrow changing the color from grey to black User Impacts: –The arrowhead icon to the right of the ID Search prompt window will now appear as a heavy black arrowhead. API – No change Bulk Insert – No change

12. 12 Requirement 7 Description: Do not allow changes to the Title Field on MarkeTrak Issues GUI Changes: –Update the Create transition on all MarkeTrak workflow transitions to ensure the Title Field is “Read Only”. User Impacts: –The user will no longer have the opportunity to change the default Issue type/sub-type text automatically populated into the Title field during Issue Create

13. 13 Requirement 7 - continued Description: Do not allow changes to the Title Field on MarkeTrak Issues API Changes: Update API WSDL to remove the Title element on Submit Request and recompile with the updated WSDL User Impacts: –User will no longer have the ability to send the Title element on Issue Submit Requests –Market Participant’s backend system may need to be modified to not map the deleted element on submit and update requests. Bulk Insert Changes: Title field will be removed from all Bulk Insert Templates User Impacts: Bulk Insert CSV files will no longer contain the Title field column. This will change the row length and number of fields.

14. 14 Requirement 8 Description: Do not capture Non-ERCOT Owner during “Begin Working” unless the owner field is empty GUI Changes: –Script will be updated to assign non-ERCOT owner if the Issue’s current owner is zero. User Impacts: –No functionality changes when a Company first hits the “Begin Working” transition. –Upon the second execution of the “Begin Working” transition by a Company User, the Company Owner will not change.

15. 15 Requirement 8 - continued Description: Do not capture Non-ERCOT Owner during “Begin Working” unless the owner field is empty API Changes: –No changes User Impacts: –Company Owner will not change upon any subsequent executions of “Begin Working” transition. –API using MP’s backend systems may need to be modified to not send “Assign Owner” transactions following subsequent “Begin Working” transitions. Bulk Insert – No change

16. 16 Requirement 9 Description: Require comments for Siebel Chg/Info Sub-types GUI Changes: –Update the workflow to require comments User Impacts: –When a user creates a Siebel Chg/Info issue in MarkeTrak, they will be required to enter comments before the Issue will successfully create. –An error message will appear if the user does not enter comments. API Changes: Update API WSDL User Impacts: –MP’s API backend systems may need to be modified to map the required field –Will require a recompile with the new WSDL

17. 17 Requirement 9 - continued Description: Require comments for Siebel Chg/Info Sub-types Bulk Insert Changes: –Update the new Bulk Insert Templates to change comments to required User Impacts: –Comments will be required and rows will fail if Comments are not populated –User will see Bulk Insert Validation errors if field is not populated

18. 18 Requirement 10 Description: Add Service Period Start/Stop Date Field to D2D Sub-types GUI Changes: –Update the Missing Transaction, Projects, Siebel Chg/Info and Other workflows to add Service Period Start Date –Update Rep of Record and Usage to add Service Period Start Date and Service Period Stop Date User Impacts: –User sees the Service Period Start Date on all above mentioned issue sub-types Optional for Missing Tran, Projects, Siebel Chg/Info and Other Required for Rep of Record and Usage/Billing –User sees the Service Period Stop Date for Rep of Record and Usage/Billing sub-types optional fields –Help text will be provided for Stop Time

19. 19 Requirement 10 - continued Description: Add Service Period Start/Stop Date Field to D2D Sub-types API Changes: –Update MarkeTrak API WSDL User Impacts: –API Backend systems may need to be modified to map the new required/optional elements on submit and responses. –System will require recompile with the new WSDL. Bulk Insert Changes: –Add 2 new columns to the D2D Bulk Insert Template with appropriate required/optional designations User Impacts: –Rows will fail without required information –New templates will need to be incorporated into systems

20. 20 Requirement 11 Description: Add ISA field to Submit for 997, Projects, and Other sub-types GUI Changes: –Update workflows in include new field Optional for Projects and Other Required for 997 User Impacts: –User will see the ISA Number field and will have the option of populating it for Projects and Other but will be required to populate for 997 issues.

21. 21 Requirement 11 - continued Description: Add ISA field to Submit for 997, Projects, and Other sub-types API Changes: –Update WSDL to support new field User Impacts: –New ISA may appear in QueryResponseIssuetype complex element of the API WSDL –New field, ISA Num IssueSubmitRequest may appear as required/optional in the complex element of the API WSDL –MP’s API backend systems may need to be modified to map the new element on Query Detail Response and/or Issue Submit Request.

22. 22 Requirement 11 - continued Description: Add ISA field to Submit for 997, Projects, and Other sub-types Bulk Insert Changes: –Add new column to the D2D Bulk Insert Template and make appropriate optional/required designations –Add validation for new field User Impacts: –Templates will reflect new field –997 rows will fail if the ISA Number is not populated –User will need to either modify their Bulk Insert file building programs or use the new templates to account for the new field

23. 23 Requirement 12 Description: Add new required field to the Reject Sub-type to provide Reject Reason GUI Changes: –Update Reject Transaction workflow to add new required field –Change the comment field from optional to required User Impacts: –User will be required to select reject code from a drop down list API Changes: –Update WSDL to support new field User Impacts: –New field will appear in QueryResponseIssuetype complex element of WSDL –Reject code and comments will be required in the IssueSubmitRequest complex element of the WSDL –MP’s backend system may need to be modified to map new element

24. 24 Requirement 12 - continued Description: Add new required field to the Reject Sub-type to provide Reject Reason Bulk Insert Changes: –Add new column to the template to incorporate new field –Update to validation –Change comments column to required User Impacts: –Row will fail without population of the Reject Code or Comments –Users will need to either modify their Bulk Insert file building programs or use the new templates to account for the new field on the D2D Bulk Insert type.

25. 25 Requirement 13 Description: Update Transaction Types during “Submit” and Add new Required Tran Type during “Re-assign” for Missing Transaction GUI Changes: –Modify Missing Transaction Workflow to limit Tran Type choices as dictated by Market –Modify Re-assign transition to allow user to update Tran Type User Impacts: –User will be restricted to limited Tran Type choices –User will be able to modify Tran Type during re-assign transition –User will be required to enter the Tran ID on the Complete transition –Help language will be provided for Original Tran ID

26. 26 Requirement 13 - continued Description: Update Transaction Types during “Submit” and Add new Required Tran Type during “Re-assign” for Missing Transaction API Changes: –Modify WSDL to incorporate changes to Tran Type User Impacts: –When creating a new Missing Tran sub-type issue, the API user will be limited by the valid values for Tran Type. –Backend API systems may need to be reviewed to insure all Tran Types are valid and that Tran ID is sent on “Complete” transition

27. 27 Requirement 13 - continued Description: Update Transaction Types during “Submit” and Add new Required Tran Type during “Re-assign” for Missing Transaction Bulk Insert Changes: –Update to validations for Tran Types User Impacts: –User may see new validation error regarding permitted values –User may need to modify Bulk Insert file building program to ensure proper use of permitted Tran Types

28. 28 Requirement 14 Description: Add columns to Escalation Email Attachment Other Changes: –Add new output columns and column headings User Impacts: –Companies Primary and Secondary Escalation contacts per sub-type will see the addition of 6 new columns on the Escalation email Escalation report. Columns will be left blank if no Owner is assigned or if the owner field is not applicable to the row’s Issue sub-type.

29. 29 Requirement 15 Description: Validate ESI ID/TDSP Association GUI and API Changes: –Add validation to verify TDSP/ESI ID association on issues User Impacts: –Users during Issue Submit may be presented with a new warning message if the TDSP returned from ERCOT’s Registration System for the ESI ID involved does not match the TDSP on the Issue being submitted. Bulk Insert Changes: –Update Bulk Insert Template to incorporate validation User Impacts: –Bulk insert will assume validation is “off” –Users will need to either modify their Bulk Insert file building programs or use the new templates to account for the new field.

30. 30 Requirement 16 Description: Changes to Usage and Billing Sub-type GUI Changes/User Impacts: –Users will be limited to the pre-designated drop down list of “Tran Type” during submit –User will be required to select IDR or NIDR from drop down during Submit –Original Tran ID will be Optional except for 867_03 Finals Error will be returned if not populated for “867_03 Final” Add help language to Original Tran ID –User will be required to select Dispute or Missing from drop down during Submit (Cont.)

31. 31 Requirement 16 - continued Description: Changes to Usage and Billing Sub-type GUI Changes/User Impacts: (Cont.) –User will be required to populate Transaction Date Required –User will be required to populate new “Tran ID” field on “Complete” transition for Missing –User will be required to populate new “Tran ID” field on “Submit” for Dispute API Changes: –Modify WSDL to incorporate all field changes User Impacts: –Backend API Systems may need to be reviewed to ensure compliance with all field changes

32. 32 Requirement 16 - continued Description: Changes to Usage and Billing Sub-type Bulk Insert Changes: –Bulk Insert Templates will be updated to incorporate all changes User Impacts: –Rows will fail if required or valid information not provided according to field changes

33. 33 Requirement 17 Description: Reporting Improvements GUI Changes: –Design process flow, similar to Bulk Insert’s, that will allow user to select, from a drop down list, a report to be executed. Once User selects the report, enters any report parms and hits submit, the report request will be passed to a backend system Backend system will execute the report and generate results in a CSV format that will be written to a file and sent to MID/MIR for posting to TML. –A URL link will be added to the Report Issue that will link to TML’s Report Explorer. This will be added to Bulk Insert also User Impacts: –If a user wants to view all rows of a report greater than 3,000 rows, the user should use the “Background Report” workflow type in MarkeTrak

34. 34 Requirement 18 Description: Standardize Sub-type names within DEV LSE Issues GUI Changes/User Impacts: –User will see “LSE in MP sys no ERCOT: De-engz” in Project names lists instead of “LSE in MP sys not ERCOT: inactiv” –All new “LSE in MP sys not ERCOT: De-engz” issues will have a default title field of “LSE Relationship record present in MP System, not in ERCOT: De-energized” API Changes/User Impacts: –Update to WSDL –Users will see new Sub Type name returned with Issue Detail responses Bulk Insert Changes/User Impacts: –User will be presented with “de-energized” sub-type names instead of “inactive” sub-type names on the Create Issue screen

35. 35 Requirement 19 Description: Populate ERCOT Owner and Siebel Status/Sub- status on ERCOT Initiated Issues GUI Changes/User Impacts: –Users will see new fields: “Siebel Status”, “Siebel Substatus”, “Last Siebel Status Retrieval Date” and “ERCOT Owner” in ERCOT Initiated Issue Information section. –Users will see a new push button called “Update Siebel Status/Substatus” on ERCOT Initiated Issues, that when (ESIID and Original Tran ID are populated) executed will retrieve the Issue Global ID’s Siebel Status/Substatus. API User Impacts: –Users will see new fields: “Siebel Status”, “Siebel Substatus”, “Last Siebel Status Retrieval Date” and “ERCOT Owner” returned on ERCOT Initiated Issue Detail responses. Bulk Insert – No change

36. 36 Requirement 20 Description: Provide “First Touched Date” GUI Changes/User Impacts: –“First Touched Date” will be added to all workflows and user will see this field in the Issue Information Section. –This field will either be blank or contain the date the Issue performed it’s first “Begin Working” transition API Changes/User Impacts: –Update WSDL to support the new field –New field will appear in the QueryResponseIssuetype complex element –MP’s API backend systems may need to be modified to map the new element on Query Detail Response. Bulk Insert – No change

37. 37 Requirement 21 Description: Siebel Status/Sub-status Auto Update Upon Completion GUI Changes: –Update “Complete” transition from “In Progress (Assignee)” state on Siebel Chg/Info and ERCOT initiated workflows to add auto Siebel Status update User Impacts: –Users will see that the “Last Siebel Status Retrieval” date has changed to current date, when the ERCOT user transitioned the Siebel Chg/Info or ERCOT Initiated Issue from “In Progress (Assignee)” using the “Complete” transition. API – No change Bulk Insert – No change

38. 38 Requirement 22 Description: Validation of CR for Siebel Change Issues GUI Changes –MarkeTrak will validate that the issue submitter or assignee is the CR associated with the ESI ID in the ERCOT Registration Database User Impacts: –During Submit users will receive error if CR requested to be involved in the issue differed from what ERCOT’s Registration System has as the CR involved with the GlobalID and issue will not be submitted

39. 39 Requirement 22 - continued Description: Validation of CR for Siebel Change Issues API Changes: –Update to WSDL User Impacts: –Error returned –API Users will only see error if ValidateCRAssociation is turned on – defaults to “False” if blank. Bulk Insert Changes: –Bulk Insert Templates will be updated to incorporate validation User Impacts: –Bulk Insert Siebel Change rows will fail if the CR Validation flag is “true” and ERCOT’s Registration System doesn’t match chosen CR Issue DUNS.

40. 40 Requirement 23 Description: Add ability to turn on/off Automation for IAG and DEV Changes: –ERCOT will be able to turn off Adapter calls and workflow automation if necessary. User Impacts: –No Market User impact.

41. 41 Requirement 24 Description: Change the layout of the DEV Analysis Fields on GUI Screen for applicable DEV LSE Sub-types GUI Changes: –Changes made to the layout of DEV Analysis fields User Impacts: –User may notice field order changes on DEV LSE sub-types –Users will now see the following fields on DEVLSE sub-types in ERCOT Systems not MP “Usage Matches Date Requested” instead of “Row Exists at ERCOT” “Usage Loaded for Date Requested” instead of “Usage Exists for Time Period” –Users should use “Usage Matches Date Requested” instead of “Row Exists at ERCOT” and “Usage Loaded for Date Requested” instead of “Usage Exists for Time Period” on all “DEV LSE in ERCOT system not MP” Issue reports.

42. 42 Requirement 24 - continued Description: Change the layout of the DEV Analysis Fields on GUI Screen for applicable DEV LSE Sub-types API Changes: User Impacts: –Backend systems should expect “RowExistsERCOT” and “UsageExistsForTimePeriod” to now appear in “UsageLoadedDateReq” field on all “DEV LSE in ERCOT system not MP” Issue Responses. –Backend systems should not use “RowExistsERCOT” field and “UsageExistsForTimePeriod” field, but use “UsageMatchesDateReq” field and “UsageLoadedDateReq” field (respectively) on all “DEV LSE in ERCOT system not MP” Issue Updates (if applicable to Issue Update request). Bulk Insert – No change

43. 43 Requirement 25 Description: Inadvertent Gain GUI Changes: –Two new workflows will be added to the MarkeTrak Submit Tree under the D2D Parent to accommodate changes requested in this requirement. Inadvertent Gains – Losing Inadvertent Gains – Gaining –Multiple new fields and transitions as outlined in Requirement 25 User Impacts: –Inadvertent Switch workflow will not be in the Submit Tree Users will not be able to submit new Issues but will only be able to work existing Issues –Users will see the two new workflows –Users will see new fields and new transitions as outlined in Requirement 25

44. 44 Requirement 25 - continued Description: Inadvertent Gain API Changes: –Modify WSDL to incorporate new fields and transitions User Impacts: –Users will have two new IAG workflows, new fields to map and new transitions to code –Users will not be able to submit new Inadvertent Switch Issues –Users may see new validation error messages

45. 45 Requirement 25 - continued Description: Inadvertent Gain Bulk Insert Changes: –Templates will be created to accommodate new workflows User Impacts: –Users will see two new D2D sub-types on the D2D Bulk Insert submit table and table will no longer contain Inadvertent Switch –If Users backend systems generate Inadvertent Switch Issues they will need to be converted to generate Inadvertent Gain – Losing and Inadvertent Gain – Gaining

46. 46 Requirement 25 - continued Description: Inadvertent Gain Other Changes: –Make changes to Escalations as stated in Requirement 25 –Add Auto Close to IAG Issues User Impacts: –Responsible MP Primary and Secondary Inadvertent Escalation Contacts will see escalations on new IAG Issues according to rules defined in Requirement 25 –New IAG Issues will Auto Close as stated in Requirement 25

47. 47 Requirement 26 Description: Premise Type Field GUI Changes: –Update MarkeTrak workflows to automatically populate the Premise Type when an ESI ID is provided on an issue User Impacts: –All workflows with an ESI ID defined will now automatically populate and display the “Premise Type” Any workflow that required “Premise Type” is now not applicable Any workflow allowing input of Premise Type will now enforce permitted values (ERCOT Initiated and Premise Type (Req. 37)

48. 48 Requirement 26 - continued Description: Premise Type Field API Changes: –Update WSDL User Impacts: –Users should ensure that their API backend systems do not send Premise Type on Issues Submit. –API backend systems should also be prepared to receive Premise Type in API responses of Issues that contain an ESI ID Bulk Insert Changes/User Impacts: –Templates will no longer be available on the DEV Existence Bulk Insert Table –Premise Type field will be validated against permitted values in ERCOT Initiated and Premise Type Issues

49. 49 Requirement 27 Description: Add Close capability for Submitting MP for the Day to Day and Inadvertent Gain Workflows GUI Changes: –Update workflows to incorporate “Close” transition and “Closed by Submitter” state –Add new transitions of “Complete” and “Unexecutable” to the “In Progress” State User Impacts: –User will see new transition buttons on D2D and IAG Issues API Changes: –Update WSDL User Impacts: –User backend systems may need to be updated to enable the sending of the “Close” transition Bulk Insert – No change

50. 50 Requirement 28 Description: Various Changes to Cancel with Approval GUI Changes/User Impacts: –Users will be presented with new fields, updated/new transitions, and warning messages as outlined in Requirement 28 API Changes: –Update to WSDL User Impacts: –Users may see error messages returned if validations are turned on –Backend systems may need to be reviewed to ensure they have the ability to send the new field and updated transition, if desired. –Backend systems may need to be updated to handle the addition of “Priority” and “SMRD” fields returned.

51. 51 Requirement 28 - continued Description: Various Changes to Cancel with Approval Bulk Insert Changes: –Bulk Insert Template will be updated to include new fields User Impacts: –Users will need to either modify their Bulk Insert file building programs or use the new templates to account for the new fields Other Changes: –Add escalations as outlined in Requirement 28 –Add Siebel Status Auto Update and auto “Complete” transition User Impacts: –New Issues may appear on escalation lists

52. 52 Requirement 29 Description: Various Changes to Cancel Without Approval GUI Changes: –MarkeTrak will validate that the TDSP specified in the Issue is the TDSP associated with the ESI ID –Rename the “Cancel Item” transition between “In Progress (ERCOT)” and “Cancelled (PC)” to “Item Cancelled” User Impacts: –Users will be presented with warning if TDSP specified in the issue is not associated with the ESI ID in the ERCOT Registration System API Changes: –Update WSDL to incorporate validation User Impacts: –Backend systems may need to be reviewed to ensure they have the ability to send the few field and updated transition

53. 53 Requirement 29 - continued Description: Various Changes to Cancel Without Approval Bulk Insert Changes: –Bulk Insert Template will be updated to include new field for TDSP Validation User Impacts: –Users will need to either modify their Bulk Insert file building programs or use the new templates to account for the new validation

54. 54 Requirement 30 Description: Add “New Total” Required field to certain DEV IDR Sub-types GUI Changes: –Update the DEV IDR Sub-types as outlined in Requirement 30 User Impacts: –Users will now have to provide a value for “New Total” on designated sub-types API Changes: –Update to WSDL User Impacts: –Backend systems may need to be updated to accommodate new field and validation associated with the required field

55. 55 Requirement 30 - continued Description: Add “New Total” Required field to certain DEV IDR Sub-types Bulk Insert Changes: –Bulk Insert Template will be updated to incorporate the new field User Impacts: –Users should ensure they add the new column to the designated sub-types and be prepared to receive validation error associated with the required field.

56. 56 Requirement 31 Description: Add Service History with DUNS for Affected Period to DEV LSE Sub-types GUI Changes: –Add SHwDfAP to submit screen as outlined in the requirement User Impacts: –TDSP must submit SHwDfAP information if submitting a DEV LSE issue that requires service history Will see new error if information is not provided –Only TDSPs and ERCOT will have access to view/update the SHwDfAP fields

57. 57 Requirement 31 - continued Description: Add Service History with DUNS for Affected Period to DEV LSE Sub-types API Changes: –Update WSDL to incorporate changes User Impacts: –Users will need to review backend systems to ensure they specify the Service History on Submit and Update requests –TDSPs will now see the Service History fields returned in responses

58. 58 Requirement 31 - continued Description: Add Service History with DUNS for Affected Period to DEV LSE Sub-types Bulk Insert Changes: –Bulk Insert Templates will be updated User Impacts: –Users will need to either modify their Bulk Insert file building programs or use the new templates to account for the new fields. –Validations on format of the new date fields will be performed if they contain values

59. 59 Requirement 32 Description: Capture Modify/Reassign StartTime and/or StopTime fields on DEVLSE Issues and make them available on the issue GUI Changes/User Impacts: –Workflow will be updated to capture a log of the changes made using the “Modify/Reassign” transition on the “NewStartTime” and “NewStopTime” fields API Changes/User Impacts: –Comments will be returned as normal for API but will include the log of changes Bulk Insert – No change

60. 60 Requirement 33 Description: Provide update via API whenever a Market Participants Visibility to an Issue has been removed GUI Changes: –Rename “Intervention by ERCOT” transition to “Wrong MP Involved” and “Closed by ERCOT” state to “Intervention Complete” on all workflows –Delete any information in the issues so that permissions are not removed but information is not available User Impacts: –Issues that have “Wrong MP Involved” transitioned will contain “X’s” and “O’s” in fields and ERCOT will be the owner –Users may need to review their reports to ensure the inclusion/exclusion of “Wrong MP Involved” Issues

61. 61 Requirement 33 - continued Description: Provide update via API whenever a Market Participants Visibility to an Issue has been removed API Changes: –Update to WSDL User Impacts: –Minor recompile or user backend systems –Backend systems may need to be updated to comprehend “Intervention Complete” state by updating or deleting all the Issues’ fields (updating Proprietary data) and Closing the Issue from continued processing Bulk Insert – No change

62. 62 Requirement 34 Description: Support for XML Special Characters GUI – No change API Changes: –ERCOT systems will be updated to ensure proper processing of Special Characters (applies to all text fields) User Impacts: –Users will need to update their systems to make sure they can support the use of Special Characters Bulk Insert Changes: –ERCOT systems will be updated to ensure proper processing of Special Characters User Impacts: –Users will be able to use Special Characters (applies to all text fields)

63. 63 Requirement 35 Description: DEV Workflow Changes GUI Changes: –Add new transitions as outlined in Requirement 35 –Remove “Closed by Submitter” transition from DEV Characteristics –Create new notification that users can subscribe to that alerts when Issues transition to “Closed by Submitter” User Impacts: –User will have new transitions available and will be able to subscribe to new notification API Changes: –Update WSDL User Impacts: –Backend systems need to be updated to enable sending of new and exclusion of deleted transitions Bulk Insert – No change

64. 64 Requirement 36 Description: Email “push” button GUI Changes: –Update MarkeTrak Workflow –Update TeamTrak email setting and permissions User Impacts: –Users will see a new push button called “Email Responsible MP” on all issue types/sub-types. Users can use this push button to email the Responsible MP contacts for a given issue. –All Emails sent from an Issue will appear as Note Attachments on that issue. Any User will view permissions will be able to view the email. –Users will be able to add and view all Issue notes.

65. 65 Requirement 36 - continued Description: Email “push” button API Changes: –Update MarkeTrak API WSDL –Updates to ERCOT’s internal TIBCO and Visual Studio Adapters User Impacts: –New fields will appear in the ResponseIssueType complex element of the API WSDL and “AttachmentExits” will no longer be visible. –Market Participant’s API backend systems may need to be modified to map the new elements on Query Detail Response. Bulk Insert – No changes

66. 66 Requirement 37 Description: New Premise Type and Service Address Sub-types GUI Changes: –New workflows created as outlined in Requirement 37 User Impacts: –CR Users will see 2 new workflows listed under D2D Type on the Submit Tree API Changes: –Update WSDL to incorporate new workflows User Impacts: –New workflows will be available to API Users Bulk Insert Changes: –Create Bulk Insert Template User Impacts: –CR Users will be able to submit Premise Type and Service Address Issues through Bulk Insert

67. 67 Requirement 38 Description: New D2D Sub-type titled “Safety Net Order” GUI Changes: –New workflow created as outlined in Requirement 37 User Impacts: –TDSP Users will see new workflows listed under D2D Type on the Submit Tree API Changes: –Update WSDL to incorporate new workflow User Impacts: –New workflow will be available to API Users

68. 68 Requirement 38 - continued Description: New D2D Sub-type titled “Safety Net Order” Bulk Insert Changes: –Create Bulk Insert Template User Impacts: –TDSP Users will be able to submit Safety Net Order Issues through Bulk Insert

69. 69 Requirement 39 Description: New D2D Sub-type titled “Service Order – 650” GUI Changes: –New workflow created as outlined in Requirement 39 User Impacts: –Users will see new workflows listed under D2D Type on the Submit Tree API Changes: –Update WSDL to incorporate new workflow User Impacts: –New workflow will be available to API Users

70. 70 Requirement 39 - continued Description: New D2D Sub-type titled “Service Order – 650” Bulk Insert Changes: –Create Bulk Insert Template User Impacts: –Users will be able to submit Service Order Issues through Bulk Insert

71. 71 Requirement 40 Description: New D2D Sub-type titled “Move Out with Meter Removal” GUI Changes: –New workflow created as outlined in Requirement 40 User Impacts: –TDSP Users will see new workflows listed under D2D Type on the Submit Tree API Changes: –Update WSDL to incorporate new workflow User Impacts: –New workflow will be available to API Users

72. 72 Requirement 40 - continued Description: New D2D Sub-type titled “Move Out with Meter Removal” Bulk Insert Changes: –Create Bulk Insert Template User Impacts: –TDSP Users will be able to submit Move Out with Meter Removal Issues through Bulk Insert

73. 73 Requirement 41 Description: Correct logic used in the StartTime fields on DEVLSE Issues GUI Changes: –Correct the logic used to display the StartTime User Impacts: –Users shouldn’t be impacted, except that the StartTime, NewStartTime and Resolution field information will be correctly displayed after “Submit” and “Modify/Reassign” transitions. API – No change Bulk Insert – No change

74. 74 Requirement 42 Description: Correct logic used in the StopTime fields on DEVLSE Issues GUI Changes: –Correct the logic used to display the StopTime User Impacts: –Users shouldn’t be impacted, except that the StopTime, NewStopTime and Resolution field information will be correctly displayed after “Submit” and “Modify/Reassign” transitions. API – No change Bulk Insert – No change

75. 75 Requirement 43 Description: IAG Analysis Automation (ERCOT Change) GUI Changes: –Automation of IAG Analysis in ERCOT’s internal systems User Impacts: –No impact to Market users. –ERCOT Users may see a reduction in the amount of IAG issues to be worked manually due to automation. API Changes: User Impacts: Bulk Insert – No change

76. 76 Requirement 44 Description: DEV Analysis Automation (ERCOT Change) GUI Changes: –Automation of DEVLSE Analysis in ERCOT’s internal systems User Impacts: –No impact to Market users. –ERCOT Users may see a reduction in the amount of DEV LSE issues to be analyzed manually due to automation. API Changes: –Update MarkeTrak WSDL User Impacts: –Market API user’s backend API programs may need to updated to capture the “AnalysisInfo” data and states/transitions. Bulk Insert – No change

77. 77 Requirement 45 Description: Allow MP to request Bulk Insert for MarkeTrak Quarterly Validation LPA Issues GUI Changes: –Updates made to ERCOT Initiated Issue submit to allow for the input of LPA elements (update workflow) User Impacts: –ERCOT users will see new fields when creating “ERCOT Initiated” Issues and new LPA category types. –If requested, Market users will see increased number of “ERCOT Initiated”/LPA category issues.

78. 78 Requirement 45 - continued Description: Allow MP to request Bulk Insert for MarkeTrak Quarterly Validation LPA Issues API Changes: –Update WSDL to incorporate new fields User Impacts: –New elements and category enumerations will be added to “ERCOT Initiated” Issue responses. –Market Participant’s API backend systems may need to be modified to map the new elements and expected new category enumerations.

79. 79 Requirement 45 - continued Description: Allow MP to request Bulk Insert for MarkeTrak Quarterly Validation LPA Issues Bulk Insert Changes: –Add columns to ERCOT Initiated type submit table as identified in Appendix A of detailed requirements –Add new fields to the existing “ERCOT Initiated” validation script –Update the Bulk Insert Validation script to Use the updated count of the number of fields in each row for each MarkeTrak issue type/sub-type User Impacts: –User will see a new ERCOT Initiated Bulk Insert submit table. –LPA Issue field will not appear on the Issue, it will become an Issue link on the new issue created.

80. 80 Any Questions?