TX SET Meeting

October 18-19, 2000

 

Agenda

 

Pilot Review

Pilot Volunteer tracking by Customer vs. ESI ID – update from PIC members

·        Discuss the processes for each (ESI ID tracked and Customer tracked)

·        Discuss/assign scenario maps for each process.

·        Biggest difference is when volunteering is done by ESI ID, then tracking it by Customer – so it has to be cancelled and then a new addition, notify the RA. 

·        In PIC it was agreed that tracking by customer will only be within TDSP service territory – if a Customer moves to a new TDSP service territory tracking will not occur.

·        In Customer tracking, the eligibility list will become a living list….

·        From a SET perspective, it would mostly impact residential customers, however SET doesn’t feel that it deserves any more attention, technically it makes the most sense to track by ESI ID.

·        If we track by Customer, it is not really a Pilot for real market, it would be different than open market.

·        Mike McCarty will draft something and present it to PIC (next Tuesday)

 

820_02 Issues

·        If the money and transaction are sent split then we would use 3. 

·        Fix structure page – remove DTM

·        ENT remove gray box – this can be any number but will most often be “1”

·        In the example change the 60 to 6O (this is a letter O)

·        Add the REF~Q5 in the example  - take this back to the REPs, will this make a difference to the REPs – can we send this?

·        We will leave in the Q5 for the baseline, if we decide that the Q5 requirement cannot be accommodated then we can enter a change control to remove the segment.

·        All “must use” fields in this implementation guide (820_02) must be forwarded to the Financial Institution. – or something like this (on page 2 of the doc)

·        Diana will baseline and distribute  - 820_02 Version 1.0

 

824 Issues

·        There is only one 824 now

·        ESI ID has been added back in

·        Add ESI ID back into the example

·        If no 824 is received within 48 hours, then the transaction is deemed to be correct (there may still be problems with the content of the transaction)

·        Remove the PER and add the REF at position 20

·        Always identify the Utility and the REP on this transaction – fix gray box for the N1s – remove the conditional statement and make it Required. 

·        N106s Add gray box “if the Utility is the receiver then it will be used, otherwise it will not be used” – copy the same language as used before

·        N106s become Dependent

824_02 and 03

·        TED (TED02): Do not need the "A13", "Other" on either of these. (Entergy) – these codes will stay.

·        NTE:  If delete the "A13" then this is not needed. (Entergy) – these codes will stay

824_03

·        Title Page - Monthly Usage Reject Response shows "824_02".  This needs to be corrected. (Entergy) – this has already been corrected.

·        Diana will baseline and distribute  - 824 Version 1.0

 

650 Issues

·        Review minutes from 7/24-25 on Service Order comments – some of the items that had earlier been decided that they would be addresses with an “Alternative to EDI Solution” – these codes have been included in the 650s, does anyone have any problems with addressing these with the 650?

·        For Disconnect for Non-pay (this can only be done by the POLR) will be coded as a “Disconnect.”

Review of Comments/Issues with 650s October 13, 2000

650_01

·        Add an “Accept” code (WQ) in the BGN08.

·        Request to add a DTM segment for time windows as follows for the 650-01: (Entergy) –

Segments were not added, MTX gray box example will be added with “please work not 10/1 or after 10/3” in the MTX02 field, MTX02 add a gray box to recommend not using more than 160 characters.  (fix this on all three 650s)

                                                                                                                                  DTM01 - 843 = Not Before - 844 = Not After

Due to the fact that a consensus (after lengthy discussion) in SET was reached to place the request for a time window in the MTX Message Text segment of the 650_01, these codes will not be added at this time.

**According to Ts&Cs the TDSP has 5 days to work the order anyway.

·        Purpose of the NU Transaction type on the 650s – based on the comments below the description and use of the NU Meter Change Request code will remain as is.  Removal of lock-band can be considered like a clearance.  Interference can

BGN07 – add a gray box to direct user to MTX for additional information, if applicable

BGN07 - code “79” – when no wiring changes – add gray box text “this does not involve a wiring change”

BGN07 - code “IN” – add gray box text “ (i.e. radio, television)”

BGN07 – code “CJ” – add gray box text “(i.e. multiplier, manufacturer)”

BGN07 – code “UF” – add gray box, if UF used further explanation is required in the MTX segment. UF is used for new installation. 

Add note in MTX gray box to note that codes listed in the BGN07 will dictate if the MTX segment is required.

·        Diana will baseline and distribute  - 650_01 Version 1.0

650_02

