TX SET Minutes
5/17-18
Finalize
Minutes from 4/25-26 Meeting
Discuss
Emergency Process for Change Controls
Review
SET Procedures Documents (3 attachments)
Final
approval of SET Version Control document (attachment)
Discuss
Schedule for next release 7/1-13
Permits
during Pilot will be handled with phone calls – after the TDSP receives the
814_03, it will notify CRs by phone if a permit is needed. Permits for
Choice will require a reason in the 814_08 Cancel; the 814_04/05 need a field
for Permit required. Critical Care
during Pilot – will be handled in the same manner as today, TDSPs will
qualify and keep records of CC status, CRs will supply the TDSP with the CC
flag in the 814_01 and provide customer contact info Notifications
WS – for planned or emergency outages, TDSPs will contact CR designated
person outages via email to list serve or directly (depends on the volume of
the outage) Notifications
WS – for service order notification when the Customer made the request
through the TDSP during Pilot, CRs will receive no prior notice of the
Service Order and/or associated charges, the first indication is on the
810_02 TDSP Invoice. Notifications
WS – for overpayments, action item for John Hudson to report back on the
current GAAP process, no definite procedure was determined. Retail Metering
WS – For Choice, new net loop in the 867_03. Move-in/out
WS – During Pilot phone calls from TDSP to CR will notify of: move-in without meter, move-in
unexecutable (wasted trip charge may be applied). CR calls TDSP during Pilot for: priority move-ins (same-day/next-day) Move-in/out WS – For Choice, Move-in
without meter changes: make meter info dependent on 814_04/05. For Priority Move-ins add a code(s) for
priority in the 814_16 move-in request.
For Move-in Unexecutable create a new transaction (???_0?) with
code(s) for “completed unexecutable” and gray box language to indicate the
origin of the transaction reference number for the business life cycle. Move-in/out
WS – A solution for, during Pilot, Move-in date changes (may result in a
customer being disconnected before the requested move-out date) has not been
developed. ERCOT will need to weigh
in on this to see what kind of manual tracking they can implement. Options will be presented at RMS. Move-in/out for
CSAs - CSA process has not been finalized
either – currently ERCOT systems will cancel a move-in if the CSA CR and the
Tenant CR are the same, more work is needed. Other notes from
the discussion in SET: 1. Create a
Transaction Notes page for every implementation guide, explaining the purpose
of the guide and anything that people need to know, such as
Upppercase/Lowercase issue, etc. 2. Correct Cross Ref
Number in front of 810_02 that it will not be populated for Discretionary
charges after final bill and LPC bill 3. Change all load
profiles to real examples 4. Wholesale Delivery
Point doesn't have a "NO" on the 814_20 5. One ESI per 814, 810,
650, 867 Multiple ESIs per 820 state
in front pages. 6. Clarification of how
you send a change in one piece of a service address (i.e., zip code) 7. Show examples of
decimal values in meter read values and meter multipliers 8. State that there are
multiple rejection reasons or status reasons |
Overpayments
Will any market participants expect manual checks from
a TDSPs in lieu of making adjustments to their 820s (as described in the 820
guidelines) when dealing with overpayments from CRs to TDSPs?
Option 1 -
TDSP sends payment to the CR, either by check or by EFT. This would require no action on the CR's
part.
Option 2 -
TDSP contacts the CR and explains the overpayment. The CR adjusts the next 820 that they are planning to send to the
TDSP for the amount of the overpayment.
An issue with this, however, is whether the CR will be provided with an
Invoice Number, Cross Reference Number and ESI ID which to apply the dollar
amount.
That brings up another issue. We changed the 810 invoice to state that the
cross reference number is not required on a Late Payment Charge invoice or an
Invoice after final bill for discretionary charges. But, we never adjusted the
820 to state that the cross reference number is not required in this case. What is required on the 820 if the CR is
taking back an overpayment?
All TDSPs should be prepared to handle negative
amounts on the 820 as a normal business practice resulting from
cancel/rebills. But, are all TDSPs
prepared to handle adjustments on the 820 for overpayments?
RESOLUTION: TDSPs will call the CR and
will have the CR adjust the amount on the next 820 (current due minus
overpayment) to the TDSP. Which data
elements will be needed by the CR to identify the error? The TDSP will indicate the invoice in
question and ESI ID – if it is a large number of corrections, the TDSP may send
a spread sheet/report. TDSPs want contact
info for CRs A/P.
Other:
GISB
EDM
Bulletin A0038 has been
recalled and revised. It has been determined that if the GISB EDM guide
is followed, there are no interoperability issues with PGP Version 6.5.2 and
later releases. No change is required for the TDTWG GISB EDM Plan,
Version 1.1 or the GISB EDM Standard, Version 1.3.
ERCOT will not automatically
purge any documents during Pilot. ERCOT
will drop a report in each TDSPs area of the Portal a couple of times a week
that shows outstanding responses that are 20 days or older. Again, nothing will be purged. ITPTA will issue a bulletin so all MPs will
be aware of this.
ESI
ID per Transaction
Want to confirm that the TX SET decision /understanding confirmed on April 26th's conference call is "All SET transactions with the exception of the 820 will only contain 1 ESI ID per transaction.” This includes all flavors of 814s, 867s, 810s, and 650s. This implies only ONE LIN loop per 814 transactions.
Can
the Reference Identification (BPT09) on the 867_02 also refer to the Reference
Identification (BGN02) on the 814_01. The Implementation Guide mentions the
BGN06 on the 814_03 or the 814_26. The question is posed because the 814_01
also allows for the request of Historical Usage/Historical Interval usage when
requesting enrollment.
What
is the business reasoning behind having the BNG06 of the 814_22, CSA CR
Move In Request, reference the BGN02 of the 814_24, "Move Out
Request?"
1. A CR can
not request multiple service activities (meter test plus disconnect for
customer requested clearance plus etc.) for one ESI-ID or Meter on one
650_01.
2. From one
650_01 the TDSP may initiate multiple internal service orders depending on how
that TDSP operates
3. If the TDSP
initiates multiple internal service orders for the one 650_01, the TDSP is not
to complete the service order back to the CR until the TDSP completes all
internal service orders.
4. For TDSPs
that generate multiple internal service orders, these service order numbers
including the completion dates of each separate internal service order are to
be provided on the respective 650_02 (one completion date per TDSP internal
service order).
5. On the
650_02, the MEA always loops in conjunction with the DTM~MRR (MEA never loops
by itself).
6. The one
650_01 may be for an ESI-ID that is a multiple meter installation.
7. For an
ESI-ID multiple meter installation, the CR can not request a different action
on the same 650_01 for different meters (meter one do a tree trimming, meter
five do a disconnect for customer requested clearance, meter eight do a meter
test).
8. If this is
a 650_01 ESI-ID multiple meter installation without additional meter
information provided by the CR, the TDSP is to complete the work requested
(same activity) for all meters under that ESI-ID.
9. If this is
a 650_01 ESI-ID multiple meter installation with specific meter information
provided by the CR, the TDSP completes the work requested (same activity) for
only those meters that the specific meter information has been provided for
under that ESI-ID.
10. For
service orders requesting action for multiple meters, the TDSP will complete
action (the same action) requested at each meter before responding to the CR.
If
there is a change in Meter Characteristics such as Meter Attributes, Meter
Cycle or Number of Dials, will an initial meter read be performed?
Discuss
details of the late payment invoice.
What are MPs expecting.
kW
in 867_04
The
867_04, there is no place for the KW reading.
I do not know if this was an oversight or the CR is to assume this value
is always 0.
867_04
There
is no way to cancel an 867_04 transaction or what is the process of canceling
and rebilling an initial reading?
Mid-Cycle
Meter Change
Need understand what TDSPs will be doing for Pilot when they switch out a meter mid-cycle. First instance is when they switch out a non-interval meter for a non-interval meter and the second instance is when they switch out a non-interval meter for an interval meter.
Meter Type
Need to discuss how the REF*MT is used for interval data, non-interval data, and unmetered data. (When to use KHMON, KH015, etc.)
· Interval usage uses KH015
There is a gap in the
move-in, move-out date changes and forced move-out dates. Subgroup from RMs has developed two options
for RMS, ERCOT will have an option 3 drafted by the RMS meeting on Wed, 23rd. More work on the move-iin/out date change
650_02
– Hierarchical Loops
Need
clarification on how the TDSP's intend to handle the 650_02 Response
Document. For all the fields that can
appear in either the parent loop, or in the child loop, if such exists, where
do you plan to put them? According to
the examples, they always appear in the child loops when those are
present. I had heard that some TDSP's
might be doing it differently. Is this
the way you intend to do it? The
Implementation Guide is not clear that that is a hard and fast rule, it only
says "The decision will be based on whether one or more TDSP Service
Orders are generated as a result of the 650_01 request." If there is one meter, and one service order
number, do you still put the service order information (or the comments) in the
child loop? For multiple meters, do you
put the service order information in each child loop, or do you put it at the
parent level?
867_02
The TEXAS SET guidelines states that the MEA05 element
in the 867_02 is Dependent ("Dep").
What unit or basis of measurement would make the MEA05 element in the
867_02 a required element?
Whenever there is an ESI-ID that is supporting
multiple unmetered devices, how does the CR request than only one of the lamps
be removed? A move-out would set all
the devices to an de-energized status.
The 650 transaction does not include a street light or guard light lamp
removal request. That might be a good
place for the request???
If
you recall, change control #93 noted that the examples are implying a looping
structure that does not exist in the 810_01 QSE Invoice. Instead
of moving the SAC within the SLN loop as requested, I would like to recommend that we modify the example to show one IT1
Loop for each SAC.
The structure of the document was meant
to show a subtotal in the SAC and then below
it, the SLN loops which each showed the settlement day, statement number and settlement amount. If we moved the first
SAC into the SLN loop, this structure would no longer
exist. So, instead of the current structure, which is not
valid for x12:
IT1
|
We
would do: IT1
|
Meter
Service Voltage
Previously sent this to Texas SET for reply, got a few,
talked to some more over the course of this week. No one seems to know what the requirement is for this - why it is
there - there does not seem to be consistency on what the definition for this
is or that there is a value in providing/receiving this information. What is the value in knowing the
"manufacturers voltage rating of the meter"? In today’s environment, there are meters
that are rated by the manufacturer for multiple voltages. Which do you send? Possibly providing "voltage delivered at the service
delivery point" may be of value to the CR, but do they really need
this? Need Texas SET official answer on
this. Should this be deleted from the
transaction? I'll submit the change
control if needed.
For clarification, tell me what the expectation of the
value is in this example:
An industrial customer is taking service at 13,800
volts. Instrument rated metering is
used, and thus the voltage rating of the meter device is 120 volts. Which of these two values is the REP
expecting to see in this field?
Answer: 120
Change Control 2001-047 - This was approved on 22 Feb 2001 for next release, however, does not seem to have made it into Version 1.3. Should this now become an "Approved Emergency" one?
814_11
In looking at the 814s related to Life Support
Indicator, noticed that on the 814_11, Drop to POLR Response, ERCOT to Current
CR, the summary of changes for version 1.1 shows changing REF~SU to remove
"Required" and add the note of ".....will revisit....." as
done on other 814s.
820
We need to develop a
rejection process for the 820 remittance advice. If one ESI ID on the 820 is not the CRs or other reason for
rejection.
Has this issue been discussed/decided yet ? It's not
documented anywhere that we can find, but our CR wants to be
"pro-active", of course.... I think you were the one that originally
brought up the scenario of a move-in forcing a move-out and the CR being
required to accept that 'inbound move out' or am I mistaken ?
I suggest we get it on our next TX SET agenda for
dissemination to the group. Is there a
write up of the details to give out? Do
we need it put out on the ERCOT website under our page? Also, I think we need an update on the
status of the PC and PD transactions.
Did we ever get them blessed?
Are they official and when will they be used?
·
The Drop to POLR process
is to support the following:
·
CR wants to drop the
customer back to the TDSP for what ever reason Customer calls CR to drop out of
Pilot Customer calls TDSP to drop out of Pilot or is not interested in
participating, TDSP calls CR for CR to initiate the Drop
·
The Drop to POLR process
is what was agreed upon in the meetings between ERCOT and the TDSPs. SET has really not discussed the
details. When the TDSP receives the
814_03 on a DROP to POLR, it is basically just another switch.
·
The CR N1 loop will
contain the TDSPs LSE DUNS number which is a different DUNS Than the
TDSPs. The TDSP should look at the CR
N1 loop and determine if the DUNs is in fact their LSE DUNs, if it is their
DUNs then the TDSP knows to revert the ESI ID back to the bundled rate (back to
the 95%). As a TDSP acting as the
LSE(POLR CR), ERCOT will send you the 867_02, 814_14 and the 867_04. ERCOT understands that you can just clear
out your LSE FTP Mailbox, basically trashing these transactions. TXU has set their transaction default for
the LSE role as the WEB Portal, so we will manage these transactions via the
ERCOT Web Portal. We will not be
accepting this as EDI transactions.
Again, if a TDSP chooses EDI as the default method while acting as an
LSE, then any CR (i.e., 814_14, etc.) transaction that TDSP receives from ERCOT
can be trashed and no response will be required.
·
One thing we need to
verify is if the CR wants to drop the customer back to The TDSP, that ERCOT
will not send out the letter to allow the customer to Choose another CR. This way we can avoid the current processing
situation.
Power
Factor
There are only so many ways to determine
power factor:
pf
= kW / kVA = kW / (SQRT ((kW squared + kVAr squared))).
This
can be calculated for every market interval but is reported usually at time of
monthly non-coincident peak.
If the TDSP gets an 814_12
date change request and the TDSP can not accept the date change request (i.e; -
non-business day) I do not see a DTM in the 814_13 to send back the date that
we can accept.
ESI ID “Not Eligible”
Error on the 814_02
If a switch (814_01) is sent
in during pilot and the 814_20 change eligibility
date has not been made, what error message will be returned? Will it be ESI ID not eligible ??
ERCOT Response: Yes - that is
the error message.
WHAT CODE WILL BE USED? A13 with
comments?
Tracking
Number on Portal
A
unique Transaction Reference Number is required for each document that is keyed
into the ERCOT Portal. Either ERCOT or
the Market Portal user can populate the Transaction Reference Number. If ERCOT populates the unique Transaction
Reference Number, they can ensure that the Transaction Reference Number is
unique. The "unique" quality of the number must be unique
across all portal transactions. There is no foolproof way for a CR
entering the Transaction Reference Number to be sure that another CR has not
entered the same number. If ERCOT populates the Transaction Reference
Number, it would allow several users on the CR side to enter data without being
concerned that the number is unique. It is assumed that Portal users
are working outside of applications where this number might be generated.
Resolution
MPs were unanimous in asking ERCOT to
populate the Transaction Tracking Number.
·
How
can a CR that initiates the transaction make sure that the reference number is
unique in its system, since it doesn’t generate the number?
·
Glen
will check to see if there will be any logic in the number so CRs can avoid
duplicate “unique” reference numbers in its system.
Action
Items - Follow Up:
·
BJ
– James Cohea white-paper on date gap/overlap
·
Glen
– code ERCOT will use for “not eligible” on the 814_02, 814_17
New
Action Items:
·
Mass
Customer Lists – Sharon
·
Change
Control #90 - 867_04 REF~TN to “Required” – Shirley/Kyle
·
810_03
Muni/Coop Invoice – Tom
·
Redline
of the 810_02 – Johnny will send to Shirley
·
Logic
in the Portal assigned reference number – Glen
·
Protocols
Revisions from move-in/out - Heidi
Move-in/out
Date Change
POLR/CSA
Subgroup
Business
Process Subgroup
Muni/Coop
Invoice Subgroup
RSVPs:
Jill
Prince TXU Dave
Robeson Entergy
Jill
Popelka TXU Darrell
Hobbs TXU
Kim
Wall Green
Mountain Roshni Patel Reliant
Mike McCarty ERCOT Laura Strait Xcel
Energy
Carrie Landis Xcel
Energy Shirley
Whyte ITPTA
Johnny Robertson TXU Christine
Meloro New Power
Chuck Moore PUCT Heidi
Schrab Green Mountain
Kyle Patrick Reliant Gerald
Murphy Austin Energy
Jason Wrubel Shell Glen
Wingerd ERCOT
George Behr ITPTA Susan
Neel Reliant
Sharon Polliard AEP Blake
Gross AEP
Bryn Owen ESG Shirley
Whyte ITPTA
John Barrow Bryan
George
Behr ITPTA
Rita Morales Entergy Randy
Brannon TXU
Tom Jackson Austin
Energy Maria
Archuleta Austin Energy