Minutes

SET Conference Call 2/14/01

Questions from James Cohea (these will be addressed when James is available):

ERCOT Issues:

Assumption #1.

When initially sending consumption to LodeStar, TCH will always send any existing historical consumption data (867_01) before sending current/monthly consumption data (867_03).

We assume that historical consumption data must always be sent in 867_01 EDI file in chronological order (from past to present) and if LodeStar ever receives usage for current period (867_03 transaction) and then receives usage data for prior periods (867_01 transactions), the latter ones will not pass LodeStar’s date-gap validation and will be rejected through 824 transaction marked with error code of DDM = Dates Do Not Match.

Assumption #2.

Canceling multiple periods of consumption data normally creates gap in historical usage. We assume the adjustment data cuts being sent to cover gap created by cancellation have to be sent in form of one single adjustment for the time span that was cancelled in order for LodeStar to accept this.

In case of adjustment data being sent in form of multiple cuts (i.e. multiple months) there is a possibility of these cuts coming to LodeStar in such a sequence that will create gap in dates and hence error out through 824 transaction marked with error code of DDM = Dates Do Not Match.

· Need to get some buy in b/c this is the way that Lodestar will load this data. Historical conversion data must be brought in chronological order. HL&P will send info present to past (backward) because the data is stored that way. Requirements for Lodestar will start

· For successful load of conversion data ERCOT wants in date order.

· One 867_01 per ESI ID, the loops will not be guaranteed that the loops will come in any order. They don’t need to come in any order b/c there are dates associated with each loop of consumption/usage.

· Last load for 867_01 is in March, first 867_03 in May. (867_01 not for Non-ERCOT)

· ERCOT needs the start and stop dates for the 867_03 to be the same day for non-interval.

· This should be discussed with the Conversion Team.

Change Control 2001-044:

Conversion Load/Opt-in

Add an “Energize/De-energized” flag to the 814_20 to indicate if the ESI ID is active (energized) or inactive (de-energized).

Add gray box to note when this segment can be used, move gray box from REF03 to REF02.

Approved 2/7:

Emergency change – will be implemented before 2/26 (third mock load).

This will be a new version 1.2A – Kim will send a redline to Mike.

· Redline version of this change was sent to listserver 2/13, will be final on 2/15

Change control 2001 – 046:

ERCOT is instructed in the protocols PIP Number 189, Off-cycle meter read request dates, rejection of switch request to reject switch requests which are received with a requested switch date prior to the first available switch date. A new rejection code is needed for this rejection reason.

*We may need to add the POLR enrollment transaction to this same change control. - - new change control if POLR applies

Approved

Change control 2001-047

650 in the PRT

Reliant needs:

ED Electronic Devise

BS Bus Shelters

TXU needs:

TR Transceiver

PA Power Analog node

Entergy needs:

AN - Antenna

CU - Cat Unit

SL - Group D & E Streetlights

OT - Other Unmetered

PB - Phone booth

PO - Phone Outlet

Susan will re-write change control - - and re-submit to Mike

Change control 2001-048

The POLR (or disconnecting CR) needs to know if the apartment complex is master metered because if it is, certain procedures must be followed prior to the disconnection.

Not Approved

Change Control 2001-049

Below is wording from Customer Protection concerning estimated bills. It states

That the REP must provide the reason for the issuance of the estimated bill. Ts&Cs - 4.8.1.4 Estimated Usage

Not Approved

Change Control 2001-050

Add an QTY segment in the Non-Interval Detail and Interval Summary loop for adjustments when meters readings are found to be inaccurate.

· Need some gray boxes in the PTD loop to handle this QTY. This will be used for the 95%, may need to be implemented by Pilot. ERCOT maps will be affected for 867_02 and 867_03.

Tabled, pending ERCOT approval. – EMERGENCY Priority

Change Control 2001-051

In the 650_01

Add a gray box under the RC002 that says "not used if customer re-wired during time of disconnect for customer requested clearance"

Add a gray box under the ME009 that says " also used for reconnect if the customer re-wired during the time of disconnect for customer requested clearance"

Suggested addition of a YNQ instead of the above gray box solution.

Tabled, TDSPs need to investigate this

Other:

Procedure for updates:

The sef file is created first, then an rtf document is produced from that sef file, and finally a compare of the new and prior rtf documents produces the redline. Redline will never say draft, b/c the redline is created from the SEF file of the new version. Redlines will be sent to the list serve, once changes have been accepted they will be posted to the website.

Patch list –

· New format, based on a transaction basis. “Here is the affected transaction”

· BJ will develop the format

Version Number/Naming convention

1.2.a

Position 1=Major Releases

Position 2=Application changes

Position a=Patch list

Unmetered Questions:

A couple of questions about the unmetered service type segment on the 814-04. Is there an update to the types of devices?

· Yes, 814_20 REF~PRT, REF~TD~REFPRT

