I agree with Bob on #1.
I am indifferent on #2, but will vote with Bob because he is a nice guy.

> ----------
> From: 	Harshbarger, Robert[SMTP:bharsh@puget.com]
> Sent: 	2001, October, 08 10:24 AM
> To: 	'Hackney, Mark'; 'Grow, Lisa'; 'Lacen, Don'; 'DEMPSEY, JERRY';
> 'Cobb, Steven'; 'Scholtes, Diana'; 'Smith, Chris'; 'Fotiou, Demetrios'
> Subject: 	FW: WSCC Tagging practices
> 
> 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.
> > 
> >  <<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. 
> > > >
> > **********************************************************************
> > > > 
> > > > 
> > > 
> > 
>