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 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 of 157


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 of 157


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 of 157


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 of 157


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 of 157


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 of 157


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 of 157


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 of 157


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 of 157


• 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 of 157


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 of 157


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 of 157


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 of 157


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 of 157


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 of 157


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 of 157


Menu - Administrator User

Figure 8– Administrator User Function Menu

Menu - Carrier User

Figure 9– Normal Carrier User Function Menu

June 2015 of 157


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:


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 of 157



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 of 157


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 of 157


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 of 157


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 of 157


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 of 157


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 of 157


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 of 157


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 of 157


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 of 157



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.


Departure Time The scheduled departure time for the flight.


Arrival Port The final port for the international flight.




Location Code.

Arrival Date The arrival date at the Arrival Port.


June 2015 of 157



Arrival Time The arrival time at the Arrival Port.


Trans-border Port The IATA airport code at which the service will cross the

border of the United Arab Emirates.


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.


Location Code.

Figure 20: Flight Details Fields

June 2015 of 157


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 of 157


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 of 157


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 of 157


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 of 157


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 of 157


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 of 157


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 of 157


Figure 30– APP Check-in Transaction –Passenger Deta ils

Figure 31– Travel Document Details screen

June 2015 of 157


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 of 157


4. Complete the fields as follows:


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.


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.


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.


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 of 157



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.


Only letters, hyphens, apostrophes and spaces are allowed.



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 of 157



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 of 157


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 of 157


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 of 157


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 of 157


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 of 157


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 of 157


Figure 38: Re Check-in

Figure 39: G Override

June 2015 of 157


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 of 157


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 of 157


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 of 157


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 of 157


Figure 44– Search Flight screen

2. Complete fields as follows:


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 of 157



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.


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.


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 of 157


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 of 157


Figure 47– Individual APP Cancellation Transaction – Passport Details


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.


Board Status The directive given to this traveler.

June 2015 of 157



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.


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 of 157


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 of 157


Figure 50– Check-in Transaction Response – ‘CANCELL ED’

You may attempt to cancel another transaction by clicking on the ‘Back’ button.

June 2015 of 157


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 of 157


Figure 52– Submit Batch Transactions screen

2. Complete the following fields:


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 of 157


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 of 157


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 of 157


Figure 57– APP Batch Enquiry screen



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 of 157


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 of 157


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 of 157


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:


No. Serial number of the transaction.

Doc Type Document Type submitted in the transaction.

June 2015 of 157



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 of 157


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 of 157


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 of 157


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:


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 of 157


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 of 157


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 of 157


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 of 157


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 of 157


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:


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 of 157



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 of 157


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 of 157


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 of 157


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 of 157


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 of 157


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


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 of 157


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 of 157


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 of 157


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



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 of 157










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.








be entered.






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 of 157



Passport Expiry

Date

The expiry date of the passport as indicated on the passport title page.

Mandatory.


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 of 157


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 of 157


• 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 of 157


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 of 157


Figure 86- Enquire on the status of a CTA applicati on screen



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 of 157





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.








be entered.






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 of 157


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 of 157


Figure 88– APP Batch Enquiry screen



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 of 157


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 of 157


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 of 157


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:


No. Serial number of the transaction.

June 2015 of 157



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 of 157


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 of 157


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 of 157


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 of 157


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 of 157


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 of 157


6. Highlight the Digital Certificate provided during registration.

7. Click the ‘Encrypt’ button at the bottom of the screen.

June 2015 of 157


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 of 157


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 of 157


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 of 157


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.


• 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’





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 of 157


Detailed examples of the specific structures of the various CTA batch formats are provided in

Appendix F – CTA Batch File Formats.

June 2015 of 157


API UAE Project

UAE General Civil Aviation Authority

Carrier Portal User Manual

Appendices

June 2015 of 157


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 of 157


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 of 157


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 of 157


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 of 157


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 of 157


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 of 157


Appendix C – APP Batch File Formats

This appendix describes the batch file format for APP Transactions for Carrier Users.


• Microsoft Excel spreadsheet file. These files must have an extension of ‘xls’ and ‘xlsx’






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 of 157


• 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 of 157


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 of 157



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 of 157


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 of 157




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 of 157


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 of 157


AIRLINE BATCH FORMAT – VERSION 2


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.








• 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.


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.


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 of 157



Mandatory/Optional

Comments


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.



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.


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 of 157




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.


3 Document Type



• O = Other


4 Issuing State Alpha (3) Mandatory Issuing state in the travel document.

5 Family Name Alpha (24) Mandatory

6 Given Names Alpha (24) Mandatory


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


9 Country of Birth



Alphanumeric (11)



June 2015 of 157




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’.





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 of 157


Example Version 2 Batch File Containing a Single Sub-batch

Document Number


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 TIME 0800

*ARR PORT AUH


*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 of 157


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 of 157


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.








• 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.


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 of 157



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:


• Mandatory for Inbound, Optional for Outbound


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.


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



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


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 of 157


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.


3 Document Type



• O = Other


4 Issuing State

Alpha (3) Conditional Mandatory if Document Type = ‘O’

5 Family Name

Alpha (24) Mandatory

6 Given Names




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


9 Country of Birth



Alphanumeric (11)



June 2015 of 157



Mandatory/ Optional

Comments





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 of 157


Example Version 2S Batch File Containing a Single Sub-batch for an Inbound Shipping Service

Document Number


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 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 of 157


General Aviation, Land and Sea Carriers Batch Format – VERSION 3S


Mandatory/Optional

Comments

1 ***VERSION 3S Conditional. Version 3S can be used for general aviation, bus services and shipping with transit/transfer movements.








• 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 of 157



Mandatory/Optional

Comments

7 *DEP PORT Departure Port Alpha (5) Conditional For general aviation:

• Three-character IATA airport code

• Mandatory. For bus services:


• Mandatory. For shipping services:


• Mandatory for Outbound, Optional for Inbound.


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:


• Mandatory For shipping services:


• Mandatory for Inbound, Optional for Outbound

June 2015 of 157



Mandatory/Optional

Comments


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.


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



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


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 of 157



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.


3 Document Type



• O = Other


4 Issuing State

Alpha (3) Conditional Mandatory if Document Type = ‘O’

5 Family Name


6 Given Names




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


9 Country of Birth



Alphanumeric (11)



June 2015 of 157



Mandatory/ Optional

Comments

11 Travel Type Alpha (1) Optional Permissible values are:

• N = Normal (Default)

• T = Transit

• X = Transfer.





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 of 157


Example Version 3S Batch File Containing a Single Sub-batch for an Outbound Bus Service

Document Number


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 TIME 0700

*ARR PORT BHAHD


*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 of 157


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 of 157


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 of 157


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 of 157


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 of 157


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 of 157


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 of 157


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 of 157


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 of 157


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


• Microsoft Excel spreadsheet file. These files must have an extension of ‘xls’ or ‘xlsx’.



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 of 157


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 of 157


ColNo.

Field Name Data Type and Maximum Length


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.


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 of 157


ColNo.

Field Name Data Type and Maximum Length


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.


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 of 157


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 of 157


Figure 116: CTA Application Batch (Microsoft Excel Format)

June 2015 of 157


Figure 117: CTA Application Batch Result (Microsoft Excel Format)

June 2015 of 157


Figure 118: CTA Application Batch Resubmission (Mic rosoft Excel Format)

Figure 119: CTA Application Batch Resubmission Resu lt (Microsoft Excel Format)

June 2015 of 157


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)