sabre sonic revenue integrity_tty reject processing_user guide v1_1

SabreSonic Revenue Integrity TTY Reject Processing User Guide

Sabre Airline Solutions Version 1.1 February 2009

smart.proven.bankable.

This documentation is the confidential and proprietary intellectual property of Sabre Airline Solutions. Any unauthorized use, reproduction, preparation of derivative works, performance or display of this document or software represented by this document, without the express written permission of Sabre Airline Solutions is strictly prohibited. Sabre Airline Solutions, the Sabre Airline Solutions logo and products shown in italic are trademarks and/or service marks of an affiliate of Sabre Holdings Corporation. All other trademarks, service marks and trade names are the property of their respective owners. © 2008 Sabre Inc. All rights reserved.

SabreSonic Revenue Integrity TTY Reject Process User Guide Sabre Airline Solutions

i

1 INTRODUCTION 1

The Process Flow 3

Pointing the process at your TTY Reject Queue 4

2 SEGMENT HANDLING – THE DEFAULT PROCESS 6

Rules used by the Default Process 6

Actions taken by the Default Process 7

The Default Process Represented as an IF THEN ELSE Statement 9

3 OSI/SSR HANDLING – THE DEFAULT PROCESS 14

Rules used by the Default Process 14

Actions taken by the Default Process 14

The Default Process Represented as an IF THEN ELSE Statement 15

How ‘Add SSR to PNR’ is Handled by the Process – a reference 16

How ‘Add OSI to PNR’ is Handled by the Process – a reference 24

4 BUILDING YOUR OWN CUSTOM RULES AND ACTIONS 25

Actions 26

Segment Action Rule 33

SSR/OSI Action Rule 37

SSR/OSI Action Rule – an example 39


1

1 Introduction This document describes the TTY Reject Process in SabreSonic Revenue Integrity. This process is significantly different from the original eight Revenue Integrity processes; therefore it was decided to create a separate user guide for this process as a supplement to the main Revenue Integrity User Guide.

The TTY Reject Queue

An external user can create a PNR on an external GDS or Other Airline (OA) system that contains a flight the host airline. When this happens a TTY Message will be sent from the GDS, (or Other Airline) to the host airline to allow the host to create a PNR on their HA system. Subsequent segment or SSR/OSI updates by the external agent will also result in TTY messages being sent from the GDS or OA to the host to notify the host of changes to the booking. In this situation the original PNR on the external GDS or OA system is the master PNR. The host needs to keep their PNR on their HA system in sync with this master PNR. The TTY messages sent by the external GDS or OA system are Request TTY messages which inform the HA of the changes that the HA needs to make to their PNR on their HA system to keep it in sync.

However, it is also possible for the host airline itself to create a PNR. This PNR will no doubt contain segments for the host but, it may also contain segments that the host has booked on other airlines. The host system will, in this situation, be acting like the external GDS or OA system described above. The host system will notify the OA that they have created a PNR containing an OA segment by sending the OA a TTY. Subsequently, when the host makes changes to the PNR the HA system will notify the OA of the changes by sending it further TTY messages. In this situation the host PNR will be the master PNR and the OA system will need to keep its PNR in sync with that of the host. However, it might be that the OA is not able to honour the booking. For example, the OA flight booked might be cancelled by the OA and / or might be replaced by a different OA flight. In this situation the OA system might send the host a Reply TTY to notify them of this fact. In this situation the host system would need to update its master PNR to reflect the cancellation and / or replacement of the OA flight with a different OA flight.

Ordinarily, these TTY messages are handled by the native Sabre host system without human intervention. However, for whatever reason, the messages sometimes fail to get acted upon automatically and will therefore end up on the TTY Reject Queue.

It is this Queue that the TTY Reject Process in Revenue Integrity is going to be working on with a view to taking the appropriate action indicated by the TTY message.

As such, there are two key differences between the TTY Reject Process and the other Revenue Integrity processes. Firstly, the process comes with a pre-configured ‘default’ process. Secondly, the rules and actions available to the user are unique to the TTY Reject process and differ from those used by the other Revenue Integrity process.


2

The Default Process

Out of the box the TTY Reject process has been configured with a ‘default’ process to handle the most common action requests directed by the incoming TTY messages. This default process is invisible to the user, residing in the background of the application. It is therefore the chief aim of this document to describe this default process. The following sections describe this default process should be used in order to become familiar with what the process is doing. If having understood the default process, you decide that you need to create additional rules and actions – or you need to over-rule a condition or action in the default process - then there are rules and actions available to the user that allow you to do this.

Rules and Actions available to the user

The TTY Reject Process uses different rules and actions to those used by the other Revenue Integrity process. Firstly, there are many different actions related to TTY operations and these are described fully in the Actions chapter of this document.

Secondly, the rules used by the TTY Reject Process differ from those used elsewhere in Revenue Integrity. In fact, there are jus two types of rule used by this process

• Segment Action Rule

• SSR/OSI Action Rule

There are two element types in the TTY Message that the process is looking to take action on. The Segment Action Rules will evaluate the lines in the TTY that are segments and the SSR/OSI Action Rules will evaluate the lines in the TTY that are SSR or OSI messages. These rules use the same kind of IF THEN ELSE statements that are used elsewhere in Revenue Integrity where conditions can be defined and then Actions can be called depending on whether or not the conditions have been met. These rules also use Groups in the same way as the other Revenue Integrity processes.


3

The Process Flow

The Process begins by taking the next message off the TTY Reject Queue. You are able to view or configure the queue being used by the application via the Revenue Integrity ‘Table’ menu. Please see the section ‘Pointing the process at your TTY Reject Queue’ for more information about this.

Next the process will try and find a PNR on the host that matches the TTY Message. The process will try to match the PNR based on the following criteria:

