Simultaneously confirms all schedule changes in the booking as provided by the airline and records the agent’s acceptance of these changes.

Equivalent commands

Amadeus – ERK Galileo – ALL Sabre – EWR

Used in the scheme after performing key checks to prevent incorrect automated processing and to identify cases that require manual intervention.

Key checks before the Accept schedule changes:

• Minimum connecting time — verify compliance with minimum connection time requirements at all transfer points.
• Segment status — ensure the PNR does not consist exclusively of segments with statuses HX, UN, UC, NO, or WK.
• Ticket was issued — take into account whether a ticket has been issued or not.

The rule is preconfigured with the recommended status codes that trigger acceptance:

Code	Meaning
HK	Confirmed segment
TK	Confirmed segment with a schedule change
SC	Segment booked directly with the vendor — used primarily by American Airlines to indicate a schedule change for a confirmed segment

A schedule change is accepted only if each part of the journey is covered by a segment with one of the status codes listed above.

⚠ All at once: All segments requiring confirmation will be confirmed simultaneously. The system does not confirm selected segments individually.

⚠ No ticket revalidation: The system does not revalidate tickets at this stage unless the airline automatically revalidates them on its side. To revalidate a ticket within the system, use the Revalidate ticket element.

When the condition fails

The stage will Fail if:

• The GDS returns an error after the confirmation command is sent.
• All segments already have status HK (no changes to confirm).

Example 1

Initial PNR:

#2 EY 100 B 01NOV 6*LISAUH TK1 0825 1945 01NOV E
#3 EY 800 B 01NOV 6*AUHNRT HK1 2105 1140 02NOV E

After execution:

#2 EY 100 B 01NOV 6*LISAUH HK1 0825 1945 01NOV E EY/XK4GI9
#3 EY 800 B 01NOV 6*AUHNRT HK1 2105 1140 02NOV E EY/XK4GI9

Result: The TK segment became HK, meaning the agent accepted the airline’s proposed schedule change.

Example 2

Initial PNR: 
Connection replaced with a direct flight; status codes updated accordingly.

#1 PD2206 V YOWYTZ 17MAY 07:00 HK
#2 PD2127 V YTZEWR 17MAY 09:45 HK
#3 PD2136 C EWRYTZ 19MAY 16:15 UN
#5 PD2338 C EWRYOW 19MAY 17:15 TK
#4 PD2217 C YTZYOW 19MAY 20:05 UN

After execution:
Segments with UN status are removed; TK becomes HK.

#1 PD2206 V YOWYTZ 17MAY 07:00 08:02 HK
#2 PD2127 V YTZEWR 17MAY 09:45 11:15 HK
#3 PD2338 C EWRYOW 19MAY 17:15 18:56 HK

Since the final route EWR–YOW is covered by a segment with TK status (per the condition settings), the system accepts the change and exits with OK.

---

Suggested elements

Preceding elements:

• Event happened — determine whether special or manual handling of schedule changes is required if the departure is approaching soon.
• Schedule change by — verify that no significant schedule changes have occurred compared to the original flight.

Subsequent elements:

• Codeshare — restrict automation for codeshare flights.
• Revalidate ticket — updates an existing ticket without reissuing.
• Even exchange — reissues a ticket with no additional payment.

If a ticket has been issued, use the following checks both before and after:

• Coupon route differs from segments — verifies significant route changes compared to the initial itinerary.
• Coupons and segments do not match — verifies that coupons match the segments across different parameters.

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:

GDS	Phone	Email
Amadeus	AP	APE
Sabre	9	PE
Galileo	P	MT

If contact details in the PNR are not associated with a specific passenger, the system will create CTCM and CTCE elements for each passenger in the PNR using the detected phone number and email address.

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.

Processing notes

• If the system cannot find passenger contact details, the processing history will show:“No contact information to write to the reservation.”
• Otherwise, the history will display which details were added and which were updated.

Commit on exit

Use the appropriate commit mode for your workflow:

• ER — if the PNR will be further processed according to the workflow design.
• E — if you are moving to the final Finish stage.

These remarks are read by the system when importing PNR data into back-office systems.
Use them to pass additional information for internal processing.

Choose the remark type based on purpose:

• DI.FT — informational (free text)
• DI.AC — financial (accounting)

You can insert variables to automatically pull data from the PNR and compose a text.

DI.FT — Free-text accounting remark

Purpose: Pass custom, non-financial data (e.g., project code, folder, department, client name, service structure).
Typical usage: External CRMs and back-office systems (Travelwire) — easy for them to parse.
Impact: Does not affect GDS billing or fiscal calculations.

Format:

