I hope to clarify my earlier e-mail and answer your questions -

The "transmissionless" transactions that we developed business practice #11
around are CA to CA interchanges.  Historically, participants at the MIDC
would track purchases and sales of energy between each other as scheduled
interchange between their control areas.  The participants all have owned
and/or contracted transmission to/from their systems.  

When tagging came along, authoring PSEs for these MIDC deals just wanted to
do a tag with one source control area and once sink control area with no
transmission segments.  There could be a dozen marketers (thus, a dozen
title transfers) in the chain, but the tag would not indicate transmission,
just interchange between source and sink CAs (limited to CA participants at
the MIDC).  

At some point (1.5 or 1.6?) E-Tag required a tag to contain at least one
transmission segment.  The WSCC approached the IS to allow for no
transmission segments in a tag.  We were told no.  So, the business practice
of picking the source (or the sink) CA's TP to provide a MIDC-MIDC
transmission segment was adopted. 

Hope answers your question.

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.
> 
>  <<comments to IS letter.doc>> 
> 
> 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. 
> > >
> **********************************************************************
> > > 
> > > 
> > 
>