The expiry date of the passenger's passport in the format YYYY-MM-DD
The issue date of the passenger's passport in the format YYYY-MM-DD
The number of the passport the guest will be using on the holiday.
The pax type defines which passenger type an optional supplement on a room is applicable to, e.g. Adult / 1st child means the supplement is only applicable to adults and the first child on the room booking.
Some examples of different pax types are given below:
This is a boolean value that describes whether the component or part of a component needs to be paid for locally at the resort. If true the adjustment total will not be included in the Room Total.
The total amount to be paid locally at the resort. This amount is not included in the room total.
This is a string field that forms part of the payment details on either a basket book request or a make payment request. The field can have any string value, but all values will be treated as a custom payment type except for the following three recognised payment types:
CreditCard
OFP_Deferred_Payment
CustomWithMakePayment
All other values are treated as custom payment types.
In the quote details node of the basket book request, this is the contact telephone number of the customer the quote is being emailed to. This is a string and can contain numbers, letters and characters such as a hyphen and brackets.
The town or city the guest was born in, as it appears on the passport the guest will be using.
This is the postcode or zipcode (for addresses in the USA) of the address e.g. 90211, SW1A 1AA.
This describes how the component or part of a component price will be calculated.
For example, on a flight extra (in the flight prebook response) the price basis can be either Per Booking or Per Person. The Price Basis Per Booking means the price given for the flight extra is the total price for that flight extra for the whole booking. Per Person means the price given needs to be multiplied by the number of passengers on the flight to find the total price of that flight extra for the booking.
Product attributes are attributes that can be assigned to a particular component and used as ways of searching for components that all have a particular feature. Product attributes are organised into product attribute groups.
Example
Product Attributes are organised into product attribute groups, which are defined by the client and allocated an ID when they are set up.
Some clients will not have enough Product Attributes to warrant needing to organize them into different product attribute groups. In this case only one product attribute group should be set up, and every product attribute assigned to this product attribute group.
Unique identifier for product attribute in the system.
Unique identifier for product attribute in the system.
A combination of letters and or numbers used to get a discount on a booking. This is highly configurable in the system, with validity of promotional codes based on dates, destinations, booking price, component price, brand, currency and various other criteria to specify the amount of discount a promotional code will offer and which components and or bookings for which it will be valid.
The property ID is a unique identifier in the system for each own stock property or third party property that has been imported into the system. Each record will have its own unique property ID, which can mean that the same property might be imported from different suppliers and therefore have multiple records in the database, all with unique property IDs, e.g.
This can make it difficult to identify which PropertyIDs actually refer to the same property. To solve this problem, there is a centralised property record, which allocates each unique property a single PropertyReferenceID.
In general iVectorConnect uses the PropertyReferenceID and not the PropertyID to search for and book properties.
The property reference ID is a unique identifier for a centralised record of a property in iVectorConnect. The purpose of the centralised property record is to allow the system to identify when different property records from different suppliers actually relate to the same property.
When a property is imported from a supplier, a record for that property is created and it is allocated a PropertyID. The same property may be imported several times from different suppliers, creating multiple records in the database with different PropertyIDs. It is difficult to determine through any automatic process whether properties from different suppliers are duplicates of one another and relate to the same property, as small details may differ between records (such as whether the telephone number is hyphenated). A centralised property record has been created to allow the user to create a single record for each property and match (dedupe) all property records in the database for a particular property to this centralised record.
Each centralised record has a unique identifier, the Property Reference ID. This means properties with different property IDs can be mapped to the same property reference ID, e.g.
In general iVectorConnect uses the PropertyReferenceID and not the PropertyID to search for and book properties.
Product attributes are attributes that can be assigned to a particular component and used as ways of searching for components that all have a particular feature. Product attributes are organised into product attribute groups.
Example
Product Attributes are organised into product attribute groups, which are defined by the client and allocated an ID when they are set up.
Some clients will not have enough Product Attributes to warrant needing to organize them into different product attribute groups. In this case only one product attribute group should be set up, and every product attribute assigned this product attribute group.
The property ID is a unique identifier in the system for each own stock property or third party property that has been imported into the system. Each record will have its own unique property ID, which can mean that the same property might be imported from different suppliers and therefore have multiple records in the database, all with unique property IDs, e.g.
This can make it difficult to identify which PropertyIDs actually refer to the same property. To solve this problem, there is a centralised property record, which allocates each unique property a single PropertyReferenceID.
In general iVectorConnect uses the PropertyReferenceID and not the PropertyID to search for and book properties.
The property reference ID is a unique identifier for a centralised record of a property in iVectorConnect. The purpose of the centralised property record is to allow the system to identify when different property records from different suppliers actually relate to the same property.
When a property is imported from a supplier, a record for that property is created and it is allocated a PropertyID. The same property may be imported several times from different suppliers, creating multiple records in the database with different PropertyIDs. It is difficult to determine through any automatic process whether properties from different suppliers are duplicates of one another and relate to the same property, as small details may differ between records (such as whether the telephone number is hyphenated). A centralised property record has been created to allow the user to create a single record for each property and match (dedupe) all property records in the database for a particular property to this centralised record.
Each centralised record has a unique identifier, the Property Reference ID. This means properties with different property IDs can be mapped to the same property reference ID, e.g.
In general iVectorConnect uses the PropertyReferenceID and not the PropertyID to search for and book properties.