• Max length: 45 characters
• Allowed characters: A–Z, space, –, _, /,*
• Rule: Enter each remark on a separate line
• Examples:

DI.AC — Accounting remark (hard-coded)

Purpose: Record payment forms, agency fees, commissions, etc.
Processing: Included in MIR files for accounting exports

Format:

• Max length: 42 characters
• Allowed characters: A–Z, 0–9, /,*
• Rule: Only one DI.AC remark per PNR
• Examples:

Important: Before adding a DI.AC remark, the system checks if one already exists. If yes — it will not add another and will log a Warning in history.

Inserting variables into remarks

For both DI.FT and DI.AC, you can use variables to insert dynamic values from the PNR.
Click Insert variable to view the list of available variables.

When you select a value from the dropdown list, the system will insert it into the field enclosed in square brackets.

Important: Square brackets indicate a variable — its value will change depending on the data in the specific PNR.

Example:
If a variable needs to return, for example, the departure date and the airport code, the configuration for this remark will look like this:

Remark text: 08AUG25 AMS

Variables are preconfigured in the system and divided into the following sections:
System / PNR / Processor / Backoffice / Optimizer / Agent

For the Customs section, variables must be created by the user in advance.

Go to: Settings → Variables

Use this element to add OSI (Other Service Information) messages to the PNR in order to pass additional information about the passenger or booking to the airline. This information does not require automatic processing and serves as a text note.

Equivalent commands in GDS

Sabre – 3
Amadeus – OS 
Galileo – SI.

Settings

Enter the text in the Message field, using Variables if necessary.

Then select a parameter:

• all marketing carriers in the PNR – if the remark should be passed to all carriers in the PNR
• carrier – available only to the specified carrier

Specify a value in the Commit to exit field.

Workflow behavior

This element has only an OK output, therefore the process will exit via OK in any of these cases:
Event #5042: OSI added to reservation for carrier
Event #5043: Error on adding OSI to reservation for carrier

Examples

Adding a sample VIP PASSENGER message:

Notes

If you want to use the OSI format to add CTCM, use the Add client contact details element, since this information is individual.

Remarks support automation processes. They can be used to:

• Insert comments after important actions performed automatically by the system, allowing later verification of these actions with the Remarks condition.
• Leave explanations for agents performing manual post-processing of the PNR.

When the Add remark action is performed, the system reads the element settings and inserts the configured remark into the PNR. Remarks may vary by type and can be either general or internal.

Equivalent commands

The available remark types and corresponding commands depend on the GDS in use.

Amadeus

RM (RMA, RMB) – General (with optional categories A-Z) 
RC – Confidential
RII – Itinerary and Invoice remark
RIR – Itinerary remark
RIF – Invoice remark
RIZ – Mini-Itinerary remark

Sabre

5 – General
5H – Historical
5HR – Confidential

Galileo

NP. – General 
NP.HZ – Historical
NP.C – Confidential 

Settings

Enter the remark text in the element settings and select its type. Use variables if the remark must include values from the PNR.

• To add multiple remarks of the same type, enter each remark on a new line
• To add remarks of different types, use this element multiple times

Text length

• Amadeus – up to 126 characters
• Sabre – up to 70 characters
• Galileo – up to 87 characters

If the remark text exceeds the limit, the system will issue a warning and block saving the settings.

Workflow behavior

This element has only an OK output, therefore the process will exit via OK in any of these cases:
Event #5044: Remark added to reservation
Event #5045: Error on adding remark to reservation
Event #5046 Cannot add empty remark to reservation

In Test mode:
Event #5175: The remarks should be added to the reservation but was ignored due to dry run mode

Examples

A remark with static text and a variable that inserts the current UTC time. The variable is displayed in square brackets.

The resulting remark text will be:

TKT ISSUE ERROR/PLS CHECK 10SEP25 14.14

14.14 – example UTC time

Notes

Often used with

Remarks (preceding condition) – use this condition to check the presence or absence of a remark with the specified content in the PNR.

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 commands

Amadeus – RU1A
Sabre – 0OTH
Galileo – 0TUR (as segment)
Galileo – RT.T/ (as remark)

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

(i) For Galileo, choose how to insert the element: as a remark or as a segment

(i) If the calculated date exceeds the maximum allowed value, it is automatically reduced to the GDS limit.

Checkboxes

Do not add 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

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

Amadeus – RU1AHK1STO09SEP

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 – 0OTHYYGK1STO19JUN

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 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-****

NOTES

Often use 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.

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.

(i) At this step, the system does not insert elements in DOCO or DOCA formats.

Equivalent commands

Amadeus – SR DOCS YY Sabre – 3DOCS Galileo – SI.SSRDOCSYY

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

