PASSENGER AND AIRPORT DATA

INTERCHANGE STANDARDS

EDIFACT IMPLEMENTATION GUIDE

PNR DATA PUSHED TO STATES
OR OTHER AUTHORITIES
PNRGOV MESSAGE

Version 17.1 DRAFT

(subject to approval and publication by the WCO API Contact Committee)
 NOTICE

DISCLAIMER. The information contained in this

publication is subject to constant review in the light of
changing government requirements and regulations. No
subscriber or other reader should act on the basis of any
such information without referring to applicable laws
and regulations and/or without taking appropriate
professional advice. Although every effort has been
made to ensure accuracy, the International Air Transport
Association shall not be held responsible for loss or
damage caused by errors, omissions, misprints or
misinterpretation of the contents hereof. Furthermore,
the International Air Transport Association expressly
disclaims all and any liability to any person, whether a
purchaser of this publication or not, in respect of
anything done or omitted, and the consequences of
anything done or omitted, by any such person in reliance
on the contents of this publication.

No part of the Passenger and Airport Data Interchange

Standards EDIFACT Implementation Guide – for
PNRGOV Message Document may be reproduced,
recast, reformatted or transmitted in any form by any
means, electronic or mechanical, including
photocopying, recording or any information storage and
retrieval system, without the prior written permission
from:

Managing Director,
IATA Distribution and Financial Services
International Air Transport Association
800 Place Victoria
P.O. Box 113
Montreal, Quebec
Canada, H4Z 1M1

Passenger and Airport Data Interchange Standards EDIFACT Implementation Guide – PNRGOV
PADIS EDIFACT Implementation Guide – PNRGOV (version 17.1)
© 2017 International Air Transport Association. All rights reserved.
Montreal — Geneva
 PADIS EDIFACT Implementation Guide – Table for Contents

1. INTRODUCTION ................................................................................................................................................... 1
1.1. PNRGOV MESSAGE VERSION RELEASE ...................................................................................................... 1
1.1.1 WHAT MESSAGE VERSION IS SUPPORTED BY WHICH IMPLEMENTATION GUIDE 1
1.1.2 ERRATA 1
1.2. DOCUMENT STRUCTURE ............................................................................................................................... 2
1.3. HOW TO USE THIS DOCUMENT ..................................................................................................................... 2
1.4. GUIDELINES AND RULES................................................................................................................................ 3
1.5. CODE SETS ......................................................................................................................................................... 4
1.6. REFERENCES ..................................................................................................................................................... 4
2 MESSAGE RELATIONSHIP ................................................................................................................................ 6
2.1 PNRGOV ............................................................................................................................................................. 6
2.2 GOVREQ ............................................................................................................................................................. 7
3 MESSAGE STRUCTURE ...................................................................................................................................... 8
3.1 MESSAGE SEGMENT DESCRIPTIONS (PNRGOV) ................................................................................................... 9
3.2 PUSH OF PNR DATA TO STATE - (PNRGOV) .................................................................................................... 11
3.3 ACKRES – ACKNOWLEDGEMENT RESPONSE ..................................................................................................... 13
3.4 PNRGOV ADHOC REQUEST (GOVREQ) ......................................................................................................... 14
3.5 EMERGENCY LOCK (PNRGOV) .......................................................................................................................... 14
4 UNITED NATIONS SERVICE SEGMENTS..................................................................................................... 15
4.1 UNA: SERVICE STRING ADVICE .................................................................................................................. 15
4.2 UNB: INTERCHANGE HEADER .................................................................................................................... 17
4.3 UNE: FUNCTIONAL GROUP TRAILER ......................................................................................................... 19
4.4 UNG: FUNCTIONAL GROUP HEADER ........................................................................................................ 20
4.5 UNH: MESSAGE HEADER .............................................................................................................................. 22
4.6 UNT: MESSAGE TRAILER .............................................................................................................................. 24
4.7 UNZ: INTERCHANGE TRAILER .................................................................................................................... 24
5 PADIS RESERVATIONS SUB-GROUP APPROVED SEGMENTS .............................................................. 25
5.1 ABI: ADDITIONAL BUSINESS SOURCE INFORMATION (PNRGOV) ..................................................... 25
5.2 ADD: ADDRESS INFORMATION (PNRGOV)....................................................................................................... 26
5.3 APD: ADDITIONAL PRODUCT DETAILS (PNRGOV) ................................................................................ 28
5.4 DAT: DATE AND TIME INFORMATION (PNRGOV) .................................................................................. 29
5.5 EBD: EXCESS BAGGAGE DETAILS (PNRGOV) .......................................................................................... 30
5.6 EQN: NUMBER OF UNITS ............................................................................................................................. 31
5.7 ERC: APPLICATION ERROR INFORMATION ............................................................................................. 32
5.8 FAR: FARE INFORMATION (PNRGOV) ....................................................................................................... 33
5.9 FOP: FORM OF PAYMENT (PNRGOV) ......................................................................................................... 34
5.10 FTI: FREQUENT TRAVELLER INFORMATION (PNRGOV) ....................................................................... 35
5.11 IFT: INTERACTIVE FREE TEXT (PNRGOV) ............................................................................................... 36
5.12 LTS: LONG TEXT STRING (PNRGOV) ......................................................................................................... 37
5.13 MON: MONETARY INFORMATION (PNRGOV) ......................................................................................... 38
5.14 MSG: MESSAGE ACTION DETAILS (PNRGOV), (ACKRES) ..................................................................... 39
5.15 ORG: ORIGINATOR OF REQUEST DETAILS (PNRGOV) .......................................................................... 40
5.15.1 ORG: Push PNR Data to States - PNRGOV 40
5.15.1 ORG: PNRGOV Adhoc Request - GOVREQ 42
5.16 PTK: PRICING/TICKETING DETAILS (PNRGOV) ...................................................................................... 43
5.17 RCI: RESERVATION CONTROL INFORMATION (PNRGOV) ................................................................... 45
5.18 REF: REFERENCE INFORMATION (PNRGOV) ........................................................................................... 46
5.19 RPI: RELATED PRODUCT INFORMATION (PNRGOV) ............................................................................. 46
5.20 SAC: SOURCE AND ACTION INFORMATION (PNRGOV) ........................................................................ 47
5.21 SRC: SEGMENT REPETITION CONTROL (PNRGOV) ................................................................................ 48
5.22 SSD: SEAT SELECTION DETAILS (PNRGOV) ............................................................................................. 49
5.23 SSR: SPECIAL REQUIREMENTS DETAILS (PNRGOV) ............................................................................. 50
5.24 TBD: TRAVELER BAGGAGE DETAILS/ELECTRONIC TICKETING (PNRGOV) ............................................. 52
5.25 TIF: TRAVELLER INFORMATION (PNRGOV) ............................................................................................ 54
5.26 TKT: TICKET NUMBER DETAILS (PNRGOV) ............................................................................................ 55
5.27 TRA: TRANSPORT IDENTIFIER............................................................................................................................. 56
 PADIS EDIFACT Implementation Guide – Table for Contents

5.28 TRI: TRAVELLER REFERENCE INFORMATION (PNRGOV) .................................................................... 57

5.29 TVL: TRAVEL PRODUCT INFORMATION (PNRGOV) .............................................................................. 58
5.29.1 Flight Details for Passenger data sent 58
5.29.2 Flight Itinerary 60
5.29.3 Codeshare information 62
5.29.4 Non Air Segments 63
5.30 TXD: TAX DETAILS (PNRGOV) .................................................................................................................... 65
6 CODE SETS ........................................................................................................................................................... 66

7 ADDITIONAL IMPLEMENTATION GUIDELINES ...................................................................................... 68

7.1 TYPES OF PUSH AND PNR CANCELLATIONS ........................................................................................................ 68
7.1.1 Full PNR Push (PNRGOV) 68
7.1.2 Update PNR Push (PNRGOV) 68
7.1.3 Adhoc PNR Push (GOVREQ/PNRGOV) 68
7.2 ERROR HANDLING ............................................................................................................................................... 69
7.3 ACCOMMODATION OF PNR DATA EXCEEDING MAXIMUM OCCURRENCES IN PUBLISHED STANDARDS ............... 69
7.4 HANDLING OF SSR DATA .................................................................................................................................... 70
7.4.1 Standardized SSR Construction 70
7.4.2 Placement of SSR Data in Structured Messaging Formats 70
7.4.3 SSR Handling Best Practices 71
APPENDIX A – CONTRL MESSAGES....................................................................................................................... 75

APPENDIX B – BUSINESS EXAMPLES .................................................................................................................... 77

1 SCENARIOS – TWO PASSENGERS TRAVELING INTERNATIONALLY: ............................................... 77

2 EXAMPLE OF PNRS WITH INFANT, RESERVATION AND CHECK-IN DATA AND UNFORMATTED
HISTORY ........................................................................................................................................................................ 79

3 EXAMPLE OF CODESHARE PNRS WITH RESERVATION AND CHECK-IN DATA AND

UNFORMATTED HISTORY........................................................................................................................................ 81

4 SIMPLE PNR BOOKED IN ANOTHER SYSTEM (NO PNR HISTORY) .................................................... 82

5 EXAMPLE WITH THREE PNRS CONTAINING TICKET INFORMATION ............................................. 83

6 EXAMPLE WITH ONE ADULT AND AN INFANT ........................................................................................ 86

ASSUMPTIONS: .............................................................................................................................................................. 86
7 PNR WITH FREQUENT TRAVELER (2 ADULTS) AND PNR SPLIT ......................................................... 87
ASSUMPTIONS: .............................................................................................................................................................. 87
8 COORDINATION OF MSG AND EQN TO DENOTE TYPE AND SCOPE OF MESSAGE ..................... 88

APPENDIX C – PADIS EDIFACT MESSAGE PROCESSING - BACKGROUND FOR PNRGOV USERS ....... 90

1 INTRODUCTION ................................................................................................................................................. 90
1.1 PURPOSE.............................................................................................................................................................. 90
1.2 SCOPE.................................................................................................................................................................. 90
1.3 BACKGROUND ..................................................................................................................................................... 90
1.4 REFERENCES ....................................................................................................................................................... 90
1.5 ASSUMPTIONS AND CONSTRAINTS ....................................................................................................................... 90
1.5.1 Assumptions 90
1.5.2 Constraints 90
1.6 DOCUMENT OVERVIEW ....................................................................................................................................... 91
2 EDIFACT ENVELOPE STRUCTURE ............................................................................................................... 92
 PADIS EDIFACT Implementation Guide – Table for Contents

2.1 THE INTERCHANGE ENVELOPE ............................................................................................................................ 92

2.2 THE FUNCTIONAL GROUP ENVELOPE .................................................................................................................. 92
2.3 THE MESSAGE ENVELOPE ................................................................................................................................... 92
3 PARSING & PROCESSING STEPS ................................................................................................................... 94

4 ACKNOWLEDGEMENT RECOMMENDATIONS......................................................................................... 96
4.1 TYPES OF ACKNOWLEDGEMENTS ........................................................................................................................ 96
4.1.1 Acknowledgement of Receipt 96
4.1.2 Acknowledgement of Processing 96
4.2 RECOMMENDATIONS ........................................................................................................................................... 96
4.3 EXAMPLES......................................................................................................................................................... 100
5 REPETITION MAXIMUMS AND SEPARATORS ........................................................................................ 101
 PADIS EDIFACT Implementation Guide – PNRGOV Message

1. INTRODUCTION

The purpose of this document is to describe the recommended usage of the Passenger and Airport Data Interchange
Standards PNRGOV EDIFACT Message Standards. These messages are intended to facilitate the exchange of data
relevant to government requirements on PNR data and Airlines reservation systems.

This document was developed, and will be maintained, by the IATA/A4A PNRGOV Working Group in coordination
with the Passenger and Airport Data Interchange Standards Reservations Working Group.
This will be a living document and will be updated as necessary. If there are any changes to the message structure, the
change process defined in the PNRGOV Principles Document should be followed.

1.1. PNRGOV MESSAGE VERSION RELEASE

Version control will be handled in the following manner:

 Message structure change requires a new version of the message and new version of the Implementation Guide.
 Changes in the text of the Implementation Guide other than message structure changes may also trigger new
release of the Implementation Guide.
 Minor changes can be kept in the Errata document attached to a specific release of the Implementation Guide
and eventually incorporated into the next new release and new version of the same.
 Any text pending formal approval by the WCO API Contact Committee and/or the PADIS Board will be shaded
in grey.

1.1.1 WHAT MESSAGE VERSION IS SUPPORTED BY WHICH IMPLEMENTATION GUIDE

This table lists all current PNRGOV EDIFACT messages and shows in which PNRGOV Implementation Guide
document release a message was modified from its previous publication. A bold version release shows the first
publication of that message or guide.

Implementation Guide 10.1 11.1 12.1 13.1 14.1 15.1 16.1 17.1
PNRGOV 10.1 11.1 12.1 13.1 13.1 15.1 15.1 17.1
ACKRES 10.1 11.1 12.1 12.1 12.1 12.1 12.1 12.1
GOVREQ 12.1 12.1 12.1 12.1 12.1 12.1

1.1.2 ERRATA

An ERRATA sheet will be maintained for each release and will be stored on the IATA website along with the
corresponding Implementation Guide.

 Each entry in the Errata sheet will include a sequence number, date included in ERRATA, Implementation Guide
paragraph reference, current text and/or problems description for charts, required change in text and/or change
description for charts, reason for change, and who submitted the ERRATA item. .
 Once an entry is made in Errata sheet, the PNRGOV group will receive a notification.
 The Errata sheet is intended only for minor corrections. Issues which require debate by the group must be
submitted, together with a proposed solution, as formal agenda items to a PNRGOV Working Group meeting.
 Once changes are approved by the PNRGOV group, the group will notify WCO of changes made to the
PNRGOV implementation guide.

1
 PADIS EDIFACT Implementation Guide – PNRGOV Message

1.2. DOCUMENT STRUCTURE

This document contains the following eight sections:

Introduction
Contains an overview and guidelines for use of the document.

Message Relationships
Describes the relationships between query messages and the expected response message for the different business
functions listed. The function of a message can be modified, in some cases, by the use of data element 1225 in a MSG
segment. This will be indicated as such in the message relationship section.

Message Structure
Shows in diagrammatic format each approved PADIS PNRGOV message. The diagrams show the construction of the
message and the data segments used. The hierarchy of the segments is indicated by means of data levels.

Service Segments
Refer to the Architecture for IATA Interactive EDIFACT, and the ISO 9735 for United Nations Service Segments
standards. For use in the PADIS Reservations environment, the service segments including the UNH have been described
in greater detail in Section 4.

Data Segments
Lists in alphabetical order all data segments that are part of the messages contained in this document. For each segment
there will be a list of the composites and data elements used to construct the segment and an indication of how these
elements are commonly used. To cater for different business requirements, there may be multiple definitions of the same
data segment.
Examples
For every business function listed there will be at least one example of the data to be transmitted. No response is
anticipated except for an acknowledgement that the message has been received.

States’ Legal Requirements

Each States legal requirements will be listed separately including a mapping to the PNRGOV Message structure where
the information is held. This information will be mapped out to segment and element level. The same information may be
found in different places, depending on the structure and contents and how this is stored in different reservation systems.

The IATA PNRGOV Principles Document contains a recap of the governments requirements. Additionally, IATA
maintains a copy of the legislation on their API-PNR World Tracker extranet site. Use the following link to access this
information:

Link for already registered users:

https://extranet2.iata.org/sites/facilitation/Lists/API%20World%20Tracker/By%20Country.aspx

Link to register for access to the FAL extranet site containing the API-PNR World Tracker:
http://www2.iata.org/registration/getemailpage.aspx?siteurl=facilitation

Appendices
As necessary, appendices will be added to the Implementation Guide.

Appendix A – contains details concerning the UN CONTROL message (Syntax and Service Report).
Appendix B – contains detailed business examples from a number of airlines.
Appendix C – contains PADIS EDIFACT Message Processing - Background for PNRGOV Users

1.3. HOW TO USE THIS DOCUMENT

The PNRGOV, ACKRES and GOVREQ messages are currently the only EDIFACT Message documented in this
Implementation guide.

The guide contains complete description of the Message Structure, segments and elements with notes and examples.

2
 PADIS EDIFACT Implementation Guide – PNRGOV Message

1.4. GUIDELINES AND RULES

For all implementation guide additions and updates to Section 5 (Segments), the following rules apply to the format and
contents, including definitions of special notations:

1. Data segments appear for each business function in Section 5.0.

2. If the information is the same for multiple business functions, the data segment will not be repeated.

3. The status of a data element, composite data element, simple data element or component data element, is
indicated in the “Status” column. If an element is marked “C” (conditional), it becomes mandatory under certain
circumstances which have to be specified. It may be omitted if these circumstances do not prevail. If an Element
is marked “M” (mandatory), it is containing information which forms a fundamental part of the procedure and
must always be included.

4. If an 'N/A' appears in the ”Status”' column, it indicates that the composite element or data element is conditional
in the PADIS Message Standards, but for this function no applicable use has been identified. In such cases, all
columns of the chart are completed, except “Common Usage”, “Code Set” and “Comments”. “Common Usage”
and “Code Set” columns are marked “--” and the “Comments” column is left blank. If a composite is conditional
and all component data elements are N/A, the composite is shown as N/A. If the composite is N/A, then all the
component data elements will be shown as N/A.

5. If a composite or data element is defined as conditional in the IATA approved message but must be mandatory
to complete a business function, the composite or data element will be indicated with a M for mandatory along
with an asterisk (*). The M* will indicate the status differs from the PADIS Message Standard.

6. All elements marked as “C” (conditional) or as “M” or “M*” (mandatory) will have all columns of the charts
completed as appropriate. When an element has multiple occurrences and is marked as M or M*, the first
occurrence is considered mandatory and subsequent occurrences are considered conditional.

7. Where a State’s requirements differ for “Conditional” fields from the standard implementation guide, a separate
supplemental document will be provided by the State(s) detailing which “Conditional” fields are “Mandatory”
for that State. Provisions in paragraphs 1.5.1 and 1.5.2 of the “Principles, Functional and Business
Requirements PNRGOV” shall be respected. These differing requirements will not change the structure of the
message.

8. Where a State’s requirements differ from the standard implementation guide, a separate supplemental document
will be provided by the State(s). This will not change the structure of the message.

9. If an element is a coded value, “Yes” is indicated in the “Code Set” column. If it is not a coded value, the
column is marked “--”.

10. In general, dates and times are expressed in local time except where specifically noted; such as, the UNB where
the time will be expressed in Greenwich Mean Time (GMT) or Universal Time Coordinated (UTC). Where
GMT is specified in the examples, UTC equally applies. However, due to different systems criteria, the subject
of date/times in various fields from various sources (e.g., centralized reservations and DCS for local vs.
centralized system) should be addressed in the bilateral discussions between governments/airlines/system
providers. .

11. The ”Field Type” refers to the field length as defined within the message and should match the value indicated in
the most current PADIS Message Standards document.

12. “Common Usage” refers to the length and characteristics typically used to define that data element. This
information is used to show how a data element should be used for this segment within the travel industry.
Because existing data elements were used to create certain elements, the ”Field Type” characteristics may
exceed the actual requirements of the data element. “Common Usage” exists to better define the characteristics
of the data element.

13. The “Comments” column will use consistent wording for the same elements across the segments if they are used
in the same way.

3
 PADIS EDIFACT Implementation Guide – PNRGOV Message

14. Each segment is followed by “Notes” (if applicable) and by segment examples. However, “Notes” are only
included if they are necessary to explain the usage.

15. Each segment and message will have enough examples to show the standard usage as defined by the PADIS
group.

16. For numeric fields, see reference Part 1 ISO 9735 Syntax Rules, Section 10.

17. The full stop ( period .) or the comma (,) is allowed to represent the decimal mark. Either is acceptable within
the interchange but both cannot be used in the same interchange.

18. The length of a numeric data element value shall not include the minus sign (-), the decimal mark (.),
or the exponent mark (E or e).

19. When a decimal mark is used, there shall be at least one digit after the decimal mark.

20. When a segment appears at more than one level, it is reflected only once, with composites and data elements
conditional as applicable.

21. The first segment in a group is mandatory and is the segment that triggers the group. Some trigger segments may
be exchanged without data. In such cases these are noted with a pound (#) sign in the message diagram segment
list in Section 3.2

22. For the purpose of the PNRGOV documentation all Airlines are referred to as Carriers and all governments are
referred to as States.

23. Standalone data element names and composites having uppercase names are separated by the plus sign (+).
Component data elements within a composite are in lower case and are separated by a colon (:).

24. Repetition separator is not used in PNRGOV messages and therefore the default * separator does not need to be
released.

25. Depending on systems in place, in email addresses, airlines should use

“// “(double slash) in place of “@ (at sign),
“..” (double dot) in place of “_” (underscore) and
“ ./” (dot slash) in place of “-” as specified in AIRIMP.

1.5. CODE SETS

Codes used in codesets are used to define the values for the relevant business item. All codesets utilized in the PNRGOV
message are defined in the PASSENGER AND AIRPORT DATA INTERCHANGE STANDARDS - Codeset
Directory.

If additional codes are required, requests should be submitted to the PADIS Reservation Sub-group for approval prior to
them being submitted in the PADIS Board vote for inclusion in the standards.

1.6. REFERENCES

The following documents may be used as additional references to the PNRGOV Iimplementation Guide:

 IATA PNRGOV Principles Document

 IATA PASSENGER AND AIRPORT DATA INTERCHANGE STANDARDS - MESSAGE STANDARDS
DOCUMENT
 IATA PADIS EDIFACT and XML Codeset
 IATA Reservations Interline Message Procedures – Passenger (AIRIMP)
4
 PADIS EDIFACT Implementation Guide – PNRGOV Message

 IATA Passenger Services Conference Resolutions Manual (PSCRM)

 IATA Airline Coding Directory
 ISO 9735 – Version 4
 IATA SYSTEMS AND COMMUNICATIONS REFERENCE, VOLUME 6 – INTERACTIVE EDIFACT
ARCHITECTURE

Definitions of common terms used within the airline industry can be found on the IATA website by accessing the IATA
website as follows:

1. Go to the home page www.iata.org

2. Do a search on the word “glossary”
3. Download the spreadsheet entitled “passenger-glossary-of-terms.xls”

5
 PADIS EDIFACT Implementation Guide – PNRGOV Message

2 MESSAGE RELATIONSHIP
This Section describes the possible query and response relationship of the messages developed for PNRGOV function.
The following convention is used to represent the possible relationships between messages; a solid line ( ______ )
indicates the primary relationship; and a broken line (-------) indicates an optional relationship.

The message diagram depicts the message relationship by showing the query origin in the top box and the response origin
in the bottom box.

A CONTRL message (See Appendix A) is used:

(a) to respond to any message, indicating that a non-application error was encountered
(usage not illustrated in message relationship diagrams)
(b) to acknowledge receipt of specific messages for which no paired response
exists (as illustrated in the message relationship diagrams)

2.1 PNRGOV
The following messages are used by airlines, airline service suppliers and States to exchange PNR related data
information.

PNRGOV
(Carrier)

ACKRES
(States)

Note: Data element 1225 of composite C302 in segment MSG defines the business function of the message.

Message Functions:

PNRGOV (Element 1225 = 22) Push PNR data to States

PNRGOV (Element 1225 = 141) Update (used for update push)
ACKRES (Element 1225 = 23) Acknowledgement from States receipt of push PNR data

The ACKRES message is only sent where there is a Bilateral Agreement between Carrier and State to do so.

6
 PADIS EDIFACT Implementation Guide – PNRGOV Message

2.2 GOVREQ
The following messages are used by States to make an Adhoc request for a PNRGOV. The request may be for a specific
airline/flight number/date or for a specific record locator. Implementation of this message requires a bilateral agreement
between the government and the carrier. This message is to be used only in exceptional situations.

GOVREQ
(States)

PNRGOV ACKRES Nothing

(Carrier) (Carrier) (Carrier)

Notes: Date element 1225 of composite C302 in segment MSG defines the business function of the message.

Message Functions:

GOVREQ (Element 1225 = 43) Flight report

GOVREQ (Element 1225 = 77) Record locator request

The Bilateral Agreement defines the conditions under which the messages are exchanged. One of three results may
occur:
 The carrier may respond with the PNRGOV message.
 The carrier may respond with the ACKRES message indicating one of two conditions: 1. The message is
acknowledged and PNRs will be sent, or 2. errors are detected in the request, the ACKRES contains error codes
to describe the error.
 The carrier may not respond and process according to carrier defined procedures.

7
 PADIS EDIFACT Implementation Guide – PNRGOV Message

3 MESSAGE STRUCTURE

This document describes the message structure for the IATA approved PADIS PNRGOVand other related EDIFACT messages
to support the PNRGOVprocess.

In reference to the message diagrams, segments at Level 0 are not repeated and apply to the entire message. The first segment
in a group is mandatory and is called the trigger segment. Segments at levels below the trigger segment apply to the group and
not the entire message.

The order of segments within a group are read top to bottom, left to right.

8
 PADIS EDIFACT Implementation Guide – PNRGOV Message

3.1 Message Segment Descriptions (PNRGOV)

The following information is intended to provide a high level understanding as to what data is contained in the individual
segment at the various Groups and Levels in the PNRGOV message. More details are provided in the individual segment
sections.

UNA -Service String Advice

UNB - Interchange Header Segment
UNG - Functional Group Header
UNH - message header information
MSG - specifies the function of the message
ORG - specifies the sender of the message
TVL - the flight (departure date/time, origin, destination, operating airline code, flight
number, and operation suffix) for which passenger data is being sent.
EQN - the total number of PNRs being sent for the flight push

GR.1 - repeats for each passenger record sent

SRC - contains no data
RCI - the record locator(s) for this passenger record
SSR - special service data that applies to all passengers/ flights
DAT - date of most recent ticket issuance and last PNR transaction date/time
IFT - other service information (OSI) for all passengers/flights
ORG - origination of the booking
ADD - contact information
EBD - excess baggage information for all passengers

GR.2 - repeats for each passenger in the passenger

TIF - a passenger name; indication of type - only use for group; a given name,
PTC code, possible traveler reference to SSRs, FF’s and other info, and a traveling
with infant indicator.
FTI - frequent traveler numbers for the passenger in the TIF
IFT - other service information (OSI) for this passenger and/or email address
REF - unique passenger reference id
EBD - excess baggage information for this passenger(s)
FAR - fare info - PTC code, age, discounted fare type, percent of discount or country code,
in-house fare type/corporate contract number, and fare basis code
SSR - special service data that applies to the passenger for all flights
ADD - emergency contact information and/or UMNR delivery and collection addresses

GR.3 - repeats for each ticket associated to this passenger

TKT - ticket number, total number of booklets issued, in connection doc info
MON - ticket amount
PTK - pricing information for this ticket
TXD - tax amounts for this ticket
DAT - Date of ticket issuance for each ticket

GR.4 - form of payment information

FOP - type of form of payment, credit card info, and other form of payment
information associated with a ticket.
IFT - sponsor information
ADD - credit card billing information

GR.5 - repeats for each flight segment in the passenger record’s itinerary
TVL - date/time of departure, arrival time, origin and destination, marketing & operating
airline code(s), flight number, reservation booking designator, operational suffix.
TRA - operating carrier code, flight number and RBD.
RPI - flight booking status and number of passengers for this flight
APD - type of aircraft
SSR - special service requests that apply to this flight
RCI - passenger record locator specific to this flight
9
 PADIS EDIFACT Implementation Guide – PNRGOV Message

IFT - other service information (OSI) for this flight

GR.6 - Check in information for each flight in the itinerary

DAT - check-in time
ORG - the agent info that checked-in the passenger

GR.7 - boarding, seat number and checked bag info

TRI - sequence/boarding number for this check-in
TIF - the checked-in name
SSD - actual seat number (row and column)
TBD - checked bag information

GR.8 - split passenger record locator

EQN - the number of passengers split to/from a passenger record
RCI - the split record locators

GR.9 - non-air segments

MSG - specifies the type of non-air segment such as car, hotel, rail
TVL - non-air segment information

GR.10 - repeats for each occurrence of a history credit

ABI - originator of change and agent id
DAT - history time stamp

GR.11 - one line in a history credit

SAC - history action code
TIF - history passenger name changes
SSR - history special service requirement changes
IFT - history other service information changes
TBD – History Baggage Details

GR.12 - history flight and non-air information

TVL - dates, departure/arrival airport/city codes, vendor code, etc.
RPI - booking status and number of passengers

LTS - unformatted history information

UNT - Message Trailer Information
UNE - Functional Group Trailer
UNZ - Interchange Trailer

Segments and groups below a parent group can not be sent unless the trigger segment of the parent group is sent.
For example: ADD (Level 5) can not be sent unless at least FOP (Group 4), TKT (Group 3) & TIF(Group 2) are also sent,.

It should be noted that the message structure for ACKRES and GOVREQ are simple and therefore do not require a segment
description as defined above for PNRGOV.

10
 PADIS EDIFACT Implementation Guide – PNRGOV Message

3.2 Push of PNR DATA to State - (PNRGOV)

Function: This message enables airlines to send data relevant to State requirements for passenger data in airline reservation systems.

PNRGov Message Structure

Level 0

UNA UNB UNG UNH MSG ORG TVL EQN UNT UNE UNZ
C1 M1 C1 M1 M1 M1 M1 M1 M1 C1 M1

GR 1

C999

Level 1 SRC
M1

Level 2 GR 2 GR 5 GR 8 GR 9 GR 10
RCI SSR DAT IFT ORG ADD EBD LTS
M1 C999 C1 C999 M1 C99 C9 C9999
C999 C999 C99 C9 C99999
TIF TVL EQN MSG ABI

M1 M1 M1 M1 M1

GR 3 GR 6 GR 11
FTI IFT REF EBD FAR SSR ADD TRA RPI APD SSR RCI IFT RCI TVL DAT
Level 3 C1 C99 C1 C1 C9 C999 C99 C1 C1 C1 C999 C1 C99
C999
M1 C99 C1
C999
C999
TKT DAT SAC

M1 M1 M1

GR 4 GR 7
MON PTK TXD DAT ORG TIF SSR IFT TBD GR 12
C1 C1 C99 C1 C1 C1 C1 C1 C1
Level 4 C1 C999 C2
FOP TRI
TVL
M1 M1 M1

Level 5 IFT ADD TIF SSD TBD RPI

C1 C1 C1 C1 C1 C1

11
 PADIS EDIFACT Implementation Guide – PNRGOV Message

Segments:
ABI Additional business source information
ADD Address Information
APD Additional product details
DAT Date and time information
EBD Excess Baggage Details
EQN Number of units
FAR Fare information
FOP Form of Payment
FTI Frequent Traveler Information
IFT Interactive free text
LTS Long Text String
MON Monetary information
MSG Message action details
ORG# Originator of request details
PTK Pricing/ticketing details
RCI Reservation control information
REF Reference information
RPI Related product information
SAC Source And Action Information
SRC# Segment repetition control
SSD Seat Selection Details
SSR Special Requirements Details
TBD Traveler Baggage Details
TIF Traveler information
TKT Ticket number detail
TRA Transport identifier
TRI# Traveller Reference Information
TVL Travel product information
TXD Tax details
UNA Service String Advice
UNB Interchange Header Segment
UNE Functional Group Trailer
UNG Functional Group Header
UNH Message Header
UNT Message Trailer
UNZ Interchange Trailer

# Trigger segment

Some segments may occur multiple times in the structure. Some of these are due to name relation and/or segment
relation.
Where the usage differs depending on grp or level, an explanation is provided under each segment and also mapped
back into each country’s requirements in the Appendices.

12
 PADIS EDIFACT Implementation Guide – PNRGOV Message

3.3 ACKRES – Acknowledgement Response

Function: The ACKRES is used as a response under two possible conditions:

 If a State is responding to receipt of a PNRGOV from a carrier – As bilaterally agreed, to provide a response to
the carriers as to whether the PNRGOV message was received.
 If a carrier is responding to receipt of a GOVREQ from a State – As bilaterally agreed, to provide a response to
the State as to whether the GOVREQ message was received.

ACKRES – Acknowledgement Response

Level 0
UNA UNB UNG UNH MSG ERC UNT UNE UNZ
C1 M1 C1 M1 M1 C999 M1 C1 M1

Segments:

ERC Errors identified in the message (coded) if sent to Carrier

MSG To identify the message function being acknowledged and the result of the processing (successful,
partially processed, etc.)
UNA Service String Advice
UNB Interchange Header Segment
UNE Functional Group Trailer
UNG Functional Group Header
UNH Message Header Information
UNT Message Trailer Information
UNZ Interchange Trailer

Note: It is anticipated that through the provision of an acknowledgment message, Carriers will be able to automatically
resend the messages if not delivered or incorrect data. This would be a system generated resend rather than one as a result
of manual intervention.

13
 PADIS EDIFACT Implementation Guide – PNRGOV Message

3.4 PNRGOV ADHOC Request (GOVREQ)

Function: This message enables a State to make an adhoc request for PNRs of a specified airline/flight/date or record
locator. The use of this message is controlled by a bilateral agreement between the State and the carrier.

GOVREQ – Government Request

UNA UNB UNG UNH MSG ORG TVL RCI UNT UNE UNZ
Level 0 C1 M1 C1 M1 M1 M1 C1 C1 M1 C1 M1

Segments:

MSG Message action details

ORG Originator of request details
RCI Reservation control information
TVL Travel product information
UNA Service String Advice
UNB Interchange Header Segment
UNE Functional Group Trailer
UNG Functional Group Header
UNH Message Header
UNT Message Trailer
UNZ Interchange Trailer

Notes:
1. The MSG should specify whether the request is for an airline/flight number/date or for a record locator.
2. If the request is for an airline/flight number/date, the TVL should be included in the request and the RCI should
be omitted from the request.
3. If the request is for a record locator, the RCI should be included in the request and the TVL should be omitted
from the request.

3.5 Emergency lock (PNRGOV)

Function: This message enables an airline to indicate emergency situation

For message description and segments, see 3.1 and 3.2 above.

Notes:
1. The MSG at level 0 should specify that flight in TVL level 0 of PNRGOV is under emergency lock .
2. This procedure is subject to bilateral agreement

14
 PADIS EDIFACT Implementation Guide – PNRGOV Message

4 UNITED NATIONS SERVICE SEGMENTS

The United Nations Service Segments should be referenced in ISO 9735 and the Architecture for IATA Interactive
EDIFACT. The IATA Architecture Strategy Group, along with its working groups, has made some changes to the service
segments to satisfy the requirements of interactive EDIFACT. The UNB and UNZ should be implemented as they are
described in the ISO 9735.

As per ISO 9735, the service segments are sequenced in a message in the following order:
UNA Service String Advice
UNB Interchange Header Segment
UNG Functional Group Header
UNH Message Header
(BODY of MESSAGE)
UNT Message Trailer
UNE Functional Group Trailer
UNZ Interchange Trailer

For ease in locating the service segment specification in this section, the service segments are defined in alphabetical
order

4.1 UNA: SERVICE STRING ADVICE

Function: The Service String Advice (UNA) is Conditional and provides the capability to specify the service
characters (delimitation syntax) used within the interchange. The UNA service string advice must
be used if the service characters differ from the defaults. The UNA is optional if the default
characters are used.
When used, the service string advice appears immediately before the interchange header segment. The service
string advice shall begin with the upper case characters UNA immediately followed by six characters in the order
shown below. The same character shall not be used in more than one position of the UNA.

Default Service Characters

Name Graphic Representation Functionality

Colon Component Data Element Separator

:
Plus sign Data Element Separator
+
Full stop or Comma . or , Decimal Mark

Question mark Release Character

?
Asterisk Repetition Separator. Not used.
*
Apostrophe
‘ Segment Terminator

15
 PADIS EDIFACT Implementation Guide – PNRGOV Message

Description No. Field Comm Status Max Code Comp. Values / Comments
Type Usage Rep Set

COMPONENT DATA UNA1 an1 an1 M 1 - -

ELEMENT SEPARATOR
DATA ELEMENT UNA2 an1 an1 M 1 - -
SEPARATOR
DECIMAL MARK UNA3 an1 an1 M 1 - -

RELEASE CHARACTER UNA4 an1 an1 M 1 - -

REPETITION UNA5 an1 an1 M 1 - -

SEPARATOR
SEGMENT TERMINATOR UNA6 an1 an1 M 1 - -

Note:
1. UNA1 through UNA6 represent the UN notation for positional values as opposed to normal representation using
data element numbers. In this case where positional values are used, standard separators for standalone data
elements are not used in the UNA segment. The data is simply a string of characters with each position defining
a specific delimiter and its use.
2. Repetition separator is not used in PNRGOV messages and therefore the default * separator does not need to be
released.

Examples:

1. Default characters for UNA service string

UNA:+.?*‘
2. In this example, the right-parens represents the exception to the default Segment Terminator.
UNA:+.?*)