• Sometimes, Sabre will add a header line to the TTY message such as ‘ABCDEF IS PNR ADDR’ (where ABCDEF is the record locator. When this header is in place, the process will simply use the record locator to retrieve the PNR.

• Otherwise, the process will look for the OAL record locator and try and retrieve the PNR using ‘TM*1A/ABCDEF’ where 1A is the GDS or OAL and ABCDEF is the OAL record locator.

• Otherwise the process will take the flight from the TTY message and use a flight list to find the PNR by matching the passenger name.

If the process cannot match the TTY with a Host PNR, and the TTY contains instructions to sell a segment on the host, then the assumption is that the process needs to create a new PNR on the Host.

Next, the process will look for lines in the TTY Message that are Segments or SSR/OSIs and will process these lines one by one. First it will look at the Segment Action Rules, or SSR/OSI Action Rules that have been created by the user.

If the TTY element satisfies a rule that the user has provided, then this rule will be used by the process and the subsequent actions will be called.

If the TTY element does not satisfy any rules that the user has provided, then the default process will be used.

If the default process is unable to process the TTY Message, then it will be placed on the user-defined Error Queue.

Pointing the process at your TTY Reject Queue

The following explains how to set up your application so that it is pointing at your TTY Reject Queue.

On the main Revenue Integrity menu, click ‘Tables’

In the Configuration Tables menu, click ‘Input Queue Tables’

Here you can see all your existing Input Queue Table settings. Check to see if one of them is being used by the TTY Reject Process, (in the Process Type column). If this is present, then this row in the table will show the Queue the process is using.

If there is no entry for the TTY Reject Process, then you can add one here by clicking the ‘Add New’ link.

Under ‘Process Type’ select TTY Reject Processing.

Enter the City Code, Queue Number and Prefatory in the next three boxes.

You now have options related to the running of the process.

Mode: The options are,

• 24 hours / 7 days a week: This process will run constantly.

• 24 hours / specified day of week. The process will run for 24 hours on a specified day. Use the ‘Day Of Week’ column to specify the day on which the process should run.

• Between specified hours / 7 days a week: The process will run every day but only between the hours specified. Use the ‘Start Time’ and ‘End Time’ boxes to specify the times between which the process should run everyday.

• Between specified hours / specified day of week: The process will run on a specified day of the week between specified hours. Use the ‘Day Of Week’ column to specify the day on which the process should run. Use the ‘Start Time’ and ‘End Time’ boxes to specify the times between which the process should run on that day.

Once you have entered all the settings, click ‘Add’ (on the right) to add the input queue instruction to the list and then click Submit to save.


4


5

Error Queue

As mentioned earlier in the chapter, when the process is unable to actions a TTY Message for whatever reason, then the TTY Message will be placed on an Error Queue as specified by the user.

In the Configuration Tables menu, click ‘Error Queue Tables’

Here you can see all your existing Error Queue Table settings. Check to see if one of them is being used by the TTY Reject Process, (in the Process Type column). If this is present, then this row in the table will show the Queue the process is using.

If there is no entry for the TTY Reject Process, then you can add one here by clicking the ‘Add New’ link.

Select the Process Type (TTY Reject Processing) and then provide the City Code, Queue Number and Prefatory. Click ‘Add’ to add this queue to the list and then click Submit to save


6

2 Segment Handling – The Default Process This section describes the way that the TTY Reject Automation will process TTY segments with different Action Codes. First we will look at the rules and actions used by the default process.

Rules used by the Default Process

Rule Description

Is Host Booking True: the TTY is an Outgoing TTY from an OAL or GDS notifying us of a change in a host created PNR.

False: The TTY is an Incoming TTY message for a TTY created PNR.

Segment Status Code Specifies the action code of the segment in the TTY message. (This is not to be confused with the Status Code of a PNR segment).

Is Codeshare True if the segment in the TTY is a codeshare segment. There are four Options for specifying codeshare segments in a TTY:

Option 1: OP069F10JUN AMSDTW HK1 / 1115 1330 -MA8069F/A

Option 2: MA3500C22SEP JFKDEN CS1/0800 1630

Option 3: OP0121C15JUN ATLZRH CS1 19151005/1

Option 4: OP123F/MA7007F15JAN LHRSYD CS2/10001500

where:

OP=Operating Carrier and MA=Marketing Carrier

Is Informational Segment True if the segment in the TTY is purely for informational purposes, such as connection information.

There are three criteria under which a TTY segment will be considered an Informational Segment:

1) when the TTY is for a Host Booking, then any TTY segment with a carrier code that matches that of the host airline will be considered to be Informational

2) when the TTY contains codeshare segments, then any non codeshare


7

segment will be considered to be Informational.

3) when the TTY is not for a Host Booking and does not contain any codeshare segments, then any segment with a carrier code that does not match that of the host airline will be an Informational segment.

Status of matching PNR segment Specifies the status code of the segment in the PNR that matches the segment in the TTY message

Is Matching PNR Found True if a PNR has been found in the Sabre system that matches the record locator of the TTY and which matches the passenger names in the TTY

Is Matching Segment in PNR Indicates whether or not a segment in the PNR exists which matches the TTY segment in Carrier Code, Flight Number, Class and Departure Date and which has a status code that matches the status code(s) specified

Matching PNR Segment modified after TTY sent

True if the history of the PNR shows that the most recent operation on the segment that matched the TTY segment occurred later than when the TTY was created.

Segments are matched by Carrier Code, Flight Number, Class and Departure Date

Actions taken by the Default Process

Action Description

No Action Indicates that no action is required for this TTY segment

Create PNR based on TTY A PNR will be created. The names from the TTY will be copied into the new PNR along with the record locator

Sell TTY Segment in the PNR The TTY segment will be long sold into the Sabre PNR using the action code specified.

Modify Status of PNR Segment that matches TTY Segment

The matching PNR segment will have its status code changed to the action code specified.

Cancel PNR Segment that matches TTY Segment

The matching PNR segment will be cancelled with an X1 type transaction

Send TTY NRL The Sabre transaction TTYNRL will be made in the AAA of the loaded PNR. This will result in a TRL message being sent to the booking source specified


8

in the PNR if an RR agreement is in place with the booking source.

The Send TTY NRL action will only be performed at the very end of the processing on the PNR and it will only be performed if there were no modifications made to any of the other segments in the PNR. This means that the TRL message will not be required if other messages are generated back to the booking source.

FlagError An error will be flagged resulting in the aborting of the processing of the TTY. The TTY Message will then be placed on the Error Queue, as specified in the ‘Tables’ menu in your Revenue Integrity application.


9

The Default Process Represented as an IF THEN ELSE Statement

If Is Host Booking

If Is Informational Segment No Action

Else (not info segment) If Is Matching PNR Found

If Is Matching Segment in PNR If Segment Status Code = UN If Status of matching PNR segment = UN No Action

