Dear All,
Please find the trailing circular received from our Regional HQ for your kind information and dissemination to all our travel partners in Nepal.
Sub: Migration Process for PNR Migration
Dear Travel Partners,
Greetings from Air India!
This is further to communication on migrating from Amadeus (1A) to Travelport (Galileo - 1G) Air India inventory.
In order to shift the PNRs made in Amadeus to Travel Port you must send communication both to Amadeus and Travel port. The detailed procedure to be followed / Migration Form and Guide are enclosed. You are requested to complete this process by mid of this week without fail.
The details of procedure as advised by Travelport is quoted below:
Quote
1) Attached please find the migration form (Mail Release Form) that needs to be duly filled in and email to the email id mentioned below:
NOTE : Email to be sent from same email id that is mentioned in the migration form & should be official id instead of personal id.
Please note that you can only choose a date of migration from MON - FRI and the time difference is approximate 11 hours.
Also agency can fill form & send to us for review before directly emailing form to above email ids.
This request must be submitted with at least 5 business days prior to the Migration Date chosen.
Please note the details below regarding the steps to be followed before the cutover date:
2) Attached is Migration Plan document & guide. Please do go through the same.
3) Attached is some of the 1A entries used for Migration which will be useful (Amadeus Entries for Migration).
STEPS FOR MIGRATION :
1. Agency is to ensure that all the data / live PNRs on the Que____ & Que Category _____ of Amadeus System is removed by date fixed for migration and made completely empty. This is the Q number that is being advised to Galileo for all the PCCs.
2. Agency has to ensure that all the past date, and duplicate bookings are removed latest by date fixed for migration from all the systems.
3. Agency to take the printouts of all the live PNRS after the removal of the past date and Duplicate bookings OR PNRs could be saved on system (softcopy).
4. All the live PNRs are placed on the respective Que no of Amadeus at least 24 hrs prior to the time mentioned on the form on that given date. PL SEND US THE SCREENSHOT OF THE QUEUE TABLE SHOWING NUMBER OF PNR QUEUED FOR MIGRATION 24 hours prior to date of Migration.
5. Once the data has been queued, Agency staff needs to remember NOT TO ALTER ANY BOOKINGS. In case any amendments are made, a manual note of the same has to be made and later added into the PNR once PNRs are migrated to Galileo.
6. On the date of migration, the migrated PNRs will be placed on the queues on Agency's corresponding Galileo system. It is important to note that PNRs arriving into the queues are also not altered until a notification is sent from Galileo.
Q/90
|
Waitlisted segments
|
Q/91
|
Schedule changes
|
Q/92
|
Unticketed – time-limit PNRs
|
Q/93
|
Train Bookings
|
Misc. – While migration of PNR is the following message is received “Check date/time continuity or
| |
Q/94
|
Listed segment is followed by confirmed segment or Check continuity segment no.” , the PNR will fall into this queue
|
Q/99
|
PNRs with car & hotel segment and all ticketed bookings
|
7. Agency can use their Galileo PCC to create new bookings from cutover date until all PNR's are migrated completely.
Request you kindly follow the above steps to ensure a smooth migration.
Amadeus entries…. Below is based if Queue No 85 Category 0 is taken for Migration
1) Please do QTQ and see whether there is Q85 already created by them and see whether Q category 0 exists for Q 85.
2) If Q 85 is not created, do the command QA85C1 (This will activate Q 85 and create one Category which is 0)
3) If Q 85 is already created but no Category 0 created, then do QAC85C1-1 (This will activate one Category for Q 85, which would be Category 0 ).
4) If Q 85 already exists, please remove all bookings from Q 85 so that there is no past date bookings in Q 85. The command is QR85C0
5) To place all bookings in Q 85, Category 0 the command is LPO/ALL-Q85C0 (Please do this command after they finish all the work for the day).. will take some time to complete.
6) To view status of all PNRs placed above…. LPS/PS response....completed with queue count of PNRs… pl take screenshot of PNR count.
7) Once the PNR's fall under Q85C0, have a look at them and remove all Past date/Flown PNR's.
8) Once the above task is complete, take a print of all bookings in Q85 using the command is QPR85C0
9) If the LPO/ALL-Q85C0 was done on an earlier date & the same needs to be redone, pl delete all previous PNR placed ….LPX/ALL & then re-do LPO/ALL-Q85C0 on final day of Migration.
10) Take a screenshot of the queue table & send the same to the Migration coordinator.
11) If individual PNRs to be moved to queue 85 cat 0…QE85C0.
AGENCY MIGRATION PLAN- AMADEUS TO GALILEO
INDEX:-
- Important points to be considered
- Terminology & Important Notes
- Amadeus Entries to be used
- Travelport Release Form Inbound from Amadeus & Notes on Travelport Release Form Inbound from Amadeus
- Migrated PNR – Look
- Some Helpful Tips
IMPORTANT POINTS TO BE CONSIDERED
- Galileo migration date is finalized and the process of migration to Galileo will begin on (date) at (time)
- For the migration to be successful, the following will have to be followed by each coordinator:
- Ensure maximum staff has been trained at all branches and wherever training is pending same should be completed at the earliest .We want minimum no. of staff to be trained post migration.
- Galileo will send our engineer to load Focalpoint in all the machines at all your branches and implants between (dates). Kindly co-ordinate with your Galileo representative locally and ensure all PCs have been loaded with Focalpoint latest by (date). In case of a problem please do not hesitate to contact us.
- Ensure no PNR’S are touched, no amendments are made on any PNR’s during the migration period .In case PNRs are amended during such period, the changes will not reflect post migration in Galileo & in that event Galileo will not be responsible for those PNRs.
- In case any changes need to be made, kindly contact the airlines directly and do the needful.
- Agency can start using Galileo effective (date) after receiving a confirmation from Galileo conveying that the migration has been completed successfully.
- All active PNRs need to be moved into a queue assigned by Amadeus at each office ID (details to be provided). Please do not use this queue and category for any purpose apart from placing PNRs for migration.
- Kindly ensure that all dead , inactive PNRs (past date bookings-where all segments are traveled , duplicate bookings – where 2 or more bookings with the same booking reference have been placed on queue twice ) are cancelled , thus reducing the load of PNRs for migration .
- Kindly ensure to take printouts of all the PNRs that have been put on the queue to be migrated, so the same can be verified post migration.
- Details of PNRs which have not been migrated due to any reason will be advised
- After migration the PNRs will fall into Q’s 90-99 on Galileo. Agency should not work on any of these PNRs till a confirmation is received from Galileo regarding completion of the migration process
Q/90
|
Waitlisted segments
|
Q/91
|
Schedule changes
|
Q/92
|
Unticketed – time-limit PNRs
|
Q/93
|
Train Bookings
|
Q/94
|
Misc. – While migration of PNR is the following message is received “Check date/time continuity or Listed segment is followed by confirmed segment or Check continuity segment no.” , the PNR will fall into this queue
|
Q/99
|
PNRs with car & hotel segment and all ticketed bookings
|
To read messages on the Galileo message queue
|
QCA to access the queues, then QM to display any messages.
IT IS THE RESPONSIBILITY OF OPERATIONS MANAGER AT EACH OF THE LOCATION TO ENSURE THAT 24 HOURS BEFORE THE SPECIFIED TIME ( …… ), ALL THE LIVE PNRS ARE QUEUED ON THE SPECIFIED QUEUE FOR ALL THE LOCATIONS. AS A PROCES WE ADVISE A SCREENSHOT BE RETAINED OF THE QUEUE TABEL ON AMADEUS SHOWING PNR COUNT & SEND THAT TO US AS A CONFIRMATION OF NUMBERS OF PNRS TO BE MIGRATED FOR THAT SPECIFIC LOCATION.
If you discover any bookings that are missing once the migration has been completed, please immediately contact your Galileo representative with the details and they will investigate for you.
ONCE THE PNRS ARE MIGRATED, EFFECTIVE (date), PLEASE ENSURE THAT NO BOOKINGS ARE MADE ON AMADEUS AND NONE OF THEIR SYSTEMS ARE IN USE.
IN CASE YOU HAVE ANY QUESTIONS / QUERIES PLEASE CONTACT US AT THE FOLLOWING NUMBERS: (numbers to be included)…….
TERMONILOGY & IMPORTANT POINTS TO NOTE
- Past date bookings (bookings where all segments have travelled) cannot be migrated into Galileo and will be rejected during the migration process. It is advisable to remove these from the capture queue prior to migration however to allow a more accurate estimate of migration volume to be provided and more accurate scheduling of the process to be planned.
- Duplicate bookings (where two or more bookings with the same booking reference have been placed on queue twice) will also be rejected during the migration process but should be removed for the same reason stated above. The migration process will not remove duplicate bookings where these have distinct booking references but the same passenger name and segment details booked. These bookings may be identified and defined as duplicates by carriers when checking space booked and some carriers will cancel bookings that they suspect to be this kind of duplicate. Whilst these will already have been present on the former GDS system, the fact that the migration process sends New Record Locator Teletype messages to the carriers for each segment may make the existence of such duplicates more obvious to the carriers concerned. It is the responsibility of the agency to identify these duplicates and manage them prior to migration.
- AIR SEGMENTS (Participants/Non-Participants)
The booking migration software uploads air segments with the following status codes.
Some status codes may differ slightly between GDSs. In such cases, the application
uses Galileo recognized status codes instead. These are listed below for reference:
Galileo Air Status Code
|
Type
|
Description
|
FS
|
ACTION
|
SOLD ON FREE SALES BASIS
|
HS
|
ACTION
|
HAVE SOLD – INVENTORY ADJUSTED
|
IN
|
ACTION
|
IF NOTHING HOLDING – NEED
|
IS
|
ACTION
|
IF NOTHING HOLDING – SELL
|
IX
|
ACTION
|
IF HOLDING – CANCEL
|
LL
|
ACTION
|
WAITLIST REQUESTED
|
NA
|
ACTION
|
NEED SPECIFIED SEGMENT OR THE ALTERNATE
|
NN
|
ACTION
|
NEED REQUEST
|
OX
|
ACTION
|
CANCEL IF FOLLOWING REQUESTED SEGMENT IS AVAILABLE
|
RR
|
ACTION
|
RECONFIRMING
|
XK
|
ACTION
|
CANCEL WITHOUT GENERATING MESSAGE
|
XL
|
ACTION
|
CANCEL OF WAITLIST SEGMENT
|
XX
|
ACTION
|
CANCEL CONFIRMED/REQUESTED SSR…SEAT
|
DX
|
ACTION
|
INTERACTIVELY CANCELLED; CANCEL ALREADY ALLOWED VIA LINK (MARRIAGE LOGIC ONLY)
|
PK
|
ACTION
|
NEWLY ADDED, CONFIRMED PASSIVE SEGMENT (ONLY SENT TO AIRLINES WITH PASSIVE SEGMENT NOTIFICATION (PSN) AGREEMENT)
|
PL
|
ACTION
|
NEWLY ADDED, WAITLISTED PASSIVE SEGMENT (ONLY SENT TO AIRLINES WITH PASSIVE SEGMENT NOTIFICATION (PSN) AGREEMENT)
|
PX
|
ACTION
|
CANCEL OF PASSIVE SEGMENT (ONLY SENT TO AIRLINES WITH PASSIVE SEGMENT CANCELLATION AGREEMENT)
|
UN
|
ADVICE
|
UNABLE – VENDOR CANNOT SUPPLY SERVICE
|
US
|
ADVICE
|
UNABLE TO SELL – VENDOR CANNOT ACCEPT REQUEST…HAVE WAITLISTED
|
UU
|
ADVICE
|
UNABLE – VENDOR CANNOT CONFIRM…HAVE WAITLISTED
|
NO
|
ADVICE
|
NO ACTION TAKEN (NO INVENTORY HELD)
|
SS
|
ADVICE
|
SELL (SOLD WITHIN THIS TRANSACTION)
|
HX
|
ADVICE
|
HAVE CANCELLED (BY AIRLINE)
|
KK
|
ADVICE
|
CONFIRMING BOOKING
|
KL
|
ADVICE
|
CONFIRMING FROM WAITLIST
|
TK
|
ADVICE
|
HOLDS CONFIRMED? ADVISE CLIENT OF NEW TIMINGS
|
TL
|
ADVICE
|
WAITLISTED? ADVISE
|
TN
|
ADVICE
|
REQUESTED? ADVISE CLIENT OF NEW TIMINGS
|
UC
|
ADVICE
|
UNABLE – SEGMENT CLOSED
|
AK
|
STATUS
|
CONFIRMED OUTSIDE GALILEO SYSTEM - NO MESSAGE SENT WHEN CANCELLED
|
AL
|
STATUS
|
WAILISTED OUTSIDE GALILEO SYSTEM - NO MESSAGE SENT WHEN CANCELLED
|
AN
|
STATUS
|
REQUESTED OUTSIDE GALILEO SYSTEM - NO MESSAGE SENT WHEN CANCELLED
|
BK
|
STATUS
|
BOOKING OUTSIDE GALILEO SYSTEM – MESSAGE SENT WHEN CANCELLED
|
BL
|
STATUS
|
WAITLISTED OUTSIDE GALILEO SYSTEM – MESSAGES STILL SENT AND RECEIVED
|
BN
|
STATUS
|
REQUESTED OUTSIDE GALILEO SYSTEM – MESSAGES STILL SENT AND RECEIVED
|
HK
|
STATUS
|
HOLDS CONFIRMED
|
HL
|
STATUS
|
HOLDS WAITLIST
|
HN
|
STATUS
|
HAVE REQUESTED
|
PN
|
STATUS
|
PENDING NEED – AWAITING CONFIRMATION
|
Below are the status codes used during the migration process for Amadeus:
Conversion of AMADEUS Status Codes
Amadeus Status Code
|
Converted in Galileo to:
|
BK, HL, HK, KL, RR, HX, KK
|
No Change to Code
|
GK
|
AK
|
TL
|
HL
|
KK
|
No Change to Code
|
GN, HN
|
AN
|
SC
|
HK
|
TK
|
HK
|
NO
|
Incorporate the status code “NO” for open segment
|
UC, US
|
UN – with message “AMADEUS UNABLE TO CONFIRM THIS FLIGHT”
|
CAR SEGMENTS
All Car segments from Amadeus, Sabre and Worldspan are inserted into Galileo with a BK status (see table above). Unlike the airlines, which conform to the AIRIMP message standard for the sending of NRL messages, hotel and car companies do not accept a change of ownership between GDSs and so all segments are inserted into Galileo with a vendor code of ZZ. This means that all amendments and cancellations to migrated car segments must be made directly with the vendor as changes made in Galileo will not be passed on.
Example:
Source PNR Segment (from Amadeus)
5 CCR ZI HK1 SFO 06MAR 11MAR LCAR/BS-20206896/ARR-AF0084-1300/NM-FRADIN JEANPIERRE/RC-MH/RT-1410/CF-99953835FR0 *ZI//P2
Galileo Converted Segment
3 0CARZZBK1SFO06MAR-11MARLCAR/**AVIS RATE-PLEASE VERIFY** /CF99953835FR0
HOTEL SEGMENTS
All Hotel segments from Amadeus, Sabre and Worldspan are inserted into Galileo with a BK status (see table above). Unlike the airlines, which conform to the AIRIMP message standard for the sending of NRL messages, hotel and car companies do not accept a change of ownership between GDSs and so all segments are inserted into Galileo with a vendor code of ZZ. This means that all amendments and cancellations to migrated hotel segments must be made directly with the vendor as changes made in Galileo will not be passed on.
Example:
Source PNR Segment (from Amadeus)
2 HHL RT HK1 ESS IN23NOV OUT27NOV 1ROHRNH EUR65.00 DLY RHE
MERCURE ESSEN VIEHOFERPLATZ 2M/BC-ROHRNH/BS-08210370
/CF-9991EKM502
MERCURE ESSEN VIEHOFERPLATZ 2M/BC-ROHRNH/BS-08210370
/CF-9991EKM502
Galileo Converted Segment
1 0HTLZZBK1ESS23NOV-OUT27NOV**MERCURE ESSEN VIEHOFERPLATZ 2M RATE-65.00EUR**/CF-9991EKM502
“Date Beyond” Segments
Each GDS has a different system limit on the number of days in advance that a segment can be booked. It may be that segments booked in the former GDS are beyond the Galileo limit set to allow booking.
These segments will be inserted into the Galileo booking as a TUR segment, a Phone Field entry (to ensure high visibility) and a Notepad item.
Example:
1 0LH5910D 02JAN FRABRU HK3/1535 1630
The above segment would be entered through a TOUR segment as:
1 0TURZOBK1FRA<Valid future date>-**0LH5910D 02JAN FRABRU HK3/1535 1630**
and
1 0TURZOBK1FRA<Valid future date>-**0LH5910D 02JAN FRABRU HK3/1535 1630**
and
P.<PhoneCity>N*0LH5910D 02JAN FRABRU HK3/1535 1630 Date Beyond Segments
and
NP.0LH5910D 02JAN FRABRU HK3/1535 1630 Date Beyond Segments
The agency must convert these to live segments once the segment is within bookable range.
Married Segments
Segments linked by the carrier at time of booking to give a linked fare.
The carrier inserts marriage indicators when the booking is made and cannot be migrated from one GDS to another.
It is the agency’s responsibility to check for any marriage logic warnings before modifying a booking.
When migrating from the Amadeus system, Amadeus do not currently capture married segment information when supplying booking data to us so no warning can be given that these existed in the original booking.
“Past Date” Segments
These are segments in the original booking that have travelled or are past their date of travel.
Past date segments will not be migrated into the Galileo system as Galileo does not allow the insertion of a past date segment. The remainder of a booking containing past dated segments will be migrated as normal.
Bookings where all segments are travelled or past dated should be removed from the capture queue in the former GDS by the Agency Coordinator before the data is captured.
“Duplicate” bookings
Duplicate bookings where two or more bookings with the same booking reference have been placed on queue twice for capture will be automatically rejected during the upload process. The migration process will not remove duplicate bookings where these have distinct booking references but the same passenger name and segment details booked. As mentioned previously, these bookings may be identified and defined as duplicates by carriers when checking space booked and some carriers will cancel bookings that they suspect to be this kind of duplicate. Whilst these will already have been present on the former GDS system, the fact that the migration process sends New Record Locator teletype messages to the carriers for each segment may make the existence of such duplicates more obvious to the carriers concerned. It is the responsibility of the agency to identify these duplicates and manage them prior to migration.
TUR segments
TUR (tour) segments are built with the equivalent Galileo field formats.
Sometimes to retain a PNR at least a live dummy TUR segment is needed.
Sometimes to retain a PNR at least a live dummy TUR segment is needed.
Reject Bookings
These are bookings that, for some reason, cannot be migrated into Galileo. If a new type of information is identified during conversion then the automation software will be modified and the data represented to it. Exceptional bookings that cannot be migrated are reported to the agency as “rejects”.
Some common reasons why bookings may also have to be rejected are:
- Number of seats does not match with number of passengers.
- Some itineraries cannot be built with the original formats/status codes.
- Missing Group names.
- Duplicate passenger names.
- Source PNRs with missing SI.RLOC information cannot be built.
Where possible the agency should ensure that such issues are corrected in the original GDS system to prevent bookings being rejected during the migration process.
AMADEUS ENTERIES (However do verify with 1A as there could be some changes….
(Below is based assuming Queue No 85 Category 0 is taken for Migration)
1) Please do QTQ and see whether there is Q85 already created by them and see whether Q category 0 exists for Q 85.
2) If Q 85 is not created, do the command QA85C1 (This will activate Q 85 and create one Category which is 0).
3) If Q 85 is already created but no Category 0 created, then do QAC85C1-1 (This will activate one Category for Q 85, which would be Category 0).
4) If Q 85 already exists, please remove all bookings from Q 85 so that there is no past date bookings in Q 85. The command is QR85C0 .
5) To place all bookings in Q 85, Category 0 the command is LPO/ALL-Q85C0 (Please do this command after they finish all the work for the day).. will take some time to complete.
To view status of all PNRs placed above…. LPS/PS response....completed with queue count of PNRs… pl take screenshot of PNR count. Once the PNR's fall under Q85C0, have a look at them and remove all Past date/Flown PNR's.
Once the above task is complete, take a print of all bookings in Q85 using the command is QPR85C0.
If the LPO/ALL-Q85C0 was done on an earlier date & the same needs to be redone, pl delete all previous PNR placed ….LPX/ALL & then re-do LPO/ALL-Q85C0 on final day of Migration.
Take a screenshot of the queue table & send the same to the Migration coordinator.
If individual PNRs to be moved to queue 85 cat 0…QE85C0.
TRAVELPORT RELEASE FORM INBOUND FROM AMADEUS
Authorisation for Release of Information
IMPORTANT: This release form should be sent via e mail as an attachment to: DATA.MIGRATIONS@TRAVELPORT.COM and AGENCYMIGR@AMADEUS.COM
Receiving GDS
(choose one)
|
☐ Galileo
|
☐ Worldspan
|
☐ Apollo
|
This request must be submitted with at least 5 business days prior to the retrieval dates.
Note: This notice period does not guarantee that the requested date will be available.
This is your authority to release all PNR and/or PROFILE records to our new chosen GDS. Please find below the information you will need to retrieve our data in the time frame we have specified.
I understand that incomplete or invalid information will delay the data migration. Note: It is mandatory for the agency to provide queue and category information as well as a count of the number of PNRs on queue for capture.
I agree that by virtue of releasing such information, Amadeus and its affiliates does not waive or relinquish any legal rights it may have with respect to the underlying contractual relationship between it and the agency listed below, including agency representatives. I agree that I shall continue to comply with all of the necessary laws, regulations and rules that relate to the use of personal data and that upon assignment of the data Travelport will cease to be liable for any act or omission in breach of this or any subsequent legislation.
Note: Customer is responsible for doing a queue count and providing queue and category in which PNR’s are to be extracted from. If this information is missing, it will result in a delay in getting PNR’s.
When requesting a capture of 5,000 or more PNRs/profiles, the records must be placed on the queue the night prior to the scheduled date for an 800 AM capture. PNR’s created on the day of the capture must then be placed on a designated queue for an 8am capture on the following business day. For 5pm captures of less than 5,000 PNR’s and more than 5,000 records are placed on queue the additional PNR’s will be captured the following business day.
Agency Releasing PNRs/Profiles:
Agency Legal Name:
|
Office ID:
| |||||||
Trading As:
| ||||||||
CIDB Number:
|
N/A
| |||||||
Address :
| ||||||||
City:
|
Country:
|
ZIP :
| ||||||
Contact Person:
|
Alternate Contact:
|
Phone:
| ||||||
Email Address:
|
(This email address is used to validate the release form and must be from the releasing agency rather than personal email account.)
| |||||||
Authorised Agency Signatory Name, Title, Email address & Phone Number:
| ||||||||
Amadeus Account Manager (mandatory):
|
Email:
|
Agency Receiving PNRs/Profiles:
Agency Legal Name:
|
PCC/SID:
| |||||
Trading As:
| ||||||
CIDB Number:
| ||||||
Address :
|
City:
| |||||
Country:
|
ZIP:
|
Email:
| ||||
Contact Person:
|
Alternate Contact:
|
Phone:
| ||||
Travelport Account Manager (mandatory):
|
Lynette Alexander
|
Email:
|
lynette.alexander@galileo.co.in
|
PNR Conversion :
Retrieval Date:
| Valid days are Monday to Friday only. | |
Retrieval Time:
| Valid times are from 08:00 – 17:00 U.S Eastern time only | |
Queue Number:
|
… where PNRs will be placed for retrieval. Also state category (for Amadeus migrations)
| |
Estimated Number of PNRs:
|
Active PNRs only, past-dated PNRs will not be converted and should be removed prior to capture if possible.
|
Profile Conversion:
Retrieval Date:
| Valid days are Monday to Friday only. | ||
Retrieval Time:
| Valid times are from 8:00 – 17:00 U.S Eastern time only | ||
Estimated number of profiles?
|
This should be a total of all levels of profile to be migrated.
| ||
Retrieve…
|
☐ All Profiles
|
☐ Specific Profiles
|
☐ No Profiles (choose one)
|
If only specific profiles are to be retrieved, please list which ones below:
| |||
REMARKS:
NOTES ON TRAVELPORT RELEASE FORM INBOUND FROM AMADEUS
Email to be sent from same email id that is mentioned in the migration form & should be official id instead of personal id.
Please note that you can only choose a date of migration from MON - FRI and the time difference is approximate 11 hours .
Do cc the email to us for follows to be then done by us: lynette.alexander@galileo.co.in
MIGRATED PNR WILL LOOK LIKE ….
QUEUE 99
T777BO/11 XDBMC E231114 MA 143XXXXX 31MAR
1.1GALILEO/TESTMS
1. AI 471 T 07MAY JDHBOM TK1 1400 1625 SA
** VENDOR LOCATOR DATA EXISTS ** >*VL·
** SERVICE INFORMATION EXISTS ** >*SI·
FONE-CCUT*33-0000000 – ABC TRAVELS - A
2. BOMN*C/O NISHA
3. BOMN*XXXE WNISHA AT ABC TRAVELS
4. ATLN*/MEMO/BF BUILT BY GALILEO AUTOMATED SYSTEM CONVERSION
5. ATLN*/MEMO/PLEASE CHECK REMARKS FOR ITINERARY INFO
FOP -S
TKTG-T*OK16FEB/BOMI228BM//ETIC
NOTE-*T* T- T/OK16FEB/BOMI228BM//ETIC 11 31MAR 1729Z
2. *S* 1.SSR ADTK 1A TO IC BY 1656 16FEB ELSE WILL BE XXLD 11
31MAR 1729Z
3. T-CA-01 ERFADITI 11 31MAR 1729Z
4. NP.****BS TOWN ADITI 11 31MAR 1729Z
5. FM *M*3 11 31MAR 1729Z
6. G 16FEB*NWSU/1A OFFICEID /BOMI228BM-B 11 31MAR 172
9Z
7. AI/JSKGF 11 31MAR 1729Z
8. FM *M*3 11 31MAR 1729Z
9. G 16FEB*NWSU/1A OFFICEID /BOMI228BM-B 11 31MAR 172
9Z
10. AI/JSKGF 11 31MAR 1729Z
SOME HELPFUL TIPS…….
- REISSUE & REFUNDS OF TICKETS ISSUED ON AMADEUS…..
Reissue; once the PNRs are migrated to Galileo, we can reissue the ticket on Galileo. We can do the reissue in the PNR that has been migrated by putting the original Ticket Numbers for reissue provided the ticket image opens on Galileo.
Name mismatch – In Galileo, the agent may get name mismatch error while reissuing the ticket because of space in the name when the ticket was issued from 1A. As 1A accept spaces but in Galileo spaces are not allowed so if seats are available try to create new PNR in Galileo & put that ticket for reissue. The last option to get the ticket reissued back from 1A OR carrier office.
Refund: Once PNRs are migrated to Galileo, we can process the same on our system provided the ticket image opens on Galileo. If we are unable to process the refund on Galileo then the same should be processed via BSP link.
Both the above can be done as the IATA Location (IATA No) is the same irrespective of CRS provided the Ticket image opens in Galileo post Migration.
In case the Ticket Image does not open in Galileo then in such cases the Reissue/ Refund will need to be done from carrier office only.
- TICKET NUMBERS IN MIGRATED PNR……
We can locate the tickets number in the Migrated PNR in the Notepad.
- VENDOR REMARK……
Very important to check the Vendor remarks of all Migrated PNR's to see the responses from the carriers concerned. Maybe a *VR snapshot could be pasted
- GALILEO PNRS AGAINST AMADEUS PNRS…..
To find out the Galileo PNRs for the Amadeus PNRs migrated staff needs to refer to the template sent to them post migration of each branch advising them of the Amadeus V/s Galileo PNR's migrated.
6) PNRS NOT MIGRATED (NO SEATS AVAILBALE) …..
If any PNR(s) have not been migrated after migration is completed, & there are no seats to cancel that pnr, then leave the live PNR(s) on Amadeus system. Agency can then create a passive pnr on Galileo and ticket the same and then pass the ticket number locally with the airlines.
7) PNRS NOT MIGRATED ( SEATS AVAILABLE)
If any PNR(s) have not been migrated and there are seats available, then cancel the Amadeus pnr & create new PNR(s) in Galileo system.