SET Minutes

January 31-February 1, 2001

 

Discussion of Break out groups for assignments

·        Risk & Gap

·        TDSP transactions During Pilot Recommendation to PIC

·        Data Element Matrix/867 Examples/Map Descriptions

·        Muni/Coop Invoice

 

Move-in Un-executable – update – no response from ERCOT yet?

·        This is a Protocol issue, it is not currently in Protocols, and therefore a change will need to be entered.  There has not been a group formed yet so, until it has been resolved this will be dealt with in a phone call?

·        If we have 7 business days to complete a move in – the TDSP has to return the 814_04 with the required info, the ERCOT systems will not flag this for 20 days, so the TDSP can return the 814_04 in the 7-day window. 

 

Move-in Reschedule (814_12, 814_13)

·        Option 1:   TDSP reject if requested date cannot be scheduled/performed.  If yes, use REF~7G~A13~OVERBOOKED/CANNOT WORK or another code?

·        Option 2:   TDSP is over-booked.  TDSP would send back the date requested or the next business day if the date requested is a non-business day.  Then plan on using the next 7 days to fulfil the request (which is in the time frame required). .  If yes, use REF~1P~A13~OVERBOOKED/RESCHEDULED or another code?  Do TDPS have scheduling systems that allow it to send back a reschedule date on the response?

·        Option 3:  Neither reject or reschedule - but to perform the work in the time required by the T&C rule (see section 4.3.2.1 in the 12/07/00 proposed rule).  It would be very helpful (mandatory) for the REP to know which of those seven days the TDSP plans to perform the work. Maybe that is or should be the question.

 

·        Protocol issue, SET cannot resolve.  If this is an issue for your company then have it raised to TAC. 

 

Parent/Child loops in the 650

On the 650_01 in the Hierarchical Child Code, if there is only has one meter under the ESI ID would the TDSP expect (or should the CR submit)  “0” (no children/meters) or a “1” (children/meters) in the Parent Loop.  Example #1 shows a 1 and only one meter.  Should we always expect a 1 on the ESI-IDs that only have one meter.

·        Expect both parent and child evern if only one meter is on the ESI ID.

 

Ad-hoc Usage Request (814_26)

814 requests going from a CR to the RA and then passed through to the TDSP that the name N1 and Zip Code N4 is only required on the transaction from the CR to the RA (i.e. 814_08 Drop and 814_12 Change Move-in/Move-out date request).

·     ERCOT does pass through the Customer information to the TDSPs in the N1 Customer Name (can be “PREMISE” or Customer Name) and N4 (Zip code).

·     ERCOT validates on the first 5 digits of the zip code, but will pass on all nine digits if the 4 digit extension is sent.

 

Move-out date

If the utility receives a 814.03 with move-out (CSA)  will the date requested be send in the DTM01 move in date   or the DTM01 the date the CR would like to have the meter read and the customer switched to the CRs service.  The gray box on page 21 of the 814_03 states that the date comes from the 814_16.  However there is not a 814_16 in this scenario.  The original transaction would be an 814_24 move-out request where the R/A has a CSA agreement thus a switch in CRs is all that is needed at the utility.

·        In the case of a move out with a CSA, the TDSP would be sent a switch of providers (814_03) with the Move Out date in the DTM~MRR field. 

 
IDR Questions

·        MISSING INTERVALS -  Will there ever be a time when the Utility sends Interval data that is   missing  intervals or will the Utility always estimate the missing intervals prior to transmitting the 867 so that the Interval summary and the Interval detail  equal?  Since the Utility bills  NBC charges based on consumption , as a REP we are assuming that all intervals will be present/ if any intervals are missing at the time the meter is polled, the utility would estimate each missing interval and note each interval as estimated.

·        TDSPs will fill all intervals and will note “estimated” on the appropriate intervals.

 

Life cycle tracking number

814_01 has a BGN02=111

             814_03 has a BGN02=222, BGN06=111

             814_04 has a BGN02=333, BGN06=111

             814_05 has a BGN02=444, BGN06=111

             867_02 has a BPT02=555, BPT09=111

·        Correct gray box:  “Refers to the BGN06 of the Historical Usage Request (814_03 or 814_26).  This number will be tracked in the BGN06 through the lifecycle of the Registration Process if applicable.”

·        Change control write-up (Heidi).  This has no impact to ERCOT.