If Status of matching PNR segment = HK or SC or RR Modify Status of PNR Segment that matches TTY Segment

ActionCode:UN If Status of matching PNR segment = Other FlagError

If Segment Status Code = TK If Status of matching PNR segment = TK No Action

If Status of matching PNR segment = UN Sell TTY Segment in the PNR ActionCode:TK

If Status of matching PNR segment = HK or SC or RR Modify Status of PNR Segment that matches TTY Segment

ActionCode:UN Sell TTY Segment in the PNR ActionCode:TK

If Status of matching PNR segment = Other FlagError

Else (no matching segment) If Segment Status Code = UN

FlagError

If Segment Status Code = TK Sell TTY Segment in the PNR ActionCode:TK

Else (no matching PNR) FlagError

End

Else (not host booking) If Is Informational Segment

If Is Matching PNR Found If Is Matching Segment in PNR If Segment Status Code = HK No Action

If Segment Status Code = XX


10

Modify Status of PNR Segment that matches TTY Segment ActionCode:XK

Else (no matching segment) If Segment Status Code = HK

Sell TTY Segment in the PNR ActionCode:HK

If Segment Status Code = XX No Action

Else (no matching PNR) If Segment Status Code = HK Sell TTY Segment in the PNR ActionCode:HK

If Segment Status Code = XX No Action

Else (not info segment)

If Is Matching PNR Found And Is Matching Segment in PNR

If Matching PNR Segment modified after TTY sent = FALSE If Segment Status Code = HK or CH or ZK

If Status of matching PNR segment = HK or SC or RR No Action

If Status of matching PNR segment = HL Modify Status of PNR Segment that matches TTY Segment ActionCode:UU


If Segment Status Code = HN If Status of matching PNR segment = HK or SC or RR

Modify Status of PNR Segment that matches TTY Segment ActionCode:KK



If Segment Status Code = RR or CR or ZR If Status of matching PNR segment = RR

No Action If Status of matching PNR segment = HK or SC

Modify Status of PNR Segment that matches TTY Segment ActionCode:RR

If Status of matching PNR segment = HL Modify Status of PNR Segment that matches TTY Segment ActionCode:HL


If Segment Status Code = HL


11

If Status of matching PNR segment = HL No Action

If Status of matching PNR segment = HK or SC or RR Modify Status of PNR Segment that matches TTY Segment ActionCode:KL


If Segment Status Code = SS or IS or CS or ZS If Status of matching PNR segment = HK or SC or RR

Send TTY NRL If Status of matching PNR segment = HL

Modify Status of PNR Segment that matches TTY Segment ActionCode:UU


If Segment Status Code = NN or IN or CN or ZN If Status of matching PNR segment = HK or SC or RR

Modify Status of PNR Segment that matches TTY Segment ActionCode:KK



If Segment Status Code = LL or CW or ZW or CL or ZL If Status of matching PNR segment = HK or SC or RR

Modify Status of PNR Segment that matches TTY Segment ActionCode:KL

If Status of matching PNR segment = HL Send TTY NRL


If Segment Status Code = HS or CY or ZY If Status of matching PNR segment = HK or SC or RR


FlagError – need to ask agents what they would do If Status of matching PNR segment = Other

FlagError

If Segment Status Code = LK or DK If Status of matching PNR segment = HK or SC or RR


FlagError – need to ask agents what they would do If Status of matching PNR segment = Other

FlagError

If Segment Status Code = XX or IX


12

If Status of matching PNR segment = HK or SC or RR Cancel PNR Segment that matches TTY Segment

If Status of matching PNR segment = HL Cancel PNR Segment that matches TTY Segment


If Segment Status Code = XL If Status of matching PNR segment = HK, SC or RR

FlagError If Status of matching PNR segment = HL

Cancel PNR Segment that matches TTY Segment If Status of matching PNR segment = Other

FlagError

Else (more recent action in history) No Action..

End If

Else (no matching PNR or no matching segment in PNR)

If (Is Matching PNR Found = TRUE AND Matching PNR Segment modified after TTY sent = FALSE) OR Is Matching PNR Found = FALSE

If Segment Status Code = HK or RR If Is Codeshare

Sell TTY Segment in the PNR ActionCode:ZS Else

Sell TTY Segment in the PNR ActionCode:SQ If Segment Status Code = CH or ZK or CR or ZR

Sell TTY Segment in the PNR ActionCode:ZS If Segment Status Code = SS or IS

If Is Codeshare Sell TTY Segment in the PNR ActionCode:ZS

Else Sell TTY Segment in the PNR

If Segment Status Code = CS or ZS ActionCode:SQ

Sell TTY Segment in the PNR ActionCode:ZS If Segment Status Code = HS

If Is Codeshare Sell TTY Segment in the PNR ActionCode:ZU

Else Sell TTY Segment in the PNR ActionCode:HS

If Segment Status Code = DK or LK If Is Codeshare

Sell TTY Segment in the PNR ActionCode:ZU Else

Sell TTY Segment in the PNR If Segment Status Code = CY or ZY

ActionCode:OB

Sell TTY Segment in the PNR ActionCode:ZU If Segment Status Code = HN or NN or IN

If Is Codeshare Sell TTY Segment in the PNR ActionCode:ZN

Else


13

Sell TTY Segment in the PNR ActionCode:NN If Segment Status Code = CN or ZN

Sell TTY Segment in the PNR ActionCode:ZN If Segment Status Code = HL or LL

If Is Codeshare Sell TTY Segment in the PNR ActionCode:ZL

Else Sell TTY Segment in the PNR ActionCode:L

If Segment Status Code = CL or ZL or CW or ZW L

Sell TTY Segment in the PNR ActionCode:ZL If Segment Status Code = XX or IX or CX or ZX

No Action If Segment Status Code = XL

No Action Else (more recent action in history)

See above for comments about this scenario No Action

End If

End If End If

End If It should be noted that if a TTY segment is not matched by any section of the above IF THEN ELSE statement then this will be taken as a reason to reject the TTY. The TTY message will then be placed on the Error Queue, as specified in the ‘Tables’ menu in your Revenue Integrity application.


14

3 OSI/SSR Handling – The Default Process

This section describes the way that the TTY Reject Automation will process TTY SSRs or OSIs with different Action Codes in terms of IF THEN ELSE statements. The following special placeholders are used for decision making points in these IF THEN ELSE statements:

