FW: ESC Conference Call to discuss Business Practices ,
 fyi.  I work with Sharon on the OSC.

-----Original Message-----
From: Miller, Sharon R [mailto:sharon.r.miller@xcelenergy.com]
Sent: Wednesday, January 30, 2002 1:05 PM
To: estf@nerc.com
Subject: RE: ESC Conference Call to discuss Business Practices


I have to caution against copying the S&CP 1.4, or the closely related
Order 638, into the OASIS Phase 2 business practices. They should merely
be reviewed to avoid missing anything.  Copying in parts of Order 638
have already created direct conflict between some of the business
practices.  It's important to remember that the S&CP 1.4 is the solution
to business needs that existed 2-5 years ago and that were a much
smaller subset of the business needs of OASIS Phase 2.  Slapping an old
solution onto a new problem is rarely, if ever, advisable.  

There is a lot of technical implementation detail in Order 638 that
should be avoided in the new business practices.  Instead the BPs should
focus on WHAT (business requirements). The HOW (design & implementation)
should be covered by the new S&CP.  For instance, instead of covering
the specific state change of "COUNTEROFFER", cover the general business
processes of negotiation.  Nothing in the BP's even says that
negotiation can occur, much less what can be negotiated. Is it just
price, or is it capacity and time as well, or is it something else?   

I'd suggest you start by defining what the transmission products are.
The existing definitions don't fit some of the BP's. 
Then cover the processes for obtaining them.  For instance:
- Buyers submit requests for what and to whom? (source to sink submitted
to many sellers all at once, or partial path to one seller at a time?
What data is required or optional?  Can they agree in advance to accept
the current posted price? Can they agree in advance to accept whatever
capacity is available?)
- Sellers do what with the request? (negotiate terms, approve request,
reject request according to what rules, etc)
- Buyers do what during negotiation process? (accept terms, suggest
other terms, match another buyers bid, reject the terms, etc.)
- Buyers do what with their transmission right? (use them as they are,
don't use them, use them on a different path, sell part or all of them
to someone else, reassign part or all of them to someone else, defer
them to a later time period, extend them beyond their original time
period, etc).

If these types of "what" questions are answered thoroughly, then the OSC
will be able to define the right architecture, communication structure,
state transitions, etc. to meet the business needs.

Sharon Miller
IBM 
representing Xcel Energy
612-330-5946
  






-----Original Message-----
From: John_Calder@dom.com [mailto:John_Calder@dom.com]
Sent: Wednesday, January 30, 2002 8:12 AM
To: pterris@pwrteam.com; mcelhany@wapa.gov
Cc: estf@nerc.com
Subject: Re: ESC Conference Call to discuss Business Practices


Patt,

I think many of your questions about Business Practice 2 could be
resolved
by including the definitions and state diagram from the OASIS 1.4 S&CP /
Order 638.  (I pulled out a copy of the definitions, but could not grab
the
diagram from the pdf file, so I attached the entire 1.4 document.  The
definitions appear on pages 26-28, and the state diagram is on page 29.)
I
also threw out my responses, for whatever they are worth, to your
questions
in the body of your email.

Mike,

Although the wording for these standards in BP 2 is taken directly out
of
Order 638, in looking at the State Diagram, it appears to me that
"SUPERSEDED" should be included in Standards 4.6, 4.7, and 4.12 , and
that
"DECLINED" and "SUPERSEDED" should be included in Standard 4.6.VI.

Is there a reason that we are trying to make this our stand-alone
document
instead of just endorsing the Standards as they appear in Order 638,
taking
exception or recommending changes where necessary?  Using Patt's email
as
an example, it seems like we are taking a big risk of missing something
if
we just take bits and pieces of a document.


John Calder
Dominion Virginia Power

(See attached file: OASIS1-4SCP-rm95-9-final.pdf)


     The possible STATUS values are:

                  QUEUED =       initial status assigned by TSIP on
receipt
                                 of  "customer services purchase
request".

                  INVALID =      assigned by TSIP or Provider indicating
an
                                 invalid field in the request, such as
                                 improper POR, POD, source, sink, etc.
