TX SET Minutes

 5/17-18

 

Finalize Minutes from 4/25-26 Meeting

 

Discuss Emergency Process for Change Controls

 

Review SET Procedures Documents (3 attachments)

 

Final approval of SET Version Control document (attachment)

 

Discuss Schedule for next release 7/1-13

 

Review SET Directives from RMS Workshops (this is not comprehensive):

Permits during Pilot will be handled with phone calls – after the TDSP receives the 814_03, it will notify CRs by phone if a permit is needed.

 

Permits for Choice will require a reason in the 814_08 Cancel; the 814_04/05 need a field for Permit required.

 

Critical Care during Pilot – will be handled in the same manner as today, TDSPs will qualify and keep records of CC status, CRs will supply the TDSP with the CC flag in the 814_01 and provide customer contact info

 

Notifications WS – for planned or emergency outages, TDSPs will contact CR designated person outages via email to list serve or directly (depends on the volume of the outage)

 

Notifications WS – for service order notification when the Customer made the request through the TDSP during Pilot, CRs will receive no prior notice of the Service Order and/or associated charges, the first indication is on the 810_02 TDSP Invoice.

 

Notifications WS – for overpayments, action item for John Hudson to report back on the current GAAP process, no definite procedure was determined.

 

Retail Metering WS – For Choice, new net loop in the 867_03.

 

Move-in/out WS – During Pilot phone calls from TDSP to CR will notify of:  move-in without meter, move-in unexecutable (wasted trip charge may be applied).  CR calls TDSP during Pilot for:  priority move-ins (same-day/next-day)

 

Move-in/out WS – For Choice, Move-in without meter changes: make meter info dependent on 814_04/05.  For Priority Move-ins add a code(s) for priority in the 814_16 move-in request.  For Move-in Unexecutable create a new transaction (???_0?) with code(s) for “completed unexecutable” and gray box language to indicate the origin of the transaction reference number for the business life cycle.

 

Move-in/out WS – A solution for, during Pilot, Move-in date changes (may result in a customer being disconnected before the requested move-out date) has not been developed.  ERCOT will need to weigh in on this to see what kind of manual tracking they can implement.   Options will be presented at RMS.

 

Move-in/out for CSAs - CSA process has not been finalized either – currently ERCOT systems will cancel a move-in if the CSA CR and the Tenant CR are the same, more work is needed.

 

Other notes from the discussion in SET:

1. Create a Transaction Notes page for every implementation guide, explaining the purpose of the guide and anything that people need to know, such as Upppercase/Lowercase issue, etc. 

2. Correct Cross Ref Number in front of 810_02 that it will not be populated for Discretionary charges after final bill and  LPC bill

3. Change all load profiles to real examples

4. Wholesale Delivery Point doesn't have a "NO" on the 814_20

5. One ESI per 814, 810, 650, 867  Multiple ESIs per 820 state in front pages.

6. Clarification of how you send a change in one piece of a service address (i.e., zip code)

7. Show examples of decimal values in meter read values and meter multipliers

8. State that there are multiple rejection reasons or status reasons

 

 

Overpayments

Will any market participants expect manual checks from a TDSPs in lieu of making adjustments to their 820s (as described in the 820 guidelines) when dealing with overpayments from CRs to TDSPs?

 

Option 1 - TDSP sends payment to the CR, either by check or by EFT.  This would require no action on the CR's part.

 

Option 2 - TDSP contacts the CR and explains the overpayment.  The CR adjusts the next 820 that they are planning to send to the TDSP for the amount of the overpayment.  An issue with this, however, is whether the CR will be provided with an Invoice Number, Cross Reference Number and ESI ID which to apply the dollar amount.

 

That brings up another issue.  We changed the 810 invoice to state that the cross reference number is not required on a Late Payment Charge invoice or an Invoice after final bill for discretionary charges. But, we never adjusted the 820 to state that the cross reference number is not required in this case.  What is required on the 820 if the CR is taking back an overpayment?

 

All TDSPs should be prepared to handle negative amounts on the 820 as a normal business practice resulting from cancel/rebills.  But, are all TDSPs prepared to handle adjustments on the 820 for overpayments?

 

RESOLUTION:  TDSPs will call the CR and will have the CR adjust the amount on the next 820 (current due minus overpayment) to the TDSP.  Which data elements will be needed by the CR to identify the error?  The TDSP will indicate the invoice in question and ESI ID – if it is a large number of corrections, the TDSP may send a spread sheet/report.  TDSPs want contact info for CRs A/P. 

 

 

