Overview

Automatically detects passenger contact details in the PNR and inserts them using CTCE/CTCM formats.

Description

This step automates the process of adding passenger contact information.

The system detects and inserts the passenger’s phone number and email address into the appropriate CTCM / CTCE SSR elements and OSI remarks.

How contact data is detected

The system reads contact information from the following PNR fields depending on the GDS:

Phone numbers (CTCM)

Detected phone numbers are added to SSR/OSI remarks once during processing.

If the phone number in the PNR is later changed or removed, the existing SSR/OSI entry will remain unchanged.

Email addresses (CTCE)

Detected email addresses are added to SSR/OSI remarks.

If the PNR is processed again and additional email addresses are detected, they will be added to the existing CTCE entries. Previously added email addresses remain unchanged.

Overview

Adds a retention segment to the PNR to prevent it from being archived.

Description

A retention segment extends the active storage period of a PNR in the GDS. It prevents the booking from being archived and keeps it accessible.

The system applies the configured settings and inserts either a retention segment or a remark with the calculated date into the PNR.

The maximum allowable number of days for this segment is determined by the technical parameters of the GDS in use.

Equivalent GDS commands

Settings

Define retention segment parameters:

• Select the reference point (Processing date or Last travel date)
• Set the number of days for the segment

Optionally:

• Add free-text remarks to be included in the segment note

Checkboxes

• Do not add a retention segment if one with a later date already exists –  if enabled, the system will not insert a new segment (even if different from the existing one), and the step will exit with OK
• Assign the maximum possible retention period –  keeps a PNR for the maximum possible period (up to 360 days from processing)

Workflow behavior

This element has OK and FAIL outputs. Processing will complete successfully if the retention segment with the calculated date is added successfully.

Exits via OK if:
Event #5237: Add retention segment

Exits via **FAIL** because:
*Event #5238: Add retention segment error alternatives*

In Test mode:
*Processing the scheme in Test mode will result in exit on Fail*

Workflow behavior

Examples of adding a retention segment and displaying it in the PNR:

Amadeus 

RU 1A HK 1 STO 09SEP

1. TEST/TEST MR
2  YY 123 Y 21DEC 7 MXPCDG HK1  0615 1  0655 0835   *1A/E*
3 MIS 1A HK1 CPH 09SEP

Sabre

0OTHYYGK1 STO 19JUN

1.1  1.TEST/TEST MR
1 YY 123 Y 21DEC S MXPCDG HK1   655A  835A /DCAF*XYZXYZ /E
2  OTH YY 19JUN F GK1  STO

Galileo (as segment)

0TURZZAK1 PAR 17AUG

1.1 TEST/TEST MR
1. YY 123 Y  21DEC MXPCDG HK1  0655   0835  O*       E SU
2. TUR ZZ AK1  PAR 17AUG

Galileo (as a remark)

RT.T/17AUG*

1.1 TEST/TEST MR
1. YY 123 Y  21DEC MXPCDG HK1  0655   0835  O*       E SU
2. T  **  TEXT **  17AUG-****

Often used with

Condition Coupon status (preceding) –  checks that the PNR contains a ticket with coupons still in Open status.

Condition Itinerary exists in PNR (preceding) –  monitors PNRs where (if the condition above is met) the itinerary is missing.

Overview

Checks for the presence of SSR DOCS and, if necessary, automatically adds missing passenger data to the PNR.

Description

At this step, the system checks for DOCS data for all passengers across all segments and, if any data is missing, adds the required information according to the data level defined in the settings.

Equivalent GDS commands

Settings

Configure the step by selecting one of the parameters. Each parameter defines the set of data that the system will add when it is used.

• SFPD (Secure Flight Passenger Data): Passenger name, gender, date of birth
• APIS (Advance Passenger Information System): SFPD data + travel document number

To use a fictitious DOB, enable the setting Apply pseudo SecureFlight when passenger information required for ticketing is missing so the system can insert a pseudo DOB.

Specify a value in the Commit to exit field.

Workflow behavior

Processing will complete successfully if all the data which is required for the setting level you've chosen was detected and successfully added.

Exits via OK if: Event #5137: Secure Flight information applied to PNR Event #5131: Create fake SecureFlight data for passenger

Exits via FAIL if: Event #5132: The SFPD/APIS information is not provided for one/all of the passengers and the use of fake data is disabled (issue ticket (error))

In Test mode: Processing the scheme in Test mode will result in exit on Fail

Similar functionality

A similar algorithm is also available in the Issue ticket element, triggered when a ticket issuance error occurs. It works in the same way, but always at the SFPD level.

Overview

Adds an SSR remark to the PNR for CKIN or SEMN services.

Description

The system applies the step settings and adds an SSR remark for CKIN or SEMN services, including the remark text specified in the settings.

Equivalent GDS commands

Settings

1. Select the remark type to add to the PNR.
2. Enter the remark text (required).
3. Select a value from the list.

Overview

Adds a vendor remark to the PNR with the text specified in the step settings.

Description

The system adds a vendor remark to the PNR with the text specified in the step settings. The remark can be applied to all carriers in the PNR or to selected carriers only.

Equivalent GDS commands

Settings

1. Enter the remark text in the free-text field. The text will be inserted into the remark..

If needed, use variables to make all or part of the remark text change dynamically.

ℹ Note: Click Insert variable to open the list of available variables.
When you select a variable from the dropdown, the system inserts it into the field enclosed in square brackets.

1. Select whether the remark should be added for all carriers in the PNR or for specific carriers only.
2. Set the value from the list.

Overview

Cancels the entire itinerary or segments with a specific status code.

Description

Use this element when you need to delete a specific segment that contains a certain status code, or delete all flight segments from the booking and all related ancillary services.

Equivalent GDS commands

Settings

Choose the action you need to get performed:

• Cancel the entire itinerary: Deletes all flight segments in the booking, regardless of their status, along with all associated ancillary services. The retention segment is preserved.
• Cancel segments with a specific status code: Requires specifying the status code. With this setting, the system first checks whether the PNR contains a segment with the specified status code, and if found, executes the command to delete the segment with the corresponding segment number.

