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.

Entering passenger contact details in SSR/OSI format is a requirement for most airlines.
Missing these elements in the PNR may result in fines from the carrier, which will be charged to the agent.

This step automates the process of adding passenger contact information.

The system detects and inserts the passenger’s phone number and email address in CTCM/CTCE formats and OSI remarks.

How contact data is detected

The system reads the following PNR fields depending on the GDS:

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

Phone numbers (CTCM)

• Added to SSR/OSI remarks once only during processing.
• If the phone number in the PNR is later deleted, changed, or replaced, the SSR/OSI entry will not be updated automatically — it will keep the original value.
• If you edit the phone number in the PNR, make sure to update the SSR/OSI remarks manually.

Email addresses (CTCE)

• The system detects email addresses and adds them to SSR/OSI remarks.
• On reprocessing, any new email addresses found will be added to the existing ones (previous emails will not be removed).

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

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

The system applies Best Buy pricing to determine the lowest applicable fare for the current itinerary. Upon identification of a lower fare, and subject to the conditions and restrictions configured for this step, the system rebooks segments as required, generates a new pricing record, and uses it for downstream processing.

The settings allow you to control the repricing logic, including the ability to:

• 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).

The optimization will be rejected if:

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

Successful fare optimization may lead to a change in the ticket time limit (TTL). It is recommended to perform the Ticket Time Limit check after the optimization step has been successfully completed.

Ticket Time Limit (TTL)  — enables validation of the remaining time before the reservation TTL expiration.

Configure the parameters that define the scope of the system’s search for lower-priced fare options. The search behavior is governed by the following settings:

1) By fare type

---

Use [any / private / published] fares for PNR pricing - specifies the fare types within which the system is allowed to search for lower-priced options.

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

(i) If the fare types predefined in the pricing command (PQ) must be respected, use the following setting:

• Keep original fare type (if specified in pricing command) - when enabled, the system applies the fare type explicitly specified in the inbound pricing command. The following logic is applied:
  - If a fare type is specified in the pricing command, it is mandatorily applied during subsequent repricing.
  - If no fare type is specified, the system applies the value defined in Use [__] fares for pricing.

(2) By passenger type

---

Optimize using another passenger type - specifies alternative passenger type codes (PTCs) to be used when the system is required to replace the original passenger type (for example, ADT, CHD, INF) with another one during pricing.

For example, if a passenger is booked in the PNR as ADT, but the agency applies special fares for the VFR category, the system overrides the passenger type and reprices the itinerary using the alternative PTC.

(i) If passenger type mappings are specified, the system automatically replaces the 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 for the specified passenger types if the resulting total amount is equal to or lower than the amount in the existing pricing record (that is, an optimization has been found).

(i) If option disabled, new pricing record will be created only if fare optimization is found.

Limit optimization using the following settings

---

(3) Specifies the minimum savings threshold, defined as an amount or a percentage required to apply fare optimization. If the savings are insignificant, the system skips repricing to avoid unnecessary changes  

(4)  Select this setting to validate baggage conditions when searching for new fares and to reject optimization if any of the following applies:
- is more restrictive — the baggage allowance of the new fare is more restrictive than that of the current fare;
- does not allow any baggage — the new fare does not include any baggage allowance.  

(5) Enable this option to reject fare optimization for specific fare basis patterns, either for all carriers or for selected carriers. Use the information provided via the help icon to correctly define the fare basis criteria applied by the system.  

(6) Enable this option to allow fare optimization even when optional services (SSRs) are present in the PNR. In this case, SSRs associated with the modified segments will be cancelled and must be requested again

(i) By default, this option is disabled, and fare optimization is rejected if optional service requests are present in the PNR. 
In such cases, it is recommended to add the Lower fare is available step to the "NO CHANGES" output. This allows the agent to see that optimization is possible but was not applied due to the presence of optional services, and to perform the optimization manually if required.

(7) Enable this option to request booking classes for all itinerary segments, not only for the segments where optimization has been identified.

(i) This setting is useful for carriers that track the timing of segment updates. If outbound and inbound segments are modified at different times, the carrier may treat this as an invalid booking modification_. Reassigning booking classes for all segments helps avoid this issue.

(7) Allows the system to preserve the fare brand during optimization, even if it is not explicitly specified in the pricing command. When this option is enabled, the system automatically determines the applicable fare family and performs optimization within the boundaries of that brand.

(i) If this option is disabled but a fare brand is explicitly specified in the pricing command, the system still honors the specified brand regardless of the setting state.

Specify the offices where the system is allowed to perform pricing

---

(8) Select the offices (OID/PCC) to which the system is allowed to connect in order to perform pricing evaluations. If no offices are specified, the scheme performs pricing only in the office defined in the Scheme Properties.

(i) The list of available offices is based on the offices configured in the Office section.
(i) The selected offices must correspond to the list of offices specified in the preceding Lower fare is available step.

(9) Specify the ticketing offices (OID/PCC) to be used for ticket issuance when an optimization is detected in an office that is not ticketing-enabled but is included in the list above.

(i) If the list is empty, the PQ for optimization in a non-ticketing office will be created in the first available ticketing PCC where the pricing is possible.

The system will complete this step successfully if, according to the specified parameters, a lower fare is found, the segments are successfully rebooked and the new PQ/FF/TST is stored.

Exits via OK if:
Event #4076: Found a lower price option. Possible profit is [__]
Event #4029: PCC/OID [__]: Cost improvement completed successfully. Details [__]

Exits via NO CHANGE(*) if:
Event #4017:  PCC/OID [__]: Fare evaluation did not return any better value.

(*) if this response is received for all PCC/OIDs where an optimization attempt was made 

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

Often used with

Event happened (condition preceding) – the “Ticket has been issued” setting will allow you to determine whether tickets have previously been issued for this PNR.

Theoretically possible to reduce total amount (condition subsequent) — allows to detect and exclude from optimization those PNRs that already have the lowest possible fare booked in the lowest booking classes.

Lower fare is available  (condition subsequent)  — allows to check if the PNR can be optimized at the time of processing

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.

Settings

No specific settings are required.

Workflow behavior

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

Exits via OK if:
Event #3160: Segments recovered

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

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

Examples

The segment with status code HX has no alternative

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

Processing result: OK (Event #3160)

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

The HX segment is overlapped by a segment with status HK

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

Processing result: FAIL (Event #3163)

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

The HX segment is overlapped by a segment with status TK

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

Processing result: FAIL (Event #3162)

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

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

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

Processing result: OK (Event #3160)

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

Notes

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.

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

Notes

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.

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