SET
Meeting
January
10-12, 2001
·
“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_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)
·
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)
·
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”
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
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.
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.
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.
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.
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.
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
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:
·
Go through “pending”
change controls and get ERCOT to provide expected dates for those changes
·
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.
·
We have completed the initial phase of development. Final transactions will be moved into a
maintenance phase. Larry Shields has
stepped down as Chair.
·
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: |
|
|
|
|
|
|
|
|
|
|
|