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.

How contact data is detected

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

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.

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

Adding a VIP PASSENGER message

One of the common applications of this element is adding a VIP PASSENGER message to the PNR. The following examples show how such an OSI remark appears in the processing history and how the behavior differs in normal and Test modes.

• If the OSI remark is successfully added to the PNR, the processing history for the corresponding instance will display the following entry:

  OSI added to reservation for carrier LH (event 5042)  
  OSI text: VIP PASSENGER

• If the scheme was run in Test mode, the message will be as follows:

  OSI text: VIP PASSENGER (event 5392)  

  The test run does not allow changes to be saved. The PNR must be saved and re-read.

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

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

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

Remark types

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

Text length limits

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

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
where 14.14 is the current UTC time.

Suggested preceding conditions

Remarks: use this condition to check the presence or absence of a remark with the specified content in the PNR.

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

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

Notes

• If the calculated date exceeds the maximum allowed value, it is automatically reduced to the GDS limit.
• If the option Do not add retention segment if one with a later date already exists is enabled, the system will not insert a new segment (even if different from the existing one), and the step will exit with OK.

Good to know: To keep a PNR for the maximum possible period (up to 360 days from processing), enable the option Assign the maximum possible retention period.

Errors and exception handling

If an error occurs when inserting the remark, the step ends with Fail. In this case, It is recommended to configure an alternative post-processing scenario (e.g., place the PNR in a queue, send an email, or add a tag).

(i) Processing in Test mode will result in exit on Fail.

Corresponding commands

Suggested preceding conditions

• Coupon status – check that the PNR contains a ticket with coupons still in Open status.
• Itinerary exists in PNR – monitor PNRs where (if the condition above is met) the itinerary is missing.

• Control of DOCS presence on all segments for all passengers in the PNR
• Automatic insertion of missing data
• Simplifying agent workflow: automatic completion of missing information from the passenger name field or back-office systems

Errors and exceptions

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

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