(Final
                                 state).

                  RECEIVED=      assigned by  Provider or Seller to
                                 acknowledge QUEUED requests and
indicate
the
                                 service request is being evaluated,
                                 including for completing the required
                                 ancillary services.

                  STUDY=         assigned by   Provider or Seller to
indicate
                                 some level of study is required or
being
                                 performed to evaluate service request.

                  REFUSED =      assigned by   Provider or Seller to
indicate
                                 service request has been denied due to
                                 availability of transmission
capability.
                                 SELLER_COMMENTS should be used to
                                 communicate details for denial of
service.
                                 (Final state).

                  COUNTEROFFER=  assigned by   Provider or Seller to
indicate
                                 that a new OFFER_PRICE is being
proposed
or
                                 that CAPACITY_GRANTED is less than
                                 CAPACITY_REQUESTED.

                  REBID =        assigned by Customer to indicate that a
new
                                 BID_PRICE is being proposed.

                  SUPERSEDED =   assigned by Provider or Seller when a
                                 request which has not yet been
confirmed
is
                                 displaced by another reservation
request.
                                 (Final state).

                  ACCEPTED =     assigned by   Provider or Seller to
indicate
                                 the service request at the designated
                                 OFFER_PRICE and CAPACITY_GRANTED has
been
                                 approved/accepted. If the reservation
                                 request was submitted PRECONFIRMED and
                                 CAPACITY_GRANTED is equal to
                                 CAPACITY_REQUESTED, the OASIS Node
shall
                                 immediately set the reservation status
to
                                 CONFIRMED. Depending upon the type of
                                 ancillary services required, the Seller
may
                                 or may not require all ancillary
service
                                 reservations to be completed before
                                 accepting a request.

                  DECLINED =     assigned by Provider or Seller to
indicate
                                 that the terms and conditions, such as
the
                                 BID_PRICE, are unacceptable and that
                                 negotiations are terminated.
SELLER_COMMENTS
                                 should be used to communicate reason
for
                                 denial of service. (Final state).

                  CONFIRMED=     assigned by  Customer in response to
                                 Provider or Seller posting "ACCEPTED"
                                 status, to confirm service. Once a
request
                                 has been "CONFIRMED", a transmission
service
                                 reservation exists. (Final state,
unless
                                 overridden by DISPLACED or ANNULLED
state).

                  WITHDRAWN=     assigned by  Customer at any point in
                                 request evaluation to withdraw the
request
                                 from any further action. (Final state).

                  DISPLACED=     assigned by  Provider or Seller  when a
                                 "CONFIRMED" reservation from a
Customer
is
                                 displaced by a longer term  reservation
and
                                 the  Customer  has exercised right of
first
                                 refusal (i.e. refused to match terms of
new
                                 request). (Final state).

                  ANNULLED=      assigned by  Provider or Seller  when,
by
                                 mutual agreement with the  Customer, a
                                 confirmed reservation is to be voided.
                                 (Final state).

                  RETRACTED=     assigned by  Provider or Seller  when
the
                                 Customer fails to confirm or withdraw
the
                                 request within the required time
period.
                                 (Final state).





----- Forwarded by John Calder/ES/VANCPOWER on 01/29/2002 11:36 -----
 

                    pterris@pwrte

                    am.com               To:     "Mike McElhany"
<mcelhany@wapa.gov>                               
                    Sent by:             cc:     estf@nerc.com

                    owner-estf@ne        Subject:     Re: ESC Conference
Call to discuss Business Practices        
                    rc.com

 

 

                    01/29/2002

                    02:46

 

 






Mike:

I won't be able to join the conference call on the 31st (due to being on
night shift).  I have a couple of questions on BP 2 and 3.

Regarding Business Practice #2:

1.  I don't see where there's an option to Pre-Confirm a transmission
request.

Are we still going to have this option?  Does it need to be specifically
addressed (I would think yes).  Is this supposed to be implied in
Standard
4.10?  The customer doesn't actually change the status to CONFIRMED, but
maybe it's just semantics (as in, if there computer is doing the CONFIRM
behind the scenes, and not actually changing the status manually)?



