Introduction
KIU SNAPSHOTS (PNR) is a service for PNRs that will allow keep synchronized the status of all PNRs with the PSS in real-time. Every time a PNR is created, modified, splited, or purged, a JSON file will be sent with the affected PNR(s).
File Structure
The name of the JSON file has the prefix PNRS_ and the timestamp in UTC, following the pattern PNRS_YYYYMMDDTHHMMSSFFFZ.json. For example, PNRS_20230512T105030923Z.json.
Internally, the file contains an “event_details” object that provides details about the event that triggered the change, and a list of affected PNRs [1..n]. Each object in the array represents a PNR, and its structure is represented in the schema of the get_booking_information API (with the exception of the purge event).
Example File
{
“event_details”: {...},
"pnr_list": [
{
"record_locator_version_information": {},
"record_locator_information": {},
"passengers_information": {},
"flights_segment_information": {},
"flights_origin_destination_information": {},
"contacts_list": [],
...
},
{...}
]
}
Structure of event_details
The event_details object has the following structure:
Key | Type Data | Possibles values | Description | Example | Observations |
|---|---|---|---|---|---|
system_from | string(2:3) | C1 or airline operator code, depending on whether it is a PSS terminal or Kiu GDS terminal | Z8 | ||
company | string(4) | Unique code of the company, airline, or agency within Kiu | 00Z8 | ||
channel | string | HOST, GDS | HOST | ||
subchannel | string | In the case of GDS, it’s the own GDS code (C1, 1A, etc.). For HOST, is the value configured in the office table, command DNO / BI STAT.SUB-CHANNEL. | SALES OFFICE | ||
device | string(0:10) | Kiu device that generated the transaction | LPB00Z8205 | ||
agent | string(0:9) | Kiu device that generated the transaction | HDQ00Z8SM | ||
pnr_action | string | CREATE, MODIFY, SPLIT, DELETE | Identifies whether the event is a creation, modification, or split | CREATE | The SPLIT will apply to both PNRs (the newly created and the modified ones in that process). |
transaction_type | string | DIRECT, INDIRECT | Identifies if the modification to the PNR is a direct intervention by a user/API or an indirect one related to another process. | ||
origin | string |
| Identifies the origin that triggers the modification Related to the If it's DIRECT, this field could be:
If it’s INDIRECT, this field could be:
| ||
application | string |
| Detailed in "Source and Applications" | ||
timestamp | datetime | 2023-04-20T22:02:32.750Z |
Source and Applications
Since there are different scenarios where a PNR can be modified, the classification is based on the type of transaction - direct or indirect - the origin, and the application that triggered it.
Based on these variables, the following combinations are constructed:
Origin | Application | Agent | Description |
|---|---|---|---|
AGENT/WEBSERVICES | KIU_COMMAND / OTHER | The entity that generates the transaction | Processes of reservations, modification, splitting, saving, issuing and voiding, via commands or APIs |
WEBSERVICES | OTHER | The entity that generates the transaction | Reservation creation, reservation modification, and reservation splitting processes via webservices (v1 and v2) |
FROM_EXTERNAL_MESSAGE | MESSAGE_PROCESS | KIUSYSTEM | Process of Creation, Modification, and Splitting of Reservations via TTY Type B/Type A messaging. In this case, the device will be that of the office configured for the host with terminal address 00. |
FROM_EXTERNAL_MESSAGE | PFS_PROCESS | KIUSYSTEM | Adjustments due to post-departure messages (PFS, PRL) |
FROM_EXTERNAL_MESSAGE | PRL_PROCESS | KIUSYSTEM | Adjustments due to post-departure messages (PFS, PRL) |
INTERNAL_PROCESS | KAM | The entity that generates the action in KAM | KAM quota management process (inventory PNRs) |
INTERNAL_PROCESS | ROBOT_TIME_LIMIT | KIUSYSTEM | Robot time limit adjustments |
INTERNAL_PROCESS | VMOVE_PROCESS | KIUSYSTEM | Reservation changes with VMOVE command (reaccommodation) |
INTERNAL_PROCESS | VMTM_PROCESS | KIUSYSTEM | Reservation changes with VMTM command (schedule change), if the carrier has that function activated. |
INTERNAL_PROCESS | EXPIRED_ITINERARIES_PROCESS | KIUSYSTEM | Process for canceling expired active itineraries (those that have passed more than 40 hours since their flight date) |
INTERNAL_PROCESS | CONFIRM_WAITLIST_PROCESS | KIUSYSTEM | Automatic waitlist confirmation process |
INTERNAL_PROCESS | SCHEDULE_PROCESS | KIUSYSTEM | Reservation changes due to schedule change (reaccommodation) |
INTERNAL_PROCESS | SERVICES_AUTOMATIC_CANCEL | KIUSYSTEM | Process for canceling itineraries or SSRs due to expiration. |
INTERNAL_PROCESS | SSR_INVENTORY_PROCESS | KIUSYSTEM | Process for confirming/rejecting SSRs with inventory |
INTERNAL_PROCESS | SSR_AUTOMATIC_PROCESS | KIUSYSTEM | Internal process for creating/canceling SSRs (This process is used by the system when an action/command needs to automatically add SSRs to a PNR, for example: when web check-in is done for a flight managed in an external DCS, and the SSR needs to be added with the check-in data.) |
INTERNAL_PROCESS | FOP_VALIDATION_PROCESS | KIUSYSTEM | Post-validation process for online payment issuance (In this process, the validator may add remarks with errors from the process or, for example, a remark with a transaction reference) |
INTERNAL_PROCESS | SEAT_ASSIGN_PROCESS | KIUSYSTEM | Internal seat assignment process (This occurs, for example, with the current web check-in functionality where a default seat is chosen, and since it involves PRS, the PNR is modified.) |
INTERNAL_PROCESS | RECORD_LOCATOR_PURGED | KIUSYSTEM | PNR purge process |
RECORD_LOCATOR_SYNCHRONIZATION | Synchronization process that generates snapshots of all active PNRs in the PSS. No modifications are made to the reservation. |
Purge
The PNR purge process can contain up to 1,000 PNRs in a single file. In this scenario, the key record_locator_version_information of each PNR will be provided, along with a copy of the PNR history at the time of the purge (equivalent to *H).
Example of file
{
"event_details": {
"application": "RECORD_LOCATOR_PURGED",
"timestamp": "2023-08-15T05:02:13.540Z"
},
"pnr_list": [
{
"record_locator_version_information": {
"record_locator": "AWCVUB",
"record_locator_version": "2023-08-14T00:00:05.360Z"
},
"history_item_list": [
"ARM ITINERARY RECEIPT-» BAGGAGE ALLOWANCE 1 PIECES UP TO 10K FOR ADT",
" /XX100 Y 12AUG AEPOYO",
"BUE.BUEXX-DA 1325/12JUL23",
"XS XX100 Y 12AUG SA AEPOYO HK1 0800 0830",
"SYS-EX 0000/14AUG23"
]
},
{
"record_locator_version_information": {
"record_locator": "BFLNBT",
"record_locator_version": "2023-08-14T00:00:05.360Z"
},
"history_item_list": [
"XTK OK",
"AT FC WK*F/VIXXXXXXXXXXXX4242N/XXXX/V123/Z12466",
"ATT OK * 10AUG23/AEPXX-FT",
"ATK 9990210044640 * 10AUG23/AEPXX-FT - FERNAN/M.",
"ATK 9990210044641 * 10AUG23/AEPXX-FT - FERNAN/M.",
"AEP.AEPXX-FT 1524/10AUG23",
"ASR ABAG XX HK1 AEPCOR2049Y12AUG-1FERNAN/MR.UPTO 23KG BAGGAGE",
"ASR ABAG XX HK1 AEPCOR2049Y12AUG-1FERNAN/MRS.UPTO 23KG BAGGAGE",
"AEP.AEPXX-FT 1525/10AUG23",
"XSR ABAG XX HK1 AEPCOR2049Y12AUG-1FERNAN/MR.UPTO 23KG BAGGAGE",
"XSR ABAG XX HK1 AEPCOR2049Y12AUG-1FERNAN/MRS.UPTO 23KG BAGGAGE",
"SYS-TX 0730/11AUG23",
"XS XX2049Y 12AUG SA AEPCOR HK2 0800 0900",
"SYS-EX 0000/14AUG23"
]
}
]
}
Recap
When this module is implemented, a RECAP process will be executed that will re-run un the database, generating a snapshot of each PNR. In this scenario, there are no modification to the PNR; the event_details will only have the key "application": "RECORD_LOCATOR_SYNCHRONIZATION".
This RECAP functionality is included in the implementation cost. Any additional requests by the airline for re-execution of this process will need to be evaluated by the commercial department.