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




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

Query

SELLER_CODE*

SELLER_DUNS*

CUSTOMER_CODE*

CUSTOMER_DUNS*

CONTROL_AREA

ANC_SERVICE_POINT

SERVICE_INCREMENT

AS_TYPE

STATUS


START_TIME

STOP_TIME

START_TIME_QUEUED

STOP_TIME_QUEUED

NEGOTIATED_PRICE_FLAG

ASSIGNMENT_REF

REASSIGNED_REF

SALE_REF


REQUEST_REF

DEAL_REF


TIME_OF_LAST_UPDATE (only if TIME_OF_LAST_UPDATE is posted by record)


  1. Response

CONTINUATION_FLAG

ASSIGNMENT_REF

SELLER_CODE

SELLER_DUNS

CUSTOMER_CODE

CUSTOMER_DUNS

AFFILIATE_FLAG (Set by TSIP)

CONTROL_AREA

ANC_SERVICE_POINT

CAPACITY

SERVICE_INCREMENT

AS_TYPE

START_TIME



STOP_TIME

CEILING_PRICE

OFFER_PRICE

BID_PRICE

PRICE_UNITS

PRECONFIRMED

POSTING_REF

SALE_REF


REQUEST_REF

DEAL_REF


NEGOTIATED_PRICE_FLAG ("L" if Seller accepted Price is lower than OFFER_PRICE in ancoffering Template; "H" if higher; otherwise blank)

STATUS=


QUEUED, INVALID, RECEIVED, STUDY, REBID, COUNTEROFFER, ACCEPTED, REFUSED, CONFIRMED, WITHDRAWN, SUPERSEDED, DECLINED, ANNULLED, RETRACTED, DISPLACED

STATUS_NOTIFICATION

STATUS_COMMENTS

TIME_QUEUED

RESPONSE_TIME_LIMIT

TIME_OF_LAST_UPDATE

PRIMARY_PROVIDER_COMMENTS

SELLER_COMMENTS

CUSTOMER_COMMENTS

SELLER_NAME

SELLER_PHONE

SELLER_FAX

SELLER_EMAIL

CUSTOMER_NAME

CUSTOMER_PHONE

CUSTOMER_FAX

CUSTOMER_EMAIL

REASSIGNED_REF

REASSIGNED_CAPACITY

REASSIGNED_START_TIME

REASSIGNED_STOP_TIME
002-4.3.8.3 Seller Approves Ancillary Service (ancsell)
Seller Approves Ancillary Service (ancsell) is used by the Seller to confirm acceptance after the Seller has approved the purchase of ancillary service.
The following fields may be submitted in continuation records for the ancsell Template to convey ancillary rights from multiple original ancillary service reservations to this new reservation: REASSIGNED_REF, REASSIGNED_CAPACITY, REASSIGNED_START_TIME, and REASSIGNED_STOP_TIME. If the Provider/Seller supports the negotiation of price on individual segments of a profiled reservation request (support for reservation profiles is at the discretion of the Provider), OFFER_PRICE, START_TIME and STOP_TIME Data Elements may be submitted in continuation records to modify the Seller's offer price associated with the profile segment(s) corresponding to START_TIME and STOP_TIME. OFFER_PRICE associated with each segment of a profiled request must match the corresponding BID_PRICE for the reservation request's STATUS to be set to ACCEPTED.
SELLER_CODE and SELLER_DUNS shall be determined from the registered connection used to input the request.
Template: ancsell


  1. Input

CONTINUATION_FLAG

ASSIGNMENT_REF (Required)

START_TIME

STOP_TIME

OFFER_PRICE

STATUS =

INVALID, RECEIVED, STUDY, COUNTEROFFER, SUPERSEDED, ACCEPTED, REFUSED, DECLINED, ANNULLED, RETRACTED, DISPLACED

STATUS_COMMENTS

NEGOTIATED_PRICE_FLAG

RESPONSE_TIME_LIMIT

SELLER_COMMENTS

REASSIGNED_REF

REASSIGNED_CAPACITY

REASSIGNED_START_TIME

REASSIGNED_STOP_TIME


  1. Response (acknowledgment)

RECORD_STATUS

CONTINUATION_FLAG

ASSIGNMENT_REF

START_TIME

STOP_TIME

OFFER_PRICE

STATUS =



