Business Practices for Open Access Same-Time Information Systems (oasis) Standards & Communication Protocols Business Practices Requirements




старонка3/11
Дата канвертавання24.04.2016
Памер0.7 Mb.
1   2   3   4   5   6   7   8   9   10   11

002-4.2.7.5 Continuation Records
Continuation records shall be used to indicate that the information in multiple rows (records) is part of one logical record. Continuation records will be indicated through the use of a column header called CONTINUATION_FLAG. This column header is either the first column (if in a response to a query) or second column (if in a response to an input) in all Templates permitting continuation records. The first record shall contain an "N" in the CONTINUATION_FLAG column and each following record which is part of a continuation record shall contain a "Y" in this column, thus associating the information in that record with the information in the previous record. An "N" shall indicate that the record is not a continuation record. In addition to the CONTINUATION_FLAG Data Element identifying that a record is associated with a previous record, any unique record identifier associated with the first (CONTINUATION_FLAG = N) record shall be repeated in all subsequent continuation records returned in an OASIS response. Each Template that supports the use of continuation records and those particular Data Elements (COLUMN_HEADERS) that may be referenced in one or more continuation records are identified in Standardsection 002-4.3. On upload or input of Template data, any values supplied via continuation records that correspond to COLUMN_HEADERs other than those explicitly allowed to appear in continuation records for a particular Template shall be ignored. However commas must be included to properly align the fields (columns). Note that the submission of continuation records is only supported by the CSV Format method of uploading data to an Input/Response Template
002-4.2.7.6 Error Handling in CSV-Formatted Responses
a. Validity of each record in the CSV-formatted Response to a Template Input shall be indicated through the use of RECORD_STATUS and ERROR_MESSAGE Data Elements which are included in each Data Record (row) of the Response.


  • If no error was encountered in an Input Data Record, the RECORD_STATUS Data Element in the corresponding Response record shall be returned with a value of 200 (success), and the ERROR_MESSAGE shall be blank.

  • If any error is detected in processing an Input Data Record, it shall be indicated by a RECORD_STATUS Data Element value other than 200. The ERROR_MESSAGE shall be set to an appropriate text message to indicate the source of the error in that Data Record.

b. The overall validity of each Template Query or Input shall be indicated in the CSV-formatted Response via the two REQUEST_STATUS and ERROR_MESSAGE header records (see section Standard 002-4.2.7.3):




  • If no errors were encountered in processing the User's Input Data Records, the REQUEST_STATUS shall be returned with the value of 200 (success), and the ERROR_MESSAGE shall be blank.

  • If any errors were detected in the Template Input Data Records, the REQUEST_STATUS value shall be any value other than 200, and the ERROR_MESSAGE shall be set to an appropriate text message to indicate the source of the error.

c. The OASIS Node shall validate all Input records before returning a Response to the User. The Node shall process all valid records, while invalid records shall be identified as erroneous through the use of RECORD_STATUS and ERROR_MESSAGE. The User must correct the invalid fields and resubmit only those records that were invalid. If an error is encountered in a record which is part of a set of Continuation records, then all records belonging to that set must be resubmitted.


