marketrak issue resolution tool retail market participant workshop

MarkeTrakIssue 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. (http://www.ercot.com/services/client_svcs/mktrk_info/index)

– 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 fileCancel With Approval Template found on MarkeTrak Information page.

8


**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


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 ReportRequirement 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 Name Report Description

Average Days Open Report to Provide average days open by subtype for the time frame specified.

Count of Active and Inactive Issues Report 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 State Report 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 ESIID Issue Details for a select group of ESIIDs for the subtype(s) selected.

Issue Details by Issue ID Issue Details for a select group of Issue IDs for the subtype(s) selected.

New User Issue Access Report to add a new user to the existing issues for the purpose of granting visibility.

Time in State Report 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. Closed Report to provide a count by subtype of all issues closed within the specified time frame.

Issues Open Outside Benchmark Report 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

SubmittedTDSP 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 ResolutionRemove 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 ERCOTSystem not MP:AssigneeESI ID UIDESIIDSTARTTIMESTOPTIME- optionalPROFILECODEREP CODEADDTIMESTATUS

ROR 1 (if Submitter is TDSP)

4. Select OK


34

3

4

Requirement 31

TDSP

35


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


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


5. ERCOT selects ‘Begin Working’

5

Only ERCOT and TDSP can view the TDSP Information within the issue. (Requirement 31)

ERCOT

38


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


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’

40

8

7

ERCOT

41


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


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


9. Selection of ‘Update Approved’, the Responsible MP is agreeing to the current requested resolution

9

CR

44


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

46



11

ERCOT

47


12. ERCOT has the option to select ‘Additional Info Required’, ‘Unexecutable’ or ‘Complete’. In this example, ERCOT selects ‘Complete’

12

ERCOT

48


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


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

SubmittedTDSP 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 ResolutionChange 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


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

56

3

4

CR

57


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?


58


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



5

ERCOT

61


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


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’

63

7

8

ERCOT

64


The issue is transitioned to a state of “New (Pending Approval)” with the TDSP as the Responsible Party.

65


9. The Responsible MP (TDSP) selects ‘Begin Working’

9

TDSP

66


From the state of “In Progress-Pending Approval” the Responsible MP has three options:

‘Update Approved’

‘No Agreement Reached’

‘Modify/Reassign’

TDSP

67


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/orNew StopTime < StopTime

68

10a

10b

CR

Requirement 31

69


The issue is transitioned to a “New (ERCOT Resolve)” state with ERCOT as the Responsible Party

TDSP

70



11

ERCOT

71


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

73


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


13. The Submitter will select ‘Complete’

13

CR

75


The issue will go to a “Complete” state and be Closed.

CR

76

ERCOT InterventionRequirement 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 email 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 CharactersRequirement 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

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

Yes

Requirement 36

92

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

93

Requirement 37-40

94

Day To Day Subtype Descriptions

Premise Type Requirement 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 Address Requirement 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 - 650 Requirement 39…CR/TDSP has an issue concerning the 650 service orders.

Move Out With Meter Removal Requirement 40…TDSP will notify CR that a Move Out transaction is necessary after a 650_04 was sent to CR.

Safety Net Requirement 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 AddressRequirement 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?


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 TypeCR

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


From the Submit

Tree, select Service Address

111

Service AddressThe 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 requiredSelect ‘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?



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 - 650Requirement 39

116

Service Order - 650

The CR sends a 650_01 transaction, but receives a 650_02 Reject transaction and would like more

explanation on reject reason.

117


From the Submit

Tree, select Service Order- 650

Service Order - 650

118


*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


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 - ERRORESI 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


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”



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


132


*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


Select ‘OK’


133


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?



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


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


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”



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


139

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

CR


140

The issue is transitioned in a new state of “Pending Complete” with the Submitting TDSP as the Responsible Party.

CR


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


142

TDSP

143

Safety Net OrderRequirement 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


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?


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



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 InitiatingTDSP – 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

marketrak issue resolution tool retail market participant workshop

Documents