Travelport Selective Access User Guide

Selective Access
User Guide
Version 4.0
Contents
Module 1: Introduction ............................................................................................................ 7
Prerequisites ................................................................................................................... 7
Housekeeping ................................................................................................................. 7
Course Length................................................................................................................. 7
Course Materials ............................................................................................................. 8
Course Objectives ........................................................................................................... 8
What is Selective Access™ ............................................................................................. 8
Features and Concepts ................................................................................................... 8
Other Options for Sharing Information ............................................................................. 9
Group Coding ............................................................................................................ 9
Consolidator .............................................................................................................. 9
Ad-hoc Data Sharing ................................................................................................. 9
Summary ................................................................................................................. 10
Module 2: Getting Started...................................................................................................... 11
Module Objectives ......................................................................................................... 11
Security ......................................................................................................................... 11
Providers and Requesters ............................................................................................. 12
How it Works ........................................................................................................... 12
Shared Information .................................................................................................. 12
Business Relationships ................................................................................................. 13
Business Relationships Between Two Individual Agencies ...................................... 13
Business Relationships Between Members of an Affiliate ........................................ 13
Buisiness Relationships Between Two Affiliates ...................................................... 14
Buisiness Relationships Between an Affiliate and an Individual Agency .................. 14
Selective Access™ Files ............................................................................................... 14
Agreement File ........................................................................................................ 15
Customiser File ....................................................................................................... 15
Permission File ........................................................................................................ 15
Affiliate File .............................................................................................................. 16
Summary....................................................................................................................... 16
Module Review.............................................................................................................. 17
Module 3: The Agreement File .............................................................................................. 18
Overview ....................................................................................................................... 18
Displaying the Entire Agreement File ............................................................................ 19
Displaying a Specific Agreement ................................................................................... 20
By Agreement Number ............................................................................................ 20
By Fill-in-Format ...................................................................................................... 23
Displaying Multiple Agreements .................................................................................... 24
Module Review.............................................................................................................. 25
Module 4: The Permission File .............................................................................................. 26
Overview ....................................................................................................................... 26
Displaying ..................................................................................................................... 27
The Entire Permission File....................................................................................... 27
Specific Agreements................................................................................................ 30
Adding an Agreement.................................................................................................... 31
Changing an Agreement ............................................................................................... 32
Deleting ......................................................................................................................... 33
An Individual Agreement.......................................................................................... 33
All Agreements ........................................................................................................ 34
Displaying History ......................................................................................................... 35
Module Review.............................................................................................................. 37
Module 5: The Affiliate File .................................................................................................... 39
Overview ....................................................................................................................... 39
Displaying ..................................................................................................................... 40
A List of Affiliate Files .............................................................................................. 40
An Individual Affiliate File......................................................................................... 41
Summary of Agreements ......................................................................................... 42
The Affiliate Members Section ....................................................................................... 44
Designating Headquarters ....................................................................................... 44
Building the Affiliate Members Section..................................................................... 46
Adding a Member .................................................................................................... 47
Deleting a Member .................................................................................................. 47
Changing a Description ........................................................................................... 48
Deleting the Entire Affiliate ...................................................................................... 49
The Authorisation Section ............................................................................................. 50
Agreement Between Members of the Same Affiliate ................................................ 50
Agreement with Another Affiliate.............................................................................. 52
Agreement with an Individual Agency ...................................................................... 53
Changing the Authorisation Section ......................................................................... 53
Special Affiliate Processing (SAP) ................................................................................. 56
SAP Table ............................................................................................................... 56
Adding ..................................................................................................................... 58
Replacing ................................................................................................................ 60
Deleting ................................................................................................................... 62
Cancelling ............................................................................................................... 63
Supervisory Message Queue .................................................................................. 64
Displaying History .................................................................................................... 67
Module Review.............................................................................................................. 69
Module 6: The Customiser File ............................................................................................. 73
Overview ....................................................................................................................... 73
Displaying ..................................................................................................................... 74
A List of Customiser Files ........................................................................................ 74
An Individual Customiser ......................................................................................... 75
Customiser Form ..................................................................................................... 78
Building a Customiser ................................................................................................... 79
Basic Section........................................................................................................... 79
Function Section ...................................................................................................... 80
Adding to a Customiser ................................................................................................. 84
Changing Customiser Fields ......................................................................................... 85
Deleting ......................................................................................................................... 85
Field(s) Within a Customiser .................................................................................... 86
An Entire Customiser File ........................................................................................ 87
All Customiser files .................................................................................................. 88
Module Review.............................................................................................................. 91
Appendix A: Step-by-Step Procedures................................................................................. 96
Between Two Individual Agencies ................................................................................. 96
Setting Up an Agreement ........................................................................................ 97
Deleting an Agreement ............................................................................................ 98
Between Members of an Affiliate ................................................................................... 99
Setting Up an Agreement ........................................................................................ 99
Adding a Member .................................................................................................. 102
Deleting a Member ................................................................................................ 103
Changing an Agreement ........................................................................................ 104
Deleting an Agreement .......................................................................................... 105
Between Two Affiliates ................................................................................................ 106
Setting Up an Agreement ...................................................................................... 106
Adding a Member .................................................................................................. 109
Between an Affiliate and an Individual Agency ............................................................ 112
Appendix B: Flowchart Procedures .....................................................................................115
Between Two Individual Agencies ............................................................................... 116
Between Members of an Affiliate ................................................................................. 118
Adding a Member .................................................................................................. 119
Changing an Agreement Number .......................................................................... 121
Between Two Affiliates ................................................................................................ 123
Adding an Agreement ............................................................................................ 123
Adding a Member .................................................................................................. 124
Between an Affiliate and an Individual Agency ............................................................ 127
Appendix C: Agreements with Apollo ® Agencies ...............................................................129
Features and Benefits – Switchable Access and Global Access™ .............................. 129
Switchable Access ...................................................................................................... 130
Retrieving a PNR in Apollo®................................................................................... 130
Global Access™.......................................................................................................... 130
Booking File Servicing ........................................................................................... 131
Global Information Area ......................................................................................... 132
Global Booking File Header Identification .............................................................. 135
Queues.................................................................................................................. 136
Global MIR ............................................................................................................ 136
Step-by-Step Procedures ............................................................................................ 136
Switchable Access................................................................................................. 137
Global Selective Access ........................................................................................ 138
Receiving Global MIRs .......................................................................................... 145
Apollo Formats ............................................................................................................ 148
Appendix D: Troubleshooting ..............................................................................................149
Affiliate Questions ....................................................................................................... 149
Can an HQ be HQ of more than one Affiliate ......................................................... 149
Does the HQ have to be in the Affiliate .................................................................. 149
Can just one Agency be in an Affiliate ................................................................... 149
Can an Agency be in more than one Affiliate ......................................................... 149
Error Responses ......................................................................................................... 150
Appendix E: Worksheets and Entries ..................................................................................157
Customiser File Worksheet ......................................................................................... 158
Affiliate File Worksheet................................................................................................ 159
Authorisation Section............................................................................................. 159
Members Section .................................................................................................. 159
Entry List ..................................................................................................................... 160
Agreement File ...................................................................................................... 160
Customisers .......................................................................................................... 160
Permission File ...................................................................................................... 161
Affiliate File ............................................................................................................ 161
Deautomation of Selective Access™ ..................................................................... 162
Appendix F: Answer Key ......................................................................................................163
Module 2: Getting Started........................................................................................... 163
Module 3: The Agreement File ................................................................................... 164
Module 4: The Permission File ................................................................................... 165
Part 1..................................................................................................................... 165
Part 2..................................................................................................................... 165
Module 5: The Affiliate File ......................................................................................... 166
Adding an Agreement Between Members of the Same Affiliate ............................. 166
Adding an Agreement Between Two Affiliates ....................................................... 167
Module 6: The Customiser File ................................................................................... 168
Adding an Agreement Between Two Individual Agencies ...................................... 168
Appendix G: Consolidator Information ...............................................................................169
Consolidator Set-up..................................................................................................... 169
Originating Agency Functions ................................................................................ 169
Queuing a Booking File to a Consolidator ................................................................... 170
Specify Change Of Booking File Ownership To The Consolidator ......................... 170
Queuing a Message to a Consolidator......................................................................... 171
Consolidator Agency Functions ................................................................................... 171
Retrieving Booking Files from Queue .................................................................... 171
Re-queuing a Retrieved Booking File .................................................................... 172
Accessing Message Queues ................................................................................. 172
Queuing a Message to an Agency ......................................................................... 172
Consolidator Functionality Enhancement .................................................................... 173
Overview ............................................................................................................... 173
Customer Benefit ................................................................................................... 173
Set Up/Security ..................................................................................................... 174
Security ................................................................................................................. 179
New Descriptive Banner ........................................................................................ 179
Fares and Ticketing Data Masking ........................................................................ 181
Consolidator Display.............................................................................................. 188
Sub-agent Display ................................................................................................. 190
Sub-agent B Display .............................................................................................. 193
Sub-agent A Display .............................................................................................. 196
New Galileo Formats ................................................................................................... 200
Agent Alerts ........................................................................................................... 201
Enhancement Assumptions ................................................................................... 202
New Qualified Notepad Field ................................................................................. 202
New Fares entry to display taxes only ................................................................... 202
Data masking for Manual Fare data ....................................................................... 204
Module 1: Introduction
Welcome to Selective Access™. This course explains how you
can provide other agencies on the Galileo ® and Apollo® systems
with access to your agency’s functions, such as Booking Files,
Client Files and PrivateFares™.
This course shows you how to set up and maintain Selective

Access™ business relationships with other agencies. The modules
in this course cover the information and procedures needed to
create successful Selective Access™ relationships. You will learn
how to share the customer information your business partners
need, without compromising your other customers.
Prerequisites
To attend this course you:
Must be able to build and retrieve a Booking File.
Have a good knowledge of the Galileo ® central system.
Housekeeping
The following should be noted:
 Fire exits
 Toilets
 Smoking policy
 Breaks
 Communication
 Mobile phones
Course Length
The schedule is as follows:
Day 1 Modules 1 – 5
Day 2 am Revision – Appendix A and B
Module 6
Day 2 pm Evaluation
Selective Access 7
Course Materials
The Selective Access™ Course Book provides an area to take
notes, write down entries and complete exercises. It is designed
to be used as a learning tool during class. Once you have
completed the Selective Access class, use this course book as a
reference guide back at your office.
Course Objectives
Upon completion of this course, you will be able to:
 Describe how Selective Access™ benefits an agency.
 Display and interpret the agreement file.
 Update and add agreements to the permission file.
 Build and process customiser files.
 Interpret an affiliate file and add basic affiliate agreements.
What is Selective Access™

The Selective Access™ product allows you to provide service to
your customers no matter where they go – all over the country or
throughout the world. You designate other Galileo® and/or Apollo®
agencies who will be allowed to update your customer’s Booking
Files.
You decide exactly which customer information and functions the

other agencies need to access. For example, you can permit
another agency to display and update specific Booking Files, while
denying access to Booking Files for your customers who are not
travelling to that destination.
Features and Concepts

Listed below are some of the important features and concepts of
Selective Access™.
Relationships may be between one or numerous agents.
Relationships may be between Galileo® and Apollo® users.
You may customise the agreement by giving access to only certain
functionality.
You may allow only certain individual agents in that office (pseudo)
to service your customer’s bookings.
8 Selective Access
Other Options for Sharing Information

Before deciding exactly what business relationship you require
with an agency or agencies you should consider the other Galileo ®
sharing mechanisms.
Group Coding
Group coding is primarily designed to link together individual

agencies who are branches of the same company or organisation.
Agencies sharing the same group code number are permitted to

access each other’s data, including Booking Files, Client Files,
queues and message queues.
Group coding is predominantly used by multi-branch agencies.
Consolidator
This functionality allows communication between agencies and a

consolidator, regardless of the fact that they may have separate
group codes, or be part of a Selective Access network.
The originating agent creates a Booking File and queues it to the

consolidator’s “queuing city”. Once actioned, the Booking File
may be returned to the originating agency, or ownership may be
assumed by the consolidator (depending on the queuing input by
the originating agency).
Ad-hoc Data Sharing
Ad-hoc data sharing allows two agencies to share Booking File

data for the purposes of ticketing.
The ad-hoc agency may set up a business agreement with a

Selective Access agency, or with a non-Selective Access agency.
If an agency is group coded, it may set up an ad-hoc data sharing

agreement with another agency, without affecting its group coding.
The non-ticketing agency is required to communicate the Booking

File record locator to the ticketing agency, in order for them to be
able to retrieve it.
Selective Access 9
Summary
The following table suggests when you would want to use each of
the different sharing mechanisms.
Use Selective Use group coding: Use consolidator: Use ad-hoc data sharing:
Access™:
With other Apollo and With other Galileo With a designated With a designated Galileo
Galileo agencies agencies only Galileo agency set-up agency set-up as an ad-
as a consolidator hoc agent
To allow access to To allow access to To allow an agency to To allow a ticketing agency
information between any information between queue a Booking File to to retrieve a Booking File
agencies – branches or branches of an agency. a consolidator who belonging to a non-ticketing
separate agencies. provides special fare agency for ticketing
and/or travel services, purposes, outside any
and who may issue group coding.
tickets on their behalf.
To give another agency To give another agency To give another agency To give another agency
access to all your access to all your access to Booking File access to Booking File
information or access to information. information only. information only.
certain functions, but not
others.
10 Selective Access
Module 2: Getting Started
Before you set up Selective Access™ agreements, you need to

decide which information to share and what types of business
relationships to establish with your branches or other agencies. In
addition, you need to know about the types of Selective Access™
files and how they work together.
Module Objectives
Upon completion of this module you will be able to:
 Identify security implications.
 Describe the differences between a provider and a requester.
 Choose the applicable business relationship for your needs.
 Give an overview of the different types of Selective Access™
files.
Security
The OTH AUTH field on the first page of the STD profile
determines whether Selective Access™ functionality may be
performed.
The fourth character in this field must be set to Y:
Points to note:
You will not be able to see this field if all characters are set to N.
However, you can see it once one of the characters is set to Y.
You do not have to be a secondary authoriser.
Selective Access 11
Providers and Requesters

In every Selective Access™ relationship there is a “provider and a
“requseter”
 The provider is the agency that grants the other agency access
to its functions. They provide information.
 The requester is the agency that is granted access to the other
agency’s functions. They request information.
How it Works
The provider selects a pre-set agreement, indicating exactly which

functions they will allow the requester to access. In order for
Selective Access™ to work, there must be an agreement in each
direction. In other words, each agency acts as a provider, as well
as a requester. In some cases both agencies select the same
agreement and give each other access to the same types of
information; in other cases, each agency selects different
agreements.
Example:
An agency in Dublin may require an agency in Rome to service

Booking Files for a group of pilgrims travelling from Ireland to Italy.
The Irish agency could give the Italian agency agreement number
15, which allows the Italian agency to access the Booking Files for
the Irish group members.
The Italian agency does not require any reciprocal servicing from
the Irish agency, so they would give the Irish agency agreement
number 10, which does not allow any functionality.
Shared Information
Selective Access™ allows you to provide information and request

access associated with the following products:
 Booking Files
 Client Files
 Queues
 Document production
 MIRs
 PrivateFares™
 Custom Check™
12 Selective Access
Business Relationships
Selective Access™ can be established between individual
agencies or groups of agencies, which are referred to as affiliates.
There are four types of Selective Access business relationships.
The following is a list of these relationships and examples of each.
Business Relationships Between Two Individual Agencies
When a Galileo® or Apollo® agency sets up a Selective Access™

relationship with any other Apollo or Galileo agency, they form the
simplest type of Selective Access™ relationship. This may be
done as a short-term or long-term relationship.
Example: – Short term relationship
An example of a short-term relationship is an agency that sends a

large number of customers to the Olympics. They require a local
representative who can tend to last minute changes and ticket
reissues once the customers arrive at their destination.
Example: – Long term relationship
A long-term relationship can be established for an agency in

Sydney that has a corporate account with offices in Sydney and
Canberra. Since executive officers frequently travel from Sydney
to Canberra, the agency sets up a Selective Access relationship
with an agency in Canberra that provides service to executives
when necessary.
Business Relationships Between Members of an Affiliate
When there are several agencies or branches of one agency that

need to have the same relationship with each other, they can form
an affiliate.
Example:
An example of a relationship between members of an affiliate is

one where branches of one agency decide to give full access to
their Booking Files to each other, and allow them to display and
move information from Client Files. But they decide not to allow
the other affiliate members to build, change, or delete Client Files
of other affiliate members.
Selective Access 13
Buisiness Relationships Between Two Affiliates
When one group of agencies needs to do business with another

group of agencies, each group forms an affiliate. The two affiliates
set up a Selective Access™ relationship with each other.
Example:
An example of this arrangement is an affiliate of United Kingdom

agents who send frequent tour groups to South Africa. An agency
with branches throughout South Africa forms an affiliate to provide
service to the tour groups when they visit the various South African
cities.
Buisiness Relationships Between an Affiliate and an Individual Agency
When a group of agencies need to do business with one agency,

they can form an affiliate.
Example:
An example of this arrangement is a twenty-four hour agency that

contracts with a group of agencies to handle evening and
weekend phone calls. The affiliate gives the twenty-four hour
agency access to Booking Files, Client Files, queuing, and
PrivateFares™ accounts.
Selective Access™ Files

Selective Access™ consists of the following four files:
 Agreement file
 Customiser file
 Permission file
 Affiliate file
14 Selective Access
Agreement File
Galileo International builds and maintains the agreement file.
The agreement file is a list of pre-set agreements. An agreement

is a list of functions, (e.g. updating Booking Files, Client Files,
PrivateFares™, etc.) that a provider allows a requester to access.
The functions accessible for each agreement are different to those

of any other agreement. Galileo International has already set up
agreements for the most typical Selective Access™ business
relationships.
Customiser File
The provider builds and maintains the customiser file.
The customiser file allows the provider to take an agreement and

customise it.
Example:
The selected agreement may allow the requester to display,

update, and queue the provider’s Booking Files. The provider may
designate on the customiser file, which Booking Files the
requester may work with, and which queue the Booking Files
should be routed to. Each provider may have several customiser
files.
Note: Use of the customiser file is optional.
Permission File
The provider builds and maintains the permission file.
The permission file defines the business relationship between the

provider and requester. It specifies the requester, the agreement
number and customiser, and effective dates. Each provider has
one permission file, but can list several business relationships on
it.
Selective Access 15
Affiliate File
The headquarters of an affiliate builds and maintains the affiliate

file.
It lists the members of the affiliate and the agreements it has with
requesters. Every time the affiliate file is updated, the
headquarters runs Special Affiliate Processing, which updates all
affiliate member’s permission files with the updated information on
the affiliate file.
Summary
The following summarises the business relationships, Selective
Access™ files and steps you could follow when setting up
Selective Access™.
Type: Description:
Business relationships There are 4 main relationships which can exist between:
- Two individual agencies.
- Individual members of a group (affiliate)
- The members to two groups (affiliates)
- The members of a group (affiliate) and individual agency
Selective Access™ files The 4 main files are:
- Agreement file which details the pre-set functions.
- Customiser file which allows the provider to limit the functionality of the
agreement.
- Permission file which is a record of all the provider’s agreements.
- Affiliate file which lists the affiliate members and all the agreements that the
affiliate has with other pseudos.
Steps to set-up Selective The process will vary for each set-up, but these are the general steps:
Access™ 1. Determine what type of business relationship you need to form.
2. Determine what information and functions you need the other agency or
affiliate to access.
3. Select the appropriate agreement from the agreement file.
4. Customise the agreement, if you need to refine it, using the customiser file.
5. Set up the affiliate file, if a group of agencies is involved.
6. Set up the permission file.
16 Selective Access
Module Review
Using your course book, write down the answers to the following questions.
1. Do you have to be a secondary authoriser to perform Selective Access™ functionality?
2. The STD profile is set as below. Can the user perform Selective Access™ functionality?
a. Yes
b. No
3. An agency is both the provider and requester.

a. True
b. False
4. Your agency is part of a multi-national chain. Your individual agency is sending a group of
customers to Rio de Janeiro on business. You require an agency in Rio to service your
customers requirements. What type of a business relationship is this?
5. Which type of Selective Access™ file would you display if you wanted to check whether you had
already given a particular pseudo an agreement?
Selective Access 17
Module 3: The Agreement File
The agreement file is a table built by Galileo ®, which lists a variety

of agreements that might be required in a business relationship.
Before putting business relationships into effect, you must decide
which agreement number you are going to provide to the other
agency (requester).
Module Objectives
 Describe which functions the agreement file controls.
 Display the entire agreement file.
 Display a specific agreement.
 Display multiple agreements.
Overview
Each agreement has been assigned a number and consists of a
list of possible functions that you may wish to provide to the
requester.
You can allow or deny the requester access to the following

functions:
 Displaying, updating, and creating Booking Files
 Queuing Booking Files at end transact
 Displaying, printing, updating, creating, and removing business
and personal Client Files / PRO-files
 Displaying and updating agency files
 Sending and accepting queued Booking Files and supervisory
messages
 Issuing documents from Booking Files
 Sending Global MIRs
 Displaying and using PrivateFares™ accounts
 Building and removing Custom Check™ rules
Selective Access 18
Points to note:
The provider agency selects the number of the agreement they
wish to provide to the requester.
When Selective Access™ links two agencies, it is necessary to
have an agreement in each direction, but not necessarily the
same agreement number.
A fill-in format is provided in the system to assist the search for an
agreement.
If a particular agreement is required by an agency, but is not
shown in the table, a request can be made to your helpdesk to
add the required agreement to the table.
Selective AccessTM agreement file formats begin with:
PAAGR
Displaying the Entire Agreement File

The entire agreement file is a summary of all agreements at-a-
glance.
When to use
Display this file to quickly check what is allowed for each individual
agreement.
How to use
To display the entire agreement file:
PAAGR*
Response:
2 3 4 5 6 7 8 9 10
Selective Access 19
Screen description:
Callout: Function Description:

heading:
1 NBR Agreement numbers. These can be between 0001 and

9999. Not all of these numbers have been used.
2 BF Booking File functions
3 CF Client File functions
4 MAR Agency file functions
5 QEB Queuing Booking Files
6 QES Queuing supervisory messages
7 DOC Document production
8 GLB MIR capabilities
9 PVT PrivateFares™
10 RUL Custom Check™ functions
Displaying a Specific Agreement

By displaying a specific agreement, you can focus on the exact
functions permitted for that agreement without viewing other
agreements that do not apply.
There are two ways to display a specific agreement:

 By agreement number(s)
 By agreement functions using the fill-in-format
By Agreement Number
When you display an individual agreement, the headings which

used initials in the entire agreement file display, e.g. BF D for
Booking File display, use longer abbreviations in the specific
agreement display, BF DIS. Thus making the agreement easier to
read.
When to use
Use this format when you already know the agreement number
you want to view.
20 Selective Access
How to use
To display a specific agreement by agreement number:
PAAGR*/1
Response:
Screen description
Booking File functions
A provider may give a requester access to the following Booking

File functions.
Function Y indicates requester may: N indicates requester may not:

heading:
BF DIS Display provider’s Booking Files.

BF UPD Update and end transact provider’s Booking Files.
BF CRE Create Booking Files on behalf of provider.
Note: At end transact, the requester types E/XXX. (XXX is
provider’s pseudo city code.)
BF QET Programmatically place provider’s Booking File on one of the
provider’s queues at end transact.
Points to note:
 The default is queue 1, unless otherwise specified in the
customiser file.
 If QEB/xxx/99 is entered, the Booking File will only fall on Q99,
not Q1.
Selective Access 21
Client File functions
A provider may give a requester access to the following Client File

Plus™ functions.
heading:
CF DIS Display and move from provider’s business and personal files.
CF PRT Print provider’s business and personal files.
CF UPD Update provider’s business and personal files.
CF CRE Create business and personal files for the provider.
CF RMV Delete the provider’s business and personal files.
MAR DIS Display and move provider’s agency file.
MAR UPD Update provider’s agency file.
Note: For all Client File Plus™ and TravelScreen™ functions, the
requester must have the appropriate authorisation in their STD
profile and the requesting agency must be set-up correctly.
Queue functions
A provider may give a requester access to the following queue

functions.
Function Y indicates provider may: N indicates provider may not:

Heading:
QEB IN Accept queued Booking Files from the requester.

QEB OUT Queue Booking Files out to requester.
QES IN Accept supervisory messages from requester.
QES OUT Send supervisory messages to requester.
Other functions
A provider may give a requester access to the following other

functions.

heading:
DOC PRD Issue documents from provider’s Booking Files.

GBL MIR Send a MIR to the provider.
PVT FAR View and use provider’s PrivateFares™ accounts.
RUL BLD Build a Custom Check™ rule for provider.
RUL RMV Delete a Custom Check™ rule for provider.
22 Selective Access
By Fill-in-Format
Displaying an agreement by functions allows you to complete the

fill-in-format screen by tabbing through the options and entering Y
or N.
Note: Ensure your INS (insert key) is off when completing this
screen, otherwise the tabs will be out of place and the agreement
will not display.
When to use
Use this option when you know the functions you want the
requester to access. It allows you to find a matching agreement.
How to use
To display a specific agreement by agreement functions, follow

these steps.
1. Display the fill-in-format:
PAAGRF
Response:
2. Tab to each field and indicate whether access is allowed, as

follows:
To allow access to the function, type Y.
 To not allow access to the function, type N.
3. After completing all fields, place the cursor to the right of the
RUL RMV tab and press Enter.
4. Determine whether an agreement exists based on these
responses:
 If a matching agreement exists, the agreement displays.
 If a matching agreement does not exist, an agent alert
