TX SET

April 25-26, 2001 Call Meeting

Minutes

 

E-Mail Addresses

 

·         Please forward your e-mail address changes to ERCOT.  They have strict security.  You can only use the e-mail address in their system, not an alternate.

 

Finalize Minutes from 4/10-11 Meeting

 

·         Correction to meeting minutes of April 10th-11th – correcting previous correction.  Where it said CR will send 814_03, ERCOT will send the 814_03. 

 

Ownership

 

·         ERCOT is taking ownership of all SET guidelines, *.SEF files and examples and will do all future changes.  He has a new person on board, Glenn Wingerd, and they also have backup contractors.

 

Straw-Dog in TX SET procedures

 

·         Still looking for volunteers/input.  This subgroup will meet sometime next week.

 

Schedule for next release

 

·         We need to think about what approach we are going to take to attack the next version release.  Input is requested.  Suggestion to have small groups concentrate on a few transactions and thoroughly comb through to find errors and/or discrepancies.

·         George wants us to shoot for 7/1 for the next release – it is the one that will be used for Choice, including the 10/01 Flight testing.  George wants to allow time to code.

·         Everything coming out of workshops should be implemented in the next version release, plus all change controls queued.

·         Shirley is going through and finding materials.  Kim Wall is also finding problems as she goes through.

·         We have to agree to our own date.   7/1 could be a problem because we would have to meet almost weekly, and there are many RMS workshops going on.

·         We have to start backwards from October 1st to see what we need to do.  October flight begins September 27th.  We should allow six weeks or so to code.  Feeding customer information on enrollments is a major system change that might not be ready for choice, but it is really needed.  Everything permit group did is a protocol change.

·         Between July 1st and 15th is realistically necessary.   Some thought August 1st is more realistic.

·         7/1 billing is about to kick off, and we’ll find problems there.  

·         Tentatively, we will set July 17th as the deadline for the guides.  We will meet June 12, 13, 14, then 19, 20 & 21, and 26, 27 & 28, last day ˝ day.  All meetings will all be in Austin.  If we can cut back to 1˝  days, we will.  ERCOT will commit to the first set on the 12th - 14th.

 

867 Retail Metering

 

·         AEP is hosting metering workshop on May 9th .   Sharon Polliard will send out to SET request for agenda items.

 

Results of PTD/QTY questions on 867_02/03 and use of Channel

 

·         The PTD / QTY issue was pushed to the 4/25/2001 Change Control Conference call.  Resolution is that all TDSPs will use channel number and that the 867_03 guide will be changed to match the example (looping QTYs).

 

PTD Loop document

 

·         Need to add a section on generation.

·         Reference profiling protocol in non-interval meter measurement for provision of coincidental peak.

·         Change language in un-metered to not refer to more than one device type but rather refer to different wattages.

·         Metered Services summary – remove “this is the lowest level of reporting”.

·         Change “kVARH” to “kVArh”.

·         Add additive to “adjusted for subtractive consumption”.

·         In estimated consumption adjustment section, Add “Sometimes, depending on TDSP practice” to “readings are not adjusted to compensate”.

·         Put as an issue to RMS as to whether estimated consumption adjustments usage in first pass through netted or not.  Need to have one practice.  The same issue exists with subtract metering.

·         After these adjustments are made, the revised document will be sent out for comment.

 

Master and subtract meters with separate ESI Ids.

 

·         TXU has about 8, Entergy 2-10, SPS zero subtractive meters.

 

814_PCs and 814_PDs

 

·         Guide doesn’t say for move-ins and changes in contact info only, but that was the intent.  This is a subject for PWIG.

·         Shell work-around will be discussed at PWIG.

·         Technical merit – comments from Xcel Energy will be incorporated in PC/PD Alternative (by Shell).  This is technical merit only, not an endorsement by TX SET.

·         We need to have some timing defined for us.  Exactly when this transaction will not have to be supported by the TDSP anymore (Dec 2001?), and the timing of when the transaction should be sent by the CR (after the 867_04 is received?)

 

Correct to 867_03

 