16
 PADIS EDIFACT Implementation Guide – PNRGOV Message

4.2 UNB: INTERCHANGE HEADER

Function: To start, identify and specify an interchange.

Composite/Data Element No. Field Comm Status Max Code Comp. Values / Comments
Type Usage Rep Set

SYNTAX IDENTIFIER S001 - - M 1 - -

Syntax identifier 0001 a4 a4 M 1 - S001 IATA
Syntax version number 0002 n1 n1 M 1 - S001 1
INTERCHANGE SENDER S002 - - M 1 - -

Sender identification 0004 an..35 an..35 M 1 - S002 ‘AIRLINE1’

Sender of the message
Partner identification code 0007 an..4 - N/A - - -
qualifier
Address for reverse routing 0008 an..14 - N/A - - -
INTERCHANGE S003 - - M 1 - -
RECEIVER
Recipient identification 0010 an..35 an..35 M 1 - S003 ‘NZCS’
Receiver of the message
Partner identification code 0007 an..4 - N/A - - -
qualifier
Routing address 0014 an..14 - N/A - - -
DATE AND TIME OF S004 - - M 1 - -
PREPARATION

Date of preparation 0017 n6 n6 M 1 - S004 ‘091128’

The default format is
‘YYMMDD’ (n6)
Time of preparation 0019 n4 n4 M 1 - S004 ‘0900’
The default format is ‘HHMM’
(n4)
INTERCHANGE 0020 an..14 an..14 M 1 - - ‘000000001’
CONTROL REFERENCE Will be repeated in UNZ data
element 0020
RECIPIENTS REFERENCE S005 - - N/A - - -
PASSWORD
Recipient reference password 0022 an..14 - N/A - - S005
Recipient reference password 0025 an..2 - N/A - - S005
qualifier
APPLICATION REFERENCE 0026 an..14 an..14 C 1 - -
PROCESSING PRIORITY 0029 a1 a1 C 1 - -
CODE

ACKNOWLEDGEMENT 0031 n1 n1 C 1 - -
REQUEST
COMMUNICATIONS 0032 an.35 C 1 - -
AGREEMENT ID
TEST INDICATOR 0035 n1 C 1 - -

17
 PADIS EDIFACT Implementation Guide – PNRGOV Message

Notes:
1. The conditional status (C) of elements within this segment is used to indicate that Border Control Authorities
may establish bilateral requirements for these data elements.
2. Elements 0001/0002 recommendation to use +IATA:1
3. Element 0004 is the airline code and 0010 is the targeted specific State entity.
4. Elements 0017 and 0019 are based on UTC (GMT)
5. For systems hosting multiple carriers and/or Ground Handlers, use composite S002, element 0008 for Carrier or
ground handling agent (2 or 3 character airline designator, e.g. BD or full term e.g., AEROGROUND, or a
bilaterally agreed code). Additionally S003, data element 0014 may be used for the routing address of the
recipient or for hub routing for electronic documents.

Examples:
1. Generic example for PNRGOV file generated on 28th Nov 2009 at 9:00GMT:
UNB+IATA:1+AIRLINE1+NZCS+091128:0900+000000001’
2. Message header DL Airline to Canadian CBSA for PNRGOV file generated on 12th Jan 2011 at 15:30GMT:
UNB+IATA:1+DL+CBSAPNRGOV+110112:1530+1234567890’
3. This example is concerned with the push to Australia. QF30 is a flight with the following routing and times:
HKG - 01 Aug 12 - 18:55 - MEL – 02 Aug 12 – 06:05
The push will occur at 24h prior Scheduled Departure Time out of HKG
For the flight departing on 1st Aug at 18:55 (Local Time) from HKG and arriving at MEL at 06:05 on 2nd Aug,
the following segment UNB will be sent:
UNB+IATA:1+1A+AUCBP+120731:1055+0002++PNRGOV+X'
4. United Airlines Flight 1752 - From San Francisco (SFO) to Sydney (SYD)
Scheduled Departure: 02 Aug 12 14:25 local (22:25 GMT)

UNB segments Push

UNB+IATA:1+UA+AUCBP+120731:2225+12345678905’ -72
UNB+IATA:1+UA+AUCBP+120801:2225+12345678904’ -24
UNB+IATA:1+UA+AUCBP+120802:2030+12345678903’ -2
UNB+IATA:1+UA+AUCBP+120802:2130+12345678902’ -1
UNB+IATA:1+UA+AUCBP+120802:2240+12345678901’ Wheels Up

18
 PADIS EDIFACT Implementation Guide – PNRGOV Message

4.3 UNE: FUNCTIONAL GROUP TRAILER

Function: To end and check the completeness of a Functional Group.

Composite/Data Element No. Field Comm Status Max Code Comp. Values / Comments
Type Usage Rep Set

NUMBER OF MESSAGES 0060 n..6 n..6 M 1 - - ‘1’

APPLICATION SENDER 0048 an..14 an..14 M 1 - - ‘000000001’
IDENTIFICATION Must be equal to UNG data
element 0048

Note:

1. Data element 0048 used in the UNE must match 0048 used in UNG

Example:

1. UNE+1+000000001’
2. See UNG example 2.
UNE+1+1’
3. See UNG example 3.
UNE+1+901’

19
 PADIS EDIFACT Implementation Guide – PNRGOV Message

4.4 UNG: FUNCTIONAL GROUP HEADER

Function: To head, identify and specify a Functional Group.

Composite/Data Element No. Field Comm Status Max Code Comp. Values / Comments
Type Usage Rep Set

FUNCTIONAL GROUP 0038 an6 an6 M 1 - - PNRGOV

IDENTIFICATION
APPLICATION SENDER S006 - - M 1 - -
IDENTIFICATION
Application Sender 0040 an..35 an..35 M 1 - S006 ‘AIRLINE1’
identification Sending Application
Partner identification code 0007 an..4 - N/A - - S006
qualifier
APPLICATION S007 - - M 1 - -
RECIPIENT
IDENTIFICATION
Application Recipient 0044 an..35 an..35 M 1 - S007 ‘NZCS’
identification Receiving Application
Partner identification code 0007 an..4 - N/A - - S007
qualifier
DATE AND TIME OF S004 - - M 1 - -
PREPARATION

Date of preparation 0017 n6 n6 M 1 - S004 ‘091128’

The default format is
‘YYMMDD’ (n6)
Time of preparation 0019 n4 n4 M 1 - S004 ‘0900’
The default format is ‘HHMM’
(n4)
FUNCTIONAL GROUP 0048 an..14 an..14 M 1 - - ‘000000001’
REFERENCE NUMBER Will be repeated in UNE data
element 0048
CONTROLLING AGENCY 0051 an..2 an..2 M 1 - - IA
MESSAGE VERSION S008 - - M 1 - -
Message Type Version 0052 an..3 an..3 M 1 - S008 ‘10’ (for example)
Number
Message Type Release 0054 an..3 an..3 M 1 - S008 ‘1’
Number See Note 2.
Association assigned code 0057 an..6 an..6. C 1 - -

APPLICATION 0058 an..14 an..14 C 1 - -

PASSWORD

Notes:
1. The conditional status (C) of elements within this segment is used to indicate that Border Control Authorities
may establish bilateral requirements for these data elements.
2. Border Control Authorities may establish bilateral requirements for the value placed in these data elements.
3. Data element 0048 used in the UNE must match 0048 used in UNG

20
 PADIS EDIFACT Implementation Guide – PNRGOV Message

Examples:

1. An example of an airline sending to a State agency

UNG+PNRGOV+AIRLINE1+NZCS+091128:0900+000000001+IA+13:1'
2. See UNE example 2.
UNG+PNRGOV+UA+USADHS+070218:1545+1+IA+13:1'
3. See UNE example 3
UNG+PNRGOV+AF+USADHS+070218:2100+901+IA+13:1'

21
 PADIS EDIFACT Implementation Guide – PNRGOV Message

4.5 UNH: MESSAGE HEADER

Function: To head, identify and specify a Functional Group.

Composite/Data Element No. Field Comm Status Max Code Comp. Values / Comments
Type Usage Rep Set

MESSAGE REFERENCE 0062 an..14 an..14 M 1 - - ‘MSG001’

NUMBER Will be repeated in UNT data
element 0062

MESSAGE IDENTIFIER S009 - - M 1 - -

Message type 0065 an..6 a6 M 1 - S009 PNRGOV
Message version number 0052 an..3 n2 M 1 - S009 10
Message release number 0054 an..3 n1 M 1 - S009 ‘1’
See Note 2.
Controlling agency, coded 0051 an..2 a2 M 1 - S009 IA
Association assigned code 0057 an..6 - N/A - - S009
Code list directory version 0110 an..6 - N/A - - S009
number
Message type sub-function 0113 an..6 - N/A - - S009
identification
COMMON ACCESS 0068 an..35 an..35 C 1 Initiator's key. As per ISO
REFERENCE 9735:CARF is a Key to relate all
subsequent transfers of data to
the same business case or file.
STATUS OF THE S010 - - C 1 - -
TRANSFER
Sequence of transfers 0070 n..2 n..2 M 1 - S010
First and last transfer 0073 a1 a1 C 1 - S010
MESSAGE SUBSET S016 - N/A - -
IDENTIFICATION
Message subset identification 0115 an.14 - N/A - - S016
Message subset version 0116 an..3 - N/A - - S016
number

Note:

1. The conditional status (C) of elements within this segment is used to indicate that Border Control Authorities
may establish bilateral requirements for these data elements.
2. When used in an ACKRES, the data elements 0068 and 0070 should carry the same values as the UNH of the
message for which it is providing acknowledgement.
3. If multiple messages are required to send the PNRs for a given flight push, the following rules shall apply:
- 0068 should be the same for each message in the series.
- S010/0070 should contain the sequence number of each message in the series (consecutive numbers starting
with 1)
- S010/0073 should contain an indication of where the message fits into the sequence of multiple messages as
one of the following:
C – Commencing message of a sequence
F – Final message of a sequence
For interim messages in a sequence, S010/0073 is not used

22
 PADIS EDIFACT Implementation Guide – PNRGOV Message

Examples:

1. UNH with data element 0068 containing Initiator’s key and Responder’s key:
UNH+1+PNRGOV:10:1:IA+0976310900003C'
2. UNH for a flight split across 3 messages.
First message: UNH+1+PNRGOV:11:1:IA+893133434478201+01:C'
Second message: UNH+1+PNRGOV:11:1:IA+893133434478201+02'
Third and final message: UNH+1+PNRGOV:11:1:IA+893133434478201+03:F

3. UNH for PNR Push and ACKRES.

PNR Push
UNH+1+PNRGOV:10:1:IA+0976310900003C’

ACKRES
UNH+1+ACKRES:10:1:IA+0976310900003C'

4. UNH for PNR Push and ACKRES, where the flight is split across multiple messages, second message.
PNR Push
UNH+1+PNRGOV:11:1:IA+893133434478201+02'
ACKRES
UNH+1+ACKRES:11:1:IA+893133434478201+02'

23
 PADIS EDIFACT Implementation Guide – PNRGOV Message

4.6 UNT: MESSAGE TRAILER

Function: To end and check the completeness of a message by counting the segments in the message
(including UNH and UNT) and validating that the message reference number equates to data
element 0062 in the UNH segment (when applicable).

Composite/Data Element No. Field Comm Status Max Code Comp. Values / Comments
Type Usage Rep Set

NUMBER OF SEGMENTS 0074 n..10 n..10 M 1 - - ‘2578’

IN A MESSAGE
MESSAGE REFERENCE 0062 an..14 an..14 M 1 - - ‘MSG001’
NUMBER Must equal UNH data element
0062

Notes:

1. For data element 0074, the number is computed by counting the number of segments used in the message from
the UNH to the UNT inclusive.

2. For 0062, the value must be identical to the value in 0062 in the corresponding UNH segment.

Examples:

1. UNT+2578+MSG001´
2. UNT+2578+1’

4.7 UNZ: INTERCHANGE TRAILER

Function: To end and check the completeness of an Interchange.

Composite/Data Element No. Field Comm Status Max Code Comp. Values / Comments
Type Usage Rep Set

INTERCHANGE 0036 n..6 n..6 M 1 - - ‘1’

CONTROL COUNT
INTERCHANGE 0020 an..14 an..14 M 1 - - ‘000000001’
CONTROL REFERENCE Must be equal to UNB data
element 0020
Example:

5. UNZ+1+000000001’

24
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5 PADIS RESERVATIONS SUB-GROUP APPROVED SEGMENTS

This section lists all the segments, in alphabetical order, that are a part of the PADIS PNRGOV EDIFACT Message. For
each segment, all composites and elements are listed along with a description, the element or composite number
according to the data dictionary, field type, common usage, mandatory or conditional characteristic, number of
repetitions, indication of a code set and general comments to assist in better understanding the intent of the composite
and/or element.

Always refer to 3.1 Message Segment Descriptions for the context of the segment within the message structure.

5.1 ABI: ADDITIONAL BUSINESS SOURCE INFORMATION (PNRGOV)

Function: To specify additional originator and source information.

Push PNR Data to States - PNRGOV

Composite/Data Element No. Field Comm Stat. Max Code Comments

Type Usage Rep. Set
SOURCE TYPE C337 - - -- M 1 --
Sector/subject identification 7293 an..3 an..3 M 1 Yes To specify this information is the
qualifier creator of the history credit. The value
used is “4”.
Sector/subject identification 7293 an..3 - - N/A 1 --
qualifier
ORIGINATOR DETAILS C300 -- -- C 1 --
Travel agent identification 9900 n..9 n8 C 1 -- ATA/IATA ID number or pseudo IATA
details number.
In-house identification 9902 an..9 an..9 C 1 -- Identification code assigned to an
office/agency by the reservation system.
Maybe a pseudo city or city and office
number.
In-house identification 9902 an..9 an..9 N/A 1 --
In-house identification 9902 an..9 - - N/A 1 --
LOCATION C328 - - -- C 1 --
Place/Location Identification 3225 an..25 a3..5 C 1 Yes The location of the agent making the
change.
Place/Location name 3224 an..17 - - N/A 1 --
COUNTRY, CODED 3207 an..3 an..3 N/A 1 --
COMPANY 9906 an..35 an..3 C 1 Yes A 2-3 character airline/CRS code to
IDENTIFICATION specify the creator of the change.

Example:
1. The creator of the history credit is a DL agent in Atlanta.
ABI+4+05FD28:GS+ATL++DL’

25
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.2 ADD: Address Information (PNRGOV)

Function: To specify passenger address information.

Push PNR Data to States - PNRGOV

Composite/Data Element No. Field Comm Stat. Max Code Comments

Type . Rep. Set
Usage
ACTION DETAILS C031 -- - -- N/A 1 --
Update action code 9858 a1 - - N/A 1 - -
Action request/notification, 1229 an..3 - - N/A 9 --
coded
ADDRESS DETAILS C032 -- -- M 9 --
Address purpose code 3299 an..3 an..3 C 1 Yes Specifies the purpose of the address
information, e.g., contact, payer, billing
address
Street and number/P.O. Box 3042 an..125 an..125 C 1 -- The street number and name
City name 3164 an..35 an..35 C 1 - - City name
Country sub-entity 3229 an..9 an..9 C 1 - - State or province
identification
Country sub-entity name 3228 an..35 an..35 C 1 --
Country, coded 3207 an..3 -- C 1 Yes Use ISO 3166-1-alpha 2 or 3 code
Postcode identification 3251 an..17 an..10 C 1 --
Free text 4440 an..255 an..70 C 1 -- See note 5
Place/location 3224 an.l7 - - N/A 1 --

Notes:
1. The ADD in GR.1 at level 2 may contain a contact address for the PNR.
2. The ADD in GR.2 at level 3 may contain emergency contact information and or/ UMNR delivery and collection
addresses.
3. The ADD in GR.4 at level 5 may contain the address of the payer of the ticket.
4. Email addresses can be provided in ADD, SSR or IFT segments. The preference is to first place them in ADD
segments. Otherwise, place them in SSR segments when it is in the airline’s system as SSR CTCE. Or else, place
them in IFT.
5. Free text field 4440 can include telephone number, email address or unstructured address as designated by the
Address purpose code in 3299..

Example:
1. The contact address is 4532 Wilson Street, Philadelphia, zip code 34288
ADD++700:4532 WILSON STREET:PHILADELPHIA:PA::US:34288’
2. The contact address includes a long Street and number/P.O. Box [3042] description.
ADD++700:FLAT 201 SMEATONWITCH AVENUE CORNMILL YARD
VIEWS:LEEDS:YORKSHIRE::GB:LS185NG'
3. Fully fielded address and telephone number (Address 325 VICTORIA AVENUE BELLEVILLE ON CA
K8N2E2 and Telephone 16139688982)
ADD++700:325 VICTORIA AVENUE:BELLEVILLE:ON::CA:K8N2E2+4:::::::16139688982'
4. Address as free text and e-mail address (Address 325 VICTORIA AVENUE BELLEVILLE ON CA K8N2E2
and E-mail KEN.DAVIDSON@GMAIL.COM)

26
 PADIS EDIFACT Implementation Guide – PNRGOV Message

ADD++11:::::::325 VICTORIA AVENUE+11:::::::BELLEVILLE ON

K8N2E2+10:::::::KEN.DAVIDSON//GMAIL.COM'
5. Telephone number and e-mail address (Telephone 16139688982 and E-mail
KEN.DAVIDSON@GMAIL.COM)
ADD++4:::::::16139688982+10:::::::KEN.DAVIDSON//GMAIL.COM'

27
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.3 APD: ADDITIONAL PRODUCT DETAILS (PNRGOV)

Function: To convey additional information concerning an airline flight.

Push PNR Data to States - PNRGOV

Composite/Data Element No. Field Comm. Stat. Max Code Comments

Type Usage Rep. Set
ADDITIONAL PRODUCT C314 - - -- C 1 - - Additional details describing a specific
DETAILS means of transport
Type of Means of Transport 8179 an..8 an..8 C 1 Yes UN/IATA code identifying type of
aircraft (747, 737, etc.).
Number of Stops 9924 n..3 - - N/A 1 --
Leg Duration 9926 n..6 - - N/A 1 --
Percentage 5482 n..8 - - N/A 1 --
Days of Operation 9928 an..7 - - N/A 1 --
Date/Time/Period 2380 an..35 - - N/A 1 --
Complexing Flight Indicator 9950 an1 - - N/A 1 --
Place/Location Identification 3225 an..25 - - N/A 1 --
Place/Location Identification 3225 an..25 - - N/A 1 --
Place Location Identification 3225 an..25 - - N/A 1 --
STATION INFORMATION C348 - - - - N/A 1 --
Gate Description 9870 an..6 - - N/A 1 --
Related Place/ Location One 3223 an..25 - - N/A 1 --
ID
Related Place/ Location Two 3233 an..25 -- N/A 1 --
ID
STATION INFORMATION C348 - - -- N/A 1 --
Gate Description 9870 an..6 -- N/A 1 --
Related Place/ Location One 3223 an..25 -- N/A 1 --
ID
Related Place/ Location Two 3233 an..25 -- N/A 1 --
ID
MILEAGE/TIME DETAILS C317 - - -- N/A 1 --
Measurement Value 6314 n..18 -- N/A 1 --
Measure Unit Qualifier 6411 an..3 -- N/A 1 --
First Time 9918 n..4 -- N/A 1 --
TRAVELLER TIME C318 - - -- N/A 1 --
DETAILS
First Time 9918 n..4 -- N/A 1 --
Second Time 9922 n..4 -- N/A 1 --
Check-In Details 9952 an..10 -- N/A 1 --
PRODUCT FACILITIES C320 -- -- N/A 10 --
Facility Type, Coded 9932 an..3 -- N/A 1 --
Facility Description, Text 9934 an..70 -- N/A 1 --
Product Details Qualifier 9970 an..3 -- N/A 1 --
Characteristic Identification 7037 an..17 -- N/A 26 --

Example:
1. Equipment Type of Boeing 747
APD+747'

28
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.4 DAT: DATE AND TIME INFORMATION (PNRGOV)

Function: To convey information regarding estimated or actual dates and times of operational events.

Push PNR Data to States - PNRGOV

No. Field Comm. Stat. Max Code Comments

Composite/Data Element Type Usage Rep. Set
DATE AND TIME DETAILS C688 -- -- C 99 --
Date/Time/Period Qualifier 2005 an..3 an ..3 C 1 Yes To identify the type of date to follow
First Date 9916 an..35 n6 C 1 - - A date (ddmmyy).
First Time 9918 n..4 n4 C 1 - - A time (hhmm).
Date/Time/Period Qualifier 2005 an..3 -- N/A 1 --
First Time 9918 n..4 -- N/A 1 --
Movement Type 8335 an..3 -- N/A 1 --
Place/Location Identification 3225 an..25 -- N/A 1 --

Notes:
1. DAT at GR1 can contain ticket issue date and last PNR transaction date/Time
2. DAT at GR3 is the date of ticket issuance for each ticket.
3. DAT at GR6 will be check-in transaction date/time as stored by RES systems holding DC data
4. DAT at GR10 will hold PNR History transaction date/time
5. DAT at Group 6 holds Check-in information. C688/2005 will be used to specify that date/time is in free text
format in data element C688/9916.
6. Unless specifically stated otherwise in bilateral agreement, the time is in Universal Time Coordinated (UTC)

Examples:
1. Latest PNR transaction date and time.
DAT+700:241097:1005'
2. Ticket issuance date and time
DAT+710:041159:0730'
3. Check-in transaction date/time
DAT+2:010604:1800’
4. PNR History transaction date/time
DAT+T:010695:1800'
5. Check-in including date time is expressed as free text
DAT+3:L FT WW D014357 12AUG121423Z 1D5723'

29
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.5 EBD: EXCESS BAGGAGE DETAILS (PNRGOV)

Function: To specify information concerning excess baggage charges and the associated baggage details

Push PNR Data to States - PNRGOV

Composite/Data Element No. Field Comm. Stat. Max Code Comments

