Questions And Answers

In the A15 section provided the data has been entered in the Travelport+ Booking File using the RI.CT, RI.AT etc entries.

Enter the data using a T- (Travelport Apollo System) or DI. (Travelport+) entry and it will appear in the A14 section. These fields provide a free format area and it is the responsibility of the back office system to define the format of the text to be used in this area. Note that the character set is 7 bit ASCII and limited to upper case letter, numbers and a small number of other characters such as -/.(*).

The MIR is sent automatically provided:

• A ticket is being issued and

• The issuing terminal is linked to a MIR device and

• The sending of a MIR is not countermanded.

A MIR can be sent at other times but must be specifically requested, typically using the DAD modifier.

Retransmission (using the HQNN entries) involves finding the original MIR and then sending that exact MIR again. The Booking File/PNR need not be present for this to occur.

A DAD (e.g. issued using TKPDAD) MIR is a new MIR. It will contain a copy of the booking file at the point when it is commanded. All MIRs are a snapshot of the booking file at the point where the entry creating the MIR is sent.

MIRs are only held in buffers for a maximum of 24 hours. Once deleted from the buffer the MIR cannot be retransmitted.

Look at T50IN1 which will be Y for a retransmission. T50IN12 indicates what entry was originally used to create the MIR so a retransmitted DAD MIR will have Y in T50IN1 and A in T50IN12.

There are several answers to this question depending on the precise meaning of the question.

As previously noted retransmission will find the original and send an exact copy. Alternatively the DAD modifier causes a new MIR, representing the PNR/Booking File at the moment of request, to be sent. Also see “Dual MIR” and next answer.

The MIR product itself has “Dual MIR” capability. This comes in 2 flavours:

• The entry TKPDND.F101BA.GL2 will cause a MIR to be sent to the MIR device F101BA at pseudo city GL2. No MIR will be sent to the linked (normal) MIR device.

• The entry TKPDXD.F1012E.AA0 will cause a MIR to be sent to the linked (normal) device and to MIR device F1012E at pseudo city AA0.

In both cases the actual MIR device and pseudo city will be allocated by Galileo.

Galileo also provides a piece of software know as the “Data Collector”. The software resides on the Galileo Print Manager PC and only works when MIR to disc is in use. The Data Collector can be configured to create more than one copy of each MIR. It can be configured to create copies of some MIRs and nor others. It can be configured to send copies to different discs and folders.

It depends. Until a fare is present the MIR will represent the whole PNR/Booking File. Once a fare is present the MIR will represent the flights related to a filed fare. The precise meaning varies slightly between Travelport+ and Travelport Apollo System. See A04 and A05 sections for a full explanation.

Commission percentages are shown in T50RTE and amounts in T50COM. The two fields are mutually exclusive. Travelport+ and Travelport Apollo System will only ever transmit one, or the other.

The user has not entered a plating carrier.

• Serial

  Where the MIR is being transmitted to a serial device it is necessary for the receiving system to implement XON/XOFF flow control. Where this is not implemented the data flow will be uninterrupted and can fill the memory of the receiving system. Once the memory of the receiving system is full with data it has to process the received data and and further data sent by Galileo during processing will be lost by the receiving system. This method of delivery is no longer recommended.

• MIR to disc – mapped

  It is technically possible to configure the MIR to be delivered round a LAN (or even a WAN) to a mapped disc/folder. We have experienced issues with the reliability of the LANs/WANs provided by agencies, in particular character or even block loss. It is therefore recommended that at least one copy of every MIR is written to the same disc as the Galileo Print Manager installation.

• MIR to disc – local

  This is the preferred method of delivery. The MIR is delivered to a folder on the same PC that hosts the Galileo Print Manager software. Truncation occurs when the receiving system tries to process the file before Galileo has finished writing it. Once Galileo has written the file we recommend that a copy be taken and the original left in place. The copy can then be processed and, when processing has successfully completed the original can be deleted.

If you look at the folder where Print Manager has been configured to place MIR to disc files you will find that, as well as the MIR to disc files (*.MIR) there is a file called mirfile.txt. Mirfile.txt contains the file name of the next file to be created. If it is not present a new copy is created and the next file name starts again at AAAAAGAL.MIR. It is therefore important, when copying MIR files to only copy MIR files and to ensure mirfile.txt is left alone.

IT (Inclusive Tour) and BT (Bulk Tour) ticketing started as a reaction to Package Tour holidays. It allowed scheduled airlines to offer tour operators special (lower) fares. Not wanting to disclose these fares to the travelling public airlines chose to print the letters IT or BT in the fare and total boxes in place of the actual fare. Agents were required to have such arrangements approved and, once approved, a “tour code” was issued that had to be shown in the box of that name on the ticket. Arrangements sold using IT and BT fares had to be sold at a price that included the fare, hotel accommodation and transfers between the airport and accommodation. When airlines began selling special fares as a matter of course (without the need for accompanying accommodation or transfers) many airlines simply adapted the IT/BT method. The agency enters the amount due to the airline (known as the net fare), sets the commission at zero and uses IT and BT to hide this from the customer on the ticket. The Tour Code box contains data which looks like an actual Tour Code but may have a different meaning to the airline. The sale price is set by the agency and the difference between this and the amount due to the airline is the agency “profit”. The sale price is usually not reported to the BSP meaning that if the agent accepts payment by credit card he does so using his own merchant agreement, not the merchant agreement of the airline.

Some airlines adopted a different method, sometimes known as “Net Remit”. Both Net Remit and IT/BT (sometimes known as Net Report) can exist within one BSP.