·         ERCOT documented how they developed the cancel – re-submission process.  It is not TX SET compliant.  There will be further discussion in data conversion call for conversion issues (867_01).

·         SET’s understanding was to cancel each month and then resend each month.

·         ERCOT’s understanding is that you can replace one month without following month adjustments as long as you cancel the month and send new data with an adjustment code.

·         We need to know how to cancel – re-statements on un-metered services, and is it different for street lights.  This could be an issue for RMS.

·         Use of Code 04 Adjustment Change.  This is an ERCOT special code not TX SET compliant that bypasses date checks.

·         Current Practice:

Ř       Reliant – street lights only, constant readjustment so concerned about volume but can handle. 

Ř       SPS cancel re-bill

Ř       TXU cancel re-bill

Ř       AEP cancel-rebill all the way back

Ř       TNMP & Entergy – still waiting for a response.

 

Special Read

 

Small Commercial customer wants a special read on end of fiscal year, mid-cycle.  Has TX SET addressed this?  The customer gets a special bill and then a regular cycle bill. 

 

·         Response – most won’t issue a special bill, just a special read.

 

Other Questions

 

·         Will a CR ever get an 814-08 move-out cancellation?  No.  Or a cancel to move-in?  No.  In each case the cancel would have to initiate.

·         Would we ever get a cancel drop to POLR as a CR?  No.

 

814_PA, 814_PB multiple LIN loops

 

In ASC X12 structure the REF segment is greater than 1. Does the guideline allow one LIN when requesting multiple ESIIDs to be enrolled?  Or do we have a one to one relationship in LIN and REF?

 

·         One for one – one 814_PA for one ESI ID.  You cannot include several ESI IDs wirh one 814_PA.  This is true for all EDI transactions except for 820’s.  The ESI ID and zipcode are validated at ERCOT – the transaction only allows for one zipcode.  Additionally, if one ESI ID is not valid the entire transaction would be rejected.  

·         Can Reliant enter a Protocol change to add some clarifying language to Chapter 19?

 

814_PC and 814_PD Guides – Driver’s license and social security REFs

 

