pa 1169 (version 09) remove segment association on ssr doc...

January 13, 2012 ©2011 Travelport. All rights reserved. All Travelport logos and marks as well as all other Travelport proprietary materials depicted herein are the property of Travelport

LP and/or its affiliates.

Product Advisory

Remove Segment Association on SSR DOC items

Apollo™ / Galileo™ only

Product Advisory Number: 1169

Version: 09

Load To Production:

Galileo: 14-Feb-12

Apollo: To be advised

15:00

EST

20:00

GMT

High Level Description:

Remove segment association for SSR DOC (DOCA, DOCO and DOCS) items and make these SSRs name related, only. This will result in newly created SSR DOC items no longer being automated (Programmatic) but instead will now be non-automated (Manual) SSRs.

Impact Summary:

• Structure Data/XML

• SSR DOC Entries

• YY (generic) carrier code in SSR DOC items

• Client Files

• TTY Outbound

• Displays containing SSR DOC items

• PNR/Booking File Divide

• Repeat (REALLSALL)

• Name deletes/changes

• Drop through (1G only)

• PNR Claim/Global access

• Ticketing.

• Traversa

Reason For Issue:

This is to advise that activation will take place on 14 February 2012 for the Galileo system.

The activation for the Apollo system will be advised in due course.

Customer Impact:

Internal Only

Developers

Agency Customers

Airline Customers

eCommerce Customers

Car, Hotel, Rail or Cruise Customers

System:

Galileo

Product Advisory Remove Segment Association on SSR DOC items Apollo / Galileo only



Apollo

Worldspan

Load To Copy:

Galileo: 17-Jan-12

Apollo: To be advised

22:00

EST

03:00 (18-Jan)

GMT

Web Services: (API and Messaging)

The segment association details for SSR DOC (DOCA, DOCO and DOCS) are currently required for Structured Data processing. Therefore, when an SSR is added and the SSR code is DOCA, DOCO or DOCS, Apollo and Galileo will change Structured Data to skip the current segment validation.

While TPF changes shall be made to support Structured Data, no new or revised Structured Data KLR messages are required.

Both automated (Programmatic) and non-automated (Manual) SSR data are currently sent in using the same data block in Structured Data. Apollo and Galileo will ignore the flight details (flight, date, origin and destination) in Inbound SSR DOC Structured Data messages that are segment related. This action shall reduce the impact to Structured Data users.

For outbound segment related Structured Data messages containing SSR DOC items, Apollo and Galileo will create and send the applicable KLR based the format used to store the SSR DOC data – as automated (old) or Non-automated (new).

NOTE: SSR DOC DATA CAN NOW BE RETURNED IN EITHER OR BOTH KLR STRUCTURES.

Issue History:

Version 01 – Issued 22-Apr-11 Version 02 – Issued 29-Apr-11 Version 03 – Issued 27-Jun-11 Version 04 – Issued 18-Jul-11 Version 05 – Issued 28-Jul-11 Version 06 – Issued 19-Sep-11 Version 07 – Issued 10-Oct-11 Version 08 – Issued 31-Oct-11




Overview

This enhancement will modify SSR DOC (DOCA, DOCO or DOCS) processes that automatically create an SSR item for each passenger name and each segment in a PNR/Booking File. This change will allow Apollo and Galileo SSR DOC items to be name related, instead of name and segment related. Additionally, Apollo and Galileo will begin treating new SSR DOC items as non-automated (Manual) SSRs by no longer allowing specific flight/segment details (e.g. flight, date, origin and destination) in an SSR DOC entry.

Changing the Apollo and Galileo systems to non-automated SSRs for SSR DOC types will provide consistency whereas all three Travelport systems will now offer the same functionality under the Travelport GDS umbrella. Additionally, all three systems under the Travelport GDS umbrella will now provide competitive functionality when compared to other GDSs.

Customer Benefit

• This effort will significantly reduce the number of SSRs within the PNR for our Apollo and Galileo customers.

• SSR DOCs will remain in the PNR until manually cancelled unless a name is changed or deleted. Once in production, PNRs containing new SSR DOCs will no longer automatically be removed when an itinerary segment is cancelled/modify by the agency and/or modified by the airline

Detail and Customer Examples

1. SSR DOC (DOCA, DOCO and DOCS) General Rules and IMPORTANT information regarding

user/customer impact

1.1 SSR DOC (DOCA, DOCO and DOCS) entries will be changed from automated (segment

associated) to non-automated (non-segment associated). Consequently, segment information which includes all flight details (e.g. flight, date, origin and destination) will no longer be included in these SSRs.

1.2 Apollo and Galileo will restrict segment select and require a carrier code in SSR DOC (DOCA, DOCO and DOCS) entries.

1.3 The carrier code may be for a specific carrier or the generic carrier code YY (refer to item 2,

below).

1.4 In addition to adding a carrier code in an SSR DOC entry, the action code HK must be

entered, instead of NN.

1.5 For SSR DOCS and DOCO name select shall be required when the Apollo PNR or Galileo Booking File contains more than one passenger.

1.6 As shown in the examples below, the position of the passenger name select will be moved from the middle to the end of the non-automated SSR DOCs.




1.7 Changes will be required to Apollo Pro-Files and Galileo Client Files containing SSR DOCs – See Section 7 for additional details.

1.7.1 When building the new SSR DOCs, you will be required to re-enter sensitive passenger information again and ENSURE agents do NOT use the X’s that are currently displayed when sensitive information is shown in the old format. Existing processes/procedures should be used activating/deactivating masking. CAUTION: When deactivation of the masking function has occurred to make the necessary updates (adding sensitive passenger information in SSR DOCs), PLEASE ENSURE THE MASKING FUNCTION IS RE-ACTIVATED.

1.7.2 Prior to moving an SSR DOC with a YY (generic) carrier code from a Y line in Apollo Pro-Files or Galileo Client Files, flight segment(s) must be sold. The alternative is to store SSR

DOC items with a YY (generic) carrier code as an O line NOTE: THIS PROCEDURE MAY REPRESENT A SIGNIFICANT CHANGE IN YOUR BUSINESS PRACTICE.

1.8 The current limit for automated (Programmatic) SSRs is a maximum of 180 characters. However, the limit for non-automated (Manual) SSRs is 127 characters. Consequently, fewer characters will now be allowed in SSR DOC items effective 25JUL2011. Although the potential of exceeding 127 characters is extremely low, it will be the agent’s responsibility to determine the best way to reduce the number of characters in SSR DOC items when the need arises.

2. SSR DOC (DOCA, DOCO and DOCS) Entries using carrier code:

2.1 Apollo – New SSR DOC Entry Examples:

2.1.1. Example 1: SSR DOCS with all fields populated:

Entry:

>@:3SSRDOCSAAHK1/N1/P/US/S12345678/US/12JUL66/M/23OCT12/SMITH/J

OHN/RICHARD/H

2.1.2 Example 2: SSR DOCS populating the minimum fields allowed.

Entry: >@:3SSRDOCSDLHK1/N1/////12JUL66/M//SMITH/JOHN

2.1.3 Example 3: SSR DOCA without name select shall add 1 per passenger per carrier entered.

Entry: >@:3SSRDOCABAHK1/D/GBR//SLOUGH/BERKSHIRE/SL14T5