·        This will be re-released as version 1.3

 

Energized/De-energized flag:

·        Proposal:  Modify the N1 segment for the CR on the 814_20 (for initial load) to “dependent”.  If the N1 is present with the TDSP DUNs number (no code in N106 for sender/receiver) it would notify ERCOT that the premise is energized.  If the segment is not used the premise is de-energized.  This field would only be required for the final load.

814_20 – N1~SJ (Competitive Retailer) Gray box:  For initial ESI ID load to ERCOT systems:  Required, otherwise Required only when the CR is the receiver.

·        ERCOT can support this for the 3rd Mock (February 26th) and agrees that this is the best way to address the issue.  NEW REQUIREMENT FOR CONVERSION, requires a map change for TDSPs., do not send N106 or it will be rejected by ERCOT.

·        Change control or Add to Patch List – (Jill)  add an example.

 

810_02 Taxes

Assuming that the TXI~LS (state and local tax) segment will only appear for discretionary charges (service orders), what specifically will carry a tax?  Is it legal to pass through a sales tax?  Will the tax be included in the TDS (Sum of the SACs)?  In the TXI07 (relationship code) what is the use for “O = Information only” – does it matter to the CR or Customer if it is not being charged any amount?  Is franchise fee (TXI~FR) based on consumption?  If yes, should it be in the rate loop?

·        Check with PUC on taxes – Cary will have her legal person contact the PUC on this issue.

Change Control: (Heidi/Johnny)  Move TXI~FR to the rate or account loop (if not reporting at the rate level).  The TXI will appear in both loops (rate and account) to allow for both types of reporting.

 

867_03 PTD~BO (Interval Summary)

·        Either remove QTY01 or add language to clarify what would constitute “estimated”.

·        If one interval is estimated then the Interval Summary loop will be noted “Estimated” for that usage reporting period.

 

Review of Actual vs. Estimated Criteria:

The following criteria will be used to determine the setting of the Quantity Quailifier field in the Interval Summary section: If 1 or more intervals in the interval detail has a status of estimated, the interval summary record for that cut will be set to "KA" - Quantity is estimated, otherwise, the value will be "QD" - Quantity is actual. If the end intervals of the cut are trimmed back to fit a max allowed bill period window (ex. 36 days trimmed to 33 days), the cut will still be considered "QD", unless there are one or more estimated intervals remaining in the trimmed cut.

 

867_03 QTY (Non-interval Summary)

Within QTY segment for Non-interval detail, the Implementation Guide states that the consumption in the QD is the total consumption after the multiplier is applied.  Then, in the MEA03, it says the consumption there is the total consumption after the multiplier is applied.  Are these two values supposed to be the same?  If not,  how are they to be interpreted.

·        Yes, if it is totalized (51) these should be the same.

 

650_01 DNP Request

In 650 note “POLR CR” for disconnect for non-pay.  Add a N1 for POLR Duns so that the TDSP can validate that the sender is able to initiate a “disconnect for non-pay.”

·        Not an issue, no change.

 

Review of Un-metered Usage reporting

Un-metered usage should be cancelled and re-billed in the same fashion as metered usage.  We need to walk through the un-metered adjustment, how will the adjustment be applied, in the past.  Will pat dates invalidate the transaction?  Will the adjustment be reported in a separate loop (if so could we add another code in the PTD~BD to indicate if the loop is for regular monthly usage or and adjustment)?  How will the usage be applied when the adjustment spans several REPS?

·        Un-metered usage should be addressed in the same manner as metered usage when it comes to cancel/re-bill situations (all 867s and 810s will be canceled in total and new original transactions will be issued with corrected info)

·        Change request  - 867_03 in the Un-metered loop, change “adjustment code”  to “cancel”

 

820 with $0.00

The date and order of the ACH rule change. Four years ago the NACH relaxed its rule governing the $0.00 transaction.  Prior to that only a PRE NOTE could be $0.00.  They now pass a $0.00 transaction through the ACH system.   The 820 guideline is correct as is.  I still feel that it is a bad accounting practice to pass a $0.00 payment 820 transaction with addendum records, as no funds are transferred.

·        TRN~3 (trace number) segment has to match the payment coming from your bank.  

 

Daylight Savings Time