The Drivers License and Social Security REFs need to be deleted from the 814_PC/PD Guides per the Terms and Conditions Rulemaking.  We will submit a change control for this, however we want to discuss this on the call tomorrow since PIWG will be approving these transactions (as well as it's workaround) next week (at the May 1st PIWG meeting).

 

·         We should get it in writing any decisions by PWIG or other competent authority before we do anything.  Haven’t seen anything in any minutes.   It’s optional now.  We should go to RMS to ensure that the decision is, in fact, to remove the option for driver’s license and social security REFs.

 

CSA and POLR scenarios

 

·         Subgroup to discuss Choice issues for CSA and POLR.  Volunteers are Christine Meloro, Heidi Schrab, Mike McCarty, someone from TXU, and Susan Neel.

 

Invoice Changes that do not affect the Consumption 867

 

Question regarding what messages are required in the following scenario:

For February (02/01/01) we send a 810 which has a meter billing and a mics. charge (some type field trip), we also sent a 867 for the usage for the meter billing. 

On 02/10/01 we cancel the mics. charge, so we send a 810 cancel for both charges and a new 810 for the meter charges only, are we required to send a new 867 for the usage even though it did not change ?

We changed something on invoice doesn’t affect consumption

 

·         Prevailing discussion - whenever we cancel an 810, we’ll cancel 867 as well.  The two are tied by reference numbers.

 

SET Issues from 4/10- present: TDSP Rate Class Codes

 

In the 814_05 the REF~NH segment does not list the codes that should be used for the TDSP Rate Class.  I thought the rate classes were final but the charges for these classes were not.  If this is so should the codes not be listed in the implementation guide?  

 

·         The codes are not approved yet.  For now they are the tariff codes, and will be posted on a web site.  They could change.  The REF~NH will allow anything.

 

Multiple Changes in Move-out/in Dates

 

We need info what ERCOT will do in this situation, whether or not it is already covered in the protocols, or needs to be addressed.  I don't find anything.

Existing Customer schedules a Move Out for 5/15 and it is in the works.  New Customer schedules a Move In for 5/1.  ERCOT sees the date problem, sends an 814_12 to the current CR to change the Move Out date to 5/1, and sends the 814_03 on to the TDSP with a code of MDI.  TDSP changes the Move-Out date to 5/1.  Now, New Customer calls back in and changes the Move In date to 5/15.

Since Old Customer really wanted to move out on 5/15, and he has been forced into a Move-Out on 5/1, how is he protected from having his service cut on 5/1, two weeks ahead of when he wanted it?   The dates appear to ERCOT to be in the proper order, so how would they know to send any kind of notification?

 

ERCOT will not go back to the Move-Out and change the date back.  An 814_12 would be required to change the date back to 4-15.

 

I think that this issue will cause problems.   The example that was presented is "very real world" and the Move-out customer will not even be aware that their requested date for service interruption has been moved back.  Has anyone worked through a flow of this scenario to see what all happens on the change of date requested on the move-in as outlined?

 

The problem on this is that the hapless move out customer is now scheduled to have his service terminated on 5/1, when he requested it to be on 5/15.  He probably doesn't know it was rescheduled.  His CR doesn't know.  The TDSP doesn't know.  I had originally thought that this could be handled by them when the 814_12 came in, by checking for a move out at that premise.  In this case, they would find it, but they wouldn't be able to tell that the date was not the original date, or even the one the customer had requested.  In order for a TDSP to be able to keep up with this, they would probably have considerable expense and overhead, adding all the dates and keeping the histories, AND having to check through them all, every time a date change request came in.  Is ERCOT keeping up with this already, so that they would know the originally requested date?  I'd hate to be the customer.

 

·         This issue was pushed to the RMS move-in – move-out workshop.

 

Additional Validation Fields Needed

 

Excelergy has a concern there is the potential for error when processing multiple transactions within a short period of time for a single ESI ID. For example, for one ESI ID, a CR sends/receives multiple transactions for a tenant move-out, CSA transactions, tenant move-in, final and beginning reads, possibly a regular read cycle 867, and 810s for each of the customers.  Add in a date change or two and things begin to get muddled.  While there is extensive cross referencing in the BIG of the 810, BGN of the 814 and REF*TN in the 867, several transactions do not include the customer name that could be used as a second validation, e.g. 814-06 - Drop Due to Switch Request - ERCOT to Current CR, 814-08 - Cancel Switch Request – ERCOT to Current CR, ERCOT to Current CR.  Would it be possible to require the customer name in additional transactions for a second validation in order to associate the correct data with the correct customers.

 

·         This issue will be pushed to the POLR CSA subgroup.

 

BGN Tracking Numbers

 

I know the 814_25 states that the BGN06 "Refers to the BGN02 identification number of the Move Out Request (814_24)." I wanted check to see if the TDSP picks up the BGN02 for the original, which is the BGN06 of the forwarded 814_24 from ERCOT. Or do we use the BGN02 of the 814_24 from ERCOT, which is a different number from the 814_24 from the CR to ERCOT. Hope this makes sense. Call me if you want me to clarify further.

EXP     814_24 from CR to ERCOT       BGN02 = 7362

            814_24 from ERCOT to TDSP    BGN02=1234567890 & BGN06 = 7362

Does the TDSP use 7362 or 1234567890 in their BGN06 of the 814_25 back to ERCOT?

 

·         Mike McCarty sent something out yesterday.  There have been two responses, both are bulletins.   They are both on the ITPTA web site.  Mike McCarty will try to create a link from TX SET to ITPTA web sites.

 

Additional “Rules” for the N102

 

It is my understanding that in the N102 element of the N1 segments that the only requirement was that the data be in all caps. It is also my understanding that punctuation would be allowed unless specified in the gray box next to the element.

Please let me know if I am correct in this understanding.

 

·         There is a change control being developed – ERCOT can’t handle “&”.

 

814_PA/PB Transactions Timing

 

We're wondering what everyone else is doing: We know that the 814_PA transactions cannot be sent to our trading partners until Monday 4/16 at 12:01 am.    Can we process these within our own system prior to this date?  This would mean the dates within the transactions (BGN03) are prior to 4/16, but the file date would be 4/16. 

 

·         You can create and process whenever you want, just don’t send the 814_PA’s earlier than April 16th.

 

ESI ID “Not Eligible” Error on the 814_02

 

If a switch (814_01) is sent in during pilot and the 814_20 change eligibility date has not been made, what error message will be returned? Will it be ESI ID not eligible ??

ERCOT Response: Yes - that is the error message. WHAT CODE WILL BE USED?  A13 with comments?

 

·         ERCOT will have to more completely respond to this.

 

814_20 transaction questions

 

1)       I want to verify that when the CR contacts the TDSP to establish a new ESI ID, the TDSP sends the 814_20 to ERCOT.   ERCOT does not forward the 814_20 to a CR as they don't know at this point who the CR is.  An old copy of the scenarios shows the "create" only going to ERCOT.  But the current guideline does not reflect this.  If I was a new participant, how would I know this?  I would have the same question for the adding or deleting which only goes from the TDSP to ERCOT.  How would a new participant know this.