displays. Call the helpdesk / customer service support
center to have the new agreement added.
Selective Access 23
Displaying Multiple Agreements

It is possible to display, on the same screen, up to 10 specific
agreements with one entry.
When to use
This can be useful when normally the agreements would not

display on the same screen and you wish to compare the
functionality offered by each.
How to use
To display multiple agreements:
PAAGR*/29-31+2+55
Response:
Note: There is no warning if you have selected an agreement,

which does not exist.
24 Selective Access
Module Review
®
Using your course book and/or the Galileo system, write down the answers to the following
questions.
1. What is the entry to display agreement 18.
a. Does this agreement allow the requester to update the provider’s Booking Files?
b. Can the requester display the provider’s agency file?
c. Can the provider queue Booking Files to the requester?
2. Display only agreements 1 and 2 in order to compare them.
a. In which way do the agreements differ?
_____________________________________________________________________________
_
3. What does agreement 10 allow?
4. Find an agreement where the provider will only allow the requester to display a Client File, queue
bookings between the provider and requester (QEB in and out), and the provider will allow the
requester to use their PrivateFares™.
Selective Access 25
Module 4: The Permission File
The provider builds and maintains the permission file. Each

agency has one permission file, which contains the details of all
agreements that the provider has with requester agencies. In
order to activate a business relationship through Selective
Access™, both parties must set up an agreement with each other
in their respective permission files.
Points to note:
This module refers to Galileo® agents forming agreements with
other Galileo agents. For details regarding Galileo ® agents
forming agreements with Apollo® agents, see Appendix C:
Agreements with Apollo® Agencies.
For a list of entries, display the Selective Access™ help pages:
H/PAPE.
Module Objectives
Upon completion of this module you will be able to perform the
following permission file functions:
 Display, add, change and delete agreements in the permission
file
 Display the history
Overview
The permission file contains:
The requester’s pseudo city code and optional agency description
The agreement number and optional customiser code
Optional effective and discontinue dates
The headquarter’s pseudo city code and affiliate code, if the
requester is an affiliate member
Selective Access™ permission file formats begin with the

identifier:
PAPER
Selective Access 26
Displaying
You can display:
 The entire permission file
 Specific agreements by pseudo city code
The Entire Permission File
The entire permission file is a list of all the agreements that you
have with other agencies. To see all agreements it may be
necessary to move down (MD) through the various screens.
When to use
Display the entire permission file when you wish to see a list of all
the Selective Access™ agreements you have given to requester
agencies.
How to use
To display the permission file:
PAPER*
Response – first screen
1
2
Selective Access 27
First screen description:
Item: Screen: Description:
1 PERMISSION DISPLAY: EA7 This permission display shows the agreements that EA7 has
given to other requesting agencies.
2 PSEUDO CITY The permission file displays the pseudos in the following order:
- Galileo®, alphabetically then numerically
- Apollo®, alphabetically then numerically
®
Note: 1V precedes Apollo pseudos.
AGR NBR Agreement number given to the requester
CUSTOMIZER IDENTIFIER A 2-letter code here indicates that the agreement has been
customised.
EFFECTIVE DATE Begin date for agreement.
DISCONTINUE DATE End date for agreement. If OPEN, infinity is assumed.
3 DZ2, BAHRAIN TRAVEL, 1 EA7 has given DZ2 agreement number 1.
X3N/MIDEA DZ2 is in an affiliate called MIDEA of which X3N is the
headquarters.
th
The agreement is effective from 14 June.
4 XC3, PARIS TRAVEL, 2 EA7 has given XC3 agreement number 2.
EA7/EUROP XC3 is in an affiliate called EUROP of which EA7 is the
headquarters.
The agreement is effective from 14th June
5 XF8, 1 EA7 has given XF8 agreement number 1.
The agreement is effective from 23rd June.
6 XN9, DUBAI TRAVEL, 1 EA7 has given XN9 agreement number 1.
XN9 is also (see DZ2) in an affiliate called MIDEA of which X3N
is the headquarters.
The agreement is effective from 14th June.
Continued on next page
28 Selective Access
How to use (Cont.)
Response – second screen after moving down:
10
11
12
Second screen description:
Callout: Screen response: Description:
7 39CC, ATHENS TRAVEL, 2 EA7 has given 39CC agreement number 2.

EA7/EUROP 39CC is in an affiliate called EUROP of which EA7 is the
headquarters.
8 XX8, 49 EA7 has given XX8 agreement number 49.
9 XX9, ZURICH TRAVEL, 2 EA7 has given XX9 agreement number 2.
EA7/EUROP XX9 is in an affiliate called EUROP of which EA7 is the
headquarters.
10 X3M, ESSO IMPLANT, 49 EA7 has given agreement number 49 to X3M.
EA7/ES However, it will not be all the functionality in agreement 49 as
the agreement has been customised by the customiser file ES.
ES was created by EA7 (as EA7 is before the 2-letter
customiser file code).
The agreement is effective from 16th June 2000 to 31st
December 2001.
11 39CD, ADHOC TRAVEL, 100 EA7 has given 39CD agreement number 100. 39CD is an ad-
hoc agent who will perform ticketing functions on behalf of EA7.
12 1V-JT9, 67, APOLLO TRAVEL EA7 has given agreement number 67 to Apollo (1V) agency
JT9.
Selective Access 29
Specific Agreements
Rather than display the entire permission file, you can display a
specific agreement with one agency.
When to use
Display an agreement with a specific agency when you only need

to focus on that one agreement. This could save you time by not
having to move down and down through the permission file.
How to use
To display an agreement for a specific agency:
PAPER*/XX8
Response:
30 Selective Access
Adding an Agreement
There is no build format for the permission file. The permission file
is created the first time your agency adds an agreement. Once the
agreement is in place both ways access to data and functions can
begin.
When to use
Add an agreement to your permission file when you have decided

what to allow the requester to do and any relevant customiser files
have been built.
How to use
To add an agreement:
PAPERA/X3M@ESSO
IMPLANT/49/ES/EFF16JUN00/DIS31DEC02
Mandatory items:
Primary Access PERmission
Add, X3M
Agreement 49
Optional items:
ESSO IMPLANT (agency name)
ES (2-letter customiser code for Esso as defined by agent)
EFFective date if in the future. If same day as entering agreement,
leave EFF out
DIScontinue date. If OPEN is required, leave out DIS.
The system responds with an asterisk (*).
Note: To see this agreement in the permission file, you will need
to display the permission file.
Selective Access 31
Changing an Agreement
The only field in a permission file, which may be changed, is the
agency name. To change any other field in an agreement, delete
the agreement and then add it with the updated information.
When to use
Use the change entry when you wish to amend the agency’s
name.
How to use
To change the agency requester’s name:
PAPERC/X3M@SHELL IMPLANT
Primary Access Permission Change
Note: To see the change in the permission file, you will need to
display the permission file.
32 Selective Access
Deleting
You can delete:
One agreement
All agreements (the entire permission file)
An Individual Agreement
There is no warning when you delete a pseudo from your

permission file. However, details will remain in the history.
When to use
There are two main reasons to delete an agreement.

 You can delete an agreement to terminate a business
relationship with another agency.
 You can delete an agreement when you need to change one
or more of the fields in that agreement. After deleting the
agreement, you can add it again with the updated information.
How to use
To delete an agency’s pseudo:
PAPERD/X3M
Primary Access Permission Delete
Selective Access 33
All Agreements
By deleting all agreements from your permission file you are also
deleting the history.
Warning! Use this format with caution. Once these files are
deleted, they cannot be restored.
When to use
Delete all agreements if your agency is now part of a different

chain and none of the agreements are valid.
How to use
Follow these steps to delete all agreements from your permission

file.
1. Type the following format and press Enter.
PADELD/PER
Primary Access Delete Delete Indicator, Permision Files
Response:
2. To confirm deletion, tab and press Enter.

Note: To ignore deletion, clear the screen by pressing
CTRL+S.
34 Selective Access
Displaying History
Permission file history is maintained for 30 days. As per normal,
the most recent history items are at the top of the display.
You can display the history for:

All agreements
One agreement
When to use
You can check history to see what recent changes have been
made and who made them.
How to use
To display permission file history for all agreements:
PAPERH
Primary Access Permission History
To display the permission file history for one agreement:
PAPERH/X3M
Response:
1
2
Selective Access 35
Screen description:
Item: Response: Description:
1 PERMISSION HISTORY: Display title

EA7 Provider’s pseudo city code
X3M Individual pseudo for whom the history was requested.
Note: No pseudo here indicates that the history has been
requested for the whole permission file.
2 CREATED-14JUN00 Date the permission file was created, i.e. date the first
agreement was added.
BY- EA7/009141 6 Pseudo city and agent sign-on plus check digit of creator.
3 DEL History code:
ADD Denotes an addition
CHG Denotes a change
DEL Denotes a deletion
REP Denotes replacement (via Special Affiliate Processing)
AGY Item affected:
AGY Agency name
PER Permission file
Translation Agreement 49, effective 30 Jun 00 – 31 Dec 01, customised
with ES, given to X3M Shell Implant, was deleted on 27 June
at 2006 GMT (Z).
The one entry, PAPERD/X3M, created the two DEL history
entries.
4 Translation There was a change to the agency name which used to be
ESSO IMPLANT
5 Translation Agreement 49, effective 30 Jun 00 – 31 Dec 01, customised
with ES, given to X3M Shell Implant, was added on 27 June at
2001 GMT (Z).
The one entry, PAPERA/X3M@ESSO
IMPLANT/49/ES/EFF30JUN00/DIS31DEC01, created the two
ADD history entries.
36 Selective Access
Module Review
This exercise will enable you to practice setting up a Selective Access™ agreement, servicing
another agency’s Booking File and using their Client Files. Emulate the pseudo on your card and
write down the entries you used where appropriate.
Part 1
1. Agreement details
Set up an agreement with your neighbour. You are to provide each other with the same facilities,
which are:
 Booking File display
 Booking File update
 Client File display
 MAR display
 QEB in and out
2. Permission file
When you have located this agreement, add it to your permission file. The agreement should
come into effect immediately, and terminate at the end of the year.
Booking File Servicing
Create a simple Booking File with return flights, AK status. Make a note of the locator.
Assume your customer has now travelled the first part of their journey and whilst abroad visits
your neighbour’s agency and wishes to change the return date to a day later.
Retrieve your neighbour’s Booking File by record locator (as this would be on the ticket), change
the date and queue it back to the owning agency (QEB/xxx).
Notice what queue the Booking File falls on. _________________________________________
Client Files
Display your neighbour’s agency file: C*xxx/
3. Ignore the Booking File and delete the agreement ____________________________________
Selective Access 37
Part 2
1. Now set up a new agreement with your neighbour. You are to provide each other with Booking
File display only and add this to your permission file.
2. Retrieve your neighbour’s Booking File again by locator. Can you update it?
3. Can you display and move your neighbour’s agency file?
4. Delete the agreement.
38 Selective Access
Module 5: The Affiliate File
An affiliate is formed when a group of agencies, having common
commercial interests, come together to form a business alliance.
An affiliate file must be created to specify the detail of the

agreement that the affiliate group has among its own members.
Subsequent agreements may be added to this affiliate file if the
affiliate group sets up Selective Access™ agreements with other
affiliate groups or with individual agencies.
Module Objectives
 Interpret and describe the items in an affiliate file
 Add and delete pseudos from the affiliate file members section
 Add agreements to the affiliate file authorisation section
 Display affiliate file history
 Perform Special Affiliate Processing (SAP)
Overview
The affiliate file is very similar to a permission file and contains:
The pseudo city codes of the members of the affiliate
The detail of the agreement that the affiliate group has among its
own members
The detail of agreements that have been given to other affiliate
groups and individual agencies
Points to note:
An affiliate file is given a unique mandatory affiliate file code
(minimum one, maximum five alpha/numeric characters) and an
optional descriptive name (maximum 25 alpha/numeric
characters).
There is no limit to the number of agencies who may form an
affiliate.
One agency from each affiliate group is designated as the
headquarters of the affiliate. This headquarters must:
build and maintain the affiliate file.
build any required customiser file for the affiliate.
transfer the agreement details into the permission file of each
member of the affiliate by means of Special Affiliate Processing.
There are two sections to an affiliate file:
the members section, formats begin with: PAAFF
the agreement section, formats begin with: PAATH
Selective Access 39
Displaying
You can display:
 A list of affiliate files
 One affiliate file
A List of Affiliate Files
You may display a list of all affiliate files that you have built and
control in your pseudo, i.e. you are the headquarters for each of
these affiliate files.
When to use
Display a list of affiliate files when you wish to review the affiliate
file names and descriptions.
How to use
To display the list:
PAAFF*
Input: Description:
PAAFF* Primary Access AFFiliate display
Response:
Screen description:
This display is a two-column list of all affiliate codes and

descriptions created by headquarters pseudo city EA7, e.g.
EUROP is the name of the EUROPEAN TRAVEL affiliate.
EUR24 is the name of the EUROP 24 HOUR affiliate.
40 Selective Access
An Individual Affiliate File
You may display the detail in an individual affiliate file.
When to use
Display an individual affiliate file when you wish to check:

Any of the agreement details that have been given by the affiliate
(as the provider) to other affiliates or pseudos (the requesters)
Who is actually in the affiliate, i.e. which pseudo cities are
members
How to use
To display the affiliate file:
PAAFF*@EUROP
Input: Description:
PAAFF* Primary Access AFFiliate display
@EUROP Mandatory @ followed by the name of the
affiliate.
Response:
1
2
Selective Access 41
Screen description:
Item: Screen response: Description:
1 AFFILIATE DISPLAY: EA7/EUROP The affiliate display is for headquarters EA7 and
affiliate name (or code) EUROP
2 AFFILIATE DESCRIPTION - EUROPEAN The description for the affiliate is EUROPEAN
TRAVEL TRAVEL
3 Authorisation section. The top part of this screen summarises all agreements that the EUROP
affiliate has given to other affiliates or pseudos.
There are three main types of agreements you will see in the authorisation section:
 Agreement between members of the same affiliate
 Agreement between the affiliate and another affiliate
 Agreement between the affiliate and an individual pseudo
®
Note: If the agreement was with an Apollo pseudo, you would see 1V before the pseudo.
EA7/EUROP 2 14JUN00 OPEN EA7/EUROP has given to its own members in
EA7/EUROP agreement 2.
– the agreement has not been customised
– the agreement is effective from 14JUN00
XX8 49 14JUN00 OPEN EA7/EUROP has given to individual pseudo
(XX8) agreement 49.
X3N/MIDEA 1 14JUN00 OPEN EA7/EUROP has given to another affiliate
called MIDEA (headquarters X3N) agreement 1.
4 Affiliate members section. The bottom part of the screen lists all the members (pseudo cities)
who are in the affiliate EUROP.
CRS CITY DESCRIPTION There are four Galileo members in this affiliate.
EA7 LONDON TRAVEL Note: If one of these pseudos was an Apollo
XC3 PARIS TRAVEL agent, under the CRS heading, you would see
39CC ATHENS TRAVEL 1V.
XX9 ZURICH TRAVEL
Summary of Agreements
The following diagram is a summary of what you could deduce

from the affiliate file EUROP.
Points to note:
You would not know which pseudos are in the affiliate MIDEA
unless you checked the permission file of one of EUROP’s
members.
You do not know which agreement number the affiliate pseudos of
MIDEA or the individual pseudo XX8, has given to the pseudos of
the EUROP affiliate.
42 Selective Access
EA7/EUROP
EA7
2 2
XX9 XC3
2 2
39CC
1
49
XX8
X3N/MIDEA
??? ???
??? ???
???
Selective Access 43
The Affiliate Members Section

The affiliate is built and maintained by the headquarters. The only
action required by the affiliate members is to designate the
headquarters. After this, no other action is required.
Caution! Prior to the Special Affiliate Processing (SAP), affiliate

members can be added and deleted with ease. For the correct
procedure after SAP, refer to Appendix A: Step-by-Step
Procedures and/or Appendix B: Flowchart Procedures.
Designating Headquarters
In each pseudo, the agency must designate the headquarters

pseudo of the affiliate of which they are a member.
With regard to the headquarters, individual pseudos may:

Designate, display and delete the headquarters
When to use
The individual pseudo must designate the headquarters prior to

the Special Affiliate Processing batch running. If they do not do
this, they will be left out when the agreements are entered in the
permission files for each member, i.e. their permission file will be
blank.
Points to note:
The pseudo who did not designate headquarters will still be ‘in’ all
the other members’ permission files.
An error message will appear on the supervisory queue of the
headquarters, informing them of which pseudo did not designate
them as headquarters.
A pseudo may only have one headquarters at a given time.
44 Selective Access
How to use
Designate headquarters
PAHDQA/EA7
Input: Description:
PAHDQA Primary Access Headquarters Add

/EA7 Designated headquarters pseudo
Display headquarters
PAHDQ*
Input: Description:
PAHDQ* Primary Access Headquarters Display
Response indicating which pseudo is the headquarters:
Delete headquarters
PAHDQD
Input: Description:
PAHDQD Primary Access Headquarters Delete
Selective Access 45
Building the Affiliate Members Section
The headquarters now builds the members section. If members

join later or are missed out on the initial build, their pseudo may be
added with ease providing the SAP has not run.
When to use
Build the affiliate members section when you have a group of

agencies who wish to share files with each other and with other
groups and individual agents.
How to use
Building the affiliate section
PAAFFB/EUROP@EUROPEAN TRAVEL/EA7@LONDON
TRAVEL+XC3@PARIS TRAVEL+39CC@ATHENS
TRAVEL+XX9@ZURICH TRAVEL
Input: Description:
PAAFFB Primary Access Affiliate Build

/EUROP@EUROPEA Maximum 5-letter affiliate code and
N TRAVEL optional affiliate description
/EA7@LONDON If the headquarters is a member of the
TRAVEL affiliate, enter the pseudo with optional
description first, so that it is not forgotten.
+XC3@PARIS Follow by pseudo and optional description
TRAVEL+39CC@ATH of all members, each linked by an end
ENS item.
TRAVEL+XX9@ZURI
CH TRAVEL
Note: A maximum of 47 pseudos can be included in the initial

build entry. Additional members must then be added.
46 Selective Access
Adding a Member
A member can be added with ease before the SAP and is

immediately reflected in the members section.
When to use
Add a member to the affiliate section when you have:

Omitted a pseudo
Exceeded the maximum amount of pseudos in the build entry
How to use
PAAFFA/EUROP/X90@COPENHAGEN TRAVEL
Input: Description:
PAAFFA Primary Access Affiliate Add

/EUROP Affiliate to which you wish to add the
member
/X90@COPENHAGE Pseudo and optional agency description
N TRAVEL
Deleting a Member
A member can be deleted with ease before SAP and will be

immediately deleted from the members section.
When to use
Delete a member when you have made an error inputting their

pseudo.
How to use
PAAFFD/EUROP/X90
Input: Description:
PAAFFD Primary Access Affiliate Delete
/EUROP Affiliate from which you wish to delete the
member
/X90 Pseudo that you are deleting (description
not required)
Selective Access 47
Changing a Description
The headquarters can change only the affiliate description and the
member description.
When to use
Change the description when you have made a typing error or

wish to add the description.
How to use
PAAFFC/EUROP@EUROP TRAVELS/XC3@VIENNA TRAVEL

Input: Description:
PAAFFC Primary Access Affiliate Change
/EUROP@EUROP Affiliate and new description
TRAVELS
/XC3@VIENNA Agency pseudo and new description
TRAVEL
48 Selective Access
Deleting the Entire Affiliate
An affiliate file can be deleted with ease before SAP.
When to use
Delete the affiliate when you no longer require it.
How to use
PAAFFD/EUROP
Input: Description:
PAAFFD Primary Access Affiliate Delete
/EUROP Affiliate to be deleted
Response:
To confirm deletion, Tab and Enter.
Selective Access 49
The Authorisation Section

Once the affiliate members section is built, the headquarters can
add the authorisation section, which can consist of three main
types of agreements:
Agreement between members of the same affiliate
Agreement between the affiliate and an individual pseudo
Agreement between the affiliate and another affiliate
Caution! Prior to the Special Affiliate Processing (SAP),

agreements can be added and deleted from the authorisation
section with ease. For the correct procedure after SAP, refer to
Appendix A: Step-by-Step Procedures and/or Appendix B:
Flowchart Procedures.
Agreement Between Members of the Same Affiliate
This would be an agreement between all the members in one

affiliate, e.g. EUROP. The members of the affiliate must decide
amongst themselves what level of functionality they will be
required to perform on each other’s Booking Files.
When to use
If all members of the affiliate wish to service each other’s

bookings, then you must provide and request an agreement.
An agreement must exist between the individual members of the

same affiliate otherwise they will be unable to service each other’s
bookings.
50 Selective Access
How to use
Adding the agreement:
PAATHA/EUROP/EA7@EUROP/2
Input: Description:
PAATHA Primary Access Authority Add

/EUROP Affiliate EUROP as the provider
/EA7@EUROP Affiliate EUROP as the requester
/2 Agreement number 2
Note: The pseudo for the requesting affiliate is mandatory. You

do not need to state who is the headquarters for EUROP as the
provider, as only the headquarters can make this entry. However,
you do need to state who you are giving it to, as you could be
giving it to another requester with a different headquarters, e.g.
X3N@MIDEA.
Deleting the agreement
PAATHD/EUROP/EA7@EUROP
Input: Description:
PAATHD Primary Access Authority Delete
/EA7@EUROP Affiliate EUROP as the requester
Selective Access 51
Agreement with Another Affiliate
This would be an agreement that one affiliate makes with another

affiliate. The providing affiliate decides what level of functionality
they will require the other affiliate to perform on their Booking
Files.
When to use
Provide an agreement to another affiliate when you need them to

service your bookings for a set amount of time or indefinitely.
An agreement must exist between the affiliates otherwise you will

be unable to service each other’s bookings.
How to use
Adding the agreement
PAATHA/EUROP/X3N@MIDEA/1
Input: Description:

/X3N@MIDEA Affiliate MIDEA as the requester
PAATHD/EUROP/X3N@MIDEA
Input: Description
/X3N@MIDEA Affiliate MIDEA as the requester
52 Selective Access
Agreement with an Individual Agency
This would be an agreement that an affiliate makes with an

individual agency. The providing affiliate must decide what level of
functionality they wish the individual agent to be able to perform on
their Booking Files.
When to use
Use when you wish just one agent to service your bookings for
either a set amount of time or indefinitely. An agreement must
exist in both directions between the affiliate and individual agent in
order to service each other’s bookings.
How to use
Adding the agreement
PAATHA/EUROP/XX8/49
Input: Description:
/XX8 Agency XX8 as the requester
PAATHD/EUROP/XX8
Input: Description:
/XX8 Agency pseudo XX8 as the requester
Changing the Authorisation Section
Any change to the authorisation section must be made by:

1. Deleting the old agreement.
2. Re-adding it with the updated information.
Selective Access 53
Displaying History
Affiliate file history is maintained for 30 days. As per normal
Booking File history, the latest action is at the top of the display.
The history often displays what the item was before it was
changed.
When to use
made and who made them. You may then wish to reinstate
members or agreements.
How to use
To display the history:
PAAFFH/EUROP
Input: Description:
PAAFFH Primary Access Affiliate History
/EUROP Affiliate EUROP
54 Selective Access
Response:
1
2
Screen description:
1 AFFILIATE HISTORY: EA7/EUROP: Affiliate history for EA7/EUROP

2 CREATED-14JUN00 BY- EA7/0091416 The affiliate was created on 14 June 2000 by EA7,
sign-on 9141 and check digit 6
Note: History codes: Affiliate area:
ADD – Addition AFF – Affiliate title
CHG – Change ATH – Authorisation section
DEL – Deletion MEM – Members section
3 DEL ATH 07JUL 1258Z EA7/0091416 The authority for EA7/EUROP, which was 67, was
EA7/EUROP 0067 07JUL00 OPEN deleted and the new authority (agreement 2) was
ADD ATH 07JUL 1258Z EA7/0091416 added. The 2 entries which generated this history
EA7/EUROP 0002 07JUL00 OPEN were:
PAATHD/EUROP/EA7@EUROP
PAATHA/EUROP/EA7@EUROP/2
4 CHG AFF 06JUL 1340Z EA7/0091416 A change was made to the affiliate title for EUROP.
EA7/EUROP EUROPEAN TRAVEL It used to be EUROPEAN TRAVEL
5 CHG MEM 06JUL 1340Z EA7/0091416 A change was made to the members section.
XC3 PARIS TRAVEL RAVE It used to be XC3 PARIS TRAVEL
6 CHG AFF 06JUL 1340Z EA7/0091416 A change was made to the affiliate title for EUROP.
EA7/EUROP EUROP TRAVELS It used to be EUROP TRAVELS
Selective Access 55
Special Affiliate Processing (SAP)

Special Affiliate Processing (SAP) transfers the detail of
agreements contained in the authorisation section of the affiliate
file, into the permission file of each member of the affiliate.
The SAP entry is one of the most complex to understand,

however, once grasped, you have the key to Selective Access™.
When
It is a time-initiated batch utility that runs six times a day, seven

days a week. Processing times are:
0100, 0400, 0800, 1100, 1515, and 2000 GMT/UTC
Note: These times can vary slightly.
Why
The SAP batch utility combines entries made for an affiliate, so

that actual processing time is reduced. It saves the headquarters
having to make individual PAPERA entries on behalf of all its
members.
After each processing time, a message will be directed to the