2.1.4 Example 4: SSR DOCA with name select shall add 1 for the carrier and passenger specified.

Entry: >@:3SSRDOCABAHK1/N2/D/GBR//SLOUGH/BERKSHIRE/SL14T5




2.2 Galileo– New SSR DOC Examples:

2.2.1 Example 1: SSR DOCS with all fields populated:

Entry: >SI.P1/SSRDOCSUSHK1/P/US/S12345678/US/12JUL66/M/23OCT12/SMITH/J

OHN/RICHARD/H

2.2.2 Example 2: SSR DOCS populating the minimum fields allowed.

Entry: >SI.P1/SSRDOCSDLHK1/////12JUL66/M//SMITH/JOHN

2.2.3 Example 3: SSR DOCA without name select shall add 1 per passenger per carrier selected.

Entry: >SI.SSRDOCACOHK1/D/GB/SLOUGH/BERKSHIRE//SL14T5

2.2.4 Example 4: SSR DOCA with name select shall add 1 for the passenger and carrier specified.

Entry: >SI.P1/SSRDOCABAHK1/D/GB//SLOUGH/BERKSHIRE/SL14T5

3. SSR DOC (DOCA, DOCO and DOCS) with new or existing error responses

3.1 When an attempt is made to include segment select in an SSR DOC entry. Apollo and Galileo will return error responses currently used for other non-automated (Manual) SSR entries.

3.2 There will be new error conditions for SSR DOC entries. When a new error conditions for SSR DOC entries is presented, Apollo and Galileo will also return existing error responses.

3.3 Following are examples of SSR DOC error conditions where Apollo and Galileo will return existing (Manual) SSR error responses.

3.3.1 Apollo - New Error Conditions using Existing Error Responses: 3.3.1.1 Example 1 - New Apollo SSR DOCS format input without a status code. An

‘HK1’ status code must be entered following the carrier code in the new non-automated SSR DOC format.

Entry:

>@:3SSRDOCSBA/N1/P/US/S12345678/US/12JUL66/M/23OCT12/SMITH/JOHN/

RICHARD/H

Existing Error Response will be returned:

INVLD FRMT/NOT ENT/@:3SSRDOCSBA/N1/P/US/S12345678/US/12JUL 66/M/2 OCT12/SMITH/JOHN/RICHARD/H

3.3.1.2 Example 2: New Apollo SSR DOCS format input with a Name Range. A name range may not be used in the new non-automated SSR DOC format.




Entry: >@:3SSRDOCSBAHK1/N1|2/P/US/S12345678/US/12JUL66/M/23OCT12 /SMITH/JOHN/RICHARD/H

Existing Error response will be returned:

CK NO IN PARTY

3.3.2 Galileo - New Error Conditions using Existing Error Responses:

3.3.2.1 Example 1: New Galileo SSR DOCS format input without a status code: A’ HK1’ status code must be entered following the carrier code in the new non-automated SSR DOC format. Entry: >SI.P1/SSRDOCSUS/P/US/S12345678/US/12JUL66/M/23OCT12/

SMITH/JOHN/RICHARD/H Existing Error Response will be returned:

STATUS CODE IS MANDATORY IN INPUT

3.3.2.2 Example 2: New Galileo SSR DOCS format input with a Name Range: A passenger range may not be used in the new non-automated SSR DOC format.

Entry: >SI.P1-2/SSRDOCSUSHK2/P/US/S12345678/US/12JUL66

/M/23OCT12/SMITH/JOHN/RICHARD/H

Existing Error Response to be Returned:

SINGLE PASSENGER RELATION ONLY

4. Processing of YY (generic carrier) code for SSR DOC (DOCA, DOCO, and DOCS):

4.1 When the generic carrier code YY is used in an SSR DOC entry Apollo and Galileo will internally examine the itinerary and create an SSR DOC item for each air carrier in the PNR or Booking File.

4.2 Because SSR DOC item(s) with a YY (generic) carrier code are used internally to create a

separate SSR DOC for each carrier code present in the itinerary, the SSR DOC entry with YY will not be stored in the Apollo PNR or Galileo Booking File.

4.3 When a segment for a new carrier is added to an existing PNR/BF that contains previously stored SSR DOC items, neither Apollo nor Galileo will automatically create a new SSR DOC item or send a TTY-OUT for the newly added carrier into the itinerary. The user will be required to add the SSR DOC item with the new carrier code or use the YY (generic) carrier code which will send to all existing and new airlines in the itinerary.




4.4 Examples of YY (generic) carrier code in SSR DOC 4.4.1 Example 1: Apollo Single SSR DOC Input with YY (generic carrier) code:

The following 1V PNR is created with three carriers:

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

AAA1BB/31 XDBKR E033586 AG 14537482 28JAN

1.1TESTONE/JOHN

1 BA 219Y 26MAR LHRDEN HK1 1235P 425P * SA E

2 DL 125Y 27MAR DENSLC HK1 630P 900P * SU E

3 AA 349Y 29MAR SLCDFW HK1 730A 914A * TU E

FONE-ORDT7735555454

TKTG-T/

>

The following SSR DOCS is input using a YY (generic) carrier code: Entry:

>@:3SSRDOCSYYHK1/N1/P/US/S12345678/US/12JUL66/M/23OCT14/TESTONE/

JOHN/PAUL/H

Subsequent entry: >*R or >*PS

Apollo Response when the PNR is redisplayed:

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15


1.1TESTONE/JOHN




FONE-ORDT7735555454

TKTG-T/

GFAX-SSRDOCSBAHK1/P/US/XXXXX5678/US/XXXXXXX/M/23OCT14/TESTONE/J

OHN/PAUL-TESTONE/JOHN

3 SSRDOCSDLHK1/P/US/XXXXX5678/US/XXXXXXX/M/23OCT14/TESTONE/J


5 SSRDOCSAAHK1/P/US/XXXXX5678/US/XXXXXXX/M/23OCT14/TESTONE/J


ACKN-DL YFFFFF 29JAN 0623

>

NOTE: THE SSR DOCS ITEM WITH THE YY CARRIER CODE WILL NOT BE STORED IN THE PNR.




4.4.2 Example 2: Galileo Single SSR DOC Input with YY (generic carrier) code:

The following 1G Booking File (BF) is created with three carriers

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

J4ZQGB/86 XDBKR E335860 AG 38212661 28JAN

1.1TESTOC/JP

1. BA 219 C 20MAY LHRDEN HK1 1605 1850 O E FR

2. CO 398 Y 22MAY DENMSP HK1 0825 1150 O E SU

3. DL 408 Y 23MAY MSPATL HK1 0750 1230 O E MO

** FILED FARE DATA EXISTS ** >*FF

** VENDOR LOCATOR DATA EXISTS ** >*VL

** SERVICE INFORMATION EXISTS ** >*SI

FONE-LONB*816-555-6876

TKTG-TAW/TU01FEB/1600

>

The following SSR DOCA is input using a YY (generic carrier) code: Entry:

>SI.SSRDOCAYYHK1/R/US/234 DAREDEVEL ST/HANOVER/MO/11718

Subsequent entry: >*SI

Response:

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15

** SPECIAL SERVICE REQUIREMENT **

SEGMENT/PASSENGER RELATED