002-4.2.8 Registration Information
002-4.2.8.1 General
As specified in the Information Access Requirements, OASIS Nodes shall provide a mechanism to register Users of the OASIS Node with a Provider. For all levels of access to OASIS information beyond simple read-only access, OASIS Nodes shall provide a mechanism to identify Users of the OASIS at least to the level of their respective Companies. The OASIS Node shall maintain both Company and User registration information.
002-4.2.8.2 Company Information
OASIS Templates require that certain Company registration information be maintained. As an extension of the Company registration information of the host, domain and port identifiers for dynamic notification of changes in the Customer's purchase requests, a field should be added to the Company's registration information that would define/identify how notification would be delivered to that Company should a transmission or ancillary purchase request be directed to that Company as a Seller of a transmission or ancillary service. The pertinent information would be either a full HTTP protocol URL defining the protocol, host name, port, path, resource, etc. information or a "mailto:" URL with the appropriate mailbox address string. On receipt of any purchase request directed to that Company as SELLER via either the "transrequest" or "ancrequest" Templates, or on submission of any change in request information submitted to that Company as SELLER via either the "transcust" or "anccust" Templates, a notification message formatted as documented for the delivery of notification to the Customer, shall be formatted and directed to the Seller. At a minimum, OASIS Nodes shall maintain the following information for each Company:
a. Company Code: 4 character code for primary transmission providers; 6 character code for eligible customers in accordance with NERC Tagging Information System (TIS) requirements shall be maintained for each Company.
b. Default Contact: Unless specified for each individual user affiliated with the Company, default contact information consisting of a phone number, fax number, and e-mail address shall be maintained for each Company.
c. Provider Affiliation: Each eligible Customer shall be obligated to identify to the OASIS TSIP any affiliation with a Transmission Provider whose "home page" is on that OASIS Node.
d. Notification URL: For Companies using the URL notification mechanism for delivery of messages on each change of ancillary/transmission reservation STATUS, each Company shall provide the IP host name and port number to be used in delivering notification messages. OASIS Nodes shall have the right to refuse support for notification to any IP ports other than port 80.
002-4.2.8.3 User Information
With the exception of "read-only" (visitor) access, OASIS Nodes shall, at a minimum, provide a mechanism to identify Users of the Node with at least their Company. However, OASIS Nodes and Providers shall have the right to require full User identification even for visitor accounts. To support the required OASIS Template Data Elements, OASIS Nodes shall maintain the following information for each registered User:

  • Company

  • Name

  • Phone

  • Fax

  • E-mail

In the event no additional User identification/registration information is maintained by the OASIS Nodes, all Template Data Elements referring to "company, name, phone, fax, e-mail" for either Customers or Sellers shall default to the Contact Information maintained for that User's Company.
002-4.2.9 Representation of Time
002-4.2.9.1 General
It is critical that all Users of OASIS Nodes have a clear and unambiguous representation of time associated with all information transferred to/from OASIS Nodes. For this reason, all Data Elements associated with time in OASIS Nodes shall represent "wall clock" times, which are NOT to be confused with other common industry conventions such as "hour ending." For the convenience of the User community, OASIS Nodes shall be allowed to accept the input and display of "time" in any acceptable form provided such non-standard representations are CLEARLY labeled on the associated HTML screens. Alternate representations of time in CSV formatted messages shall not be allowed. The following rules shall be implemented in OASIS Nodes for the representation of time on User entries (Query and Input) and output (Response) Templates.
002-4.2.9.2 Input Time
All time related Data Elements associated with either the Input or Query of Input/Response or Query/Response OASIS Templates shall be validated according the following rules. If the time zone associated with a time Data Element is associated with either Universal Time (UT) or a "standard" time zone (e.g., ES, CS, etc.), OASIS Nodes shall accept and apply a fixed hour offset from Universal Time year-round. If the time zone associated with a time Data Element is specified with a "daylight savings" time zone (e.g. ED, CD, etc.), OASIS Nodes shall verify that daylight savings time is in effect for the date/time specified. If daylight savings time (as specified by the time from 2:00am on the first Sunday of April through 2:00 am on the last Sunday of October) is not in effect, the Users input shall be rejected with an error response. If daylight savings time is in effect, the Users input shall be accepted and the appropriate hours offset from Universal Time shall be applied by OASIS Nodes for conversion to all other time zones. The input of start/stop times for transactions spanning the crossover day between standard and daylight (and vices versa) times must be made either entirely in standard time (valid year-round), or in two different time zones (xS/xD or xD/xS) for the start and stop times, depending on the time of year.
002-4.2.9.3 Output (Response) Time
The OASIS Node shall return all time Data Elements in the response to Input/Response or Query/Response OASIS Templates based on either the User specified RETURN_TZ header Query Variable or an appropriate OASIS specific default. OASIS Nodes shall interpret RETURN_TZ to specify:
a. The base time zone for conversion of all time Data Elements (e.g. Eastern, Pacific, etc.)
b. Whether daylight savings time is recognized. For example, a RETURN_TZ=ES would return all time Data Elements in Eastern Standard Time year-round. However, a RETURN_TZ=ED would direct OASIS Nodes to return all time Data Elements in Eastern Standard Time (ES) when daylight savings time is not in effect, and then return all time Data Elements in Eastern Daylight Time (ED) when daylight time is in effect.
002-4.2.10 Transaction Process
OASIS shall implement Templates that allow Customers and Sellers to enter, modify and consummate arrangements for transmission and ancillary services. The transaction process is controlled through the transaction REQUEST_TYPE, identifying the type of transaction being conducted, and STATUS, indicating where in the transaction process the request is currently.
The following is a summary of the templates used and actions that may be taken by the Customer and Seller to execute a transaction on OASIS. Detailed examples of the transaction process and description of the business logic envisioned to be implemented as part of the Transmission Provider’s OASIS or other back-end transaction support services are provided in the OASIS Implementation Guide, WEQ 011.
a. The transrequest and ancrequest Templates shall be used by the Customer