supervisory message queue to confirm the completion of the entry,
and to advise of any errors found during processing.
Who
This process is carried out by the headquarters of the affiliate,

after the relevant agreements have been added to the appropriate
affiliate file.
A similar procedure is undertaken by an individual agency when it

sets up an agreement with an affiliate.
Special Affiliate Processing formats begin with the identifier:

PASAP
SAP Table
SAP entries are stored in the SAP table, and processed at the
next batch time. The table displays pending entries, and those
that are currently being processed.
When to use
Display the table if you wish to check the entries that are waiting.
56 Selective Access
How to use
PASAP*
Input: Description:
PASAP* Primary Access SAP display
Response:
Screen description:
Response: Description:
SAP TABLE EA7 SAP table for EA7

0091416 EA7 1500Z/06JU Agent sign-on, pseudo city, time (Greenwich time) and
date of SAP entry
* PASAPAEA7@EUROP/EA7@EUROP A PASAP Add entry between members of the same
affiliate
* PASAPREA7@EUROP/X3N@MIDEA A PASAP Replace entry between members of different
affiliates
PASAPDEA7@EUROP/XX8 A PASAP Delete entry between an affiliate and individual
agent
Points to note:
 An asterisk (*) before the PASAP entry indicates the entry is currently being processed.
 All PASAP entries must have the pseudo before the affiliate name. This is required as there is only one
global table where all entries are stored – you can just view your entries. If there was no pseudo, the
®
Galileo system would not know where the affiliate details were stored.
Selective Access 57
Adding
SAP entries add new agreements from the affiliate file into the
member’s permission file. However, a SAP add entry will not
override or replace any existing agreements that pseudos have
with each other.
When to use
Use a SAP add entry only when:

A completely new affiliate is created and none of the members
were previously using Selective Access™.
How to use
PASAPAEA7@EUROP/EA7@EUROP
Input: Description:
PASAPA Primary Access SAP Add
EA7@EUROP The agreement number in the authorisation
section that affiliate EUROP as the provider
gives to…
/EA7@EUROP …affiliate EUROP as the requester
58 Selective Access
Explanation
What actually is this entry doing?
All members of EUROP are giving all the other members of

EUROP agreement 2. This entry puts all the members (pseudos)
of EUROP into each permission file of the members of EUROP,
agreement 2. It is equivalent to each of the members of EUROP
individually making the entries:
In EA7: PAPERA/XC3@VIENNA TRAVEL/2
PAPERA/39CC@ATHENS TRAVEL/2
PAPERA/XX9@ZURICH TRAVEL/2
In XC3: PAPERA/EA7@LONDON TRAVEL/2
In 39CC: PAPERA/EA7@LONDON TRAVEL/2
PAPERA/XC3@VIENNA TRAVEL/2
In XX9: PAPERA/EA7@LONDON TRAVEL/2
Summary:
Often affiliate files consist of over a 100 pseudos. So the PASAP

entry saves time and ensures accuracy.
Selective Access 59
Replacing
SAP replace entries override existing agreements in the

permission file with updated agreements from the affiliate file. The
replace entry also adds new agreements if none exists.
When to use
Use a SAP replace entry when:

You are forming a new affiliate but some of the members already
have agreements in place with various pseudos. Using
replace instead of add will ensure all members have the
correct agreement.
You need to change the established agreement number. The
authorisation section of the affiliate file will need to be changed
and then a replace SAP will override existing, old agreements.
How to use
PASAPREA7@EUROP/X3N@MIDEA
Input: Description:
PASAPR Primary Access SAP Replace
gives to…
X3N@MIDEA …affiliate MIDEA as the requester
60 Selective Access
Explanation
EUROP affiliate
All members of EUROP are giving all members of MIDEA

agreement 1. This entry puts all the members (pseudos) of MIDEA
into each permission file of the members of EUROP, agreement 1.
It is equivalent to each of the members of EUROP individually
making the entries:
In EA7: PAPERA/DZ2@BAHRAIN TRAVEL/1
PAPERA/XN9@DUBAI TRAVEL/1
In XC3: PAPERA/DZ2@BAHRAIN TRAVEL/1
In 39CC: PAPERA/DZ2@BAHRAIN TRAVEL/1
In XX9: PAPERA/DZ2@BAHRAIN TRAVEL/1
MIDEA affiliate
The headquarters for MIDEA (X3N) would then make their PASAP
entry saying ‘all members in MIDEA want to give all members in
EUROP , agreement 214’:
PASAPRX3N@MIDEA/EA7@EUROP
This entry is the equivalent to the members in MIDEA making the

individual entries:
In DZ2: PAPERA/EA7@LONDON TRAVEL/214
In XN9: PAPERA/EA7@LONDON TRAVEL/214
Summary:
The PASAP entry automatically does all this. Once agreements

are in place in both directions, the agents may service each other’s
Booking Files.
Selective Access 61
Deleting
SAP delete entries delete agreements from the permission files,

i.e. the entry will remove the pseudo(s).
When to use
Use a SAP delete entry when:

You no longer wish to have an agreement between your own or
another affiliate.
A member leaves your affiliate or an affiliate with whom you have
an agreement.
How to use
PASAPDEA7@EUROP/XX8
Input: Description:
PASAPD Primary Access SAP Delete
gives to…
/XX8 …the requester agency
Explanation
EUROP affiliate
All members of EUROP want to delete XX8. This entry deletes

XX8 from each permission file of the members of EUROP. It is
equivalent to each of the members of EUROP individually making
the entry:
In EA7: PAPERD/XX8
In XC3: PAPERD/XX8
In 39CC: PAPERD/XX8
In XX9: PAPERD/XX8
62 Selective Access
XX8
XX8 makes a PASAP entry stating ‘I want to delete all members of

EUROP who are in my permission file’:
PASAPDXX8/EA7@EUROP
This is equivalent to XX8 making the entries:

In XX8: PAPERD/EA7
PAPERD/XC3
PAPERD/39CC
PAPERD/XX9
Summary:
The PASAP entry automatically does all this.
Cancelling
The SAP cancel entry deletes the pending entry from the SAP
table.
Note: If an entry has been processed or is being processed (*), it

cannot be cancelled.
When to use
You have made an error in your PASAP entry and no longer wish
it to be processed.
How to use
Follow these steps to delete an entry:

1. Display the PASAP table PASAP*
2. Take your cursor to just before the entry you wish to delete,
insert a som  (page down) and put your INSert key on:
Selective Access 63
How to use (Cont.)

3. Type in PASAPX/ before the entry and leaving no spaces, go
to the end of the entry:
4. Press Enter:
5. To confirm deletion, tab and Enter. The system responds with

an asterisk (*). Or to ignore deletion, Ctrl+W.
Supervisory Message Queue
After each batch processing time, a message will be directed to

the supervisory queue to confirm the completion of the entry and
to advise of any errors found during processing.
The supervisory queue should always be checked after a PASAP

entry has been processed.
64 Selective Access
Successful transfer
The response below confirms that the PASAPR entry was

successful; maybe completely or maybe only partially. You must
still check all your supervisory queue messages for any other
individual errors.
Headquarters not designated
This response indicates that a pseudo did not designate

headquarters:
The result of this message will mean that XC3’s permission table
will contain none of the EUROP pseudos, i.e. XC3 has given no
agreements to EUROP.
However, the other pseudos in the EUROP affiliate will contain

XC3 as they have successfully given the agreement to XC3.
The agencies will not be able to work with XC3 until the PASAPR
is repeated.
Correction
To correct this, follow these steps:

1. Emulate the ‘offending’ agency, XC3, and designate the
headquarters: PAHDQA/EA7
2. Emulate back to the headquarters, EA7 and repeat the
PASAPR entry: PASAPREA7@EUROP/EA7@EUROP
Selective Access 65
Different agreements exist
This response confirms that EA7 has already given an agreement

to XC3, 39CC and XX9, which is different to the agreement
contained in the authority section for the affiliate EUROP:
This would be where a PASAPA (add) has been used, when a

PASAPR (replace) should have been used to override existing
agreements. The PASAPA has been ignored and it is necessary
to repeat the PASAP using R (replace).
Affiliate error
This response indicates that an agreement has not been added to

the authority section for one of the affiliates:
66 Selective Access
Displaying History
SAP table history is maintained for 30 days. As per normal

The history often displays what the item was before it was
changed.
When to use
You can check history to see recent changes and who made them.
You may also track what transpired at the last batch processing
time.
How to use
PASAPH
Input: Description:
PASAPH Primary Access SAP History
Response:
Selective Access 67
How to use (Cont.)
Screen description:
1 SAP TABLE HISTORY EA7 SAP table history for EA7

2 CANCEL 0091416 EA7 1237Z/07JUL The PASAPA entry was ADDed to the table, then it
PASAPAEA7@EUROP/EA7@EUROP was cancelled.
ADD 0091416 EA7 1103Z/07JUL
PASAPAEA7@EUROP/EA7@EUROP
3 END 0091416 EA7 2000Z/06JUL A PASAPR entry was ADDed to the table. The
PASAPREA7@EUROP/EA7@EUROP Special Affiliate Processing STARTed at 2000 GMT
START 0091416 EA7 2000Z/06JUL And it ENDed at 2000 GMT.
PASAPREA7@EUROP/EA7@EUROP
ADD 0091416 EA7 1538Z/06JUL
Note: If the history code STOP appears, this indicates a partial or unsuccessful SAP. Check the supervisory
queue for the error.
68 Selective Access
Module Review
You are going to form an affiliate with other colleagues, as advised by your instructor. One of you will
be the headquarters. There are two parts to this module review.
Complete the flow chart(s) at the end of this module with the entries your affiliate used.
Part 1 – Agreement Between Members of the Same Affiliate (Day 1)
The following is required:
 Agreement number 1
Part 2 – Agreement Between Two Affiliates (Day 2)
The following is required:
 Agreement number 31 or 26 (Agreement number does not have to be the same in both
directions).
Selective Access 69
Affiliate Agreements
This diagram summarises how the affiliates will be formed and relates to the completed
flowcharts in Appendix F: Answer Key.
Note: You should only check the answer key when you have completed this exercise.
XR5/WORLD
UQ5/AIRSA
XR5 X0F
UW3 1CO
7FI XQ6 7WS

New member (if rqd.)
X1K
UQ5/AIRSA
XQ0/GLOBE
UW3
XQ0 1CO
XQ4
7FI XJ7
UQ5/AIRSA
X0I/UNIV
X0Z
UW3
X0I 1CO
XR3
7FI 7WS
X0E
X0D/STARS XF8
X0D XJ8
39AG
XX8
Individual Agent
X3M
70 Selective Access
Adding an Agreement Between Members of an Affiliate
ALL MEMBERS to choose SAME AGREEMENT NBR
Display HQ
Designate/ADD HQ (each agency makes this entry - not HQ) Display CUStomiser
files
HQ to Build CUStomiser
DO YOU WISH TO
CUSTOMISE THE Yes
AGREEMENT?
No
HQ to BUILD AFFILIATE MEMBERS section
Display list of
AFFiliates (HQ only)
HQ to ADD AUTHORISATION section Display AFFiliate

(HQ only)
Display AFFiliate
(Affiliate Members)
HQ to perform SPECIAL AFFILIATE PROCESSING

(will place AGReement in PERmission files for each member)
Display PASAP
table
THE TIME-INITIATED SPECIAL AFFILIATE PROCESSING Display PERmission

UTILITY MUST RUN BEFORE CONTINUING file
Selective Access 71
Adding an Agreement Between Two Affiliates
Complete only your own affiliate’s entries.

Each AFFILIATE to choose AGREEMENT number Display CUStomiser
files
Each AFFILIATE to choose AGREEMENT number
HQ to BUILD CUSTOMISER
DO YOU WISH TO
CUSTOMISE THE Yes
HQ to BUILD CUSTOMISER
AGREEMENT?
No
EACH HQ to ADD Agreement with the other AFFILIATE

- to the AUTHORISATION of their own AFFILIATE file
Display Affiliate file
EACH HQ to ADD Agreement with the other AFFILIATE

Display Affiliate file
EACH HQ to perform Special Affiliate Processing

- to place Agreement into the Permission file of each of
their own members
Display PASAP table
EACH HQ to perform Special Affiliate Processing

their own members
72 Selective Access
Module 6: The Customiser File
The provider builds and maintains the customiser file. Each

agency can have numerous customiser files, which can be used
with multiple agreements. The customiser file is optional and
takes an agreement to a more refined level.
Module Objectives
Upon completion of this module you will be able to perform the
following:
 Display, build, add, change and delete customisers
 Display customiser history
Overview
By using a customiser, the provider may determine which:
Booking Files and Client Files the requester may access
Queues the amended Booking Files should fall on
Requester agents may actually access the provider’s
PrivateFares™ accounts and Booking Files
Points to note:
As there may be multiple customiser files, the provider assigns
each file a unique 2-character customiser code and an optional
customiser description to distinguish the customiser files from
each other.
The provider may associate the same customiser file with more
than one agreement in the permission file.
When a customiser is attached to an agreement on the permission
file, only the fields that are set to Y on the agreement are activated
on the customiser file.
Selective AccessTM customiser file formats begin with the identifier:
PACUS
Selective Access 73
Displaying
It is possible to display an individual customiser file or a list of all
customiser files belonging to your office.
A List of Customiser Files
The list will summarise all customiser files that have been built in
your own pseudo.
When to use
Display the list to check which customisers have been built for
your office.
How to use
To display the list:
PACUS
Primary Access Customiser Display
Response:
1
2
Screen description:
Item: Screen response: Description:
1 CUSTOMISER DISPLAY: EA7 This is the customiser display for pseudo EA7
2 CODE DESCRIPTION 2-letter code and full description (maximum 25 characters)
3 EA7/BC BBC Owning pseudo, 2-letter code and full description.
EA7/ES ESSO IMPLANT Naming convention for customisers
EA7/RS RSPCA – The first three customisers in this example (BC, ES, RS),
EA7/75 Q75 would all be linked to individual agreements with
companies, as their respective description indicates.
– The last customiser (75) is of a more generic nature and
could be attached to many agreements as it simply states
that all Booking Files should be queued back to queue 75.
74 Selective Access
An Individual Customiser
You can display a specific customiser using the 2-letter code you
found in the list or when you already know the 2-letter code.
When to use
Display a specific customiser to determine if it is appropriate for

use with a specific business relationship or to determine if you
need to modify it.
How to use
To display the customiser:
PACUS*/ES
Primary Access Customiser Display
Mandatory slash and 2-character code
Response:
Basic
Queues
Auth.
Agents
BF.
Cust. ID
Client
Files
Private
Fares
Selective Access 75
How to use (Cont.)
Screen description:
Section: Screen response: Description:
Basic EA7/ES ESSO IMPLANT Providers pseudo city, 2-letter customiser code and full
description.
Queues QET: 89 When the requester modifies a provider’s Booking File and
end transacts, the Booking File is automatically placed on the
provider’s queue shown in this field.
When this section does not appear, Booking Files are
automatically placed on the provider’s queue 1 (GEN).
Note: This field is activated when the Booking File QET field
is set to Y.
QEB: 80 When the requester modifies a provider’s Booking File and
enters QEB (without a queue number) the Booking File is
placed on the provider’s queue shown in this field.
When this field does not appear, Booking Files are
automatically placed on the provider’s queue 1.
Note: This field is activated when the QEB IN field on the
selected agreement is set to Y.
Authorised – EXCLUDING When –EXCLUDING appears here, the listed agent signs on
agents at the requester’s agency are not allowed access to the
provider’s Booking Files and Client Files.
When –EXCLUDING does not appear here, any listed agent
sign on at the requester’s agency are the only agents allowed
access to the provider’s Booking Files and Client Files.
When this section does not appear, all of the requester’s
agents may access the provider’s Booking Files and Client
Files.
ZXX8FB The sign-on of the agent(s) who are allowed or not allowed
access to the provider’s Booking Files and Client Files.
In this example, all of the requester’s agents except ZXX8FB
may access the provider’s Booking Files and Client Files.
Booking File ESSO When there is no dash before the customer ID, the requester
customer may only access Booking Files containing this customer
identification identification code.
When there is a dash (–) before the customer ID, the
requester can access all of the provider’s Booking Files
except Booking Files containing this customer identification
code.
When this section does not appear, the requester may access
all of the provider’s Booking Files.
In this example, since there is no dash before ESSO, the
requester may access only Booking Files with ESSO in the
customer identification field.
Note: To add a customer identification field to a Booking File,
type CI. and the customer identification code, e.g. CI.ESSO.
76 Selective Access
Section: Screen response: Description:
Client Files BAR: ESSO In this example, since there is no dash before ESSO, the
requester may only access the ESSO business file.
PAR: –ESSO-CHIEF In this example, since there is a dash before ESSO-CHIEF,
the requester may access all personal files associated with the
ESSO business file, except CHIEF.
PrivateFares AUTHORISED AGENTS: When –EXCLUDING appears here, the listed agent sign-ons
™ –EXCLUDING at the requester’s agency are not allowed access to the
display/quote provider’s PrivateFares™ accounts.
ZXX8FB
When –EXCLUDING does not appear here any listed agent
sign-ons at the requester’s agency are the only agents allowed
access to the provider’s PrivateFares™ accounts.
When this section does not appear, all of the requester’s
agents may access the provider’s PrivateFares™ accounts.
In this example, all of the requester’s agents except ZXX8FB
may access the provider’s PrivateFares accounts.
ACCOUNT CODES: When there is a dash before the account codes, the requester
ESSO may display and quote all PrivateFares accounts except those
listed.
When there is no dash before the account codes, the
requester may only display and quote the PrivateFares
accounts listed.
When this section does not appear, the requester may display
and quote all of the provider’s PrivateFares accounts.
In this example, since there is no dash before the account
code, the requester may display and quote only the
PrivateFares™ account listed.
Selective Access 77
Customiser Form
Sometimes it can be beneficial to summarise what you wish the

requester to be able to do, before entering the details in the
system. The form for the ESSO customiser would be completed
as follows.
Note: Additional forms may be found in Appendix E: Worksheets

and Entries.
Customiser Identification
(2 characters min/max - alpha/numeric) ES
Customiser Description
(1-25 characters maximum - alpha/numeric) ESSO IMPLANT
QET QEB
Queue Automatically at ET 89 Queue Manually 80
CID (BF entry = CI. Code) AID

Customer Identification code Booking Agent Identification
File (CUST field)
ESSO
-ZXX8FB
BAR Client Files PAR

Business Account Record Personal Account Record
ESSO -ESSO-CHIEF
FAC PrivateFares FAI

PrivateFares Account Codes PrivateFares sign-on
ESSO --ZXX8FB
78 Selective Access
Building a Customiser
The format to build a customiser file has two parts. The first part
includes basic information, which identifies the action and names
the customiser file. The second part includes each function you
wish to customise, and the customised information. If you want to
customise several functions, the format can be very long.
When to use
Build a customiser when you wish to customise or limit the

functionality of an agreement, which you are about to give to a
requester.
How to use
The following format would have built the example explained on

the previous pages:
PACUSB/ES@ESSO IMPLANT/QET89/QEB90/AID-
ZXX8FB/CIDESSO/BARESSO/PAR-ESSO-
CHIEF/FACESSO/FAI-ZXX8FB
The following sections describe each part of the above format.
Basic Section
All information in the basic section is mandatory except the

customiser description. The following table lists the basic section
fields and gives a description of each:
PACUSB/ES@ESSO IMPLANT
Field: Description:
PACUS Primary Access CUStomiser file identifier

B Build indicator
ES Customiser code (2 alphanumeric characters)
@ESSO IMPLANT Optional customiser description (1-25
alphanumeric characters) preceded by @
Selective Access 79
Function Section
This section of the format includes a three-letter field identifier

followed by the information for each field that you need to
customise. A slash before each field identifier separates it from
the previous field. To activate the customiser field, select an
agreement with the corresponding agreement file fields set to Y.
The following table lists the fields and instructions on how to

complete them.
Queuing
Instead of returning Booking Files to queue 1 (GEN), at end

transact, automatically return the Booking File to queue 89 and at
QEB return Booking Files to queue 90:
QET89/QEB90
Field: To: Do this:
QET Allow requester to queue provider’s

Booking Files at end transact to:
 Queue 1 Omit this field.
 Another specified queue Type the identifier and queue number (QET89).
QEB Allow requester to queue provider’s
Booking Files by typing QEB to:
 Queue 1 Omit this field.
 Another specified queue Type the identifier and queue number (QEB90).
80 Selective Access
Authorised agents
Grant access to your Booking Files and Client Files to all agents
except ZXX8FB:
AID–ZXX8FB
Field: To: Do this:
AID Grant Selective Access™ authority to:

 All of the requester’s agents Omit this field.
 A specified agent only (omitting other Type the agent’s sign-on code, e.g. AIDZXX8FB
agents in the office)
 Multiple agents Type all agent’s sign-on codes joined by a plus (+),
e.g. AIDZXX8FB+ZXX8DG+ZXX8KR
Deny Selective Access authority to:
 A specified agent Type the agent’s sign-on code preceded by a dash,
e.g. AID–ZXX8FB
 Multiple agents Type all agents’ sign-on codes joined by a plus (+)
and preceded by a dash,
e.g. AID–ZXX8FB+ZXX8DG+ZXX8KR
Note: If the pseudo city code of the agency is a four-character code, the @ symbol must precede the agent’s
initials in the sign-on code, e.g. AIDZ7AA1@FB, where 7AA1 is the pseudo city code, and FB the agent’s
initials.
Customer Identification Code
Only Booking Files which have the CUST field ESSO can be
accessed by the requester:
CIDESSO
Field: To: Do this:
CID Grant access to:

 All Booking Files Omit this field.
 Booking Files with a specified Type the identifier and the customer ID, e.g.
customer ID CIDESSO
 Booking Files with multiple customer Type the identifier followed by the customer IDs,
IDs separated by a plus, e.g. CIDESSO+ESSOUK
Deny access to:
 Booking Files with a specified Type the identifier, a dash, and the customer ID,
customer ID e.g. CID–ESSO
 Booking Files with multiple customer Type the identifier and a dash followed by the
IDs customer IDs, separated by a plus, e.g.
CID–ESSO+ESSOUK
Note: The Booking File customer identification code must be entered in the customiser file exactly as it is
entered in the Booking File. For example if USA TOUR is entered in the customiser file with a space between
the two words, then USA TOUR must be entered in the Booking File with the same spacing.
Selective Access 81
Business and Personal Files
The requester may view the ESSO business file and all associated
personal files except CHIEF:
BARESSO/PAR-ESSO-CHIEF
Field: To: Do this:
BAR Grant access to:

 All business files Omit this field.
 A specified business file Type the identifier and the business file title,
e.g. BARESSO
 Multiple business files Type the identifier followed by the business file titles,
separated by a plus, e.g. BARESSO+SHELL
Deny access to:
 A specified business file Type the identifier, a dash, and the business file title,
e.g. BAR–ESSO
 Multiple business files Type the identifier and a dash followed by the
business file titles, separated by a plus, e.g.
BAR–ESSO+SHELL
PAR Grant access to:
 All personal files Omit this field.
 A specified personal file Type the identifier and the personal file title, e.g.
PARESSO–CHIEF
 Multiple personal files Type the identifier followed by the personal file titles,
separated by a plus,
e.g. PARESSO–CHIEF+SHELL–SMITH
Deny access to:
 A specified personal file Type the identifier, a dash, and the personal file title,
e.g. PAR–ESSO–CHIEF
 Multiple personal files Type the identifier and a dash followed by the
personal file titles, separated by a plus,
e.g. PAR–ESSO–CHIEF+SHELL–SMITH
82 Selective Access
PrivateFares™ Account Code Identification
Grant access to the PrivateFares ESSO:

FACESSO/FAI-ZXX8FB
Field: To: Do this:
FAC Grant access to:

 All of the provider’s PrivateFares™ Omit this field.
accounts
 A specified PrivateFares™ account Type the identifier and PrivateFares account
code, e.g. FACESSO
 Multiple PrivateFares™ accounts Type the identifier followed by the PrivateFares
account codes, separated by a plus,
e.g. FACESSO+SHELL
Deny access to:
 A specified PrivateFares™ account Type the identifier, a dash, and the PrivateFares
account code, e.g. FAC–ESSO.
 Multiple PrivateFares™ accounts Type the identifier and a dash followed by the
PrivateFares account codes separated by a plus,
e.g. FAC–ESSO+SHELL.
PrivateFares™ Authorised Agent Identification
All requesters may view the PrivateFares except ZXX8FB:

FAI–ZXX8FB
Field: To: Do this:
FAI Grant PrivateFares access to:

 All of the requester’s agents Omit this field.
 A specified agent only (omitting other Type the agent’s sign-on code, e.g. FAIZXX8FB
agents in the office)
 Multiple agents Type all agents’ sign-on codes joined by a plus,
e.g. FAIZXX8FB+ZXX8DG+ZXX8KR
Deny Selective Access authority to:
 A specified agent Type the agent’s sign-on code preceded by a dash,
e.g. FAI–ZXX8FB
 Multiple agents Type all agent’s sign-on codes joined by a plus and
preceded by a dash,
e.g. FAI–ZXX8FB+ZXX8DG+ZXX8KR
Note: If the pseudo city code of the agency is a four-character code, the @ symbol must precede the agent’s
initials in the sign-on code, e.g. FAIZ7AA1@FB, where 7AA1 is the pseudo city code, and FB the agent’s
initials.
Selective Access 83
Adding to a Customiser
Once a customiser file has been built, it is possible to add new
information or supplement existing information, as shown below, in
any of the following fields:
Field: Description:
QET Queue at end transaction

