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.
INTRODUCTION
1 3 4 6 6 7 9 14 14 14 15 16 24 25 26 33 37 39
The Process Flow Pointing the process at your TTY Reject Queue 2 SEGMENT HANDLING THE DEFAULT PROCESS
Rules used by the Default Process Actions taken by the Default Process The Default Process Represented as an IF THEN ELSE Statement 3 OSI/SSR HANDLING THE DEFAULT PROCESS
Rules used by the Default Process Actions taken by the Default Process The Default Process Represented as an IF THEN ELSE Statement How Add SSR to PNR is Handled by the Process a reference How Add OSI to PNR is Handled by the Process a reference 4 BUILDING YOUR OWN CUSTOM RULES AND ACTIONS
Actions Segment Action Rule SSR/OSI Action Rule SSR/OSI Action Rule an example
SabreSonic Revenue Integrity TTY Reject Process User Guide Sabre Airline Solutions
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.
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.
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.
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
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 Is Host Booking
Description 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). 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 Codeshare
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
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 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 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 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
Is Matching PNR Found
Is Matching Segment in PNR
Matching PNR Segment modified after TTY sent
Actions taken by the Default Process
Action No Action Create PNR based on TTY
Description Indicates that no action is required for this TTY segment A PNR will be created. The names from the TTY will be copied into the new PNR along with the record locator The TTY segment will be long sold into the Sabre PNR using the action code specified. The matching PNR segment will have its status code changed to the action code specified. The matching PNR segment will be cancelled with an X1 type transaction
Sell TTY Segment in the PNR
Modify Status of PNR Segment that matches TTY Segment Cancel PNR Segment that matches TTY Segment 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. 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.
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 = No Action If Status of matching PNR segment = Modify Status of PNR Segment that ActionCode:UN If Status of matching PNR segment = FlagError
UN HK or SC or RR matches TTY Segment Other
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
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 Status of matching PNR segment = Other FlagError 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 Status of matching PNR segment = HL Modify Status of PNR Segment that matches TTY Segment ActionCode:UU If Status of matching PNR segment = Other FlagError 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 Status of matching PNR segment = Other FlagError If Segment Status Code = HL
10
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 Status of matching PNR segment = Other FlagError 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 Status of matching PNR segment = Other FlagError 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 Status of matching PNR segment = HL Modify Status of PNR Segment that matches TTY Segment ActionCode:UU If Status of matching PNR segment = Other FlagError 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 Status of matching PNR segment = Other FlagError If Segment Status Code = HS or CY or If Status of matching PNR segment Send TTY NRL If Status of matching PNR segment FlagError need to ask agents If Status of matching PNR segment FlagError If Segment Status Code = LK or DK If Status of matching PNR segment Send TTY NRL If Status of matching PNR segment FlagError need to ask agents If Status of matching PNR segment FlagError ZY = HK or SC or RR = HL what they would do = Other
= HK or SC or RR = HL what they would do = Other
If Segment Status Code = XX or IX