Workflow behavior

The process will complete successfully if the system cancels the entire booking or the segments that match the status codes specified in the settings.

Exits via OK if:
Event #5224: Segments have been successfully canceled

Exits via FAIL if:
Event #5221: Cancellation aborted due to no segments in the itinerary (entire itinerary setting)
Event #5226: Cancellation aborted due to no segments in the itinerary after filtering (specified segment setting)

In Test mode:
Processing the scheme in Test mode will result in exit on Fail

Examples

Cancel entire itinerary

PNR before processing:

1 LASTNAME/FIRST MR
2 TK1830 L 15MAR 7*CDGIST HK1  0700 1240  15MAR  E  TK/RMVLWD
3 TK 077 L 15MAR 7*ISTMIA HK1  1535 2135  15MAR  E  TK/RMVLWD
4 MIS 1A HK1 CPH  19JUN
5 AP 000000000000
6 TK TL07NOV/XXXYY0000
7 SSR OTHS 1A PLEASE ADVISE FQTV NUMBER IF AVAILABLE
8 SSR OTHS 1A PLS ADV PSGR MOBILE AND/OR EMAIL AS SSR  CTCM/CTCE

PNR after processing:

1 LASTNAME/FIRST MR
2 MIS 1A HK1 CPH  19JUN
3 AP 000000000000
4 TK TL07NOV/XXXYY0000
5 SSR OTHS 1A PLEASE ADVISE FQTV NUMBER IF AVAILABLE
6 SSR OTHS 1A PLS ADV PSGR MOBILE AND/OR EMAIL AS SSR  CTCM/CTCE

Cancel  segments with UN status code

PNR before processing:

1 LASTNAME/FIRST MR
2 TK1830 L 15MAR 7*CDGIST UN1  0700 1240  15MAR  E  TK/RMVLWD
3 TK 077 L 15MAR 7*ISTMIA HK1  1535 2135  15MAR  E  TK/RMVLWD
4 MIS 1A HK1 CPH  19JUN
5 AP 000000000000
6 TK TL07NOV/XXXYY0000
7 SSR OTHS 1A PLEASE ADVISE FQTV NUMBER IF AVAILABLE
8 SSR OTHS 1A PLS ADV PSGR MOBILE AND/OR EMAIL AS SSR  CTCM/CTCE

PNR after processing:

1 LASTNAME/FIRST MR
2 TK 077 L 15MAR 7*ISTMIA HK1  1535 2135  15MAR  E  TK/RMVLWD
3 MIS 1A HK1 CPH  19JUN
4 AP 000000000000
5 TK TL07NOV/XXXYY0000
6 SSR OTHS 1A PLEASE ADVISE FQTV NUMBER IF AVAILABLE
7 SSR OTHS 1A PLS ADV PSGR MOBILE AND/OR EMAIL AS SSR  CTCM/CTCE

Often used with

Condition Segment status (preceding) –  allows identifying PNRs in which all segments or some have a specific status (for example, HX).

Overview

Processes a refund for the EMD.

Description

The system performs an EMD refund only if all associated coupon statuses are eligible for refund and none contain a non-refundable indicator.

If at least one coupon is not eligible for refund, the entire EMD is treated as non-refundable.

When executed within a PNR-based scheme, the system attempts to refund all EMDs associated with the PNR. In schemes that operate directly with EMD documents, the refund is processed only for the specific EMD being handled by the scheme.

Equivalent GDS commands

Description

No additional configuration is required. However, you must define the outcome the system should assign (OK or FAIL) if no EMDs eligible for refund are found.

Optional:

• Complete the Waiver code field if a justification is required to process a full EMD refund.
• Use a Variable if the waiver code needs to be dynamically supplemented with variable values.

Workflow behavior

Processing will complete successfully if the EMD eligible for refund is successfully refunded.

In Test mode: Processing the scheme in Test mode will result in exit on Fail.

Similar function

A similar function is available for Sabre within the Refund EMD step, which allows partial EMD refunds based on the criteria defined in the step settings.

Overview

Reissues tickets with no additional collection for fare or taxes.

Description

At this step, all tickets requiring reissue are reissued as an even exchange (no add-collect). The system uses airline schedule change data to identify coupons that no longer match the itinerary segments. These tickets are reissued unless additional filters are enabled in the condition settings.

This functionality can be useful for processing involuntary reissues for tickets impacted by an airline schedule change.

(i) Ticket reissue must be enabled at the carrier level (Carriers → Revalidation and Reissue), including for multi-carrier tickets on the validating carrier’s stock.

Equivalent GDS commands

Settings

1. Fill in the Endorsement and Tourcode fields with the required values for the ticket being reissued. You may use variables if needed. Click on the square brackets to see the variables list.

Alternatively, enable Apply issuing carrier settings to dynamically auto-fill the fields based on the issuing carrier’s Revalidation and Reissue configuration.

Optional settings

1. Use conditions to limit the exchange to specific tickets in the PNR. Only tickets matching the selected criteria will be exchanged.
2. Use this setting when a ticket must be exchanged even though no actual mismatch exists between coupons and itinerary segments.

Configure system behavior for the following cases

1. Define the outcome when no tickets eligible for exchange are detected in the PNR.
2. Define the outcome when at least one ticket exchange fails and no further reissue attempts are made.

Workflow behavior

The process is considered successful if all tickets for which discrepancies were identified are successfully reissued by the system.

Exits via ОК if:
Event #5110: Even exchange completed

Exits via FAIL if:
Event #5109: Error on even exchange

In Test mode:
Processing the scheme in Test mode will result in exit on Fail

Examples

Exchange of 2 coupons for 2 coupons

1. HA7082U  SLCSEA 11NOV 07:20 OPEN OK
2. HA6770U  SEAEUG 11NOV 11:20 OPEN OK

Segments:

