TX SET
April
10-11, 2001 Meeting
Minutes
·
Open
issues list 3/21 concerning 814_20 for new customer. It stated that CR will send request to set meter in 650. This is incorrect. The CR will send an 814_03 and this will clue the TDSP to set a
meter if that is what is needed.
2001-83
·
Shirley Whyte
discussed change controls she introduced (2001-83). We will discuss in detail in the future.
Ø Item 2 – PTD loops should be sorted by logical PTD
loop structure – would help immensely.
Ø Discussion of Item 7a (second item 7) re: Channels
(and 34/36): There was discussion
whether anybody needed channel information.
We need to ask if we are always sending channel numbers if there are
only one channel for kWh, one for kW.
If there is more than one channel measuring the same information (kWh,
for example), we are supposed to send channel # according to protocol. Heidi to take the issue to RMS to determine
if there is a business reason to send channel information.
Ø Item 18 – For ERCOT polled meters, need to have S in
PP to identify it as a resource ID.
Jill is to write up the procedure.
Jill Prince says ERCOT will not pass this through when it is a resource
meter.
Ø Item 21 – Discussion of QTY01 use of AO and 92. AO is for a verified reading – meter reading
is correct (second trip). Need to put
in clarifying information in gray box. Need
to verify how we are using these codes.
Ø Item 38/39 – Shirley Whyte concern that without a
meter number for subtractive loop, that most systems will overwrite previous
information because there is no information distinguishing from previous
loops. It would be best to provide a
meter number, even if it is made up.
Is it better to simply provide the ERCOT data and ignore the master
meter and subtractive meter information?
Jill and Shirley to write up a detailed discussion and bring to RMS.
Ø This should be broken into subjects – referencing
channeling, subtract metering, gray box cleanup – three change controls.
Other
·
867_04 will be
changed Add gray box on REF=TN. Reword
from final usage to initial usage –
Roshni to write up change control.
814_PC/PD
Alternate
· Shell won’t be able to handle 814_PCs and 814_PDs at pilot open. They went to the PUC and asked about penalties. The PUC asked PIWG to see if a workaround is possible. The PIWG has charged SET to define the alternative process.
· This will probably be another file format of some sort. Shell’s system can’t handle 814_PC and 814_PD but can generate a CSV. The TDSPs said that the coding for an 814_PC or 814_PD has already been done, and to code an alternate 6 weeks from pilot is a major issue.
· Shell will do GISB EDI, eventually, but it is an issue of timing. Shell might be ready for 3rd or 4th quarter. PCs and PDs are pilot only.
· Shell has developed an alternate format. Any TDSP not wanting to do this should be at PIWG May 1st to argue against it. Whether or not an alternate is a good idea is a PIC issue, not a SET issue. The TDSPs say they have no time to code for something else and do not support an alternate, but this is not the forum. Endorsement of an alternate for PIC discussion doesn’t not translate into support for an alternate. There was discussion about other, non-electronic means such as an e-mail or fax with an Excel spreadsheet. This would be better than a CSV file. Phone calls may not be best due to the need for an audit trail, but e-mails or faxes would do. Other CRs might step up wanting to do the same thing.
· Discussion ensued concerning holding on to the 814_PCs and 814_PDs until Shell was ready, but there is a liability issue there.
· This would be an issue for TX Test as well.
· Shell would like to send on a weekly basis but could send on a nightly basis. Shell needs to put work into process flow. An e-mail back saying “we have it” could be appropriate. Shell will send the Excel spreadsheet via e-mail, batched weekly, but more often if they get a bunch, and will expect a response. Discussion took place about Shell only including the changes that need to be made, and that was rejected – it has to follow the EDI protocol – supplying all information that the equivalent EDI transaction requires. There was discussion by Exolink that they might take the Excel spreadsheet into a CSV file, put it into their system, and then send back an EDI 814_PD. Could Shell handle the EDI in return? This would be one less manual work-around step for the TDSPs.
· Shell will re-send out its proposal (to Heidi Schrab) including format, transport mechanisms (both ways), timing issues, and a complete process flow map. And it will be discussed at our next (non-change control) conference call. Shell will send out the proposal by next Tuesday, April 17th.
814_01
· Some MPs are not populating State Code in notification loop. They are providing City, Zip, but not State. Shirley Whyte advocating a change control to change gray box because there is confusion whether it is required. There is a problem cropping up. This will crop up whenever N1 and then the code N1 within the N1 exists.
867 Loop Usage Bulletin
· ITPTA, Shirley White, as a result of confusion, wrote up a PTD definition and use description. She points out that the PTD loops cannot be used in isolation, but in pairs. This will be sent out imminently for comment. Reporting of generation meters has to be added to this since there is a separate PP loop for generation. Jill and Shirley to work on it.
Review the RMS Procedures
Draft
·
Added 15-1.5.3 Notification of TDSP of move-out. When ERCOT receives a Move-out request and a
CR is not associated with the ESI ID, it will forward the SET 814_24 or its MIS
equivalent to the TDSP. ERCOT will
process Move-Out requests up to six times a day. The timing of ERCOT processing will be made available prior to
the Customer Choice Pilot.
Ø
This was in our flows. It is
simply a protocols gap.
Ø
After discussion, it was decided to take out the “and a CR is not
associated with the ESI ID”.
·
Added 15.1.5.4 Response from TDSP to Move-Out Request
Ø
The language got modified here so that the TDSP sends (1) ESI ID and (6)
Move-out date (if different than requested date). This information shall be transmitted in accordance with SET
814_25.
·
ERCOT Protocols need to document the 814_13 received from the TDSP for
move-in or move-out date changes will be forwarded by ERCOT to CR.
·
Move-in or move-out data change (15.1.5.7). The process change proposed here is that if the change date
requested by the customer is earlier than the previously requested date, the
TDSP will respond with the Date Change Response within “x” hours in accordance
with the SET 814_13 if the date change cannot be accommodated. If
the change date requested by the Customer is later than the previously
requested date, the TDSP will respond with the Date Change Response within
“y” business days in accordance with
SET 814_13. The “x” and the “y” need to
be supplied by the TDSPs after checking what is possible. There was discussion about allowing 2 days
for all notifications from the TDSP because that’s what is currently stated by
protocols. After discussion, it was
decided to take out the timing issue out of it.
·
Same Day / Next Day
Move-ins (15.1.4.1, 15.1.4.3-6). There
was a discussion about how to handle expedited move-ins. This is a bigger issue than RMS. This may need to be a workshop /
meeting. It could be by phone call by
the customer to the TDSP or the CR to make it happen, with follow-up EDI or MIS
equivalent . The EDI codes don’t yet
exist for follow-ups for a move-in that’s already happened.
·
Move-in unexecutable
– leave it for a workshop
·
Issue 5: Premise
Information when Meter Info Unavailable – Going to a workshop.
·
Issue 6: Mass
Customer List: – Cary Reed will bring it forward from something Don Bender of
AEP has used.
Move-in/out
during Pilot – Pseudo Move-in
·
During Pilot, TDSPs are also CRs.
For 95% of customers, TDSPs would
have to do move-in’s, move-outs on 95%, etc. Legacy systems weren’t designed to handle this. There have been several meetings with ERCOT
and TDSPs to create workarounds.
·
If customer calls and wants to be reverted to TDSP, TDSP will take
information from customer, then call CR and get the CR to initiate a drop to
POLR.
·
A pseudo-move in is a file format worked out between TDSPs and ERCOT to
say, here are all of our move-ins today.
This will be new ESI IDs, and then a file to have ERCOT knows it is
energized. The pseudo-move in process
won’t be ready until August. If the
customer then wants to be in pilot, on June 1st, there is a problem
because pseudo move-in won’t be ready.
For the 2 months, there was a discussion about not letting the customer
participate or creating a work-around for the work-around. There is a potential issue here.
Rejects at ERCOT
·
What would be the
appropriate error code for the case during Pilot in which ERCOT sends an 814_03
to the TDSP, but there is no 814_14 PA-PB set of transactions? Would it be the A83, Invalid or Unauthorized
Action? It seems incorrect to return
"Invalid ESI-ID". We should
find out what ERCOT has programmed to.
It may be an A13. We’re waiting
for an answer. Shirley Whyteand Mike
McCarty will follow through.
·
In theory ERCOT
would have rejected the 814_01 with the 814_02 – ESI ID not eligible.
Muni – Coop Invoice
·
Johnny Robertson has
tried a few times to contact municipal / cooperative personnel. We haven’t heard. We would like to go to baseline.
We do have a draft. The next
step is to go to RMS with the draft, and RMS can say, here it is, TX SET needs
feedback, and will give them a time frame.
It was agreed that we would go to RMS.
·
We might need to add some language to the gray box in the BGN06 of the
814_08 Cancel Switch Request.
1. Customer chooses New CR 2. New CR enters the 814_01 (BGN02: reference
number ABC) 3. ERCOT sends Current CR the 814_06 Drop due
to Switch (BGN02: reference number 123, BGN06: reference number ABC) 4. Customer claims slamming - tells ERCOT 5. ERCOT sends Current CR an 814_08 Cancel
Switch Request (BGN02: reference number 456, BGN06: reference ABC) OR 6. ERCOT sends
Current CR an 814_08 Cancel Switch Request (BGN02: reference number 456,
BGN06: reference 123) |
Shouldn't the BGN06
reference the transaction that should be cancelled? Since the Current CR never received the 814_01, 814_10 or
814_24 we need to show some reference to the 814_06 in the gray box.
gray box on 814_08, BGN06
reads:
"Refers
to the BGN02 of the...
... Enrollment Request (814_01),
... Drop to POLR Request
(814_10),
... Move Out Request (814_24).
This number will
be tracked in the BGN06 through the life-cycle of the respective process."
·
We need to find
out what ERCOT is doing. Heidi is going
to send the issue to Mike McCarty to find out which ERCOT is doing. We are hoping that ERCOT is using ABC.
867_01
Usage Corrections
·
TDSP billing systems include functionality for correction of current and
prior period usage history. This is a
requirement of most utility information systems, as 100% accuracy in the
gathering and reporting of meter readings is not attainable. This means that, despite best efforts, X% of
the usage history information that will be loaded into the ERCOT database
during conversion will be incorrect.
·
TDSPs want to keep sending 867_01’s until they are correct. ERCOT would prefer 867_03’s to correct
history. This is because the
environment for initial load and for production are different – they don’t want
to maintain staffs for initial load.
·
Mike McCarty
taking back to ERCOT to follow through.
The preference from TDSPs is to use the 867_01.
Move-In
– Move-Out Process
·
Christine Melro
sent around the following process, and asked if it were correct:
PILOT MOVE-OUT / MOVE-IN SCENARIO
(INELIGIBLE ESI ID AT NEW PREMISE): John Smith enrolls for Pilot with CR 1 on
March 1st in TDSP A's territory. On
July 29th, John notifies CR 1 that he will be moving on September 17th to
another premise in TSDP A's territory.
He would like to remain with CR 1 and have them make all necessary
arrangements for his move-out and his move-in. The new premise is not yet eligible to participate in Pilot
being that the last tenants opted not to participate. If the Pilot is not full on July 29th, my
assumptions for the transactions are as follows (dates are approximated): July 29th
(1) CR 1 sends an
814_24 (Move-Out Request) to ERCOT (which is a pass through to TDSP A) (2) CR 1 sends an 814_PA to
TDSP A with the new premise's ESI ID to make the new ESI ID eligible for
Pilot July 31st
(1) TDSP A
receives the 814_24, processes the move-out, and sends back an 814_25
(Move-Out Response) to ERCOT (which is a pass through to CR 1) (2) TDSP A sends
an 814_20 to ERCOT with the eligibility date of July 29th to make the new ESI
ID eligible for Pilot `
(3) TDSP sends out 814_PB.
(this was added at the SET meeting). August 2nd
(1) CR 1 receives
the 814_25 (Move-Out Response) (1)
CR
1 sends an 814_16 (Move-In Request) to ERCOT (which is a pass through to TDSP
A via the 814_03 unless ERCOT rejects the request with an 814_17 (Move-In
Reject) August 3rd
(1) TDSP A sends
an 814_04 to ERCOT in response to the 814_03 August 4th
(1) ERCOT sends an
814_05 to CR 1 as a pass through of the 814_04 *At some point, the 814_PC will be submitted by CR 1 to TDSP A to
update customer information at the move-in premise. |
·
With the
italicized addition under July 31st, the process is correct.
·
Check with ERCOT
that, after June 1st, is current date equal eligibility date. Are they checking the eligibility date? If a
date is sent in that is prior to the current date, will it get rejected? This was flagged by the use of July 29th
in the July 31st step.
·
If for some reason
everybody is committed but the 867_03 doesn’t get in on time, what
happens? Shirley and Mike to follow up.
For
example: Customer A is with REP 1 Customer A moves out Customer B moves in and
chooses REP1 Customer B moves out Customer C moves in and
chooses REP1 TDSP
sends Outstanding Discretionary Charge after Final Invoice... who is it for? Also,
are there any rules around how long a TDSP has to send such an invoice...
obviously if too much time goes by, it would be very difficult for the REP to
collect. Does
this invoice fall into the same parameters as others in regards to being due
in 35 days? |
·
Discretionary
charges will come in on a cycle bill, normally. But if charges come into after the final bill, how will accounting
be done? The TDSP will know what
service order it is tied to, and therefore what customer it belonged to.
·
It
was discussed that there may be no practical way to handle this with the EDI
transactions. A phone call can
straighten this out.
·
Kim
Wall would like to submit a change control to remove any language about
discretionary charges after final bill.
·
There
will be a development of a change control not to remove discretionary charges
after final bill, but to instead develop a special code for BIG07 or BIG08 for
discretionary charges after final bill and for final bill.
·
Shirley
Whyte pointed out that the examples are not correct and need work. There was discussion about a Version 1.3a
just to fix the examples, not the coding (unless somebody messed up due to a
bad example). The late payment charges
were pulled out into a separate 810 going to version 1.3 from 1.2, but the
examples didn’t change along with the substantive change. There was push back about the idea of a
Version 1.3, even if there is no coding change, because systems people will go
through line by line and won’t believe there were no coding changes.
·
Mike
McCarty offered to put up “corrected examples” for 810_02 posted on web site
right next to 810_02, with a red flag.
The 810 is documented, already, in a change control. We need to add a cover page to say this is
corrected examples for 810_02. Kim Wall
assumed responsibility.
·
We
could do this for 867’s as well. The
867 examples will be done by Jill and Shirley Whyte.
·
The customer
protection rules require that the Historical Usage be for the customer (i.e.,
not the premise). But the TDSP may not
necessarily know if the customer has or has not moved. What are the TDSPs planning to send... customer history or premise history? All TDSPs are sending premise history.
·
There is a
conflict between T’s & C’s and customer protection rules. TDSPs will send 12 months history regardless
of customer – i.e., premise history. It
might be worth adding a gray box that the TDSPs will be sending premise history
when available. Kim Wall to submit this
change control.
Data
Element Matrix
·
Roshni and Kyle
will review the data element matrix to ensure that it is up to date.
·
Per Customer
Protection, section titled “Privacy of Customer Information” for all customers
eligible for price to beat shall be included on the mass customer list – Name,
billing address, rate classification, monthly usage for the most recent
12-month period, meter type, and account number or ESI ID. Maybe a csv format. Issue discussed RMS, AEP will provide
starting point document.
·
Cary Reed already
sent a copy to Heidi, but in Heidi’s transition to Green Mountain Power, it got
lost, and has been re-sent. So it will
be brought up at the next meeting.
Version
1.3
·
Mike McCarty asked
everybody to call back home and inform them that Version 1.3 of TX SET EDI is
baseline and is what will be used for pilot.
Some people were apparently confused about that and wanted to use different,
older versions. Version 1.3 will.
Permits
·
On the last patch
list, there was an item for the 814_04, requesting the addition of the code PRM
to the 1P. It did not make it to
version 1.3.
·
Update from the
Permit workshop on 4/5. Document and
present “during Pilot” solution and “Choice” solution will be presented to
RMS. The REPS and TDSPS agreed that
the TDSPs will hold the orders. Entergy
voted against, TNMP abstained, SPS not there.
·
TDSPs can send
back complete unexecutable. During pilot, if you choose to use 650’s for
service orders, TDSPs can send back a 650 complete unexecutable because you
need a permit. You need to develop a
workaround to support 814’s during pilot.
There is nothing in an 814 dealing with permits. Every time you haver a move-in, you need a
permit in some parts of TX.
Therefore, since the 814’s can’t handle the permit issue, phone calls or
other means need to be employed.
·
BJ Flowers to send
a copy of the Permit workshop minutes to Fred Plett to post out with the TX SET
minutes on the TX SET list serve.
Web Portal During Pilot
·
Portal will be
ready for pilot, and will be ready for testing May 15th. Shell heard some rumor that if they send
something by portal, they could get an EDI response back, or vice-versa. Mike McCarty thinks that this is
incorrect. Shell is to get
clarification from Cherie Broadrick.
·
ESI ID lookup
won’t be available until after conversion, and when the portal is
available, Randy Brannon to check this
out further.
·
What is the
difference between the 814_24 and the 814_03 in regard to the flow from ERCOT
to TDSP ? The 814_24 indicates all the
way through that it flows from the CR to ERCOT, and ERCOT sends it on to the
TDSP. The 814_03 says it is passing the move out date from ERCOT to
the TDSP that was initiated by an 814_24 generated by a CR. The following two bullets fairly answer the
question:
·
The
814_24 is in support of an actual tenant move-out. When the TDSP receives the 814_24 the TDSP knows to de-energize
(remove, sleeve, power no-longer flowing, etc.) the premise and remove the
association of a CR.
·
The
814_03 is in support of a Continuous Service Agreement (CSA) move-out. A “CSA is an arrangement between the owner
or controller of a leased premise and a CR wherein the CR provides service to
the leased Premise between tenants so that the Premise does not experience
discontinuation (energized) of electric service during vacancy”. When ERCOT receives the 814_24 and a CSA CR
exist, ERCOT will submit to the TDSP the 814_03 ( LIN~MVO, DTM~MRR (move-out
date from the 814_24) to switch the premise to the CR noted in the transaction.
·
CRs will send 814_01
enrollment transactions to the RA on 5/31 [in batches of 1,000] – not on
5/25. These transactions will be
processed sequentially based on who was in first. These transactions no longer need to be sent by meter read date.
[The Commissioners expressed the belief that the meter read cycle data that
some utilities have stated they will be able to provide to REPs will serve to
ease the big bang to some degree. For
those utilities that indicated they will be unable to provide such data, the
Commission requested that this decision be re-evaluated.]
·
ERCOT will begin
accepting 814_20 (change eligibility date) transactions on 4/17. ERCOT will “hold” these transactions. TDSPs are encouraged to send the 814_20
transactions as soon as possible.
·
ERCOT will hold all
these transactions until 4/27.
·
From 4/27 to 4/30,
ERCOT will have a blackout period.
During this time, TDSPs should not send any transactions to ERCOT.
·
From 4/30 to 5/6,
ERCOT will process 814_20 transactions and data conversion files that were
being “held”.
·
After 5/7, ERCOT
will process 814_20 transactions on a day-by-day basis.
·
After 6/1, CR will
continue to send 814_PA to TDSP. From
that point, CRs should wait 2 days to submit 814_01 transaction to RA to allow
TDSP time to send 814_20 transaction to ERCOT.
CSA
Discussion
·
There are no CSA’s
during pilot. The TDSPs will have to
keep track of its own equivalents to a CSA.
If the TDSP has an agreement with a landlord, and during pilot, a tenant
participates in pilot, and then moves out, the TDSP has to keep track and
ensure that de-energizing does not take place because there is still a valid
and binding agreement in place with the landlord. If the CR sends a move-out, the TDSP will have to process it as a
switch.
·
When will mailboxes be ready to receive transactions? Transitional
mailboxes are ready now. TDSPs can send
starting on 4/17 for change of eligibility date, 5/31 for enrollments. These mailboxes will be in a
transitional stage, not in a production environment. It is possible that materials could be lost
during cut-over to production. It is
not clear when cutover to production mailboxes will occur.
·
What is the
"processing times" schedule by transaction for ERCOT?
Ø ERCOT will continue sweeping mailboxes, converted to
XML, put into buckets (867’s in one, 814’s in another for example, and then
processed.
Ø Timing is still being worked out when the messages
are being processed, in what order, and how frequently.
·
Meeting protocols –
We get RSVPd by 5 people, 30 show up, or the opposite. Setting up meals is a problem. The meeting notice needs to have an RSVP
schedule by a certain date to the meeting host, as it does now, but the meeting
host will send out a confirmatory e-mail stating who he or she has received
RSVPs from, and a note that if you didn’t send an RSVP, don’t plan on coming
unless one is received within 24 hours.
If plans change, please inform the host so that meals can be properly
scheduled.
·
It was decided that
meetings would go 9-5 the first meeting day, and 8:30 – 1:00 the second day,
with no lunch provided on the second day.
·
If a premise is de-energized, and the TDSP sends an 867_03 to ERCOT will
ERCOT reject the transaction? NO
Action Items
·
Heidi Schrab to send
out reminder to people to find out whether TDSPs are sending channel numbers
for cases in which there is one channel per measurement type (say one channel
for kWh, another for kW), whether we’re using channels at all, and whether we
send channel number where there is more than one channel measuring the same
quantity. Heidi also to bring business
issue up to RMS.
·
Roshni Ghelani-Patel to write change control to 867_04. It will be changed Add gray box on REF=TN. Reword from
final usage to initial.
·
Roshni and Kyle Patrick will review the data element matrix to ensure
that it is up to date.
·
Shell to develop an
Excel file format as a work-around for
814_PC and 814_PD. TX SET to discuss
4/11/2001 and then it will go to PIC.
·
Shirley Whyte to
send out imminently an explanatory paragraph for PTD definitions and use in
867s.
·
Mike McCarty and
Shirley Whyte to follow up on question about 867-03 – what happens if it
doesn’t show up in time,in move-in and move-out process, and to check if ERCOT
is checking eligibility dates.
·
Heidi to ask Mike
McCarty ERCOT’s implementation of the BGN06
of the 814_08 Cancel Switch Request.
·
Jill Prince and
Shirley Whyte to work on 867 examples.
·
There was a
discussion about needing to code to Version 1.3 but there were purported
statements by the ITPTA that participants won’t be penalized to code beyond
that to an approved change control.
Dave Robeson with Kim Wall’s help to bring this back for clarification
to the ITPTA because this could cause mis-matches between market
participants.
·
ERCOT needs to set
up conference call for 4/25 and 4/26, 9-11 AM CDT. Agenda – 867 issues on first day, 814 PC and PD issues (Shell
alternative) and, day 2, RMS issues that come back to us.
·
Any suggestions concerning
procedures, processes, etc. should be submitted to BJ Flowers by next
Wednesday, April 18th.
Next Meetings
There will be an
extended conference call on 4/25 and 4/26, about 2 hours each day, to replace
the meeting that was supposed to have happened on those dates.
5/9-10 Wednesday and Thursday 8:30 – 5:00. Houston, hosted by Shell. Location TBD, Shell will inform Heidi.
*Conference calls for SET
Change Controls will be at 2PM on Wednesdays.
Open Issues List |
|
|
Date |
Issue |
Approach |
12/20 |
1) 814_28/29 – PC and PD 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. This issue has not yet been brought to RMS. If we are going to do 814_PC and PD type
materials in open market, the intent was that this would flow through ERCOT,
but ERCOT pushed back and said they don’t want it to go through ERCOT at this
time. The open issue is that changes
need to take place in EDI transactions and protocols for RMS consideration. We need to take change Change Controls
2000-22 and 2000-25 to the next level.
These change controls give a history and narrative. They were approved in concept. ERCOT would need to change its system to
handle it. If we get protocols
changed, ERCOT will support this.
Timing is an issue. This is in the Ts&Cs and is expected to be
resolved for the Phase II of the ERCOT time frame. |
Needs to go to RMS. Heidi Schrab as Chair was assigned the
action to bring it to RMS. She can
reassign if necessary. We will send
the Change Controls 2000-22 and 2000-25 with some additional language to RMS
as a vehicle to request action from RMS.
A change in protocol language needs to come from the RMS group, not TX
SET. |
1/24 |
Muni/Coop Invoice |
In progress. |
3/21 |
Future method to reject 820 for bad ESI-ID, bad
invoice #, etc. The approach is to
see how this goes through pilot, and then revisit the issue. It was suggested that a subgroup needs to be formed to
put together a change control and determines when it needs to be done by to
get into a Phase II, including testing, and preparation time for
participants. It would kill people
now because we’re in the middle of test, but scheduling in mid-June or so for
a working group meeting might be in order.
This would be broader than just this 820 issue. We can recommend to RMS a need for an 824 reject. This is an issue for market participants
to bring to bring back to their companies to see if the companies will
support a line-item reject via an 824 reject mechanism. To be discussed in our next meeting, the
conference call meeting. |
To be discussed in our next meeting. Participants need to check whether they
will support a line item 824 reject for bad invoice #, ESI ID, etc. |
|
|
|
Items Closed
at this Meeting: |
|
|
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 ESI ID
level? Credit balance on an ESI ID? 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. |
TX SET does not have a requirement to do anything with
EDI for overpayments or credit balances.
Any issue on this needs to be brought to RMS by the party concerned. |
1/31 |
Submit a Protocol change for Move-in Un-executable (not
for overbooking) |
Assignment made in this
meeting to bring it to RMS for a workshop. |
3/21 |
“Tax” statement from the PUC – waiting for answer from
State Controller’s Office. We do not
allow tax segment at overall charge, just individual items. Does our EDI cover state tax issues on a
charge line item basis. This should
be a closed issue unless a TDSP revives it. |
This is a closed issue unless a TDSP revives it. |
3/21 |
Charges
not associated with consumption after the customer has switched away – The
TDSP 810 should not reference the 867.
We can change the 867 to optional, change the gray box, so that it is
not required for when the cost is not associated with an 867. Add a gray box
for late payment charges or invoices not used. |
This was initially change control 2001-63,
resubmitted as 2001-71, included in Version 1.3 so it is now a closed
issue. As a result of 810 review, a
new change control will be developed to add codes for late payment charges
and services orders not associated with consumption. |
3/21 |
TDSP
creates 814_20 for new customer to set a new ESI ID, while construction is
taking place. TDSP allows wire
installs, builds customer directly.
When the customer wants a meter, TDSP needs a CR. This is where the 814_20 comes in. Would get request on 814_03 and would get
a complete unexecutable. CR also
sends an 814_01 to ERCOT Enrollment request, and ERCOT will reject because
they don’t have the meter information.
The best solution could probably be send an 814_04 without meter
information, and then an 814_20 ESI ID.
This would require a modification to the 814_04. |
No change control needed. It is not a permit issue.
We are waiting for requirements to come back from RMS. RMS
Subcommittee will create the process. |
Attendance:
Name |
Affiliation |
Phone |
E-Mail |
Fred
Plett |
Logica |
603-497-3907 |
Plettf@logica.com |
Johnny
Robertson |
TXU |
214-812-2712 |
Jrobert1@txu.com |
Jill
Prince |
TXU |
214-875-1545 |
Jprince1@txu.com |
John
Wilkinson |
GE
GXS |
817-379-5001 |
John.Wilkinson@gxs.ge.com |
Jason
Wrubel |
Shell
Energy |
917-452-3633 |
Jason.M.Wrubel@accenture.com |
Paul
McKinney |
Shell
Energy |
713-241-6394 |
Dpmckinney@shellus.com |
Jill
Popelka |
TXU |
972-679-5064 |
Jill.popelka@txu.com |
Randy
Brannon |
TXU |
214-875-5182 |
Randybrannon@txu.com |
Carrie
Landis |
XCEL
/ SPS |
303-571-7310 |
Carrie.Landis@Xcelenergy.com |
Roshni
Patel |
Reliant
Energy |
713-207-8258 |
|
Dave
Robeson |
Entergy |
504-576-2571 |
Drobe90@Entergy.com |
Sharon
Polliard |
AEP |
918-594-2265 |
Spolliard@aep.com |
Shirley
Whyte |
ITPTA |
713-906-5124 |
Swhyte@mindspring.com |
Heidi
Schrab |
Green
Mountain Energy |
512-691-6104 |
Heidi.schrab@greenmountain.com |
Mike
McCarty |
ERCOT |
512-248-3959 |
Mmccarty@ercot.com |
Rita
Morales |
Entergy |
972-538-6983 |
Rita.morales@exolink.com |
Charles
Scheffer |
Reliant
Energy |
713-945-6630 |
Charlesscheffer@reliantenergy.com |
Kathy
D. Scott |
Reliant
Energy |
713-945-6630 |
Kathy_D_Scott@ReliantEnergy.com |
Dave
Bynoe |
Shell |
713-241-0429 |
Rbynoe@shell.com |
Kyle
Patrick |
Reliant |
713-207-3519 |
Kyle_Patrick@reliantenergy.com |
Nancy
Hetrick |
Enron |
712-366-3399 |
Nancy.Hetrick@enron.com |
Kim
Wall |
Green
Mountain Energy |
610-799-2740 |
Kim.Wall@greenmountain.com |
Bryn
Owen |
Energy
Services Group |
781-829-9956
x318 |
Bowen@energyservicesgroup.net |
BJ
Flowers |
TXU |
214-812-4330 |
Bj.flowers@txu.com |
Annette
Morton |
AEP |
214-777-1589 |
Ammorton@aep.com |
Ryan
Goldman |
Blackstone
Tech |
415-350-0326 |
Rgoldman@bstonetech.com |
Darrell
Hobbs |
TXU |
214-875-2204 |
Dhobbs2@txu.com |