11
If Status of matching Cancel PNR Segment If Status of matching Cancel PNR Segment If Status of matching FlagError If Segment Status Code = If Status of matching FlagError If Status of matching Cancel PNR Segment If Status of matching FlagError
PNR segment = HK or SC or RR that matches TTY Segment PNR segment = HL that matches TTY Segment PNR segment = Other
XL PNR segment = HK, SC or RR PNR segment = HL that matches TTY Segment PNR segment = Other
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 ActionCode:SQ If Segment Status Code = CS or ZS 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 ActionCode:OB If Segment Status Code = CY or ZY 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
12
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:LL If Segment Status Code = CL or ZL or CW or ZW 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.
13
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 Message Type
Description 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. Specifies the action code of the SSR in the TTY message
SSR Status Code
Actions taken by the Default Process
Placeholder No Action Add PNR SSR that matches TTY SSR
Description Indicates that no action is required for this TTY SSR or OSI message 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. The TTY SSR will be attempted to be cancelled from the PNR. 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.
Cancel PNR SSR that matches TTY SSR Add PNR OSI that matches TTY OSI
14
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.
15
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 Code Description 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 0 Description 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. 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
16
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 The possible values are: Value 0 Description 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. 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 0 Description If the TTY SSR relates to multiple passengers then only a single SSR related to the same passengers should be added into the PNR 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
17
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 0 Description 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. 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 0 Description The addition of the SSR should not be skipped if the PNR contains a matching SSR. 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 Blank Meaning of matching SSR
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. 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.
Non blank
18
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 0 Description Any matching SSR should not be removed from the PNR prior to SSR addition 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 0 Meaning of matching SSR
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. 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:
19
Value
Description If the Column is left blank then the short hand format for adding SSRs to the PNR will be used.
(i.e. blank) @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 HK1SEAEWR0014M24JUL1TSONTON/JOANN.005215096 4478C2)
Non blank value Carrier Code to use for SSR Addition
The actual action code to be used in the long format transaction for adding the SSR
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). The possible values are: Value Description Left blank if the short hand format for adding SSRs to the PNR will be used. (i.e. blank) @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 HK1SEAEWR0014M24JUL1TSONTON/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. The possible values are: Value Description
20
(i.e. blank) @MSG@
If the column is left blank then non message text will be included in the SSR added to the PNR.
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 The actual message text to be used in the transaction for adding the SSR
Non blank value 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 0 Description The explicit Sabre passenger relation option can be used when adding the SSR to the PNR. 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 0 Description The explicit Sabre passenger relation option can be used when adding the SSR to the PNR. 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.
21
Add SSR to PNR Reference Table

Code Pax relate Seg relate Indivually Pax relate WCBD, WCBW, WCHC, WCHR, WCHS, WCMP, WCOB SPML 1 1 1 1 1 1 WCBD, WCBW, WCHC, WCHR, WCHS, WCMP, WCOB ??ML, LCAL, LOCH, FRBL ??ML, LCAL, LOCH, FRBL AVIH, PETC, BLND, DEAF, BSCT, FLEO, MILT, MEDA, STCR, DEPA, DEPU, COUR, SEMN, LANG, TWOV, MAAS CBBG, CKIN, SabreSonic Revenue Integrity TTY Reject Process User Guide Sabre Airline Solutions 1 1 1 @MSG@ 0 1 0 0 0 1 1 1 1 1 1 ??ML, LCAL, LOCH, FRBL 1 1 0 0 0 1 1 1 0 0 @MSG@ 1 1 1 0 0 1 1 1 0 0 Similar Code Action Code for PNR SSR Carrier Code for PNR SSR Message for PNR SSR Is Code Exclusive? Skip If Already Exists? Remove If Already Exists? Expand Pax Relation Expand Seg Relation
22
WEAP, XBAG UMNR 1 1 1 @MSG@ See note (1) TKNA, TKNM, TKNC ADTK OTHS FOID FQTV 0 0 1 1 0 0 0 0 0 0 1 1 @CC@ @MSG@ @MSG@ @MSG@ @MSG@ See note (2) TKNE INFT CHLD PSPT PCTC DOCS DOCO DOCA 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 1 1 1 1 1 1 1 1 @AC@ @CC@ @MSG@ @MSG@ @MSG@ @MSG@ @MSG@ @MSG@ @MSG@ @MSG@ 0 0 0 1 1 0 0 0 1 1 1 1 1 1 1 1 0 0 0 1 1 1 1 1 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 @AC@ @CC@ @MSG@ 0 1 0 1 1 1 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])
23
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.
24
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 airlines 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.
25
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 semicolon. 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
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 Then Execute sequence of actions specified by SPECIAL ACTION SPECIAL MARKET
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) Carrier Codes (this is the Marketing Carrier) Booking Class (this is the Marketing Booking Class) Dates
Evaluations
Compares with UserDefined group
IS A MEMBER OF IS NOT A MEMBER OF IS A MEMBER OF IS NOT A MEMBER OF IS A MEMBER OF IS NOT A MEMBER OF
Carrier Code Group
Classes Group
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
33
Point of Sale
Location Group
Route O&D Pair
Market Group
O&D Pair
Market Group
Originating CRS
CRS Group
IATA Numbers
IATA Group
Originating Pseudo City
Pseudo City Code Group Dates Group
PNR Creation Date
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?) Is First Air Segment (Is this the 1st segment in the PNR?)
TRUE FALSE TRUE FALSE
N/A
N/A
34
Is Last Air Segment (Is this the last segment in the PNR?) Is Codeshare (Is there a codeshare info tag line for this segment?) Marketing Carrier Shown First (i.e. Marketing info in the itinerary, Operator info in the tag line?) CS (Codeshare) Partner Flight Nbr Not Advised. (Does the codeshare tag line not contain the Flight Number info?) OP (Operator) Carrier Codes OP (Operator) Booking Class OP (Operator) Flight Number User Defined Condition
TRUE FALSE TRUE FALSE TRUE FALSE
N/.A
N/A
N/A
TRUE FALSE
N/A
IS A MEMBER OF IS NOT A MEMBER OF IS A MEMBER OF IS NOT A MEMBER OF IS A MEMBER OF IS NOT A MEMBER OF SELECT USER DEFINED CONDITION FROM LIST
Carrier Code Group
Classes Group
Flight Number Group
True for this item True for any item False for this item False for any item
TRUE FALSE
Is Matching Segment Found in PNR Status of Matching PNR Segment
TRUE FALSE IS A MEMBER OF IS NOT A MEMBER OF Status Code Group
35
Matching PNR Segment modified after TTY Sent Is Informational Segment
TRUE FALSE 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.
36
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 Then Execute sequence of actions specified by PSPT ACTION PSPT
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) Point of Sale
Evaluations
Compares with UserDefined group
Location Group
Originating CRS
CRS Group
IATA Numbers
IATA Group
Originating Pseudo City
Pseudo City Code Group Dates Group
PNR Creation Date
Is Ticketed
TRUE FALSE
N/A
37
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?) Message Type
TRUE FALSE EQUALS
N/A
GEN FAX SSR GEN FAX OSI
SSR Message Code
Message Code Group
SSR/OSI Carrier Code
Carrier Code Group
SSR Status Code
Status Code Group
Message Text
Message Text Group
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.
38
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

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Sabre Sonic Revenue Integrity - TTY Reject Processing - User Guide v1 - 1

