Embed Size (px)
Citation preview
ERCOT strictly prohibits Market Participants and their employees who are participating in ERCOT activities from using their participation in ERCOT activities as a forum for engaging in practices or communications that violate the antitrust laws. The ERCOT Board has approved guidelines for members of ERCOT Committees, Subcommittees and Working Groups to be reviewed and followed by each Market Participant attending ERCOT meetings. If you have not received a copy of these Guidelines, an electronic version is available at http://www.ercot.com/about/governance/index.html. Please remember your ongoing obligation to comply with all applicable laws, including the antitrust laws.
Disclaimer:All presentations and materials submitted by Market Participants or any other Entity to ERCOT staff for this meeting are received and posted with the acknowledgement that the information will be considered public in accordance with the ERCOT Websites Content Management Operating Procedure.
1
2
MTTF3 - Using the current Usage/Billing workflow, create two distinct Usage and Billing subtypes 1) Usage and Billing – Missing and 2) Usage and Billing – Dispute. This will minimize the optional fields resulting in fewer issues submitted with incorrect data.
MTTF4 - Create new MarkeTrak Administrator workflows.
MTTF5 - Change the name of the subtype ‘Missing TXNs’ to ‘Missing Enrollment TXNs’.
MTTF8 - Increase validations on Original Tran ID and Tran ID fields to prevent users from entering invalid data.
MTTF9 – Improve the process flow for Inadvertent Losing subtype.
3
MTTF10 - Update Bulk Insert Templates by removing columns and rows that are no longer deemed necessary and check formatting of templates.
MTTF15 - Add the ability to return comments for specific date ranges on Background reports.
MTTF17 - Add “First Touched by TDSP” field to all DEV LSE subtypes.
MTTF21 - Add Service History as a required field for DEV LSE for the TDSP when a CR is the submitting MP and the modify/reassign transition is executed by the TDSP.
MTTF22 - For the Missing TXN subtype, add the 867_02, 814_PC, and 814_PD transactions to the list in the Tran Type drop-down field.
4
MTTF23 - Add the ability to retrieve and download attachments via the API.
MTTF24 - Add Additional Subtypes to the Contact Type field in the MarkeTrak Contact List (Rolodex) table.
MTTF25 – Add the ability to validate ROR is the Submitting market participant to prevent users from creating invalid issues. This will apply to Usage Billing – Missing and Usage Billing-Dispute workflows.
MTTF26 - Background Reports:• Standardize the backend report criteria to use Issue Available Date• Count of Issues by Submitting MP Duns (Summary)• Count of Issues by Submitting MP Duns (By Subtype)
MTTF27 - ESIID duplicate warning message expanded to include hyperlinks to other MarkeTrak issues with that ESIID.
5
MTTF28 - Auto close escalation and notification messages for issues remaining in Pending (not yet submitted) state for greater than three calendar days.
MTTF30 - Add the ability to execute and retrieve Background Reports via the API.
MTTF31 - Require Tran ID on the ‘814_20 Sent/Complete’ transition for Premise Type and Service Address subtypes.
MTTF33 - Create automatic transition for no regaining Siebel status (IAG and IAL).
MTTF34 - Change the TDSP matches validation from a warning to an error message.
MTTF35 - Add Recipient DUNs number and subject ESIID to MarkeTrak generated emails.
MTTF36 - Add Requested Date and MVI priority for Regaining Transaction.
6
MTTF37 - Add an escalation email if an issue has been in states of ‘New’ for more than 3 calendar days.
MTTF40 - Add optional fields such as ESIID to the ‘997 Issues’ subtype to provide additional information about the transaction for which the 997 functional acknowledgement is missing.
MTTF44 - Add the ability to differentiate between Submitting MP Type in Background Reports.
MTTF46 - Add help function to field labels on Inadvertent Subtypes.
7
Description:Using the current Usage/Billing workflow, create a distinct subtype for Dispute.
New Field titled ‘Dispute Category’ added to the workflow. Values for this field are as follows:
Priority Issue Defined as a subsequent MarkeTrak issue submitted/resubmitted due to initial MarkeTrak
issue being auto closed without resolution or a follow-up MarkeTrak issue exceeding Market accepted SLA. A MarkeTrak issue submitted as ‘Priority Issue’ that does not meet these guidelines may be rejected.
Consumption/Usage Issue Billing Calculations kWh Billing Calculations kW Billing Calculations Power Factor TDSP Charge Issues Rate Issues Crossed Meter Issues Non-Metered Issues Other
Comments required
8
9
10
The following fields must be populated for successful submission (required information).
ASSIGNEEESI IDTran TypeTXN DateSTARTTIMEDISPUTE CATEGORYIDR/NON-IDRTRAN Id
Description:Using the current Usage/Billing workflow, create a distinct Usage and Billing subtype - Missing.
11
12
The following fields must be populated for successful submission (required information).
ASSIGNEEESI IDTran TypeTXN DateSTARTTIMEIDR/NON-IDR
13
‘Add User’ function will be added to the Submit Tree under a ‘MarkeTrak Admin’ tab for Administrator use only.
14
Submit Transition Fields:• Employee ID – Required• First Name – Required• Middle Name/Initial – Optional• Last Name – Required• Email Address – Required• Phone Number – Required
Validations Performed on Submit Transition:• Email Address is formatted correctly• Phone number has 10 digits• Employee ID is alpha-numeric• Employee ID is not a duplicate
15
16
Employee ID: Enter the Employee ID from the digital certificate. There is no need to precede the Employee ID with duns$. MarkeTrak automatically adds duns$ to the Employee ID.
Enter remaining information making sure telephone number is 10 digits and Email address is formatted correctly.
Your Company duns will be defaulted in the Company field.
User Type: User type will typically be either Regular or MP Admin User.
Select OK to continue.
17
Add User issue is created
The Contact Record and Company Association have been created.
Review the information and if edits are needed, select the ‘Re-Select Parameters’ button. Or the user can select Withdraw to cancel the Add User process.
Edit the information and select ‘OK’.
18
Select the ‘Commit’ transition to complete the Add User request.
19
Add User request is complete and the issue auto closes.
‘Update User’ link will be added to the Submit Tree under a ‘MarkeTrak Admin’ tab for Administrator use only. Update User through a MarkeTrak workflow will allow for a more efficient means to update user information.
20
21
Company – Your Duns number will be defaulted in this field.
Contact – Enter the user name to be updated or select Find and review the list of users in your company.
Select OK
22
Edit User issue is created
From this screen, the MP Admin would either select ‘Edit’ to make changes to the selected user or choose ‘Select Different User’ if the current user selected is incorrect
23
The fields appearing in green can be edited. For this example, the email address was modified.
Select OK
“Now I’m [email protected]!”
24
To complete the Update User request, select ‘Commit’. The MP Admin can also ‘Re-Edit User’ or ‘Withdraw’ the issue.
25
Update User is complete and the issue auto closes.
‘Delete User’ link will be added to the Submit Tree under a ‘MarkeTrak Admin’ tab for Administrator use only. Delete User through a MarkeTrak workflow will allow for a more efficient delete user process.
26
27
Company – Your Duns number will be defaulted in this field.
Contact – Enter the user name to be deleted or select Find and review the list of users in your company.
Select OK
28
Delete User issue is created
This workflow allows the MP Admin to select a replacement for the user being deleted. If there is no replacement, the value should remain (None).
Enter either a replacement user or leave (None) and select ‘OK’.
29
This workflow allows the MP Admin to view all items owned by the user being deleted. It also provides a means to identify all rolodex entries corresponding to the deleted user. To view issues and rolodex contacts, select the links under Description.
30
31
32
To choose a replacement user, select the Find button and choose a user from the list.
Select ‘OK’.
33
• Delete User issue is created
• A Review the information and if edits are needed, select the ‘Re-Select Parameters’ button. Or the user can select Withdraw to cancel the Add User process.
• Edit the information and select ‘OK’.
To complete the replacement selection, click the ‘Commit’ button. The MP Admin also has an option to select another replacement if necessary by selecting the ‘Re-Select Replacement’ button.
34
Delete User request is complete and the issue auto closes.
35
Ability to report against the Add User, Delete User, and Update User workflows
36
Report criteria:• Delete User Workflow• All users deleted on or after 1/1/2014
37
• Delete User issue is created
• A Review the information and if edits are needed, select the ‘Re-Select Parameters’ button. Or the user can select Withdraw to cancel the Add User process.
• Edit the information and select ‘OK’.
38
Description:Change the name of the subtype ‘Missing TXNs’ to ‘Missing Enrollment TXNs’ to help minimize confusion surrounding which transaction types are available in this subtype. By changing the subtype name, it should provide clarity that only missing enrollment transactions; i.e. 814 tran types and 867_02/867_04 tran types are available for selection.
Impacts:◦GUI Submit Tree
◦API XSD/WSDL
◦GUI Reports
◦Background Reports
39
40
Subtype name has been updated on the Submit Tree.
41
Subtype name has been updated for GUI reporting.
42
Subtype name has been updated in the MarkeTrak Projects list on all Background Report options.
43
Increase validations on the Original Tran ID field and the Tran ID field to prevent users from entering invalid data such as dates in the BGN fields.
Error will generate if user attempts to enter invalid data in either of these fields.
44
45
User corrects the invalid values and selects OK.
Tran ID field cannot contain special characters. For this example, a date is entered in Tran ID field. Error message displays indicating an invalid value for Tran ID.
46
Original Tran ID field cannot contain special characters. For this example, a backslash is entered in Original Tran ID field. Error message displays indicating an invalid value for Original Tran ID.
47
User corrects the information in the Original Tran ID field and selects OK.
48
Issue successfully creates.
49
Description:
Task Force Participants have requested that on Inadvertent Issues, the workflow and validations be improved to ensure that the “Responsible MP” is reflected as the party that is expected to provide the next update to move the issue towards resolution.
New/Revised Transitions:
Agree – New Transition
Transitioned by Gaining CR to indicate clear agreement on the Inadvertent issue.
Send To Losing CR – Revised Transition
This transition will be used by the Gaining CR to send the issue back to the Losing CR for clarification or information exchange. It is not an indication of agreement to the Inadvertent Loss.
Using this transition could potentially delay resolution of the issue. Market Participants are strongly encouraged to add pertinent information such as customer name in the comments section when submitting the issue. Providing information upon Submit could prevent the need for the Gaining CR to transition the issue back to the Losing CR for additional information or clarification.
Send To TDSP – Revised Transition
This transition will only be available to the Losing CR once the Gaining CR has selected the ‘Agree’ transition. If the Gaining CR selects ‘Send To Losing CR’ instead of the ‘Agree’ transition, the ‘Send To TDSP’ transition will not be available.
50
51
CR1 submits Inadvertent Losing issue. No change to current submit process.
CR2 is the Gaining CR and selects ‘Begin Working’ transition.
52
CR2 agrees to the Inadvertent Loss and selects the ‘Agree’ transition.
Issue is transitioned back to the Losing CR in a state of ‘New (Losing CR)’.
53
Losing CR selects ‘Begin Working’ Losing CR selects ‘Send To TDSP’ Workflows continues with no further changes.
54
Gaining CR selects ‘Begin Working’ and the issue transitions to ‘In Progress (Gaining CR)’
Gaining CR selects ‘Send To Losing CR’ and is prompted for comments.
Gaining CR enters comments and selects ‘OK’.
Issue is transitioned back to Losing CR in a state of ‘New (Losing CR)’.
55
Losing CR selects ‘Begin Working’. ‘Send To TDSP’ transition is not available. Losing CR selects ‘Send To Gaining CR’
(comments optional) and the issue transitions back to ‘New (Gaining CR)’.
56
Gaining CR selects ‘Begin Working’. Gaining CR selects ‘Agree’ and the
issue transitions back to the Losing CR.
57
Losing CR selects ‘Begin Working’. ‘Send To TDSP’ button is now visible. Losing
CR selects ‘Send To TDSP’, provides the required information, and the issue transitions to the TDSP in a state of ‘New (TDSP)’.
Workflow continues with no further changes.
58
Description:Add the ability to return comments for specific date ranges on Background reports.
New Fields:◦Comment Returned (Optional) – Y/N◦Comment Start Date (Optional) – yyyy/mm/dd format◦Comment Stop Date (Optional) – yyyy/mm/dd format◦If Comment Returned field = Y, and no dates are entered into the Comment Start and Stop Date fields, all comments on the issue will be returned in the result set
59
60
Comment section contains comments dated 6-3-2014.
61
62
Issue ID,Submit Date,Issue Available Date,Close Date,Subtype,State,Submitting MP,Submitting MP Type,Assignee Company Duns,Responsible Party,ESIID,Original Tran ID,Global ID,Tran ID,Start Time,Stop Time,New Start Time,New Stop Time,Siebel Status,Siebel Substatus,SMRD,Comments2007494,2014-06-03 09:05:46,2014-06-03 09:06:00,,Ercot Initiated,In Progress (Assignee),ERCOT,ERCOT,Retail TestLSE,Retail TestLSE,,,,,,,,,,,,"(06/03/2014 9:6:49) - RCC1 LSE-111111111: Information reviewed and approved. |(06/03/2014 9:5:46) - Michael Taylor-Admin-183529049: Please review the information attached."
Subtypes selected(None)
Parameter 1 (Include Comments),Parameter 2 (Comment Start Date),Parameter 3 (Comment End Date),Parameter 4 (Not Used),Parameter 5 (Not Used),Parameter 6 (Not Used),Parameter 7 (Not Used),Parameter 8 (Not Used), Parameter 9 (Multi-Input)Y,2014-06-03,,,,,,,'2007494'
63
64
Description:Add “First Touched by TDSP” field to all DEV LSE subtypes so that market participants will know when the TDSP first touched the issue. If a TDSP has not yet begun working the issue, the field will be blank.
65
66
Once the ‘Begin Working’ transition is executed by the TDSP, the ‘First Touched by TDSP’ field is populated.
This field will remain static. Any additional ‘Begin Working’ transitions executed by the TDSP will not change the value in this field.
67
68
Description:Add Service History as required information for DEV LSE subtypes when a CR is the submitting MP and the modify/reassign transition is executed by the TDSP. This logic currently exists on the ‘Update Approved’ transition and should perform in the same manner when the ‘Modify/Reassign’ transition is executed by MP Type TDSP.
DEV LSE issue is in the ‘In Progress (Pending Approval)’ state.
TDSP does not agree with dates submitted by CR and selects ‘Modify/Reassign’ to make changes to the dates (New STOPTIME date for this example).
69
70
TDSP now has the ability to enter ROR information for the service period of 3/30/2014 to 4/29/2014.
TDSP enters ROR information and selects ‘OK’.
Issue transitions to CR in a state of ‘New (Pending Approval)’.
71
72
Description:For the current Missing Enrollment TXN workflow, add the following transactions to the Tran Type drop-down field:
◦867_02: This transaction set is used to report historical usage.
◦814_PC: This transaction set, from CR to TDSP, is used by TDSPs to update customer information.
◦814_PD: This transaction set is used to acknowledge receipt of the 814_PC Maintain Customer Information Request.
73
74
75
Description:MPs that utilize the API have requested the ability to access attachments to MarkeTrak Issues via their API to avoid logging into the GUI to retrieve them.
76
MarkeTrak Bulk Insert Issue AttachmentM
P AP
IM
arke
Trak
API
Phase
Obtain Issue File Attachment Number
from Issue Query Detail Response
Issue a IssueFileAttachmentReques, providing: Issue Number, File
Attachment Number
IssueFileAttachmentResponse returns
File “characteristics” and File contents in
Base64
API Program should create the Issue File
(using File “Characteristics”) locally, open for
append and write the File contents
from the IssueFileAttachment
Request into the local file
77
Functionality has been added to Bulk Insert to facilitate downloading of attachments via the API. Users now have the option to select ‘Issue Attachment’ for the Bulk Insert results file.
The option to post the Bulk Insert results file to MIS is still available.
78
79
Description:Add all D2D subtypes to the Contact Type field in the MarkeTrak Contact List (Rolodex) table to allow a broader range of contact designations for notification and escalation purposes.
80
MP Admin selects Manage Data from the Search Menu.
81
MP Admin selects MarkeTrak Contact List (Rolodex) from the Manage drop down field.
MP Admin enters company duns and selects ‘Lookup’.
82
MP Admin selects a contact from the Lookup Results column.
MP Admin selects ‘Update’.
83
MP Admin can now assign a contact type for all subtypes. NOTE: During implementation, all contacts associated with
the current ‘Other’ subtype will be populated to all new subtypes in the Contact Type list. MP Admins should review designations and update if necessary.
84
85
Description:Update background report types to allow for Count of MarkeTrak Issues by Submitting MP DUNS to be selected in the parameters and returned in the result set.
86
87
88
MP Duns, Total Issues666666666,3
Subtypes selectedD2D|Cancel With Approval,D2D|Market Rule,D2D|Move Out With Meter Removal,D2D|Safety Net Order,DEV LSE|LSE in MP sys not ERCOT: active,DEV LSE|LSE in MP sys not ERCOT: de-engz
Parameter 1 (Issue Available Date),Parameter 2 (End Date),Parameter 3 (Submitting MP DUNS),Parameter 4 (Not Used),Parameter 5 (Not Used),Parameter 6 (Not Used),Parameter 7 (Not Used),Parameter 8 (Not Used), Parameter 9 (Multi-Input)2014-01-01 00:00:00.00,,666666666,,,,,,
89
90
Description:Update background report types to allow for Count of MarkeTrak Issues by Submitting MP DUNS to be selected in the parameters and returned in the result set.
91
92
93
MP Duns, Subtype, Total Issues666666666,ERCOT Projects|MarkeTrak|Issues|D2D|Market Rule,3
Subtypes selectedD2D|Cancel With Approval,D2D|Market Rule,D2D|Move Out With Meter Removal,D2D|Safety Net Order,DEV LSE|LSE in MP sys not ERCOT: active,DEV LSE|LSE in MP sys not ERCOT: de-engz
Parameter 1 (Issue Available Date),Parameter 2 (End Date),Parameter 3 (Submitting MP DUNS),Parameter 4 (Not Used),Parameter 5 (Not Used),Parameter 6 (Not Used),Parameter 7 (Not Used),Parameter 8 (Not Used), Parameter 9 (Multi-Input)2014-01-01 00:00:00.00,,666666666,,,,,,
94
95
Description:When the ESIID duplicate warning message displays in the MarkeTrak GUI, it will also include a hyperlink to the issues that exist in the live database with that ESIID.
96
Warning message received noting multiple records with a duplicate ESI ID.
Issue numbers are now hyperlinks.
97
Selected issue opens in a new IE window.
98
99
Description:An automatic escalation would be added to all issues where it remains in a “Pending” state for more than three calendar days. The issue would transition to a closed state at this time if the Submitter has not used the “Submit” transition, and an escalation email sent to the issue owner.
100
101
102
103
104
Description:MPs have requested the ability to execute any Background Report available via the GUI and retrieve the result set via the API.
105
Request XML
<soapenv:Header/> <soapenv:Body> <ns:IssueSubmitRequest app="?"> <!--You have a CHOICE of the next 8 items at this level--> <ns:IssueBackgroundReport> <ns:ReportName>Average Days Open</ns:ReportName> <ns:CommentsText>${#Project#Comments}</ns:CommentsText> </ns:IssueBackgroundReport> <ns:Transition>Create</ns:Transition> <ns:AlternateUserID>${#Project#UserID-REP1}</ns:AlternateUserID> </ns:IssueSubmitRequest> </soapenv:Body></soapenv:Envelope>
Response XML
<ns0:ResponseStatus>SUCCESS</ns0:ResponseStatus> <ns0:ResponseDateTime>2014-06-02T10:39:40.439 05:00</ns0:ResponseDateTime> <ns0:IssueNumber>2008124</ns0:IssueNumber>
106
<soapenv:Header/> <soapenv:Body> <ns:IssueUpdateRequest app="?"> <ns:UpdateIssue> <ns:IssueUpdateBackgroundReport> <ns:SubTypeUpdateBackgroundReport> <ns:ReportDestination>Issue Attachment</ns:ReportDestination> <ns:DataToReturn>Live</ns:DataToReturn> <ns:MarkeTrakProjects> <ns:MarkeTrakProjectsList>D2D|997 Issues</ns:MarkeTrakProjectsList> <ns:MarkeTrakProjectsList>D2D|Cancel With Approval</ns:MarkeTrakProjectsList> <ns:MarkeTrakProjectsList>D2D|Cancel Without Approval</ns:MarkeTrakProjectsList> <ns:ReportParameter1>${#Project#Date-T-7Months-BckRpt}</ns:ReportParameter1> </ns:SubTypeUpdateBackgroundReport> </ns:IssueUpdateBackgroundReport> </ns:UpdateIssue> <ns:Transition>Provide Parameters</ns:Transition> <ns:AlternateUserID>${#Project#UserID-REP1}</ns:AlternateUserID> <ns:IssueNumber>2008128}</ns:IssueNumber> </ns:IssueUpdateRequest>
107
<soapenv:Envelope <soapenv:Header/> <soapenv:Body> <ns:IssueUpdateRequest app="?"> <ns:Transition>Submit Report</ns:Transition> <ns:AlternateUserID>${#Project#UserID-REP1}</ns:AlternateUserID> <ns:IssueNumber>2008128</ ns:IssueNumber> </ns:IssueUpdateRequest> </soapenv:Body></soapenv:Envelope>
108
109
Description:For the current Premise Type and Service Address workflows, add Tran ID as a required field for the ‘814 Sent/Complete’ transition.
110
Premise Type and Service Address issues in state of ‘In Progress (Assignee). No changes to workflows prior to this state.
User selects ‘814_20 Sent/Complete’.
111
User attempts to complete the ‘814_20 Sent/Complete’ transition without entering a Tran ID.
Error message is received indicating a value is required for the Tran ID field.
112
User enters Tran ID and selects ‘OK’. Issue transitions to Pending Complete.
113
114
Description:Add functionality to auto transition an Inadvertent Gaining or Inadvertent Losing issue that has been in a state of ‘Regaining Transaction Submitted (PC)’ state for greater than 14 calendar days.
115
Inadvertent issue is in a state of ‘In Progress (Submit Regaining). Losing CR selects ‘Provide Regaining BGN02’ transition and enters required information.
Issue transitions to ‘Regaining Transaction Submitted (PC)’ state.
116
Issue enters ‘Regaining Transaction Submitted (PC)’ state on 6/2/2014.
For testing purposes, ITEST environment auto transition settings are escalated from 14 days to 1 day.
Issue time in ‘Regaining Transaction Submitted (PC)’ state has exceeded maximum allowable time.
MarkeTrak auto updates the issue to ‘New (Losing CR Re-Submit)’ state.
117
Comment is auto posted advising that issue remained idle too long and should be reviewed.
118
119
Description:Currently, the ESI ID/TDSP Association validation that occurs upon Submit is structured as a warning message. The Submitting MP has the ability to select OK and continue with the submit process. This validation will be changed from a warning message to an error message which will eliminate the ability to continue with the Submit process unless the ESI ID/TDSP association is corrected.
120
Error messages cannot be bypassed by selecting OK. The submitting MP must either correct the ESIID or select Cancel to close the submit process.
121
122
Description:Attention emails generated within the MarkeTrak GUI will be expanded to include the DUNS numbers of each recipient on the email and the ESIID on the issue.
123
124
125
Description:Task Force Participants have requested that on Inadvertent issues, the requested date and MVI priority code be reflected within the issue. In addition, the Regaining Transaction Submit Date will also be auto-populated.
126
Regaining BGN Requested Date: The requested date in the regaining transaction sent by the Losing CR. This field is auto-populated from date in ERCOT Registration system.
Regaining BGN Priority Code: The priority code in the regaining transaction sent by the Losing CR.
127
Regaining Transaction Submit Date: The regaining transaction submit date will no longer be manually populated by the user on the ‘Provide Regaining BGN02’ transition. This date will also be auto populated by ERCOT Registration system.
128
Regaining Transaction Submit Date: The date the regaining transaction was sent by the Losing CR. This field is auto-populated from date in ERCOT Registration System.
129
130
Description:An escalation email will be auto generated for issues that remain in states of ‘New’ for more than three calendar days. The email recipients are the escalation primary and escalation secondary for the Responsible MP applicable subtype.
131
Impacts issues in states of ‘New’ for more than 3 calendar days where there is no owner established thru a Begin Working transition.
MP Primary and Secondary escalation contacts for this subtype would receive an escalation in the form of the standard spreadsheet noting that the someone within the organization should take action on the issue.
132
133
Optional fields added:• ESIID • StartTime • StopTime • Original Tran ID • Tran Type
134
135
Description:◦ Expand on the results set of certain Background
Reports by adding a column identifying the Submitting MP Type of CR or TDSP.
136
Reports Impacted:
• Details for Issues Resolved Outside of Benchmark
• Issue Details by ESIID• Issue Details by Issue ID• Issue Transition Details
137
138
Issue Id,Subtype,Submitting MP Type
1883944,ERCOT Projects|MarkeTrak|Issues|D2D|Cancel With Approval,CR
2005328,ERCOT Projects|MarkeTrak|Issues|D2D|Cancel With Approval,TDSP1981320,ERCOT Projects|MarkeTrak|Issues|D2D|Usage/Billing Issues,CR
139
140