Net Remit has an actual fare in the fare box that the passenger sees. This is reported to and billed by the BSP in the usual way and commission (if any) is applied. The agency adds further information to the ticket either in the form of an amount due to the airline (known as the net fare - again) or additional commission. This is then processed by BSP to a secondary billing showing the actual amount due to the airline. Additional commission can be an amount or a percentage and can be applied to the fare shown in the fare box or to the amount due to the airline after the deduction of commission from the fare shown in the fare box. The precise methodology varies from BSP to BSP and with something like 17 different variations it’s impossible for us to list all the possibilities and which applies to which market.

The extra data which the agency has to show on the ticket is printed in the tour code box. However, it is not, strictly, a tour code. It is either a “Value Code” and/or a “Carrier Agreement Reference” and in Galileo they have specific entry formats which cause the items to be shown in the A21 section of the MIR (assuming you’ve switched that on using the MMOD table). The Carrier Agreement Reference is simply a contract number but the Value Code actually represents the value. The first character will always be a letter and it tells you whether the remaining characters are a commission amount or percentage and which value to apply that to or whether it’s a net fare value. The value may be expressed as numbers but it can also be encoded into letters. The precise encoding varies by market/airline but 3 examples include:

0123456789

RUNWAYJETS

BLACKHORSE

CUMBERLAND

Depending on which of the above is used 250 might be encoded as NYR or AHB or MRC.

In some implementations the amount due to the airline (the net fare) is not entered using a Value Code but a separate method (which does not print in the Tour Code box of the ticket).

So, depending on the precise method used in a market you may need to search for data in the A21 section and also the T50ITC field. The net amount due may be found in A07TBF, A21NRT or A21NVC.

Yes. There are two steps. Firstly change the flags in the MMTD display. Note that it is possible to set the system to send MIRs when a refund is processed or a void or a spoiled. If you want all 4 you must set all 4 to “Y”. Now go to the MMOD display and set “REFUND DATA” to “Y”. Note that setting REFUND DATA will cause the A23 section to be sent to your back office system. You must therefore ensure your back office is capable of processing this data.

Go to the MMOD display and set “MISCELLANEOUS DOC” to “Y”. This causes the A19 section to be sent – please ensure your back office system can process this data. Now go to the MMTD display and set “MPD” to “Y”.

Travelport+ (Galileo) answer (Travelport Apollo System is different)  - Until a filed fare is present in the Booking File all of the flights will appear in the A04 section. Once a filed fare is present in the Booking File a separate MIR is sent for each field fare. In these circumstances the flights that are covered in the filed fare appear in the A04 section and all others in the A05. The status of the flight has no affect on whether it appears in the A04 or the A05.

No. A MIR is sent for each filed fare.

This is related to the IATA practice known as “proration” and these websites give some information about the process:

• http://gnp.sourceforge.jp/

• http://www.iata.org/whatwedo/proration/index.htm

• http://www.interglobetechnologies.com/whitepapers/Managing-the-Challenges-of-Airline-Revenue-Accounting.pdf#search=%22airline%20proration%22

Proration is the term used by airlines to describe the process they undertake to share out the revenue on a ticket when more than one carrier is involved. The sharing process uses distance flown as its’ basis but then applies various other rules and even commercial agreements. It is the commercial agreements (which are confidential between the airlines) that make it impossible for us to accurately calculate the flight by flight coupon value.

No. In the airline world there are flow mileages, maximum permitted mileages and each airline uses different frequent flyer miles. All of those mileages are artificial to one degree or another. The shortest distance between two points is the “Great Circle Mileage” but there are at least 7 models of the shape of the earth each of which can produce a slightly different result. Faced with those options Galileo decided not to fill this field.

When a MIR is sent it is placed into a holding area in the Galileo system known as a buffer. In most cases it goes into the buffer and then immediately out again when it is sent to the agency. Each pseudo city has its' own buffer even though they are sending data to the same gtid. When the gtid is Down in one pseudo city

this is simply a means to stop the MIRs from being sent from that Pseudo city. The buffer feeding the gtid in another pseudo can be up. We have some customers who, rather than receiving   

all the MIRs immediately they have been issued like to set the MIR device to Down, buffer up many MIRs and then bring the device Up so that they receive all the MIRs from one branch together.      

The conjunction ticket data in the MIR is not sent the same way as it is shown in the filed fare. We send the first ticket number for each passenger and then send an indicator to say how many tickets have been issued.                                          

For instance:                                                      

338500849024990024294301000000885AD 01  N

means                                                              

33850084902 this ticket has this TCN.                              

         4 is the year when the ticket was issued                

          9900242943 is the ticket number                        

                    01 is the number of tickets issued. If this was a conjunction ticket this number would be 02 or 03 or 04 as appropriate.                                                               

The MIR will not issue until at least one passenger name has been added to the Booking File.

Yes. It is necessary to set the MMOD and MMTD screens to send MPD/MISC DOCS data.

TASF MIRs are only generated at the time of TASF creation. There is no way of sending a MIR containing TASF data using a DAD modifier. Should agents wish to send TASF data in the MIR at a later date they will have to approach their back office vendor to ascertain the correct procedure to follow. This will probably involve rekeying the data either direct to the back office system or, if a MIR is to be used in the DI.FT area of the Booking File using formats given to the agency by the back office system provider.

The general principle is that the A04 represents the flights related to the fare value in the MIR and the A05 represents any other flights. No link exists between the and the filed fare. As such, the link th exists between the filed fare and segments is broken and the system, not knowing any better, puts all the segments in A04.

The MIR is typically transmitted at the same time as the ticket/EMD. Provided the terminal making the entry TKP or EMDI is linked to both a ticket device and a MIR device both the ticket/EMD and MIR “documents” will be created from the single entry. It is also possible to send a MIR using the entries TKPDAD, TKPDND.xxx.xxx, and TKPDXD.xxx.xxx. The Galileo formats guide gives detail of these entries.