QEB Queue manually
AID Authorised agent identification
CID Booking File customer identification
BAR Business file identification
PAR Personal file identification
FAC PrivateFares™ account code identification
FAI PrivateFares™ authorised agent
You may add one field or multiple fields at a time.
When to use
Add fields when the customiser has already been built and you
need to make an addition.
How to use
Adding one field
PACUSA/ES/CIDESSOUSA
Primary Access Customiser Add

/ES Mandatory slash and 2-character Customiser code
CID Field identifier
ESSOUSA Information to be added
Example of adding multiple fields:
PACUSA/ES/CIDESSOUSA/BARESSOUSA
Input: Description:
PACUSA Primary Access CUStomiser Add

/ES Mandatory / and 2-character customiser code
/CIDESSOUSA Mandatory / and CID field and data to be added.
/BARESSOUSA Mandatory / and BAR field and data to be added.
84 Selective Access
Changing Customiser Fields

The only items of a customiser file which may be changed are the
optional descriptive name of the file and the queuing fields.
Note: If changes are required to any other field, the old field must
be deleted and a new field added.
How to use
Changing one field
PACUSC/ES@ESSO LONDON
Primary Access Customiser C to change

@ESSO LONDON New description
Example of changing multiple fields:
PACUSC/ES@ESSO LONDON/QET50/QEB55
Input: Description:
PACUSC Primary Access CUStomiser Change

@ESSO LONDON New description
/QET50/QEB55 New queue numbers
Deleting
It is possible to delete:
Specific fields within a customiser
The entire customiser
All customisers
Selective Access 85
Field(s) Within a Customiser
You may delete one or multiple fields within a customiser.
When to use
There are two reasons to delete customiser fields.

 You can delete a specific field in a customiser file when you no
longer want to restrict it. For instance, if you have granted
Selective Access authority to one of the requester’s agents
and now want to grant authority to all agents you can
accomplish that by deleting the AID field.
 You can delete a specific field if it is incorrect. Then you can
add the field again with the updated information. For instance,
if the PrivateFares™ account code was entered incorrectly you
can delete the FAC field, and then add the correct
PrivateFares account code using a customiser file add format.
How to use
Deleting one field
PACUSD/ES/CIDESSOUSA
Primary Access Customiser D to delete

/CIDESSOUSA Customer id to be deleted
Example of deleting multiple fields:
PACUSD/ES/CIDESSOUSA/BARESSOUSA
Input: Description:
PACUSD Primary Access CUStomiser Delete

/CIDESSOUSA Mandatory / and CID field and data to be deleted
/BARESSOUSA Mandatory / and BAR field and data to be deleted
86 Selective Access
An Entire Customiser File
When you no longer need a customiser file, you can delete it. You
should, however, delete any agreements in the permission file that
include this customiser file before deleting the customiser file.
When to use
Delete the customiser when the agreement no longer needs to be

customised or you no longer have that agreement with the
requester.
How to use
To delete a customiser:
PACUSD/ES
Primary Access Customiser D to delete

/ES Mandatory slash and 2-character Customiser code to be
deleted
Response:
This response is followed by a tab stop, which acts as a double

check to prevent deletion in error. If deletion is required, Tab and
Enter.
Selective Access 87
All Customiser files
You may delete all customisers (and their history) that exist for a
pseudo in one entry.
Warning! Once these files are deleted, they cannot be restored.

There is no history.
When to use
If an agency has a major policy change, which means all

customiser files must be changed, it may be more efficient to
delete all existing customiser files and build new ones.
How to use
To delete all customisers:
PADELD/CUS
Primary Access Delete

/CUS All Customisers
Response:
This response is followed by a tab stop, which acts as a double

check to prevent deletion in error. If deletion is required, Tab and
Enter.
88 Selective Access
Displaying History
Customiser file history is maintained for 30 days. As per normal
When to use
made and who made them. You may then wish to reinstate the
customiser as it was.
How to use
PACUSH/ES
Primary Access Customiser History

/ES Mandatory slash and Customiser code
Selective Access 89
How to use (Cont.)
Response:
1
2
Screen description:
1 CUSTOMIZER HISTORY: Display title

EA7 Pseudo city code
ES Customiser code
2 CREATED – 14JUN00 Date created
BY – EA7/009146 Pseudo city code and agent sign of creator
3 DEL History codes:
DEL – Deletion
ADD – Addition
CHG – Change
CUS Customiser file identifier
21JUL 0933Z EA7/0091416 Date and time (Greenwich time) of update. Pseudo
city code and agent sign of agent updating file
BAR: ESSOUSA Deleted business file ESSOUSA
CID: ESSOUSA Deleted customer identification ESSOUSA
Note: The entry made to generate the above history was
PACUSD/ES/CIDESSOUSA/BARESSOUSA
4 CHG CUS … QEB: 80 The QEB field was changed from 80
CHG CUS … QET: 89 The QET field was changed from 89
CHG CUS …DES: ESSO IMPLANT The DES field was changed from ESSO IMPLANT
Note: The entry made to generate the above history was PACUSC/ES@ESSO
LONDON/QET50/QEB55
90 Selective Access
Module Review
This exercise will allow you to customise a Selective Access™ agreement.
Two agencies, WINDMILL TRAVEL of Amsterdam, and EMPIRE TRAVEL of New York have
decided to set up a business agreement to service each other’s bookings:
 Windmill travel regularly sends Philips’ employees to New York whose details are in a
business file called PHILIPS.
 Empire travel are sending a group of Coca Cola employees to Amsterdam whose details
are in a business file called COLA.
You and your neighbour should each take the part of one of these agencies.
Use the following information to choose an appropriate agreement, decide what

customisation is needed, and enter it in your permission file.
Complete the customiser form and flowchart at the end of this module, with your own entries.
Part 1 – Selective Access™
4. Agreement details
The agreement should allow the requester to:
 Display and update Booking Files
 Display and print your business and personal files
 Display your agency file
 Queuing of Booking Files should be possible to and from the requester, as should
supervisor queue messages
 The agreement should allow the provider to:

 See all updated Booking Files, so you want them to be automatically queued back to you
at the end of the transaction.
Selective Access 91
Part 1 – Selective Access™ (Cont.)
2. Customiser requirements.
Use the following worksheet to plan these items:
When the requester has serviced a booking, the provider wants it to return automatically
to his queue number 50.
If the requester needs to queue a booking to the provider manually, it should be placed
on queue 55.
• WINDMILL TRAVEL will only allow access to bookings with the identifier (CI.)
PHILIPS and view this business file.
• EMPIRE TRAVEL will only allow access to bookings with the identifier (CI.) COLA
and view this business file.
3. Permission file
Add the relevant agreement to your permission file. The agreement should take effect
immediately, and terminate at the end of the year.
4. Build a Booking File using the relevant business file.

Note: The CI. field is automatically completed from the file.
Make a note of the locator.
Part 2 – Booking Files with the Customer Identification Code.
As the requester, imagine that the passenger has travelled the first part of his/her journey
and now wishes to change the return date
Retrieve the Booking File by locator (which would be on the ticket)
Amend the return flight
QEB the Booking File back to provider
Provider note the Q number the Booking File has been returned on _________________
92 Selective Access
Part 3 – Booking Files without the Customer Identification Code.
Provider to take out the CID from the Booking File and End Transact.
As the requester, imagine that the passenger has travelled the first part of his/her journey
and now wishes to change the return date:
attempt to retrieve the Booking File by locator (which would be on the ticket)
Note the response
Part 4 – Queuing of Booking Files
Provider to queue their Booking File to the requester for action prior to travel once QEB’d,
the requester will be able to update regardless of whether the correct CID is present or not.
Part 5 – Displaying and Moving Client Files
Use the other agency’s Client Files to build bookings.
Attempt to change a line within the Client File.
When you have completed this exercise, delete the permission and customiser files.
Selective Access 93
Customiser File Worksheet
(2 characters min/max - alpha/numeric)
(1-25 characters maximum - alpha/numeric)
QET QEB
Queue Automatically at ET Queue Manually

Customer Identification code Booking File Agent Identification
(CUST field)

FAC PrivateFares™ FAI

94 Selective Access
Adding an Agreement Between Two Individual Agencies – Flowchart
Windmill Travel - CHOOSE AGREEMENT
Empire Travel - CHOOSE AGREEMENT
Display CUStomiser
files
Windmill travel - BUILD CUSTOMISER
DO YOU WISH TO
CUSTOMISE THE Yes
AGREEMENT? Empire Travel - BUILD CUSTOMISER
No
Windmill Travel - ADD AGREEMENT to PERmission

file
Display PERmission
files
Empire Travel - ADD AGREEMENT to PERmission
file
Selective Access 95
Appendix A: Step-by-Step Procedures
This appendix summarises the typical Selective Access™

scenarios and procedures to set up, update, and delete Selective
Access™ agreements between:
 Two individual agencies
 Members of an affiliate
 Two affiliates
 An affiliate and an individual agency
Points to note:
As you read through these procedures, refer to the previous
modules for a full explanation of all formats and files.
Sometimes it is the head office (headquarters) that carries out all
entries by emulating into the relevant pseudos.
Between Two Individual Agencies

This section describes procedures for:
 Setting up an agreement
 Deleting an agreement
Selective Access 96
Setting Up an Agreement
In this scenario, EA7 (Head Office) and the X3M (Esso Implant)
need to be able to share Booking Files for servicing purposes.
Setting up an agreement is a 3-step process:

1. Select an agreement.
2. Set up a customiser file (optional).
3. Add an agreement to the permission file.
Step 1 – Select the agreement
Each agency, as provider, may select the same or different

agreements.
Both agencies
Decide which functions you wish to allow the requester. To assist

you use one or all of the following:
The agreement fill-in-format: PAAGRF
The list of agreements: PAAGR*
Step 2 – Set up a customiser file (optional)
If a customiser is not required, go to the next step.
Both agencies
If you wish to customise your agreement either:

Check if you have an existing customiser you wish to use:
PACUS*
Build a customiser file using the following format:
PACUSB/ES@ESSO/QET89/QEB80/AID-ZXX8FB/CIDESSO
/BARESSO/ PAR-ESSO-CHIEF/FACESSO/FAI-ZXX8FB
Step 3 – Add the agreement
In EA7
Add an agreement to the permission file, using the following

format:
PAPERA/X3M@ESSO IMPLANT/49/ES/DIS31DEC01
In X3M
Add an agreement to the permission file, using the following

format:
PAPERA/EA7@HEADOFFICE/2/DIS31DEC01
Selective Access 97
Deleting an Agreement
In this scenario, the Esso contract has now been taken over by
another agent. The agreement between EA7 and X3M is no
longer required.
Deleting the agreement is a 2-step process:

1. Delete the customiser file.
2. Delete the agreement from the permission file.
Step 1 – Delete the customiser file
If a customiser has been used, review the details and delete if it

was built just for this agency. However, if the customiser is a
generic one then leave it in place and go to the next step.
Both Agencies
Delete the customiser file using the following format:

PACUSD/ES and Enter
Tab and Enter to confirm deletion.
Step 2 – Delete the agreement
The agreement must now be deleted from the permission files.
In EA7
Use the following format:

PAPERD/X3M
In X3M
Use the following format:

PAPERD/EA7
98 Selective Access
Between Members of an Affiliate

This is where one or more agencies wish to work together to
service or part-service each other’s Booking Files.

 Adding a new member
 Deleting a member
 Changing an agreement number
 Deleting the agreement
A group of agencies come together to form a business alliance,

and set up an arrangement whereby they will service the needs of
each other's clients when they are travelling in each other's
countries. They therefore form an affiliate.
The agencies are:

London Travel in the UK (EA7)
Paris Travel in France (XC3)
Athens Travel in Greece (39CC)
Zurich Travel in Switzerland (XX9)
They decide to name the affiliate EUROPEAN TRAVEL, and give

it the affiliate file code EUROP.
Setting up an agreement is a 5-step process:

1. Designate headquarters.
4. Create the affiliate file and add the authorisation.
5. Run Special Affiliate Processing (SAP).
Selective Access 99
Step 1 – Designate headquarters
All members of the affiliate must designate their headquarters as

EA7. It is not necessary for the headquarters to designate
themselves.
In XC3, 39CC and XX9
Designate EA7 as the headquarters:

PAHDQA/EA7
Points to note:
If a member does not designate the headquarters, when the SAP
takes place they will be missed out, i.e. their permission file will be
blank but they will be in the other permission files for the other
members.
An error message will be returned on the headquarters
supervisory queue.
The affiliate members first decide upon the agreement number that
is most appropriate to their situation – all must agree the same
number. Use one or all of the following:
Step 3 – Build the customiser (Optional)
If a customiser is not required, go to the next step .
In EA7 (Headquarters)
If a customiser was required it would always be built in the

headquarters:
PACUS*
Build a customiser file using the following format: PACUSB/ …
100 Selective Access

Step 4 – Create the affiliate file
If this is a new affiliate file, then the headquarters will add the
members and the agreement number which will create the affiliate
file.
The headquarters builds:

The affiliate members section: PAAFFB/EUROP@EUROPEAN
TRAVEL/EA7@LONDON TRAVEL+XC3@PARIS TRAVEL
+39CC@ATHENS TRAVEL+XX9@ZURICH TRAVEL
Note: In this example the headquarters is in the affiliate. This
will allow them to test that sharing Booking Files is working
successfully. If you do not wish to be in the affiliate, omit your
pseudo.
The authorisation section to specify the details of the agreement
that the affiliate has among its own members:
Step 5 – Perform Special Affiliate Processing
The SAP entry will copy the agreement specified in the

authorisation section of the affiliate file, into the permission file of
each of the affiliate members.
In case any members have been using Selective Access™ and

could have conflicting agreements, use R to replace:
Selective Access 101

Adding a Member
Madrid Travel (DU6) decides to join the affiliate, EUROP. In this

scenario, EUROP has an agreement between its own members,
but not with any other party.
The affiliate uses the following process to add Madrid Travel to

EUROP.
2. Add the new member to the affiliate file.
The new member, DU6 must designate EA7 as the headquarters.
In DU6
PAHDQA/EA7
Step 2 – Add the new member’s name
The pseudo city code DU6 and the optional agency name must be
added to the affiliate members section of the affiliate file EUROP.
PAAFFA/EUROP/DU6@MADRID TRAVEL
SAP is performed to place the detail of the agreement with the

new member, into the permission file of each of the affiliate
members.
Use R to replace in order to override an existing agreement DU6

may have with other members of the affiliate:

Deleting a Member
Madrid Travel (DU6) decides to leave the affiliate, EUROP. In this

scenario, EUROP has an agreement between its own members,
but not with any other party.
The affiliate uses the following process to delete Madrid Travel

from EUROP.
2. Delete the departing member from the affiliate file.
3. Delete the headquarters.
SAP is performed to delete the departing member from the

permission files of the affiliate members.
Use D to delete: PASAPDEA7@EUROP/DU6
Warning! The SAP must run before you proceed to the next step.
Step 2 – Delete the departing member’s pseudo city code
The pseudo city code (DU6) of the departing member must be

deleted from the affiliate member’s section of the affiliate file
EUROP.
PAAFFD/EUROP/DU6
Step 3 – Delete headquarters
Madrid Travel (DU6) now deletes headquarters.

PAHDQD

Changing an Agreement
To change an agreement number, you need to delete the

agreement from the authorisation section of the affiliate file and
then add it with the updated information.
The affiliate uses the following process to change to a different

agreement.
1. Delete the agreement from the affiliate file.
2. Add the new agreement to the affiliate file.
Step 1 – Delete the agreement from the affiliate file
The headquarters deletes the agreement from the authorisation

section of the affiliate file:
EA7 deletes the agreement that EUROP has given to
EA7@EUROP: PAATHD/EUROP/EA7@EUROP
Step 2 – Add the new agreement to the affiliate file
The headquarters adds the new agreement to the authorisation

section of the affiliate file.
PAATHA/EUROP/EA7@EUROP/25/EU
The SAP entry will replace the agreement number in all the
member’s permission files with the new agreement number
specified in the authorisation section.

The members of affiliate EUROP decide to end their business

relationship with each other. In this scenario, EUROP has an
agreement between its own members, but not with any other party.
The affiliate uses the following process to delete their agreement.

1. Run Special Affiliate Processing.
2. Delete the affiliate file.
3. Delete headquarters.
The SAP entry will delete the agreement from the permission files
of the affiliate members.
PASAPDEA7@EUROP/EA7@EUROP
Step 2 – Delete the affiliate file
The affiliate file must now be deleted
PAAFFD/EUROP and Enter. Tab and Enter to confirm the
deletion.
Step 3 – Delete headquarters
All members (except EA7) delete headquarters.
In XC3, 39CC and XX9

PAHDQD

Between Two Affiliates

Two separate affiliates decide that they wish to form a business
alliance which will be to their mutual advantage. Both are
established affiliates and already have agreements between their
own members.
This module describes procedures for:

 Adding a member to an affiliate
 Deleting a member from an affiliate
Affiliate codes EUROP and MIDEA decide to form a business

relationship with each other.
EUROP affiliate
EA7 is the headquarters of EUROP (EUROPEAN TRAVEL) and

makes the entries on behalf of its members. The members are:
London Travel (EA7)
Paris Travel (XC3)
Athens Travel (39CC)
Zurich Travel (XX9)
MIDEA affiliate
X3N is the headquarters of MIDEA (MIDDLE EAST) and makes

the entries on behalf of its members. X3N is not a member. The
members are:
Bahrain Travel (DZ2)
Dubai Travel (XN9)
Both affiliates are the provider and requester. Use the following
process to set up an agreement with the requester affiliate.
3. Add the agreement to the affiliate file.
4. Perform Special Affiliate Processing (SAP).

Step 1 – Select an agreement
Each affiliate decides as a provider, how much access it wishes to

allow to the other affiliate as requester, and each selects an
agreement number that satisfies their business requirement.
Use one or all of the following:

Note: The selected agreement number need not be the same for
both affiliates.
Step 2 – Build the customiser (Optional)
In EA7 (EUROP headquarters)

headquarters:
PACUS*
In X3N (MIDEA headquarters)

headquarters:
PACUS*
Step 3 – Add the authorisation to the affiliate file
The headquarters agency of each affiliate adds the agreement that

their affiliate is giving to the other affiliate, and a customiser file if
applicable, to the authorisation section of their affiliate file.
As a provider, EA7 enters the agreements it wishes to give the

MIDEA affiliate:
As a provider, X3N enters the agreement it wishes to give the

EUROP affiliate (include a customiser and dates as appropriate):
PAATHA/MIDEA/EA7@EUROP/214

The headquarters agency of each affiliate performs the SAP entry

to copy the detail of the agreement that their affiliate is providing to
the other affiliate, into the permission file of each of its own
members.
EA7 EUROP (provider) wishes to give X3N MIDEA (requester) the

agreement number in the authorisation section :
This entry transfers the detail of that agreement into the

permission files of the affiliate members of EUROP.
X3N MIDEA (provider) wishes to give EA7 EUROP (requester) the

agreement number in the authorisation section :
PASAPRX3N@MIDEA /EA7@EUROP
This entry transfers the detail of that agreement into the

permission files of the affiliate members of MIDEA.
Points to note:
Using replace will replace any original agreement numbers that
may be in place between members of the affiliates.
If you use add, any original agreement numbers will remain in
place and an error response will be returned on the
supervisory queue stating that ‘AN AGREEMENT ALREADY
EXISTS BETWEEN’.

Adding a Member
Madrid Travel (DU6) decides to join the affiliate, EUROP. In this

scenario, EUROP has an agreement between its own members
and with another affiliate MIDEA.
The process is as follows:
2. Add the new member to the affiliate file.
3. Run Special Affiliate Processing (both affiliates).
Note: In this example EUROP only has one agreement with
another affiliate (MIDEA). If EUROP had more agreements with
other affiliates, the last two entries would need to be repeated in
each affiliate accordingly.
The new member, DU6 must designate EA7 as the headquarters.
In DU6
PAHDQA/EA7
Step 2 – Add the new member’s name
The pseudo city code DU6 and the optional agency name must be
added to the affiliate members section of the affiliate file EUROP.

SAP is performed by both affiliates to place the detail of the

agreement with the new member, into the permission file of each
of the affiliate members.
After these entries have been made, the permission file of each
member of each affiliate will now show the amended agreement,
which includes DU6.

Add the agreement amongst EUROP’s own members:
Add the agreement that affiliate EUROP provides to affiliate
MIDEA: PASAPREA7@EUROP/X3N@MIDEA

Add the agreement that affiliate MIDEA provides to affiliate
EUROP (to now include the new member):

Deleting a Member
Madrid Travel (DU6) decides to leave the affiliate, EUROP. In this
scenario, EUROP has an agreement between its own members
and with another affiliate MIDEA.
1. Run Special Affiliate Processing (EUROP).
2. Delete the departing member from the affiliate file (EUROP).
3. Run Special Affiliate Processing (MIDEA).
4. Delete headquarters (Madrid Travel).
Note: In this example EUROP only has one agreement with
another affiliate (MIDEA). If EUROP had more agreements with
other affiliates, the last two entries would need to be repeated in
each affiliate accordingly.
Step 1: Perform Special Affiliate Processing

SAP is performed to delete DU6 from the permission file of each
member of EUROP.
This will delete the departing member (DU6) from its own affiliate
member’s permission files: PASAPDEA7@EUROP/DU6
Step 2: Delete the departing member from the affiliate file

The headquarters of EUROP deletes the departing member (DU6)
from the member section of the affiliate file, using the following
format.
PAAFFD/EUROP/DU6
Step 3: Perform Special Affiliate Processing

The headquarters of MIDEA runs SAP to delete the departing
member (DU6) of the other affiliate from its own affiliate member’s
permission files.
PASAPDX3N@MIDEA/DU6
Step 4: Delete the Headquarters

In DU6 (Madrid Travel)
The departing member, Madrid Travel, now deletes the
headquarters using the following format.
PAHDQD

Affiliate EUROP and affiliate MIDEA decide to end their business

relationship. In this scenario, EUROP has an agreement between
its own members and an agreement with the affiliate MIDEA.
EUROP plans to maintain the agreement between its own
members.

1. Run Special Affiliate Processing (EUROP and MIDEA).
2. Delete the agreement from the affiliate file (EUROP and
MIDEA).
Step 1 – Special Affiliate Processing autodelete
SAP autodeletion is performed to “undo” the agreement that each

affiliate had provided to the other.
This input deletes the MIDEA agreement from the permission files
of the members of the affiliate EUROP:
PASAPDEA7@EUROP/X3N@MIDEA
This input deletes the EUROP agreement from the permission files
of the members of the affiliate MIDEA:
PASAPDX3N@MIDEA/EA7@EUROP
Step 2 – Delete the agreement from each affiliate file
The headquarters agency of each affiliate deletes the agreement

their affiliate had given to the other, from the authorisation section
of their affiliate file.
EA7 as the provider deletes the agreement from the authorisation

section that was given to MIDEA:
X3N as the provider deletes the agreement from the authorisation

section that was given to EUROP:
PAATHD/MIDEA/EA7@EUROP

Between an Affiliate and an Individual Agency

The affiliate EUROP negotiates a business agreement with an

individual agency, Andes Travel (XX8) located in Chile. They will
service the needs of each other’s customers when they are
travelling in each other’s countries.
EA7 is the headquarters agency of the affiliate EUROP and follows

the procedures detailed below, and makes inputs on behalf of its
members.
XX8 makes inputs on its own behalf.
It is a four-step process.
1. Select an agreement (EUROP and Andes Travel).
2. Add the agreement to the affiliate file (EUROP).
3. Run Special Affiliate Processing (EUROP).
4. Add agreement to the permission file and run Special Affiliate
Processing (Andes Travel).
The affiliate decides as a provider, how much access to allow the

individual agency as the requester. The individual agency decides
as a provider, how much access to allow the affiliate as the
requester. Each selects an agreement number that satisfies their
business requirement.
Use one or all of the following:

Note: The selected agreement number need not be the same.
Step 2 – Customiser file (Optional)

Step 3 – The affiliate file
The headquarters agency of the affiliate EUROP adds the

agreement that their affiliate is giving to Andes Travel (XX8), to the
authorisation section of their Affiliate File (previously created).
EA7 the headquarters of EUROP as the provider enters:

PAATHA/EUROP/XX8/49
Step 4 – Special Affiliate Processing
The headquarters agency of affiliate EUROP performs SAP to

copy the detail of the agreement that the affiliate is providing to
Andes Travel (XX8), into the permission file of each of its
members.
To transfer the detail of the agreement into the permission files of

the affiliate members of EUROP, EA7 enters:
PASAPREA7@EUROP/XX8
In XX8 (Andes Travel)
XX8 as provider adds the agreement it is providing to affiliate

EUROP to its own permission file, using a combined SAP and
permission file entry.
XX8 as the provider enters:

PASAPRXX8/EA7@EUROP/67

Affiliate EUROP and Andes Travel decide to end their business

relationship. In this scenario, EUROP also has an agreement
between its own members, which it plans to maintain.
It is a 2-step process:
1. Run Special Affiliate Processing. (EUROP and Andes Travel)
2. Delete the agreement from the affiliate file. (EUROP)
Step 1 – Special Affiliate Processing autodelete
SAP autodeletion is performed to “undo” the agreement that each

party had provided to the other.
This input deletes the agreement from the permission files of the
members of the affiliate EUROP:
PASAPDEA7@EUROP/XX8
In XX8 (Individual agency)
This input deletes the agreement from the permission file of Andes
Travel (XX8):
PASAPDXX8/EA7@EUROP
Step 2 – Delete the agreement from the affiliate file
The headquarters agency of affiliate EUROP deletes the

