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:

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:

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.

Entering passenger passport details in the PNR in the SSR DOCS format is required by most airlines and is mandatory for successful ticket issuance.

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.

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.

[ADD IMAGE]

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

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.

Use the options below to define the step behavior:

[ADD IMAGE]

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.

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.

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.

[ADD IMAGE]

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.

heading h3

paragraph

heading h3 bold

paragraph

heading h4

paragraph

heading h4 bold

paragraph

heading h5

paragraph

heading h5 bold

paragraph

heading h6

paragraph

heading h6 bold

paragraph

Use [ FARE TYPE ▼ ] fares for PNR pricing.
☐ Keep original fare type (if specified in pricing command).

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.

Optimize using another passenger type
Adult: <CHOOSE TYPE>     Children: <CHOOSE TYPE>      Infant: <CHOOSE TYPE>
☐ Create new pricing record for the specified passenger types.