TX SET Meeting

November 1-2, 2000

 

Agenda

*Last chance for changes to be included in the next version of the implementation guides is November 8th.

 

810 Settlements

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.

 

867 Example Questions

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.

 

Website Comments

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

Protocol Chapter 9 – Settlements, Section 9.2 – Statement, Section - 9.3 Invoice

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. 

Late Payments

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

 

Updates from Other Teams

PIC

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

 

Test Plan Team

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

 

Service Orders Meeting

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

 

Technical Workshop

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

 

Outage Workshop

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

 

RUG

·        Load Profiling presentation, voted and agreed on

·        ERCOT presented a gap analysis, gray boxes in the protocols documents – final protocols are not really final

·        POLR has the option to request historical usage, gray-boxed item – not sure what the design is or how this will end up.

·        Next meeting – not yet scheduled

 

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 Forms

Review change control requests

·        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

 

Document Versions Status

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)

 

Next Meetings

·        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