S 1. BA 0219 C 20MAY LHRDEN

P 2. TESTOC/JP SPML NN 1 NO EGGS

S 2. CO 0398 Y 22MAY DENMSP


S 3. DL 0408 Y 23MAY MSPATL


NO OSI EXISTS

** MANUAL SSR DATA **

1. SSRDOCABA HK 1 /R/US/234 DAREDEVEL ST/HANOVER/MO/11718-TE

STOC/JP

2. SSRDOCACO HK 1 /R/US/234 DAREDEVEL ST/HANOVER/MO/11718-TE

STOC/JP

>MD

NOTE: THE SSR DOCS ITEM WITH THE YY CARRIER CODE WILL NOT BE STORED IN THE BOOKING FILE.




Moving Down: 1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15







NO OSI EXISTS



STOC/JP


STOC/JP

3. SSRDOCADL HK 1 /R/US/234 DAREDEVEL ST/HANOVER/MO/11718-TE

STOC/JP

>MD

4.4.3 Duplicate SSR DOC items will be possible as each time the carrier code YY is used in any SSR DOC item, the system will create a new SSR DOC item for each air carrier in the itinerary AND create a new SSR DOC item.

4.4.3.1 Example 1: Apollo SSR DOC item input again with YY (generic) carrier code

after the initial SSR DOC with the YY carrier code was entered:

In the following example a duplicate SSR DOCS is input in the PNR using the YY carrier code. Entry:

>@:3SSRDOCSYYHK1/N1/P/US/S12345678/US/12JUL66/M/23OCT14/TE

STONE/JOHN/PAUL/H

Subsequent entry: >*R or >*PS




Apollo Response when the PNR is redisplayed:

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15


1.1TESTONE/JOHN




FONE-ORDT7735555454

TKTG-T/







7 SSRDOCSBAHK1/P/US/XXXXX5678/US/XXXXXXX/M/23OCT14/TESTONE/J

>MD


1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15







7 SSRDOCSBAHK1/P/US/XXXXX5678/US/XXXXXXX/M/23OCT14/TESTONE/J





OHN/PAUL-1TESTONE/JOHN


ACKN-1A 2FFFFF 29JAN 0624

>MD




4.4.3.2 Example 2: Galileo SSR DOC item input again with YY (generic) carrier

code after the initial SSR DOC item with the YY carrier code was entered:

In the following example a duplicate SSR DOCA is input in the Booking File using the YY carrier code

Entry: >SI.SSRDOCAYYHK1/R/US/234 DAREDEVEL ST/HANOVER/MO/11718

Subsequent entry: >*SI

Response:

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15









NO OSI EXISTS



STOC/JP


STOC/JP

>MD


1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15

NO OSI EXISTS



STOC/JP


STOC/JP


STOC/JP


STOC/JP


STOC/JP


STOC/JP

>MD




5. Modified SSR DOC (DOCA, DOCO, and DOCS) Format and Placement in Displays:

This enhancement changes Apollo and Galileo SSR DOC items from automated (segment associated) to non-automated (PNR/passenger). Newly added SSR DOC (DOCA, DOCO and DOCS) items will no longer contain segment specific flight details. SSR DOC items entered into PNRs prior to this change will NOT be automatically changed to a non-automated SSR DOC item.

5.1 The change from automated to non-automated SSR DOC items will impact the placement of SSR DOC items in the Galileo Booking File.

5.2 There will not be a change in the placement location of the SSR DOC items in the Apollo PNR as the new non-automated SSR DOC items (without flight details) will continue to appear in GFAX field in the PNR display and in the *PS display.

5.3 SSR DOC items in PNR/Booking File Displays: 5.3.1 Example 1: Apollo – Newly created PNR with only new SSR DOC format(s) in PNR

GFAX displays:

Entries to Display SSR items in PNR GFAX or *PS Display:

>*R or >*PS

Revised Response – For SSR DOC items in GFAX area of PNR:

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15

W3TLRU/86 XDBKR E033586 AG 05725661 11JAN

1.1TESTVO/VICTORIALEE

1 AA 605Y 10FEB CLTDFW HK1 710A 910A TH

2 AA1841Y 10FEB DFWTUS HK1 955A 1120A TH

3 UA6818Y 14FEB TUSSFO HK1 1208P 121P * MO E

OPERATED BY UNITED EXPRESS/SKYWEST AIRLINES

4 US1486Y 17FEB SFOCLT HK1 850A 439P * TH E

FONE-LAXB/818 555-7000X469

TKTG-TAU/01FEB

GFAX-SSRFOIDACNN1/DL12345-1TESTVO/VICTORIALEE

2 SSRDOCSAAHK1/A/US/XXX2345/US/XXXXXXX/F/23OCT12/TESTVO/VICT

ORIA/LEE-TESTVO/VICTORIALEE

3 SSRDOCSUAHK1/A/US/XXX2345/US/XXXXXXX/F/23OCT12/TESTVO/VICT

)>MD





1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15


5 SSRDOCSUSHK1/A/US/XXX2345/US/XXXXXXX/F/23OCT12/TESTVO/VICT


>

5.3.2 Example 2: Galileo – Revised SSR DOC format(s) in SERVICE INFORMATION display from the Booking File:

Galileo Booking File display

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

12

JF999R/86 XDBKR E335860 AG 38212661 19JAN


1. UA 245 F 20FEB ORDDEN HK1 0900 1035 O* E SU

2. AA 1274 Y 27FEB DENDFW HK1 0715 1020 O* E SU 1

3. AA 2417 Y 27FEB DFWLAX HK1 1040 1210 O* E SU 1

4. BA 192 C 04MAR DFWLHR HK1 1655 #0735 O* E FR


** VENDOR REMARKS DATA EXISTS ** >*VR


FONE-LONB*816-891-6876


>

The following changes will be made in displaying SSR DOC items in the SERVICE INFORMATION display from the Booking File.

Entry: >*SI




Revised Response – For SSR DOC items in the Booking File in Galileo new SSR DOC items will

appear under the ** MANUAL SSR DATA ** 1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15

SI

"** SPECIAL SERVICE REQUIREMENT **


S 1. UA 0245 F 20FEB ORDDEN

P 1. TESTVO/VICTORIALEE SPML NN 1 NO EGGS

S 2. AA 1274 Y 27FEB DENDFW


S 3. AA 2417 Y 27FEB DFWLAX


S 4. BA 0192 C 04MAR DFWLHR


NO OSI EXISTS


1. SSRFQTVAA HK 1 /FF1234567891234-TESTVO/VICTORIALEE

)>MD

Moving Down:

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15

MD

2. SSRFOIDUA HK 1 /DLMO12341234-1TESTVO/VICTORIALEE

3. SSRDOCAUA HK 1 /R/US/234 DAREDEVEL ST/HANOVER/MO/11718-TE

STVO/VICTORIALEE

4. SSRDOCAAA HK 1 /R/US/234 DAREDEVEL ST/HANOVER/MO/11718-TE

STVO/VICTORIALEE


STVO/VICTORIALEE

6. SSRDOCOUA HK 1 /LONDON GB/R/XXX2310/LONDON GB/14MAR09/US-

TESTVO/VICTORIALEE