INVALID, RECEIVED, STUDY, COUNTEROFFER, SUPERSEDED, ACCEPTED, REFUSED, DECLINED, ANNULLED, RETRACTED, DISPLACED

STATUS_COMMENTS

NEGOTIATED_PRICE_FLAG

RESPONSE_TIME_LIMIT

SELLER_COMMENTS

REASSIGNED_REF

REASSIGNED_CAPACITY

REASSIGNED_START_TIME

REASSIGNED_STOP_TIME

ERROR_MESSAGE


002-4.3.8.4 Customer accepts Ancillary Service (anccust)
Customer accepts Ancillary Service (anccust) is used by the customer to confirm acceptance after the seller has approved the purchase of ancillary service.
The Customer must change the BID_PRICE to be equal to the OFFER_PRICE before the reservation request's STATUS can be set to CONFIRMED. If the Provider/Seller supports the negotiation of price on individual segments of a profiled reservation request (support for reservation profiles is at the discretion of the Provider), BID_PRICE, START_TIME and STOP_TIME Data Elements may be submitted in continuation records to modify the Customer's bid price associated with the profile segment(s) corresponding to START_TIME and STOP_TIME. BID_PRICE associated with each segment of a profiled request must match the corresponding OFFER_PRICE for the reservation request's STATUS to be set to CONFIRMED.
CUSTOMER_CODE and CUSTOMER_DUNS shall be determined from the registered connection used to input the request.
Template: anccust


  1. Input

CONTINUATION_FLAG

ASSIGNMENT_REF (Required)

START_TIME

STOP_TIME

REQUEST_REF

DEAL_REF

BID_PRICE

PRECONFIRMED

STATUS=


REBID, CONFIRMED, WITHDRAWN

STATUS_COMMENTS