(i) If APIS level is required but only SFPD-level data is available, the data will still be inserted, but the step will be completed with Fail.

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

Notes

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.

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 commands

Amadeus – XE
Sabre – X
Galileo – X

(i) The system can delete only future segments. Segments in the past cannot be detected or deleted by the system.

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.

(i) The system does not use the XI command when canceling the entire booking – it processes the cancellation by removing each flight segment individually.

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

Notes

Often used with

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

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.

GDS	Command
Amadeus	TRFP

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.

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.

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.

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.

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.

(i) The system provides a preconfigured variable, SchdChngFlight, supporting segment statuses UN, SC, WK, TK. You can use this variable directly or create your own in the Variables section.

Optional settings

2️⃣ Use conditions to limit the exchange to specific tickets in the PNR. Only tickets matching the selected criteria will be exchanged.

3️⃣ 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

4️⃣ Define the outcome when no tickets eligible for exchange are detected in the PNR.

5️⃣ Define the outcome when at least one ticket exchange fails and no further reissue attempts are made.

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

Exchange of 2 coupons for 2 coupons

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

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

GDS	Command
Amadeus	FXB
Sabre	WPNCB
Galileo	FQBBK

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

Perform a TTL check after the optimization step has been successfully completed.

TTL validates the remaining time before reservation expiration.

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

Use this option when fare types predefined in the pricing command must be respected.

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.

If passenger type mappings are specified, the system automatically replaces passenger types and reprices the PNR based on the configured mapping.

Create 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.

If disabled, a new pricing record is created only when optimization is found.

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

Use the information provided via the help icon to correctly define the fare basis criteria.

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

By default, this option is disabled. Optimization is rejected if optional services are present.

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

If disabled but a fare brand is explicitly specified in the pricing command, the system still honors the specified 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.

If empty, the pricing record is created in the first available ticketing PCC

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 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

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. 

(i) This element does not perform a new fare recalculation for the restored segments.

Equivalent commands

Sabre – WC 

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.

No specific settings are required.

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

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.

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.

GDS	Command
Amadeus	TRF[TicketNumber]TRFU/WASKCHGTRFP
Sabre	WETR*T[TicketNumber]WETRR WETRR
Galileo	TRNE[TicketNumber]/RF

Use the options below to define the step behavior:

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

(i) If no rules are added or the ticket does not match any of the added rules, the full refund will not be made.

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.

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

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.

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

(i) This option is available only when option 1 is disabled.

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

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

(i) Not available for Ticket processing schemes.

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

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 Error if:

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

Any car segments that do not require a voucher should be removed manually before processing.

GDS	Command
Amadeus	CVP/ET/Sx (x = segment number)

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.

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.

GDS	Command
Amadeus	TTM
Sabre	W¥EMD*AE
Galileo	EMDI

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.

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.

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.

ℹ️ This action does not perform partial re-ticketing. If the PNR already contains partially issued tickets, the action does not issue the remaining ones.

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.

GDS	Command
1A	TTP
1S	W¥
1G	TKP

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.

⚠️ The Ticketing Time Limit stated in the fare quote must still be valid. 

⚠️ Enabling this option may result in airline debit memos (ADM) if fare rules are violated.

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.

⚠️ If the PNR was processed in parallel by another optimization scheme that performed optimization in a different office, the operational office used is the one where that optimization occurred.

• 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 office is selected, an additional setting becomes available:

only for 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.

⚠️ If a carrier filter is applied, add a second Issue ticket action without a filter later in the scheme to issue tickets for the remaining carriers.

ℹ️ Ensure that a branch access agreement and ticketing printer are configured for each specified office

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.

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. 

If the error cannot be resolved automatically after several attempts, the scheme terminates with a Fatal status. The system then sends a notification according to the settings configured in Scheme properties.

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.

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.

• ⚠ Important: Queue availability depends on the selected PCC. Not all queues or categories exist in all offices. Incorrect office selection may result in an inability to read the PNR or a queue movement failure.

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 has 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.

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

GDS	Command
1A	QE
1S	QP
1G	QEB

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.

⚠ 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.

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.

⚠ Important: 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.

⚠ Important: With validation disabled, the system cannot verify whether the specified PCC exists, whether the queue and category are valid, or whether the queue placement operation completed successfully.

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.

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.

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.

GDS	Command
1A	WRA/RT

No additional configuration is required.

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

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.

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:

TVK QC - PASSED 09OCT19 14:10

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

The action has two possible exits:

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

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.

Sabre	WFRR<EMD number>/EMD

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

 [image]

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.

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.

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.

---

ℹ Note: This action works like PNR elements > Remarks but is scoped exclusively to DI remarks.