MarkeTrak Issue Resolution Tool Retail Market Participant Workshop

MarkeTrak Overview

3 Bulk Insert Requirement 4

4 Bulk Insert A method via the GUI application to submit multiple issues at once Must use a csv (comma separated value) file to submit issues All issues within a single csv file must be of the same issue sub-type

5 Bulk Insert – Creating csv file Guidelines for creating csv input file –Bulk Insert Templates can be found on the MarkeTrak Information page. ( –Use the MarkeTrak data field tables as a guide. –Must use all fields even if left blank –Follow csv file format rules: Pay attention to special characters because it may alter columns –Exclude header row Requirement 4

6 Bulk Insert DATE FORMAT: YYYY-MM-DDTHH:MM:SS

7 Bulk Insert – Creating csv file Cancel With Approval Template found on MarkeTrak Information page.

8 Bulk Insert – Creating csv file **NOTE: 1 in the Optional Columns N and O means run those validations. Otherwise Validations are defaulted to 0 (do not run) Requirement 4

9 Bulk Insert – Creating csv file Delete both of the Header Rows before saving as a csv file

10 Bulk Insert – Creating csv. file

11 **You will have to open your csv file in notepad and verify that all fields are represented by commas.**

12 **Add any missing commas (place holders) to the issues**

13 Background Report Requirement 17

14 Market Participants have requested the ability to run reports that would involve more than 1000 rows of data. In an effort to accommodate this request, ERCOT has enabled Market Participants to request reports that are run in the background and are delivered either as attachments or posted to TML. Report will be posted as a.csv file This ability allows Market Participants to increase their efficiency by allowing the Market Participant to request large reports and continue working in MarkeTrak while the report is being run. Multiple background reports can be requested, so Market Participants do not have to wait for an individual report to complete before moving on to other MarkeTrak tasks. Background Report Overview

15 From Submit Tree, CR selects Background Report

16 CR then selects the appropriate report from the drop-down menu and types any comments (optional) and clicks “OK” button

17 Background Reports Available and Descriptions Report NameReport Description Average Days OpenReport to Provide average days open by subtype for the time frame specified. Count of Active and Inactive IssuesReport to provide a count of Active and Inactive issues for the time frame specified. Count of Issues Resolved Outside Benchmark Returns a count of issues closed outside of the specified benchmark number of days for a particular time frame. Count of Issues Resolved Within Benchmark Returns a count of issues resolved within the specified benchmark number of days for a particular time frame. Count of Issues in StateReport to provide the total number of issues in each state for the selected subtype(s) for the time frame specified. Details for Issues Resolved Outside of Benchmark Returns details for issues closed outside of the selected benchmark number of days within the time frame specified. Issue Details by ESIIDIssue Details for a select group of ESIIDs for the subtype(s) selected. Issue Details by Issue IDIssue Details for a select group of Issue IDs for the subtype(s) selected. New User Issue AccessReport to add a new user to the existing issues for the purpose of granting visibility. Time in StateReport to provide the days an issue spent in each distinct state both the first time it moves into the state as well as the last time if applicable. Total No. ClosedReport to provide a count by subtype of all issues closed within the specified time frame. Issues Open Outside BenchmarkReport to Provide the active issues that have been open outside of the selected benchmark number of days.

18 CR is then given a screen showing what report they are requesting. CR will then click the “Provide Parameters” button.

19 CR Selects Destination for report (either Issue Attachment or TML) from the Report Destination drop-down menu

20 CR Selects applicable project(s) from the MarkeTrak Projects drop- down menu. *Note: All background reports have the option, but some background reports do not require the MarkeTrak Projects field to be populated. All required parameters for the report type selected will be shown above the Report Destination drop-down menu

21 CR Inputs Parameters required for the type of background report that is being requested. Different reports have different parameters. Any parameters that are not necessary will either not be visible or will show the “Not Used” header. Once all Parameters are filled out, CR clicks the “OK” button

22 If CR would like to be notified upon completion of the report, the CR Clicks the “Actions” drop-down menu, selects “Add Item Notification” and selects “MT – Background Report has been prepared”. This must be done prior to submission of the report request.

23 CR then reviews the details of the background report submission and has the option to either ‘Update Parameters’, ‘Withdraw’, ‘Add Comment’ or “Submit Report” using the buttons at the top of the page.

24 At this point the report has been submitted and will be posted either as an attachment or to TML, whichever was requested. Reports will be available on TML for 30 days

25 Once the report has completed and is either attached to the issue or posted to TML, the MarkeTrak issue will Auto-Close.

26 Screenshot of an example report

27 If the report encounters an error, the report will post with all data present up to the point in which the error occurred and will include a description of the source of the error in the last populated column. Possible errors may include (but not limited to): SQL errors –Data requested in wrong format (date that does not exist, etc) –Start and Stop time transposed If a report encounters an error, you cannot modify the report once submitted. You will have to submit another background report request with the needed modifications.

28 Requirement 31

29 LSE in ERCOT System but not in MP System

30 LSE relationship record present in ERCOT system but not in MP system Submitted TDSP to ERCOT CR to ERCOT TDSPs and CRs should file this variance when: –LSE relationship should be removed at ERCOT When a de-energized period would be created in ERCOT’s systems to complete a Variance, the TDSP will be asked to confirm rep of record for the affected time period Submitting MP and Assignee must be in agreement prior to process the change request ERCOT Resolution Remove LSE relationship from ERCOT systems

31 LSE relationship record present in ERCOT system but not in MP system Requested Resolution equals Remove LSE relationship from ERCOT systems Information should reflect relationship as is present in ERCOT systems and is communicated to the MP through their ESI ID Data Extract (SCR727) If a de-energized period is being created in ERCOT systems where TDSP reflects a rep of record, TDSP is required to inform ERCOT of rep of record as is reflected in their systems per RMS decision on 8/14/2003 Most required fields are found in your ESI ID Extract (SCR727) Quick Notes

32 LSE in ERCOT system not MP 1. The TDSP selects the Submit tab 2. From the Submit Tree, select LSE in ERCOT system not MP 1 2

33 3. The following fields must be populated for successful submission of a DEV- LSE sub type LSE in ERCOT System not MP: Assignee ESI ID UIDESIID STARTTIME STOPTIME- optional PROFILECODE REP CODE ADDTIME STATUS ROR 1 (if Submitter is TDSP) 4. Select OK LSE in ERCOT system not MP

Requirement 31 TDSP

35 LSE in ERCOT system not MP Three Validations Occur: –ESI ID Validation- Is the ESI ID valid? –ESI ID Duplicate Check- Are there any other MarkeTrak issues submitted with the same ESI ID for the same company? –TDSP associated with ESI ID?

36 LSE in ERCOT system not MP The issue enters ERCOT’s queue in the state of “New” and is visible only by the Submitter, Assignee and ERCOT The Submitter can ‘Withdraw’ only. ERCOT can acknowledge it only TDSP

37 LSE in ERCOT system not MP 5. ERCOT selects ‘Begin Working’ 5 Only ERCOT and TDSP can view the TDSP Information within the issue. (Requirement 31) ERCOT

38 LSE in ERCOT system not MP 6. The Submitter can no longer ‘Withdraw’ the issue. ERCOT has the options: ‘Passed Analysis’ or ‘Unable to Complete’, which transitions the issue to an “Unable to Complete (PC)” status or ERCOT selects primary path: ‘Passed Analysis’ 6 ERCOT

39 LSE in ERCOT system not MP 7. The following fields must be populated by ERCOT to complete the transition based on this sub type: Usage Matches Date Requested, Usage Loaded for Date Requested and Usage for Time Period 8. Once these fields are populated, ERCOT selects ‘OK’

ERCOT

41 LSE in ERCOT system not MP The issue is transitioned to a state of “New (Pending Approval)”. The visibility of the issue remains unchanged. Only the Responsible MP (CR) can transition and the only option is ‘Begin Working’ CR

42 LSE in ERCOT system not MP From the state of “In Progress-Pending Approval” the Responsible MP has three options: ‘Update Approved’, ‘No Agreement Reached’ or ‘Modify/Reassign’ for Approval transitioning to a “New-Pending Approval State” CR

43 LSE in ERCOT system not MP 9. Selection of ‘Update Approved’, the Responsible MP is agreeing to the current requested resolution 9 CR

44 LSE in ERCOT system not MP 10. The Responsible party (CR) can provide Comments at this time and Select ‘OK’. The issue will transition to state “New (ERCOT Resolve) 10 CR

45

46 LSE in ERCOT system not MP 11. ERCOT selects ‘Begin Working’ 11 ERCOT

47 LSE in ERCOT system not MP 12. ERCOT has the option to select ‘Additional Info Required’, ‘Unexecutable’ or ‘Complete’. In this example, ERCOT selects ‘Complete’ 12 ERCOT

48 LSE in ERCOT system not MP The change would be made in Siebel/Lodestar and notifications would be sent to affected MPs. The issue is transitioned to a “Pending Complete” state The Submitter has the option to close the issue by selecting ‘Complete’ or the issue will be auto closed in 14 calendar days TDSP

49 LSE in ERCOT system not MP The issue will transition to a “Complete” (Closed) state. TDSP

50 Questions

51 LSE Date Change: Start Time and Stop Time

52 LSE relationship records present in both systems but Start and Stop Time do not match Submitted TDSP to ERCOT CR to ERCOT TDSPs and CRs should file this variance when: –LSE relationship STARTTIME and STOPTIME should be changed at ERCOT Analysis performed to determine if the new relationship conflicts with existing LSE relationships. When a de-energized period would be created in ERCOT’s systems to complete a Variance, the TDSP will be asked to confirm rep of record for the affected time period. Affected CR will be notified Submitting MP and Assignee must be in agreement prior to process the change request ERCOT Resolution Change LSE Relationship STARTTIME and STOPTIME in ERCOT systems

53 Date different should exceed +/- 2 calendar day variance. Requested Resolution equals Change LSE Relationship STARTTIME and STOPTIME in ERCOT systems New Start Time <> STARTTIME; format mm/dd/yyyy 00:00:00 New Stop Time <> STOPTIME; format mm/dd/yyyy 23:59:59 ERCOT’s preferred method of indicating an active relationship is to leave the STOPTIME/New STOPTIME blank If a de-energized period is being created in ERCOT systems where TDSP reflects a rep of record, TDSP is required to inform ERCOT of rep of record as is reflected in their systems per RMS decision on 8/14/2003 Most required fields are found in your ESI ID Extract (SCR727) Quick Notes LSE relationship records present in both systems but Start and Stop Time do not match

54 LSE in ERCOT system not MP 1. The CR selects the Submit tab 2. From the Submit Tree, select LSE date change: Start and Stop 1 2

55 LSE Date Change: StartTime 3. The following fields must be populated for successful submission of a DEV- LSE sub type LSE date change: Start and Stop Assignee New STARTTIME STARTTIME STOPTIME STATUS UIDESIID PROFILE CODE REP CODE ADDTIME ROR1 (if Submitter is TDSP) 4. Select OK

CR

57 LSE Date Change: StartTime Three Validations Occur: –ESI ID Validation- Is the ESI ID valid? –ESI ID Duplicate Check- Are there any other MarkeTrak issues submitted with the same ESI ID for the same company? –TDSP associated with ESI ID?

58 LSE Date Change: StartTime The issue enters ERCOT’s queue in the state of “New” and is visible only by the Submitter, Assignee and ERCOT The Submitter can ‘Withdraw’ only. ERCOT can acknowledge it only

59 CR

60 LSE Date Change: StartTime 5. ERCOT selects ‘Begin Working’ 5 ERCOT

61 LSE Date Change: StartTime 6. The Submitter can no longer ‘Withdraw’ the issue. ERCOT has the options: ‘Passed Analysis’ or ‘Unable to Complete’, which transitions the issue to an “Unable to Complete (PC)” status or ERCOT selects primary path: ‘Passed Analysis’ 6 ERCOT

62 LSE Date Change: StartTime 7. The following fields must be populated by ERCOT to complete the transition based on this sub type: Usage Matches Date Requested, Usage Loaded for Date Requested and Another CR Involved 8. Once these fields are populated, ERCOT selects the ‘OK’

ERCOT

64 LSE Date Change: StartTime The issue is transitioned to a state of “New (Pending Approval)” with the TDSP as the Responsible Party.

65 LSE Date Change: StartTime 9. The Responsible MP (TDSP) selects ‘Begin Working’ 9 TDSP

66 LSE Date Change: StartTime From the state of “In Progress-Pending Approval” the Responsible MP has three options: ‘Update Approved’ ‘No Agreement Reached’ ‘Modify/Reassign ’ TDSP

67 LSE Date Change: StartTime 10. Selection of ‘Update Approved’, the Assigned MP did agree with the current requested New STARTTIME and New STOPTIME. The TDSP is required to enter Rep of Record Information (Requirement 31) in the TDSP Information section if: New StartTime > StartTime and/or New StopTime < StopTime

68 10a 10b CR Requirement 31

69 LSE Date Change: StartTime The issue is transitioned to a “New (ERCOT Resolve)” state with ERCOT as the Responsible Party TDSP

70 LSE Date Change: StartTime 11. ERCOT selects ‘Begin Working’ 11 ERCOT

71 LSE Date Change: StartTime 12. ERCOT Selects ‘Complete’; the change would be made in Siebel/Lodestar and notifications would be sent to any MPs affected by the change ERCOT 12

72

73 LSE Date Change: StartTime The issue is transitioned to a “Pending Complete” state. The Submitter has the option to close the issue by selecting ‘Complete’ or the issue will be auto closed in 14 calendar days

74 LSE Date Change: StartTime 13. The Submitter will select ‘Complete’ 13 CR

75 LSE Date Change: StartTime The issue will go to a “Complete” state and be Closed. CR

76 ERCOT Intervention Requirement 33

77 An ERCOT Intervention can occur for the following reasons: 1.The wrong CR is assigned and Proprietary information is included in the issue. An ERCOT Intervention will remove the proprietary information from the wrong CRs view and close the issue. 2. An issue is in a “Hung” state because of a Market Participant leaving the market or unable to access the issue.

78 TDSP creates a Safety Net issue but assigns the incorrect CR. ERCOT Intervention Wrong CR Assigned TDSP

79 The Assignee’s view of the issue before ERCOT Intervention. Wrong CR View ERCOT Intervention

80 The TDSP contacts ERCOT via or phone to inform them that the wrong CR is included on a MarkeTrak issue and the issue needs to be closed. ERCOT opens the issue and hits the ‘Intervention By ERCOT’ button ERCOT ERCOT Intervention

81 ERCOT enters Required *Comments at this point and selects ‘OK’ ERCOT ERCOT Intervention

82 The issue will be transitioned to a state of “Closed By ERCOT (Closed)” and all proprietary information will be hidden from all MPs involved except ERCOT. ERCOT View Only ERCOT will continue to see issue information ERCOT Intervention

83 Submitter and Assignee will only have Comments field available for review and ERCOT will be the owner. Wrong CR View ERCOT Intervention

84 API Changes When an Issue is “Intervention by ERCOT” the last modified date will be updated. This will trigger the MP’s backend system to pull a Query Detail for the Issue. In the Query Detail Response, all proprietary fields will be X’ed and O’ed. All issue attachments will not be sent, triggering the MP’s API Backend System to remove any attachment information. The issue will be in a “Closed by ERCOT” state. API Users will need to make a minor recompile of their backend applications to comprehend “Closed by ERCOT” state by updating all the Issue’s fields (removing Proprietary data) and Closing the Issue from continued processing. ERCOT Intervention

85 ERCOT Intervention

86 Support XML Characters Requirement 34

87 Requirement 34 Market: Support for XML Special Characters Description All XML reserved characters should be supported throughout the GUI, API and Bulk Insert MarkeTrak Interface on all text fields. This will resolve a current problem with special characters causing XML parsing errors with the API Interface (‘,&, ) This will resolve a current problem with special characters being pulled through the API Special characters are able to be received and interpreted correctly

88 Requirement 34 API user’s backend applications will need to be updated to be able to encode any special characters received to be XML compatible. Also their backend applications will need to be updated to be able to decode any XML compatible special characters into user friendly characters. In this way the company’s MarkeTrak users will not see any impact

89 Requirement 36

90 Responsible Party – Selecting this button will allow the user to contact the Responsible MP Primary, Secondary and Issue Owner directly. Yes Requirement 36

91

92 The will be attached to the Issue as a Note Attachment.

93 Requirement 37-40

94 Day To Day Subtype Descriptions Premise TypeRequirement 37 …CR users to submit an issue to ask that the TDSP evaluate the Premise Type associated with an ESI ID for a possible change and update if applicable. Service AddressRequirement 37 …CR users to submit an issue to ask that the TDSP evaluate the Service Address associated with an ESI ID for a possible change and update if applicable. Service Order - 650Requirement 39 …CR/TDSP has an issue concerning the 650 service orders. Move Out With Meter RemovalRequirement 40 …TDSP will notify CR that a Move Out transaction is necessary after a 650_04 was sent to CR. Safety NetRequirement 38 …TDSPs submit to CRs when requesting a backdated MVI on a previous Safety Net Order request. Other…CR/TDSP has Day to Day issues that do not fit one of the Sub Types indicated above such as: Siebel/997 reports, CSA’s. Issue Sub-Type:Submitted when…

95 Premise Type and Service Address Requirement 37

96 Premise Type The CR needs the TDSP to evaluate the Premise Type for a certain ESI ID and update if applicable

97 Premise Type The CR selects the Submit tab From the Submit Tree, select Premise Type

98 Premise Type The following fields must be populated for a successful submission of a Day to Day Issue sub type Premise Type: * Assignee The Assignee will be the TDSP associated with the ESI ID and is determined by the Submitter. * ESI ID *New Premise Type What the CR feels the new Premise Type should be. *Comments Comments are required Select ‘OK’

99 CR

100 Premise Type 3 Validations Occur: –ESI ID Validation- Is the ESI ID valid? –ESI ID Duplicate Check- Are there any other MarkeTrak issues submitted with the same ESI ID for the same company? –TDSP associated with ESI ID? Selecting ‘OK’ after each validation will override the validation and take you a step further in submitting your issue

101 Premise Type The issue enters the TDSP’s queue in a state of “New” and is visible only by the Submitter (CR) and the TDSP The Submitting CR can ‘Withdraw’ the issue at this point CR

102 Premise Type The TDSP selects ‘Begin Working’ and the issue is transitioned in a new state of “In Progress Assignee”. At this point, the Submitting CR can no longer ‘Withdraw’ the issue TDSP

103 TDSP

104 Premise Type The TDSP reviews the issue and has the following options: –“814_20 Sent/ Complete” – This means you have sent an 814_20 Maintain in order to update the Premise Type for the ESI ID. This transitions to a state of “Pending Complete” –‘Unexecutable’- This means you will not be able to resolve the issue. This transition results in state “Unexecutable- Pending Complete” –‘Return to Submitter’- This means you need additional information from the submitter to resolve the issue. This transition does not close the issue. Once selected it requires comments and then the issue is transitioned back to the Submitter for more information The Submitting CR at any point can close the issue by selecting the ‘Close’ button. The issue will then go into a “Closed By Submitter” state

105 Premise Type The TDSP will send the 814_20 Maintain transaction and select ‘814_20 Sent/Complete’ TDSP

106 Premise Type TDSP Comments are required. TDSP presses ‘OK’ to transition the issue to a state of “Pending Complete” with the Submitter as the Responsible Party. TDSP

107 Premise Type In this state, the CR has the option to close the issue by selecting ‘Complete’ or the issue will be auto closed in 14 calendar days CR

108 Premise Type CR

109 Service Address The CR needs the TDSP to evaluate the Service Address for a certain ESI ID and update if applicable

110 Service Address The CR selects the Submit tab From the Submit Tree, select Service Address

111 Service Address The following fields must be populated for a successful submission of a Day to Day Issue sub type Service Address: * Assignee The Assignee will be the TDSP associated with the ESI ID and is determined by the Submitter. * ESI ID *New Service Address What the CR feels the new Service Address should be. *New Service City What the CR feels the new Service City should be. New Service State Defaulted to ‘TX’. *New ZIPCODE What the CR feels the new Service Address should be. *Service Address What the current Service Address is. *Service City What the current Service City is. Service State Defaulted to ‘TX’. *ZIP What the current Zip Code is. *Comments Comments are required Select ‘OK’

112 CR The CR will enter in the required information and Select ‘OK’ to Submit issue. Service Address

113 Service Address 3 Validations Occur: –ESI ID Validation- Is the ESI ID valid? –ESI ID Duplicate Check- Are there any other MarkeTrak issues submitted with the same ESI ID for the same company? –TDSP associated with ESI ID? Selecting ‘OK’ after each validation will override the validation and take you a step further in submitting your issue

114 Service Address The ‘Service Address’ Workflow will now follow the same Workflow as ‘Premise Type’. 1. MarkeTrak issue is assigned to the state of “New” with the TDSP as the Responsible Party. 2. TDSP User selects ‘Begin Working’ 3. MarkeTrak issue is assigned to the state of “In Progress” with the TDSP as the Responsible Party. 4. TDSP User selects ‘814_20 Sent/Complete’ and enters Required Comments. 5. MarkeTrak issue is assigned to the state of “Pending Complete” with the Submitting MP as the Responsible party. 6. Submitting MP User selects ‘Complete’ MarkeTrak Issue is assigned to the state of “Complete” with the Submitting MP as the Responsible Party.

115 Service Order Requirement 39

116 Service Order The CR sends a 650_01 transaction, but receives a 650_02 Reject transaction and would like more explanation on reject reason.

117 The CR selects the Submit tab From the Submit Tree, select Service Order- 650 Service Order - 650

118 The following fields must be populated for a successful submission of a Day to Day Issue sub type Premise Type: * Assignee The Assignee will be the TDSP associated with the ESI ID and is determined by the Submitter. * ESI ID * Original Tran ID *Tran Type The 650 transaction type that the submitter would like the Assignee to evaluate. *Comments Comments are required Select ‘OK’ Service Order - 650

119 CR Service Order - 650

120 Validations Occur: –ESI ID Validation- Is the ESI ID valid? –ESI ID Duplicate Check- Are there any other MarkeTrak issues submitted with the same ESI ID for the same company? –TDSP associated with ESI ID? –Global ID Duplicate Check- Are there any other MarkeTrak issues submitted with the same global id (ESI ID + original tran id) for the same company? –Invalid Original Tran ID/ ESI ID combination does not exist - ERROR ESI ID/ Original Tran ID combination “global id” is not valid according to the ERCOT Registration System Click OK again after corrections made to continue or Cancel to abort Selecting ‘OK’ after each validation will override the validation and take you a step further in submitting your issue Service Order - 650

121 The issue enters the TDSP’s queue in a state of “New” and is visible only by the Submitter (CR) and the TDSP The Submitting CR can ‘Withdraw’ the issue at this point CR Service Order - 650

122 The TDSP selects ‘Begin Working’ and the issue is transitioned in a new state of “In Progress Assignee”. At this point, the Submitting CR can no longer ‘Withdraw’ the issue TDSP Service Order - 650

123 TDSP

124 The TDSP reviews the issue and has the following options: –“Complete” – This means you have reviewed the issue and can provide feedback on the transaction in question. This transitions to a state of “Pending Complete” –‘Unexecutable’- This means you will not be able to resolve the issue. This transition results in state “Unexecutable- Pending Complete” –‘Return to Submitter’- This means you need additional information from the submitter to resolve the issue. This transition does not close the issue. Once selected it requires comments and then the issue is transitioned back to the Submitter for more information The Submitting CR at any point can close the issue by selecting the ‘Close’ button. The issue will then go into a “Closed By Submitter” state Service Order - 650

125 The TDSP will review the transaction and select ‘Complete’ TDSP Service Order - 650

126 TDSP Comments are required. TDSP presses ‘OK’ to transition the issue to a state of “Pending Complete” with the Submitter as the Responsible Party. TDSP Service Order - 650

127 In this state, the CR has the option to close the issue by selecting ‘Complete’ or the issue will be auto closed in 14 calendar days CR Service Order - 650

128 CR

129 Move out with Meter Removal Requirement 40

130 Move Out with Meter Removal The TDSP is requesting a Move Out transaction on an ESI ID to de-energize the premise after a Meter Removal transaction (650_04) has been sent

131 The TDSP selects the Submit tab From the Submit Tree, select Move out With Meter Removal Move Out with Meter Removal

132 The following fields must be populated for a successful submission of a Day to Day Issue sub type Premise Type: * Assignee The Assignee will be the CR associated with the ESI ID and is determined by the Submitter. * ESI ID *Meter Removal Date The date that the meter was removed *Comments Comments are required Select ‘OK’ Move Out with Meter Removal

133 Move Out with Meter Removal

134 3 Validations Occur: –ESI ID Validation- Is the ESI ID valid? –ESI ID Duplicate Check- Are there any other MarkeTrak issues submitted with the same ESI ID for the same company? –TDSP associated with ESI ID? Selecting ‘OK’ after each validation will override the validation and take you a step further in submitting your issue Move Out with Meter Removal

135 The issue enters the CR’s queue in a state of “New” and is visible only by the Submitter (TDSP) the CR and ERCOT The Submitting TDSP can ‘Withdraw’ the issue at this point TDSP Move Out with Meter Removal

136 The CR selects ‘Begin Working’ and the issue is transitioned in a new state of “In Progress Assignee”. At this point, the Submitting TDSP can no longer ‘Withdraw’ the issue CR Move Out with Meter Removal

137 CR

138 The CR reviews the issue and has the following options: –“Complete” – This means you have sent an 814_24 Move Out Transaction for this ESI ID. CR will be required to provide the Original Transaction ID of the transaction. This transitions to a state of “Pending Complete” –‘Unexecutable’- This means you will not be able to resolve the issue. This transition results in state “Unexecutable- Pending Complete” –‘Return to Submitter’- This means you need additional information from the submitter to resolve the issue. This transition does not close the issue. Once selected it requires comments and then the issue is transitioned back to the Submitter for more information The Submitting TDSP at any point can close the issue by selecting the ‘Close’ button. The issue will then go into a “Closed By Submitter” state Move Out with Meter Removal

139 The CR selects ‘Complete’ and enters the Original Transaction ID of their Move out transaction and optional Comments. CR Move Out with Meter Removal

140 The issue is transitioned in a new state of “Pending Complete” with the Submitting TDSP as the Responsible Party. CR Move Out with Meter Removal

141 In this state, the TDSP has the option to close the issue by selecting ‘Complete’ or the issue will be auto closed in 14 calendar days TDSP Move Out with Meter Removal

142 TDSP

143 Safety Net Order Requirement 38

144 Safety Net The TDSP needs the CR to follow up with a backdated Move In transaction that is associated with a Safety Net Order request

145 The TDSP selects the Submit tab From the Submit Tree, select Safety Net Order Safety Net

146 The following fields must be populated for a successful submission of a Day to Day Issue sub type Premise Type: * Assignee The Assignee will be the CR associated with the ESI ID and is determined by the Submitter. * ESI ID *Date of Safety Net Spreadsheet Submittal The date that the safety net spreadsheet was submitted to the TDSP *Requested Move In Date The Move in Date requested for the order *Premise Energize Date The date the request was processed and completed *Comments Comments are required Select ‘OK’ Safety Net

147 Safety Net

148 4 Validations Occur: –ESI ID Validation- Is the ESI ID valid? –ESI ID Duplicate Check- Are there any other MarkeTrak issues submitted with the same ESI ID for the same company? –TDSP associated with ESI ID? –Global ID Duplicate Check- Are there any other MarkeTrak issues submitted with the same global id (ESI ID + original tran id) for the same company? Selecting ‘OK’ after each validation will override the validation and take you a step further in submitting your issue Safety Net

149 The issue enters the CR’s queue in a state of “New” and is visible only by the Submitter (TDSP) the CR and ERCOT The Submitting TDSP can ‘Withdraw’ the issue at this point TDSP Safety Net

150 The CR selects ‘Begin Working’ and the issue is transitioned in a new state of “In Progress Assignee”. At this point, the Submitting TDSP can no longer ‘Withdraw’ the issue CR Safety Net

151 CR

152 The CR reviews the issue and has the following options: –“Complete” – This means the CR has sent the backdated Move In transaction associated with the Safety Net Order request –‘Unexecutable’- This means you will not be able to resolve the issue. This transition results in state “Unexecutable- Pending Complete” –‘Return to Submitter’- This means you need additional information from the submitter to resolve the issue. This transition does not close the issue. Once selected it requires comments and then the issue is transitioned back to the Submitter for more information The Submitting TDSP at any point can close the issue by selecting the ‘Close’ button. The issue will then go into a “Closed By Submitter” state Safety Net

153 The CR selects ‘Complete’ and enters optional Comments. The issue is transitioned in a new state of “Pending Complete” with the Submitting TDSP as the Responsible Party. CR Safety Net

154 In this state, the TDSP has the option to close the issue by selecting ‘Complete’ or the issue will be auto closed in 14 calendar days TDSP Safety Net

155 TDSP

156 LPA – Premise Type: TDSP receives an ERCOT Initiated LPA issue. They determine that they would like multiple issues created from the attachment and sends the Parent issue back to ERCOT requesting that a Bulk Insert be submitted to create individual Child issues. ERCOT Initiating Requirement 45

157 ERCOT Initiating The TDSP receives the LPA issue from ERCOT in a state of “New”. They will select ‘Begin Working’ to transition the issue to a state of “In Progress (Assignee)” TDSP – LPA Parent

158 ERCOT Initiating The TDSP reviews the attached file and decides they would like individual issues created for each ESI ID. The TDSP will select ‘Request LPA 1:1’ TDSP – LPA Parent

159 ERCOT Initiating The TDSP will add Required *Comments and select ‘OK’ to transition the issue to a “Pending Approval (LPA 1:1)” state with ERCOT as the Responsible Party. TDSP – LPA Parent

160 ERCOT Initiating TDSP – LPA Parent

161 ERCOT Initiating ERCOT will select ‘Submit LPA 1:1’ ERCOT – LPA Parent

162 ERCOT Initiating This will transition ERCOT to a Bulk Insert issue screen. ERCOT will attach a Bulk Insert.csv file and submit a Bulk Insert issue to create multiple ERCOT Initiated issues. ERCOT – Bulk Insert

163 ERCOT Initiating ERCOT Initiated Issues automatically get generated with Parent Issue id (LPA issue id) and Category. TDSP – Child Issue

164 ERCOT Initiating The TDSP and ERCOT will work Child issues as a normal ERCOT Initiated Issues. TDSP – Child Issue

165 ERCOT Initiating When all ERCOT initiated children are closed, the Parent LPA issue will transition to a “Child Issues Complete (LPA 1:1)” state and then automatically transitions to a “Pending Complete” State with ERCOT as the Responsible Party. TDSP – LPA Parent

166 ERCOT Initiating ERCOT will then open the Parent LPA issue and “Complete”. The issue will go to a “Complete” state and become Closed. ERCOT – LPA Parent

167 ERCOT Initiating