TX SET

April 10-11, 2001 Meeting

Minutes

 

 

Correction to Meeting minutes of  3/11 and 3/12

 

·         Open issues list 3/21 concerning 814_20 for new customer.  It stated that CR will send request to set meter in 650.  This is incorrect.  The CR will send an 814_03 and this will clue the TDSP to set a meter if that is what is needed.

 

Change Controls

 

2001-83

·         Shirley Whyte discussed change controls she introduced (2001-83).  We will discuss in detail in the future.

Ø       Item 2 – PTD loops should be sorted by logical PTD loop structure – would help immensely.

Ø       Discussion of Item 7a (second item 7) re: Channels (and 34/36):  There was discussion whether anybody needed channel information.  We need to ask if we are always sending channel numbers if there are only one channel for kWh, one for kW.  If there is more than one channel measuring the same information (kWh, for example), we are supposed to send channel # according to protocol.  Heidi to take the issue to RMS to determine if there is a business reason to send channel information. 

Ø       Item 18 – For ERCOT polled meters, need to have S in PP to identify it as a resource ID.  Jill is to write up the procedure.  Jill Prince says ERCOT will not pass this through when it is a resource meter.

Ø       Item 21 – Discussion of QTY01 use of AO and 92.  AO is for a verified reading – meter reading is correct (second trip).  Need to put in clarifying information in gray box.  Need to verify how we are using these codes.

Ø       Item 38/39 – Shirley Whyte concern that without a meter number for subtractive loop, that most systems will overwrite previous information because there is no information distinguishing from previous loops.  It would be best to provide a meter number, even if it is made up.   Is it better to simply provide the ERCOT data and ignore the master meter and subtractive meter information?  Jill and Shirley to write up a detailed discussion and bring to RMS.

Ø       This should be broken into subjects – referencing channeling, subtract metering, gray box cleanup – three change controls.

 

Other

 

·         867_04 will be changed Add gray box on REF=TN.  Reword from  final usage to initial usage – Roshni to write up change control.

 

814_PC/PD Alternate

 

·         Shell won’t be able to handle 814_PCs and 814_PDs at pilot open.  They went to the PUC and asked about penalties.  The PUC asked PIWG to see if a workaround is possible. The PIWG has charged SET to define the alternative process.
·         This will probably be another file format of some sort.  Shell’s system can’t handle 814_PC and 814_PD but can generate a CSV.  The TDSPs said that the coding for an 814_PC or 814_PD has already been done, and to code an alternate 6 weeks from pilot is a major issue.
·         Shell will do GISB EDI, eventually, but it is an issue of timing.  Shell might be ready for 3rd or 4th quarter.  PCs and PDs are pilot only.
·         Shell has developed an alternate format.  Any TDSP not wanting to do this should be at PIWG May 1st to argue against it. Whether or not an alternate is a good idea is a PIC issue, not a SET issue.  The TDSPs say they have no time to code for something else and do not support an alternate, but this is not the forum.  Endorsement of an alternate for PIC discussion doesn’t not translate into support for an alternate.  There was discussion about other, non-electronic means such as an e-mail or fax with an Excel spreadsheet.  This would be better than a CSV file.  Phone calls may not be best due to the need for an audit trail, but e-mails or faxes would do.  Other CRs might step up wanting to do the same thing. 
·         Discussion ensued concerning holding on to the 814_PCs and 814_PDs until Shell was ready, but there is a liability issue there.
·         This would be an issue for TX Test as well.
·         Shell would like to send on a weekly basis but could send on a nightly basis.  Shell needs to put work into process flow.  An e-mail back saying “we have it” could be appropriate.  Shell will send the Excel spreadsheet via e-mail, batched weekly, but more often if they get a bunch, and will expect a response.  Discussion took place about Shell only including the changes that need to be made, and that was rejected – it has to follow the EDI protocol – supplying all information that the equivalent EDI transaction requires.  There was discussion by Exolink that they might take the Excel spreadsheet into a CSV file, put it into their system, and then send back an EDI 814_PD.  Could Shell handle the EDI in return?  This would be one less manual work-around step for the TDSPs.
·         Shell will re-send out its proposal (to Heidi Schrab) including format, transport mechanisms (both ways), timing issues, and a complete process flow map.  And it will be discussed at our next (non-change control) conference call.  Shell will send out the proposal by next Tuesday, April 17th.
 