Type Usage Rep. Set
EXCESS BAGGAGE C674 - - -- C 1 --
DETAILS
Currency, coded 6345 an..3 an..3 C 1 -- The currency code per unit
Monetary amount 5004 n..18 n..18 C 1 -- The rate per unit
Processing indicator, coded 7365 an..3 -- N/A 1 --
BAGGAGE DETAILS C675 -- -- C 3 --
Quantity 6060 n..15 n..2 C 1 -- The total number in excess
Measurement value 6314 n..18 -- N/A 1 --
Allowance or charge qualifier 5463 an..3 an..3 C 1 Yes Specifies if pieces or weight
Measure unit qualifier 6411 an..3 an..3 C 1 Yes If weight, specifies if pounds or
kilograms.
Processing indicator, coded 7365 an..3 -- N/A 1 --
BAGTAG DETAILS C358 -- -- N/A 99 --
Company identification 9906 an..35 -- N/A 1 --
Item number 7140 an..35 -- N/A 1 --
Total number of items 7240 n..15 -- N/A 1 --
Place/location identification 3225 an..25 -- N/A 1 --
Company identification 9996 an..15 -- N/A 1 --
number
Data indicator 9988 an..3 -- N/A 1 --
Item characteristic, coded 7081 an..3 -- N/A 1 --
Special requirement type 9962 an..4 -- N/A 1 --
Measurement value 6314 n..18 -- N/A 1 --
Measure unit qualifier 6411 an..3 -- N/A 1 --
Free text 4440 an..25 -- N/A 1 --
5

Note:
1. Used to send paid baggage information.

Example:
1. One piece of baggage over the allowance USD 50
EBD+USD:50.00+1::N’

30
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.6 EQN: NUMBER OF UNITS

Function: To specify the number of units required.

Push PNR Data to States - PNRGOV

Composite/Data Element No. Field Comm. Stat. Max Code Comments

Type Usage Rep. Set
NUMBER OF UNIT C523 - - -- M 9 --
DETAILS
Number of Units 6350 n..15 n..3 M* 1 -- A 1-3 numeric to specify number of
PNR or passengers.
Number of Units Qualifier 6353 an..3 -- N/A 1 --

Notes:
1. The EQN at level 0 is used to specify the total number of PNRs being sent for the flight push. In case of full
PNR push, the total number of PNRs contained in the full PNR push regardless of the number of messages used
for the full push. In the case of update PNR push, the total number of PNRs contained in the update PNR push
regardless of the number of messages used for the update push should be used.
2. The EQN at GR8 is used to identify numbers of passengers split from/to PNR.
3. As bilaterally agreed, where there is no PNR to be sent in a specific message, the EQN at level ‘0’ may contain
the number zero (“0”).

Examples:
1. Total number of PNRs
EQN+98'
2. Four passengers split from this PNR.
EQN+4'

31
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.7 ERC: APPLICATION ERROR INFORMATION

Function: To identify errors in the message sent to the States

Acknowledgement Response – ACKRES

Composite/Data Element No. Field Comm. Stat. Max Code Comments

Type Usage Rep. Set
APPLICATION ERROR DETAIL C901 -- -- M 1 --
Application error, coded 9321 an..3 n..3 M 1 Y
Code list qualifier 1131 an..3 -- N/A 1 --
Code list responsible agency, coded 3055 an..3 N/A 1

Examples:
1. Application Error - Invalid Departure Time
ERC+103'
2. Invalid flight number.
ERC+114'

32
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.8 FAR: FARE INFORMATION (PNRGOV)

Function: To specify fare information details.

Push PNR Data to States - PNRGOV

Composite/Data Element No.

Field Comm. Stat. Max Code Comments
Type Usage Rep. Set
NUMBER OF UNITS 6353 an..3 an..3 C 1 Yes Type of passenger, e.g. adult, child, group,
QUALIFIER corporate. Used to specify an industry
defined pricing passenger type code (PTC).
QUANTITY 6060 n..15 n..3 C 1 - - Age. To specify age related to a child or
senior citizen, etc.
FARE DETAILS C662 - - -- C 1 --
Number of units Qualifier 6353 an..3 an..3 C 1 Yes Discounted fare type, related to each PTC
code.
Percentage 5482 n..8 n..3 C 1 - - The percent of discount. Discount fare.
Country, coded 3207 an..3 an..3 C 1 Yes ISO country code in lieu of discounted
percentage amount.
Fare classification type, coded 9878 an..3 an..3 C 1 Yes Discounted fare classification type.
IDENTITY NUMBER 7402 an..35 an..35 C 1 - - In-house fare type/corporate contract
number.
FARE TYPE GROUPING C644 - - -- N/A 1 --
INFORMATION
Pricing Group 5388 an..35 -- N/A 5 -- .
RATE/TARIFF CLASS 5242 an..35 an..18 C 9 - - Fare basis code/ticket designator code.

Examples:
1. The fare is a 20 percent discounted fare type for an 9 year old child.
FAR+C+9+1:20:US+++YEE3M'
2. The fare is an industry discounted passenger traveling on business with space available.
FAR+I++764:4::B2+++C'
3. More than nine fare basis codes per passenger.
FAR++++++VEE3MEGI+VEE3MEGI+VEE3MEGI+LRTEG+LRTEG+VEE3MEGI+VEE3MEGI+VEE3ME
GI+LRTEG’
FAR++++++LRTEG'
4. Two different discounts used.
FAR+++:20+++Y3LPK'
FAR+++:5+++Y3PLK+Y4PLK+C4PLK'
5. Two different types of fares used for one passenger: 25% discounted fares for a child, based on the ticket
designator appended to the end of the resulting fares or specified fares applied and a normal fare with no
discount.
FAR+C++:25+++LRT3ED/CH+KRT3ED/CH’
FAR++++++MRTYED'

33
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.9 FOP: FORM OF PAYMENT (PNRGOV)

Function: To convey details describing the form of payment

Push PNR Data to States - PNRGOV

Composite/Data Element No. Field Comm. Stat. Max Code Comments

Type Usage Rep. Set
FORM OF PAYMENT C641 - - -- M 99 --
DETAILS
Form of Payment Identification 9888 an..10 an..3 M 1 Yes Form of payment type
Data Indicator 9988 an..3 an..3 C 1 Yes To indicate old, new or original form of
payment
Monetary Amount 5004 n..18 n..18 C 1 - - Form of payment amount
Company Identification 9906 an..35 an..3 C 1 - - Vendor code (CC)
Reference Number 1154 an..35 an..25 C 1 - - Account number (CC/GR/SGR)
First Date 9916 an..35 n4 C 1 - - Expiration date (CC) (mmyy)
Approval Identification 9889 an..17 - N/A 1 --
Source, Coded 9890 an..3 - N/A 1 --
Monetary Amount 5004 n..18 - N/A 1 --
Verification, Coded 9891 an..3 - N/A 1 --
Account holder number 3194 an..70 - N/A 1 --
Payment Time Reference, 2475 an..3 - N/A 1 --
Coded
Free Text 4440 an..25 - C 1 --
5
Membership Status, Coded 7453 an..3 - N/A 1 --
Transaction Information 9892 an..35 - N/A 1 --

Note:
1. If payment is via credit card, then the provision of the cardholder name is via the IFT if different from the
passenger.
2. Airline specific (non-standard) form of payment codes should be sent in 9888 as MS (IATA standard) and add
own code in Free Text (4440).

Examples:
1. Paid with an American Express card, with an expiration date of 12/11
FOP+CC::416.00:AX:373212341234123:1211’
2. Form of payment is cash.
FOP+CA::731.00'
3. Form of payment is Government receipt.
FOP+GR::200.00::AB123456'
4. Old form of payment was VISA card with an expiration date of August, 2013
FOP+CC:2:628.32:VI:4235792300387826:0813’
5. PayPal payment
FOP+EF::2044.30:PP:1234'
6. Visa card payment for $353.71 and PayPal payment for 38.29
FOP+CC::353.71:VI:XXXXXXXXXXXX4576:1018+EF::38.29:PP'

34
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.10 FTI: FREQUENT TRAVELLER INFORMATION (PNRGOV)

Function: To specify frequent traveller information.

Push PNR Data to States - PNRGOV

Composite/Data Element No. Field Comm. Stat. Max Code Comments

Type Usage Rep. Set
FREQUENT TRAVELLER C326 - - -- M 9 --
IDENTIFICATION
Company Identification 9906 an..35 an..3 M 1 Yes Airline designator, coded
Frequent Traveller 9948 an..25 an..20 M 1 - - A code to identify a frequent traveller -
Identification the frequent traveller number.
Traveller Reference Number 9944 an..10 - - N/A 1 --
Status, coded 4405 an..3 an..3 C 1 Yes Use code “CK” to indicate FF number
was obtained at check-in
Membership level 7456 an..35 -- C 1 - - Membership Information
Hierarchical ID Number 7164 an..12 -- N/A 1 --
Item Description 7008 an..35 -- C 1 - - Tier Description
Company Identification 9906 an..35 -- C 1 - - Alliance Code
Passenger Priority Value 9949 n..4 -- N/A 1 --

Examples:
1. A United Airlines Frequent Traveller.
FTI+UA:12345678964'
2. Passenger is using frequent flyer account on airline ZZ.
FTI+ZZ:001012693109'
3. Passenger has a British Airways Frequent Traveller number, is a BA GOLD member and description of tier level
is GOLD. Passenger also has a One World (code 701) alliance Emerald member.
FTI+BA:12345678:::GOLD::GOLD+BA:12345678:::EMER::EMERALD:701'
4. Airline ZZ frequent flyer account information, platinum level, for accompanying passenger(s). Collected at time
of Check-In.
FTI+ZZ:0114797350::CK:PLATINUM::ELITE PLUS’

35
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.11 IFT: INTERACTIVE FREE TEXT (PNRGOV)

Function: To provide free form or coded text information.

Push PNR Data to States - PNRGOV

Composite/Data Element No. Field Com Stat. Max Code Comments

Type m. Rep. Set
Usage
FREE TEXT C346 -- -- C 1 --
QUALIFICATION
Text Subject Qualifier 4451 an..3 an..3 M 1 Yes See code set values.
Information Type 9980 an..4 an..4 C 1 Yes A code describing data in 4440
Status, coded 4405 an..3 an..3 C 1 Yes Fare calculation reporting indicator or
pricing indicator
Company Identification 9906 an..35 an..3 C 1 - - Validating carrier airline designator
Language, coded 3453 an..3 - - N/A 1 Yes ISO Code for Language of free text.
FREE TEXT 4440 an..255 an..25 C 999 - - Free text message
5

Notes:
1. Multiple occurrences of the same type of literal free text should each be contained in a separate IFT segment to
avoid confusion regarding where each occurrence begins and ends.
2. If the value in code set 4451 indicates that coded information exists, then this coded data pertains to information
in element 9980.
3. Data in fare calculation is positional information within a free text data element. The data should never be
truncated or padded by an EDIFACT handler.
4. When data element 4451 is used, it should contain values 1, 3 or 4. All other codes in 4451 code set are SISC
codes.

Examples:

1. Fare calculation with fare calculation reporting indicator.

IFT+4:15:0+DEN UA LAX 01.82 487.27 UA DEN 487.27 USD976.36 ENDXFDEN3LAX+3'
2. OSI information.
IFT+4:28::KL+CTC 7732486972-U‘
3. Sponsor information.
IFT+4:43+TIMOTHY SIMS+2234 MAIN STREET ATLANTA, GA 30067+770 5632891‘

36
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.12 LTS: LONG TEXT STRING (PNRGOV)

Function: To represent a piece of information that contains multiple lines of text as one whole.

Push PNR Data to States - PNRGOV

Composite/Data Element No. Field Comm. Stat. Max Code Comments

Type Usage Rep. Set
TEXT STRING DETAILS 9990 an..9999 an..9999 M 1 - - Block of free text up to 9999
characters. May include control
characters such as carriage return and
line feed.

Notes:
1. Carriage returns and line feeds may corrupt commercial parsers and this will need to be agreed through a
bilateral agreement
2. Flown segments are to be included in history.
3. **LTS segments can repeat

Example:
1. Unstructured PNR history.
LTS+ LAX GS WW D006217 2129Z/09DEC 02961B AS DL1314U 19FEB MCOATL NN/SS1
1130A 105P AS SEAT RS 29F TRAN/TRINH DL1314 19FEB MCOATL AS DL1319T
23FEB ATLMCO NN/SS1 355P 524P¬AS SEAT RS 28A TRAN/TRINH DL1319 23FEB
ATLMCO A$ 4P A-USD 160.93 TX 33.27 TTL 194.20 WW09DEC AC A ORL DL
ATL87.44UA10A0SJ DL ORL73.49TA10X3SJ USD160.93END ZP MCOATL XF MCO4.5ATL4.5 PS
LAXADLLAX LAXGSWWUS LAXDL -LAX GS WW D006217 09DEC2129Z 02961B XS DL1314U 19FEB
MCOATL NN/HK1 1130A 105P XS SEAT XR/RS 29F TRAN/TRINH DL1314 19FEB MCOATL
XS DL1319T 23FEB ATLMCO NN/HK1 355P 524P XS SEAT XR/RS 28A TRAN/TRINH DL1319
23FEB ATLMCO X$ 4P A-USD 160.93 TX 33.27 TTL 194.20 WW09DEC XC A ORL DL
ATL87.44UA10A0SJ DL ORL73.49TA10X3SJ USD160.93END ZP MCOATL XF MCO4.5ATL4.5 XE A-
USD XF-9.00/ZP-7.20/AY-5.00/US-12.07/ XT TKT-TE/1200N/09DEC -LAX GS WW D006217
09DEC2129Z 02961B’

2. Repeating LTS - still unstructured history

LTS+0/O/NM/BELT/ISABELLE MRS(ADT)(INF/SOPHY/20SEP12)'

LTS+0/O/SS/SQ 602 D 27MAY 1 SINICN LK1 1430 2205/NN \*1A/E\*

/SQ/SG/C/I/CAB J//1///// /Y 1625/B 153//AY 1838/EY 1685/SINICN/D'

LTS+0/O/SR/SSR INFTSQNN1 BELT/SOPHY 20SEP12/SQ 602 D 27MAY

SINICN/BELT/ISABELLE MRS(ADT)(INF/SOPHY/20SEP12)'

LTS+0/O/SR/SSR FQTVSQHK/ SQ8794285757 S/KFES/BELT/ISABELLE

MRS(ADT)(INF/SOPHY/20SEP12)'

37
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.13 MON: MONETARY INFORMATION (PNRGOV)

Function: To specify monetary information details.

Push PNR Data to States - PNRGOV

Composite/Data Element No. Field Comm. Stat. Max Code Comments

Type Usage Rep. Set
MONETARY C663 - - -- M 20 --
INFORMATION
Monetary amount type 5025 an..3 an1..3 M 1 Yes To specify total ticket/document amount
qualifier
Allowance or Charge number 1230 an..35 an1..18 C 1 -- Amount or text defined by industry
standards Reso 720a para 13
Currency, coded 6345 an..3 an..3 C 1 -- ISO currency code
Place/location identification 3225 an..25 -- C 2 --

Examples:
1. Ticket/document amount is $0.00 due to an award certificate.
MON+T:AWARD'
2. Ticket/document amount is 297.50 EUR.
MON+T:297.50:EUR’

38
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.14 MSG: MESSAGE ACTION DETAILS (PNRGOV), (ACKRES)

Function: To specify the message type and business function.

Push PNR Data to States - PNRGOV

Acknowledgement Response- ACKRES
PNRGOV Adhoc Request - GOVREQ

Composite/Data Element No. Field Comm. Stat. Max Code Comments

Type Usage Rep. Set
MESSAGE FUNCTION / C302 - - -- M* 1 --
BUSINESS DETAILS
Business Function, Coded 4025 an..3 an..3 C 1 Yes A code specifying type of service (air,
car, hotel, etc.).
Message Function, Coded 1225 an..3 an..3 C 1 Yes Identifies what action is requested or
has been performed.
Code List Responsible 3055 an..3 -- N/A 1 --
Agency, Coded
Message function, coded 1225 an..3 -- N/A 20 --
RESPONSE TYPE, CODED 4343 an..3 an…3 C 1 Yes Indicates whether request was processed
successfully.

Notes:
1. Business Function, Coded (Element 4025) is only used in the MSG Gr9 of PNRGOV to specify the type of
service (car, hotel, train, etc.)
2. If MSG is used at Level 0 of PNRGOV or ACKRES, 4025 is not needed
3. Data element 4343 is M* if the MSG is used in the ACKRES message.
4. Data element 4343 is N/A if the MSG is used in the PNRGOV and GOVREQ messages.

Examples:
1. To specify that the TVL is for a hotel segment.
MSG+8'
2. Push PNR data to States
MSG+:22’
3. To identify a change PNRGOV message
MSG+:141’
4. To specify that flight in TVL level 0 of PNRGOV is under emergency lock
MSG+:772’

39
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.15 ORG: ORIGINATOR OF REQUEST DETAILS (PNRGOV)

Function: To specify the point of sale details.

5.15.1 ORG: Push PNR Data to States - PNRGOV

Composite/Data Element No. Field Comm. Stat. Max Code Comments

Type Usage Rep. Set
SYSTEM DETAILS C336 - - -- M* 1 --

Company Identification 9906 an..35 an..3 M* 1 Yes 2-3 character airline/CRS code, or
bilaterally agreed code, of the system
that delivers the message.
Place/Location identification 3225 an..25 a3..5 C 1 Yes 3 character ATA/IATA airport/city
code of the delivering system/
originator of the request.
Place/Location Name 3224 an..17 -- N/A 1 --
ORIGINATOR C300 - - -- C 1 --
IDENTIFICATION DETAILS
Travel Agent Identification 9900 n..9 n8 C 1 -- ATA/IATA travel agency ID number or
Details pseudo IATA travel agency number.
In-House Identification 9902 an..9 an..9 C 1 -- Identification code assigned to an
office/agency by the reservation system.
May be a pseudo city or city and office
number.
In-House identification 9902 an..9 an..9 C 1 -- Identification code that is related to a
system key. Access security/entry key
into actioning system.
In-House identification 9902 an..9 -- N/A 1 --
LOCATION C328 - - -- C 1 --
Place/Location Identification 3225 an..25 a3..5 M* 1 Yes A 3 character ATA/IATA airport/city
code from where the agent initiates the
request.
Place/Location Name 3224 an..17 -- N/A 1 --
SYSTEM DETAILS C336 - - -- C 1 --
Company Identification 9906 an..35 an..3 C 1 Yes 2-3 character airline/CRS code, or
bilaterally agreed code, of the system
that originates the message, when
different from the delivering system.
Place/Location Identification 3225 an..25 a3..5 C 1 Yes 3 character ATA/IATA airport/city
code of the system that originates the
message.
Place/Location name 3224 an..17 -- N/A 1 --
ORIGINATOR TYPE CODE 9972 an1 an1 C 1 Yes One character code for airline agent,
travel agent, etc.
ORIGINATOR DETAILS C354 - - -- C 1 --
Country, Coded 3207 an..3 an..3 C 1 Yes ISO country code of the agent.
Currency, Coded 6345 an..3 an..3 C 1 Yes ISO currency code for currency of
originator country.
Language, Coded 3453 an..3 an..3 C 1 Yes ISO code of language.
ORIGINATOR'S 9904 an..9 an..9 C 1 - - A reference number/ authority code
AUTHORITY assigned to the requester as in an agent's
REQUEST CODE initials or logon.

40
 PADIS EDIFACT Implementation Guide – PNRGOV Message

COMMUNICATION 3148 an..25 an..6 C 1 -- LNIATA where LN=line and

NUMBER IA=interchange address and
TA=terminal address.
PARTY ID 3039 an..17 an..17 C 1 -- Group identification such as network id.
IDENTIFICATION

Notes:
1. The ORG at level 0 is the sender of the data.
2. The ORG in GR.1 at level 2 is the originator of the booking. For “update” pushes when the push flight/date is
cancelled from a PNR or the complete PNR is cancelled or not found, the ORG is sent as an empty segment, i.e.,
does not contain data.
3. The ORG in GR.6 at level4 is the agent id who checked in the passenger for this flight segment.

Examples:
1. The originator of the message is American Airlines agent in Dallas
ORG+AA:DFW'
2. The originator of the booking is an LH agent located in Amsterdam hosted on Amadeus.
ORG+1A:MUC+12345678:111111+AMS+LH+A+NL:EUR:NL+0001AASU’
3. The originator of the booking is an Amadeus travel agent request.
ORG+1A:NCE+12345678:DDGS+++T'
4. Origination details for a Worldspan travel agent request.
ORG+1P:HDQ+98567420:IPSU+ATL++T+US:USD+GS'
5. For a cancelled PNR in an “update” push
ORG’

41
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.15.1 ORG: PNRGOV Adhoc Request - GOVREQ

Composite/Data Element No. Field Comm. Stat. Max Code Comments

Type Usage Rep. Set
SYSTEM DETAILS C336 -- -- -- 1 --
Company Identification 9906 an..35 -- -- 1 --
Place/Location identification 3225 an..25 -- N/A 1 --
Place/Location Name 3224 an..17 -- N/A 1 --
ORIGINATOR C300 -- -- N/A 1 --
IDENTIFICATION DETAILS
Travel Agent Identification 9900 n..9 -- N/A 1 -- .
Details
In-House Identification 9902 an..9 -- N/A 1 --
In-House identification 9902 an..9 -- N/A 1 --
In-House identification 9902 an..9 -- N/A 1 --
LOCATION C328 -- -- N/A 1 --
Place/Location Identification 3225 an..25 -- N/A 1 --
Place/Location Name 3224 an..17 -- N/A 1 --
SYSTEM DETAILS C336 -- -- N/A 1 --
Company Identification 9906 an..35 -- N/A 1 --
Place/Location Identification 3225 an..25 -- N/A 1 --
Place/Location name 3224 an..17 -- N/A 1 --
ORIGINATOR TYPE CODE 9972 an1 -- N/A 1 --
ORIGINATOR DETAILS C354 -- -- M* 1 --
Country, Coded 3207 an..3 an..3 M* 1 Yes ISO country code of the State making
the adhoc request for PNRGOV of a
specific flight/date..
Currency, Coded 6345 an..3 -- N/A 1 --
Language, Coded 3453 an..3 -- N/A 1 --
ORIGINATOR'S 9904 an..9 -- N/A 1 --
AUTHORITY
REQUEST CODE
COMMUNICATION 3148 an..25 -- N/A 1 --
NUMBER
PARTY ID 3039 an..17 -- N/A 1 --
IDENTIFICATION

Examples:
1. The originator of the message is The Australian government.
ORG++++++AU'

42
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.16 PTK: PRICING/TICKETING DETAILS (PNRGOV)

Function: To specify pricing/ticketing details.

Push PNR Data to States - PNRGOV

Composite/Data Element No. Field Comm. Stat. Max Code Comments

Type Usage Rep. Set
PRICING / TICKET-ING C664 - - -- C 1 --
INFORMATION
Price type qualifier 5387 an..3 an..3 C 1 Yes Ticketing mode indicator
Price type qualifier 5387 an..3 an..3 C 1 Yes International or domestic sales indicator
Price type qualifier 5387 an..3 an..3 C 1 Yes Statistical code
Price type qualifier 5387 an..3 an..3 C 1 Yes Self sale indicator
Price type qualifier 5387 an..3 an..3 C 1 Yes Net reporting indicator
Price type qualifier 5387 an..3 an..3 C 1 Yes Tax on commission indicator
Price type qualifier 5387 an..3 an..3 C 1 Yes Non-endorsable indicator
Price type qualifier 5387 an..3 an..3 C 1 Yes Non-refundable indicator
Price type qualifier 5387 an..3 an..3 C 1 Yes Penalty restriction indicator
Price type qualifier 5387 an..3 -- N/A 1 --
Price type qualifier 5387 an..3 -- N/A 1 --
Price type qualifier 5387 an..3 -- N/A 1 --
Price type qualifier 5387 an..3 an..3 C 1 Yes Non-interlineable indicator
Price type qualifier 5387 an..3 an..3 C 1 Yes Non-commissionable indicator
Price type qualifier 5387 an..3 -- N/A 1 --
Price type qualifier 5387 an..3 an..3 C 1 Yes Non-reissuable/non-exchangeable
indicator
Price type qualifier 5387 an..3 an..3 C 1 Yes Carrier fee reporting indicator
Price type qualifier 5387 an..3 an..3 C 1 Yes Refund calculation indicator
Price type qualifier 5387 an..3 -- N/A 1 --
Price type qualifier 5387 an..3 -- N/A 11 --
PRICE/TARIFF TYPE, 5379 an..3 -- N/A 1 --
CODED
PRODUCT DATE/TIME C310 - - -- C 1 --
First date 9916 an..35 n6 C 1 -- Ticketing purchase deadline date.
(ddmmyy)
First time 9918 n..4 n4 C 1 -- Ticketing purchase deadline time.
(hhmm)
Second date 9920 an..35 -- N/A 1 --
Second time 9922 n..4 -- N/A 1 --
Date variation 9954 n1 -- N/A 1 --
COMPANY C306 - - -- C 1 --
IDENTIFICATION
Company identification 9906 an..35 an..3 M 1 Yes Validating carrier airline code
Company identification 9906 an..35 an..3 C 1 Yes Ticketing system code
Company identification 9906 an..35 -- N/A 1 --
COMPANY C665 - - -- C 1 --
IDENTIFICATION
NUMBERS
Company identification 9996 n..15 n3 M 1 -- Validating carrier accounting code
number
Company identification 9996 n..15 n3 C 1 -- System provider accounting code
number
LOCATION DETAILS C666 - - -- C 2 --
Place/location identification 3225 an..25 a3..5 C 1 - - Sales/ticketing location city code
Country, coded 3207 an..3 an..3 C 1 Yes Sales/ticketing location country code
IDENTITY NUMBER 7402 an..35 an..35 C 1 - - In house fare type/corporate contract
number
43
 PADIS EDIFACT Implementation Guide – PNRGOV Message

MONETARY AMOUNT 5004 n..18 -- -- N/A --

Example:
1. The pricing/ticketing details: the ticket is non-refundable, the ticketing deadline date and time are
10 pm on 6/15/10, the validating carrier is DL and the sales/ticketing location city code is ATL.
PTK+NR++150610:2200+DL+006+ATL'

44
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.17 RCI: RESERVATION CONTROL INFORMATION (PNRGOV)

Function: To specify a reference to a reservation.

Push PNR Data to States – PNRGOV

PNRGOV Adhoc Request - GOVREQ

Composite/Data Element No. Field Comm. Stat. Max Code Comments

Type Usage Rep. Set
RESERVATION CONTROL C330 - - -- M* 9 --
INFORMATION
Company Identification 9906 an..35 an..3 M* 1 Yes 2-3 character of airline/CRS code of the
following record reference (Reservation
Control Number)
Reservation Control Number 9956 an..20 an..20 M* 1 - - Reference to a record
Reservation Control Type 9958 an1 an1 C 1 Yes Code identifying type of record
reference: record locator number,
confirmation number, etc.
First Date 9916 an..35 n6 C 1 - - Date record was created (ddmmyy).
Time 9994 n..9 n4..6 C 1 - - Time (GMT) record was created,
common usage is to minute or second,
not millisecond (hhmmss[msmsms]).

Notes:
1. The composite C330 will appear at least once and may be repeated up to eight more times.

2. In case the data is coming from a DCS or ground handling system which does not have access to the reservation
system’s Record Locator, the following information will be contained in composite C330:
- 9906 - the operating carrier code
- 9956 - the locator assigned by DCS in 9956
- 9958 – a code specifying that the RCI contains a “DCS Reference”
3. The operating carrier’s record locator should be included in the RCI if available

Examples:
1. SAS passenger record reference.
RCI+SK:12DEF'
2. Travel agency using Galileo (1G) created booking on operating flight SAS (SK) ground handler(XX) using a 3rd
party DCS.
RCI+SK:123EF+1G:345ABC+XX:7890:C '
3. Delta is the operating carrier and the PNR was created on 24 February 2010 at 2230 GMT.
RCI+DL:ABC456789::240210:2230'
4. CX is the operating carrier and no PNR was received from the reservation system at a station handled by a
ground handler; therefore the CX reservation PNR locator is not available and “DCS reference” is the
Reservation Control Type.
RCI+CX:89QM3LABML:C’

45
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.18 REF: REFERENCE INFORMATION (PNRGOV)

Function: To specify an association between references given to travellers, to products, to services.

Push PNR Data to States - PNRGOV

Composite/Data Element No. Field Comm. Stat. Max Code Comments

Type Usage Rep. Set
REFERENCING DETAILS C653 - - -- C 99 -
Reference Qualifier 1153 an..3 -- N/A 1 --
Reference Number 1154 an..35 an..25 C 1 - Unique passenger identifier assigned for
communications with one or more
States

Example:
1. The unique passenger reference identifier is 4928506894.
REF+:4928506894'

5.19 RPI: RELATED PRODUCT INFORMATION (PNRGOV)

Function: To indicate quantity and action required in relation to a product.

Push PNR Data to States - PNRGOV

Composite/Data Element No. Field Comm. Stat. Max Code Comments

Type Usage Rep. Set
QUANTITY 6060 n..15 n..3 C 1 - - Number of passengers associated with
the TVL segment.
STATUS, CODED 4405 an..3 an..3 C 10 - - A4A/IATA action/advice/status code
for this TVL segment, see AIRIMP
Section 7, SIPP 105.170.1.1 .

Example:
1. Flight booking status is holds confirmed for 3 passengers.
RPI+3+HK'

46
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.20 SAC: SOURCE AND ACTION INFORMATION (PNRGOV)

Function: To specify information concerning the source and action to be taken.

Push PNR Data to States - PNRGOV

Composite/Data Element No. Field Comm. Stat. Max Code Comments

Type Usage Rep. Set
STATUS INDICATOR, 1245 an..3 -- N/A 1 --
CODED
PLACE/LOCATION 3225 an..25 -- N/A 1 --
IDENTIFICATION
STATUS, CODED 4405 an..3 an..3 M* 1 Yes Specifies the status (action) taken on the
history item, such as add, cancel, etc.

Notes:
1. Used in conjunction with other segments where the item was actioned. Eg Name Change, flight etc
2. Flown segments are to be included in history.

Examples:
1. The history line contains a cancelled item
SAC+++X'
2. The history line contains an added item
SAC+++A’

47
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.21 SRC: SEGMENT REPETITION CONTROL (PNRGOV)

