SET
Minutes
March
7-8, 2001
Version 1.3
Review
draft transactions, compare with patch list, publish REDLINED version 1.3 by
3/8. MPs have until Tuesday 13th
to review the documents. The discussion
call will be at 2PM on Tuesday. Mike
will set up the conference call and send out an email with dial-in number. Final version 1.3 will be released and
posted on March 15th.
814_18 Customer Notification Letter
Entered a change control
for removing the N1~N1, per ERCOT Protocols 15.1.6.1 Request to Initiate CSA. The change will be included in the v 1.3
redline, if MPs object it can be discussed at the conference call on Tues.
Need an N1~N1for the 814_10 Drop to
POLR
Where should ERCOT receive the customer notification address in the
814_10 Drop to POLR? There is not a N1 customer notification address loop in
the transaction.
·
ERCOT needs to
enter a change control for this.
810_02
The
810_02 (v 1.2) there is a unit of measure in the SAC of K5. This K5 does not appear in the MEA of the
867_03 (v 1.2). Should it be in the
867_03 or should it be taken out of the 810_02? If it does belong would someone please provide an explanation of
this K5?
·
A K5 code may need
to be added to the 867_03 (and 814_20 too?) – Reliant will check on this and
enter a change control if necessary.
Otherwise a change control to remove the K5 from the 810_02 will need to
be entered.
814_05
Removal of the MVO code
from the 814_05 should also apply to the 814_04, since the 814_05 is supposed
to be a pass-through of the information in the 814_04.
·
Included in v1.3 redline
814_12
The 814_12 was renamed a long time ago from
Move In/Move Out Date Change Request to simply Date Change Request because we
allowed the transaction to handle a change in DTM~151 when "changing the
scheduled drop to POLR date due to a switch that causes the drop to occur
earlier."
"Refers to the BGN02 of the Move In
Request (814_16) or Move Out Request (814_24).
This number will be tracked in the BGN06 throughout the lifecycle of the
Move In or Move Out Process."
Corrected
gray box with:
Refers
to the BGN02 of the Move In Request (814_16), Move Out Request (814_24), or
Drop to POLR Request (814_10). This
number will be tracked in the BGN06 throughout the lifecycle of the respective
process
·
Included in v1.3 redline
867_03
Changes
·
Replace implementation guide page
·
Interval misspelled in REF~MT – in the PTD~SU loop
·
Correct example #5 SE
·
Add example for EPS
·
Add an example for subtractive interval
·
Add an example for subtractive non-interval
·
867_03 examples move the totalizer into the same loop as
on-peak, off-peak, etc.
·
867_04 examples need to be corrected
867_04
Change “Settlement agent/Clearinghouse” to
ERCOT
Add another example for interval ESI Ids
**Change control needs
to be written to address how the “reading” is addressed for interval ESI
Ids.
867_01
In 867_01, the PTD~SU (non-interval summary loop) contains a MEA
(consumption) segment for which the unit of measurement (usually sent in MEA07)
is not specified. Are we assuming that consumption is always measured in kWh?
If not, what is the default unit of measurement?
·
The answer is
NO, you cannot always assume the consumption measured is always kWh. The REF (Meter Type) segement will indicate
the type of consumption reported in the PTD~SU loop.
·
Email from David
as of 1/23, multiple units of measure will be reported in individual PTD loops
– the unit of measure will be in the REF~MT.
Documents which have
dials and multiplies, the gray box indicates that you would not have number of
dials for a demand meter. Is this true?
·
NO, sometimes
for a demand meter you could have an LCD read out, which is essentially the
same thing as a dial.
K1 Kilowatt
Demand (kW)
K2 Kilovolt
Amperes Reactive Demand (kVAR)
K3 Kilovolt
Amperes Reactive Hour (kVARH)
K4 Kilovolt
Amperes (kVA)
KH Kilowatt Hour
(kWh)
814_PC/PD
The
814_PC and 814_PD transactions are used to update customer information for
Outage options 2 and 3. Will the TDSP ever update the customer info and
initiate the transaction – 814_PC?
·
No, TDSP will
never initiate the 814_PC.
814_01 is sent to ERCOT
and could be rejected for reason's other than permits. The 814_PC is only for the CRs that chose
option 2 or 3 for outage/service orders.
I think that the CR shouldn't send the 814_PC until they receive the
814_04 response. That way they know that the 814_01 made it through ERCOT and
the 814_03 made it through the TDSP.
·
Timing for PC proposal should be presented to
RMS. Proposal for CR to send 814_PC to
the TDSP after the CR receives the incoming 867_04.
824s on 820 -
TABLED
There doesn't seem to be a way to reject an 820. I know that MPs do not want to reject
money. But what if the ESI-ID is bad,
or the invoice # is bad? Did we
decide that since there were multiple ESI-IDs on one 820 that it would be a phone
call. What if the DUNs # is wrong?
If we get a 824 rejection of a 810 or 867 - then our next step is to send
a cancel - so that we can send a corrected.
Then lets say we get a 824 rejection of the cancel 810 or cancel
867. Would the lifecycle reference # on
the second 824 be the BIG02 of the original 810 or 867 or the BIG02 of the
cancel 810 or 867.
Suppose that the CR has chosen option 3
(Customer calls TDSP directly) in the event of an emergency or service order
request. The customer call the TDSP to
request a disconnect for construction and a reconnect.
·
The customer
must initiate a Move-in, switch or Move-out through the CR.
How will the TDSPs notify the CRs that a
customer has called them directly for a service order and it has been
performed?
·
TABLED – the
issue is that the CR wants to be notified if the Customer has requested
something that involves a charge (the CR will be responsible for paying the
TDSP for that service 35 days after the TDSP invoice)
Will the TDSP send an 814_PD without the
complementing 814_PC or will the only notification be on the 810_02?
·
No. TDSPs will not initiate an 814_PC (the
transaction does not have data elements to send that kind of info anyway).
The only option available during pilot would
be option 3 (customer calls TDSP directly).
The availability
of both option 1 and option 2 would commence with market open.
Beginning Market Open planned outage
notification/transactions will be sent
Change Controls
Daylight Savings Time Change Control: Is this needed
for Pilot or not? Mike has this one to
do and will put it together later, after the Pilot.
In SET minutes -
and in our discussion of the daylight savings time indicator. We said that it would not be issue until
Fall. However, for conversion of historical data it is a issue now. We need to get this change control escalated.
[David] My
understanding about the conversion process is that the intervals are loaded in
the order that they are received. I
will follow-up with the conversion team
to work on verifying the conversion process correctly maps the daylight savings
time intervals for a sample of ESI IDs with each TDSP until this change can be
implemented.
·
We need to add a separate code to distinguish the 867_03 monthly from the
867_03 EPS. The 867_03 EPS only has the
PP loop which is the summarized across meters.
·
Need a code in the BPT04 (code “PD” Proof of Delivery – gray box “Daily
consumption for ERCOT Polled Services”) to map to the XML tag
“<ERCOTReadLoad>”
·
Who was going to enter the Change request - 867_03 in the Un-metered loop, change “adjustment code” to “cancel”
·
Companies need
to check to see if Street Light Billing will be a problem - report back to SET.
·
For the 867_04, no start read will be sent, just the
start “date” – for unmetered services there will be no meter number, absence of
the meter information will indicate that it is an unmetered account.
·
For cancel – rebill,
need to cancel – rebill each month and to get correct usage in each month in
867_03. Will need to cancel all 810’s,
re-send all 810’s. We will need to fix
the guide because the 867 has a code in it for one-time adjustment that needs
to come out. If ERCOT has an issue with
this it will need to submit a change control.
Change
Control 050: Emergency. OPEN ISSUE – additional consumption
will not match the readings. Impact to
ERCOT. Issue forwarded to James
Cohea. TXU will investigate the
impact. TABLED for next Texas SET meeting.
This will not impact ERCOT. This is just to send additional
consumption (fast meter, slow meter, dead channel) to the CR. Beginning and ending meter readings
will need to be TXU is Requesting a new code (VM) in the
QTY and a gray box to explain when the code will be used. The consumption (positive or negative adjustment) on the 867 will need to match
the 810. So either the reads will be
off if the VM is used Reliant and AEP will not use the VM code,
process is to remove the meter and escalate reads. Concept will be raised to RMS
|
Change Controls 053 and 054: - will be
resubmitted with new Change control numbers.
Change Control 055:
Concept Approved - Not needed for Pilot, needed for Choice
David will resubmit the Change Control with
the REF page.
The
original transaction id is needed to complete the correct business process
when multiple business processes are occurring for an ESI ID. When a move out and a move in are both
pending, it is not possible to match the 867 correctly for all cases without
this data Add the following REF to the 867_03
and 867_04
This
REF is required when completing a switch, move in, drop to POLR, or move out
request. REF01
= 6O NEW CODE WILL BE CHOSEN REF02
= Original Transaction Id from the Move In, Move Out, Switch, or Drop to POLR
transactions initiating this to be a final or start read. This value should come from the TDSP to
ERCOT and will be forwarded by ERCOT to the CR. The source of this value will be the BGN06 of the 814_03 or
814_24 sent from ERCOT to the TDSP. |
All TDSPs can do this by market open. |
Change Control 056: Withdrawn, done in 824 – 1.2a
Affects transactions from CR to ERCOT.
The TDSP needs to be identified (in the 824) by the CR in order to
forward the usage rejection from ERCOT to the TDSP.
Without the TDSP being identified, ERCOT will not be able to forward
the usage rejection to the TDSP.
Change the TDSP N1 from dependent to “Required.” Include an example where the TDSP is
identified for a notification from the CR to ERCOT where the TDSP is not the
sender or the receiver. Change the N106
from Required to Dependent. The N106
should be required when the TDSP is the sender or the receiver of the
transaction.
Change
Control 057 – resubmitted as #59: Withdrawn, done in 824 - 1.2a
Change Control 058: TABLED AGAIN, pending ERCOT input
ERCOT wants to add "power region
code" to 867_01 and 867_03.
Already send this to ERCOT via 814_20.
Seems to be more of an ERCOT problem than other market
participants. ERCOT rejects 867s coming from Non-ERCOT entities if they have
consumption information on them.
Add power region to the 867_01 and 867_03
ERCOT is not going to load non-ERCOT ESI ID usage into its data
aggregation system. We may receive usage data for non-ERCOT ESI Ids for switch
reads. Adding REF~SR to 867_01 and 867_03 will allow ERCOT to do validation on
the power region so that such usage is not loaded into the system
1 - Add REF~SR at the header
level to 867_01 and 867_03 as follows:
Change Control 060 - TABLED
On
the 650 _03 Service Order Response (Reject or Complete Unexecutable) add the
code “V005 – No Field Action Taken-Reconnect Received” to Segment REF (Complete
Unexecutable Reason).
The
TDSP recieves a Disconnect for Non-Pay 650_01 Service Order Request from the
CR. Before the TDSPcan dispatch
and/or work this Disconnect for Non-Pay
650_01 Service order Request, the TDSP recieves a Reconnect for Non-Pay 650_01
Service Order Request from the CR. The
TDSP has not done any field work. The
TDSP would use this code to close out both 650_01 Service Order Requests
received from the CR (Disconnect for Non-Pay and Reconnect for Non-Pay). There would not be any charges associated
with this if a person was not dispatched.
If a person was dispatched, there could be potential wasted trip fee
charged.
Change Control 061 – Approved for Choice
Mixed Values - 867_03 Add the DR code to the BPT04 Gray box: Mixed Values-reporting cycle contains
periods of both non-interval and interval data. There would be a PTD loop for each type (two loops) When a meter change occurs mid cycle and
changes from non-interval to interval or vice versa.. |
Change Control 062 – Approved for Choice pending a redline
Late Payment: - needs an SLN description
Add a REF segment indicating the delinquent Invoice Number in the SLN
all loops to support tying back the Late Fee to the delinquent invoice and
interest.
The 810 supports the TDSP sending the CR a late payment charge when
an invoice is past due. Currently, it
assumes that the tie to the Late Payment Charge is the previous, previous
invoice. When a cancel/re bill (refer
to example below) occurs there is a potential to have multiple months of
invoices for the same ESI ID to be late.
Therefore, causing multiple late payment charges on one invoice. In the vent this scenario occurs, the CR
will have no way to tie the late payment charge to the correct invoice. For this reason, there must be away to tie
back the late payment charge to the corresponding delinquent invoice.
Change Control 063 - Approved for Choice pending a redline
Interest: Mapped in REF segment. Different SLN for late fees. Tying the invoice to the late fee. Credits (negative charges) contained with
in EDI 810 transactions from Utilities to competitive retailers should be
used for Utilities to pay interest to Competitive Retailers owed because of
improperly invoiced charges (Section 4.4.8 of the Terms and Conditions). In the same way, Utilities should use
debits on 810s to charge interest to Competitive Retailers when they withhold
amounts that were properly invoiced.
These interest payments will need their own SAC codes. Currently, no other EDI document is
available to make such transfers. The
market should try to keep paper flow at a minimum, therefore, EDI transfers
are a logical choice. Creating
another EDI document or using a current one, like an Retailer is a reduction
in monies or additional charges due to the Utility. |
During the Pilot if a customer who volunteered and moves to a new CR and
then wishes to go back to the TDSP, how is this accomplished? I do not know if this has been resolved
completely.
There are several options:
White papers will be discussed at the RMS level or PUC.
For mass transition how will ERCOT set-up
all customers who did not choose another REP (default customers)? Some TDSPs will split the inherited
customers between several Affiliate CRs.
Therefore, should we assume in order to move customers from a utility to
an affiliate REP, a massive change (or switch request) would need to be sent by
the REP to transfer all defaulting customers from the utility to the affiliate
REP.
·
Need 4-6 people to
discuss the Muni/Coop invoice draft
1. When can the TDSPs begin sending the send
814_20's to update eligibility date for Pilot Customers ESI IDs?
[ANSWER] This question is under review at
this time. We are working to determine
the time required to process the transactions at this point. Our answer has always been June 1. The mail box will be set up prior to that
date. Please see answer 2.
2.
When will mailboxes be ready to receive transactions? 4/16? 5/31?
[ANSWER] These will be production
transactions. The Independent Third
Party Test Plan Administrator will have certified the market participant and
ERCOT systems before these transactions should be sent. There will also be an issue of the
production encryption keys for production.
This is all under development at this time.
3.
What is the "processing times" schedule by transaction for
ERCOT? MPs would like to set systems up to mirror ERCOT processing times. The general plan has been requested. It has not been received.
·
If a premise is de-energized, and the TDSP sends an 867_03 to ERCOT…will
ERCOT reject the transaction? Need to follow-up
·
“Tax” statement from the PUC – waiting for answer from State Comptrollers
Office
·
814_28/29 – this is
an 814_PC and PD, in draft form.
·
Overpayments – not
resolved.
·
Charges not
associated with consumption after the customer has switched away – The TDSP 810
should not reference the 867. We can
change the 867 to optional, change the gray box, so that it is not required for
when the cost is not associated with an 867.
Johnny Robertson will write change control.
·
Move in – unexecutable
– need a protocol change for this.
·
Additional
consumption, reads won’t match - RMS
issue
Transaction path for 867s
for Non-ERCOT TDSPs. Pass through
ERCOT, Point-to-point or choice of options? Still waiting for final word.
Per Cherie:
The protocols section 15.3 Monthly Meter
Reads and we found the following ""for Non- ERCOT ESI IDs, the TDSP
will send effecting meter reads to ERCOT in accordance with SET 867_03. This transaction contains the meter read
date without consumption information."
I read this to say that ERCOT cannot accept consumption information from
Non-ERCOT entities. We have been looking at our technical capabilities in
response to non-ERCOT entities but we must meet the protocol requirements.
RMS Issues:
·
NEW ISSUE: Timing for the 814_PC – proposal to require the CR to send after it
has received the 867_04.
·
NEW ISSUE: Concept(s) for reporting additional consumption (change control #50)
·
Protocol says 814_24
will not be received by TDSP from ERCOT, and will not send back an 814_25. Protocol needs to be fixed.
·
814_13 – Protocols
needs to document that the 814_13 received from the TDSP will be forwarded by
ERCOT to the CR.
·
Permits / inspection
clarification.
·
Move-in Unexecutable
·
Non-ERCOT TDSPs 867s
– do they have an “option” of passing ERCOT or Point-to-point?
·
Timing of 814_20 for
eligibility date change and 814_01 for the beginning of Pilot. Need clarification on exact dates and times
that transaction will be accepted by ERCOT and processed.
·
TDPS During Pilot –
settlement of 100% of the market
Other
·
Protocol Revision Subcommittee (PRS) -The ERCOT
Protocol Revision Subcommittee (PRS) finalized its operating procedures. The procedures will be presented to ERCOT
TAC 3/8 for approval PRS discussed the
rough schedule for addressing the PUC Protocol Order changes. A proposed schedule is being developed that
target's the PUC's June 1, 2001 implementation date.
·
Conference call
is to address Change Controls only. We
will not ask MPs to make split second decisions on a conference call, only
decisions on Change Controls that have been circulated on the listserve.
·
Conference calls
have been moved back to Wednesdays at 2PM
Review
Assignments:
·
Susan – 867_03 EPS change control
·
ERCOT – daylight saving time change control
·
ERCOT – Customer Notification N1 loop in the 814_10
·
Heidi – Change control for removal of N1~N1 in the 814_18
·
Who’s issues was
this? - Change request for CSA Scenarios for BGN06 of the 814_03, or the
814_24.
·
Reliant – check on
the 810_02 – use of the K5 code in the 867_03 MEA.
·
Who’s doing this?? - Change control needs to be written
to address how the “reading” is addressed for interval ESI Ids.
·
ERCOT/David – verify the conversion process in reference to the daylight
savings time issue.
·
ERCOT – needs to respond to the Un-metered Usage Reporting Issue –
cancel/re-bill month-by-month or lump adjustment.
·
TDSPs – review street light billing process in reference to
cancel/re-bill month-by-month or lump adjustment.
·
ERCOT – be prepared to comment (on the Tuesday conference call) on the
867_03 EPS addition of a code in the BPT04 to indicate that the transaction is
for EPS.
Next Meeting:
3/21-22, Wednesday and
Thursday 8:30 – 5:00 Austin, AEP will sponsor, in Austin - WellsFargo Building
15th @ Guadalupe, 6th Floor Suite 650
4/10-11 Wednesday and Thursday
8:30 – 5:00 Dallas, TXU will sponsor; 1601 Bryan @ Ervay
4/25-26 Wednesday
and Thursday 8:30 – 5:00 Dallas, AEP and Entergy will sponsor; 1616 Woodall
Rogers @ Arkard
5/9-10 Wednesday
and Thursday 8:30 – 5:00, AEP and Entergy will sponsor; Corpus
5/23-24 Wednesday
and Thursday 8:30 – 5:00, Green Mountain will sponsor; tentative - Ft.
Lauderdale
*Conference calls for SET
Change Controls will be at 2PM on Wednesdays.
Attachments:
Meeting Minutes 3/7-8/01
Updated Map Scenarios DE
Attendees:
Jill Prince TXU Cary Reed AEP
Johnny Robertson TXU Kyle
Patrick Reliant
Kathy Scott Reliant Kim Wall Green Mountain
Mike McCarty ERCOT Dave Robeson Entergy
BJ Flowers TXU Susan
Neel Reliant
Christine Meloro New
Power Dave
Bynoe Shell
Carrie Landis Xcelenergy
Open Issues List |
|
|
Date |
Issue |
Approach |
12/20 |
1) 814_28/29 – PC and PD In
our minutes of 01-02 Nov, information is provided related to potentially
continuing to develop the 814_28 and 814_29 to use for Customer
Maintenance. As reflected in the
minutes: this is for REPs that will
not handle service calls/outage notification calls. This would allow CRs to submit end use customer
information/updates to ERCOT and/or the TDSP. Is this still being considered or is this a closed issue and
the 814_28/29 dead? This is in the Ts&Cs and is expected to be
resolved for the Phase II of the ERCOT time frame. |
In progress |
1/11 |
Overpayments: Negative values at the invoice level in the 820 are
allowed as long as the total remittance amount is still a positive deposit
amount to the bank. Other questions on over payments at an ESIID
level? Credit balance on an ESIID? Currently the implementation guide does not provide
balances in the 820 – this may be a gap that should be discussed – over
payments need to be communicated to the correct MP. |
|
1/24 |
Muni/Coop Invoice |
In progress |
1/31 |
Submit a Protocol change for Move-in Un-executeable (not
for overbooking) |
|
Items Closed
at this Meeting: |
|
|
1/11 |
Charges Not Associated with Consumption after
the customer has switched away: (Late Payment Charges or Service Order charges) After the ESI ID has switched to a new REP. How will the TDSP810 reference back to the
867 –suggestion to make the 867 reference field conditional for cases when
the late charge shows up 2 months after the customer has switched. |
Will be combined with the change control #53 |
1/31 |
Additional kWh, reading will not match consumption |
Ref Change control #50, Not approved |
|
|
|
|
|
|
|
|
|