814_01
 
·         Some MPs are not populating State Code in notification loop.  They are providing City, Zip, but not State.  Shirley Whyte advocating a change control to change gray box because there is confusion whether it is required.  There is a problem cropping up.  This will crop up whenever N1 and then the code N1 within the N1 exists.  

 

867 Loop Usage Bulletin

 
·         ITPTA, Shirley White, as a result of confusion, wrote up a PTD definition and use description.  She points out that the PTD loops cannot be used in isolation, but in pairs.  This will be sent out imminently for comment.  Reporting of generation meters has to be added to this since there is a separate PP loop for generation.  Jill and Shirley to work on it.

 

Review the RMS Procedures Draft

 

Issue 1

·         Added 15-1.5.3 Notification of TDSP of move-out.  When ERCOT receives a Move-out request and a CR is not associated with the ESI ID, it will forward the SET 814_24 or its MIS equivalent to the TDSP.  ERCOT will process Move-Out requests up to six times a day.  The timing of ERCOT processing will be made available prior to the Customer Choice Pilot.

Ø       This was in our flows.  It is simply a protocols gap.

Ø       After discussion, it was decided to take out the “and a CR is not associated with the ESI ID”.

·         Added 15.1.5.4 Response from TDSP to Move-Out Request

Ø       The language got modified here so that the TDSP sends (1) ESI ID and (6) Move-out date (if different than requested date).  This information shall be transmitted in accordance with SET 814_25.

·         ERCOT Protocols need to document the 814_13 received from the TDSP for move-in or move-out date changes will be forwarded by ERCOT to CR.

·         Move-in or move-out data change (15.1.5.7).  The process change proposed here is that if the change date requested by the customer is earlier than the previously requested date, the TDSP will respond with the Date Change Response within “x” hours in accordance with the SET 814_13 if the date change cannot be accommodated.   If the change date requested by the Customer is later than the previously requested date, the TDSP will respond with the Date Change Response within “y”  business days in accordance with SET 814_13.  The “x” and the “y” need to be supplied by the TDSPs after checking what is possible.  There was discussion about allowing 2 days for all notifications from the TDSP because that’s what is currently stated by protocols.  After discussion, it was decided to take out the timing issue out of it.

·         Same Day / Next Day Move-ins (15.1.4.1, 15.1.4.3-6).  There was a discussion about how to handle expedited move-ins.  This is a bigger issue than RMS.  This may need to be a workshop / meeting.  It could be by phone call by the customer to the TDSP or the CR to make it happen, with follow-up EDI or MIS equivalent .  The EDI codes don’t yet exist for follow-ups for a move-in that’s already happened. 

·         Move-in unexecutable – leave it for a workshop

·         Issue 5: Premise Information when Meter Info Unavailable – Going to a workshop.

·         Issue 6: Mass Customer List: – Cary Reed will bring it forward from something Don Bender of AEP has used.

 

 

Move-in/out during Pilot – Pseudo Move-in

 

·         During Pilot, TDSPs are also CRs.  For 95% of customers, TDSPs would  have to do move-in’s, move-outs on 95%, etc.  Legacy systems weren’t designed to handle this.  There have been several meetings with ERCOT and TDSPs to create workarounds.

·         If customer calls and wants to be reverted to TDSP, TDSP will take information from customer, then call CR and get the CR to initiate a drop to POLR.

·         A pseudo-move in is a file format worked out between TDSPs and ERCOT to say, here are all of our move-ins today.  This will be new ESI IDs, and then a file to have ERCOT knows it is energized.  The pseudo-move in process won’t be ready until August.  If the customer then wants to be in pilot, on June 1st, there is a problem because pseudo move-in won’t be ready.  For the 2 months, there was a discussion about not letting the customer participate or creating a work-around for the work-around.  There is a potential issue here.

 

 