Function: To indicate the number of segment group repetitions.

Push PNR Data to States - PNRGOV

Composite/Data Element No. Field Comm. Stat. Max Code Comments

Type Usage Rep. Set
SEGMENT REPETITION C678 - - -- N/A 9 --
CONTROL DETAILS
Quantity 6060 n..15 -- N/A 1 --
Number of Units 6350 n..15 -- N/A 1 --
Total number of items 7240 n..15 -- N/A 1 --

Note:
1. Used as trigger segment for PNRGOV GR.1 and will repeat for each PNR in the message.

Example:
1. This trigger segment is sent as an empty segment.
SRC'

48
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.22 SSD: SEAT SELECTION DETAILS (PNRGOV)

Function: To specify details concerning seat selection and the associated security and processing information.

Push PNR Data to States - PNRGOV

Composite/Data Element No.

Field Comm. Stat. Max Code Comments
Type Usage Rep. Set
SPECIFIC SEAT DETAILS C679 - - -- C 1 --
Specific seat 9809 an..4 an..4 C 99 - - The seat number that the passenger has
been assigned.
NO SMOKING INDICATOR 9807 a1 -- N/A 1 --
SEAT CHARACTERISTIC C680 - - C N/A 1 --
DETAILS
Seat characteristics 9825 an..2 -- N/A 99 --
SEAT RANGE DETAILS C681 - - C N/A 1 --
Seat row number 9830 n..3 -- N/A 1 --
Range maximum 6152 n..18 -- N/A 1 --
Seat column 9831 an1 -- N/A 20 --
CABIN CLASS 9854 a1 a1 C 1 Used to specify the cabin class
DESIGNATOR
CABIN CLASS OF SERVICE 9873 n1 -- N/A 1 --
FREE TEXT 4440 an..25 -- N/A 1 --
5
PLACE/LOCATION 3225 an..25 -- N/A 1 --
IDENTIFICATION
PLACE/LOCATION 3225 an..25 -- N/A 1 --
IDENTIFICATION
PROCESSING INDICATOR 7365 an..3 -- N/A 1 --
SECURITY C682 - - -- N/A 1 --
IDENTIFICATION DETAILS
Security identification 9751 an..5 -- N/A 2 --
PROCESSING INDICATOR 7365 an..3 -- N/A 1 --
SPECIFIC SEAT PURPOSE C683 - - -- N/A 99 --
Item characteristic 7081 an..3 -- N/A 1 --
Specific seat 9809 an..4 -- N/A 1 --

Note:
1. 9854 uses individual airlines cabin class designator and not a codeset

Example:
1. The passenger has been assigned seat 24A in coach.
SSD+24A++++Y’

49
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.23 SSR: SPECIAL REQUIREMENTS DETAILS (PNRGOV)

Function: To specify special requests or services information relating to a traveller.

Push PNR Data to States - PNRGOV

Composite/Data Element No. Field Comm. Stat. Max Code Comments

Type Usage Rep. Set
SPECIAL REQUIREMENT C334 - - -- M 1 --
TYPE DETAILS
Special Requirement Type 9962 an..4 an..4 M 1 Yes Specifies the type of special request
(seat, unaccompanied minor, boarding
pass, etc.).
Status, coded 4405 an..3 an..3- C 1 Yes- Status or action for this SSR, e.g. HK,
NN
Quantity 6060 n..15 n..3 C 1 - - Number of services requested or
processed.
Company Identification 9906 an..35 an..3 C 1 Yes 2-3 character airline/CRS code
identifying system to which special
request is directed.
Processing Indicator 7365 an..3 -- N/A 1 --
Processing Indicator 7365 an..3 -- N/A 1 --
Place/Location Identification 3225 an..25 a3..5 C 1 Yes Board city of segment to which special
service request applies.
Place/Location Identification 3225 an..25 a3..5 C 1 Yes Off city of segment to which special
service request applies.
Free Text 4440 an..25 an..255 C 999 - - Literal text related to the special service
5 request.
SPECIAL REQUIREMENT C332 - - -- C 999 --
DATA DETAILS
Special Requirement Data 9960 an..4 an..4 C 1 -- Identifies specific information ( age of
unaccompanied minor, seat number,
etc.).
Measure Unit Qualifier 6411 an..3 an..3 C 1 Yes Qualifies 9960 (i.e., years).
Traveller Reference Number 9944 an..10 n..3 C 1 - - Specifies for which traveller in the TIF
segment the special service applies.
Seat Characteristic, coded 9825 an..2 an..2 C 5 Yes Characteristic of a seat specified in
9960, or for a generic seat assignment
(not associated to a particular seat).

Notes:
1. SSR’s in GR.1 apply to all flights and may apply to all passengers or may apply to specific passenger based on
the traveler reference number in SSR/9944 and TIF/9944.
2. SSR’s in GR.2 apply to the specific passenger.
3. SSR’s in GR.5 (per TVL) apply to a specific flight and may apply to all passengers or may apply to a specific
passenger based on the traveler reference number in SSR/9944 and TIF/9944.
4. The Traveler Reference Number (9944) in the SSR segment in Gr.1 or Gr. 5 may be used to specify for which
passenger this SSR applies. This is a reference number assigned by the sending system and should contain the
same reference number as that found in the Traveler Reference number in the TIF in Gr.2.

Examples:
1. One passenger is an SSR type unaccompanied minor.
SSR+UMNR'
2. Passenger number 2 has requested to transport a bike on a DL flight.

50
 PADIS EDIFACT Implementation Guide – PNRGOV Message

SSR+BIKE:HK:1:DL+::2’
3. Passenger has been assigned seat 53C on the AA flight from AMS to JFK.
SSR+SEAT:HK:1:AA:::AMS:JFK+53C::2:N’
4. DOCS information for a passenger on KL.
SSR+DOCS:HK:1:KL::::://///05AUG70/F//STRIND/BENITA+::2’
5. Other information about passenger one.
SSR+OTHS:HK::AF:::::CORP//***CORPORATE PSGR***+::1'
6. A passenger by the name of Mr. John Meeks supplies a United States Redress number for his PNR:
a. For those systems using automated format:
SSR+DOCO:HK:1:AA:::JFK:LAX:0001Y28JUN//R/1234567890123///US

b. For those systems using non-automated format:

SSR+DOCO:HK:1:AA::::://R/1234567890123///US
7. Passenger has been assigned seat 22C on the PY flight from AUA to PBM.
SSR+SEAT:HK:1:PY:::AUA:PBM:NOTICKET/TOM+22C’
8. Passenger is an infant traveling with an adult on PY flight from PBM to MIA and the date of birth is 12Jul09.
SSR+INFT:HK:1:PY:::PBM:MIA:INFANT/BABY 12JUL09’
9. A bassinet has been confirmed for the PY flight from MIA to PBM.
SSR+BSCT:HK:1:PY:::MIA:PBM’
10. Passenger has requested a generic seat on the AA flight from DCA to MIA.
SSR+NSSA:NN:1:AA:::DCA:MIA:MADDOX/MOLLY’
11. Passenger traveling with a British passport and 1st and 2nd given names in separate fields:
SSR+DOCS:HK::DL:::::/P/GBR/123456789/GBR/12JUL64/M/23AUG19/SMITHJR/JONATHON/ROBERT’
12. Passenger traveling with a British passport and 1st and 2nd given names in same field:
SSR+DOCS:HK::DL:::::/P/GBR/987654321/GBR/12JUL15/M/15JAN13/COOPER/GARYWILLIAM’
13. Passenger traveling with a British passport and 1st and 2nd given names in same field:
SSR+DOCS:HK::DL:::::/P/GBR/123456789/GBR/12JUL12/M/23AUG15/WAYNE/JOHNALVA’

51
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.24 TBD: TRAVELER BAGGAGE DETAILS/Electronic Ticketing (PNRGOV)

Function: To specify the baggage details, including number of bags and serial numbers.

Push PNR Data to States - PNRGOV

Composite/Data Element No. Field Comm. Stat. Max Code Comments

Type Usage Rep. Set
STATUS, CODED 4405 an..3 -- N/A 1 --
BAGGAGE DETAILS C675 -- -- C 1 - - Checked baggage information
Quantity 6060 n..15 n..3 C 1 - - Number of pieces
Measurement and value 6314 n..18 n..4 C 1 Weight of checked baggage
Allowance or charge qualifier 5463 an..3 an..3 C 1 Yes Kilograms or pounds
Measure unit qualifier 6411 an..3 -- N/A 1 --
Processing indicator, coded 7365 an..3 -- N/A 1 --
BAGGAGE DETAILS C675 -- -- N/A 1 --
Quantity 6060 n..15 -- N/A 1 --
Measurement and value 6314 n..18 -- N/A 1
Allowance or charge qualifier 5463 an..3 -- N/A 1 --
Measure unit qualifier 6411 an..3 -- N/A 1 --
Processing indicator, coded 7365 an..3 -- N/A 1 --
BAGGAGE REFERENCE C686 -- -- C 1 --
DETAILS
Processing indicator, coded 7365 an..3 a2 C 1 Yes Pooled checked bag indicator
Identify number 7402 an..35 an..14 C 1 -- Baggage pool reference
BAGTAG DETAILS C358 -- -- C 99 --
Company identification 9906 an..35 an..3 C 1 -- Airline designator
Item number 7140 an..35 n..10 M* 1 -- Bag license plate
Total number of items 7240 n..15 n..3 C 1 -- Number of consecutive tags serial
numbers
Place/location identifier 3225 an..25 an..5 C 1 - - Place of destination
Company identification 9996 n..15 n3 C 1 - - Bag Tag Issuer’s Code (numeric code)
number as contained in the IATA Airline
Coding Directory.
Data indicator 9988 an..3 an..3 C 1 Yes To specify if online or interline
Item characteristic, coded 7081 an..3 a2 C 1 Yes Indicates manual, auto or limited
release bag tag
Special service requirement 9962 an..4 -- N/A 1 --
type
Measurement value 6314 n..18 -- N/A 1 --
Measure unit qualifier 6411 an..3 -- N/A 1 --
Free text 4440 an..25 -- N/A 1 --
5
Note:
1. This segment is for the checked in baggage and not for excess bag details

Examples:
1. Bag pool members with Head of Pool ticket.
TBD++++MP:0741234123456’
2. 3 bags, weight 84 kilos, Head of Pool, tags 4074902824, 3 in sequence to MSP.
TBD++3:84:700++HP+KL:4074902824:3:MSP’
3. Total 5 bags, weight 155 pounds, 2 checked to MSP, 3 short checked to JFK
TBD++5:155:701+++KL:8074902824:2:MSP+KL:8074902826:3:JFK’

52
 PADIS EDIFACT Implementation Guide – PNRGOV Message

4. Total 2 bags, weight 20 kilos, head of pool, 2 bags in sequence to CPH with the carrier code of the airline
issuing the bag tags.
TBD++2:20:700++HP:5+LH:3020523456:2:CPH:220’
5. 2 bags, QF tag 00081111111 to Sydney
TBD++2+++QF:0081111111:2:SYD’
6. 1 bag, no weight provided
TBD++1+++UA:4016722105:1:DOH’

53
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.25 TIF: TRAVELLER INFORMATION (PNRGOV)

Function: To specify a traveller(s) and personal details relating to the traveller(s).

Push PNR Data to States - PNRGOV

Composite/Data Element No.

Field Comm. Stat. Max Code Comments
Type Usage Rep. Set
TRAVELLER SURNAME C322 - - -- M 1 --
INFORMATION
Traveller Surname 9936 an..70 a..70 M 1 - - Specifies passenger surname.
Number of Units Qualifier 6353 an..3 an..3 C 1 Yes Indicates name qualifier, i.e. group
name and same family name, etc.
Quantity 6060 n..15 -- N/A 1 --
Status, coded 4405 an..3 -- N/A 1 --
TRAVELLER DETAILS C324 - - -- C 99 --
Traveller Given Name 9942 an..70 a..70 C 1 - - Specifies passenger given name and
title.
Number of Units Qualifier 6353 an..3 an..3 C 1 Yes Specifies passenger type (adult,
frequent traveller, infant, etc.).
Traveller Reference Number 9944 an..10 an..10 C 1 - - Direct reference of passenger assigned
by requesting system. Used as a cross
reference between data segments. In
GR2 must be unique per passenger
within the PNR.
Traveller Accompanied by 9946 an1 an1 C 1 Yes Adult passenger is accompanied by an
Infant Indicator infant without a seat.
Other names 9754 an..70 -- C 2 --

Notes:
1. Only one surname and given name should be sent in one occurrence of the TIF even if there are multiple names
for a surname in the PNR.
2. The Traveller Reference Number (9944) is assigned by the sending system and this number in Gr.2 may be used
to cross reference an SSR in Gr.1 or Gr.5 or a TRI in Gr.7.

Examples:
1. Passenger Jones/John Mr is an adult.
TIF+JONES+JOHNMR:A'
2. Passenger has a single letter family name – Miss Moan Y – single letter is doubled where MoanMiss was
considered the given name. This rule is as defined in AIRIMP rules and its examples.
TIF+YY+MOANMISS:A’
3. Adult passenger has a single letter family name – Miss Tuyetmai Van A – all given names are combined with the
single letter surname where Miss was considered the given name. This rule is as defined in AIRIMP rules and
its examples.
TIF+ATUYETMAIVAN+MISS:A’
4. The PNR is for a group booking with no individual names.
TIF+SEETHE WORLD:G’
5. Infant no seat Passenger
TIF+RUITER+MISTY:IN’

54
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.26 TKT: TICKET NUMBER DETAILS (PNRGOV)

Function: To convey information related to a specific ticket.

Push PNR Data to States - PNRGOV

Composite/Data Element No.

Field Comm. Stat. Max Code Comments
Type Usage Rep. Set
TICKET NUMBER DETAILS C667 - - -- M 1 --
Document/message number 1004 an..35 an..14 C 1 - - Ticket document number
Document/ message name, 1001 an..3 an..3 C 1 Yes Document type
coded “1” for ticketless
Total number of items 7240 n..15 n..2 C 1 - - Total number of booklets issued
Data Indicator 9988 an..3 an..3 C 1 Yes To specify if in connection with ticket
number.
Action request/notification, 1229 an..3 -- N/A 1 --
coded
Document/message number 1004 an..35 an..14 C 1 - - In connection with document number
may be an EMD
Document/message name, 1001 an..3 an..3 C 1 Yes In connection document type
coded
STATUS, CODED 4405 an..3 -- N/A 1 --

Examples:
1. The ticket number for a passenger
TKT+0062230534212:T'
2. Conjunctive ticket – 2 booklets
TKT+0271420067693:T:2'
3. A Ticketless passenger
TKT+:1’
4. An ET which has an EMD-A associated to it
TKT+0062145645678:T:1:4::0061509876543:J’
5. An ET which has an EMD-S in connection document
TKT+0062145645678:T:1:4::0061506543210:Y’

55
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.27 TRA: Transport Identifier

Function: To specify transport service(s) or to specify transport service(s) which is/are to be updated or cancelled.

Push PNR Data to States - PNRGOV

Composite/Data Element No. Field Comm. Stat. Max Code Comments

Type Usage Rep. Set
COMPANY IDENTIFICATION C306 -- -- M 1 --
Company Identification 9906 an..35 an..3 C 1 Yes A 2-3 character code to specify the
operating airline designator code when
different from the marketing airline.
Company Identification 9906 an..35 -- N/A -- --
Company Identification 9006 an..35 -- N/A -- --
PRODUCT IDENTIFICATION C308 -- -- C 1 --
DETAILS
Production Identification 9908 an..35 an..4 C 1 -- The operating flight number
Characteristic Identification 7037 an..17 a1 C 1 -- Operating reservations booking designator
Product Identification 9914 an..3 a1 C 1 -- An operational suffix related to flight number
Characteristic
Item Description Identification 7009 an..7 -- N/A -- --

Example:

1. Flight number 123 operated by Delta

TRA+DL+123:Y”

2. Gr.5 portion of the message

TVL+121210:0915::1230+LHR+JFK+DL+324:B'
TRA+KL+8734:B’ Operating carrier information
RPI+2+HK’
APD+767’
SSR+SEAT:HK:2:DL:::LHR:JFK+15A::1+15B::2’
DAT+2:111210:0915’
TRI++108:::1’
TIF+SMITHJR+JOHNMR:A:1’
SSD+15A++++Y’
TVL+121210:2200::2330+JFK+YVR+DL+330:B'
RPI+2+HK’
APD+767’
SSR+SEAT:HK:2:DL:::JFK:YVR+15E::1+15F::2’

56
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.28 TRI: TRAVELLER REFERENCE INFORMATION (PNRGOV)

Function: To specify information regarding a traveller or traveller account .

Push PNR Data to States - PNRGOV

Composite/Data Element No. Field Comm. Stat. Max Code Comments

Type Usage Rep. Set
REFERENCE C670 - - -- N/A 1 --
QUALIFICATION
Identity number qualifier 7405 an..3 -- N/A 1 --
Reference Qualifier 1153 an..3 -- N/A 1 --
TRAVELLER C671 - - -- C 999 --
IDENTIFICATION
Reference Number 1154 an..35 an..35 C 1 -- The sequence/boarding number for this
flight for a passenger.
Reference Qualifier 1153 an..3 -- N/A 1 --
Specific Seat 9809 an..4 -- N/A 1 --
Traveller Reference Number 9944 an..10 n..3 C 1 -- Used to indicate which passenger is
being checked in and refers to the 9944
assigned in the TIF in GR2 level 2.

Notes:
1. The Traveler Reference Number (9944) in the TRI segment in Gr.7 may be used to specify for which passenger
the check-in information applies so that the TIF in this group does not need to be sent. This is a reference
number assigned by the sending system and should contain the same reference number as that found in the
Traveler Reference number in the TIF in Gr.2.
2. Each occurrence of the TRI handles only one passenger (i.e. one surname and one given name) at a time, thus
the Composite C671 does not repeat

Example:

1. The sequence number for this passenger is 108.

TRI++108'
2. The sequence number for passenger, which has reference number 4, is 220.
TRI++220:::4'
3. The sequence number for passenger, which has reference number 10, is JFK-058.
TRI++JFK-058:::10'
4. No sequence number for the passenger, which has reference number 11.
TRI++:::11'

57
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.29 TVL: TRAVEL PRODUCT INFORMATION (PNRGOV)

Function: To specify details related to a product.

5.29.1 Flight Details for Passenger data sent

TVL at Level 0

Push PNR Data to States - PNRGOV

PNRGOV Adhoc Request - GOVREQ

Composite/Data Element No. Field Comm. Stat. Max Code Comments

Type Usage Rep. Set
PRODUCT DATE/TIME C310 - - -- M* 1 --
First Date 9916 an..35 n6 M* 1 -- Departure date (ddmmyy)
First Time 9918 n..4 n4 M* 1 -- Departure time (hhmm)
Second Date 9920 an..35 n6 M* 1 -- Arrival date (ddmmyy)
Second Time 9922 n..4 n4 M* 1 -- Arrival time (hhmm)
Date Variation 9954 n1 n1 C 1 -- Variance between departure and arrival
date.
LOCATION C328 - - -- M* 1 --
Place/Location Identification 3225 an..25 a3..5 M* 1 Yes A 3 character code to specify the last
IATA airport / city code of departure
prior to crossing the border
For multi-leg flights, please see note 3
Place/Location Name 3224 an..17 - - N/A 1 --
LOCATION C328 - - -- M* 1 --
Place/Location 3225 an..25 a3..5 M* 1 Yes A 3 character code to specify the first
IATA airport / city code of arrival after
crossing the border.
For multi-leg flights, please see note 3
Place/Location Name 3224 an..17 - - N/A 1 --
COMPANY IDENTIFICATION C306 - - -- M* 1 --
Company Identification 9906 an..35 an..3 M* 1 Yes A 2-3 character code to specify the
operating airline designator code.
Company Identification 9906 an..35 an..3 N/A 1 --
Company Identification 9906 an..35 - - N/A 1 --
PRODUCT IDENTIFICATION C308 - - -- M* 1 --
DETAILS
Product Identification 9908 an..35 n..4 M 1 -- Flight number
Characteristic Identification 7037 an..17 - - N/A 1 --
Product Identification 9914 an..3 a1 C 1 -- An operational suffix related to flight
Characteristic number.
Item Description Identification 7009 an..7 -- N/A 3 --
PRODUCT TYPE DETAILS C309 -- -- N/A 1 --
Sequence Number 1050 an..6 -- N/A 9 --
LINE ITEM NUMBER 1082 n..6 -- N/A 1 --
PROCESSING INDICATOR, 7365 an..3 -- N/A 1 --
CODED
MARRIAGE CONTROL C311 -- -- N/A 99 --
DETAILS
Relation, coded 5479 an..3 -- N/A 1 --
Group number 9995 n..10 -- N/A 1 --
Line item number 1082 n..6 -- N/A 1 --
Relation, coded 5479 an..3 -- N/A 1 --
Company identification 9906 an..35 -- N/A 1 --

58
 PADIS EDIFACT Implementation Guide – PNRGOV Message

Note:
1. Dates and times in the TVL are in Local Time.
2. Departure and arrival points of the transborder segment for a given country are the ones of the leg which makes
the segment eligible for push to a given country.
3. For multi-leg flights, States may where technically possible, and under bilateral agreement with system providers
& carriers, request that pushes of PNRGOV messages may be sent from each Board Point NOT just the trans-
border leg.
 The TVL at Level Zero may include the Board Point and off point for the relevant push, instead of the trans-
border leg.
 Due to technical limitations, system providers & carriers may or may not be able to set the First Date [9916]
& First Time [9918] in respect of the local time at each Board point, and consequently may only reflect the
timings at the trans-border leg.
4.

Examples:
1. The passenger information being sent is for Delta flight 10 from ATL to LHR on 30MAR which departs at 5:00
pm.
TVL+300310:1700:310310:0500+ATL+LHR+DL+10’
2. The passenger information being sent is for Delta flight 9375 from ATL to AMS on 24 FEB which departs at
9:35 pm.
TVL+240210:2135:250210:10:55+ATL+AMS+DL+9375’
3. This example is only concerned with the push to Canada. While the US will also have a push, the US is not
demonstrated in this example. CX888 is a multileg flight with the following routing and times,
HKG 10May 0100 YVR 09May 2030
YVR 09May 2230 JFK 10May 0420
The leg eligible for Canada is HKG YVR. The passenger information to push are for CX888 from HKG YVR
(terminate YVR Canada) and HKG to JFK (transit YVR Canada). The push will occur at Scheduled Departure
Time out of HKG.
For the flight departing on 10th May at 0100 (Local Time) from HKG and arriving at YVR at 2030 on 09May,
the following segment TVL in PNRGOV level 0 will be sent:
TVL+100512:0100:090512:2030+HKG+YVR+CX+888

59
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.29.2 Flight Itinerary

TVL in Gr5 at Level 2 and Gr.12 at Level 4

Push PNR Data to States - PNRGOV

Composite/Data Element No. Field Comm. Stat. Max Code Comments

Type Usage Rep. Set
PRODUCT DATE/TIME C310 -- -- C 1 --
First Date 9916 an..35 n6 C 1 - - Departure date (ddmmyy)
First Time 9918 n..4 n4 C 1 - - Departure time (hhmm)
Second Date 9920 an..35 n6 C 1 - - Arrival date (ddmmyy)
Second Time 9922 n..4 n4 C 1 - - Arrival time (hhmm)
Date Variation 9954 n1 n1 C 1 - - Variance between departure and arrival date.
LOCATION C328 -- -- C 1 --
Place/Location Identification 3225 an..25 a3..5 M* 1 Yes A 3 character code to specify place of
departure.
Place/Location Name 3224 an..17 -- N/A 1 --
LOCATION C328 -- -- C 1 --
Place/Location 3225 an..25 a3..5 M* 1 Yes A 3 character code to specify place of arrival.
Place/Location Name 3224 an..17 -- N/A 1 --
COMPANY C306 -- -- C 1 --
IDENTIFICATION
Company Identification 9906 an..35 an..3 M* 1 Yes A 2-3 character code to specify the marketing
airline designator code.
Company Identification 9906 an..35 an..3 C 1 Yes A 2-3 character code to specify the operating
airline designator code when different from
the marketing airline.
Company Identification 9906 an..35 -- N/A 1 --
PRODUCT C308 - - -- M* 1 --
IDENTIFICATION
DETAILS
Product Identification 9908 an..35 an..4 M 1 -- Marketing flight number or ARNK or OPEN
Characteristic Identification 7037 an..17 a1 C 1 -- Marketing reservations booking designator
Product Identification 9914 an..3 a1 C 1 -- An operational suffix related to flight number.
Characteristic
Item Description 7009 an..7 -- N/A 3 --
Identification
PRODUCT TYPE DETAILS C309 - - -- N/A 1 --
Sequence Number 1050 an..6 -- N/A 9 --
LINE ITEM NUMBER 1082 n..6 -- N/A 1 --
PROCESSING INDICATOR, 7365 an..3 -- N/A 1 --
CODED
MARRIAGE CONTROL C311 -- -- N/A 99 --
DETAILS
Relation, coded 5479 an..3 -- N/A 1 --
Group number 9995 n..10 -- N/A 1 --
Line item number 1082 n..6 -- N/A 1 --
Relation, coded 5479 an..3 -- N/A 1 --
Company identification 9906 an..35 -- N/A 1 --

60
 PADIS EDIFACT Implementation Guide – PNRGOV Message

Notes:
1. Dates and times in the TVL are in Local Time.

2. For OPEN and ARNK segments, the date, place of departure and place of arrival are conditional. For an
Airline/ Flight Number / class/ date / segment, the date, place of departure and place of arrival are mandatory.

3. Flown segments are to be included in history.

4. Departure and arrival city/airport codes are the ones in the passenger’s itinerary. There may be non-IATA codes
such as heliports.
Segments may include non-air destinations for example a train station and included in TVL at Group 9 Level 3

Examples:
1. The flight segment in the passenger’s itinerary is Delta flight 10 from ATL to LHR on April 1 which departs at
10:35 p.m. and arrives at noon and the reservation booking designator is K. The operating carrier is KL.
TVL+010410:2235:020410:1200+ATL+LHR+DL:KL+10:K’
2. An ARNK segment is used to fill a gap in the itinerary.
TVL+++++ARNK’
3. An OPEN segment is used where the passenger has purchased a ticket between two cities/airports but does not
know the flight number or date.
TVL++LHR+ORD++OPEN’
4. An OPEN segment is used where the passenger has purchased a ticket between two cities/airports and knows the
airline on which he will fly but not the flight number or date.
TVL++LAX+SIN+SQ+OPEN’
5. This example is only concerned with the push to Canada. While the US will also have a push, the US is not
demonstrated in this example.
CX888 is a multileg flight with the following routing and times:
HKG 10May 0100 YVR 09May 2030
YVR 09May 2230 JFK 10May 0420
The leg eligible for Canada is HKG YVR. The passenger information to push are for CX888 from HKG YVR
(terminate YVR Canada) and HKG to JFK (transit YVR Canada). The push will occur at Scheduled Departure
Time out of HKG.
For the flight departing on 10th May at 0100 (Local Time) from HKG and arriving at YVR at 2030 on 09May,
the following segment TVL in PNRGOV will be sent:
Level 0 - TVL+100512:0100:090512:2030+HKG+YVR+CX+888
Grp 5 level 2 for HKG YVR passengers - TVL+100512:0100:090512:2030+HKG+YVR+CX+888
Grp 5 level 2 for HKG JFK passengers - TVL+100512:0100:100512:0420+HKG+JFK+CX+888

61
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.29.3 Codeshare information

Versions of PNRGOV prior to 14.1 indicated the use of a second TVL segment in group 5 for the specification of code-
share flight information. Implementations of PNRGOV version 13.1 and later should instead use the TRA segment for
code-share details (see section 5.27). If the TRA segment is used for operating carrier information, the TVL segment
should not be used to convey this information.

Systems upgrading from earlier versions should discontinue use of a second TVL in favor of the TRA segment.

62
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.29.4 Non Air Segments

TVL in GR.9 at level 3 and Gr.12 at Level 4 is used to carry non-air segments (car, hotel, rail, etc.)

Push PNR Data to States - PNRGOV

Composite/Data Element No. Field Comm. Stat. Max Code Comments

Type Usage Rep. Set
PRODUCT DATE/TIME C310 - - -- M* 1 --
First Date 9916 an..35 n6 M* 1 - - The starting date of the utilization of the
service/product, e.g. check-in date, pickup date,
First Time 9918 n..4 n4 C 1 - - The starting time of the utilization of the
service/product, e.g. check-in time, pickup time
(hhmm)
Second Date 9920 an..35 n6 C 1 - - The ending date of the utilization of the
service/product, e.g. check-out date, drop-off date.
Second Time 9922 n..4 n4 C 1 - - The ending time of the utilization of the
service/product, e.g. check-out time, drop-off time
(hhmm)
Date Variation 9954 n1 -- N/A 1 --
LOCATION C328 - - -- C 1 --
Place/Location Identification 3225 an..25 a3..5 M* 1 Yes A 3 character code where utilization of the
service/product commences, e.g. location of the
hotel or rental car company..
Place/Location Name 3224 an..17 -- N/A 1 --
LOCATION C328 - - -- C 1 --
Place/Location 3225 an..25 a3..5 M* 1 Yes A 3 character code where utilization of the
service/product terminates if different from the
first location, e.g. drop-off location
Place/Location Name 3224 an..17 -- N/A 1 --
COMPANY C306 - - -- C 1 --
IDENTIFICATION
Company Identification 9906 an..35 an..3 M* 1 Yes Indicates the code of the provider of the
service/product, e.g. HH, ZE
Company Identification 9906 an..35 an..35 C 1 - - May contain the hotel name
Company Identification 9906 an..35 -- N/A 1 --
PRODUCT C308 - - -- M* 1 --
IDENTIFICATION
DETAILS
Product Identification 9908 an..35 an..10 M 1 -- A code identifying the location or other
mechanism used by a vendor to offer
services/products for sale, e.g. hotel property id
Characteristic Identification 7037 an..17 an..17 C 1 -- The classes related to the service/product, e.g.
hotel room type, car type
Product Identification 9914 an..3 -- N/A 1 --
Characteristic
Item Description Identification 7009 an..7 -- N/A 3 --
PRODUCT TYPE DETAILS C309 - - -- N/A 1 --
Sequence Number 1050 an..6 an..2 C 9 Yes Characteristics of air and non air segment (air, car
and hotel)
LINE ITEM NUMBER 1082 n..6 -- N/A 1 --
PROCESSING INDICATOR, 7365 an..3 -- N/A 1 --
CODED
MARRIAGE CONTROL C311 -- -- N/A 99 --
DETAILS
Relation, coded 5479 an..3 -- N/A 1 --
Group number 9995 n..10 -- N/A 1 --
Line item number 1082 n..6 -- N/A 1 --
63
 PADIS EDIFACT Implementation Guide – PNRGOV Message