7. SSRDOCOAA HK 1 /LONDON GB/R/XXX2310/LONDON GB/14MAR09/US-

TESTVO/VICTORIALEE

8. SSRDOCOBA HK 1 /LONDON GB/R/XXX2310/LONDON GB/14MAR09/US-

TESTVO/VICTORIALEE

)>MD





1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

12

13

14

MD

9. SSRDOCSUA HK 1 /A/US/XXXXX4567/US/XXXXXXX/F/23JAN12/TESTV

O/VICTORIA/LEE-TESTVO/VICTORIALEE

10. SSRDOCSAA HK 1 /A/US/XXXXX4567/US/XXXXXXX/F/23JAN12/TESTV


11. SSRDOCSBA HK 1 /A/US/XXXXX4567/US/XXXXXXX/F/23JAN12/TESTV


>

5.4 PNR/Booking File Displays with OLD and NEW SSR DOC items:

Once changes are made to remove segment association for SSR DOC item(s), all new SSR DOC items will be reflected in the new display format in a PNR/Booking File (as shown above). However, SSR DOC items entered in a PNR/Booking File before this enhancement is implemented will continue to display as they do today. Consequently, there will be an interim period when SSR DOC items may be displayed in both OLD and NEW formats.

5.4.1 Apollo PNR Display with OLD and NEW SSR DOC items in PNR GFAX or *PS

Displays: 5.4.1.1 Example 1: Apollo

>*R

Or >*PS

Revised Response: SSR DOCS GFAX items for AA were entered prior to the enhancement so would be displayed as OLD SSR DOC items while SSR DOCS and SSR

DOCO GFAX items for UA and US were added after the enhancement was in production so would be displayed as NEW SSR DOC items

NOTE: THIS WILL OCCUR FOR AN INTERIM PERIOD UNTIL ALL

PNRs CONTAINING OLD SSR DOC ITEMS BECOME PAST DATE.




1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15

W3TLRU/86 XDBKR E033586 AG 05725661 11JAN

1.1TESTVO/SEANMARK

1 AA 605Y 10FEB CLTDFW HK1 710A 910A TH

2 AA1841Y 10FEB DFWTUS HK1 955A 1120A TH

3 UA6818Y 14FEB TUSSFO HK1 1208P 121P * MO E

OPERATED BY UNITED EXPRESS/SKYWEST AIRLINES

4 US1486Y 17FEB SFOCLT HK1 850A 439P * TH E

FONE-LAXB/818 555-7000X469

TKTG-TAU/01FEB

GFAX-SSRFOIDACNN1/DL12345-1TESTVO/SEANMARK

2 SSRCLIDAANN1/12345ABC-TESTVO/SEANMARK

3 SSRDOCSAAHK1 CLTDFW 0605Y 10FEB-

1TESTVO/SEANMARK.A/US/XXX2345/US/XXXXXXX/F/23OCT12/TESTVO/SEAN/

MARK

)>MD

Moving Down:

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15

5 SSRDOCSAAHK1 DFWTUS 1841Y 10FEB-

1TESTVO/SEANMARK.A/US/XXX2345/US/XXXXXXX/F/23OCT12/TESTVO/SEAN/

MARK

7 SSRDOCSUAHK1/P/US/XXXXX5678/US/XXXXXXX/M/23OCT12/TESTVO/SE

AN/MARK-TESTVO/SEANMARK

11 SSRDOCSUSHK1/P/US/XXXXX5678/US/XXXXXXX/M/23OCT12/TESTSO/SE

AN/MARK-TESTVO/SEANMARK

13 SSRDOCOAAHK1/NEW YORK US/R/XXXXXX7177/NEW ORLEANS LA USA /

14OCT10/USA-TESTVO/SEANMARK

15 SSRDOCOUAHK1/NEW YORK US/R/XXXXXX7177/NEW ORLEANS LA USA

/14OCT10/USA-TESTVO/SEANMARK

17 SSRDOCOUSHK1/NEW YORK US/R/XXXXXX7177/NEW ORLEANS LA USA

/14OCT10/USA-TESTVO/SEANMARK

>

5.4.2 Galileo Booking File Display with h and new SSR DOC items in *SI Display:

In Galileo all existing or OLD SSR DOC items will appear in SEGMENT/PASSENGER

RELATED areas of the *SI (SERVICE INFORMATION) display and all NEW SSR

DOC items will appear under the

** MANUAL SSR DATA ** area in the same display.




5.4.2.1 Example 2: Galileo

Galileo Booking File:

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

12


1.1TESTVO/SEANMARK

1. AZ 202 C 10FEB FCOLHR HK1 0930 1125 O* E TH

2. AA 87 Y 15FEB LHRORD HK1 1015 1250 O* E TU

3. UA 761 Y 24FEB ORDSFO HK1 0800 1051 O* E TH




FONE-LONB*816-891-6876


>

In the following example, the old SSR DOCS item for AZ appears in the

SEGMENT/PASSENGER RELATED area, while newly added SSR DOCS for

AA, and UA items will appear in the

** MANUAL SSR DATA ** area of the *SI display.

NOTE: THIS WILL OCCUR FOR AN INTERIM PERIOD UNTIL ALL

BOOKING FILES CONTAINING OLD SSR DOC ITEMS BECOME PAST DATE.

Entry: >*SI

Response:

5.4.3. History Displays with New SSR DOC items:

To better illustrate the placement and format of new non-automated (PNR/passenger associated) SSR DOC items in PNR/Booking File History displays the following examples contain both old and new SSR DOC items.

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11



S 1. AZ 0202 C 10FEB FCOLHR

P 1. TESTVO/SEANMARK DOCS HK 1 P/GB/XXXXX5678/GB/XXXXXXX/-

M/23OCT14/TESTVO/SEAN/MARK

NO OSI EXISTS


1. SSRDOCSAA HK 1 /A/US/XXXXX4567/US/XXXXXXX/F/23JAN12/TESTV

O/SEAN/MARK-TESTVO/SEANMARK

2. SSRDOCSUA HK 1 /A/US/XXXXX4567/US/XXXXXXX/F/23JAN12/TESTV

O/SEAN/MARK-TESTVO/SEANMARK




5.4.3.1 Apollo PNR History Display containing SSR DOC items: 5.4.3.1.1 Example 1: Apollo PNR history display:

In the following example, the new non-automated SSR DOCs functionality was activated in production on 12 AUG. The SSR DOCS item for passenger 1 (TESTVO/SEANMARK) was entered on 11JAN 1859Z for the UA segment (UA6818). However, the SSR DOCS the US segment (US1486) was added on 13AUG 1601Z. Therefore, the SSR DOCS for the UA segment displays in the OLD format and the SSR DOCS for the US segment displays in the NEW format.

NOTE: THESE FORMATS WILL ALSO BE USED IN THE ‘SSR

HISTORY’ (*HG), AS APPLICABLE.

Entry: >*H

Response: 1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15

RCVD-PAX/E033586

XDB AG 86 1811Z/11JAN

AG SSRDOCSUSHK1/A/US/XXX4567/US/XXXXXXX/F/23OCT15/TESTVO/SEAN/M

ARK-TESTVO/SEANMARK

RCVD-/E033586 -CR- XDB/1MY/1V AG 86 13AUG1601Z