Rules used by the Default Process

Rule Description

Message Type Indicates whether a TTY SSR or OSI is being processed. ‘GEN FAX SSR’ indicates it is an SSR while ‘GEN FAX OSI’ indicates it is an OSI.

SSR Status Code Specifies the action code of the SSR in the TTY message

Actions taken by the Default Process

Placeholder Description

No Action Indicates that no action is required for this TTY SSR or OSI message

Add PNR SSR that matches TTY SSR The TTY SSR will be attempted to be added into the PNR. The actual details of how the attempted addition of the TTY SSR into the PNR will be performed are fairly complex and are described in the section ‘How Add SSR to PNR is handled by the process’.

Cancel PNR SSR that matches TTY SSR The TTY SSR will be attempted to be cancelled from the PNR.

Add PNR OSI that matches TTY OSI The TTY OSI will be attempted to be added into the PNR. The actual details of how the attempted addition of the TTY OSI into the PNR will be performed are described are described in the section ‘How Add OSI to PNR is handled by the process’.


15

The Default Process Represented as an IF THEN ELSE Statement

If Message Type = GEN FAX SSR If SSR Status Code = HK, NN, DK, SS

Add PNR SSR that matches TTY SSR

If SSR StatusCode = XX Cancel PNR SSR that matches TTY SSR

Else If Message Type = GEN FAX OSI

Add PNR OSI that matches TTY OSI It should be noted that if a TTY SSR or OSI is not matched by any section of the above IF THEN ELSE statement then this will be taken as a reason to reject the TTY. The TTY message will then be placed on the Error Queue, as specified in the ‘Tables’ menu in your Revenue Integrity application.


16

How ‘Add SSR to PNR’ is handled by the Process – a reference

Please note that this section is for reference only. It explains exactly how the ‘Add SSR to PNR’ action type is handled by the TTY Reject Process. The information given here is not visible in the Process itself, but rather explains how the adding of an SSR to the PNR is handled in the background of the application.

The different types of SSRs that can be added to the PNR need to be handled in slightly different ways. The handling of the different SSR types is summarised in the ‘Add SSR to PNR’ Reference Table with columns that specify the different parameters used for the handling of the SSRs. An individual row in the table applies to the TTY SSR type (or types) specified in the ‘Code’ column of the row (for example VGML types); the other columns in the row define how the SSR type (or types) will be handled.

The meaning of the different columns in the ‘Add SSR to PNR’ Reference Table are described below:

Column Description

Code Indicates the TTY SSR type that the row applies to. The Code is the 4 character SSR code extracted from the TTY SSR, for example:

SSR WCHC AZ NN1 FCOPMP 0754Y12OCT-1SMITH/JMR.

Pax Relate This column specifies whether or not it is mandatory that the SSR be added into the PNR with an explicit passenger association

The possible values are:

Value Description

0 When the SSR is added to the PNR it is not mandatory that it be explicitly passenger associated. If the TTY SSR is explicitly passenger related then the SSR will be added to the PNR with the same explicit passenger association. However, if the TTY SSR is not explicitly passenger related then the SSR will be added to the PNR without any explicit passenger association.

1 When the SSR is added to the PNR it is mandatory that it be explicitly passenger associated. If the TTY SSR is explicitly passenger related then the SSR will be added to the PNR with the same explicit passenger association. However, if the TTY SSR is not explicitly passenger related then the SSR message part will be examined to determine whether it contains a passenger name that matches one of the passenger names in the PNR – if so then it will be assumed that the SSR should be related to this passenger and therefore the SSR will be added to the PNR with an explicit passenger association to this passenger; if the SSR message part does not contain a passenger name then it will be assumed that the SSR should relate to all passengers in the PNR and therefore the SSR will be added to the PNR with an explicit passenger


17

association to all passengers in the PNR.

Seg Relate This column specifies whether or not it is mandatory that the SSR be added into the PNR with an explicit segment association


Value Description

0 When the SSR is added to the PNR it is not mandatory that it be explicitly segment associated. If the TTY SSR is explicitly segment related then the SSR will be added to the PNR with the same explicit segment association. However, if the TTY SSR is not explicitly segment related then the SSR will be added to the PNR without any explicit segment association.

1 When the SSR is added to the PNR it is mandatory that it be explicitly segment associated. If the TTY SSR is explicitly segment related then the SSR will be added to the PNR with the same explicit segment association. However, if the TTY SSR is not explicitly segment related then the SSR message part will be examined to determine whether it contains a segment string that matches one of the segments in the PNR – if so then it will be assumed that the SSR should be related to this segment and therefore the SSR will be added to the PNR with an explicit segment association to this segment; if the SSR message part does not contain a segment string then it will be assumed that the SSR should relate to all segments in the PNR and therefore the SSR will be added to the PNR with an explicit segment association to all segments in the PNR.

Individually Pax Relate

This column defines whether passenger related SSRs should be added into the PNR as a single SSR related to multiple passengers or as multiple SSRs each related to a single different passenger. The possible values are:

Value Description

0 If the TTY SSR relates to multiple passengers then only a single SSR related to the same passengers should be added into the PNR

1 If the TTY SSR relates to multiple passengers then multiple SSRs each related to a single different passenger should be added into the PNR

Similar Code Some types of SSRs (for example PSPT) are only allowed to be present in a PNR once for a

particular passenger. i.e. a PSPT SSR for Pax A cannot be entered into the PNR if the PNR already contains a PSPT SSR for Pax A. Furthermore, there are some SSR types that cannot be added into the PNR if another similar, but not exactly the same, SSR type already exists in the PNR. For example, a VGML SSR cannot be entered into the PNR for Pax A on Seg X if the PNR already contains a KSML SSR for Pax A on Seg X.

The Similar Code column defines which are the ‘similar’ SSR types for the SSR in question


18

which, if present in the PNR, would prevent the SSR from being added

Is Code Exclusive?

This column defines whether or not the SSR is one which is prevented from being added to the PNR if the PNR already contains an SSR with the same or similar code and with the same Passenger and Segment associations. The possible values are:

Value Description

0 The SSR is not one which is prevented from being added to the PNR if the PNR already contains an SSR with the same or similar code.

1 The SSR is one which is prevented from being added to the PNR if the PNR already contains an SSR with the same or similar code.