Relation, coded 5479 an..3 -- N/A 1 --

Company identification 9906 an..35 -- N/A 1 --

Notes:
1. Element 1050 is required for non air segments such as Car Rental (CR) and Hotel Booking (HT).

Examples:
1. Car segment.
TVL+290110:1050:310110:0900+ATL++ZE+:FCAR’
2. Hotel segment.

TVL+060514:0000:080514:0000+YYZ++OM:THE OMNI KING EDWARD HOTEL+HOTEL:S1KPKX'

3. History car rental reservation (addition or cancellation).
GR12 Level 4 Hotel TVL segment
TVL+290110:1050:310110:0900+ATL++ZE+:FCAR+:CR’
4. History hotel reservation (addition or cancellation) at the HOTEL LE CRYSTAL MONTREAL.
GR12 Level 4 Hotel TVL segment
TVL+060514:0000:080514:0000+YUL++OM:HOTEL LE CRYSTAL MONTREAL+HOTEL:S1KPKX+:HT'

64
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5.30 TXD: TAX DETAILS (PNRGOV)

Function: To specify all details related to taxes

Push PNR Data to States - PNRGOV

Composite/Data No. Field Comm. Stat. Max Code Comments

Element Type Usage Rep. Set
DUTY/TAX/FEE 5305 an..3 an..3 C 1 -- Special tax indicator
CATEGORY,
CODED
TAX DETAILS C668 -- -- C 99 --
Duty/Tax/Fee rate 5278 an..17 n..17 C 1 -- Tax Amount.
Country, coded 3207 an..3 an..3 C 1 Yes ISO code identifying
country.
Currency, coded 6345 an..3 an..3 C 1 Yes ISO code identifying
currency.
Duty/Tax/Fee type, 5153 an..3 an..3 C 1 Yes Tax designator code to
Coded specify individual
taxes of a group.
Duty/tax/fee rate 5278 an..17 an..11 C 1 Tax filed amount
Currency, coded 6345 an..3 an..3 C 1 Yes Tax filed ISO currency
code
Duty/Tax/Fee type, 5153 an..3 an..3 C 1 Yes Tax filed type code
Coded
Monetary amount 5004 an..18 an..3 C 1 -- Filed conversion rate
Monetary function, 5007 an..3 an..3 C 2 Yes Tax qualifier
coded

Notes:
1. The tax code and country code should be in data elements 5153 and 3207 respectively.

Examples:
1. Tax details for departure taxes for Great Britain.
TXD++5:GB::9'
2. Tax information related to the given fare.
TXD++6.27::USD'

65
 PADIS EDIFACT Implementation Guide – PNRGOV Message

6 CODE SETS

For all codesets utilized in the PNRGOV message, please refer to the PADIS EDIFACT AND XML Code set
Directory available on the PADIS Extranet

This document will not contain any codeset breakdown to ensure that all relevant codes available now and in the future
are available for use should they be required. This will ensure that no codeset is presented incorrectly in this document.

If additional codes are required, they should be submitted to the PADIS Working Group for approval prior to being
submitted to a PADIS Board vote for inclusion in the standards.

66
PADIS EDIFACT Implementation Guide – PNRGOV Message

67
 PADIS EDIFACT Implementation Guide – PNRGOV Message

7 ADDITIONAL IMPLEMENTATION GUIDELINES

7.1 Types of Push and PNR Cancellations

The control of which type of push is used between a government and a given carrier is defined in the bilateral agreement
between that government and that carrier. In these paragraphs, the term cancellation refers to either the pushed flight
being cancelled from the PNR itinerary or the entire PNR being cancelled.

7.1.1 Full PNR Push (PNRGOV)

Under this concept, a full PNR Push is used to send all active PNRs to the government each time a push is required from
that government. In all cases, PNRs no longer containing the pushed flight segment are omitted from subsequent pushes.
For a full push, the MSG on level 0 will contain 22 (Push PNR data to States) in C302/1225.

7.1.2 Update PNR Push (PNRGOV)

Under this concept, the initial push to a given government sends a full PNR Push as defined in paragraph 8.1.1.
Intermediate pushes may contain only those PNRs that have been modified, added to, or removed from the flight since the
previous push. The Update push will contain 141 (Update) in MSG C302/1225.
- If a PNR is included in a push, all PNR data is sent.
- For cancellations, only the SRC (empty), the RCI with the record locator information and an empty ORG are
included.

Example:

 PNR for passenger APPLE booked 7 days prior to departure

 PNR for passenger PEAR booked 2 months prior to departure
 PNR for passenger BANANA booked 1 month prior to departure
 PNR for passenger MINT booked 36 hours prior to departure.
 PNR for passenger ORANGE booked 2 weeks prior to departure and changed 50 hours and changed 20 hours prior
to departure.
 PNR for passenger LIME booked 10 days prior to departure and segment cancelled 18 hours prior to departure.
 PNR for passenger PINEAPPLE booked 12 days prior to departure and PNR cancelled 30 hours prior to departure
 A particular government requires five pushes. The above PNRs will be included as follows:
 72 hours prior to departure – APPLE, PEAR, BANANA, ORANGE, LIME, PINEAPPLE
 48 hours prior to departure - ORANGE
 24 hours prior to departure – MINT, PINEAPPLE (only SRC/RCI/ORG)
 12 hours prior to departure – ORANGE, LIME (only SRC/RCI/ORG)
 1 hour prior to departure – No PNRs sent.

For any push in which there are no PNRs, the EQN on level 0 contains a “0” in C523/6353.

7.1.3 Adhoc PNR Push (GOVREQ/PNRGOV)

The Adhoc push is used by bilateral agreement.

- If the Adhoc request is for an entire flight, a full push as defined in 7.1 above is sent. The MSG on level 0 of the
GOVREQ message will contain 43 (Flight report) in C302/1225. The MSG on level 0 of the PNRGOV message
will contain 22 (PNR Data to Government) in C302/1225.

- If the request is for a specific PNR locator, the MSG on level 0 of the GOVREQ message will contain 77 (Record
locator request) in C302/1225.

- All PNR data is sent for an active and relevant PNR. The MSG on level 0 of the PNRGOV message will contain
22 (PNR Data to Government) in C302/1225.
68
 PADIS EDIFACT Implementation Guide – PNRGOV Message

- If the PNR is not found or if the PNR itinerary is not relevant to the government (no active itinerary to or from the
requesting country), then ACKRES is returned with the appropriate ERC error code.

7.2 Error Handling

Acknowledgement of the receipt and/or processing of a PNRGOV or GOVREQ message by the destination application, if
bilaterally agreed, should be accomplished using a functional message whenever possible. The functional message may
be an ACKRES in response to a PNRGOV, or may be either an ACKRES or PNRGOV in response to a GOVREQ as is
explained in section 2 of this document. However, there may be business cases in which the PNRGOV or GOVREQ
message is not able to reach the destination application in a timely manner or at all. In these cases, it is appropriate to use
a CONTRL message to provide automated advice to the sender of that message regarding the status of processing.

The following table briefly summarizes the recommendations for acknowledgement of receipt and/or processing of a
message based on the standard PADIS interactive process. For more background and detailed recommendations, please
see the document entitled PADIS EDIFACT Message Processing - Background for PNRGOV Users.

Message Use Case Recommended Response Message

PNRGOV Successful Receipt & Processing ACKRES
PNRGOV or GOVREQ Successful Receipt, Functional Data Errors ACKRES with ERC
PNRGOV or GOVREQ Received containing syntax errors rendering it CONTRL
unable to parse
PNRGOV or GOVREQ Received with incorrect header information or CONTRL
unsupported message type or version
PNRGOV or GOVREQ Received, but destination application is not CONTRL
available
GOVREQ Successful Receipt & Processing – Response PNRGOV
returned immediately
GOVREQ Successful Receipt & Processing – response to ACKRES
follow

For details, refer to the Appendix C: PADIS EDIFACT Message Processing - Background for PNRGOV Users

7.3 Accommodation of PNR Data Exceeding Maximum Occurrences in Published Standards

The PNRGOV EDIFACT message structure and this Implementation Guide have been adapted to accommodate
transmission of each of the 19 PNR Data Elements defined in the PNRGOV Principles document. However there have
been production instances in which the volume of data in a single PNR has exceeded the limitations of the specification,
causing validation errors, rejected messages and even unexpected system behavior.

The following guidelines can minimize impact of cases in which the data elements themselves are within the standard, but
the number of occurrences exceeds the maximums.

When designing systems that will receive and/or process PNRGOV message data:

 Strict enforcement of maximum occurrences may result in sending systems having to truncate data in order to pass
validation. This creates a no-win situation in which:
o If the sending system truncates some of the data, the receiving system may not have any indication that the
truncation has occurred and will have no control over which data is truncated.

o If the sending system does not truncate and sends all of the available data, without regard to specified
maximum occurrences, the receiving system may reject the entire message as invalid, not processing any of
it.

 Consider following relational data modelling best practices. Avoid database and application designs that place
artificial or arbitrary limits on data relationships (e.g. PNRs per flight, passengers or flights per PNR, tickets per

69
 PADIS EDIFACT Implementation Guide – PNRGOV Message

passenger, etc.).

 Note that EDIFACT standards documents don’t make use of the concept of unbounded occurrences. Furthermore,
the maximum number of occurrences generally reflects a number of digits or order of magnitude, rather than a typical
functional limitation. For example C9 indicates [0..9] occurrences are allowed while M999 indicates [1..999]
occurrences are allowed. Maximum occurrence values such as C4 or M150 will not be used. Therefore maximum
occurrence values can only be used as a rough guideline in system and application design.

 Consider monitoring and reporting for instances in which maximum occurrences are exceeded, along with an
operating procedure and infrastructure that allows bilateral alteration of the maximums as appropriate. Follow up
with agenda items to the PNRGOV working group to adjust the limits in the next version of the specification.

 Consider not enforcing maximum occurrence limitations at the parsing and message validation step, as long as the
received message structure is otherwise parseable. Instead, determine which action is to be taken with occurrences
exceeding the maximum at time of processing:

o Store and/or process all structurally valid data received, even if it exceeds stated maximum occurrences.

o Only when necessary, truncate the least functionally relevant data, which may be the first occurrences, last
occurrences, or occurrences with specific characteristics.

If necessary to reject the data, reject only the PNRs exceeding the maximum occurrences in lieu of all PNRs in message.
Have a work-around procedure in place to deal directly with the sender regarding rejected PNR data.

7.4 Handling of SSR Data

Special Service Requests (SSRs) are used by airlines to track and communicate information regarding a
number of varied services. These services include but are not limited to: loyalty membership and status,
seating, special meals, infant or child passenger types, travel documents, ticket numbers, ancillary services,
etc. While any given system may store SSR details in its own way, IATA has standardized formats for
exchange of this information as it relates to PNRs. The primary source for documentation on standardized
SSRs is the A4A/IATA Reservations Interline Message Procedures – Passenger (AIRIMP) manual. AIRIMP
defines formatting rules for SSR data in Teletype (Type-B) messages and lists the standardized SSR codes,
also noting any special handling rules that may be applicable for any particular SSR.

7.4.1 Standardized SSR Construction

Generally, SSR construction falls into two categories: Automated Format and Non-Automated Format.
Automated Format SSRs pertain to individual flights and therefore contain flight data while Non-Automated
Format SSRs are not generally flight specific and generally do not contain structured flight data.
Example SSR in Automated Format: Passenger needs to carry a cello as cabin baggage on Spirit (NK) flight
123 in economy from FLL to CUN on 30 June 2014.
SSR CBBG NK NN1 FLLCUN0123Y30JUN.CELLO
Example SSR in Non-Automated Format: Passenger John Doe, traveling on USAirways (US) has an
associated Client ID ABC987XQ
SSR CLID US HK/ABC987XQ-1DOE/JOHN

In addition to their formats being either Automated or Non-Automated, SSRs may contain free text in one or
more positions. Furthermore, some or all of the free text may have specific formatting requirements. In the
following examples, the free text is underlined.
Example SSR having more than one Free Text area: MCO number 16023512345673 for $50 USD for
passenger Emma Morris
SSR MCOA CX HK1/16023512345673-MORRIS/EMMA.USD50
Example SSR having specific format requirements for free text: Advise of the issuance of an EMD for a
vegetarian meal.
SSR ASVC BA HS1 NCLLHR1321J30JUN.I/E23/VGML/VEGETARIAN MEAL/S/1251234567890C1

7.4.2 Placement of SSR Data in Structured Messaging Formats

70
 PADIS EDIFACT Implementation Guide – PNRGOV Message

PNRGOV messages do not use AIRIMP teletype formats to communicate SSR information, but rather use
structured data elements instead. EDIFACT uses an SSR segment and XML uses elements of common types
SpecialServiceRequestType and DOC_SpecialServiceRequestType. Each of the structured data types
contain specific fields which correspond to the general construction for the teletype format as defined in
AIRIMP 2.11.6 Construction of SSR.
Component EDIFACT XML Example
(a) Element Identifier SSR Segment Element
Identifier <SSR…>
(b) SSR Element Code C334, 9962 @SSRCode CBBG
(c) Airline or CRS Designator C334, 9906 <Airline @Code> NK
(d)5 Action/Status/Advice Code C334, 4405 @Status NN
(e)1 Number of services C334, 6060 @ServiceQuantity 1
(f)2 Departure Airport 3225 (1st) FLL
(g)2 Arrival Airport 3225 (2nd) CUN
(h)2 Flight number 0123
(i)2 RBD Y
(j)2 Date (of departure) 30JUN
(k)3,4 Associated Names C332, 9944 1DOE/JOHN
(l) Free Text C334, 4440 <Text> CELLO
1Required for automated, may not be required in non-automated format SSR
2Notapplicable for non-automated SSRs
3Name association in EDIFACT is performed through the use of a Traveler Reference

Number
4Name association in XML is performed through the use of the @RPH

Example in AIRIMP Format

SSR CBBG NK NN1 FLLCUN0123y30JUN-1DOE/JOHN.CELLO
Example in EDIFACT Format
SSR+CBBG:NN:1:NK:::FLL:CUN:CELLO+::987
Notes:
 John Doe’s Traveler Reference Number is 987
 This SSR Element should be placed at Level 3 in Group GR.5 following the TVL for flight 0123

Example in XML Format

<SSR SSRCode="CBBG" ServiceQuantity="1" Status="NN"
BoardPoint="FLL" OffPoint="CUN" RPH="987">
<Airline Code="NK" CodeContext="IATA" />
<Text>CELLO</Text>
</SSR>

7.4.3 SSR Handling Best Practices

The list of SSR codes and formats standardized by IATA evolves over time. In addition, airlines are free to
define their own codes for internal use and exchange with partners by bilateral agreement. Therefore this
document will not attempt to describe guidelines for specific SSRs. Rather, the following best practices should
be observed when building support for SSR data in PNRGOV messaging.

7.4.3.1 Placement
SSR data should be placed at the most appropriate level based on its scope.
 Automated SSRs contain flight-level information
o In EDIFACT they should be placed in GR.5 at Level 3 after the TVL for which they are
applicable.
o In XML they should be placed within the <Flight> element for which they are applicable.
(IATA_PNRGOV_NotifRQ\PNRs\PNR\Flight\SSR)
 Non-Automated SSRs that are passenger-specific
71
 PADIS EDIFACT Implementation Guide – PNRGOV Message

o In EDIFACT they should be placed in GR.2 at Level 3 after the TIF for which they are
applicable.
o In XML they should be placed within the <Passenger> element for which they are applicable
(IATA_PNRGOV_NotifRQ\PNRs\PNR\Passenger\SSR) or
(IATA_PNRGOV_NotifRQ\PNRs\PNR\Passenger\DOC_SSR)
 Non-Automated SSRs that are not passenger-specific
o In EDIFACT they should be placed in GR.1 at Level 2
o In XML they should be placed within the <PNR> element for which they are applicable
(IATA_PNRGOV_NotifRQ\PNRs\PNR\SSR) or
(IATA_PNRGOV_NotifRQ\PNRs\PNR\DOC_SSR)

7.4.3.2 Use of Most Specific Structured Data Location

When possible, if a more specific EDIFACT segment or XML Element exists, data should be placed in that
segment/element. For example, customer loyalty data should be placed in an FTI segment (EDIFACT) or
<CustLoyalty> element (XML) rather than transmitted as an SSR FQTV.
The XML version of the message contains specific elements for use to communicate travel document
information (SSR DOCS, DOCO and DOCA). This information should be placed in the <DOC_SSR>
elements rather than being handled as a regular <SSR>. It should be noted specific attributes are available for
each of these SSR types.

7.4.3.3 Handling of Free Text

Although the standard construction rules are followed for a significant number of SSRs, there are many
exceptions. In order to maximize consistency of data transmission, please consider the following guidelines:
 When free text appears in more than one area of an SSR:
o EDIFACT: the text in each area should be placed into separate occurrences of element 4440
as they appear from left to right in the AIRIMP format of the SSR

AIRIMP:
SSR MCOA CX HK1/16023512345673-MORRIS/EMMA.USD50

Becomes EDIFACT:
SSR+MCOA:HK:1:CX:::::16023512345673:USD50+::1

o XML: all free text components must be concatenated into a single text string to be placed
within the <Text></Text> element. A separator such as the colon (:) should be used between
the components.

AIRIMP:
SSR MCOA CX HK1/16023512345673-MORRIS/EMMA.USD50

Becomes XML:
<SSR SSRCode="MCOA" ServiceQuantity="1" Status="HK" RPH="1">
<Airline Code="CX" CodeContext="IATA" />
<Text>16023512345673:USD50</Text>
</SSR>

 When free text is lengthy:

o EDIFACT: if a free text component exceeds 255 characters, it should be split into multiple
occurrences of element 4440. The split should produce exactly 255-character chunks except
for the last occurrence. No characters should be added or trimmed from each chunk. This
will help the receiving system determine if it is receiving components of a long free text area or
separate free text areas from the SSR.

72
 PADIS EDIFACT Implementation Guide – PNRGOV Message

o XML: The <Text> element is not constrained to a specific length and therefore does not
require splitting of SSR free text data.

 Continuation SSRs should not be used. When SSR text and/or name association causes the AIRIMP
