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:
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
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 |
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.
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
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.
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.
Other:
·
New
format, based on a transaction basis.
“Here is the affected transaction”
·
BJ will
develop the format
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?
·
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