HS US1486 Y17AUG SFOCLT SS/HK2 850A 439P *

RCVD-PAX/E033586 -CR- XDB/1MY/1V AG 86 13AUG1518Z

AG SSRDOCSUAHK01 TUSSFO 6818Y 24AUG-1TESTVO/SEANMARK.P/US/XXXX

X5678/US/XXXXXXX/M/23OCT12/TESTVO/SEAN/MARK

AG SSRCLIDAANN1/12345ABC-TESTSO/SEANL

RCVD-/E033586 -CR- XDB/1MY/1V AG 86 11JAN1859Z

HS UA6818 Y24AUG TUSSFO NN/HK2 1208P 121P *

ATA TAU/01FEB

RCVD-PAX/E033586 -CR- XDB/1MY/1V AG 86 11JAN1811Z

>

5.4.3.2 Galileo SERVICE Information HISTORY display containing SSR DOC items

5.4.3.2.1 Example 1 Galileo Booking File history display:

Following is an example of a Galileo SERVICE INFORMATION HISTORY

display. This screen is displayable from the Booking File or from the

Booking File History display by entering *HSI . In the following example, the new non-automated SSR DOCs functionality was activated in production on 12 AUG. The SSR DOCS item below for the KL segment was entered on 08FEB 1406Zwhen the Booking File was originally created. However, the SSR DOCS for the AZ segment was entered 13 AUG 1300Z Therefore, the SSR DOCS for the KL segment displays in the OLD format and the SSR DOCS for the AZ segment displays in the NEW format

-

Entry: *HSI




Response: 1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15

***** SERVICE INFORMATION HISTORY ZR3RMW *****

** SEGMENT/PASSENGER RELATED **

HSI AZ 1844 J 10 APR AMSFCO

** CARRIER RELATED **

AO SSRDOCSKL HK1/A/US/XXXXX4567/US/XXXXXXX/F/23JAN12/TESTVO

/SEAN/MARK-TESTVO/SEANMARK

RCVD-P/E335860

CRDT- XDB/ L2R/1G AG 86 1300Z/13AUG

** SEGMENT/PASSENGER RELATED **

HSI KL 1602 J 10 MAR FCOAMS

AG 2.TESTVO/SEANMARK NN/PN001 DOCS P/GB/XXXXX5678/GB/XXXXXX

X/M/23OCT14/TESTVO/SEAN/MARK

** CARRIER RELATED **

AO SSRFOIDKL HK001 /NI55511123A

RCVD-P/E335860

CRDT- XDB/ L2R/1G AG 86 1406Z/08FEB

>

6. TTY:

Processing that currently transmits an SSR DOC to each carrier in the itinerary when one SSR DOC (DOCA, DOCO and/or DOCS) is entered will continue to apply. However, the new non-automated (PNR/Passenger associated) SSR DOC format (exclusive of flight details) will be sent in TTY-OUT.

NOTE: IF Carriers have done special coding for SSR DOCs from Apollo and Galileo, they will

need to make changes to accommodate the SSR DOCs in a non-automated format. 6.1 TTY Outbound

The following TTY-OUT processing shall apply for Apollo and Galileo. 6.1.1 EXAMPLE 1: Apollo - Single Carrier PNR:

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

S55555/31 XDBKR E033586 AG 14537482 28JAN



FONE-ORDT7135555454

TKTG-T/

GFAX-SSRDOCSBAHK1/////XXXXXXX/F//TESTVO/VICTORIA/LEE-TESTVO/VIC

TORALEE

ACKN-1A YKK111 29JAN 0525

>




Apollo TTY OUT to 1A for BA flight:

MUCRM1A

.QTSRM1V 300537

QTS1V S55555/0GK5/14537482/DEN/1V/T/US

MUC1A YKK111

1TESTVO/VICTORIALEE

BA219Y26MAR LHRDEN HK1 1A

SSRDOCSBAHK1/////12JUL54/F//TESTVO/VICTORIA/LEE-TESTVO/VICTORIALEE

6.1.2 EXAMPLE 2: Apollo Multiple Carrier PNR:

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

12

13

14

TTT111/31 XDBKR E033586 AG 14537482 28JAN

1.1TEST/IANPAUL



3 DL 349Y 29MAR SLCMSP HK1 730A 914A * TU E

FONE-ORDT7735555454

TKTG-T/

GFAX-SSRDOCSBAHK1/////XXXXXXX/M//TEST/IAN/PAUL-TEST/IANPAUL

3 SSRDOCSDLHK1/////XXXXXXX/M//TEST/IAN/PAUL-TEST/IANPAUL


ACKN-1A 2FFFFF 29JAN 0624

)>

NOTE: BECAUSE INFORMATION IS NOW PNR/PASSENGER ASSOCIATED, ONLY ONE SSR IS CREATED FOR DL EVEN THOUGH THE PNR CONTAINS TWO DL FLIGHTS.

Apollo TTY-OUT to 1A for BA flight:

MUCRM1A

.QTSRM1V 300626

QTS1V TTT111/0GK5/14537482/DEN/1V/T/US

MUC1A 2FFFFF

1TEST/IANPAUL

BA219Y26MAR LHRDEN HK1 1A

SSRDOCSBAHK1/////12JUL04/M////23OCT14/TEST/IAN/PAUL-TEST/IANPAUL

Apollo TTY-OUT to DL:

HDQRMDL

.QTSRM1V 300626

QTS1V TTT111/0GK5/14537482/DEN/1V/T/US

HDQDL YFFFFF

1TEST/IANPAUL

DL125Y27MAR DENSLC HK1

DL349Y29MAR SLCMSP HK1

SSRDOCSDLHK1/////12JUL04/M////23OCT14/TEST/IAN/PAUL-TEST/IANPAUL

NOTE: SPECIFIC FLIGHT DETAILS (E.G. FLIGHT, DATE, ORIGIN, DESTINATION) ARE NO LONGER INCLUDED IN THE SSR DOCS WHEN TRANSMITTING THE INFORMATION TO THE CARRIER.




6.1.3 EXAMPLE 3: Galileo - Single Carrier Booking File:

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

JF999R/86 XDBKR E335860 AG 38212661 28JAN

1.1TESTVO/VICT0RIALEE

1. UA 245 F 20FEB ORDDEN HK1 0900 1035 O* E SU




FONE-LONB*816-555-6876


>

Service Information Display Entry: >*SI Response:

01

02

03

04

05

NO OSI EXISTS


1. SSRDOCSUAHK1////XXXXXXX/F//TESTVO/VICTORIA/LEE-TESTVO/VICTO

RIALEE

>

Galileo TTY OUT to UA:

HDQRMUA

.SWITL1G 280835

SWI1G JF999R/X9J/96809381/ADL/1G/T/AU

HDQUA THX17U

1TESTVO/VICTORIALEE

UA245F20FEB ORDDEN HK1

SSRDOCSUAHK1/////12JUL66/F//TESTVO/VICTORIA/LEE-TESTVO/VICTORIALEE

6.1.4 EXAMPLE 4: Galileo - Multiple Carrier Booking File:

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11


1.1TEST/JIMBOB

1. BA 219 C 20MAY LHRDEN HK1 1605 1850 O E FR

2. DL 398 Y 22MAY DENMSP HK1 0825 1150 O E SU

