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