to enter a transaction request for specific transmission or ancillary services from a specified Seller. All pertinent transaction-specific information must be provided in the template data elements.


b. The transstatus and ancstatus Templates shall be used by both Customer and Seller to query for the current transaction information (e.g., STATUS). Alternatively, the Customer may request dynamic notification per Standard 002-4.2.10.3 whenever the transaction data is changed.
c. The transsell and ancsell Templates shall be used by the Seller to indicate to the Customer whether the request is acceptable or not by setting the transaction STATUS to one of RECEIVED, INVALID, STUDY, COUNTEROFFER, ACCEPTED, REFUSED, SUPERSEDED, DECLINED, DISPLACED, ANNULLED, or RETRACTED. A Transmission Provider as the Seller may use the transsell and ancsell Templates to act on requests or may use proprietary software solutions to perform this function in a similar manner.
d. The transcust and anccust Templates shall be used by the Customer to indicate to the Seller whether they wish to negotiate, confirm or withdraw the transaction by setting the transaction STATUS to one of REBID, CONFIRMED, or WITHDRAWN.
e. The transassign and ancassign Templates shall be used by the Seller to notify the Primary Provider of the transfer of rights from the Seller to the Customer consummated off the OASIS Node.
f. The source of all Customer and Seller contact information shall be provided under Standard 002-3.1 REGISTRATION AND LOGIN REQUIREMENTS. Therefore, it shall not be input as part of uploads, but shall be provided as part of all transaction downloads.
g. OASIS Nodes shall accept a Seller-initiated change in STATUS to ACCEPTED only when OFFER_PRICE matches BID_PRICE.
h. OASIS Nodes shall accept a Customer initiated change in STATUS to CONFIRMED only when BID_PRICE matches OFFER_PRICE.
i. If CAPACITY_GRANTED is null when STATUS is being changed to ACCEPTED or CONFIRMED, the OASIS Node shall set it equal to CAPACITY_REQUESTED.
j. OASIS Nodes shall set the initial transaction STATUS of the request to QUEUED and assign a unique ASSIGNMENT_REF identifier for the transaction.
k. If the Customer has identified the transaction as PRECONFIRMED and the Seller has set the transaction STATUS to ACCEPTED, OASIS Nodes shall automatically set the transaction’s STATUS to CONFIRMED without any Customer interaction required.
l. If the Customer has identified the transaction as PRECONFIRMED and the Seller has set the transaction STATUS to COUNTEROFFER, OASIS Nodes shall take no automatic action on the transaction and require explicit confirmation by the Customer.
The transaction process flow is depicted in the diagram below.



