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




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

Exhibit 4-21 - State Diagram of Purchase Transactions
002-4.2.10.3 Dynamic Notification
Customers may specify the delivery of dynamic notification messages on each change in STATUS or any other Data Element(s) associated with an ancillary or transmission service reservation. OASIS Nodes shall support the delivery of dynamic notification messages through either the HTTP protocol or by electronic mail. The selection of which mechanism is used and the contents of the messages delivered to the client program or e-mail address is defined by the content of the STATUS_NOTIFICATION Data Element as described in the next subsections. Regardless of whether this dynamic notification method is used or not, it shall still remain the User's responsibility to get the desired information, possibly through the use of a periodic "integrity request". OASIS Nodes shall not be obligated or liable to guarantee delivery/receipt of messages via the STATUS_NOTIFICATION mechanism other than on a "best effort" basis. 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 STATUS (or any other Data Elements associated with the request) 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. This extension of dynamic notification is required only where the Transmission Provider has programmed its computer system for its own notification.
002-4.2.10.3.1 HTTP Notification
OASIS Nodes shall deliver dynamic notification to a client system based on HTTP URL information supplied in part by the STATUS_NOTIFICATION Data Element and by information supplied as part of the Customer's Company registration information. HTTP URL's are formed by the concatenation of a protocol field (i.e., http: ), a domain name (e.g., //www.tsin.com), a port designation (e.g., :80), and resource location information.
The STATUS_NOTIFICATION Data Element shall contain the protocol field "http:", which designates the notification method/protocol to be used, followed by all resource location information required; the target domain name and port designations shall be inserted into the notification URL based on the Customer's Company registration information. The resource location information may include directory information, cgi script identifiers and URL encoded query string name/value pairs as required by the Customer's application. An OASIS Node performs no processing on the resource location information other than to include it verbatim along with the protocol, domain name and port information when forming the URL that will be used to deliver the HTTP protocol notification message. For example,

Company XYZ has established the domain name and port designations of "//oasistc.xyz.com:80" as part of their registration information.When a transmission reservation is submitted by one of Company XYZ's users (the Customer), and includes a STATUS_NOTIFICATION Data Element with the value of

"http:/cgi-bin/status?DEAL_REF=8&REQUEST_REF=173", an OASIS Node shall deliver an HTTP notification message using the URL:

http://oasistc.xyz.com:80/cgi-bin/status?DEAL_REF=8&REQUEST_REF=173


If the STATUS_NOTIFICATION field contained only the "http:" protocol designation, the notification message would be delivered using the URL:

http://oasistc.xyz.com:80


The contents of the HTTP protocol notification message delivered by an OASIS Node shall consist of the complete URL created by combining fields from the STATUS_NOTIFICATION Data Element and Company registration information as part of an HTTP POST method request. In addition to the POST method HTTP header record, OASIS Nodes shall also append the CSV formatted output of the transstatus Template information for that particular reservation using the standard Content-type: text/x-oasis-csv and appropriate Content-length: HTTP header records. OASIS Nodes shall use a Primary Provider specific default value for RETURN_TZ in formulating the transstatus response information. Continuing with the previous example, the important records in the HTTP notification message that would be delivered to Company XYZ for the transmission reservation request submitted to Primary Provider ABC and given an ASSIGNMENT_REF of 245 would be,
POST http://oasistc.xyz.com:80/cgi-bin/status?DEAL_REF=8&REQUEST_REF=173

HTTP/1.0


.

.

Content-type: text/x-oasis-csv



Content-length:

REQUEST_STATUS=200

TIME_STAMP=

VERSION=1.4

TEMPLATE=transstatus

OUTPUT_FORMAT=DATA

PRIMARY_PROVIDER_CODE=ABC

PRIMARY_PROVIDER_DUNS=123456789

RETURN_TZ=

DATA_ROWS=1

COLUMN_HEADERS=CONTINUATION_FLAG, ASSIGNMENT_REF, . . .

N, 245, . . .


In the event an error is encountered delivering the HTTP notification message to the target URL as indicated by a failure of the target system to respond, or return of HTTP response status of 408, 500, 503, or 504, OASIS Nodes shall retry up to two more times, once every 5 minutes.
002-4.2.10.3.2 E-mail Notification
OASIS Nodes shall deliver dynamic notification to an e-mail address based on Mailto: URL information specified in the STATUS_NOTIFICATION Data Element. Mailto: URL's consist of the "mailto:" protocol identifier and an Internet mail address to which the notification message should be sent. The STATUS_NOTIFICATION Data Element shall contain the protocol field "mailto:", which designates the notification method/protocol to be used, followed by an Internet mail address in conformance with RFC 822. OASIS Nodes shall send an e-mail message to the Internet mail address containing the following information: "To:" set to the mail address from the STATUS_NOTIFICATION Data Element, "From:" set to an appropriate mail address of the OASIS Node, "Subject:" shall be the transstatus Template name followed by the value of the ASSIGNMENT_REF Data Element and the current value for the STATUS Data Element associated with the reservation (e.g., "Subject: transstatus 245 ACCEPTED"), and the body of the message shall contain the CSV formatted output of the transstatus Template information for that particular reservation. OASIS Nodes shall use a Primary Provider specific default value for RETURN_TZ in formulating the transstatus response information.
002-4.2.10.4 Use of Comments
Transmission and ancillary service reservation templates support the following text data elements to be used to communicate information between parties (i.e., transmission provider, seller, and customer) to a transaction:


  • PRIMARY_PROVIDER_COMMENTS - for information to be communicated by the primary transmission provider to all other parties

  • SELLER_COMMENTS - for information to be communicated by the seller (either primary provider or reseller) to the customer

  • CUSTOMER_COMMENTS - for information to be communicated by the customer to the seller

  • STATUS_COMMENTS - for information to be communicated by any party to all other parties

Use of these comments fields is at the discretion of the parties to the transaction with the exception that sellers of services must indicate via SELLER_COMMENTS the reason for denial of any request for service (STATUS values of INVALID, REFUSED, or DENIED). Transactions which are subject to displacement, either before or after confirmation (STATUS values of SUPERSEDED or DISPLACED), shall also include a reference to the competing reservation request that initiated the displacement in the SELLER_COMMENTS.


002-4.2.11 Reference Identifiers
a. The TSIP shall assign a unique reference identifier, ASSIGNMENT_REF, for each Customer request to purchase capacity or services. The value of ASSIGNMENT_REF may be used to imply the order in which the request was received by the TSIP. This identifier will be used to track the request through various stages, and will be kept with the service through out its life. Whenever a transaction is modified by a subsequent transaction, a new ASSIGNMENT_REF number is assigned to that subsequent transaction along with a reference to the previous transaction such that a chain of all transactions related to the service can be maintained. These changes create a parent/child relationship between related requests. The TSIP shall use REASSIGNED_REF or RELATED_REF as specified in section 4.2.13 to identify the parent request’s ASSIGNMENT_REF and shall increment the IMPACTED counter of the parent request by 1. Reductions to a request posted by the Transmission Provider shall also reference the requests ASSIGNMENT_REF and the TSIP shall increment the IMPACTED counter of the request by 1.
b. The TSIP shall assign a unique reference identifier, POSTING_REF, to each Seller's offerings of service for sale or other information (messages) posted on an OASIS Node. The Seller in any/all subsequent Template submissions, that would result in a modification to or deletion of that specific offering or message, shall reference this identifier. Optionally, Customers may also refer to this POSTING_REF in their subsequent purchase requests to aid in identifying the specific offering associated with the purchase request.
c. Sellers may aggregate portions of several previous transmission service reservations to create a new offering to be posted on an OASIS Node. When all or a portion of such offerings are sold, the Seller (original Customer) is obligated to notify the Primary Provider of the sale/assignment by inserting appropriate reassignment information on the OASIS Node (via the transsell or transassign Templates) or by some other approved method. This reassignment information consists of the ASSIGNMENT_REF value assigned to the original reservation(s) and the time interval and capacity amount(s) being reassigned to the new reservation. These values are retained in the REASSIGNED_REF, REASSIGNED_START_TIME, REASSIGNED_STOP_TIME, and REASSIGNED_CAPACITY Data Elements.
d. Sellers may identify their service offerings received from Customers through the Seller supplied value specified for the SALE_REF Data Element.
e. Customers may track their purchase requests through the Customer supplied values specified for the DEAL_REF and REQUEST_REF Data Elements. Customers may also use POSTING_REF and SALE_REF in their purchase requests to refer back to posted offerings.
002-4.2.12 Linking of Ancillary Services to Transmission Services
The requirements related to ancillary services are shown in transoffering (and updated using transupdate) using the ANC_SVC_REQ Data Element containing the following permitted values:
SC:x; RV:x; RF:x; EI:x; SP:x; SU:x;
where SC, RV, RF, EI, SP and SU are the ancillary services 1 through 6 described in the Proforma Tariff,

  • SC - Scheduling, system Control and dispatch

  • RV - Reactive supply and Voltage control

  • RF - Regulation and Frequency response

  • EI - Energy Imbalance

  • SP - SPinning reserve

  • SU - SUpplemental reserve

and where x={M,R,O,U} means one of the following:

  • Mandatory, which implies that the Primary Provider must provide the ancillary service

  • Required, which implies that the ancillary service is required, but not necessarily from the Primary Provider

  • Optional, which implies that the ancillary service is not necessarily required, but could be provided

  • Unknown, which implies that the requirements for the ancillary service are not known at this time

Ancillary services may be requested by a User from the Provider at the same time as transmission services are requested via the transrequest Template, by entering the special codes into ANC_SVC_LINK to represent the Proforma ancillary services 1 through 6 (or more) as follows:

SC:(AA[:xxx[:yyy[:nnn]]]); RV: (AA[:xxx[:yyy[:nnn]]]); RF:

(AA[:xxx[:yyy[:nnn]]]);

EI: (AA[:xxx[:yyy[:nnn]]]); SP: (AA[:xxx[:yyy[:nnn]]]); SU:

(AA[:xxx[:yyy[:nnn]]]); {Registered}:(AA[:xxx[:yyy[:nnn]]])

where AA is the appropriate PRIMARY_PROVIDER_CODE, SELLER_CODE, or CUSTOMER_CODE, and represents the company providing the ancillary services. "AA" may be unspecified for "xxx" type identical to "FT", in which case the ":" character must be present and precede the "FT" type. If multiple "AA" terms are necessary, then each "AA" grouping will be enclosed within parenthesis, with the overall group subordinate to the AS_TYPE specified within parenthesis and where xxx represents either:



  • "FT" to indicate that the Customer will determine ancillary services at a future time, or

  • "SP" to indicate that the Customer will self-provide the ancillary services, or

  • "RQ" to indicate that the Customer is asking the OASIS Node to initiate the process for making an ancillary services reservation with the indicated Provider or Seller on behalf of the Customer. The Customer must then continue the reservation process with the Provider or Seller. If the transmission services request is for preconfirmed service, then the ancillary services shall also be preconfirmed, or

  • "AR" to indicate an assignment reference number sequence follows.

The terms "yyy" and "nnn" are subordinate to the xxx type of "AR". yyy represents the ancillary services reservation number (ASSIGMNENT_REF) and nnn represents the capacity of the reserved ancillary services. Square brackets are used to indicated optional elements and are not used in the actual linkage itself. Specifically, the :yyy is applicable to only the "AR" term and the :nnn may optionally be left off if the capacity of ancillary services is the same as for the transmission services, and optionally multiple ancillary reservations may be indicated by additional (xxx[:yyy[:nnn]]) enclosed within parenthesis. If no capacity amount is indicated, the required capacity is assumed to come from the ancillary reservations in the order indicated in the codes, on an "as-needed" basis.
Examples:
Example 1:
Assume ancillary services SC and RV are mandatory from the TP, whose code is "TPEL", and ancillary services RF, EI, SP and SU are required, but will be defined at a future time.
"SC: (TPEL:RQ); RV: (TPEL:RQ); RF:(:FT); EI:(:FT); SP:(:FT); SU:(:FT)";
Example 2:
Assume ancillary services SC and RV are mandatory from the TP, whose code is "TPEL", and RF, EI, SP and SU are self-supplied. The customer code is "CPSE"
"SC: (TPEL:RQ); RV: (TPEL:RQ); RF:(CPSE:SP); EI:(CPSE:SP);

SP:(CPSE:SP); SU:(CPSE:SP)"


Example 3:
Assume ancillary services SC and RV are mandatory from the TP, whose code is "TPEL", and ancillary services RF, EI, SP and SU were purchased via a prior OASIS reservation from seller "SANC" whose reservation number was "39843". There is sufficient capacity within the Ancillary reservation to handle this Transmission reservation.
"SC:(TPEL:RQ); RV:(TPEL:RQ); RF:(SANC:AR:39843);

EI:(SANC:AR:39843) SP:(SANC:AR:39843); SU:(SANC:AR:39843)"


Example 4:
Assume ancillary services SC and RV are mandatory from the TP, whose code is "TPEL", and ancillary services RF, EI, SP and SU were purchased via prior OASIS reservations from sellers "SANC" and "TANC", whose reservation numbers where "8763" and "9824" respectively. There is not sufficient capacity within the Ancillary reservation from seller "SANC" to handle this Transmission reservation. In this case the OASIS reservation number 8763 will be depleted for the time frame specified within the transmission reservation and the remaining required amount will come from reservation number "9824".
"SC:(TPEL:RQ); RV:(TPEL:RQ); RF:((SANC:AR:8763)(TANC:AR:9824));

EI:((SANC:AR:8763)(TANC:AR:9824));

SP:((SANC:AR:8763)(TANC:AR:9824));

SU:((SANC:AR:8763)(TANC:AR:9824))"


Example 5:
Assume a transmission reservation in the amount of 100 mw/hour for a period of one day is made. Ancillary services SC and RV are mandatory from the TP, whose code is "TPEL", and ancillary services RF, EI, SP and SU were purchased via prior OASIS reservations from sellers "SANC" and "TANC", whose reservation numbers where "8763" and "9824" respectively. There is sufficient capacity within the Ancillary reservation from seller "SANC" to handle this Transmission reservation, however the purchaser wishes to use only "40 mw's" from this seller. In this case the OASIS reservation number 8763 will be depleted in the amount of "40 mw's" for the time frame specified within the transmission reservation and the remaining required amount will come from reservation number "9824".
"SC:(TPEL:RQ); RV:(TPEL:RQ); RF:((SANC:AR:8763:40)(TANC:AR:9824));

EI:((SANC:AR:8763:40)(TANC:AR:9824));

SP:((SANC:AR:8763:40)(TANC:AR:9824));

SU:((SANC:AR:8763:40)(TANC:AR:9824))"


002-4.2.13 Modifications to Transactions
Transactions processed by OASIS as outlined in Section 4.2.10 may be subject to modification by subsequent transactions or events as permitted under the Transmission Provider's Tariff. The following subsections describe the actions to be taken on OASIS to implement specific provisions of the Open Access Pro Forma Tariff related to transmission service. Depending on the exact form of the Provider's Tariff, some of these provisions may not be applicable, and implementation of other provisions may be Provider specific. In general, modification to any OASIS transaction initiated by the Customer shall involve the submission of a new transaction. The new transaction shall identify the specific type of modification being requested using the REQUEST_TYPE Data Element, and reference the transaction to be modified using the RELATED_REF Data Element. In the specific case of secondary market transactions, related transactions are identified with the use of the REASSIGNED_REF Data Element. The following are the specific restricted values for the REQUEST_TYPE Data Element and a brief description of their use:


  • ORIGINAL – typical reservation requests submitted to the Primary Provider

  • RESALE – secondary market requests submitted to a Transmission Customer as Secondary Transmission Provider

  • RENEWAL – request to renew an expiring transmission reservation

  • MATCHING – request to meet or exceed a competing request to retain transmission service (right of first refusal)

  • DEFERRAL – request to defer or apply for extension on start of transmission service

  • REDIRECT – request to redirect all or portion of a transmission reservation to an alternate POR/POD and/or make other changes to the terms of service as permitted

  • {registered} – Primary Transmission Provider's may register values for REQUEST_TYPE to implement specific provisions of their Tariffs.

The Primary Transmission Provider may also modify a Customer's transmission reservation to the extent that the original reservation's MW capacity available for scheduling may be reduced over all or a portion of the term of the original reservation subject to the terms of the Provider's Tariff. Any time a subsequent transaction initiated by the Customer modifies all or a portion of a prior transaction, or a reduction in reserved MWs is initiated by the Primary Provider, the IMPACTED counter will be incremented in the prior transaction shall be set. OASIS User's may view the list of all subsequent transactions or events impacting a given transaction using the reduction Template. The following subsections describe the application of REQUEST_TYPE to actions taken on OASIS, and how various modifications to existing reservations are to be affected.


002-4.2.13.1 Original Transactions
Transactions submitted to the Primary Transmission Provider using the transrequest Template for the typical reservation of transmission service shall be identified by the REQUEST_TYPE of "ORIGINAL", and be processed as described in Section 4.2.10. The RELATED_REF Data Element must be null, the Primary Provider specified as SELLER, and, if the REQUEST_TYPE is null, the OASIS node shall default its value to "ORIGINAL". The value returned in the ASSIGNMENT_REF Data Element shall be used to refer to this specific, original transmission reservation request in any subsequent actions taken.
002-4.2.13.2 Partial Service
If in the evaluation of a transmission request, the Primary Provider determines that only a portion of the Customer's requested capacity reservation (CAPACITY_REQUESTED Data Element) can be accommodated and that the Provider is obligated or elects to offer the Customer only a portion of the requested capacity, the Primary Provider shall set the CAPACITY_GRANTED Data Element(s) associated with that transmission reservation to the amount available, and set the STATUS to COUNTEROFFER. If the CAPACITY_REQUESTED and/or CAPACITY_GRANTED are not constant over time, continuation records shall be used to convey the time varying profile of MW capacity associated with the transmission request (CAPACITY_REQUESTED, CAPACITY_GRANTED, START_TIME and STOP_TIME). The Customer shall recognize the offer of partial service by CAPACITY_REQUESTED not being equal to CAPACITY_REQUESTED and the request STATUS of COUNTEROFFER. The Customer may elect to CONFIRM, WITHDRAW, or REBID the reservation using the transcust Template. If the transmission reservation request was marked PRECONFIRMED by the Customer and an offer of partial service is extended, the reservation request must be explicitly CONFIRMed by the Customer. The OASIS node shall not automatically CONFIRM a request where CAPACITY_REQUESTED does not equal CAPACITY_GRANTED when/if the request STATUS is set to ACCEPTED.
002-4.2.13.3 Secondary Sales – On OASIS
The sale or assignment of rights from one Transmission Customer to another may be conducted on OASIS using the same transaction process as described for purchases made from the Primary Transmission Provider. The request for purchase of transmission service from another Transmission Customer (Secondary Transmission Provider) is submitted by the Customer purchasing the capacity using the transrequest Template. Secondary transmission sales shall be identified by the REQUEST_TYPE of "RESALE", and be processed as described in Section 4.2.10. Th RELATED_REF Data Element must be null, the Transmission Customer owning capacity offered for resale (the Secondary Transmission Provider) specified as SELLER, and, if the REQUEST_TYPE is null, the OASIS node shall default its value to "RESALE". The Secondary Transmission Provider (original Customer) selling their transmission rights over OASIS shall use the transsell Template to approve/deny the request. If the request is to be approved (STATUS=ACCEPTED), the transmission reservation(s) currently held by the Customer selling their capacity and the amount of capacity over time from each such reservation to be transferred to the secondary market Customer must be identified. This information is supplied via the REASSIGNED_REF, REASSIGNED_CAPACITY, REASSIGNED_START_TIME and REASSIGNED_STOP_TIME Data Elements. The aggregation of all REASSIGNED_xxx Data Elements must match the capacity and time frame of the secondary transmission request as specified in the CAPACITY_GRANTED (and/or CAPACITY_REQUESTED), START_TIME and STOP_TIME Data Elements of the "RESALE" transaction. The Customer purchasing transmission service on the secondary market over OASIS shall use the transcust to monitor the transaction and CONFIRM the sale if necessary. Upon confirmation of the secondary sale the IMPACTED attribute will be incremented for each reservations referenced by the REASSIGNED_REF Data Elements.
1   2   3   4   5   6   7   8   9   10   11


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

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