·        Add the 1P segment to the 650_02 for the code “PRM” for Permit Required – Make the 650_02 be for Accept w/ conditions or Reject (Copy the 1P segment from the 650_03 and remove BDR, DOG, INA, and LCK).  The “Description” field in REF03 (required vs. optional) – gray box reflects that something is required in REF03 when REF02 is “PRM”, however we will wait until next week to find out how the Technical Workshop (or other group) decides the details around the Permit notification issue

·        Include comments and gray boxes that were changed on the 650_01 (above), as needed.

·        In the REF~7G, remove the REF02 code MTI (Maintenance code invalid)

·        Add gray box for A84 to communicate that this is used for  “not REP of record” – add code for “not REP of record”- gray box for A84 that is on the 814_25 – and add a gray box to the 814_25 and 650_02 to explain when the A84 is used.

·        Add an example with the MTX message text

·        Diana will baseline and distribute  - 650_02 Version 1.0

650_03

·        Include comments and gray boxes that were changed on the 650_01 (above), as needed.

·        Add an example with the MTX message text

·        Diana will baseline and distribute  - 650_03 Version 1.0

 

810_02 Issues

·        Take the first few pages from an 814 for the template

·        Change the “Implementation Guideline Field Descriptions” page – Change the box that says “Used on a Cancel” to say “Example”

·        Move info from gray box (now on page 5) and re-work page 3 (like other 814 transactions) – “This transaction set will be paired with an 867_03 (Monthly Usage) to trigger the Customer billing process, as applicable.” Or some other language that indicates that an invoice can be sent to the Customer monthly even if no 867 usage is received

·        REF02 should be REF03 for the ESI ID element

·        IT1 in the gray box remove the statement: “The decision of which IT109 code to use...”

·        Rate Class info will only be provided at the IT1 level, multiple rates under the same ESI ID (ex. street lights) can be billed on one 810 by using multiple IT1 Loops at the different rate levels. 

·        An example is needed for the Account level.

·        Add gray box for the LPC (Late Payment Charge) – yet to be decided

·        Add code for Charge-off Allowance (DSC001) and add a gray box  - yet to be decided

·        TXI – discussion around the franchise FEE – if it appears above the TDS then it should be relevant to the SAC immediately preceding it …. Add a gray box under Franchise Tax to indicate “Franchise Fee”

·        Are any REPs expecting to get a franchise CREDIT passed from the TDSP?  Franchise Credits are tracked by name, since the TDSP doesn’t have the customer name, they have argued that they will not know where to assign the credit.

·        Examples reviewed.  Some issue with the RATE vs ACCOUNT level charges, especially in regard to streetlight billing at two different rates under one ESI ID.

·        Johnny will baseline and distribute  - 820_02 Version 1.0

 

Change Control Forms

·        Schedule conference calls weekly to address change control  - This will be scheduled every week (even on the weeks that there are SET meetings) -  Wednesday at 2:00 (ERCOT will facilitate the conference call bridge)

Review change control requests

·        Change Control #6 – Alternative B has been accepted.  We now need to add this REF01 segment code “PTC ”  Patent Type (PREMISE TYPE) to add to the 814_20, 814_04 and 814_05.

Codes needed for REF02: 

Residential                                                         Non-residential small

Non-residential medium                                   Non-residential large

*ERCOT needs this so they will know which POLR is associated with the premise, and REPs need this to make sure they are not in violation of an Customer Protection rules.

 

·        Change Control #7

First two points is internal ERCOT validation points – approved by SET

        Drop to POLR Response (814_11) in detail position 030, REF code 7G:

        A84 – Invalid Relationship – add gray box from 814_25

        NFI – Block by Pending Request

 

Second points is internal ERCOT validation points – approved by SET

        Move-in response (814_17) in detail position 030, REF code 7G:

        NFI – Blocked by Pending Request

        Move-out response (814_25) in detail position 030, REF code 7G:

        NFI – Blocked by Pending Request

 

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

Requires more research - will be addressed at the next conference call

 

Fourth  point “REF position 030= “WI”….”

Requires more research – will be addressed at the next conference call

 

·        Change Control #8

No usage indicators for the last 4 LIN data elements (LIN06, LIN07, LIN08, LIN09).  They should be conditional, based on what is sent in the 814_01, 814_10, 814_16, 814_22, or 814_24.  The request on the 814_01 will be passed on to the TDSP in the 814_03,  however if there is something invalid on the 814_01 request it will not be passed on to the TDSP.  We need to add “Dep” in the right hand column and add a gray box to refer to the explanation in the top gray box. – approved by SET.

 