Exhibit 4-1 Transaction Template Usage Diagram
002-4.2.10.1 Request Types
The following are the valid OASIS transaction request types (template data element REQUEST_TYPE) submitted by the Customer unless otherwise noted, along with a brief description of their intended use:
ORIGINAL = reservation request submitted to the Primary Provider as the Seller of the transmission or ancillary service
RESALE = The request to convey scheduling rights associated with a reservation for Point-To-Point Transmission Service from a Reseller to an Assignee
TRANSFER = Request to convey all rights and obligations associated with a reservation for Point-To-Point Transmission Service from a Reseller to an Assignee
RENEWAL = request to renew an expiring transmission reservation
MATCHING = request to meet a competing request by exercising a right of first refusal
DEFERRAL = request to defer or apply for an extension to the start of transmission service
REDIRECT = request to move all or portion of the capacity of a transmission reservation to an alternate POR/POD and/or make other changes to the terms of service as permitted
RELINQUISH = request submitted to the Primary Provider to release all or a portion of the capacity of a transmission reservation
RECALL = request submitted by the Seller (Reseller or Primary Transmission Provider) to take back all or a portion of the capacity of a transmission reservation
{registered} = A Primary Transmission Provider may register values for REQUEST_TYPE to implement specific provisions of their Tariff.
The OASIS Implementation Guide, WEQ 011, contains detailed descriptions on the use of each transaction REQUEST_TYPE and explains the business processes to be implemented in association with each of these requests as specified by the OASIS Business Practice Standards, WEQ 001.

OASIS shall implement Templates that allow Customers and Sellers to enter, modify and consummate arrangements for transmission and ancillary services. The following subsections outline the basic steps for arranging for these services. Section 4.2.13 provides further detail on the use of OASIS Templates to modify the terms of a transaction in support of specific provisions of the Open Access ProForma Tariff.