3. DL 408 Y 23MAY MSPATL HK1 0750 1230 O E MO




FONE-LONB*816-555-6876


>




Service Information Display

Entry: >*SI

Response: 1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

12

NO OSI EXISTS


1. SSRDOCSBA HK 1 ////XXXXXXX/M//TEST/JIM/BOB-TEST/JIMBOB

2. SSRDOCSDL HK 1 ////XXXXXXX/M//TEST/JIM/BOB-TEST/JIMBOB


ST/JIMBOB


ST/JIMBOB

>

NOTE: ONLY ONE SSR DOCS AND ONE SSR DOCA IS CREATED FOR DL EVEN THOUGH THE PNR CONTAINS TWO DL FLIGHTS.

Galileo TTY-OUT to 1A for BA:

MUCRM1A

.SWITL1G 280835

SWI1G J4ZQGB/X9J/96809381/ADL/1G/T/AU

MUCQY1A A123CD

1TEST/JIMBOB

BA219C20MAY LHRDEN HK1

SSRDOCSBAHK1/////23JUL76/M//TEST/JIM/BOB-TEST/JIMBOB

SSRDOCABAHK1/R/US/234 DAREDEVEL ST/HANOVER/MO/11718-TEST/JIMBOB

Galileo TTY-OUT to DL:

HDQRMDL

.SWITL1G 280835

SWI1G J4ZQGB/X9J/96809381/ADL/1G/T/AU

HDQDL D123EF

1TEST/JIMBOB

DL398Y22MAY DENMSP HK1

DL408Y23MAY MSPATL HK1

SSRDOCSDLHK1/////23JUL76/M//TEST/JIM/BOB-TEST/JIMBOB

SSRDOCADLHK1/R/US/234 DAREDEVEL ST/HANOVER/MO/11718-TEST/JIMBOB

NOTE: SPECIFIC FLIGHT DETAILS (E.G. FLIGHT, DATE, ORIGIN, DESTINATION) SHALL BE STRIPPED FROM THE SSR DOCS ITEM IN TTY-OUT, AS ILLUSTRATED ABOVE.




7. Pro-File/Client Files

The following changes will be made in Apollo Pro-Files and Galileo Client Files to support new SSR DOC (DOCA, DOCO and/or DOCS) entries: 7.1 Apollo Pro-Files and Galileo Client Files will accept the new non-automated SSR DOC format,

including Name (e.g. N1) and Passenger (e.g. P1) select options. 7.2 Name/Passenger select must be included in DOCA, DOCO and DOCS SSR entries stored in a

Pro-File/Client File if there are multiple names in the Profile or Client File. 7.3 New non-automated DOCA, DOCO and DOCS SSR entries will no longer be stored as an R

(Related move) line in a Pro-File/Client File. Instead, these SSRs must be stored as either Y (Yes – Always move) or O (Optional move) lines.

NOTE: IF SSR DOC ITEM(S) WITH A YY (GENERIC) CARRIER CODE IS STORED IN A ‘Y’ LINE IN THE PRO FILE/CLIENT FILE, FLIGHT SEGMENTS MUST BE BOOKED BEFORE THE ‘Y’ LINE WITH THE SSR DOC ITEM CAN BE MOVED.

7.3.1 Example 1: Apollo Pro-File: SSR DOCS items are stored in the Pro-File as Y (Yes-Always move) lines and SSR

DOCO and DOCA are stored as an O (Optional move) line. All three SSR DOC types include a name select (N1) and are all in the new non-automated SSR DOC format (exclusive of flight/segment details).

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15

GK5 /TRAVELPORT-STEVENSON 10JUL09

PERSONAL FILE

1O/N:1STEVENSON/JONATHANRICHARD

4Y/P:ATLB/770 563 5555

5Y/R:DC

6Y/T:T/

7Y/D-DELIVER ADDRESS

10Y/¤:5THIS IS A TEST PNR

12Y/¤:3SSRDOCSYYHK1/N1/P/USA/XXXXX1234/USA/XXXXXXX///STEVENSON/

JONATHAN/RICHARD

13O/¤:3SSRDOCOBAHK1/N1/PARIS FR/V/XXXXX1234/LONDON GB/12JUL15/G

BR

14O/¤:3SSRDOCAUAHK1/N1/R/USA/10 MAIN STREET/ATLANTA/GA/30019

END OF DISPLAY




7.3.2 Example 2: Galileo Client File:

SSR DOCS items are stored in the Client File as Y (Yes-Always move) lines and SSR DOCO and DOCA are stored as an O (Optional move) line. All three SSR DOC types include a passenger

select (P1) and are all in the new non-automated SSR DOC format (exclusive of flight/segment details).

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

12

13

50OB/TRAVELPORT-STEVENSON 09FEB09

PERSONAL FILE

1O/N.1STEVENSON/JONATHANRICHARD

4Y/P.ATLB/770 777-7777-DC

5Y/R.DC

6Y/T.T*

7Y/D.DELIVER ADDRESS

10Y/NP.THIS IS A TEST PNR

11Y/SI.P1/SSRDOCSYYHK1/P/USA/XXXXX1234//XXXXXXX///STEVENSON/JON

ATHAN/RICHARD

12O/SI.P1/SSRDOCOBAHK1/PARIS FR/V/XXX4567 /LONDON GB/12JUL15/GB

13O/SI.P1/SSRDOCAUAHK1/R/USA/10 MAIN STREET/ATLANTA/GA/30019

END OF DISPLAY

7.3.3 Following is IMPORTANT INFORMATION FOR USERS regarding changes in SSR DOC

(DOCA, DOCO and DOCS) items in Apollo Profiles and Galileo Client Files:

7.3.3.1 It will be the responsibility of Apollo/Galileo customers to remove all automated SSR DOCA, DOCO and DOCS items currently stored in ‘R’ lines in a Pro-File/Client File and replace them with ‘Y’ or ‘O’ lines containing new non-automated (Manual) SSR DOC formats using Name/Passenger select. If no action is taken errors will be returned on all automated SSR DOC items moved from ‘R’ lines in a Pro-File/Client File. As a result, customers will be required to reenter the SSR DOC information in the new non-automated format each time a PNR/Booking File is built.

7.3.3.2 Since Name/Passenger select must be input in new non-automated SSR DOCO and DOCS items stored in a Pro-File/Client File, customers should check PNR/Booking Files created using multiple passenger Pro-Files/Client Files to ensure that the name association is correct in the SSR DOC item that was moved. Example: A PNR/Booking File contains 2 names. When a SSR DOCS entry stored in an Apollo Pro-File contains N1,or, in a Galileo Client File contains P1 the data will move and associate the SSR DOCS to name 1 in the PNR/Booking File. If data in the SSR DOCS item should actually be associated to name 2 (N2 or P2) the user will be required to adjust the SSR DOCS item to associate it to the correct name in the PNR/Booking File.

7.3.3.3 When building the new SSR DOCs, you will be required to re-enter sensitive passenger information again and ENSURE agents do NOT use the X’s that are currently displayed when sensitive information is shown in the old format.




Existing processes/procedures should be used activating/deactivating masking. CAUTION: When deactivation of the masking function has occurred to make the necessary updates (adding sensitive passenger information in SSR DOCs), PLEASE ENSURE THE MASKING FUNCTION IS RE-ACTIVATED.

