Message-ID: <24391166.1075840028985.JavaMail.evans@thyme> Date: Tue, 9 Oct 2001 09:57:35 -0700 (PDT) From: dempsey@wapa.gov To: mhackney@apsc.com, demetrios.fotiou@bchydro.bc.ca, csmith@caiso.com, dscholt@ect.enron.com, lgrow@idahopower.com, dlacen@pnm.com, bharsh@puget.com, sccobb@srpnet.com Subject: Re: FW: WSCC Tagging practices Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-From: JERRY DEMPSEY X-To: mhackney@apsc.com, Demetrios.Fotiou@BCHydro.bc.ca, csmith@caiso.com, dscholt@ect.enron.com, lgrow@idahopower.com, DLACEN@pnm.com, bharsh@puget.com, sccobb@srpnet.com X-cc: X-bcc: X-Folder: \ExMerge - Scholtes, Diana\STF\Current issues X-Origin: SCHOLTES-D X-FileName: Here's my input - Issue #1 may be difficult to implement if we allow multiple TP's to be stacked. I believe this requires a change to the E-tagging specification, which is not looked upon favorably even with the delay. Currently, we deny tags that try to stack TP's because spec 1.67 does not allow it (even though some vendors Agent's allow it to go through). Issue #2 - Seems like we may need a better solution somewhere - and I guess the debate is on. Overall - I agree with Bob that we may not want these issues at the NERC I.S. level yet - can ISAS or WSCC OC work on these issues first and then move them forward? Jerry >>> "Harshbarger, Robert" 10/8/01 11:24:59 AM >>> Okay - our exchanges of e-mail were suppose to improve mutual understanding and it seems to keep getting deeper as I go. Two issues - 1) putting multiple transmission providers on the same path on a tag (stacking of parallel providers), and 2) transmissionless interchange (business practice #11) Number 1 - don't we in the WSCC want the ability to have tags that can contain multiple transmission providers on the same path? For example PSEI, PGE, and BPAT are all TPs offering Johnday-COB service. There could be a transaction that would utilize a reservation with each provider and it would be most convenient to stack all that information in one tag. Andy suggests the WSCC might want to come-up with an alternative, such as one administrator TP for the whole path. Sounds like an RTO. So, if we have a choice, we prefer the ability to stack providers on a tag - yes??? Number 2 - the transmissionless interchange. I have been suggesting that we will continue on with our practice just using the TP that belongs to source (or sink) as stated in BP #11. Andy doesn't think that'll fly in 1.7. What really concerns me is his statement that "Under 1.7, a CA cannot exist without a parent TP." Funny, I always looked at it the other way around. I don't know what that means to SCL, CHPD, and other CAs who, up till now, have not registered as TPs. My example was a MIDC CA to CA transaction that has historically been at the bus without transmission. The participants have traditionally used their interchange accounting systems to record these deals as scheduled interchange with another CA. Transmission was not taken into consideration since the participants had owned and/or contract rights from MIDC to their systems. In addition, it has been an easy way to path-it-out by sinking it, then creating separate transaction source at the same place. I did feel that this issue shouldn't be brought to IS's attention - that we would just work it out with our business practices. What do you think? Bob Harshbarger > ---------- > From: Rodriquez, Andy[SMTP:Andy.Rodriquez@enron.com] > Sent: Monday, October 08, 2001 9:23 AM > To: Harshbarger, Robert > Subject: RE: WSCC Tagging practices > > Robert, > > With regard to item 1, solution C was to communicate that WSCC could > explore any number of other options and propose them to either its > members or to the IS. For example, TOs could be granted allocations of > rights sold through a single virtual Tariff Administrator. I guess the > real goal was to pull the IS out of the decision making process and give > the control to the WSCC, and if the WSCC said "we are going to do option > a or b," then that would be fine - provided that a CONCRETE practice was > defined, so that everybody in the WSCC did it the same. > > Item 2 will be a problem in E-Tag 1.7, because of how it deals with the > relationship between TPs and CAs. > > In 1.67, a CA can exist independent of a TP (hence the simple fix of > adding a single dummy TP). Under 1.7, a CA cannot exist without a > parent TP. I think this will cause problems. Theoretically, it is the > same answer as is used in 1.67, but I think it may be much more > confusing to many. I would propose a formal practice, registered in > Policy or some other document, that indicates how this is done (for > example, create a virtual TP called "WSCC Title Transfer" and have WSCC > entities use that specific TP, or something like that). This would go a > long way to reducing confusion about how each CA does business (I have > been told it varies form company to company, and even sometimes from > shift to shift). > > In your example, you indicate that "fake" transmission is being used. > You also indicate that there is no CA to CA interchange occurring. What > is indicated by going from the PSEI control area to the PCW control > area? If this is a title transfer, then it has been tagged incorrectly. > The only other interpretation I can make is that the energy is moving > from the PSEI control area to the PCW control area. You previous > discussion seems to support this also. I am not sure how dynamic > schedules or grandfather transmission relate, as those are required to > be tagged also, as they should be using transmission service. I know > the WSCC has been violating that practice, and recently sought an > exemption form the IS, but at this point, the exemption has been denied. > > I would appreciate an explanation, as I am unsure I yet understand what > is happening. Is it a title transfer, or is it interchange? > > Andy Rodriquez > Regulatory Affairs - Enron Corp. > andy.rodriquez@enron.com > 713-345-3771 > > -----Original Message----- > From: Harshbarger, Robert [mailto:bharsh@puget.com] > Sent: Monday, October 08, 2001 11:03 AM > To: Rodriquez, Andy > Subject: RE: WSCC Tagging practices > > > Comments were inserted in your letter contained in the body of your > original > e-mail. I've copied and pasted that text into a Word document - > formatting > all screwed-up. > > <> > > The posted WSCC business practice #11 reads: > > For transactions that occur at only one bus (i.e. no OASIS/GF > transmission > involved) use a willing TP on the second line with the same PSE as on > the > first line and the words "Single Bus" in the OASIS reservation field and > "7-F" as the Product. > > Guess we need to understand what it is about 1.7 that prevents someone > from > creating a tag for these types of transactions. > > A related issue to this is there CAs that are not registered as TPs. > So, > when Seattle City Light sells to Chelan PUD at the MID-C, who does the > transmission segment of the tag. Neither has registered as a TP. So > the > transaction just doesn't get tagged. > > Bob > > > > ---------- > > From: Rodriquez, Andy[SMTP:Andy.Rodriquez@enron.com] > > Sent: Monday, October 08, 2001 7:14 AM > > To: Harshbarger, Robert > > Cc: Hackney, Mark; Grow, Lisa; DEMPSEY, JERRY; McIntosh, Jim; > Lacen, > Don > > Subject: RE: WSCC Tagging practices > > > > Bob, > > > > I did not get your attached file. Please resend. > > > > I know that there is fake transmission that is supposed to be used > > today, but I continue to see situations where that is not applied. As > > it stands today, the incorrect practice will function under 1.6, but > not > > under 1.7. As such, I would like to see a definitive 1.7 practice > > defined and listed someplace so that ALL of WSCC has to follow the > > practice. Otherwise, our West desk has no idea what is right or > wrong, > > and they end up having to memorize the ways that each provider likes > to > > see their tags. That is unacceptable. > > > > Andy Rodriquez > > Regulatory Affairs - Enron Corp. > > andy.rodriquez@enron.com > > 713-345-3771 > > > > -----Original Message----- > > From: Harshbarger, Robert [mailto:bharsh@puget.com] > > Sent: Friday, October 05, 2001 7:57 PM > > To: Rodriquez, Andy > > Cc: 'Hackney, Mark'; 'Grow, Lisa'; 'DEMPSEY, JERRY'; 'McIntosh, Jim'; > > 'Lacen, Don' > > Subject: FW: WSCC Tagging practices > > > > > > Andy - > > > > I marked-up your draft letter with comments. > > > > The second issue should be removed. Our current practice is to > specify > > fake > > transmission for these bus to bus control area interchanges. I think > > that > > will still be possible in 1.7. In any event I inserted some related > > comments in that section, too. > > > > Robert Harshbarger > > Puget Sound Energy > > OASIS Trading Manager > > 425.882.4643 (desk) > > 206.604.3251 (cell) > > > > > > > ---------- > > > From: Rodriquez, Andy[SMTP:Andy.Rodriquez@enron.com] > > > Sent: Friday, October 05, 2001 8:26 AM > > > To: osc@nerc.com > > > Subject: WSCC Tagging practices > > > > > > Please review this letter and make sure it is correct. These issues > > > were brought up in our Phoenix tag training. I will plan on sending > > to > > > the IS Monday morning. > > > > > > > > > Members of the IS, > > > > > > In our recent E-Tag 1.7 Training sessions, we had two common issues > > > brought up regarding the way tags are handled in the WSCC. We would > > > like your guidance and assistance in regard to these issues. > > > > > > 1.) Jointly owned transmission > > > > > > In the west, several jointly owned transmission facilities exist. > In > > > these situations, one particular line or path is managed by operated > > > within a single > > > control area, but has several different Transmission Owners. In the > > > East, I believe that we address this situation by having one entity > > > administer a single OATT and the TOs receive transmission revenues > as > > > distributions from the administrator of the OATT (much the way that > > SPP > > > or MAPP distribute regional tariff revenues to their members). > > > > > > In the west, they have taken a somewhat different approach. In this > > > case, each TO administers their own tariff. So it is possible that > a > > > transaction could utilize more than one TP on the same transmission > > > segment. In such a situation (and > > > common practice) for a tag to be written that could "stacks" TPs. > So > > we > > > might > > > see in a tag a three transmission providers all flowing on the same > > path > > > within the same Control Area: > > > > > > CA TP OASIS PATH > > > > > > AAA AAA 123456 POINTA/POINTB > > > AAA BBB 234567 POINTA/POINTB > > > AAA CCC 345678 POINTA/POINTB > > > > > > Is this representation of the transaction's physical segment valid? > > We > > > perceive several potential have two solutions: > > > > > > a.) Tag as above for convenience > > > b.) Tag as a separate tag for each TP > > > c.) Indicate to WSCC that process is invalid, and let them determine > > > their own solution [note: there are only two possibilities here. > > Solution > > > c suggests a PSE can not buy transmission from multiple providers > for > > the > > > same path]. > > > > > > Some concerns have been raised by some WSCC members that "solution > a" > > is > > > might be difficult during curtailment processing, as it is hard to > > > determine > > > which cuts should be made at what points. However, other entities > > point > > > out that the tag does represent energy flow along a single contract > > > path, and the "stacking" really only identifies contractual > > > relationships (and as such, should be allowed). > > > > > > Regardless of how the issue is resolved, we encourage the > development > > of > > > a standard method for handling this situation, and believe that > > standard > > > should be developed by either the WSCC or the IS. > > > > > > 2.) Control Area Bus Transfers > > > [note: I'm not sure we can include this second issue because of the > > size > > > and scope of the issues surrounding it. 1.67 has required a minimum > > of > > > one transmission segment in the tag and the WSCC worked around this > > > requirement by using fake PTP transmission segments. The same > should > > > probably work for 1.7]. > > > > > > In the west, there is the practice of moving energy to different > > Control > > > Area entities at a bus. In the east, I we accommodate this through > > > title transfers and consider it a market mechanism rather than an > > > operations mechanism. For example: > > > > > > Merchant MMMMMM Generates 100MW in Control Area AAAA > > > Marketer NNNNNN buys at the bus and sells to OOOOOO > > > Marketer OOOOOO buys at the bus and sells to PPPPPP > > > Marketer PPPPPP buys at the bus and wheels from AAAA to BBBB... > > > > > > In the WSCC, such transactions are tagged in a different manner. > > > [note: MIDC is not tagged like this - everyone is a PSE except for > the > > CA > > > generating and the CA sinking or wheeling away from the MIDC. There > > is > > > not any CA to CA to CA to CA interchanges as long as the energy > > doesn't > > > leave the bus.] > > More typical are direct transactions specifying "fake" > > transmission > > (especially real-time): > > > CA TP PSE OASIS PATH > > INFO > > PSEI PSEMKT G@MIDC > > PCW PCW PAC01 NOR MIDC > > L > > > > > The WSCC practice is not currently supported by E-Tag 1.7. The > > > structure of E-Tag 1.7 is predicated on the fact that energy cannot > > move > > > between Control Areas without use of transmission. > > > > > > Historically, participants at the generator bus have found it more > > > efficient to track these energy exchanges at the bus as scheduled > > > interchange between their respective control areas. In addition, > they > > > typically have owned transmission and/or long-term, grandfather > > > transmission rights to move energy to/from the jointly owned bus to > > their > > > systems via dynamic schedules. > > > > > > This issue has recently been discussed by the IS with regard to such > > > situations where transactions use NO transmission (i.e., energy > moves > > > between CAs across bus, with no transmission service). If I > remember > > > correctly, the IS discussed several different issues: > > > > > > How can a single bus be simultaneously metered in several different > > > Control Areas? > > > If no physical movement of power occurs, why are these transactions > > > tagged? > > > If the power DOES move (even across a bus) then shouldn't that > > movement > > > be accomplished under a tariff? > > > > > > As I remember the IS resolution, it was decided that such > transactions > > > should indicate the use of PTP transmission if indeed power is > moving > > > between Control Areas. Otherwise, the market turn approach used in > > the > > > East (illustrated in the first example) should be utilized. > > > > > > This specifically becomes an issue, as E-Tag 1.67 would allow the > > > current WSCC practice and 1.7 will not. We would encourage the IS > to > > > make sure WSCC is fully prepared for this situation, and has WSCC > > > practices in place that address this issue. > > > Andy Rodriquez > > > Regulatory Affairs - Enron Corp. > > > andy.rodriquez@enron.com > > > 713-345-3771 > > > > > > > > > > ********************************************************************** > > > This e-mail is the property of Enron Corp. and/or its relevant > > affiliate > > > and may contain confidential and privileged material for the sole > use > > of > > > the intended recipient (s). Any review, use, distribution or > > disclosure by > > > others is strictly prohibited. If you are not the intended recipient > > (or > > > authorized to receive for the recipient), please contact the sender > or > > > reply to Enron Corp. at enron.messaging.administration@enron.com and > > > delete all copies of the message. This e-mail (and any attachments > > hereto) > > > are not intended to be an offer (or an acceptance) and do not create > > or > > > evidence a binding and enforceable contract between Enron Corp. (or > > any of > > > its affiliates) and the intended recipient or any other party, and > may > > not > > > be relied on by anyone as the basis of a contract by estoppel or > > > otherwise. Thank you. > > > > ********************************************************************** > > > > > > > > >