TX SET Meeting
November 1-2, 2000
*Last chance for changes
to be included in the next version of the implementation guides is November 8th.
Statement wanted by
AC/ERCOT
We want the list of
elements needed for the statement, we need to know which data elements will be
included in the statement.
AC will provide the
structure and data elements.
There was push-back from
SET on developing the “statements” for the QSE. SET recommends that ERCOT send a survey to the 25 QSEs so we can
find out if any QSEs are planning/expecting to use EDI for the
“statements.” Mike will report back on
this issue.
In the 867_02, two
multipliers are needed for un-metered services – discussion on the QTY loop,
make the “multiplier” comments clearer.
The first one is the number of devices and the second is the consumption
per device, they are multiplied together and the total consumption is shown in
QTY02.
867 Questions –
Non-interval question:
The data aggregation
group (AC/ERCOT) expects the consumption to be summarized at the ESI ID
level. They propose use of the SU loop for non-interval summarized
data. Then the TDSP would have to send
a detail (meter) loop and summary loop even if there is only one meter on the
ESI ID. ERCOT does not have the storage
capacity to AC will submit a change control for this. The TDSP will have to send this additional loop for every 867_03.
For un-metered services
AC believes that the detail loop by device type will meet ERCOT’s needs, won’t
need to have an additional Summary loop for un-metered services consumption on
867_03.
In the 867_03 AC/ERCOT
wants the “time” for start and stop to be included. AC says the processing time will be significantly impacted when
doing data aggregation because of the DTM~196 for the ending of each interval,
they have to go down into the transaction to find the exact end time.
Error code “date does not
match” error – they need the hours/minutes for the start time and the end time
for them to determine if there is any overlap in the consumption reported.
Only asking for this in
the 867_03 interval usage across meters.
This is only for the PTD~ loop for the intervals across intervals.
867_01 they want the
hours and minutes for the start and end times – can’t assume that midnight is
the start and end. They are going to
count through the intervals for daylight savings time and to make sure that all
intervals are reported anyway, but they want the hours and minutes reported at
the start and end times.
Standard Interconnection
Point - Add “load bus ID” in the
gray box to clarify what the standard interconnection point is used for the
814s (814_20) Service Deliver Point (SPL) – make sure they are on the data
element matrix.
SET has decided that there
is no need to have anything posted that is not the MOST current version. All documents will be posted by Mike McCarty
(via Kurt Vacula). Each document will
have the date of the document, date of the document, and version
number listed in the document name or link. All documents need to be downloadable (.rtf for the
implementation guides) – link to . R emove the “Differences LIN/AASI/BGN”
document should be removed from the website.
810_01 – Settlement Invoice/Statements
Section9.2: “The settlement Statement(s) will be made
available according to the Settlement Calendar for each Operating Day and will
be published to the Market Information System for Statement Recipients
electronically on Business Days The statement Recipient is responsible for
accessing the information from the h MIS once posted by ERCOT.”
·
ERCOT protocol
dictates that the QSE will not use EDI for statements or invoices.
810_02 (TDSP Invoice) Discussion
Johnny will write up a
change control to move the B-to-B loop past the TDSP.
·
REPs would like to
know the percentage being applied, the delinquent $ amount, total
late payment charge and (check internally to see if we need invoice number as
well?).
·
This needs to be
taken back to our companies to figure out if our rate cases or Ts& Cs will
prevail on the percentage that will be charged.
·
Use SAC05 - $
amount, SAC08 – percentage applied, SAC09 – EA (each), SAC10 – previous
balance, SAC15 – description
·
Add an additional
REF to include “Invoice Number” if we decide that we need it. Group feels that invoice number will not be
need to tie the late fee back because it will always be on the invoice 2 prior
(due to the 35 day payment window, the second invoice will have already been
issued by the time the late fee is applied).
Business
to Business Loop (includes the
Late Payment and Charge-off Allowance)
·
IT109 loop for
Business to Business charges (code B2B)
·
Add a gray box to
indicate REFs (NH, PR) and DTMs (150, 151) will not be used in the B-to-B loop.
·
The charge off
allowance will only be used in the B-to-B loop also – we will always use a “C”
(charge) in the SAC01 with a negative amount in SAC05, EA (each) will be used
in the SAC09 in the B-to-B loop.
·
The SLN in the
B-to-B loop
·
SAC08 x SAC10 = SAC05
The SAC10 will be pulled from the SAC04 (MSC027) and the rate
(percentage) will be shown in the SAC08, the charge-off amount will be shown as
a negative amount.
·
For Discretionary
(service order) charges – Add a gray box that says that for discretionary
service orders we will only use the SAC01, SAC03, SAC04, SAC05 and SAC15. – “Do
not use SAC08, SAC09, SAC10 for discretionary service charges”
·
Presented the case of ESI ID vs. Customer based tracking
for Pilot, everyone agreed to use the ESI ID except for the Consumer
groups. Positions were sent to Connie
Corona, this will be taken to the PUC that ESI ID was preferred but there was
concern about not being tracked by Customer.
·
Has PIC discussed the P1-4 transactions? From TDSP perspective they don’t want to do
the P1-4 transactions, we need to figure out what kinds of solutions are being
discussed.
·
Next meeting, Dec. 6th.
·
Group was brought under the PUC at the first Technical
Workshop. Consensus was met on the
issue of 3rdParty Administrator and one-test plan. ERCOT is not in agreement now.
·
Covered guiding principles, scope, assumptions, standard
nomenclature (9 categories). No
consensus was reached on the issue of TDSP Web Portal vs. EDI 650s.
·
Construction service orders are out-of-scope and will
not be covered by this group.
Transport
Protocol Meeting
·
GISB EDM will be used for Point-to-Point
transactions. FTP with PGP is being
proposed for ERCOT transactions.
·
May use the PA strawman test plan for GISB EDM (Version
1.4) testing for TX.
·
Conference call this Friday to discuss further.
·
Trading Partner
Agreements are needed for 820s.
Discretionary charges will be held by the TDSP until the next billing
cycle. Late fees and Charge-off
Allowances will be at the ESI ID level – a Business-to-business loop was added
to accommodate these charge types.
·
814_28 discussion of which pieces of information would
be sent, and that the transaction could go to and from the REP/TDSPs. Two-way information is wanted by the
TDSPs. The sharing of information
between TDSP and REP was discussed.
·
The TDSP and REP can agree to support option #1 in a
bi-lateral agreement outside of what is required by Ts&Cs.
·
For information required on the 814 to meet the needs of
option #2 and #3.
·
Reporting issues for the TDSP on outage/trouble calls
back to the REPs. Need to define
standardized nomenclature for outage systems.
·
This will further be discussed at the next Ts&Cs
meeting on Nov 16th.
REP Certification Issue
·
How do we handle a defaulting REP, the case where a
defaulting REP transfers the wires charges to the POLR to handle the billing
function. How can we do this
logistically without handling this as a manual process on an exception basis –
TDSP would have to have a way to indicate that the ESI ID has both an active REP
and active POLR. TDSP would send the
867_03 to the REP and POLR and send the 810_02 to the POLR.
Map
Description Documents
In the date column, we will add a disclaimer
to note that the “dates are estimates, refer to Protocols for exact timing”
Update
from PUC Discussion 11/1
Modification on Change control #6 – Drop to
POLR
·
ERCOT/AC has added a “Premise Type” code to the system
for the 814_04 and 814_05, SET needs to add the field to the implementation
guides (814_04, 814_05) used to determine which POLR should be active for that
ESI ID – current POLR rule will allow for an ESI ID to have as many as three
POLRs assigned to the ESI ID. TDSP cost
of service rule definition for the different types of customers – the outcome
from the PUC meeting (3 customer classes):
·
Residential (includes guardlights that are associated
with a residential),
·
Small Non-Residential (used for determining the POLR
<1MW (2 out of the previous 12 months over 1MW would put the customer in the
large non-residential),
·
Large Non-residential (2 out of the previous 12 months
>1MW).
·
20 kw cut-off for the Price to Beat will not be used
when determining the POLR.
·
TDSPs have to assign each premise a rate class. How will the TDSP get enough info to
determine the business type so it can report by SIC code to the Federal Reserve?
·
Critical Care Flag – PUC realizes that there is still a
gap there, Customer Protection this will try to address this in the next filing
(December). This is still being debated
internally at the PUC. Ultimately the TDSP needs to qualify the customer (like
today) and maintain the database on Critical Care, but how will the TDSP be
able to maintain the database after Choice.
The PUC feels that the TDSP would be responsible for “knowing” the
critical status of hospitals, clinics, airports, dialysis center, etc. – REP
may need to be responsible for notifying the TDSP in some of the less obvious
cases.
·
PUC will maintain a list of certified REPS on the PUC
website – certified by the TDSP and ERCOT.
REPS will send a letter to PUC, REP will send a letter to notify them o
f certification status.
·
Postcards will not be sent on CSA
·
Change Control #5
–
Reject
Reason Codes – sync up 814 implementation guides with protocols –
Sharon/Jill/Larry
This
should be completed by Monday 11/6 – will be further discussed on 11/8
conference call.
·
Change Control #7 –
First
two points point– approved by SET
Fourth
point “REF position 030= “WI”….” – has been removed because there will not be a
postcard sent in this case anyway.
This has been removed from Change Control #7: Third point “If a TDSP
sends usage data to ERCOT for meters that are to be polled by ERCOT this data
should be rejected and not sent into the settlement process. A rejection reason for this is needed on the
824_02” Requires more research - will be addressed at
the next conference call – STILL OUTSTANDING James Cohea conference call: ·
Culmination of multiple meters, the data is only
created in data aggregation and ERCOT will create the 867 and it will be sent
out to the TDSP and CR. So the TDSP will have to be able to handle an
INCOMING 867_03 daily for meters that are polled by ERCOT. The TDSP would then calculate associated
charges based on the incoming 867_03 and would send the 810_02 to the CR. ERCOT does not want to let “ERCOT polled”
info pass through lodestar internally, so the 867_03 will need to be able to
reject…. ·
ERCOT will poll the meter daily and provide the data
to the TDSP (via 867_03), the TDSP would have to store that info until the end
of the month/billing period, then the TDSP would create the 867_03 and send
it to ERCOT and on to the REP, and create the 810_02 and send it to directly
to the REP. ·
Additional issue around a Non-Opt-in where the REP of
record and the TDSP for that ESI ID would both be the Non-Opt-in ·
Load ESI Ids will be sent to the REP and TDSP
on that ESI ID, 867_03 will be sent to TDSP and CR ·
Suggestion: The 867_03
that ERCOT is creating may not need to be sent to the CR daily, the CR would
wait until the TDSP generated monthly 867_03. THIS NEEDS TO BE TAKEN BACK TO THE
MARKET PARTICIPANT COMPANIES. |
·
Change Control #10 –
Need to communicate a data change to the
current REP if a switch request speeds the timeline for the REP to lose the
customer. (Mike will update change control form to include the case when a
move-in and move-out overlap.)
If
the Drop to POLR cannot be CANCELLED until after the Customer Review Period has
passed . The Current REP and the TDSP
will need to be notified of the earlier date (814_12) with a code to indicate
the real end date and the reason code indicating that the timeline has been
moved up.
Need to cancel a Drop to POLR request or
Switch request as “Not First In” if the other request is accepted.
Requires more research – will be
addressed at the next conference call, we need David to be present on the next
conference call.
Add a new rejection reason for the 8_05 with
“Not First In” if the receipt of the 814_04 Switch Notification Response from
the TDSP results in the immediate cancellation of the Switch request.
·
SET will add the PIF – “POLR in First” code which
is used when the switch date will not happen
before the end of the customer review period.
·
Change Control #13 –
Add REF segment to the PTD loop for
unmetered devices for rate and rate subclass.
Approved.
·
Change Control #14 –
Include “Late payment charge” and the
“Charge-off allowance” at the ESI ID level and the addition of the
Business-to-business loop.
Approved.
·
Change Control #15 –
Change the usage to “Must Use” on the BGN07
on all 814s. Add the same in the 867.
Approved.
·
Change Control #16 –
Add DTM03 (time) as a required field to
DTM~150 and DTM~151 for PTD~PP.
Delay until we have time to review and
study. Will be discussed at Wednesday
conference call.
·
Change Control #17 –
Add the metered services summary loop
(PTD01=SU), as defined for 867_01 Conversion historical Usage, to the 867_03
Monthly Usage.
Delay until we have time to review and
study. Will be discussed at Wednesday
conference call.
·
Change Control #18 –
Add at lease one (potentially three) time of
use code to MEA07 for the metered services summary loop (PTD01=SU) to super
peak time of use. Suggested codes: 63, 64, 65, 71(Summer Super On-peak)
Approved, specific codes will be discussed
at the conference call next week.
XML Update from
Andersen
·
For each transaction type (ex. 814_01, etc.) there are five documents have been created
·
XML Schema, Schema Diagram, Valid Values Report
(includes possible codes), Mapping Specifications, Sample (Examples)
·
This deliverable will be due to ERCOT (from Andersen) by
11/13. Mike McCarty will send an email
to SET notifying market participants that it is available.
·
The Andersen version of
XML uses BizTalk Schema
·
Richard Howard had previously reported that the
“Commercial Operations for XML” document was published on 10/1 – however this
document is unknown to the Andersen XML document owner . Not sure where this document is published.
Need for a New
867 – 867_05? - Diedra Mallott
(614.264.2874) from Data Aggregation
·
Used by aggregation to report the distribution loss
factors in the day ahead market (96 loss factors are needed by ERCOT for each
day). They want one factor per interval
per end time.
·
Distribution loss factors are filed and vary on a yearly
basis – SET feels that there is no need to send this for each interval if the
factor will not change.
·
ERCOT calculates distribution loss factors internally
for TDSPs that submit the distribution loss codes annually. For those TDSPs that want to calculate its
own loss factors daily, ERCOT asks that we add an optional field in each
interval loop in the 867 to send this data.
·
This data would have to be sent on a separate 867
(possibly 867_05) which will be sent a day ahead for a particular ESI IDs consumption
867_03. Anderson does not want this
data send this at the ESI ID level, however for this to function in our current
EDI format it would require to be reported at the ESI ID level.
·
Suggestion: The
TDSP/Muni/Coop could send this data to ERCOT in some other format.
·
If this is not specifically noted in protocols that this
be addressed with a SET transaction, then SET feels that this is out of
scope. If this is specifically included
in protocol then, ERCOT/AC needs to submit a change control that outlines this
issue in detail.
Customer Contact Information
·
We need add the customer data elements (name, phone
number(2nd optional), drivers license (optional), ss#(optional))
·
The TDSP will not be able to update customer contact
info, or send any customer info back to the REP – transactions in this
direction for this purpose are not included Ts&Cs does not dictate this.
·
For initial transfer of customer information – REPs will
use the 814_01, 814_03, 814_16
·
For customer data updates a REP will use the 814_26/27 – change the Ad-hoc
Historical Usage transaction to include the data elements required for the
Customer Contact Info.
·
If a REP wants to keep the premise when a customer
moves-out, then a new customer moves-in, the 814_28 would be sent to
update the customer info with the new customer info.
·
A change control
form needs to be completed to add data elements to the 814_01, 03, 16 - Heidi
·
A new change request
to add the 814_26/27 transaction - Jill
·
Third option: change
the allowable direction for the 814_20/21 and include the customer contact
info.
Review of Manual Transactions Appendix
·
Rescind Switch will be
performed through the web portal. ERCOT
has designated a dispute entry page for registration and one of the possible
types of disputes is a rescind switch
· Outage reporting is currently a matter before the PUCT. The processes required and mechanisms involved are pending the Project 22187 rulemaking
· Construction Services and Service Order processes are currently a matter before the PUCT. The process requires and mechanisms involved are pending the Project 2187 rulemaking Temporary Disconnect
· Requests Missing Consumption for the Premise will be processed via email or phone call to the TDSP
Other
·
Updates: Monday 13th, Diana and Kim will
work on the examples and implementation guides to be handed over to ERCOT for
version control and version 1.2 release.
Release date of ______
·
On a move-in when the premise is de-energized, the TDSP
will send the 867_04 because there is not enough info to send an 867_03. This is an exception.
·
Send change controls request to Mike McCarty (not
Larry). The approved change controls
are on the website.
Attachments:
Meeting Minutes 11/1-2/00
Assignments:
·
Update the Market
Data Flow document (Ray’s) -Reliant
will do this.
·
Mike McCarty will
write up the change control form for 867_01 and 03 issues. Market participants need to take this issue
back to our internal MV90 people.
·
TXU will re-do all
of the 867 and 814 examples to standardize the right hand column for the descriptions. We want to be consistent across all
examples.
·
Need to add a column
to the version control log (on the website) that will display the date that
ERCOT has implemented each change in its system. – Mike McCarty
·
Change control to
remove the code for change (BPT~04) – Reliant will write-up this change
control.
·
Change control on the 867_03 and 867_04 for the BPT09
field that will allow for an additional tracking number (potentially customer
account number) – TXU will write-up this change control
·
Clean up website –
update the Conversion transactions, fix “Scenario Names” Document presentation
on site – Mike
·
Appendices in a
matrix format – BJ
Implementation Guides
that have been base-lined and will be distributed by the transaction set owner:
|
IG’s |
Examples |
Matrix |
Map
Descriptions |
Flows |
Transaction
Scenario Names |
Pending
Change Controls |
|
814 (1-27) |
V 1.1 |
V 1.0 |
V 1.1 |
review |
review |
1.1 |
1-10, 15 |
|
867 (1-4) |
V 1.1 |
V 1.0 |
V 1.1 |
review |
review |
1.1 |
11-13 |
|
810 (1-2) |
V 1.0 |
V 1.0 |
V 1.0 |
V 1.0 |
V 1.0 |
1.0 |
14 |
|
820 (2) |
V 1.0 |
V 1.0 |
V 1.0 |
V 1.0 |
V 1.0 |
1.0 |
N |
|
824 (1) |
V 1.0 |
V 1.0 |
V 1.0 |
V 1.0 |
V 1.0 |
1.0 |
N |
|
650 |
pending |
|
|
|
|
|
|
|
Recommendations Document |
V 1.0 - 11/10 |
|
||||||
Pilot Transactions |
PIC |
|
||||||
Settlement Statements |
ERCOT decision |
|
||||||
·
820_01 (QSE Payment)
– ON HOLD
·
814_28/29 Customer
Maintenance (this is for REPs that will not handle service calls/outage
notification calls)
·
Tentative Meeting
November 15-16, CANCELLED.
·
Service Order
Meeting - Nov 13-15 hosted by TXU in Dallas. Monday 1-7, Tuesday 8-5, Wednesday
8-5.
·
Conference call for
Version 1.2 discussion - November 16th @ 2:00-4:00 – ERCOT will set
up the conference bridge.
·
Market Readiness
Series is on Monday - Tuesday December 4-5, in Austin.
·
Tentative Meeting
December 6-7, Wednesday @10:00, Thurs 8:30-5:00, hosted by TNMP in Austin. Location to be determined.
Attendees:
Randy
Brannon TXU Diana
Rehfeldt TNMP
Debbie
McKeever TXU Rohni Patel Reliant
Jill
Prince TXU Heidi
Schrab Reliant
BJ
Flowers TXU Jeanette
Harris Reliant
Mike
McCarty ERCOT Bruce White TXU
Dave
Robeson Entergy Johnny Robertson TXU
Susan
Neel Reliant Dave Bynoe Shell
Joe
Nett US
Power Solutions Ward Camp US Power Solutions
Fred
Plett Logica Moraima Rosado AC