Other:

 

GISB EDM

Bulletin A0038 has been recalled and revised.  It has been determined that if the GISB EDM guide is followed, there are no interoperability issues with PGP Version 6.5.2 and later releases.  No change is required for the TDTWG GISB EDM Plan, Version 1.1 or the GISB EDM Standard, Version 1.3.

 

20 Day Window

ERCOT will not automatically purge any documents during Pilot.  ERCOT will drop a report in each TDSPs area of the Portal a couple of times a week that shows outstanding responses that are 20 days or older.  Again, nothing will be purged.  ITPTA will issue a bulletin so all MPs will be aware of this.

 

ESI ID per Transaction

Want to confirm that the TX SET decision /understanding confirmed on April 26th's conference call is "All SET transactions with the exception of the 820 will only contain 1 ESI ID per transaction.” This includes all flavors of 814s, 867s, 810s, and 650s. This implies only ONE LIN loop per 814 transactions.

 

Reference Number

Can the Reference Identification (BPT09) on the 867_02 also refer to the Reference Identification (BGN02) on the 814_01. The Implementation Guide mentions the BGN06 on the 814_03 or the 814_26. The question is posed because the 814_01 also allows for the request of Historical Usage/Historical Interval usage when requesting enrollment.

 

CSA Reference Number

What is the business reasoning behind having the BNG06 of the 814_22, CSA  CR Move In Request, reference the BGN02 of the 814_24, "Move Out Request?"

­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­

­­­­­­­­­­­­­­­­­­­­­­­­­­­­­

650 Questions

1.  A CR can not request multiple service activities (meter test plus disconnect for customer requested clearance plus etc.) for one ESI-ID or Meter on one 650_01. 

 

2.  From one 650_01 the TDSP may initiate multiple internal service orders depending on how that TDSP operates

 

3.  If the TDSP initiates multiple internal service orders for the one 650_01, the TDSP is not to complete the service order back to the CR until the TDSP completes all internal service orders.

 

4.  For TDSPs that generate multiple internal service orders, these service order numbers including the completion dates of each separate internal service order are to be provided on the respective 650_02 (one completion date per TDSP internal service order).

 

5.  On the 650_02, the MEA always loops in conjunction with the DTM~MRR (MEA never loops by itself).

 

6.  The one 650_01 may be for an ESI-ID that is a multiple meter installation.

 

7.  For an ESI-ID multiple meter installation, the CR can not request a different action on the same 650_01 for different meters (meter one do a tree trimming, meter five do a disconnect for customer requested clearance, meter eight do a meter test).

 

8.  If this is a 650_01 ESI-ID multiple meter installation without additional meter information provided by the CR, the TDSP is to complete the work requested (same activity) for all meters under that ESI-ID.

 

9.  If this is a 650_01 ESI-ID multiple meter installation with specific meter information provided by the CR, the TDSP completes the work requested (same activity) for only those meters that the specific meter information has been provided for under that ESI-ID.

 

10.  For service orders requesting action for multiple meters, the TDSP will complete action (the same action) requested at each meter before responding to the CR.

 

Meter Characteristics

If there is a change in Meter Characteristics such as Meter Attributes, Meter Cycle or Number of Dials, will an initial meter read be performed?

 

Late Payment Invoice

Discuss details of the late payment invoice.  What are MPs expecting.

 

kW in 867_04

The 867_04, there is no place for the KW reading.  I do not know if this was an oversight or the CR is to assume this value is always 0.

 

867_04

There is no way to cancel an 867_04 transaction or what is the process of canceling and rebilling an initial reading?

 

Mid-Cycle Meter Change

Need understand what TDSPs will be doing for Pilot when they switch out a meter mid-cycle.  First instance is when they switch out a non-interval meter for a non-interval meter and the second instance is when they switch out a non-interval meter for an interval meter.

 

Meter Type

Need to discuss how the REF*MT is used for interval data, non-interval data, and unmetered data. (When to use KHMON, KH015, etc.)

·         Interval usage uses KH015

 

Move-in/out

There is a gap in the move-in, move-out date changes and forced move-out dates.  Subgroup from RMs has developed two options for RMS, ERCOT will have an option 3 drafted by the RMS meeting on Wed, 23rd.  More work on the move-iin/out date change

 

650_02 – Hierarchical Loops

