TX SET Meeting

September 19-20, 2000

 

Agenda

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).

 

Pilot Transactions Review

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?

 

 

Test Plan

·         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.

 

 

824_01 Reject Settlements Invoice/QSE to ERCOT – this transaction is on hold, pending use

·         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.

 

824_02 Reject Invoice/REP to Utility

·         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.

 

824_03 Reject the 867/RA to Utility/REP to RA

·         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

 

Timeline

·         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

 

Next Meetings

·         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