TX SET Meeting
September 19-20, 2000
Pilot
·
We need to develop
the Data Element Matrix for the Pilot transactions ·
We need to develop
the Scenario flows for Drop out of Pilot, Pilot to full Choice and need to
flow out what the entire process looks like (including the CSA process during
Pilot) |
·
Transaction Names
Inventory for Pilot (814_P1-P4) Review
·
Process Flows Review
– updates to the scenario maps
·
The 814_P1, added an
814_20 for the eligibility date from Utility to RA (ERCOT plans on populating
the database with an eligibility date of 6/1/01 (for Residential Customer only)
because they don't believe that the residential pilot will reach the 5%, if
this is the case then steps 4 and 5 are not needed).
814_P1:
·
Change
the gray box for the direction of the flows (REP to Utility)
·
LIN will include
VL for “volunteer” ·
Either the ESI ID
(REF*Q5) or the Utility Account Number (REF*12) must be present 814_P2:
·
BGN06 includes
BGN02 from the P1 transaction ·
The response
should include the ESI ID (REF*Q5) and the Utility Account Number
(REF*12) ·
This can have an
“accept” or a “reject” ·
Reject reason code
– ESI ID or Account number Exists but is not active ·
Add a reject code
for “invalid class” (for example, if a residential customer is volunteered
using a P3) 814_P3:
·
Update the gray
box, From the REP to the Utility ·
LIN has NC which
indicates a “negotiated contract” – fix the example in the gray box 814_P4:
·
Add a reject code
for “invalid class” (for example, if a residential customer is volunteered
using a P3) ·
The response
should include the ESI ID (REF*Q5) and the Utility Account Number
(REF*12) ·
Fix
gray box in the BGN06
|
Pilot Issues:
1.
List of Non-matching ESI Ids in the Aggregator
Excel Spreadsheet Can the Utility reject
an Aggregation Packet if only a few ESI Ids are wrong? What if 2 out of 100 ESI IDs are not
valid? What if the Aggregator’s Packet will exceed the 1% what happens, are
only a portion of the ESI Ids accepted, thus chancing the make-up o f the
packet? We need to define a way for
the Utility to communicate back to the Aggregator (REP on its behalf) on the
Excel spread sheet – 2.
Dates, need to be confirmed Expression of interest
begins: Non-Aggregators 2/15/01, Aggregators 2/15/01 Deadline for Expression
of Interest: Non-Aggregator 3/15/01; Aggregator 4/02/01 Lottery if necessary:
Non-Aggregator 3/21/01; Aggregator 4/05/01 Deadline to Execute
Contract: Non-Aggregator 5/15/01; Aggregator 6/15/01 Deadline for Confirmed
Contract: Non-Residential 5/14/01 (including time to correct those submitted
by 5/10/01); Non-residential Aggregator is 5/21/01. 3.
“Confirmed Contract” Means that the
transaction 814_P3 has been received by the Utility and it has returned an
“accept” on the 814_P4 (this is the transaction pair that notifies the Utility
that the REP has signed a contract with the Customer). By the time the Utility posts the
non-matching ESI IDs that Customer’s ESI ID has already been removed from the
participant list has already been added to the available load – this
essentially looks like the customer is being punished for a REP error. 4.
The dates for Aggregator Power-flow on June 1 (Section G1) For power-flow on June
1, 2001 – a REP will need to be able to submit a switch before the listed May
31st. A Customer could
enter a move-in transaction (814_16) in order to waive the review period to
be able to have power-flow on June 1 – but we do not want people to “say” it
is a move-in when it is really a switch.
Suggestion: we would like to see the date that a REP
can send in a switch as early as May 15th (give or take a day) to allow for review
period and blackout period. If a
switch is submitted on May 31st it would not be effective until
mid-June - - is this intent of the rule, or can we manage the technical
aspects to effect June 1 power-flow. 5.
CSA (Continuous
Service Agreements) during Pilot
Will CSAs be part of the
Pilot? How will we deal with CSAs
during Pilot – what if only 5 ESI Ids under the CSA are “shopping”? ·
After
the Utility Data Load (814_20), the CSA agreements (814_18 and 814_19) can be
established in the ERCOT database. ·
There
are a number of transactions that ERCOT thinks that the Utility will need to
code to act as a REP, POLR and Utility during Pilot as ERCOT expects it to work right now. – BIG PROBLEM! ·
We
might need to flow out what the entire process looks like to enter Pilot as
well as to drop out of Pilot and what the flow looks like entering full
Choice. 6.
Pilot Volunteer When a customer volunteers to
participate in the Pilot, is the CUSTOMER volunteering or is the ESI ID
volunteering? Is this Customer based
or ESI ID based? Currently the
transactions are being tracked by ESI ID, if it is customer based – how will
the Utility track it? 7.
Residential Volunteer date
(Section G2B; Section G1E) What is the earliest date that
a REP can send a volunteer transaction to the Utility? April 16th? 8.
Non-Residential Volunteering
(Section G3C) The rule does not preclude an
Aggregator from delegating it volunteering process to a REP, does the same
hold for non-Residential customers?
Can a non-Residential customer have a REP volunteer for it? 9.
Posting of Non-matching ESI Ids
(Section G1A) Per the Pilot rulemaking, a
utility “shall maintain a weekly updated list of non-matching rejected ESIs
on its pilot project Internet website”.
Does this need to be a standardized day of the week across all
Utilities? Which fields need to be
included in the CSV file? 10.
Aggregator Info (Section G4H) Will the Excel fields for
interest in participation be defined by the PIC or by TX SET? Which fields should be included in the
Excel file? 11.
Non-Residential Participant
List (Section G3D) Why is the turn around over a
weekend (May 11-14)? By what time on
the 11th, does the Utility need to have the list posted? By what time on the 14th, does the
REP need to correct and respond to the Utility? Will this allow sufficient time for questions/complications? 12.
Utility notifies RA (Section
G1E) REPs must notify the utility
when they have received a switch authorization from a customer. The utility must then notify the RA so
that the RA can flag the accounts that can participate in the Pilot. Does this apply to all customer
classes? When does the utility notify
the RA (using the 814_20) of the eligibility for that ESI? May 17th, 2001? 13.
Notification of executed
contracts (Section G4G) In addition to notifying the
Utility of switch authorizations received from customers, does the REP also
have to provide a list of ESIs representing executed contracts to the
utility? What is the format? How often should this list be
submitted? Does this pertain only to
non-residential aggregators, or all non-residentials and non-residential
aggregators? Non-residential Aggregators? Will this list be used to
compare both the REP and the Utility’s list of executed contracts? If not, will there be another opportunity
for the REP and the Utility to compare lists to make sure that they match? |
·
The Technical
Working Group meeting is set for October 5th. Is has been suggested that market
participants cover the expense of bringing George Behr to present testing info
and experience from other markets.
Statement of Work (Section 4) Update
·
Milestone chart is
on the ERCOT website (Architecture Operations, Disaster Recovery Plan, testing
– market and business testing…) ERCOT
has several phases of testing prior to the market being involved. ERCOT calls some of the market testing in
December-Jan, this is internally in ERCOT.
ERCOT internal Testing of Siebel is Nov-Mid December. ERCOT internal testing of Siebel with other
internal ERCOT pieces Mid-Dec –Mid –Jan.
Last week of Feb through March for market participant testing – this is
what ERCOT is thinking
·
Upshot: Andersen
will provide a testable product…sometime…..
·
ERCOT will have
several sections of the total system that could be available for testing prior
to the complete ERCOT system being ready.
If this is the case then could market participants schedule testing of
transactions that is aligned with the Andersen deliverable schedule?
·
Critical Date: the connectivity to the wide area
network, how is this done, when, what are all of the available options for
connections? Can it be used for the 867
historical usage?
·
We need clarification on the meaning of the
“market participants” involvement and timing of the testing process.
·
Statement of Work
(4.1.1) – Assembly of Test [May 2000-January 2001]
“
The objective of the Assembly Test is to show that modified application
processes are operating as designed from both a technical and a functional
perspective when tested as stand alone functions. …Assembly test will target changes made to the application
configuration, which will be determined during functional design. Participants: ERCOT and Andersen Consulting.
·
Statement of Work
(4.1.2) – Product Test [November 2000-January 2001]
“The
objective of the product test is to show that the individual products (i.e. in
Package 2 , LODESTAR, Siebel, and PaperFree) are configured correctly and work
in a stand-alone fashion. The product
test will verify all business functions can be performed in the system and that
standard business scenarios can be processed through a simulation of the
expected operating environment period.
Technical performance tests will also be incorporated into the product
testing process. Participants: ERCOT,
Andersen Consulting, and Market
Participants (if Market Participant are part of the product).
·
Statement of Work
(4.1.3) – Package Integration Test [January 2001-February 2001]
“Package
integration Testing (PIT) tests the integration and inter-working of the
components of each package. Package
Integration Testing is the final phase of testing before the beginning Program
Level Testing. Market Participants may
take part in the Package Testing as defined within the test plan for each
package. Andersen Consulting will
develop test data, scripts, and expected results and is responsible for
performing test execution and actual result documentation. Participants: ERCOT,
Andersen Consulting, and Market
Participants (as necessary).
·
Statement of Work
(4.1.4) – Cross-Package Business Integration Test [March 2001]
“A
cross-package Integration and Business Test will take place during the month
prior to the mock market. These tests
are designed to test the overall capabilities developed and integration across
Package 1, 2, and 3. While
Cross-Package integration testing focuses on more of the technical system
components of the solution, business testing focuses more on the business
processes across the overall solution.
…Market Participant interaction
will be required in some cycles of the cross-package integration test. The interaction will be under controlled
conditions where specific test data and scripts are provided to the selected
participants. Technical
performance, fail-over, and disaster recovery testing will also take place
during the Cross-Package and Business Testing period. Participants: ERCOT,
Andersen Consulting, and Selected
Stakeholders.
·
Add a gray box, from
the QSE to ERCOT…for this transaction we need to change the sending entity to
“Settlement Invoice”
·
N1 code will be
changed to PO “Receiver” this is the party to receive invoice (gray
box refers to Settlement Invoice Recipient)
·
TED error codes:
many of the codes may be unnecessary since ERCOT has decided that the dispute
portal will address this.
·
Add a gray box, from
the REP to the Utility….
·
PER needs to be
moved to the N1 loop for the REP
·
TED03 – 08 will be
removed. The incorrect/bad data will be
addressed in the TED01-02.
·
Carry forward the
814 “7G” codes for use in the TED02, TED01 will use “848” following the same
format that UIG uses.
·
Keep the NTE for
additional rejection reason text.
·
Add a gray box, from
the RA to Utility or the REP to the RA….
·
Add the N1~AY for
ERCOT
·
Remove all of the
PER segments
·
TED03 – 08 will be
removed. The incorrect/bad data will be
addressed in the TED01-02.
·
Carry forward the
814 “7G” codes and specific codes for 867 reject reasons for use in the
TED02, TED01 will use “848” following the same format that UIG uses.
·
Keep the NTE for
additional rejection reason text.
Service Orders
650_01 – Basic Service Order Request
·
Remove code for “New
Guardlights”
·
Add code for
Investigation Service
·
Add code for check
meter seal – or something like this, baseball breaks meter,
·
Change the N1
segment to what it looks like on the 814_06
·
Make the PER allow
for several types of contact types (like what we deleted from the 824s we
discussed today)
·
Edit HL segment,
only include the HL01, HL03
·
Remove gray box on
REF01 for Meter Number
·
Include same
language “unsure if we are required to have this….” (from an 814 for Life Support)
·
DTM03, the time will
be addressed with a YNQ (yes only) segment with a question stating “I do
authorize the order to be worked outside of regular business hours.” Need a
gray box for the YNQ segment.
650_02 – Basic Service Order Reject
Response
·
Fix BGN01, response
·
Add a BGN08 on all
of the response transactions; reject, not capable of taking action, etc. (take
these codes from CUBR)
·
Remove REF~1P; flags
for “bad dog” etc., will be used on the 650_03
·
MTX example must be
in all caps.
650_03 – Basic Service Order
Completion Response
·
Edit HL segment,
only include the HL01, HL03
·
On a re-read, the
MEA (read) is included whether the original read in question was correct or
incorrect. (Utilities would rather not
build in the logic to only send the read if it was correct.) There was some discussion around dealing
with reads that are determined incorrect, the Utility should then “know” to
send and 867 cancel and re-issue an 867 original with the corrected read/usage.
·
Add a code that
states “Prior reading was incorrect – Bad Read” – then the REP can expect the
following 810 and 867s.
·
Discussion on
including the read on this transaction, one argument against including the read
is that the read will not be “clean” given that some meters are interval or
time of use – don’t want to make an assumption on the accuracy of the data
given that it has not passed VEE. REPs
seem to want this read to help explain the invoice to the Customer.
·
In the MEA we need
to add the codes to allow for time of use and interval - Add the MEA07 for
on-peak/off-peak/totalizer – This “read” will not match the following 867 and
should not be used for billing, it is for information only. REPs expect a summarized usage value for
interval meters.
·
Add code BRD for “Bad Read” in the REF~1P
650_04 – Meter Change Request
·
Edit HL segment,
only include the HL01, HL03
·
Remove the REF~TD
Reason for Change
·
The MTX will be used
for text description of the reason for change and additional info
·
The 650 meter
change-out will not be linked to the 814
650_05 – Meter Change Response
·
We will use the
650_03 as a response to the 650_04 – there was not enough different to justify
a separate transaction.
810_02 – Utility to REP Invoice
·
Edited the BALs to
include only the “Total Balance Detail”
·
ITD gray box, remove
“if applicable” – Ts&Cs section 4.4.5, we need to keep the due date per the
rule.
·
IT1 loop will be at
the “account” and “rate” levels only; it can be repeated many times, edit gray
box – delete all except the example.
This came out of a discussion about street lights, where all on the same
ESI ID have the same characteristics, but they are on different rates – when
this happens two IT1 loops will be reported to assign charges to each rate
type.
·
Taxes will be
reported at the account level.
·
The Account level
IT1 loop will only be used when a charge cannot be associated with a specific
rate.
·
Remove the TXI in
the IT1 loop and only include it at the SAC level.
·
Remove the meter
number REF~MG
·
REF~NH Utility Rate
Class; in the gray box should include Account and Rate level only
·
REF~PR Utility Rate
Sub-class; in the gray box should include Account and Rate level only;
“required if available”
·
Remove the DTMs in
the SLN loop
·
Service Orders
REF~OW; gray box should read “required if applicable”
·
All SAC elements
should be “Must Use” – suggestion to have one SAC page including all applicable
charges, show all examples in the gray box.
Remove the SAC01 “A” (Allowance charge); when we want to report a
negative charge it will be shown with a negative sign.
·
SAC04 proposed codes
for Service Orders SAC loop:
BAS001 |
Customer Charge |
MSC007 |
Property Damage |
BAS004 |
Field Service Charge |
MSC010 |
Select Read Cycle Monthly Fee |
DCS002 |
Disconnect Visit Charge |
MSC022 |
Competition Transition Charge (CTC) |
DIS001 |
Distribution Charge (DUOS) |
MSC024 |
System Benefit Fund (SBF) |
DIS004 |
Transport Charge (XFMR) |
MSC025 |
Nuclear Decommissioning (NDF) |
FAC001 |
Equipment and Service Charge |
MSC027 |
Transition Charge (TC) |
FFR001 |
Non metered Service |
RCS001 |
Reconnect Charge |
FUE001 |
Fuel Adjustment |
RRR006 |
Regulatory Commission Mandated Refund |
HOC001 |
Service Connection Charge |
SMD019 |
Special Meter Read |
LAA001 |
Billed for Work performed Labor/Material |
SMD020 |
Meter Change |
LPC001 |
Late Payment Charge |
TEM001 |
Temporary Service Charge |
MSC002 |
Set-time Appointment Charge |
TRN001 |
Transmission Charge (TUOS) |
MSC003 |
Meter Seal Replacement Charge |
|
|
·
One SLN loop per
service order, in the SAC09 we need to show the details for each service order,
ex. Mileage Charged
·
Kim will write a gray box to explain the SLN
·
Edit the TXI in the
SLN loop [make it look like CUBR or the TXI that we deleted from the IT1
loop]; only include TXI 01 (code LS),
TXI02, TXI07
·
TDS ; “total amount
of invoice” in gray box – check CUBR for gray box wording.
·
Remove TXI in the
Summary – if it were included here it would be charged twice
820_02 – Payment Remittance – REP
to Utility
·
Cover page notes
should read: “This transaction set from, the Retail
Electric Provider (REP) to the Utility, is used by the REP to notify the
utility f payment details related to a specific invoice, if the remittance
detail is separate from the payment. If
payment and remittance travel together through a financial institution, this
Implementation Guide can be used as a baseline discussion with the your
financial institution.”
·
“Notes” Gray box on
the intro page must be re-worded
·
BPR01; only code
used is the I (Remittance Information Only); fix gray box
·
TRN gray box
“Required”
·
TRN01, use code “3”
(Financial Re-association Trace Number )
·
Add a gray box under
the TRN02 – “Unique number identifying this ….” wording from CUBR.
·
Removed the DTM~097
– Transaction Creation Date
·
N1s and BPRs need to
be noted “Must Use”
·
RMR Negative
Remittances (total due is a negative amount) – “The 820 payment instruction
advice……
·
REF~6O – this is a
letter O; not a zero.
·
Add a REF~Q5, ESI ID
Risk/Gap Analysis Update:
·
Customer Protection
Update – Based on current Consumer Protection Rulemaking and current
Registration Protocols, it appears that the market documents may be in
conflict. The Consumer Protection
rulemaking identifies REP to REP transactions specific to historical
consumption data. REP-to-REP transactions do not exist. Currently the Registration Protocols provide
for the Utility to supply the historical consumption data to the RA, and
forwarded on to the REP (who has previously obtained Customer). Please visit with your company
representative regarding the comments being written with regard to this
rulemaking for further information.
Communications Protocols Update:
·
XML that maps to the
EDI stuff, the internal translation of EDI incoming to ERCOT will be translated
to XML (Andersen’s version of XML) in order to be passed between the internal
parts of the ERCOT system. The inbound
814s to ERCOT have been signed off on, the schemas to
·
The XML schemas will
be available and “published” at some
undetermined time, it will look like an EDI Implementation Guide as much as
possible.
·
ERCOT management
will support use of the Andersen XML for some transactions, but not all
transactions – internally ERCOT will support receiving an XML formatted
document that is sent FTP to ERCOT.
However, ERCOT maintains that it is impartial to “how/format” it
receives these transactions. If the
transaction is not defined as an EDI message (Portal of XML), then it is
determined that it is an XML message; if it is received Portal/XML or FTP/XML
then it will be returned in the same format as received.
·
Can a REP talk to
ERCOT using only XML? ERCOT says
yes. At this point it can support all
transactions that SET has developed that touch ERCOT.
·
The FTP format and
the encryption – the only one that has been supplied on how to do FTP today are
the Utilities are giving ERCOT information.
The specifics of “how” this is physically done are not posted yet.
·
Send questions to:
Questions@texaschoiceprogram.com
Andersen Issues – Change Control Forms will be
sent on these issues:
·
Need a reject reason
“not current REP of record” added to the 814_25 and 814_11 to address
situations where a Move-out is submitted on an ESI ID that is not “owned” by
the REP.
·
Receiving
distribution line loss calculation – this is on hold until James Cohea (jcohea@ercot.com) gets response from Market
Participants
·
All customers are
covered by Customer Protection, therefore the “waiver” flag should cover the
Customer Review Period – for POLR assignment, ERCOT should be able to be
determined by the profile for the ESI ID.
ERCOT will need a look-up table by above 1MW and below 1MW.
·
Discussion on
concurrent processing, David will write up this process and flows to describe
the timing issue. REP and POLR REP will
have different DUNs numbers, so ERCOT should be able to tell which “switch” is
to POLR – they have this data table by ESI ID.
·
If a TDSP could send
usage data to ERCOT for meters that are to be polled by ERCOT this data should
be rejected and not sent into the settlement process. A rejection reason for this is needed on the 824_02.
·
Remove the
“notification letter” on the Establish CSA transaction.
·
814_24 and 814_08 is
a request from RA to Utility needs to have a BGN06 that will capture the
reference number from the 814_24 from the REP to RA.
Waiver Eligibility
·
Results from RUG
meeting last week.
·
If the REP request
includes a waiver of the customer notification letter, the RA will send the “first
available switch date” to the Utility, however the Utility can still read the
meter two days before the “first available switch date” because of the 2 day
early meter read cushion. The Utility
will not be concerned with waiver vs. no-waiver.
Protocols Discussion
·
Review of the SET
chapter, we need to work out some of the details on the Change Control process,
send changes to ERCOT Representative and SET listserve.
Change Control
Process
·
5
changes submitted to ERCOT (by TXU)
#1 Date of Request: 9/13/00 Customer Recission Period
Expiration Date: This filed needs to be renamed to First Available Switch
date. This data element needs to be
modified to be consistent with the terminology outlined in the protocols. ·
Change
814_03 – DTM segment, Customer Recission Period Date renamed to “First
Available Switch Date”. All gray box
referencing Customer Recission Period should be renamed to reflect First
Available Switch Date. Why: To be consistent with the Protocols document. * SET members present in the meeting
agree with this change. |
#2 Date of Request: 9/13/00 814_04/05 – Include the total
number by Load Profile and description devices. 814_20 – Include the total
number added or removed by Load Profile and description of devices. ·
The
Customer Registration Protocols requires the number and description of
un-metered devices for an ESI ID be provided to the REP by the TDSP. ·
Changes
in the 814_04/05: Add REF for
Un-metered Services REF01 would have a code for number of un-metered
services, REF02 would have total number of un-metered services, REF03 would
have description of valid un-metered services (ie. Argon, Fluorescent,
Traffic Lights, etc.) Why: To accurately communicate
services being provided at an ESI ID. ·
Changes
in the 814_20: Add REF for Un-metered Services, REF01 would have a code for
number of un-metered services, REF02 would have total number of un-metered
services added or removed, REF03 would have description of valid un-metered
services (ie. Argon, Fluorescent, Traffic Lights, etc.) Why: To accurately communicate
services being provided at an ESI ID. *SET agrees that this issue may
need more discussion. |
#3 Date of Request: 9/13/00 Utility Rate Class and Utility
Sub-class data elements need to be modified on the 814_20. ·
These
data elements indicate that they are required for Data Conversion/Create ESI
ID. ERCOT will not be storing these
data elements therefore; they are not required. These data elements are a “Pass Through to the REP” ·
Change
the 814_20. Modify the REF: Utility
Rate Class to the following: Conversion/Create ESI ID Request: Not
Required Change ESI ID Information Request: Required if changing this item Retire ESI ID Request: Not Used ·
Change
814_20. Modify the REF: Utility Rate Class to the Following: Gray box should indicate that
this is only used if you are further defining the Utility Rate Class (i.e.
When there are sub-rates or riders associated with the primary rate) Conversion/Create ESI ID Request: Not
Required Change ESI ID Information Request: Required if changing this item Retire ESI ID Request: Not Used Why: To be consistent with protocols. Not required by ERCOT. *SET agrees with this. |
#4 Date of Request: 9/13/00 Add standard Interconnection
Point tot he 814_04/05 Last month we added the
standard interconnection point tot he 814_20 but not the 814_04/05, a
definite oversight since it is required by protocols. It should definitely be there. It should not be available for a query
however, only when you gain the customer do you get it. ·
It
is required to support the Registration Protocols. The REP is going to know the Standard Interconnection Point to
aid in determining the weather zone, congestion zone and UFE zone. These data elements are derived from the
Standard Interconnection Point. ·
Change
814_04/05. Add REF: Standard Interconnection Point ·
REF01: SPL Standard Point Location Code (SPLC) ·
Gray
box: Point at which the Utility’s distribution
system is connected to the transmission grid for the Service Delivery Point
(SDP). The value shall correspond to
an ERCOT-defined Substation ID via look-up table provided by the Utility. Why: To be consistent with the
protocols. * SET wants additional comments
on this |
#5 Date of Request: 9/13/00 ·
1. Rejection Reason Code text needs to be
modified to be consistent with the registration protocols. ·
2. Review rejection reason codes that are
inconsistent with the protocols when the 814 is created (i.e. Responses to enrollment, move-out/in) by
the Utility ·
This
data element needs to be modified to the consistent with the terminology
outlined in the protocols. Detailed Explanation: ·
1. Change 814_02, 04, 05, 07, 09, 11, 13, 17,
19, 21, 25, 27 – Review all the descriptions for rejection reason codes for
consistency with the registration protocols. ·
2. Review protocols and all 814 Utility
Responses to determine the validation of the codes. Why: To be consistent with protocols. *SET wants additional comments
on this |
·
Send
Change Control Forms via email to Cherie (cbroadrick@ercot.com) and Mike
McCarty and copy SET listserve
·
Add
a tracking number to each Change Control Form, and keep track of a log of
submissions and resolved issues.
Issues:
·
Can the dispute
process be done via API?
·
RUG decision:
Guardlights will have ESI Ids separate from other load types.
·
Load Profile cannot
be used to determine a customers classification (small commercial, large
commercial) for Non-ERCOT. Can the
revenue codes that we have to use per FERC be used to determine this? Suggestion for us to continue to use the
Load Profile field and add codes for 3 Non-ERCOT profiles, this will be used to
determine which POLR the Customer will be served by. OR come up with a completely new field that everyone will
use the same code – this means that the REP will have to hold 2 profile
codes. David will submit two alternatives.
Other:
· List of UIG codes to be added –Johnny
· Communications Mechanism Outside ERCOT –
Dave(Lead)/Jill
· Manual Processes write-up – Larry/Bruce
Attachments:
Meeting Minutes 9/19-20/00
810_02 Implementation Guides - comments due
to Johnny by 9/30
Following
Attachments:
820_01-02 Implementation Guidelines -
comments due to set@ercot.com by 9/30
824_01-03 Implementation Guidelines -
comments due to set@ercot.com by 9/30
650_01-04 Implementation Guides – comments
due to set@ercot.com
by 9/30
Assignments:
·
Clean up website –
update the Conversion transactions, fix “Scenario Names” Document presentation
on site – Mike
·
Appendices in a
matrix format – BJ
·
Examples for the
810s – Johnny
·
Examples for the 824
– Cary
·
Examples for the 650
– Jill/Johnny
·
Examples for the 820
– Johnny
·
Examples for 814_Ps
– Roshni/Heidi
·
814s complete
Version 1.1
·
867s complete
Version 1.1
·
810_01 complete
Version 1.0
·
810_02 draft –
Version 1.0 due 9/30
·
820_01 draft –
Version 1.0 due 9/20
·
820_02 draft–
Version 1.0 due 9/20
·
824_01 (response to
867) draft – Version 1.0 due 9/30
·
824_02 (response to
810) draft – Version 1.0 due 9/30
·
824_03 (response to
820) draft – Version 1.0 due 9/30
·
650s –draft due 9/20
·
814 Customer
Maintenance (this is for REPs that will not handle service calls/outage notification
calls)
·
Open item: Time line – now through market open,
including Market dates and SET assignment deadlines – Quentin
·
Open Item: Mock
Market/Pilot Transactions – Quentin/Kim/Roshni (Lead) /Heidi/Leticia - on hold
·
Open Item: Data
Element Ownership – Cary/Larry (Lead)/Diana
- David will furnish this, in
progress
·
Open Item: Test Plan
– Roshni (Lead)/Robert/Quentin – working with ERCOT and PUC
·
UIG meeting October
1-4 – Cincinnati, OH
·
Meeting October 4-6
– Wednesday @1:00, Thurs 8:30-12:00 (Test Plan Workshop in the afternoon at the
PUC), Friday 8:30 – 12:30 - hosted by Reliant, in Austin. 1005 Congress @ 10th, 6th Floor,
AECT Boardroom (512.474.6725)
·
Technical Workshop
Thursday October 5 (1:30-5:00) - 1701 Congress , William B. Travis Building, 7th
Floor in the Commissioners Hearing Room
·
Tentative Meeting
October 18-19 – Wednesday @9:30, Thurs 8:30-5:00, hosted by TXU, in Dallas.
1601 Bryan @ Akard, Mezzanine Level
·
Tentative Meeting
November 1-2 – Wednesday @10:00, Thurs 8:30-5:00, hosted by ERCOT, in Austin. 7200 North MOPAC Expressway (near the
Far West exit), Suite 240.
·
Attendees:
Larry
Shields Xcelenergy Randy Brannon TXU
Diana
Rehfeldt TNMP Fred
Plett Logica
Debbie
McKeever TXU Rohni Patel Reliant
Jill
Prince TXU Heidi Schrab Reliant
BJ
Flowers TXU Jeanette Harris Reliant
David
Lotspeich AC Mike
McCarty ERCOT
Nancy
Hettrick Enron Dave
Darnell Systrends
Sharon
Polliard AEP Cary
Reed AEP
Johnny
Robertson TXU Bruce White TXU
Dave
Robeson Entergy