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

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

Condition Ticket has been issued (preceding): 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.