SET Meeting

January 10-12, 2001

 

997 Discussion

·        “Best-practices” Implementation of the 997 is to reject a transaction at the earliest possible level, however this is different than the ERCOT approach.

·        ERCOT is using an ANSI compliant map (in the translator) to validate at the 997 level.

·        It would significantly increase the staffing and time for ERCOT to investigate 997 rejects.  If it is rejected at the 997 ERCOT will not track that they received a response to the transaction, assuming 814s where each request should have a corresponding response.  ERCOT 997 processing is not integrated with the normal business processes that deal with the SET defined transactions.

·        If SET docs are used to validate at the 997, and one transaction is “bad” the reject should be sent at the transaction level and not at the envelope level.

·        Mike will talk to Cherie about getting something in writing on the preferred implementation of the 997 this since it impacts ERCOT and how its system is set up to process.

 

Review of 650 Transactions:

·        If an ESI ID is sent for a 650 re-read request, it is assumed that all meters are being requested to be re-read.  For multiple-metered accounts, where only one (or a subset of the meters) the meter-number would need to be specified.

 

Option 1: unfavorable option

One loop per meter at the HL on request and response, but all REFs for that loop would need to be repeated – increases room for error.

Option 2:Create an NM loop which would include the meter number, any dates or other info would have to be in a REF

Option 3: unfavorable option

One service order per meter, and the meter number would have to be specified in the request.

 

650 BGNs

650_01 Original Request: BGN02

650_01 Cancel Request: its own BGN02 and BGN06 (equals the BGN02 of the Original Request)

650_02 Original Response: its own BGN02 and BGN06 (equals the BGN02 of the Original Request)

 

650_01 Original Request: BGN02

650_01 Update Request: its own BGN02 and BGN06 (equals the BGN02 of the Original Request)

On an Update (the Original Request has not been worked yet) the TDSP would apply the update and respond to the Update Request – the Original Request will not receive a response

650_02 Update Response: its own BGN02 and BGN06 (equals the BGN02 of the Original Request, which is the same as the BGN06 of the Update Request)

 

650_01 – Request (Original, Cancel, or Change/Update)

·        Add HL parent/child relationship for meter and ESI ID levels

·        BGN06 – is it used just for Reconnect after DNP

·        BGN08 should always be populated

·        Remove N401 and N402 as agreed in Service Order Meeting

·        PER01 and PER02 should be Dependent.  (In the Service Order Meeting it was agreed that Contact Name would be in “First Name Last Name order”)

·        Add gray box on REF02 for ADE, Pole Number

·        Meter Number REF in the parent HL will be removed

·        Clarify gray box on Priority Code REF

·        Clarify gray box in the DTM~211 (Service Requested Date) is Required when sending priority code other than 01 (standard)

·        REF segment in the LM loop (on p. 25) will be removed

·        Clarify gray box on YNQ for disconnect location, “Required for disconnects”

·        Add verbiage to the MTX to state that if only one MTX segment is sent that up to 160 characters can be sent.  “When directions and comments are both used each must be limited to 80 characters.  If only one is used then that one can be no more that 160 characters.”

·        What are the data elements that can be updated?

Add REF~TD (Reason for Change) codes:

N18R – (includes N1, PER, and TE)

REFADE – Pole Number

DTM211 – Requested Date

DTM843 – Not Before Date

YNQCAL – Call before

YNQPDL – Premium Disconnect Location

REFMG – Meter Number

MTXACC – Access Instructions

MTXRPT – Report Remarks

 

650_02 – Response (Completed)

·        Add HL parent/child relationship for meter and ESI ID levels

·        Move Meter Number into the meter level HL loop

·        Move TDSP Service Order Number REF to the LM loop (meter level) – if no meter number exists the meter level (LM) loop will still be used

·        Date/Time will be reported at the meter level, the completion date and time may be different by meter for multiple metered ESI IDs.  There are no DTMs in the NM1 loop, so how should we report the DTM info at the meter level?  Reason for adding the LM loop – NM1 loop removed.

·        There will be no restrictions on the number of characters in the MTX for comments from the TDSP.  CRs may want to think about how they will handle a large incoming text message.

·        The Service Order number (REF~OW) will be provided in the parent level loop or the child level loop, whichever is appropriate.

·        Remove the sentence in the gray box in the REF~MG (Meter Number) “If this segment is not sent, it is implied that the work is to be done for all meters at the ESI ID” – it is an incorrect statement.

 

650_03 – Response (Completed Unexecuted or Rejected)