We have cable boosters and highway signs (not traffic lights) but there is no code that seems to describe them. Also, we don't carry the wattage for these devices although we have the usage (KWH). In some cases, we could guesstimate the wattage from the usage but for devices like warning sirens, we only have usage and couldn't make a reasonable guess at the actual wattage. What would you like to do with these?

· Don’t send wattage if you don’t have it.

814_PA and PB(please refer to the attached 814P question.doc):

The way the examples are done gives the impression that whenever there is a Negotiated Contract the TDSPs Account Number is always to be used; whenever it is a Residential Volunteer the ESI-ID is always to be used.

Is this correct? Or, did the examples just turn out this way?

· The examples need to be changed to be more "generic" and apply to both residential and non-residential customers.

814P transactions:

It is our understanding that ERCOTs WEB Portal for looking up ESI-IDs from addresses will not be available until 01 June. The CR can send either the TDSP Account Number (as found on the end use customer current bill) or the

ESI-ID. Is this correct? Is this a Market Requirement for Pilot?

Send to PIC – If we get direction from PIC then someonw can write a change control

· The ESI ID is required per the Pilot Rule:

g(1)(E)

“Beginning April 16, 2001, a REP shall electronically report to the utility any switch request for a customer or an aggregation packet with a listing of the ESIs to be switched to the REP as set forth in this paragraph. After the utility confirms that a non-residential ESI or aggregation packet is on the associated participant list, the utility shall submit the ESI to the registration agent. The registration agent shall keep a record of all the ESIs identified by the utility for participation in the pilot. The REP shall be responsible for submitting to the registration agent the ESIs associated with the switch request to serve. If the ESI identified by the REP matches an ESI identified by the utility, then the registration agent shall allow the registration process to continue.”

· The rule requires a REP to send an ESI.

Pilot (Pre-Pilot) Synchronization with ERCOT:

On or about 30 March we send ERCOT Production Load. On 16 April we can begin sending 814_20s (based on the 814_PAs received) changing eligibility date.

A. What happens between 30 March and 01 June how and when do we provide updates to ERCOT for other changes that would normally flow through the 814_20s (i.e., how do we notify ERCOT we have new ESI-ID or changed meters at the ESI-ID)?

· This is a Conversion Issue

B. Should the TDSP continue to accept 814_PAs throughout the Pilot provided that a Pilot Class (i.e., Residential, Industrial Demand Metered Customers) is not fully subscribed?

· The TDSP is the Pilot Administrator. They are responsible for keeping track of the Pilot participation. Therefore, TDSPs SHOULD continue to accept 814_PAs throughout the Pilot UNTIL the Pilot class is fully subscribed.

Customer Name:

What is the standard rule we are following for formatting the customer name on the EDI transactions (Segment N1 (Customer) of 814_01 Enrollment, and for future use when EDI transactions are updated per Ts&Cs, possibly for the

650s also)(i.e., the customer name field is a total of 80 characters, but the first name must always appear in the first 35, middle in the next 15, and last in the remaining, how do you input Dr. Sr. Mr. Mrs., etc.)?

· Dave will create a strawdog.

· For outage there may be a need to deal with the Name field. No value to changing the N1s for 814s.

Patch List Items:

· AEP has offered resources. MPs need to have the list in hand very soon. It will be posted on the SET website and red-lined IGs will be posted. Mike is in the process of collecting additional documents for posting from the document owners.

814_20: Add to Patch List: We need change to the description on the REFSPL Code in the REF~TD segment in the LIN loop. It still reads Change Standard Interconnection Point and should be Change Station ID.

650 Purpose Codes: Add to Patch List: In the 650 (01,02,03) transactions, the gray box for Purpose Codes contains two errors:

ME use only when BGN07= RH. should be KH for Meter Exchange

TE use only when BGN07 = TE. should be IN for Technical/Environmental

824 Reject Reasons: Add to Patch List: Change gray box in 824 for TED~848~CRI – should be used for invalid or missing reference number for 867_03 cancel transactions when the BPT09 does not match a previous transaction. Add gray box to indicate: “…or an 867_03 cancel transaction does not match an existing open 867_03”

Data Structure Page: Add to Patch List: No repeating loops on the data structure page for the 650s

810_02 Taxes: Add to Patch List: take out the TXI07 – “O” in the 810_02

Assignments from SET meeting 2/1:

· Document list of Protocols gaps (language that does not reflect how ERCOT is processing transactions) (BJ/Jill/Heidi)

· Tax Treatment (Cary)

Attendees:

James Cohea ERCOT Kyle Patrick Reliant

Lisa Numrich Exolink Mike McCarty ERCOT

Kembabla Perkins Accenture Kim Wall Greenmountain

Calvin Susan Neel Reliant

Cary Reed AEP Heidi Schrab Relaint

Carrie Xcelenergy Fred Plett Logica

Dave Robeson Entergy Jill Prince TXU

Darrell Hobbes TXU Johnny Robertson TXU

BJ Flowers TXU Rosemary