Need clarification on how the TDSP's intend to handle the 650_02 Response Document.  For all the fields that can appear in either the parent loop, or in the child loop, if such exists, where do you plan to put them?  According to the examples, they always appear in the child loops when those are present.  I had heard that some TDSP's might be doing it differently.  Is this the way you intend to do it?  The Implementation Guide is not clear that that is a hard and fast rule, it only says "The decision will be based on whether one or more TDSP Service Orders are generated as a result of the 650_01 request."  If there is one meter, and one service order number, do you still put the service order information (or the comments) in the child loop?  For multiple meters, do you put the service order information in each child loop, or do you put it at the parent level?

 

867_02

The TEXAS SET guidelines states that the MEA05 element in the 867_02 is Dependent ("Dep").  What unit or basis of measurement would make the MEA05 element in the 867_02 a required element? 

 

Number of Unmetered Device Changes – change control #101, was approved 5/17.

Whenever there is an ESI-ID that is supporting multiple unmetered devices, how does the CR request than only one of the lamps be removed?  A move-out would set all the devices to an de-energized status.  The 650 transaction does not include a street light or guard light lamp removal request.  That might be a good place for the request???

 

QSE Invoice – change control #93 has been withdrawn, a new change control will be entered.

If you recall, change control #93 noted that the examples are implying a looping structure that does not exist in the 810_01 QSE Invoice.  Instead of moving the SAC within the SLN loop as requested, I would like to recommend that we modify the example to show one IT1 Loop for each SAC. The structure of the document was meant to show a subtotal in the SAC and then below it, the SLN loops which each showed the settlement day, statement number and settlement amount. If we moved the first SAC into the SLN loop, this structure would no longer exist. So, instead of the current structure, which is not valid for x12:

 

IT1
SAC
SLN
SLN
SAC
SLN
SLN

We would do:
IT1
SAC
SLN
SLN
SLN

IT1
SAC
SLN
SLN
SLN

 

Meter Service Voltage

Previously sent this to Texas SET for reply, got a few, talked to some more over the course of this week.  No one seems to know what the requirement is for this - why it is there - there does not seem to be consistency on what the definition for this is or that there is a value in providing/receiving this information.  What is the value in knowing the "manufacturers voltage rating of the meter"?  In today’s environment, there are meters that are rated by the manufacturer for multiple voltages.  Which do you send?  Possibly providing "voltage delivered at the service delivery point" may be of value to the CR, but do they really need this?  Need Texas SET official answer on this.  Should this be deleted from the transaction?  I'll submit the change control if needed.

 

For clarification, tell me what the expectation of the value is in this example:

 

An industrial customer is taking service at 13,800 volts.  Instrument rated metering is used, and thus the voltage rating of the meter device is 120 volts.  Which of these two values is the REP expecting to see in this field?

Answer:  120

 

Unmetered Service Type Codes – waiting for change control call next week to get feedback from ERCOT.

Change Control 2001-047 - This was approved on 22 Feb 2001 for next release, however, does not seem to have made it into Version 1.3.  Should this now become an "Approved Emergency" one?

 

814_11

In looking at the 814s related to Life Support Indicator, noticed that on the 814_11, Drop to POLR Response, ERCOT to Current CR, the summary of changes for version 1.1 shows changing REF~SU to remove "Required" and add the note of ".....will revisit....." as done on other 814s.

 

820

We need to develop a rejection process for the 820 remittance advice.  If one ESI ID on the 820 is not the CRs or other reason for rejection. 

 

Inbound Move-out to the CR

Has this issue been discussed/decided yet ? It's not documented anywhere that we can find, but our CR wants to be "pro-active", of course.... I think you were the one that originally brought up the scenario of a move-in forcing a move-out and the CR being required to accept that 'inbound move out' or am I mistaken ?

 

Drop to POLR Process

I suggest we get it on our next TX SET agenda for dissemination to the group.  Is there a write up of the details to give out?  Do we need it put out on the ERCOT website under our page?  Also, I think we need an update on the status of the PC and PD transactions.  Did we ever get them blessed?  Are they official and when will they be used?

·         The Drop to POLR process is to support the following:

 

·         CR wants to drop the customer back to the TDSP for what ever reason Customer calls CR to drop out of Pilot Customer calls TDSP to drop out of Pilot or is not interested in participating, TDSP calls CR for CR to initiate the Drop

·         The Drop to POLR process is what was agreed upon in the meetings between ERCOT and the TDSPs.  SET has really not discussed the details.  When the TDSP receives the 814_03 on a DROP to POLR, it is basically just another switch.