7.3.3.4 Prior to moving an SSR DOC item with a YY (generic) carrier code from a Y line in Apollo Pro-Files or Galileo Client Files, flight segment(s) must be sold. The

alternative is to store SSR DOC items with a YY (generic) carrier code as an O line NOTE: THIS PROCEDURE MAY REPRESENT A SIGNIFICANT CHANGE IN YOUR BUSINESS PRACTICE.

8. Divide Function:

8.1 Apollo:

8.1.1 No changes will be made in the Apollo PNR Divide process that currently moves

SSR items for applicable name(s) when a PNR Divide is performed. 8.1.2 When a PNR Divide is performed SSR DOC (DOCA, DOCO and/or DOCS) items

will be moved to divided PNRs in the SSR format (non-automated, or, automated) they were stored in the original PNR.

8.2 Galileo:

8.2.1 Galileo will make internal changes to ensure name association (rather than

segment association) is used in moving SSR DOC items to the related Booking Files when a Divide function is performed.

8.2.2 Additionally, when a Divide is performed SSR DOC (DOCA, DOCO and/or

DOCS) items will be moved to divided Booking Files in the SSR format (non-automated, or, automated) they were stored in the original Booking File

8.2.3 Example: The original Booking File contains SSR items (including SSR DOCS and DOCO) for both passengers. As illustrated below, Galileo will ensure SSR DOC (DOCA, DOCO and DOCS) items are moved to the Booking File that contains the related name when a Divide is performed. Original 1G Booking File:

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

Q1P0B8/86 XDBKR E335860 AG 99999992 08MAR

1.1SMITH/JOHN 2.1TESTVO/VIC

1. DL 4 J 10JUN LHRJFK HK2 1005 1310 O* E FR



FONE-LONB*8168916876

TKTG-TAW/WE01JUN/1600

>




Below is the*SI display for the original booking (before any Divide function is performed). This example shows an SSR DOCS item for Passenger 1 (SMITH/JOHN) that was added prior to implementation of this enhancement. However, the SSR DOCS and SSR DOCO items for Passenger 2 (TESTVO/VIC) were added after implementation of this enhancement.

Entry: >*SI

Response:

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15



S 1. DL 0004 J 10JUN LHRJFK

P 1. SMITH/JOHN DOCS HK 1 P/US/XXXXX5678/US/XXXXXXX/-

M/23OCT12/SMITH/JOHN/RICH -

ARD/H

P 2. TESTVO/VIC SPML PN 1 NO EGGS

NO OSI EXISTS


1. SSRFOIDDL HK 1 /CCVIXXXXXXXXXXX8923-1SMITH/JOHN

2. SSRFOIDDL HK 1 /DLGB12341234-1TESTVO/VIC

3. SSRDOCSDL HK 1 /A/GB/XXXXX8901/GB/XXXXXXX/M/23OCT12/TESTVO

/VICTOR/ALLEN-TESTVO/VIC

4. SSRDOCODL HK 1 /LONDON GB/R/XXX2310/LONDON GB/14MAR15/US-T

)>MD

Moving Down:

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15





ARD/H


NO OSI EXISTS







ESTVO/VIC

)>




The Divide function is used to Divide Passenger 2 from the original Booking File:

Entry: >DP2

Response:

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

Q1P0B8/86 XDBKR E335860 AG 99999992 08MAR

1.1TESTVO/VIC



** DIVIDED BOOKINGS EXIST ** >*DV



NOTE--S*SPLIT PTY/28MAR/86AG/XDB/Q1P0B8 86 28MAR 1401Z

>

As shown below, when the *SI entry is made after the Divide entry is made for Passenger 2 (TEXTVO/VIC) all related SSR items for Passenger 2 will be moved to the Booking File for Passenger 2.

Entry: >*SI

Response:

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

12





NO OSI EXISTS






ESTVO/VIC

>




Entry to File the Divided Booking File: >F Followed by Received From Entry: >R.VO Response: Displays the booking file for Passenger 1:

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

RECORD FILED

Q1P0B8/86 XDBKR E335860 AG 99999992 08MAR

1.1SMITH/JOHN




** DIVIDED BOOKINGS EXIST ** >*DV



NOTE--S*SPLIT PTY/28MAR/86AG/XDB/Q1P3FE 86 28MAR 1401Z

>

When the *SI entry is made for Passenger 1 (SMITH/JOHN) all related SSR items for Passenger 1 are moved. Entry: >*SI

Response:

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10






ARD/H

NO OSI EXISTS



>

NOTE: THE SSR DOCS ITEM FOR PASSENGER 1 WAS ADDED TO THE BOOKING

FILE PRIOR TO IMPLEMENATION OF THIS ENHANCEMENT.

9. Repeat (REALL and REALLSALL)

The following changes will apply when a Repeat and End Transact (e.g. REALLSALL or REALL) function is performed on a PNR or Booking File that contains SSR DOC item(s). 9.1 Apollo

This enhancement will not change processing when a Repeat and End Transact (e.g. REALLSALL or REALL) is performed in Apollo. All SSR types will continue to be copied to the newly created PNR in the SSR format (automated and/or non-automated) stored in the in the PNR being Repeated.




9.2 Galileo

In Galileo only automated (Programmatic) SSRs are currently copied when the Repeat function (e.g. REALL or REALLSALL) is used. This enhancement will ensure all non-automated SSR DOC types (i.e. DOCA, DOCO and DOCS) are also copied during the Repeat and End Transact process. e.g. A display of the original booking file indicates that there are SPECIAL SERVICE

REQUIREMENTS.

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

12

ZT2PZ8/86 XDBKR E335860 AG 99999992 09FEB

1.1TESTOC/JOHN

1. KL 2750 J 10MAY LCYAMS HK1 0750 1005 O E TU

OPERATED BY CITYJET




** TINS REMARKS EXIST ** >*HTI

** ELECTRONIC DATA EXISTS ** >*HTE


TKTG-T*XDB 10FEB1700Z 86 AG

>

The following SSR items are present in the *SI display in the original booking File. Entry: >*SI Response:

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

12

13

14



S 1. KL 2750 J 10MAY LCYAMS

P 1. TESTOC/JOHN TKNE HK 1 0749900606413C1

NO OSI EXISTS


1. SSRFOIDKL HK 1 /NI55511123A-1TESTOC/JOHN

2. SSRDOCSKL HK 1 /P/GB/XXXXX5678/GB/XXXXXXX/M/23OCT14/TESTO

OC/JOHN/PATRICK-TESTOC/JOHN

3. SSRDOCAKL HK 1 /R/US/234 DAREDEVEL ST/HANOVER/MO/11718-TE

STOC/JOHN

4. SSRDOCOKL HK 1 /LONDON GB/R/XXX2310/LONDON GB/14MAR09/US-

TESTOC/JOHN

>

Repeat all segments and all Customer Data by using the following entries:

Received From Entry: >R.VO

Repeat Entry: >REALLSALL




Response: 1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

1.1TESTOC/JOHN

1. KL 2750 J 10MAY LCYAMS NN1 0750 1005 TU



RCVD-VO

>