·        Use HL Parent/child structure.  The first HL~1 would be the parent, the child would be (for example) HL~2~1 (one HL child loop for each meter).

·        Change “Completed Unexecuteable” to “Complete Unexecuteable”

·        BGN06 gray box – remove paragraph beginning “For Cancel and Change (Update) transactions, also note:  1. If the original service order….”

·        REF~G7 (Complete Unexecuteable Reason), change the gray box in REF03 to indicate “T018” instead of “R018”

Hierarchical Level

HL~1~~EV~1                                                                ESI ID Level  - HL04 (1=children, 0=no children)

               REF~Q5

REF~8X

Other ESI ID level info goes in this loop

HL~2~1~EV                                                                  Meter Level - FIRST METER

REF~MG                                                                                 (HL02 in the child refers to the HL01 in the parent)

               Other meter level info goes in this loop

HL~3~1~EV                                                                  Meter Level - SECOND METER

REF~MG                                                                                 (HL02 in the child refers to the HL01 in the parent)

               Other meter level info goes in this loop

 

Change Control Conference Call:

No new change controls have been submitted.

The 810_02 is missing the Summary of changes page, it will be added to a “oops” list and will be added to the document at the next version release.  The “oops” list will be added to the website under Patch List.

Send any of these clean up items to Mike, use “Patch List” in the subject line of the email.

 

810_02 – TDSP Invoice

Waiting to see the outcome of “partial payments” in Ts&Cs.  If some portion of the invoice is being disputed, how will the TDSP deal with the invoice.  The TDSP could cancel the entire invoice and re-invoice for the amount minus the disputed amount.  How will the remaining (disputed) amount be reconciled, either paid by the CR or re-invoiced later.  On amounts that are ruled valid, that were disputed will owe interest on the amount that was erroneously withheld.

 

