To communicate capacity and booking information between booking/reservation systems, it's necessary that the receiving system unambiguously understands the information sent to it. This process is complicated by the fact that each reservation system is built on its own database. Each database is always unique and therefore its information may be impossible for another system to understand.
[A simple example of this would be that many tours do not have the same name in the TripAdvisor extranet as they have in TourCMS. Imagine what happens when TripAdvisor sends a booking for "City Tour Hamburg" and TourCMS has the same product listed as "Hamburg Citytour". You'll guess right if you think that such a transmission would fail.]
Now, to make unambiguous communication between systems possible, someone has to do - what we call - a mapping. You can imagine mapping as some sort of a translation process. Someone has to sit down and very carefully enter the corresponding values of system A into system B (or vice versa), so that system B is enabled to send information to system A that is recognizable.
[You can compare this situation to two people with entirely different languages trying to communicate with each other. Only if one learns the vocabulary of the other will they be able to communicate.]
When reservation systems communicate information about capacity and reservations, they need to transmit four critical components of information. We call those four components the “four pillars of mapping”. Not unlike the pillars of a house, they are essential for the stability of the communication process. Those components are: supplier, tour, departure/offer/option, and passenger rate.
I. Operator/Supplier
This is the most straightforward component to understand. It must be clear to a superordinate system who is supplying the tour. Usually, this information is coded with a supplier ID, the TourCMS account ID, or the channel ID.
II. Tour
As mentioned above, tours often have different names in different systems. The reason for this is, in most cases, different audiences; a tour name in a reseller system is often somewhat "polished", while the same tour in an operating system often is more "practical". Usually, the Tour ID or the Unique tour ID are the mapped values.
III. Option/Offer/Departure
This is usually the most problematic component in a mapping. OOD (option/offer/departure) relates to different daily offerings of a tour. Those can vary in time, quality, or both. For a better understanding, see the following examples:
TIME
| 10 AM - Morning |
| 2 PM - Afternoon |
-> use of time code
QUALITY
| 10 AM - With Sandwich | 10 AM - Without Sandwich |
-> use of product & supplier note
TIME & QUALITY
| 10 AM - With Sandwich | 10 AM - Without Sandwich |
| 2 PM - With Sandwich | 2 PM - Without Sandwich |
-> use of product & supplier note
In TourCMS those OODs are reflected by different departures. The “Time & Quality” example above would equal four daily departures for that tour. In order to clearly communicate the OOD between those systems, one must not only map the various possibilities but also which of the above strategies was used. Either that the offerings vary by time or that the product & supplier note must be used.
IV. Passenger category/rate
Passenger rates are usually relatively simple by either using standardized values (Age category such as Adult, Child, Infant) or the TourCMS rate values (such as r1, r2, r3, etc.)