·         The CR N1 loop will contain the TDSPs LSE DUNS number which is a different DUNS Than the TDSPs.  The TDSP should look at the CR N1 loop and determine if the DUNs is in fact their LSE DUNs, if it is their DUNs then the TDSP knows to revert the ESI ID back to the bundled rate (back to the 95%).  As a TDSP acting as the LSE(POLR CR), ERCOT will send you the 867_02, 814_14 and the 867_04.  ERCOT understands that you can just clear out your LSE FTP Mailbox, basically trashing these transactions.  TXU has set their transaction default for the LSE role as the WEB Portal, so we will manage these transactions via the ERCOT Web Portal.  We will not be accepting this as EDI transactions.  Again, if a TDSP chooses EDI as the default method while acting as an LSE, then any CR (i.e., 814_14, etc.) transaction that TDSP receives from ERCOT can be trashed and no response will be required.

·         One thing we need to verify is if the CR wants to drop the customer back to The TDSP, that ERCOT will not send out the letter to allow the customer to Choose another CR.  This way we can avoid the current processing situation.

 

Power Factor

There are only so many ways to determine power factor:

pf = kW / kVA = kW / (SQRT ((kW squared + kVAr squared))). 

This can be calculated for every market interval but is reported usually at time of monthly non-coincident peak.

 

Date Change Response – change control #104, on hold until change control call next week

If the TDSP gets an 814_12 date change request and the TDSP can not accept the date change request (i.e; - non-business day) I do not see a DTM in the 814_13 to send back the date that we can accept.     

 

ESI ID “Not Eligible” Error on the 814_02

If a switch (814_01) is sent in during pilot and the 814_20 change eligibility date has not been made, what error message will be returned? Will it be ESI ID not eligible ??

ERCOT Response: Yes - that is the error message. WHAT CODE WILL BE USED?  A13 with comments?

 

Tracking Number on Portal

Issue

A unique Transaction Reference Number is required for each document that is keyed into the ERCOT Portal.  Either ERCOT or the Market Portal user can populate the Transaction Reference Number.   If ERCOT populates the unique Transaction Reference Number, they can ensure that the Transaction Reference Number is unique.  The "unique" quality of the number must be unique across all portal transactions.  There is no foolproof way for a CR entering the Transaction Reference Number to be sure that another CR has not entered the same number.  If ERCOT populates the Transaction Reference Number, it would allow several users on the CR side to enter data without being concerned that the number is unique.  It is assumed that Portal users are working outside of applications where this number might be generated. 

 

Resolution

MPs were unanimous in asking ERCOT to populate the Transaction Tracking Number.

 

·         How can a CR that initiates the transaction make sure that the reference number is unique in its system, since it doesn’t generate the number?

·         Glen will check to see if there will be any logic in the number so CRs can avoid duplicate “unique” reference numbers in its system.

 

Action Items - Follow Up:

·         BJ – James Cohea white-paper on date gap/overlap

·         Glen – code ERCOT will use for “not eligible” on the 814_02, 814_17

 

New Action Items:

·         Mass Customer Lists – Sharon

·         Change Control #90 - 867_04 REF~TN to “Required” – Shirley/Kyle

·         810_03 Muni/Coop Invoice – Tom

·         Redline of the 810_02 – Johnny will send to Shirley

·         Logic in the Portal assigned reference number – Glen

·         Protocols Revisions from move-in/out - Heidi

 

Current Subgroups

Move-in/out Date Change

POLR/CSA Subgroup

Business Process Subgroup

Muni/Coop Invoice Subgroup

 

RSVPs:

Jill Prince                               TXU                                                       Dave Robeson                      Entergy

Jill Popelka                            TXU                                                       Darrell Hobbs                       TXU

Kim Wall                                Green Mountain                                   Roshni Patel                          Reliant

Mike McCarty                      ERCOT                                                   Laura Strait                            Xcel Energy

Carrie Landis                         Xcel Energy                                          Shirley Whyte                      ITPTA

Johnny Robertson               TXU                                                       Christine Meloro                  New Power

Chuck Moore                        PUCT                                                     Heidi Schrab                         Green Mountain

Kyle Patrick                           Reliant                                                    Gerald Murphy                     Austin Energy

Jason Wrubel                       Shell                                                       Glen Wingerd                       ERCOT

George Behr                          ITPTA                                                    Susan Neel                            Reliant

Sharon Polliard                     AEP                                                        Blake Gross                           AEP

Bryn Owen                            ESG                                                         Shirley Whyte                      ITPTA

John Barrow                          Bryan                                                     George Behr                          ITPTA

Rita Morales                         Entergy                                                  Randy Brannon                    TXU

Tom Jackson                         Austin Energy                                      Maria Archuleta                   Austin Energy