format for an SSR to exceed 69 characters (the line length limit), it must be split into two or more lines
as necessary to convey all details. In this process, the first elements of the SSR must be repeated
and a continuation indicator (///) must be included. However, this representation is required strictly
because of the limitations of Teletype format, and should not be carried over into EDIFACT or XML.

AIRIMP Example:
SSR PCTC AF HK/JOHN BAKER/FR33122334455-1SMITH/JOHN.TO BE
SSR PCTC AF /// CONTACTED IN CASE OF EMERGENCY

Becomes EDIFACT:
SSR+PCTC:HK::AF:::::JOHN BAKER/FR33122334455:TO BE CONTACTED IN CASE OF
EMERGENCY+::1

Becomes XML:
<SSR SSRCode="PCTC" Status="HK" RPH="1">
<Airline Code="AF" CodeContext="IATA" />
<Text>JOHN BAKER/FR33122334455:TO BE CONTACTED IN CASE OF EMERGENCY</Text>
</SSR>

 With the exception of API SSRs, any leading delimiters such as the oblique (/) or full stop (.) used
before the start of free text should not be included in element 4440 (EDIFACT) or the <Text> element
(XML). This is particularly important because some SSRs support both automated and non-
automated formats and the use of leading delimiters varies between those formats. However oblique
or full stop characters within the free text should be retained.

Example SSR ASVC (AIRIMP Automated)

SSR ASVC BA HS1 NCLLHR1321J30JUN.I/E23/VGML/VEGETARIAN MEAL/S/1251234567890C1

-- In PNRGOV EDIFACT
SSR+DOCS:HK:1:NZ:::MAD:LHR:I/E23/VGML/VEGETARIAN MEAL/S/1251234567890C1

-- In PNRGOV XML:
<Text>I/E23/VGML/VEGETARIAN MEAL/S/1251234567890C1</Text>

 For API SSRs (DOCS, DOCO, DOCA), special handling is appropriate and specific to each message
syntax. In EDIFACT, the leading oblique (/) preceding the document type or address type should be
included in element 4440. In XML, <DOC_SSR> elements should be used. The API data should be
parsed and placed in each attribute within the appropriate <DOCS>, <DOCO>, or <DOCA> element.

Example SSR DOCS for Passport (AIRIMP Automated)

SSR DOCS NZ
HK1MADLHR0455Y28JUN/P/NZL/P13248721/NZL/15NOV61/F/15NOV05/PEERS/MARLA

-- In PNRGOV EDIFACT:
SSR+DOCS:HK:1:NZ:::MAD:LHR:/P/NZL/P13248721/NZL/15NOV61/F/15NOV05/PEERS/MARLA

-- In PNRGOV XML:
<DOC_SSR SSRCode="DOCS" ServiceQuantity="1" Status="HK" RPH="1">
<FlightInfo BoardingPoint="MAD" DePlaningPoint="LHR" FlightNumber="0455"
ClassOfSvc="Y" CompanyShortName="NZ"/>
<DOCS TravelDocType="P" TravelDocNbr="P13248721" IssuingLoc="NZL" PaxNationality="NZL"
DateOfBirth="16NOV61" Gender="F" ExpiryDate="15NOV15" Surname="PEERS"
73
 PADIS EDIFACT Implementation Guide – PNRGOV Message

FirstGivenName="MARLA" />
</DOC_SSR>

Example SSR DOCS for Passport (AIRIMP Non-Automated)

SSR DOCS NZ HK1/P/NZL/P13248721/NZL/15NOV61/F/15NOV05/PEERS/MARLA

-- In PNRGOV EDIFACT:
SSR+DOCS:HK:1:NZ:::::/P/NZL/P13248721/NZL/15NOV61/F/15NOV05/PEERS/MARLA

-- In PNRGOV XML:
<DOC_SSR SSRCode="DOCS" ServiceQuantity="1" Status="HK" RPH="1">
<DOCS TravelDocType="P" TravelDocNbr="P13248721" IssuingLoc="NZL" PaxNationality="NZL"
DateOfBirth="16NOV61" Gender="F" ExpiryDate="15NOV15" Surname="PEERS"
FirstGivenName="MARLA" />
</DOC_SSR>

Example SSR DOCS for SFPD (AIRIMP Automated)

SSR DOCS NZ HK1MADLHR0455Y28JUN/////15NOV61/F//PEERS/MARLA

-- In PNRGOV EDIFACT:
SSR+DOCS:HK:1:NZ:::MAD:LHR://///15NOV61/F//PEERS/MARLA

-- In PNRGOV XML:
<DOC_SSR SSRCode="DOCS" ServiceQuantity="1" Status="HK" RPH="1">
<FlightInfo BoardingPoint="MAD" DePlaningPoint="LHR" FlightNumber="0455"
ClassOfSvc="Y" CompanyShortName="NZ"/>
<DOCS DateOfBirth="16NOV61" Gender="F" Surname="PEERS" FirstGivenName="MARLA" />
</DOC_SSR>

Example SSR DOCS for SFPD (AIRIMP Non-Automated)

SSR DOCS NZ HK1/////15NOV61/F//PEERS/MARLA

-- In PNRGOV EDIFACT:
SSR+DOCS:HK:1:NZ:::::////15NOV61/F//PEERS/MARLA

-- In PNRGOV XML:
<DOC_SSR SSRCode="DOCS" ServiceQuantity="1" Status="HK" RPH="1">
<DOCS DateOfBirth="16NOV61" Gender="F" Surname="PEERS" FirstGivenName="MARLA" />
</DOC_SSR>

 Passenger Names used for name-association of SSRs should not be repeated as free text. Instead,
name association should be accomplished by use of the Traveler Reference Number established in
the TIF segment (EDIFACT) or <Passenger @RPH> attribute (XML). However name data relevant to
the SSR should be retained in free text. Examples for which name data is relevant in free text include
the infant name (SSR INFT) or the travel document name (SSR DOCS). It should be noted that
associated names are not always applicable to SSRs.

74
 PADIS EDIFACT Implementation Guide – PNRGOV Message

APPENDIX A – CONTRL MESSAGES

SYNTAX AND SERVICE REPORT (CONTRL) MESSAGE

Introduction
This specification provides the definition of the IATA EDIFACT Syntax and Service Report (CONTRL)
message to be used in Electronic Data Interchange (EDI) between partners involved in administration,
commerce and transport.

Functional Definition
Purpose:

CONTRL is a message syntactically acknowledging or rejecting, with error indication, a

received interchange, functional group or message.

References:
UNTDID, Part 4, Section 2.5
UN/ECE UNSM General introduction, Section 1

Principles:
See Trade/WP.4/R.1010

CONTRL Segment Table

TAG NAME STATUS REPETITIONS

UNH MESSAGE HEADER M 1
UCI INTERCHANGE RESPONSE M 1
UCM MESSAGE RESPONSE C 1
UNT MESSAGE TRAILER M 1

CONTRL Message Branching Diagram

UNH UCI UNT

LEVEL 0
M1 M1 M1

GR.1
C1
LEVEL 1
UCM
M1

CONTRL Supporting Batch Segments

The following batch segments (taken from the Trade/WP.4/R.1010/Corr.1) are detailed to support the CONTRL
message.

UCI INTERCHANGE RESPONSE

Function: To identify the subject interchange and to indicate acknowledgement or rejection (action taken) of
the UNA, UNB and UNZ segments, and to identify any error related to these segments.
Depending on the action code, it may also indicate the action taken on the functional groups and
messages within that interchange.

75
 PADIS EDIFACT Implementation Guide – PNRGOV Message

Name -ISO 9735 No. Field Status IATA Remarks

Type Status IATA Implementation
INTERCHANGE CONTROL 0020 an..14 M M As per ISO 9735
REFERENCE
INTERCHANGE SENDER S002 M M As per ISO 9735
Sender identification 0004 an..35 M M As per ISO 9735
Partner identification code qualifier 0007 an..4 C C As per ISO 9735
Address for reverse routing 0008 an..14 C C As per ISO 9735
INTERCHANGE RECIPIENT S003 M M As per ISO 9735
Recipient identification 0010 an..35 M M As per ISO 9735
Partner identification code qualifier 0007 an..4 C C As per ISO 9735
Routing address 0014 an..14 C C As per ISO 9735.
ACTION, CODED 0083 an..3 M M As per ISO 9735
SYNTAX ERROR, CODED 0085 an..3 C C As per ISO 9735
SEGMENT TAG 0013 a3 C C As per ISO 9735
DATA ELEMENT IDENTIFICATION S011 C C As per ISO 9735
Erroneous data element position in 0098 n..3 M M As per ISO 9735
segment
Erroneous component data element 0104 n..3 C C As per ISO 9735
position

UCM MESSAGE RESPONSE

Function: To identify a message in the subject interchange, and to indicate that message’s
acknowledgement or rejection (action taken), and to identify any error related to the UNH and UNT
segments.

Name -ISO 9735 No. Field Status IATA Remarks

Type Status IATA Implementation
MESSAGE REFERENCE NUMBER 0062 an..14 M M As per ISO 9735
MESSAGE IDENTIFIER S009 M M As per ISO 9735
Message type identifier 0065 an..6 M M As per ISO 9735
Message type version number 0052 an..3 C C As per ISO 9735
Message type release number 0054 an..3 M M As per ISO 9735
Controlling agency 0051 an..2 M M As per ISO 9735
Association assigned code 0010 an..6 C C As per ISO 9735
ACTION, CODED 0083 an..3 M M As per ISO 9735
SYNTAX ERROR, CODED 0085 an..3 C C As per ISO 9735
SEGMENT TAG 0013 a3 C C As per ISO 9735
DATA ELEMENT IDENTIFICATION S011 C C As per ISO 9735
Erroneous data element position in 0098 n..3 M M As per ISO 9735
segment
Erroneous component data element 0104 n..3 C C As per ISO 9735
position

76
 PADIS EDIFACT Implementation Guide – PNRGOV Message

APPENDIX B – Business Examples

The following business case examples are provided to illustrate the variety of data and potential differences in where
specific data is contained in a message based on the system sending the message, where and how data is stored in that
system and based on the original source of the information.

Because of the volume of data that would be sent for entire flight, the examples only contain information for one
complete PNR with indication that the message is partial data for entire flight.

All examples placed in the Implementation Guide have been reviewed and agreed by the PNRGOV working group
All amounts have been neutralized to ensure there is no hint of price sensitivity. All personally identifiable information is
fictitious.

1 Scenarios – Two Passengers traveling internationally:

A PNRGOV message sent 24 hours prior to departure for Delta flight 324 with routing LHR > JFK > YVR. This flight
requires four separate messages to 3 separate governments (UK, US and Canadian). The first message is for DL flight
324 out of London (LHR) and is sent to UK and US. The partial message contains two PNRs with the following
characteristics:

PNR 1 – Two Passengers booked and paid by 3rd party, credit card payment. PNR has been split, the full
itinerary has had a change in flight, SSR meals and seats for all passengers. Passengers are ticketed and due to a
change in the itinerary, the ticket had to be exchanged and repriced. Also included are elite frequent flier,
Secure Flight Passenger Data, and hotel. Two bags were paid for fees. Passenger John Smith has checked in at
24 hours prior to departure.

PNR 2 – Two passengers, booked on a round trip by a GDS. The name has been changed.

UNA:+.\*
UNB+IATA:1+DL+??+101209:2100+020A07’ Interchange header segment
UNH+1+PNRGOV:10:1:IA+F6C2C268' Message header
MSG+:22'
ORG+DL:ATL+52519950’
TVL+121210:0915+LHR+JFK+DL+324' PNR data for DL324/12DEC10 LHR
EQN+2' Number of PNRs being sent in the message
SRC’ <<< Start of PNR 1 >>>
RCI+DL:MFN4TI'
SSR+AVML:HK:2:DL’
DAT+700:061210:1010+710:061210:1200’
IFT+4:28::DL+THIS PASSENGER IS A VIP’
IFT+4:28::DL+CTCR 00115555555555’
ORG+DL:ATL+52519950:LON+++A+GB:GBP+D050517’ Booked by DL call center agent in UK
ADD++702:45 HIGH Phone in free text
STREET:SLOUGH:BERKSHIRE::GB:SL1AA:00441753637285’
EBD+GBP:40.00+4::N’ Total for 4 bags
TIF+SMITHJR+JOHNMR:A:1’ Adult passenger, Mr. John Smith Jr.
FTI+DL:1234567890:::ELITE’
IFT+4:15:9+LHR DL X/JFK DL YVR GBP/IT END ROE0.618831
XT3.10AY6 8.50YQ3.40+YC4.30XY3.10XA2.80XFATL4.5’
REF+:38739393AN8739P’
FAR+N+++++MIL24’ Military Fare
SSR+DOCS:HK::DL:::::/P/GBR/123456789/GBR/12JUL64/M/23AUG19/SMITHJ
R/JONATHON/ROBERT’
TKT+0062120234533:T:1'
MON+B:2888.00:GBP+T:2957.94:GBP'
PTK+NR++061210:1010+DL+006+LON'
TXD++3.10:::AY6+8.50:::YQ+3.40:::YC+4.30:::XY+3.10:::XA+2.80:::XF'
DAT+710:061210:1200’
FOP+CC:::VI:XXXXXXXX1186:0211'
IFT+4:43+TIMOTHY SIMS+2234 MAIN STREET ATLANTA, GA 30067+770 Sponsor
5632891’
TIF+JONES+WILLIAMMR:A:2’ Adult passenger, Mr. William Jones
FTI+AF:0093789865:::ELITE’
IFT+4:15:9+ LHR DL X/JFK DL YVR GBP/IT END ROE0.618831
XT3.10AY6 8.50YQ3.40+YC4.30XY3.10XA2.80XFATL4.5’
REF+:38739393AN8780P’
FTI+AF:0093789865:::ELITE’
FAR+A+++++YN324N’ Normal Advance Booking Fare
SSR+DOCS:HK::DL::::://///GBR/12JUL64/M//JONES/WILLIAMNEVELL’
TKT+0062120234534:T:1'

77
 PADIS EDIFACT Implementation Guide – PNRGOV Message

MON+B:2888.00:GBP+T:2957.94:GBP'
PTK+NR++061210:1010+DL+006+LON'
TXD++3.10:::AY6+8.50:::YQ+3.40:::YC+4.30:::XY+3.10:::XA+2.80:::XF'
DAT+710:081210:1200’
FOP+CC:::VI:XXXXXXXX1186:0211'
IFT+4:43+TIMOTHY SIMS+2234 MAIN STREET ATLANTA, GA 30067+770 Sponsor
5632891’
TVL+121210:0915::1230+LHR+JFK+DL+324:B' First flight in itinerary
APD+767’
SSR+SEAT:HK:2:DL:::LHR:JFK+15A::1+15B::2’ Seats for both passengers
DAT+2:111210:0915’ Check-in info starts here
TRI++108:::1’ Boarding/Check-in #108
TIF+SMITHJR+JOHNMR:A:1’ Adult passenger, Mr. John Smith Jr.
SSD+15A++++Y’ Seat and cabin check-in info
TVL+121210:2200::2330+JFK+YVR+DL+330:B' Second flight in itinerary
RPI+2+HK’
APD+767’
SSR+SEAT:HK:2:DL:::JFK:YVR+15E::1+15F::2’ Seats for both passengers
EQN+1’
RCI+DL:ABCDEF'
MSG+8’ Hotel segment
TVL+121210:1500:151210+YVR:VANCOUVER ARMS++VN+67576:ROH’ Hotel info
ABI+1+:LHRRR+LON++DL’ Start First History Item
DAT+ZT:071210:1010’
SAC+++X’
TVL+101210:0915::1230+LHR+JFK+DL+324:B' Cancel Flight #1
RPI+2+K’
SAC+++X’
SSR+AVML:HK:2:DL’ Cancel AVML for both passengers
SAC+++X’
SSR+SEAT:HK:2:DL:::LHR:JFK+15A::1+15B::2’ Cancel Seats for both passengers
SAC+++X’
TVL+101210:2200::2330+JFK+YVR+DL+330:B' Cancel Flight #2
RPI+2+K’
SAC+++X’
SSR+AVML:HK:2:DL’ Cancel AVML for both passengers
SAC+++X’
SSR+SEAT:HK:2:DL:::JFK:YVR+15E::1+15F::2’ Cancel Seats for both passengers
SAC+++A’
TVL+121210:0915::1230+LHR+JFK+DL+324:B' Add flight #1
RPI+2+K’
SAC+++A’
SSR+AVML:HK:2:DL’ Add AVML for both passengers
SAC+++A’
SSR+SEAT:HK:2:DL:::LHR:JFK+15A::1+15B::2’ Add Seats for both passengers
SAC+++A’
TVL+121210:2200::2330+JFK+YVR+DL+330:B' Add flight #2
RPI+2+K’
SAC+++A’
SSR+AVML:HK:2:DL’ Add AVML for both passengers
SAC+++A’
SSR+SEAT:HK:2:DL:::JFK:YVR+15E::1+15F::2’ Add Seats for both passengers
SRC’ <<< Start of PNR 2 >>>
RCI+1A:23456'
DAT+700:061210:1010+710:061210:1200’
ORG+1A:MUC+12345678:F31+LON++T+GB:GBP+A78987’
ADD++702:351 LANDSDOWN ROAD:SLOUGH:BERKSHIRE::GB:SL1AA’ Booked by 1A travel agent in UK
EBD+GBP:20.00+2::N’ Total for 2 bags
TIF+WAYNE+JOHNMR:A:1’ Adult passenger, Mr. John Wayne
FTI+DL:1234567893:::ELITE’
IFT+4:15:9+LHR DL X/JFK DL YVR GBP/IT END ROE0.618831
XT3.10AY6 8.50+YQ3.40YC4.30XY3.10XA2.80XFATL4.5’
REF+:38739393AN8740P’
FAR+A+++++YN324N’ Normal advance booking fare
SSR+DOCS:HK::DL:::::/P/GBR/123456789/GBR/12JUL12/M/23AUG15/WAYNE/
JOHNALVA’
TKT+0062120234535:T:1'
MON+B:2888.00:GBP+T:2957.94:GBP'
PTK+NR++061210:1010+DL+006+LON'
TXD++3.10:::AY6+8.50:::YQ+3.40:::YC+4.30:::XY+3.10:::XA+2.80:::XF'
DAT+710:061210:1200’
FOP+CC:::VI:XXXXXXXX1186:0211'
TIF+COOPER+GARYMR:A:2’ Adult passenger, Mr. Gary Cooper
FTI+AF:0093789830:::ELITE’
IFT+4:15:9+ LHR DL X/JFK DL YVR GBP/IT END ROE0.618831
XT3.10AY6 8.50+YQ3.40YC4.30XY3.10XA2.80XFATL4.5’
REF+:38739393AN8793P’
FAR+A+++++YN324N’ Normal Advance Booking Fare
SSR+DOCS:HK::DL:::::/P/GBR/987654321/GBR/12JUL15/M/15JAN13/COOPER
/GARYWILLIAM’
TKT+0062120234536:T:1'
MON+B:2888.00:GBP+T:2957.94:GBP'
PTK+NR++061210:1010+DL+006+LON'
TXD++3.10:::AY6+8.50:::YQ+3.40:::YC+4.30:::XY+3.10:::XA+2.80:::XF'
DAT+710:061210:1200’
FOP+CC:::DC:XXXXXXXX3578:0211'

78
 PADIS EDIFACT Implementation Guide – PNRGOV Message

TVL+121210:0915::1230+LHR+JFK+DL+324:B' First flight in itinerary

RPI+1+HK’
APD+767’
SSR+SEAT:HK:2:DL:::LHR:JFK++17A::1+17B::2’ Seats for both passengers
DAT+2:111210:0915’ Check-in info starts here
TRI++2:::1’ Boarding/Check-in #2
TIF+COOPER+GARYMR:A:2’ Adult passenger, Mr. Gary Cooper
SSD+15A++++Y’ Seat and cabin check-in info
TVL+121210:2200::2330+JFK+YVR+DL+330:B' Second flight in itinerary
RPI+1+HK’
APD+767’
SSR+SEAT:HK:2:DL:::JFK:YVR+17E::1+17F::2’ Seats for both passengers
ABI+1+:LHRRR+LON++DL’ Start First History Item
DAT+ZT:071210:1010’
SAC+++X’
TIF+WAYNE+JONMR:A:1’ Cancel Name
SAC+++A’
TIF+WAYNE+JOHNMR:A:1’ Add Name
UNT+135+1
UNZ+1+020A07’

2 Example of PNRs with Infant, Reservation and Check-in data and unformatted history

UNA:+.\*’ Interchange header segment

UNB+IATA:1+1A+KRC+130527:0649+0003' Message header
UNH+1+PNRGOV:11:1:IA+270513/0649/SQ/602'
MSG+:22' 22 used for ‘Push PNR data to States’
ORG+1A:MUC' Information about the sender of this message
TVL+270513:1430:270513:2205+SIN+ICN+SQ+602' Leg information for which passenger data is being sent
EQN+1' Number of PNRs being sent in the message
SRC'
RCI+1A:3PGZOV::190313:1354' PNR Record information, PNR creation date and time
DAT+700:270513:0559' Latest PNR transaction date
ORG+1A:MUC+32393340:SINSQ08AA+NCE+SQ:NCE+A+SG+ELPD+CFDE59+9C' Originator of request details
TIF+BELT:I+ISABELLE MRS:A:2:1' Passenger last and first name
FTI+SQ:8794285757' Passenger Frequent Flyer number
IFT+4:63::SQ' 63 : Go show indicator
REF+:001C451486DFF0CC' Unique passenger id
SSR+DOCS:HK:1:SQ:::::/P/GBR/512731999/GBR/20SEP12/FI/25OCT17/BELT/SOP Passport information of the infant
HY OLIVIA/'
SSR+DOCS:HK:1:SQ:::::/P/GBR/509229987/GBR/01JUL78/F/12NOV22/BELT/ISAB Passport information of the parent
ELLE RUTH/'
TIF+BELT:I+SOPHY:IN:3' Infant last and first name
IFT+4:63::SQ' 63 : Go show indicator
SSR+DOCS:HK:1:SQ:::::/P/GBR/512731999/GBR/20SEP12/FI/25OCT17/BELT/SOP
HY OLIVIA/'
TVL+270513:1430:270513:2205+SIN+ICN+SQ+602:D' Segment booked information
RPI+1+HK' Flight booking status
APD+333' Aircraft type
SSR+INFT:HK:1:SQ:::SIN:ICN:BELT/SOPHY 20SEP12+::2' SSR INFT information

SSR+DOCS:HK:1:SQ:::SIN:ICN:/P/GBR/509229987/GBR/01JUL78/F/12NOV22/BEL Passport information of the parent

T/ISABELLE RUTH/+::2'
RCI+1A:3PGZOV::190313:1354' Passenger record locator specific to this flight
DAT'
Check-in information of the parent:
ORG+SQ++++A' Check-in Agent information
TRI++SIN-168:::2' Sequence/boarding number
TIF+BELT:I+ISABELLE MRS:A:2' Check-in passenger last and first name
SSD+011D++++J' Seat number assigned
TBD++3:33:700++HP:SIN- Checked in Baggage information
168+618:0123456789:2:ICN+618:0123456788:3:ICN+618:0123456787:722356:ICN'
DAT'
Check-in information of the infant:
ORG+SQ++++A' Check-in Agent information
TRI++SIN-169:::3' Sequence/boarding number
TIF+BELT:I+SOPHY:IN:3' Check-in passenger last and first name
SSD+011D++++J' Seat number assigned
LTS+0/O/NM/BELT/ISABELLE MRS(ADT)(INF/SOPHY/20SEP12)' Unformatted history information
LTS+0/O/SS/SQ 602 D 27MAY 1 SINICN LK1 1430 2205/NN \*1A/E\*
/SQ/SG/C/I/CAB J//1///// /Y 1625/B 153//AY 1838/EY 1685/SINICN/D'
LTS+0/O/SR/SSR INFTSQNN1 BELT/SOPHY 20SEP12/SQ 602 D 27MAY
SINICN/BELT/ISABELLE MRS(ADT)(INF/SOPHY/20SEP12)'
LTS+0/O/SR/SSR FQTVSQHK/ SQ8794285757 S/KFES/BELT/ISABELLE
MRS(ADT)(INF/SOPHY/20SEP12)'
LTS+0/O/SR/SSR FQTSSQHK1 SQ8794285757 S/KFES/SQ 602 D 27MAY
SINICN/BELT/ISABELLE MRS(ADT)(INF/SOPHY/20SEP12)'
LTS+0/O/SR/SSR DOCSSQHK1
P/GB/509229987/GB/01JUL78/F/12NOV22/BELT/ISABELLE//H/SQ 602 D 27MAY
79
 PADIS EDIFACT Implementation Guide – PNRGOV Message

SINICN/BELT/ISABELLE MRS(ADT)(INF/SOPHY/20SEP12)'
LTS+0/Z/AMADEUS E RETAIL CR-SINSQ08AA 32393340 SU 0001AA/DS-
9CCFDE59 19MAR1354Z'
LTS+0/1/R/SR/SSR INFTSQKK1 BELT/SOPHY 20SEP12/HN/SQ 602 D 27MAY
SINICN/BELT/ISABELLE MRS(ADT)(INF/SOPHY/20SEP12)'
LTS+1/Z/1AINV RM SQ 191354 CR-1AINV RM SQ 0000 19MAR1354Z'
LTS+2/P/QE/SINSQ0100/1C15D4'
LTS+2/Z/1AINV RM SQ 191354 CR-1AI NV R 19MAR1354Z'
LTS+3/Z/ -SQ/WSSQSAA CR-SINSQ08AA 32393340 GS 9999WS/RO-9C404C04
SAAW330SQ 00000000 19MAR1354Z'
LTS+4/Z/1AINV RM SQ 191354 CR-1AINV RM SQ 0000 19MAR1354Z'
LTS+0/5/C/5/AP AMADEUS-H'
LTS+0/5/C/27/TKXL 20MAR/0004/SINSQ08AA'
LTS+5/A/27/TKOK 19MAR/SINSQ08AA'
LTS+5/6/R/27/TKOK 19MAR/SINSQ08AA'
LTS+6/Z/AA CR-SINSQ08AA 32393340 SU 0001AA/DS-9CCFDF66 19MAR1359Z'
LTS+7/Z//DCS-SYNCUS CR-SINSQ00CO 00000000 PD 6160MC/DS-9CBABA44
23MAY1240Z'
LTS+0/8/C/SR/SSR FQTVSQHK/ SQ8794285757 S/KFES/BELT/ISABELLE
MRS(ADT)(INF/SOPHY/20SEP12)'
LTS+0/8/C/SR/SSR FQTSSQHK1 SQ8794285757 S/KFES/SQ 602 D 27MAY
SINICN/BELT/ISABELLE MRS(ADT)(INF/SOPHY/20SEP12)'
LTS+8/A/SR/SSR FQTVSQHK/ SQ8794285757 G/QPPS/BELT/ISABELLE
MRS(ADT)(INF/SOPHY/20SEP12)'
LTS+8/A/SR/SSR FQTSSQHK1 SQ8794285757 G/QPPS/SQ 602 D 27MAY
SINICN/BELT/ISABELLE MRS(ADT)(INF/SOPHY/20SEP12)'
LTS+8/Z/CSXAPU CR-NCE1A0SQ0 SU 0001AA 24MAY2009Z'
LTS+9/Z/1AINV RM SQ 242009 CR-1AINV RM SQ 0000 24MAY2009Z'
LTS+1/10/R/SR/SSR INFTSQHK1 BELT/SOPHY 20SEP12/KK/SQ 602 D 27MAY
SINICN/BELT/ISABELLE MRS(ADT)(INF/SOPHY/20SEP12)'
LTS+4/10/R/SR/SSR BSCTSQHK1/KK/SQ 602 D 27MAY SINICN/BELT/ISABELLE
MRS(ADT)(INF/SOPHY/20SEP12)'
LTS+10/Z/ETK-ISSBOE CR-SINSQ01W0 32391122 GS 1916VV/RO-9CB39093
MUCPI2SQ1 00000000 25MAY0309Z'
LTS+11/A/SK/SK LKPX SQ HK1 Z8OWIE-P1/SQ 602 D 27MAY
SINICN/BELT/ISABELLE MRS(ADT)(INF/SOPHY/20SEP12)'
LTS+11/Z/ISSBOE CR-SINSQ01W0 32391122 GS 1916VV/RO-9CB39093
MUCPI2SQ1 00000000 25MAY0313Z'
LTS+12/Z/MRS BELT CR-SINSQ01W0 32391122 GS 1916VV/RO-9CB39093
MUCPI2SQ1 00000000 25MAY0315Z'
LTS+13/Z/1AINV RM SQ 250315 CR-1AINV RM SQ 0000 25MAY0315Z'
LTS+14/A/7/RX \*\*\*\*\*\*\*\* ATTN SINKKXH SINKDXH SINKNXH PLS ASSIST PAX
WITH TKT 618-2402058077 AND 618-2402241436 TO BE SEATED TOGETHER
FLT'
LTS+14/A/7/RX SQ602 D SIN - ICN 27MAY13 14\:30 ON BSCT SEAT X MANY
THANKS SINRRRSQ'
LTS+14/A/7/RX MS BELT CALLED TO UPDATE SEAT RQST X ADDED SEAT /
MEAL X TELEX SENT X NIL SEATS AND MEALS X MOBILE CONTACT NUMBER
UPDATED'
LTS+14/A/7/RX X VIAN / 8\:48 IST 25/5/2013'
LTS+14/Z/MRS BELT CR-SINSQ01W0 32391122 GS 1916VV/RO-9CB39093
MUCPI2SQ1 00000000 25MAY0320Z'
LTS+15/A/SR/SSR DOCSSQHK1
P/GBR/512731999/GBR/20SEP12/FI/25OCT17/BELT/SOPHY
OLIVIA//BELT/ISABELLE MRS(ADT)(INF/SOPHY/20SEP12)'
LTS+15/A/SR/SSR DOCSSQHK1
P/GBR/512731999/GBR/20SEP12/FI/25OCT17/BELT/SOPHY OLIVIA//SQ 602 D
27MAY SINICN/BELT/ISABELLE MRS(ADT)(INF/SOPHY/20SEP12)'
LTS+15/Z//DCS-IREQ CR-SINSQ00VW 00000000 GS 9743EC/DS-9CBCCB00
27MAY0422Z'
LTS+0/16/C/SR/SSR DOCSSQHK1
P/GB/509229987/GB/01JUL78/F/12NOV22/BELT/ISABELLE//H/SQ 602 D 27MAY
SINICN/BELT/ISABELLE MRS(ADT)(INF/SOPHY/20SEP12)'
LTS+16/A/SR/SSR DOCSSQHK1
P/GBR/509229987/GBR/01JUL78/F/12NOV22/BELT/ISABELLE RUTH//SQ 602 D
27MAY SINICN/BELT/ISABELLE MRS(ADT)(INF/SOPHY/20SEP12)'
LTS+16/Z//DCS-IREQ CR-SINSQ00VW 00000000 GS 9743EC/DS-9CBAB9B5
27MAY0423Z'
LTS+17/A/SR/SSR DOCSSQHK1
P/GBR/509229987/GBR/01JUL78/F/12NOV22/BELT/ISABELLE
RUTH//BELT/ISABELLE MRS(ADT)(INF/SOPHY/20SEP12)'
LTS+17/Z//DCS-IREQ CR-SINSQ00VW 00000000 GS 9743EC/DS-9CBAB9D5
27MAY0423Z'
LTS+18/Z//DCS-SYNCUS CR-SINSQ00VW 00000000 GS 9743EC/DS-9CBABA1D
27MAY0423Z'
LTS+19/Z//DCS-SYNCUS CR-SINSQ00VW 00000000 GS 9743EC/DS-9CBCCB14
27MAY0423Z'
LTS+20/Z//DCS-SYNCUS CR-SINSQ00CO 00000000 PD 2092EL/DS-9CBAB94B
27MAY0559Z'
LTS+21/Z//DCS-SYNCUS CR-SINSQ00CO 00000000 PD 2092EL/DS-9CBABA1A
27MAY0559Z'
UNT+85+1' Number of segments
UNZ+1+0003' Interchange trailer

80
 PADIS EDIFACT Implementation Guide – PNRGOV Message

3 Example of Codeshare PNRs with Reservation and Check-in data and unformatted history

UNA:+.\*' Interchange header segment

UNB+IATA:1+1A+KRC+130527:0754+0003' Message header
UNH+1+PNRGOV:13:1:IA+270513/0754/SQ/609'
MSG+:22' 22 used for ‘Push PNR data to States’
ORG+1A:MUC' Information about the sender of this message
TVL+270513:1640:270513:2200+ICN+SIN+SQ+609' Leg information for which passenger data is being sent
EQN+2' Number of PNRs being sent in the message
SRC' 1st PNR
RCI+1A:2LS6KP::200513:0439+KE:EDP2RW' PNR Record information, PNR creation date and time
DAT+700:270513:0718' Latest PNR transaction date
ORG+1A:MUC+:HDQKE2400+NBE+KE:NBE+A+KR+GNPD+003956+94' Originator of request details
TIF+PARK:I+SEJOONMR::1' Passenger last and first name
FTI+SQ:314655277:::::G' Passenger Frequent Flyer number
IFT+4:63::SQ' 63 : Go show indicator
REF+:001435199A918A76' Unique passenger id
SSR+DOCS:HK:1:SQ:::::/P/KR/JR3364288/KR/10SEP72/M/05JUL16/PARK/SE Passport information
JOON’
TVL+270513:1640:270513:2200+ICN+SIN+KE:SQ+609:B' Segment booked information
TRA+SQ+303:Y’ Operating flight number
RPI+1+HK' Flight booking status
APD+333' Aircraft type
SSR+NSSA:HN:1:SQ:::ICN:SIN+::1' Seat request information
SSR+CKIN:HK:1:SQ:::ICN:SIN:10KG EXBG WAIVER AUTH BY MDPRM+::1' SSR information
SSR+DOCS:HK:1:SQ:::ICN:SIN:/P/KOR/JR3364288/KOR/10SEP72/M/05JUL16/PAR Passport information
K/SE JOON/+::1'
RCI+1A:2LS6KP::200513:0439+KE:EDP2RW' Passenger record locator specific to this flight
DAT'
ORG+SQ++++A' Check-in Agent information
TRI++ICN-188:::1' Sequence/boarding number
TIF+PARK:I+SEJOONMR::1' Check-in passenger last and first name
SSD+039G++++Y' Seat number assigned
TBD++2:34:700++MP+618:1026000001:2:MPM+618:1026000002:3:MPM' Checked in Baggage information
LTS+0/O/NM/PARK/SEJOONMR' Unformatted history information
LTS+0/O/SS/SQ 609 E 27MAY 1 ICNSIN LK1 1640 2200/LK \*1A/E\*
/KE/KR/C/I/CAB Y//2/0001//// /Y 621/B 3//AY 914/EY 908/ICNJNB/E'
[…]
LTS+14/A/SR/SSR DOCSSQHK1
P/KR/JR3364288/KR/10SEP72/M/05JUL16/PARK/SE JOON/PARK/SEJOONMR'
LTS+14/Z/SELRMKE 210921 CR-SEL RM KE 21MAY0921Z'
[…]
LTS+47/Z//DCS-SYNCUS CR-ICNSQ00CS 00000000 PD 6017GN/DS-9CBABA8A
27MAY0718Z'
SRC' 2nd PNR
RCI+1A:X49V9U::210113:0411+OZ:2OX5VV’ PNR Record information, PNR creation date and time
DAT+700:270513:0726' Latest PNR transaction date
ORG+1A:MUC+32393340:SINSQ08AA+NCE+SQ:NCE+A+SG+HJGS+CFDEA9+9C' Originator of request details
TIF+KIM:I+KONG CHUN MRS:A:3' Passenger last and first name
FTI+SQ:223422444' Passenger Frequent Flyer number
IFT+4:63::SQ' 63 : Go show indicator
REF+:0010350E7830159A' Unique passenger id
SSR+DOCS:HK:1:SQ:::::/P/KOR/M17072944/KOR/15FEB57/F/23MAR19/KIM/KONG Passport information
CHUN/'
TVL+270513:1640:270513:2200+ICN+SIN+OZ:SQ+609:Z' Segment booked information
TRA+SQ+752:D’ Operating flight number
RPI+1+HK' Flight booking status
APD+333' Aircraft type
SSR+RQST:HK:1:SQ:::ICN:SIN+14A::3' Seat request information
SSR+DOCS:HK:1:SQ:::ICN:SIN:/P/KOR/M17072944/KOR/15FEB57/F/23MAR19/KIM Passport information
/KONG CHUN/+::3'
RCI+1A:X49V9U::210113:0411+OZ:2OX5VV’ Passenger record locator specific to this flight
DAT'
ORG+SQ++++A' Check-in Agent information
TRI++ICN-229:::3' Sequence/boarding number
TIF+KIM:I+KONG CHUN MRS:A:3' Check-in passenger last and first name
SSD+014A++++J' Seat number assigned
TBD++2:29:700++MP+618:0000290138:1:SIN+618: 0000290139:3:SIN' Checked in Baggage information
LTS+0/S/PARK/KWANG SOO MR(ADT) -YHD2DT' Unformatted history information
LTS+0/Z/PARK HYUNJU CR-SELSQ01G0 17381302 GS 5477EK/RO-9CB3A23D
MUCPI2SQ1 00000000 21JAN0411Z'
[…]
LTS+65/Z//DCS-SYNCUS CR-ICNSQ00CI 00000000 GS 6058HJ/DS-9CBAB945
27MAY0726Z'
UNT+336+1' Number of segments
UNZ+1+0003' Interchange trailer

81
 PADIS EDIFACT Implementation Guide – PNRGOV Message

4 Simple PNR booked in another system (no PNR history)

UNA:+.\*' Interchange header segment

UNB+IATA:1+1A+CBSAPNRGOV+130527:1414+0001++PNRGOV' Message header
UNH+1+PNRGOV:11:1:IA+LH474/270513/0000'
MSG+:22' 22 used for ‘Push PNR data to States’
ORG+1A:MUC' Information about the sender of this message
TVL+270513:1550:270513:1820+MUC+YUL+LH+474' Leg information for which passenger data is being sent
EQN+3' Number of PNRs being sent in the message
SRC' 1st PNR
RCI+1A:3MZVP2::210513:1526+AC:P46KA5' GDS code, RLOC within the GDS code, PNR creation date
and time, other GDS where the booking is as well present +
RLOC within this other GDS
DAT+700:270513:1354' Latest PNR transaction date
ORG+1A:MUC+:MUC1A1TTY++1A++DE+LHSU' Originator of request details
TIF+JACKS:I+JAMES::1' Passenger last and first name
REF+:00243519B9209183' Unique passenger id
SSR+DOCS:HK:1:LH::::://///21APR66/M//JACKS/JAMES' Passport information
TKT+3537321830:T:1' Ticket number and total number of booklets issued
TVL+270513:1550:270513:1820+MUC+YUL+AC:LH+9099:U' Segment booked information
RPI+1+HK' Flight booking status
APD+343' Aircraft type
RCI+1A:3MZVP2::210513:1526+AC:P46KA5' Passenger record locator specific to this flight
TVL+++++474:U' Operating flight number
SRC' 2nd PNR
RCI+1A:33O6DK::070513:0837+1G:MS6HXI' GDS code, RLOC within the GDS code, PNR creation date
and time, other GDS where the booking is as well present +
RLOC within this other GDS
DAT+700:270513:1354' Latest PNR transaction date
ORG+1A:MUC+:SWI1G2400++1G++IT+LHSU+0401C0+94' Originator of request details
TIF+CARRERA:I+MARCUSMR::1' Passenger last and first name
FTI+LH:992223782028813' Frequent traveler number
REF+:002015188BD5A2F7' Unique passenger id
SSR+DOCS:HK:1:LH:::::/P/IT/YA0196755/IT/17APR80/M/11JAN20/CARRERA/MAR Passport information
CUS'
TKT+3909508960:T:5' Ticket number and total number of booklets issued
DAT+710:100513' Ticket issue date
TVL+270513:1300:270513:1405+VCE+MUC+LH:EN+9457:Z' Segment booked information
RPI+1+HK' Flight booking status
RCI+1A:33O6DK::070513:0837+1G:MS6HXI' Passenger record locator specific to this flight
TVL+++++8203:Z' Operating flight number
TVL+270513:1550:270513:1820+MUC+YUL+LH+474:Z' Segment booked information
RPI+1+HK' Flight booking status
APD+343' Aircraft type
RCI+1A:33O6DK::070513:0837+1G:MS6HXI' Passenger record locator specific to this flight
SRC' 3rd PNR
RCI+1A:35K2IO::150213:0149+1S:EVFSDI' GDS code, RLOC within the GDS code, PNR creation date
and time, other GDS where the booking is as well present +
RLOC within this other GDS
DAT+700:270513:1354' Latest PNR transaction date
ORG+1A:MUC+:DFW1S4100++1S++CA+LHSU+7E5AA8+9B' Originator of request details
TIF+DORON:I+NINA MS::2' Passenger1 last and first name
REF+:00183511D94292CC' Unique passenger id
SSR+DOCS:HK:1:LH::::://///05FEB53/F//DORON/NINA' SSR DOCS information
TKT+3204694511:T:4' Ticket number and total number of booklets issued
DAT+710:150213' Ticket issue date
TIF+LENDROT:I+CHARLOTTE MS::1' Passenger2 last and first name
REF+:00183511D94292CD' Unique passenger id
SSR+DOCS:HK:1:LH::::://///14FEB52/F//LENDROT/CHARLOTTE' SSR DOCS information
TKT+3204694509:T:4' Ticket number and total number of booklets issued
DAT+710:150213' Ticket issue date
TVL+270513:1550:270513:1820+MUC+YUL+LH+474:W' Segment booked information
RPI+2+HK' Flight booking status
APD+333' Aircraft type
RCI+1A:35K2IO::150213:0149+1S:EVFSDI' Passenger record locator specific to this flight
UNT+55+1' Number of segments
UNZ+1+0001' Interchange trailer

82
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5 Example with three PNRs containing ticket information

Three PNRs:
- one single passenger, ticketless, registered passenger with customer ID,
- one single passenger, with a IATA ticket,
- one Group PNR with some names

UNB+IATA:1+TZ+AUCBPS+130523:2210+00102181551362'
UNG+PNRGOV+TZ+AUCBPS+130523:2210+00102181551362+IA+11:1'
UNH+00102181551362+PNRGOV:11:1:IA+AUTZ000623052013221001SIN2013052
8'
MSG+:22' PNR Data to State (Australia)
ORG+TZ:MSP+++TZ:SYS+++HOLMESS' Sent by TZ agent HOLMESS
TVL+280513:2225:290513:0750+SIN+OOL+TZ+0006' For flight TZ 0006 from SIN to OOL
EQN+3' 3 PNRs on flight
SRC' 1st PNR
RCI+TZ:W9TEND::230513:181348' Airline locator W9TEND, created 23 May 2013 at 18:13Z
DAT+700:230513:2125+710:230513:2124' Last modified 23 May 2013 at 21:25Z
Payment made 23 May 2013 at 21:24Z
ORG+TZ:SYS+++++:SGD' Booking originated by a TZ system user
ADD++700:123 ANY STREET:LAKE TOWN:MN::US:55123:H5555555555 W 1 555 Reservation contact information including address and
555 5555 ' telephone numbers
TIF+VANDENBERG+KEVINMICHAELMR:A:43576' Adult passenger name and unique ID
REF+:43576' Security-related unique ID
FAR+A+32++++SFLY+SFLY' Adult fare with fare basis code SFLY
SSR+DOCS:HK:1:TZ:::::/P/USA/548721687/USA/04JUL80/M/12JAN19/VANDENBE Passport details
RG/KEVIN/MICHAEL+::43576'
TKT+:700' Ticketless payment
MON+B:999.00:SGD+T:1999.99:SGD' Base and total fare
TXD++99.99::SGD:BK+99.99::SGD:OO+99.90::SGD:SG+99.99::SGD:WY+99.99::SG Tax details
D:OP+99.99::SGD:AU+99.99::SGD:WG+99.99::SGD:WY'
DAT+710:230513:2124' Date of payment
FOP+CA::1999.99' Cash form of payment
TVL+280513:2225:290513:0750+SIN+OOL+TZ+0006:S' First flight (TZ006 SIN-OOL 28MAY13)
RPI+1+HK' 1 passenger confirmed
TVL+310513:0900:310513:1500+OOL+SIN+TZ+0005:S' Second flight (TZ005 OOL SIN 31MAY13)
RPI+1+HK' 1 passenger confirmed
ABI+4++++TZ' History item #1 by TZ user/system
DAT+T:230513:1813' Action taken 23MAY 18 :13Z
SAC+++X' Action was cancellation
IFT+4:19+XF MC 0 VANDENBERG KEVIN 20 00' History item system-specific details
ABI+4++++TZ' History Item #2 by TZ user/system
DAT+T:230513:1829' Action taken 23MAY 18:29Z
SAC+++X' Action was cancellation
IFT+4:19+ F 28MAY13 SIN OOL 2225 0750 TZ 6 HK SFLY 590 82' History item system-specific details
TVL+280513::290513+SIN+OOL+TZ+0006:S' Canceled item was flight TZ006 in S class
RPI+1+HK' For a party of 1
SAC+++X' Action was cancellation
IFT+4:19+ F 31MAY13 OOL SIN 0900 1500 TZ 5 HK SFLY 582 81' History item system-specific details
TVL+310513::310513+OOL+SIN+TZ+0005:S' Canceled item was flight TZ005 in S class
RPI+1+HK' For a party of 1
ABI+4++++TZ' History item #3 by TZ user/system
DAT+T:230513:2124' Action taken 23MAY13 at 21:24Z
SAC+++A' Action to add content
IFT+4:19+ P CA 1 173 63 SGD' History item system-specific details
SAC+++A' Action to add content
IFT+4:19+ F 28MAY13 SIN OOL 2225 0750 TZ 6 HK SFLY 590 82' History item system-specific details
TVL+280513::290513+SIN+OOL+TZ+0006:S' Added item was flight TZ006 in S class
RPI+1+HK' For a party of 1
SAC+++A' Action to add content
IFT+4:19+ F 31MAY13 OOL SIN 0900 1500 TZ 5 HK SFLY 582 81' History item system-specific details
TVL+310513::310513+OOL+SIN+TZ+0005:S' Added item was flight TZ005 in S class
RPI+1+HK' For a party of 1
SRC' 2nd PNR
RCI+TZ:D1RGHI::230513:183845' Airline locator D1RGHI, created 23 May 2013 at 18:38Z
DAT+700:230513:1838+710:230513:1838' Last modified 23 May 13 at 18:38Z
Paid 23 May 13 at 18:38
ORG+TZ:SYS+++++:SGD' Booking originated by a TZ system user
ADD++700:9874 HILLY DRIVE:ST LOUIS:MO::US:63124:H5555551212 ' Reservation contact information including address and
telephone numbers
TIF+DYE+DOLANMR:A:43577' First Passenger (Adult) name and Unique ID
FTI+RI:438QZ99' Frequent traveler information
REF+:43577' Security related unique ID
FAR+A+23++++SFLY+SFLY' Adult fare with fare basis codes
SSR+DOCS:HK:1:TZ:::::/P/USA/159264375/USA/01FEB90/M/20NOV19/DYE/DOLA Passport details
N+::43577'
SSR+DOCA:HK:1:TZ:::::/D/AUS/13 SHORE Destination address
AVENUE/BROADBEACH/QLD/4215+::43577'
TKT+:702' Externally Issued E-ticket
MON+B:999.99:SGD+T:1999.99:SGD' Base and Total fare
TXD++99.99::SGD:BK+99.99::SGD:OO+99.99::SGD:SG+99.99::SGD:WY+99.99::SG Tax details
83
 PADIS EDIFACT Implementation Guide – PNRGOV Message

D:OP+99.99::SGD:AU+99.99::SGD:WG+99.99::SGD:WY'
DAT+710:230513:1838' Date of most recent payment
FOP+CA::9999.99' Payment was in cash
TIF+DYE+KAYLAMS:A:43578:1' Second Passenger (Adult) name and Unique ID. Passenger
is accompanied by an infant in lap
REF+:43578' Security related unique ID
FAR+A+20++++SFLY+SFLY' Adult fare with fare basis codes
SSR+DOCS:HK:1:TZ:::::/P/USA/345678901/USA/07APR93/F/15DEC18/DYE/KAYLA Passport details
+::43578'
SSR+DOCA:HK:1:TZ:::::/D/AUS/13 SHORE Destination address details
AVENUE/BROADBEACH/QLD/4215+::43578'
TKT+:702' Externally Issued E-ticket
MON+B:999.99:SGD+T:1999.99:SGD' Base and Total fare
TXD++99.99::SGD:BK+99.99::SGD:OO+99.99::SGD:SG+99.99::SGD:WY+99.99::SG Tax details
D:OP+99.99::SGD:AU+99.99::SGD:WG+99.99::SGD:WY'
DAT+710:230513:1838' Date and time of payment
TIF+DYE+ARCHER:IN:43578I' Third passenger (infant) name and unique ID
REF+:43578I' Security related unique ID
FAR+IN+1' Infant fare was applied
SSR+DOCS:HK:1:TZ:::::/P/USA/654321987/USA/15APR12/MI/31DEC19/DYE/ARCH Passport details
ER+::43578I'
TKT+:702' Externally Issued E-ticket
TVL+270513:1915:280513:1505+LHR+SIN+BA+0011:L' First Flight (BA 0011 in L class) (informational)
RPI+2+HK' Confirmed for 2 seats
TVL+280513:2225:290513:0750+SIN+OOL+TZ+0006:S' Second Flight (TZ0006 in S class)
RPI+2+HK' Confirmed for 2 seats
SSR+SEAT:HK:1:TZ:::SIN:OOL+54A::43577:N' Passenger 1 is in seat 54A
SSR+SEAT:HK:1:TZ:::SIN:OOL+54B::43578:N' Passenger 2 is in seat 54B
SSR+TKNE:HK:1:TZ:::SIN:OOL:9631270001234C2+::43577' Passenger 1 e-ticket and coupon numbers
SSR+TKNE:HK:1:TZ:::SIN:OOL:9631270001235C2+::43578' Passenger 2 e-ticket and coupon numbers
SSR+TKNE:HK:1:TZ:::SIN:OOL:INF9631270001236C2+::43578I' Infant e-ticket and coupon numbers
SSR+SPEQ:HK:1:TZ:::SIN:OOL+::43577' Passenger 1 has sports equipment
SSR+IFET:HK:1:TZ:::SIN:OOL+::43578' Passenger 2 ordered In-Flight entertainment
SSR+INFT:HK:1:TZ:::SIN:OOL:DYE/ARCHER 15APR12+::43578' Passenger 2 has an infant in arms on this flight
TVL+050613:0900:050613:1500+OOL+SIN+TZ+0005:S' Third flight (TZ0005 in S class)
RPI+2+HK' Confirmed for 2 seats
SSR+SEAT:HK:1:TZ:::OOL:SIN+54A::43577:N' Passenger 1 is in seat 54A
SSR+SEAT:HK:1:TZ:::OOL:SIN+54B::43578:N' Passenger 2 is in seat 54B
SSR+TKNE:HK:1:TZ:::OOL:SIN:9631270001234C3+::43577' Passenger 1 e-ticket and coupon numbers
SSR+TKNE:HK:1:TZ:::OOL:SIN:9631270001235C3+::43578' Passenger 2 e-ticket and coupon numbers
SSR+TKNE:HK:1:TZ:::OOL:SIN:INF9631270001236C3+::43578I' Infant e-ticket and coupon numbers
SSR+SPEQ:HK:1:TZ:::OOL:SIN+::43577' Passenger 1 has sports equipment
SSR+IFET:HK:1:TZ:::OOL:SIN+::43578' Passenger 2 ordered in-flight entertainment
SSR+INFT:HK:1:TZ:::OOL:SIN:DYE/ARCHER 15APR12+::43578' Passenger 2 has an infant in arms on this flight
TVL+050613:2255:060613:0500+SIN+LHR+BA+0012:D' Fourth flight (BA 0012 in D class) (informational)
RPI+2+HK' Confirmed for 2 seats
SRC' 3rd PNR
RCI+TZ:GBFKSK::230513:184819' Airline locator GBFKSK, created 23MAY13 at 18:48Z
DAT+700:230513:1849' Last modified 23 May 2013 at 18:49
No payments received
ORG+TZ:SYS+++++:SGD' Originated by a TZ System user
ADD++700:2431 MOPAC EXPRESSWAY:AUSTIN:TX::US:78750:H5125551212 ' Booking contact address and phone number
TIF+ACME TEAM PARTY:G' Group Name for Group PNR
TIF+CAPSON+LISALMS:A:43579' First name received. Adult passenger with Unique ID
REF+:43579' Security-related unique ID
FAR+A+++++ZSCTBIZ+SFLY' Adult fare will be used with included fare basis codes
TKT+:700' No ticket information is received
MON+B:999.99:SGD+T:1999.99:SGD' Base and total fare to be collected
TXD++99.99::SGD:BK+99.99::SGD:OO+99.99::SGD:SG+99.99::SGD:WY+99.99::SG Tax details
D:OP+99.99::SGD:AU+99.99::SGD:WG+99.99::SGD:WY'
TIF+CAPSON+HUNTER:A:43580' Second name received. Adult passenger with Unique ID
REF+:43580' Security-related unique ID
FAR+A+21++++ZSCTBIZ+SFLY' Adult fare will be used with included fare basis codes
SSR+DOCS:HK:1:TZ::::://///27APR92/M//CAPSON/HUNTER+::43580' Secure Flight Passenger Data
TKT+:700' No ticket information is received
MON+B:999.99:SGD+T:1999.99:SGD' Base and total fare to be collected
TXD++99.99::SGD:BK+99.99::SGD:OO+99.99::SGD:SG+99.99::SGD:WY+99.99::SG Tax details
D:OP+99.99::SGD:AU+99.99::SGD:WG+99.99::SGD:WY'
TIF+ALLEN+SETH:A:43581' Third name received. Adult passenger with Unique ID
REF+:43581' Security related unique ID
FAR+A+++++ZSCTBIZ+SFLY' Adult fare will be used with included fare basis codes
TKT+:700' No ticket information is received
MON+B:999.99:SGD+T:1999.99:SGD' Base and total fare to be collected
TXD++99.99::SGD:BK+99.99::SGD:OO+99.99::SGD:SG+99.99::SGD:WY+99.99::SG Tax details
D:OP+99.99::SGD:AU+99.99::SGD:WG+99.99::SGD:WY'
TIF+TBA+C:A:43582' Fourth name TBA
REF+:43582'
FAR+A+++++ZSCTBIZ+SFLY' Adult fare quote
TKT+:700' No ticket information is received
MON+B:999.99:SGD+T:1999.99:SGD' Base and total fare to be collected
TXD++99.99::SGD:BK+99.99::SGD:OO+99.99::SGD:SG+99.99::SGD:WY+99.99::SG Tax details
D:OP+99.99::SGD:AU+99.99::SGD:WG+99.99::SGD:WY'
TIF+TBA+D:A:43583' Fifth name TBA
REF+:43583'
FAR+A+++++ZSCTBIZ+SFLY' Adult fare quote
TKT+:700' No ticket information is received

84
 PADIS EDIFACT Implementation Guide – PNRGOV Message

MON+B:999.99:SGD+T:1999.99:SGD' Base and total fare to be collected

TXD++99.99::SGD:BK+99.99::SGD:OO+99.99::SGD:SG+99.99::SGD:WY+99.99::SG Tax details
D:OP+99.99::SGD:AU+99.99::SGD:WG+99.99::SGD:WY'
TIF+TBA+E:A:43584' Sixth name TBA
REF+:43584'
FAR+A+++++ZSCTBIZ+SFLY' Adult fare quote
TKT+:700' No ticket information is received
MON+B:999.99:SGD+T:1999.99:SGD' Base and total fare to be collected
TXD++99.99::SGD:BK+99.99::SGD:OO+99.99::SGD:SG+99.99::SGD:WY+99.99::SG Tax details
D:OP+99.99::SGD:AU+99.99::SGD:WG+99.99::SGD:WY'
TIF+TBA+F:A:43585' Seventh name TBA
REF+:43585'
FAR+A+++++ZSCTBIZ+SFLY' Adult fare quote
TKT+:700' No ticket information is received
MON+B:999.99:SGD+T:1999.99:SGD' Base and total fare to be collected
TXD++99.99::SGD:BK+99.99::SGD:OO+99.99::SGD:SG+99.99::SGD:WY+99.99::SG Tax details
D:OP+99.99::SGD:AU+99.99::SGD:WG+99.99::SGD:WY'
TIF+TBA+G:A:43586' Eighth name TBA
REF+:43586'
FAR+A+++++ZSCTBIZ+SFLY' Adult fare quote
TKT+:700' No ticket information is received
MON+B:999.99:SGD+T:1999.99:SGD' Base and total fare to be collected
TXD++99.99::SGD:BK+99.99::SGD:OO+99.99::SGD:SG+99.99::SGD:WY+99.99::SG Tax details
D:OP+99.99::SGD:AU+99.99::SGD:WG+99.99::SGD:WY'
TIF+TBA+H:A:43587' Ninth name TBA
REF+:43587'
FAR+A+++++ZSCTBIZ+SFLY' Adult fare quote
TKT+:700' No ticket information is received
MON+B:999.99:SGD+T:1999.99:SGD' Base and total fare to be collected
TXD++99.99::SGD:BK+99.99::SGD:OO+99.99::SGD:SG+99.99::SGD:WY+99.99::SG Tax details
D:OP+99.99::SGD:AU+99.99::SGD:WG+99.99::SGD:WY'
TVL+280513:2225:290513:0750+SIN+OOL+TZ+0006:Z' First flight (TZ0006 in Z class)
RPI+9+HK' Confirmed for 9 passengers
TVL+170613:0900:170613:1500+OOL+SIN+TZ+0005:S' Second flight (TZ0005 in S class)
RPI+9+HK' Confirmed for 9 passengers
ABI+4++++TZ' History credit by TZ system/user
DAT+T:230513:1849' Action taken on 23 May 2013 at 18:49
SAC+++C' Action taken was to Change
IFT+4:19+GN FROM NONE TO ACME TEAM PARTY' System-specific details
UNT+173+00102181551362'
UNE+1+00102181551362'
UNZ+1+00102181551362'

85
 PADIS EDIFACT Implementation Guide – PNRGOV Message

6 Example with one adult and an Infant

In this example the PNRGOV message is sent 24 hours prior to departure for AM flight (MTY-LAS), containing one
PNR booked by AM.

Assumptions:
- Mexico requires PNRGOV messages both for outbound and inbound flights
- 24h trigger used- no check-in data present
- No history and ticketing data (only TKNE SSRs) present-Phase 2

UNA:+.?*'
UNB+IATA:1+AM+MXPNRGOV+130522:1540+13052210400995+PNRGOV' Interchange header-sender/receiver/date
UNG+PNRGOV+AM+MXPNRGOV+130522:1540+13052210400995+IA+11:1' Functional group header
UNH+13052210400995+PNRGOV:11:1:IA+AM498/230513/1142' Message header
MSG+:22' Code to specify the message function
ORG+AM' The originator of the request is AM
TVL+230513:1039:230513:1142+MTY+LAS+AM+498' PNR data for AM498/23MAY13 MTY LAS
EQN+1' Total numbers of PNRs
SRC'
RCI+AM:XXXYET::300413:115500' Passenger record reference
SSR+OTHS:::::::: ADV TKT NUMBER BY 03MAY13 1800CO OR WILL CANCEL' Special requirements /general information-applies to all
SSR+OTHS:::::::: IF THE FARE RULE TL DIFFERS FROM THE AUTOMATIC' Flights and all passengers
SSR+OTHS:::::::: TL THE MOST RESTRICTIVE TL WILL APPLY'
DAT+700:180513:1502' Ticket issue / last PNR transaction date/Time
ORG+AM:BOG' Booked by AM, BOG agent
TIF+TESTSURNAMEONE+TESTNAMEONE MRS:A:1.1:1' Adult passenger’s name & surname
SSR+INFT:NN:1:AM:::::TESTSURNAMETWO/TESTNAMETWO/10AUG11+::1.1' Infant information: surname/name/DOB
SSR+INFT:NN:1:AM:::::TESTSURNAMETWO/TESTNAMETWO/10AUG11+::1.1' Infant information: surname/name/DOB
SSR+TKNE:HK:1:AM:::MEX:CUN:1392178947000C2+::1.1' Ticketing details for adult MEX CUN
SSR+TKNE:HK:1:AM:::CUN:BOG:1392178947000C3+::1.1' Ticketing details for adult CUN BOG
SSR+TKNE:HK:1:AM:::MEX:CUN:INF1392178947000C2+::1.1' Ticketing details for infant MEX CUN
SSR+TKNE:HK:1:AM:::CUN:BOG:INF1392178947000C3+::1.1' Ticketing details for infant CUN BOG
SSR+DOCS:HK:1:AM:::::/P/CO/52263000/CO/30MAY76/F/31OCT15/TESTSURNAM Passport information for adult
EONE/TESTNAMEONE MRS+::1.1'

TIF+TESTSURNAMETWO+TESTNAMETWO:IN:2.1' Infant passenger’s name & surname

IFT+4:28+AM INF' OSI free text information
SSR+DOCS:HK:1:AM:::::/P/COL/AO234000/COL/10AUG11/FI/21DEC22/TESTSURN
AMETWO/TESTNAMETWO+::2.1'
TVL+150513:0105:150513:0557+BOG+MEX+AM+709:R' PNR data for AM709/15MAY13 BOG MEX
RPI+1+YG' Flight booking status for 1 adult passenger
APD+737' Equipment Type- Boeing 737
RCI+AM:XXXYET::300413:115500' AM passenger record reference
TVL+190513:1500:190513:1710+MEX+CUN+AM+445:S' PNR data for AM445/19MAY13 MEX CUN
RPI+1+HK' Flight booking status for 1 adult passenger
APD+738' Equipment Type
SSR+INFT:NN:1:AM:::::TESTSURNAMETWO/TESTNAMETWO/10AUG11' Infant information: surname/name/DOB
SSR+TKNE:HK:1:AM:::MEX:CUN:1392178947000C2' Ticketing details for adult MEX CUN
SSR+TKNE:HK:1:AM:::MEX:CUN:INF1392178947000C2' Ticketing details for infant MEX CUN
RCI+AM:XXXYET::300413:115500' AM passenger record reference
TVL+230513:0135:230513:0500+CUN+BOG+AM+718:Q' PNR data for AM718/23MAY13 CUN BOG
RPI+1+HK' Flight booking status for 1 passenger
APD+737' Equipment Type
SSR+INFT:NN:1:AM:::::TESTSURNAMETWO/TESTNAMETWO/10AUG11' Infant information: surname/name/DOB
SSR+TKNE:HK:1:AM:::CUN:BOG:1392178947000C3' Ticketing details for adult CUN BOG
SSR+TKNE:HK:1:AM:::CUN:BOG:INF1392178947000C3' Ticketing details for infant CUN BOG
RCI+AM:XXXYET::300413:115500' AM passenger record reference
UNT+42+13052210400995’ Message trailer corresponding UNH segment
UNE+1+13052210400995’ Functional group trailer corresponding UNG
UNZ+1+13052210400995’ Interchange trailer

86
 PADIS EDIFACT Implementation Guide – PNRGOV Message

7 PNR with Frequent Traveler (2 adults) and PNR split

In this example the PNRGOV message is sent 24 hours prior to departure for AM flight (MTY-LAS).

Assumptions:
- Mexico requires PNRGOV messages both for outbound and inbound flights
- 24h trigger used- no check-in data present
- No history and ticketing data (only TKNE SSRs) present-Phase 2

UNA:+.?*'
UNB+IATA:1+AM+MXPNRGOV+130522:1540+13052210400995+PNRGOV' Interchange header-sender/receiver/date
UNG+PNRGOV+AM+MXPNRGOV+130522:1540+13052210400995+IA+11:1' Functional group header
UNH+13052210400995+PNRGOV:11:1:IA+AM498/230513/1142' Message header
MSG+:22' A code to specify the message function
ORG+AM' The originator of the request is AM
TVL+230513:1039:230513:1142+MTY+LAS+AM+498' PNR data for AM498/23MAY13 MTY LAS
EQN+2' Total numbers of PNRs
SRC'
RCI+AM:ICOXXX::120413:175500' AM passenger record reference
DAT+700:120413:2044' Ticket issue / last PNR transaction date/Time
IFT+4:28+AM 045 81 8396 0000/TESTNAMEONE TESTSURNAMEONE' OSI free text information- contact details
IFT+4:28+AM PNR UNDER AM TRAVEL UNIT LT Q/000'
IFT+4:28+AM CTCP MEX1800 002 5200 DOMESTIC TOLL FREE'
IFT+4:28+AM CTCP MEX1866 252 5200 USA AND CAN TOLL FREE'
IFT+4:28+AM CTCP MEX52 55 4446 0000 FAX'
IFT+4:28+AM CTCH MEX01 81 8336 6900 H'
IFT+4:28+AM CTCP MEX045 81 8396 1000 M'
ORG+AM:TTY' Booked by AM, TTY agent
TIF+TESTSURNAMEONE+TESTNAMEONE MRS:A:1.1' 1st adult passenger’s name & surname
FTI+AM:511650000' Frequent traveler information (airline/no.)
SSR+TKNE:HK:1:AM:::MTY:LAS:1393207166000C1+::1.1' Ticketing details for 1st adult MTY LAS
SSR+TKNE:HK:1:AM:::LAS:MTY:1393207166000C2+::1.1' Ticketing details for 1st adult LAS MTY
TIF+TESTSURNAMEONE+TESTNAMETWO MR:A:2.1' 2nd adult passenger’s name & surname
SSR+TKNE:HK:1:AM:::MTY:LAS:1393207166000C1+::2.1' Ticketing details for 2nd adult MTY LAS
SSR+TKNE:HK:1:AM:::LAS:MTY:1393207166000C2+::2.1' Ticketing details for 2nd adult LAS MTY
TVL+230513:1039:230513:1142+MTY+LAS+AM+498:A' PNR data for AM498/23MAY13 MTY LAS
RPI+2+HK' Flight booking status for 2 adult passengers
APD+738' Equipment Type
SSR+SEAT:DK:2:AM:::MTY:LAS:.03BN03AN' Seat information for MTY LAS for 2pax
SSR+TKNE:HK:1:AM:::MTY:LAS:1393207166000C1' Ticketing details for MTY LAS
SSR+TKNE:HK:1:AM:::MTY:LAS:1393207166000C1' Ticketing details for MTY LAS
RCI+AM:ICOXXX::120413:175500' AM passenger record reference
TVL+260513:1311:260513:1800+LAS+MTY+AM+499:A' PNR data for AM499/26MAY13 LAS MTY
RPI+2+HK' Flight booking status for 2 adult passengers
APD+738' Equipment Type
SSR+SEAT:DK:2:AM:::LAS:MTY:.03BN03AN' Seat information for LAS MTY for 2 passengers
SSR+TKNE:HK:1:AM:::LAS:MTY:1393207166000C2' Ticketing details for MTY LAS
SSR+TKNE:HK:1:AM:::LAS:MTY:1393207166000C2' Ticketing details for MTY LAS
RCI+AM:ICOXXX::120413:175500' AM passenger record reference
SRC'
RCI+AM:BJOXXX::110513:114800' AM passenger record reference
DAT+700:190513:0521' Ticket issue / last PNR transaction date/Time
IFT+4:28+AM CTCBOG 571-600 5820-A-COTOURIST COLOMBIA' OSI free text information
IFT+4:28+AM CTCT BOG 571 600 5830 A'
IFT+4:28+AM CTCP BOG 571 600 5820 A PBX'
IFT+4:28+AM RLOC HDQ1SYDIXXZ'
ORG+AM:TTY' Booked by AM, TTY agent
TIF+TESTSURNAMETHREE+TESTNAMETHREE MR:A:1.1' Adult passenger’s name & surname
SSR+TKNE:HK:1:AM:::BOG:CUN:.1393534576000C1+::1.1' Ticketing details for BOG CUN
SSR+TKNE:HK:1:AM:::CUN:BOG:.1393534576000C2+::1.1' Ticketing details for BOG CUN
SSR+DOCS:HK:1:AM:::::/P/CO/AO589000/CO/14OCT94/M/08MAY23/TESTSURNA Passport information
METHREE/TESTNAMETHREE+::1.1'
SSR+CKIN:NN:1::::::WEBCHKIN+::1.1' Check-in information SSR data
SSR+CKIN:NN:1::::::BAGS TO CHECK 1+::1.1' Check-in information SSR data
TVL+190513:0700:190513:1030+BOG+CUN+AM+719:V' PNR data for AM719/19MAY13 BOG CUN
RPI+1+HK' Flight booking status for 1 adult passenger
APD+738' Equipment Type
SSR+TKNE:HK:1:AM:::BOG:CUN:.1393534576000C1' Ticketing details for BOG CUN
RCI+AM:BJOXXX::110513:114800' AM passenger record reference
TVL+230513:0135:230513:0500+CUN+BOG+AM+718:V' PNR data for AM718/23MAY13 CUN BOG
RPI+1+HK' Flight booking status for 1 passenger
APD+737' Equipment Type
SSR+TKNE:HK:1:AM:::CUN:BOG:.1393534576000C2' Ticketing details CUN BOG
RCI+AM:BJOXXX::110513:114800' AM passenger record reference-new PNR
EQN+1' Split
RCI+AM:ZLMXXX::110513:114800' AM passenger record reference-original (split from)PNR
UNT+64+13052210400995’ Message trailer corresponding UNH segment
UNE+1+13052210400995’ Functional group trailer corresponding UNG
UNZ+1+13052210400995’ Interchange trailer

87
 PADIS EDIFACT Implementation Guide – PNRGOV Message

8 Coordination of MSG and EQN to Denote Type and Scope of Message

All amounts have been neutralized to ensure there is no hint of price sensitivity. All passenger and address data is
fictitious.
The following examples indicate the combination of MSG and EQN Segments in PNRGOV messages:
- Data element 1225 of composite C302 in the MSG segment is used to indicate whether the transmission is a Full
transmission of all PNR data for a flight (22), or changed PNRs only (141).
- Data element 6350 of composite C523 in the EQN segment is used to indicate the number of PNRs transmitted
in the message

The combination of the values in these two elements can be used to indicate several conditions:

Example 1: A transmission is made for a flight that has no passengers (no PNRs) or to represent a cancelled flight

UNB+IATA:1+TZ+AUCBPS+130523:2210+00102181551362'
UNG+PNRGOV+TZ+AUCBPS+130523:2210+00102181551362+IA+11:1'
UNH+00102181551362+PNRGOV:11:1:IA+AUTZ000623052013221001SIN20130528'
MSG+:22' PNR Data to State (full push)
ORG+TZ:MSP+++TZ:SYS+++HOLMESS'
TVL+280513:2225:290513:0750+SIN+OOL+TZ+0006' For flight TZ 0006 from SIN to OOL
EQN+0' No PNRs on flight
UNT+6+00102181551362'
UNE+1+00102181551362'
UNZ+1+00102181551362'

Example 2: There are no updated PNRs since the previous transmission for this flight

UNB+IATA:1+TZ+AUCBPS+130523:2210+00102181551362'
UNG+PNRGOV+TZ+AUCBPS+130523:2210+00102181551362+IA+11:1'
UNH+00102181551362+PNRGOV:11:1:IA+AUTZ000623052013221001SIN20130528'
MSG+:141' PNR Data to State (update)
ORG+TZ:MSP+++TZ:SYS+++HOLMESS'
TVL+280513:2225:290513:0750+SIN+OOL+TZ+0006' For flight TZ 0006 from SIN to OOL
EQN+0' 0 PNRs updated
UNT+6+00102181551362'
UNE+1+00102181551362'
UNZ+1+00102181551362'

Example 3: A single PNR has been updated since the previous transmission for this flight (multiple PNRs exist)

UNB+IATA:1+TZ+AUCBPS+130523:2210+00102181551362'
UNG+PNRGOV+TZ+AUCBPS+130523:2210+00102181551362+IA+11:1'
UNH+00102181551362+PNRGOV:11:1:IA+AUTZ000623052013221001SIN20130528'
MSG+:141' PNR Data to State (update)
ORG+TZ:MSP+++TZ:SYS+++HOLMESS'
TVL+280513:2225:290513:0750+SIN+OOL+TZ+0006' For flight TZ 0006 from SIN to OOL
EQN+1' 1 PNR updated
SRC' Start of 1st PNR
RCI+TZ:W9TEND::230513:181348' Airline locator W9TEND, created 23 May 2013 at 18:13Z
DAT+700:230513:2125+710:230513:2124' Last modified 23 May 2013 at 21:25Z
Payment made 23 May 2013 at 21:24Z
ORG+TZ:SYS+++++:SGD'
ADD++700:123 ANY STREET:LAKE TOWN:MN::US:55123:H5555555555 W 1 555 555
5555 '
TIF+VANDENBERG+KEVINMICHAELMR:A:43576'
REF+:43576'
FAR+A+32++++SFLY+SFLY'
SSR+DOCS:HK:1:TZ:::::/P/USA/548721687/USA/04JUL80/M/12JAN19/VANDENBERG/
KEVIN/MICHAEL+::43576'
TKT+:700'
MON+B:999.00:SGD+T:1999.99:SGD'
TXD++99.99::SGD:BK+99.99::SGD:OO+99.90::SGD:SG+99.99::SGD:WY+99.99::SGD:
OP+99.99::SGD:AU+99.99::SGD:WG+99.99::SGD:WY'
DAT+710:230513:2124'
FOP+CA::1999.99'
TVL+280513:2225:290513:0750+SIN+OOL+TZ+0006:S'
RPI+1+HK'
TVL+310513:0900:310513:1500+OOL+SIN+TZ+0005:S'
RPI+1+HK'
ABI+4++++TZ' History item #1 by TZ user/system

88
 PADIS EDIFACT Implementation Guide – PNRGOV Message

DAT+T:230513:1813' Action taken 23MAY 18 :13Z

SAC+++X' Action was cancellation
IFT+4:19+XF MC 0 VANDENBERG KEVIN 20 00' History item system-specific details
ABI+4++++TZ' History Item #2 by TZ user/system
DAT+T:230513:1829' Action taken 23MAY 18:29Z
SAC+++X' Action was cancellation
IFT+4:19+ F 28MAY13 SIN OOL 2225 0750 TZ 6 HK SFLY 590 82' History item system-specific details
TVL+280513::290513+SIN+OOL+TZ+0006:S' Canceled item was flight TZ006 in S class
RPI+1+HK' For a party of 1
SAC+++X' Action was cancellation
IFT+4:19+ F 31MAY13 OOL SIN 0900 1500 TZ 5 HK SFLY 582 81' History item system-specific details
TVL+310513::310513+OOL+SIN+TZ+0005:S' Canceled item was flight TZ005 in S class
RPI+1+HK' For a party of 1
ABI+4++++TZ' History item #3 by TZ user/system
DAT+T:230513:2124' Action taken 23MAY13 at 21:24Z
SAC+++A' Action to add content
IFT+4:19+ P CA 1 173 63 SGD' History item system-specific details
SAC+++A' Action to add content
IFT+4:19+ F 28MAY13 SIN OOL 2225 0750 TZ 6 HK SFLY 590 82' History item system-specific details
TVL+280513::290513+SIN+OOL+TZ+0006:S' Added item was flight TZ006 in S class
RPI+1+HK' For a party of 1
SAC+++A' Action to add content
IFT+4:19+ F 31MAY13 OOL SIN 0900 1500 TZ 5 HK SFLY 582 81' History item system-specific details
TVL+310513::310513+OOL+SIN+TZ+0005:S' Added item was flight TZ005 in S class
RPI+1+HK' For a party of 1
UNT+50+00102181551362'
UNE+1+00102181551362'
UNZ+1+00102181551362'

89
 PADIS EDIFACT Implementation Guide – PNRGOV Message

APPENDIX C – PADIS EDIFACT Message Processing - Background for PNRGOV Users

1 INTRODUCTION
This document is intended to provide guidance to airlines, System Suppliers and States who are implementing the
PNRGOV message. The information contained in this document should be utilized in conjunction with the current
PNRGOV implementation Guide. This document is a living document and will be updated for any future requirements /
principles as agreed by the Working Group.

The PNRGOV message is designed to comply with States’ Legislation for the provision of PNR data from Carriers. Its
receipt and processing by a State may be acknowledged with an ACKRES message. However there are certain cases
when it is appropriate to return a CONTRL message.

1.1 Purpose
The purpose of this document is to clearly define the recommended method for handling the interchange of PNRGOV
messages including the use of ACKRES and CONTRL messages for the acknowledgement of message transfer and
processing status.

1.2 Scope
The scope of this document is to provide relevant information in conjunction with the implementation guide to ensure a
consistent approach to implementation. It will also identify, where necessary, any bilateral agreements that need to be
implemented for the usage of the PNRGOV, ACKRES and CONTRL messages.

1.3 Background
The PNRGOV message has been developed under the auspices of the PADIS Board. The message structure and the
contents of the message are designed to provide a consistent approach for all Carriers required to provide PNR
information to States. In order to provide a mechanism to acknowledge receipt and/or processing of a message, the
ACKRES message has also been defined. This message may be sent by a State to a Carrier by bilateral agreement.
The basis for the PNRGOV messages is PADIS EDIFACT, which in turn is based on UN EDIFACT (ISO 9735). PADIS
EDIFACT also defines the CONTRL message as a mechanism that can be used to acknowledge receipt and indicate
processing status of a message interchange.
This document discusses common use of CONTRL as opposed to functional response messages (e.g. ACKRES) in the
airline industry, and makes recommendations for handling PNRGOV interchanges in a consistent manner.

1.4 References
PADIS Codeset Directory
PADIS Message Standards
ISO 9735

1.5 Assumptions and Constraints

1.5.1 Assumptions
It is assumed that PNRGOV processing will be handled largely asynchronously based on exchange with a queuing
technology. However other technologies may be used for message exchange (transport), such as web services, IATA
Host-to-Host, etc. It is equally possible that completion of the message exchange indicates only receipt of the message, or
also its processing.
Any technology used for transport of messages may or may not provide message delivery assurance / acknowledgement
outside of the EDIFACT layer. Any such delivery assurance provided by those layers may be acceptable (as per bilateral
agreement between the Carrier and the State) and is beyond the scope of this document.
If message interchange acknowledgement and processing status is desired in lieu of or in addition to that provided by the
underlying transport, it is recommended that it is handled as described in this document.

1.5.2 Constraints
 The protocol for message delivery depends on the capability of the States and Carriers. The protocol to be used
is agreed on a bilateral basis.

90
 PADIS EDIFACT Implementation Guide – PNRGOV Message

 The software architecture used by each Carrier and State may vary in its handling of each layer of the EDIFACT
messages. Variances in architectures may contribute to an organization’s ability to generate specific
acknowledgement types.
 Individual State legislation may drive specific functional requirements for handling of acknowledgements.
Acknowledgment of Receipt may or may not indicate Successful Processing of the message. Definitions of
Receipt, Processing Status and Rejection must be clear such that the Carrier can react appropriately.

1.6 Document Overview

This document addresses 3 key areas for the acknowledgement of receipt/processing. These are:
1. EDIFACT Envelope Structure – This section provides a brief overview of the EDIFACT envelope
structure and the purpose of each envelope.
2. Parsing & Processing Steps – This section identifies the steps that should be taken to parse and process an
incoming EDIFACT message as the envelopes are opened.
3. Acknowledgement Recommendations – This section provides recommendations for acknowledgement of
receipt or rejection and processing status using CONTRL and ACKRES.

91
 PADIS EDIFACT Implementation Guide – PNRGOV Message

2 EDIFACT Envelope Structure

ISO 9735 defines EDIFACT message structure as a combination of:

1. A conditional Service String Advice (UNA) - a fixed length structure required at the beginning of the message
only if non-standard delimiter characters are used.
2. Service Segments (UNB-UNZ) – a set of segments used to envelope the interchange itself, functional groups of
messages within an interchange, and each individual message.
3. User Data Segments – functional segments as required comprising each individual message.

Figure 1 - EDIFACT Interchange Structure

2.1 The Interchange Envelope

An Interchange begins with an Interchange Header (UNB) segment and ends with an Interchange Trailer (UNZ) segment,
providing the outermost envelope in an EDIFACT interchange. The purpose of the Interchange Envelope is to identify
the transmission attributes of the entire interchange unit. These attributes include:

 The Syntax and Version of the Interchange

 The sender and receiver of the interchange
 The date/time of preparation
 An Interchange Control Reference
The interchange itself may contain multiple independent messages (using the same syntax and version), which may be
placed into one or more interchange groups.
For PNRGOV, each interchange is expected to contain a single message. Therefore no message group identification is
required.

2.2 The Functional Group Envelope

Within an interchange, multiple individual messages may be grouped by function. When such grouping is required, the
Functional Group Header (UNG) and Functional Group Trailer (UNE) form an envelope around a related group of
individual messages. Since PNRGOV indicates only a single message per interchange, grouping is not required.
Therefore these segments are not used.

2.3 The Message Envelope

Each message in an interchange consists of a set of functional data segments wrapped in a Message Envelope.

 The Message Header segment (UNH) precedes the first functional segment in the message and indicates the
message type (e.g. PNRGOV), version and release (e.g. 11:1) and controlling agency (e.g. IA). It also may
contain a common access reference (CARF) that can be used to communicate a relationship among
messages.

92
 PADIS EDIFACT Implementation Guide – PNRGOV Message

 The Message Trailer segment (UNT) follows the last functional segment in the message and indicates the
number of segments in the message (both functional and envelope).

93
 PADIS EDIFACT Implementation Guide – PNRGOV Message

3 Parsing & Processing Steps

The service segments that comprise the interchange, group and message envelopes are versioned on a separate scheme
from the functional segments of the EDIFACT message. The syntax and version of the Interchange itself is contained in
the UNB segment. The structure (and version) of these segments rarely changes. This allows an application receiving an
EDIFACT interchange to be architected in a modular fashion in which common, non-functional logic may be used to
handle the service segments and determine the type, version and release of the message(s) contained within. Once the
message type, version and release have been determined, the message can be handed off to the appropriate logic module
for parsing and processing of the functional segments within the message.
After receipt of the interchange from the chosen transport layer, the receiving handler should process the interchange in
the following manner:

1. Determine if the interchange begins with a Service String Advice (UNA) segment.
This segment is used by a sender to define the characters selected for use as delimiters and indicators in the rest
of the interchange that follows (ISO 9735). If present, the 6 characters following the UNA tag should be used by
the receiving handler to parse the interchange. If not present, default delimiters and indicators should be used.
a. If there is an error processing the UNA and the receiving handler can identify the sender of the
interchange based on the transport, configuration or other means, it may elect to return a CONTRL
message to the sender. This CONTRL message would have to be quite generic (or hard-coded), as no
part of the interchange could actually be parsed or interpreted in order to properly populate a
corresponding CONTRL.
b. Note: Once the effective delimiter set has been determined, the handler may elect to parse the entire
interchange into a collection of segments, composites and elements. This allows validation of the
envelopes as well as the general structure of the interchange before invocation of functional logic.
2. Using the selected (default or modified by UNA) delimiters, parse the Interchange Header (UNB).
a. If there is a failure to parse a valid UNB, and the receiving handler can identify the sender of the
interchange as mentioned in 1.a. above, it may elect to return a CONTRL message to the sender.
b. Upon successful parsing of the UNB, the receiving handler can identify the interchange syntax and
version, interchange sender, interchange receiver, interchange generation date/time, and Interchange
Sender’s reference. These values may be validated against those obtained from configuration or
transport layer, or used to identify the sending and receiving systems for the interchange in order to
continue processing.
3. Continue parsing the Functional Group Header (UNG).
Although the PNRGOV implementation guide and message structure does not indicate the use of the Functional
Group envelope, the interchange headers may be processed on a messaging tier that handles various incoming
message types, others of which do use functional group headers.
a. If this is the case, then the handler may use values obtained from this functional group header for
further validation/processing.
b. If this is not the case, then the application may choose to ignore the UNG, or may choose to generate a
CONTRL message if one is encountered. When generating a CONTRL message in this case, the
Interchange envelope in the CONTRL message should contain values corresponding to the Interchange
envelope from the message received.

4. Continue parsing the Message Header (UNH).

This header will provide information about the message payload including its type (e.g. PNRGOV) version and
release (e.g. 11:1) as well as a common access reference. The handler should determine that the message type,
version and release are supported and message-type-specific handlers are available. It may also optionally
determine if the message type, version and release are expected from this interchange sender for this interchange
recipient (obtained from the UNB).

94
 PADIS EDIFACT Implementation Guide – PNRGOV Message

a. If the specific message type cannot or should not be processed or is otherwise unexpected, a CONTRL
message should be returned to the sender indicating the reason the message is being rejected (e.g.
version not supported, etc.)
5. Continue parsing the functional segments comprising the message.
A handler for the message-type-specific segments should be invoked on each segment encountered until the
Message Trailer (UNT) segment. Some architectures include message-specific parsing and structural validation
at the EDIFACT handler tier, while others defer that processing until a later phase or on another tier.

The UNT contains an element indicating the number of segments in the message (inclusive of UNH/UNT). This
value may be validated against the number of functional segments received.
a. Any errors in locating the UNT or parsing the functional segments due to delimiter/structural issues
should result in a CONTRL message being returned to the interchange sender. Code set 0085 includes
a number of specific errors that may be returned in the UCI and UCM segments. The UCI and UCM
segments also include elements in which the context of the error may be specified (e.g. tag name and
ordinal number of the segment having in which the error was encountered, etc.).
b. Please note that a CONTRL is not generally appropriate for indication of functional errors
encountered while processing the functional segments of message. If functional processing of the
message is invoked in-process, functional errors should return a functional response (e.g. ACKRES).
Errors in validation of syntax or structure (e.g. data type or field length violations) of the functional
segments may result in a CONTRL.
6. Hand the parsed data to the functional processing modules appropriate for the message.

This hand-off may be in-process or may be via a message queuing technology, etc. as architected by the State.
a. These modules may perform detailed transformation of the data into internal structures, and if they
encounter a structural error, may also return a CONTRL message to the interchange sender.
b. If no structural error is encountered, a CONTRL message indicating receipt or successful processing of
the interchange may be returned to the sender. However, this is not common practice if a functional
response message is available (ACKRES). It should only be considered if the EDIFACT handler tier is
handing off the message content for later processing by the application, and a more immediate
confirmation of receipt is required. In this case, the CONTRL message should only be considered as
acknowledgement of receipt, not of processing.
c. If no structural error is encountered and functional processing is expected to commence and complete
within a reasonable time frame, an ACKRES may be returned to the sender as a result of processing.
The ACKRES should indicate the processing status, such as having completed successfully or that the
message was rejected due to one or more specific errors.
d. The State may elect to send no acknowledgement at all. This may be appropriate if it has established
other means by which acknowledgement and status may be communicated (e.g. email, web site, etc.)
7. Process the next message in the interchange.
For PNRGOV, only one message per interchange is expected. However an inbound interchange being processed
by a common handler may contain additional messages.
8. Process the next functional group in the interchange.
For PNRGOV, functional groups are not applicable or expected. However an inbound interchange being
processed by a common handler may contain functional groups.

9. Wrap-up processing of the Interchange.

When all messages in all functional groups have been successfully parsed and handed off for processing,
interchange processing is complete.
a. Generation of a CONTRL message indicating an error may have been already performed due to one of
the error conditions mentioned above.
b. Generation of a CONTRL message indicating receipt and/or processing of the message may be
performed, but is not generally used for PADIS.
95
 PADIS EDIFACT Implementation Guide – PNRGOV Message

4 Acknowledgement Recommendations
PADIS standards deal with interactive messaging, in which a request/response pair of messages are exchanged
synchronously. The requesting application transmits the request message and synchronously waits for a response message
or an eventual time-out. It is always preferred to receive some form of response message rather than to require the
application to wait for a timeout period to expire.
Generally speaking, if there are any errors encountered in processing the service segments, the non-functional logic can
produce a CONTRL message indicating that there was a failure to hand the functional content off to the functional logic
module. However, if there are no errors in processing the envelope and the message is handed off to the functional logic,
then it is the responsibility of the functional logic to return an appropriate response message. In the case of PNRGOV,
that functional response message would be ACKRES.
While it is possible to use a CONTRL message to positively acknowledge receipt and/or processing of a PNRGOV
message, this practice is not commonly used in PADIS, especially when a functional response message is available. This
is particularly true in interactive scenarios since a 1:1 request/response pair is expected. If a CONTRL is sent as a
positive response, then the requesting system would have to receive a 2nd message containing the functional results from
the processing application. This practice results in redundant processing, extra I/O, increased bandwidth usage, etc.
PNRGOV, however, may not be handled as an interactive exchange. A State may not elect to send a functional response
in the form of an ACKRES, but still wish to convey acknowledgement of receipt of the PNRGOV message above and
beyond any acknowledgement provided by the transport layer. If the acknowledgment of receipt is strictly from a State’s
messaging tier, use of CONTRL may be acceptable. However if acknowledgement of receipt is from the State’s
application tier, use of ACKRES is still recommended.

4.1 Types of Acknowledgements

It is generally accepted that an interchange sender (Carrier) wishes to receive, and States wish to send message
acknowledgements in order to track processing and ensure interchanges are being processed as expected. However, there
are two main types of events that may be acknowledged. Acknowledgement of receipt of a message indicates that a State
has received the message for processing. Acknowledgement of Processing of the message implies receipt but also
indicates the status of functional processing.

4.1.1 Acknowledgement of Receipt

Acknowledgement of receipt of a message (or interchange) indicates a State has received the Carrier’s message. However
the architecture of the State’s system may take several forms. Therefore it is possible for receipt to need further
clarification. Receipt could mean a message has simply arrived at the facility, has passed validation of the envelope and
queued for functional processing, or has actually been received by the destination application. Any or all of these status
values may be of interest to the Carrier and State based on bilateral agreement.

4.1.2 Acknowledgement of Processing

Acknowledgement of Processing indicates that the State has processed the Carrier’s message. The acknowledgement
itself may indicate a processing status (e.g. success, warning, or failure). In order to be processed, the message has to
have been first received by the application. Therefore an acknowledgement of processing implies receipt of the message.
However, the definition of processing itself may be ambiguous. In this document, processing means any functional
processing performed by the State on the data received in the PNRGOV message.

4.2 Recommendations
The following table summarizes the recommendations for acknowledgement of receipt and processing in various
scenarios. Final decisions are up to each Carrier and State and should be bilaterally agreed upon. However these
recommendations provide guidance to Carriers and States looking to implement acknowledgment procedures.
Please note that although architectures vary, conceptually the EDIFACT message must first be received, parsed,
recognized and structurally validated. Then the message must be functionally processed. Although some States may
choose to do this in a single application, while others may separate the work, the table below separates the two functions
logically. Whichever application is handling the functions described in the second column of the table should generate
the recommended response.

96
 PADIS EDIFACT Implementation Guide – PNRGOV Message

Acknowledgement Processing Status Recommendation

Type Phase
Receipt Transport All Facilities available in the selected transport layer (e.g.
WebSphere MQ, S/FTP, Web Service, etc.) can be used to
acknowledge receipt of a message interchange by the State.
Such acknowledgment indicates only that the message has been
received. It does should not imply that it is valid (can be
parsed or processed) or has been parsed or processed.
Receipt Message Invalid
 A CONTRL message should be returned to the message
Router / Structure
sender assuming the sender can be determined.
EDIFACT (cannot be
Handler parsed)  To the extent possible, include any information from the
service segments of the received message in the service
segments of the CONTRL
 Populate the UCI with the most appropriate
ACTION,CODED and SYNTAX ERROR, CODED values
from code sets 0083 and 0085 respectively.
 If the Message Header (UNH) of the message received was
successfully parsed, include a UCM segment with S009
populated accordingly from the UNH of the received
message. Populate elements 0083 and 0085 as appropriate
based on the code sets. Generally 0083 should contain a
value of 4 (rejected). If possible also include:
 The tag of the invalid segment (e.g. TVL) in element 0013
o The position of the invalid element or composite in
S011
 Return of a CONTRL message with a value of 4 in element
0083 of a UCI or UCM indicates that the destination
application has not received or processed the message.
Receipt Message Invalid
 If the Interchange and Message envelopes are able to be
Router / Request or
parsed, but the message type or version is not supported or
EDIFACT Interchange
authorized for the interchange partner, a CONTRL message
Handler partner
should be returned. This condition should only occur due to
a system misconfiguration or disagreement between Carrier
and State.
 Populate the service segments of the CONTRL based on the
values contained in the service segments of the received
message
 Include a UCI segment containing the most appropriate
values for elements 0083 and 0085. The UCI should
indicate Interchange-level errors, if any. These include
invalid interchange recipient or sender.
 Include a UCM segment containing S009 populated based
on the corresponding fields from the UNH of the message
received. Populate elements 0083 and 0085 as appropriate
to indicate message-level errors. These include any syntax
or version errors, invalid control totals, etc.
 The UCM should contain a value of 4 in element 0083,
indicating that the message has been rejected and not
processed by the application.

97
 PADIS EDIFACT Implementation Guide – PNRGOV Message

Receipt Message Delivered to

 If the State’s architecture separates the message router from
Router / Application
the processing application, and business process dictates
Handler
that the State’s router should acknowledge that the message
has been received and forwarded to the application, a
CONTRL message should be returned to the sender.
 Populate the service segments of the CONTRL based on the
values contained in the service segments of the received
message.
 Include a UCI segment with element 0083 populated with
the value 8 – Interchange received. Element 0085 should
not be populated.
 Include a UCM segment containing S009 populated based
on the corresponding fields from the UNH of the message
received. Element 0083 should be populated with a 7 (or
8), and element 0085 should not be populated.
Note: This procedure should be considered an exception
case, as a functional response message (ACKRES) upon
completion of functional processing is preferred. (See next
item.)
Receipt Functional Success
 Once the inbound message has been handed off to the
Processing
application, an application-level acknowledgement is
(Destination
recommended. The application should return an ACKRES
Application)
to the sender to acknowledge receipt of the message.
 The service segments of the ACKRES should be populated
based on the service segments of the PNRGOV for which it
is associated. This includes echo back of the Common
Access Reference (CARF) in element 0068
 Populate the MSG Segment as follows:
o Element 1225 in Composite C302 should contain 23 to
indicate it is an ACKRES
o Element 4343 should contain a value of 2 to indicate
the message has been received but not yet processed.
Processing Status Functional Successfully
 Once functional processing has begun on the inbound
Processing Completed
message, an application-level response is recommended.
(Destination
The application should return an ACKRES to the sender to
Application)
indicate the processing status.
 The service segments of the ACKRES should be populated
based on the service segments of the PNRGOV for which it
is associated. This includes echo back of the Common
Access Reference (CARF) in element 0068
 Populate the MSG Segment as follows:
o Element 1225 in Composite C302 should contain 23 to
indicate it is an ACKRES
o Element 4343 should contain a value of 3 to indicate
the message has been successfully processed.

98
 PADIS EDIFACT Implementation Guide – PNRGOV Message

Processing Status Functional Not Processed

 If the destination application determines that the message
Processing
does not require processing, an ACKRES response should
(Destination
be generated.
Application)
 The service segments of the ACKRES should be populated
based on the service segments of the PNRGOV for which it
is associated. This includes echo back of the Common
Access Reference (CARF) in element 0068
 Populate the MSG Segment as follows:
o Element 1225 in Composite C302 should contain 23
to indicate it is an ACKRES
o Element 4343 should contain a value of 7 to indicate
the message has been received, but not processed.
 Optionally, an ERC segment may be included if an
appropriate reason for not processing is defined in code set
9321.
 Note: This status may not be applicable and the State may
only choose to return an Error status.
Processing Status Functional Error /
 If the destination application determines that the message
Processing Rejected
cannot be processed, an ACKRES response should be
(Destination
generated.
Application)
 The service segments of the ACKRES should be populated
based on the service segments of the PNRGOV for which it
is associated. This includes echo back of the Common
Access Reference (CARF) in element 0068
 Populate the MSG Segment as follows:
o Element 1225 in Composite C302 should contain 23
to indicate it is an ACKRES
o Element 4343 should contain a value of 8 to indicate
the message has been received and rejected.
 One or more ERC segments should be included with
appropriate reason(s) for rejection as defined in code set
9321.

99
 PADIS EDIFACT Implementation Guide – PNRGOV Message

4.3 Examples

Scenario Message Sample Content

Not able to parse envelope CONTRL UCI+00000000000000+XX+YY+4+18

Able to parse UNB/UNH, Interchange sender XX is invalid or CONTRL UCI+99999999999999+XX+YY+4+23

unexpected. UCM+1432+PNRGOV:11:1:IA+4

Message/version not supported CONTRL UCI+99999999999999+XX+YY+8

UCM+1432+PNRGOV:93:2:IA+4+2

Parsing error, functional segments out of order (e.g. found an CONTRL UCI+99999999999999+XX+YY+8
ABD segment when not expected) UCM+1432+PNRGOV:93:2:IA+4+15+ABD

Received and queued by message router for functional CONTRL UCI+99999999999999+XX+YY+8

processing, which may be delayed UCM+1432+PNRGOV:93:2:IA+7

Received by functional processing logic ACKRES MSG+:23+2

Received by functional processing logic, but will not be ACKRES MSG+:23+7

processed
Successfully processed ACKRES MSG+:23+3

Error in processing / rejected (e.g. invalid departure date) ACKRES MSG+:23+8

ERC+102

100
 PADIS EDIFACT Implementation Guide – PNRGOV Message

5 Repetition Maximums and Separators

Data in EDIFACT segments and composites are position-dependent rather than named as in other syntaxes such as XML. The position is not based on fixed-width fields
or alternation of data types, but on the use of the appropriate separators. The structure of a Segment defines an ordered list of Data Elements (each of which may be a
standalone Data Element or Composite Data Element) separated with a Data Element Separators (+ by default). In PADIS documentation, these elements are denoted by
the use of ALL UPPER CASE characters for their names. Each data element may have one or more maximum repetitions. Although fields that may repeat are generally
found at the end of a segment, there are instances of repeating fields within some segments. PADIS does not make use of the Repetition Separator (* by default) but
instead uses the Data Element Separator between repetitions of any repeating Data Elements. Therefore, in order to establish the correct position of a Data Element
within the segment, the maximum number of repetitions of all Data Elements prior to that Data Element must be represented, whether or not those Data Elements contain
any data.

Likewise, the structure of a Composite Data Element defines an ordered list of single Data Elements, each of which are separated with a single Component Data Element
Separator (: by default). Any given Data Element within the Composite Data Element may have one or more maximum repetitions within that Composite Data Element. In
order to establish the correct position of a Data Element within the Composite Data Element, the maximum number of repetitions of all Data Elements prior to that Data
Element must be represented, whether or not those Data Elements contain any data.

Finally, it should be noted that trailing separators should not be used. Data Element Separators should not be used after the last non-empty Data Element within a
segment. Component Data Element Separators should not be used after the last non-empty Data Element within a Composite Data Element.

For example, please refer to specific documentation for segment PTK .

101