·        Change Control #9

The REF04 was a Foresight error, it will be fixed.  There should only be the REF01 and REF02. – approved by SET

 

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

 

Reason Codes (650 and 814)

·        For Consistency, on the 814s we should include codes that are similar/same as the REF codes on the 650.  On 650_03 there is a REF02 Data element 127 "Need codes" (for bad dog, gate locked, inaccessible, other) yet on the 814's there is not a similar field.   We will encounter the same conditions on move-ins, move-outs, disconnects for non-pay, etc.   (HL&P)

·        This will need to be addressed with a new transaction/new process (especially to address Move-ins) that we currently do not have mapped, this may turn into a Protocols Change Process. 

·        “PRM” Permit needed in the 1P for the 814_04 – Reliant will submit a change control

·        THIS WILL NEED TO BE ADDRESSES SEPARATELY, ERCOT will probably push back from adding the customer information to the 814_01 – this would required ERCOT to update the Portal to include customer info on the enrollment screens.  If the 814_20 is used to update this info, then we need to update the direction of the transactions to allow for the REP to send this info.  Another issue is that we don’t want 814s to go point-to-point.

Flow of the 814_28/29 transactions (part of the issue above)

·        We also need to clarify if this transaction needs to go through ERCOT. If so, an update of terminology will be necessary.  ERCOT does not want the 814_28 and 814_29 to flow through ERCOT.

·        Discuss possibility of incorporating this notification into one or all of the 814's that request a switch, move-in, etc.  Would the REP know at the time they obtained the customer that the Utility would take the calls? Is it easier to request a change for those transactions now than trying to create a new transaction?

 

Data Element Matrices

·        Review for consistency with implementation guides

 

Un-metered Enrollment

·        How will we handle a customer move in on an Un-metered ESI ID?  The 867_04 seems appropriate but some changes would need to be made so that the transaction would not error out due to the required MEA field.  Could this just pass a zero in the “start read” field?

·        Change control to remove the “requirement” for QTY for the 867_04 to accommodate unmetered services. Add the PTD04 code of “XX” (we need to choose a code here), PTD05 for “UNMETERED” – TXU will write-up this change control

 

867 Example Issues

·        867_01 Examples:  An issue was found when our IT department reviewed the non-interval usage example for the

·        Since there is suppose to be one PTD loop for each unit of measure and one QTY loop for each period then why is there not a QTY loop for each period within that one PTD loop? (TNMP) – Example appears to be wrong.

·        Will all interval metered ESI Ids always pass the BO loop (usage summarized across meters at each interval)? Yes.

·        We need some clarification from ERCOT on when they expect the PP loop  - it seem redundant to send exactly the same info in the PP loop (summarized) and the PM loop (detail at the meter level) when there is only one meter on the ESI ID.

·        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

 

Streetlight

·        Issues with street light rates (TXU REP)

Example:  175 watt MV on rate xx with a subclass rate of xx.

Example:  a 175 mv may be higher if on a wood pole than on a steel pole etc.

 

There is not enough info on the 867_03 to bill our streetlights, but it is on the (810 - rate, subclass)

·        Change control needed to add the Rate Class and Sub-class in the 867_03, needs to be broken out by rate class by schedule – TXU will write-up change control.

·        We need to add quantity of un-metered services to the 814_20, this is in change control, the QTY

 

Non-ERCOT data elements – Conversion and Cut-over Matrix:

·        Bruce spoke with Andersen about the 814_20, and the issues below and on the Conversion/Cut-over Matrix, they will be correcting the matrix and will redistribute.

 

Line 7: TDSP DUNS                                        Non-ERCOT Required should be Yes

Line 8: Distribution Loss Factor Code            Non-ERCOT Required should be No

Line 10: Standard Interconnection Point         Should be re-labeled “Load Bus ID” 

                                                                           Non-ERCOT Required should be No

                                                                           Populated on Initial Load should be Yes

Line 14: Date Eligibility                                    Non-ERCOT Required should be Yes

Line 16: Meter Voltage:                                    Non-ERCOT Required should be Yes

                                                                           (This a REP need – not ERCOT)

Line 17: Load Profile                                        Non-ERCOT Required should be No

Line 18: Utility Rate Class                                 Populated on Initial Load should be No

Line 18: Utility Rate Sub-Class                         Populated on Initial Load should be No

 

