Message-ID: <30328948.1075840029116.JavaMail.evans@thyme>
Date: Fri, 5 Oct 2001 12:17:29 -0700 (PDT)
From: bharsh@puget.com
To: isas@wscc.com
Subject: FW: WSCC Tagging practices
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-From: Harshbarger, Robert <bharsh@puget.com>
X-To: Interchange Scheduling & Accounting Subcommittee (ISAS) <isas@wscc.com>
X-cc: 
X-bcc: 
X-Folder: \ExMerge - Scholtes, Diana\STF\Current issues
X-Origin: SCHOLTES-D
X-FileName: 

FYI 

> ----------
> 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 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 (and
> common practice) for a tag to be written that "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 procedure valid?  We perceive several potential 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
> 
> Some concerns have been raised by some WSCC members that "solution a" is
> 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
> 
> 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.
> 
> Merchant MMMMMM Generates 100MW in Control Area AAAA
> The energy moves from Control Area AAAA into Control Area NNNN
> The energy moves from Control Area NNNN into Control Area OOOO
> The energy moves from Control Area OOOO into Control Area PPPP
> Marketer PPPPPP buys at PPPP and wheels from PPPP to BBBB...
> 
> 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.  
> 
> 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. 
> **********************************************************************
> 