STATUS_NOTIFICATION (If left blank, then the original URL from the ancrequest will be used

CUSTOMER_COMMENTS




  1. Response (Acknowledgment)

RECORD_STATUS

CONTINUATION_FLAG

ASSIGNMENT_REF

START_TIME

STOP_TIME

REQUEST_REF

DEAL_REF


BID_PRICE

PRECONFIRMED

STATUS =

REBID, CONFIRMED, WITHDRAWN

STATUS_COMMENTS

STATUS_NOTIFICATION

CUSTOMER_COMMENTS

ERROR_MESSAGE
002-4.3.8.5 Seller to Reassign Service Rights to Another Customer (ancassign)
Seller to Reassign Service Rights to Another Customer (Input) (ancassign) is used by the seller to ask the Transmission Services Information Provider to reassign some or all of the seller's rights to Services to another Customer, for seller confirmed transactions that have occurred off the OASIS Node.
Implementation of this Template is optional until such time that a business case requiring the use of such a facility to selectively reassign ancillary services is clearly demonstrated.
The TSIP shall assign a unique ASSIGNMENT_REF in the response (acknowledgment) and enter the status CONFIRMED as viewed in the ancstatus Template.
SELLER_CODE and SELLER_DUNS shall be determined from the registered connection used to input the request.
Only the following fields may be redefined in a continuation record for the ancassign input Template: CAPACITY, START_TIME, STOP_TIME, REASSIGNED_REF, REASSIGNED_CAPACITY, REASSIGNED_START_TIME, and REASSIGNED_STOP_TIME.
SELLER_CODE and SELLER_DUNS shall be determined from the registered connection used to input the request.
Template: ancassign


  1. Input

CONTINUATION_FLAG

CUSTOMER_CODE

CUSTOMER_DUNS

CONTROL_AREA

ANC_SERVICE_POINT

CAPACITY

SERVICE_INCREMENT

AS_TYPE

START_TIME



STOP_TIME

OFFER_PRICE

POSTING_NAME

REASSIGNED_REF

REASSIGNED_CAPACITY (Capacity being sold from each previous assignment)

REASSIGNED_START_TIME

REASSIGNED_STOP_TIME

SELLER_COMMENTS




  1. Response (acknowledgment)

RECORD_STATUS

CONTINUATION_FLAG

ASSIGNMENT_REF (assigned by TSIP)

CUSTOMER_CODE

CUSTOMER_DUNS

CONTROL_AREA

ANC_SERVICE_POINT

CAPACITY (Total capacity being reassigned)

SERVICE_INCREMENT

AS_TYPE

START_TIME



STOP_TIME

OFFER_PRICE

POSTING_NAME

REASSIGNED_REF

REASSIGNED_CAPACITY (Capacity being sold from each previous assignment)

REASSIGNED_START_TIME

REASSIGNED_STOP_TIME

SELLER_COMMENTS

ERROR_MESSAGE
002-4.3.9 Seller Posting of Ancillary Services
002-4.3.9.1 Seller Ancillary Services Posting (ancpost)
Seller Ancillary Services Posting (ancpost) is used by the Seller to post information regarding the different services that are available for sale by third party Sellers of ancillary services.
SELLER_CODE and SELLER_DUNS shall be determined from the registered connection used to input the request.
Template: ancpost


  1. Input

CONTROL_AREA

SERVICE_DESCRIPTION

CAPACITY


SERVICE_INCREMENT

AS_TYPE


START_TIME

STOP_TIME

OFFER_START_TIME

OFFER_STOP_TIME

SALE_REF

OFFER_PRICE

SELLER_COMMENTS


  1. Response (acknowledgment)

RECORD_STATUS

POSTING_REF (Assigned by TSIP)

CONTROL_AREA

SERVICE_DESCRIPTION

CAPACITY


SERVICE_INCREMENT

AS_TYPE


START_TIME

STOP_TIME

OFFER_START_TIME

OFFER_STOP_TIME

SALE_REF

OFFER_PRICE

SELLER_COMMENTS

ERROR_MESSAGE


002-4.3.9.2 Seller Modify Ancillary Services Posting (ancupdate)
Seller Modify Ancillary Services Posting (ancupdate) is used by the Seller to modify posted information regarding ancillary services that are available for sale by a third party Seller.
SELLER_CODE and SELLER_DUNS shall be determined from the registered connection used to input the request.
Template: ancupdate


  1. Input

POSTING_REF (Required)

CAPACITY (only if modified)

SERVICE_DESCRIPTION (only if modified)

START_TIME (only if modified)

STOP_TIME (only if modified)

OFFER_START_TIME (only if modified)

OFFER_STOP_TIME (only if modified)

SALE_REF (only if modified)

OFFER_PRICE (only if modified)

SELLER_COMMENTS (only if modified)


  1. Response (acknowledgment)

RECORD_STATUS

POSTING_REF

CAPACITY


SERVICE_DESCRIPTION

START_TIME

STOP_TIME

OFFER_START_TIME

OFFER_STOP_TIME

SALE_REF


OFFER_PRICE

SELLER_COMMENTS

ERROR_MESSAGE
002-4.3.10 Informal Messages
002-4.3.10.1 Provider/Customer Want Ads and Informal Message Posting Request (messagepost)
Provider/Customer Want Ads and Informal Message Posting Request (messagepost) is used by Providers and Customers who wish to post a message. The valid entries for CATEGORY shall be defined by providers and shall be listed in the List of CATEGORY Template.
CUSTOMER_CODE and CUSTOMER_DUNS shall be determined from the registered connection used to input the request.
When the OASIS node is out of service and transmission requests are received by the TP by phone or fax then the CATEGORY=OASIS_MAINTENANCE_OUTAGE will be used to document the outage. The VALID_FROM_TIME will be the time the outage started and VALID_TO_TIME will be the time the outage ended. A list of all transactions that occurred during the outage and entered afterwards will be available through a query of the transstatusTemplate using START_TIME_QUEUED= and STOP_TIME_QUEUED=.
Template: messagepost


  1. Input

SUBJECT


CATEGORY

VALID_FROM_TIME

VALID_TO_TIME

MESSAGE (must be specified)




  1. Response (acknowledgment)

RECORD_STATUS

POSTING_REF (assigned by information provider)

SUBJECT


CATEGORY

VALID_FROM_TIME

VALID_TO_TIME

MESSAGE


ERROR_MESSAGE
002-4.3.10.2 Message (message)
Message (message) is used to view a posted Want Ad or Informal Message. The CATEGORY Data Element can be queried.
Template: message


  1. Query

CUSTOMER_CODE

CUSTOMER_DUNS

POSTING_REF

CATEGORY

VALID_FROM_TIME

VALID_TO_TIME

TIME_POSTED




  1. Response

CUSTOMER_CODE

CUSTOMER_DUNS

POSTING_REF

SUBJECT

CATEGORY


VALID_FROM_TIME

VALID_TO_TIME

TIME_POSTED

CUSTOMER_NAME

CUSTOMER_PHONE

CUSTOMER_FAX

CUSTOMER_EMAIL

MESSAGE
002-4.3.10.3 Provider/Sellers Message Delete Request (messagedelete)


Provider/Sellers Message Delete Request (messagedelete) is used by Providers and Sellers who wish to delete their message. The POSTING_REF number is used to determine which message.
CUSTOMER_CODE and CUSTOMER_DUNS shall be determined from the registered connection used to input the request.
Template: messagedelete


  1. Input

POSTING_REF




  1. Response (Acknowledgment)

RECORD_STATUS

POSTING_REF

ERROR_MESSAGE


002-4.3.10.4 Personnel Transfers (personnel)
The personnel Template is used to indicate when personnel are transferred between the merchant function and the Transmission Provider function as required by FERC Statutes and Regulations (18 CFR 37.4(b)(2))Standards of Conduct Standards WEQ 009, or applicable regulations .
Template: personnel


  1. Query

TIME_OF_LAST_UPDATE

START_TIME_POSTED

STOP_TIME_POSTED




  1. Response

POSTING_NAME

EMPLOYEE_NAME

FORMER_POSITION

FORMER_COMPANY

FORMER_DEPARTMENT

NEW_POSITION

NEW_COMPANY

NEW_DEPARTMENT

DATE_TIME_EFFECTIVE

TIME_POSTED

TIME_OF_LAST_UPDATE


002-4.3.10.5 Discretion (discretion)
The discretion Template is used to describe the circumstances when discretion was exercised in applying terms of the tariff, as described in the Standards of Conduct Standards WEQ 009, or applicable regulations.FERC Statutes and Regulations (18 CFR 37.4(b)(5)(iii)).
Template: discretion


  1. Query

START_TIME_POSTED

STOP_TIME_POSTED

START_TIME

STOP_TIME

SERVICE_TYPE

SERVICE_NAME

TIME_OF_LAST_UPDATE




  1. Response

POSTING_NAME

RESPONSIBLE_PARTY_NAME (name of person granting discretion)

SERVICE_TYPE (ancillary or transmission)

SERVICE_NAME (make consistent with offering Templates)

TARIFF_REFERENCE

START_TIME

STOP_TIME

DISCRETION_DESCRIPTION

TIME_POSTED

TIME_OF_LAST_UPDATE
002-4.3.10.6 Standards of Conduct (stdconduct)
The stdconduct Template indicates when information is disclosed in a manner contrary to the standards of conduct, as described in the Standards of Conduct Standards WEQ 009, or applicable regulations.FERC Statutes and Regulations (18 CFR 37.4(b)(4)(ii)).
Template: stdconduct


  1. Query

START_TIME_POSTED

STOP_TIME_POSTED

TIME_OF_LAST_UPDATE


  1. Response

POSTING_NAME

RESPONSIBLE_PARTY_NAME

STANDARDS_OF_CONDUCT_ISSUES

TIME_POSTED

TIME_OF_LAST_UPDATE


002-4.3.11 Audit Log
The OASIS audit log report facility shall be implemented by the definition of the following Templates:
transofferingaudit - audit counterpart to transoffering

ancofferingaudit - audit counterpart to ancoffering

scheduledetailaudit - audit counterpart to scheduledetail

securityaudit - audit counterpart to security

systemdataaudit - audit counterpart to systemdata

transstatusaudit - audit counterpart to transstatus

ancstatusaudit - audit counterpart to ancstatus

personnelaudit - audit counterpart to personnel

discretionaudit - audit counterpart to discretion

dtdconductaudit - audit counterpart to stdconduct
Each of these audit Templates is an extension to the OASIS Template definitions of their non-audit counterparts. The requirements for implementation of the audit Templates is defined in the following sections.
002-4.3.11.1 Query Variables
Each of the audit Templates defined shall support exactly the same set of Query Variables as defined for their non-audit Template counterpart. As with the standard Template definitions, audit reports may be downloaded in Comma Separated Value (CSV) format by the specification of the OUTPUT_FORMAT=DATA Query Variable, or may be viewed using a web browser when OUTPUT_FORMAT=HTML is specified.
002-4.3.11.2 Audit Report Response Format
Audit report information shall be returned in response to a valid query request made to any of the audit Templates defined. Query variables may be specified as allowed by each individual Template and shall have the effect of limiting the scope of audit data returned to that set of information selected by that combination of additional Query Variables.
The response to an audit query shall consist of ordered sets of information reflecting both the current information as posted on OASIS and the full history of changes made to that information. These ordered sets of information are organized around the individual postings or "records" returned in response to the applicable non-audit Template. For example, execution of the transstatus (or ancstatus) Template returns a set of individual records identified by unique ASSIGNMENT_REF. The transstatusaudit Template response is then organized by ASSIGNMENT_REF and would show all changes made to those Data Elements associated with each individual ASSIGNMENT_REF record.
Execution of the transoffering (or ancoffering or systemdata) Template returns a set of individual records identified by unique POSTING_REF. The transofferingaudit Template response is then organized by POSTING_REF and would show all changes made to those Data Elements associated with each individual POSTING_REF record.
The specific audit report response format is detailed in the following sections.
002-4.3.11.3 Comma Separated Value (CSV) Format
A CSV formatted audit Template response shall comply with all the general provisions and specifications defined previously for a CSV formatted response. The CSV response records shall be organized in sets of records containing both the latest information posted on OASIS and all changes made to that information over time.
002-4.3.11.3.1 CSV Response Header Records
The following additional Data Element names shall be included as the first set of Data Elements in the COLUMN_HEADERS record and the corresponding Data Element values shall be included in each subsequent Data Record (row) returned in the audit response:
RECORD_TYPE

TIME_OF_LAST_UPDATE

MODIFYING_COMPANY_CODE

MODIFYING_NAME


These Data Elements shall precede the standard Data Elements associated with the specific Template being invoked.

The RECORD_TYPE Data Element shall take on one of the following restricted values:


I - denotes a record of information as it appeared on its initial Insertion (posting) on OASIS

U - denotes a record of information as it appeared immediately following an Update to the posted information

D - denotes a record of any Deleted information as it last appeared on OASIS.
The TIME_OF_LAST_UPDATE Data Element shall contain the time that the Template Data Elements were inserted, updated or deleted to the values reported in that record (row) of the response. This Data Element is identical to the standard Template TIME_OF_LAST_UPDATE Data Element, and is included as part of the fixed audit specific Data Element columns to aid users in sorting the audit response records.
The MODIFYING_COMPANY_CODE and MODIFYING_NAME Data Elements shall contain the identity of the entity (by the appropriate 4-6 character customer/provider code) and the person that inserted, updated or deleted the Data Elements to the values reported in that record (row) of the response. In the event the modification of posted information cannot be associated with a specific OASIS user (e.g., as a result of an automated back-end process), the MODIFYING_NAME Data Element may be null.
Immediately following the MODIFYING_NAME column header, each of the standard non-audit counterpart Template's Data Elements shall be listed in the exact sequence defined for that non-audit Template.
Finally, OASIS implementations may include additional Data Elements identified by unique column headers appended after the fixed audit and standard Template Data Elements. These additional Data Elements may be used to convey implementation specific information maintained in the OASIS database in association with the data being audited.
002-4.3.11.3.2 CSV Data Records
In formatting an audit response, OASIS shall collect and order information into sets of Data Records (rows). Each set of records returned shall include a record corresponding to the information as original inserted into the OASIS database denoted by a RECORD_TYPE of "I", and as many additional records with RECORD_TYPE of "U" corresponding to each update made to that information over time. If applicable, a record may also be returned in the set with a RECORD_TYPE of "D" if the corresponding information was effectively deleted from the database. The number of sets of audit report records returned in response to an audit query shall be determined by the number and type of additional Template Query Variables specified by the user.
002-4.3.11.3.3 CSV Continuation Records
Continuation records are used in certain standard Phase 1-A Templates to report repeating Data Elements associated with a single OASIS transaction such as demand profiles or the reassignment of rights on the secondary market. The first (CONTINUATION_FLAG=N) record and all associated continuation (CONTINUATION_FLAG=Y) records shall be treated as a group when generating the response to an audit query. To minimize the volume of information reported in an audit response, implementations may elect to suppress repeating the contents of information contained in continuation records if none of the Data Elements associated with those continuation records were modified. If, however, the Data Element(s) to be reported by an audit record are contained in one or more of the continuation records (e.g., a change was made to a transmission reservation's demand profile), the first (CONTINUATION_FLAG=N) record followed by the entire group of continuation (CONTINUATION_FLAG=Y) records shall be reported.
1   2   3   4   5   6   7   8   9   10   11


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

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