Rejects at ERCOT

 

·         What would be the appropriate error code for the case during Pilot in which ERCOT sends an 814_03 to the TDSP, but there is no 814_14 PA-PB set of transactions?  Would it be the A83, Invalid or Unauthorized Action?  It seems incorrect to return "Invalid ESI-ID".  We should find out what ERCOT has programmed to.  It may be an A13.  We’re waiting for an answer.  Shirley Whyteand Mike McCarty will follow through.

·         In theory ERCOT would have rejected the 814_01 with the 814_02 – ESI ID not eligible.

 

Muni – Coop Invoice

 

·         Johnny Robertson has tried a few times to contact municipal / cooperative personnel.  We haven’t heard.  We would like to go to baseline.  We do have a draft.  The next step is to go to RMS with the draft, and RMS can say, here it is, TX SET needs feedback, and will give them a time frame.  It was agreed that we would go to RMS.

 

BGN in the 814_08

 

·         We might need to add some language to the gray box in the BGN06 of the 814_08 Cancel Switch Request. 

 

1.  Customer chooses New CR

2.  New CR enters the 814_01 (BGN02: reference number ABC)

3.  ERCOT sends Current CR the 814_06 Drop due to Switch (BGN02: reference number 123, BGN06: reference number ABC)

4.  Customer claims slamming - tells ERCOT

5.  ERCOT sends Current CR an 814_08 Cancel Switch Request (BGN02: reference number 456, BGN06: reference ABC)

OR

6.  ERCOT sends Current CR an 814_08 Cancel Switch Request (BGN02: reference number 456, BGN06: reference 123)

 

 

 

Shouldn't the BGN06 reference the transaction that should be cancelled?    Since the Current CR never received the 814_01, 814_10 or 814_24 we need to show some reference to the 814_06 in the gray box.

 

gray box on 814_08, BGN06 reads:

"Refers to the BGN02 of the...

... Enrollment Request (814_01),

... Drop to POLR Request (814_10),

... Move Out Request (814_24). 

 

This number will be tracked in the BGN06 through the life-cycle of the respective process."

 

·         We need to find out what ERCOT is doing.  Heidi is going to send the issue to Mike McCarty to find out which ERCOT is doing.  We are hoping that ERCOT is using ABC.

 


 

867_01 Usage Corrections

 

·         TDSP billing systems include functionality for correction of current and prior period usage history.  This is a requirement of most utility information systems, as 100% accuracy in the gathering and reporting of meter readings is not attainable.  This means that, despite best efforts, X% of the usage history information that will be loaded into the ERCOT database during conversion will be incorrect.

·         TDSPs want to keep sending 867_01’s until they are correct.  ERCOT would prefer 867_03’s to correct history.  This is because the environment for initial load and for production are different – they don’t want to maintain staffs for initial load.

·         Mike McCarty taking back to ERCOT to follow through.  The preference from TDSPs is to use the 867_01.

 

Move-In – Move-Out Process

·         Christine Melro sent around the following process, and asked if it were correct:

 

PILOT MOVE-OUT / MOVE-IN SCENARIO (INELIGIBLE ESI ID AT NEW PREMISE):

John Smith enrolls for Pilot with CR 1 on March 1st in TDSP A's territory.  On July 29th, John notifies CR 1 that he will be moving on September 17th to another premise in TSDP A's territory.  He would like to remain with CR 1 and have them make all necessary arrangements for his move-out and his move-in.  The new premise is not yet eligible to participate in Pilot being that the last tenants opted not to participate.  If the Pilot is not full on July 29th, my assumptions for the transactions are as follows (dates are approximated):

 

July 29th

(1)  CR 1 sends an 814_24 (Move-Out Request) to ERCOT (which is a pass through to TDSP A)