Many of the corrections involve not needing certain information for non-ERCOT premises regarding settlement such as Profile, Loss Factor Code, and Load Bus ID. However this assumes the other power regions will have a different method of settlement than ERCOT. It is reasonable to expect that the non-ERCOT areas may choose to piggy-back and use a similar procedure to ERCOT and further that the needed information could be shadowed in the Registration database. This needs to be investigated by the non-ERCOT utilities and ERCOT. It could benefit the REPs and their QSEs.

 

The 867 looks suspicious for the non-ERCOT Required field as well. ERCOT does not require any 867s from non-ERCOT premises on Initial Load or monthly cycle reads. 867s are only required when completing a switch or move-in or drop, etc. which may or may not correspond to a cycle read.

Solution:  If the settlement = ERCOT then the profile info would be required.

 

Billing Scenario Maps (J maps)

·        Reviewed the scenarios, no problems cited.

 

Unresolved Issues

Late Payment Charge at the ESI ID level vs. the REP level

·        Discuss company positions on this. 

·        LPC at the ESI ID level: AEP, TXU

·        LPC at the REP level:  HL&P

·        SPS could go either way.

·        What are other company positions on the LPC, ESI ID level vs. REP level?

Concurrent Processing

·        Review updated flows from Andersen, discuss any issues

 

Other

·        Bruce will send language to SET that will cover the changes from REP to CR and Utility to TDSP

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

·        Permits/Inspections (this is under the PUC Technical Workgroup)

·        Test Plan Sub-group has been moved under the PUC - Test Plan Sub-group participants from each market participant?  Who is in favor of a 3rd party test administrator? 

·        Internet EDI Data Transport Sub-group has been moved under the PUC

·        Change control to remove the code for change (BPT~04) – Reliant will write-up this change control.

·        814_04 and 814_05 –County and City codes need to be added – for permitting and taxing identification ERCOT will not store this, but should be passed through.  The REP may need to SEND the TDSP the business description so the TDSP can correctly assign the SIC codes. Reliant will write-up the change control form

·        Change Controls may not get implemented until market open, change controls that will likely not be implemented for Pilot.

 

Tabled Agenda Items

·        Review of Version Control Document

 

Attachments:

Meeting Minutes 10/18-19/00

867 Examples

Data Element Matrix

 

Assignments:

·        Clean up website – update the Conversion transactions, fix “Scenario Names” Document presentation on site – Mike

·        Appendices in a matrix format – BJ

 

Timeline

Implementation Guides that have been base-lined and will be distributed by the transaction set owner:

·        814s complete Version 1.1

·        867s complete Version 1.1

·        810_01 (ISO/QSE) - Version 1.0 base-line 10/19

·        810_02 (TDSP/REP) – Version 1.0 base-line 10/19

·        820_01 (QSE Payment) – ON HOLD

·        820_02 (REP Payment) – Version 1.0 base-line 10/19

·        650_01(Request) Version 1.0 base-line 10/19

·        650_02 (Accept/Reject) Version 1.0 base-line 10/19

·        650_03 (Completion) - Version 1.0 base-line 10/19

·        824 (Reject for 810, 867) - Version 1.0 base-line 10/19

·        814_28/29 Customer Maintenance (this is for REPs that will not handle service calls/outage notification calls)

·        Open Item: Data Element Ownership – Cary/Larry (Lead)/Diana  - David will furnish this, in progress

·        Open Item: Test Plan – Roshni (Lead)/Robert/Quentin – working with ERCOT and PUC

 

Next Meetings

·        Meeting November 1-2, Wednesday @10:00, Thurs 8:30-5:00, hosted by ERCOT, in Austin. 7200 North MOPAC Expressway (near the Far West exit), Suite 240.  Hotels near ERCOT building:  Hampton Inn 512.349.9898, La Quinta 512.832.2121, Holiday Inn 512.343.0888, North Park Suites 512.452.9391

·        Tentative Meeting November 15-16, Wednesday @10:00, Thurs 8:30-5:00, hosted by ????????? – we need a host.

·        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                                     Leticia Moreno                    Reliant

Diana Rehfeldt                    TNMP                                 Richard Howard                 ERCOT

Debbie McKeever                              TXU                                     Rohni Patel                          Reliant

Jill Prince                             TXU                                     Heidi Schrab                        Reliant

BJ Flowers                           TXU                                     Jeanette Harris                     Reliant

Mike McCarty                      ERCOT                               David Johnson                     Systrends

Nancy Hetrick                     Enron                                   Bruce White                         TXU

Dave Robeson                     Entergy                                Johnny Robertson                              TXU

Donna Ellis                          Reliant                                  Susan Neel                           Reliant

Dave Bynoe                         Shell                                     Dave Darnell                       Systrends