One area which SET has not addressed completely is defining the daylight savings time indicator for when the second hour is resent.  The time standards call for this to be indicated on the second occurrence of the interval with a "d" trailing the time.  Understandably, the concerns with EDI and lowercase remains.  I would like to ask that we address potential solutions for communicating this via EDI.  Two alternatives that come to mind are:

 

Option 1:  Looking for an indicator field or code within the DTM segment that would indicate that this hour is a repeat.

Option 2:  Looking for a REF segment within the same loop as a DTM which could be used as such an indicator if the interval is the second occurrence of that time.

In either case, this element would not be sent unless the date/time was a second occurrence of the time when the clock is turned back for daylight savings time.

Option 3:  Selected alternative:

In the DTM segment the DTM04 is time code 623, under data element 623 there is a code for:

Central Daylight Time (CD)

Eastern Daylight Time (ED)

Mountain Daylight Time (MD)

 

·        Only use this DTM for the one-hour that is repeated each year 2AM and the new code will only be used on the second occurrence of 2AM.

·        OPEN ISSUE, can MV90 accommodate this for a once a year change, or will the code have to be applied at all intervals and months during Daylight savings..

 

Split Load

If a CR is serving a customer who chooses to split their load on a meter among different CRs, we may or may not be the CR responsible for paying wires charges for the customer.  If we are not the CR paying the 810 charges, will there be an 810 to match to the 867?

·        Check Ch.10 Metering Protocols

 

867 & Added kWh Question:

Additional consumption that is not read by the meter (diversion, fast or slow meter, or otherwise).   How will that info on the kWh's added be transmitted to the REP?   The readings would not match up with the consumption. There is no code on the 867 that would designate KWH's added and the reason for the additional KWH.

 

Customer Protection :

"The beginning and ending meter readings; the kind and number of units measured, whether the bill was issued based on estimated usage, and any conversions from meter reading units to billing units, or any other calculations to determine billing units from recording or other devices, or any other factors used in determining the bill, unless the customer is provided conversion charts; "

 

One  example:   The meter did not register kWh's due to a diversion above the meter. The meter is fine. It is determined/estimated that 1000 kWh's should be added to the registered kWh's.   The readings on the meter are correct but consumption should be added due to the electricity being used that did not pass through the meter.  How would this consumption be transmitted to the REP and how would the REP know why kWh's were added.

·        OPEN ISSUE – additional consumption will not match the readings.

·        For subtractive and totalized meters.  Customer A (ESI ID A) has the subtractive meter and Customer B (ESI ID B) has the totalizer.  On the Customer invoice for TDSPs pass the total amount to ERCOT.

·        The first QTY loop (QTY~QD) will report the metered consumption for billing, followed by MEAs with the meter reads.

·        Add a QTY loop (QTY~VM) for variance adjustment.  Gray box:  “consumption is adjusted, but the meter reads are not changed.  (Meter reads will be reported as metered)”

·        The two QTYs will need to be added together

·        Jill and Johnny will write up examples and options.

 

Adjusted Usage – Review

On the 867_02 and 03, what is expected for the Interval Summary Field Segment MEA (Transformer Loss Factor), MEA03?  Since the multiplier is usually specified in the "Rate Schedules" and is a constant value, like 1.05 which is used on many accounts.  Do we have to provide this value even if it is already posted in our rate schedules and not a measured value?  

·        Review discussion from Conference call:  The Team agreed that the interval data usage reported in the 867 transaction includes the usage that was measured by the recorder. That usage is usually reduced as it passes through the transformer and encounters resistance. In order to prorate the usage back up to perform billing, and transformer loss factor is applied. What will be reported in the 867 is the actual measured usage and the transformer loss factor that is documented in the Distribution rate schedule.

 

Update Recission Period

How will a CR satisfy: "The customer shall be informed of the scheduled date that the customer will begin receiving electric service from the REP, and of any delays in meeting that date."

·        ERCOT Portal look-up for the meter read code for the ESI ID.

 