(2) CR 1 sends an 814_PA to TDSP A with the new premise's ESI ID to make the new ESI ID eligible for Pilot

July 31st

(1)     TDSP A receives the 814_24, processes the move-out, and sends back an 814_25 (Move-Out Response) to ERCOT (which is a pass through to CR 1)

(2)     TDSP A sends an 814_20 to ERCOT with the eligibility date of July 29th to make the new ESI ID eligible for Pilot

`      (3)   TDSP sends out 814_PB. (this was added at the SET meeting).

 

August 2nd

(1)     CR 1 receives the 814_25 (Move-Out Response)

(1)     CR 1 sends an 814_16 (Move-In Request) to ERCOT (which is a pass through to TDSP A via the 814_03 unless ERCOT rejects the request with an 814_17 (Move-In Reject)

August 3rd

(1)     TDSP A sends an 814_04 to ERCOT in response to the 814_03

August 4th

(1)  ERCOT sends an 814_05 to CR 1 as a pass through of the 814_04

 

*At some point, the 814_PC will be submitted by CR 1 to TDSP A to update customer information at the move-in premise.

 

 

 

·         With the italicized addition under July 31st, the process is correct.

·         Check with ERCOT that, after June 1st, is current date equal eligibility date.  Are they checking the eligibility date? If a date is sent in that is prior to the current date, will it get rejected?  This was flagged by the use of July 29th in the July 31st step.

·         If for some reason everybody is committed but the 867_03 doesn’t get in on time, what happens?  Shirley and Mike to follow up.

 

810_02 Discretionary Charges

 

·         How will the REP know which customer the Outstanding Discretionary Charge after Final Invoice is for?  We do not require service period dates, which is the only thing that can be used to distinguish a customer at the ESI ID.

 

For example:

Customer A is with REP 1

Customer A moves out

Customer B moves in and chooses REP1

Customer B moves out

Customer C moves in and chooses REP1

TDSP sends Outstanding Discretionary Charge after Final Invoice... who is it for?

Also, are there any rules around how long a TDSP has to send such an invoice... obviously if too much time goes by, it would be very difficult for the REP to collect.

Does this invoice fall into the same parameters as others in regards to being due in 35 days?

 

·         Discretionary charges will come in on a cycle bill, normally.  But if charges come into after the final bill, how will accounting be done?  The TDSP will know what service order it is tied to, and therefore what customer it belonged to.

·         It was discussed that there may be no practical way to handle this with the EDI transactions.  A phone call can straighten this out.

·         Kim Wall would like to submit a change control to remove any language about discretionary charges after final bill.

·         There will be a development of a change control not to remove discretionary charges after final bill, but to instead develop a special code for BIG07 or BIG08 for discretionary charges after final bill and for final bill.

·         Shirley Whyte pointed out that the examples are not correct and need work.  There was discussion about a Version 1.3a just to fix the examples, not the coding (unless somebody messed up due to a bad example).  The late payment charges were pulled out into a separate 810 going to version 1.3 from 1.2, but the examples didn’t change along with the substantive change.  There was push back about the idea of a Version 1.3, even if there is no coding change, because systems people will go through line by line and won’t believe there were no coding changes.

·         Mike McCarty offered to put up “corrected examples” for 810_02 posted on web site right next to 810_02, with a red flag.  The 810 is documented, already, in a change control.  We need to add a cover page to say this is corrected examples for 810_02.  Kim Wall assumed responsibility.

·         We could do this for 867’s as well.  The 867 examples will be done by Jill and Shirley Whyte.

 

12-Month History - Premise or Customer?

 

·         The customer protection rules require that the Historical Usage be for the customer (i.e., not the premise).  But the TDSP may not necessarily know if the customer has or has not moved.  What are the TDSPs planning to send...  customer history or premise history?  All TDSPs are sending premise history.

·         There is a conflict between T’s & C’s and customer protection rules.  TDSPs will send 12 months history regardless of customer – i.e., premise history.  It might be worth adding a gray box that the TDSPs will be sending premise history when available.  Kim Wall to submit this change control.

 

Data Element Matrix

 

·         Roshni and Kyle will review the data element matrix to ensure that it is up to date.

 

Mass Customer Lists

·         Per Customer Protection, section titled “Privacy of Customer Information” for all customers eligible for price to beat shall be included on the mass customer list – Name, billing address, rate classification, monthly usage for the most recent 12-month period, meter type, and account number or ESI ID.  Maybe a csv format.  Issue discussed RMS, AEP will provide starting point document.

·         Cary Reed already sent a copy to Heidi, but in Heidi’s transition to Green Mountain Power, it got lost, and has been re-sent.  So it will be brought up at the next meeting.

 

Version 1.3

 

·         Mike McCarty asked everybody to call back home and inform them that Version 1.3 of TX SET EDI is baseline and is what will be used for pilot.  Some people were apparently confused about that and wanted to use different, older versions.  Version 1.3 will.

 

 

Permits

 

·         On the last patch list, there was an item for the 814_04, requesting the addition of the code PRM to the 1P.  It did not make it to version 1.3. 

·         Update from the Permit workshop on 4/5.  Document and present “during Pilot” solution and “Choice” solution will be presented to RMS.   The REPS and TDSPS agreed that the TDSPs will hold the orders.  Entergy voted against, TNMP abstained, SPS not there.

·         TDSPs can send back complete unexecutable. During pilot, if you choose to use 650’s for service orders, TDSPs can send back a 650 complete unexecutable because you need a permit.  You need to develop a workaround to support 814’s during pilot.  There is nothing in an 814 dealing with permits.  Every time you haver a move-in, you need a permit in some parts of TX.    Therefore, since the 814’s can’t handle the permit issue, phone calls or other means need to be employed.

·         BJ Flowers to send a copy of the Permit workshop minutes to Fred Plett to post out with the TX SET minutes on the TX SET list serve.

 
Web Portal During Pilot

 

·         Portal will be ready for pilot, and will be ready for testing May 15th.  Shell heard some rumor that if they send something by portal, they could get an EDI response back, or vice-versa.  Mike McCarty thinks that this is incorrect.  Shell is to get clarification from Cherie Broadrick.

·         ESI ID lookup won’t be available until after conversion, and when the portal is available,  Randy Brannon to check this out further.

 

 

Zero Usage

 

·         Are TDSPs required to send an 867 for zero usage?  The unanimous response from TDSPs is yes, there will be 867’s with zero usage.  This could be a clarification made in Shirley Whyte’s draft of an introduction to the 867.  TDSPs will send in zero consumption 867s as agreed to with ERCOT for the LSE/TDSP work around.

 

814_24 Move-out

 

·         What is the difference between the 814_24 and the 814_03 in regard to the flow from ERCOT to TDSP ?  The 814_24 indicates all the way through that it flows from the CR to ERCOT, and ERCOT sends it on to the TDSP.  The 814_03 says it  is passing the move out date from ERCOT to the TDSP that was initiated by an 814_24 generated by a CR.  The following two bullets fairly answer the question:

·         The 814_24 is in support of an actual tenant move-out.  When the TDSP receives the 814_24 the TDSP knows to de-energize (remove, sleeve, power no-longer flowing, etc.) the premise and remove the association of a CR.

·         The 814_03 is in support of a Continuous Service Agreement (CSA) move-out.   A “CSA is an arrangement between the owner or controller of a leased premise and a CR wherein the CR provides service to the leased Premise between tenants so that the Premise does not experience discontinuation (energized) of electric service during vacancy”.  When ERCOT receives the 814_24 and a CSA CR exist, ERCOT will submit to the TDSP the 814_03 ( LIN~MVO, DTM~MRR (move-out date from the 814_24) to switch the premise to the CR noted in the transaction.

 

Review of Big Bang Remedy (out of PIWG meeting 3/28) in for in brackets is from the 4/6 PUC Open Meeting

 

TDSPs expressed concern about having to make their systems available on May 25th  Since the TDSP systems would not be ready.  In response to this, ERCOT has modified their original proposal.  The May 25th date is no longer operative.  This Big Bang came from an ERCOT concern that the system is built to handle 21,600 switches per day and ERCOT was concerned about a system overload and backup at the beginning of pilot.

 

New ERCOT Proposal:

 

·         CRs will send 814_01 enrollment transactions to the RA on 5/31 [in batches of 1,000] – not on 5/25.  These transactions will be processed sequentially based on who was in first.  These transactions no longer need to be sent by meter read date. [The Commissioners expressed the belief that the meter read cycle data that some utilities have stated they will be able to provide to REPs will serve to ease the big bang to some degree.  For those utilities that indicated they will be unable to provide such data, the Commission requested that this decision be re-evaluated.]

·         ERCOT will begin accepting 814_20 (change eligibility date) transactions on 4/17.  ERCOT will “hold” these transactions.  TDSPs are encouraged to send the 814_20 transactions as soon as possible.

·         ERCOT will hold all these transactions until 4/27.

·         From 4/27 to 4/30, ERCOT will have a blackout period.  During this time, TDSPs should not send any transactions to ERCOT.

·         From 4/30 to 5/6, ERCOT will process 814_20 transactions and data conversion files that were being “held”.

·         After 5/7, ERCOT will process 814_20 transactions on a day-by-day basis.

·         After 6/1, CR will continue to send 814_PA to TDSP.  From that point, CRs should wait 2 days to submit 814_01 transaction to RA to allow TDSP time to send 814_20 transaction to ERCOT.

 

CSA Discussion

 

·         There are no CSA’s during pilot.  The TDSPs will have to keep track of its own equivalents to a CSA.  If the TDSP has an agreement with a landlord, and during pilot, a tenant participates in pilot, and then moves out, the TDSP has to keep track and ensure that de-energizing does not take place because there is still a valid and binding agreement in place with the landlord.  If the CR sends a move-out, the TDSP will have to process it as a switch.

 

Other - Outstanding Issues – ERCOT will provide this info when available

 

·         When will mailboxes be ready to receive transactions? Transitional mailboxes are ready now.  TDSPs can send starting on 4/17 for change of eligibility date, 5/31 for enrollments.  These mailboxes will be in a transitional stage, not in a production environment.  It is possible that materials could be lost during cut-over to production.  It is not clear when cutover to production mailboxes will occur. 

·         What is the "processing times" schedule by transaction for ERCOT?

Ø       ERCOT will continue sweeping mailboxes, converted to XML, put into buckets (867’s in one, 814’s in another for example, and then processed.

Ø       Timing is still being worked out when the messages are being processed, in what order, and how frequently. 

 

Process

 

·         BJ Flowers to create a straw dog on TX SET procedures, and a schedule for getting it done.  A committee is to help.  The committee consists of Carie Landis, and Kim Wall.  Shell will put forth a candidate later,  This needs to address all timing issues.  

·         Meeting protocols – We get RSVPd by 5 people, 30 show up, or the opposite.  Setting up meals is a problem.  The meeting notice needs to have an RSVP schedule by a certain date to the meeting host, as it does now, but the meeting host will send out a confirmatory e-mail stating who he or she has received RSVPs from, and a note that if you didn’t send an RSVP, don’t plan on coming unless one is received within 24 hours.  If plans change, please inform the host so that meals can be properly scheduled.

 

 

Meeting schedules

 

·         It was decided that meetings would go 9-5 the first meeting day, and 8:30 – 1:00 the second day, with no lunch provided on the second day.

 

Open Issues

 

·         If a premise is de-energized, and the TDSP sends an 867_03 to ERCOT will ERCOT reject the transaction?  NO

 

 

Action Items

 

·         Heidi Schrab to send out reminder to people to find out whether TDSPs are sending channel numbers for cases in which there is one channel per measurement type (say one channel for kWh, another for kW), whether we’re using channels at all, and whether we send channel number where there is more than one channel measuring the same quantity.  Heidi also to bring business issue up to RMS.

·         Roshni Ghelani-Patel to write change control to 867_04.  It will be changed Add gray box on REF=TN.  Reword from  final usage to initial.

·         Roshni and Kyle Patrick will review the data element matrix to ensure that it is up to date.

·         Shell to develop an Excel  file format as a work-around for 814_PC and 814_PD.  TX SET to discuss 4/11/2001 and then it will go to PIC.

·         Shirley Whyte to send out imminently an explanatory paragraph for PTD definitions and use in 867s.

·         Mike McCarty and Shirley Whyte to follow up on question about 867-03 – what happens if it doesn’t show up in time,in move-in and move-out process, and to check if ERCOT is checking eligibility dates.

·         Heidi to ask Mike McCarty ERCOT’s implementation of the BGN06 of the 814_08 Cancel Switch Request.

·         Jill Prince and Shirley Whyte to work on 867 examples.

·         There was a discussion about needing to code to Version 1.3 but there were purported statements by the ITPTA that participants won’t be penalized to code beyond that to an approved change control.  Dave Robeson with Kim Wall’s help to bring this back for clarification to the ITPTA because this could cause mis-matches between market participants. 

·         ERCOT needs to set up conference call for 4/25 and 4/26, 9-11 AM CDT.  Agenda – 867 issues on first day, 814 PC and PD issues (Shell alternative) and, day 2, RMS issues that come back to us.

·         Any suggestions concerning procedures, processes, etc. should be submitted to BJ Flowers by next Wednesday, April 18th.

 

Next Meetings

 

There will be an extended conference call on 4/25 and 4/26, about 2 hours each day, to replace the meeting that was supposed to have happened on those dates.

 

5/9-10 Wednesday and Thursday 8:30 – 5:00.  Houston, hosted by Shell.  Location TBD, Shell will inform Heidi.

 

 

*Conference calls for SET Change Controls will be at 2PM on Wednesdays.

 

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.  This issue has not yet been brought to RMS.   If we are going to do 814_PC and PD type materials in open market, the intent was that this would flow through ERCOT, but ERCOT pushed back and said they don’t want it to go through ERCOT at this time.  The open issue is that changes need to take place in EDI transactions and protocols for RMS consideration.  We need to take change Change Controls 2000-22 and 2000-25 to the next level.  These change controls give a history and narrative.  They were approved in concept.  ERCOT would need to change its system to handle it.  If we get protocols changed, ERCOT will support this.  Timing is an issue.

 

This is in the Ts&Cs and is expected to be resolved for the Phase II of the ERCOT time frame. 

Needs to go to RMS.  Heidi Schrab as Chair was assigned the action to bring it to RMS.  She can reassign if necessary.  We will send the Change Controls 2000-22 and 2000-25 with some additional language to RMS as a vehicle to request action from RMS.   A change in protocol language needs to come from the RMS group, not TX SET.

1/24

Muni/Coop Invoice

In progress. 

3/21

Future method to reject 820 for bad ESI-ID, bad invoice #, etc.  The approach is to see how this goes through pilot, and then revisit the issue.

 

It was suggested that a subgroup needs to be formed to put together a change control and determines when it needs to be done by to get into a Phase II, including testing, and preparation time for participants.  It would kill people now because we’re in the middle of test, but scheduling in mid-June or so for a working group meeting might be in order.  This would be broader than just this 820 issue.

 

We can recommend to RMS a need for an 824 reject.  This is an issue for market participants to bring to bring back to their companies to see if the companies will support a line-item reject via an 824 reject mechanism.  To be discussed in our next meeting, the conference call meeting.

To be discussed in our next meeting.  Participants need to check whether they will support a line item 824 reject for bad invoice #, ESI ID, etc.

 

 

 

Items Closed at this Meeting:

 

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 ESI ID level?  Credit balance on an ESI ID?

 

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.

 

TX SET does not have a requirement to do anything with EDI for overpayments or credit balances.  Any issue on this needs to be brought to RMS by the party concerned.

1/31

Submit a Protocol change for Move-in Un-executable (not for overbooking)

Assignment made in this meeting to bring it to RMS for a workshop.

3/21

“Tax” statement from the PUC – waiting for answer from State Controller’s Office.  We do not allow tax segment at overall charge, just individual items.  Does our EDI cover state tax issues on a charge line item basis.  This should be a closed issue unless a TDSP revives it.

This is a closed issue unless a TDSP revives it.

3/21

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. Add a gray box for late payment charges or invoices not used. 

This was initially change control 2001-63, resubmitted as 2001-71, included in Version 1.3 so it is now a closed issue.  As a result of 810 review, a new change control will be developed to add codes for late payment charges and services orders not associated with consumption.

3/21

TDSP creates 814_20 for new customer to set a new ESI ID, while construction is taking place.  TDSP allows wire installs, builds customer directly.  When the customer wants a meter, TDSP needs a CR.  This is where the 814_20 comes in.  Would get request on 814_03 and would get a complete unexecutable.  CR also sends an 814_01 to ERCOT Enrollment request, and ERCOT will reject because they don’t have the meter information.  The best solution could probably be send an 814_04 without meter information, and then an 814_20 ESI ID.  This would require a modification to the 814_04.

No change control needed.  It is not a permit issue.  We are waiting for requirements to come back from RMS. RMS Subcommittee will create the process.

 

 


Attendance:

 

Name

Affiliation

Phone

E-Mail

Fred Plett

Logica

603-497-3907

Plettf@logica.com

Johnny Robertson

TXU

214-812-2712

Jrobert1@txu.com

Jill Prince

TXU

214-875-1545

Jprince1@txu.com

John Wilkinson

GE GXS

817-379-5001

John.Wilkinson@gxs.ge.com

Jason Wrubel

Shell Energy

917-452-3633

Jason.M.Wrubel@accenture.com

Paul McKinney

Shell Energy

713-241-6394

Dpmckinney@shellus.com

Jill Popelka

TXU

972-679-5064

Jill.popelka@txu.com

Randy Brannon

TXU

214-875-5182

Randybrannon@txu.com

Carrie Landis

XCEL / SPS

303-571-7310

Carrie.Landis@Xcelenergy.com

Roshni Patel

Reliant Energy

713-207-8258

 

Dave Robeson

Entergy

504-576-2571

Drobe90@Entergy.com

Sharon Polliard

AEP

918-594-2265

Spolliard@aep.com

Shirley Whyte

ITPTA

713-906-5124

Swhyte@mindspring.com

Heidi Schrab

Green Mountain Energy

512-691-6104

Heidi.schrab@greenmountain.com

Mike McCarty

ERCOT

512-248-3959

Mmccarty@ercot.com

Rita Morales

Entergy

972-538-6983

Rita.morales@exolink.com

Charles Scheffer

Reliant Energy

713-945-6630

Charlesscheffer@reliantenergy.com

Kathy D. Scott

Reliant Energy

713-945-6630

Kathy_D_Scott@ReliantEnergy.com

Dave Bynoe

Shell

713-241-0429

Rbynoe@shell.com

Kyle Patrick

Reliant

713-207-3519

Kyle_Patrick@reliantenergy.com

Nancy Hetrick

Enron

712-366-3399

Nancy.Hetrick@enron.com

Kim Wall

Green Mountain Energy

610-799-2740

Kim.Wall@greenmountain.com

Bryn Owen

Energy Services Group

781-829-9956 x318

Bowen@energyservicesgroup.net

BJ Flowers

TXU

214-812-4330

Bj.flowers@txu.com

Annette Morton

AEP

214-777-1589

Ammorton@aep.com

Ryan Goldman

Blackstone Tech

415-350-0326

Rgoldman@bstonetech.com

Darrell Hobbs

TXU

214-875-2204

Dhobbs2@txu.com