2)       For the wholesale delivery point - currently we can say Y in the EDI doc.  Is there a case where the wholesale delivery point would no longer be one?  How would this then be denoted? or what would the transaction flow be if  this is a valid situation.

 

(1)     There is not an 814_20 sent to the CR because the CR is not the CR of record.  After the 814_20 establishes the ESI ID, the CR will have to follow up on its own to determine what the ESI ID is for the customer and do what it needs to do for marketing.

(2)     Shirley Whyte to take an issue on this one.

 

867 Gap/Overlap

 

I didn't see any explanatory language in the 867_03 regarding the date overlap/gap issue that the TDSPs and ERCOT discovered during conversion.  I would like to discuss this on Wednesday and create a change control to add some clarifying language to be sure the CRs are not surprised during testing/pilot the way the TDSPs were during conversion.  The issue is how the date ranges are sent. 

Example of how to send date ranges so that ERCOT can process:

Jan 1 - Jan 31

Jan31 - Feb 28

Feb28 - March 31

March 31 - April 30

Example of how not to send date ranges:

Jan 1 - Jan 31

Feb 1 - Feb 28

Mar 1 - Mar 31

April 1 - April 30

What do you think?  Are there any other conversion lessons learned that we can document?

 

·         James Cohea developed a really good white paper on gaps / overlaps.  If Shirley could post with her other materials that would be helpful.  Glenn will take action item.  We should put in what ERCOT is validating and not validating.

 

Date Change Response

 

If the TDSP gets an 814_12 date change request and the TDSP can not accept the date change request (i.e; non

business day) I do not see a DTM in the 814_13 to send back the date that we can accept. 

 

·         We need a change control.  In the T’s & C’s there is language allowing 7 days leeway from requested date – change control is necessary to feed back the date to the CR.

 

Approved  “emergency” Change Controls

 

Can you please tell me what are the approved emergency change controls that are not included in Version 1.3? I had heard none on Tuesday but I think a couple we approved yesterday.

 

·         The approved emergency change controls are posted on the ITPTA web site.  Mike McCarty will take an action to do the same with the TX SET web site.

 

Meter Re-sets

 

Texas SET, this is Entergy DisCos approach to handling Meter ReSets.  Do any other Market Participants have a similar scenario....similar concern.....similar requirement.....

Entergy dist co will send 2 cuts for a meter re-set during the billing period. The first cut of data will contain the start read/date for the beginning of the bill period, and the end read/date immediately prior to the meter re-set:

 

CUT 1:

Start Date:              3/1/01

Start Value:             48000

End Date:              3/15/01

End Value:             50000

 

The second cut will contain the re-set date and value, and the end read/date for the end of the bill period:

 

CUT 2:

Start Date:              3/15/01

Start Value:             0

End Date:              3/31/01

End Value:             1000

 

Total consumption in this example for the meter is 3000 KWH.  The alternative - combining these cuts of data – would result in the following:

Start Date:              3/1/01

Start Value:             48000

End Date:              3/31/01

End Value:             1000

 