002-4.2.10.1 Purchase Transactions
Customers shall purchase services from the Seller using the following basic steps (see Exhibit 4-1):
a. The Templates (transrequest and ancrequest) shall be used by a Customer to enter a request for specific transmission or ancillary services from a specific Seller. Basic requests for transmission services from the Primary Transmission Provider shall be assigned a REQUEST_TYPE of "ORIGINAL"; requests for transmission services on the secondary market (where SELLER is not the Primary Transmission Provider) shall be assigned a REQUEST_TYPE of "RESALE" (Section 4.2.13 documents other values that may be assigned to REQUEST_TYPE). The Customer may enter a BID_PRICE which is different from the OFFER_PRICE in order to try to negotiate a lower price. The OASIS Node sets the initial STATUS of the request to QUEUED. The Customer may set the STATUS_NOTIFICATION to indicate that the OASIS Node must notify the Customer on any change in the request's STATUS or related Data Elements (see Dynamic Notification). The Customer may designate the request as PRECONFIRMED. Preconfirmed requests will be automatically set to the STATUS of CONFIRMED when ACCEPTED by the Seller without requiring an explicit confirmation from the Customer. Prior to or commensurate with a Seller's setting of a preconfirmed reservation request's STATUS to ACCEPTED (and by implication CONFIRMED), the Seller must set OFFER_PRICE equal to the value of BID_PRICE as established by the Customer on submission of the request.
b. The Templates (transstatus and ancstatus) shall be used by Customers and Sellers to monitor the status of their transactions in progress. These Templates shall also be used by any Users to review the status of any transactions. The NEGOTIATED_PRICE_FLAG Data Element is set when the Seller agrees to a BID_PRICE (by setting OFFER_PRICE equal to BID_PRICE) that is different from the previously posted price. It will show "higher" when OFFER_PRICE is higher than the posted price, and "lower" when the OFFER_PRICE is lower than the posted price.
c. The Templates (transsell and ancsell) shall be used by a Seller to set a new value into STATUS, to enter a MW value in CAPACITY_GRANTED, if offering partial service, and to negotiate a price by entering a new OFFER_PRICE which is different from the BID_PRICE entered by the Customer in the transrequest Template. During these negotiations, a Reseller shall formally indicate the approval or disapproval of a transaction and indicate which rights from prior confirmed reservations are to be reassigned. A Primary Provider may, but is not required, to enter transaction approval or disapproval using this Template. In the event the Seller is only able to grant a portion of the transmission capacity requested by the Customer and the Seller is obligated or elects to extend an offer for partial service, the Seller shall indicate to the Customer the amount of capacity available using CAPACITY_GRANTED and set the reservation request's status to COUNTEROFFER. Preconfirmed requests that are set to COUNTEROFFER due to an offer of service at a level lower than requested by the Customer shall require explicit confirmation by the Customer. The valid STATUS values which may be set by a Seller are: RECEIVED, INVALID, STUDY, COUNTEROFFER, ACCEPTED, REFUSED, SUPERSEDED, DECLINED, DISPLACED, ANNULLED, or RETRACTED.
d. The Customer shall use the transstatus and ancstatus Templates to view the Seller's new offer price, partial service offer and/or approval/disapproval decision.
e. After receiving notification of the transaction's STATUS being set to COUNTEROFFER by the Seller, the Templates (transcust and anccust) shall be used by the Customer to modify the BID_PRICE and set the STATUS to REBID or CONFIRMED. Transcust shall also be used to confirm an offer for partial service (where CAPACITY_GRANTED is less than CAPACITY_REQUESTED) by setting the STATUS to CONFIRMED. After negotiations are complete (STATUS set to ACCEPTED by the Seller), the Customer shall formally enter the confirmation or withdrawal of the offer to purchase services for the OFFER_PRICE shown in the transstatus Template. The valid STATUS values which a Customer may set are: REBID, CONFIRMED, or WITHDRAWN.
f. The Seller shall use the transstatus (ancstatus) Template to view the Customer's new bid price and/or confirmation/withdrawal decision, again responding through transsell or ancsell if necessary. If the Seller offers to sell a service at an OFFER_PRICE less than that posted in the transoffering (ancoffering) Template, the transoffering (ancoffering) Template must be updated to reflect the new OFFER_PRICE.
g. For deals consummated off the OASIS Nodes by a Seller, after the Customer has accepted the offering, the Templates (transassign and ancassign) may be used by the Seller to notify the Primary Provider of the transfer of rights to the Customer. Continuation records may be used to indicate the reassigning of rights for a "profile" of different assignments and different capacities over different time periods.
h. The source of all User and Seller contact information shall be the User registration process. Therefore, it shall not be input as part of uploads, but shall be provided as part of all transaction downloads.
i. OASIS Nodes shall accept a Seller initiated change in STATUS to ACCEPTED only when OFFER_PRICE matches BID_PRICE (i.e., Seller must set OFFER_PRICE equal to BID_PRICE prior to or coincident with setting STATUS to ACCEPTED).
j. OASIS Nodes shall accept a Customer initiated change in STATUS to CONFIRMED only when BID_PRICE matches OFFER_PRICE (i.e., Customer must set BID_PRICE equal to OFFER_PRICE prior to or coincident with setting STATUS to CONFIRMED).
k. If CAPACITY_GRANTED is null when STATUS is being changed to ACCEPTED or CONFIRMED, the OASIS Node shall set it equal to CAPACITY_REQUESTED.
002-4.2.10.2 Status Values
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 lack of availabilityle of transmissionfer capability. (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 preempted 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 of the request, such as the BID_PRICE, are unacceptable and that negotiations are terminated or that contractual terms and conditions have not been met. (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 higher priority reservation and the Customer is not offered or has not 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).
The following diagram can be used as a business process guideline; however, individual tariffs will dictate specific allowed actions between states.




1   2   3   4   5   6   7   8   9   10   11


База данных защищена авторским правом ©shkola.of.by 2016
звярнуцца да адміністрацыі

    Галоўная старонка