agreement from the authorisation section of their affiliate file:
PAATHD/EUROP/XX8

Appendix B: Flowchart Procedures
This appendix summarises the typical Selective Access™

scenarios and procedures to set up, update, and delete Selective
Access agreements between:
 Two individual agencies
 Members of an affiliate
 Two affiliates
 An affiliate and an individual agency
Points to note:
As you read through these procedures, refer to the previous
modules for a full explanation of all formats and files.
Sometimes it is the head office (headquarters) that carries out all
entries by emulating into the relevant pseudos.

Between Two Individual Agencies

In this scenario, EA7 (the head office) and the X3M (Esso Implant) need to be able to share
Booking Files for servicing purposes.
In EA7 - CHOOSE AGREEMENT
PAAGRF = 49
In X3M - CHOOSE AGREEMENT
PAAGRF = 2
Display CUStomiser
files
PACUS*
In EA7 - BUILD CUSTOMISER
PACUSB/ES@ESSO IMPLANT/
QET89/QEB80/AID-ZXX8FB/
CIDESSO/BARESSO/PAR-ESSO-
CHIEF/FAI-ZXX8FB
DO YOU WISH TO
CUSTOMISE THE Yes
AGREEMENT? In X3M - BUILD CUSTOMISER
N/A
No
In EA7 - ADD AGREEMENT to PERmission file
PAPERA/X3M@ESSO IMPLANT/
49/ES/DIS31DEC01 Display PERmission
files
In X3M - ADD AGREEMENT to PERmission file PAPER*
PAPERA/EA7@HEADOFFICE/
2/DIS31DEC01

In this scenario, the Esso contract has now been taken over by another agent. The
agreement between EA7 and X3M is no longer required.
In EA7 - DELETE CUSTOMISER
PACUSD/ES
In X3M - DELETE CUSTOMISER
N/A
In EA7 - DELETE AGREEMENT in PERmission file
PAPERD/X3M
Display PERmission
files
In X3M - DELETE AGREEMENT in PERmission file
PAPER*
PAPERD/EA7

Between Members of an Affiliate

Four agencies decide to form an affiliate. The affiliate will be called EUROP and the
headquarters will be EA7.
PAAGRF = 2
Designate/ADD HQ (each agency makes this entry - not HQ)
PAHDQA/EA7
In EA7 - HQ to Build CUStomiser
DO YOU WISH TO CUSTOMISE

Yes
THE AGREEMENT? N/A
No
In EA7 - HQ to BUILD AFFILIATE MEMBERS section
PAAFFB/EUROP@EUROPEAN TRAVEL/
EA7@LONDON TRAVEL+XC3@PARIS
TRAVEL+39CC@ATHENS
HQ to ADD AUTHORISATION section
Provider Requester
In EA7 - HQ to perform SPECIAL AFFILIATE PROCESSING

(will place AGReement in PERmission files for each member)
Provider Requester
THE TIME-INITIATED SPECIAL AFFILIATE

Display PERmission
PROCESSING UTILITY MUST RUN BEFORE file
CONTINUING
PAPER*

Adding a Member
Madrid Travel (DU6) decides to join the affiliate, EUROP. In this scenario, EUROP has an
In DU6 - NEW agency designates HQ
PAHDQA/EA7
In EA7 - HQ adds the new agency to the AFFILIATE (members section)
In EA7 - HQ to perform SPECIAL AFFILIATE PROCESSING

(to place the NEW MEMBER into everyone's PERmission files)
Provider Requester
Display PASAP table
PASAP*

PROCESSING UTILITY MUST RUN BEFORE
CONTINUING
Display PERmission files
PAPER*

Deleting a Member
Madrid Travel (DU6) decides to leave the affiliate, EUROP. In this scenario, EUROP has an
In EA7 - HQ performs SAP autodeletion to delete the departing member from
the PERmission files of the Affiliate members
PASAPDEA7@EUROP/DU6
Display PASAP table
PASAP*

CONTINUING
Display PERmission
files
PAPER*
In EA7 - HQ delete leaving member's pseudo from the AFFiliate
PAAFFD/EUROP/DU6
Display Affiliate
PAAFF*@EUROP
In DU6 - LEAVING MEMBER deletes HQ
PAHDQD

Changing an Agreement Number
To change an agreement number, you need to delete the agreement from the authorisation
section of the affiliate file and then add it with the updated information. The SAP then
replaces the original agreement number with the new one.
In EA7 - HQ deletes the agreement from the authorisation section for EUROP
Provider Requester
PAATHD/EUROP/EA7@EUROP
In EA7 - HQ adds the new agreement to the affiliate file EUROP
PAATHA/EUROP/EA7@EUROP/25/EU
In EA7 - HQ performs Special Affiliate Processing to replace the new

agreement in all of EUROPs members' permission files

The members of affiliate EUROP decide to end their business relationship with each other.
In this scenario, EUROP has an agreement between its own members, but not with any
other party.
In EA7 - HQ performs autodeletion to undo the agreement that the Affiliate members
have with each other i.e. delete the agreement from the PERmission files
PASAPDEA7@EUROP/EA7@EUROP

CONTINUING
In EA7 - HQ deletes the Affiliate file
PAAFFD/EUROP
In all INDIVIDUAL PSEUDOS - delete HQ
PAHDQD

Between Two Affiliates
Adding an Agreement
Affiliate codes EA7/EUROP and X3N/MIDEA decide to form a business relationship with
each other.
In EA7/EUROP - HQ to choose AGREEMENT number
In X3N/MIDEA - HQ to choose AGREEMENT number
In EA7/EUROP - HQ to BUILD CUSTOMISER
N/A
DO YOU WISH TO CUSTOMISE Yes
THE AGREEMENT? In X3N/MIDEA - HQ to BUILD CUSTOMISER
N/A
No
In EA7/EUROP - HQ to ADD Agreement with the other

AFFILIATE
Provider Requester
In X3N/MIDEA - HQ to ADD Agreement with the other

AFFILIATE
Provider Requester
PAATHA/MIDEA/EA7@EUROP/214
In EA7/EUROP- HQ to perform Special Affiliate Processing

their own members
In X3N/MIDEA - HQ to perform Special Affiliate Processing

- to place Agreement into the Permission file of each of their own
members
PASAPRX3N@MIDEA /EA7@EUROP

Adding a Member
Madrid Travel (DU6) decides to join the affiliate, EUROP. In this scenario, EUROP has an
agreement between its own members and with another affiliate MIDEA.
In DU6 - NEW MEMBER designates HQ
PAHDQA/EA7
In EA7/EUROP - HQ adds the new agency to the AFFILIATE (members

section)
In EA7/EUROP - HQ to perform SPECIAL AFFILIATE PROCESSING

to place the NEW MEMBER into it's own Affiliate members' PERmission file
In EA7/EUROP - HQ to place MIDEA pseudos into the new member's
PERmission file, i.e. The agreement EUROP is giving MIDEA
In X3N/MIDEA - HQ for which the existing AFFILIATE has agreements

- ADD the NEW MEMBER (in EUROP) to their OWN MEMBERS' PERmission
file

Deleting a Member
Madrid Travel (DU6) decides to leave the affiliate, EUROP. In this scenario, EUROP has an
agreement between its own members and with another affiliate MIDEA
In EA7/EUROP - delete the pseudo city from the Permission files of the Affiliate
members
PASAPDEA7@EUROP/DU6
THE TIME-INITIATED SPECIAL AFFILIATE PROCESSING

UTILITY MUST RUN BEFORE CONTINUING
In EA7 - HQ delete the pseudo city code of the departing member from the Affiliate
members section
PAAFFD/EUROP/DU6
In X3N/MIDEA - HQ OTHER AFFILIATE delete the departing MEMBER's pseudo from

their members' permission file
PASAPDX3N@MIDEA/DU6
THE TIME-INITIATED SPECIAL AFFILIATE PROCESSING

UTILITY MUST RUN BEFORE CONTINUING
In EA7/EUROP HQ - delete ALL the In DU6 - DEPARTING PSEUDO - delete

PERmission files for the departing PERmission files not required for all
pseudo! (BUT ensure that NONE are affiliate members
required)
PAPERD/DZ2 (MIDEA) etc.
PADELDDU6/PER
In DU6 - DEPARTING PSEUDO - delete

HQ
PAHDQD

Affiliate EUROP and affiliate MIDEA decide to end their business relationship. In this
scenario, EUROP has an agreement between its own members and an agreement with the
affiliate MIDEA. EUROP plans to maintain the agreement between its own members.
In EA7/EUROP - HQ deletes the MIDEA agreement from the permission files of the
members of EUROP
PASAPDEA7@EUROP/X3N@MIDEA
In X3N/MIDEA HQ- deletes the EUROP agreement from the permission files of the
members of MIDEA
PASAPDX3N@MIDEA/EA7@EUROP

CONTINUING
In EA7/EUROP - HQ deletes the MIDEA agreement in the AUTHorisation section
In X3N/MIDEA - HQ deletes the EUROP agreement in the AUTHorisation section
PAATHD/MIDEA/EA7@EUROP

Between an Affiliate and an Individual Agency
The affiliate EUROP negotiates a business agreement with an individual agency, Andes
Travel (XX8) located in Chile. They will service the needs of each other’s customers when
they are travelling in each other’s countries.
In EA7/EUROP - HQ to decide which AGREEMENT NUMBER

to give the Agency
PAAGRF = 49
In XX8 - AGENCY to decide which AGREEMENT NUMBER to
give the Affiliate
PAAGRF = 67
In EA7/EUROP-HQ to BUILD CUStomiser
N/A
DO YOU WISH TO
CUSTOMISE THE Yes
AGREEMENT? In XX8 - AGENCY to BUILD CUStomiser
N/A
No
In EA7/EUROP- HQ must ADD the agreement they are

providing to the AGENT
- to the AUTHORISATION section of the AFFILIATE file
PAATHA/EUROP/XX8/49
Note: No description is required otherwise
this will be read as an affiliate
in XX8 - AGENCY
N/A
In EA7/EUROP - HQ ADDS the agreement with the AGENCY

- to the PERmission file of each of it's AFFILIATE members
PASAPREA7@EUROP/XX8
In XX8 - AGENCY ADDS the agreement with the AFFILIATE

to it's own PERmission file - combining SAP/PERmission
entry
PASAPRXX8/EA7@EUROP/67

Affiliate EUROP and Andes Travel decide to end their business relationship. In this
scenario, EUROP also has an agreement between its own members, which it plans to
maintain.
In EA7/EUROP - HQ performs SAP autodeletion to delete the XX8 agreement

from the PERmission files of its members
PASAPDEA7@EUROP/XX8
In XX8 - Individual agency deletes the EUROP agreement from its

PERmission file
PASAPDXX8/EA7@EUROP

CONTINUING
In EA7/EUROP - HQ deletes the agreement from the AUThorisation section

of their AFFiliate file
PAATHD/EUROP/XX8

Appendix C: Agreements with Apollo® Agencies
This appendix deals with Galileo ® agencies forming business

arrangements with Apollo agencies. In order for Galileo agencies
to service bookings made in Apollo® (and vice-versa), Selective
Access™ agreements must be in place across the CRSs in both
directions.
Apollo® bookings can be serviced by using either Switchable

Access or, as is more common, Global Access™.
Points to note:
This appendix deals with Galileo® agencies servicing bookings
made in Apollo®.
In Apollo, a Booking File is referred to as a Passenger Name
Record (PNR).
Agencies set up for Switchable and/or Global Access can connect
to both Galileo® and Apollo® from one terminal.
Apollo® SAP times are 0800, 1100, 1515 and 2100 Mountain time.
Features and Benefits – Switchable Access and Global Access™

The table below summarises the functionality for Switchable
Access and Global Access™, providing that the Selective
Access™ agreement in place allows this functionality.
Switchable Access: Global Access:
You must switch into Apollo® with the entry: ##1V No switching entries are required
Then switch back to Galileo®: ##1G
A separate Apollo sign-on is required. No Apollo sign-on is required.
® ®
Once switched, in Apollo you may retrieve a PNR, In Galileo , you may retrieve a PNR, Apollo PRO-
PRO-files etc. using the majority of Galileo formats, files etc. using your standard Galileo entries.
known as ‘Common’ formats.
Note: For document production and fare servicing, you
will need to use Apollo formats.
You may view a PNR’s history. It is not possible to view an Apollo PNR history in
Galileo®.
Note: Switchable Access™ is also used for loading

PrivateFares™ as these fares must be loaded in Apollo®. A
Selective Access agreement does not have to be in place for
loading PrivateFares™.

Appendix C: Agreements with Apollo Agencies
Switchable Access
If your agency does not use Global Access™ or prefers to service
Apollo bookings in the Apollo ® system, then you would use
Switchable Access. You will need to switch into your secondary
system, Apollo®, and sign on before retrieving the PNR.
Retrieving a PNR in Apollo®
The steps are as follows to retrieve a PNR by switching into

Apollo®:
1. Switch to Apollo: ##1V or 6C1V
Note: When a terminal has been switched off and then back
on again, it will access the CRS that was active when it was
switched off.
2. Sign on to Apollo. You must have a separate sign-on code for
each CRS. The sign-ons are used when accessing each
system for the first time in a session.
Note: It is not necessary to sign off before switching to the
other system.
3. Retrieve and service the PNR using the Galileo common
formats. These are the entries in the Format Guide with a 
next to them or use the Galileo help pages: HELP COMMON.
Note: Where common formats are not available, native Apollo
inputs must be used.
4. Sign off from Apollo®.
5. Switch back to Galileo® to return to normal working: ##1G or
6C1G
Global Access™
Global Access unites Galileo® and Apollo® and enables travel
agencies to service effectively the needs of global travellers.
Global travellers are defined as those who make their initial

reservations at an agency using either Galileo or Apollo, and who
require further assistance during their travels at a related agency
who uses the other CRS.
Agencies set up for Global Access have access to both Galileo

and Apollo from one terminal without switching or signing on
again.

What functionality can I perform in the Galileo system with reference to an Apollo ® agency?
You may perform all functionality that is allowed in the agreement

you have been given. This could include items such as:
Booking File servicing
This enables an agent to retrieve in Galileo, PNRs held in
Apollo. The PNR may be updated, and tickets and
itineraries produced from the Galileo system.
Client information
In Galileo, this enables you to display, retrieve and move client
information and use TravelScreen preferences that were
created in Apollo. Information is stored in Apollo ® in the
form of a PRO-file, and retrieved in Galileo ® in the form of a
Client File.
Queuing
Booking Files/PNRs may be queued between Galileo and
Apollo.
Global MIR
This enables you to send and receive back-office information
in the form of a Global MIR between Galileo® and Apollo®.
Booking File Servicing
Global Access™ allows a Galileo agency to retrieve in Galileo a

PNR created in Apollo®. Once the PNR has been retrieved,
amendments may be made to the itinerary and specific customer
data sections, and tickets and itinerary/invoices may be issued.
Retrieving a PNR
When the Galileo agency retrieves an Apollo PNR, they are in

effect borrowing a copy of it from Apollo. Changes made by the
Galileo agency will be transmitted to Apollo ® at end transaction,
and the master booking in Apollo will be updated. Ownership
does not change.
Note: If the Galileo agency updates an Apollo PNR and enters ER

to end and retrieve, it may initially be displayed again in its original
form. Synchronisation messages are sent on end transaction to
update the original booking, and some moments are needed for
those to take effect in the original Apollo PNR. A subsequent input
IR (ignore and retrieve) should display the updated booking.

Global Information Area
The Global Information area of the PNR is used to store data,

which cannot be translated into equivalent fields during the
retrieval process. Data is stored for information only, and may only
be amended by the Apollo agency that owns the PNR.
If a field is added to the Booking File, which cannot be translated

from one CRS to the other, it will be permanently stored in the
Global Information area.
Note: It is recommended that an agency always reviews the

Global Information area before working a PNR.
Fields that do not translate
The following Apollo data fields do not translate, and will always
be stored in the Global Information area:
Ticketing field
Stored fares with/without ticketing modifiers
Queue minder
Value added tax itinerary remarks
Note: As a general rule, when the number of characters allowed

in a specific field exceeds the maximum number permitted in a
Galileo Booking File, the data will be placed in the Global
Information area.

Retrieval
Once an Apollo PNR is retrieved in Galileo ®, if the Global

Information area exists, it will be indicated in the face of the PNR.
Example:
You may tab and display the Global Information area:
Response:

Keywords
The following keywords may appear in the Global Information area

to describe each item of information:
Keyword: Description:
ADRS Address
CFMA Client File marry
CTCX Contact/phone field
CUST Customer identifier
DLVR Delivery address
FARE Fare data
GRMK General remarks
IRMA Associated itinerary/invoice remarks
IRMU Unassociated itinerary/invoice remarks
NREL Name related items
NRMK Name field remarks
NXTM Ticketing data
RBKG Review booking
QMDR Queue Minder
RCVD Received from field
RQSV Request for servicing
SEAT Seat data
SSR Service information
TINS TINS data
TKTD Ticketing arrangement
TRMK Ticket remark
UNKN Unknown data
VLOC Vendor locator

Global Booking File Header Identification
When an Apollo® PNR is retrieved by a Galileo agency, the header

displays the name of the owning CRS:
If the Selective Access™ agreement does not allow the borrowed

Apollo PNR to be updated, a warning message displays on the
second line:

Queues
Booking Files may be queued between Galileo and Apollo

agencies. Additionally, it is possible to queue the same Booking
File to Galileo and Apollo agencies and to more than one queue,
in any one input.
Queue history
Queue history is maintained in the CRS that owns the global

Booking File.
Queue ticketing
If the Galileo queue ticketing process encounters a global Booking

File, the Galileo system will reject it to queue 14.
Moving queues
It is not possible to move Booking Files (queue bounce) from one

CRS to another.
Global MIR
When a booking is created in Galileo for a global traveller whose

reservations are normally made in Apollo, it may be necessary to
send details of the booking to the back-office system of the original
Apollo agency. This ensures that the detail of the global traveller's
booking is kept up-to-date, regardless of the CRS in which the
changes were made.
Members of multi-national companies may be required to send a

Global MIR to the back-office system of the multi-national
company, so that records may be kept centrally. Where this is
required, all member agencies will have full details of the
procedures to follow.
Step-by-Step Procedures
This section covers the Selective Access™ step-by-step process if
servicing and setting up agreements for:
Switchable Access
Global Access™
Receiving Global MIRs

Switchable Access
To be able to perform Switchable Access functionality and share

data with another agency, an agreement is required in both
directions between your Apollo pseudo and the Apollo agency that
created the PNR.
Galileo Agent with secondary Apollo pseudo (JM1) and Apollo pseudo (IF3)
The set up could be similar to the diagram below for two individual
agencies:
Galileo agent Apollo agent
Galileo pseudo Apollo pseudo

EA7 IF3
PAPERA/JM1@Apollo Intl/1
PAPERA/IF3@Apollo Travel/2
Secondary Apollo
pseudo
JM1
Points to note:
The Apollo® pseudos could be group coded, then Selective
Access™ would not be required.
Agreements are set up in the same way for Apollo pseudos as
they are for Galileo pseudos.

Global Selective Access
For Global Selective Access servicing to be possible, one of the

following agreements would be in place between:
A Galileo agent and an Apollo agent
A Galileo affiliate which includes an Apollo agent
A Galileo affiliate and an Apollo affiliate
A Galileo affiliate and an individual agent
Galileo agent (DU6) and an Apollo agent (IF3)
To be able to perform Global Access™ functionality, an agreement

is required in both directions between your Galileo pseudo and the
Apollo agency that created the PNR. The set up could be similar
to the diagram below for two individual agencies:
Note: If transmission of Global MIRs is required, contact your

local Helpdesk as additional/different Global permission or SAP
entries are made by the providing pseudo who wishes to give
other agents permission to send them Global MIRs.
Scenario
Galileo agent (DU6) and Apollo agent (IF3) wish to service each
other’s Booking Files. However, DU6 only wishes IF3 to have
limited functionality of agreement 1 and thus customises the
agreement.
The procedure for both agents would be as follows:
PAPERA/1G@DU6@Galileo Travel/1
Galileo pseudo Apollo pseudo

DU6 IF3
PAPERA/1V@IF3@Apollo Travel/1/TW

Permission Files
Servicing is possible, subject to (customised) agreements.
Response in Galileo DU6:
Response in Apollo IF3:

Galileo affiliate (EUROP) with an Apollo member (IF3)
The 1G EUROP affiliate has an Apollo member (IF3) and they all
wish to service each other’s booking using agreement 2.
However, the SAP entry only works within the CRS in which it is
entered. Thus duplicate entries need to be made in the Apollo
pseudo in order to complete IF3’s permission tables with the
Galileo members of EUROP.
The procedure would be as follows:

EA7 IF3
Affiliate EUROP Build EUROP 'copy'

PAAFFB/ PAAFFB/
EUROP@EUROPEAN EUROP@EUROPEAN
IF3 must create a 'copy' of COPY/
OFFICES/
the EUROP affiliate to 1G@EA7@LONDON+
EA7@LONDON+
place the 1G pseudos in 1G@XC3@PARIS+
XC3@PARIS+
IF3's permission tables 1G@39CC@ATHENS+
39CC@ATHENS+
XX9@ZURICH+ 1G@XX9@ZURICH+
1V@IF3@APOLLO IF3@APOLLO
Authority between Authority between

EUROP EUROP 'copy' afiliate
PAATHA/EUROP/ PAATHA/EUROP/
EA7@EUROP/2 IF3@EUROP/2
Complete EUROPs permission Complete IF3's permission table

tables with EUROP agreement with EUROP 1G agreements
PASAPREA7@EUROP/ PASAPRIF3@EUROP/
EA7@EUROP IF3@EUROP
Note: This will put all EUROP's Note: This will put the IG members
pseudos, including 1V IF3, in of EUROP into IF3's permission
EUROP's IG permission tables. table.
But 1V IF3's permission tables will Thus servicing by IF3 for 1G's
be blank as you cannot SAP Booking Files will now be possible.
across CRS

Permission Files
Response in EA7 with reference to the Apollo pseudo:
Response in IF3 with reference to EA7:

Galileo® affiliate (EUROP) and an Apollo ® affiliate (EAST1)
In this example EUROP and EAST1 wish to service each other’s

Booking Files.
EUROP wishes to give EAST1 agreement 1
EAST1 wishes to give EUROP agreement 2
Permission Files
Response in EA7 with reference to the Apollo pseudo:
Response in JT9:

Galileo affiliate (EUROP) and an individual Apollo agent (GK4)
In this example affiliate EUROP and an individual Apollo agent

(GK4) are to form a business relationship.
Note: A reverse procedure is undertaken for a single Galileo

agency setting up with an Apollo affiliate.
Apollo agent
Galileo agent
GK4
EA7
Build EUROP 'copy'
Existing Affiliate EUROP PAAFFB/

GK4 must create a 'copy'
EUROP@EUROPEAN
of the EUROP affiliate
EA7@LONDON COPY/
to place the 1G pseudos
XC3@PARIS 1G@EA7@LONDON+
into GK4's permission
39CC@ATHENS 1G@XC3@PARIS+
table
XX9@ZURICH 1G@39CC@ATHENS+
1V@IF3@APOLLO 1G@XX9@ZURICH+
IF3@APOLLO
Authority provided by EUROP

'copy' affiliate to GK4
Authority provided by
EUROP to 1V GK4 PAATHA/EUROP/GK4/1
PAATHA/EUROP/1V@GK4/ Note: This step is a formality so

1/75 that there is an agreement in
both directions. (GK4 add's
agreement with EUROP in the
SAP entry)
Complete EUROPs 1G
permission tables with 1V GK4 Complete GK4 permission table
agreement with EUROP agreement
PASAPREA7@EUROP/1V@GK4 PASAPRGK4/GK4@EUROP/2
Note: This will put 1V GK4 into the Note: This will put the EUROP 'copy'
permission files of EUROP pseudos into GK4's permission table.
members.

Permission Files
Response in EUROP (EA7):
Response in 1V GK4:

Receiving Global MIRs
If you wish to send MIRs, agreements and entries are as per

Global Access set-up.
If you wish to receive MIRs, i.e. as the provider, you want to give
other agents permission to send you MIRS, then this requires you
to make different permission or SAP entries which refer to a Global
Permission Table. For these procedures you must refer to your
local Helpdesk.
Important note: There are other security items that must be in

place in order for the smooth transmission of MIRs. To fully set up
the transmission of Global MIRs, for one-to-one agreements or
between affiliates, contact your local Helpdesk.
Galileo agent (EA7) and Apollo agent (N17) sending Global MIRs
EA7 wishes N17 to service their Booking Files but, also to transmit
Global MIRS back to EA7 when necessary. As N17 is an Apollo
pseudo, Global MIRs cannot be transmitted between CRSs.
Therefore EA7 must have a secondary pseudo which will be an
Apollo one (JM1).
The Galileo agent via their Apollo pseudo (JM1) can then receive
MIRs from Apollo N17. An additional global agreement must be
set up between the providing MIR agency (JM1) and requesting
Apollo agency (N17).
The diagram below indicates the entries that can be made by you
for a one to one agreement.
PAPERA/1V@N17@MIR TRAVEL/2
Standard agreement to permit normal
servicing Apollo pseudo
N17
Galileo pseudo Provides 1G EA7 with
PAPERA/1G@EA7@UK Travel/286
EA7 agreement, but does
not need to receive
MIRs
PAPERGA/N17@MIR Travel/145
Global MIR agreement to permit
the sending of MIRS
Secondary Apollo pseudo
JM1
Global MIR sent from Apollo
primary system to receiving
Provides N17 with permission
secondary Apollo pseudo
to transmit GMIRS to JM1 by
at a Galileo site
adding the agreement to the
Global Permission Table
PAPERG*
Note: A reverse procedure is undertaken if the Apollo pseudo is

to receive the MIRs. The Galileo agency would simply set up a
normal servicing agreement with the Apollo pseudo, not involving
the Global Permission Table.

Permission Files
In EA7 (Primary)
PAPER*/1V@N17
PAPER*/1V@JM1
In 1V JM1 (Galileo agent’s secondary/interface Apollo

pseudo):
Response in the Global Permission Table - PAPERG*

In N17
PAPER*/1G@EA7
PAPER*/JM1

Apollo Formats
The table below lists some of the main Galileo formats when
working in a Global Access™ environment in the Galileo ® system
with an Apollo booking.
Description: Format:
Retrieval by passenger name *1V/**JT9-NAME/AMR

Retrieval by record locator *1V/*3IV3GP
Retrieval if pseudo is unknown *1V/**B-NAME
Transmitting a Global MIR from Galileo agency to an TKPDND.1V.JT9
Apollo agency
Places a Booking File on queue 35 at Apollo agency QEB/1V/JT9/35
JT9
Places a Booking File on queue 40 at Apollo agency QEB/1V/RH7/40+EA7/35
RH7 and queue 35 at Galileo agency EA7
Display agency PRO-file in JT9 C*1V/JT9/
Display business PRO-file in JT9 C*1V/JT9//CRAYOLA
Display personal PRO-file in JT9 C*1V/JT9//CRAYOLA-BROWN
Move a PRO-file from JT9 CMT/1V/JT9//CRAYOLA-BROWN

Appendix D: Troubleshooting
This appendix covers two areas:
Affiliate questions
Error responses
Affiliate Questions
Listed below are some of the most common questions and
suggested answers.
Can an HQ be HQ of more than one Affiliate
Yes. A headquarters may control several affiliates.
Does the HQ have to be in the Affiliate
No.
Can just one Agency be in an Affiliate
Yes. Sometimes this makes it easier to control as the

headquarters will be dealing with just affiliate entries.
Can an Agency be in more than one Affiliate
Yes although this would be very impractical as:

The pseudos would need to keep changing their HQ accordingly,
i.e. each time that headquarters made a PASAP entry.
You could have conflicting agreements if other pseudos were in
two affiliates.

Error Responses
You will receive an error response if you make an incorrect entry.
This troubleshooting table alphabetically lists possible error
responses, describes the cause and provides the corrective action
to take.
Error response: Cause: Corrective action:

ACCESS DENIED – Selective Access™ Try entry later.
SELECTIVE ACCESS – experienced a system problem
SYSTEM ERROR and cannot determine if
Selective Access is allowed.
ADD IGNORED – AFFILIATE Tried to add previously added No action necessary.
MEMBER ALREADY EXISTS pseudo city code to existing
affiliate.
AFFILIATE DOES NOT EXIST Made SAP entry with affiliate Verify affiliate code and re-enter
code that does not exist for SAP entry.
this pseudo city.
AFFILIATE DOES NOT EXIST Tried to add authorised affiliate Verify affiliate code and re-enter
user and the affiliate doesn’t format.
exist for this pseudo city.
AFFILIATE FILE ACCESS NOT Tried to display an affiliate file Verify affiliate code,
AUTHORIZED that the pseudo city has not headquarters’ pseudo city code,
been authorised to display. and your authorisation. Re-
enter format.
AFFILIATE FILE ACCESS NOT Tried to make SAP entry for an Verify affiliate code,
AUTHORIZED affiliate that the pseudo city headquarters’ pseudo city code,
has not been authorised to and your authorisation. Re-
update. enter format.
AFFILIATE FILE ALREADY Tried to build an affiliate file Select a new affiliate code and
EXISTS using an affiliate code, which re-enter format.
already exists for this pseudo
city.
AFFILIATE PERMISSION Tried to make SAP entry for an Add the agreement to the
DATA DOES NOT EXIST agreement that does not exist authorisation section and then
in authorisation section of the make SAP entry.
affiliate file.
AGENCY IS AN AFFILIATE Tried to add agreement Delete individual pseudo city
MEMBER between an affiliate and an from affiliate and re-enter
individual pseudo city and the format.
pseudo city is a member of the
affiliate.
AGENCY IS AN AUTHORIZED Tried to add a pseudo city to Delete agreement between
USER an affiliate and the pseudo city pseudo city and affiliate and re-
has an agreement with the enter format.
affiliate.
AGENT ID NUMBER Tried to add an agent ID No action necessary.
ALREADY EXISTS FOR number that already exists in
CUSTOMIZER the AID field.

AGENT NOT AUTHORIZED - Tried to build, add, change, or Have secondary authoriser
SELECTIVE ACCESS delete Selective Access files and change SELAC second
the agent’s STD profile SELAC indicator to YES.
second indicator is set to NO. Note: If you are a secondary
authoriser, ask your account
manager to have your first
indicator set to Y.
AGREEMENT NUMBER DOES Tried to enter a format including Verify agreement number and
NOT EXIST an agreement number that does re-enter format.
not exist.
AUTHORIZED AFFILIATE Tried to add an agreement that No action necessary.
USER ALREADY EXISTS already existed on the
authorisation section of the
affiliate file.
CHANGE IGNORED – Used a customiser change entry Use an add entry to add new
CUSTOMIZER DESCRIPTION to change a customiser customiser description.
DOES NOT EXIST description where one does not
exist.
CHANGE IGNORED – NO Tried to add a member Add pseudo city code and
AFFILIATE MEMBER FOUND description to an affiliate file, but member description to
the pseudo city is not an affiliate affiliate file.
member.
CHANGE IGNORED – QEB Used a customiser change entry Use an add entry to add a
NUMBER DOES NOT EXIST to change a QEB field where new QEB field.
one does not exist.
CHANGE IGNORED – QET Used a customiser change entry Use an add entry to add a
NUMBER DOES NOT EXIST to change a QET field where one new QET field.
does not exist.
CUSTOMER ID ALREADY Tried to add a customer ID code No action necessary.
EXISTS to a customiser file, which
already exists in the CID field.
CUSTOMIZER ALREADY Tried to build a customiser file Re-enter the format using a
EXISTS using a customiser code that different customiser code.
already exists.
CUSTOMIZER DESCRIPTION Tried to add a customiser No action necessary.
ALREADY EXISTS description, but one already
exists.
CUSTOMIZER ENTRY Tried to make an add or build Re-enter format with less
IGNORED – ENTRY TOO customiser entry exceeding 531 than 531 total characters.
LONG total characters.
CUSTOMIZER FILE ACCESS Non-headquarters agent tried to Have an agent from the
NOT AUTHORIZED display another pseudo city’s customiser pseudo city or the
customiser file. headquarters pseudo city
display the customiser file.
CUSTOMIZER ID DOES NOT Tried to enter a format including Verify customiser code and
EXIST a customiser code that does not re-enter format.
exist.

DELETE IGNORED – Tried to delete an agreement from Verify affiliate code and re-
AUTHORIZED AFFILIATE the affiliate file authorisation enter format.
USER DOES NOT EXIST section, which does not exist.
DELETE IGNORED – Tried to delete an affiliate Verify affiliate description
AFFILIATE DESCRIPTION description, which either does not and re-enter format.
DOES NOT MATCH match exactly or does not exist.
DELETE IGNORED - Tried to delete an affiliate Verify pseudo city of affiliate
AFFILIATE MEMBER DOES member, which does not exist in member and re-enter format.
NOT EXIST the affiliate file.
DELETE IGNORED – AGENT Tried to delete an agent ID (AID) Verify agent ID and re-enter
ID DOES NOT EXIST which does not exist in the format.
customiser file.
DELETE IGNORED – Tried to delete a business file title Verify business file title and
BUSINESS FILE TITLE DOES (BAR) which does not exist in the re-enter format.
NOT EXIST customiser file.
DELETE IGNORED – Tried to delete customer ID (CID) Verify customer identifier
CUSTOMER ID DOES NOT which does not exist in the and re-enter format.
EXIST customiser file.
DELETE IGNORED – Tried to delete a customiser Verify customiser description
CUSTOMIZER DESCRIPTION description, which does not exist and re-enter format.
DOES NOT EXIST in the customiser file.
DELETE IGNORED - MEMBER Tried to delete member No action necessary.
DESCRIPTION DOES NOT description, which does not exist
EXIST in the affiliate file.
DELETE IGNORED -MEMBER Tried to delete a member Verify member description
DESCRIPTION DOES NOT description, which does not and re-enter format.
MATCH exactly match the description in
the affiliate file.
DELETE IGNORED – NO Tried to delete an affiliate No action necessary.
AFFILIATE DESCRIPTION description, which does not exist
in the affiliate file.
DELETE IGNORED – NO Tried to delete headquarters No action necessary.
HEADQUARTERS when headquarters was not
DESIGNATED designated.
DELETE IGNORED – Tried to delete personal file title Verify personal file title and
PERSONAL FILE TITLE DOES (PAR) which does not exist in the re-enter format.
NOT EXIST customiser file.
DELETE IGNORED – Tried to delete a PrivateFares™ Verify account code and re-
PRIVATE FARES ACCOUNT account code, which does not enter format.
CODE DOES NOT EXIST exist in the customiser file.
DELETE IGNORED – Tried to delete a PrivateFares Verify agent ID and re-enter
PRIVATE FARES AGENT ID agent ID, which does not exist in format.
DOES NOT EXIST the customiser file.
DELETE IGNORED – QEB Tried to delete a QEB number, Verify QEP number and re-
NUMBER DOES NOT EXIST which does not exist in the enter format.
customiser file.
DELETE IGNORED – QET Tried to delete a QET number, Verify QET number and re-
NUMBER DOES NOT EXIST which does not exist in the enter format.
customiser file.


DIFFERENT AGREEMENT Tried to add a pseudo city code No action necessary.
EXISTS FOR to the permission file and an
agreement already exists for that
pseudo city.
DOCUMENT ISSUANCE Tried to issue a ticket or other Have provider change to an
DENIED – SELECTIVE document and the agreement agreement with the DOC
ACCESS UNAUTHORIZED DOC PRD field is set to NO. PRD field set to YES, and re-
enter format.
ENTRY DOES NOT MATCH Tried to add information to AID, If the customiser display
EXISTING FIELD CID, BAR, or PAR customiser shows fields with -
PARAMETER field, which doesn’t conform to EXCLUDING, add only
existing, inclusive or exclusive excluded items.
field parameters. If the customiser display
shows fields without -
EXCLUDING, add only
included items.
EOK - PNR NOT CREATED Tried to create a PNR on behalf For future PNRs: Have
FOR PSEUDO CITY of the provider, but the PNR provider change to an
CRE field is set to NO. agreement with PNR CRE set
Note: PNR is end transacted to YES.
but is controlled by the requester
pseudo city.
HEADQUARTERS ALREADY Tried to designate a To change to a different
EXISTS headquarters when one is headquarters, delete existing
already designated. headquarters and add new
one.
HEADQUARTERS NOT Special affiliate processing Have pseudo city designate
DESIGNATED BY encountered a pseudo city which headquarters and re-run
does not have headquarters special affiliate processing.
designated.
Note: This alert appears in the
supervisory message queue.
MAXIMUM NUMBER FOR Requested agreement file Re-enter format requesting
AGREEMENT DISPLAY IS 10 display with more than 10 no more than ten specific
specific agreement numbers. agreement numbers.
MESSAGE NOT PLACED ON Tried to send a supervisor Have provider change to an
QUEUE – SELECTIVE message and the agreement agreement with the QES IN
ACCESS QES IN field is set to NO. field set to YES, and re-enter
format.
NO AFFILIATE FILE FOUND Entered an affiliate file display, Verify affiliate code and re-
change, or delete format for an enter format.
affiliate code that does not exist.
NO AFFILIATE HISTORY Tried to display affiliate file No action necessary.
EXISTS history when none exists.
NO AFFILIATES FOR THIS Tried to display a list of affiliate No action necessary.
AGENCY files and none exist.
NO AGREEMENT EXISTS Tried to build a Custom Check™ Have provider add agreement
FOR PSEUDO CITY rule on behalf of provider and to the permission file with the
the agreement file RUL BLD field RUL BLD field set to YES,
is set to NO. and re-enter format.


NO AGREEMENT EXISTS FOR Tried to access the provider’s Have provider add
PSEUDO CITY functions through Selective agreement to the permission
Access™ and no agreement file and re-enter format.
exist.
NO AUTHORIZED AFFILIATE Tried to display the authorisation No action necessary.
USERS EXIST FOR section of the affiliate file and no
agreements exist.
NO CUSTOMIZER HISTORY Tried to display customiser file No action necessary.
NO CUSTOMIZERS EXIST Tried to display all customiser No action necessary.
files and none exist for this
pseudo city.
NO DATA MATCHES Tried to display permission files Re-enter the format using
QUALIFIERS USED using pseudo city code (PCC), different or broader
affiliate code (AFF), effective qualifiers.
(EFF) or discontinue (DIS) date
qualifiers, or other qualifiers; and
no matches were found.
NO HISTORY FOUND FOR Tried to display affiliate file No action necessary.
REQUEST history or permission file history
when none exists.
NO MATCHING AGREEMENT Completed an agreement file find Complete fill-in format again
FOUND – CONTACT fill-in format (PAAGRF) and no using different values, or
SUPPORT DESK TO ADD matching agreement was found. contact the customer service
support centre to have an
agreement added.
NO MEMBERS TO DISPLAY Displayed an affiliate file that has Add members to the affiliate
no pseudo city codes in the file.
member section.
NO PERMISSION HISTORY Tried to display permission file No action necessary.
NO QUEUING PERFORMED – Tried to QEB a PNR to multiple Have pseudo city change
SELECTIVE ACCESS – CK pseudo cities and queuing is not QEB IN to YES and re-
CITY performed because at least one queue PNR.
pseudo city has QEB IN set to
NO.
NO SELECTIVE ACCESS Tried to delete all Selective No action necessary.
DATA TO DELETE Access™ files or specific
Selective Access files when no
data exists.
PERMISSION ENTRY Tried to add own pseudo city to No action necessary.
IGNORED – CANNOT USE the permission file.
OWN PSEUDO CITY
PERMISSION FILE ACCESS Non-headquarters agent tried to No action necessary.
NOT AUTHORIZED display another pseudo city’s
permission file.
PERMISSION FILE DOES NOT Tried to display permission file No action necessary.
EXIST and none exists.

PERSONAL FILE CREATE Tried to create provider’s Have the provider change the
DENIED – SELECTIVE personal file and the customiser customiser file to permit
ACCESS file prohibits access to that access and re-enter format.
personal file.
PERSONAL FILE DELETE Tried to delete provider’s Have the provider change the
personal file.
PERSONAL FILE DISPLAY Tried to display provider’s Have the provider change the
personal file.
PNR ACCESS DENIED – NO Tried to retrieve a provider’s Verify affiliate code and re-
AFFILIATE CODE EXISTS – PNR using an affiliate code but enter format.
SELECTIVE ACCESS no match is found for the affiliate
code entered.
PNR DISPLAY DENIED PER Tried to display provider’s PNR Have provider change to an
SELECTIVE ACCESS and the agreement PNR DIS agreement with the PNR DIS
AGREEMENT field is set to NO. field set to YES, and re-enter
format.
PNR UPDATE NOT ALLOWED Tried to update provider’s PNR Have provider change to an
– SELECTIVE ACCESS and the agreement PNR UPD agreement with the PNR UPD
AGREEMENT – PNR field is set to NO. Note: PNR is field set to YES, retrieve
IGNORED ignored. PNR, and re-enter format.
PRIVATE FARES ACCESS Tried to access provider’s Have provider change to an
NOT AUTH PrivateFares™ account and the agreement with the PVT FAR
agreement PVT FAR field is set field set to YES and re-enter
to NO. format.
PRIVATE FARES ACCOUNT Tried to enter a PrivateFares™ No action necessary.
CODE ALREADY EXISTS account code in a customiser file
when it already exists.
PRIVATE FARES AGENT ID Tried to enter a PrivateFares™ No action necessary.
ALREADY EXISTS account code in a customiser file
when it already exists.
PROCESSING COMPLETED Message placed in the No action necessary.
supervisor message queue
when SAP has been completed.
PROVIDER PSEUDO CITY Tried to request access to Have provider add agreement
DOES NOT HAVE provider’s files and no to the permission file.
AGREEMENT WITH agreement exists between
provider and requester.
QES OUT NOT ALLOWED – Tried to queue a supervisor Have provider change to an
SELECTIVE ACCESS message and the QES OUT field agreement with the QES OUT
is set to NO. field set to YES and re-enter
format.
QET NUMBER ALREADY Tried to add a QET number to No action necessary.
EXISTS FOR CUSTOMIZER an existing customiser file where
the QET number already exists.

Error Response: Cause: Corrective action:
QET NUMBER NOT MATCHED Tried to delete QET number on Verify QET number and re-
– SELECTIVE ACCESS a customiser file and number enter format.
entered does not match the
number on the customiser file.
RESTRICTED Tried to delete a Custom Have provider change to an
Check™ rule and the RUL RMV agreement with the RUL RMV
field is set to NO. field set to YES.
SAME AGREEMENT Tried to add pseudo city code to No action necessary.
ALREADY EXISTS FOR permission file, but an
agreement already exists for
that pseudo city.
SELECTIVE ACCESS NOT Tried to borrow data from the Try later or call the Helpdesk.
ACTIVE ON PROVIDER Apollo® system and Selective
SYSTEM Access™ is not enabled on
®
Apollo .
SELECTIVE ACCESS NOT Tried to borrow data from the Try later or call the Helpdesk.
ACTIVE ON REQUESTER Apollo® system and Selective
SYSTEM Access™ is not enabled on
Galileo®.
SELECTIVE ACCESS STILL Entered a format to delete all Tab and enter to confirm
ACTIVE Selective Access™ files or deletion of files.
specific Selective Access files.
Note: This is a warning
message only.
UNABLE TO ADD – SAP Tried to make a SAP entry that No action necessary.
ENTRY ALREADY IN TABLE is already on the SAP table.
UNABLE TO CANCEL - PASAP Tried to cancel a SAP entry No action necessary.
ENTRY CURRENTLY while it is being processed.
PROCESSING
UNABLE TO CANCEL - PASAP Tried to cancel a SAP entry, Display files and make
ENTRY NOT IN TABLE which is not currently on the necessary changes
SAP table.

Appendix E: Worksheets and Entries
This appendix includes sample worksheets, which you can
duplicate, to help you work with the following files:
 Customiser file
 Affiliate file
Also included is a summary of Selective Access™ entries.

Customiser File Worksheet
(2 characters min/max - alpha/numeric)
(1-25 characters maximum - alpha/numeric)
QET QEB
Queue Automatically at ET Queue Manually

Customer Identification code Booking Files Agent Identification
(CUST field)

FAC PrivateFares FAI


Affiliate File Worksheet

Affiliate code:
(1-5 alphanumeric characters)
Affiliate description:
(1-25 alphanumeric characters)
Authorisation Section
Requester’s Requester’s Agreement Customiser Effective Discontinue

pseudo city affiliate number: code: date: date:
code: code:
Members Section
CRS code: Pseudo city Member description:

(if 1V) code:

Entry List
The following table lists the main Selective Access™ formats.
Note: When referring to Apollo® pseudos, type 1V@ before the
pseudo.
Agreement File
Display all agreements PAAGR*
Display multiple agreements PAAGR*/1+5+10
Display a range of PAAGR*/1–5
agreements
Display the fill-in-format PAAGRF
Customisers
Display all customisers PACUS*
Display a specific customiser PACUS*/ES
Build PACUSB/ES@ESSO/QET89/QEB80/AID-
ZXX8FB/CIDESSO/BARESSO
/PAR-ESSO-CHIEF/FACESSO/FAI-ZXX8FB
Add PACUSA/ES/CIDESSOUSA+ESSOJAP/BARESSOUSA+ESSOJA
P
Change PACUSC/ES@ESSO LONDON/QET50/QEB55
Note: You may only change the description and/or queuing fields.
Delete individual fields PACUSD/ES/CIDESSOUSA/BARESSOUSA
Delete an entire customiser PACUSD/ES Tab and Enter
Delete all customisers PADELD/CUS Tab and Enter Warning! The history will also be
deleted.
Display history PACUSH/ES

Permission File
Display all agreements PAPER*
Display a specific agreement PAPER*/XX8
with a pseudo (XX8)
Add an agreement PAPERA/X3M@ESSO
IMPLANT/49/ES/EFF16JUN00/DIS31DEC01
Change the requester’s name PAPERC/X3M@SHELL IMPLANT
Delete an agreement with an PAPERD/X3M
individual agency
Delete all agreements PADELD/PER Tab and Enter Warning! The history will also be
deleted
Display history for an PAPERH/X3M
individual agency
Display history for all PAPERH
agencies
Affiliate File
Headquarters: Format:
Display headquarters PAHDQ*
Designate headquarters PAHDQA/EA7
Delete headquarters PAHDQD
Affiliate File: Format:
Display a list of affiliates PAAFF*
Display details of an affiliate (in the HQ) PAAFF*@EUROP
Display details of an affiliate in the members PAAFF*EA7@EUROP
pseudo (where EA7 is the HQ of EUROP)
Change the descriptive name of the affiliate PAAFFC/EUROP@NORTHERN EUROP
History PAAFFH/EUROP
Delete an individual affiliate file PAAFFD/EUROP Tab and Enter
Delete all affiliate files PADELD/AFF Tab and Enter
Warning! The history will also be deleted
Affiliate Members Section:
Build a new affiliate PAAFFB/EUROP@EUROPEAN
TRAVEL/EA7@LONDON TRAVEL+
XC3@PARIS TRAVEL+39CC@ATHENS
Add an affiliate member (before SAP) PAAFFA/EUROP/X90@COPENHAGEN
TRAVEL
Change the name of an affiliate member PAAFFC/EUROP/IT1@NAPLES TRAVEL
History for a specific member of an affiliate PAAFFH/EUROP/XC3
Delete an affiliate member (before SAP) PAAFFD/EUROP/X90

Authority Section:
Add agreement (between two affiliates) PAATHA/EUROP/X3N@MIDEA/1/MD/EFF03AU
G00/DIS31OCT01
Add an agreement (for an individual agency) PAATHA/EUROP/XX8/49
Delete agreements (amongst the same affiliate) PAATHD/EUROP/EA7@EUROP
Special Affiliate Processing: Format:
Display the table PASAP*
Add PASAPAEA7@EUROP/EA7@EUROP
Replace PASAPREA7@EUROP/X3N@MIDEA
Delete PASAPDEA7@EUROP/XX8
Cancel PASAPX/repeat entry to be deleted
History PASAPH
Deautomation of Selective Access™

Delete all Selective Access PADELD Tab and Enter Warning! All history will also be
deleted

Appendix F: Answer Key
This answer key refers to the Module Reviews.
1. Answer: No
2. Answer: No
Rationale: The fourth field of the OTH AUTH must be set to Y
3. Answer: Yes
Rationale: Even if one of the agencies (X) wishes the other (Y) to do nothing –
X must still provide Y with an agreement (10 allows nothing)
4. Answer: Between two individual agents
Rationale: Even though your agency is part of an affiliate, your individual

agency may still have an agreement with another individual agency
if required.
5. Answer: Permission file
Rationale: The permission file is your pseudo’s record of all agreements,

whether you have given an agreement just from your pseudo or if
you are part of an affiliate.

1. Answer: PAAGR*/18
1a. Answer: Yes
Rationale: As Booking File UPD is set to Y
1b. Answer: No
Rationale: As MAR DIS is set to N
1c. Answer: Yes
Rationale: As QEB OUT is set to Y
2. Answer: PAAGR*/1+2
2a. Answer: Agreement 1 QET = Y Agreement 2 QET = N
Rationale: You would use agreement 2 when you did not wish Booking Files
that have been ended by the requester to be sent back to your Q.
3. Answer: Nothing
Rationale: This agreement would be used in a situation where only one

agency wishes the other to service their bookings. There must be
an agreement in both directions for any Selective Access™
functionality.
4. Answer: 41
Rationale: Use the fill-in-format PAAGRF

Part 1
1. Answer: Agreement 39
2. Answer: PAPERA/X0F@EMPIRE TRAVEL/39/DIS31DEC00
Rationale: No EFFective date is required if the agreement begins

immediately.
Default Q is GEN or 1
Rationale The Booking File will fall on the above queue
3. Answer: PAPERD/xxx
Part 2
1. Answer: Agreement 11 PAPERA/X0F@EMPIRE TRAVEL/11
2. Answer: No, as you have not been given permission to do so
3. Answer: No, as you have not been given permission to do so
3. Answer: PAPERD/xxx


Adding an Agreement Between Members of the Same Affiliate
PAAGRF = 1 Display HQ
PAHDQ*
Designate/ADD HQ (each agency makes this entry - not HQ) Display CUStomiser
files
PAHDQA/XR5
PACUS*
HQ to Build CUStomiser
DO YOU WISH TO
CUSTOMISE THE Yes
AGREEMENT?
No
HQ to BUILD AFFILIATE MEMBERS section
PAAFFB/WORLD@WORLD INTL/
XR5@WORLD WINDSOR+X0F@WORLD
PARIS+XQ6@WORLD ROME Display list of
Note: The HQ XR5, is a member AFFiliates (HQ only)
PAAFF*
HQ to ADD AUTHORISATION section Display AFFiliate

(HQ only)
PAAFF*@
Provider Requester
WORLD
PAATHA/WORLD/XR5@WORLD/1/WI
Display AFFiliate
(Affiliate Members)
PAAFF*XR5@
WORLD
HQ to perform SPECIAL AFFILIATE PROCESSING
(will place AGReement in PERmission files for each member) Display PASAP
table
Provider Requester
PASAPRXR5@WORLD/XR5@WORLD PASAP*
Note: Add could be used instead of Replace
THE TIME-INITIATED SPECIAL AFFILIATE PROCESSING Display PERmission

UTILITY MUST RUN BEFORE CONTINUING file
PAPER*

Adding an Agreement Between Two Affiliates
This is an example of agreements between XR5/World and XQ0/Globe.
XR5/WORLD to choose AGREEMENT number Display CUStomiser

PAAGRF = 31 files
XQ0/GLOBE to choose AGREEMENT number
PAAGRF = 26
XR5/WORLD to BUILD CUSTOMISER
DO YOU WISH TO
CUSTOMISE THE Yes
XQ0/GLOBE to BUILD CUSTOMISER
AGREEMENT?
No
XR5/WORLD to ADD Agreement with the other AFFILIATE

Provider Requester
PAATHA/WORLD/XQ0@GLOBE/31/GI Display Affiliate file
PAAFF*@
XQ0/GLOBE to ADD Agreement with the other AFFILIATE
WORLD
Provider Requester Display Affiliate file

PAATHA/GLOBE/XR5@WORLD/26/WI PAAFF*@
GLOBE
XR5/WORLD to perform Special Affiliate Processing

their own members
Provider Requester
PASAPRXR5@WORLD/XQ0@GLOBE
Display PASAP table
XQ0/GLOBE to perform Special Affiliate Processing PASAP*

their own members
Provider Requester
PASAPRXQ0@GLOBE/XR5@WORLD


Adding an Agreement Between Two Individual Agencies
Windmill Travel - CHOOSE AGREEMENT
PAAGRF = 48
Empire Travel - CHOOSE AGREEMENT
PAAGRF = 48
Display CUStomiser
files
PACUS*
Windmill travel - BUILD CUSTOMISER
PACUSB/ET@EMPIRE TRAVEL/
QET50/QEB55/CIDPHILIPS/
BARPHILIPS
DO YOU WISH TO
CUSTOMISE THE Yes
AGREEMENT? Empire Travel - BUILD CUSTOMISER
PACUSB/WT@WINDMILL TRAVEL/
QET50/QEB55/CIDCOLA/
BARCOLA
No
Windmill Travel - ADD AGREEMENT to PERmission

file
PAPERA/X0F@EMPIRE TRAVEL/
48/ET/DIS31DEC00 Display PERmission
files
Empire Travel - ADD AGREEMENT to PERmission PAPER*
file
PAPERA/XR5@WINDMILL TRAVEL/
48/WT/DIS31DEC00

Appendix G: Consolidator Information
A consolidator is an agency that has negotiated special fare

agreements with airlines or tour operators and offers these to other
travel agencies, un-associated by means of Group Coding or
Selective Access.
Consolidator Functionality is a form of data sharing. It allows
communication between an agency and a consolidator, regardless
of the fact that they have separate Group Codes, or have a
Selective Access agreement in place with other agencies. A
Consolidator uses the queuing functionality to make
communication possible between them and the agency using its
services.
The originating agency creates a Booking File and queues it to the
consolidator's "queuing city". After the consolidator has taken
action on the Booking File, they may return it to the originating
agency or take ownership, (depending on the queuing input by the
originating agency).
Note: If Selective Access™ is activated and the SAID field of the
AAT changed to YES, the communication between the
consolidator and their agency network will be unaffected.
Consolidator Set-up
Travelport allocates a Consolidator City Code to each consolidator
company; this same code is used by all branches of the
consolidator company.
The AAT of each branch of the consolidator agency is set as
follows:
 The name of the agency is preceded with C/ in the NAME
field, e.g. C/CONSOL TRAVEL
 The Consolidator City Code is located in the CONS field in
the AAT, e.g. CONS-QXX
There is no special set up required for agencies using a
consolidator's services, all they need is to know is the consolidator
city code in order to queue their bookings.
Originating Agency Functions

An agency is able to:
 Queue Booking Files to a consolidator
 Specify change of Booking File ownership to the
consolidator
 Queue messages to a consolidator
Note: Agencies using the consolidator's services must queue
Booking Files to the Consolidator City Code. The consolidator
must advise this code to all agencies using its services.

Queuing a Booking File to a Consolidator

You have the option to specify a queue number when you queue a
Booking File to a consolidator. If no queue number is specified the
Booking Files will be placed on the consolidator's general queue,
Q1.
Example entry: QEB/QXX/45
Meaning: Queue booking to Consolidator City Code QXX, Q45.
If you queue a Booking File to a consolidator and subsequently
retrieve and end transaction, the consolidator will no longer be
able to retrieve it. This is a useful feature if you made an error
when you sent the Booking File to their queue.
If you still want the consolidator to be able to retrieve and action
the Booking File, you must queue the Booking File again. As a
reminder, a warning header displays in the Booking File on
retrieving it after it has been queued to a consolidator:
Example system response:
BOOKING FILE QUEUED TO CONSOLIDATOR - RE-QUEUE AT
END TRANSACT.
If one of the agency's branches takes over ownership of a Booking
File already on a consolidators queue, the Booking File removes
from queue. The same warning header, shown above, displays
upon retrieval, advising that the Booking File must be re-queued at
end transact.
Note: The history of the Booking File will reflect all queuing
functions performed, even if the Booking File has not been seen
by the consolidator.
Specify Change Of Booking File Ownership To The Consolidator

Occasionally a consolidator may wish to take ownership of a
Booking File from an agency. The agency must agree with the
consolidator.
In order to do this, the originating agency appends a Y to the
queue input to authorize a change of ownership on queuing the
Booking File to a consolidator. The consolidator takes ownership
when they end transact on the queued Booking File.
Example entries:
QEB/QXX/Y
Place booking on to general queue and give ownership of to the
consolidator.
QEB/QXX/45/Y
Place booking on Q45 and give ownership of to the consolidator.
Note: Once the consolidator has taken ownership of a Booking
File, the originating agency is no longer able to retrieve it.

Queuing a Message to a Consolidator

An agency may queue a message to the consolidator's general or
supervisor's message queue. The message is created as a
notepad item.
Example queue entries:
QEM/QXX
Queue to general message queue of consolidator QXX
QES/QXX
Queue to supervisor queue of consolidator QXX
Consolidator Agency Functions

A consolidator is able to:
 Retrieve a Booking File either from their consolidator city
queue or by record locator.
 Take any necessary actions and return the Booking File to
the originating agency.
 Redirect a Booking File to another of their consolidator city
queues
 Read messages received from agencies
 Send supervisor and general messages to agencies
Retrieving Booking Files from Queue

The consolidator agency must specify their Consolidator City Code
in the input when they retrieve Booking Files from queue,
otherwise the consolidator will view their normal pseudo city's
queues.
Example entries:
Q/QXX
Access queue 0 or queue 1
Q/QXX/45
Access queue 45
Once a Booking File has been retrieved from queue and end
transacted, the consolidator agency may only re-retrieve it using
the Booking File record locator. Once the Booking File has been
returned to the originating agency, or the originating agency has
end-transacted it, it can no longer be retrieved by the consolidator.

Re-queuing a Retrieved Booking File

A Booking File may be returned to the originating agency's general
queue Q1, or to a specified queue, after it has been actioned by
the consolidator agency. A Booking File may also be re-directed
to another queue within the consolidator city code.
Example entries:
QEB/R
Return Booking File to agency's general queue
QEB/R/45
Return Booking File to agency's queue 45
QEB/QXX/60
Place Booking File on own consolidator city queue 60
Note: If ownership has been transferred to the consolidator
agency they are not able to return the Booking File to the
originating agency.
Accessing Message Queues

The consolidator agency must specify their Consolidator City Code
in the input when they access messages, otherwise they will view
their normal pseudo city's queues.
Example entries:
QM/QXX
Read general message queue
QS/QXX
Read supervisor message queue
Queuing a Message to an Agency

A message may be queued to an agency's general message or
supervisor's message queue in the normal way, by specifying the
agent's pseudo city code in the input. The message must be
created as a notepad item.
Example entries:
QEM/AAA
Queue message to general queue of agency pseudo AAA
QES/AAA
Queue message to supervisor queue of agency pseudo AAA

Consolidator Functionality Enhancement
Overview
Consolidator Functionality Enhancement allows both sub-agents
and consolidators to specify which Booking File data can be
viewed during the fulfilment process. There is an Agency Rule
Table providing masking capability between sub-agents and
consolidators.
This enhancement provides the following functionality:
 Consolidator and sub-agent are able to view the ticket
number in *HTI (current and historical TINS data display)
when data masking is enabled by either the Consolidator
and/or sub-agent.
 Consolidator versus sub-agent able to view net fare data in
*HTI, *HTE/*TEn (E-ticket record display), *FFn/*FFALL
(filed fare display), *HFF (filed fare history display) and
*HTD (ticketing data history display) for Consolidator
issued tickets when data masking is enabled by the
Consolidator.
 A consolidator is able to display *HTE/*TEn for tickets they
issued subsequent to a sub-agent fare quote to check fares
when data masking is enabled.
 Consolidator and sub-agent able to view net fare data in
Focalpoint (*HTI, *HTE/*TEn, *FFn/*FFALL, *HFF and
*HTD) for tickets they have issued when data masking in
enabled.
Note: Sub-agent branch offices with the same group code and/or
authorized selective access agreements are able to view each
other’s net fare data when data masking is enabled.
Customer Benefit
 Secure viewing access of confidential data between
Consolidator and Sub-agent.
 Improve workflow efficiency between Consolidator and
Sub-agent.
 Reduction in manual processes.

Set Up/Security
AAT Settings
Booking File data masking capability is controlled by the MASK
field. Only Galileo core AATs are updated with this field which is
located in the Agency Descriptor section of the AAT.
It is a YES or NO field.
YES – allows masking capability
NO – inhibits masking capability
Note: The default is set to NO. Changes to the MASK field may
only be made by GSO.

Data Masking (for Sub Agencies only)

In a sub-agency/consolidator scenario, only the sub-agency AAT
MASK field must be set to yes.
Fare and ticketing information, except taxes, entered by a
consolidator is automatically masked when sub-agents, or any
pseudo city other than the consolidator pseudo city that created
the filed fare retrieves the Booking File. A sub-agent will still be
able to display the tax break down for a ticket issued by a
consolidator.
The following are Booking File fields that may be masked by a
sub-agent. Masked data is also masked when the history for that
booking is displayed.
Data Masking System Rules

Any bookings created by a masking user will be subject to the
following rules:
 Fare and ticketing Booking File (BF) fields entered by a
consolidator are automatically masked in Booking Files
owned by participating sub-agencies.
 Data masking rules for sub-agencies are held in a table
called Agency Rule Table. This table contains rules that
govern whether or not a specific field will display in a
Booking File and Booking File history.
 Users can display the entire table or display a specific rule.
Both tables are maintained (rule additions/deletions) by
Galileo support personnel. There are no duty code
restrictions to view (only).
 If the user is any other type of user (other than NDC/SMO
or agent/consolidator), all booking data is masked that can
potentially be masked (e.g.
CF/PH/RA/RU/DI/AD/AW/FP/MM/NP/CI/RQ)
Agency Rule Table

An agency rule table has been created to allow a sub-agent to
mask various fields within a Booking File from a consolidator’s
view. This functionality is similar to Selective Access.
To display the Agency Rule Table, enter COART*
Response:
Agency Rule Table
RuleCF/P /RA/RU/RI/DI/AD/AW/FP/MM/NP/CD/CI/RQ
001 Y Y Y Y Y Y N Y Y Y Y Y Y Y Y
002 Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y
003 Y N Y Y Y Y Y Y Y Y Y Y Y Y Y
004 Y Y Y N Y Y Y Y Y Y Y Y Y Y Y

Screen explanation:
Y – Yes, mask field from Booking File Display
N – No, do not mask field from Booking File Display
Rule – Rule Number
CF - Client File
P - Phone Field
RA – Associated Remarks
RU – Unassociated Remarks
RI – Itinerary Remarks
DI – Document Itinerary Remarks Data
AD – Delivery Address
AW – Written Address
FP – Form of Payment
MM – Mileage Plus Data
NP – Notepad (current and historical)
CD – Customer Data
CI – Customer Identifier Data
RQ – Enhanced Booking File Servicing
To display specific rule:

Enter: COART*001
Response:
Agency Rule Table
RULECF/P /RA/RU/RI/DI/AD/AW/FP/MM/NP/CD/CI/RQ
001 Y Y Y Y Y Y N Y Y Y Y Y Y Y Y

Restriction Table
Sub-agents may specify which Booking File fields they wish to
mask by associating a rule number with a PCC. The rule number
and PCC are stored in a restriction table called the Sub-agent
Control Table. This table is maintained by each PCC or a PCC
may designate a ‘host’ PCC to maintain their table for them.
The host maintenance scenario was established for National and
Multi-National accounts who would benefit from having a single
department/site maintain data masking restriction standards.
 Host pseudo city may be added to the Control Table by the
Sub-Agency or Host.
 Host must emulate Sub-Agency to add PCC to Agency
Control Table.
 Once added to Agency Control Table, the host is not
required to emulate the Sub-Agency in order to perform
maintenance.
 A host city is not required to have Selective Access and/or
Group Code affiliation with the PCC it is designated to host.
The host city is required to emulate the PCC in order to
perform maintenance.
Example of a Sub-agent Control Table:
Enter: COACT*
Response:
Host XXXX Agency Control Table
PCCRULE CF/P /RA/RU/RI/DI/AD/AW/FP/MM/NP/CD/CI/RQ
CO1001 Y Y Y Y Y Y N Y Y Y Y Y Y Y Y
CO2002 Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y
CO3 010Y Y Y Y Y Y N Y Y Y Y Y Y Y Y
Screen explanation:
Host – Pseudo City designated to maintain Agency Control Table
Y – Yes, mask field from Booking File Display
N – No, do not mask field from Booking File Display
PCC – Pseudo City Code
Rule – Rule Number
CF - Client File
P - Phone Field
RA – Associated Remarks
RU – Unassociated Remarks
RI – Itinerary Remarks
DI – Document Itinerary Remarks Data
AD – Delivery Address

AW – Written Address
FP – Form of Payment
MM – Mileage Plus Data
NP – Notepad (current and historical)
CD – Customer Data
CI – Customer Identifier Data
RQ – Enhanced Booking File Servicing
To display a rule assigned to specific Consolidator PCC.

Enter: COACT*CO1
Response:
Host XXXX Agency Control Table
PCCRULECF/P /RA/RU/RI/DI/AD/AW/FP/MM/NP/CD/CI/RQ
CO1001 Y Y Y Y Y Y N Y Y Y Y Y Y Y Y
Control Table History

A historical reference of every add and delete has been provided.
Sub-agencies and host cities can display Control Table History.
Host cities must emulate. Following is an example of Control
Table History.
Enter: COACTH*
Response:
TABLE HISTORY:C01
ADD ITEM 11MAR 1504ZC01/A0234567
(action, date, Greenwich time)(PCC and user ID)
COACT*J4Z
(user entry)
ADD HOST 28FEB 1552ZC01/A0234567
COCHDQA*501F
DEL HOST 28MAR 1552ZC01/A0234567
COCHDQA*501F
ADD RULE 28MAR 1552ZC01/A0234567
COCRTA/30

Security
Selective Access and Group Code security logic will not apply to
new data masking function. This includes the ability to display,
add or delete data from Consolidator and Sub-agency Control
tables.
Only a Sub-agency or Host city (if assigned) can display, add or
delete data from control tables.
New Descriptive Banner

A new banner, **CONFIDENTIAL DATA EXISTS** will display
when Booking File fields are designated as masked. The purpose
of the banner is to inform the viewer that not all Booking File
information will display. Advise is not supplied detailing what
specific fields are masked.
Only one banner will display regardless how many fields are
masked. When Booking File data is masked, the banner will
display at the bottom of the booking. This banner will display on
the main Booking File display, as well as the historical display.
Examples of the main Booking File display and historical display
follow.
Example of Booking File display with CONFIDENTIAL DATA
EXISTS at bottom of display:
L8Z888/18 XDBKR C681181 AG 91291233 22MAR
1.1CONSOLIDATOR/ENHANCEMENTS
1. UA 241 Y 01NOV ORDDEN HK1 0635 0804 O* E TU
2. F9 4333 Y 03NOV DENABQ PN1 0830 0940 TH
OPERATED BY FRONTIER JETEXPRESS HOR
** FILED FARE DATA EXISTS ** >*FF^
** MEMBERSHIP DATA EXISTS ** >*MM^
** VENDOR LOCATOR DATA EXISTS ** >*VL^
FONE-LONB/555555555
TKTG-T*
** CONFIDENTIAL DATA EXISTS **

Example of history display with CONFIDENTIAL DATA EXISTS at

bottom:
***** HISTORY L8Z888 *****
** ONLY ACTIVE PRODUCTS EXIST **
** ORIGINAL CREATOR **
RCVD-P/C681181
CRDT- XDB AG 18 1936Z/22MAR
** HISTORY **
HS UA 241 Y 01NOV ORDDEN NN/HS1 635 804 O
HS F94333 Y 03NOV DENABQ HS/NN1 830 940
HS AA2080 Y 12NOV ABQDFW HS/NN1 1522 1803
RCVD-P/C681181
CRDT- XDB/ IF3/1G AG 18 1936Z/22MAR
If a Booking File field currently displays with a header, the header
will continue to display when the field is designated as masked. If
no header is included in the current display, no header will be
included in display when the field is designated as masked.
Following are screen examples of Booking File fields with and
without headers.
Examples:
*AA – current display both written and delivery
address, does not contain header:
DLVR-GALILEO CENTRE EUROPE*MAIN ENTRANCE*GRD FLT EAST
CORE*KENTON*MIDD*P/HA39SP
ADRS-MS.BONNER*555 FIVE STREET*KENTON*MIDD*P/HA39SP
*AA – enhanced display:

*MM – current display mileage info, contains Mileage
Membership Data header:
** MILEAGE MEMBERSHIP DATA **
P 1. CONSOLIDATOR TW 1234567PM
*MM – enhanced display:
** MILEAGE MEMBERSHIP DATA **

Fares and Ticketing Data Masking

The masking of Fare/Ticketing data is done based on whether the
booking is subject to masking. If the creator/owner of the booking
has their MASK field in the AAT turned to YES, then the
Fare/Ticketing data in the booking is subject to masking,
irrespective of whether the issuing party (consolidator) has their
MASK field set to Y or N.
Fare data (active) – Only the agency who filed the fare can see the
fare.
Fare data (history) – Only the agency who filed the original fare
can see the history for that fare.
Ticketing data (history)
 If the agency filed all fares (and all fares that are now
historical) they can see all ticketing history in the Booking
 If the agency did not file any one fare (or any fare that is
now historical) they cannot see any ticketing history in the
Booking
 If the booking file contains mixed filed fares (i.e. fares
issued and ticketed by both the agent and the
consolidator), the ticketing history is masked to all.
Customer Examples:
The following examples are based on the assumption that data
masking is enabled by the Consolidator and Sub-agent, net fare
data is not loaded at the sell/ticket level and the fare quote
requestor and ticket issuer are the same.
1. Consolidator and Sub-agent will be allowed to view the ticket
number in *HTI (current and historical TINS data display) when
data masking is enabled by either the Consolidator and/or
Sub-agent.
Consolidator *HTI Display of Ticket Number prior to Enhancement:
** NO HISTORY TIN DATA **
** CURRENT TIN DATA **
CONFIDENTIAL DATA EXISTS
>
Consolidator *HTI Display of Ticket Number after Enhancement:

SAMPLE/ONE-/1253899009414/-SGD/1459.00/ET ◄ Consolidator Issued Ticket
>

Sub-Agent *HTI Display of Ticket Number prior to Enhancement:

>
Sub-Agent *HTI Display of Ticket Number after Enhancement:

SAMPLE/ONE-/1253899009414/-XXX/XXXXXXX/ET ◄ Consolidator Issued Ticket
2. The Consolidator versus the Sub-agent will be allowed to view

net fare data in the *HTI (Current and historical TINS data
display), *HTE/*TEn (E-ticket record display), *FFn/*FFALL
(filed fare display), *HFF (filed fare history display) and *HTD
(ticketing data history display) for Consolidator issued tickets.
 Only the Consolidator will be allowed to view net fare data
at which the Consolidator ticket was issued.
 Sub-agent view of net fare data for Consolidator issued
tickets will be masked.
Consolidator *HTI Display prior to Enhancement:
>
Consolidator *HTI Display after Enhancement:

>
Sub-Agent *HTI Display prior to Enhancement:

>
Sub-Agent *HTI Display after Enhancement:

SAMPLE/ONE-/1253899009422/-XXX/XXXXXXX/ET ◄ Consolidator Issued Ticket
>

Consolidator *HTE Display prior to Enhancement:

ELECTRONIC TICKET LIST BY *HTE
NAME TICKET NUMBER
*
END OF LIST
>
Consolidator *HTE Display after Enhancement:

TKT: 125 3899 009422 NAME: SAMPLE/ONE ◄ Consolidator Issued Ticket
ISSUED: 29JAN10 FOP:CHEQUE

PSEUDO: ZZ22 PLATING CARRIER: BA ISO: SG IATA: 98765432
USE CR FLT CLS DATE BRDOFF TIME ST F/B FARE CPN
ARPT BA 175 Y 16APR LHRJFK 1025 OK Y2 1
FARE GBP 479.00 TAX 103.00 GB TAX 53.00 UB TAX 213.00 XT

TOTAL SGD 1459.00
EQUIV SGD 1090.00
LON BA NYC 784.70 NUC784.70END ROE0.610424 XT 23.00

US7.00XA10.00XY16.00YC157.00YQ
)>
Sub-Agent *HTE Display prior to Enhancement:



TOTAL SGD 1459.00
EQUIV SGD 1090.00

US7.00XA10.00XY16.00YC157.00YQ
)>
Sub-Agent *HTE Display after Enhancement:


FARE XXX XXXXXX TAX 103.00 GB TAX 53.00 UB TAX 213.00 XT

TOTAL XXX XXXXXXX
EQUIV XXX XXXXXXX
FARE CALCULATION **CONFIDENTIAL DATA EXISTS**

TOUR CODE 1234

NOTE: A Selective Access agreement has to be in place between

the Consolidator and Sub-agency in order to view the HTE and TE
data between both parties as shown in the examples above.
If no Selective Access agreement, the Sub-agency will get the
following display as per current host functionality (and vice versa
for the Consolidator when viewing a ticket issued by the Sub-
agency):
>*HTE
UNABLE TO PROCESS ELECTRONIC TICKET DISPLAY
NO AGENCY AGREEMENT EXIST – ACCESS DENIED
>
Consolidator *FFn/*FFALL Display prior to Enhancement:
>*FF1
>
>*FFALL
>
Consolidator *FFn/*FFALL Display after Enhancement:

>*FF1
FQ1 - S1 AP 29JAN10 02/AG
P1 SAMPLE/ONE ADT G E 1253899009422
LON BA NYC 784.70Y2 NUC784.70END ROE0.610424
FARE GBP479.00 EQU SGD1090.00 TAX 103.00GB TAX 53.00UB
TAX 23.00US TAX 7.00XA TAX 10.00XY TAX 16.00YC TAX 157.00YQ
TOT SGD1459.00
***ADDITIONAL FEES MAY APPLY*SEE>FO1í
S1 FB-Y2 B-1PC
T S1/Z0/ET/FCK/CBA/NFSGD1090.00/AI-1234/TAZZ22 ◄ Consolidator Issued Ticket
>
>*FFALL
TOT SGD1459.00
S1 FB-Y2 B-1PC
>
Sub-agent *FFn/*FFALL Display prior to Enhancement:

>*FF1
TOT SGD1459.00
S1 FB-Y2 B-1PC


>
>*FFALL
TOT SGD1459.00
S1 FB-Y2 B-1PC
>
Sub-agent *FFn/*FFALL Display after Enhancement:

>*FF1
>
>*FFALL
>
Consolidator *HFF Display prior to Enhancement:

>*HFF
***** FILED FARE HISTORY KDCBSK *****
RCVD-
CRDT- SIN/ZZ22/1G AG 2106Z/29JAN
CONFIDENTIAL DATA EXISTS ◄ Consolidator Issued Ticket
>
Consolidator *HFF Display after Enhancement:

>*HFF

XFQ SAMPLE/ONE -ADT G SGD 1459.00 29JAN10
AOB SAMPLE/ONE -ADT TTLSGD 1459.00 29JAN10
AOB SAMPLE/ONE -ADT SGD 0.00 29JAN10
AFQ SAMPLE/ONE -ADT G 1253899009414◄ Consolidator Ticket
RCVD-
>

Consolidator *HTD Display prior to Enhancement:

>*HTD
***** TICKETING DATA HISTORY ZN502U *****
XT T*
CRDT- XDB/ZZ22/1G AG 02 2142Z/16JUL
>
Consolidator *HTD Display after Enhancement:

>*HTD
***** TICKETING DATA HISTORY ZN4XGA *****
XT T*
AT S01/ET/FCK/CBA/NFSGD1037.00/AI-1234 ◄ Consolidator Issued Ticket
RCVD-/C103025
>
Sub-agent *HFF Display prior to Enhancement:

>*HFF

XFQ SAMPLE/ONE -ADT G SGD 1459.00 29JAN10
AOB SAMPLE/ONE -ADT TTLSGD 1459.00 29JAN10
AOB SAMPLE/ONE -ADT SGD 0.00 29JAN10
AFQ SAMPLE/ONE -ADT G 1253899009414◄ Consolidator Ticket
RCVD-
>
Sub-agent *HFF Display after Enhancement:

>*HFF
RCVD-
>
Sub-agent *HTD Display prior to Enhancement:

>*HTD
***** TICKETING DATA HISTORY ZN4XGA *****
XT T*
AT S01/ET/FCK/CBA/NFSGD1037.00/AI-1234 ◄ Consolidator Issued Ticket
RCVD-/C103025
>

Sub-agent *HTD Display after Enhancement:

>*HTD
***** TICKETING DATA HISTORY ZN502U *****
XT T*
>
3. Consolidator will be allowed to view *HTE/*TEn for

Consolidator issued tickets subsequent to a Sub-agent fare
quote to check fares.
Consolidator *HTE for Consolidator Issued Ticket after Sub-agent
Fare Quote and prior to Enhancement:
NAME TICKET NUMBER
*
END OF LIST
>
Consolidator *HTE for Consolidator Issued Ticket after Sub-agent

Fare Quote and after Enhancement:


TOTAL SGD 1459.00
EQUIV SGD 1090.00

US7.00XA10.00XY16.00YC157.00YQ
)>

4. Consolidator and Sub-agent will only be allowed to view net

fare data in Viewpoint, Focalpoint *HTI, *HTE/*TEn,
*FFn/*FFALL, *HFF and *HTD for tickets they have issued.
Example:
Segment 1 Issued by Sub-agent
Segment 2 Issued by Consolidator
KDFHWW/02 XDBKR C103025 AG 12345678 29JAN
1.1SAMPLE/TWO
1. BA 902 Y 01JUN LHRFRA HK1 0730 1005 O* E TU ◄ Sub-agent Ticket
2. SQ 25 Y 08JUN FRASIN HK1 1235 #0630 O* E TU ◄ Consolidator Ticket
** FILED FARE DATA EXISTS ** >*FFí
** VENDOR LOCATOR DATA EXISTS ** >*VLí
** CUSTOM CHECK RULES EXIST ** >*RUí
FONE-SINT/
TKTG-T*
Consolidator Display
Examples follow:
Consolidator *HTI Display prior to Enhancement:
** HISTORY TIN DATA **
>
Consolidator *HTI Display after Enhancement:

XK SAMPLE/TWO-/1253899015762/-XXX/XXXXXXX/ET ◄ Sub-agent Issued Ticket
SAMPLE/TWO-/6183899009421/-SGD/6880.00/ET ◄ Consolidator Issued Ticket
>
Consolidator *HTE Display prior to Enhancement:

NAME TICKET NUMBER
*
*
END OF LIST
>
Consolidator *HTE Display after Enhancement:

NAME TICKET NUMBER
>*TE001í SAMPLE/TWO 1253899015762 ◄ Sub-agent Issued Ticket
>*TE002í SAMPLE/TWO 6183899009421 ◄ Consolidator Issued Ticket
END OF LIST
>

Consolidator *TE1 Display after Enhancement:

TKT: 125 3899 015762 NAME: SAMPLE/TWO ◄ Sub-agent Issued Ticket

PSEUDO: 11YY PLATING CARRIER: BA ISO: SG IATA: 12345678
OPEN BA 902 Y 01JUN LHRFRA 0730 OK YIF 1
FARE XXX XXXXXX TAX 25.00 GB TAX 53.00 UB TAX 41.00 YQ

TOTAL XXX XXXXXXX
EQUIV XXX XXXXXXX

TOUR CODE 1234
)>
Consolidator *TE2 Display after Enhancement:

TKT: 618 3899 009421 NAME: SAMPLE/TWO ◄ Consolidator Issued Ticket

PSEUDO: ZZ22 PLATING CARRIER: SQ ISO: SG IATA: 98765432
OPEN SQ 0025 Y 08JUN FRASIN 1235 OK YIF 1
FARE EUR 3344.00 TAX 13.00 DE TAX 48.00 RA TAX 141.00 YQ

TOTAL SGD 6880.00
EQUIV SGD 6678.00
FRA SQ SIN 4956.11 NUC4956.11END ROE0.674722

TOUR CODE 2345
)>
Consolidator *FFn/*FFALL Display prior to Enhancement:

>*FF1
>*FF1
CONFIDENTIAL DATA EXISTS ◄ Sub-agent Issued Ticket
>
>*FF2
P1 SAMPLE/TWO ADT G E 6183899009421
FRA SQ SIN 4956.11YIF NUC4956.11END ROE0.674722
FARE EUR3344.00 EQU SGD6678.00 TAX 13.00DE TAX 48.00RA
TAX 141.00YQ TOT SGD6880.00
S2 FB-YIF B-20K
T S2/Z0/ET/FCK/CSQ/NFSGD6678.00/AI-2345/TAZZ22 ◄ Consolidator Issued Ticket
>
>*FFALL
>*FFALL
CONFIDENTIAL DATA EXISTS ◄ Sub-agent and Consolidator Issued Tickets
>

Consolidator *FFn/*FFALL Display after Enhancement:

*FF1
CONFIDENTIAL DATA EXISTS ◄ Sub-agent Issued Ticket
>
>*FF2
S2 FB-YIF B-20K
>
>FFALL
S2 FB-YIF B-20K
>
Sub-agent Display
Examples follow:
Sub-agent *HTI Display prior to Enhancement:
>
Sub-agent *HTI Display after Enhancement:

XK SAMPLE/TWO-/1253899015762/-SGD/1215.00/ET ◄ Sub-agent Issued Ticket
SAMPLE/TWO-/6183899009421/-XXX/XXXXXXX/ET ◄ Consolidator Issued Ticket
>
Sub-agent *HTE Display prior to Enhancement:

NAME TICKET NUMBER
*
*
END OF LIST
>

Sub-agent *HTE Display after Enhancement:

NAME TICKET NUMBER
>*TE001í SAMPLE/TWO 1253899015762 ◄ Sub-agent Issued Ticket
>*TE002í SAMPLE/TWO 6183899009421 ◄ Consolidator Issued Ticket
END OF LIST
>
Sub-agent *TE1 Display after Enhancement:

TKT: 125 3899 015762 NAME: SAMPLE/TWO ◄ Sub-agent Issued Ticket

PSEUDO: 11YY PLATING CARRIER: BA ISO: SG IATA: 12345678
OPEN BA 902 Y 01JUN LHRFRA 0730 OK YIF 1
FARE GBP 482.00 TAX 25.00 GB TAX 53.00 UB TAX 41.00 YQ

TOTAL SGD 1215.00
EQUIV SGD 1096.00
LON BA FRA 789.61 NUC789.61END ROE0.610424

TOUR CODE 1234
)>
Sub-agent *TE2 Display after Enhancement:

TKT: 618 3899 009421 NAME: SAMPLE/TWO ◄ Consolidator Issued Ticket

PSEUDO: ZZ22 PLATING CARRIER: SQ ISO: SG IATA: 98765432
OPEN SQ 0025 Y 08JUN FRASIN 1235 OK YIF 1
FARE XXX XXXXXXX TAX 13.00 DE TAX 48.00 RA TAX 141.00 YQ

TOTAL XXX XXXXXXX
EQUIV XXX XXXXXXX

TOUR CODE 2345
)>

Sub-agent *FFn/*FFALL Display prior to Enhancement:

>*FF1
LON BA FRA 789.61YIF NUC789.61END ROE0.610424
S1 FB-YIF B-1PC
T S1/Z0/ET/FCK/CBA/NFSGD1096.00/AI-1234/TA11YY ◄ Sub-Agent Issued Ticket
>
>*FF2
>
>*FFALL
CONFIDENTIAL DATA EXISTS ◄ Sub-agent and Consolidator Issued Tickets
>
Sub-agent *FFn/*FFALL Display after Enhancement:

>*FF1
S1 FB-YIF B-1PC
T S1/Z0/ET/FCK/CBA/NFSGD1096.00/AI-1234/TA11YY ◄ Sub-agent Issued Ticket
>
>*FF2
>
>*FFALL
S1 FB-YIF B-1PC
T S1/Z0/ET/FCK/CBA/NFSGD1096.00/AI-1234/TA11YY ◄ Sub-agent Issued Ticket

5. Sub-agents with the same group code and/or authorized

selective access agreements will be allowed to view each
other’s net fare data when Sub-agent data masking is enabled.
Example:
Sub-agent B Creates Booking File and Issues Segment 1
Sub-agent A Issues Segment 2
Consolidator C Issues Segment 3
KDCLMA/02 XDBKR C103025 AG 12345678 29JAN
1.1SAMPLE/FIVE
1. SQ 12 Y 20JUN SINLAX HK1 0940 1255 O* E SU ◄ Sub-agent B
2. BA 282 Y 28JUN LAXLHR HK1 1735 #1145 O* E MO ◄ Sub-agent A
3. CX 252 Y 02JUL LHRHKG HK1 1235 #0710 O* E FR ◄ Consolidator C
** VENDOR LOCATOR DATA EXISTS ** >*VLí
** CUSTOM CHECK RULES EXIST ** >*RUí
FONE-SINT/
TKTG-T*
>
Sub-agent B Display
Examples follow:
*HTI Display prior to Enhancement:
>
*HTI Display after Enhancement:

XK SAMPLE/FIVE-/1253899016757/-SGD/2476.00/ET ◄ Sub-agent A
XK SAMPLE/FIVE-/6183899015799/-SGD/1455.00/ET ◄ Sub-agent B
SAMPLE/FIVE-/1603899009418/-XXX/XXXXXXX/ET ◄ Consolidator C
>
*HTE/*TEn Display prior to Enhancement:

ELECTRONIC TICKET LIST BY *THE
NAME TICKET NUMBER
*
*
END OF LIST
>
*HTE Display after Enhancement:
NAME TICKET NUMBER
>*TE001í SAMPLE/FIVE 1253899016757 ◄ Sub-agent A
>*TE002í SAMPLE/FIVE 6183899015799 ◄ Sub-agent B
>*TE003í SAMPLE/FIVE 1603899009418 ◄ Consolidator C
END OF LIST
>

*TE1 Display after Enhancement:

TKT: 125 3899 016757 NAME: SAMPLE/FIVE ◄ Sub-agent A

PSEUDO: RR55 PLATING CARRIER: BA ISO: SG IATA: 99999999
OPEN BA 282 Y 28JUN LAXLHR 1735 OK Y2US 1
FARE USD 1586.00 TAX 4.00 AY TAX 23.00 US TAX 212.00 XT

TOTAL SGD 2476.00
EQUIV SGD 2237.00
LAX BA LON 1586.00 NUC1586.00END ROE1.0 XT 205.00YQ

7.00XF LAX4.5
)>

TKT: 618 3899 015799 NAME: SAMPLE/FIVE ◄ Sub-agent B

PSEUDO: 11YY PLATING CARRIER: SQ ISO: SG IATA: 12345678
OPEN SQ 0012 Y 20JUN SINLAX 0940 OK YOWSG 1
FARE SGD 1100.00 TAX 28.00 SG TAX 8.00 OI TAX 319.00 XT

TOTAL SGD 1455.00
VALID SQ ONLY.QS--
SIN SQ LAX M791.83 NUC791.83END ROE1.38917 XT 16.00

SW23.00US7.00XA10.00XY16.00YC247.00YQ
)>

TKT: 160 3899 009418 NAME: SAMPLE/FIVE ◄ Consolidator C

PSEUDO: ZZ22 PLATING CARRIER: CX ISO: SG IATA: 98765432
USE CR FLT CLS DATE BRDOFF TIME ST F/B FARE CP
OPEN CX 252 Y 02JUL LHRHKG 1235 OK Y2OW1 1
FARE XXX XXXXXXX TAX 114.00 GB TAX 53.00 UB TAX 66.00 YR

TOTAL XXX XXXXXXX
EQUIV XXX XXXXXXX

TOUR CODE 1234
)>

*FFn/*FFALL Display prior to Enhancement:

>*FF1
CONFIDENTIAL DATA EXISTS ◄ Sub-agent A
>
>*FF2
CONFIDENTIAL DATA EXISTS ◄ Sub-agent B
>
>*FF3
CONFIDENTIAL DATA EXISTS ◄ Consolidator C
>
>*FFALL
CONFIDENTIAL DATA EXISTS ◄ Sub-agents A/B and Consolidator C
>
*FFn/*FFALL Display after Enhancement:

>*FF1
P1 SAMPLE/FIVE ADT G E 6183899015799 ◄ Sub-agent A
SIN SQ LAX M791.83YOWSG NUC791.83END ROE1.38917
FARE SGD1100.00 TAX 28.00SG TAX 8.00OI TAX 16.00SW
TOT SGD1455.00
S1 FB-YOWSG B-2PC
VALID SQ ONLY.QS--
T S1/Z0/ET/FCK/CSQ/TA11YY
>
>*FF2
P1 SAMPLE/FIVE ADT G E 1253899016757 ◄ Sub-agent B
LAX BA LON 1586.00Y2US NUC1586.00END ROE1.0 XF 7.00LAX 4.5
FARE USD1586.00 EQU SGD2237.00 TAX 4.00AY TAX 23.00US
TAX 7.00XF TAX 205.00YQ TOT SGD2476.00
S2 FB-Y2US B-1PC
T S2/Z0/ET/FCK/CBA/TARR55
>
>*FF3
>

>*FFALL
TOT SGD1455.00
S1 FB-YOWSG B-2PC
VALID SQ ONLY.QS--

S2 FB-Y2US B-1PC

>
Sub-agent A Display
*HTI Display prior to Enhancement:
>
*HTI Display after Enhancement:

XK SAMPLE/FIVE-/1253899016757/-SGD/2476.00/ET ◄ Sub-agent A
XK SAMPLE/FIVE-/6183899015799/-SGD/1455.00/ET ◄ Sub-agent B
SAMPLE/FIVE-/1603899009418/-XXX/XXXXXXX/ET ◄ Consolidator C
>
*HTE Display prior to Enhancement:

NAME TICKET NUMBER
*
*
END OF LIST
>

*HTE Display after Enhancement:

NAME TICKET NUMBER
>*TE001í SAMPLE/FIVE 1253899016757 ◄ Sub-agent A
>*TE002í SAMPLE/FIVE 6183899015799 ◄ Sub-agent B
>*TE003í SAMPLE/FIVE 1603899009418 ◄ Consolidator C
END OF LIST
>

TKT: 125 3899 016757 NAME: SAMPLE/FIVE ◄ Sub-agent A

PSEUDO: RR55 PLATING CARRIER: BA ISO: SG IATA: 99999999
OPEN BA 282 Y 28JUN LAXLHR 1735 OK Y2US 1
FARE USD 1586.00 TAX 4.00 AY TAX 23.00 US TAX 212.00 XT

TOTAL SGD 2476.00
EQUIV SGD 2237.00
LAX BA LON 1586.00 NUC1586.00END ROE1.0 XT 205.00YQ

7.00XF LAX4.5
)>
TKT: 618 3899 015799 NAME: SAMPLE/FIVE ◄ Sub-agent B

PSEUDO: 11YY PLATING CARRIER: SQ ISO: SG IATA: 12345678
OPEN SQ 0012 Y 20JUN SINLAX 0940 OK YOWSG 1
FARE SGD 1100.00 TAX 28.00 SG TAX 8.00 OI TAX 319.00 XT

TOTAL SGD 1455.00
VALID SQ ONLY.QS--
SIN SQ LAX M791.83 NUC791.83END ROE1.38917 XT 16.00

SW23.00US7.00XA10.00XY16.00YC247.00YQ
)>
*TE3 Display after Enhancement

TKT: 160 3899 009418 NAME: SAMPLE/FIVE ◄ Consolidator C

PSEUDO: ZZ22 PLATING CARRIER: CX ISO: SG IATA: 98765432
USE CR FLT CLS DATE BRDOFF TIME ST F/B FARE CP
OPEN CX 252 Y 02JUL LHRHKG 1235 OK Y2OW1 1
FARE XXX XXXXXXX TAX 114.00 GB TAX 53.00 UB TAX 66.00 YR

TOTAL XXX XXXXXXX
EQUIV XXX XXXXXXX

TOUR CODE 1234
)>

*FFn/*FFALL Display prior to Enhancement:

>*FF1
CONFIDENTIAL DATA EXISTS ◄ Sub-agent A
>
>*FF2
CONFIDENTIAL DATA EXISTS ◄ Sub-agent B
>
>*FF3
>
>*FFALL
CONFIDENTIAL DATA EXISTS ◄ Sub-agents A/B and Consolidator C
>
*FFn/*FFALL Display after Enhancement:

>*FF1
TOT SGD1455.00
S1 FB-YOWSG B-2PC
VALID SQ ONLY.QS--
>
>*FF2
S2 FB-Y2US B-1PC
>
>*FF3
>

*FFALL
TOT SGD1455.00
S1 FB-YOWSG B-2PC
VALID SQ ONLY.QS--

S2 FB-Y2US B-1PC

New Galileo Formats

Rule Table display formats may be entered used by all Galileo
Core users; there are no duty code restrictions. Agency Control
Table formats are specific to Sub-agency and Host pseudo cities.
Display Rule Table COART*
Display Specific Rule COART*001
Display Control Table COACT*
Display Specific PCC in Control Table COACT*C01
Add PCC and rule to Control Table COACTA*C01/001
Delete PCC from Control Table COACTD/C01
Add Host PCC to Control Table COAHDQA/GK5
Delete Host PCC from Control Table COAHDQD/GK5
Display Control Table History COACTH*
‘Host’ Display Control Table COACT/XXX* where XXX equals hosted PCC
‘Host’ Display Specific PCC in Control COACT/XXX*C01 where XXX equals hosted
Table PCC
Host’ Add PCC to Control Table COACTA/XXX*C01/001 where XXX equals

hosted PCC
‘Host’ Delete PCC from Control Table COACTD/XXX*C01 where XXX equals hosted
PCC
‘Host’ Display Control Table History COACTH/XXX* where XXX equals hosted
PCC

Agent Alerts
Incorrect format is entered to access Sub- CHECK FORMAT
agency;
 Rule Table
 Control Table
 Control Table History
Incorrect format is entered to add a host CHECK FORMAT
pseudo city code to a Sub-agency Control
Table.
User is not authorized to update Sub- NOT AUTHORIZED FOR TABLE
agency; UPDATES
 Rule Table
 Control Table
Pseudo City entered as host city is invalid. CHECK HOST CITY
When deleting a host city and the pseudo CHECK HOST CITY
city does not match city in the Sub-agency
Control Table.
Display the following agent alert when an NOT AUTHORIZED
unauthorized PCC tries to display the
following;
 Agency Control Table
 Agency Control Table History
Display the following agent alert when a CHECK RULE NUMBER
restriction is being added to the Agency
Control Table and the rule number doesn’t
exist;

Enhancement Assumptions
This product enhancement will impact all Galileo core users who
use the Consolidator product.
Data designated as masked, will mask on the ‘main’ Booking File
display as well as historical displays.
The **CONFIDENTIAL DATA EXISTS** banner will display at the
bottom of both the ‘face’ and history of a Booking File display.
If a Booking File field currently displays with a header, the header
will continue to display when the field is designated as masked. If
no header is included in the current display, no header will be
included in display when the field is designated as masked.
A Consolidator and Sub-agency can only view filed fares and
ticketing information that they themselves input.
Fare and Ticketing data will automatically be masked between
agents and consolidators.
Refunds and exchanges can only be done by the pseudo that
originally filed the fare and issued the ticket.
New Qualified Notepad Field

A new qualified notepad field has been established for the purpose
of sharing ticketing information, mainly ticket numbers. This will
prove useful when ticketing fields have been designated as
masked. “ET” has been allocated as the new qualifier
(NP.ET*TEXT).
 The new qualified notepad field will continue to display
when all other notepad fields are designated as masked.
 The new qualified notepad field will also automatically add
to BF history without requiring user entry.
 The new qualified notepad field accepts freeform text.
New Fares entry to display taxes only

A new tax only entry and display provides both Sub-agents and
Consolidators the ability to view only the taxes (to be collected)
regardless of who filed the fare.
*FFALL/T – display taxes for all filed fares and for all passengers.
For each filed fare, taxes will be displayed only once for those
passengers with like taxes and of the same passenger type.

Example:
Note: “NO TAXES APPLY” alert for passenger 3. This message
will display when no taxes are collected.
*FFALL/T
FQ1 - S2-3 AP 13MAR06 56/AG
P1 ABBOTT/BUD G
TAX 6.80AY TAX 184.80US TAX 10.20XF TAX 9.00ZP
P2 COSTELLO/LOU RP10 M
P3 COSTELLO/BABY INF G
NO TAXES APPLY
FQ2 - S1.4 AP 13MAR06 56/AG

P1 ABBOTT/BUD G
TAX 95.80GB TAX 31.20UB TAX 3.40AY TAX 39.40US TAX 6.80XA
TAX 6.10XF TAX 9.50XYTAX 6.80YC TAX 149.20YQ
TAX 3.40AY TAX 39.40US TAX 6.80XA TAX 9.50XY TAX 6.80YC TAX 149.20YQ
*FFn/T – display taxes only for a specific filed fare, where: n

equals filed fare number. Taxes will be displayed only once for
those passengers with like taxes and of the same passenger type.
Example:
*FF1/T
FQ1 - S2-3 AP 13MAR06 56/AG
P1 ABBOTT/BUD G
TAX 6.80AY TAX 166.30US TAX 10.20XF TAX 9.00ZP`
FARE USD0.00 EQU AUD 0.00 TOT AUD0.00
*FFnPx/T – display taxes only for a specific filed fare and

passenger, where:
n equals filed fare number
x equals passenger number
*FF1P1/T
FQ1 - S2-3 AP 13MAR06 56/AG
P1 ABBOTT/BUD G

*FFPx/T – display taxes only for all filed fares, for a specific
passenger, where:
x equals passenger number
*FFP2/T
FQ1 - S2-3 AP 13MAR06 56/AG
FQ2 - S1.4 AP 13MAR06 56/AG

Data masking for Manual Fare data

With this enhancement, fares using the manual fare build entry,
*FBX will automatically mask with all other filed fare data where
filed fares are automatically masked from all viewers except the
city that input the fare for booking files that participate in the new
Consolidator data masking enhancement.
The structured data version of the *FBX entry has been enhanced
with data masking capability as well.
A new banner, **CONFIDENTIAL DATA EXISTS** was
introduced to display when BF fields are designated as masked.
The purpose of the banner is to inform the viewer that not all BF
information is being displayed. Fare information resulting from a
manual fare build entry (*FBX) is considered part of the BF
information that will not be displayed.

Travelport Selective Access User Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Travelport Selective Access User Guide

Uploaded by

Copyright:

Available Formats

Selective Access

This course shows you how to set up and maintain Selective

What is Selective Access™

You decide exactly which customer information and functions the

Features and Concepts

Other Options for Sharing Information

Group coding is primarily designed to link together individual

Agencies sharing the same group code number are permitted to

Group coding is predominantly used by multi-branch agencies.

This functionality allows communication between agencies and a

The originating agent creates a Booking File and queues it to the

Ad-hoc Data Sharing

Ad-hoc data sharing allows two agencies to share Booking File

The ad-hoc agency may set up a business agreement with a

If an agency is group coded, it may set up an ad-hoc data sharing

The non-ticketing agency is required to communicate the Booking

Before you set up Selective Access™ agreements, you need to

The fourth character in this field must be set to Y:

Providers and Requesters

The provider selects a pre-set agreement, indicating exactly which

An agency in Dublin may require an agency in Rome to service

Selective Access™ allows you to provide information and request

Business Relationships Between Two Individual Agencies

When a Galileo® or Apollo® agency sets up a Selective Access™

Example: – Short term relationship

An example of a short-term relationship is an agency that sends a

Example: – Long term relationship

A long-term relationship can be established for an agency in

Business Relationships Between Members of an Affiliate

When there are several agencies or branches of one agency that

An example of a relationship between members of an affiliate is

Buisiness Relationships Between Two Affiliates

When one group of agencies needs to do business with another

An example of this arrangement is an affiliate of United Kingdom

Buisiness Relationships Between an Affiliate and an Individual Agency

When a group of agencies need to do business with one agency,

An example of this arrangement is a twenty-four hour agency that

Selective Access™ Files

Galileo International builds and maintains the agreement file.

The agreement file is a list of pre-set agreements. An agreement

The functions accessible for each agreement are different to those

The provider builds and maintains the customiser file.

The customiser file allows the provider to take an agreement and

The selected agreement may allow the requester to display,

Note: Use of the customiser file is optional.

The provider builds and maintains the permission file.

The permission file defines the business relationship between the

The headquarters of an affiliate builds and maintains the affiliate

1. Do you have to be a secondary authoriser to perform Selective Access™ functionality?

3. An agency is both the provider and requester.

The agreement file is a table built by Galileo ®, which lists a variety

You can allow or deny the requester access to the following

Selective AccessTM agreement file formats begin with:

Displaying the Entire Agreement File

To display the entire agreement file:

Callout: Function Description:

1 NBR Agreement numbers. These can be between 0001 and

Displaying a Specific Agreement

There are two ways to display a specific agreement:

When you display an individual agreement, the headings which

To display a specific agreement by agreement number:

Booking File functions

A provider may give a requester access to the following Booking

Function Y indicates requester may: N indicates requester may not: