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
·
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.
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.
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.
·
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.
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.
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.
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..
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.
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.
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.
·
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.
·
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.
·
During Pilot flows – the transactions needed for settling the other 95%
of the market.
·
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.
·
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?
·
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.
·
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.
·
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”
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 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. |
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
·
Individuals have the responsibility to resurface any unresolved issues
from the Minutes.
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:
·
Daylight Savings
Time: Will double reporting the time affect MV90 people?
Outstanding Issues:
·
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).
·
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: |
|
|
|
|
|
|
|
|
|
|
|