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?

 

Life Cycle Tracking on 824 - TABLED

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.

 

Service Orders

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

 

Outages

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.

 

ERCOT Polled Meters – Change Control #?? –

THIS HAS NOT BEEN SUBMITTED YET, BUT IS CONSIDERED EMERGENCY

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

 

Un-metered usage reporting  -

ERCOT NEEDS TO RESPOND TO THIS ISSUE

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

 

 


Drop to TDSP during Pilot

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. 

 

Mass Change at Customer Choice

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.

 

Update Municipal/Coop Invoice

·         Need 4-6 people to discuss the Muni/Coop invoice draft

 

Questions@texaschoiceprogram - Outstanding Issues

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.

 

Open Issues

·         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

·         Pilot CSV File  - It was decided at the 3/1 PIWG meeting not to make any changes to the CSV file.  The REPs and TDSPs involved felt it was working okay without any changes. 

·         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