Skip If Already Exists?

This column specifies whether or not the addition of the SSR should be skipped if the PNR already contains a ‘matching’ SSR. The possible values are:

Value Description

0 The addition of the SSR should not be skipped if the PNR contains a ‘matching’ SSR.

1 The addition of the SSR should be skipped if the PNR contains a ‘matching’ SSR.

The meaning of ‘matching’ SSR is a little different depending on whether or not the message text part of the SSR to be added to the PNR is blank or not as shown below:

Message text part of the SSR to be added to the PNR

Meaning of ‘matching’ SSR

Blank A PNR SSR is ‘matching’ if the code of the PNR SSR matches the code of the TTY SSR and if the PNR SSR passenger relation covers the passengers that the TTY SSR relates to and if the PNR SSR segment relation covers the segments that the TTY SSR relates to.

Non blank

A PNR SSR is ‘matching’ if the code of the PNR SSR matches the code of the TTY SSR and if the message part of the PNR SSR matches the message part of the TTY SSR and if the PNR SSR passenger relation covers the passengers that the TTY SSR relates to and if the PNR SSR segment relation covers the segments that the TTY SSR relates to.


19

Remove If Already Exists?

This column specifies whether or not the addition of the SSR should be preceded by the removal from the PNR of any ‘matching’ SSRs. The possible values are:

Value Description

0 Any ‘matching’ SSR should not be removed from the PNR prior to SSR addition

1 Any ‘matching’ SSR should be removed from the PNR prior to SSR addition.

The meaning of ‘matching’ SSR is a little different depending on the value of the ‘Is Code Exclusive’ column as shown below:

Value of Is Code Exclusive

Meaning of ‘matching’ SSR

0 A PNR SSR is ‘matching’ if the code of the PNR SSR matches the code of the TTY SSR and if the message part of the PNR SSR matches the message part of the TTY SSR and if the PNR SSR passenger relation covers the passengers that the TTY SSR relates to and if the PNR SSR segment relation covers the segments that the TTY SSR relates to.

1 A PNR SSR is ‘matching’ if the code of the PNR SSR matches the code of the TTY SSR or if the code of the PNR SSR matches any of the items specified in the ‘Similar Code’ column and if the PNR SSR passenger relation covers the passengers that the TTY SSR relates to and if the PNR SSR segment relation covers the segments that the TTY SSR relates to.

The method of the removal of the matching SSRs depends on whether the passenger and segment association of the PNR SSR covers all passenger and segment associations of the TTY SSR. If so then the matching SSR is simply removed from the PNR otherwise, the passenger / segment association of the PNR SSR is simply modified to exclude the passengers and segments specified in the TTY SSR.

Action Code to use for SSR Addition

For some types of SSR the transaction used to add the SSR into the PNR uses the short hand format (i.e. 4VGML1-1.1) where neither the SSR Action Code or Carrier Code are specified. For other types of SSR the long hand format is used to add the SSR into the PNR where both the Action Code and the Carrier Code are specified (i.e. 4SSR TKNE AS HK1SEAEWR0014M24JUL-1TSONTON/JOANN.0052150964478C2).

This column defines whether or not the short or long hand format is used when adding SSRs to the PNR. The possible values are:


20

Value Description

(i.e. blank)

If the Column is left blank then the short hand format for adding SSRs to the PNR will be used.

@AC@ If the column contains the special string @ACTION_CODE@ then the long hand format for adding SSRs to the PNR will be used and the action code used in the transaction will be that extracted from the TTY SSR line, for example 4SSR TKNE AS HK1SEAEWR0014M24JUL-1TSONTON/JOANN.005215096

4478C2)

Non blank value

The actual action code to be used in the long format transaction for adding the SSR

Carrier Code to use for SSR Addition

For some types of SSR the transaction used to add the SSR into the PNR uses the short hand format (i.e. 4VGML1-1.1) where neither the SSR Action Code or Carrier Code are specified. For other types of SSR the long hand format is used to add the SSR into the PNR where both the Action Code and the Carrier Code are specified (i.e. 4SSR TKNE AS HK1SEAEWR0014M24JUL-1TSONTON/JOANN.0052150964478C2).


Value Description

(i.e. blank)

Left blank if the short hand format for adding SSRs to the PNR will be used.

@CC @ If the column contains the special string @CARRIER_CODE@ then the carrier code used in the transaction will be that extracted from the TTY SSR line, for example 4SSR TKNE AS HK1SEAEWR0014M24JUL-1TSONTON/JOANN.005215096

4478C2)

Non blank value

The actual carrier code to be used in the long format transaction for adding the SSR

Message for PNR SSR

This column is used to define the text for the message text part of the SSR added to the PNR.


Value Description


21

(i.e. blank)

If the column is left blank then non message text will be included in the SSR added to the PNR.

@MSG@ If the column contains the special string @MESSAGE@ then the message text used in the transaction will be that extracted from the message text part of the TTY SSR line, for example 4PSPT/ YP1237877/KR/26DEC52/CHAE/HYUNGWUNG/M-1.1

Non blank value

The actual message text to be used in the transaction for adding the SSR

Expand Pax Relation

For some types of SSR, TKNE and SEAT for example, it is not possible to use the explicit passenger relation option in the Sabre transaction (i.e. 4WCHR-1.1) to add the SSR into the PNR. For these types of SSRs it is necessary to spell out the passenger relation by prepending the passenger name string to the start of the message part of the SSR. i.e. like:

-JONES/JMR.MESSAGE TEXT

Value Description

0 The explicit Sabre passenger relation option can be used when adding the SSR to the PNR.

1 The explicit Sabre passenger relation option cannot be used when adding the SSR to the PNR. In this case it is necessary to prepend the name of the passenger that is required for the association to the message.

Expand Seg Relation

For some types of SSR, TKNE and SEAT for example, it is not possible to use the explicit segment relation option in the Sabre transaction (i.e. 4WCHR1) to add the SSR into the PNR. For these types of SSRs it is necessary to spell out the passenger relation by prepending the passenger name string to the start of the message part of the SSR, i.e. like SLCSEA0625U29AUG.MESSAGE TEXT

Value Description

0 The explicit Sabre passenger relation option can be used when adding the SSR to the PNR.

1 The explicit Sabre passenger relation option cannot be used when adding the SSR to the PNR. In this case it is necessary to prepend the name of the passenger that is required for the association to the message.


22

‘Add SSR to PNR’ Reference Table

Code Pax

relate

Seg

relate

Indiv-

ually

Pax

relate

Similar

Code

Action

Code for

PNR SSR

Carrier

Code for

PNR SSR

Message

for PNR

SSR

Is Code

Exclu-

sive?

Skip If

Already

Exists?

Remove If

Already

Exists?

Expand

Pax

Relation

Expand

Seg

Relation

WCBD,

WCBW,

WCHC,

WCHR,

WCHS,

WCMP,

WCOB

1 1 1 WCBD,

WCBW,

WCHC,

WCHR,

WCHS,

WCMP,

WCOB

1 1 1 0 0

SPML 1 1 1 ??ML,

LCAL,

LOCH,

FRBL

@MSG@ 1 1 1 0 0

??ML,

LCAL,

LOCH,

FRBL

1 1 1 ??ML,

LCAL,

LOCH,

FRBL

1 1 1 0 0

AVIH,

PETC,

BLND,

DEAF,

BSCT,

FLEO,

MILT,

MEDA,

STCR,

DEPA,

DEPU,

COUR,

SEMN,

LANG,

TWOV,

MAAS

1 1 1 1 1 0 0 0

CBBG,

CKIN,

1 1 1 @MSG@ 0 1 0 0 0


23

WEAP,

XBAG

UMNR 1 1 1 @MSG@

See note

(1)

1 1 1 0 0

TKNA,

TKNM,

TKNC

1 1 1 @AC@ @CC@ @MSG@ 0 1 0 1 1

ADTK 0 0 0 @MSG@ 0 1 0 0 0

OTHS 0 0 0 @MSG@ 0 1 0 0 0

FOID 1 0 1 @MSG@ 0 1 0 0 0

FQTV 1 0 1 @CC@ @MSG@

See note

(2)

0 1 0 0 0

TKNE 1 1 1 @AC@ @CC@ @MSG@ 0 1 0 1 1

INFT 1 1 1 @MSG@ 0 1 0 0 0

CHLD 1 1 1 @MSG@ 0 1 0 0 0

PSPT 1 0 1 @MSG@ 1 1 1 0 0

PCTC 1 0 1 @MSG@ 1 1 1 0 0

DOCS 1 0 1 @MSG@ 0 1 1 0 0

DOCO 1 0 1 @MSG@ 0 1 1 0 0

DOCA 1 0 1 @MSG@ 0 1 1 0 0

(1) The message in the TTY will be filtered and adapted before being used in the PNR SSR. Firstly, the process will extract any 1 or 2 digit number for the message. For example, if the message says CHILD IS 12 YEARS OLD, then “12” will be extracted. This number will then be used in the SSR for the PNR after the letters ‘UM’. So, to continue the example, if the TTY Message is ‘CHILD IS 12 YEARS OLD’, then the message used in for the PNR SSR will be ‘UM12’

(2) The Message in the TTY will be filtered before being used in the PNR SSR. Only the first alphanumeric character from the TTY SSR message string will be used in the SSR to be added to the PNR(^[A-Z0-9])


24

How ‘Add OSI to PNR’ is Handled by the Process – a reference

This section defines exactly how the ‘AddOSI’ action type is handled. This action type is very straightforward. The message text part of the TTY OSI and the carrier code part of the TTY OSI are simply extracted and are then used directly to add an OSI to the PNR.

Example:

TTY contains following OSI:

OSI AS HAVE A GOOD TRIP

The OSI would simply be added into the PNR with the following transaction:

4OSI AS HAVE A GOOD TRIP

Please note that the OSI addition will occur regardless of whether the PNR already contains a matching OSI.


25

4 Building Your Own Custom Rules and Actions In the previous sections of this document, we looked at the default process used by the TTY Reject Process. It could be that your airline’s requirements require rules in exception to this default process. There may be particular circumstances where you wish the process to do something over and above what is included in the default process. Also, there could be circumstances where you wish to process to do something instead of the actions taken by the default process.

Therefore, the TTY Reject Process has rules and actions that can be used to define exceptions to the default process. This process uses a slightly different set of building blocks than those used by the other Revenue Integrity processes and these will be described in this section. They are:

• Actions – Note that the TTY Reject Process has its own set of specific actions that differ from those used elsewhere in the Revenue Integrity application. Actions are created separately and then can be used in the Action Rules.

• Groups – Groups are common to all Revenue Integrity processes, including the TTY Reject Process, and are used by the Action Rules. When building the rules, data from the TTY message can be compared with data in the Groups. Please refer to the main Revenue Integrity user guide for full instructions on creating and using Groups.

• Segment Action Rules – These rules target the segment elements in the TTY message and decide which Action should be used.

• SSR/OSI Action Rules – These rules target the OSI and SSR elements in the TTY message and decide which Action should be used.

• User Defined Conditions – As with the other Revenue Integrity processes, user defined conditions can be used where you require more complex checks than those available in the Segment Action Rule. User Defined Conditions are not used by the SSR/OSI Action Rules. Please refer to the main Revenue Integrity user guide for full instructions on creating and using User Defined Conditions.

As with the other Revenue Integrity processes it is necessary to build the processes from the bottom up. That is, before you can create a Segment Action Rule or an SSR/OSI Action Rule, it is first necessary to create the Actions that the rule is going to use. The same applies to Groups. Before building a rule, you will need to define the groups that the rule will use.

We will now look at these elements in turn.

Actions

In the Process Flow of the TTY Reject Process, the Action Rules are checked and, if satisfied, can call an Action to perform the actual tasks required. Indeed, a particular outcome may need to apply a sequence, or series, of actions. Therefore an ‘Action’ could in fact be seen as a set of Action Components to be applied in sequence.

Existing ‘active’ Actions are listed in the Navigation Tree under the Action Rules to which they are associated. Also, all actions that have been created are available in the ‘Actions’ folder in the ‘New and Inactive Elements’ – including those that have been used in the process.

To create a new Action, you need to go to the bottom of the Navigation Tree – in the ‘Inactive and New Elements’ section. Look for the ‘Actions’ folder and click the (add new) link beneath. Remember that an Action will remain inactive until it is used in an Action Rule.

Clicking the (add new) link will open the following dialog.

There are many types of Action available and each has its own appropriate form. Next we will examine these different Action Types in detail.

No Action

This is the Action Type shown above. It simply means that no action will be taken on the TTY element being processed.

Flag Error

When this Action Type is invoked, the TTY message will be processed no further and the message will be placed on the specified Error Queue.


26

Queue TTY

This Action Type is used to place the TTY Message on a specified Queue. When this option is selected, the window will change to the boxes you can use to enter the City Code, Queue Number and Prefatory used to Queue Place the message.

Queue PNR

When a TTY Message is processed, we have seen how the process will either retrieve the matching PNR or create a new PNR. This Action Type is used to place the PNR on a specified Queue. When this option is selected, the window will change to the boxes you can use to enter the City Code, Queue Number and Prefatory used to Queue Place the message.

Send Email


27

This Action Type can be used to send an email. The ‘Distribution List’ box equates to the email ‘To’ field and can be used to enter the email address of the intended recipient. Multiple addresses can be entered if separated by a semi-colon.

Additional recipients can be added to the ‘CC List’ and ‘BCC List’ fields. Finally, there are Subject and Message Text fields.

Send TTY NRL

The Sabre transaction TTYNRL will be made in the AAA of the loaded PNR. This will result in a TRL message being sent to the booking source specified in the PNR if an RR agreement is in place with the booking source.

The Send TTY NRL action will only be performed at the very end of the processing on the PNR and it will only be performed if there were no modifications made to any of the other segments in the PNR. This means that the TRL message will not be required if other messages are generated back to the booking source.

Sell TTY Segment into PNR

This Action Type is used to long sell the TTY segment into the Sabre PNR. With this option selected, the ‘Segment Action Code’ box becomes visible. Here you should enter the 2-character action code that will be used when selling the segment into the PNR.

Cancel PNR Segment that matches TTY Segment

When this Action Type is used, the segment in the PNR that matches the segment in the TTY Message will be cancelled with an X1 type transaction.

Modify Status of PNR Segment than matches TTY Segment


28

When this Action Type is invoked, the matching PNR segment will have its status code changed to the action code specified in the ‘Segment Action Code’ box.

Add PNR SSR that matches TTY SSR

Using this Action Type, the TTY SSR will be attempted to be added into the PNR, maintaining any segment or passenger relate elements that may be included. Any values you enter in the ‘Code’, ‘Action Code, ‘Carrier Code’ and ‘Message’ fields will be used in place of the corresponding values in the original TTY SSR.

Add PNR OSI that matches TTY OSI


29

Using the Action Type, the TTY OSI will be attempted to be added into the PNR. Any values you enter in the ‘Carrier Code’ and ‘Message’ fields will be used in place of the corresponding values in the original TTY OSI.

Cancel PNR SSR that matches TTY SSR

When this Action Type is executed, the PNR SSR that matches the TTY SSR will be attempted to be cancelled from the PNR.

Add SSR to PNR

This Action Type can be used to add a new GEN FAX SSR to the PNR, regardless of whether or not there is a matching SSR in the TTY Message. When using this Action Type, you will need to provide the SSR Code, Status Code, Carrier Code and Message Text in the boxes provided.


30

Add OSI to PNR

This Action Type can be used to add a new GEN FAX OSI to the PNR, regardless of whether or not there is a matching OSI in the TTY Message. When using this Action Type, you will need to provide the Carrier Code and Message Text in the boxes provided.

Add Remark to PNR

This Action Type is used to add a Remark to the PNR. Enter the Message Text for the Remark in the ‘Text’ field.

Add ApFax SSR to PNR

This Action Type can be used to add a new AP FAX SSR to the PNR. When using this Action Type, you will need to provide the SSR Code, Status Code, Carrier Code and Message Text in the boxes provided.

Add ApFax OSI to PNR

This Action Type can be used to add a new AP FAX OSI to the PNR. When using this Action Type, you will need to provide the Carrier Code and Message Text in the boxes provided.


31

Skip and Queue

Using this Action Type causes processing on the TTY Message to be skipped and then places the Message on a Queue as specified in the City Code, Queue Number and Prefatory boxes.

It is important to note that this ‘skip’ action takes priority over all other actions. This means that if just one Segment or SSR/OSI element in the TTY uses this ‘Skip and Queue’ Action Type, then the whole TTY Message will be skipped and not processed at all.

Skip and Remove from Queue

This Action Type means the whole message will be skipped, (as in ‘Skip and Queue’ above). The Message will also be removed from the TTY Reject Queue and no further processing will be performed on it.


32


33

Segment Action Rule

The Segment Action Rules can be used to target the segment lines in the TTY message. As with all Revenue Integrity rules, they are built using IF THEN ELSE statements. The building of IF THEN ELSE statements is covered in general (and Action Rules in particular) in the main Revenue Integrity user guide and new users are advised to refer to that document for more information about building these IF Statements throughout Revenue Integrity.

The idea of the Segment Action Rule is to be able to call a particular action when the segment meets certain conditions. As ever, we are using the rules to compare information from the TTY with information in the Revenue Integrity Groups, meaning we can create a condition such as:

IF

O&D Pair IS A MEMBER OF SPECIAL MARKET

Then

Execute sequence of actions specified by SPECIAL ACTION

The following table shows all the TTY elements that can be targeted, the evaluations that can be made and the Group Type that the element uses in its comparisons.

Group Type (the element from the segment in the TTY)

Evaluations Compares with User-Defined group

Carrier Codes (this is the Marketing Carrier)

IS A MEMBER OF

IS NOT A MEMBER OF

Carrier Code Group

Booking Class (this is the Marketing Booking Class)

IS A MEMBER OF

IS NOT A MEMBER OF

Classes Group

Dates IS A MEMBER OF

IS NOT A MEMBER OF

Dates Group

Flight Number IS WITHIN RANGE

IS NOT WITHIN RANGE

Flight Number Group

Segment Status Code IS A MEMBER OF

IS NOT A MEMBER OF

Status Code Group


34

Point of Sale IS A MEMBER OF

IS NOT A MEMBER OF

Location Group

Route O&D Pair IS A MEMBER OF

IS NOT A MEMBER OF

Market Group

O&D Pair IS A MEMBER OF

IS NOT A MEMBER OF

Market Group

Originating CRS IS A MEMBER OF

IS NOT A MEMBER OF

CRS Group

IATA Numbers IS A MEMBER OF

IS NOT A MEMBER OF

IATA Group

Originating Pseudo City IS A MEMBER OF

IS NOT A MEMBER OF

Pseudo City Code Group

PNR Creation Date IS A MEMBER OF

IS NOT A MEMBER OF

Dates Group

Is Ticketed TRUE

FALSE

N/A

Is Group Booking TRUE

FALSE

N/A

Is Host Booking TRUE

FALSE

N/A

Is Part Flown TRUE

FALSE

N/A

Is Already Actioned (i.e. previously actioned by Revenue Integrity?)

TRUE

FALSE

N/A

Is First Air Segment (Is this the 1st segment in the PNR?)

TRUE

FALSE

N/A


35

Is Last Air Segment (Is this the last segment in the PNR?)

TRUE

FALSE

N/.A

Is Codeshare (Is there a codeshare info tag line for this segment?)

TRUE

FALSE

N/A

Marketing Carrier Shown First (i.e. Marketing info in the itinerary, Operator info in the tag line?)

TRUE

FALSE

N/A

CS (Codeshare) Partner Flight Nbr Not Advised. (Does the codeshare tag line not contain the Flight Number info?)

TRUE

FALSE

N/A

OP (Operator) Carrier Codes

IS A MEMBER OF

IS NOT A MEMBER OF

Carrier Code Group

OP (Operator) Booking Class

IS A MEMBER OF

IS NOT A MEMBER OF

Classes Group

OP (Operator) Flight Number

IS A MEMBER OF

IS NOT A MEMBER OF

Flight Number Group

User Defined Condition SELECT USER DEFINED CONDITION FROM LIST

True for this item

True for any item

False for this item

False for any item

Is Matching PNR Found TRUE

FALSE

Is Matching Segment Found in PNR

TRUE

FALSE

Status of Matching PNR Segment

IS A MEMBER OF

IS NOT A MEMBER OF

Status Code Group


36

Matching PNR Segment modified after TTY Sent

TRUE

FALSE

Is Informational Segment TRUE

FALSE

Reminder: If the TTY Segment fails to meet the conditions of all the Segment Action Rules entered by the user, then the default process will be used.


37

SSR/OSI Action Rule

The SSR/OSI Action Rules can be used to target the SSR and OSI lines in the TTY message. As with all Revenue Integrity rules, they are built using IF THEN ELSE statements. The building of IF THEN ELSE statements is covered in general (and Action Rules in particular) in the main Revenue Integrity user guide and new users are advised to refer to that document for more information about building these IF Statements throughout Revenue Integrity.

The idea of the OSI/SSR Action Rule is to be able to call a particular action when the SSR/OSI meets certain conditions. As ever, we are using the rules to compare information from the TTY with information in the Revenue Integrity Groups, meaning we can create a condition such as:

IF

SSR Message Code IS A MEMBER OF PSPT

Then

Execute sequence of actions specified by PSPT ACTION

The following table shows all the TTY elements that can be targeted, the evaluations that can be made and the Group Type that the element uses in its comparisons.

Group Type (the element from the SSR or OSI in the TTY)

Evaluations Compares with User-Defined group

Point of Sale IS A MEMBER OF

IS NOT A MEMBER OF

Location Group

Originating CRS IS A MEMBER OF

IS NOT A MEMBER OF

CRS Group

IATA Numbers IS A MEMBER OF

IS NOT A MEMBER OF

IATA Group

Originating Pseudo City IS A MEMBER OF

IS NOT A MEMBER OF

Pseudo City Code Group

PNR Creation Date IS A MEMBER OF

IS NOT A MEMBER OF

Dates Group

Is Ticketed TRUE

FALSE

N/A


38

Is Group Booking TRUE

FALSE

N/A

Is Host Booking TRUE

FALSE

N/A

Is Part Flown TRUE

FALSE

N/A

Is Already Actioned (i.e. previously actioned by Revenue Integrity?)

TRUE

FALSE

N/A

Message Type EQUALS GEN FAX SSR

GEN FAX OSI

SSR Message Code IS A MEMBER OF

IS NOT A MEMBER OF

Message Code Group

SSR/OSI Carrier Code IS A MEMBER OF

IS NOT A MEMBER OF

Carrier Code Group

SSR Status Code IS A MEMBER OF

IS NOT A MEMBER OF

Status Code Group

Message Text IS A MEMBER OF

IS NOT A MEMBER OF

Message Text Group

Is Matching PNR Found TRUE

False

Reminder: If the TTY OSI or SSR fails to meet the conditions of all the SSR/OSI Action Rules entered by the user, then the default process will be used.

SSR/OSI Action Rule – an example

In this example I want to build a rule that looks for an SSR with a code of ‘PSPT’ in the TTY Message.

If I find such an SSR I want to add an AP FAX SSR to the PNR. I want this AP FAX SSR to be an OTHS SSR with the carrier code copied from the original TTY SSR and the message text to be ‘PSPT’.

In order to build this rule, I first need to do two things. Firstly I need to define an SSR Message Code group that contains PSPT.

To do this, click on the Groups menu and select ‘Message Code Group’.

In the Message Code Group builder, I need to click ‘Add New’ to create a new group.

I can then configure this group to contain PSPT as a member.

I have named this group ‘PSPT’ for simplicity.

Next I need to create the Action that my rule will be executing.

At the bottom of the navigation tree, click (add new) under the Actions folder.

Remember, I want this action to add an AP FAX SSR to the PNR, so I choose the ‘Add ApFax SSR to PNR’ Action Type.


39

Also, I have entered the code OTHS, and the status code HK. For the Carrier Code, I am using the %CARRIER_CODE% placeholder to use the Carrier Code from the TTY SSR. Finally I have added PSPT into the Text field.

I am now ready to build the SSR/OSI Action Rule.

To recap: I want this rule to check that the TTY Message type is an SSR and that the Code is PSPT. So I can build my Action Rule like this:

This rule is checking that the Message Type is an AP FAX SSR, or a GEN FAX SSR.

Then, it is checking that the TTY SSR Message Code is member of the Group PSPT.

If these conditions are met, the process will execute my new PSPT TO OTHS SSR action and add the SSR to the PNR.


40


41

sabre sonic revenue integrity_tty reject processing_user guide v1_1

Documents