** Preconfirmed is not mentioned because it does not effect the timing
requirements.  When the tag is submitted, it is QUEUED and then must be
acted on by the TP within the specified time frame.  All preconfirmed
does
is remove the obligation of the PSE to respond after the TP ACCEPTS the
request, since preconfirmed automatically takes it to CONFIRMED.,


2.  In Standard 4.6, there is a state of INVALID.  But this is never
described, and there doesn't seem to be any further reference to it.
Should we describe what would be designated as INVALID?  What is
supposed
to happen when the request is in this state?  Should there be a
statement
included, such as if a request is found to be INVALID, the only way to
have
further consideration given to the request is by submitting a new, valid
request?


** Per the definition, INVALID is a Final State for the Request.


3.  What is the distinction between DECLINED and REFUSED?  Should this
distinction be included in this document?  Is DECLINED a refusal of a
REBID
(as implied in Standard 4.12)?


** See Definitions.  Refused is for lack of ATC, Declined says TP does
not
accept your terms.


4.  Depending on the answer to #3, shouldn't Standard 4.7 include
DECLINED?
In addition to ACCEPTED, COUNTEROFFER, and REFUSED?

**  No. The TP can DECLINE a request because the price is incorrect,
whether or not there is ATC available.

5.  In Standard 4.9, it talks about RECEIVED.  But RECEIVED isn't
mentioned
anywhere else.  How does the request get to the RECEIVED state?  And
what
happens to it from there?  And how is it different from QUEUED?

** RECEIVED is a "placeholder" state that simply means the TP has
received
the request.  The paths from Queued and Received are identical.

6.  Standard 4.11 says that the TP can move the request to RETRACTED.
Shouldn't this be included in Standard 4.6?

** RETRACTED should not be included in 4.6 because you cannot go from
QUEUED to RETRACTED

7.  Again depending on the answer to #3, should REFUSED be included in
Standard 4.12?  In addition to DECLINED, ACCEPTED and COUNTEROFFER?

** Again the answer is NO because you cannot go from REBID to REFUSED.
HOWEVER, SUPERSEDED should be included in this list.

Regarding Business Practice #3:

Under Detailed Practice, Reassignment:

I'm not sure that I understand the distinction between "all rights" and
"rollover rights".  Or, wouldn't "all rights" include rollover rights?

1.  It states in the first paragraph that, by default, rollover rights
remain with the original rights owner.  This seems to contradict the
rest
of the paragraph, which states that the original transmission purchaser
is
removed from all obligations, and that all rights transfer to the
secondary
purchaser.  Wouldn't that include the rollover rights?  Should the
statements say "with all rights and obligations, with the possible
exception of rollover rights, transferring to the secondary transmission
rights owner"?

2.  The first paragraph states that rollover rights can be transferred
by
explicit contractual determination.  How would this be conveyed to the
TSP?
Will the manner of communication be standardized (such as including it
in
the notification of reassignment of transmission rights)?


Thanks for the clarifications.

Patt Terris
Exelon Power Team
pterris@pwrteam.com
Phone:  610-765-6602




                    "Mike
                    McElhany"            To:     <estf@nerc.com>
                    <mcelhany@wap        cc:     (bcc: Patricia A.
Terris/Power Team)
                    a.gov>               Subject:     ESC Conference
Call
to discuss Business Practices
                    Sent by:
                    owner-estf@ne
                    rc.com


                    01/28/2002
                    11:19 PM





All,

  This serves as the announcement for the 1st in a series of Business
Practice Conference Calls.  I've setup this 1st call to discuss BP 2 and
BP 3, as I received no additional comments on the order or grouping for
discussing the BPs.

  Attached is the information for the call, as well as the current
outstanding items from the task list.  So that you have time to review
and comment on these particular BPs I've moved this call until Thursday
the 31th.   Please use the "BP Conf Call One BP2 and BP3.doc" to submit
your comments, and direct your comments to the 5 specifice areas of the
BP (i.e. Practice Summary, Associated Rules, Justification,
Applicability, Practice Details).  I will send out any updates that I
receive prior to the call.

Mike
(See attached file: BP Conf Call One BP2 BP 3.doc)(See attached file:
ConfCal BP 2 and 3.doc)
eswg@wscc.com