Enviado por

Direitos autorais:

Formatos disponíveis

SabreSonic Revenue Integrity TTY Reject Processing

Sabre Airline Solutions Version 1.1 February 2009

The TTY Reject Queue

The Default Process

Rules and Actions available to the user

Segment Action Rule SSR/OSI Action Rule

The Process Flow

Pointing the process at your TTY Reject Queue

Segment Handling The Default Process

Rules used by the Default Process

Rule Is Host Booking

Segment Status Code

Is Matching PNR Found

Is Matching Segment in PNR

Matching PNR Segment modified after TTY sent

Actions taken by the Default Process

Action No Action Create PNR based on TTY

Sell TTY Segment in the PNR

The Default Process Represented as an IF THEN ELSE Statement

UN HK or SC or RR matches TTY Segment Other

= HK or SC or RR = HL what they would do = Other

If Segment Status Code = XX or IX

OSI/SSR Handling The Default Process

Rules used by the Default Process

Rule Message Type

SSR Status Code

Actions taken by the Default Process

Placeholder No Action Add PNR SSR that matches TTY SSR

The Default Process Represented as an IF THEN ELSE Statement

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

Individually Pax Relate

Skip If Already Exists?

Remove If Already Exists?

(i.e. blank) @AC@

Non blank value Carrier Code to use for SSR Addition

Message for PNR SSR

(i.e. blank) @MSG@

Non blank value Expand Pax Relation

Expand Seg Relation

Add SSR to PNR Reference Table

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

Building Your Own Custom Rules and Actions

Send TTY NRL

Sell TTY Segment into PNR

Cancel PNR Segment that matches TTY Segment

Modify Status of PNR Segment than matches TTY Segment

Add PNR SSR that matches TTY SSR

Add PNR OSI that matches TTY OSI

Cancel PNR SSR that matches TTY SSR

Add SSR to PNR

Add OSI to PNR

Add Remark to PNR

Add ApFax SSR to PNR

Add ApFax OSI to PNR

Skip and Queue

Skip and Remove from Queue

Segment Action Rule

Compares with UserDefined group

IS A MEMBER OF IS NOT A MEMBER OF IS A MEMBER OF IS NOT A MEMBER OF IS A MEMBER OF IS NOT A MEMBER OF

Carrier Code Group

IS WITHIN RANGE IS NOT WITHIN RANGE

Flight Number Group