Does "late notice" mean after the 3+3 days? ("Any REP receiving a late notice of cancellation from the customer shall contact the registration agent and cancel the pending switch as soon as possible after such late notice is received."

·        Must follow the Portal for dispute process.

 

Pilot CSV Format

·        Zip code can be 5 or 9 postal code

·        Header line will include the total number of records preceded by a # sign (#40)

·        Total number of records in the trailer will be removed

·        Account number and/or ESI ID (both fields are available)

·        Bruce will submit this to Nancy for PIC.

 

Case Sensitivity

·        Mixed case values that ERCOT receives will not be converted into all caps.  ERCOT is going on the assumption that all MPs will send all upper case fields to ERCOT.  For fields that ERCOT uses for validation (not X12 code values, but mixed case can happen in alphanumeric fields), it will reject if that field is not all caps.

 

 

Break-out Session:  TDSP transactions during Pilot – Review Pilot switch flow and discuss

·        Transactions that TDSP will use during Pilot when it is acting as POLR and CR.

·        Drop during Pilot – TDSP is POLR, ERCOT will send and 867_04 (Initial Read) to TDSP (as POLR)

·        Switch CR during Pilot – TDSP is Current CR, ERCOT will send 814_06 (Drop Request) to TDSP (as Current CR) – this transaction can be trashed, TDSP (as Current CR) must return an 814_07 (Drop Response) to ERCOT.

·        Move-in during Pilot – TDSP is New CR, TDSP (as New CR) will send 814_16 (Move-in request) to ERCOT, ERCOT will return the 814_17 (Move-in Response) to the TDSP (as New CR) – this transaction can be trashed.

·        Move-out during Pilot – TDSP is Current CR, TDSP (as Current CR) will need to create and send the 814_24 (Move-out Request), ERCOT will return an 814_25 (Move-out response) – this transaction can be trashed, ERCOT will send the 867_03 to the TDSP – this transaction can be trashed too.

Review of Scenario Flows

·        During Pilot flows – the transactions needed for settling the other 95% of the market.

 

Discussion:

·        ERCOT wants move-in and move-outs so it can better understand gaps for settlement during Pilot.

·        TDSPs will move Customers back to bundled rates and will already have to deal with customers in two ways (those that are participating in Pilot and those that are not).

·        There is a price risk to the TDSP side QSE during Pilot if ERCOT does not know energized/de-energized status of the premises for settlement purposes.

 

Exception to Scenario A1 

·        Option 1:  The 814_06 (incoming to TDSP) be trashed after the 997 is sent

·        Option 2:  The 814_06 (incoming to TDSP) is trashed and no 997 is returned to ERCOT.  ERCOT would put these on a missing 997 report.  What are the implications of this?

·        ERCOT can deal with not receiving the 814_07 during Pilot

·        Option 1:  for TDSPs that do want EPS info, 867_03 is trashed after the 997 is sent.  ERCOT will have to make adjustments in a “different place” for TDSPs that do accept EPS 867_03s.

·        Option 2: some TDSPs will be polling their own meters so they will not be relying on incoming 867_03s for EPS.  Does ERCOT have a flag to indicate “do not send EPS info”?

 

**If a TDSP has in the ERCOT profile that indicates for ERCOT to NOT send an 867_03 for EPS, will that hold for monthly 867_03s also.  ERCOT suggestion might be to remove the trading partner agreement for EPS transactions, ERCOT will have to figure out the impact of this?

 

Exception to Scenario B1 – ERCOT TDSPs only

·        The driver for ERCOT receiving 814_24 (Move-out request) knowing if a premise is energized or de-energized during Pilot

·        TDSPs read meters every month whether it is energized or not.

·        TDSPs do not want to send the 814_24,  ERCOT thinks there is a chance that there could be a problem (invalid relation ship or another reject reason) and it would need to reject the transaction on the 814_25.

·        Instead of sending the 814_24, the TDSP will send an 814_20 to change the premise status to de-energized.

·        If the TDSP sends an 814_20 to change the premise status to “de-energized” by mistake, it would be need to be fixed with a phone call.

 

Check on this:

·        867_03 for monthly usage to ERCOT sent for 100% of TDSP customers  during Pilot – energized premises only

·        867_03 for monthly usage to ERCOT sent for 5% (customers participating in Pilot) during Pilot – premises only

·        During choice, de-energized premises will not have monthly 867_03s.

*For a TDSP acting as a Current CR during Pilot, TDSPs will have to build systems to act like a CR in the next two months.

·        How will ERCOT get usage for a Non-Pilot customer in ERCOT territory during Pilot?  ERCOT needs to receive the final 867_03.

 

TDSP recommendation: 

·        It would be easier for TDSPs to send all monthly readings, both energized and de-energized during Pilot.

·        During Pilot, TDSPs will send 814_20 for change of meter status (energized/de-energized) at the ESI ID level – Either use the N1 loop for CR or add a new REF segment.

 

Exception to Scenario C1 – ERCOT TDSPs only

·        814_16 will be addressed with 814_20.  New Customer moving-in, contacts TDSP and TDPS sends de-energize flag on the 814_20.  ERCOT will have two triggers to de-energize (move-outs – 814_24 - and premise update – 814_20).

·        867_02 – historical usage is requested, so the TDSP will not request it.

·        867_04 – will not b e sent by the TDSP to ERCOT, so ERCOT will not forward it on to TDSP.

 

Exception to Scenario E1 – ERCOT TDSPs only

·        867_04 – will not b e sent by the TDSP to ERCOT, so ERCOT will not forward it on to TDSP.

 

Scenario

 

Current Transactions

Proposed Solution

 

A1 (Switch)

Energized w/CR (switch from TDSP to CR during Pilot)

814_06 drop request

Trash, 997 “not supported” back to ERCOT

 

 

OR

 

 

 

814_06 drop request

No transaction sent by ERCOT

 

 

814_07 drop response

No transaction needed by ERCOT

 

 

867_03 usage

TDSP Profile – do not send the 867_03 to the TDSP.

 

 

OR

 

 

 

867_03 usage

For TDSPs that want EPS info the profile note will not work - TDSP would receive and trash the transaction.

 

B1

(Move-out)

Customer not in Pilot, moving-out

814_24 move-out request

814_20 to de-energize

 

 

814_25 move-out response

814_21 response

 

 

867_03 usage

TDSP Profile – do not send the 867_03 to the TDSP.

 

 

OR

 

 

 

867_03 usage

For TDSPs that want EPS info the profile note will not work - TDSP would receive and trash the transaction.

 

C1 (Move-in)

Energized w/ TDSP as REP Move-in

814_16 Move-in request

814_20 change to energized w/date

 

 

814_17 Move-in response

814_21 change response

 

 

814_05 premise info

TDSP will not receive this transaction because the 814_03 and 814_04 will not be initiated.

 

 

867_02 historical

This would be requested basis, so TDSP will not request this.

 

 

867_04 initial read

TDSP will not issue the 867_04, therefore will not receive the 867_04

 

E1

(Drop)

Drop to TDSP (leaving Pilot participation)

867_04 initial read

TDSP will not issue the 867_04, therefore will not receive the 867_04

 

Modified use of the 814_20:

·        Use the DTM~152 for “Effective date of change”

·        Add a new REF segment in the 814_20 to indicate “energized/de-energized”

 

 

Break-out Session: Municipal/Coop Invoice

Attendees: Johnny Robertson (TXU), Kim Wall (Green Mountain), Tom Jackson (Austin Energy), Lorraine Bucci (Exelon), Steve Mokry (City Public Service), Bruce White (TXU) and Kyle Patrick (Reliant)

 

Muni/Coops, upon opt-in, will bill customers directly for wires charges (unlike the IOUs).  Under this arrangement, it is required that the CR send a power bill to the Muni/Coop, which in turn will send a combined bill for the power and the Muni/Coop wires charges to the retail customer.  The Muni/Coop will then remit payment to the CR upon receipt of payment from the retail customer, under the provisions as set forth in the Muni/Coop Terms and Conditions.

 

SET will needs to address invoicing for Muni/Coops:

Modify 810_02 or create a new 810 for: 

CR to Muni/Coop invoicing transaction

Modify 820_02 or create a new 820 for: 

Muni/Coop to CR payment transaction

 

Lorraine explained the two options a Muni/Coop will have in the state.

 

Option 1

Option 2

(Opt in act like a TDSP).

(Like a REP) Where Muni/Coop take on role as competitive retailer in another utility’s territory. 

Billing Options:

Customer receives separate bill

·        867

·        814_03

·        568

Customer receives consolidated bill

·        814_03

·        810

·        867

·        820

·        568

All TX Set Transactions

Will be governed by Muni/Coop’s own Terms and Conditions

Will be governed by competitive REP’s Terms and Conditions, and all SET transactions

 

Lorraine then explained the two models that are accepted in regards to paying charges.  Group discussed options for Steve and Tom to take back to respective companies regarding these models.

 

Model 1

Model 2

Pay Charges whether customer pays or not.

Pay charges only when customer pays

·        Returned check

·        Misapplied Payment

·        Posting Sequence

 

Steve developed Scenarios M1 and M2 for Muni/Coops

 

Action Items:

1.      How customer changes billing option

2.      Steve needs to develop data flows for M1, M2

3.      Munis/Coops need to review 814_01, 814_03, and 867_03.

4.      The issue of the 568 versus the Contract Payment Management Report.  The 568 is accepted, could this report be accepted in its place?

5.      Johnny will send Tom, Steve, and Kyle the PA_568 for their review.

 


Late fees / Cancel/Re-bill

 

 

 

 


A                                                B                                                   C                                                  D   

 

Invoice A  goes out (will not be paid within the 35 day window – late fee will be assessed in Invoice C)

 

 

 

 

Invoice B goes out before the CR is late on Invoice A

 

 

 

 

Invoice C goes out with the late fee (5%) from Invoice A

 

 

 

 

Usage billed on Invoice A is cancelled and re-billed.  This will force Invoice A, B and C to be cancelled and re-billed.

 

G                                                H                                                  I                                                   J

Usage cancelled and re-billed for the past 6 months, re-billed amount is more than previously billed on each invoice

 
 

 

 

 

 

 

 


Invoice A 

Invoice B

Invoice C

Invoice D

Invoice E

Invoice F

 

 

 

Invoice G goes out too

 

 

 

 

Invoice H goes out before the CR is late on Invoice A, B, C, D, E, F & G

 

 

 

 

B2B loop in Invoice I will need to include late payment fees for 6 different invoices – the B2B loop needs invoice # in order to tie back.

 

4.4.3  INVOICE CORRECTIONS (Ts&Cs)

Invoices shall be subject to adjustment for errors, including, but not limited to, arithmetic errors, computational errors, and Meter Reading errors.  Company shall cancel and re-bill the original invoice that was incorrect and apply any payments made to the re-billed invoice.  If it is determined that Company over-billed for Delivery Charges, Company will make adjustment(s) associated with the Point of Delivery for the entire period of over-billing.  If it is determined that Company under-billed for Delivery Charges, Company will make adjustments for the entire period of under-billing but not to exceed six months.

 

·        How will the CR be notified of overpayments (underpayments will be addressed by the TDSPs)?  THIS IS A POTENTIAL MAJOR IMPACT TO TDSPS PROGRAMMING

 

810

1.  $100 (invoice of 1)

2.  $-100 (cancel of 1)

     $ 90 (re-bill of 1)

3.  $100

820

1.  $100 (payment of 1)

2.  $-100 (reverse pmt of 1)

     $ 90  (payment 2)

3.  $100

·        Change control for invoice number to tie late fee back to  (Jill/Heidi/Johnny)

·        Does Ts&Cs support balance forward?  Change control will be entered by Kim.

 

SET Listserve

·        SET listserve should not be used for any questions/issues that are internal processes.  The distribution list hits several hundred MPs so the list serve should only be used for questions/issues that impact a whole group of MPs.  Please direct other emails to a selected SET participants for other info.

·        If inappropriate emails are sent to the SET listserve, please respond to the sender that it should be addressed to the texaschoiceprogam.com list serve.  Ted Hailu at ERCOT need to know if answers are not being responded to quickly

 

Open Issues List

·        Individuals have the responsibility to resurface any unresolved issues from the Minutes.

 

IG Versions

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                  version 1.2A will be re-released.

810_02                  Draft 1-12, Approve 1-17

820_01                  – will not be developed.

820_02                  Draft 1-12, Approve 1-17

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

 

Other:

·        997 Functional Acknowledgement:  Review “position” document from ERCOT.  This will be addressed in TAC meeting/presentation.

·        Trading Partner Agreements:  This is not in Ts&Cs, this is not a SET issue.

·        Daylight Savings Time:  Will double reporting the time affect MV90 people?

 

Outstanding Issues:

Risk and Gap Analysis review/update

·        Outages still outstanding pending the Outage workshop (2/5-6 Austin, Omni Southpark) 

·        Need PIC minutes to further analyze

IDR Questions

·        TRANSFORMER LOSS and IDR  - Will the Interval Data that is transmitted on the 867 from the TDSP always have the transformer loss added to the consumption (when applicable) for the Interval summary, each Interval in the interval detail and the Summarized Interval detail (when applicable) when there is transformer loss present ? For Interval Detail, there is no segment specified for transformer loss.

·        Follow up with James Cohea (Jill).

 

Version Migration

·        A question/concern at TXU has been raised regarding the migration strategy for Texas SET EDI versions in a production environment.  What is ERCOT's strategy for migration to a new Texas SET EDI version in production?  For example, would ERCOT require a migration to Texas SET EDI version 1.3 from 1.2 based on a cut-over date/time for instance midnight 12/1/2002?  Or, would there be a transitionary period where both version 1.2 & 1.3 would be in effect?  Or is there some other migration strategy?

·        Is there any documentation describing the migration process as indicated  above?

 

Patch List Items:

·        AEP has offered resources.  MPs need to have the list in hand very soon.  It will be posted on the SET website and red-lined IGs will be posted.  Mike is in the process of collecting additional documents for posting from the document owners.

 

814_20:  Add to Patch List:  We need change to the description on the REFSPL Code in the REF~TD segment in the LIN loop. It still reads Change Standard Interconnection Point and should be Change Station ID.

 

650 Purpose Codes:  Add to Patch List: In the 650 (01,02,03)  transactions, the gray box for Purpose Codes contains two errors:

               ME   use only when BGN07= RH.  should be KH for Meter Exchange

TE   use only when BGN07 = TE.   should be IN for Technical/Environmental

 

824 Reject Reasons:  Add to Patch List: Change gray box in 824 for TED~848~CRI – should be used for invalid or missing reference number for 867_03 cancel transactions when the BPT09 does not match a previous transaction.  Add gray box to indicate:  “…or an 867_03 cancel transaction does not match an existing open 867_03”

 

Data Structure Page:  Add to Patch List:  No repeating loops on the data structure page for the 650s

 

810_02 Taxes:  Add to Patch List:  take out the TXI07 – “O” in the 810_02

 

 

Assignments:

·        Document list of Protocols gaps (language that does not reflect how ERCOT is processing transactions)  (BJ/Jill/Heidi)

·        New Change Control: Life cycle tracking number in 867_02 (Heidi)

·        New Change Control: Energized/De-energized flag in 814_20 and add an example (Jill)

·        New Change Control:  810_02 TXI segment (remove “Information only” and add TXI in the rate level loop (Johnny/Heidi)

·        New Change Control:  Un-metered services (REF~PRT) info in the 814_14 (David)

·        New Change Control:  810_02 Balance Forward (Kim)

·        Additional kWh (when meter is slow or otherwise) examples and options write-up (Jill/Johnny)

·        Follow-up with James Cohea on Transformer Loss (Jill)

·        Data flows for M1 and M2 for the Muni/Coop Invoice (Steve)

·        Review of the PA_568 (Tom/Steve/Kyle)

 

Next Meeting:

February 22-23,Thursday 8:30-5:00, Friday 8:30 – 1:00 Austin, TXU will sponsor

March 7-8, Wednesday and Thursday 8:30 – 5:00 Austin, Reliant will sponsor

March 21-22, Wednesday and Thursday 8:30 – 5:00 Austin, AEP will sponsor

*Conference calls for SET Issues will be at 2:00 on Wednesdays,

 

Attachments:

Meeting Minutes 1/31-2/1

Map Scenarios A-K (Visio)

Ts&Cs Gaps document

SET Phone list

 

Attendees:

Jill Prince                             TXU                                     Darrell Hobbes                   TXU

Johnny Robertson                              TXU                                     Kyle Patrick                         Reliant

Kathy Scott                          Reliant                                  Debbie McKeever                              TXU

Kim Wall                             Green Mountain                  Dave Robeson                     Entergy

Sharon Polliard                   AEP                                     Mike McCarty                      ERCOT

BJ Flowers                           TXU                                     David Lotspeich                  Accenture

Susan Neel                           Reliant                                  Heidi Schrab                        Reliant

Stephen Mokry                    CPS                                      Tom Jackson                        Austin Energy

Dave Bynoe                         Shell                                     Rodney Russell                    GE

Lorriane Bucci                     Exelon                                 Bruce White                         TXU

Cary Reed                            AEP

 

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.

 

1/24

Muni/Coop Invoice

 

1/31

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

 

1/31

Additional kWh, reading will not match consumption

 

Items Closed at this Meeting: