API UAE Carrier Portal User Manual v3.7 - mod
-
Upload
trinhthuan -
Category
Documents
-
view
378 -
download
9
Transcript of API UAE Carrier Portal User Manual v3.7 - mod
API UAE Project
UAE General Civil Aviation Authority
Carrier Portal User Manual
Version: 3.7
June 2015
June 2015 Page 2 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Copyright Notice
© SITA 2015
All rights reserved. Any use, republication or redistribution of content in this document is
expressly prohibited without the prior written consent of SITA. The SITA name, the SITA logo
and the following marks are trademarks, service marks or registered trademarks owned by the
SITA group of companies around the world: Affinity, AirlineConnect, AirportConnect,
AirportVision, Airport Management Solutions, CUTE, DesktopConnect, Maestro, WorldTracer.
Legal Notices
The relevant legal notices applicable to this document can be found in the Terms and
Conditions between the UAE General Civil Aviation Authority and SITA Information Networking
Computing B.V.
Document Versioning
Date Author Version Change Reference
01 Jul 2013 Tony Murillo 1.0 Initial release for Airlines only.
05 Mar 2014 Tony Murillo 2.0 Final release.
20 Mar 2014 Christopher Smith 3.0 Update document to include CTA
31 Mar 2014 Tony Murillo 3.1 Update Appd C – Air Batch file upload formats
12 May 2014 Tony Murillo 3.3 Update Ch 7 - Automated Batch Upload
27 Jun 2014 Christopher Smith 3.4 Removed CTA reference to Sea formats
14 Jul 2014 Anthony Bavcevich 3.5 Revision of sections
10 Dec 2014 Bharat Rampal 3.6 Update for the new version of CP
15 May 2015 Bharat Rampal 3.7 Updated based on feedback from AB on v3.6
Figure 1: Change record and references for each doc ument version
June 2015 Page 3 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Table of Contents
1. Introduction ...................................... ...................................................................... 5
1.1 Background and Overview ........................................................................................................... 5
1.2 Document Control ........................................................................................................................ 5
1.3 Scope of this Document ............................................................................................................... 5
2. Functionality of the Carrier Portal Overview ...... .................................................. 6
2.1 Design Overview .......................................................................................................................... 6 2.2 High-level Functionality ................................................................................................................ 9
2.3 Access Control ........................................................................................................................... 13
2.4 User Management and Timeouts ............................................................................................... 20
3. User Functions .................................... ................................................................. 25
3.1 User Functions ........................................................................................................................... 25
3.2 Open New Schedule .................................................................................................................. 27
3.3 Individual APP Check-in Transaction ......................................................................................... 33
3.4 Individual APP Cancellation Transaction ................................................................................... 51
3.5 Submit Batch APP/CTA Transactions ........................................................................................ 60
3.6 Enquiry on Submitted Batches ................................................................................................... 63
3.7 Flight Close ................................................................................................................................ 70
3.8 Information for Carriers .............................................................................................................. 74
3.9 Change Password ...................................................................................................................... 74
4. Carrier Administrator Functions ................... ...................................................... 75
4.1 Carrier Administrator Functions Overview.................................................................................. 75
4.2 Add New Carrier User Account .................................................................................................. 76
4.3 Modify Carrier User Account ...................................................................................................... 77
4.4 List Carrier Users Audit Log ....................................................................................................... 81
5. CTA Application Functions ......................... ......................................................... 84
5.1 Submit Individual CTA Application ............................................................................................. 84
5.2 Enquire on the status of an individual CTA application .............................................................. 90
5.3 Submit Batch of CTA Applications ............................................................................................. 93
5.4 Enquire on the status of batch CTA applications ....................................................................... 93
6. Automated Batch Upload Functions .................. ............................................... 100
6.1 Introduction .............................................................................................................................. 100
6.2 FTPS ........................................................................................................................................ 100
6.3 Email Attachment ..................................................................................................................... 102
6.4 HTTPS ..................................................................................................................................... 106
6.5 APP Batch File Format ............................................................................................................ 106 6.6 CTA Batch File Format ............................................................................................................ 108
Appendix A – Glossary of Terms .................... ........................................................... 111
Appendix B – Conditions of Use .................... ............................................................ 116
Appendix C – APP Batch File Formats ............... ....................................................... 117
Override .......................................... ............................................................................. 128
Response .......................................... ........................................................................... 128
June 2015 Page 4 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Appendix D – Error Messages ....................... ............................................................. 141
Appendix E – Support .............................. ................................................................... 147
Appendix F – CTA Batch File Formats ............... ........................................................ 149
Air Batch Files ..................................................................................................................................... 150
Air Batch Files - Examples .................................................................................................................. 153
June 2015 Page 5 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
1. Introduction
1.1 Background and Overview
This document is intended to be a user guide for the Carrier Portal, which is a component of the
API UAE Project as provided to UAE General Civil Aviation Authority (GCAA) by SITA INC. It
describes in full how the Carrier Portal operates and the functions provided within it.
1.2 Document Control
This volume is prepared and will be maintained by SITA on behalf of GCAA. Control of its release
is the responsibility of GCAA.
1.3 Scope of this Document
This document provides a detailed description of the functionality supported by the Carrier
Portal.
The Carrier Portal supports two user groups:
• API UAE team – as system administrators
• Carriers – as end users to submit data.
June 2015 Page 6 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
2. Functionality of the Carrier Portal Overview
2.1 Design Overview
The Carrier Portal forms part of the pre-clearance business processes. Its main purpose is to
provide the airlines and other carriers with an alternative method of submitting APP
transactions and CTA applications to the API UAE system. It is intended for use by small airlines
and other aviation companies that do not have Departure Control Systems that are fully
integrated with APP and by cruise and bus companies. It is also intended for submission of APP
transactions for crew and for the submission of individual and batch CTA applications — this
latter function is intended for both small and major air carriers.
2.1.1 Background
Each major airline carrying out APP transactions is connected through its Departure Control
System (DCS) to the Government Gateway (GG) which operates as a hub, passing on the
transactions to the APP System. Airlines submit check-in requests to the APP System for
passengers on flights, and in return they receive boarding directives.
This arrangement handles the great majority of people travelling to or from the United Arab
Emirates by scheduled air services, but there are important classes of travellers who are not
covered.
Including:
• Air crew (since crew do not go through a ‘check-in’ at the airport)
• Passengers flying with carriers without connectivity to the SITA network
• Passengers on unscheduled flights with small carriers
• Passengers and crew on international bus services
• Passengers and crew on international shipping services.
The Carrier Portal makes it possible for carriers to submit APP transactions for these groups
over the internet, both manually and using an auto-batch processing feature.
Additionally, the Carrier Portal also provides airlines with an alternative to the CTA interface for
the submission of CTA applications.
Finally, the Carrier Portal provides a facility for uploading batches automatically; to reduce the
time spent connecting to the website and to allow the implementation of a completely
June 2015 Page 7 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
automated solution. This process avoids the need to log in to the website and navigate through
the menus, by providing a transfer mechanism for receiving batches on the portal. This facility
can be integrated into the carrier’s crew rostering system to make the process of submitting
crew APP transactions and CTA applications seamless to the end user.
In summary, the Carrier Portal provides a number of enhancements over the CTA CTI interface.
Including:
• Submission of applications in batch file format — both manually and automatically
• Validation of the data submitted in CTA applications
• Reporting of upload status and application CTA application result
June 2015 Page 8 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
2.1.2 Language Options
The Carrier Portal will allow users to operate with either Arabic or English screen prompts, help
text and error messages.
Each page in the Carrier Portal will be available in either Arabic or English formats. Users will be
able to toggle between the two language formats via an option on the menu bar. Following a
language toggle, the current page will be re-displayed in the new language format.
The language option will affect the displayed labels and messages within the Carrier Portal, and
the right-to-left or left-to-right ordering of screen items.
The default language upon login to the Carrier Portal will depend on the user's browser locale
setting, i.e. if the user's browser locale setting is set to Arabic, then the Carrier Portal will be
displayed in Arabic.
Data received from carriers or entered by users will be shown as is, without transliteration or
translation.
Data capture of service data and personal data will be in Latin characters.
June 2015 Page 9 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
2.2 High-level Functionality
2.2.1 Classes of User
The Carrier Portal will be accessed only by authorised carriers. Carrier users will be staff
members working for airlines, general aviation companies, bus and shipping companies
involved in the checking-in of passengers or the rostering and administration of crew members.
Carrier Users will be of two classes:
• Carrier Administrators
• Carrier Normal Users.
UAE Government administrators will have full control over the registration, management and
monitoring of carriers for access to the Carrier Portal and of Carrier Administrators for those
carriers. They will not use the Carrier Portal to perform this role; they will use functions on the
User Portal.
A facility on the Carrier Portal will allow a new carrier to register a request to use the Carrier
Portal. They will supply details of the carrier company and for the Carrier Administrator within
the company, and the UAE Government administrators will be able to review and approve the
registration on the User Portal.
Carrier administrators will be able to register Carrier Normal Users for access to the Carrier
Portal, for their own company only. Any registration submitted by a Carrier Administrator will
need to be approved by an UAE Government administrator before it can be used.
Management of passwords for Carrier Users on the Carrier Portal, in terms of expiry, active life,
and re-use, will be subject to the security requirements defined by the UAE Government.
Both Carrier Administrators and Carrier Normal Users will be able to perform all the Carrier
Portal functions related to the submission of Traveller and service data to the APP System.
The carrier company code and the user account code will be included in APP messages sent to
the AP (and hence to the UAE government), to allow identification of the originator of all
transactions.
The carrier companies will be divided into two categories: those that have a 2/3-character IATA
carrier code, and those that do not. Broadly speaking, those with a carrier code are expected to
have scheduled flights with flight numbers recorded in the Official Airline Guide (OAG).
June 2015 Page 10 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
When UAE Government administrators approve the company code for a carrier company, they
will need to apply this categorisation. For an airline with an assigned IATA carrier code (2 or 3
characters), the assigned company code must be that carrier code. For the other carriers,
administrators may allocate any suitable code.
2.2.2 Overview of Carrier User Functions
A Carrier Administrator will have access to the following major functions once they have been
approved:
• Add New Carrier Normal User Account
• List and Modify Carrier Normal User Account
• List Carrier Users Audit Log
• Open New Service, Update Service, Close Service, and Submit APP transactions through “Service Management and Individual APP Transactions” major function
• Add New Service (*)
• List and Modify Services (*)
• Submit Batch of APP Transactions
• Enquire on Submitted APP Batches
• Information for Carriers
• Individual CTA Application (**)
• Visa/CTA Status Enquiry (**)
• Submit batch of CTA Applications (**)
• Enquiry on submitted CTA batches (**)
• Change Password
(*) - Only available to General Aviation, Sea and Land Carrier Administrators
(**) - Only available to Air and General Aviation users
Carrier Administrators will be able to register the details of a new Carrier Normal User. The new
user account will be set initially to a status of Provisional and can be used to access the Carrier
Portal only after an UAE Government administrator has reviewed the account and altered the
status from provisional to active.
Carrier Administrators will be able to view the details of Carrier Normal Users registered for
their carrier company and update the information on those users. They will not be able to view
or update information on Carrier Administrators. The update option will allow the Carrier
Administrator to:
• Change personal details (name, phone, fax, email)
June 2015 Page 11 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
• Reset a user password
• Change the account expiry date
• Make the account active or inactive.
Carrier Administrators will be required to review the Carrier Normal User accounts from time to
time to ensure there are no active accounts for people who should no longer have access to the
system. At the same time, account expiry dates should be extended for each valid user.
The account expiry date and the Active/Inactive status will provide the means for controlling
access to the system when a Carrier Normal User is no longer submitting data for a carrier.
When a person leaves, the Carrier Administrator should change the user’s status from active to
inactive. If this does not happen, then, as a back-stop, the account expiry date will prevent
access to the system. For this reason, the account expiry date will not be more than 12 months
in advance. In addition, the account will be marked as disabled if it is inactive for a configurable
period of time determined by GCAA's security requirements.
Carrier Administrators will be able to view logs of the operations performed by Carrier Users in
their own company. They will also be able to maintain information on services (other than
scheduled air services) operated by their own company.
Both Carrier Administrators and Normal Users of carriers registered for submission of APP data
will have access to “Service Management and Individual APP Transaction” major function
through which they can:
• Open New Service
• Update Service
• Close Service
• Submit an individual APP check-in transaction
• Submit an individual APP cancellation transaction
In addition, carrier administrator and normal carrier user will have access to the following
major functions:
• Submit a batch of APP transactions
• Enquire on status of submitted APP batches and retrieve results
• Submit a service close request.
Carrier Administrators and Normal Users of General Aviation, Sea and Land companies will also
be able to carry out the following Crew Service administration functions:
• Add New Service
• List and Modify Services
June 2015 Page 12 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Carrier Administrators and Normal Users of the Air and GA companies will also be able to carry
out the following Crew Travel Authority “CTA” functions:
• Submit an individual CTA application
• Enquire on the status of a CTA application
• Submit a batch of CTA applications — either manually or via the auto-batch-upload function
• Enquire on the status of submitted batches and retrieve the results of the associated applications
2.2.3 Batch process
The individual check-in and cancellation transactions will simulate the functionality available to
check-in staff using terminals connected to the Government Gateway through the SITA
network.
The facility of submitting transactions in batches will be provided for Carrier Users to enable a
more efficient way of submitting transactions.
Batch files will be transferred to the Carrier Portal using https file transfer.
The transfer will operate as follows:
• The Carrier User will log on to the secure site, choose the option to submit a batch file and then use a standard dialog box to select the file to send. The file will be sent in an https request to the application server. Since the entire session will be conducted using secure https, transmission of the file is protected by SSL encryption. When the file reaches the server the user gets an immediate acknowledgement of receipt.
• The file will be stored and recorded in a batch register against the user. Batch files will be processed in the order of receipt. The results will be stored in a file of the same type as the input batch, and the register will be updated when the process is complete.
• Upon completion of processing of a batch, an email will be sent to the user that submitted the batch.
• In addition, the user will be able to perform an enquiry on the status of the submitted batches. Any batches that are completed will be hyperlinked as being ready for viewing or downloading. Viewing and downloading may include unsuccessful transactions only, successful transactions only or all transactions. The display will be automatically refreshed to show the most recent status.
• Downloading of response files will use SSL-protected https file transfer.
The Carrier Portal will provide a facility for uploading batches automatically; to reduce the time
spent connecting to the website and to allow the implementation of a completely automated
solution. This process will avoid the need to log in to the website and navigate through the
menus, by providing a transfer mechanism for receiving batches on the portal. This facility can
be integrated into the carrier’s crew rostering system to make the process of submitting crew
APP transactions seamless to the end user.
June 2015 Page 13 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
2.3 Access Control
Carrier Users will access the system by clicking on a link on the UAE Government portal. A
session will start in a new browser window and will display the Carrier Portal Home Page.
The home page will provide users with general information on the Carrier Portal and a link to
the secure site. The user will click on this link to begin. A secure session will start in a new
browser window and user log-in will be required. All subsequent processing will occur within
the secure browser window.
The Carrier User Menu will display a list of functions available to the specific user.
The functions available will depend upon:
• Whether the user is a Carrier Administrator or a Carrier Normal User
• The type of carrier.
Functions for each carrier type and each class of Carrier User are shown in Figure 2.
Function Schedule Airlines
Unscheduled Airlines
General Aviation
Bus, Ship
APP APP APP APP
Carrier Administrator Functions:
Add New Carrier User Y Y Y Y
List and Modify Carrier Users Y Y Y Y
List Carrier Users Audit Log Y Y Y Y
APP Functions:
Add New Service Y Y Y
List and Modify Services (including Cancel)
Y Y Y
Individual APP Check-in Y Y Y Y
Individual APP Cancellation Y Y Y Y
Submit Batch of APP Transactions Y Y Y Y
Enquire on Submitted APP Batches Y Y Y Y
Service Close Y Y Y Y
General Functions:
Information for carriers Y Y Y Y
Change Password Y Y Y Y
Select carrier for Administrative Tasks Y1 Y1
Exit Y Y Y Y
CTA Functions:
Individual CTA application Y Y Y N
June 2015 Page 14 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Function Schedule Airlines
Unscheduled Airlines
General Aviation
Bus, Ship
Enquire on Status of CTA application Y Y Y N
Submit Batch of CTA applications Y Y Y N
Enquire on Submitted CTA Batches Y Y Y N 1 Only available to administrators on an exception basis.
Figure 2: Carrier User Function Availability
June 2015 Page 15 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
2.3.1 Log-in
2.3.1.1 Log into the Carrier Portal
Company users access the system by entering the Carrier Portal internet address in their
browser.
To log in to the Carrier Portal:
1. Enter the following web address in your browser:
https://carriers.apiuae.gov.ae/UCP/login.form
This URL displays the Carrier Portal Login page and user login is required. All subsequent
processing occurs within the secure browser window.
Figure 3 – Carrier Portal Login Page
June 2015 Page 16 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 4 – Carrier Portal User Conditions and Respo nsibilities
If you are logging in to the system for the first time, you must initially read and accept the terms
and responsibilities for Company users. Indicate that you agree to the conditions and
responsibilities by clicking on the ‘I accept’ button. If you have already accepted the conditions
and responsibilities, a record of this acceptance already exists on the system server and the
Carrier Portal Functions screen is displayed.
NOTE: Asterisk (*) sign after a title denotes a Mandatory input field - e.g. Carrier Code*
Figure 5 – Carrier Portal Login Screen
June 2015 Page 17 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
2. Enter the following information in the applicable f ields:
Dialog Field Name Description
Carrier Code Enter the carrier code for your airline, general aviation, bus and shipping company. If your Air Company has an IATA code, use this. Alternately, use your code as supplied by administrator. This must be entered.
User ID Enter your User ID as supplied by administrator. This must be entered.
Password Enter your current password. If logging in to the system for the first time, this will be as supplied to you by administrator and must be changed when you have logged on. This must be entered.
Figure 6 – Log in to Carrier Portal
User passwords expire after a configured number of days (typically 30 days). The user is
required to change the password on the next login after that time. See also Change Password
below.
If you enter an incorrect Carrier Code, User ID or Password, the following responses may be
displayed after all checks are performed on the local database:
Error Message Description
‘Please enter Company code and User ID’
You have not supplied a carrier code or User ID.
‘Invalid Company code or User ID’ You have not supplied a valid carrier code or user ID.
‘Invalid User name or Password’ You not entered a valid user name or password.
Figure 7 – Login Failure Error Messages
If login fails, unless you have exceeded the maximum number of allowed attempts, you are
given the option to login again by pressing the Login button or to Exit secure site and return to
the Carrier Portal landing page.
If you log in successfully to the Carrier Portal, the APP Function Menu is displayed. The system
displays the functions depending on the user type (administrator or normal).
June 2015 Page 18 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Menu - Administrator User
Figure 8– Administrator User Function Menu
Menu - Carrier User
Figure 9– Normal Carrier User Function Menu
June 2015 Page 19 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
2.3.1.2 Change Password
If your password has expired or has been reset by an administrator, for example in the case of it
being forgotten, you are required to change it at first login.
3. If your password needs to be changed, the following screen will be displayed when you login:
Figure 10– Change Password
4. Enter the new password:
Dialog Field Name Description
Please enter the old password
The old password is required as a security measure.
Please enter a new password
The new password must conform to the security standards defined in the Password Management section below. This must be entered.
June 2015 Page 20 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Dialog Field Name Description
Now re-enter to confirm
Must agree with the password entered above. This must be entered.
Figure 11– Change Your Password
To complete the Change Password process, press the ‘Submit’ button. Alternately, press the
‘Cancel’ button to exit the Carrier Portal without changing your password. If you change your
password successfully, the APP Function menu is displayed.
2.4 User Management and Timeouts
2.4.1 Registration
The Registration process will allow a new carrier to register details of their company, and of the
administrator who will manage users within the company.
2.4.1.1 Registration page
The Registration page will be located on the public pages of the Carrier Portal application.
Figure 12: Register Carrier screen
June 2015 Page 21 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 13 lists the elements shown on the screen and their purpose.
Field/Button Data Type Description
Carrier Type Input Field Drop down list of carrier types which may be:
• Air
• General aviation
• Ship/Cruise Vessel
• Bus/Coach. Mandatory.
Carrier Code Input Field Carrier company code. Length: three alphanumeric characters. Mandatory.
Carrier Name Input Field Carrier company name. Length 30 alphanumeric characters. Mandatory.
Data Capture Input Field Data capture type that will be used by the carrier company. Options available are:
• Individual APP - for carrying out individual APP transactions
• APP Batch - for carrying out batch APP transactions
• Individual CTA - for carrying out individual CTA transactions
• CTA Batch - for carrying out batch CTA transactions
• API Batch - for carrying out batch API transactions At least one option must be selected.
[Next] Button Proceeds to the Register Administrator screen.
Figure 13: Register Carrier screen fields
June 2015 Page 22 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
2.4.1.2 Nominate Carrier Administrator screen
Figure 14 shows the screen that will be used to collect the Carrier Administrator details.
Figure 14: Register Carrier Administrator screen
Field/Button Data Type Description and Validation
Family Name Input Field Length 40
Family name of the user. Mandatory
Given Names Input Field Length 40
Given name of the user. Mandatory
Telephone Contact
Input Field Length 50
User’s telephone number. Mandatory
Facsimile Number
Input Field Length 50
User’s facsimile number Optional
Email Address Input Field Length 50
User’s email address. Mandatory
[Register] Button Validates the details and performs the registration.
[Clear] Button Clear the screen input fields.
[Back] Button Returns the user to the previous page.
Figure 15: Register Carrier Administrator field def inition
When the user clicks on the Register button, the system will create a carrier company and a
Carrier Administrator record, both with a Provisional status, and will email the UAE
Government Administrators, requesting them to vet and approve the new carrier registration.
June 2015 Page 23 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
The User Portal document describes the actions taken by the UAE Government Administrators
to approve the carrier.
Following a successful approval, the Carrier Administrator will be sent a one-time use password
which will enable them to login to the Carrier Portal, where they will be required to enter a new
password.
2.4.2 Password Management
The policies and procedures controlling the management of passwords follow the rules and
guidelines provided by the Government of UAE.
This document sets out a number of rules, which mandate that all passwords used to gain
access to the Carrier Portal must comply with the following:
• Must be at least nine characters
• Must include at least one uppercase alphabetic character
• Must include at least one digit
• Must include at least one lowercase alphabetic character
• Must include at least one non-alphanumeric (special) character
• Must be different from the previous 10 passwords used
• Must not be too similar to the most recent previous password
• Must not be changed by the account owner more than once in any 24 hour period
• Must expire after 90 days.
Additionally, the system also prevents users creating passwords that are longer than 12 characters.
The following table provides examples of non-compliant passwords and the rule with which
they are not compliant:
Invalid password example Description of rule broken
Password Password too short: must be at least 9 characters
PasswordPassword Password must contain at least 1 digit
1451251351351351 Password must contain at least 1 upper case letter
Password12 Password must contain at least one punctuation character, for example _, $, ^ etc
Figure 16– Examples of Non-Compliant Passwords
June 2015 Page 24 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
2.4.3 Automatic User Timeout
When you are logged in to the Carrier Portal, if no system activity occurs for a configurable
period (currently set to 15 minutes), you are automatically logged out of the system. This is a
security feature that is intended to reduce the risk of unauthorised access. In such a case, the
login screen is displayed. You must re-establish the session by logging in again.
June 2015 Page 25 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
3. User Functions
3.1 User Functions
The following functions are available to Carrier Portal users, both administrators and normal
users. These are shown in the following figure:
Carrier Portal User menu Description
Open New Service This function enables users to open new service (flight) so that APP Check-in data can be submitted.
Individual APP Check-in This function enables users to submit individual check-in transactions for passengers and/or crew. To go to this function, click the “Service Management and Individual APP Transactions” button in the User Menu.
Individual APP Cancellation This function enables users to submit individual cancellation transactions for passengers and/or crew. To go to this function, click the “Service Management and Individual APP Transactions” button in the User Menu.
Submit Batch APP/CTA Transactions
This function enables users to submit a number of APP check-in or cancellation transactions, either inbound or outbound and CTA applications, as a batch. To go to this function, click the “Submit Batch APP/CTA Transactions” button in the User Menu.
Enquiry on Submitted APP/CTA Batches
This function enables users to check the status of previously submitted APP and CTA batches. To go to this function, click the “Enquire on Submitted APP/CTA Batches” button in the User Menu.
Service Close This function enables users to initiate a flight close request. To go to this function, click the “Service Management and Individual APP Transactions” button in the User Menu.
June 2015 Page 26 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Carrier Portal User menu Description
Information for Carriers This function enables users to display information on the Carrier Portal and provides options to download documentations. To go to this function, click the “Information for Carriers” button in the User Menu.
Change Password This function enables users to change their password. To go to this function, click the “Change Password” button in the User Menu.
Exit Ends the Carrier Portal session. Figure 17– APP Function Menu
Each function is discussed in more detail in the following sections.
June 2015 Page 27 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
3.2 Open New Schedule
Before the carrier user can submit APP data, the schedule (flight) must be opened. To go to this
function:
From the CP User Menu screen, click on the ‘Service Management and Individual APP Transactions’ button .
Figure 18: Open New Schedule 1
Click “Open New Schedule"
June 2015 Page 28 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 19: Open New Schedule 2
You can also access this screen straight from the C P User Menu screen by clicking on the ‘Open New Schedule’ button on the User Menu screen.
Use this screen to add the details for the flight that you are about to process. Fill in the required
fields as follow and then click “Open”.
Field Name Description and Validation
Direction The Direction of the flight for which data is to be captured.
You must enter one of the following:
I: Inbound
O: Outbound
The Direction selected will impact the processing of
subsequent data fields.
June 2015 Page 29 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Field Name Description and Validation
Flight Number The Flight Number.
You must enter a valid value in this field.
For an airline with a two letter IATA code, this is the full flight
number, e.g. QF121.
For a general aviation company, this is the aircraft
registration number.
For Land and Sea carriers, this is the Bus or Vessel registration
number used when the user added new service using “Add
New Service” function.
Departure Port The location from which the international flight is departing.
You must enter a value in this field.
Standard three character IATA Port Code.
For Land and Sea Carriers, this is the five character UN
Location Code.
Departure Date The departure date from the Departure Port.
You must enter a value in this field.
Departure Time The scheduled departure time for the flight.
You must enter a value in this field.
Arrival Port The final port for the international flight.
You must enter a value in this field.
Standard three character IATA Port Code.
For Land and Sea Carriers, this is the five character UN
Location Code.
Arrival Date The arrival date at the Arrival Port.
You must enter a value in this field.
June 2015 Page 30 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Field Name Description and Validation
Arrival Time The arrival time at the Arrival Port.
You must enter a value in this field.
Trans-border Port The IATA airport code at which the service will cross the
border of the United Arab Emirates.
For Land and Sea Carriers, this is the five character UN
Location Code.
Trans-border Date The scheduled arrival date at Trans-border Port for Inbound
service, or scheduled departure date from Trans-border Port
for Outbound service.
Only required if Trans-border Port is provided.
Trans-border Time The scheduled arrival time at Trans-border Port for Inbound
service, or scheduled departure time from Trans-border Port
for Outbound service.
Only required if Trans-border Port is provided.
Last Foreign Port The last IATA airport code before the service will cross the
border of the United Arab Emirates.
For Land and Sea Carriers, this is the five character UN
Location Code.
Figure 20: Flight Details Fields
June 2015 Page 31 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 21: New Service Opened
NOTE: For General Aviation, Land, and Sea carriers, the user needs to “Add New Service” first.
This function along with another function, “List and Modify Services” will be displayed for
General Aviation, Land and Sea carrier both Administrator and Normal users as separate
options in the Main Menu Page as illustrated below.
June 2015 Page 32 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 22: GA, Land, and Sea Add New Service
Click “Add New Service”
Figure 23: GA Add New Service
Fill in the required fields and then click “Create”
June 2015 Page 33 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 24: Land Carrier Add New Service
Fill in the required fields and then click “Create”
Figure 25: Sea Carrier Add New Service
3.3 Individual APP Check-in Transaction
The Individual APP Check-in Transaction function enables a user to transmit APP data for
individual crew members, both operating and positioning, and for passengers.
The following flowchart illustrates the Individual APP Check-in Transaction process.
June 2015 Page 34 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 26– Individual APP Check-in Transaction
Ex
it
Ex
it
Ex
it
Su
bm
it
Try
Ag
ain
Ex
it
Ex
it
June 2015 Page 35 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
To process an individual APP transaction for a traveller, perform the following:
1. From the CP User Menu screen, click on the ‘Service Management and Individual APP Transactions’ button.
The schedule search screen enables the user to find if the required schedule has been set-up
from previous check-in.
Enter details using the search Schedules (Flights) screen below:
Figure 27– Carrier Portal Search Schedule
June 2015 Page 36 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
2. If the schedule number being searched has already been opened, the details of the schedule will be displayed at the bottom of the screen:
Figure 28 – Carrier Portal Search Schedule Result
Choose the appropriate schedule by clicking-on the radio button on the left side of the details
then click the “Manifest” button. If there is no search result displayed for the required
schedule. The user can create a new schedule by pressing the “Open New Schedule” button as
described in the previous section.
To cancel an existing check-in, choose the appropriate traveller by clicking on the radio button
on the left and click “Cancel” button at the bottom of the screen. This will send a check-in
cancellation request to AP.
The system displays the Manifest Screen and displays a list of Check-in records for that flight if
available. Otherwise, it displays “No Records Found”.
June 2015 Page 37 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 29 – Carrier Portal Search Schedule Result
3. Click “New Check-in”
Complete the traveller information screen. When you have completed all fields as required, click on th e ‘Submit’ button.
Upon selecting the desired service from previous screen, the Travel Document details screen is
displayed.
June 2015 Page 38 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 30– APP Check-in Transaction –Passenger Deta ils
Figure 31– Travel Document Details screen
June 2015 Page 39 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
The Travel Document Details screen collects the travel document details for a single person,
either passenger or crew. For each person, the system constructs a complete APP transaction
by adding the previously entered flight details to the person details.
June 2015 Page 40 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
4. Complete the fields as follows:
Field Name Description and Validation
Traveler Type Traveler type: Passenger, Operating Crew, or Position Crew.
Document Type The type of travel document. Valid values are:
P: Passport
O: Other Travel Document
N: No Document
Nationality Nationality as indicated on the travel document.
You must enter a value in this field.
May be typed directly or selected from the dropdown list.
If you type in the Nationality, the drop-down list is automatically populated with
the entered Nationality.
Document
Number
Document Number of the travel document.
You must enter a value in this field, unless the person has no travel document.
Document Expiry
Date
The date on which the travel document will expire as indicated on the travel
document.
This is an optional field.
Issuing State Issuing State as indicated on the travel document.
Mandatory if Document Type is set to ‘O’ and the traveler is a passenger.
May be typed directly or selected from the dropdown list.
If you type in the Issuing State, the drop-down list is automatically populated
with the entered Issuing State.
Family Name Family name or surname of person as indicated on the travel document.
You must enter a value in this field.
Only letters, hyphens, apostrophes and spaces allowed.
The name must start and end with a letter. You cannot enter combinations of
hyphens and apostrophes.
June 2015 Page 41 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Field Name Description and Validation
Given Names Given names of person as indicated on the travel document. Individual names
must be separated by a blank. If the given names are not known, a hyphen may
be entered.
You must enter a value in this field.
Only letters, hyphens, apostrophes and spaces are allowed.
The name must start and end with a letter. You cannot enter combinations of
hyphens and apostrophes.
Date of Birth The date of birth of the person as indicated on the travel document.
Must be a valid date.
The entered date must be less than or equal to current date and no more than
120 years old. If the day of the month is not known, the day may be replaced by
two hyphens. In addition, if the month is not known, the month may be
replaced by three hyphens.
Sex Gender of person as indicated on the travel document.
Country of Birth Country of birth of the person as indicated on the travel document. May be
typed directly or selected from the dropdown list.
If you type in the Country of Birth, the drop-down list is automatically populated
with the entered Country of Birth.
Reservation
System Code
Reservation reference number as supplied by the carrier. This is an optional
field.
Record Locator Reference number. This is an optional field.
June 2015 Page 42 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Field Name Description and Validation
Type of Arrival Type of Arrival is only requested if the user selected “P” for Passenger Type in
the Crew/Passenger Type and Flight screen.
The following options are available in the dropdown list:
Normal Arrival in UAE: The passenger is leaving the aircraft and entering UAE.
Transit on same aircraft out of UAE: The passenger is departing on the same
aircraft and is not entering UAE.
Transfer to other flight out of UAE: The passenger is departing on another
flight, and is not entering UAE.
For Land and Sea Carriers, this will be Normal Arrival in UAE.
Figure 32– Travel Document Details
5. When you have completed entering the data, click on the ‘Submit’ button to complete the check-in of th e current passenger and proceed to the next passenger on the current flight. Alternatively, click on the ‘Cancel’ button to return to the Flight Details scr een.
If you proceed with the check-in transaction, there are four possible categories of response
options depending on the how the request is processed. These responses are as follows:
3.3.1 AP Validation Error
If, when you press the Submit button, the validation of the message on the AP fails, for example
if it contains an invalid UAE travel document number, the AP will send a 6XXX series error
message indicating why the validation failed.
Select the ‘Submit’ button after correcting the invalidly entered data. Alternately, click on the
‘Menu’ button to return to the APP Function Menu.
3.3.2 APP Communications Error
If you receive an APP communications error while checking-in a passenger, you should wait a
certain amount of time and then ascertain whether the system problem is likely to be resolved
in time to complete the check-in through APP. If this cannot be accomplished, you should revert
to your back-up manual check-in process.
June 2015 Page 43 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
3.3.3 Insufficient Data
If you do not enter sufficient data for the AP to process the APP check-in transaction, the
system returns an appropriate error message. In response, the Carrier Portal displays the
Insufficient Data screen, which prompts you to return to the previous screen and complete the
required data fields.
Figure 33– Check-in Transaction Response – ‘Insuffi cient Data’
3.3.4 Normal Response
If the check-in transaction attempt contains the complete and correct data and the system is
able to successfully communicate with the AP, you will receive a boarding directive in response.
The boarding response will depend on the current business rule configuration, but can be
summarised as follows:
OK TO Board
June 2015 Page 44 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
In the case that the system receives a positive message, the Carrier Portal will display a screen
showing the flight and person details together with directive “OK TO BOARD”.
Figure 34– Check-in Transaction Response – ‘OK TO B OARD’
You may board the person and then either check-in another person by clicking on the ‘Back’
button or return to the APP Function Menu by selecting the ‘Menu’ button.
Board if Documents OK
In the case that the system receives a message with a status indicating a positive response
conditional upon travel document inspection, the Carrier Portal will display a screen showing
the flight and person details together with directive “BOARD IF DOCS OK”.
June 2015 Page 45 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 35– Check-in Transaction Response – ‘BOARD I F DOCS OK’
You may board the person, if their travel document is in order, as set out by the Travel
Information Manual (TIM) guidelines, and then either check-in another person by clicking on
the ‘Back’ button or return to the APP Function Menu by selecting the ‘Menu’ button.
If the travel document is not in order and the traveller is not able to travel to UAE, you must
submit a cancellation transaction to cancel the APP record. See section 3.4 Individual APP
Cancellation Transaction for details on cancellations.
Do Not Board
In the case that the system receives a message with a negative response, the Carrier Portal will
display a screen showing the flight and person details together with directive “DO NOT
BOARD”. In this case you should not allow the person to board the flight.
June 2015 Page 46 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 36– Check-in Transaction Response – ‘DO NOT BOARD’
Depending on the configuration of the business rules for the system, the directive may be
either overridable or not. If overridable, you may be able to perform an airline ‘A’ override.
When you have completed processing this check-in transaction you may either check-in
another person by clicking on the ‘Back’ button or return to the APP Function Menu by
selecting the ‘Menu’ button.
See the section below on Overrides.
Note : In the initial phase of the UAE APP implementation, this directive is operationally disabled by business rule configuration. Only when or if the business rules are updated, in subsequent implementations, will air users receive this directive.
Contact UAE Government
In the case that the system receives a message with a conditional negative response, the Carrier
Portal will display a screen showing the flight and person details together with directive
“CONTACT UAE Government”.
June 2015 Page 47 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 37– Check-in Transaction Response – ‘CONTACT UAE Government’
In response to this message, you should deny the person boarding until you have contacted the
UAE Government and requested that they check on the check-in transaction in question.
You can either contact the UAE Government Operations centre and ask for authority to
override the directive while this screen is on display and, if authority is given, submit the
override, or you can Exit and then repeat the transaction after you have contacted the UAE
Government and been given authority to override.
If the UAE Government authorises you to override the directive, the carrier user needs to re
check-in the passenger and then click on the ‘G Override button’. The system will generate a
message with the appropriate status and the Carrier Portal will display the following result:
June 2015 Page 48 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 38: Re Check-in
Figure 39: G Override
June 2015 Page 49 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 40– Check-in Transaction Response – ‘OVERRID E ACCEPTED’
Alternatively, if you attempt to override a directive for which authorisation has not been
granted, you will receive the following message:
Figure 41– Check-in Transaction Response – ‘Overrid e not authorised’
June 2015 Page 50 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
From this screen, you can either attempt to override the directive again — the movement may
since have been authorised to be overridden — by selecting the ‘Try again’ button, or return to
the APP Function Menu by selecting the ‘Menu’ button.
6. When you have completed processing this check-in t ransaction, you may either check-in another person by clicking on the ‘Another’ button or return to th e APP Function Menu by selecting the ‘Menu’ button.
3.3.5 Overrides
Overrides are used when an earlier APP transaction for a person has resulted in a ‘Contact UAE
Government’ or ‘DO NOT BOARD’ directive.
• ‘G’ Override (Government Override):
— A ‘G’ Override may be used when the airline contacted the UAE Government which made a decision to override a negative directive.
When you click the ‘G’ Override button, this message is processed as before, and, in the
absence of any errors, will give rise to a response message with a status indicating a successful
override.
The following figure provides a summary list of all the messages which may be sent in response
to a check-in request and a description of what you should do in response to this message:
Message Group Directive and Description
APP Communications Error
Error. An attempt was made to send a message to the AP, but no connection was able to be made. Revert to manual process.
Error. An attempt was made to send a message to the AP and that was successful. However, no response was received back within the configured timeout period. Try again (within operations guidelines).
AP Error Error. An attempt was made to send a message to the AP and that was successful. However, the message contained an error: the type indicated by the value of the 6 series error code.
Insufficient Data Insufficient Data. If the AP does not receive all the data it requires for the check-in transaction it will return an 8516 message and an Insufficient Data directive. Complete the data.
Normal Response - Positive
OK to Board. Allow to travel.
Board if Docs OK. Allow to travel if travel document is OK. Override accepted. Allow to travel.
June 2015 Page 51 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Message Group Directive and Description
Normal Response - Negative
Do not Board. Do not allow to travel.
Contact Government. Contact UAE government operations centre.
Figure 42– Check-in Transaction Response – Message code summary
3.4 Individual APP Cancellation Transaction
The Individual APP Cancellation Transaction enables you to cancel a previously submitted APP
Transaction. Transactions should always be cancelled in situations where an APP check-in was
completed with incorrect data or where an APP transaction was completed for a passenger or
crew member who subsequently did not board the flight.
You may cancel an APP transaction by entering the same data as you submitted in the initial
APP Check-in transaction. The data supplied must be identical for the cancellation to be
successful.
The operation of the Inbound and Outbound Cancellation transactions is the same, with some
small data variations, and so they are both described in this section. The data variations are
noted where applicable.
The following figure shows an overview of the Individual APP Cancel Transaction Process:
June 2015 Page 52 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 43– Individual APP Cancellation Transaction flow
To process an individual APP cancellation transaction, perform the following:
1. From the CP User Menu screen , click on the ‘Servic e (Flight) Management and Individual APP Transactions’ button
Use this screen to search a schedule and cancel a check-in transaction from the selected
schedule.
The APP Cancellation – Search Schedule (Flight) Details screen is displayed:
June 2015 Page 53 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 44– Search Flight screen
2. Complete fields as follows:
Field Name Description and Validation
Direction The Direction of the flight for which data is to be captured.
Valid values are:
Inbound
Outbound
All
Flight Number The Flight Number.
For an airline with a two letter IATA code, this is the full flight
number, e.g. QF64.
For a general aviation company, this is the aircraft
registration number.
June 2015 Page 54 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Field Name Description and Validation
Service Status Indicator if the service has been ‘Open’ or ‘Closed’ or ‘Any’. If
you choose the status ‘Any’, the system displays both Open
and Closed services.
Departure Port The location from which the international flight is departing.
Standard three character IATA Port Code.
Departure Date
Range
The scheduled date for the start and end of a date range of
Service departures to be searched can be entered here OR
the pop-up calendar can be used to populate these fields.
These fields can be used to search for a specific date of
departure.
Departure Time
Range
The time for the start/end of a time range of Service
departures to be searched can be entered here.
Arrival Port The final port for the international flight.
Standard three character IATA Port Code.
Arrival Date Range The scheduled date for the start and end of a date range of
Service arrivals to be searched can be entered here OR the
pop-up calendar can be used to populate these fields.
These fields can be used to search for a specific date of
arrival.
Arrival Time Range The time for the start/end of a time range of Service arrivals
to be searched can be entered here.
Figure 45– Search Flight screen fields
June 2015 Page 55 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 46– Flight search result screen
Choose the appropriate flight to which the desired transaction to cancel belongs to by clicking
the radio button next to the flight number then click “Manifest” button.
The details collected on this screen apply to all subsequent crew or passengers submitted on
the following Travel Document Details screen until the flight details are changed. In other
words, when you are cancelling APP transactions for a number of crew or passengers on the
same flight, you need only enter the flight details once.
Note : The prompts on this screen differ according to whether the flight is Inbound or Outbound, so that the user does not need to remember which fields are required.
3. Select the transaction to cancel by clicking the ra dio button in front of the record then press the ‘C ancel Check-in’ button.
The Passport Details screen is displayed.
The Passport Details screen collects the travel document details for a single person, either
passenger or crew. For each person, the system constructs a complete APP cancellation
transaction by adding the previously entered flight details to the person details.
June 2015 Page 56 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 47– Individual APP Cancellation Transaction – Passport Details
Field Name Description and Validation
Traveler Type The Traveller Type indicator as to:
P - Passenger
C - Operating Crew
X - Positioning Crew
Family Name Family name or surname of person as indicated on the travel
document.
Given Names Given names of person as indicated on the travel document.
Date of Birth The date of birth of the person as indicated on the travel document.
Board Status The directive given to this traveler.
June 2015 Page 57 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Field Name Description and Validation
Document Type The type of travel document. Valid values are:
P: Passport
O: Other Travel Document
N: No Document
Document Number Document Number of the travel document.
Figure 48– Transaction Cancellation – Service Manif est
4. Click on the ‘Back’ button to return to the Travele r Type and Flight screen.
The following categories of responses may be received:
3.4.1 AP Validation Error
If, when you press the Cancel Check-in button, the validation of the (cancellation) message on
the AP fails, for example if it contains an invalid travel document number, and the system is set-
up to validate this data, the AP will send a 6XXX series error message indicating why the
validation failed.
Select the ‘Back’ button to return to the previous screen and correct the invalidly entered data.
Alternately, click on the ‘Menu’ button to return to the APP Function Menu.
3.4.2 APP Communications Error
If you receive an APP communications error while trying to cancel a check-in transaction, you
should wait a certain amount of time and then ascertain whether the system problem is likely
to be resolved in time to complete the check-in through APP. If this cannot be accomplished,
you should revert to your back-up manual check-in process.
If the system cannot establish a communications link to the AP, it behaves as if it had received a
connection error message
June 2015 Page 58 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
3.4.3 No Record
If the system cannot find matching APP check-in transactions, the AP returns a message with a
not found status. The screen displays the response message ‘NO RECORD’ indicating that the
system cannot find a matching APP check-in transaction to cancel.
Figure 49– Check-in Transaction Response – ‘NO RECO RD’
3.4.4 Cancelled
If the system successfully locates the check-in transaction record to be cancelled, the AP
returns a message indicating the cancelled status. The screen displays all the details of the
passenger or crew member and the response message ‘CANCELLED’ indicating that the system
was able to successfully cancel the check-in transaction.
June 2015 Page 59 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 50– Check-in Transaction Response – ‘CANCELL ED’
You may attempt to cancel another transaction by clicking on the ‘Back’ button.
June 2015 Page 60 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
3.5 Submit Batch APP/CTA Transactions
The Submit Batch APP/CTA Transactions function enables you to submit a number of APP or
CTA Transactions in one operation by supplying a file containing the check-in data for a group of
passengers or crew in case of APP and applicant data for CTA.
Batch Transactions may be provided in either of the following file formats:
• Microsoft Excel spreadsheet file. These files must have an extension of ‘.xls’ or ‘xlsx’
• Comma Separated Value (CSV) file, equivalent to a Microsoft Excel spreadsheet file. These files must have an extension of ‘.csv’.
The following figure demonstrates the overall process for submitting batch transactions for both APP and CTA:
Figure 51– Submit Batch APP/CTA Transactions Proces s
To submit a batch transactions perform the following:
1. From the Function Menu screen, click on the ‘Submit Batch APP/CTA Transactions’ button.
The Submit Batch Transactions screen is displayed:
June 2015 Page 61 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 52– Submit Batch Transactions screen
2. Complete the following fields:
Field Name Description and Validation
Your Batch
Reference
A description entered by you to identify the batch file
This field is optional.
You may enter any number or character combination.
Select Batch
File
The file path location of the batch file.
You may enter the file path directly or use the ‘Browse’ button
to locate the required csv, xls or xlsx batch file.
Figure 53– Submit Batch of APP Transactions
3. When you have completed the above fields, to procee d with the batch file submission, click on the ‘Submit’ button. Alternatively, click on the ‘Menu’ button to return to the APP Function Menu without uploading the selected batch file.
June 2015 Page 62 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
If you proceed to upload the batch file, the application first validates whether the attached file
is a csv, xls or xlsx format file. If the file is does not have a csv, xls or xlsx file extension, the
application remains on the submission screen and displays the following message:
File extension must be .xls, .xlsx or .csv.
If the file extension of the attached file is compliant, the application sends the file from your PC
to the APP server. When the file is received, the system will display a result screen with a status
message and the following information:
Heading Description
Batch Type Identifies the Batch File as containing APP transactions
Your Reference The description that you entered at the time of submission for
identification of the batch submission
Batch
Reference
A sequential unique reference number generated by the
system to identify the batch submission
File Type The format of the submitted file: csv, xls or xlsx
Records The number of APP check-in transactions submitted in the
attached file
Figure 54– Submit Batch of APP Transactions results
The status messages are summarised as follows:
Message Description
File uploaded Indicates that the file was in the correct format and was
successfully uploaded to the Carrier Portal server
Spreadsheet
file cannot be
opened
Indicates that the file that you are attempting to submit
cannot currently be opened by the application
Unrecognised
batch file
format
Indicates that the file can be opened by the application but its
format does not conform with the APP transaction batch file
specification
Figure 55– Submit Batch of APP Transactions submiss ion status messages
Note: This screen indicates only that a batch file has been received. It does not mean that all transactions have been successfully processed.
June 2015 Page 63 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
As part of the batch submission workflow, you must check that all the individual records have
been successfully processed for the batch. To do this, use the Enquiry on Submitted APP/CTA
Batches, described in the following section.
3.6 Enquiry on Submitted Batches
The Batch Enquiry enables you to manage the batch files that you have previously submitted.
The following figure demonstrates the overall process for enquiring on APP and CTA batch file
submissions:
Figure 56– Enquire on Submitted Batches process
To enquire on previously submitted APP and CTA batches, perform the following:
1. From the Function Menu screen, click on the ‘Enquir e on Submitted APP/CTA Batches’ button.
The Batch Enquiry screen is displayed.
Men
uD
isp
lay
all u
sers
Men
u
Men
u
Men
u
June 2015 Page 64 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 57– APP Batch Enquiry screen
2. Complete the following fields:
Field Name Description and Validation
Batch Type Type of batch: � APP � CTA
User Batch
Reference
The description entered by the user to identify the batch file.
Batch ID Unique reference number generated by the system to identify the batch file.
User ID Code used to identify the user. A partial User ID may be entered for the search.
Batch Status Status of the batch: � Receiving � Received � Processing � Processing Complete
Submit
Method
Method used to submit the batch file: � Carrier Portal (file upload on Carrier Portal) � Email/FTP (file emailed or sent via FTP)
Date Range The start and end of a date range to be searched can be entered here or the pop-up calendar can be used to populate these fields by clicking on the field. These fields can be used to search for batch files submitted within a specific date range
June 2015 Page 65 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 58– Search Batches
3. When you have completed the above fields click on ‘ Search’ button to search for a batch or click ‘Sear ch’ button without entering any criteria to view all ba tches.
Figure 59– Batch Search result
June 2015 Page 66 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
3.6.1 View Individual Transactions Submitted in a Batch F ile
To determine the status of each of the APP transactions submitted in a batch file, perform the
following:
1. From the Batch Enquiry screen, click on the hyperli nked Batch ID of the batch submission for which you wish to view the individual transaction details.
Figure 60– APP Batch Enquiry screen – view individu al transactions
The APP Batch Detail Enquiry screen is displayed:
Click Batch ID hyperlink to
view details of the
submitted file
June 2015 Page 67 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 61– APP Batch Detail Enquiry screen
The APP Batch Detail Enquiry screen displays the batch transactions, together with the system
response to each one. By default, the screen displays only the unsuccessful transactions.
Using the radio buttons and the Select button located on the top of the screen you can select
one of the following statuses to be displayed:
Radio button status Records displayed
All Displays both successful and unsuccessful transactions
Successful Displays only the successful transactions
Unsuccessful Displays only the unsuccessful transactions
Figure 62– APP Batch Detail Enquiry – select displa y status
The following details are displayed for each individual APP transaction within the batch file:
Field Name Description and Validation
No. Serial number of the transaction.
Doc Type Document Type submitted in the transaction.
June 2015 Page 68 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Field Name Description and Validation
Document
Number
Travel Document number submitted in the transaction.
Date of Expiry Date of Expiry submitted in the transaction.
Issuing State Issuing State submitted in the transaction.
Family Name Family Name submitted in the transaction.
Given Name(s) Given Names submitted in the transaction.
Nationality Nationality submitted in the transaction.
Date of Birth Date of Birth submitted in the transaction.
Sex Sex code submitted in the transaction.
Country of Birth Country of Birth submitted in the transaction.
Override Override submitted in the transaction, if any.
Response Response for the transaction.
This will be an error detected by the Carrier Portal, an error returned from the
AP or a boarding directive returned from the AP.
[Download] Will initiate the download of batch records currently being displayed on the
screen.
[Back] Takes the user back to the Batch Search for Batch Transaction & Search Results
screen.
[Print] Prints the current screen.
[Previous ] Displays the previous set of Search Results retrieved that match the selection
criteria entered.
Only available on the second and subsequent set of results.
[Next] Displays the next set of Search Results retrieved if more than 15 records are
found matching the search criteria.
Only available from the first to the penultimate set of results.
Figure 63- Enquire on APP Batch detail data fields
June 2015 Page 69 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
To download a copy of the submitted batch that includes the system responses, perform the
following:
1. Click on the ‘Download’ button.
The system displays the Batch Response Download screen. This shows the selected submitted
batch reference details and hyperlinks for either downloading or opening the response batch
spreadsheet.
Figure 64: Download Batch Response
The system opens the selected response file in Excel or CSV, depending on the original format
of the submitted transaction list.
Note : The downloaded batch will include only those transactions that are currently displayed, i.e. Unsuccessful, Successful or All depending on the radio button status.
You can use a downloaded unsuccessful transactions file to correct and resubmit any
unsuccessful transactions. The results of the resubmission should then again be checked
through the APP Batch Enquiry screen.
June 2015 Page 70 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
3.7 Flight Close
The Flight Close function allows you to request the generation of a manifest message for a
flight, indicating that it is closed. There are two functions, one for inbound flights and one for
outbound. The generation of the requested manifest message is performed on the Application
Processor and will be transmitted to the appropriate government system in the required format
without further involvement from you. A manifest request may be generated by directly
selecting the Flight Close menu item or alternatively by selecting the ‘Close Service’ button after
checking-in the last passenger on a flight.
The following figure illustrates the overall ‘Flight Close’ process.
Figure 65– Flight Close Request process
To generate a Flight Close, perform the following:
1. From the APP Function Menu screen, click the “Servi ce (Flight) Management and Individual APP Transactions”. The system displays the List Service s screen.
Ex
it
June 2015 Page 71 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
2. Enter the flight service details then click the ‘Se arch’ button. The search results will be displayed as follows:
Figure 66– Flight Close Transaction screen
3. Choose the flight to close by clicking the correspo nding radio button on the screen.
4. Click on the ‘Close’ button to send the request. Al ternatively, click the ‘Back’ button to return to t he APP Function Menu screen.
Upon submission the application commences processing the request. You may receive one of
the following responses:
3.7.1 APP Communications Error
If there is no network communication, you can either attempt to perform another request by
clicking on the ‘Back’ button, or alternatively click on the ‘Menu’ button to return to the APP
Function Menu screen.
June 2015 Page 72 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
3.7.2 Request Accepted and Queued
If the system is able to successfully submit the Flight Close to the AP and there are expected
movements for the submitted flight, the Flight Close is placed in the queue and the following
screen is displayed:
Figure 67– Flight Close Accepted and Queued
The only option you have from this screen is to click the ‘Back’ button and return to the APP
Function Menu.
3.7.3 No Movements Found
If the system is able to successfully submit the Flight Close to the AP but finds that there are no
expected movements for the submitted flight, the following screen is displayed:
June 2015 Page 73 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 68– Flight Close No Movements Found
If you receive this response, you can either amend the flight data and re-submit the request or
alternatively click on the ‘Menu’ button to return to the APP Function Menu screen.
June 2015 Page 74 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
3.8 Information for Carriers
This function enables you to choose a variety of information on the API UAE System and the
ability to download documentation on carrier obligations with respect to the APP System and
technical information on the APP System. The information may include:
• Static information such as Carrier Mandates, Decree, …
• Documents
• Circulars
• User Guides
• Contact forms
• News provided by UAE Government
• CSV, XLS and XLSX templates provided by SITA.
To display the list of documents relevant to the carriers, do the following:
1. From the Information for Carriers screen, click on the hyperlinked title for which you wish to view th e specific document.
3.9 Change Password
This function enables you to select a new password.
Please refer to 2.3.1.2 Change Password section for more details.
June 2015 Page 75 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
4. Carrier Administrator Functions
4.1 Carrier Administrator Functions Overview
In addition to the functions available for carrier administrators as normal users, the following
functions are available to Carrier Portal administrators only. These are shown in the following
table:
Note : Almost all Carrier User Functions (from previous chapter) can be used by Carrier Administrators with the addition of ‘Add new carrier user’, ‘List and modify carrier user and List Carrier Users Audit Log’. This chapter will only discuss these three additional functions.
Carrier Portal Administrator menu Description
Add new carrier user This function enables administrators to add a new carrier user.
List and Modify carrier users This function enables administrators to maintain a carrier user.
List Carrier Users Audit Log This function enables administrators to view the audit log screen.
Figure 69–Carrier Administrators Function
June 2015 Page 76 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
4.2 Add New Carrier User Account
Carrier Administrators are able to add new Carrier User accounts to the system.
To do this:
1. Select the Add New Carrier Company user function fr om the menu screen.
The Add New Carrier User Account screen is displayed.
Figure 70– Add New Carrier User Account Screen
2. Enter the following information in the applicable f ields:
Dialog Field Name Description
Family Name The Family name of the user. This must be entered.
Given Names The Given names of the user. This must be entered.
Password Enter a password for the Carrier Company User. The password must comply with the password rules as specified by the Government of UAE. The user must update the supplied password at first login. This must be entered.
June 2015 Page 77 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Dialog Field Name Description
Telephone Contact Enter the telephone contact for the user. This must be entered.
Facsimile Number Enter the facsimile number of the user. Email Address Enter a valid email for the user.
This must be entered. Account Expiry date Specify the account expiry date for the user.
The default value is one year from the date of account creation. This is the maximum allowable date.
Status Status of the account will be set to ‘Provisional’. Login Type Specify whether the user account is to be a
normal or batch upload user account.
Figure 71– Carrier User fields
3. To complete the Add New Carrier User Account, press the ‘Create’ button.
If successful, the screen is updated with a message showing the successful creation of the new
account.
You can then either return to the main menu by clicking the ‘Menu’ button, or add another new
carrier user account by clicking the ‘Add Another’ button.
4.3 Modify Carrier User Account
Carrier Administrator Users are able to modify the account details of existing Carrier user
accounts.
To do this:
1. Select the Modify Carrier User Account function fro m the menu screen.
The Modify Carrier User Account screen is displayed.
June 2015 Page 78 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 72– Modify Carrier User Account
2. Search for the user account that you wish to modify .
You can search by User ID, Family Name, or any other editable field. The search function
supports partial matching.
June 2015 Page 79 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 73: Users List
3. Click on the User ID for the account that you want to modify.
The account details for the selected user will be displayed.
June 2015 Page 80 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 74– Modify Carrier User Account
4. Update the fields as required as described in Figur e 71– Carrier User fields above.
5. Click ‘Update’ to confirm the changes.
Alternatively, select ‘Back’ to return to the account search to return to the menu screen. In
both these cases, all changes made to the user account are lost.
June 2015 Page 81 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
4.4 List Carrier Users Audit Log
The List Carrier Users Audit Log function will be available to Carrier Administrators only. This
facility will enable the user to view audit logs of system activities for a particular Carrier User or
for all Carrier Users from a specified date.
Some examples of what events will be logged for Carrier Users:
• Carrier User Account created or edited by a Carrier Administrator
• Carrier User accepts conditions of use
• Successful log-in by Carrier User
• Unsuccessful log-in by Carrier User
• Password change by Carrier User.
The following figure illustrates the List Carrier Users Audit Log process.
Figure 75- List Carrier Users Audit Log Process
June 2015 Page 82 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
1. From the APP Function Menu screen, click on the ‘Li st Carrier Users Audit Log’ button.
This screen will be displayed to search for audit log records:
Figure 76- List Carrier Users Audit Log Search scre en
2. Complete the following fields:
Dialog Field Name
Description
From date Enter the Transaction date from which audit log entries will be displayed. Mandatory.
To date Enter the Transaction date to which audit log entries will be displayed. Mandatory.
For User ID Enter specific User ID for searching.
Figure 77- List Carrier Users Audit Log Search fiel ds
June 2015 Page 83 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
3. When you have completed the above fields, to procee d with the User Audit Log, click on the ‘Search’ button. Alternatively, click on the ‘Back’ button t o return to the APP Function Menu without doing a search function.
This screen will display audit log records that match the search criteria:
Figure 78- List Carrier Users Audit Log Search Resu lts screen
Dialog Field Name
Description
Date/Time The date and time the auditable event occurred.
User ID The User ID of the user who actioned the auditable event.
Action The description of the auditable event that occurred.
Figure 79 – List Carrier Users Audit Log Search res ults field
June 2015 Page 84 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
5. CTA Application Functions
The CTA subsystem provides an alternative method for applicants to submit applications for CTAs
through an Internet-based service. This allows users anywhere to lodge an application for a CTA and
enquire on the status of this application.
Air crew operating into UAE who are not UAE passport holders must hold a Crew Travel Authority (CTA)
or a visa. The airlines could apply for CTAs using the normal ETAS facilities but, in practice, crew are
typically processed through systems separate from the airline reservations and passenger check-in
systems.
Users have access to the following CTA specific functions:
• Submit individual CTA application for a crew member
• Enquire on CTA application status for a crew member
• Submit a batch of CTA applications
• Enquire on status of submitted CTA batches and retrieve results.
5.1 Submit Individual CTA Application
The Individual CTA application function enables a user to submit an application for individual crew
member, both operating and positioning crew, to the CTA sub-system.
Figure 80- Submit Individual CTA application proces s
June 2015 Page 85 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
To submit an individual CTA application, perform the following:
1. From the CP User Menu screen, click on the ‘Individ ual CTA Application’ button.
The system displays the first data entry screen for the Individual CTA Application process. This
screen has the following appearance:
Figure 81– Individual CTA Application – Screen 1
2. Complete the fields as follows:
Field Name Description and Validation
Passport Number Passport number as indicated on the passport title page.
Mandatory.
Only letters and digits allowed. Any embedded spaces are removed.
Validation of format against nationality is NOT done on the website. This is done
by the AP when the application is submitted.
June 2015 Page 86 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Field Name Description and Validation
Nationality Nationality as indicated on the travel document.
You must enter a value in this field.
May be typed directly or selected from the dropdown list.
If you type in the Nationality, the drop-down list is automatically populated with
the entered Nationality.
Date of Birth The date of birth of the person as indicated on the travel document.
Must be a valid date.
The entered date must lie in the range from 1 January 1901 to the current date.
If the day of the month is not known, the day may be replaced by two hyphens.
In addition, if the month is not known, the month may be replaced by three
hyphens.
Family Name Family name or surname of person as indicated on the travel document.
You must enter a value in this field.
Only letters, hyphens, apostrophes and spaces allowed.
The name must start and end with a letter. You cannot enter combinations of
hyphens and apostrophes.
Given Names Given names of person as indicated on the travel document. Individual names
must be separated by a blank. If the given names are not known, a hyphen may
be entered.
You must enter a value in this field.
Only letters, hyphens, apostrophes and spaces are allowed.
The name must start and end with a letter. You cannot enter combinations of
hyphens and apostrophes.
Sex Gender of person as indicated on the travel document.
Country of Birth Country of birth of the person as indicated on the travel document. May be
typed directly or selected from the dropdown list.
If you type in the Country of Birth, the drop-down list is automatically populated
with the entered Country of Birth.
June 2015 Page 87 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Field Name Description and Validation
Passport Expiry
Date
The expiry date of the passport as indicated on the passport title page.
Mandatory.
Must be a valid date.
Must lie in the future.
Further validation is done by the AP when the application is submitted.
Issuing State Issuing state for the travel document as specified on the front cover of the
passport and on the passport title page.
Mandatory.
If the user types in the Issuing State, the drop-down list is automatically
populated with the entered Issuing State.
Date of Issue Date of issue of the travel document as specified on the passport title page.
Mandatory.
Issuing Authority Issuing authority of the travel document as specified on the passport title page.
Mandatory.
Figure 82– Individual CTA Application – Screen 1 da ta field descriptions
3. When you have entered the data, click on the Next b utton. Alternatively, click on the Clear button to reset the entered data.
When you click the Next button the system will validate the entered data. If it is complete and passes
validation, the system displays the confirmation screen. If the entered data is not complete or valid, the
system will display an appropriate error message.
The confirmation screen (screen 2) has the following appearance:
June 2015 Page 88 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 83– Individual CTA Application – Screen 2
These fields are visible only.
4. If the information displayed on this screen is corr ect, click the Submit button, the application is submitted. To correct the data, click on the Bac k button, you are returned to the first screen.
When you successfully submit the CTA application, the system sends that application to the Application
Processor (AP). If the system does not receive a response from the AP within a configurable time, you
will receive a timeout error message. If the system receives a response from the AP the following
outcomes are possible:
5.1.1.1 Error
• A Type 9-1 message has been received.
• The Error screen is displayed with an error message or messages corresponding to the error code(s) in the AP response. These are as readable and informative as possible. You are given the option to try again.
• If you select Yes, the system returns to Application 1, with the previously entered data filled in.
• If you select No, the window closes and you are returned to the Air User Menu.
5.1.1.2 Cannot Process
• A Type 4-1 message has been received, with a status of 7020. This indicates that the AP is unable to uniquely identify the applicant within its existing database and so cannot process the application.
June 2015 Page 89 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
• Display the Cannot Process screen with a suitably worded message, requesting the applicant to contact UAE Government.
• There is one processing button on the Cannot Process screen, Close.
• When user selects Press, the window closes and the user is returned to the Air User Menu.
5.1.1.3 Alert
• A Type 4-1 message has been received, with a status of 9023. This indicates that the AP has identified a possible Alert match within its existing database and so cannot process the application.
• The system displays the Alert screen with a suitably worded message, requesting that the applicant contacts the UAE Government Contact Centre.
• You are given the option to Submit another CTA application.
• If you select Yes, the system goes to Application 1.
• If you select No, the window closes and the user is returned to the Air User Menu.
5.1.1.4 CTA Issued
• A Type 4-1 message has been received, with a status of 9004. A screen is displayed informing the user that a CTA has been issued.
Figure 84– Individual CTA Application – CTA Issued
• The user is given the option to Submit another CTA application.
June 2015 Page 90 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
5.2 Enquire on the status of an individual CTA applicat ion
The enquire on the status of a CTA application enables users to determine if a crew member
has a valid visa or CTA for travel to the UAE. The user enters part of the data supplied with their
application. The terms and conditions of any associated visa or CTA is displayed.
Figure 85- Enquire on the status of a CTA applicati on process
To enquire on a CTA application, perform the following:
1. From the CP User Menu screen, click on the ‘Visa/CT A Status Enquiry’ button.
The system displays a data entry screen in which you enter the application details for which you
require to know the status. This screen has the following appearance:
June 2015 Page 91 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 86- Enquire on the status of a CTA applicati on screen
2. Complete the fields as follows:
Field Name Description and Validation
Passport Number Passport number as indicated on the passport title page.
Mandatory.
Only letters and digits allowed. Any embedded spaces are removed.
Validation of format against nationality is NOT done on the website. This is done
by the AP when the application is submitted.
Nationality Nationality as indicated on the travel document.
You must enter a value in this field.
May be typed directly or selected from the dropdown list.
If you type in the Nationality, the drop-down list is automatically populated with
the entered Nationality.
June 2015 Page 92 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Field Name Description and Validation
Date of Birth The date of birth of the person as indicated on the travel document.
Must be a valid date.
The entered date must lie in the range from 1 January 1901 to the current date.
If the day of the month is not known, the day may be replaced by two hyphens.
In addition, if the month is not known, the month may be replaced by three
hyphens.
Family Name Family name or surname of person as indicated on the travel document.
You must enter a value in this field.
Only letters, hyphens, apostrophes and spaces allowed.
The name must start and end with a letter. You cannot enter combinations of
hyphens and apostrophes.
Given Names Given names of person as indicated on the travel document. Individual names
must be separated by a blank. If the given names are not known, a hyphen may
be entered.
You must enter a value in this field.
Only letters, hyphens, apostrophes and spaces are allowed.
The name must start and end with a letter. You cannot enter combinations of
hyphens and apostrophes.
Sex Gender of person as indicated on the travel document.
Figure 87- Enquire on the status of a CTA applicati on field descriptions
3. Click on the Next button to initiate the enquiry pr ocess.
The system will display one of the following response screens:
5.2.1.1 Error
• A Type 9-1 message has been received.
• The Error screen is displayed with an error message or messages corresponding to the error code(s) in the AP response. These are as readable and informative as possible. You are given the option to try again.
June 2015 Page 93 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
5.2.1.2 No CTA Issued
• A Type 3-1 message has been received and the data indicates that there is no valid Visa or CTA in effect.
• The user is given the option to perform another enquiry.
5.2.1.3 CTA in Effect
• A Type 3-1 message has been received and the data indicates that there is a valid Visa or CTA in effect.
• If you select Back , the window closes and you are returned to the Air User Menu.
5.3 Submit Batch of CTA Applications
Process to submit a CTA batch is similar to that for APP batches documented in section 3.5 Submit Batch
of APP Check-in Transactions.
5.4 Enquire on the status of batch CTA applications
The enquire on the status of batch CTA applications function enables users to assess the status of CTA
applications submitted via batch file. The enquiry enables you to assess the status of the batch file itself
and the vetting result of each application within the batch file.
To enquire on previously submitted APP batches, perform the following:
1. From the Function Menu screen, click on the ‘Enquir y on Submitted APP/CTA Batches’ button.
The Batch Enquiry screen is displayed.
June 2015 Page 94 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 88– APP Batch Enquiry screen
2. Complete the following fields:
Field Name Description and Validation
Batch Type Type of batch: � CTA
User Batch
Reference
The description entered by the user to identify the batch file.
Batch ID Unique reference number generated by the system to identify the batch file.
User ID Code used to identify the user. A partial User ID may be entered for the search.
Batch Status Status of the batch: � Receiving � Received � Processing � Processing Complete
Submit
Method
Method used to submit the batch file: � Carrier Portal (file upload on Carrier Portal) � Email/FTP (file emailed or sent via FTP)
Date Range The start and end of a date range to be searched can be entered here or the pop-up calendar can be used to populate these fields by clicking on the field. These fields can be used to search for batch files submitted within a specific date range
Figure 89– Search Batches
June 2015 Page 95 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
3. When you have completed the above fields click on ‘ Search’ button to search for a batch or click ‘Sear ch’ button without entering any criteria to view all ba tches.
Figure 90– Batch Search result
June 2015 Page 96 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
5.4.1 View Individual Transactions Submitted in a Batch F ile
To determine the status of each of the CTA transactions submitted in a batch file, perform the
following:
4. From the Batch Enquiry screen, click on the hyperli nked Batch ID of the batch submission for which you wish to view the individual transaction details.
Figure 91– Batch Enquiry screen – view individual t ransactions
The Batch Detail Enquiry screen is displayed:
Click Batch ID hyperlink to
view details of the
submitted file
June 2015 Page 97 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 92– Batch Detail Enquiry screen
The Batch Detail Enquiry screen displays the batch transactions, together with the system
response to each one. By default, the screen displays only the unsuccessful transactions.
Using the radio buttons and the Select button located on the top of the screen you can select
one of the following statuses to be displayed:
Radio button status Records displayed
All Displays both successful and unsuccessful transactions
Successful Displays only the successful transactions
Unsuccessful Displays only the unsuccessful transactions
Figure 93– Batch Detail Enquiry – select display st atus
The following details are displayed for each individual CTA application within the batch file:
Field Name Description and Validation
No. Serial number of the transaction.
June 2015 Page 98 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Field Name Description and Validation
Passport Number Applicant’s Passport Number
Nationality Nationality of applicant’s passport
Family Name Family name or surname of applicant
Given Name(s) Given names of applicant
Date of Birth The date of birth of the applicant
Sex Sex of applicant. � M-Male � F-Female
Country of Birth Country of birth of the applicant.
Passport Expiry Date
The expiry date of applicant’s passport
Response Response for the transaction. This will be an error detected by the Carrier Portal, an error returned from the AP or application outcome returned from the AP.
[Download] Will initiate the download of batch records currently being displayed on the screen.
[Back] Takes the user back to the Batch Search for Batch Transaction & Search Results screen.
[Print] Prints the current screen.
[Previous ] Displays the previous set of Search Results retrieved that match the selection criteria entered. Only available on the second and subsequent set of results.
[Next] Displays the next set of Search Results retrieved if more than 15 records are found matching the search criteria. Only available from the first to the penultimate set of results.
Figure 94- Enquire on CTA Batch detail data fields
To download a copy of the submitted batch that includes the system responses, perform the
following:
5. Click on the ‘Download’ button.
The system displays the Batch Response Download screen. This shows the selected submitted
batch reference details and hyperlinks for either downloading or opening the response batch
spreadsheet.
June 2015 Page 99 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 95: Download Batch Response
The system opens the selected response file in Excel or CSV, depending on the original format
of the submitted transaction list.
Note : The downloaded batch will include only those transactions that are currently displayed, i.e. Unsuccessful, Successful or All depending on the radio button status.
You can use a downloaded unsuccessful transactions file to correct and resubmit any
unsuccessful transactions. The results of the resubmission should then again be checked
through the Batch Enquiry screen.
June 2015 Page 100 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
6. Automated Batch Upload Functions
6.1 Introduction
There are other ways to allow users to submit batches in a more automated fashion, without
logging in to the Carrier Portal website. This chapter describes the facility to receive batches
through different transmission protocols.
6.2 FTPS
Carrier operators can create batch files of APP check-in data and upload them using a FTPs
client program (e.g. WinSCP1) into a designated server location which has been set up for that
particular carrier. For example for British Airways (BA), there will be a FTPs server location
which will be setup and shared only by BA carrier operators for uploading batch files.
The file format for automatic batch upload will be the same as what is used in the normal UCP
batch upload process (i.e. - csv, xls and xlsx file).
How to upload a file using SFTP Protocol:
1. Create a batch file and save it in the local system. Make sure the file structure and format
are valid.
2. Run WinSCP (or similar FTPs client program) and login to the remote UCP using the User
ID/password which was provided to the carrier during registration. Also indicate ‘SFTP’ as
the File Protocol for the session.
3. Copy the batch file (using drag and drop method) from the local system into the remote
server ‘transfer’ directory - e. g. “.../transfer/ftps/BA/data”.
1 WinSCP is an open source free FTP client program for Windows. Its main function is for secure file transfer between local and remote
computer. Download website is “http://winscp.net/eng/download.php”.
June 2015 Page 101 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
4. Once the file has been copied, it will be picked up automatically and processed by the auto-
batch process which is running on the remote server.
5. After processing is complete, an email containing the summary of results will be sent to the
carrier.
June 2015 Page 102 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
6.3 Email Attachment
Carrier operators can create batch files of APP check-in data and send them via email
attachment. Upon registration to use the email facility, UAE-GCAA will assign a dedicated email
account to the carrier for receiving batches. For example, XYZ airline will have an email address
of “[email protected]”.
The file format for automatic batch upload will be the same as what is used in the normal UCP
batch process – i.e. csv, xls and xlsx. For transmission security, this file must be encrypted (using
Gpg4win**) before attaching to the email. Therefore the encrypted file to be attached must
have a ‘.gpg’ extension.
How to upload a file as an Email attachment:
1. Create a batch file and save it in your local system. Make sure the file structure and format
are valid.
2. Encrypt the batch file by running ‘Kleopatra’ (Gpg4win2) and use the digital certificate
provided by UAE-GCAA.
3. Click on File �Sign/Encrypt Files menu.
2 Gpg4win (Kleopatra) is a file encryption software for most versions of Microsoft Windows, which uses GnuPG public-key cryptography for data
encryption and digital signatures. It enables users to securely transport emails and files with the help of encryption and digital
signatures. Usage of Gpg4win and its included software are free of charge for all commercial and non-commercial purposes. Download
website is “http://gpg4win.org/download.html”.
June 2015 Page 103 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
4. Locate and open the batch file to encrypt.
5. Choose “Encrypt” radio button on the next screen and click the ‘Next’ button.
June 2015 Page 104 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
6. Highlight the Digital Certificate provided during registration.
7. Click the ‘Encrypt’ button at the bottom of the screen.
June 2015 Page 105 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
8. Upon successful process, the result will be displayed on the screen, click ‘Finish’.
9. In Windows Explorer, the encrypted file (with a file extension of ‘.gpg’) will be created
on the same directory as the batch file.
10. Send an email to the dedicated email account with the encrypted (.gpg) file as attachment.
11. Once the email has been received by the server, it will be processed automatically by the
auto-batch system.
June 2015 Page 106 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
12. After processing is complete, an email containing the summary of results will be sent to the
carrier.
6.4 HTTPS
The current version of Carrier Portal does not support this facility. The HTTPS facility has been
replaced by FTPs and Email Attachment methods. Carriers are advised to use these facilities
which are more secure and reliable.
6.5 APP Batch File Format
This section describes the batch file format for APP Transactions for Carrier Users.
The batch data may be provided in either of the following formats:
• Microsoft Excel spreadsheet file. These files must have an extension of ‘xls’ or ‘xlsx’.
• Comma Separated Value (CSV) file. These files must have an extension of ‘csv’.
In this document the file formats are described in terms of the spreadsheet format.
There will be no restriction on batch file names, apart from the extension requirements defined
above. The file name will not be used to identify the batch. It will be identified by a reference
provided by the user when the batch is submitted.
APP Transaction Batch Structure
This file format may be used for APP Check-in and Cancellation transactions, for Operating
Crew, Positioning Crew or Passengers. A single file may contain any number of sub-batches;
each sub-batch consists of the data for:
• A single flight by an airline company
• Either check-in or cancellation transactions
• One of: Operating Crew, Positioning Crew or Passengers.
Each sub-batch will consist of a header section and a body section. The header section will
define the flight, transaction type and Traveller type (Operating Crew, Positioning Crew or
Passenger). The body section will contain one row of data for each Traveller.
June 2015 Page 107 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
The sequence of rows in the file will be as follows:
• Heading rows preceding the transaction data. These may be column headings or other documentation inserted by the user who created the spreadsheet. These rows will be ignored
• A row containing ‘***HEADER’ in the first cell will indicate the beginning of the header section of a sub-batch. The header section will consist of rows each containing a data label in the first cell and a data value in the second cell. These rows may occur in any order
• A row containing ‘***START’ in the first cell will indicate the beginning of the body section of the sub-batch
• The body section will consist of a single row of APP Transaction data for each Crew member or Passenger, with the individual fields conforming to the rules for an Air transaction.
• A row containing ‘***END’ in the first cell will indicate the end of data for a sub-batch
• Subsequent occurrences of the rows from ‘***HEADER’ to ‘***END’ will contain data for other sub-batches
• Any further documentation rows inserted by the user following the final ‘***END’ will be ignored by the system
• Blank rows anywhere in the spreadsheet will be ignored.
Batch file example
This data is in CSV format using Version 2 Batch file format. The conversion inserts trailing
commas for trailing null fields. These commas are not mandatory and files that are not
generated by Microsoft Excel need not include them.
Document Number,Nationality,Document Type,Issuing State,Family Name,Given Names,Date of Birth,Sex,Country of Birth,Expiry Date,Travel Type,Override,Response ***VERSION 2,,,,,,,,,,,, ***HEADER,,,,,,,,,,,, *TYPE,P,,,,,,,,,,, *DIRECTION,I,,,,,,,,,,, *FLIGHT,SV1064,,,,,,,,,,, *DEP PORT,DXB,,,,,,,,,,, *DEP DATE,20-Oct-10,,,,,,,,,,, *DEP TIME,0800,,,,,,,,,,, *ARR PORT,RUH,,,,,,,,,,, *ARR DATE,20-Oct-10,,,,,,,,,,, *ARR TIME,0930,,,,,,,,,,, *TB PORT,,,,,,,,,,,, *TB DATE,,,,,,,,,,,, *TB TIME,,,,,,,,,,,, ,,,,,,,,,,,, ***START,,,,,,,,,,,, 869987654,GBR,P,,BROWN,ARTHUR JOHN,10-Jun-1960,M,GBR,15-Jul-2012,T,, 123700502,USA,P,,CLARK,BILLY ADAM,15-Apr-1981,M,USA,15-Aug-2012,X,, 859987635,GBO,P,GBR,EDWARDS,DAVID ROBERT,5-Apr-54,M,,,N,, E7498072,AUS,P,,FOSTER,EVAN,5-May-56,M,,,N,,
June 2015 Page 108 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
CA0277982,KOR,O,GBR,SONG,JENNY,16-Apr-44,F,,,N,G, ***END,,,,,,,,,,,,
Example APP Transaction (Airline) Batch Version 2 ( CSV format)
6.6 CTA Batch File Format
This section describes the batch file format for CTA Batch Files for Carrier Users.
The batch data may be provided in either of the following formats:
• Microsoft Excel spreadsheet file. These files must have an extension of ‘xls’ and ‘xlsx’
• Comma Separated Value (CSV) file. These files must have an extension of ‘csv’
In this document the file formats are described in terms of the spreadsheet format.
There will be no restriction on batch file names, apart from the extension requirements defined
above. The file name will not be used to identify the batch. It will be identified by a reference
provided by the user when the batch is submitted.
CTA Application Batch Structure
Crew Transaction File – Excel Spreadsheet Format
The sequence of rows in the Microsoft Excel spreadsheet is as follows:
• Heading rows preceding the application data for individual crew members. These may be column headings or documentation inserted by the user who created the spreadsheet.
• A row containing “***START” in the first cell indicates that the following rows contain application data. This row will also contain “V3” in the second cell to indicate that the following data conforms to this specification rather than the earlier format.
• CTA application data formatted as a single row for each applicant, with the individual fields conforming to the previously stipulated rules.
• The end of data for individual applications is denoted by a line containing only “***END” in the first cell.
• Any further documentation rows inserted by the user following the “***END” are ignored by the web site processes.
Blank rows anywhere in the spreadsheet are ignored.
CTA Application Result File – Excel Spreadsheet Format
The file structure is the same as for the CTA Application File with the response for each
application inserted in column 12.
June 2015 Page 109 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Detailed examples of the specific structures of the various CTA batch formats are provided in
Appendix F – CTA Batch File Formats.
June 2015 Page 110 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
API UAE Project
UAE General Civil Aviation Authority
Carrier Portal User Manual
Appendices
June 2015 Page 111 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Appendix A – Glossary of Terms
Term Description
Alert More strictly Alerted Referral . This denotes a passenger who has one or more hits – that have been qualified-in – against him or her. An alert typically results in interception of the passenger. ARAS typically sends notifications (SMS, email, and in later phases a message to the Primary Line system) to warn the Intervention team(s) of the need to take action. See also hit and referral.
API Advance Passenger Information . A term that can mean specifically APIS or, more generally, a set of techniques (including APIS and APP) to declare information on passengers prior to their arrival in a country.
APP Advance Passenger Processing is a standard for flight and document data declaration in real-time. It has strong similarities with APIS in terms of what traveller and flight data the government receives. The key difference is timing. APP takes place as a real-time interactive transaction during check-in. This enables the government to check databases of passports, visas and alerts, and according to government-dictated business rules, deny or allow boarding. In contrast, APIS is inherently a batch process (normally done post-departure).
ARAS Advance Risk Assessment System . The integrated border (iBorder) management system that SITA proposes to deliver and operate for GCAA.
AQQ APIS Quick Query . A form of interactive, real-time APIS defined by the US Customs and Border Protection agency which is similar in concept to APP. The United States as of February 2008 mandated that airlines must supply pre-departure advance passenger information so that the US can prevent high-risk suspects from flying.
AQQ Gateway SITA offers APP�AQQ conversion services to airlines enabling the airline to standardise on APP. The airline sends one APP transaction and SITA converts and forwards the information to all governments with a legitimate interest in the data. SITA transmits the information in the appropriate format for each government (be it AQQ or APP) and collates the responses (APP, AQQ) to return a single consolidated response to the airline.
Arrival Port Port code submitted in an APP check-in request that indicates where the person disembarks from the service. For air carriers this will be the airport code. For surface carriers this will be the UN/LOCODE of the location.
ARS Airline Reservation System (also known as CRS or Res). This is the inventory system used by an airline to record passenger reservations.
Blacklist The watchlist used by ARAS to provide APP boarding directives.
Boarding Directive A directive returned by APP to the carrier in response to a check-in request. Boarding directives are generally classified as positive indicating that the traveller is able to travel on the service or negative indicating that there is a problem and the traveller is not able to travel on the service.
Booking Record Equivalent to PNR.
June 2015 Page 112 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Term Description
Carrier Denotes a company that transports passengers and/or goods.
A carrier can be a: • Scheduled airline – airlines can be of different types, including passenger, charter
and cargo • General aviation – private aircraft and small charters shipping – cruise or ferry
companies
• Bus or coach – companies that transport people by bus or coach
• Cruiseline – companies that transport people by sea.
Check-in The event of assigning a physical seat on a flight to a passenger. This event usually occurs close to the actual take-off of the flight and involves the passenger handing over their luggage to the carrier for transport to their destination. Also see DCS.
Check-in Port Port code submitted in an APP check-in request, which indicates where the person is checking-in for a service. For air carriers this will be the airport code. For surface carriers this will be the UN/LOCODE of the location.
Code Share An agreement between airlines to sell space on each other's flights. The flights will have both the operating carrier's flight number and the code sharing flight number. The operating carrier or airline uses the aircraft and the code sharing carrier sells space on the aircraft.
Communications Gateway
Original name for the SITA Industry Hub for APP now called Government Gateway.
Crew Travel Authority (CTA)
Electronic travel authority used by airline carriers for crew.
DCS Departure Control System – the system used by carriers to check travellers on to services.
Departure Port Port code submitted in an APP check-in request, which indicates where the person will board the service. For air carriers this will be the airport code. For surface carriers this will be the UN/LOCODE of the location.
DNRD Department of Naturalization and Residency Dubai.
EES Entry/Exit System – the Primary Line system of the UAE.
Escalation System action that automatically forwards an alert to the next level of command (if any), if the original set of recipients have not viewed it within a pre-determined period.
Electronic Travel Authority (ETA)
An electronically stored authority for travel to the UAE that will be used in lieu of a visa for certain travellers.
Expected Port Port code submitted in an APP check-in request, which indicates where the person is expected to cross the primary line to either enter or leave UAE. For air carriers this will be the airport code. For surface carriers this will be the UN/LOCODE of the location.
e-Visa The sub-system within the ARAS that is used to process specific traveller visas types.
FFP Frequent Flyer Programme – A service offered by many airlines to reward customer loyalty. Typically, airline customers enrolled in the programme accrue points corresponding to the distance flown on that airline. Accrued points (also known as frequent flyer miles) can be redeemed for free air travel; for other goods or services; or for increased benefits, such as airport lounge access or priority bookings.
Flight Close A request sent by the carrier to the APP system indicating that the check-in process is complete and the flight is about to commence its journey.
Flight Manifest List of all passengers on a flight and their biographical data (Equivalent to APIS).
FOP Form Of Payment – The method used to pay for a booking together with details of this method, contained within a PNR.
June 2015 Page 113 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Term Description
GCAA UAE General Civil Aviation Authority .
GDS Global Distribution System – primarily Amadeus, Apollo, Galileo, Sabre and Worldspan. GDSs are the predominant method of distribution for scheduled air flights. They are a major distribution channel for car and hotel bookings – especially for business travellers.
Go-show Term used for a traveller who has no reservation (PNR record) but who turns up at the airport, buys a ticket at the airport and checks on to a flight. In this case, the traveller has an API and DCS record, but no PNR.
Hit Evaluation by ARAS that a given person flying a particular journey may pose a risk (risk score exceeds configured thresholds). Hits are generated by two mechanisms: through checking against the watchlist(s) and by PNR Profiling against the passenger data. Hits are then qualified – either manually or automatically. Only hits that are qualified-in are acted upon. See also referral and alert.
iAPI, iAPIS Interactive API – a generic term for real-time Advance Passenger Information incorporating APP and AQQ. iAPI allows the government to issue a boarding directive and to check the quality of the submitted data.
IATA International Air Transport Association – International Air Transport Association (IATA), established in 1945, is a trade association serving airlines, passengers, shippers, travel agents, and governments. The association promotes safety, standardisation in forms (baggage checks, tickets, weigh bills), and aids in establishing international airfares.
iBorders iBorders is the name of SITA’s border management product portfolio encompassing Border Management solutions ranging from the electronic application and issuing of Visas through to Advance Passenger Processing (APP) systems, risk assessment and visualisation tools and biometric identity management.
ICAO International Civil Aviation Organization (ICAO), an agency of the United Nations, codifies the principles and techniques of international air navigation and fosters the planning and development of international air transport to ensure safe and orderly growth.
Match A match occurs when a passenger record is equivalent, or similar following predefined criteria, to another record on a watchlist.
MOI Ministry of Interior , UAE.
Movement Record Created for a traveller as part of the APP process. The movement record contains details of the traveller and the service they are using. Three types of Movement Record are possible in APP. Expected Movement Record is where APP returned a positive boarding directive to the carrier and the Traveller is expected to travel on the service. Denied Movement Record is where APP returned a negative boarding directive to the carrier and the traveller is not expected to travel on the service. Cancelled Movement Record is where a previous Expected Movement Record is cancelled because the traveller is not travelling on the service.
MQ / MQ Series IBM WebsphereMQ message queues. Middleware from IBM, which is almost a de facto standard to assure the delivery of messages between communicating applications.
MRZ Machine Readable Zone – an area on a travel document (passport or visa) formatted (usually according to a standard set by ICAO) for data capture by document readers and other devices. The information can vary but normally contains name, date of birth, gender, document number (such as passport), issuing country, expiry date (i.e. the non-flight information in APIS). There are also check digits in the MRZ to reduce the likelihood of misread data.
No-show Term used for a traveller who makes a flight reservation but does not show up to use it. In this case a PNR record and unfilled (no seat number) DCS record exists, but no API.
June 2015 Page 114 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Term Description
OSI Other Service Information – extra information sent by the airline, within a PNR. OSIs are distinguished from SSRs as they do not need receipt confirmation from the Airline when transmitted, where as SSRs do.
Payment Gateway Third party provider that will accept and process credit card payments.
Qualification When a referral is generated for a particular traveller record this represents a work task for the Security Analysts, who must examine the hits within the referral and rule them in or out for action by the Intervention team. This process is known as qualification. A referral can be automatically qualified and alerted to the Intervention Team by the system if one or more of its Hits meet business rules for automatic qualification.
Referral This denotes a passenger who has one or more active hits (i.e. hits that have not been qualified-out) against him or her. See also alert.
SLC Service Level Contract – the agreement that defines the performance parameters, measurement criteria and levels of service performance required for a system.
Service Close A request sent by the carrier to the APP system indicating that the check-in process is complete the service is about to commence its journey. It is equivalent to the Flight Close request but applies to all types of service.
SSR Special Service Request – extra information sent to the airline, within a PNR. SSRs are distinguished from OSIs as they need receipt confirmation from the airline when transmitted, where as OSIs do not.
Transaction Record
Created for each transaction submitted to the APP system by a carrier. A successful transaction without errors will result in creation of a movement record.
Travel Case A categorisation for a traveller used in APP processing which consists of a combination of nationality group, travel direction and travel type.
Traveller A person who changes location. Used in context to denote any person travelling, specifically either a passenger or crew member on an aircraft.
Traveller Type Type of traveller submitted in an APP check-in request, which indicates whether this person is a passenger, an operating crew member or a positioning crew member.
Type of Travel The type of travel submitted in an APP check-in request. Three types of travel are possible in APP. Normal travel type is where the traveller will cross the border when arriving to or departing from UAE. Transit travel type is where the traveller touches down in UAE on their way to a third country on a single service. Transfer travel type is where the traveller lands in UAE and changes to another service on their way to a third country.
UDB Unified Database – the centralised watchlist database for UAE that included passports and visas.
UAE Government Government of the United Arab Emirates .
UN/LOCODE The United Nations Code for Trade and Transport Locations is a geographic coding scheme developed and maintained by United Nations Economic Commission for Europe (UNECE). UN/LOCODE assigns codes to locations used in trade and transport with functions such as seaports, rail and road terminals, airports, post offices and border crossing points.
Visa An entry in a passport or other travel document made by an official of a government to indicate that the bearer has been granted authority to enter or re-enter the country concerned. (Note: a visa is not a guarantee of entry. Immigration authority on arrival has the final authority for granting entry).
Visa - waiver Instances where a visa is not required on the basis of predetermined criteria set by Immigration authorities being met. e.g. where nationals of a specific country are exempt from requiring a visa.
June 2015 Page 115 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Term Description
Watchlist List of suspects or undesirables containing some or all of name information, document information, date of birth, place of birth, reason for inclusion on the list, action to be taken. A watchlist can either be hosted remotely by the MOI, or can be the internal watchlist provided in the ARAS (referred to as the ARAS Watchlist).
Watchlist Target A record for a single person in a watchlist.
Watchlist Reason Reason the entry has been made on the watchlist – why the person is of interest.
Watchlist Severity A rating of how important, critical or sensitive an entry on a watchlist is, according to business rules set by the Watchlist Administrator. Severity is used to define which hit will take precedence where more than one Hit is made against a traveller record.
XML eXtensible Markup Language – SITA normalises travel industry data to XML because it is flexible, easy to understand and simple to manipulate using modern programming tools.
Figure 96: Glossary of terms
June 2015 Page 116 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Appendix B – Conditions of Use
The first time a Carrier User successfully logs in to the system, a page will be displayed stating
the conditions for use of the site. The user will be required to accept these conditions by
clicking the appropriate button on the page. This acceptance will be recorded on the user’s
record in the database by storing the timestamp of the event. If the conditions are not
accepted, the user’s session will be terminated by closing the secure window. The wording of
these conditions will be adjusted to match UAE Government’s security requirements. The
following shows sample text for the Conditions of Use page, since the page is too long to be
displayed in a single screen dump:
Please read this statement carefully and acknowledge your acceptance by clicking on the appropriate button at the end of the statement. If you do not accept the conditions in this way, you will not be able to use the site.
Conditions of use of this website Using the website You may only use this website for the purposes for which it is intended and which have been documented by UAE Government. Your use of this website will be logged for the purpose of security and usage monitoring. Unauthorised use of this website could result in criminal prosecution. Your responsibilities An account and the related password should not be used by more than one user of the website. Each individual must have their own account and password. Your password should be kept secret. It should not be written down and it should not be easily deduced or guessed. Your account and password information should not be provided to other individuals. If your password becomes known to anyone else, it must be changed immediately. The first time you log in with a new account or the first time you log in after your password has been reset by the system administrator, you will be required to change your password. Passwords must be from nine to twelve characters long, with at least two letters (A to Z, upper or lower case and case-sensitive) and at least one digit (0 to 9). Any other keyboard characters are also acceptable in the password. If you try to log in and are unsuccessful after six attempts, your account will be disabled and you will need to contact the system administrator. You should never leave your computer logged in to the website and unattended. If you are logged in and do not use the website for 15 minutes, you will be automatically logged out. You will then need to log in again to continue working. Your password must be changed on a regular basis, at least every 90 days. The system will remind you when this has not been done. When you change your password you will not be able to set it to values you have used previously. If you forget your password, you can call the system administrator. For security reasons, the system administrator cannot access your password on the system but, after you have identified yourself to the system administrator, your password will be reset and you will be told the new password. You must then log in and change your password immediately. Your account has an expiry date. When this date is reached, you will need to contact the system administrator to have your account authorised for a further period of time.
� I accept � I do not accept
Figure 97: Conditions of use
June 2015 Page 117 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Appendix C – APP Batch File Formats
This appendix describes the batch file format for APP Transactions for Carrier Users.
The batch data may be provided in either of the following formats:
• Microsoft Excel spreadsheet file. These files must have an extension of ‘xls’ and ‘xlsx’
• Comma Separated Value (CSV) file. These files must have an extension of ‘csv’.
In this document the file formats are described in terms of the spreadsheet format.
There will be no restriction on batch file names, apart from the extension requirements defined
above. The file name will not be used to identify the batch. It will be identified by a reference
provided by the user when the batch is submitted.
APP Transaction Batch Structure
This file format may be used for APP Check-in and Cancellation transactions, for operating crew,
positioning crew or passengers.
A single file may contain any number of sub-batches; each sub-batch consists of the data for:
• A single flight by an airline or a single service by a general aviation company or a bus or shipping company
• Either check-in or cancellation transactions
• One of: operating crew, positioning crew or passengers.
Each sub-batch will consist of a header section and a body section. The header section will
define the flight, transaction type and traveller type (operating crew, positioning crew or
passenger). The body section will contain one row of data for each traveller.
The sequence of rows in the file will be as follows (see example in Figure 100 for an Air
transactions batch):
• Heading rows preceding the transaction data. These may be column headings or other documentation inserted by the user who created the spreadsheet. These rows will be ignored
• A row containing ‘***HEADER’ in the first cell will indicate the beginning of the header section of a sub-batch. The header section will consist of rows each containing a data label in the first cell and a data value in the second cell, as specified in Figure 98 for an Air transactions batch and Figure 105 for a transaction batch for general aviation, bus or shipping services. These rows may occur in any order
• A row containing ‘***START’ in the first cell will indicate the beginning of the body section of the sub-batch
• The body section will consist of a single row of APP Transaction data for each crew member or passenger, with the individual fields conforming to the rules in Figure 99 for an Air transactions batch and Figure 106 for a transaction batch for general aviation, bus or shipping services
June 2015 Page 118 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
• A row containing ‘***END’ in the first cell will indicate the end of data for a sub-batch
• Subsequent occurrences of the rows from ‘***HEADER’ to ‘***END’ will contain data for other sub-batches
• Any further documentation rows inserted by the user following the final ‘***END’ will be ignored by the system
• Blank rows anywhere in the spreadsheet will be ignored.
June 2015 Page 119 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
AIRLINE BATCH FORMAT – VERSION 1
No. Data Label Field Name Data Type and Maximum Length
Mandatory/Optional
Comments
1 ***VERSION 1 Optional If missing or left blank, ‘Version 1’ is assumed.
2 *** HEADER Mandatory
3 *CANCEL Transaction Type
none Conditional The presence of this data label indicates a Cancellation sub-batch.
4 *TYPE Crew/ Passenger Type
Alpha (1) Mandatory The Crew/Passenger indicator for the sub-batch. Permissible values are:
• C = Operating crew
• X = Positioning crew
• P = Passenger.
5 *DIRECTION Direction Alpha (1) Mandatory The direction of the flight. Permissible values are:
• I = Inbound
• O = Outbound.
6 *FLIGHT Flight Number Alphanumeric (8) Mandatory Flight number.
7 *DEP PORT Departure Port Alpha (3) Mandatory Three-character IATA airport code.
8 *DEP DATE Departure Date Alphanumeric (11) Format DD-MON-YYYY
Mandatory Scheduled departure date from Departure Port. The date separator may also be "/","-" or "." or omitted completely. This applies to all date fields in this format in the batch. Can be today, 1 day prior to today or up to 29 days after today.
9 *DEP TIME Departure Time Numeric (4) Format HHMM
Mandatory Scheduled departure time from Departure Port. Value must be 0 if time is not known.
10 *ARR PORT Arrival Port Alpha (3) Mandatory Three-character IATA airport code for final port for flight.
11 *ARR DATE Arrival Date Alphanumeric (11) Format DD-MON-YYYY
Mandatory Scheduled arrival date at Arrival Port. Can be today, one day prior to today or up to 29 days after today.
12 *ARR TIME Arrival Time Numeric (4) Format HHMM
Mandatory Scheduled arrival time at Arrival Port. Value must be 0 if time not known.
June 2015 Page 120 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
No. Data Label Field Name Data Type and Maximum Length
Mandatory/Optional
Comments
13 *TB PORT Trans-border Port
Alpha (3) Conditional The first port in the UAE for an Inbound flight or the last port in the UAE for an Outbound flight. Only required if it is different from the Arrival Port for an Inbound flight or different from the Departure Port for an Outbound flight. Three-character IATA airport code.
14 *TB DATE Trans-border Date
Alphanumeric (11) Format DD-MON-YYYY
Conditional Scheduled arrival date at Trans-border Port for Inbound flight, or scheduled departure date from Trans-border Port for Outbound flight. Only required if Trans-border Port is provided.
15 *TB TIME Trans-border Time
Numeric (4) Format HHMM
Conditional Scheduled arrival time at Trans-border Port for Inbound flight, or scheduled departure time from Trans-border Port for Outbound flight. Only required if Trans-border Port is provided.
Figure 98: APP Transaction Batch (Air) Header Data
June 2015 Page 121 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
No. Field Name Data Type and Maximum Length
Mandatory/Optional Comments
1 Document Number
Alphanumeric (14)
Conditional Travel document number. A value is REQUIRED unless the UAE Government has given permission to board a person with no travel document.
2 Nationality Alpha (3) Mandatory Three-character ICAO nationality code.
3 Document Type
Alpha (1) Conditional Type of travel document. Permissible values are:
• P = Passport (default if data item is blank)
• O = Other
• N = None (only if there is no travel document).
4 Family Name Alpha (24) Mandatory
5 Given Names Alpha (24) Mandatory
6 Date of Birth Alphanumeric (11)
Mandatory Format DD-MON-YYYY
The date separator may also be "/", “-“ or "." or omitted completely. This applies to all date fields in this format. For date of birth ONLY, the day OR the day and the month may be omitted if not included in the travel document. Examples: DEC-1975 or 1972.
7 Sex Alpha (1) Mandatory Permissible values are:
• M = Male
• F = Female
• X = Unspecified.
8 Country of Birth
Alpha (3) Optional Three-character ICAO country code of country of birth.
9 Document Expiry Date
Alphanumeric (11)
Optional Format DD-MON-YYYY
Document expiry date as shown in the travel document.
June 2015 Page 122 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
No. Field Name Data Type and Maximum Length
Mandatory/Optional Comments
10 Override Alpha (1) Conditional Override code indicating that an earlier directive denying permission to board is being overridden after consultation with the UAE Government or assessment of the situation against published information. Only applies to Check-in transactions. Permissible values are:
• A = Override based on a decision by the airline using published rules
• G = Override based on specific advice from the UAE Government.
11 Response Alphanumeric (May include a series of error messages)
Conditional When a processed batch is downloaded from the APP System, the result of the APP transaction is placed into this column. Possible responses are described in detail in the Airline/GG Interface Specification, Version 6.76. In summary, they are:
• ‘OK to Board’
• ‘Do Not Board’
• ‘Cancelled’
• ‘No Record’
• ‘Board if Documents OK’
• ‘Contact Government’
• ‘Insufficient data’
• ‘Override Accepted’
• or various validation error messages.
Figure 99: APP Transaction (Air) Data
June 2015 Page 123 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Example Version 1 Batch File Containing a Single Sub-batch
Document Number
Nationality Doc Type
Family Name Given Names Date of Birth Sex Country of Birth
Expiry Date Override Response
***HEADER
*TYPE C
*DIRECTION I
*FLIGHT SV1064
*DEP PORT LHR
*DEP DATE 23-OCT-2010
*DEP TIME 1205
*ARR PORT DXB
*ARR DATE 23-OCT-2010
*ARR TIME 1340
*TB PORT
*TB DATE
*TB TIME
***START
869987654 GBR P BROWN ARTHUR JOHN 10-Jun-1960 M GBR 15-Jul-2012
123700502 USA P CLARK BILLY ADAM 15-Apr-1981 M USA 15-Aug-2012
859987635 GBO P EDWARDS DAVID ROBERT 5-Apr-1954 M
123708509 USA P TURNER SAMUEL 19-Jul-1969 M
E8527654 AUS P UNDERWOOD THOMAS 23-Aug-1984 F
***END
Figure 100: Example APP Transaction (Air) Batch Ver sion 1 (Microsoft Excel Format)
June 2015 Page 124 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
AIRLINE BATCH FORMAT – VERSION 2
No. Data Label Field Name Data Type and Maximum Length
Mandatory/Optional
Comments
1 ***VERSION 2 Optional If missing or left blank, ‘Version 1’ is assumed. The presence of ‘Version 2’ indicates that this is Version 2 batch file format.
2 *** HEADER Mandatory
3 *CANCEL Transaction Type
none Conditional The presence of this data label indicates a Cancellation sub-batch.
4 *TYPE Crew/ Passenger Type
Alpha (1) Mandatory The Crew/Passenger indicator for the sub-batch. Permissible values are:
• C = Operating crew
• X = Positioning crew
• P = Passenger.
5 *DIRECTION Direction Alpha (1) Mandatory The direction of the flight. Permissible values are:
• I = Inbound
• O = Outbound.
6 *FLIGHT Flight Number Alphanumeric (8) Mandatory Flight number.
7 *DEP PORT Departure Port Alpha (3) Mandatory Three-character IATA airport code.
8 *DEP DATE Departure Date Alphanumeric (11) Format DD-MON-YYYY
Mandatory Scheduled departure date from Departure Port. The date separator may also be "/","-" or "." or omitted completely. This applies to all date fields in this format in the batch. Can be today, 1 day prior to today or up to 29 days after today.
9 *DEP TIME Departure Time Numeric (4) Format HHMM
Mandatory Scheduled departure time from Departure Port. Value must be 0 if time is not known.
10 *ARR PORT Arrival Port Alpha (3) Mandatory Three-character IATA airport code for final port for flight.
11 *ARR DATE Arrival Date Alphanumeric (11) Format DD-MON-YYYY
Mandatory Scheduled arrival date at Arrival Port. Can be today, one day prior to today or up to 29 days after today.
12 *ARR TIME Arrival Time Numeric (4) Format HHMM
Mandatory Scheduled arrival time at Arrival Port. Value must be 0 if time not known.
June 2015 Page 125 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
No. Data Label Field Name Data Type and Maximum Length
Mandatory/Optional
Comments
13 *TB PORT Trans-border Port
Alpha (3) Conditional The first port in the UAE for an Inbound flight or the last port in the UAE for an Outbound flight. Only required if it is different from the Arrival Port for an Inbound flight or different from the Departure Port for an Outbound flight. Three-character IATA airport code.
14 *TB DATE Trans-border Date
Alphanumeric (11) Format DD-MON-YYYY
Conditional Scheduled arrival date at Trans-border Port for Inbound flight, or scheduled departure date from Trans-border Port for Outbound flight. Only required if Trans-border Port is provided.
15 *TB TIME Trans-border Time
Numeric (4) Format HHMM
Conditional Scheduled arrival time at Trans-border Port for Inbound flight, or scheduled departure time from Trans-border Port for Outbound flight. Only required if Trans-border Port is provided.
Figure 101: APP Transaction Batch (Air) Header Data
June 2015 Page 126 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
No. Field Name Data Type and Maximum Length
Mandatory/Optional Comments
1 Document Number
Alphanumeric (14)
Conditional Travel document number. A value is REQUIRED unless the UAE Government has given permission to board a person with no travel document.
2 Nationality Alpha (3) Mandatory Three-character ICAO nationality code.
3 Document Type
Alpha (1) Conditional Type of travel document. Permissible values are:
• P = Passport (default if data item is blank)
• O = Other
• N = None (only if there is no travel document).
4 Issuing State Alpha (3) Mandatory Issuing state in the travel document.
5 Family Name Alpha (24) Mandatory
6 Given Names Alpha (24) Mandatory
7 Date of Birth Alphanumeric (11)
Mandatory Format DD-MON-YYYY
The date separator may also be "/", “-“ or "." or omitted completely. This applies to all date fields in this format. For date of birth ONLY, the day OR the day and the month may be omitted if not included in the travel document. Examples: DEC-1975 or 1972.
8 Sex Alpha (1) Mandatory Permissible values are:
• M = Male
• F = Female
• X = Unspecified.
9 Country of Birth
Alpha (3) Optional Three-character ICAO country code of country of birth.
10 Document Expiry Date
Alphanumeric (11)
Optional Format DD-MON-YYYY
Document expiry date as shown in the travel document.
June 2015 Page 127 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
No. Field Name Data Type and Maximum Length
Mandatory/Optional Comments
11 Travel Type Alpha (1) Optional Permissible values are:
• N = Normal (Default)
• T = Transit
• X = Transfer. This field is present if the batch file format is ‘Version 2’.
12 Override Alpha (1) Conditional Override code indicating that an earlier directive denying permission to board is being overridden after consultation with the UAE Government or assessment of the situation against published information. Only applies to Check-in transactions. Permissible values are:
• A = Override based on a decision by the airline using published rules
• G = Override based on specific advice from the UAE Government.
13 Response Alphanumeric (May include a series of error messages)
Conditional When a processed batch is downloaded from the APP System, the result of the APP transaction is placed into this column. Possible responses are described in detail in the Airline/GG Interface Specification, Version 6.76. In summary, they are:
• ‘OK to Board’
• ‘Do Not Board’
• ‘Cancelled’
• ‘No Record’
• ‘Board if Documents OK’
• ‘Contact Government’
• ‘Insufficient data’
• ‘Override Accepted’
• or various validation error messages.
Figure 102: APP Transaction (Air) Data
June 2015 Page 128 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Example Version 2 Batch File Containing a Single Sub-batch
Document Number
Nationality Doc Type
Issuing State
Family Name
Given Names
Date of Birth Sex Country of Birth
Expiry Date Travel Type
Override Response
***VERSION 2
***HEADER
*TYPE P
*DIRECTION I
*FLIGHT SV1064
*DEP PORT LHR
*DEP DATE 20-OCT-2010
*DEP TIME 0800
*ARR PORT AUH
*ARR DATE 20-OCT-2010
*ARR TIME 0930
*TB PORT
*TB DATE
*TB TIME
***START
869987654 GBR P GBR BROWN ARTHUR JOHN
10-Jun-1960 M GBR 15-Jul-2012 T
123700502 USA P USA CLARK BILL TOM ADAM
15-Apr-1981 M USA 15-Aug-2012 X
859987635 GBO P GBR EDWARDS DAVID ROBERT
5-Apr-1954 M N
E7498072 AUS P AUS FOSTER EVAN 5-May-1956 M N
CA0277982 KOR O GBR SONG JENNY 16-Apr-1944 F N G
***END
Figure 103: Example APP Transaction (Air) Batch Ver sion 2 (Microsoft Excel Format)
This is the same data as in Figure 103, but in CSV format using Version 2 Batch file format. This file was created from the Microsoft
Excel spreadsheet used in example above. The conversion inserts trailing commas for trailing null fields. These commas are not
mandatory and files that are not generated by Microsoft Excel need not include them.
June 2015 Page 129 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Document Number,Nationality,Document Type,Issuing State,Family Name,Given Names,Date of Birth,Sex,Country of Birth,Expiry Date,Travel Type,Override,Response ***VERSION 2,,,,,,,,,,,, ***HEADER,,,,,,,,,,,, *TYPE,P,,,,,,,,,,, *DIRECTION,I,,,,,,,,,,, *FLIGHT,SV1064,,,,,,,,,,, *DEP PORT,LHR,,,,,,,,,,, *DEP DATE,20-Oct-2010,,,,,,,,,,, *DEP TIME,0800,,,,,,,,,,, *ARR PORT,AUH,,,,,,,,,,, *ARR DATE,20-Oct-2010,,,,,,,,,,, *ARR TIME,0930,,,,,,,,,,, *TB PORT,,,,,,,,,,,, *TB DATE,,,,,,,,,,,, *TB TIME,,,,,,,,,,,, ,,,,,,,,,,,, ***START,,,,,,,,,,,, 869987654,GBR,P,GBR,BROWN,ARTHUR JOHN,10-Jun-1960,M,GBR,15-Jul-2012,T,, 123700502,USA,P,USA,CLARK,BILL TOM,15-Apr-1981,M,USA,15-Aug-2012,X,, 859987635,GBO,P,GBR,EDWARDS,DAVID ROBERT,5-Apr-1954,M,,,N,, E7498072,AUS,P,AUS,FOSTER,EVAN,5-May-1956,M,,,N,, CA0277982,KOR,O,GBR,SONG,JENNY,16-Apr-1944,F,,,N,G, ***END,,,,,,,,,,,,
Figure 104: Example APP Transaction (Air) Batch Ver sion 2 (CSV format)
June 2015 Page 130 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Sea Carriers Batch Format – VERSION 2S (No transit or transfer movements only)
No. Data Label Field Name Data Type & Maximum Length
Mandatory/Optional
Comments
1 ***VERSION 2S Conditional. Version 2S can be used only for shipping services where all movements are either arrivals or departures. No transit or transfer movements can be specified.
2 *** HEADER Mandatory
3 *CANCEL Transaction Type
none Conditional The presence of this data label indicates a Cancellation sub-batch.
4 *TYPE Crew/ Passenger Type
Alpha (1) Mandatory The Crew/Passenger indicator for the sub-batch. Permissible values are:
• C = Operating crew
• X = Positioning crew
• P = Passenger.
5 *DIRECTION Direction Alpha (1) Mandatory The direction of the service. Permissible values are:
• I = Inbound
• O = Outbound.
6 *VESSEL IMO Number Alphanumeric (8)
Conditional. The IMO Number of the vessel.
7 *DEP PORT Departure Port Alpha (5) Conditional For shipping services:
• Five-character UN/LOCODE
• Mandatory for Outbound, Optional for Inbound.
8 *DEP DATE Departure Date Alphanumeric (11) Format DD-MON-YYYY
Conditional Scheduled departure date from Departure Port The date separator may also be "/", “-“ or "." or omitted completely. This applies to all date fields in this format in the batch. Can be today, one day prior to today or up to 29 days after today. Mandatory if Departure Port is provided.
June 2015 Page 131 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
No. Data Label Field Name Data Type & Maximum Length
Mandatory/Optional
Comments
9 *DEP TIME Departure Time Numeric (4) Format HHMM with leading zeros.
Conditional Scheduled departure time from Departure Port Mandatory if Departure Port is provided. Value must be 0 if time is not known.
10 *ARR PORT Arrival Port Alpha (5) Conditional For shipping services:
• Five-character UN/LOCODE
• Mandatory for Inbound, Optional for Outbound
11 *ARR DATE Arrival Date Alphanumeric (11) Format DD-MON-YYYY
Conditional Scheduled arrival date at Arrival Port The date separator may also be "/",”-“ or "." or omitted completely. This applies to all date fields in this format in the batch. Can be today, one day prior to today or up to 29 days after today. Mandatory if Arrival Port is provided.
12 *ARR TIME Arrival Time Numeric (4) Format HHMM with leading zeros.
Conditional Scheduled arrival time at Arrival Port Mandatory if Arrival Port is provided. Value must be 0 if time is not known.
13 *TB PORT Trans-border Port
Alpha (5) Conditional The port at which the service will cross the border of the UAE. For shipping services:
• Five-character UN/LOCODE The Trans-border port will only be required if it is different from the Arrival Port for an Inbound service or different from the Departure Port for an Outbound service
14 *TB DATE Trans-border Date
Alphanumeric (11) Format DD-MON-YYYY
Conditional Scheduled arrival date at Trans-border Port for Inbound service, or scheduled departure date from Trans-border Port for Outbound service Only required if Trans-border Port is provided
15 *TB TIME Trans-border Time
Numeric (4) Format HHMM with leading zeros.
Conditional Scheduled arrival time at Trans-border Port for Inbound service, or scheduled departure time from Trans-border Port for Outbound service Only required if Trans-border Port is provided
Figure 105: APP Transaction Batch (general aviation and Surface) Header Data
June 2015 Page 132 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
No. Field Name Data Type & Maximum Length
Mandatory/ Optional
Comments
1 Document Number
Alphanumeric (14)
Conditional Travel document number Required unless the UAE Government has given permission to board a person with no travel document.
2 Nationality Alpha (3) Mandatory Three-character ICAO nationality code.
3 Document Type
Alpha (1) Conditional Type of travel document. Permissible values are:
• P = Passport (default if data item is blank)
• O = Other
• N = None (only if there is no travel document).
4 Issuing State
Alpha (3) Conditional Mandatory if Document Type = ‘O’
5 Family Name
Alpha (24) Mandatory
6 Given Names
Alpha (24) Mandatory
7 Date of Birth Alphanumeric (11)
Optional Format DD-MON-YYYY
The date separator may also be "/" or "." or omitted completely. This applies to all date fields in this format For date of birth ONLY, the day OR the day and the month may be omitted if not included in the travel document. Examples: DEC-1975 or 1972.
8 Sex Alpha (1) Optional Permissible values are:
• M = Male
• F = Female
• X = Unspecified.
9 Country of Birth
Alpha (3) Optional Three-character ICAO country code of country of birth.
10 Document Expiry Date
Alphanumeric (11)
Optional Format DD-MON-YYYY
Document expiry date as shown in the travel document.
June 2015 Page 133 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
No. Field Name Data Type & Maximum Length
Mandatory/ Optional
Comments
11 Override Alpha (1) Conditional Override code indicating that an earlier directive denying permission to board is being overridden after consultation with the UAE Government or assessment of the situation against published information. Only applies to Check-in transactions. Permissible values are:
• A = Override based on a decision by the airline using published rules
• G = Override based on specific advice from the UAE Government.
12 Response Alphanumeric (May include a series of error messages)
Conditional When a processed batch is downloaded from the APP System, the result of the APP transaction is placed into this column. Possible responses from the AP are described in detail in the Airline/GG Interface Specification, Version 6.76. For general aviation, bus and shipping services, the text of the responses differ from the standard airline responses because there is no check-in process as used for scheduled air services. The possible responses are: ‘APP OK’ (equivalent to ‘OK to Board’) ‘APP Not OK’ (equivalent to ‘Do Not Board’) ‘Cancelled’ ‘No Record’ ‘APP OK If Docs OK’ (equivalent to ‘Board if Documents OK’) ‘Contact Government’ ‘Insufficient data’ ‘Override Accepted’ or various validation error messages.
Figure 106: APP Transaction (general aviation and S urface) Data
June 2015 Page 134 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Example Version 2S Batch File Containing a Single Sub-batch for an Inbound Shipping Service
Document Number
Nationality Doc Type
Issuing State
Family Name
Given Names
Date of Birth Sex Country of Birth
Expiry Date Override Response
***VERSION 2S
***HEADER
*TYPE P
*DIRECTION I
*VESSEL 5386634
*ARR PORT SAJED
*ARR DATE 20-OCT-2010
*ARR TIME 0930
***START
869987654 GBR P BROWN ARTHUR JOHN
10-Jun-1960 M GBR 15-Jul-2012
123700502 USA P CLARK BILLY ADAM 15-Apr-1981 M USA 15-Aug-2012
859987635 GBO P GBR EDWARDS DAVID ROBERT
5-Apr-1954 M
E7498072 AUS P FOSTER EVAN 5-May-1956 M
CA0277982 KOR O GBR SONG JENNY 16-Apr-1944 F G
***END
Figure 107: Example APP Transaction (ship) Batch Ve rsion 2S (Microsoft Excel Format)
June 2015 Page 135 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
General Aviation, Land and Sea Carriers Batch Format – VERSION 3S
No. Data Label Field Name Data Type & Maximum Length
Mandatory/Optional
Comments
1 ***VERSION 3S Conditional. Version 3S can be used for general aviation, bus services and shipping with transit/transfer movements.
2 *** HEADER Mandatory
3 *CANCEL Transaction Type
none Conditional The presence of this data label indicates a Cancellation sub-batch.
4 *TYPE Crew/ Passenger Type
Alpha (1) Mandatory The Crew/Passenger indicator for the sub-batch. Permissible values are:
• C = Operating crew
• X = Positioning crew
• P = Passenger.
5 *DIRECTION Direction Alpha (1) Mandatory The direction of the service. Permissible values are:
• I = Inbound
• O = Outbound.
6 *SERVICE Service Identifier
Alphanumeric(8)
Conditional For general aviation, the call sign of the aircraft. For shipping services, the IMO Number of the vessel. For bus services, the service number.
June 2015 Page 136 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
No. Data Label Field Name Data Type & Maximum Length
Mandatory/Optional
Comments
7 *DEP PORT Departure Port Alpha (5) Conditional For general aviation:
• Three-character IATA airport code
• Mandatory. For bus services:
• Five-character UN/LOCODE
• Mandatory. For shipping services:
• Five-character UN/LOCODE
• Mandatory for Outbound, Optional for Inbound.
8 *DEP DATE Departure Date Alphanumeric (11) Format DD-MON-YYYY
Conditional Scheduled departure date from Departure Port The date separator may also be "/", “-“ or "." or omitted completely. This applies to all date fields in this format in the batch. Can be today, one day prior to today or up to 29 days after today. Mandatory if Departure Port is provided.
9 *DEP TIME Departure Time Numeric (4) Format HHMM with leading zeros.
Conditional Scheduled departure time from Departure Port Mandatory if Departure Port is provided. Value must be 0 if time is not known.
10 *ARR PORT Arrival Port Alpha (5) Conditional For general aviation:
• Three-character IATA airport code
• Mandatory For bus services:
• Five-character UN/LOCODE
• Mandatory For shipping services:
• Five-character UN/LOCODE
• Mandatory for Inbound, Optional for Outbound
June 2015 Page 137 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
No. Data Label Field Name Data Type & Maximum Length
Mandatory/Optional
Comments
11 *ARR DATE Arrival Date Alphanumeric (11) Format DD-MON-YYYY
Conditional Scheduled arrival date at Arrival Port The date separator may also be "/",”-“ or "." or omitted completely. This applies to all date fields in this format in the batch. Can be today, one day prior to today or up to 29 days after today. Mandatory if Arrival Port is provided.
12 *ARR TIME Arrival Time Numeric (4) Format HHMM with leading zeros.
Conditional Scheduled arrival time at Arrival Port Mandatory if Arrival Port is provided. Value must be 0 if time is not known.
13 *TB PORT Trans-border Port
Alpha (5) Conditional The port at which the service will cross the border of the UAE. For general aviation:
• Three-character IATA airport code For bus services:
• Five-character UN/LOCODE For shipping services:
• Five-character UN/LOCODE Mandatory for bus services. For other services, the Trans-border port will only be required if it is different from the Arrival Port for an Inbound service or different from the Departure Port for an Outbound service
14 *TB DATE Trans-border Date
Alphanumeric (11) Format DD-MON-YYYY
Conditional Scheduled arrival date at Trans-border Port for Inbound service, or scheduled departure date from Trans-border Port for Outbound service Only required if Trans-border Port is provided
15 *TB TIME Trans-border Time
Numeric (4) Format HHMM with leading zeros.
Conditional Scheduled arrival time at Trans-border Port for Inbound service, or scheduled departure time from Trans-border Port for Outbound service Only required if Trans-border Port is provided
Figure 108: APP Transaction Batch (general aviation and Surface) Header Data
June 2015 Page 138 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
No. Field Name Data Type & Maximum Length
Mandatory/ Optional
Comments
1 Document Number
Alphanumeric (14)
Conditional Travel document number Required unless the UAE Government has given permission to board a person with no travel document.
2 Nationality Alpha (3) Mandatory Three-character ICAO nationality code.
3 Document Type
Alpha (1) Conditional Type of travel document. Permissible values are:
• P = Passport (default if data item is blank)
• O = Other
• N = None (only if there is no travel document).
4 Issuing State
Alpha (3) Conditional Mandatory if Document Type = ‘O’
5 Family Name
Alpha (24) Mandatory
6 Given Names
Alpha (24) Mandatory
7 Date of Birth Alphanumeric (11)
Optional Format DD-MON-YYYY
The date separator may also be "/" or "." or omitted completely. This applies to all date fields in this format For date of birth ONLY, the day OR the day and the month may be omitted if not included in the travel document. Examples: DEC-1975 or 1972.
8 Sex Alpha (1) Optional Permissible values are:
• M = Male
• F = Female
• X = Unspecified.
9 Country of Birth
Alpha (3) Optional Three-character ICAO country code of country of birth.
10 Document Expiry Date
Alphanumeric (11)
Optional Format DD-MON-YYYY
Document expiry date as shown in the travel document.
June 2015 Page 139 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
No. Field Name Data Type & Maximum Length
Mandatory/ Optional
Comments
11 Travel Type Alpha (1) Optional Permissible values are:
• N = Normal (Default)
• T = Transit
• X = Transfer.
12 Override Alpha (1) Conditional Override code indicating that an earlier directive denying permission to board is being overridden after consultation with the UAE Government or assessment of the situation against published information. Only applies to Check-in transactions. Permissible values are:
• A = Override based on a decision by the airline using published rules
• G = Override based on specific advice from the UAE Government.
13 Response Alphanumeric (May include a series of error messages)
Conditional When a processed batch is downloaded from the APP System, the result of the APP transaction is placed into this column. Possible responses from the AP are described in detail in the Airline/GG Interface Specification, Version 6.76. For general aviation, bus and shipping services, the text of the responses differ from the standard airline responses because there is no check-in process as used for scheduled air services. The possible responses are: ‘APP OK’ (equivalent to ‘OK to Board’) ‘APP Not OK’ (equivalent to ‘Do Not Board’) ‘Cancelled’ ‘No Record’ ‘APP OK If Docs OK’ (equivalent to ‘Board if Documents OK’) ‘Contact Government’ ‘Insufficient data’ ‘Override Accepted’ or various validation error messages.
Figure 109: APP Transaction (General aviation and S urface) Data
June 2015 Page 140 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Example Version 3S Batch File Containing a Single Sub-batch for an Outbound Bus Service
Document Number
Nationality Doc Type
Issuing State
Family Name
Given Names Date of Birth Sex Country of Birth
Expiry Date Travel Type
Override Response
***VERSION 3S
***HEADER
*TYPE P
*DIRECTION O
*SERVICE DB1230
*DEP PORT SADMM
*DEP DATE 20-OCT-2010
*DEP TIME 0700
*ARR PORT BHAHD
*ARR DATE 20-OCT-2010
*ARR TIME 0930
*TB PORT BHKFC
*TB DATE 20- OCT-2011
*TB TIME 0845
***START
869987654 GBR P BROWN ARTHUR JOHN 10-Jun-1960 M GBR 15-Jul-2012 N
123700502 USA P CLARK BILLY ADAM 15-Apr-1981 M USA 15-Aug-2012 N
859987635 GBO P GBR EDWARDS
DAVID ROBERT 5-Apr-1954 M N
E7498072 AUS P FOSTER EVAN 5-May-1956 M N
CA0277982 KOR O GBR SONG JENNY 16-Apr-1944 F N G
***END
Figure 110: Example APP Transaction (bus) Batch Ver sion 3S (Microsoft Excel Format)
June 2015 Page 141 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Appendix D – Error Messages
There will be three levels of data checking done during the process of submitting an APP transaction or cancellation through the
Carrier Portal.
All data input pages will have client-side validation built-in. This will be coded in JavaScript and will be executed on the user’s
browser before the page is submitted to the portal. If any validation check is failed, an error message will be displayed immediately
to the user and the page cannot be submitted. The possible error messages are listed further in this section.
When input data reaches the Carrier Portal Application Server it is validated again. This is done to guard against the possibility of:
• Data corruption during transmission
• A user attempting to submit data by some means which bypasses the client-side validation.
If this re-validation fails, an error screen will be displayed with the appropriate error message. In practice, this is never likely to occur,
due to the client-side validation.
The Application Server will send messages to the AP in the same format that the GG uses, and therefore may, in principle, receive
any of the errors that could be returned to the GG. In practice, due to the validation described above, most of the possible errors
from the AP cannot occur. The few remaining expected AP errors are listed below.
When a batch of APP transactions is submitted, there will be no possibility of performing client-side validation. However, each
transaction in the batch will be processed in the same way as individual transactions.
If a batch transaction fails the validation on the Application Server, it will not be submitted to the AP; instead, an error message will
be constructed for inclusion in the response batch. This error message may contain up to six separate elements, corresponding to six
validation failures.
June 2015 Page 142 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
If the transaction passes the Application Server validation and is submitted to the AP, the AP may return up to three error codes.
These error codes will be used to construct an error message for inclusion in the response batch.
These multiple error messages will also be displayed in the batch enquiry screen.
Figure 111 lists the error messages that can be displayed during the client-side validation.
Client-side APP Validation Error Messages
Crew type must be C or X
Passenger/Crew type must be P or C
Passenger/Crew type must be P, C or X
Flight Number cannot be blank
Flight Number contains invalid character
Departure port cannot be blank
Departure port contains invalid character
Departure Date is invalid
Arrival port cannot be blank
Arrival port contains invalid character
Arrival Date is invalid
Arrival Time is invalid
First port contains invalid character
Date at First port is invalid
Time at First port is invalid
Passport Number cannot be blank
Passport Number contains invalid character
Passport Number must be blank if document type is N
Nationality must be selected from the list
Date of Birth is incomplete
Month cannot be 'Unknown' if day is given
Date of Birth is invalid
June 2015 Page 143 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Client-side APP Validation Error Messages
Date of Birth later than today's date
Sex must be M, F or X
Country of Birth must be selected from the list
Passport Expiry Date is incomplete
Passport Expiry Date is invalid
Passport Expiry Date earlier than today's date
Passport Expiry Date too far in the future
Family Name cannot be blank
Family Name contains invalid character
Given Names cannot be blank
Given Names contain invalid character
Invalid Document Type
Figure 111: Client-side APP validation errors
June 2015 Page 144 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
The error messages produced by the Application Server validation will be generally shorter, since they are listed vertically on the
screen in the batch enquiry and in a response batch. Figure 112 lists the possible messages.
Application Server APP Validation Errors
Passport number must be supplied
Invalid nationality
Invalid date of birth
Invalid sex code
Invalid country of birth
Invalid passport expiry date
Family name must be supplied
Family name contains invalid character
Given names must be supplied
Given names contain invalid character
Passport number contains invalid character
Passport number too long
Invalid issuing state
Invalid document type
Invalid crew type
Flight number must be supplied
Invalid Passenger/Crew indicator
Departure port must be supplied
Arrival port must be supplied
Invalid arrival date
Invalid arrival time
Invalid first port
Invalid first port date
Invalid first port time
Figure 112: Application Server APP validation error s
June 2015 Page 145 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 113 lists the APP error codes that may be received from the AP and the messages that will be displayed to the user.
AP Error Code Error Message
6017 Expiry date outside allowable range
6020 Invalid country of birth
6033 Invalid passport number format
6046 Departure port required
6047 Invalid departure flight number
6048 Departure date invalid
6049 Departure time invalid
6050 First port not a valid port code
6051 Invalid first port flight number
6052 First port date invalid
6053 First port time invalid
6054 Arrival port not a valid port code
6055 Invalid arrival flight number
6056 Arrival date invalid
6057 Arrival time invalid
Six of the above codes are translated differently for Outbound movements:
OB6050 Last port not a valid port code
OB6052 Last port date invalid
OB6053 Last port time invalid
OB6054 Departure port not a valid port code
OB6056 Departure date invalid
OB6057 Departure time invalid
6062 Travel document type invalid
6078 Invalid override flag
6082 Inappropriate override code
6083 Document number given for document type N
June 2015 Page 146 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
AP Error Code Error Message
6084 Invalid country of birth
6092 Override not authorised
In the unlikely event of receiving an error code from the AP that is not in the above list, the Carrier Portal displays the generic message:
6SYS A system error occurred while your request was being processed by the APP System
In addition, if the Application Server experiences a problem connecting to the AP, or gets no response from the AP, one of the following messages will be displayed. These codes are modelled on the corresponding GG error codes.
5055 Cannot connect to the APP System
5057 No response from the APP System
Figure 113: APP Error Codes from the AP
June 2015 Page 147 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Appendix E – Support
Technical Support
For any technical errors from the Carrier Portal the following SITA support contacts should be used.
SITA Contact Centre
In The United Arab Emirates contact phone number is 800-0441-4089, then dial zero and enter the key 611.
For other contact numbers please refer to www.sita.aero/content/call-us-support, then dial zero and enter the key 611.
For any other country not listed above, please call +1 514 282 6128, then dial zero and enter the key 611.
Email: [email protected].
What to do?
In the below cases, airlines should board passengers without completing check-in:
• If problems with Carrier Portal system are causing a flight delay
• If the Carrier Portal outage lasts for more than 20 min during the check-in time.
In such circumstances above the passenger information should be checked-in at the earliest possible time when the Carrier Portal System issues
are resolved.
Login Support
For problems related to Usernames or Passwords please contact your Carrier Portal Administrator for your airline.
If you are a Carrier Portal Administrator and are experiencing problems with your Username or Password please contact API UAE Centre on the
following:
June 2015 Page 148 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Within UAE: 800-API-UAE (800-274-823).
Outside UAE: 00971 800-API-UAE (00971 800-274-823).
Registration Support
For any registration enquiries please contact API UAE Centre on the following:
Within UAE: 800-API-UAE (800-274-823).
Outside UAE: 00971 800-API-UAE (00971 800-274-823).
June 2015 Page 149 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Appendix F – CTA Batch File Formats
This appendix describes the batch file format for CTA Batch Files for Carrier Users.
The following table shows the batch files which may be submitted for Air CTA applications and the corresponding result file.
Air Batch Files Sea Batch Files
CTA Application Batch CTA Application Batch
Crew CTA/APP Transaction Batch
Figure 114: Air Batch Files
The batch data may be provided in either of the following formats:
• Microsoft Excel spreadsheet file. These files must have an extension of ‘xls’ or ‘xlsx’.
• Comma Separated Value (CSV) file. These files must have an extension of ‘csv’.
In this document the file formats are described in terms of the spreadsheet format.
There will be no restriction on batch file names, apart from the extension requirements defined above. The file name will not be
used to identify the batch. It will be identified by a reference provided by the user when the batch is submitted.
June 2015 Page 150 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Air Batch Files
CTA Application File - Excel Spreadsheet Format
The sequence of rows in the Microsoft Excel spreadsheet is as follows:
• Heading rows preceding the application data for individual crew members. These may be column headings or documentation inserted by the user who created the spreadsheet.
• A row containing “***START” in the first cell indicates that the following rows contain application data. This row will also contain “V3” in the second cell to indicate that the following data conforms to this specification rather than the earlier format.
• CTA application data formatted as a single row for each applicant, with the individual fields conforming to the rules in Figure 115.
• The end of data for individual applications is denoted by a line containing only “***END” in the first cell.
• Any further documentation rows inserted by the user following the “***END” are ignored by the web site processes.
Blank rows anywhere in the spreadsheet are ignored.
CTA Application Result File - Excel Spreadsheet For mat
The file structure is the same as for the CTA Application File (above), with the data fields described in Figure 117. The
response for each application is inserted into column 12.
CTA Application and Result Files - CSV Format
The CSV files for CTA applications and application results are in the format of the files created by Microsoft Excel from the
spreadsheets specified above.
June 2015 Page 151 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
ColNo.
Field Name Data Type and Maximum Length
Mandatory/Optional Comments
1 Document Number Alphanumeric (14) Mandatory Travel document number of the crew member.
2 Nationality Alpha (3) Mandatory ICAO three-character country code of the nationality of the crew member as shown in the travel document.
3 Family Name Alpha (24) Mandatory Family name of the crew member as shown in the travel document.
4 Given Names Alpha (24) Mandatory Given names of the crew member as shown in the travel document.
5 Date of Birth Alphanumeric (11) Mandatory Date of birth of the crew member as shown in the travel document. The recommended date formats are: 23Dec1985 or 23-Dec-1985 (separators may also be / or .) Dec1985 or Dec-1985 (separator may also be / or .) 1985 Note: The month may be upper case, lower case or mixed case. The two-digit year format is also permitted eg. 23-Dec-85.
6 Sex Alpha (1) Mandatory Sex of the crew member as shown in the travel document. Permissible values are:
• M = Male
• F = Female
7 Country of Birth Alpha (3) Optional ICAO three-character country code of country of birth of the crew member. This data is optional but should be provided if it is available.
8 Document Expiry Date
Alphanumeric (11) Conditional Document expiry date as shown in the travel document. Permissible date formats are as specified for Date of Birth, except that a full date must be supplied (item 5 above). This data is optional but should be provided if it is available.
June 2015 Page 152 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
ColNo.
Field Name Data Type and Maximum Length
Mandatory/Optional Comments
9 Issuing State Alpha (3) Mandatory ICAO three-character country code of the issuing state of the travel document. This information is often on the top of the passport title page and may be called Code, Code of Issuing State, Issuing Country, Country Code, Code of State or something similar. It is normally a three-character country code, but the code for Germany is “D”. On some passports, this information is not specifically stated. In these cases, the Nationality should be used for the Issuing State. Note: The Issuing State is not always the same as the Nationality of the passport holder. A common example where these two data elements differ is passports issued by the United Kingdom (GBR) to a person classified as British National Overseas (GBN). In this case, the Issuing State is GBR and the Nationality is GBN.
10 Document Issue Date Alphanumeric (11) Mandatory Travel document issue date as shown in the travel document. Permissible date formats are as specified for Date of Birth, except that a full date must be supplied (item 5 above).
11 Issuing Authority/ Place of Issue
Alphanumeric (60) Mandatory Issuing authority or place of issue of the travel document as shown in the travel document. The Issuing Authority/Place of Issue field is a free text field and will be located in the passport somewhere near the applicant's name. The field may be called Issuing Authority or Authority or Place of Issue or something similar. These details could be a series of numbers, a place, the name of a government department or a stamp and should be entered exactly as shown in the passport. For example, British High Commission, Wellington; 861;Sydney; Ministry of Foreign Affairs – Mumbai, etc.
12 Response Alphanumeric (May include a series of error messages)
Conditional Result of the CTA application. This field is used in the result file only. Possible values are: “Registered” if the CTA application was successful; and Error message(s).
Note: The fields highlighted in orange have been added to allow airlines to provide the additional data now required for all visa and CTA applications
Figure 115: CTA Application Data
June 2015 Page 153 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Air Batch Files - Examples
Examples of the following air batch file formats are included in this section:
• CTA Application Batch – Microsoft Excel Format
• CTA Application Batch Result – Microsoft Excel Format
• CTA Application Batch Resubmission – Microsoft Excel Format
• CTA Application Batch Resubmission Result– Microsoft Excel Format
• CTA Application Batch – CSV Format
June 2015 Page 154 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 116: CTA Application Batch (Microsoft Excel Format)
June 2015 Page 155 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 117: CTA Application Batch Result (Microsoft Excel Format)
June 2015 Page 156 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Figure 118: CTA Application Batch Resubmission (Mic rosoft Excel Format)
Figure 119: CTA Application Batch Resubmission Resu lt (Microsoft Excel Format)
June 2015 Page 157 of 157
Version: 3.7 © SITA 2015: Proprietary and Confidential
Note: This file was created from the Microsoft Excel spreadsheet of Example 117 above. The conversion inserts trailing commas
for null fields. These commas are not mandatory and files that are not generated by Microsoft Excel need not include them.
Figure 120: CTA Application Batch (CSV Format)