Agency Private Fares XML Interface Web Service - … · Agency Private Fares XML Interface Web Service Version 4.0 ... 160 SOAP Request ... associated rules are extracted to the Galileo

27 June 2011 © 2011 Travelport, Inc. All Rights Reserved. i Travelport Confidential - Not to Be Transmitted to Unauthorized Persons

Agency Private Fares XML Interface Web Service Version 4.0 27 June 2011

27 June 2011 © 2011 Travelport, Inc. All Rights Reserved. ii Travelport Confidential - Not to Be Transmitted to Unauthorized Persons

THE INFORMATION CONTAINED IN THIS DOCUMENT IS CONFIDENTIAL AND

PROPRIETARY TO TRAVELPORT

Copyright

Copyright © 2013 Travelport and/or its subsidiaries. All rights reserved.

Travelport provides this document for information purposes only and does not promise that the

information contained in this document is accurate, current or complete. This document is subject to

change without notice. No part of this document may be reproduced, stored in a retrieval system, or

transmitted in any form or any means electronic or mechanical, including photocopying and recording for

any purpose other than the licensee’s personal use without the prior written permission of Travelport

and/or its subsidiaries.

Trademarks

Travelport and/or its subsidiaries may have registered or unregistered patents or pending patent

applications, trademarks copyright, or other intellectual property rights in respect of the subject matter of

this document. The furnishing of this document does not confer any right or licence to or in respect of

these patents, trademarks, copyright, or other intellectual property rights.

All other companies and product names are trademarks or registered trademarks of their respective

holders.

27 June 2011 © 2011 Travelport, Inc. All Rights Reserved. iii Travelport Confidential - Not to Be Transmitted to Unauthorized Persons

Table of Contents Agency Private Fares (APF) Overview .................................................................................... 1

What’s New ............................................................................................................................... 3

Version 4.0, July 2011 ............................................................................................................................... 3

Version 3.0 ................................................................................................................................................ 3

APF XML Interface Introduction .............................................................................................. 5

How the XML Interface to APF Web Service Works ................................................................................. 5

Connectivity and Set Up .......................................................................................................... 7

Accessing APF XML Web Service Interface ............................................................................................. 7

Set Up Requirements ................................................................................................................................ 7

Requests and Responses........................................................................................................ 9

Requests ................................................................................................................................................... 9 Extract Times ......................................................................................................................................................... 9 Process Overview ................................................................................................................................................ 10

Responses ............................................................................................................................................... 10

Multiple Items in a Single Request .......................................................................................................... 12 Request Structure ................................................................................................................................................ 12

Best Practices .........................................................................................................................16

Contracts .................................................................................................................................17

Contract Terms ........................................................................................................................................ 17

Contract Types ........................................................................................................................................ 17

Contract Requests ................................................................................................................................... 18 SOAP Request ..................................................................................................................................................... 18 SOAP Responses ................................................................................................................................................ 19

Combinations ........................................................................................................................................... 21

Creating a Contract ................................................................................................................................. 22 Exceptions ........................................................................................................................................................... 22

Contract Examples .................................................................................................................................. 23 Standard Contract Example 1 .............................................................................................................................. 25 Standard Contract Example 2 .............................................................................................................................. 53 Standard Contract Example 3 .............................................................................................................................. 65 Standard Contract Example 4 .............................................................................................................................. 72 Standard Contract Example 5 .............................................................................................................................. 81 Standard Contract Example 6 .............................................................................................................................. 89 Calculated Contract Example 1 ............................................................................................................................ 93 Calculated Contract Example 2 .......................................................................................................................... 123 Calculated Contract Example 3 .......................................................................................................................... 136

Updating a Contract ............................................................................................................................... 146 Update Request ................................................................................................................................................. 146 Partial Update Request ...................................................................................................................................... 147 Partial Update of a Standard Contract Example ................................................................................................ 148 Partial Update of a Calculated Contract Example .............................................................................................. 150

27 June 2011 © 2011 Travelport, Inc. All Rights Reserved. iv Travelport Confidential - Not to Be Transmitted to Unauthorized Persons

Discontinuing a Contract ....................................................................................................................... 153

Add-on Fares ......................................................................................................................... 155

Add-on Fare and Standard Fare Construction ...................................................................................... 156

Creating Add-on Fares .......................................................................................................................... 157 How Add-on Linking Criteria Match to Standard Contracts ................................................................................ 158

Add-on Fare Requests .......................................................................................................................... 160 SOAP Request ................................................................................................................................................... 160 SOAP Responses .............................................................................................................................................. 160

Add-on Fare Scenarios.......................................................................................................................... 162 Route Display for Constructed Fares ................................................................................................................. 162 Fare Detail Display for Constructed Fares ......................................................................................................... 163 Fare Quote for Constructed Fares ..................................................................................................................... 164 Constructed Fares by Global Direction .............................................................................................................. 165 Removal of Duplicate Fares in the Fare Display ................................................................................................ 165 Matching of Construction Criteria ....................................................................................................................... 166 Example ............................................................................................................................................................. 166

Add-on Fare Example............................................................................................................................ 168 Request .............................................................................................................................................................. 168 Response ........................................................................................................................................................... 173

Updating Add-on Fares ......................................................................................................................... 174 How Updates May Affect Add-on Fares ............................................................................................................. 174

Partial Update of an Add-on .................................................................................................................. 175 Request .............................................................................................................................................................. 175 Response ........................................................................................................................................................... 176

Discontinuing an Add-on Fare ............................................................................................................... 177

Global Distribution Groups .................................................................................................. 178

Master Global Distribution Groups ........................................................................................................ 178

Request ................................................................................................................................................. 178

Master Global and Global Distribution Group Requests ....................................................................... 179 SOAP Request ................................................................................................................................................... 179 SOAP Responses .............................................................................................................................................. 179

Updating a Global Distribution Group .................................................................................................... 181 Partial Updates................................................................................................................................................... 181

Master Global and Global Distribution Group Examples ....................................................................... 182 Creating a Global Distribution Group Example .................................................................................................. 183 Creating a Master Distribution Group Example .................................................................................................. 187 Partial Updates of Global Distribution Groups Example ..................................................................................... 189 Complete Update of a Global Distribution Group Example ................................................................................ 193 Complete Update of a Master Distribution Group Example ................................................................................ 196 Deleting a Global Distribution Group Example ................................................................................................... 198

Zones ..................................................................................................................................... 200

Working with Zones for Add-on Fares ................................................................................................... 200

Zone Requests ...................................................................................................................................... 202 SOAP Request ................................................................................................................................................... 202 SOAP Responses .............................................................................................................................................. 202

27 June 2011 © 2011 Travelport, Inc. All Rights Reserved. v Travelport Confidential - Not to Be Transmitted to Unauthorized Persons

Creating a Zone ..................................................................................................................................... 205 Request .............................................................................................................................................................. 205 Response ........................................................................................................................................................... 207

Updating a Zone .................................................................................................................................... 208 Updating Zone Information in an Associated Add-on ......................................................................................... 208

Deleting a Zone ..................................................................................................................................... 209 Request .............................................................................................................................................................. 209 Response ........................................................................................................................................................... 210

List of Examples ................................................................................................................... 211

Error Messages ..................................................................................................................... 213

General Error Messages ....................................................................................................................... 213

Messages for Contracts......................................................................................................................... 215

Messages for Add-ons........................................................................................................................... 219

Messages for Global Distribution Groups.............................................................................................. 222

Messages for Zones .............................................................................................................................. 224

Disclaimer .............................................................................................................................. 225

APF XML Interface Web Service

27 June 2011 © 2009 Travelport, Inc. All Rights Reserved. 1 Travelport Confidential - Not to Be Transmitted to Unauthorized Persons

Agency Private Fares (APF) Overview

Galileo Agency Private Fares (APF) is a web-based product that allows travel agencies to enter their

negotiated airline fare contracts (private fare data). After they are entered, these private fares and their

associated rules are extracted to the Galileo 360º Fares database and are available for automated access,

display, and distribution to travel agents. Agency Private Fares includes the fare contracts within the

Galileo 360 Fares Public Fares database to integrate fare display, rule validation, and fare quote through

the Galileo, Apollo, and/or Worldspan host. Fares are fully integrated with Public Fares, Agency Private

Fares, and Airline Private Fares that may be in use by each specific agency.

Although many agencies maintain their own fares databases using the APF database, others use third-

party databases. Data from agencies who use third-party databases is not received by the Galileo 360

Fares database.

The APF XML Web Service Interface bridges the gap for agencies who are using third-party databases.

The Web Service provides a single point of fares access where fares can be easily migrated from one data

source to another for integration into a single display. It enables third-party fares to be presented in the

Galileo 360 Fares database by allowing contracts, add-ons, distribution groups, and zones to be processed

to the APF database via an XML Interface.

For agents that compare GDS and local fares databases, the APF XML Web Service Interface:

Provides an integrated fares display of all public and private fares.

Ensures total validation of fares and reduces agents' ADMs, bookings class errors, etc.

Reduces the need for agents to visually compare/order fares when checking GDS and non-GDS

displays.

For agents that load fares into both APF and third-party systems, the APF XML Web Service Interface:

Reduces errors in duplication of the manual fares loading process.

Reduces agency manpower time (loading fares twice).

Allows simultaneous updates.

The following diagram illustrates how the Agency Private Fares product and the Agency Private Fares

XML Web Service Interface work together to populate the Galileo 360 Fares database. Fares from both

Agency Private Fares users and APF XML Web Service Interfaces users are fully integrated in the

Agency Private Fares database and the Galileo 360 Fares database so that fully integrated fares are

displayed via Focalpoint and Viewpoint.





What’s New

Version 4.0, July 2011

Note: There are no breaking changes between schema versions 3.0 and 4.0. Therefore, any request coded

to work with version 3.0 will work with version 4.0.

The following modifications were made for version 4.0:

Version 4.0 schemas are available.

In Contract requests, the NorthAmerican boolean element has been changed to a

ContractGeoType element with values of NorthAmerican, International, and RoundTheWorld

(see Standard Contract Example 1 on page 25).

Note: If an XML request that was coded to version 3.0 of the schema (i.e., includes the

NorthAmerican element) is submitted, a transformer class modifies the request to use the

ContractGeoType element.

Asterisks can be included in the fare basis code for rule exceptions and for ticket detail and

selling level exception groups.

The calculated fare has a rule ID element and can apply to a private or public tariff.

A new passenger type for airpasses is allowed. See Standard Contracts Example 5 (page 81) for a

contract example using airpasses.

Surcharges can include days of the week data. See Surcharges in Standard Contract Example 1

for more information.

Additional options added to MinStay and MaxStay. See MinStay and MaxStay in Standard

Contract Example 1 for more information.

A RelationshipRestriction element has been added with values of AND or OR.

Multiple MinStay and MaxStay are allowed.

MinStay and MaxStay can be measured from the arrival or departure of the point of

turnaround.

A new help topic contains a list of all examples.

Version 3.0

Note: There are no breaking changes between schema versions 2.0 and 3.0. Therefore, any request coded

to work with version 2.0 will work with version 3.0.

The following modifications were made for version 3.0:

Master Distribution Groups (page 178) can now be created using APF_DistributionRQ. Contract-

specific master distribution groups can also be created (see Standard Contract Example 4 on page

72).

TktCode element added, which appends to or replaces the Fare Basis Code.

Permitted attribute added to Blackouts to define the travel direction in which blackout and

exception dates occur.



The following FareType values are now allowed: PremiumEconomy, PremiumBusiness,

PremiumFirst.

RelationshipRestriction added to FlightRule and CodeShare, which defines the relationship

between restrictions when multiple restrictions are listed.

Transfers updated to include TransferSurfaceSector, which defines whether or not surface sectors

are allowed and where they are allowed.

BookingCode maximum occurrences have been updated to 99.

GDS value now includes Worldspan (1P).



APF XML Interface Introduction

The APF XML Web Service Interface is a real-time sessionless service that accesses the existing

functionality behind the APF product. It consists of several XML schemas which allow access to Web

Services that can manage private fares contracts for third-party systems. The current message set is:

APF_ContractRQ and APF_ContractRS

APF_ZoneRQ and APF_ZoneRS

APF_AddonRQ and APF_AddonRS

APF_DistributionRQ and APF_DistributionRS

Requests to APF use the message-set ending in “RQ”. Each of the request schemas listed above also

includes the APF_ContractCommonTypes schema. Responses from APF (both error and success

indicators) use the message-set ending in “RS”. The APF XMLWeb Service Interface employs SOAP

document literal to encapsulate the requests and responses.

The APF schemas are based on the Open Travel Alliance (OTA) schemas and standards. This help system

details the use of an OTA-based interface supported by APF. The APF XML Web Service Interface also

includes Web Services Definition Language (wsdl) files, based on SOAP 1.2, to define the expected

interaction between the APF XML Web Service Interface and third parties

Notes:

Use of the APF XML Web Service Interface is governed by contracts and agreements between

Galileo and third-party customers (XML Vendor Licensees).

The APF XML Web Service Interface is a dedicated Web Service that is not related to the Galileo

Web Services (GWS). User names and passwords for GWS cannot be used for the APF XML

Interface.

This help system is not intended to be a tutorial on OTA messaging. Rather it explains the use of

specific elements and attributes within various OTA messages exchanged between a client

application and the APF services. The function of these messages is to create, update, or delete

contracts, distribution groups, and zones. For a concise explanation and examples of OTA

messages see Open Travel Alliance™. The schema version used is 2006A.

The help in the Agency Private Fares product provides further detail about all business functions

in the schemas. Contact your agency for access to the product help system.

How the XML Interface to APF Web Service Works

The APF product currently allows agencies to enter and manage negotiated fares using a web-based

interface. These fares are saved in a local APF database and pushed regularly (times on page 9) to the

Galileo 360 Fares database. The fare details are defined internally in the APF product as the Contract

object. The Contract object is central to all APF processing logic. Contracts contain at least one

Distribution Group object and may contain Zone objects. The existing web-based product is shown in the

blue components in the following diagram.

The APF XML Web Service Interface enhances the current APF product and allows for SOAP-based

requests to:

Create, update, and discontinue contracts and add-on fares.

http://www.opentravel.org/



Create, update, and delete zones and Global Distribution Groups.

The Web Service functionality is shown in orange in the following diagram.



Connectivity and Set Up

The APF XML Web Service Interface allows XML Vendor Licensees (third-party customers) to send

zones, Global Distribution Groups, add-on fares, and contracts to the APF product using an XML

document. The Web Service transaction is sent through a security layer where software parses the

document and creates Java objects in accordance with the current APF Java object model. The contract is

applied to the APF database and a success or failure message is returned to the requestor.

The current extract process in APF pulls this data into the Galileo 360 Fares database.

Accessing APF XML Web Service Interface

The Copy system URL for APF XML Web Service Interface is:

https://agencyprivatefarescopy.galileo.com/services/XAPFSvc

Note: The Production URL will be provided when you are fully provisioned for this product and when a

Service Order has been completed.

Set Up Requirements

Before using the APF XML Web Service Interface, the following must be set up:

The XML Vendor Licensee must have a unique APF XML Interface vendor code, which is

created as part of the Galileo provisioning. This vendor code is provided by Galileo and must be

included in the Code element of any XML request sent to the APF XML Interface.

A supplier must have the Authorized for XML Interface checkbox enabled in the APF product so

that a user in that supplier code can process data using the XML interface.

A user within the above supplier must be created in the APF product, with Agency – XML

Interface permissions. These permissions include the user name and password that must be sent

in the HTTP header of the XML requests to the APF server. The password must be exactly 25

characters and must contain all of the following:

o Upper- and lower-case letters.

https://agencyprivatefarescopy.galileo.com/services/XAPFSvc



o Numbers.

o Special characters.

The above requirements DO NOT give the Agency – XML Interface user permission to log into the APF

product. Contact your agency for access to the product help system.



Requests and Responses

Requests

There are four requests that can be sent with the APF XML Web Service Interface:

APF_ContractRQ – Request to upload Contracts.

APF_AddonRQ – Request to Add-on Fares.

APF_DistributionRQ – Request to upload Global Distribution Groups.

APF_ZoneRQ – Request to upload Zones.

Extract Times

All requests are sessionless; the system does not return session or state information. Upload requests are

immediately applied to the APF database and are included in the next scheduled extract from APF to the

Galileo 360 Fares database. Fares maintained within Agency Private Fares are uploaded to the database

throughout the day at the following times. The time represents the beginning of each extract process. The

changes are seen in the Galileo, Apollo, and Worldspan GDSs shortly thereafter.

APF Schedule Sunday - Friday Saturday

GMT

Standard Time

00:00 00:00

01:00 01:00

02:00 02:00

03:00 03:00

04:00 04:00

05:00 n/a

06:00 n/a

07:00 n/a

08:00 08:00

09:00 n/a

10:00 n/a

11:00 n/a

12:00 12:00

(resume hourly extract)

13:00 13:00

14:00 14:00



15:00 15:00

16:00 16:00

17:00 17:00

18:00 18:00

19:00 19:00

20:00 20:00

21:00 21:00

22:00 22:00

23:00 23:00

All requests are encrypted using SSL (HTTPS protocol) using the standard destination port number 443.

Process Overview

When sending APF XML requests, keep in mind the following process logic.

Requests to create zones and Global Distribution Groups must be sent before those new zones

and Global Distribution Groups can be included in a contract request.

Requests to create zones can be sent at any time because zone processing does not rely on

contract or Global Distribution Group data or processing.

A contract that uses zones or Global Distribution Groups that currently exist in the APF database

can be sent at any time.

A contract that creates a contract-specific distribution group or groups can be sent at any time.

To learn more about each request or response and its elements, refer to Contracts (page 17), Add-on Fares

(page 155), Global Distribution Groups (page 178), and Zones (page 200).

Responses

There are four responses that are returned from the APF server to the APF XML Web Service Interface:

APF_ContractRS – Success or Error response(s) to the request to upload one or more Contracts.

APF_AddonRS – Success or Error response(s) to the request to upload one or more Add-on

Fares.

APF_DistributionRS – Success or Error response(s) to the request to upload one or more Global

Distribution Groups.

APF_ZoneRS – Success or Error response(s) to the request to upload one or more Zones.

A Success or Error status is returned for each request element sent to indicate:



Success indicates the success of an XML for APF (XAPF) request, the response message contains

an empty <Success/> tag. <Warnings> are not implemented at this time.

Error indicates failure of an XAPF request, the response message contains a collection of

<Error> tags.

Each request element has its own response status.

In a Contract response, each request element is identified by its Contract ID. Each Contract

element also contains a version number, with the create request assigned version 1.

In an Add-on response, each request element is identified by its Add-on ID. Each Add-on element

also contains a version number, with the create request assigned version 1.

In a Distribution response, each request element is identified by its Distribution Name.

In a Zone response, each request element is identified by its Zone Name.

The XAPF response message is completely within the

http://agencyprivatefares.galileo.com/2006A/XAPF/4.0 name-space. The attributes of the

RS responses are defined by OTA, and not all are applicable to XAPF transactions.



Multiple Items in a Single Request

Each of the four request types (APF_ContractRQ, APF_AddonRQ, APF_DistributionRQ, APF_ZoneRQ)

provide the ability for batch processing, that is, sending multiple items in a single request.

Each request element has its own response status.

In a Contract response, each request element is identified by its Contract ID.

In an Add-on response, each request element is identified by its Add-on ID.

In a Distribution response, each request element is identified by its Distribution Name.

In a Zone response, each request element is identified by its Zone Name.

Request Structure

The basic request structure includes the header information, request element 1, request element 2, etc.

Each request element can have different source information and different request types.

Multiple Contract Request

The following example creates one new contract, updates a contract, and partially updates another

contract. This example is not a complete request and does not contain all required elements for a request.

For a complete example, see Standard Contracts Example 2 (page 53).

<?xml version="1.0" encoding="UTF-8"?>

<APF_ContractRQ xmlns="http://agencyprivatefares.galileo.com/2006A/XAPF"

Version="1.00">

<RequestElement>

<Source xmlns=”http://www.opentravel.org/OTA/2003/05” PseudoCityCode="B0B">

<RequestorID Type="18" ID="G1B0B" ID_Context="XML">

<CompanyName CompanyShortName="BHTRAVEL" TravelSector="1"

Code="1234567"/>

</RequestorID>

</Source>

<Contract xmlns=”http://agencyprivatefares.galileo.com/2006A/XAPF/4.0”

ContractGeoType="NorthAmerican" Type="NetAndSelling" Calculated="false"

RequestType="Create">

<ContractID>TST1</ContractID>

<AirlineCode>UA</AirlineCode>

All other necessary contract elements listed here.

</Contract>

</RequestElement>

<RequestElement>

<Source xmlns=”http://www.opentravel.org/OTA/2003/05” PseudoCityCode="N1G">



Code="1234567"/>

</RequestorID>

</Source>


ContractGeoType="International" Type="Selling" Calculated="false"

RequestType="Update">




<AirlineCode>BA</AirlineCode>


</Contract>

</RequestElement>

<RequestElement>




Code="1234567"/>

</RequestorID>

</Source>


ContractGeoType="NorthAmerican" Type="NetAndSelling" Calculated="false"

RequestType="PartialUpdate">


<AirlineCode>AA</AirlineCode>


</Contract>

</RequestElement>

</APF_ContractRQ>

Multiple Contract Response

The following response is an example of what would be returned with the above request.

Notes:

The first and second request element have the same Contract ID. However, the supplier code and

owning airline are different; therefore, identical names are allowed.

When a contract is first created, it is assigned a version of 1. Version numbers are increased with

each subsequent update to that contract.

<?xml version="1.0" encoding="UTF-8" ?>

<ns3:APF_ContractRS =”http://www.opentravel.org/OTA/2003/05”

xmlns:ns2="http://agencyprivatefares.galileo.com/2006A/XAPF/4.0"

xmlns:ns3="http://agencyprivatefares.galileo.com/2006A/XAPF">

<ns3:Contract>

<ns2:ContractID Version="1">TST1</ns2:ContractID>

<ns2:Success />

</ns3:Contract>

<ns3:Contract>


<ns2:Success />

</ns3:Contract>

<ns3:Contract>


<ns2:Success />

</ns3:Contract>

</ns3:APF_ContractRS>



Multiple Zone Request

The following example creates one new zone, updates a zone, and deletes a zone. This example is not a

complete request and does not contain all required elements for a request. For a complete example, see

Creating a Zone (page 205).


<APF_ZoneRQ xmlns="http://agencyprivatefares.galileo.com/2006A/XAPF" Version="1.00">

<RequestElement>




Code="1234567"/>

</RequestorID>

</Source>

<Zone xmlns=”http://agencyprivatefares.galileo.com/2006A/XAPF/4.0”

Name="WCOAST1" Type="Contract" RequestType="Create">

All other necessary zone elements listed here.

</Zone>

</RequestElement>

<RequestElement>




Code="1234567"/>

</RequestorID>

</Source>

<Zone xmlns=”http://agencyprivatefares.galileo.com/2006A/XAPF/4.0”

Name="ECOAST1" Type="Gateway" RequestType="Update">


</Zone>

</RequestElement>

<RequestElement>




Code="1234567"/>

</RequestorID>

</Source>

<Zone

xmlns=”http://agencyprivatefares.galileo.com/2006A/XAPF/4.0” Name="MIDWEST"

Type="Interior" RequestType="Delete">


</Zone>

</RequestElement>

</APF_ContractRQ>



Multiple Zone Response

The following response is an example of what would be returned with the above request. Note that, unlike

contracts, zones do not have version numbers.


<ns3:APF_ZoneRS xmlns=”http://www.opentravel.org/OTA/2003/05”

xmlns:ns2=”http://agencyprivatefares.galileo.com/2006A/XAPF/4.0”

xmlns:ns3=”http://agencyprivatefares.galileo.com/2006A/XAPF”>

<ns3:Zone>

<ns2:ZoneName>WCOAST1</ns2:ZoneName>

<ns2:Success />

</ns3:Zone>

<ns3:Zone>

<ns2:ZoneName>ECOAST1</ns2:ZoneName>

<ns2:Success />

</ns3:Zone>

<ns3:Zone>

<ns2:ZoneName>MIDWEST</ns2:ZoneName>

<ns2:Success />

</ns3:Zone>

</ns3:APF_ZoneRS>



Best Practices

When you send requests with the APF XML Web Service Interface, the following best practices are

recommended for the following scenarios.

Your system allows more data than APF

If the APF XML Web Service Interface contract request does not contain elements or tags for data that

your system allows, send those elements and tags as free-form rules text.

Send the extra information in the <Rules> element, with <Title> set to OTHER_NOTES,

<IgnoreGenerated> set to 1 (yes), and <TextLine> providing a description.

<Rules>

<Rule Title="OTHER_NOTES" IgnoreGenerated="1">

<TextLine>Extra data included here.</TextLine>

</Rule>

</Rules>

APF is more restrictive than your system

If the APF XML Web Service Interface contract request cannot distinguish between items that your

system can, send the most restrictive APF_ContractRQ request that you can (i.e., send elements and tags

in their most simple form), and then send specific details in the free-form rules text.

APF is less restrictive than your system

All contracts should be reviewed in the Agency Private Fares GUI after they have been loaded with the

APF XML Web Service Interface.



Contracts

The APF_ContractRQ request sends contract details to APF for processing. Multiple contracts can be

submitted in a single request (e.g., you can send two new contracts and an update to an existing contract

in a single request). A response is returned from APF with a success/error message for each contract sent,

depending on whether the contract has been successfully processed.

The APF_ContractRQ request can be used to create, update, or discontinue either of the following two

contract types:

Calculated Contracts, which use fares that are calculated against an existing airline filed, public,

or private set of base fares. Rules can be either those that the airline files, or contract-specific

rules.

Standard Contracts, where all the contract fare and rule details are manually submitted with the

contract.

These two contract types are the same as the contract types that can be entered using the APF web-based

product. The APF product has sixteen different contract windows, including Flight Rules, Advance

Reservations and Ticketing, and Combinations. The contract window options are mirrored exactly in the

APF_ContractRQ schema.

For a contract to be valid and to quote accurately, the minimum data entry requirement for both the

APF_ContractRQ request and the APF product is:

Basic high-level contract details, such as Contract ID, Airline Code, Contract Type, and North

American (True/False), followed by:

Fares/Routes

Distribution

All other contract elements are optional, but it is recommended that Combinations are sent with the

request to ensure the correct journey types are selected for proper quoting of the contract.

Contract Terms

Net Fare - The standard term for the agreed amount that an agency (or consolidator) pays an airline for a

negotiated fare. This amount is sometimes referred to as the Net Submit, Net Remit, Net Net, or Net

Report amount.

Selling Fare - The standard term for the amount a passenger pays the agency (or consolidator) for the

negotiated fare.

Contract Types

The contract type is defined in the <Contract> element of the APF_ContractRQ. There are three types of

contracts:

Net - A contract containing only net fares. The contract fares may be sold at the net price or may

be increased to a selling level. The Net contract may or may not contain the limits or parameters

for a suggested selling level. Use the <SellingFareParams> element within <Distributions> to



enter these parameters. The Net contract type should only be used if the business practice calls for

it.

Selling - A contract where the fare amounts entered are the selling price. In Standard contracts,

the selling fares are entered in Fares. In Calculated contracts, the selling fares are entered in the

Fare Calculation.

Net and Selling - A contract that contains both the net amounts and selling amounts. Use the

<SellingFare> element within <Distributions> to define the net and selling amounts.

See Contract Requests (below) and Contract Examples (page 21) for more details.

Contract Requests

The SOAPBodyElement for a contract is called APF_ContractRQ. It is a request to upload a contract to

the APF system. The Contract Examples (page 21) provide sample requests and responses.

SOAP Request

The following sample includes a SOAP request, a successful response, and a failure response. The

placeholders shown need to be replaced with actual values.

The HTTP header will appear similar to the sample in the following request. The APF server expects the

APF XML Interface user ID and password (the user ID and password associated with the Supplier code

that has XML Interface permissions) to be sent in the "Authorization: Basic" field. The user ID and

password are encoded in BASE 64 in the format userid”:”password. For more information about user ID

and password, see Connectivity and Set Up on page 7.

Following a blank line, the XML SOAP payload begins. The APF server does not expect any data in the

SOAP header section, so it can be omitted. The SOAP body contains a single XML element, which is the

APF transaction to be performed. No other elements are allowed.

Request

POST /XAPF HTTP/1.1

Accept-Language: en

Content-Type: type="text/xml";

action="APF_ContractRQ";

Content-Length: 9999

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

User-Agent: SOAP Client

Host: www.apf.galileo.com

<?xml version="1.0" encoding="utf-8"?>

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">

<soap:Body>

APF_ContractRQ

</soap:Body>

</soap:Envelope>



SOAP Responses

There are two types of response that can be sent for a request: Success or Failure. Currently, XML for

APF (XAPF) does not issue warnings. A failure response always includes errors.

The HTTP header appears similar to that shown in the following responses. Following a blank line the

XML SOAP payload begins. XAPF does not expect any data in the SOAP header section, so it can be

omitted. The SOAP body contains a single XML element, which is the XAPF transaction response.

Successful Response

HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

Content-Type: text/xml;charset=utf-8

Content-Length: 777

Date: Wed, 12 Apr 2006 22:27:33 GMT

Connection: close



<soap:Body>

<ns3:APF_ContractRS

xmlns=”http://www.opentravel.org/OTA/2003/05”



<ns3:Contract>

<ns2:ContractID Version="1">AAG1</ns2:ContractID>

<ns2:Success />

</ns3:Contract>


<soap:Body>

</soap:Envelope>

Failure Response

HTTP/1.1 200 OK



Content-Length: 777

Date: Wed, 12 Apr 2006 22:27:33 GMT

Connection: close



<soap:Body>

<ns3:APF_ContractRS




<ns3:Contract>

<ns2:ContractID Version="1">AAG1</ns2:ContractID>



<ns2:Errors>

<ns1:Error Type="EWT" Code="4"

xmlns:ns1="http://www.opentravel.org/OTA/2003/05">Request Rejected –

Invalid User ID or Password</ns1:Error>

</ns2:Errors>

</ns3:Contract>


<soap:Body>

</soap:Envelope>



Combinations

Contracts entered in the Agency Private Fares database can be combined with:

Other contracts in the same supplier code in the APF database.

Airline filed public and private fares.

IATA YY fares.

ATP and SITA public and private fares.

Combinations outside of the APF database are driven by the data filed in the ATP and SITA fares, as well

as in the APF contract. If the airline rule restricts combinations by a specific tariff or rule number, the

Agency Private Fares fare will not pass combinations. ATP/SITA rules do not use Agency Private Fares

tariff information or rule number.

Contract combinations include:

Single or multiple journey types (e.g., round trips, single open jaws, etc.)

Inside and outside the current contract rule ID.

Note: Open jaw is allowed anywhere and is not restricted within one country.

Combinations must be fully defined. For example, if a contract for carrier XX is permitted to combine

with a contract for carrier YY, both contacts must contain the permission. If the YY contract does not

permit the XX contract in combination, the two will never combine.



Creating a Contract

The APF_ContractRQ is used to create both standard and calculated contracts. The main difference in

available elements between the two types of contracts is the use of the <BaseFareGroup> element in the

Standard contract and the use of the <CalcFareGroup> element in the Calculated contract. The

contracts in both the Standard contract example and the Calculated contract example are created and

processed successfully. Successful processing indicates the contract has been committed in the APF GUI

product. The effective date of the contract in the APF product is the date that it is sent and a Success

response is received.

Exceptions

All contract requests can include exceptions for specific elements. The exception types are:

<FareBasisCode> – The Fare Basis Code.

<Origin> and <Dest> – The pair of cities between which the exception applies. If the contract

uses zones, the city pairs must be entered in the appropriate zones. For example, Zone1 contains

LON, PAR, MUC and Zone2 contains DEN, HOU, WAS. The city pair must use one city from

Zone1 and one city from Zone2.

Note: Entering a city or country in the origin and nothing in the destination results in the rule

exception applying between the city/country in the origin and all other locations in the contract.

<FareBasisCode> and <Origin>/<Dest> – The Fare Basis Code and the city pair.

Notes:

Only one exception type can be sent for each element in the request. For example, if one

<Seasons> exception uses <Origin> and <Dest>, all other season exceptions in that request

can only use city pairs, although the cities in the pair can be changed. In that contract,

<FareBasisCode> or Fare Basis Code /city pair exceptions cannot be defined for <Seasons>.

A contract update can be sent with a different exception type, but all existing exceptions must be

deleted before the exception with a different type can be sent.

If fares use city codes, then exceptions must use city codes.



Contract Examples

The following table lists the contract examples contained in the APF XML Web Service help. The

Description column lists the XML elements that are defined within the request.

Example Description

Calculated Contract 1 (page 93)

Creates a single Calculated contract with the following settings:

Net and selling, international contract

Global distribution group

Ticketing details and selling levels

Seasons with exception

Days of the week with exception

Reservation ticket time limits with exceptions

Min and max stays

Blackout dates with exceptions

Flight rules

Code shares with exceptions

Stopovers with exceptions

Combinations

Surcharges with exceptions

Discounts with exceptions

Rules


Creates a Calculated contract with the minimum viable elements.


Updates the contract created in Calculated Contract Example 2.

Net and selling, North American contract

Fare decrease of 15%

One contract-specific distribution group

Fare basis code with a wildcard

TicketDetailAndSellingLevels exception using a fare family

Standard Contract 1 (page 25)

Creates a single Standard contract with the following settings:

Selling and international contract

Contract-specific distribution group


Seasons with exceptions

Days of the week with exceptions

Reservation ticket time limits with exceptions

Min and max stays with exceptions

Blackout dates with exceptions

Flight rules

Code shares with exceptions


Combinations

Surcharges that only apply on specific days of the week



Discounts with exceptions

Transfers

Rules


Updates one Standard contract, and creates another standard contract. The first section of the example has the following settings:




Transfers

The second section of the example creates a standard contract with the following settings:

Selling, international contract






Selling, international contract

Add-on fare construction permitted


Transfers

Note: This contract is used in conjunction with the create add-on fare example.




Master distribution groups




Net and selling, international contract


Airpasses and fare family

Discounts


Creates a Standard contract for a round-the-world fare.

Partial Update of a Standard Contract (page 148)

This example partially updates the standard contract created in example 1. This request updates the transfers defined in example 1.

Partial Update of a Calculated Contract (page 150)

This example contains the minimum viable elements required to partially update an existing Calculated contract.

Discontinuing a Contract (page 153)

Discontinues an active contract.



Standard Contract Example 1

The following example does not depict ALL elements or sub-elements that can be used in the request.

It is included for reference only.

The standard contract in this example is:

A Selling contract.

An international contract.

A one-way trip for an adult.

Has fares that depart from Denver, or any city or state/province, country, or area in the USWEST

zone and arrive in Tokyo.

Has one contract-specific distribution group, QXDIST, which allows agencies that are part of the

distribution group to Sell and Ticket.

Request

Elements and sub-elements in purple are required. In some cases, the sub-elements are only required

because the optional parent element is used.

Explanation Code

Defines the namespace for the APF_ContractRQ request and the version of the XAPF schema.


<APF_ContractRQ

xmlns="http://agencyprivatefares.galileo.com/2006A/XAPF

" Version="1.00">

RequestElement contains one contract's information.

Source provides requestor details. The Source namespace is OTA. Type is ignored by XAPF, but required for schema compliance. Because no definition exists for providers of airline fare data, use 18 to indicate "Other".

ID is the supplier code in which the contract resides.

Both CompanyShortName and Code are provided for the XML Vendor Licensee by Galileo, when the Licensee is provisioned, and both are used for billing purposes.

CompanyShortName provides the name of the XML Vendor Licensee. This name can be up to 32 characters.

Code is the Galileo numeric identifier, is provided to the Licensee by Galileo, and is up to seven digits.

<RequestElement>

<Source


PseudoCityCode="B0B">

<RequestorID Type="18" ID="G1B0B"

ID_Context="XML">

<CompanyName CompanyShortName="BHTRAVEL"

TravelSector="1" Code="1234567"/>

</RequestorID>

</Source>



The Contract namespace is the APF XML location, including the version number.

ContractGeoType defines the geography of the contract: NorthAmerican, International, or RoundTheWorld.

Calculated defines the contract type. A value of true indicates a calculated contract, while a value of false indicates a standard contract.

Type of contract:

Selling

Net

NetAndSelling

RequestType indicates the type of request for this contract (Create, Update, PartialUpdate). Create indicates that this is a new contract. Update and PartialUpdate indicate it is an update to an existing contract. Contracts cannot be deleted, but the discontinue date can be changed to make them inactive. Discontinued contracts remain in the database as historical contracts for one year after the discontinue date.

<Contract

xmlns=”http://agencyprivatefares.galileo.com/2006

A/XAPF/4.0” ContractGeoType="International"

Type="Selling" Calculated="false"


Contract rule IDs are unique per supplier/airline code combination throughout the system.

The Contract ID must contain four alpha, numeric, or alpha AND numeric characters. It does not have to include the airline code, but can include the airline code. No special characters or blanks are allowed. 9999 is not a valid rule ID.

<ContractID>QZ02</ContractID>

AirlineCode is the primary airline for this contract.


AccountCode can be up to 20 alpha-numeric characters, and must begin with an alpha character.

<AccountCode>A1234</AccountCode>

TourOrNetRemitCode can be up to 15 alpha-numeric characters. Tour codes/Net Remit codes display in the filed fare and print on the ticket.

<TourOrNetRemitCode>AAR102</TourOrNetRemitCo

de>

Description is a free-form text line for reference, where you can enter a description for the contract.

<Description>AA Net</Description>



DiscontinueDate is the date the contract is discontinued from the active system. It is also the last travel and ticket date, if not overridden by the optional travel and ticket dates. This date cannot be more than three years out from the effective date.

This date is used to determine when to purge a contract from the system. A contract is purged from the system on the first Saturday following 1 year after the discontinue date. It is not used for any date validation in 360°Fares.

<DiscontinueDate>2009-08-

31</DiscontinueDate>

FirstDateTravel is the earliest date on which outbound travel can begin if later than the contract effective date. This date cannot be earlier than the effective date, or earlier than the first ticket date.

LastDateTravel is the departure date of the first flight of the fare component, if earlier than the contract discontinued date. This date cannot be later than the discontinued date.

FirstDateTicket is the earliest date a ticket may be issued, if later than the contract effective date.

LastDateTicket is the last date to issue a ticket, if earlier than the contract discontinue date.

<FirstDateTicket>2008-08-

10</FirstDateTicket>

<LastDateTicket>2009-08-31</LastDateTicket>



FareGroupName is the user-defined name of the fare group. The maximum FareGroupName is 20 alpha-numeric characters.

Type indicates whether this is a OneWay, Return, or OneWayOnly fare. OneWayOnly is only valid for non-North American contracts.

The Origin and Dest (destination) Location is the city or airport code of the fare. Countries, states/provinces, and areas are not valid entries in a standard contract.

Zone is the user zone of the fare.

Set ImportNewVersion to "true" to have the contract get a new version of the zone from the APF database. See Updating a Contract (page 146) for more details.

You can enter multiple Locations and Zones. However, there are some restrictions:

You can enter all airport codes, all city code, or all zones.

You can combine airport codes and city codes, or city codes and zones. The example combines city codes and zones.

You cannot combine airport codes and zones.

Zone rule exceptions:

If a zone is built that includes Newark (EWR) in the city listing, that zone CANNOT be used when creating a fare.

If a zone includes Puerto Rico or the U.S. Virgin Islands, these are entered as states of the U.S. Their individual country codes must not be used.

Note: Zones must be created for a country, state/province, or area if a fare is valid for any of those, then enter the zone name in the Zone, as appropriate.

Direction defines whether the Location or Zone is interpreted as an origin or destination: from or between. Values can be sent as per the following table.

Note: NA = NorthAmerican, Int = International, RTW = RoundTheWorld.

NA Int RTW

Standard

From Between (default)

From From

Calculated

From Between

From (default)

N/A

<BaseFareGroup FareGroupName="OneWay">

<Fare Type="OneWay">

<Origin>

<Location>DEN</Location>

<Zone

ImportNewVersion="true">USW

EST</Zone>

</Origin>

<Dest>

<Location>TYO</Location>

</Dest>

<Direction>From</Direction>

<BookingCode>AN</BookingCode>

<FareType>PremiumEconomy</FareTyp

e>

<Amount Amount="1234.56"

CurrencyCode="USD" />

<PsgrType PsgrType="ADT" />

<FareBasisCode>AA</FareBasisCode>

<TktCode>REPLACE</TktCode>

<TktDesignator>HECTOR</TktDesigna

tor>

</Fare>



(default) Between

BookingCode is the one- or two-character booking code(s) valid for travel between the origin, destination, and via cities. The maximum number of booking codes allowed between each location is eight. The codes must be separated by a space. If a booking code is two characters long it must end in N.

FareType describes the fare. The choices are Economy, PremiumEconomy, Business, PremiumBusiness, First, and PremiumFirst.

Amount is the amount of the fare. The CurrencyCode in which the fare amount is calculated. Fares can be filed in any valid currency. This amount matches the fare in the contract so it needs to be either Return or OneWay amount (a OneWayOnly fare will also match the OneWay amount coded). If there are OneWay, OneWayOnly, and Return fares in the contract, you need to create and exception for each type and enter the applicable ticket fare amount.

PsgrType describes the passenger. Any valid three-character alpha passenger type code can be entered.

MinAge and MaxAge are attributes of PsgrType. They are optional and only available for certain Passenger Type Codes. The maximum age must be greater than or equal to the minimum age.

FareBasisCode is a code that identifies a fare. The first character must be an alpha. It cannot exceed eight alpha and numeric characters.

TktCode is a 1 – 10 character entry that replaces or alters the Fare Basis Code (FBC) on the ticket and in the linear when the fare is quoted. It is not used as match criteria for any rule provisions of the contract. The information must be alphanumeric with one exception; a hyphen is permitted in the first position. When a ticket code is entered with a hyphen preceding it, the information will be appended to the end of the Fare Basis Code. For example, if the FBC is J2RT and the ticketing code is "-SPCL", the resulting FBC will be J2RTSPCL. If there is no hyphen, the resulting FBC would be SPCL. If the ticket code results in a fare basis code that is too long for the space on the ticket, it will truncate.

TktDesignator is a 1 – 10 character alphanumeric entry that appends to the fare basis code.



Add routings after the fares associated with the contract are defined. Routings can be Simple or Complex, and you can add a combination of both routing types to a single contract. Data entered in SimpleRouting and ComplexRouting can impact the validity of data entered in Combinations, CodeShares, and FlightRules. If routings are not defined, combinations, code shares, and/or flight rules may not validate at the time of quoting.

A routing choice must be included when creating a BaseFareGroup.

Multiple cities can be entered. Blank spaces between cities are converted to a dash (-), which means to or from. If you want the simple routing to contain one city OR another, use a slash (/) to separate the cities.

Simple routings example:

A contract on airline XX that permits stopovers and transfers, using the services of XX only, is considered a simple routing. To enter a simple routing, list codes for the cities that may be transited in the order of travel.

If SimpleRouting cities are not entered, only direct or nonstop travel is validated, and itineraries that include via points will fail Fare Quote. City codes and airport codes are valid entries. Origin and Destination cities do not need to be entered. Use spaces between cities/airports.

<SimpleRouting>OMA OKC

BOS</SimpleRouting>

Complex routings are ONLY valid on non-North American standard contracts.

It is very important to create a routing for every possible path on which travel is allowed. Each routing should contain the permitted airlines and cities.

A complex routing allows for multiple via cities, and for travel on different airlines on that routing. Enter ComplexRouting in the following sequence: airline1 city1 airline2 city2 airline3, etc. (ending with an airline). City codes and airport codes are valid entries. Origin and destination cities do not need to be entered.

The following characters can be used to define complex routings:

A forward slash (/) indicates OR.

A hyphen (-) indicates AND.

In the example, the fare is available on either American Airlines or British Airways via Portland or Atlanta.

<ComplexRouting>F9 IAH

AC</ComplexRouting>

<ComplexRouting>AA/BA-PDX/ATL-

AA/BA</ComplexRouting>



Define the AirlineRoute to use a published airline route for the fare. Ensure that the booking codes for any airline permitted on the contract are included in the route. If booking codes are not defined for these airlines, they cannot be quoted on an itinerary as a secondary airline.

<AirlineRoute>

<AirlineRouteNumber>2323</Airline

RouteNumber>

<AirlineRouteTariff>121</AirlineR

outeTariff>

</AirlineRoute>

SecondaryAirlineBookingCode defines secondary airline booking codes and exceptions to those booking codes. Up to 999 booking codes can be added for each secondary airline.

<SecondaryAirlineBookingCode

Airline="CO">

<BookingCodes>A B C D E F G

H</BookingCodes>

</SecondaryAirlineBookingCode>


Airline="CO">

<BookingCodes>V W X Y

Z</BookingCodes>


<SecondaryAirlineBookingCodeException

Airline="BA" From="NYC" To="MAN">

<BookingCodes>I J K L M N O

P</BookingCodes>

</SecondaryAirlineBookingCodeException

>


Airline="BA" From="NYC" To="LON">


P</BookingCodes>


>


Airline="BA" From="NYC" To="PAR">


P</BookingCodes>


>


Airline="BA" From="NYC" To="HAM">


P</BookingCodes>


>

BookingcodeException allows you to enter up to 999 exceptions to the primary airline.

The city or country in From or To defines where the exception is valid. Zones and airport codes are not allowed. To define an exception from one city or country to all worldwide locations, enter a From value but do not enter a To value.

<BookingcodeException From=”PHX”

To=”LAX”>


P</BookingCodes>

</SecondaryAirlineBookingCodeException>

</BaseFareGroup>



Action defines whether this is a new contract-specific distribution group, a current Global Distribution Group, or an update to a contract-specific or Global distribution group. Note that multiple distribution groups can be sent in a request.

Set Action to:

CreateFromGlobal to use a global distribution group to create a contract-specific distribution group in this contract.

CreateFromLocal to create a contract-specific distribution group for this contract.

GDS provides the computer reservation system:

1G for Galileo

1V for Apollo

1P for Worldspan

Name is the distribution group name (maximum of 50 characters). Alpha-numerics (A to Z, 0 to 9), full stop (.), slash (/), dash (-),colon (:), underscore (_), asterisk (*), apostrophe ('), and blank (space) are valid. Name is case-sensitive and must be all caps.

Description is the description of the distribution group (maximum of 100 characters).

DistributionBasis defines how the distribution group is accessed:

AllAgencies - Distribute the contract to all agencies within the selected GDS.

Agencies - Distribute the contract to specific agencies identified by PCC or IATA number. If set to true, an <Agency> is required.

Geographic - Distribute the contract to all Galileo agencies within a geography. If set to true, a <Location> is required.

AgencyAndGeographic - Distribute the contract to agencies in a certain location. If set to true, both <Agency> and <Location> are required.

In addition, the security level for the organisation/location must be chosen. If you have Net or Net and Selling fares, a location must be given ticketing authority to see the net level.

DistSecLevels defines the agencies and associated security levels assigned to this distribution list. At least one security level must be assigned.

Locations define the specific

<Distributions>

<Distribution

Action="CreateFromLocal">

<DistributionGroup GDS="1V">

<Name>QXDIST</Name>

<Description>Test

DG</Description>

<DistributionBasis

Agencies="true"/>

<DistSecLevels>

<DistSecLevel>

<Agency>N17</Agency>

<Security

Update="false"

Redistribute="false"

Sell="true"

Ticket="true"/>

</DistSecLevel>

</DistSecLevels>

</DistributionGroup>



geography (countries, states/provinces, or cities). Cities are three characters, and countries and states are two. However, states and provinces must contain the country code as well. For example, Massachusetts is USMA; the country code (US) and then the state code (MA).

Agency defines the specific travel agency code or Pseudo City Code (PCC). IATA codes can be up to eight numeric characters. PCCs are three or four alphanumeric characters.

Security specifies the access given to a distribution list:

Update – Set to "true" to give agencies access in the Agency Private Fares product to copy the contract and change certain fields. This also allows agencies to view fares and rules in Galileo, Apollo, and Worldspan from fare display. Set to "false" to deny agencies the permission to copy the contract.

Redistribution – Set to "true" to allow agencies to view fares and rules in Galileo, Apollo, and Worldspan from fare display. Redistribution gives the same permission to other agencies having a business relationship with the agency named in the distribution list.

Sell – Set to "true" to allow agencies to view fares from a fare display and get a fare quote in Galileo, Apollo, and Worldspan. Note: Apollo and Worldspan do not differentiate between Sell and Ticket. If an agency/geography is given Sell authority, it can both sell and ticket.

Ticket – Set to "true" to allow agencies to view fares from a fare display and get a fare quote and issue a ticket on booked itineraries, in Galileo, Apollo, and Worldspan.

TicketingDetailAndSellingLevels is used to enter ticket details and create selling levels for the selected distribution group.

See the Calculated Contract Example (page 93) for more information about ticket and selling options and exceptions.

You must have distribution groups associated with the current contract to set up ticketing details and selling levels.

If the contract is:

<TicketDetailAndSellingLevels>

<TicketDetailAndSellingLevel>

<ExceptionGroup

TripType="OW">

<FareClass>

<FareBasisCode>AAA

</FareBasisCode>

</FareClass>

</ExceptionGroup>

<Passenger>ADT</Passenger>



Selling – You can enter ticketing details if you choose, but cannot enter selling levels.

Net – You can enter ticketing details and selling levels if you choose. Note: If you create a Net only contract, the default takes the Net fare and applies it as the Selling and Ticket fare.

Net & Selling – You must enter at least a Passenger and you must enter an exception and selling levels (ticket information is optional).

Exceptions can be filed for ticketing and selling information.

Only one exception can be selected for the entire contract (either Fare Basis Code (FBC) or Fare Family). An asterisk can be used as a wildcard.

Use ExceptionGroup TripType to define the fares to which the exception applies:

OW = One way

RT = Round trip

OW/RT = One way and round trip

Passenger is the three-character passenger type code to which this ticketing and selling level applies. The default is ALL, which is also a valid entry, although it is not part of the Passenger Type Code list. Note: All ticketing data and associated selling levels are tied to the passenger type. Ticketing detail can only be entered once for an exception group and passenger type combination (e.g., OW exception for ADT passenger type), but selling levels with different geography can exist as long as the ticketing data matches for all selling level exceptions.

TicketDetail defines ticketing details, such as baggage overrides, plating carrier, type, and commission overrides, for the distribution group.

BaggageType values include:

PC = Override the baggage allowance with the number of pieces of baggage allowed.

KG = Override the baggage allowance with a weight in kilograms.

For TicketRules, the following values are valid:

A = Retrieve FBC / Fare Family and amount.

B = Use contract FBC / Fare Family and retrieve amount.

<TicketDetail>

<BaggageOverride

BaggageType="PC"

Allowance="5"/>

</TicketDetail>

</TicketDetailAndSellingLevel>

</TicketDetailAndSellingLevels>

</Distribution>

</Distributions>



F = Retrieve FBC / Fare Family and use contract amount.

U = Use specified FBC / Fare Family and amount. Note: TicketRules cannot be set to U when UseYYFare=true.

Seasons define the seasons that exist within the contract.

FirstDate specifies the first date on which travel is permitted, if different than the effective date of the contract. LastDate specifies the last date on which travel is permitted, if different than the discontinued date of the contract. Set dates that apply every year using the dashdashMMdashDD format (--12-31).

Permitted defines the portions of the fare the seasons apply to:

Outbound - Outbound only

Inbound - Inbound only

Either - Inbound and outbound

If Outbound and Inbound, a season cannot be added for Outbound Only or Inbound Only. If Outbound Only and/or Inbound Only, make sure the dates do not overlap.

Applicable sets the portion of the journey to which the first and last date apply:

Departure of Journey Origin (D)

Departure of Each Fare Component (E)

Departure of the First International Sector of the Journey (F)

Departure of the First International Sector of Each Fare Component (I)

Exception sets exceptions to the Seasons. Exception limitations defined in Creating a Contract apply.

<Seasons>

<Season>

<FirstDate>2008-09-10</FirstDate>

<LastDate>2009-08-25</LastDate>

<Applicable>D</Applicable>

<Permitted>Inbound</Permitted>

</Season>

<Season>



<Applicable>E</Applicable>


</Season>

<Exception FareBasisCode="B"

Origin="LAX" Dest="OMA">



<Applicable>D</Applicable>


</Exception>

</Seasons>



Days of Week (DOWs) defines the days of the week on which a passenger can travel, for this contract. For example, one city pair on a contract can have different day of week restrictions than the rest of the contract. If travel is permitted on all days, there is no restriction and DOWs do not need to be entered.

ValidDays defines the specific days on which travel is permitted 1=Monday, 2=Tuesday, 3=Wednesday, 4=Thursday, 5=Friday, 6=Saturday, 7=Sunday.

Permitted defines the direction in which travel is permitted:









Exception sets exceptions to the Day of Week. Exception limitations (page 22) defined in Creating a Contract apply.

<DOWs>

<DOW ValidDays="1235" Applicable="E"

Permitted="Inbound" />

<Exception ValidDays="467"

Applicable="D" FareBasisCode="N"


</DOWs>



ResTktTimeLimits defines the length of time in advance that reservations and ticketing must take place for the contract to be valid.

Permission is either:

Latest = not permitted later than

Earliest = not permitted earlier than

Use NumberOfDays or DayOfWeek to define the latest time that reservations are permitted before departure from origin.

DayOfWeek options are 1=Monday, 2=Tuesday, 3=Wednesday, 4=Thursday, 5=Friday, 6=Saturday, 7=Sunday.

In TktTimeLimit, AfterReservation defines the number of days or hours after the reservations are made. Unit is DAY or HOUR. When AfterReservation is used, ResTimeLimit Permission must be set to L.

BeforeDeparture defines the number of days or hours before the departure from origin. Unit is DAY or HOUR.

When both BeforeDeparture and AfterReservation are defined, specify the Rule to use when choosing between the two times.

EARLIEST = Use the time that is earliest.

LATEST = Use the time that is latest.

Exception sets exceptions to the Advanced Reservation and Ticketing. Exception limitations defined in Creating a Contract apply.

<ResTktTimeLimits>

<ResTktTimeLimit>

<ResTimeLimit

Permission="Earliest">

<NumberOfDays>21</NumberOfDays>

</ResTimeLimit>

<TktTimeLimit


<BeforeDeparture Unit="HOUR"

Value="10"/>

</TktTimeLimit>

</ResTktTimeLimit>

<ResTktTimeLimit>

<ResTimeLimit Permission="Latest">


</ResTimeLimit>

<TktTimeLimit Permission="Latest">

<BeforeDeparture Unit="DAY"

Value="30"/>

</TktTimeLimit>

</ResTktTimeLimit>

<Exception FareBasisCode="AAA">



</ResTimeLimit>


<AfterReservation Unit="DAY"

Value="40"/>

</TktTimeLimit>

</Exception>

</ResTktTimeLimits>

MinStays specifies details about the minimum stay length of the contract. Do not use this option for one-way fares.

TravelFrom defines the Return Travel From:

Farthest Geographical Point (F)

Last Point of Stopover (L)

Departure of the Last Sector (D)

Departure of inbound transatlantic sector (A)

Departure of inbound transpacific sector (P)

Arrival at point of turnaround (W)

Departure from point of Turnaround (T)

StayUnit defines the stay restriction: Days, MON, TUES, WED, THU, FRI,

<MinStays>

<MinStay TravelFrom="F"

DepartFrom="FareOrigin" MinStay="7"

StayUnit="Days"

RelationshipRestriction="AND"/>

<MinStay TravelFrom="T"

DepartFrom="FirstInternationalSector"

MinStay="3" StayUnit="Days"

RelationshipRestriction="AND"/>

<Exception Origin="DEN" Dest="ATL"

TravelFrom="L" DepartFrom="FareOrigin"

MinStay="14" StayUnit="Days"/>

<Exception Origin="BOS" Dest="BWI"

TravelFrom="L"

DepartFrom="OutboundTranspacificSector

" MinStay="14" StayUnit="Days"

RelationshipRestriction="OR"/>

</MinStays>

<MaxStays>

<MaxStay TravelFrom="F"

DepartFrom="FareOrigin" MaxStay="4"



SAT, or SUN. Note that other values are available in the schema but are not accepted by APF.

DepartFrom choices are:

FareOrigin

FirstInternationalSector

OutboundTransatlanticSector

OutboundTranspacificSector

RelationshipRestriction defines whether all or just one restriction must be true. The values are AND or OR. When the relationship is AND, all restrictions entered must pass to pass Minimum Stay. When the relationship is OR, any single restriction can pass to pass Minimum Stay.

MaxStay allows you to specify details about the maximum stay.







StayUnit defines Days or Months. Note that other values are available in the schema but are not accepted by APF.

DepartFrom options are:

FareOrigin


MaxStay defines the maximum stay length.

RelationshipRestriction defines whether all or just one restriction must be true. The values are AND or OR. When the relationship is AND, all restrictions entered must pass to pass Maximum Stay. When the relationship is OR, any single restriction can pass to pass Maximum Stay.

Exception sets exceptions to the Min and Max Stay. Exception limitations defined in Creating a Contract apply.

StayUnit="Months"

RelationshipRestriction="OR"/>

<Exception FareBasisCode="*BE70"

TravelFrom="L"

DepartFrom="FirstInternationalSector"

MaxStay="4" StayUnit="Days"/>

</MaxStays>



A blackout is a period of time, within a season or during the life of the contract, when the fares are not available for sale. BlackoutDates define the dates or date ranges during which travel is not allowed.

Dates define the date or date range for which the contract fares are not applicable.

Permitted defines the travel direction in which blackout and exception dates occur:




Set the Date on which travel is not permitted. Use the dashdashMMdashDD format (--12-31) to set dates that apply every year.

AND/OR

Set the Range for which travel is not permitted. StartDate and EndDate must be entered and must have the same date format. For example, a StartDate without a year (--12-29) must have an EndDate without a year (--01-02).

Exception sets exceptions to the Blackout dates. Exception limitations defined in Creating a Contract apply.

<BlackoutDates>

<Dates Permitted="Either">

<Date Date="--12-24" />

<Range StartDate="--12-29"

EndDate="--01-02" />

</Dates>

<Exception FareBasisCode="V"

Permitted="Inbound">

<Dates>

<Date Date="2008-12-31" />

</Dates>

</Exception>

</BlackoutDates>

FlightRules defines the airlines and flight numbers or flight number ranges on which a passenger can travel. It also sets limits on the cities/airports and countries through which the passenger can fly. To limit cities/airports and countries, make sure appropriate locations are entered in SimpleRoutings and ComplexRoutings.

FlightRules may or may not be related to data in CodeShares and ComplexRouting. However, the type of data entered in FlightRules limits the type of data that can be entered in CodeShares.

Make "positive" or "negative" Rule statements:

MustBe (positive)

MustNotBe (negative)

IfTravells (positive) -- only applies to RoutingOptions.

FlightRules can be (MustBe and/or IfTravelIs) or can contain one, and ONLY one, negative statement (MustNotBe). This means that if travel MustNotBe online connection, for example, any other statements in RoutingOptions (such as via city) must be positive.

If all FlightRules are positive, all CodeShares must be positive. If

<FlightRules>

<FlightRule Direction="Both"

RelationshipRestriction="AND">

<FltRqmts Rule="MustBe"

Direct="false" NonStop="false"

OnlineConn="false" />

<Flights Rule="MustBe"

Airline="AA">

<FlightNumberRange

RangeStart="1010"

RangeEnd="1210" />

</Flights>

<RoutingOptions Rule="MustNotBe">

<Via Loc="OKC" />

</RoutingOptions>

</FlightRule>

<FlightRule Direction="Outbound"



Direct="false" NonStop="false"



Airline="AA">

<FlightNumberRange

RangeStart="2010"

RangeEnd="2210" />

</Flights>



FlightRules contains a negative statement, CodeShares must contain a negative statement.

The options entered in FlightRules DO NOT impact the options in the FlightRules Exception or CodeShares Exception.

Direction defines the direction of travel to which the rule applies:



Both - Inbound and outbound

If the rule is not based on direction, set Outbound and Inbound.

RelationshipRestriction defines the relationship between the restrictions if multiple restrictions are listed within a <FlightRule>:

AND indicates that ALL restrictions must pass. Note: If Rule=MustNotBe, then RelationshipRestriction must equal AND.

OR indicates that any one restriction can pass the rule.

Define whether the flight is NonStop, Direct, and/or OnlineConn (online connection).

Define Flights for the primary or secondary airline (or airlines), using Airline and FlightNumber and/or FlightNumberRange.

Exception set exceptions to Flight Rules. Exception limitations defined in Creating a Contract apply.

Exceptions in FlightRules are linked to exceptions in CodeShares. This link means that the type of exception (e.g., fare basis code, city pair) used in FlightRules is also the type of exception that must be used in CodeShares, if code share exceptions are entered.

Flight rule exceptions are unique. When adding multiple flight rule exceptions, they can be positive or negative. Subsequent exceptions are not dependent on the first exception.

For example, FareBasisCode = ABC = all positive statements for the first exception, the second can be FareBasisCode = XYZ = negative statement or all positive statements.

<RoutingOptions Rule="MustBe">

<Via Loc="DFW" />

</RoutingOptions>

</FlightRule>

</FlightRules>



CodeShares defines code share details for the contract.

Data in CodeShares may or may not be related to data in FlightRules and ComplexRouting. However, the type of data entered in CodeShares limits the type of data that can be entered in FlightRules.

CodeShares can be all positive (MustBe and/or IfTravelIs) or can contain one, and ONLY one, negative statement (MustNotBe). This means that if travel MustNotBe on marketing airline XX and operating airline YY, any other statements in RoutingOptions (via this city or between cities) must be positive.

If all CodeShares are positive, all FlightRules must be positive. If CodeShares contains a negative statement, FlightRules must contain a negative statement.

The options entered in CodeShares DO NOT impact the options in the CodeShares Exception or FlightRules Exception.

Direction defines the direction to which the restriction applies:




RelationshipRestriction defines the relationship between the restrictions if multiple restrictions are listed:



MktgOperatings defines whether the flights must or must not be on the MarketingAirline and the OperatingAirline; maximum of 50 pairs.

Make "positive" or "negative" statements:

MustBe (positive)


IfTravelIs (positive)

Note: RoutingOptions limits the code share restriction to specific portions of the itinerary.

Exception sets exceptions to the Code Share. Exception limitations defined in Creating a Contract apply.

Exceptions in CodeShares are linked to exceptions in FlightRules. This link means that the type of exception (e.g., fare basis code, city pair) used in CodeShares is also the type of

<CodeShares>

<CodeShare Direction="Inbound"


<MktgOperatings Rule="MustBe">

<MktgOprtng

MarketingAirline="UA"

OperatingAirline="BA"/>

</MktgOperatings>

</CodeShare>

<CodeShare Direction="Outbound"


<MktgOperatings Rule="MustNotBe">

<MktgOprtng

MarketingAirline="UA"

OperatingAirline="BA"/>

</MktgOperatings>

</CodeShare>

<Exception Direction="Both"

Origin="NYC" Dest="LAX">

<MktgOperatings Rule="MustNotBe">

<MktgOprtng

MarketingAirline="AA"

OperatingAirline="DL" />

</MktgOperatings>

<RoutingOptions Rule="MustBe">

<Via Loc="OMA" />

</RoutingOptions>

</Exception>

</CodeShares>



exception that must be used in FlightRules, if flight rules exceptions are entered.

Code share exceptions are unique. When adding multiple code share exceptions, they can be positive or negative. Subsequent exceptions are not dependent on the first exception.




Stopovers define the permitted number of free and charged stopovers. Stopovers also sets limits on the cities/airports, countries, and gateways at which the passenger can stop. It also defines whether travel into and out of all stopover points must be on the same airline.

FreeStopover:

MaxNumber defines the number of free stopovers permitted. ** indicates unlimited stopovers.

MinNumber defines the minimum number of stopovers required to qualify for the fare. Note: If a MinNumber is defined, MaxNumber is required and must be greater than or equal to the MinNumber.

InAndOutPermitted – Set to "true" to allow either inbound or outbound stopovers, but not both. Set to "false" to define the number of inbound and outbound stopovers. InboundNumber and OutboundNumber must equal the number in MaxNumber.

OnlineOnly – When set to "true," all travel into and out of all stopovers must be on the same airline.

GatewayOnly – Set to "true" if the free stopovers are only allowed at gateways. If GatewayOnly is set to true in conjunction with airports/cities, stopovers are only permitted at the airports/cities if they are gateways. If GatewayOnly is set to true in conjunction with countries, stopovers are only permitted at the gateways in the country or countries specified.

If MaxNumber contains a number (not **), define how stopovers are permitted, using:

Locations Permitted defines the allowed ("true") or disallowed ("false") locations. CitiesAirports and/or Countries must contain values (up to a maximum of 12 combined) to define where stopovers can or cannot occur.

ChargedStopover:

MaxNumber defines the number of charged stopovers permitted. ** indicates unlimited stopovers.

InAndOutPermitted – Set to "true" to allow either inbound or

<Stopovers>

<Stopover>

<FreeStopover MaxNumber="3"

MinNumber="2"

InAndOutPermitted="false"

OutboundNumber="1">

<Locations Permitted="true">

<CitiesAirports>DEN ABQ

LAX SFO

SAN</CitiesAirports>

<Countries>CA US MX

</Countries>

</Locations>

</FreeStopover>

<ChargedStopover MaxNumber="3"


OnlineOnly="true">

<Locations Permitted="false">

<CitiesAirports>NYC</Citi

esAirports>

</Locations>

<Fee CurrencyCode="USD"

Amount="15.00"/>

</ChargedStopover>

</Stopover>

<Exception FareBasisCode="STPOVR">


InAndOutPermitted="true"

GatewayOnly="true">


<CitiesAirports>PDX</Citi

esAirports>

</Locations>

</FreeStopover>

</Exception>

</Stopovers>



outbound stopovers, but not both. Set to "false" to define the number of inbound and outbound stopovers. InboundNumber and OutboundNumber must equal the number in MaxNumber.


ChildInfantDiscounts can be set to "true" (discounts apply) or "false" (discounts do not apply). Applicable discounts must be entered in Discounts.



Fee defines the amount to be charged per stopover. CurrencyCode defines the currency in which the amount is charged.

Notes:

One or two currencies/amounts can be defined. The amounts are based on the Fare amounts.

At the time of fare quote, the system looks for a match to the currency of the fare quote. If none of the currencies entered match the currency of the fare quote, the system converts the currency it finds to the currency of the quoted fare. If two surcharge currencies are found and neither match the quoted fare, both surcharges are converted to neutral currency units (NCUs) and the lowest is applied to the fare.

Exception sets exceptions to the Stopovers. Exception limitations defined in Creating a Contract apply.



Contracts entered in the APF database can be combined with:



IATA YY fares.


For an overview of Combinations within APF, see Combinations (page 21).

Combinations define the permitted combinations for the contract. Ensure that the appropriate routing is entered in SimpleRouting and ComplexRouting.

Combinations must be fully defined. For example, if a contract for carrier XX is permitted to combine with a contract for carrier YY, both contacts must contain the permission. If the YY contract does not permit the XX contract in combination, the two will never combine.

WithinContract defines the journey types available for the contract airline or any airline if the contract allows combinations with any airline in the contract. Airline defines the airline on which the combination is permitted. If no airline is defined, the contract can combine with any airline in the contract.

ContractRuleID is the rule for the contract that combines with this one. Note: ContractRuleID 9999 is not valid.

OutsideContract creates combinations between this contract and other contracts/airlines. Combinations outside the current contract rule ID may combine with other contracts in the same supplier code, applicable airline filed fares, and IATA YY fares. If no ContractRuleID is defined, this contract can combine with all Contract Rule IDs outside of this contract, including other contracts in your supplier code, airline filed fares, and IATA YY fares.

OJTrip defines the type of open jaws allowed. Only one open jaw type is permitted per contract. Open jaw is allowed anywhere and is not restricted within one country.

OJTripType values are:

OJ – single open jaw

DOJ – single or double open jaw

TOJ – turnaround open jaw

<Combinations>

<WithinContract Airline="BA">

<ComboTripTrip>

<OJTrip OJTripType="OJ"

HighestFare="false"/>

</ComboTripTrip>

</WithinContract>

<WithinContract ContractRuleID="QX01">

<ComboTripTrip>

<NonOJTrip>EO</NonOJTrip>

</ComboTripTrip>

</WithinContract>

<OutsideContract Airline="AA"

ContractRuleID="ABCD">

<ComboTripTrip>

<NonOJTrip>CT</NonOJTrip>

</ComboTripTrip>

</OutsideContract>

<OutsideContract

ContractRuleID="EFGH">

<ComboTripTrip>


HighestFare="true"/>

</ComboTripTrip>

</OutsideContract>

</Combinations>



OOJ – origin open jaw

If HighestFare is set to true, the highest fare is used in the combination.

NonOJTrip type values are:

RT – round trip.

CT – circle trip. When international calculated contracts are created it is important to set CircleTrip to "true". An International quote comprised of two half round trip fares can sometimes result in a circle trip. The contract will fail to quote unless circle trips are permitted. Omit circle trip combinations if the contract restricts the combination.

EO – end on. For North American contracts containing OW fares, EndOn must be "true" if the fares are expected to be used on round trip journeys.

If Combinations are not set for a non-North American contract, only round trip journeys within the same contract for the primary carrier of the contract are allowed. You may keep this coding, delete it by sending an update request for the contract with updated combinations, or add more combination options.



Surcharges define the surcharges that are applied to tickets purchased using this contract. All fares loaded via the APF XML Interface have standard airline surcharges applied to them.

Set AppliesDirection to define the direction of travel to which the surcharge applies:




ApplyDays is used to specify that surcharges only apply when travel is on specific days of the week. Enter the value of each day for which the surcharge applies (e.g., 234 indicates that the surcharge only applies on Tuesday, Wednesday, and Thursday). The days of the week are defined as follows: 1=Monday, 2=Tuesday, 3=Wednesday, 4=Thursday, 5=Friday, 6=Saturday, 7=Sunday.

Use LifeOfContract to define surcharges that are applied for the life of the contract.

Set StandardSurchargeExempt to "true" to exempt the surcharges that would normally be applied by the airline whose fares you are entering in this contract.

Note: Set StandardSurchargeExempt to "true" and enter no other data to ensure surcharges do not apply to the fares in this contract. When this option is set, it exempts the standard surcharge for the entire journey, for the life of the contract. Date and Inbound/Outbound have no effect on the exemption.

Use Dated to define StartDate and StopDate. Use the dashdashMMdashDD format (--12-31) to set dates that apply every year.

Note: At least one amount must be entered to use the Start/Stop dates.

Data defines the amount and currency of the surcharge.

AppliesPsgrType defines the passenger type(s) to which the surcharge applies:

ALL - All Passengers

“” – Default; the surcharge applies to all passengers, same as ALL.

ADT+CHD - Both Adult/Child (default - the surcharge applies to all passengers, same as above)

ADT+CHD-DISC - Both Adult/Child - Child Discounted -

<Surcharges>

<Surcharge AppliesDirection="Inbound"

ApplyDays=”34”>

<LifeOfContract>

<Data AppliesPsgrType="ADT">

<Amount CurrencyCode="USD"

Amount="15.00"/>

<Amount CurrencyCode="CAD"

Amount="20.00"/>

</Data>

</LifeOfContract>

<FlightSelector>

<FlightRanges range1="333"

range2="350"/>

</FlightSelector>

</Surcharge>

<Surcharge AppliesDirection="Outbound">

<LifeOfContract>

<Data AppliesPsgrType="ADT+CHD-

DISC">


Amount="30.00"/>


Amount="50.00"/>

</Data>

</LifeOfContract>

<FlightSelector>

<FlightNumbers flightno="111"/>



</FlightSelector>

</Surcharge>

</Surcharges>



this applies to Infant also, but you must have a discount set up for the child and/or infant in Discounts. If the child/infant is a published fare, do not use this option.

ADT - Adult Only

Amount defines the amount that is added to each fare component. CurrencyCode defines the currencies.

Notes:

One or two currencies and amounts can be defined.


FlightSelector is used to define surcharges that are only applicable if travel is via a certain airport (Locations) and/or when travel is on a certain flight (FlightNumbers and/or FlightRanges).

Exception sets exceptions to the Surcharges. Exception limitations (page 22) defined in Creating a Contract apply.

Discounts define discounts for the contract. All discounts are based off the primary passenger type entered in Fare. Discounts can be set for any qualifying passenger type.

PrimaryPsgrType defines the primary passenger type. Only passenger types in Fare are valid.

PsgrType defines the passenger type to which the discount applies. The choices are based on the child, infant, and youth options available for each adult passenger type entered in Fare. E.g., if ADT and MIL are entered in Fare, both CNN and MNN are valid entries, in addition to other PTCs that apply.

Important! If both ADT and CLG have CNN discounts, Agency Private Fares takes the *lowest* discount of the two. If the CNN from ADT discounts 10% and the CNN from CLG discounts 20%, anytime a user enters CNN, the 20% discount is applied.

The MinAge and MaxAge for the discount. They are optional and only

<Discounts>

<Discount PrimaryPsgrType="ADT"

PsgrType="CNN" MinAge="2" MaxAge="5"

TktCode="APPEND" TktDesignator="A">

<Percent Percent="15" />

</Discount>

<Exception FareBasisCode="L"

Origin="LAX" Dest="OMA"

PrimaryPsgrType="ADT" PsgrType="CNN"

MinAge="2" MaxAge="5"

TktCode="REPLACE" TktDesignator="A">

<Values>



</Values>

</Exception>

</Discounts>



available for certain Passenger Type Codes. The maximum age must be greater than or equal to the minimum age.

TktCode defines a 1-10 character entry, if necessary. It replaces or alters the Fare Basis Code (FBC) on the ticket and in the linear when the fare is quoted. It is not used as match criteria for any rule provisions of the contract. The information must be alphanumeric with one exception; a hyphen is permitted in the first position. When a ticket code is entered with a hyphen preceding it, the information will be appended to the end of the Fare Basis Code. For example, if the FBC is J2RT and the ticketing code is “-SPCL”, the resulting FBC will be J2RTSPCL. If there is no hyphen, the resulting FBC would be SPCL. IF the ticket code results in a fare basis code that is too long for the space on the ticket, it will truncate.

TktDesignator defines a 1-10 character alphanumeric entry, if necessary.

Values defines a decrease to the fare by a percent or a flat amount. The calculation applies to the fare amount in the Fare not an amount created in the SellLevel in Distributions.

To decrease the fare by a percent, use the Percent element and set the Percent (0-100) by which the fare will be decreased.

To decrease the fare by an amount, use the Amount element and enter the Amount by which the fare will be decreased. Set the CurrencyCode that applies to the amount.

Exception sets exceptions to the Discounts. Exception limitations defined in Creating a Contract apply.



Transfers defines the transfers and surface sectors allowed within a contract. If your contract restricts transfers, define the restrictions using TransferLocDir.

TransferRuleBase defines how the transfer rules are to be applied to the pricing unit:

WholePricingUnit

IndividualFareComponent

Direction is used to define the maximum number of transfers and direction restrictions, if the direction is not limited to specific locations. If transfers are limited to specific locations, use LocationAndDirection instead.

TransferBound values are as follows:

NotRestricted = Not restricted by direction

InboundOrOutbound

NumberBound

LocationAndDirection defines transfers that are limited to a specific location. The number of locations defined for all sections of LocationAndDirection may not exceed 16.

Direction defines the direction of travel to which the transfer applies:

Both = Both outbound and inbound

Outbound = Outbound only

Inbound = Inbound only

Either = Either outbound or inbound, but not both

A surface sector is a sector between two intermediate points of a fare component where travel is via other than air transportation. The TransferSurfaceSector defines whether or not surface sectors are allowed and where they are allowed. The fare over the surface sector is covered by the through fare component.

<Transfers>

<Transfer

TransferRuleBase="WholePricingUnit">

<Direction MaxNumber="2"

TransferBound="NotRestricted"/>

<LocationAndDirection>

<TransferLocDirs>

<TransferLocDir

NumberPermitted="1"

Location="BOS"

Direction="Outbound"

Permitted="true"/>

</TransferLocDirs>

</LocationAndDirection>

<TransferSurfaceSector

Direction=”Either”>

<SurfaceSector

Permitted=”true”>

<Location>US-

CA</Location>

</SurfaceSector>

</TransferSurfaceSector>

</Transfer>

</Transfers>



Rules display in standard Galileo, Apollo, and Worldspan formats. The descriptions entered in Rules explain the contract details in simple terms.

Important! Auto-generated text is created from data filed in the contract rules and is validated by the Galileo 360 Fares system when you price an APF fare. User-entered text is informational only and is not validated at the time of pricing. As well, user-entered text displays in Fare Quote and Fare Display Follow-on entries preceded by a NOTE identifier.

Title (or rule paragraph) sets the various rule text headings.

IgnoreGenerated defines whether automatically generated rules text is used.

Do not ignore generated text -- 0 or "false".

Ignore generated text -- 1 or "true"

TextLine defines the text for the Title. Alpha-numerics (A to Z, 0 to 9), full stop (.), slash (/), dash (-), colon (:), asterisk (*), and blank (space) are valid.

Title

Available titles are:

ACCT_CODE

DAY_OF_WEEK

SEASONS

CODE_SHARE (which is also flight restrictions)

ADV_PURCH

MIN_STAY

MAX_STAY

STOPOVERS

TRANSFERS

COMBINATIONS

BLACKOUTS

SURCHARGES

TRAVEL_RESTRICTIONS

SALES_RESTRICTIONS

CANCEL_CHANGE

HIP

ENDORSEMENTS

DISCOUNTS_CHD (Children)

DISCOUNTS_OTHER

CONTRACT_DETAILS

FOP (Form of Payment)

NET_SELLING

OSI

OTHER_NOTES

ROUTING

TICKETING_DETAILS

<Rules>

<Rule Title="DISCOUNT_CHD"

IgnoreGenerated="0">

<TextLine>For passenger type

ACCOMPANIED CHILD decrease fares

by 15 percent. Ticket designator

A. Ages 2-5.</TextLine>

</Rule>

<Rule Title="MIN_STAY"


<TextLine>Return travel from Last

Point of Stopover must commence

no earlier than the first WED

after departure from FARE

ORIGIN</TextLine>

</Rule>

</Rules>

</Contract>

</RequestElement>

</APF_ContractRQ>



Response

The Success response indicates a successful upload of the contract to the APF server.


<ns3:APF_ContractRS xmlns=”http://www.opentravel.org/OTA/2003/05”



<ns3:Contract>

<ns2:ContractID Version="1">QZ02</ns2:ContractID>

<ns2:Success />

</ns3:Contract>







The following request contains two contracts:

The first request element updates an existing Net and Selling, North American contract.

The second request element creates a new Selling, international contract.

Request



Explanation Code



<APF_ContractRQ

xmlns="http://agencyprivatefares.galileo.com/2006A/XAPF

" Version="1.00">







<RequestElement>

<Source




ID_Context="XML">



</RequestorID>

</Source>






Type of contract:

Selling

Net

NetAndSelling

RequestType indicates the type of request for this contract (Create, Update, PartialUpdate).

When a contract is updated, all contract information must be included in the update request.

<Contract

xmlns=”http://agencyprivatefares.galileo.com/2006

A/XAPF/4.0” ContractGeoType="NorthAmerican"

Type="NetAndSelling" Calculated="false"


Contract rule IDs are unique per supplier/airline code combination throughout the system. The ContractID must be supplied.

The ContrctID must contain four alpha, numeric, or alpha AND numeric characters. No special characters or blanks are allowed. 9999 is not a valid rule ID.

<ContractID>QB01</ContractID>




<Description>AA Net and

Selling</Description>



<DiscontinueDate>2009-08-

31</DiscontinueDate>






Zone is the user zone of the fare.

Set ImportNewVersion to "true" to have the contract get a new version of the zone from the APF database. See Updating a Contract (page 146) for more details.






If a zone is built that includes Newark (EWR) in the city listing, that zone CANNOT be used when creating a fare.

If a zone includes Puerto Rico or the U.S. Virgin Islands, these are entered as states of the U.S. Their individual country codes must not be used.

Note: Zones must be created for a country, state/province, or area if a fare is valid for any of those, then enter the zone name in the Zone, as appropriate.



NA Int RTW

Standard


From From

Calculated


From (default)

N/A



<Origin>


</Origin>

<Dest>

<Location>LAX</Location>

</Dest>



<FareType>Economy</FareType>





</Fare>



Between



Amount is the amount of the fare. The CurrencyCode in which the fare amount is calculated. Fares can be filed in any valid currency.






The contract/fare group is allowed to use any airline route published by the contract-owning airline that passes validation for the quoted fare component. This option is only valid for North American contracts.

<AirlineWildcardRoute>true</AirlineWil

dcardRoute>



Indicates that only fares that are on non-stop or direct flights are quoted.

<DirectOrNonStop>true</DirectOrNonStop

>

</BaseFareGroup>


Set Action to:



GDS provides the computer reservation system: 1G for Galileo, 1V for Apollo, or 1P for Worldspan.



AllAgencies - Distribute the contract to all agencies.

Agencies - Distribute the contract to specific agencies identified by PCC or IATA number.

Geographic - Distribute the contract to all Galileo agencies within a geography.

AgencyAndGeographic - Distribute the contract to agencies in a certain location.


Agency defines the specific travel agency code or Pseudo City Code (PCC). IATA codes can be up to eight numeric characters. PCCs are three or four alphanumeric characters.

DistSecLevels defines the agencies and associated security levels assigned to this distribution list.

Security specifies the access given to an agency:

Update – Set to "true" to give agencies access in the Agency Private Fares product to copy

<Distributions>

<Distribution



<Name>QXDIST</Name>

<DistributionBasis

Agencies="true"/>

<DistSecLevels>

<DistSecLevel>


<Security

Update="false"


Sell="true"

Ticket="true"/>

</DistSecLevel>

<DistSecLevel>

<Agency>ET6</Agency>

<Security

Update="true"

Redistribute="true"

Sell="false"

Ticket="false"/>

</DistSecLevel>

</DistSecLevels>




the contract and change certain fields. This also allows agencies to view fares and rules in Galileo, Apollo, and Worldspan from fare display. Set to "false" to deny agencies the permission to copy the contract.







If the contract is:


Net – You can enter ticketing details and selling levels if you choose. Note: If you create a Net only contract, the default takes the



<ExceptionGroup

TripType="OW">

<FareClass>

<FareBasisCode>AAA

</FareBasisCode>

</FareClass>

</ExceptionGroup>


<TicketDetail>

<BaggageOverride

BaggageType="PC"

Allowance="5"/>

</TicketDetail>



Net fare and applies it as the Selling and Ticket fare.

Net & Selling – You must enter at least a Passenger and you must enter selling levels.


Only one exception can be selected for the entire contract (either Fare Basis Code (FBC) or Fare Family). The fare family entry is one or two letters and a wildcard (e.g., F* or YH*).


OW = One way

RT = Round trip





A = Retrieve FBC/Fare Family and amount

B = Use contract FBC/Fare Family and retrieve amountp

F = Retrieve FBC/Fare Family and use contract amount

U = Use specified FBC/Fare Family and amount. Note: TicketRules cannot be U when UseYYFares=true.



If selling levels are entered for a specific passenger type (instead of using ALL), then selling levels must be created for all passenger types.

For example, if the contract has fares for ADT, MIL, and SEA, and ADT has a different selling level than the other two passenger types, create:

One entry specifically for ADT.

A second entry specifically for MIL.

A third entry for SEA.

These separate entries need to be done for every distribution group added to the contract.

Options that are valid for SellingLevel depend on whether the contract contains Net, Net and Selling, or Selling fares.

AllRoutes applies the selling level to all routes in this contract.

If the contract is Net and Selling:

SellingLevel and SellingFare can be entered. In SellingFare, do one of the following:

Set IncreasePct option then set Pct to the appropriate percentage increase.

Set IncreaseAmount option then enter an Amount and CurrencyCode. The amount will be added to the amount of the fare.

SellingFareParams are not valid for Net and Selling contract.

Note: To create a selling fare with no increase, enter 0.01 in IncreasePercent.

If the contract is Net:

SellingFareParams can be entered when the Sell amounts are to be created by another organisation who has update authority.

Use the value that is in the original contract, either PctRange or AmountRange. Using an incorrect value will lead to an error. For example, if the original contract had an AMOUNT maximum, only the AmountRange parameter can be entered for the copied contract.

Enter a Minimum and Maximum value for the percent. Or, enter a MinAmount and MaxAmount to define a flat rate. Enter the appropriate CurrencyCode.

To create a minimum and no

<SellingLevel

AllRoutes="true">

<SellingFare>

<IncreasePct

Pct="10"/>

</SellingFare>

</SellingLevel>



</Distribution>

</Distributions>



maximum (e.g., to increase the fare by at least $10.00, or increase it by any denomination over $10.00), enter the minimum value and enter 0.0 for the maximum. The system recognizes that any value above the minimum can be entered as a selling level.

To create a maximum and no minimum (e.g., No increase at all; perhaps infant cannot be increased), enter 0.01 in the Maximum and enter 0.0 in Minimum. A mark-up greater than 0.01 cannot be entered when selling the fare.

SellingFare is not a valid entry for a Net contract.

Transfers defines the transfers and surface sectors allowed within a contract.


WholePricingUnit





InboundOrOutbound

NumberBound

LocationAndDirection defines transfers that are limited to a specific location. Only eight locations total can be defined in all sections of LocationAndDirection.

Direction defines the direction of travel to which the transfer applies:

Both = Both outbound and inbound

Outbound = Outbound only

Inbound = Inbound only

Either = Either outbound or inbound, but not both


<Transfers>

<Transfer



TransferBound="NotRestricted"/>


<TransferLocDirs>

<TransferLocDir

NumberPermitted="1"

Location="BOS"

Direction="Outbound"

Permitted="true"/>

</TransferLocDirs>



Direction=”Inbound”>

<SurfaceSector

Permitted=”true”>

<Location>ABQ-

PHX</Location>

</SurfaceSector>


</Transfer>

</Transfers>

</Contract>

</RequestElement>



This RequestElement creates a new contract. For more information about creating a new contract, see Standard Contract Example (page 25).

<RequestElement>

<Source




ID_Context="XML">



</RequestorID>

</Source>

<Contract

xmlns=”http://agencyprivatefares.galileo.com/2006A

/XAPF/4.0” ContractGeoType="International"



<ContractID>QB7A</ContractID>


<Description>Create a contract</Description>

<DiscontinueDate>2009-08-31</DiscontinueDate>



<Origin>


</Origin>

<Dest>

<Location>TYO</Location>

</Dest>


<BookingCode>Q</BookingCode>





<FareBasisCode>QQQ</FareBasisCode

>

</Fare>

<DirectOrNonStop>true</DirectOrNonStop

>

</BaseFareGroup>

<Distributions>

<Distribution



<Name>QXDIST</Name>

<DistributionBasis

Agencies="true"/>

<DistSecLevels>

<DistSecLevel>


<Security

Update="false"




Sell="true"

Ticket="true"/>

</DistSecLevel>

<DistSecLevel>


<Security

Update="true"

Redistribute="true"

Sell="false"

Ticket="false"/>

</DistSecLevel>

</DistSecLevels>




<ExceptionGroup

TripType="RT">

<FareClass>

<FareBasisCode>QQQ

</FareBasisCode>

</FareClass>

</ExceptionGroup>


<TicketDetail>

<BaggageOverride

BaggageType="PC"

Allowance="5"/>

</TicketDetail>



</Distribution>

</Distributions>

<Stopovers>

<Stopover>


InAndOutPermitted="true">


<CitiesAirports>LAX SFO

SAN</CitiesAirports>

</Locations>

</FreeStopover>

<ChargedStopover MaxNumber="3"



<CitiesAirports>SEA</Citi

esAirports>

</Locations>


Amount="15.00"/>

</ChargedStopover>

</Stopover>

<Exception FareBasisCode="STPOVR">






<CitiesAirports>PDX</Citi

esAirports>

</Locations>

</FreeStopover>

</Exception>

</Stopovers>

</Contract>

</RequestElement>

</APF_ContractRQ>

Response






<ns3:Contract>

<ns2:ContractID Version="11">QB01</ns2:ContractID>

<ns2:Success />

</ns3:Contract>

<ns3:Contract>

<ns2:ContractID Version="1">QB7A</ns2:ContractID>

<ns2:Success />

</ns3:Contract>







The following request creates a contract that:

Is an international, Selling contract.

Permits add-on fares to be combined using fare basis code. This contract can combine with the

Add-on fare example (page 168).

Request



Explanation Code



<APF_ContractRQ

xmlns="http://agencyprivatefares.galileo.com/2006A/XAPF"

Version="1.00">







<RequestElement>

<Source




ID_Context="XML">



</RequestorID>

</Source>






Type of contract:

Selling

Net

NetAndSelling


<Contract





Contract rule IDs are unique per supplier/airline code combination throughout the system. This element must contain four alpha, numeric, or alpha AND numeric characters. It does not have to include the airline code, but can include the airline code. No special characters or blanks are allowed. 9999 is not a valid rule ID.

<ContractID>QX0A</ContractID>



Indicates that this contract can be combined with Add-on fares. For more information, see Creating Add-on Fares (page 157).

AddonConstructionOptions values are:

Permitted - Indicates that this contract is allowed to construct with Add-on fares.

NotPermitted - Indicates that this contract is not allowed to construct with Add-on fares.

Required - Indicates that this contract is allowed to construct with Add-on fares. However, Required also restricts the Standard contract fares from quoting alone. They will only display and quote when constructing with an Add-on fare.

AddonRules dictate how fares construct:

FBC - Fare basis code

FT - Fare type

RuleIDandFBC - Contract rule ID and fare basis code

RuleIDandFT - Contract rule

<AddonConstructionOptions>Permitted</AddonCon

structionOptions>

<AddonRules>FBC</AddonRules>



ID and fare type

ALL permits any Add-on fare that matches the Standard contract's specific rule information (Contract Rule ID, fare type, or fare basis) to construct. Note: Caution should be used when allowing this broad application.

Both the Add-on fare and the Standard contract fare must allow the construction in order for the fares to create a through fare.


<Description>Contract permits Add-

ons</Description>













Direction defines whether the Location or Zone is interpreted as an origin or destination: from or between. Values can be sent as per the following table:

NA Int RTW

Standard


From From

Calculated


From (default) Between

N/A




PsgrType describes the passenger.



<Origin>


</Origin>

<Dest>

<Location>LON</Location>

</Dest>









</Fare>



Any valid three-character alpha passenger type code can be entered.






<AirlineWildcardRoute>true</AirlineWild

cardRoute>


<DirectOrNonStop>true</DirectOrNonStop>

</BaseFareGroup>




Set Action to:





<Distributions>

<Distribution

Action="CreateFromGlobal">


<Name>QXGLOB1</Name>


</Distribution>

</Distributions>

Transfers defines the transfers and surface sectors allowed within a contract.


WholePricingUnit





InboundOrOutbound

NumberBound


<Transfers>

<Transfer



TransferBound="InboundOrOutbound"/

>


Direction="Either">

<SurfaceSector

Permitted="false"/>


</Transfer>

</Transfers>

</Contract>

</RequestElement>

</APF_ContractRQ>

Response








<ns3:Contract>

<ns2:ContractID Version="1">QX0A</ns2:ContractID>

<ns2:Success />

</ns3:Contract>







This standard contract example focuses on creating contract-specific distribution groups. For information

about other elements within this request, refer to Standard Contract Example 1 (page 25).

The example below takes advantage of the new master distribution group functionality availability with

version 3.0 and above of the schema. This example creates a contract-specific master distribution group,

named QCMSTR2. Because QCMSTR2 is a contract-specific master distribution group, it cannot be used

outside this contract.

QCMSTR2 contains two master distribution groups:

QCMSTR1 is a master distribution group defined within this contract.

QTESTMSTR is a master distribution group that is created from an existing master distribution

group.

For more information about distribution groups, see Distribution Groups (page 178).

Request



Explanation Code



<APF_ContractRQ


xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://agencyprivatefares.galileo.co

m/2006A/XAPF APF_ContractRQ.xsd" Version="1.00">






Code is the Galileo numeric

<RequestElement>

<Source




ID_Context="XML">



</RequestorID>

</Source>



identifier, is provided to the Licensee by Galileo, and is up to seven digits.




Type of contract:

Selling

Net

NetAndSelling


<Contract


/XAPF/4.0” ContractGeoType="NorthAmerican"



Contract rule IDs are unique per supplier/airline code combination throughout the system.

<ContractID>QV32</ContractID>



FareGroupName is the user-defined name of the fare group. Refer to Standard Contract Example 1 (page 25) for an in-depth explanation about BaseFareGroup and other contract options



<Origin>


</Origin>

<Dest>


</Dest>








</Fare>


</BaseFareGroup>




Set Action to:



UpdateFromLocal to update an existing contract-specific distribution group.

<Distributions>

<Distribution Action="CreateFromLocal">

DistributionGroup is the container element for the contract-specific distribution group being created.

Specify a Name for the contract-specific distribution group.

This example creates a contract-specific master distribution group, named QCMSTR2. QCMSTR2 contains two master distribution groups:

QCMSTR1 is a master distribution group defined within this contract.

QTESTMSTR is a master distribution group that is created from an existing master distribution group.


<Name>QCMSTR2</Name>

When a master distribution group is created within a contract, you must define the global distribution groups and/or master distribution groups that are included within the master group being created.

Each Group element contains one master distribution group, one global distribution group, or one contract-specific distribution group. Multiple Group elements are used to further define the contract-specific master distribution group.

The first Group element is creating a new master distribution group named QCMSTR1. The new distribution group is a master distribution group because Group elements will be used to define the master distribution groups and/or distribution groups that are included in QCMSTR1.

<Group Action="CreateFromLocal">

<Name>QCMSTR1</Name>



As a new contract-specific master distribution group is being created, the Group elements are used to define the master distribution groups and/or global distribution groups that are included in QCMSTR1.

Within the master distribution group QCMSTR1, a new distribution group is being created named QXDIST1.

The QXDIST1 distribution group is not a master distribution group because the GDS is specified. GDS provides the computer reservation system:

1G for Galileo

1V for Apollo

1P for Worldspan

When a distribution group is defined, you can also define the DistributionBasis and Security Levels.



Agencies - Distribute the contract to specific agencies identified by PCC/SID or IATA number. If set to true, an <Agency> is required.

Geographic - Distribute the contract to all Travelport agencies within a geography. If set to true, a <Location> is required.

AgencyAndGeographic - Distribute the contract to agencies in a certain location. If set to true, both <Agency> and <Location> are required.



Locations define the specific geography (countries, states/provinces, or cities). Cities are three characters, and countries and states are two. However, states and provinces must contain the country code as well. For example, Massachusetts is USMA; the country code (US) and then the state code (MA).

Agency defines the specific travel

<Group

Action="CreateFromLocal"

GDS="1V">

<Name>QXDIST1</Name>

<Description>Update by

adding

N18</Description>

<DistributionBasis

Agencies="true"/>

<DistSecLevels>

<DistSecLevel>

<Agency>ET6</Agen

cy>

<Security

Update="false"

Redistribute="fal

se" Sell="true"

Ticket="true"/>

</DistSecLevel>

</DistSecLevels>

</Group>



agency code, Pseudo City Code (PCC), or Subscriber Identification (SID). IATA codes can be up to eight numeric characters. PCCs are three or four alphanumeric characters. SIDs are three alpha, numeric, or alphanumeric characters.

Security specifies the access given to a distribution list:







This Group element creates another distribution group named QCDIST3 within the master distribution group QCMSTR1.

Again, this distribution group is not a master distribution group. Therefore, the GDS, DistributionBasis, and Security Levels are defined.

<Group

Action="CreateFromLocal" GDS=

"1G">

<Name>QCDIST3</Name>

<Description>New group

added in

contract</Description>

<DistributionBasis

Agencies="true"/>

<DistSecLevels>

<DistSecLevel>

<Agency>XG4</Agency

>

<Security

Update="false"

Redistribute="false

" Sell="true"

Ticket="true"/>

</DistSecLevel>

</DistSecLevels>

</Group>

This Group element uses an existing global distribution group named NEWDIST to further define the master distribution group QCMSTR1.

<Group

Action="CreateFromGlobal"

GDS=

"1G">

<Name>NEWDIST</Name>

</Group>

Ends the definition of the first contract-specific master distribution group, QCMSTR1.

</Group>

This Group element uses an existing master global distribution group named QTESTMSTR to create a contract-specific distribution group within the master group QCMSTR2.

<Group


<Name>QTESTMSTR</Name>

</Group>





If the contract is:

Selling – You can enter ticketing details if you choose, but cannot enter selling



<ExceptionGroup

TripType="OW">

<FareClass>

<FareBasisCode>AAA<

/FareBasisCode>

</FareClass>

</ExceptionGroup>



levels.


Net & Selling – You must enter at least a Passenger and you must enter an exception and selling levels (ticket information is optional).




OW = One way

RT = Round trip


Passenger is the three-character passenger type code to which this ticketing and selling level applies. The default is ALL, which is also a valid entry, although it is not part of the Passenger Type Code list.

Note: All ticketing data and associated selling levels are tied to the passenger type. Ticketing detail can only be entered once for an exception group and passenger type combination (e.g., OW exception for ADT passenger type), but selling levels with different geography can exist as long as the ticketing data matches for all selling level exceptions.








<SellingLevel

AllRoutes="true">

<SellingFare>

<IncreasePct

Pct="10"/>

</SellingFare>

</SellingLevel>



</Distribution>

</Distributions>




If the contract is Selling, SellingLevels are not allowed.

If the contract is Net and Selling, SellingFareParams are not valid

If the contract is Net, SellingFare is not valid.



In SellingFare, do one of the following:




Note: To create a selling fare with no increase, enter 0.01 in IncreasePct.



PctRange or AmountRange. Using an incorrect value will lead to an error. For example, if the original contract had an AMOUNT maximum, only the AmountRange parameter can be entered for the copied contract.

Minimum and Maximum value for the percent. Or, enter a MinAmount and MaxAmount to define a flat rate. Enter the appropriate CurrencyCode.

To create a minimum and no maximum (e.g., to increase the fare by at least $10.00, or increase it by any denomination over $10.00), enter the minimum value and enter 0.0 for the maximum. The system recognizes that any value above the minimum can be entered as a selling level.

To create a maximum and no minimum (e.g., No increase at all; perhaps infant cannot be increased), enter 0.01 in the Maximum and enter 0.0 in Minimum. A mark-up greater than 0.01 cannot be entered



when selling the fare.


</Contract>

</RequestElement>

</APF_ContractRQ>

Response






<ns3:Contract>

<ns2:ContractID Version="1">QV32</ns2:ContractID>

<ns2:Success />

</ns3:Contract>







The following request creates one net and selling, international contract that uses the airpass passenger

type code.

Request



Explanation Code



<APF_ContractRQ











<RequestElement>

<Source




ID_Context="XML">



</RequestorID>

</Source>




Type of contract:

<Contract







Selling

Net

NetAndSelling



The ContractID contains four alpha, numeric, or alpha AND numeric characters. No special characters or blanks are allowed. 9999 is not a valid rule ID.

<ContractID>R604</ContractID>




<Description>Airpasses</Description>









NA Int RTW

Standard

From Between

From From



<Origin>


</Origin>

<Dest>

<Location>LON</Location>

</Dest>






<PsgrType PsgrType="APA" />



</Fare>



(default)

Calculated



N/A












<AirlineWildcardRoute>true</AirlineWild

cardRoute>



</BaseFareGroup>


Set Action to:





<Distributions>

<Distribution






See the Calculated Contract Example 1 (page 93) for more information about ticket and selling options and exceptions.


If the contract is:



Net & Selling – You must enter at least a Passenger



<ExceptionGroup

TripType="OW">

<FareClass>

<FareFamily>*BE70</

FareFamily>

</FareClass>

</ExceptionGroup>

<Passenger>APA</Passenger>



and you must enter selling levels.


Only one exception can be selected for the entire contract (either Fare Basis Code (FBC) or Fare Family). An asterisk can be used as a wildcard in the FBC or Fare Family.


OW = One way

RT = Round trip












SellingLevel and SellingFare can be entered. In SellingFare, do one of the following:

Set IncreasePct option then set Pct to the

<SellingLevel

AllRoutes="true">

<SellingFare>

<IncreasePct

Pct="10"/>

</SellingFare>

</SellingLevel>



</Distribution>

</Distributions>



appropriate percentage increase.



Note: To create a selling fare with no increase, enter 0.01 in IncreasePercent.













Important! If both ADT and CLG have CNN discounts, Agency Private Fares takes the *lowest* discount of the two. If the CNN from ADT discounts 10% and the CNN from CLG discounts 20%, anytime a user enters CNN, the 20% discount is applied.

The MinAge and MaxAge for the discount. They are optional and only available for certain Passenger Type Codes. The maximum age must be greater than or equal to the minimum age.





To decrease the fare by an amount,

<Discounts>

<Discount PrimaryPsgrType="APA"

PsgrType="APC" TktCode="REPLACE"

TktDesignator="CH">

<Percent Percent="25.0" />

</Discount>


PsgrType="API" TktCode="-APPEND"

TktDesignator="IN">

<Percent Percent="90.0" />

</Discount>


PsgrType="APS">

<Values>


CurrencyCode="USD"/>

</Values>

</Discount>

<Exception FareBasisCode="DSCNT"

PrimaryPsgrType="APA" PsgrType="API">


</Exception>

</Discounts>



use the Amount element and enter the Amount by which the fare will be decreased. Set the CurrencyCode that applies to the amount.


</Contract>

</RequestElement>

</APF_ContractRQ>

Response






<ns3:Contract>

<ns2:ContractID Version="1">R604</ns2:ContractID>

<ns2:Success />

</ns3:Contract>







This request creates a standard contract for a round-the-world fare.

Request



Explanation Code



<APF_ContractRQ











<RequestElement>

<Source




ID_Context="XML">



</RequestorID>

</Source>




Type of contract:

Selling

<Contract


/XAPF/4.0” ContractGeoType="RoundTheWorld"





Net

NetAndSelling



The ContractID contains four alpha, numeric, or alpha AND numeric characters. No special characters or blanks are allowed. 9999 is not a valid rule ID.












NA Int RTW

Standard


From From

<BaseFareGroup FareGroupName="RoundTrip">

<Fare Type="RoundTrip">

<Origin>

<Location>ATL</Location>

</Origin>

<Dest>

<Location>ATL</Location>

</Dest>









</Fare>

<Fare Type="RoundTrip">

<Origin>


</Origin>

<Dest>




Calculated



N/A









</Dest>







<FareBasisCode>BB</FareBasisCode>

<TktCode>-APPEND</TktCode>

</Fare>





</BaseFareGroup>


Set Action to:





<Distributions>

<Distribution





</Distribution>

</Distributions>

</Contract>

</RequestElement>

</APF_ContractRQ>

Response






<ns3:Contract>


<ns2:Success />

</ns3:Contract>




Calculated Contract Example 1



The calculated contract in this example:

Contains a Net and Selling, International contract.

Includes a round-trip for an adult on British Airways.

Specifies travel between Los Angeles and London.

Increases the fares by 25%.

Contains one contract-specific distribution group, TEST1G, which allows Update, Redistribute,

and Sell and Ticket for agencies and geographies who are part of the distribution group.

Request



Explanation Code



<APF_ContractRQ


Version="1.00">







<RequestElement>

<Source




ID_Context="XML">


TravelSector="1" Code="1234567" />

</RequestorID>

</Source>






Type of contract:

Selling

Net

NetAndSelling


<Contract

xmlns=”http://agencyprivatefares.galileo.com/2006A/

XAPF/4.0” ContractGeoType="International"

Type="NetAndSelling" Calculated="true"



<ContractID>K112</ContractID>



AccountCode can be up to 20 alpha-numeric characters, and must begin with an alpha character.

<AccountCode>Q234</AccountCode>

TourOrNetRemitCode can be up to 15 alpha-numeric characters. Tour codes/Net Remit codes display in the filed fare and print on the ticket.

<TourOrNetRemitCode>5AB8902</TourOrNetRemitCo

de>


<Description>Calc Selling</Description>

DiscontinueDate is the date the contract is discontinued from the active system. It is also the last travel and ticket date, if not overridden by the optional travel and ticket dates. This date cannot be more than three years out from




the effective date.


FirstDateTicket is the earliest date a ticket may be issued, if later than the contract effective date.

LastDateTicket is the last date to issue a ticket, if earlier than the contract discontinue date.

FirstDateTravel is the earliest date on which outbound travel can begin if later than the contract effective date. This date cannot be earlier than the effective date, or earlier than the first ticket date.

LastDateTravel is the departure date of the first flight of the fare component, if earlier than the contract discontinued date. This date cannot be later than the discontinued date.

<FirstDateTicket>2006-08-10</FirstDateTicket>

<LastDateTicket>2007-08-10</LastDateTicket>

<FirstDateTravel>2006-08-15</FirstDateTravel>

<LastDateTravel>2007-08-01</LastDateTravel>


PublicFare defines whether the base fare is Public (true) or Private (false). If private, the private tariff number must be sent in PrivateTariff. The tariff number can be found in paragraph 0 of the rule display of the base fare.

PsgrType describes the passenger type of the base fare. PsgrType accepts any valid three-character alpha passenger type code.

OwRt indicates whether this is a OneWay, RoundTrip, OneWayOnly, or All.

For a private base fare (i.e., PublicFare=false),

Tariff is required.

InclFBC or ExclFBC with a specific fare basis code or a fare basis with wildcard is required. These elements include or omit FBCs from the group. See FBC Notes below for more information.

InclFareType and ExclFareType are not valid.

For a public base fare,

Both Tariff and RuleNbr are optional. However, if RuleNbr is included, then Tariff is required.

InclFBC and ExclFBC (with or without wildcard) are

<CalcFareGroup FareGroupName="CalcPublic">

<BaseCalcFare PublicFare="true">


<OwRt>RoundTrip</OwRt>

<InclFareType>First</InclFareType>

<InclFBC>YGH17 B4Y* *YG4</InclFBC>

</BaseCalcFare>



optional. These elements include or omit FBCs from the group. See FBC Notes below for more information.

At least one of the one of the following must be included in the request: InclFareType or ExclFareType.

InclFareType defines fare types to include:

All - If set to All, only ExclFBC is a valid entry. The ExcludeFareType element is valid with All.

Economy

PremiumEconomy

Business

PremiumBusiness

First

PremiumFirst

Notes:

If InclFareType is set to All, only ExclFBC is valid.

If InclFareType is not sent, only InclFBC is valid, and at least one fare basis code (with or without wildcard) must be sent.

ExclFareType defines fare types to exclude:

Economy

PremiumEconomy

Business

PremiumBusiness

First

PremiumFirst

FBC Notes:

A YY fare will not be considered for selecting a base fare.

A wildcard can be used to represent any character or characters in a fare basis code. The wildcard is an asterisk (*) (e.g., YE*, YE*2, or *YE).

Only one wildcard can be used in an entry.

When there is an asterisk present anywhere in the entry, there is also an assumed asterisk at the end.

The assumed asterisk at the end is never replaced by a



numeric.

An asterisk at the beginning of the wildcard entry will be replaced with at least one character.

Make the wildcard as general as possible. For example, use *UQ to retrieve BHUQ7 and QLUQ93 fares versus entering *UQ7 and *UQ9.

CalcCalcFare defines the calculated fare.

Direction defines whether the locations and zones are interpreted as origins or destinations: from or between. Values can be sent as per the following table.


NA Int RTW

Standard


From From

Calculated



N/A

Loc1 and Loc2 define the city code, US state/CA province code, country code, area code, or zone. Use Location to enter any values that are not zones. Use Zone to define the zone for the fare. Multiple Locations and Zones can be included in Loc1 and Loc2.

Airport codes are not valid.

Note: If a zone is built which includes Newark, New Jersey (EWR) in the city listing that zone CANNOT be used when creating a non-North American fare.

<CalcCalcFare>

<Routes Direction="Between">

<Loc1>

<Location>LAX</Location

>

</Loc1>

<Loc2>

<Location>LON</Location

>

</Loc2>

</Routes>

IncrDecr defines the increase and/or decrease of the fare. At least one of the following must be entered:

Percentage Increase – Whether the calculated fare will increase or decrease by a percentage. To decrease, set Increase to "false".

Percentage – The percent (0-100) by which the fare will increase or decrease. Set Increase to "false" to enter zero percent.

<IncrDecr>

<Percentage Increase="true"

percent="25" />

<Value Increase="false">




CurrencyCode="CAD" />

</Value>

</IncrDecr>



Amount Increase – Whether the calculated fare will increase or decrease by an amount. To decrease, set Increase to "false".

Amount and CurrencyCode – The amount by which the fare will increase or decrease (zero is not permitted) and the currency in which the amount is calculated. Amount is not a valid entry if percent is decreased by zero.

PsgrType describes the passenger. PsgrType accepts any valid three-character alpha passenger type code.

TktDesginator is a 1-10 character alphanumeric entry that appends to the fare basis code.

TktCode is a Ticket Code that replaces or alters the Fare Basis Code (FBC) on the ticket and in the linear when the fare is quoted. It is not used as match criteria for any rule provisions of the contract. The information must be alpha-numeric with one exception; a hyphen is permitted in the first position. When a ticket code is entered with a hyphen preceding it, the information will be appended to the end of the Fare Basis Code. For example, if the FBC is J2RT and the ticketing code is “-CH”, the resulting FBC will be J2RTCH. If there is no hyphen, the resulting FBC would be CH. If the ticket code results in a fare basis code that is too long for the space on the ticket, it will truncate.

FareBasisCode is a code that identifies a fare. The first character must be an alpha. It cannot exceed 8 alpha and numeric characters.

BookingCode is the one- or two-character booking code(s) valid for travel between the From/Between cities. The maximum number of booking codes allowed between each location is eight. The codes must be separated by a space. If a booking code is two characters long it must end in N.

Values in TktCode, FareBasisCode, and BookingCode are populated in the APF database from the Base Fare if they are not sent in the request.


<TktDesignator>QTP</TktDesignator>

<FareBasisCode>QWE</FareBasisCode>

<BookingCode>X</BookingCode>

</CalcCalcFare>



Define the airlines on which travel is allowed. Secondary booking codes are valid for non-North American calculated fares.

If secondary booking codes are not entered, all airlines included in the base fare routing are valid.

SecondaryAirlineBookingCode defines secondary airline booking codes and exceptions to those booking codes. Airline defines the airlines on which travel is allowed. Multiple booking codes can be entered, separated by spaces. Up to 999 booking codes can be added for each secondary airline.

In SecondaryAirlineBookingCodeException, there is no limit to the number of exception booking codes that can be entered.

For example, a base fare is filed by BB airlines, with permitted travel on CC, DD and EE.

If the contract has no exceptions to this, then travel on CC, DD and EE are permitted.

If the contract contains booking codes for CC and DD, then travel on EE will not be permitted.

RulesOverride values are AIRLINE, CONTRACT, BOTH, or NO_RESTRICTION, depending on the specific attribute.

Note: The option for the contract to calculate a Higher Intermediate Point (HIP) is available on contracts that meet all of the following criteria.

Non-North American

SELLING contracts

Using a public base fare

For these contracts, if the intent is not to process HIPs, set HIP to CONTRACT. If HIP is not set, or is set to AIRLINE, Higher Intermediate Point is calculated for the contract.

Note: If TicketRules is set to AIRLINE, do not include ticket details or an error will be returned.

SimpleRouting and ComplexRouting are NOT VALID for calculated contracts.


Airline="AA">

<BookingCodes>D F G</BookingCodes>



Airline="BA" BC1="A" From="NYC"

To="LON">


P</BookingCodes>

</SecondaryAirlineBookingCodeException>

<RulesOverrides DOW="BOTH"

FltRulesCodeshare="AIRLINE"

MinStay="CONTRACT" Stopovers="AIRLINE"

Surcharges="AIRLINE" Transfers="AIRLINE"

Penalties="NO_RESTRICTION"

Season="CONTRACT" AdvResTkt="AIRLINE"

MaxStay="AIRLINE" Blackouts="AIRLINE"

Endorsements="CONTRACT"

Combinations="CONTRACT"

Accompaniment="NO_RESTRICTION"

HIP="AIRLINE" TicketRules="CONTRACT" />

</CalcFareGroup>




Set Action to:




1G for Galileo

1V for Apollo

1P for Worldspan










Agency defines the specific travel agency codes or Pseudo City Codes (PCC). IATA codes can be up to eight numeric characters.

<Distributions>

<Distribution Action="CreateFromGlobal"

<DistributionGroup GDS="1G">

<Name>TEST1G</Name>

<Description>Test

DG</Description>

<DistributionBasis

AgencyAndGeographic="true"/>

<DistSecLevels>

<DistSecLevel>

<Agency>XG4</Agency>

<Location>LON</Location

>

<Security Update="true"

Redistribute="true"

Sell="true"

Ticket="true"/>

</DistSecLevel>

</DistSecLevels>




PCCs are three or four alphanumeric characters.


Security defines the security levels assigned to this distribution list.











OW = One way

RT = Round trip





<ExceptionGroup

TripType="OW">

<FareClass>

<FareBasisCode>A*</F

areBasisCode>

</FareClass>

</ExceptionGroup>

Passenger is the three-character passenger type code to which this ticketing and selling level applies. The default is ALL, which is also a valid entry, although it is not part of the Passenger Type Code list. Note: All ticketing data and associated selling levels are tied to the passenger type. Ticketing detail can only be entered once for an exception group and passenger type combination (e.g., OW exception for ADT passenger type), but selling levels with different geography can exist as long as the ticketing data matches for all selling level.











BaggageType values include:

PC = Override the baggage allowance with the number of pieces of baggage allowed.

KG = Override the baggage allowance with a weight in kilograms.






If no ticket fare is provided, the following rules apply to the fare output on the ticket:

If the contract is Selling, the Selling Fare amount for the fare is used on the ticket and the Fare Basis code from that fare is placed in the Fare Basis/Ticket Designator box on the ticket.

If the contract is Net/Selling, the net fare is placed in the Fare Amount Box on the ticket. If the APF contract is a Net only contract then the Net amount is placed in the Fare Amount Box on the ticket as the Selling Fare.

<TicketDetail>

<TourBox

TypeOfTourCode="CAR"

TourCode="CARCODE"/>

<PlatingCarrier

AirlineCode="BA"

Option="Required"/>

<BaggageOverride

BaggageType="KG"

Allowance="20"/>

<FareBox>

<TicketFare>

<TicketRules>A</Ti

cketRules>

<FareBaseOrFamily>

ABC*D</FareBaseOrF

amily>

</TicketFare>

</FareBox>

</TicketDetail>



If the contract is Net and Selling, SellingFareParams are not valid.

If the contract is Net, SellingFare is not valid.



In SellingFare, do one of the

<SellingLevel

AllRoutes="true">

<SellingFare>

<IncreasePct Pct="10"

/>

</SellingFare>

</SellingLevel>

</TicketDetailAndSellingLeve

l>



following:














A TicketDetailAndSellingLevel must be defined for every distribution group added to the contract.







If no ticket fare is provided, the following rules apply to the fare output on the ticket:

If the contract is Selling, the Selling Fare amount for the fare is used on the ticket and the Fare Basis code from that fare is placed in the Fare Basis/Ticket Designator box on the ticket.

If the contract is Net/Selling, the net fare is placed in the Fare Amount Box on the ticket. If the APF contract is a Net only contract then the Net amount is placed in the Fare Amount Box on the ticket as the Selling Fare.


<ExceptionGroup

TripType="OW">

<FareClass>

<FareFamily>B*</FareFa

mily>

</FareClass>

</ExceptionGroup>


<TicketDetail>

<CommissionOverride>

<Commission>CALCULAT

E</Commission>

<Commission1

Amount="10.00"


</CommissionOverride>

<FareBox>

<TicketFare>

<TicketRules>U</Tick

etRules>

<FareBaseOrFamily>BA

BCD</FareBaseOrFamil

y>

<FareAmount

Amount="2234.56"


</TicketFare>

</FareBox>

</TicketDetail>

<SellingLevel From="DEN"

To="ATL">

<SellingFare>

<IncreasePct

Pct="10"/>

</SellingFare>

</SellingLevel>


l>


</Distribution>

</Distributions>



Seasons define the seasons that exist within the contract.

FirstDate specifies the first date on which travel is permitted, if different than the effective date of the contract. LastDate specifies the last date on which travel is permitted, if different than the discontinued date of the contract. Set dates that apply every year using the dashdashMMdashDD format (--12-31).

Permitted defines the portions of the fare the seasons apply to:




If Outbound and Inbound, a season cannot be added for Outbound Only or Inbound Only. If Outbound Only and/or Inbound Only, make sure the dates do not overlap.






Exception sets exceptions to the Seasons. Exception limitations (page 22) defined in Creating a Contract apply.

<Seasons>

<Season>



<Applicable>E</Applicable>


</Season>

<Exception FareBasisCode="B"

Origin="LAX" Dest="ELP">



<Applicable>F</Applicable>


</Exception>

</Seasons>



Days of Week (DOWs) defines the days of the week on which a passenger can travel, for this contract. For example, one city pair on a contract can have different day of week restrictions than the rest of the contract. If travel is permitted on all days, there is no restriction and DOWs do not need to be entered.

ValidDays defines the specific days on which travel is permitted 1=Monday, 2=Tuesday, 3=Wednesday, 4=Thursday, 5=Friday, 6=Saturday, 7=Sunday.

Permitted defines the direction in which travel is permitted:









Exception sets exceptions to the Day of Week. Exception limitations (page 22) defined in Creating a Contract apply.

<DOWs>

<DOW ValidDays="13567" Applicable="F"


<Exception FareBasisCode="N"

ValidDays="247" Applicable="F"


</DOWs>



ResTktTimeLimits defines the length of time in advance that reservations and ticketing must take place for the contract to be valid.

ResTimeLimit defines the latest time that reservations are permitted before departure from origin. The following are Permission values:

Latest = not permitted later than

Earliest = not permitted earlier than

To define Permissions, use either a number of days before departure from origin or a specific day of the week to be applied before departure from origin. Use NumberOfDays or DayOfWeek to define the latest time that reservations are permitted before departure from origin.

DayOfWeek options are 1=Monday, 2=Tuesday, 3=Wednesday, 4=Thursday, 5=Friday, 6=Saturday, 7=Sunday.

TktTimeLimit defines the point in time when tickets must be issued, either EARLIEST or LATEST, for BeforeDeparture or AfterReservation.

AfterReservation defines the number of days or hours after the reservations are made. Unit is DAY or HOUR.

BeforeDeparture defines the number of days or hours before the departure from origin. Unit is DAY or HOUR.

When both BeforeDeparture and AfterReservation are defined, specify the Rule to use when choosing between the two times.

EARLIEST = Use the time that is earliest.

LATEST = Use the time that is latest.

Note: The choice of earlier or later only applies to “before departure” time periods; “after reservation” time periods must be “not later than.”

Exception sets exceptions to the Advanced Reservation and Ticketing. Exception limitations defined in Creating a Contract apply.

<ResTktTimeLimits>

<ResTktTimeLimit>

<ResTimeLimit Permission="Earliest">


</ResTimeLimit>

<TktTimeLimit Rule="LATEST"

Permission="Latest">

<BeforeDeparture Unit="DAY"

Value="2"/>

<AfterReservation Unit="HOUR"

Value="24"/>

</TktTimeLimit>

</ResTktTimeLimit>

<Exception>



</ResTimeLimit>


<AfterReservation Unit="HOUR"

Value="12"/>

</TktTimeLimit>

</Exception>

</ResTktTimeLimits>



MinStays specifies details about the minimum stay length of the contract. Do not use this option for one-way fares.





Departure of inbound transatlantic sector (A)

Departure of inbound transpacific sector (P)



StayUnit defines the stay restriction: Days, MON, TUES, WED, THU, FRI, SAT, or SUN. Note that other values are available in the schema but are not accepted by APF.

DepartFrom choices are:

FareOrigin




RelationshipRestriction defines whether all or just one restriction must be true. The values are AND or OR. When the relationship is AND, all restrictions entered must pass to pass Minimum Stay. When the relationship is OR, any single restriction can pass to pass Minimum Stay.

MaxStay allows you to specify details about the maximum stay.






Departure from point of

<MinStays>

<MinStay TravelFrom="L"

DepartFrom="FareOrigin" MinStay="1"

StayUnit="WED" />

</MinStays>

<MaxStays>

<MaxStay TravelFrom="D"

DepartFrom="FareOrigin" MaxStay="9"

StayUnit="Days" />

</MaxStays>



Turnaround (T)

StayUnit defines Days or Months. Note that other values are available in the schema but are not accepted by APF.

DepartFrom options are:

FareOrigin




MaxStay defines the maximum stay length.

Exception sets exceptions to the Min and Max Stay. Exception limitations defined in Creating a Contract apply.

A blackout is a period of time, within a season or during the life of the contract, when the fares are not available for sale. BlackoutDates define the dates or date ranges during which travel is not allowed.

Dates define the date or date range for which the contract fares are not applicable.

Permitted defines the travel direction in which blackout and exception dates occur:




Set the Date on which travel is not permitted. Use the dashdashMMdashDD format (--12-31) to set dates that apply every year.

AND/OR

Set the Range for which travel is not permitted. StartDate and EndDate must be entered and must have the same date format. For example, a StartDate without a year (--12-29) must have an EndDate without a year (--01-02).

Exception sets exceptions to the Blackout dates. Exception limitations (page 22) defined in Creating a Contract apply.

<BlackoutDates>

<Dates Permitted="Either">

<Date Date="2007-08-13" />

<Date Date="2007-12-13" />

<Range StartDate="2007-09-13"

EndDate="2007-09-30" />


EndDate="2008-06-30" />

</Dates>

<Exception FareBasisCode="AAASWE"

Origin="SFO" Dest="DEN"

Permitted="Outbound">

<Date Date="2007-08-13" />

<Date Date="2008-05-13" />


EndDate="2007-09-03" />


EndDate="2008-04-12" />

</Exception>

</BlackoutDates>



FlightRules defines the airlines and flight numbers or flight number ranges on which a passenger can travel. It also sets limits on the cities/airports and countries through which the passenger can fly. To limit cities/airports and countries, make sure appropriate locations are entered in SimpleRoutings and ComplexRoutings.

FlightRules may or may not be related to data in CodeShares and ComplexRouting. However, the type of data entered in FlightRules limits the type of data that can be entered in CodeShares.

Make "positive" or "negative" Rule statements:

MustBe (positive)



FlightRules can all positive (MustBe and/or IfTravelIs) or can contain one, and ONLY one, negative statement (MustNotBe). This means that if travel MustNotBe online connection, for example, any other statements in RoutingOptions (such as via city) must be positive.

If all FlightRules are positive, all CodeShares must be positive. If FlightRules contains a negative statement, CodeShares must contain a negative statement.

The options entered in FlightRules DO NOT impact the options in the FlightRules Exception or CodeShares Exception.

Direction defines the direction of travel to which the rule applies:




If the rule is not based on direction, set Outbound and Inbound.

RelationshipRestriction defines the relationship between the restrictions if multiple restrictions are listed within a <FlightRule>:



Define whether the flight is NonStop, Direct, and/or OnlineConn (online connection).

<FlightRules>


RelationshipRestriction="OR">


NonStop="false" Direct="true"



Airline="AA">

<FlightNumber Num="4491" />

<FlightNumberRange

RangeStart="4567"

RangeEnd="4599" />

</Flights>

</FlightRule>




NonStop="false" Direct="true"



Airline="UA">

<FlightNumber Num="1234" />

</Flights>

</FlightRule>

</FlightRules>



Define Flights for the primary or secondary airline (or airlines), using Airline and FlightNumber and/or FlightNumberRange.

Exception set exceptions to Flight Rules. Exception limitations (page 22) defined in Creating a Contract apply.

Exceptions in FlightRules are linked to exceptions in CodeShares. This link means that the type of exception (e.g., fare basis code, city pair) used in FlightRules is also the type of exception that must be used in CodeShares, if code share exceptions are entered.

Flight rule exceptions are unique. When adding multiple flight rule exceptions, they can be positive or negative. Subsequent exceptions are not dependent on the first exception.


CodeShares defines code share details for the contract.

Data in CodeShares may or may not be related to data in FlightRules and ComplexRouting. However, the type of data entered in CodeShares limits the type of data that can be entered in FlightRules.

Make "positive" or "negative" statements:

MustBe (positive)



CodeShares can all positive (MustBe and/or IfTravelIs) or can contain one, and ONLY one, negative statement (MustNotBe). This means that if travel MustNotBe on marketing airline XX and operating airline YY, any other statements in RoutingOptions (via this city or between cities) must be positive.

If all CodeShares are positive, all FlightRules must be positive. If CodeShares contains a negative statement, FlightRules must contain a negative statement.

The options entered in CodeShares DO NOT impact the options in the CodeShares Exception or FlightRules Exception.

<CodeShares>

<Exception Direction="Inbound"

Origin="LAX" Dest="ELP"


<MktgOperatings

Rule="MustBe">

<MktgOprtng

MarketingAirline="BH"

OperatingAirline="R3"

/>

</MktgOperatings>

</Exception>

</CodeShares>



Direction defines the direction to which the restriction applies:




RelationshipRestriction defines the relationship between the restrictions if multiple restrictions are listed:



MktgOperatings defines whether the flights must or must not be on the MarketingAirline and the OperatingAirline; maximum of 50 pairs.

Note: RoutingOptions limits the code share restriction to specific portions of the itinerary.

Exception sets exceptions to the Code Share. Exception limitations defined in Creating a Contract apply.

Exceptions in CodeShares are linked to exceptions in FlightRules. This link means that the type of exception (e.g., fare basis code, city pair) used in CodeShares is also the type of exception that must be used in FlightRules, if flight rules exceptions are entered.

Code share exceptions are unique. When adding multiple code share exceptions, they can be positive or negative. Subsequent exceptions are not dependent on the first exception.



FreeStopover:

MaxNumber defines the number of free stopovers permitted. ** indicates

<Stopovers>

<Stopover>

<FreeStopover MaxNumber="**"


OutboundNumber="1">


<CitiesAirports>NYC DFW

LON</CitiesAirports>

<Countries>US

GB</Countries>

</Locations>



unlimited stopovers.







ChargedStopover:


InAndOutPermitted – Set to "true" to allow either inbound or outbound stopovers, but not both. Set to "false" to define the number of inbound and outbound stopovers. InboundNumber and OutboundNumber must equal the number in

</FreeStopover>

<ChargedStopover MaxNumber="**"


InboundNumber="3"

OutboundNumber="0"

ChildInfantDiscounts="true">

<Locations Permitted="truue">

<CitiesAirports>DEN CHI ROM

PAR</CitiesAirports>

<Countries>US FR

IT</Countries>

</Locations>


Amount="45.00"/>

<Fee CurrencyCode="CAD"

Amount="65.00"/>

</ChargedStopover>

</Stopover>

<Exception FareBasisCode="C">

<FreeStopover


InboundNumber="0" OutboundNumber=2"

ChildInfantDiscounts="true"

GatewayOnly="true">


<CitiesAirports>SYD NYC ELP

OKC OMA

LAX</CitiesAirports>

<Countries>US

AU</Countries>

</Locations>

</FreeStopover>

</Exception>

</Stopovers>



MaxNumber.






Notes:



Exception sets exceptions to the Stopovers. Exception limitations (page 22) defined in Creating a Contract apply.






IATA YY fares.











DOJ – single or double

<Combinations>

<WithinContract Airline="BH"

ContractRuleID="K112">

<ComboTripTrip>

<NonOJTrip>RT</NonOJTrip>

</ComboTripTrip>

</WithinContract>

<WithinContract ContractRuleID="K112">

<ComboTripTrip>


</ComboTripTrip>

</WithinContract>

<OutsideContract Airline="HC"

ContractRuleID="SJ01">

<ComboTripTrip>



</ComboTripTrip>

</OutsideContract>

</Combinations>



open jaw





RT – round trip.















Or, set the LifeOfContract to "true" to apply the surcharges for the life of the contract.





"" - (Default) The surcharge applies to all passengers, same as ALL.

ADT+CHD-DISC - Both Adult/Child - Child Discounted - this applies to Infant also, but you must have a discount set up for the

<Surcharges>

<Surcharge AppliesDirection="Either">

<StandardSurchargeExempt>true</Standa

rdSurchargeExempt>

<Dated StartDate="--12-15"

StopDate="--01-15">

<Data AppliesPsgrType="ALL">


Amount="23.87"/>


Amount="25.76"/>

</Data>

</Dated>

</Surcharge>

<Exception AppliesDirection="X"

Origin="PHX" Dest="NYC">


rdSurchargeExempt>

<LifeOfContract>



Amount="35.00"/>

</Data>

</LifeOfContract>

</Exception>

</Surcharges>



child and/or infant in Discounts. If the child/infant is a published fare, do not use this option.

ADT - Adult Only


Notes:

Only two Amounts and CurrencyCodes can be set. The currencies are dependent on the currencies entered in Fare.







Important! If both ADT and CLG have CNN discounts, Agency Private Fares takes the *lowest* discount of the two. If the CNN from ADT discounts 10% and the CNN from CLG discounts 20%,

<Discounts>

<Discount PrimaryPsgrType="ADT"

PsgrType="CNN" MinAge="2" MaxAge="11"

TktCode="REPLACE" TktDesignator="A">


</Discount>

<Exception PrimaryPsgrType="ADT"

PsgrType="CNN" FareBasisCode="L"

Origin="PHX" Dest="BOX" MinAge="2"

MaxAge="11" TktCode="-APPEND"

TktDesignator="A">

<Values>




CurrencyCode="CAD" />

</Values>

</Exception>

</Discounts>



anytime a user enters CNN, the 20% discount is applied.

The MinAge and MaxAge for the discount. They are optional and only available for certain Passenger Type Codes. The maximum age must be greater than or equal to the minimum age.





To decrease the fare by an amount, use the Amount element and enter the Amount by which the fare will be decreased. Set the CurrencyCode that applies to the amount.




Rules display in standard Galileo, Apollo, and Worldspan formats. The descriptions entered in Rules explain the contract details in simple terms.

Important! Auto-generated text is created from data filed in the contract rules and is validated by the Galileo 360 Fares system when you price an APF fare. User-entered text is informational only and is not validated at the time of pricing. As well, user-entered text displays in Fare Quote and Fare Display Follow-on entries preceded by a NOTE identifier.

Title (or rule paragraph) sets the various rule text headings.

IgnoreGenerated defines whether automatically generated rules text is used.

Do not ignore generated text -- 0 or "false".

Ignore generated text -- 1 or "true"

TextLine defines the text for the Title. Alpha-numerics (A to Z, 0 to 9), full stop (.), slash (/), dash (-), colon (:), asterisk (*), and blank (space) are valid.

Title

Available titles are:

ACCT_CODE

DAY_OF_WEEK

SEASONS

CODE_SHARE (which is also flight restrictions)

ADV_PURCH

MIN_STAY

MAX_STAY

STOPOVERS

TRANSFERS

COMBINATIONS

BLACKOUTS

SURCHARGES

TRAVEL_RESTRICTIONS

SALES_RESTRICTIONS

CANCEL_CHANGE

HIP

ENDORSEMENTS

DISCOUNTS_CHD (Children)

DISCOUNTS_OTHER

CONTRACT_DETAILS

FOP (Form of Payment)

NET_SELLING

OSI

OTHER_NOTES

ROUTING

TICKETING_DETAILS

<Rules>

<Rule Title="DAY_OF_WEEK


<TextLine>Travel is permitted IB

ONLY on MON WED FRI SAT

SUN.</TextLine>

<TextLine>Applies to DEPARTURE OF

THE FIRST INTERNATIONAL SECTOR OF

THE FARE.</TextLine>

</Rule>

</Rules>



Ends the Contract request. </Contract>

</RequestElement>

</APF_ContractRQ>

Response






<ns3:Contract>

<ns2:ContractID Version="1">K112</ns2:ContractID>

<ns2:Success />

</ns3:Contract>







This request creates a calculated contract with the minimum viable elements necessary to create a

contract.

Request



Explanation Code



<APF_ContractRQ



xsi:schemaLocation="http://agencyprivatefares.galileo.com

/2006A/XAPF APF_ContractRQ.xsd" Version="1.00">







<RequestElement>

<Source




ID_Context="XML">



</RequestorID>

</Source>






Type of contract:

Selling

Net

NetAndSelling


<Contract


XAPF/4.0” ContractGeoType="NorthAmerican"

Type="Selling" Calculated="true"










For a private base fare (i.e.,

<CalcFareGroup FareGroupName="CalcFBC">



<OwRt>All</OwRt>

<Tariff>333</Tariff>

<RuleNbr>1234</RuleNbr>

<InclFBC>ABC*</InclFBC>

</BaseCalcFare>



PublicFare=false),

Tariff is required.





InclFBC and ExclFBC (with or without wildcard) are optional. These elements include or omit FBCs from the group. See FBC Notes below for more information.




Economy

PremiumEconomy

Business

PremiumBusiness

First

PremiumFirst

Notes:




Economy

PremiumEconomy

Business

PremiumBusiness

First

PremiumFirst



FBC Notes:





The assumed asterisk at the end is never replaced by a numeric.






NA Int RTW

Standard


From From

Calculated



N/A



Note: If a zone is built which

<CalcCalcFare>

<Routes Direction="From">

<Loc1>


>

</Loc1>

<Loc2>

<Location>SYD</Location

>

</Loc2>

</Routes>



includes Newark, New Jersey (EWR) in the city listing that zone CANNOT be used when creating a non-North American fare.






<IncrDecr>

<Percentage Increase="false"

percent="15.0" />

</IncrDecr>



</CalcCalcFare>



Non-North American

SELLING contracts





<RulesOverrides Transfers="AIRLINE"

TicketRules="CONTRACT"

Surcharges="AIRLINE" Stopovers="AIRLINE"

Season="AIRLINE" Penalties="AIRLINE"

MinStay="AIRLINE" MaxStay="AIRLINE"

HIP="AIRLINE"


Endorsements="AIRLINE" DOW="AIRLINE"

Combinations="AIRLINE"

Blackouts="AIRLINE" AdvResTkt="AIRLINE"

Accompaniment="AIRLINE"/>

</CalcFareGroup>




Set Action to:




1G for Galileo

1V for Apollo

1P for Worldspan











<Distributions>

<Distribution Action="CreateFromLocal"


<Name>QXDIST</Name>

<Description>Test

DG</Description>

<DistributionBasis

Agencies="true"/>

<DistSecLevels>

<DistSecLevel>


<Security

Update="false"


Sell="true"

Ticket="true"/>

</DistSecLevel>

<DistSecLevel>



Redistribute="true"

Sell="false"

Ticket="false"/>

</DistSecLevel>

</DistSecLevels>


</Distribution>

</Distributions>






Update – Set to "true" to give agencies access in the Agency Private Fares product to copy the contract and change certain fields. This also allows agencies to view fares and rules in Galileo and Apollo from fare display. Set to "false" to deny agencies the permission to copy the contract.


Sell – Set to "true" to allow agencies to view fares from a fare display and get a fare quote in Galileo and Apollo. Note: Apollo and Worldspan do not differentiate between Sell and Ticket. If an agency/geography is given Sell authority, it can both sell and ticket.



FreeStopover:

MaxNumber defines the number of free stopovers permitted. ** indicates

<Stopovers>

<Stopover>

<FreeStopover MaxNumber="**"


OutboundNumber="1">


<CitiesAirports>NYC DFW

LON</CitiesAirports>

<Countries>US

GB</Countries>

</Locations>



unlimited stopovers.







ChargedStopover:


InAndOutPermitted – Set to "true" to allow either inbound or outbound stopovers, but not both. Set to "false" to define the number of inbound and outbound stopovers. InboundNumber and OutboundNumber must equal the number in

</FreeStopover>

<ChargedStopover MaxNumber="**"


InboundNumber="3"

OutboundNumber="0"

ChildInfantDiscounts="true">

<Locations Permitted="truue">

<CitiesAirports>DEN CHI ROM

PAR</CitiesAirports>

<Countries>US FR

IT</Countries>

</Locations>


Amount="45.00"/>

<Fee CurrencyCode="CAD"

Amount="65.00"/>

</ChargedStopover>

</Stopover>

<Exception FareBasisCode="C">

<FreeStopover


InboundNumber="0" OutboundNumber=2"

ChildInfantDiscounts="true"

GatewayOnly="true">


<CitiesAirports>SYD NYC ELP

OKC OMA

LAX</CitiesAirports>

<Countries>US

AU</Countries>

</Locations>

</FreeStopover>

</Exception>

</Stopovers>



MaxNumber.






Notes:



Exception sets exceptions to the Stopovers. Exception limitations (page 22) defined in Creating a Contract apply.






IATA YY fares.











DOJ – single or double

<Combinations>

<WithinContract Airline="BH"

ContractRuleID="K112">

<ComboTripTrip>

<NonOJTrip>RT</NonOJTrip>

</ComboTripTrip>

</WithinContract>

<WithinContract ContractRuleID="K112">

<ComboTripTrip>


</ComboTripTrip>

</WithinContract>

<OutsideContract Airline="HC"

ContractRuleID="SJ01">

<ComboTripTrip>



</ComboTripTrip>

</OutsideContract>

</Combinations>



open jaw





RT – round trip.















Or, set the LifeOfContract to "true" to apply the surcharges for the life of the contract.





"" - (Default) The surcharge applies to all passengers, same as ALL.

ADT+CHD-DISC - Both Adult/Child - Child Discounted - this applies to Infant also, but you must have a discount set up for the

<Surcharges>

<Surcharge AppliesDirection="Either">


rdSurchargeExempt>

<Dated StartDate="--12-15"

StopDate="--01-15">

<Data AppliesPsgrType="ALL">


Amount="23.87"/>


Amount="25.76"/>

</Data>

</Dated>

</Surcharge>

<Exception AppliesDirection="X"

Origin="PHX" Dest="NYC">


rdSurchargeExempt>

<LifeOfContract>



Amount="35.00"/>

</Data>

</LifeOfContract>

</Exception>

</Surcharges>



child and/or infant in Discounts. If the child/infant is a published fare, do not use this option.

ADT - Adult Only


Notes:

Only two Amounts and CurrencyCodes can be set. The currencies are dependent on the currencies entered in Fare.





</RequestElement>

</APF_ContractRQ>

Response






<ns3:Contract>


<ns2:Success />

</ns3:Contract>







The calculated contract in this example updates the contract created in Calculated Contract Example 2

with the following settings:

Net and Selling, North American contract

Fare decrease of 15%

One contract-specific distribution group

Fare basis code with a wildcard

TicketDetailAndSellingLevels exception using a fare family

Request



Explanation Code



<APF_ContractRQ



xsi:schemaLocation="http://agencyprivatefares.galileo.com

/2006A/XAPF APF_ContractRQ.xsd" Version="1.00">


Source is required for all requests. provides requestor details. The Source namespace is OTA. Type is ignored by XAPF, but required for schema compliance. Because no definition exists for providers of airline fare data, use 18 to indicate "Other".





<RequestElement>

<Source




ID_Context="XML">



</RequestorID>

</Source>






Type of contract:

Selling

Net

NetAndSelling


<Contract


XAPF/4.0” ContractGeoType="NorthAmerican"

Type="NetAndSelling" Calculated="true"










For a private base fare (i.e.,




<OwRt>All</OwRt>



<InclFBC>*BE70</InclFBC>

</BaseCalcFare>



PublicFare=false),

Tariff is required.





InclFBC and ExclFBC (with or without wildcard) are optional. These elements include or omit FBCs from the group. See FBC Notes below for more information.




Economy

PremiumEconomy

Business

PremiumBusiness

First

PremiumFirst

Notes:




Economy

PremiumEconomy

Business

PremiumBusiness

First

PremiumFirst



FBC Notes:





The assumed asterisk at the end is never replaced by a numeric.






NA Int RTW

Standard


From From

Calculated



N/A



Note: If a zone is built which

<CalcCalcFare>


<Loc1>


>

</Loc1>

<Loc2>

<Location>SYD</Location

>

</Loc2>

</Routes>



includes Newark, New Jersey (EWR) in the city listing that zone CANNOT be used when creating a non-North American fare.






<IncrDecr>


percent="15.0" />

</IncrDecr>



</CalcCalcFare>



Non-North American

SELLING contracts






TicketRules="CONTRACT"

Surcharges="AIRLINE" Stopovers="AIRLINE"

Season="AIRLINE" Penalties="AIRLINE"

MinStay="AIRLINE" MaxStay="AIRLINE"

HIP="AIRLINE"


Endorsements="AIRLINE" DOW="AIRLINE"

Combinations="AIRLINE"



</CalcFareGroup>




Set Action to:




1G for Galileo

1V for Apollo

1P for Worldspan











<Distributions>

<Distribution Action="CreateFromLocal"


<Name>QXDIST</Name>

<DistributionBasis

Agencies="true"/>

<DistSecLevels>

<DistSecLevel>


<Security

Update="false"


Sell="true"

Ticket="true"/>

</DistSecLevel>

<DistSecLevel>



Redistribute="true"

Sell="false"

Ticket="false"/>

</DistSecLevel>

</DistSecLevels>


</Distribution>

</Distributions>
















OW = One way

RT = Round trip



Only one exception can be selected for the entire contract (either Fare Basis Code (FBC) or Fare Family). A wildcard (represented by as asterisk) is allowed (e.g., F* or *UQ).

<TicketDetailAndSellingLevel

>

<ExceptionGroup

TripType="OW">

<FareClass>

<FareFamily>*BE70<

/FareFamily>

</FareClass>

</ExceptionGroup>

Passenger is the three-character passenger type code to which this ticketing and selling level applies. The default is ALL, which is also a valid entry, although it is not part of the Passenger Type Code list. Note: All ticketing data and associated selling levels are tied to the passenger type. Ticketing detail can only be entered once for an exception group and passenger type combination (e.g., OW exception for ADT passenger type), but selling levels with different geography can exist as long as the ticketing data matches for all selling level.







<Passenger>ADT</Passenger

>



If the contract is Net and Selling, SellingFareParams are not valid

If the contract is Net,

<SellingLevel

AllRoutes="true">

<SellingFare>

<IncreasePct

Pct="10" />

</SellingFare>

</SellingLevel>


l>



SellingFare is not valid.



In SellingFare, do one of the following:











SellingFare is not a valid entry for


</Distribution>

</Distributions>



a Net contract.


</RequestElement>

</APF_ContractRQ>

Response






<ns3:Contract>


<ns2:Success />

</ns3:Contract>




Updating a Contract

Contracts can be updated in two ways:

Use "Update" to totally replace the current contract with a new version. All required elements and

sub-elements must be sent in an Update request.

Use "PartialUpdate" to only send the portions of the contract that require modification. When

using PartialUpdate, the source information, Contract ID, and airline code are also required.

The following elements cannot be updated:

ContractID

Calculated option (i.e., you cannot change a contract from a Calculated to a Standard or vice

versa)

Update Request

An Update request is almost the same as the original create contract request, with the following

differences:

Set RequestType to "Update" instead of "Create".

Set Distribution's <Action> to:

o "UpdateFromLocal" to update a contract-specific distribution group that was created with a

previous CreateFromGlobal or CreateFromLocal request.

o "CreateFromGlobal" if the contract used a Global Distribution Group and the Global group

was updated (see Updating a Global Distribution Group on page 181).

o "CreateFromLocal" to send all information for a contract-specific distribution group.

o "NoChange" to use the existing Global or contract-specific distribution group in the contract,

without any changes.

Notes:

o If, for example, a contract has four distribution groups, any subsequent upload requests for

that contract must resend four <Distribution> elements to have the updated contract

look the same.

o To delete a distribution group from a contract, omit the <Distribution> element for the

group. All other distribution groups can be kept in the contract by setting Action to

"NoChange" or "UpdateFromLocal" (along with any changes).

Set BaseFareGroup's <Zone ImportNewVersion> to "false" so that the request uses the current

version of the zone for the contract. Or, set it to "true" so the request checks the APF database for

an updated version of the zone.



Make sure the <ContractID> sent in the Update request is the same as the <ContractID> in the

original contract. All other information sent in the request must be identical except for the information to

be updated. See the Creating a Contract (page 25) examples for sample code.

Partial Update Request

To update a contract using a partial update, send the following information:

Source information, which includes the requestor information

ID or Name

Airline code (only required for Add-ons and contracts)

The element being modified

For an example partial update request, see Partial Update of a Standard Contract (page 148).

How Partial Updates Can Affect Contracts

Some partial updates may cause other contract information to be changed or lost.

You can only change the Contract Tour Code if no Ticket Details exist. If Ticket Details exist,

delete the Ticket Details first before changing the Contract Tour Code.

If you change the Contract Type, all ticketing information and selling levels associated with

distribution groups will be lost. For Net and Selling Contracts, selling levels must be entered. For

all types, ticket details must be entered.

If you change from North American to International or from International to North American, all

fare group information will be lost and will need to be entered.



Partial Update of a Standard Contract Example

When using the Partial Update feature, only the elements that are changing need to be sent in the request,

unlike an Update request that requires all elements to be sent.

The following example updates the location for permitted transfers. This partial update is a follow-on

request to the Standard Contract Example. For more information about each request element, see Standard

Contract Example (page 25).

Request



Explanation Code



<APF_ContractRQ


Version="1.00">


Source is required for all requests.

<RequestElement>

<Source xmlns=”http://www.opentravel.org/OTA/2003/05”





</RequestorID>

</Source>


<Contract

xmlns=”http://agencyprivatefares.galileo.com/2006A/XAPF/4.0”

ContractGeoType="International" Type="Selling"

Calculated="false" RequestType="PartialUpdate">

Both ContractID and AirlineCode are required. Enter the Contract Rule ID of the contract that is being modified.


Rule ID and Airline Code can be "edited," but this is not recommended. If either one is changed, a new contract is created; it is no longer an edit to the original contract.

<ContractID>QZ02</ContractID>




In this example, the Transfers section is being modified; therefore, it is the only contract element required in the request.

In the create request, transfers were allowed through Boston. In the partial update request, the location of permitted transfers is changed from Boston to Atlanta.

The current Transfer information is sent with a ChangeAction="Update" to indicate that information within this element needs to be updated. The <Change> element follows, defining the old and new values.

For information about Transfers, see Standard Contract Example (page 25).

<Transfers>

<Transfer TransferRuleBase="WholePricingUnit">


TransferBound="NumberBound"/>


<TransferLocDirs>

<TransferLocDir NumberPermitted="1"

Location="BOS" Direction="Outbound"

Permitted="true" ChangeAction="Update">

<Change Name="Location" Action="Update"

OldValue="BOS" NewValue="ATL"/>

</TransferLocDir>

</TransferLocDirs>


</Transfer>

</Transfers>

</Contract>

</RequestElement>

</APF_ContractRQ>

Response






<ns3:Contract>

<ns2:ContractID Version="2">QZ02</ns2:ContractID>

<ns2:Success />

</ns3:Contract>




Partial Update of a Calculated Contract Example



This example contains the minimum elements required for a partial update. This example is a follow-on

update request to the contract created in Calculated Contract Example 2 (page 123).

Request



Explanation Code



<APF_ContractRQ



xsi:schemaLocation="http://agencyprivatefares.galileo.com/2006A/XAPF

APF_ContractRQ.xsd" Version="1.00">



<RequestElement>






</RequestorID>

</Source>


<Contract


ContractGeoType="NorthAmerican" Type="Selling"

Calculated="true" RequestType="PartialUpdate">



Rule ID and Airline Code can be "edited," but this is not recommended. If either one is changed, a new contract is created; it is no longer an edit to the original





contract.

In this example, the RuleNbr is being modified within the CalcFareGroup. Therefore, it is the only contract element required in the request. For more information about the CalcFareGroup, see Calculated Contract Example 2.




<OwRt>All</OwRt>


<InclFBC>ABC*</InclFBC>


<Change Name="RuleNbr" Action="Update"

OldValue="1234" NewValue="9876"/>

</BaseCalcFare>

<CalcCalcFare>


<Loc1>


</Loc1>

<Loc2>

<Location>SYD</Location>

</Loc2>

</Routes>

<IncrDecr>


percent="15.0" />

</IncrDecr>


</CalcCalcFare>


TicketRules="CONTRACT" Surcharges="AIRLINE"

Stopovers="AIRLINE" Season="AIRLINE"

Penalties="AIRLINE" MinStay="AIRLINE"

MaxStay="AIRLINE" HIP="AIRLINE"

FltRulesCodeshare="AIRLINE" Endorsements="AIRLINE"

DOW="AIRLINE" Combinations="AIRLINE"



</CalcFareGroup>

</Contract>

</RequestElement>

</APF_ContractRQ>

Response






<ns3:Contract>


<ns2:Success />



</ns3:Contract>




Discontinuing a Contract

An active contract cannot be deleted. However, it can be discontinued if the discontinued date is set to

today's date and the contract is processed again. When the contract is processed in the fares database, it

becomes a historical contract and is no longer available for use by end users.

Request

The following example is a minimum viable contract update request with the discontinue date set to

"today's" date, August 8, 2009. Elements and sub-elements in purple are required. In some cases, the child

elements are only required because the optional parent element is used.

Explanation Code



<APF_ContractRQ


Version="1.00">


Source provides requestor details. The Source namespace is OTA. Type is ignored by XAPF but required for schema compliance. Because no definition exists for “provider of airline fare data”, use 18 to indicate "Other".





<RequestElement>

<Source xmlns=”http://www.opentravel.org/OTA/2003/05”>

<RequestorID Type="18" ID="G0XG4" ID_Context="APF">

<CompanyName CompanyShortName="3rdParty"


</RequestorID>

</Source>






Type of contract:

Selling

Net

NetandSelling

RequestType is set to Update, as this request is modifying the DiscontinueDate in order to discontinue the contract.

<Contract


ContractGeoType="NorthAmerican" Type="Selling"

Calculated="false" RequestType="PartialUpdate">

Contract rule ID of the contract being modified.

<ContractID>AAAA</ContractID>



DiscontinueDate should be set to today's date.


<Change Name="DiscontinueDate" Action="Update"

OldValue="2009-12-31" NewValue="2009-08-08"/>

Ends the contract request. </Contract>

</RequestElement>

</APF_ContractRQ>

Response






<ns3:Contract>

<ns2:ContractID Version="11">AAAA</ns2:ContractID>

<ns2:Success />

</ns3:Contract>




Add-on Fares

Add-on fares can be linked to the Standard contract fare to create a single through fare for fare display

and pricing. The combination of the Add-on fare and the Standard contract fare is described as a

"constructed fare". Add-on fares can never be displayed or priced alone. They can be reused as often as

needed to accommodate airlines that issue add-on fares that are common across multiple contracts. For

example, Emirates (EK) airline issues contracts for different classes of travel, different seasons, and

different markets. As their add-on fares are common across all contracts, Agency Private Fares allows an

EK Add-on contract to be appended to any EK Standard contract, provided the appropriate criteria have

been set in the Add-on and Standard contracts.

It is possible to restrict the use of an Add-on fare to combine specifically with one Standard contract, or

multiple Standard contracts, using Contract Rule ID, Fare Types, and Fare Basis Codes as criteria for

construction. See Creating Add-on Fares (page 157) for details.

Add-on contracts must have Gateway and Interior cities and/or zones associated with them. A Gateway is

the first point of arrival or the last point of departure in a country or area. Interior refers to cities or zones

that are the ultimate origin or destination of the constructed fare. In the example diagram below, potential

interior routes are designated with blue dotted lines and potential gateway cities with black dashed/dotted

lines. Only gateway cites/airports can construct to create an international Standard contract route.

The Interior cities and the Gateway cities in the diagram could also be grouped into Gateway and Interior

zones, which are structured similarly to Standard and Calculated contract zones. They can have multiple

cities, and in the case of Gateway zones, cities and airports. Gateway zones are always international

points of departure, where two fares can connect. Interior zones are made up of city codes only (no

airport codes) and consist of final origin or destination points. Gateway and Interior zones can never be

used on a Standard or Calculated contract. See Working with Zones for Add-on Fares (page 200).



Add-on fares can construct with an international Standard Contract to create a through-fare via a Gateway

zone, to save filing time. All the fare rules are inherited from the Standard Contract after a through fare is

created.

Add-on Fare and Standard Fare Construction

Add-on fares contain many of the same elements as Standard contracts. They include your Supplier Code,

an airline code, effective and discontinue dates, currency, and type. All Add-on fares require an owning

airline. This airline does not have to be present as a permitted airline on the Add-on fare, but is considered

the owner of the Add-on fare and route. The airline code of the Add-on fare matches to Standard contract

fares owned by the same airline. Add-on construction is not permitted for domestic North American

Standard contract fares.

Agency Private Fares allows you to set criteria that defines how the Add-on fare will construct with

Standard fares. You can enter the contract rule ID alone, or in combination with fare basis code or fare

types (economy, premium economy, business, premium business, first, and premium first), or you can use

the fare type or fare basis code alone. Other criteria in the Add-on fare is also used to determine whether

the Add-on can construct with a Standard contract. Both the Add-on and the Standard contract must have

the same supplier code and owning airline code. Add-on fares can apply to one-way fares that can be used

round trip, one-way only fares, or round trip only fares. The Rule ID, fare type, or fare basis code in the

Add-on fare must match the Rule ID, fare type, or fare basis code on the Standard fare.

In order for Add-on fares to construct (or link) with Standard contract fares, the gateways on the Add-on

must match to an origin or destination city or airport on the Standard contract. If the Add-on fare has

gateways of CHI, JFK, and BOS and the Standard contract only has CHI and JFK, the fares only link or

permit travel via CHI and JFK, not via BOS.

The passenger must travel via the gateways filed on the Add-on fare. All possible gateways must be

included when the Add-on fare is built in order to construct the fare and to define the allowable gateway

the passenger may travel via. For example, a fare is constructed using a BA Add-on fare filed from MAN-

BD-LON plus a BA standard fare filed from LON to ROM. The itinerary must include travel via LON.

The passenger cannot fly MAN-BA-ROM direct.

The ability to create zones for groups of cities is permitted for both interior and gateway points. See

Working with Add-on Zones (page 200). A gateway/gateway zone using an airport code must match to

another airport code and a city code can only match to another city code. For example, a fare is

constructed using a UA Add-on fare filed from DEN-UA-CHI or JFK plus a UA standard fare filed from

CHI or NYC to LON or PAR. The fare will not permit travel via NYC because JFK does not match the

city code of NYC.

Currency does not need to match in order to construct fares. If there is a currency mismatch between the

standard fare and the add-on fare, the final constructed fare is always converted to the currency of the

constructed fare origin. Also, the effective and discontinue dates of the add-on fare do not have to match

the dates of the Standard Contract. As long as the dates are valid for both the standard fare and the add-on

fare, the fare can be constructed.

When two North American cities are present on the itinerary and those cities are present on the Add-on

fare, Agency Private Fares allows one intermediate city between the interior and gateway point if that

intermediate point can be found on the route for the highest domestic fare in that market

(interior/gateway). This process is called domestic route validation or DRV. Since complete routings are

not always provided by the carrier who supplies the negotiated contract, Agency Private Fares provides

Domestic Route Validation (DRV) for Add-on fares within the US and Canada when constructing with



international fares. If the city passes the DRV process, the intermediate city is permitted on the Add-on

portion of the itinerary.

For example, the Add-on fare is SLC-NYC and the Standard fare is NYC-TLV. Travel SLC to TLV via

DEN and NYC is permitted if DEN is found on the airline route for the airline’s highest SLCNYC fare.

However, travel SLC to TLV via DEN, ATL, and NYC is not permitted as only one intermediate city is

allowed in DRV. A connection in ATL makes travel invalid for this fare.

Through fares are constructed for every applicable add-on gateway that has been filed on the Add-on fare

if that gateway is found on the Standard Contract fare. All possible route paths via applicable gateways

are displayed in a through route path from the origin city to the final destination city. This process is

similar to the route display for any constructed fare in Galileo 360 Fares.

When routes construct or link together:

A route for the Add-on fare is created behind the scenes between the interior and gateway points,

with the permitted airlines allowed between those points.

Domestic route validation takes place for Add-ons within the US, US Virgin Islands, Puerto Rico,

and Canada to allow one intermediate via city between the interior point and a gateway, based on

the domestic route for the highest fare in that market, for the airline being used. For all other Add-

ons, via points are not allowed.

The gateway cities or airports from the Add-on fare must be found on the airline route if the

Standard contract uses an airline published route option, in order for the routes to link and permit

travel via those cities or airports.

The $LR (Apollo) or FR* (Galileo) displays all valid, permitted route paths, via all applicable

gateway cities. The route display does not include the DRV locations.

Travel via one of the permitted gateways is required when the itinerary is booked, and the

gateway must be a ticketed point.

See Fare Quote for Constructed Fares (page 164) in Add-on Fare Scenarios for details.

Creating Add-on Fares

Agency Private Fares allows you to set criteria that defines how the Add-on fare will construct with

Standard fares. You can enter the contract rule ID alone, or in combination with fare basis code or fare

types (economy, premium economy, business, premium business, first, and premium first), or you can use

the fare type or fare basis code alone. Other criteria in the Add-on fare are also used to determine whether

the Add-on fare can construct with a Standard contract.

Both the Add-on and the Standard contract must have the same supplier code and owning airline code.

Add-on fares can apply to one-way fares that can be used round trip, one-way only fares, or round trip

only fares. The Add-on fare type (indicated in <FareUsage TripType>) must exactly match the

Standard fare type. The Rule ID, fare type, or fare basis code in the Add-on fare (in LinkCriteria)

must match the Rule ID, fare type, or fare basis code on the Standard fare.

The interior and gateway cities and the permitted airlines dictate the routing permitted. You can enter a

maximum of 10 permitted airlines.



Example

An Add-on fare is filed from an interior zone containing SFO / LAX / ONT / PDX / MRY to a

gateway zone that includes the cities CHI / NYC / DEN / SLC / WAS. The airlines permitted on

the Add-on contract route are DL / AA / UA / US. The route paths are created using the interior

points, via the airlines listed, to all the gateway points.

SFO / LAX / ONT / PDX / MRY – DL / AA / UA / US – CHI / NYC / DEN / SLC / WAS

You can make changes to your Interior or Gateway zones without affecting the existing Add-on

fares/routes. You must update the Add-on fares that are impacted by the zone change, if you want

the fares to reflect the change.

How Add-on Linking Criteria Match to Standard Contracts

Add-on fares and Standard contracts within your supplier code construct based on criteria defined in each.

The Add-on fare allows you to define the following criteria to link to the Standard contract:

Contract Rule ID

Fare Type (Economy, PremiumEconomy, Business, PremiumBusiness, First, PremiumFirst)

Fare Basis Code

Contract Rule ID and Fare Type

Contract Rule ID and Fare Basis Code

The combination of criteria that you enter must be an exact match to the Contract Rule ID, Fare Basis

Code, and Fare Type(s) entered in the Standard contract. For example, if you enter a Contract Rule ID in

the Add-on fare, unless it is an exact match to the Contract Rule ID of a Standard contract within your

supplier code, the Add-on fare will not construct with any Standard contract.

Additionally, for an Add-on fare to construct with a Standard contract:

The Supplier Code must be the same for the Add-on fare and the Standard contract.

The owning airline must be the same for the Add-on fare and the Standard contract.

The Type (OW, OW/RT, RT) must be the same for the Add-on fare and the Standard contract.

The Standard contract must permit or require Add-ons.

The Add-on fare link criteria must match the criteria defined for Add-ons in the Standard contract

(in the <AddonRules> section).

The following table shows how the Standard contract criteria and the Add-on fare criteria match to each

other to permit the construction. The Add-on criteria filed must also match to the specific information for

the Standard contract the Add-on is trying to construct with. In other words, the Contract Rule ID

specified on the Add-on must match the specific Standard contract Rule ID. See the Matching

Construction Criteria (page 166) scenario in Add-on Fare Scenarios.

When the Standard contract is set to permit construction with All Fares, it permits any Add-on fare that

matches the Standard contract's specific rule information (Contract Rule ID, fare type, or fare basis) to

construct.

Note: Caution should be used when allowing this broad application.



Standard Contract Add-on Criteria

Contract Rule ID

Contract Rule ID & Fare Basis Code

Contract Rule ID & Fare Type

Fare Basis Code

Fare Type

All Fares

Add-on Fare Link Criteria

Contract Rule ID

Match No Match No Match No Match No Match

Match

Contract Rule ID & Fare Basis Code

Match Match No Match Match No Match

Match

Contract Rule ID & Fare Type

Match No Match Match No Match Match Match

Fare Basis Code

No Match No Match No Match Match No Match

Match

Fare Type No Match No Match No Match No Match Match Match



Add-on Fare Requests

The SOAPBodyElement for Add-on fares is called APF_AddonRQ. It is a request to upload a contract to

the APF system. The Add-on Examples (page 168) provide sample requests and responses.

SOAP Request






password are encoded in BASE 64 in the format userid”:”password.

Following a blank line, the XML SOAP payload begins. The APF server does not expect any data in the



Request

POST /XAPF HTTP/1.1

Accept-Language: en


action="APF_AddonRQ";







<soap:Body>

APF_AddonRQ

</soap:Body>

</soap:Envelope>

SOAP Responses

There are two types of response that can be sent for a request: Success or Failure. Currently, XML for

APF (XAPF) does not issue warnings. A failure response always includes errors.


XML SOAP payload begins. XAPF does not expect any data in the SOAP header section, so it can be

omitted. The SOAP body contains a single XML element, which is the XAPF transaction response.

Successful Response

HTTP/1.1 200 OK





Content-Length: 777

Date: Wed, 12 Apr 2006 22:27:33 GMT

Connection: close



<soap:Body>

<ns3:APF_AddonRS




<ns3:Addon>

<ns2:AddonID Version="1">AAG1</ns2:AddonID>

<ns2:Success />

</ns3:Addon>

</ns3:APF_AddonRS>

<soap:Body>

</soap:Envelope>

Failure Response

HTTP/1.1 200 OK



Content-Length: 777

Date: Wed, 12 Apr 2006 22:27:33 GMT

Connection: close



<soap:Body>

<ns3:APF_AddonRS




<ns3:Addon>

<ns2:AddonID Version="1">AAG1</ns2:AddonID>

<ns2:Errors>


xmlns:ns1="http://www.opentravel.org/OTA/2003/05">Request Rejected –

Invalid User ID or Password</ns1:Error>

</ns2:Errors>

</ns3:Addon>

</ns3:APF_AddonRS>

<soap:Body>

</soap:Envelope>



Add-on Fare Scenarios

The following scenarios provide examples of how Add-on fares entered in Agency Private Fares connect

to Standard routes. These scenarios are for illustration purposes only.

Route Display for Constructed Fares

Fare Detail Display for Constructed Fares

Fare Quote for Constructed Fares

Constructed Fares by Global Direction

Removal of Duplicate Fares in the Fare Display

Matching Construction Criteria

Route Display for Constructed Fares

The gateway point on the add-on route is the only point that can connect to the Standard route. The gateway city/airport can link to any common city/airport on the Standard route. The final route display reflects all possible route paths (not including duplicate paths) through all possible gateways for the $LR on Apollo or the FR*ln on Galileo:

BA Add-on fare for 30.00 GBP

Only gateway cities/airports will be used to construct with a city/airport on the Standard contract:

Interior cities: GLA IOM NCL EDI

Gateway cities: MAN LON

Airlines permitted between Interior cities and Gateway cities/airports: BD

Booking class permitted: S

BA Standard contract fares/routes for 400.00 GBP that allows direct/non-stop flights only

Origin cities on the Standard contract are: LON / MAN / EDI

To destination city: NYC

The origin cities that are common to the gateway cities on the add-on are the construction points:

LON/MAN

Note: EDI is displayed as both a constructed fare via LON or MAN and a Standard fare permitting only

direct/non-stop travel.

Constructed Fares

The linked route, with the Add-on route in parentheses, displays. The $LR on Apollo or FR*ln on

Galileo follow-on display may remove some of the duplicates:

FDGLANYC/BA OR $DGLANYC|BA: Only one constructed fare is displayed (a duplicate is

removed), but the routing allows travel via either gateway.

GLA-NYC MON-13NOV06 BA AIRPORT FARES

MPM 4032 AT

TAXES/FEES NOT INCLUDED



PRIVATE FARES FOR XXX

USD CURRENCY FARES EXIST

CX FARE FARE C AP MIN/ SEASONS.... . MR GI DT

GBP BASIS MAX

GLANYC

1 -BA 430.00R TESTFARE T + SU/1M 10NOV6-12DEC6 R

FR*1 OR $LR1: Both gateways LON and MAN connect to the Standard Contract fare to create

the constructed route path.

GLA-BD-LON-BA-NYC

GLA-BD-MAN-BA-NYC

Fare Detail Display for Constructed Fares

The Fare Detail of any constructed APF fare can be displayed to show both the Standard contract fare

details and the Add-on fare details. Each fare is detailed in one column and you can determine which APF

fares were used to construct the resulting through international fare.

The first column always displays the Standard contract fare information. The Standard contract fare item

in red, in the example below, provides the Add-on construction rules filed on the contract.

The second column, shown in blue, details the Add-on fare information. If multiple gateways apply to the

Add-on fare, only one of those gateways displays in the fare detail as duplicated fares are not presented in

the fare display. The route display entry shows all possible route paths via all the permitted gateway

cities/airports.

A third column displays if both an origin and destination Add-on are constructing with the Standard fare.

FH*2 Galileo®

FD2 Apollo®

MUC-HKG FRI-23MAR07 CX TAXES/FEES NOT INCLUDED ADULT FARES CX FARE FARE C AP MIN/ SEASONS...... MR GI DT EUR BASIS MAX 2 -CX 4550.00 YTEST Y R

FRAHKG CX MUCFRA CX

AMOUNT: EUR/ 4500.00 USD/ 50.00 Add-on fare amount.

NUC EQUIV: NUC/ 5750.34 NUC/ 63.89 Add-on fare amt converted to NUCs.



FBC: YTEST R/YTEST Add-on link criteria – Rule ID = R/ , Fare Basis Code displays as filed, Fare Type is indicated by E* (Economy), Z* (Premium Economy), B* (Business), J* (Premium Business), F* (First), or P* (Premium First).

TRVL EFF/DIS: OPEN OPEN

TKT EFF/DIS: 09JAN0730OCT07 05JAN0705JAN10

TRAVEL COMP:

FOOTNOTE:

FARE USAGE: OW RT OW RT

GLOBAL DIR: 99

FARE TYPE: PRO

CONST ZONES: RFB Add-on rules from the Standard contract, permitting construction by Rule ID and Fare Basis Code. RFB=Rule ID and FBC, RFT=Rule ID and FT, R=Rule ID, FT=Fare Type, and ALL=All fares.

SUPP/TARIFF: APF 3/PF3 APF 3/PF3 Add-on Fare usage.

ROUTE/MIL: PF3/0061 PF3/0092 Add-on tariff and assigned Route number.

RULE NUMBER: PF3/1234 PF3/1236 Add-on tariff and Add-on ID.

PASNGR TYPE: ADT DAY TYPE: SEASON TYPE: NORMAL/SPECL: SPECIAL DISPLAY CAT: L

SEASON TYPE:

Fare Quote for Constructed Fares

An itinerary is built for the constructed fare described above in Fare and Route Display for Constructed

Fares. A through fare is shown in the linear from GLA to NYC.

1 BD 390S 15AUG GLAMAN SS1 700A 805A * WE E

OPERATED BY OPERATED BY BMI REGIONAL

2 BA1503T 15AUG MANJFK SS1 1000A 1245P * WE E

3 BA 178T 25AUG JFKLHR SS1 845A 830P * SA E

4 BD 14S 25AUG LHRGLA SS1 940P 1055P * SA E

FQ OR $B

GLA BD X/MAN BA NYC 423.39TESTFARE BA X/LON BD GLA

423.39TESTFARE NUC846.78END ROE0.507796

FARE GBP 430.00 TAX 80.00GB TAX 24.70UB TAX 1.30AY TAX 15.80US

TAX 2.60XA TAX 2.40XF TAX 3.70XY TAX 2.60YC TAX 96.00YQ TOT GBP

659.10

S1 NVB15MAR/NVA15MAR




E NONREF/PEX



Constructed Fares by Global Direction

Carrier QF has one Standard Contract for an LLTEST fare for 1200.00 AUD from Australia to FRA. The

Standard Contract permits two different routings, one via Asia (Eastern Hemisphere global direction) and

the other via the US (Atlantic/Pacific Global direction). There are two different Add-on fare amounts for

ADL-SYD, one for travel via the Eastern Hemisphere for 100.00 AUD and the other for travel via the US

for 150.00 AUD.

In order to control how the Add-on fares can construct:

Two separate Standard Contracts should be created using different routes to indicate the direction

in which the passenger must travel (via Asia for the EH global direction and via the US for the

AP global direction).

Both Standard Contracts should be set to permit construction by Rule ID.

Two Add-on fares should be created using the Contract Rule ID to define the Standard Contract

that each Add-on fare can construct with.

The following Fare Display and follow-on shows the results:

>FDADLFRA/QF/L-PRI-TEST:P OR $DADLFRA+QF:L-PRI-TEST:P

ADL-FRA TUE-16JAN07 QF

MPM 12128 EH 13084 TS 16218 AP



CX FARE FARE C AP MIN/ SEASONS...... MR GI DT

AUD BASIS MAX

1 QF 1300.00R LLTEST L + 15AUG -30AUG R

ACCT: TEST

2 QF 1350.00R LLTEST L + 15AUG -30AUG R

ACCT: TEST

FR*1 OR $LR1

ADL(QF)SYD(QF)SIN(QF)LON(BA)FRA

FR*2 OR $LR2

ADL(QF)SYD/MEL(QF)LAX(QF)LON(BA)FRA

ADL(QF)SYD/MEL(QF)NYC(QF)LON(BA)FRA

Removal of Duplicate Fares in the Fare Display

BA has a contract that contains Add-on fare amounts for US markets. The Standard contract MTEST fare

is 600.00 EUR from ATH to the US gateways NYC, BOS, DTT, CHI, and WAS. The Add-on fare for

the Midwest portion of the US permits travel via any of these gateways. One interior Add-on city is DSM

and permits travel on AA via NYC, BOS, DTT, CHI, or WAS for an Add-on amount of 100.00 EUR.

When the fares are constructed for Fare Display, there are actually five duplicate fares created linking the

two fares at each gateway city. Only one of these fares displays because all the permitted route paths via

each gateway are also displayed.



Only one of the fares constructed using the same Add-on Fare and the same Standard Contract fare is

displayed. The routing permits travel via any of the five gateway cities. If additional constructed fares are

created using a different Add-on fare or a different Standard contract, they are displayed and they are not

considered duplicates.

>FDATHDSM/BA-PRI-TEST:P OR $DATHDSM+BA-PRI-TEST:P

ATH-DSM TUE-16JAN07 BA

MPM 6891 AT


PUBLIC FARES


EUR BASIS MAX

1 BA 700.00R MTEST M 3/12M 12JAN -30JUN R

ACCT: TEST

END

FR*1 OR $LR1

ATH(BA)LON(BA)NYC(AA)DSM

ATH(BA)LON(BA)BOS(AA)DSM

ATH(BA)LON(BA)DTT(AA)DSM

ATH(BA)LON(BA)CHI(AA)DSM

ATH(BA)LON(BA)WAS(AA)DSM

Matching of Construction Criteria

In order for an International Standard fare to construct with an Add-on fare, both fares must match in

terms of criteria that has been filed on each fare. The Standard contract must permit or require Add-on

construction, and also define the type of Add-on fares permitted to construct, based on the link criteria

filed on the Add-on fare. See How Add-on Linking Criteria Match to Standard Contracts (page 158) for a

table view.

Example

A non-North American Standard contract that uses Contract Rule ID 1234 has been filed by Supplier

G0XXX for carrier CX. The contract contains fares between FRA and HKG, and three different fare basis

codes exist: YTEST (4500.00 EUR), CTEST (5000.00 EUR), and FTEST (8000.00 EUR).

The Add-on construction options selected for the Standard contract are Permitted for construction and

Rule ID and Fare Basis Code for the Add-on Rules. These selections require that the Add-on rule must

contain a specific Rule ID and a specific fare basis code in the link criteria section in order for the fares to

construct.

The same supplier (G0XXX) has also filed several Add-on fares between cities within Germany for

carrier CX.

1. Add-on ID 1234 is filed between Interior cities—MUC/STR/DUS—and the Gateway city—

FRA—using LH for an amount of 75.00 EUR. The criteria filed are Contract Rule ID–1234 and

Fare Basis Code–CTEST.




FRA—using LH for an amount of 50.00 EURs. The criteria filed are Contract Rule ID–1234 and

Fare Basis Code–YTEST.


FRA—using LH. The criteria filed are Rule ID–1234 and Fare Type–First.

Both the first and second Add-ons (ID 1234 and 1236) will construct with fares from the Standard

contract for CX because both Add-ons have defined the link criteria by specific Rule ID and specific fare

basis code. The criteria from both Add-ons match specific information in Contract Rule ID 1234. The first

Add-on will only construct with the CTEST fare and the second Add-on will only construct with the

YTEST fare.

The third Add-on listed will not construct with Contract Rule ID 1234. Although the specific Rule ID is

defined as Contract Rule ID–1234, a fare basis code has not been defined, therefore the fare will not

construct based on Rule ID and Fare Type.

The fare display shows both the constructed YTEST and CTEST fares but the FTEST fare is not in the

display because construction is not valid.

In Galileo FDMUCHKG/CX/L-PRI-TESTFARE:P or in Apollo $DMUCHKG|CX:L-PRI-TESTFARE:P



EUR BASIS MAX

1 -CX 4550.00R YTEST Y R

ACCT: TESTFARE

TD:TSTFARE

2 -CX 5075.00R CTEST C R

ACCT: TESTFARE

TD:TSTFARE

END



Add-on Fare Example



This add-on fare request creates two add-on fares:

Round trip between Manchester and London on British Airways or United

One way between Denver or Albuquerque and Los Angeles or San Francisco on American

Airlines or United

Request



Explanation Code

Defines the namespace for the APF_AddonRQ and the version of the XAPF schema.


<APF_AddonRQ


Version="1.00">

The RequestElement contains the information for a single add-on fare. Multiple Add-on RequestElements can be submitted in a single request.

Source provides requestor details. Type is ignored by XAPF, but required for schema compliance. Because no definition exists for providers of airline fare data, use 18 to indicate "Other".



CompanyShortName provides the name of

<RequestElement>






</RequestorID>

</Source>



the XML Vendor Licensee. This name can be up to 32 characters.


The RequestType values can be Create, Update, or PartialUpdate. Create indicates that this is a new add-on fare. Update indicates it is an update to an existing add-on fare and that all information necessary for the add-on fare is included in the update request. PartialUpdate indicates that it is an update to an existing add-on fare but that only the modified elements are being sent in the request.

Add-on IDs are unique per supplier/airline code combination throughout the system. This element must contain four alpha, numeric, or alpha AND numeric characters. It does not have to include the airline code, but can include the airline code. No special characters or blanks are allowed. Note: 9999 is not allowed.

<Addon



<AddonID>QAD8</AddonID>

AirlineCode is the primary or owning airline for the add-on fare.


DiscontinueDate is the date the add-on fare is no longer valid. After this date has passed in GMT, the




add-on fare is moved to history.

The default DiscontinueDate is one year from the effective date. The DiscontinueDate cannot be more than three years from the effective date.

Description is a free-form text line for reference, where you can enter a description for the add-on fare.

<Description>Create an Addon</Description>

Any valid currency can be used.

<AddonAmount CurrencyCode="EUR" Amount="150.00"/>

FareUsage indicates for which trips the add-on fare can be used.

RT = round trip

OW = one way

OW/RT = both round trip and one way

<FareUsage TripType="RT"/>

For Interior, indicate which interior cities or zones are able to be constructed with the add-on fare. Enter the three-letter city code (not airport code) or zone name.

For Gateway, indicate which gateway cities, airports, or zones are able to be constructed with the add-on fare. Choose to enter either zones or cities and airports.

You can enter all airport codes, all city codes, or a combination of cities and airports. Or, you can enter zones. Note: You cannot combine zones with cities or airports.


If NYC is included in an Interior zone, NYC includes LGA, JFK, and

<InteriorCitiesOrZone>

<InteriorCities>MAN</InteriorCities>

</InteriorCitiesOrZone>

<GatewayCitiesAirportsOrZone>

<GatewayCitiesAirports>LON</GatewayCitiesAirports>

</GatewayCitiesAirportsOrZone>



EWR. However, EWR cannot be named separately in an Interior zone.

Puerto Rico and U.S.Virgin Islands are entered as states of the U.S.; USPR for Puerto Rico and USVI for Virgin Islands.

At least one airline and booking code must be included. The airline can be different than the one that owns the add-on fare.

You can enter up to eight booking codes per airline.

<PermittedAirlines Airline="BA">

<BookingCodes>A B C D</BookingCodes>

</PermittedAirlines>

<PermittedAirlines Airline="UA">

<BookingCodes>E F G H</BookingCodes>


Add-on fares and Standard contracts within your supplier code construct based on criteria defined in each. The Add-on fare allows you to define the following LinkCriteria to the Standard contract. For more information, see Add-on Fare and Standard Fare Construction (page 156).

At least one type of linking criteria must be defined:

Contract Rule ID

Fare Type

Fare Basis Code

Contract Rule ID and Fare Basis Code

Contract Rule ID and Fare Type

ALL permits any Add-on fare that matches the Standard contract's specific rule information (Contract Rule ID, fare type, or fare basis) to construct. Note: Caution

<LinkCriteria>

<FareTypeOrFBC>


</FareTypeOrFBC>

</LinkCriteria>

</Addon>

</RequestElement>



should be used when allowing this broad application.

Both the Add-on fare and the Standard contract fare must allow the construction in order for the fares to create a through fare.

For an Add-on fare to construct with a Standard contract:

The Supplier Code must be the same for the Add-on fare and the Standard contract.

The owning airline must be the same for the Add-on fare and the Standard contract.

The Type (OW Only, OW/RT, RT) must be the same for the Add-on fare and the Standard contract.

The Standard contract must permit or require Add-ons.

The selection in the Add-on rules drop-down list on the Standard contract header window must match the criteria defined for the Standard Contract in the Add-on fare.

A second add-on fare is added.

<RequestElement>






</RequestorID>

</Source>

<Addon








<Description>Create an Addon</Description>

<AddonAmount CurrencyCode="USD" Amount="120.00"/>

<FareUsage TripType="OW"/>

<InteriorCitiesOrZone>

<InteriorCities>DEN ABQ</InteriorCities>

</InteriorCitiesOrZone>


<GatewayCitiesAirports>LAX

SFO</GatewayCitiesAirports>


<PermittedAirlines Airline="AA">

<BookingCodes>A B C D</BookingCodes>


<PermittedAirlines Airline="UA">

<BookingCodes>E F G H</BookingCodes>


<LinkCriteria>

<FareTypeOrFBC>

<FareBasisCode>QQQ</FareBasisCode>

</FareTypeOrFBC>

</LinkCriteria>

</Addon>

</RequestElement>

</APF_AddonRQ>

Response

The Success response indicates a successful upload of the Add-on the APF server.


<ns3:APF_AddonRS xmlns=”http://www.opentravel.org/OTA/2003/05”



<ns3:Addon>

<ns2:AddonID Version="1">QAD8</ns2:AddonID>

<ns2:Success />

</ns3:Addon>

<ns3:Addon>


<ns3:Success />

</ns3:Addon>

</ns3:APF_AddonRS>



Updating Add-on Fares

Add-on fares can be updated in two ways:

Use "Update" to totally replace the current Add-on fare with a new version. All required elements

and sub-elements must be sent in an Update request.

Use "PartialUpdate" to only send the portions of the Add-on fare that require modification. When

using PartialUpdate, the source information, Addon ID, and airline code are also required. See

Partial Update of an Add-on (page 175) for sample code.

How Updates May Affect Add-on Fares

Some updates may cause the Add-on fare to no longer construct with the same Standard contracts as

before the update.

Depending on the linking criteria (page 158) of the Add-on fare and the Add-on rules of the

Standard contract, changing the Rule ID, fare type, or fare basis code value in the Add-on fare

may change the Standard contract with which the Add-on fare can construct.

Modifying the TripType will change the Standard contracts with which this fare can construct.

The Add-on fare's Trip Type must match the TripType of the Standard contract.



Partial Update of an Add-on



The following example adds a gateway city to the existing Add-on fare. This partial update is a follow-on

request to the Add-on Fares Example. For more information about each request element, see Add-on

Fares Example (page 168).

Request



Explanation Code

Defines the namespace for the APF_AddonRQ request and the version of the XAPF schema.


<APF_AddonRQ


Version="1.00">



<RequestElement>






</RequestorID>

</Source>


<Addon

xmlns=”http://agencyprivatefares.galileo.com/2006A/XAPF/4.

0” RequestType="PartialUpdate">



Rule ID and Airline Code can be "edited," but this is not recommended. If either one is changed, a new contract is created; it is no longer an edit to the original contract.



In this example, the GatewayCitiesAirportsOrZone element is being updated to include a new gateway

<GatewayCitiesAirportsOrZone ChangeAction="Update">

<Change Name="GatewayCitiesAirports"

Action="Create" NewValue="PAR"/>



city.

The <Change> element defines the new gateway city. Action is set to Create because this gateway city is new to this Add-on fare.


</Addon>

</RequestElement>

</APF_AddonRQ>

Response

The Success response indicates a successful upload of the Add-on update to the APF server.


<ns3:APF_AddonRS xmlns=”http://www.opentravel.org/OTA/2003/05”



<ns3:Addon>


<ns2:Success />

</ns3:Addon>

</ns3:APF_AddonRS>



Discontinuing an Add-on Fare

You cannot delete an active Add-on fare. You can, however, update the Add-on fare and set the

Discontinued Date to today's date. When the Add-on is extracted to the fares database, it becomes a

historical Add-on fare and is no longer available for use by end users.

The following example includes a partial update to an existing Add-on fare. This request sets the

discontinue date to today's date.


<APF_AddonRQ xmlns="http://agencyprivatefares.galileo.com/2006A/XAPF"

Version="1.00">

<RequestElement>




Code="1234567"/>

</RequestorID>

</Source>

<Addon xmlns=”http://agencyprivatefares.galileo.com/2006A/XAPF/4.0”



<AirlineCode>F9</AirlineCode>


<Change Name="DiscontinueDate" Action="Update" OldValue="2009-08-31"

NewValue="2009-07-10"/>

</Addon>

</RequestElement>

</APF_AddonRQ>



Global Distribution Groups

A Distribution Group is defined as one or more organisations and/or locations that have the same

security level (ability to view, update, and/or sell). Distribution groups must be created so that contracts

can be viewed through Galileo access products (Focalpoint and Viewpoint). Each distribution group must

have a unique name. There are two types of distribution groups:

Contract Specific – A distribution group or master distribution group that is associated with a

particular contract. It does not display globally and it is sent in the <Distributions> element

of the APF_ContractRQ request. Contract-specific distribution groups must have a unique name

within the contract, but a contract-specific distribution group can have the same name as a global

distribution group. Contract-specific distribution groups are only used within the contract in

which they are created.

Global – A distribution group or master distribution group that is available to any user within a

specific supplier code for use with any contract in that same supplier code.

Distribution lists can be built according to:

Travel agency Pseudo City Code (PCC) or IATA Number.

Geography – Fares can optionally be distributed to all Galileo, Apollo, and Worldspan agencies

in a geography.

A combination of both of the above options.

All travel agencies within a GDS.

For each contract, there can be one or many sets of selling fares for each distribution group. In addition,

the security level for the organisation/location must be chosen. If you have Net or Net and Selling fares, a

location must be given ticketing authority to see the net level.

Master Global Distribution Groups

A master global distribution group contains other master global and/or global distribution groups. A

master global distribution group is not GDS specific; therefore, no GDS is required in the request. Master

distribution lists can be built using:

Other master distribution groups

Distribution groups

Note: The security levels and distribution basis are maintained at the distribution group level.

Request

APF_DistributionRQ is a request that sends details about a master global and global distribution group,

including whether to create, update, or delete the group. A response is returned from APF with a

success/error message depending on whether the distribution group is successfully processed.



Master Global and Global Distribution Group Requests

The SOAPBodyElement for master global and global distribution groups is called APF_DistributionRQ.

It is a request to upload a master global or global distribution group to the APF server. The Global

Distribution Group examples provide sample requests and responses.

SOAP Request







Following a blank line the XML SOAP payload begins. The APF server does not expect any data in the



Request

POST /XAPF HTTP/1.1

Accept-Language: en









<soap:Body>

APF_DistributionRQ

</soap:Body>

</soap:Envelope>

SOAP Responses


XML SOAP payload begins. XML for APF (XAPF) does not expect any data in the SOAP header

section, so it can be omitted. The SOAP body contains a single XML element, which is the XAPF

transaction response.

There are two types of response that can be sent for a request: Success or Failure. A successful response

may include warnings. A failure response always includes errors.

Successful Response

HTTP/1.1 200 OK





Content-Length: 777

Date: Wed, 12 Apr 2006 22:27:33 GMT

Connection: close



<soap:Body>

<ns3:APF_DistributionRS




<ns3:Distribution>

<ns2:DistributionName>NewDistribution</ns2:DistributionName>

<ns2:Success/>

</ns3:Distribution>

</ns3:APF_DistributionRS>

<soap:Body>

</soap:Envelope>

Failure Response

HTTP/1.1 200 OK



Content-Length: 777

Date: Wed, 12 Apr 2006 22:27:33 GMT

Connection: close



<soap:Body>

<ns3:APF_DistributionRS




<ns3:Distribution>

<ns2:DistributionName>NewDistribution</ns2:DistributionName>

<ns2:Errors>


xmlns:ns1="http://www.opentravel.org/OTA/2003/05">Global Distribution Group Create

Rejected – Global Distribution Group Name and Supplier Code Combination Already

Exists</ns1:Error>

</ns2:Errors>

</ns3:Distribution>


<soap:Body>

</soap:Envelope>



Updating a Global Distribution Group

To modify an existing Master Global or Global Distribution Group, you can either send a total replace or

a partial update by setting RequestType to one of the following:

Update – Indicates that the request is a total replace that contains ALL the elements and sub-

elements that are required. If certain elements or sub-elements are not required, they can be left

out of the update request. All other information sent in the request must be identical except for

the information to be updated. See Example of a Complete Update of a Global Distribution Group

(page 181) for sample code.

PartialUpdate – Indicates that the request is a partial update, and only those element and sub-

elements that are being modified are included in the update request. See Examples of a Partial

Update of a Global Distribution Group (page 189) for sample code.

Ensure that the <Name> sent in either update request is the same as the <Name> of the existing Master

Global or Global Distribution Group.

Partial Updates

When sending a Partial Update of a Master Global or Global Distribution Group,

Set RequestType to PartialUpdate.

Include the Source information.

Include the <Name> of the group being modified.

Include the elements being modified.



Master Global and Global Distribution Group Examples

Global distribution group examples are provided for:

Creating a Global Distribution Group (page 183)

Partially Updating a Global Distribution Group (page 189)

Updating a Global Distribution Group (page 193)

Deleting a Global Distribution Group - The same request is used for both master global and

global distribution groups (page 198).

Master global distribution group examples are provided for:

Creating a Master Global Distribution Group (page 187)

Updating a Master Global Distribution Group (page 196)

Deleting a Global Distribution Group - The same request is used for both master global and

global distribution groups (page 198).

For examples of contract-specific distribution groups, see Standard Contract Example 1(page 25) and

Standard Contract Example 4 (page 72).



Creating a Global Distribution Group Example

The following example may not depict ALL elements or sub-elements that can be used in the request. It

is included for reference only.

The following request creates a Global Distribution Group that can be used by two agencies; each agency

has different access rights.

Master global distribution groups use the same XML request; however, the required information is

different. See Creating a Master Global Distribution Group for an example.

Request



Explanation Code

Defines the namespace for the APF_DistributionRQ and the version of the XAPF schema.


<APF_DistributionRQ


Version="1.00">

RequestElement contains the information for one global distribution group. Multiple RequestElements can be submitted in a single request.






<RequestElement>






</RequestorID>

</Source>

The Distribution namespace is the APF XML location,

<Distribution

xmlns=”http://agencyprivatefares.galileo.com/2006A/XAPF/4



including the version number.


RequestType indicates the type of request:

Create indicates that this is a new Global Distribution Group.

Update indicates it is an update to an existing Global Distribution Group and that all group information will be included in the request.

PartialUpdate indicates an update to an existing Global Distribution Group but that only the updated information will be sent in the request.

Delete indicated the Distribution Group will be deleted.

.0” GDS="1V" RequestType="Create">

Name is the distribution group name (maximum of 50 characters). Alpha-numerics (A to Z, 0 to 9), full stop (.), slash (/), dash (-),colon (:), underscore (_), asterisk (*), apostrophe ('), and blank (space) are valid.

<Name>QXCRE1</Name>



Agencies - Distribute the contract to specific agencies identified by PCC or IATA number. If set to true, an <Agency> is required in DistSecLevel below.

Geographic - Distribute the contract to all Galileo agencies within a geography. If set to true, a <Location> is required in DistSecLevel below.

AgencyAndGeographic - Distribute the contract to agencies in a certain location. If set to true, both <Agency> and <Location> are required in DistSecLevel below.

<DistributionBasis Agencies="true"/>



DistSecLevels defines the agencies and associated security levels assigned to this distribution group. At least one security level must be assigned.

If Agencies or AgencyAndGeographic were used in the DistributionBasis above, Agency defines the specific travel agency code or Pseudo City Code (PCC) that can use this distribution group. IATA codes can be up to eight numeric characters. PCCs are three or four alphanumeric characters.

If Geographic or AgencyAndGeographic were used in the DistributionBasis above, Location defines the specific geography (countries, states/provinces, or cities) that can use this distribution group. Cities are three characters, and countries and states are two. However, states and provinces must contain the country code as well. For example, Massachusetts is USMA; the country code (US) and then the state code (MA).

Security specifies the access given to a distribution group. If no permissions are given, the location has view access only.

Update – Set to "true" to give agencies access in the Agency Private Fares product to copy the contract and change certain fields. This also allows agencies to view fares and rules in Galileo and Apollo from fare display. Set to "false" to deny agencies the permission to copy the contract.

Redistribution – Set to "true" to allow agencies to view fares and rules in Galileo and Apollo from fare display. Redistribution gives the same permission to other agencies having a business relationship with the agency named in the distribution list.

Sell – Set to "true" to allow agencies to view fares from a fare display and get a fare

<DistSecLevels>

<DistSecLevel>


<Security Update="false" Redistribute="false"

Sell="true" Ticket="true"/>

</DistSecLevel>

<DistSecLevel>


<Security Update="true" Redistribute="true"

Sell="false" Ticket="false"/>

</DistSecLevel>

</DistSecLevels>



quote in Galileo and Apollo. Note: Apollo and Worldspan do not differentiate between Sell and Ticket. If an agency/geography is given Sell authority, it can both sell and ticket.


Ends the request. </Distribution>

</RequestElement>

</APF_DistributionRQ>

Response

The Success response indicates a successful upload of the distribution group to the APF server.


<ns3:APF_DistributionRS xmlns=”http://www.opentravel.org/OTA/2003/05”



<ns2:Distribution>

<ns2:DistributionName>QXCRE1</ns2:DistributionName>

<ns2:Success />

</ns3:Distribution>




Creating a Master Distribution Group Example



The following request creates a master global distribution group. Master global distribution groups differ

from global distribution groups in the following ways:

Master global distribution groups can contain other master distribution groups and distribution

groups.

Master global distribution groups are not GDS specific. Rather, GDS information is maintained at

the distribution group level.

Master distribution groups security levels and distribution basis are maintained that the

distribution group level.

To see an example of a request that creates a contract-specific master distribution group, see Standard

Contract Example 4 (page 72).

Request



Explanation Code



<APF_DistributionRQ

xmlns="http://agencyprivatefares.galileo.com/200

6A/XAPF"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-

instance"

xsi:schemaLocation="http://agencyprivatefares.ga

lileo.com/2006A/XAPF APF_DistributionRQ.xsd"

Version="1.00">

RequestElement contains the information for one master distribution group. Multiple RequestElements can be submitted in a single request.






<RequestElement>

<Source

xmlns=”http://www.opentravel.org/OTA/2003/0

5” PseudoCityCode="B0B">


ID_Context="XML">

<CompanyName

CompanyShortName="BHTRAVEL"


</RequestorID>

</Source>



The Distribution namespace is the APF XML location, including the version number.

Unlike in a distribution group request, the master distribution group create request does not contain a GDS value.


Create indicates that this is a new master global distribution group.

Update indicates it is an update to an existing master global distribution group and that all group information will be included in the request.

PartialUpdate indicates an update to an existing master global distribution group but that only the updated information will be sent in the request.

Delete indicated the distribution group will be deleted.

<Distribution

xmlns=”http://agencyprivatefares.galileo.co

m/2006A/XAPF/4.0” RequestType="Create">


<Name>QMSTR2INT2</Name>

The Group elements define the other master distribution groups or global distribution groups that are part of the master distribution group being created.

Note: The global distribution groups included in the request must already exist.

<Group>

<Name>QGLB1INT2</Name>

</Group>

<Group>


</Group>

<Group>


</Group>


</RequestElement>


Response






<ns2:Distribution>

<ns2:DistributionName>QMSTR2INT2</ns2:DistributionName>

<ns2:Success />

</ns3:Distribution>




Partial Updates of Global Distribution Groups Example

The partial update examples below modify the Global Distribution Group created in the Create

Distribution Group example (page 183). All responses are similar to the one given in the Create example;

therefore, the responses are not displayed on this page. For detailed information about each request

element, see Creating a Global Distribution Group. The following examples provide information related

to the partial update.

Example 1 adds an agency and permissions to the Global Distribution Group.

Example 2 modifies the permissions agency N18.

Example 3 deletes agency N18 from the Global Distribution Group.

Example 4 changes the distribution agency.

Example 1

The following request gives agency N18 permission to redistribute and sell but not update or ticket. For a

full description of each element, see Creating a Global Distribution Group.

Note: Elements and sub-elements in purple are required. In some cases, the sub-elements are only

required because the optional parent element is used.

Explanation Code



<APF_DistributionRQ


Version="1.00">

RequestElement contains the information for one distribution group.


<RequestElement>






</RequestorID>

</Source>

RequestType indicates the type of request.

<Distribution


GDS="1V" RequestType="PartialUpdate">

Name is the distribution group name being modified.

<Name>QXCRE1</Name>

DistSecLevels defines the agencies and associated security levels assigned to this distribution group. Each Global

<DistSecLevels>

<DistSecLevel ChangeAction="Create">


<Security Update="false" Redistribute="true"

Sell="true" Ticket="false"/>



Distribution Group must contain at least one security level.

In this example, a new security level is being added.

</DistSecLevel>

</DistSecLevels>

Agency ET6 is already defined for this Global Distribution Group with permission to update and redistribute. This request is modifying permissions to also allow agency ET6 to sell. The original security information is sent followed by a <Change> element, which defines the field being modified and the new value.

<DistSecLevels>

<DistSecLevel ChangeAction="Update">


<Security Update="true" Redistribute="true"

Sell="false" Ticket="false"/>

<Change Name="Sell" Action="Update"

OldValue="false" NewValue="true"/>

</Security>

</DistSecLevel>

</DistSecLevels>

</Distribution>

</RequestElement>


Example 2

The following request modifies the permissions of agency N18 so that the agency can also update. For a

full description of each element, see the Create Distribution Group (page 183) example.




<APF_DistributionRQ xmlns="http://agencyprivatefares.galileo.com/2006A/XAPF"

Version="1.00">

<RequestElement>




Code="1234567"/>

</RequestorID>

</Source>

<Distribution xmlns=”http://agencyprivatefares.galileo.com/2006A/XAPF/4.0”


<Name>QXCRE1</Name>

<DistSecLevels>



<Security Update="false" Redistribute="true" Sell="true"

Ticket="false"/>



<Change Name="Update" Action="Update" OldValue="false"

NewValue="true"/>

</Security>

</DistSecLevel>

</DistSecLevels>

</Distribution>

</RequestElement>


Example 3

The QXCRE1 Global Distribution Group allows agencies N18 and ET6 permissions. The following

request deletes agency N18 from the Global Distribution Group. Security levels must be deleted

separately. A Global Distribution Group must contain at least one security level in order to be processed.

For a full description of each element, see the Create Distribution Group example (page 183).





Version="1.00">

<RequestElement>




Code="1234567"/>

</RequestorID>

</Source>



<Name>QXCRE1</Name>

<DistSecLevels>

<DistSecLevel ChangeAction="Delete">


<Security Update="true" Redistribute="true" Sell="true"

Ticket="false"/>

</DistSecLevel>

</DistSecLevels>

</Distribution>

</RequestElement>


Example 4

The following request modifies the permissions of agency ET6 so that the agency can update, sell, and

ticket but cannot redistribute. For a full description of each element, see the Create Distribution Group

example (page 183).







Version="1.00">

<RequestElement>




Code="1234567"/>

</RequestorID>

</Source>



<Name>QXCRE1</Name>

<DistSecLevels>



<Security Update="true" Redistribute="true" Sell="true"

Ticket="false"/>

<Change Name="Ticket" Action="Update" OldValue="false"

NewValue="true"/>

<Change Name="Redistribute" Action="Update" OldValue="true"

NewValue="false"/>

</Security>

</DistSecLevel>

</DistSecLevels>

</Distribution>

</RequestElement>




Complete Update of a Global Distribution Group Example

The following request updates an existing Global Distribution Group. This update is a complete replace of

the existing Global Distribution Group, and it changes the N17 agency's access. When setting the

RequestType to Update, all information must be included in the request. To send only the information to

be updated, use a Partial Update request (page 189).

Request



Explanation Code



<APF_DistributionRQ


006A/XAPF" Version="1.00">

RequestElement contains the information for one global distribution group. Multiple RequestElements can be submitted in a single request.



Both CompanyShortName and Code are provided for the XML Vendor Licensee by Travelport, when the Licensee is provisioned, and both are used for billing purposes.


Code is the Galileo numeric identifier, is provided to the Licensee by Travelport, and is up to seven digits.

<RequestElement>

<Source

xmlns=”http://www.opentravel.org/OTA/200

3/05” PseudoCityCode="B0B">


ID_Context="XML">

<CompanyName



</RequestorID>

</Source>

GDS provides the computer reservation system. The values are as follows:

1G for Galileo

1V for Apollo

1P for Worldspan






<Distribution

xmlns=”http://agencyprivatefares.galileo

.com/2006A/XAPF/4.0” GDS="1V"


Name is the distribution group name (maximum of 50 characters). Alpha-numerics (A to Z, 0 to 9), full stop (.), slash (/), dash (-),colon (:), underscore (_), asterisk (*),

<Name>QXCRE1</Name>



apostrophe ('), and blank (space) are valid.



Agencies - Distribute the contract to specific agencies identified by PCC/SID or IATA number.

Geographic - Distribute the contract to all Travelport agencies within a geography.


<DistributionBasis Agencies="true"/>

DistSecLevels defines the agencies and associated security levels assigned to this distribution group. At least one security level must be assigned.

If Agencies or AgencyAndGeographic were used in the DistributionBasis above, Agency defines the specific travel agency code, Pseudo City Code (PCC), or Subscriber Identification (SID) that can use this distribution group. IATA codes can be up to eight numeric characters. PCCs are three or four alphanumeric characters. SIDs are three alpha, numeric, or alphanumeric characters.

If Geographic or AgencyAndGeographic were used in the DistributionBasis above, Location defines the specific geography (countries, states/provinces, or cities) that can use this distribution group. Cities are three characters, and countries and states are two. However, states and provinces must contain the country code as well. For example, Massachusetts is USMA; the country code (US) and then the state code (MA).

Security specifies the access given to a distribution group. If no permissions are given, the location has view access only.





<DistSecLevels>

<DistSecLevel>


<Security Update="false"

Redistribute="true" Sell="true"

Ticket="true"/>

</DistSecLevel>

<DistSecLevel>



Redistribute="true" Sell="false"

Ticket="false"/>

</DistSecLevel>

</DistSecLevels>


</RequestElement>




Response






<ns3:Distribution>

<ns2:DistributionName>QXCRE1</ns2:DistributionName>

<ns2:Success />

</ns3:Distribution>




Complete Update of a Master Distribution Group Example

The following request updates an existing Master Global Distribution Group. This update is a complete

replace of the existing Master Global Distribution Group. When setting the RequestType to Update, all

information must be included in the request. To send only the information to be updated, use a Partial

Update request.

Request



Explanation Code



<APF_DistributionRQ


006A/XAPF"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-

instance"

xsi:schemaLocation="http://agencyprivatefares.

galileo.com/2006A/XAPF APF_DistributionRQ.xsd"

Version="1.00">

RequestElement contains the information for one master global distribution group. Multiple RequestElements can be submitted in a single request.



Both CompanyShortName and Code are provided for the XML Vendor Licensee by Travelport, when the Licensee is provisioned, and both are used for billing purposes.


Code is the Galileo numeric identifier, is provided to the Licensee by Travelport, and is up to seven digits.

<RequestElement>

<Source

xmlns=”http://www.opentravel.org/OTA/200

3/05” PseudoCityCode="B0B">


ID_Context="XML">

<CompanyName



</RequestorID>

</Source>







<Distribution

xmlns=”http://agencyprivatefares.galileo

.com/2006A/XAPF/4.0”


Name is the distribution group name (maximum of 50 characters). Alpha-numerics (A to Z, 0 to 9), full stop (.), slash (/), dash (-),colon (:), underscore (_), asterisk (*),

<Name>QMSTR2INT2</Name>



apostrophe ('), and blank (space) are valid.

The Group elements define the other master distribution groups or global distribution groups that are part of the master distribution group being created.

Note: The global distribution groups included in the request must already exist.

<Group>


</Group>

<Group>


</Group>


</RequestElement>


Response






<ns3:Distribution>

<ns2:DistributionName>QMSTR2INT2</ns2:DistributionName>

<ns2:Success />

</ns3:Distribution>




Deleting a Global Distribution Group Example

Delete a Global Distribution Group by sending the APF_DistributionRQ request with the RequestType

set to "Delete". The <Name> must match an existing Global Distribution Group.

Request



Explanation Code



<APF_DistributionRQ


Version="1.00">

RequestElement contains the information for one Global Distribution Group. Multiple Global Distribution Group creations, deletions, and updates can be sent in a single request.





Code is the Galileo numeric identifier, is provided to the Licensee by Galileo, and is up to seven

<RequestElement>

<Source xmlns=”http://www.opentravel.org/OTA/2003/05”>




</RequestorID>

</Source>



digits.


RequestType indicates that this Global Distribution Group will be deleted.


<Distribution


RequestType="Delete">

<Name>TEST</Name>

</Distribution>

Ends the request. </RequestElement>


Response





<ns3:Distribution>

<ns2:DistributionName>TEST</ns2:DistributionName>

<ns2:Success />

</ns3:Distribution>




Zones

A zone is a collection of codes for cities, US states/ CA provinces, countries, or IATA areas that, when

grouped together, make for faster loading of private fare contracts. A zone usually consists of a logical

grouping of cities. For example, a contract that includes cities on the east coast of the United States might

have a zone called EASTUS that contains the three-letter codes for New York, Boston, Miami,

Washington, and Philadelphia. Instead of entering five three-letter codes in the <Zone> sub-element of

the <BaseFareGroup> element in the APF_ContractRQ request, enter the zone name.

Zones are created independently of fare contracts, which means that the EASTUS zone can be used in any

contract that is created by a specific agency. Every zone must have its own unique name and the name of

a zone cannot match the code for an existing state or province. For example, a zone may not be named

USCO because that is a valid state code for Colorado in the United States. A zone description should be

entered to provide a reminder of which cities or areas of the world are contained within the zone.

APF_ZoneRQ is a request that sends details about a zone, including whether to create, update, or delete

it, to APF for processing. A response is returned from APF with a success/error message depending on

whether the zone is successfully processed.

Working with Zones for Add-on Fares

A zone for an Add-on fare is a collection of codes for cities/airports that, when grouped together, make

for faster loading of Add-on fares. A zone usually consists of a logical grouping of cities. Add-on fares

can have Gateway and Interior cities and zones associated with them. A Gateway is the first point of

arrival or the last point of departure in a country or area. Interior refers to cities or zones that are the

ultimate origin or destination of the constructed fare.

Zones are created independently of Add-on fares, which means the zone can be used in any contract that

you build. Every Add-on zone you create must have its own unique name. You can enter a zone

description as a reminder of which cities are contained within the Add-on zone. In the example diagram

below, potential interior routes are designated with orange lines and potential gateway cites link with grey

lines representing possible Standard contract routes.

The cities in the diagram could be grouped into Gateway zones (e.g., WAS NYC BOS YTO) and Interior

zones (e.g., DEN SLC LAS YYC YEG and SEA SFO LAX in North America and MAD BCN AGP and

BER FRA MUC in Europe), which are structured similarly to Standard and Calculated contract zones.

They can have multiple cities, and in the case of Gateway zones, airports. Gateway zones are always



international points of departure or arrival, where two fares can connect. Interior zones are made up of

city codes only (no airport codes) and consist of interior points within a country or area. Gateway and

Interior zones can only be used on Add-on fares and can be reused indefinitely by any Add-on fares in

your supplier code. However, Gateway zones are not interchangeable with Interior zones, which means if

you want an Interior and a Gateway zone to have some or all of the same cities, you must create two

zones: one Interior and one Gateway.

Agency Private Fares uses the gateway city as match criteria to the origin/destination point on the

Standard Contract fare. A gateway/gateway zone that uses an airport code can only match to an airport

code and a city code can only match to a city code. The passenger must travel via the gateways filed on

the Add-on fare. All possible gateways must be included when the Add-on fare is built in order to

construct the fare and to define the allowable gateway the passenger may travel via. The APF product

allows the use of both cities and airports for Add-on fare creation but larger geographies such as countries

or areas cannot be used.

The following options are available for zones:

Creating Gateway and Interior Zones (page 205)

Editing Interior and Gateway Zones (page 208)

Deleting Interior and Gateway Zones (page 209)



Zone Requests

The SOAPBodyElement for Zones is called APF_ZoneRQ. It is a request to upload a zone to the APF

system. The Zone examples provide sample requests and responses.

SOAP Request







Following a blank line the XML SOAP payload begins. The APF server does not expect any data in the



Request

POST /XAPF HTTP/1.1

Accept-Language: en









<soap:Body>

APF_ZoneRQ

</soap:Body>

</soap:Envelope>

SOAP Responses


XML SOAP payload begins. XML for APF (XAPF) does not expect any data in the SOAP header

section, so it can be omitted. The SOAP body contains a single XML element, which is the XAPF

transaction response.

There are two types of response that can be sent for a request: Success or Failure. A successful response

may include warnings. A failure response always includes errors.



Successful Response

HTTP/1.1 200 OK



Content-Length: 777

Date: Wed, 12 Apr 2006 22:27:33 GMT

Connection: close



<soap:Body>

<ns3:APF_ZoneRS




<ns3:Zone>

<ns2:ZoneName>NewZone</ns2:ZoneName>

<ns2:Success/>

</ns3:Zone>

</ns3:APF_ZoneRS>

<soap:Body>

</soap:Envelope>

Failure Response

HTTP/1.1 200 OK



Content-Length: 777

Date: Wed, 12 Apr 2006 22:27:33 GMT

Connection: close



<soap:Body>

<ns3:APF_ZoneRS




<ns3:Zone>

<ns2:ZoneName>NewZone</ns2:ZoneName>

<ns2:Errors>

<ns1:Error Type="EWT" Code="10" Tag=”Zone”

xmlns:ns1="http://www.opentravel.org/OTA/2003/05">Zone Rejected – Missing Mandatory

Field</ns1:Error>

</ns2:Errors>

</ns3:Zone>

</ns3:APF_ZoneRS>

<soap:Body>



</soap:Envelope>



Creating a Zone



The APF_ZoneRQ is used to create interior zones, gateway zones, and contract zones. Multiple zones can

be created in a single request.

The following example creates two zones: a contract zone and a gateway zone.

The contract zone is named WCOAST1, which includes the cities Seattle and Anchorage, the

states Washington, Oregon, California, the province British Columbia, and area AR1. The

contract zone excludes the cities San Francisco and San Jose and the countries Costa Rica,

Mexico, and Guatemala.

The gateway zone is named WCOAST2, which includes the cities Seattle, Anchorage, and

Portland.

Request



Explanation Code

Defines the namespace for the APF_ZoneRQ and the version of the XAPF schema.


<APF_ZoneRQ

xmlns="http://agencyprivatefares.galileo.com/2006A

/XAPF" Version="1.00">






<RequestElement>

<Source




ID_Context="XML">

<CompanyName



</RequestorID>

</Source>

The Zone namespace is the APF XML location, including the version number.

Zone Name provides the name; a unique identifier for the zone. The zone name can be four to eight alphanumeric characters.

Type indicates the zone type that is being created.

<Zone

xmlns=”http://agencyprivatefares.galileo.com/

2006A/XAPF/4.0” Name="WCOAST1"

Type="Contract" RequestType="Create">

<Description>US and Canada west coast

zone</Description>



Contract

Interior

Gateway

For more information about gateway and interior zones, see Working with Zones for Add-on Fares.

Request Type indicates which action should be taken with the zone. The values are Create, Update, and Delete.

Description is a text-only field that is used for reference and searches.

Include defines the cities, states/provinces, countries, and areas that are included in the zone. At least one of the following must be included in the request, and the elements must be sent in the order presented:

Cities defines the city codes in the zone. It accepts three alpha characters per city and uses spaces to delineate between cities (e.g., DEN PAR LON etc.), up to a maximum of 125 values.

Countries defines the countries in the zone. It accepts two alpha characters, up to a maximum of 166 values.

USCA defines the state/province codes in the zone. It accepts four alpha characters per state/province and uses spaces to delineate between states/provinces (e.g., USCO, USCA, CAAB, CABC, etc.), up to a maximum of 125 values.

Areas is three alphanumeric characters and allows you to enter areas in the zone. You can enter a maximum of 3 values in this field.

Exclude defines the cities, states/provinces, and countries to exclude from the zone. Exclude values must be sent in order of Cities, Countries, then USCA.

Notes:

Airport codes are not valid entries.

If NYC is included in a Gateway zone, NYC includes LGA, JFK, and EWR. However, EWR can also be named separately in a Gateway zone.

A zone with EWR can only be used in a North American contract. If a zone with EWR is attached to any contract other than one which is wholly within North America, the fare will not quote.

Puerto Rico and U.S.Virgin Islands are not entered as countries. These locations must be entered as U.S. states; USPR for Puerto Rico and USVI for Virgin Islands.

<Include>

<Cities>SEA ANC</Cities>

<USCA>USWA USOR USCA CABC</USCA>

<Areas>AR1</Areas>

</Include>

<Exclude>

<Cities>SFO SJC</Cities>

<Countries>CR MX GT</Countries>

</Exclude>

</Zone>

</RequestElement>

A second zone can be created in the same request. Note that the source does not have to be identical to the first zone request.

The zone created in this RequestElement is a gateway zone.

<RequestElement>

<Source






ID_Context="XML">

<CompanyName



</RequestorID>

</Source>

<Zone

xmlns=”http://agencyprivatefares.galileo.com/

2006A/XAPF/4.0” Name="WCOAST2" Type="Gateway"


<Description>US and Canada west coast

gateway zone</Description>

<Include>

<Cities>SEA ANC PDX</Cities>

</Include>

</Zone>

</RequestElement>

Ends the request. </APF_ZoneRQ>

Response

The Success response indicates a successful upload of the zone to the APF server.





<ns3:Zone>


<ns2:Success />

</ns3:Zone>

<ns3:Zone>


<ns2:Success />

</ns3:Zone>

</ns3:APF_ZoneRS>



Updating a Zone

You can update an existing Gateway or Interior zone. When you edit a Gateway or Interior zone, it does

not affect any Add-on fares which have the zone in use. To apply zone changes to Add-on fares that use

the zone, send an update request to the Add-on fare with the zone information included.

To modify an existing zone, you can either send a total replace or a partial update by setting

RequestType to one of the following:

Update – Indicates that the request is a total replace that contains ALL the elements and sub-

elements that are required. If certain elements or sub-elements are not required, they can be left

out of the update request. All other information sent in the request must be identical except for

the information to be updated. See the Creating a Zone example (page 205) for sample code.

PartialUpdate – Indicates that the request is a partial update. Send the source information, zone

name, and only those element and sub-elements that are being modified. For more information,

see Partial Update of a Zone (page 208).

Ensure the <Name> sent in either update request is the same as the <Name> of the existing zone.

Updating Zone Information in an Associated Add-on

When you edit a Gateway or Interior zone, it does not affect any Add-on fares which have the zone in

use. To apply zone changes to an Add-on fare that uses that zone, send an Add-on request with a zone

update element. The following sample code causes the Add-on fare to update the zone USWEST.


<APF_AddonRQ xmlns="http://agencyprivatefares.galileo.com/2006A/XAPF"

Version="1.00">

<RequestElement>




Code="1234567"/>

</RequestorID>

</Source>

<Addon xmlns=”http://agencyprivatefares.galileo.com/2006A/XAPF/4.0”



<AirlineCode>F9</AirlineCode>


<GatewayZone ChangeAction="Update">

<ZoneName>USWEST</ZoneName>

<Change Name="ImportNewVersion" Action="Update" OldValue="false"

NewValue="true"/>

</GatewayZone>


</Addon>

</RequestElement>

</APF_AddonRQ>



Deleting a Zone

Delete a zone by sending the APF_ZoneRQ request with the RequestType set to "Delete". The

<Name> must match an existing zone.

Note: When a zone is deleted, it is removed from the database. You cannot recover it; it must be re-

created, if you require it.

Request

In the following example, a request is sent to delete the USWEST zone. Elements and sub-elements in

purple are required. In some cases, the sub-elements are only required because the optional parent

element is used.

Explanation Code

Defines the namespace for the APF_ZoneRQ and the version of the XAPF schema.


<APF_ZoneRQ

xmlns="http://agencyprivatefares.galileo.com/2006A/X

APF" Version="1.00">

Provides requestor details. The Source namespace is OTA.

Type is ignored by XAPF, but required for schema compliance. Because no definition exists for providers of airline fare data, use 18 to indicate "Other".





<RequestElement>

<Source




ID_Context="XML">

<CompanyName



</RequestorID>

</Source>

The Zone namespace is the APF XML location, including the version number.

Zone Name provides the name; a unique identifier for the zone. In a delete request, the name must match an existing zone name.

Type indicates the zone type that is being deleted.

Contract

Interior

Gateway

Request Type indicates which action should be taken with the zone: Create, Update, Delete.

Note: When a zone is deleted, iIt is removed from the database. You cannot recover it; it must be re-created, if you require it.

<Zone

xmlns=”http://agencyprivatefares.galileo.com/2006A/X

APF/4.0” Name="USWEST" Type="Gateway"

RequestType="Delete" />



Ends the request. </RequestElement>

</APF_ZoneRQ>

Response





<ns3:Zone>

<ns2:ZoneName>USWEST</ns2:ZoneName>

<ns2:Success/>

</ns3:Zone>

</ns3:APF_ZoneRS>



List of Examples

The APF XML Web Service help contains many example XML requests that highlight the product's

functionality.

Example Description

Contract Examples


Creates a single net and selling, international contract that uses a global distribution group, ticketing details and selling levels, seasons, days of the week, reservation ticket time limits, min and max stays, blackout dates, flight rules, code shares, stopovers, combinations, surcharges, discounts, and rules.


Creates a calculated contract with the minimum viable elements.


Updates the contract created in Calculated Contract Example 2.


Creates a single selling, international contract that uses a contract-specific distribution group, ticketing details and selling levels, seasons, days of the week, reservation ticket time limits, min and max stays, blackout dates, flight rules, code shares, stopovers, combinations, surcharges, discounts, transfers, and rules.


This example contains multiple contracts within a single request:

Updates one net and selling, North American contract that uses a contract-specific distribution group, ticketing details and selling levels, and transfers.

Creates one selling, international contract that uses a contract-specific distribution group, ticketing details and selling levels, and stopovers.


Creates a single selling, international contract that permits add-on fare construction and uses a global distribution group and transfers.

Note: This contract is used in conjunction with the create add-on fare example.


Creates a single net and selling, North American contract that uses master distribution groups and ticketing details and selling levels.


Creates a single net and selling, international contract that uses a global distribution group, airpasses, fare family, and discounts.


Create a single contract for a round-the-world trip.

Partial Update of a Standard Contract (page 148)

Partially updates the standard contract created in example 1 by only updating the transfers defined in example 1.

Partial Update of a Calculated Contract (page 150)

This example contains the minimum viable elements required to partially update an existing Calculated contract.

Discontinuing a Contract (page 153)

Discontinues an active contract.



Add-on Fare Examples

Create an Add-on Fare (page 168)

This example creates an add-on fare that constructs with the standard contract created in example 3.

Partially Update an Add-on Fare (page 175)

Partially updates the add-on fares created in the example above.

Discontinue an Add-on Fare (page 177)

Discontinues an add-on fare.

Global Distribution Groups

Create a Global Distribution Group (page 183)

Creates a global distribution group that can be used by two agencies, each with different access rights.

Create a Master Global Distribution Group (page 187)

Update a Global Distribution Group (page 193)

Updates a global distribution group.

Update a Master Global Distribution Group (page 196)

Updates a master distribution group.

Partially Update a Global Distribution Group (page 189)

Contains four partial update examples of an existing global distribution group.

Delete a Global Distribution Group (page 198)

Delete a global distribution group. The same request is used for both master global and global distribution groups.

Zones

Create a Zone (page 205)

Creates a contract zone and a gateway zone.

Partially Update a Zone (page 208)

Partially updates a zone.

Delete a Zone (page 209)

Deletes a zone. When a zone is deleted, it is removed from the database and cannot be recovered.



Error Messages

There are four types of error messages that are returned by the APF XML Web Service Interface:

General Messages – Apply to contract, Global Distribution Group, and zone requests.

Contract Messages – Apply specifically to contract requests.

Global Distribution Group Messages – Apply specifically to Global Distribution Group

requests.

Zone Messages – Apply specifically to zone requests.

General Error Messages

This page contains the errors messages that may be returned in a response.

1-100 : General errors are defined by the OTA Code Table “Error Warning Type”.

500-599 : XML APF-specific errors

Condition Message Return Code

If the supplier code, user ID, and password do not pass, the request is rejected. OTA Error 4 "Authentication".

Request Rejected - Invalid User ID or Password.

4

If the user ID and password are not authorized for the XML interface, the request is rejected. OTA error 6 "Authorization".

Request Rejected - User not Authorized.

6

If a required element or attribute is missing, the request is rejected. OTA Error 10 "Required field missing".

Request Rejected - Missing Mandatory Field.

NOTE: Field name is in attribute "Tag" of element "Error"

10

Database error. Database error 50

XAPF encounters an unexpected error in validating a user ID/password.

Unexpected authentication error. 51

This general error message is returned from the Addon Converter if no more specific message is applied.

Unexpected exception while working on Addon.

51

Occurs when more than one user is trying to update the same contract, add-on, zone, or distribution group at the same time.

User request in progress. 52

If this message displays, try to resubmit the request. If the error occurs again, call the service center.

System Error 500


Application Error. Unable to display error message for key '{0}'

500



This error displays when the request is validated against the schema and a problem occurs. This error also returns information about the problem, such as invalid length, invalid character, required element is missing. Correct the request and resubmit.

Marshal exception: 500

For each request, the ID should be unique for each Create. To modify an existing contract, add-on, distribution group, or zone, send an update request.

Entity to be created ({0}) already exists. An update request must be used.

500

The request that was submitted did not contain the required information.

{0} in {1} is required. 500

Verify that the request contains the required information.

Could not find {0} in type {1}. 500


Unknown application error ({0}). Please contact support if you are unable to proceed.

500

The ID/Name submitted in the update, partial update, or delete request could not be found. Verify that the correct name was entered.

Object to be changed could not be found {0}

500



Messages for Contracts

Range 101 - 199 is allocated for errors with contracts.

101-109 : Create/Update problems with contract keys.

110-119 : Contract-specific problems.

150-159 : Missing or invalid fields.


If the request is to add a new contract, and the keys (Supplier code and contract ID) are already present in APF, a response message is sent.

This Contract is a Duplicate of an Existing Contract. Send New Contract ID or Indicate Contract is for a Change”

101

If the request is to change an existing contract, the keys (Supplier code and contract ID) must match an existing contract. If the keys do not match an existing contract, the response message is sent.

Change Rejected. No Matching Contract Found.

102

If the contract does not contain at least one fare group (mandatory for a minimal viable contract), the contract is rejected.

Contract Rejected – At Least One Fare Group is Required.

110

If the contract does not contain at least one distribution item (mandatory for a minimal viable contract), the contract is rejected.

Contract Rejected - Contract Must Contain at Least One Distribution Group.

111

For calculated fares, a fare by rule tariff number is not allowed.

Fare By Rule Tariff Number Not Allowed.

112

If an attempt is made to update an existing contract, and the contract is locked (meaning the contract is in the process of being updated via APF or is in a non-committed state), a response is returned.

Unable to Change - Contract Locked.

113

If a contract request specifies a user-defined zone, and that zone name is not contained in the APF system, a response message is sent.

Contract Rejected - User Defined Zone Name Cannot Be Found.

114

This error message occurs when a calculated contract with multiple fare groups is sent and the calcfare rules indicating whether airline rules should apply are not the same for all of the fare groups.

Fare group ticket rules are not the same for all fare groups.

115

When the data in the contract is validated against the contract tables, if the contract is rejected, a message is sent indicating the field that caused the rejection and the data contained in the field.

Contract Has Been Rejected. Invalid Field Contents XXXX.

NOTE: Values for XXXX can be carrier code, city code, passenger type code, currency/country code.

150



NOTE: Field name is in attribute "Tag" of element "Error".

When specifying an <AddonRule> within a contract, the values are:

FBC

FT

RuleIDandFBC

RuleIDandFT

ALL

Invalid addon rule.

150

When specifying a CommissionOverride within TicketDetail, Commission2 cannot occur without first defining Commission1.

Commission currency 1 must be used before currency 2.

150

When specifying two commission currencies, the currencies must be different. Commission currencies are defined within the TicketDetail element.

Both commission currencies for Ticket Detail cannot be the same.

150

This message displays when the contract is North American and/or Calculated and AddonConstructionOptions are set to Permitted or Required.

Addon rule is not permitted. 150

This message displays when the value of the AddonConstructionOptions is something other than Required, NotPermitted or Permitted.

Invalid addon construction. 150

When specifying an increase percentage (<IncreasePct>) within a SellingLevel, the percentage value must be greater than zero.

Percent increase must be greater than 0.

150

The request did not include the minimum required fields. See the schema or the examples within the help to determine required fields.

Please fill in all required fields 150

When defining an exception within TicketDetailAndSellingLevels, only one exception can be selected for the entire contract (either Fare Basis Code (FBC) or Fare Family).

The same exception type must be used throughout the contract.

150

This message displays when the Contract ID is null.

Field Rule ID required 150

In TicketDetail, if Commission=Calculate, Percentage is not valid.

Commission percentage for Ticket Detail is invalid when Commission Type is 'Calculate'.

150

In Combinations, the OutsideContract rule ID must be defined and cannot be the same rule ID as the current contract.

Outside Contract rule ID must be specified and cannot be the same as this contract's rule ID.

150

If multiple Surcharges are defined, the StandardSurchargeExempt value should be

Standard Surcharge Exemption 150



the same for each Surcharge. should be the same for all {0}.

This error occurs when the TktTimeLimit permission value does not match the sub-element. For example, the following code would produce this error:

<TktTimeLimit

Permission="EARLIEST">

<AfterReservation...>

</TktTimeLimit>

'AfterReservation' is invalid for the given permission type.

150

In Distribution, TicketRules must be set to U (use specified FBC / Fare Family and amount) if FareAmount is specified.

Fare box amount not allowed when 'TicketRules' is not 'U'.

150

In Distribution, when TicketFare is used, TicketRules is required. TicketRules values are:





TicketRules is required when TicketFare is used.

150

In Distribution, TicketRules cannot be set to U when <TicketFare UseYYFare="true">.

TicketRules value 'U' not allowed when UseYYFare is selected.

150

Ensure that the airline code entered for the following is a valid:

Contract's <AirlineCode>

Addon's <AirlineCode>

Addon's <PermittedAirlines> airline codes

Carrier is required and must be an existing carrier.

150

Within Combinations, ensure that each <OJTrip OJTripType> uses the same open jaw type.

Only one open jaw type permitted per contract.

150

In BaseFareGroup, ensure that the zones can be used with addon fares.

One or more Zones contains locations other than cities. The following Zones cannot be used when Addon construction is permitted: {0}

150

This message displays if a value for Rule is sent without a BeforeReservation or AfterDeparture value. For example, the following would produce this error:

<ResTktTimeLimit>

<ResTimeLimit

'Rule' is invalid for the given input. 150




<DayOfWeek>1</DayOfWeek>

</ResTimeLimit>

<TktTimeLimit Rule="EARLIEST"

Permission="Latest">

</TktTimeLimit>

</ResTktTimeLimit>

When creating a standard, non-North American contract, From is the only valid direction (located in BaseFareGroup).

{0}, Invalid direction, only direction valid for non-North American contracts is 'From'.

150

The specified zone does not exist. Ensure that the zone name is entered correctly. To use a zone in a contract, create the zone first, then create the contract that uses that zone.

{0} zone code entered does not exist: {1}

150



Messages for Add-ons

Range 401 – 499 is allocated for errors with Add-on requests.

401-409 : Create/Update problems with Add-on keys.

410-419 : Add-on fare-specific problems.



Add-ons must have a unique combination of Add-on ID, supplier code, and airline code. This error code is returned when a create Add-on request contains the same combination of Add-on ID, supplier code, and airline code as an existing Add-on.

Change Addon Rule ID and/ or Airline Code to avoid a duplicate.

401

This error displays if one user has an Add-on open for edit and another user attempts to send an update request. Unlike contracts, Add-ons are not locked during edit.

This Addon fare has been modified by another user since editing began. Please update your changes in the latest Addon version.

401

This error displays when the Add-on being saved matches an Add-on in the database. Ensure that the update request contains a modification to the current Add-on.

This Addon has not been modified, please use cancel if not modifying addon.

401

Each AddonID must be unique within a supplier code. To modify an existing Add-on, send an Update request.

This Addon ID is a duplicate of an existing (active or historical) Addon ID.

401

This error occurs when an Add-on Update request is submitted with an AddonID that does not exist.

No matching Add-ons found. 402

The InteriorZone submitted does not exist. To use a zone, first create the zone, then create an Add-on using that zone.

Interior Zone entered does not exist: {0}

414

The GatewayZone submitted does not exist. To use a zone, first create a zone, then create an Add-on using that zone.

Gateway Zone entered does not exist: {0}

414

The request should contain at least one GatewayCitiesAirports or one GatewayZone.

At least one of GatewayCitiesAirports or GatewayZone is required.

450

This message displays if an Add-on zone contains an invalid city code.

Invalid {0} Cities (no Airports) '{1}' (3 alphabetic characters)

450

Ensure that a DiscontinueDate is included. The Discontinued date is required and must contain a valid date in the format of (DDMMMYY).

450

Within a supplier code, each AddonID in a Addon Create Rejected. Addon 450



create request must be unique. Modify the request with a different AddonID or AirlineCode.

Name, Airline Code and Supplier Code Combination Already Exist.

This message displays if an Add-on zone contains an invalid city or airport code.

Invalid {0} Cities/Airports '{1}' (3 alphabetic characters)

450

Ensure that the DiscontinueDate value is equal to or later than the effective date.

Discontinue Date must be later than or equal to the Effective Date.

450

There can only be one gateway zone; however, a gateway zone can contain up to 10 cities/airports. Ensure that the gateway zone included in the request has 10 or fewer cities/airports.

A Gateway Zone can have a maximum of {0} Cities/Airports.

450

Gateway zones that are defined with an <Exclude> cannot be used with an Add-on fare. Gateway zones can only contain cities/airports.

Exclusions are not allowed in a Gateway zone.

450

This message displays if the gateway zone sent does not include any cities or airports.

Must specify at least one Include Cities/Airports

450

When sending an update request, the AddonID must match an existing Add-on ID.

Addon Update Rejected. Addon Name Cannot be Found.

450

When sending a create request, the AddonID must be unique for the given supplier code and carrier. AddonID must be four alpha, numeric, or alpha and numeric characters. No special characters or blanks are allowed.

Required Addon ID length 4, and unique within supplier and carrier

450

The zone sent in the request must have at least one <Include> <Cities> defined.

Must specify at least one Include City (no Airports)

450

City codes must be used when specifying interior zones. Airport codes cannot be used for interior zones.

{0} is an airport. Airports are not allowed for Interior zones.

450

This message displays if a geography larger than a city is submitted in an Add-on zone.

{0} Zone must only have cities. 450

Within LinkCriteria, if FareTypeOrFBC is used, then one FareType or FareBasisCode must be defined.

At least one of FareBasisCode or FareType is required.

450

AddonID must be four alpha, numeric, or alpha and numeric characters. No special characters or blanks are allowed.

Field Addon ID contains invalid character(s)

450

Ensure that the interior city code entered is correct.

Interior City code entered does not exist: {0}

450

The request should contain at least one InteriorCities or one InteriorZone.

At least one of InteriorCities or InteriorZone is required.

450

Ensure that the gateway city or airport code Gateway City/Airport code entered 450



entered is correct. does not exist: {0}

Ensure that the gateway city or airport code entered is correct.

Gateway City/Airport code entered does not exist

450



Messages for Global Distribution Groups

Range 301 – 399 is allocated for errors with Global Distribution Groups.

301-309 : Create/Update problems with Global Distribution Group keys.

310-319 : Global Distribution Group-specific problems.



If the message is to add a Global Distribution Group, determine if the Global Distribution Group name already exists in the APF system.

The global distribution group name may already be assigned to a Global Distribution Group entered via the XML interface or directly via the APF product.

If the Global Distribution Group name exists, a message is returned.

Global Distribution Group Create Rejected – Global Distribution Group Name and Supplier Code Combination Already Exists.

301

If the message is to edit an existing Global Distribution Group and the Global Distribution Group name does not exist, indicating that the name is wrong, or that the group does not exist, a message is returned.

Global Distribution Group Edit Rejected – Global Distribution Group Name Cannot Be Found.

302

If the message is to delete an existing Global Distribution Group, the header must indicate to delete. If the Global Distribution Group name cannot be found in the APF database, a message is returned.

Global Distribution Group Delete Rejected – Global Distribution Group Name Cannot Be Found.

303

When the data in the Global Distribution Group is validated against the Distribution Group tables, if the Global Distribution Group is rejected, a message is sent indicating the field that caused the rejection and the data contained in the field.

Distribution Group Has Been Rejected. Invalid Field Contents XXXX.

NOTE: Values for XXXX can be city code, country code or IATA zone.

NOTE: Field name is in attribute “Tag” of element “Error”.

350

When <DistributionBasis Agencies="true">, only <Agency> is allowed in <DistSecLevel>. Locations cannot be defined.

Only agencies are allowed for the selected Distribution Basis.

350

When <DistributionBasis Geographic="true">, only <Location> is allowed in <DistSecLevel>. Agencies cannot be defined.

Only location information is allowed for the selected Distribution Basis.

350

When <DistributionBasis Both agency and location are 350



AgencyAndGeographic="true">, both <Location> and <Agency> must be defined.

required for the selected Distribution Basis.

When <DistributionBasis AllAgencies="true">, no Location or Agency should be defined.

No agency or location information is allowed for the selected Distribution Basis.

350



Messages for Zones

Range 201 – 299 is allocated for errors with zones.

201-209 : Create/Update problems with zone keys

210-219 : Zone-specific problems.



If the message is to add a user zone, determine if the user zone name already exists in the APF system.

The user zone name may already be assigned to a user zone entered via the XML interface or directly via the APF product.

If the user zone name exists, a message is returned.

Zone Create Rejected – Zone Name and Supplier Code Combination Already Exists.

{0} zone name and Supplier code combination already exists in the database.

201

If the message is to edit an existing zone name and the zone name does not exist, a message is returned.

Zone Edit Rejected – Zone Name Cannot Be Found.

202

If the message is to delete an existing zone, the header must indicate to delete. If the zone name cannot be found in the APF database, a message is returned.

If the message is to delete an existing zone, the header must indicate delete. If the zone name cannot be found on the APF database, return response. Zone Delete Rejected – Zone Name Cannot be Found.

203

When the data in the zone is validated against the zone tables, if the zone is rejected, a message is sent indicating the field that caused the rejection and the data contained in the field.

Zone Has Been Rejected. Invalid Field Contents XXXX.

NOTE: Values for XXXX can be carrier code, city code, passenger type code, currency/country code.

NOTE: Field name is in attribute “Tag” of element “Error”.

250



Disclaimer

Travelport provides the materials in this help system on an "as is" and "as available" basis, and makes no

representations or warranties as to the accuracy, completeness, or quality of these materials, nor that they

will meet any of your particular needs or objectives. Furthermore, code samples in this help system are

provided as a development resource for demonstrative purposes and are not intended to be used on

production Web Sites or for learning how to build a travel Web Site in general. Travelport disclaims any

warranties implied by law, and reserves the right to change these materials without notice. Your use of

these materials is at your own risk, and is governed by the terms of your Agency Private Fares

Deployment Agreement and/or Non-Disclosure Agreement, as applicable.

Agency Private Fares XML Interface Web Service - … · Agency Private Fares XML Interface Web Service Version 4.0 ... 160 SOAP Request ... associated rules are extracted to the Galileo

Documents