With this enhancement, when a request is made to Repeat all segments and all customer data all non-automated (Manual) SSR DOC items will be copied into the *SI display in the newly created Booking File, as illustrated below:

Entry: >*SI

Response: 1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

12

13



S 1. KL 2750 J 10MAY LCYAMS

P 1. TESTOC/JOHN TKNE HK 1 0749900606413C1

NO OSI EXISTS


1. SSRFOIDKL HK 1 /NI55511123A-1TESTOC/JOHN

2. SSRDOCSKL HK 1 /P/GB/XXXXX5678/GB/XXXXXXX/M/23OCT14/TESTOC

/JOHN/PATRICK-TESTOC/JOHN

3. SSRDOCAKL HK 1 /R/US/234 DAREDEVEL ST/HANOVER/MO/11718-TES

TOC/JOHN

4. SSRDOCOKL HK 1 /LONDON GB/R/XXX2310/LONDON GB/14MAR09/US-T

ESTOC/JOHN >

NOTE: WHEN PRESENT, ALL AUTOMATED (PROGRAMMATIC) SSRS WILL CONTINUE TO BE COPIED WHEN A ‘REPEAT AND END TRANSACT’ IS PERFORMED.

10. Name deletes/changes:

In line with current non-automated (Manual) SSR processing, Apollo and Galileo shall ensure that when a name is deleted or changed all related SSR DOC (DOCA, DOCO and DOCS) items are canceled.

NOTE: IN THE CASE OF A NAME CHANGE, THE USER WILL NEED TO CREATE A NEW SSR DOC ITEM FOR THE REVISED NAME.

11. Drop Through (Galileo only):

Galileo will modify Drop Through to remove segment related processing and ensure that SSR DOCS is modified. SSR DOCO and SSR DOCA are not applicable for Drop Through. Changes will be made to build non-automated (Manual) SSR DOCS items without using specific flight/segment details (e.g. flight, date, origin and destination). For examples of new non-automated (Manual) SSR DOCS entries, for Galileo refer to item 1.2 under section 1, above.




12. PNR Claim/Global Access:

Changes will be made in Apollo and Galileo to allow PNR Claim and Global Access to retrieve a PNR/Booking File that has SSR DOC items that do not contain specific flight/segment details (e.g. flight, date, origin and destination).

NOTE: THE FOLLOWING IS A SINGLE EXAMPLE (A SAMPLE) THAT SHOULD BE USED

FOR ILLUSTRATION PURPOSES, ONLY.

12.1 Example: A PNR is claimed from Apollo through Galileo Global Access. The Apollo PNR has a new SSR DOCS item (without specific flight/segment data) Apollo PNR:

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

10

11

JF999R/86 XDBKR E335860 AG 38212661 28JAN

1.1TESTVO/VIC


FONE-ORDT7135555454

TKTG-T/

GFAX-

SSRDOCSBAHK1/P/US/XXXXX5678/US/XXXXXXX/F/23OCT14/TESTVO/VICTOR-

TESTVO/VIC

ACKN-1A YKK111 29JAN 0525

>

Retrieval of Apollo PNR via Galileo Global Access: 1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

06

07

08

09

10

11

GLOBAL BOOKING FROM APOLLO

94V- JTB CWT BTS LON

JF999R/86 XDBKR E335860 AG 38212661 28JAN

1.1TESTVO/VIC

1. BA 219 Y 26MAR LHRDEN HK1 1235 1625 O* E SU




FONE-LONB*816-555-6876


>

Entry: >*SI

Apollo SSR DOCS translated to Galileo SERVICE INFORMATION Display via Global Access:

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

01

02

03

04

05

NO OSI EXISTS


1. SSRDOCSBA HK 1 /P/US/XXXXX4567/US/XXXXXXX/F/23OCT14/TESTVO

/VICTOR-TESTVO/VIC

>




13. Ticketing:

Apollo and Galileo will make internal changes to handle both automated SSR DOC items and new non-automated SSR DOC items at ticketing.

However, when an existing PNR/Booking File contains more than one segment on the same carrier, with old SSR DOC items, and one of those segments is cancelled (using the ‘cancel segment’ functionality e.g. >X2) then a new segment is rebooked on the same carrier, a new (Manual) SSR DOC item must be entered when the segment is rebooked.

Example:

An Apollo PNR or Galileo Booking File contains two AA segments both with SSR DOCS items in the old (Programmatic) SSR DOCS format. Segment 2 is cancelled using the ‘cancel segment’ functionality (e.g. >X2) then rebooked on another AA flight. When Segment 2 is cancelled then rebooked, the old SSR DOCS item for segment 2 is also cancelled. Due to the way the ticketing utility identifies flights as Secure Flight eligible, it will be necessary for the agent to enter a SSR DOCS item for AA in the new (Manual) format when segment 2 is rebooked.

e.g.

AA 123 Y20OCT ORDDFW HK1

AA 456 Y25OCT DFWORD HK1

Each segment for the existing itinerary (above) has a SSR DOCS in the old (Programmatic) SSR DOC format. Segment 2 is cancelled using the ‘cancel segment’ functionality. e.g. >X2 When segment 2 is rebooked (as illustrated below), a SSR DOCS in the new (Manual) SSR format must be entered for AA.

AA 123 Y20OCT ORDDFW HK1

AA 789 Y27OCT DFWORD HK1

Additionally, Apollo and Galileo will also ensure that Secure Flight Inhibit Ticketing requirements introduced November 1, 2010 are satisfied when a new non-automated (Manual) SSR DOC item exists for the airline(s) on the ticket

Additionally, Apollo and Galileo will also ensure that Secure Flight Inhibit Ticketing requirements introduced November 1, 2010 are satisfied when a new non-automated (Manual) SSR DOC item exists for the airline(s) on the ticket.

14. Traversa:

Traversa ‘After Sell Copy’ processing in Terminal Emulation takes information from the Traversa Profile and formats it into SSR DOC data to be put into the Booking. Apollo and Galileo will make internal changes to format the SSR DOC items as the new non-automated SSR DOC items during this process. There are no changes to the entry formats or how the data displays in the Traversa Profile Display.




Glossary

Term Definition

Programmatic Automated SSRs - include specific flight/segment details (flight, date, origin and destination.

Manual Non-Automated SSRs- do not include specific flight/segment details (flight, date, origin and destination.

SSR DOC Include SSR DOCA, SSR DOCO and SSR DOCS.




THE INFORMATION CONTAINED IN THIS DOCUMENT IS CONFIDENTIAL AND

PROPRIETARY TO TRAVELPORT

Copyright Copyright © Travelport and/or its affiliates. All rights reserved.

Travelport provides this document for information purposes only and does not promise that the information contained in this document is accurate, current or complete. This document is subject to change without notice. No part of this document may be

reproduced, stored in a retrieval system, or transmitted in any form or any means electronic or mechanical, including photocopying and recording for any purpose other than the licensee’s personal use without the prior written permission of Travelport and/or its

affiliates.

Trademarks Travelport and/or its affiliates may have registered or unregistered patents or pending patent applications, trademarks copyright, or other intellectual property rights in respect of the subject matter of this document. The furnishing of this document does not confer

any right or license to or in respect of these patents, trademarks, copyright, or other intellectual property rights.

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

pa 1169 (version 09) remove segment association on ssr doc...

Documents