Service Request Validation Processing: Error Comment Explanations

 

Displayed Comment

Detailed Description

Fail Status

Insufficient Committed ATC

Checks to ensure the available Committed ATC is sufficient to accommodate the request. Firm TSRs are checked against the Committed Firm ATC. Non-Firm TSRs are checked against the Committed Non-Firm ATC. The MW Profile is compared with the ATC on the impacted segment(s) as specified on the TSR.

REFUSED

Insufficient Pending ATC

Checks to ensure the available Pending ATC is sufficient to accommodate the request. Firm TSRs are checked against the Pending Firm ATC. Non-Firm TSRs are checked against the Pending Non-Firm ATC. The MW Profile is compared with the ATC on the impacted segment(s) as specified on the TSR.

REFUSED

POD/POD Check

Checks to ensure the POR and POD on the request have been defined as a POR and POD in webTrans. This  validation should seldom fail, as OASIS does not allow a customer to request a POR or POD that has not been entered on OASIS. If the POR or POD has been entered as a service point on OASIS but not entered in webTrans the validation will fail.

INVALID

Source/Sink Check

Checks to ensure the Source and Sink combination entered on the request has been defined in the Source/Sink Data Summary display

in webTrans.

INVALID

Timing Check

There are four possible reasons for this comment to be generated.

1. Duration – The allowable length of a request in terms of hours, days, weeks, months, or years. The duration of the request is calculated as the ultimate stop time minus the ultimate start time.  If the request is beyond the

minimum or maximum duration specified the validation will fail.

2. Lead Time – Calculated as the start time minus the queued time of the request. The validation will fail if the lead time does not meet the minimum lead time or  exceeds the maximum lead time. If the Stoptime checkbox is selected when the timing requirement is entered, the request lead time will be calculated as stop time minus the queued time.

 

If the SpecialTiming checkbox is selected when the timing requirement is entered, the validation will checked against the WECC Prescheduling Calendar or the Special Timing Default Settings to see if an exception exists to extend the lead time.

 

3. Term/Increment – This validation requires that requests start at a particular hour, day of the month, or day of the week, if specified. Similarly, the request must stop at a particular hour, day of the month, or day of the week, if specified. If the Flexible checkbox is selected when the timing requirement is entered, the request can start or stop any time between the specified hours or days.

 

See the Reservation Timing Requirements Page for more details

 

·4. Pre-confirmed – If the Pre-confirmed checkbox is selected when the timing requirement is entered, the request must be pre-confirmed to pass validation if all other timing requirements are met.

DECLINED

Customer/Service Check

Checks to ensure the customer listed on the request is a valid customer eligible to purchase the requested type of service. Transmission Customer Summary can be entered and assigned the rights to purchase different contract types.

DECLINED

Credit Limit Check

Checks to ensure the MW profile multiplied by the Bid Price profile on the request does not exceed the available customer credit limit.

INVALID

REDIRECT Check

Checks to ensure the parent reservation, identified in  he Related Ref field, can support the redirect request.

INVALID

RESALE Check

Checks to ensure the parent reservation, identified in the Reassigned Ref field, can support the resale request.

INVALID

Bid Price Check

Checks to ensure the Bid Price on the request is equal to the Total Rate for the transmission service type, time period, and path.

NO CHANGE

Service/Path failed

 

DECLINED

Bid price out of range

Checks to ensure the Bid Price on the request is between the Ceiling Price and the Floor Price for that transmission service type.

DECLINED

RENEWAL

Checks to ensure the parent reservation, identified in the Related Ref field, can support the renewal request.

NO CHANGE

MATCHING

Checks to ensure the parent reservation, identified in the Related Ref field, can support the matching request.

NO CHANGE

DEFERRAL

Checks to ensure the parent reservation, identified in the Related Ref field, can support the deferral request.

NO CHANGE

Release

Checks to ensure the capacity on the Release request does not release capacity that has

already been scheduled on the parent reservation, identified in the Related Ref field. This

validation check will only be performed on reservations with the RELEASE request type.

NO CHANGE

Unposted POR/POD

Checks for reservations with a POR or POD

of NEWPOINT. NEWPOINT indicates an

unposted path is being used.

NO CHANGE

 

Last updated 6/5/08