The total consumption in this case is still 3000 KWH, however, a retailer cannot determine how we arrived at this consumption value if we do not publish as 2 separate cuts.  For an on-cycle re-set, we will simply send the readings as a single cut for each bill period. A REP should always look at the start read value for a particular cut rather than use the end value from the previous bill period.

 

Response 1:

I think that what you are describing is a meter change, and the meter is changed mid-cycle.  The 867_03 gives the method to show the readings from beginning to change date (end reading) and then another beginning(change date) and end reading.

 

Response 2:

It needs to be essentially shown as a meter change... my question is do you have circumstances where you reset the meter to 0 without physically changing the meter out?  Without a physical change in the meter, you would not send the 814_20 and we would not be looking for the break in the usage.  Regardless the use of the two PTD Loops, with start date & change date for the first and change date and end date for the second will work.  We'll realize it is a "reset" because the meter number will not change.

 

Response 3:

TXU will do a meter change in this situation.

 

·         Will go to retail metering RMS workshop.

 

Customer Waiting Periods

 

When a CR signs a customer service contract with the customer, are there two waiting periods or one?  Once the CR sends in the transaction to ERCOT, ERCOT sends a letter out, and the customer could possibly object.  Does the CR need to wait 3 days before sending in the transaction, or is the 3 day wait part of the ERCOT wait?

 

·         There were varying opinions.  We still need to clear this up.  We can ask Dale Goodman, responsible for customer contract, but it is really a PUCT question.  Mike McCarty to take to Dale.

 

Move-Out Change in Date on the day move out is supposed to occur

 

What if a customer calls the CR on the day the move is to occur, and wants to delay it two weeks?  How shall the CR handle with the TDSP?

 

·         First, a phone call by the CR to the TDSP is in order to try to prevent crew dispatch if possible.  However, a follow-up transaction is also necessary because ERCOT is involved.

 

650’s during Pilot

 

·         Is anybody using 650’s during pilot?  TXU retail was planning on using them, at least.

 

Next Meeting

 

May 17th and 18th, Austin, location TBD.

 

Attendance:

 

Name

Affiliation

Phone

E-Mail

Fred Plett

Logica

603-497-3907

Plettf@logica.com

Jill Prince

TXU

214-875-1545

Jprince1@txu.com

Darrell Hobbes

TXU

214-875-2204

Dhobbs2@txu.com

Paul McKinney

Shell Energy

713-241-6394

Dpmckinney@shellus.com

Bill Boute

Entergy

 

 

Christine Meloro

New Power

 

 

Charles Scheffer

Reliant Energy

713-945-6630

Charlesscheffer@reliantenergy.com

Susan Neel

Reliant Energy

 

 

Heidi Schrab

Green Mountain Energy

512-691-6104

Heidi.schrab@greenmountain.com

Kyle Patrick

Reliant

713-207-3519

Kyle_Patrick@reliantenergy.com

BJ Flowers

TXU

214-812-4330

Bj.flowers@txu.com

Jill Popelka

TXU

972-679-5064

Jill.popelka@txu.com

Randy Brannon

TXU

214-875-5182

Randybrannon@txu.com

Carrie Landis

XCEL / SPS

303-571-7310

Carrie.Landis@Xcelenergy.com

Rosemary Freeman

Exolink

 

 

Barb Tate

Exolink

 

 

Rita Morales

Entergy

972-538-6983

Rita.morales@exolink.com

Sharon Polliard

AEP

918-594-2265

Spolliard@aep.com

Bob Hill

Energy Services

 

 

John Wilkinson

GE GXS

817-379-5001

John.Wilkinson@gxs.ge.com

Jason Wrubel

Shell Energy

917-452-3633

Jason.M.Wrubel@accenture.com

Roshni Patel

Reliant Energy

713-207-8258

 

Dave Robeson

Entergy

504-576-2571

Drobe90@Entergy.com

Diana Rehfeldt

Excel Energy / SPS

 

 

Shirley Whyte

ITPTA

713-906-5124

Swhyte@mindspring.com

Mike McCarty

ERCOT

512-248-3959

Mmccarty@ercot.com

Glenn Wingard

ERCOT

 

 

Shailendra Reddy

Reliant Energy