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