This section provides examples of the most common error messages, their causes, and recommended solutions where applicable.

There are few steps that Exchange Shopping makes during transaction processing and, on each of these steps, an error message can be returned if the system detects the problem.

These steps are:

• Validation of incoming request against XSD schema.
• Business validation of incoming request and documents used in the transaction.
• Further validation of the requested document(s) and itinerary is performed by underlying subsystems.
• Searching for itinerary options and validating them against Category 31 of fares in exchanged tickets, which are done by the Shopping system.
• Calculating exchange cost for passengers, which is performed by the Post Calculation process.

Error Messages by Category

The following list contains error messages which are grouped in categories:

• Error messages coming from the orchestrating application Example:

  <ApplicationResults xmlns=“http://services.sabre.com/STL_Payload/v02_01" status=“Incomplete">
  <Error type=“Application" timeStamp=“2017-04-24T06:03:49.597-05:00">
      <SystemSpecificResults>
          <Message code=“ERR.SP.CLIENT.INVALID_REQUEST">Incomplete POS information - missing Actual element.</Message>
      </SystemSpecificResults>
  </Error>
  </ApplicationResults>

• Error messages coming from subsystems. Example:

  <ApplicationResults xmlns=“http://services.sabre.com/STL_Payload/v02_01" status=“Incomplete">
  <Error type=“Application" timeStamp=“2017-04-21T11:18:21.363-05:00">
      <SystemSpecificResults>
          <Message code=“ERR.SP.PROVIDER_ERROR">No valid shopping combinations found</Message>
      </SystemSpecificResults>
  </Error>
  </ApplicationResults>

  Please note that whenever the application encounters an error from any of the subsystems called, the generic error message No valid shopping combinations found will be returned. Service will then include all messages coming from subsystems as warnings.

Business Validation Errors

The business validation layer of Exchange Shopping request data verifies the following:

• Information in the XML request, such as checking if conflicting search or pricing parameters were used.
• Exchange Shopping eligibility, such as remaining OPEN coupons on the ticket, or correct reservations status included in the request.

Table of Common Business Validation Errors

The following table provides information about some other business validation errors that you may encounter.

Note: Long error message text contains variables (such as start and end location of leg, ticket number, and search parameters) that cause the particular issue.

Errors from Other Subsystems

Following are some of the common errors that may be returned by other subsystems working under Exchange Shopping. The following examples do not cover all possible errors but list the ones that are most common.

Unable to Verify Interline Coupon Status

Reason The Exchange Shopping web service was not able to get information about the real status of coupon in the “CTRL” status. Solution Try again in a few minutes. If the issue persists, contact the Web Services Support desk.

Unable to reprice - voluntary change rules failed

Reason This error is returned when the itinerary for which the passenger shopped is not allowed by Category 31 rules of the exchanged ticket. Solution Verify Category 31 filing of all exchanged fares in the ticket.

Unable to reprice – voluntary change rules unavailable

Reason At least one of the ticketed fares does not have a Category 31 rule. Solution Exchange Shopping requires Category 31 rules on all ticketed fares. The only option in this case is to book a new itinerary and use the standard desktop Exchanges product to calculate the exchange. Fares without Category 31 rules cannot be exchanged in the self-service environment.

Unable to match fares

This error message indicates that the ticketed fares were not found in the fare database, and consequently no Category 31 rules could be retrieved. Some of the instances where this occurs are:

• Ticket was issued with manually constructed fares not published in the Sabre system
• The ticketed fares were manually discounted