TX SET Meeting
October 18-19, 2000
·
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
·
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)
·
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?
·
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.
·
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?
·
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.
·
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
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
·
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