Customer Information (change control #22, #25):

This is included in Ts&Cs, ERCOT Protocols need to be updated because the transaction will pass through ERCOT.  All MPs need to push this issue so that ERCOT will add this to the list of priorities and an estimated date (from ERCOT) that this can be done.

 

It was suggested that a group of us get together and make a presentation for why this information is needed and how the TDSPs will receive the info (separate transaction or part of an existing transaction)

 

810_01 QSE

·        BIG 01 add gray box “invoice date”

·        Change REF~RU to REF~01

·        REF02 instead of REF03, for REF~RU(or 01) and REF~11

·        David will check on how ERCOT calculates late fees, he thinks it may not be a straight percentage – remove the percentage data element ITD15?

·        Add an SAC03 position 230

·        Add SAC04 and added code “STL001” for “Settlement Statement Summary Amount”

 

820_01

Will not be developed, this will need to be worked out between MP and bank.

 

Post Conversion/Pre-Pilot Maintenance Transactions

Between April and June 2001, receiving and loading the maintenance transactions during this time.

 

Because of having to populate the database at the end of March, TXU would prefer to not have to send daily updates during that period…Would monthly updates be acceptable until at least end of May?  These monthly updates would include the April-mid-May monthly usage too.  The concern is the volume of the transactions that ERCOT would be able to handle, ERCOT does not think the volume will be a problem.

Should the 814_20s associated with Pilot customers should be batched as well?  Or is it better to send daily transactions for Pilot customer?  Based on this if there is a new ESI ID that is being held in the monthly batch, ERCOT would not have it available in its system yet to change the eligibility date yet – however the TDSP could indicate the “correct” eligibility date on the 814_20 ESI ID create transaction.

 

824

·        ERCOT has merged the 824s, the XML that ERCOT has programmed is labeled “824_02” however there is really only one 824.

·        Change control #33 – TED reject codes

·        MRI – Meter Role Invalid or not found (gray box: Incorrect meter role for ID type)

·        TOU – Time of Use (gray box: Incorrect time of use periods)

 

Case Sensitivity:

Load profile IDs include lower and upper case letters, the comparison at ERCOT is in Siebel, ERCOT’s Translator and in Lodestar.  David will report back the “fix” to

 

867_04 for Un-metered Services

If un-metered in indicated in the PRT then the MEA and QTY will not be present.  The date of the effective switch will still be sent.

 

For un-metered services, the example is incorrect in that it shows a meter number in the PTD segment.  The absence of a meter number indicates that the 867 is for an un-metered account.  The 867_04 does "not provide any information on type of device or its consumption".  This information is included in the 814_04, 814_05, and 814_20 in the REF~PRT segment which are communicated when a REP signs up the ESI ID.  The only information obtained from the 867 for an un-metered account is the actual start date of the switch.

 

Account Status

Register all ESI IDs, some are active and some are inactive.  How will ERCOT know which ESI IDs are active.  TXU is not planning on sending inactive ESI IDs to ERCOT until they are activated, at that time they will send a create ESI ID 814_20.  Upon conversion all ESI IDs will go to the affiliate REP, if the ESI ID is not registered, then the affiliate would not receive the ESI ID.  One solution would be to send two files: one for energized/active accounts, and other for inactive/de-energized accounts.  Take this issue back to TDSPs.  Another solution would be to add codes in the LIN to indicate the difference.

 

814_20:  NM1 Reason for Change Codes

Removed the reason for change when a meter exchange or meter re if reason for change is not present ERCOT will not reject based on the missing reason code.

 

The lack of a reason for change for this case will not cause the transaction to be rejected by ERCOT's system.  Using the NM1 code to indicate the meter action should be sufficient

 

867_01 PTD Non-Interval Usage Summary Loop, MEA Segment

There is no need for a MEA04 because you loop it at the PTD level

 

Status of the 867_05

ERCOT has programmed the transaction, however the implementation guides have not been created yet.

 

867/810 IDR Validations Concern

Concern with matching 867 Service Period Start and End Dates for IDR to the dates on the 810 Service Period Start and End Dates.  Are other Utilities having this problem?  How are other Utilities handling this?

Dave will organize a call with David to discuss this issue.

 

TDSP Cancel/Re-bill (J3 Scenario Map)

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. OPEN ISSUE

 

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 conditional for cases when the late charge shows up 2 months after the customer has switched.   OPEN ISSUE

 

Also a late payment charge after the ESIID has switched to another CR.

There will be no 867 to reference on the 810 for the late pay charge if the CR does not pay the final 810.

 

Interest Charges:

In the 810 there is no SAC code to return an interest charge to the REP if the TDSP holds on to REP funds for too long during a dispute.  Should this be done in the B2B loop?  Change request will be written up by Jill/Johnny.

 

Pilot Transactions

814_PA and 814_PB will be published  in draft form 1/12, for approval 1/17.

 

PIC update:

Staff recommended a new option that will likely be supported.  On 2/15/01, as REPs sign up customers, the REP will be required to send an email to the TDSP with a file detailing the REP DUNS No., Account No., Date and service zip code.  There will be a daily file and a weekly file that will include a running count.  The TDSP will be required to report to the PUC as enrollment reaches various levels, i.e. 50%, 75%, 90%, 95%, 100% (not sure of the exact % at this time).  PUC would then be required to immediately notify the REPs of the %.

 

If the Pilot is oversubscribed on 4/16, the number of transactions sent to the TDSP by the REP will be analyzed.  If the REP had reported in their emails that they had signed 100 customers, they will need to send 100 switch authorizations or some number of transactions that falls within an acceptable variance.

 

Pilot Suggested Format for TDSP counting file (Pilot Volunteer File):

Bruce has developed a recommendation document (attached to this email).  Bruce will forward to Nancy Hetrick for presentation to PIC.

 

Drop to POLR during Pilot

Option, per David:

·        Current REP submits 814_10 drop to ERCOT,

·        ERCOT notifies the TDSP with the 814_03 with a TDSP DUNs number in the N1 for the REP (the TDSP will in effect be acting as the POLR REP),

·        814_04 back to ERCOT with the scheduled date of switch/drop,

·        814_11 back to the CR if it is an “accept”.

·        867_03 and 867_04 to complete the switch/drop.  The TDSP will kill the incoming 867_04 (not needed).  TDSP must somehow separate the 867_04 from the incoming 867_03 for ERCOT polled meters.

 

TDSP Move-in of Customer during Pilot

This refers to the case when a Customer had participated in Pilot and subsequently moves out.  The new tenant/customer at that premise moves-in but does not want to participate in Pilot.  The TDSP can initiate the move-in through the Portal (so the TDSP will not have to program a move-in transaction, since it would not do so during Choice).  This is the recommended solution for the TDSP during Pilot to “bring” a customer back under TDSP service/supply.

 

REP to REP Transactions

Per Customer Protection, deposit transfers from REP to REP will not be standardized by SET.  The suggested solution is to have each REP wire transfer the funds to the new REP.

 

820 ENT

The “1” in the ENT is just a placeholder, this segments true use is for more complicated 820s.

 

814_12  Move-in Un-executeable

On the move-in process there is a not a mechanism for the TDSP to respond back to the CR that they were "Unable to execute" the move-in  request due to conditions at the premise.  This is still pending.

 

Additional Consumption reporting when a meter has malfunctioned (per Ts&Cs 4.8.3)

Recommendation to add the consumption in an un-metered loop this would require a reason for additional loop and allow for a metered loop and un-metered loop existing in the same transaction.  The additional consumption could be either a positive or negative value.

 

Risk and Gap Analysis:

Ts&Cs and Customer Protection need to be reviewed for gaps with ERCOT Protocols.

 

Protocols Changes/Updates:

1.      Ch. 19 - Pilot, currently says there are 4 Pilot transactions should be 814_PA, 814_PB

2.      Ch. 19 - Service orders, make sure there are only three 650’s

3.      Ch. 19 – Need to add 867_05

4.      Ch. 19 – There should be only one 824

5.      Ch. 19 – There should only be one 820

6.      Customer Information

7.      Reason for estimated read (867_03)

8.      Move-in Unexecuteable

9.      In the 814_17 (move-in) currently ERCOT will reject the transaction if the CR is already the CR of record.  For cases when a CR is trying to circumvent the move-out then move-in for the same premise with two charges – recommendation to allow for back to back move-ins.

10.    Life Support

11.    Permits

 

Transaction Status

650_01                  Draft 1-12, Approve 1-17

650_02                  Draft 1-12, Approve 1-17

650_03                  Draft 1-12, Approve 1-17

810_01                  Draft 1-12, Approve 1-17

820_01                  – will not be developed.

814_PA                Draft 1-12, Approve 1-17

814_PB                 Draft 1-12, Approve 1-17

824                        version 1.2A will be re-released next week

810_01                  version 1.2A will be re-released.

 

Other:

·        Both Upper/Lower case will be handled by ERCOT on incoming Transactions.

·        Life Support could be at a Meter Level but the SET documents will indicate life support at the ESI ID level.

·        Bruce has a question that was submitted 3 weeks ago to Pat Coon that has not been answered, the Q/A process may not be working.

·        867_03 and 867_04, per Customer Protection, we need to add a “reason for estimated read” field and this needs to be made consistent with the ERCOT Protocols.  Johnny has written up a change control.

·        Customer Information on the 814 needs to be changed in ERCOT Protocols, as well.

·        Meter voltage code is ONLY passed on the 814_20, the REP will not get the code unless there is a meter exchange.  Is there a need to include this data element on any other 814s, maybe 814_04 and 05.

 

To Do:

·        SET website – only list the most current documents with “download” and “view” options

·        Update the “Possible Manual Transactions” page on the website

·        Go through “pending” change controls and get ERCOT to provide expected dates for those changes

·        Gap Analysis on Ts&Cs, Customer Protection and Protocols Ch. 15

·        Update 814 Master document

·        Take the active/energized vs. inactive/de-energized ESI IDs during initial load (conversion) issue back to TDSPs for comment

·        Raise Customer Information (change controls 22, 25) to TAC

·        All MPs need to review the HL loop (position 010) at the child level to make sure that all types of service orders that can be requested at the meter level are included in the gray box.

 

TX SET Update

·        We have completed the initial phase of development.  Final transactions will be moved into a maintenance phase.  Larry Shields has stepped down as Chair.

 

Next Meetings

·        January 25-26 Thursday 8:30-5:00, and Friday 8:30-12:30 in Austin.  Location to be determined.

·        Change Control conference call is every Wednesday at 2:00 pm.

 

Attachments:

Meeting Minutes 1/10-12/01

Map Scenarios A-K (Visio)

Texas SET Recommendation for Pilot Volunteer List

 

Attendees:

Dave Bynoe                         Shell                                     Jill Prince                             TXU

Johnny Robertson                              TXU                                     Kyle Patrick                         Reliant

Jeanette Harris                     Reliant                                  Kathy                                   Reliant

Kim Wall                             Green Mountain                  Dave Robeson                     Entergy

Sharon Polliard                   AEP                                     Mike McCarty                      ERCOT

BJ Flowers                           TXU                                     Bruce White                         TXU

Larry Shields                        Xcel                                      David Lotspeich                  Accenture

Ken Corcoran                     Accenture                            Diana Rehfeldt                    TNMP

Heidi Schrab                       Reliant

 

Open Issues List

 

Date

Issue

Approach

12/20

1)  814_28/29

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.

 

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

 

 

 

 

 

 

 

Items Closed at this Meeting: