|
|
Enron Mail |
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)
|