#1 HA 7082 U SLCSEA   11NOV07:20 HK   (No differences)
#2 HA 6592 U SEAEUG   11NOV19:59 HK   (Differs in: flight number; time of departure)

Result: OK (Event #5110)

Partly used

Coupons:

1.  AA  9019  L  HELDFW  15AUG 12:35  USED   OK  
2.  AA  1458  L  DFWOKC  15AUG 19:20  USED    OK  
3.  AA  2224  O  OKCDFW  29MAY 14:53  OPEN   OK  
4.  AA  8964  O  DFWHEL  29MAY 21:05  OPEN   OK  

Segments:

#3 AA3731 N OKCDFW 29MAY 12:45 HK (Differs in: flight number; reservation class; time of departure)
#4 AA9018 N DFWHEL 29MAY 16:50 HK  (Differs in: flight number; reservation class; time of departure)

Result: OK (Event #5110)

Exchange of 2 coupons for 1 coupon

Coupons:

1. AC8752 T CMHYYZ 19MAY 09:20 OPEN  OK
2. AC 412 T YYZYUL 19MAY 13:00 OPEN  OK

Segments:

#3 AC8622 T CMHYUL 18MAY 14:40 HK (Differs in: flight number; time of departure; date of departure; alternative routing is offered by the carrier; the number of connections has decreased)

Result: ОК (Event #5110)

Often used with

Action Accept schedule changes (preceding) – Use this action to update the segments after a schedule change

Condition Minimum Connecting Time is valid for all segments (preceding) – allows you to verify that the segments selected for reissue do not contain any MCT violations

Overview

Performs fare optimization by repricing the PNR in accordance with the specified configuration parameters.

Description

With this element, the system applies Best Buy pricing to determine the lowest applicable fare for the current itinerary.

When a lower fare is identified — and all configured conditions and restrictions are met — the system will perform these actions:

• rebook segments as required
• generate a new pricing record
• use it for downstream processing

Optimization control logic

The settings allow you to control the repricing logic:

• enforce application of the new fare in compliance with baggage requirements
• consider or ignore booked Special Service Requests (SSRs)
• retain the fare brand
• override passenger types
• restrict the optimization search to specific offices (OIDs / PCCs)

Fare optimization will not be applied when at least one of the following conditions is met:

• the PNR contains open-dated segments
• pricing evaluation requires manual intervention (for example, forced fare basis, PlusUp, or similar adjustments)
• the carrier selected for pricing is flagged as Carrier blacklist

Equivalent GDS commands

Recommendations and limitations

Successful fare optimization may lead to a change in the Ticket Time Limit (TTL).

TTL validates the remaining time before reservation expiration.

Settings

Configure the parameters that define the scope of the system’s search for lower-priced fare options.

1. Set fare type

Specify the fare types within which the system is allowed to search for lower-priced options.

Available options:

• any
• private
• published

When this setting is enabled, the system ignores private/published qualifiers provided in the inbound pricing command and performs repricing strictly within the selected fare type.

Keep original fare type (if specified in pricing command)

When enabled:

• If a fare type is specified in the inbound pricing command, it is mandatorily applied
• If no fare type is specified, the system applies the value defined in Use XX fares for pricing

2. Set passenger type

Specify alternative Passenger Type Codes (PTCs) to be used when the system replaces the original passenger type during pricing (for example: ADT, CHD, INF).

Example: A passenger is booked as ADT, but the agency applies special VFR fares. The system overrides the passenger type and reprices the itinerary using the alternative PTC.

Create a new pricing record for the specified passenger types

When enabled, the system creates a new pricing record if the resulting total amount is equal to or lower than the existing pricing record.

3. Specify the minimum saving threshold

Define the minimum saving required to apply fare optimization.

• Value can be defined as amount or percentage
• If savings are insignificant, repricing is skipped to avoid unnecessary changes

4. Validate baggage conditions

Select this setting to validate baggage conditions when searching for new fares.

Optimization is rejected if baggage conditions are:

• more restrictive than the current fare
• not allowing any baggage

5. Reject fare optimization for specific fare basis patterns

• For all carriers
• For selected carriers

6. Ignore optional services (SSRs)

Allow fare optimization even when optional services (SSRs) are present in the PNR.

• SSRs associated with modified segments will be cancelled
• services must be requested again

Add the Lower fare is available step to the NO CHANGES output to inform agents that optimization is possible but was not applied.

7. Preserve the fare brand

Preserve the fare brand during optimization, even if it is not explicitly specified in the pricing command.

When enabled:

• the system automatically determines the applicable fare family
• optimization is performed within the boundaries of that brand

8. Specify the offices to perform pricing

Select the OID / PCC offices where the system is allowed to perform pricing evaluations.

• If empty, pricing is performed in the office defined in Scheme Properties
• Available offices are based on the Office configuration
• Selected offices must match the list defined in the Lower fare is available step

9. Specify the ticketing offices

Define ticketing offices to be used when optimization is found in a non-ticketing office.

Workflow behavior

The step completes successfully when:

• a lower fare is found
• segments are successfully rebooked
• a new PQ / FF / TST is stored

Exit via OK

Event #4076: Found a lower price option. Possible profit is XX
Event #4029: PCC/OID XX: Cost improvement completed successfully. Details XX

Exit via NO CHANGE (*)

Event #4017: PCC/OID XX: Fare evaluation did not return any better value
(*) Applies when received for all PCC/OIDs where optimization was attempted.
Processing the scheme in Test mode results in exit on Fail.

Often used with

• Event happened (preceding condition) – Determines whether tickets have been issued for this PNR
• Theoretically possible to reduce the total amount (subsequent condition) – Excludes PNRs already booked at the lowest possible fare
• Lower fare is available (subsequent condition) – Checks optimization availability at processing time

Overview

Restores cancelled HX segments in the PNR.

Description

With this element, the system restores HX segments in the PNR to their original booking class if no replacement has been provided. Before restoration, the system checks that there are no substitute segments for the given HX segment.

With this element, the system restores HX segments in the PNR to their original booking class if no replacement has been provided.

Before restoration, the system checks that there are no substitute segments for the given HX segment – that is, no new segments with the same origin and destination and with one of the following statuses: HK, HS, NS, XM, LK, KL, SA, RR, HL, SS, SC, TK. If such an alternative is found, the restoration of HX segments is not performed.

This functionality can be useful for restoring cancelled HX segments that were removed from the PNR by the carrier.

Equivalent GDS commands

Recommendations and limitations

• It is not recommended to restore HX segments if the schedule change in the PNR has not yet been confirmed. Restoring in such cases may result in duplicate segments and complicate the booking structure.
• If the airline has already added new segments, reissued the tickets, and all coupons are in a synchronized state, restoring HX segments is not required.
• We recommend processing schedule changes in a timely manner, as multiple unconfirmed schedule changes received consecutively may be mistakenly interpreted by the system as independent events. This may lead to the restoration of outdated HX segments.

Key checks

Coupons and segments do not match (condition) – this check helps identify cases where a schedule change occurred and tickets were reissued (segments and coupons are now in a synchronized state).

Segment statuses (condition) – allows verifying the presence or absence of other segment statuses besides HX.

Settings

No specific settings are required.

Workflow behavior

Processing will complete successfully if HX segments are found that are not covered by schedule change segments and are successfully restored to HK status.

Exits via OK if: Event #3160: Segments recovered

Exits via FAIL if: Event #3162: No schedule changes without alternatives for restoring HX segments Event #3163: No segments with HX status and no alternatives

In Test mode: Processing the scheme in Test mode will result in exit on Fail

Examples

The segment with status code HX has no alternative

#1 LX 8066 W ZRHMLE 25OCT 19:20 – HK 
#2 UL 0102 Q MLECMB 08NOV 09:25 – HX 
#3 LX 8065 K CMBZRH 15NOV 11:55 – TK

Processing result: OK (Event #3160)

Explanation: Segment #2 was restored (HX → HK) because there is no alternative for the HX segment.

The HX segment is overlapped by a segment with status HK

#1 ET 0378 U ADDMGQ 26JUN 14:45 – HX 
#2 ET 0376 U ADDMGQ 27JUN 08:50 – HK 
#3 ET 0379 U MGQADD 23JUL 18:00 – HK

Processing result: **FAIL** (*Event #3163*)

Explanation: The segment was not restored because an alternative exists on segment #2.

The HX segment is overlapped by a segment with status TK

#1 FI 0522 V KEFFRA 29SEP 10:20 – HX 
#2 FI 0522 J KEFFRA 29SEP 10:20 – TK 
#3 A3 0431 U FRAHER 29SEP 18:35 – HK

Processing result: **FAIL** (*Event #3162*)

Explanation: The HX segment was not restored because a similar segment with status TK was found.

The HX segment is overlapped by a TK status segment, but the route has changed

#1 B6 0524 L LAXJFK 01NOV 13:30 – HX 
#2 B6 0388 L LAXBOS 01NOV 13:40 – TK

Processing result: **OK** (*Event #3160*)

Explanation: Segment #1 was restored (HX → HK) because there is no alternative for the HX segment (i.e., no identical flight with the same routing).

Often used with

Ticket has been issued (preceding condition) – allows checking whether a ticket has been issued for the given PNR

Similar functionality

A similar function is available in the Start element in PNR pricing schemes for all GDSs (1A, 1S, 1G). This option – Attempt to restore HX segments to the original reservation class – allows fare pricing to be performed on restored segments.

Overview

Performs a full refund of all tickets included in the PNR.

Description

At this step, the system performs a full refund for all tickets in the PNR without validating segment statuses, unless segment validation is explicitly defined in the carrier refund rules.

The refund parameters (e.g., waiver code, endorsement) are applied based on the settings below or according to the rules configured in the Involuntary Refund Rulesets section.

Tickets with coupon statuses OPEN and ARPT are eligible for refund.

Equivalent GDS commands

Settings

Use the options below to define the step behavior:

1. Use carrier refund rules

Enable this option to allow the system to retrieve refund values from Involuntary Refund Rulesets.

Alternatively, you can use remarks and OSI for reservations to process remarks and OSI messages for reservations eligible under the carrier refund rules. This setting disables the refund process and only enters remarks and OSI messages into the PNR according to the applicable rules.

2. Use step settings

Available only when option 1 is disabled.

Manually define a fixed value or select a variable to be used for the refund of any ticket reaching this step.

• Sabre: additional fields are available – Endorsement, Tour code, and Free text
• Amadeus: a waiver code can be added as RM, AA, WA, or Tour code
• Galileo: no additional fields are available; only the Waiver code can be specified

Optional settings

3. Allow refund in another PCC/OID

When enabled, the system allows refund processing in a different PCC/OID belonging to the same IATA if the original ticketing PCC/OID is not available.

4. Limit refund by ticket conditions

Use conditions to limit the refund to specific tickets in the PNR. Only tickets matching the selected criteria will be refunded.

Configure system behavior for the following cases

5. Result if nothing to refund

Define the outcome when no tickets in the PNR are eligible for refund.

6. Result if partially refunded

Define the outcome when tickets in the PNR are only partially refunded.

Workflow behavior

The step completes successfully if all tickets selected by the configured rules and having eligible coupon statuses are successfully refunded.

Exits via ОК if:
Event 5236 – Full refund completed

Exits via FAIL if:
Event 5235 – Error on Full refund

In Test mode:
Processing the scheme in Test mode will result in exit on Fail

Often used with

• Ticket coupon status (subsequent condition) – using the condition that checks ticket coupon status after the refund step to identify the status of tickets
• Cancel itinerary (subsequent action) – cancels flight segments, if present

Overview

Issues vouchers for confirmed car segments.

Description

At this step, the system automatically issues vouchers for all Car rental segments booked  for future dates with confirmed status (HK) in the PNR.

If multiple car segments are present in a PNR, the system generates an issue request for each segment, except for those with an existing voucher.

Car voucher will be issued:

• In the ticketing office, if issued tickets are present
• In the scheme operational office, if tickets are not yet issued or if there are multiple tickets issued in different offices.

If the segment meets the criteria, the system issues a voucher and completes the step with OK.

The step ends with an error if:

• the criteria are not met
• there is nothing to issue
• issuing at least one voucher fails

Equivalent GDS commands

Settings

No specific settings are required.

Often used with

• Types of segments (preceding condition) – Allows the system to identify PNRs that contain booked CAR segments.
• Car supplier (preceding condition) – Use this condition to determine that the PNR contains confirmed CAR segments and that no vouchers have been issued for them.

Overview

Issues Electronic Miscellaneous Documents (EMDs) for confirmed services stored in the PNR.

Description

Use this step to automatically issue EMDs for confirmed ancillary services such as baggage, seats, or other optional services.

The system checks the status of services in the PNR and issues EMDs for those that are confirmed and eligible for issuance.

Equivalent GDS commands

Settings

Specify SSR codes for the services that require EMD issuance.

• Enter one or more SSR codes separated by commas or spaces.
• Only services with the specified SSR codes will be processed.

If the field is empty, the system issues EMD for all confirmed services in the PNR.

Workflow behavior

The step returns OK when all required EMD documents are successfully issued.
The step returns Error if a technical problem occurs during EMD issuance (event #5350).
If the service does not yet have a confirmed status, the system retries EMD issuance several times. If the status does not become confirmed, the step ends with Fatal (event #5393).

Often used with

Need to issue EMD for optional services (preceding condition) – use this condition before the Issue EMD step to ensure that the PNR contains services requiring EMD issuance. This prevents errors and avoids interruption of the scheme processing.

Overview

Issues all air tickets in a PNR based on a stored fare quote (PQ/TST/FF).

Description

The action issues all air tickets contained in the PNR. Ticketing is performed against an existing fare quote (PQ/TST/FF) stored in the PNR.

Regardless of scheme type, the action can be configured to:

• restrict ticketing based on segment status codes;
• apply an agency commission as a fixed amount or percentage, or define a priority order for selecting the commission source;
• add pseudo APIS data when required passenger information is missing from the PNR;
• print an invoice and/or itinerary receipt at the time of ticketing (1A and 1S only);
• send other PNRs belonging to the same mid-office reservation for ticketing.

PNR Processing Schemes

In PNR Processing schemes, ticketing is performed only against the existing fare quote (PQ/TST/FF). The fare quote cannot be recreated.

One additional setting is available:

• Disable fare quote time validation – allows ticketing even if the fare quote was not created on the current date.

PNR Pricing Schemes

In PNR Pricing schemes, ticketing is also performed against the existing fare quote (PQ/TST/FF). However, when required, the action can update the fare quote (PQ/TST/FF) before issuing tickets and verify the resulting price against the price increase thresholds configured in the action settings.

Fare quote update may be required in the following cases:

• the ticketing currency changes when issuing in a different office;
• the validating carrier changes.

In addition to the base functionality, PNR Pricing schemes support:

• selecting the ticketing office;
• restricting ticketing offices for specific carriers;
• preserving the existing fare basis in the PNR.

Equivalent GDS commands

Settings

Go to the settings for the selected scheme type

PNR Processing Schemes

1. List of segment status codes when ticketing should be aborted

Specify the segment status codes that prevent ticketing. If any segment in the PNR carries one of the listed status codes, the system does not issue tickets, and the action exits via the Error path.

2. Commission

Sets the agency commission for ticketing as a percentage or a fixed amount.

If a commission value is entered directly in this field, it takes highest priority:

• the commission stored in the PNR is ignored.
• the commission from Commission Module is ignored.
• the Priority for selecting the source of commission setting becomes unavailable.

Priority for selecting the source of commission – defines the priority order the system uses to select a commission source at the time of ticketing. The default value is not specified. If no commission is found in the PNR and this field is not configured, processing stops.

3. Print invoice (1A and 1S only)

Specifies the document type printed at the time of ticketing: invoice, itinerary receipt, or both. Available options may differ depending on the GDS.

4. Apply pseudo APIS

Adds pseudo APIS data if the passenger information required for ticketing is missing from the PNR.

5. Restore missing FOP from MEP (1A only)

Recovers the form of payment (FOP) from the Method of Payment (MEP) element when FOP is absent from the PNR.

This setting is intended for situations where the FOP is lost during PNR processing or optimization in Amadeus, but the MEP element is still present in the PNR. When enabled, the system checks for FOP and MEP before proceeding with ticketing. If FOP is absent but MEP is found, the system attempts to reconstruct FOP from the MEP data and continues ticketing. If MEP is not found or recovery fails, ticketing continues under standard logic and may exit via the Error path.

6. Disable fare quote time validation

Disables validation of the fare quote creation date, allowing ticketing even when the fare quote was not created on the current date.

7. Send for ticketing other PNR(s) belonging to the same mid-office reservation

Sends other PNRs associated with the same mid-office reservation for ticketing.

Delay ticketing with – delays ticketing of the associated PNRs by the specified amount of time. Available only when Send for ticketing other PNR(s) belonging to the same mid-office reservation is enabled.

PNR Pricing Schemes

1. Issue ticket in

Select the office in which tickets are issued from the dropdown list. Available options:

• scheme operational office – tickets are issued in the operational office defined in the Scheme properties of this scheme.

• PNR creating office – tickets are issued in the office where the PNR was originally created.
• PNR responsible office – tickets are issued in the office currently responsible for the booking.
• office – tickets are issued in a specific PCC/Office ID selected from the list.

When the office is selected, an additional setting becomes available:

Only for the following carriers – specify the office and the list of carrier codes for which tickets must be issued in that office.

Actions with a carrier filter are displayed in the scheme with a plane icon.

2. Accepted ticketing threshold for

Sets the maximum permitted price increase at the time of ticketing compared to the last known price. The check can apply to either the total PNR price (the whole PNR) or the price per adult passenger (one adult).

This threshold check applies when the action needs to recreate the fare quote. This can occur when:

• ticketing is performed on a different carrier's stock, as defined in the carrier settings;
• the currency of the ticketing office differs from the currency in the stored fare quote;
• a surcharge is applied during authorization of certain credit card types.

3. List of segment status codes when ticketing should be aborted

Specify the segment status codes that prevent ticketing. If any segment in the PNR carries one of the listed status codes, the system does not issue tickets and the action exits via the Error path.

4. Commission

Sets the agency commission for ticketing as a percentage or a fixed amount.

If a commission value is entered directly in this field, it takes highest priority:

• the commission stored in the PNR is ignored;
• the commission from Commission Module is ignored;
• the Priority for selecting the source of commission setting becomes unavailable.

Priority for selecting the source of commission – defines the priority order the system uses to select a commission source at the time of ticketing. The default value is not specified. If no commission is found in the PNR and this field is not configured, processing stops.

5. Print invoice (1A and 1S only)

Specifies the document type printed at the time of ticketing: invoice, itinerary receipt, or both. Available options may differ depending on the GDS.

6. Disable change of farebasis

Prevents fare basis changes when the fare quote is recalculated.

7. Apply pseudo APIS

Adds pseudo APIS data if the passenger information required for ticketing is missing from the PNR.

8. Restore missing FOP from MEP (1A only)

Recovers the form of payment (FOP) from the Method of Payment (MEP) element when FOP is absent from the PNR. Behavior is identical to the description under PNR Processing schemes above.

9. Send for ticketing other PNR(s) belonging to the same mid-office reservation

Sends other PNRs associated with the same mid-office reservation for ticketing.

Delay ticketing with – delays ticketing of the associated PNRs by the specified amount of time. Available only when Send for ticketing other PNR(s) belonging to the same mid-office reservation is enabled.

Workflow behavior

The action outcome is determined by the result of the ticketing process.

Exit: OK
The action exits via the OK path when all tickets selected for issuance are successfully issued.

Exit: Error
The action exits via the Error path when:
an unrecoverable error occurs during ticketing;
no tickets eligible for issuance are found in the PNR.

Stop: Fatal
If not all tickets are successfully issued, or if a potentially recoverable error occurs during ticketing, the system temporarily suspends processing and retries the action after a delay. 

Overview

Moves a PNR from one queue to another within the selected offices (PCC/OID).

Description

Use this action to move a PNR from a specified source queue to a target queue and category. It is designed to automate queue management and route PNRs to the next processing stage.

The system performs the following sequence:

1. Retrieves the PNR from the source queue.
2. Moves it to the target queue.
3. Logs the result in the processing history.

Settings

Select the office where the queue operation will be performed.

Office selection (OID/PCC)

Office - the PCC or OID in which the queue operation is executed. Available options:

• PCC/OID - a manually defined office identifier.
• Operational PCC - the office selected for processing the object in the scheme.
• Ticketing PCC - the office selected for ticket issuance.
• Creating PCC - the office where the PNR was originally created.
• Responsible PCC - the office responsible for the PNR (the office to which PNR ownership has been transferred).

Queue configuration (Queue number/Category)

• Define the following in the configuration panel:
• The queue number in the From field.
• The queue number in the To field.
• A category in each field (optional).
• Use categories when the queue structure requires additional segmentation.

Workflow behavior

The action completes successfully when the PNR is moved to the target queue.

The following events are recorded in the processing history:

Event 5311 — PNR is moved from queue to following queues.
Event 5312 — PNR should have been moved from queue to another, but the move was ignored due to dry run mode.
Event 5313 — Error on PNR move from queue to following queues.

Overview

Places a PNR into a specified queue in a designated office (PCC/OID).

Description

At this step, the system reads the configuration panel settings to determine the target office and queue parameters, then places the PNR into the corresponding queue. Both immediate and deferred queue placement are supported

Equivalent GDS commands

Settings

1. Office selection

Determines the office into which the PNR is placed. The following options are available:

• PCC/OID - a specific office entered manually in the configuration field.
• Operational PCC/OID - the office configured in the Scheme Properties of the current scheme.
• Ticketing PCC/OID - the office in which tickets were issued, or the office identified by the system as the ticketing office (the office where ticket issuance is planned).
• Creating PCC/OID - the office in which the booking was created.
• Responsible PCC/OID - the office to which responsibility for the booking was transferred. If that office is unavailable, the PNR is placed into the Creating PCC instead.

2. Queue number and category

Enter a specific queue number and category number in the corresponding configuration fields. Select the info icon next to a field to view the list of queues and categories available in the selected office.

To assign values dynamically, use Variables.

3. Use Agent Queue number / Use Agent Queue category

When a checkbox is enabled, the corresponding manual input field for the queue number or category is disabled, and the system determines the value automatically based on the agent settings configured in Office → Agent.

These options are useful when:

• PNRs must be routed automatically to a queue associated with a specific agent.
• The task distribution logic within an office and its sub-agent offices must be preserved.

How the system defines agent parameters

1. Identifies the agent from the PNR – typically by creating user.

2. Searches for that agent in the settings of the selected office:

   • If a specific office is set, its agent configuration is used.
   • If a derived office (Creating, Ticketing, or Responsible) is set, the agent is looked up in the resolved PCC/OID.

3. Applies:

   • Agent Queue number – if the corresponding checkbox is enabled.
   • Agent Category / PIC code – if the corresponding checkbox is enabled.
   ⚠️

   If the agent is not found in the office settings, queue placement fails with an error.

4. Deferred placement

Enter the number of time units after which the PNR is to be placed into the queue:

• Days – for 1G and 1S
• Hours – for 1A

5. Disable input validation to place PNR on queue at third-party PCC

This option is available for 1G (Galileo) only.

When this option is enabled, the system does not validate the existence of the PCC, queue, or category. Only basic format validation of the entered values is retained (character length and type).

Use this option only when a PNR must be sent to a third-party PCC that is not accessible from the current office.

When using this option:

• Manually verify the outcome of the step – for example, through error monitoring or by confirming with the receiving office.
• Ensure that the PCC, queue, and category values are entered correctly, as the system does not validate them.

Often used with

Placed on queue (condition) – verifies whether a PNR is present or absent in a specific queue. Applicable only for offices to which the system has configured branch access.

Overview

Prints the entire currently displayed PNR.

Description

This action prints the currently displayed PNR to the default printer.

To print, the system uses the transaction code WRA — combining WR with the modifier A (All) — to retrieve and print the entire PNR.

Equivalent GDS commands

Settings

No additional configuration is required.

Overview

This action checks if required remarks exist in a PNR and if their values match the defined patterns. It then automatically adds the quality control (QC) result in the PNR.

Description

The system processes each configured condition, searches the PNR for a matching remark, checks its value against the defined regular expression, collects all failed conditions, and adds a QC remark with the result.

Use this action to check the presence and content of remarks in the PNR for quality control purposes.

The system processes each configured condition as follows:

1. Searches the PNR for a remark whose name (static part) matches the defined pattern.
2. If a matching remark is found – checks its value against the defined regular expression.
3. Collects all failed conditions.

4. Adds a QC remark to the PNR with the result in the following format:

   • TVK QC - PASSED <date time> – if all conditions are met
   • TVK QC - <condition names> NOT PASSED <date time> – if one or more conditions failed

Settings

Define validation rules with one condition per line.

Format

[Remark name] Regular expression

Example

[DEPARTMENT] [A-Z0-9]{4}
[CARRIER] [A-Z]{2}

Validation rules

The system validates input before saving:

• At least one condition must be defined.
• Each condition must follow the correct format.
• Condition name must be unique.
• Condition name can only contain: uppercase letters, digits, and the symbols :, , and space.
• Regular expression must be valid.

Examples

Example 1 – successful validation

Configured pattern:

[DEPARTMENT] [A-Z0-9]{4}
[CARRIER] [A-Z]{2}

The system expects remarks of the following form:

• DEPARTMENT AB12 – where AB12 is a variable value consisting of digits and uppercase letters.
• CARRIER YY – where YY is a variable value containing uppercase letters only.

If both remarks are present in the PNR and match their respective patterns, the result is:

Example 2 – validation failed

Configured pattern:

[DEPARTMENT] [A-Z0-9]{4}
[FOP] NONREF

The PNR contains the following remarks:

DEPARTMENT NCE01001

No FOP remark.

Result:

TVK QC - DEPARTMENT, FOP NOT PASSED 09OCT19 14:10

Workflow behavior

The action has two possible exits:

• Passed – all conditions are satisfied.
• Not passed – one or more conditions failed.

Overview

The Refund EMD action processes a full or partial refund of an EMD.

Description

This step initiates an EMD refund via the GDS. It is designed for automated refund processing only in scenarios where GDS rules permit the refund (refund eligibility validation is performed on the Sabre side).

After the command executes, the system evaluates the GDS response to determine whether the refund was completed successfully.

Behavior by scheme type

• In PNR Processing schemes – where the processing source is a PNR – the step refunds all EMDs in the PNR that are eligible for refund.
• In EMD Processing schemes – where the processing source is an EMD – each EMD is processed individually.

Pre-refund validation logic

The step does not submit an EMD for refund if either of the following conditions is met:

• ALL coupons are NOT in Open or AirportControl status;
• ALL coupons are marked NonRefundable.

Equivalent GDS commands

Settings

No configuration is required if all EMDs in the PNR should be refunded.

Conditions (optional) – use a condition to define selection criteria for EMDs eligible for refund. If a condition is set, only EMDs that match the specified parameters are submitted for refund (for example, by RFISC or carrier).

If nothing to refund, consider the result as – defines system behavior when the PNR contains no EMDs eligible for refund. Available values:

• OK – the step exits via the OK path;
• Fail – the step exits via the Fail path;
• Fatal Error – processing is stopped.

Workflow behavior

The step exits via OK only when all of the following conditions are met:

The PNR contains EMDs eligible for refund;
All such EMDs were successfully refunded;
Or the PNR contains no EMDs eligible for refund and If nothing to refund is set to OK.

In all other cases, the step exits via Fail.

Overview

Removes Document Itinerary (DI) remarks from a PNR based on keywords or patterns matched against the remark text.

Description

The action searches DI remark text and removes all remarks that match the defined search condition. The search mode depends on whether the Keywords or phrases are regular expressions checkbox is enabled.

Standard search (checkbox off)

Keyword search (default)

Matches any remark that contains the keyword, regardless of position.

REFUNDABLE matches TICKET IS REFUNDABLE, TICKET IS NON-REFUNDABLE, and REFUNDABLE.

Exact match

Wrap the keyword or phrase in double quotes "" to match only remarks containing that exact word or phrase.

"REFUNDABLE" matches TICKET IS REFUNDABLE and REFUNDABLE, but not NON-REFUNDABLE.

Wildcard patterns

• % – zero or more characters. "AR%" matches ARRIVAL, ARCHIVE, AR.
• _ – exactly one character. "APPL_" matches APPLY and APPLE.

RegEx search (checkbox on)

Each line is evaluated as a regular expression.

ACCT-\\d+ matches ACCT-1500 and ACCT-7890, but not ACCT-REFERENCE.

Equivalent GDS commands

Settings

The settings panel has three parameters, numbered as labeled in the screenshot.

1 – Keywords or phrases to be found in Document Itinerary remarks

Required. Enter the keywords or phrases to match against DI remark text. Matched remarks are removed.

• Enter one keyword or phrase per line.
• Use separate lines for multiple values.

See how it works for supported search modes.

2 – Keywords or phrases are regular expressions

When enabled, each line in field 1 is evaluated as a regular expression. When disabled, standard search applies.

3 – Commit on exit

Determines how PNR changes are saved after the action runs.

• E- End the GDS session
• ER- Save changes and keep the session open

Workflow behavior

The action has a single exit path and always completes — regardless of whether a matching remark was found.

• Remark found and removed – execution continues normally.

Examples

Example 1 – Keyword search

Goal: remove all DI remarks containing REFUNDABLE.

Search condition: REFUNDABLE

DOCI-AC ACCT-1500
001. FREE TEXT-TICKET IS REFUNDABLE
002. FREE TEXT-TICKET IS NON-REFUNDABLE
003. FREE TEXT-HELLO WORLD

Remarks 001 and 002 are removed. Remark 003 is not affected.

Example 2 – RegEx search

Goal: remove all DI remarks where ACCT- is followed by a numeric value.

Search condition: ACCT-\\d+

Checkbox: Keywords or phrases are regular expressions — enabled

DOCI-AC ACCT-1500
001. FREE TEXT-ACCT-7890
002. FREE TEXT-ACCT-REFERENCE
003. FREE TEXT-HELLO WORLD

Remark 001 is removed (ACCT-7890 matches the pattern). Remarks 002 and 003 are not affected.

Overview

Removes a PNR from the queue or queues specified in the step settings.

Description

The Remove from queue action executes a GDS command to remove the PNR from the queue number configured in the step settings.

The step has a single exit path. If the removal completes successfully, processing continues to the next step. If the removal fails, the error is logged and processing continues.

Equivalent GDS commands

Settings

1. Office selection

Defines the office whose queues the PNR will be removed from. The following options are available:

• PCC/OID – a specific office entered manually in the configuration field.
• Operational PCC/OID – the office configured in the Scheme Properties of the current scheme.
• Ticketing PCC/OID – the office where tickets were issued, or the office identified by the system as the ticketing office.
• Creating PCC/OID – the office where the PNR was created.
• Responsible PCC/OID – the office to which responsibility for the booking was transferred. If that office is unavailable, the PNR is placed into the Creating PCC instead.

ℹ Note: Ensure that the required queues and categories exist in all used PCCs/OIDs.

⚠ Important: For the system to access the designated PCCs, branch access from the operational office to all required PCC/OID values must be configured.

2. Queue number and category

Enter a specific queue number and category number in the corresponding configuration fields. Select the info icon next to a field to view the list of queues and categories available in the selected office.

3. Remove even future queue placements

Enable this setting to prevent the PNR from being placed into a queue for which a deferred placement was previously scheduled by a Place to queue step.

Overview

The step finds remarks in a PNR by pattern and removes them.

Description

The step reads its settings and removes any remarks that match the defined patterns.

Two search methods are available:

• plain text or wildcards – to match full or partial remark text (Setting 1)
• regular expressions – to match remarks with variable content (Setting 2)

Equivalent GDS commands

Settings

Setting 1 – Search pattern input

Enter one or more patterns to search for. The step scans the PNR for remarks that match. Each pattern goes on a new line.

Without wildcards

• Plain text – matches any remark that contains this text, anywhere in the string.

  • Example: REFUNDABLE matches TICKET IS REFUNDABLE, TICKET IS NON-REFUNDABLE, REFUNDABLE.

• Text in double quotes " " – matches an exact word or phrase only.

  • Example: "REFUNDABLE" matches TICKET IS REFUNDABLE, REFUNDABLE. Does not match: NON-REFUNDABLE.

With wildcards

• % – matches zero or more characters.

  • Example: AR% matches ARRIVAL, ARCHIVE, AR.

• _ – matches exactly one character.

  • Example: APPL_ matches APPLY, APPLE.

Setting 2 – Keywords or phrases are regular expressions

Enable this setting to use regular expressions instead of plain patterns. Each line in the input field is treated as a separate regex.

Use regex when you need to:

1. Match an exact format or structure – validate character type and length.

   • TKT-\\d{10} – TKT- followed by exactly 10 digits
   • [A-Z]{2}\\d{6} – 2 letters followed by 6 digits

2. Control string length – match exactly N characters or a range.

   • \\d{8} – exactly 8 digits
   • [A-Z]{3,5} – 3 to 5 letters

3. Exclude a specific substring – match a pattern, but skip it if a certain string follows.

   • Words starting with RE, but not REFUND: \\bRE(?!FUND\\b)\\w*

Setting 3 – Commit on exit

Sets how the system saves changes when done working on the PNR.

Accepted values:

• E – save and close the session. Use when no further work on the PNR is needed.
• ER – save and keep the PNR open for continued processing.

Workflow behavior

The step completes with OK in all cases:

• remarks found and removed successfully
• no remarks found
• a technical error occurred during removal

Often used with

Remark (condition) – checks whether the PNR contains specific remarks. Place it before Remove remark to verify remark presence before deletion.

Overview

This step revalidates tickets in a PNR. Only tickets that match the configured parameters and additional filter conditions are eligible for revalidation.

Description

The step compares current segments in the PNR against their corresponding coupons and identifies discrepancies. Identified discrepancies are then matched against the parameters selected in Setting 1.

A ticket is accepted for revalidation when:

• at least one marked parameter has a discrepancy
• no unmarked parameter has a discrepancy

A ticket is not accepted for revalidation if any discrepancy falls outside the marked parameters.

ℹ Note: Revalidation can also be enabled or disabled at the carrier level via Carrier Settings → Ticket revalidation allowed.

Equivalent GDS commands

Settings

Setting 1 – Revalidation parameters (required)

Select the parameters whose discrepancy triggers ticket revalidation.

⚠ Important: If the system detects a discrepancy on a parameter that is not selected, revalidation does not run. This applies regardless of how many marked parameters match.

Setting 2 – Additional filter conditions (optional)

Restrict revalidation to specific tickets in the PNR. Only tickets that match the selected criteria are eligible for revalidation.

Setting 3 – Outcome when nothing to revalidate

Define the step outcome when no tickets eligible for revalidation are found in the PNR.

Available values: Ok / Failed / Fatal Error

ℹ Note: Two cases fall into the “nothing to revalidate” category:

• the PNR contains no tickets with discrepancies;
• the PNR contains tickets with discrepancies, but none passed the filter conditions and were selected for revalidation.