Valuation

The structures previously defined can be grouped into three different types according to their usefulness: 

Availability

These structures provide information to evaluate if the booking is bookable in the requested dates. The main information in this group is inventory, stop of sales, minimum and maximum stay restrictions, etc… 

Valuation

These structures provide rules to determine the final price of the service to be booked. Prices, supplements, discounts, frees, etc… 

Additional information

These structures provide additional information needed to complete the booking process or show relevant information to the final customer. For example, promotions, cancellation fees, etc… 

The main process is divided in three steps:

  1. Check the contracts at CCON
    1. List the available rooms at CNHA
    2. List the available boards at CNSR
  2. Check the availability of the contracts
  3. Valuate and obtain the price
  4. Complete the information 

Structure

Availability

Valuation

Additional Info

[CCON] CONTRACT HEADER 

x 

x

x

[CNHA] ROOM TYPES 

x

ü

 

[CNIN] INVENTORY 

x

 

 

[CNCT] PRICES 

 

x

 

[CNSR] BOARD SUPPLEMENTS AND DISCOUNTS 

 

x

 

[CNPV] STOP SALES 

x

 

 

[CNSU] SUPPLEMENTS AND DISCOUNTS 

 

x

 

[CNGR] FREES 

 

x

 

[CNOE] COMBINABLE OFFERS 

 

x

 

[CNEM] MINIMUM AND MAXIMUM STAY 

x

 

 

[CNTA] RATE CODES 

 

 

x

[CNES] CHECK IN AND CHECK OUT 

x

 

 

[CNNH] NO HOTEL CONTRACTS 

 

 

x

[CNCF] CANCELLATION FEES 

 

 

x

[CNPR] PROMOTIONS 

 

 

x

[CNHF] HANDLING FEES 

 

 

x

Internal inventory structures summary

Availability application rules

These rules determine the available product of the contract. The availability requires a travel start and travel end dates.

[CNHA] Rooms

The structure CNHA inform about the available rooms. A single room is defined by code [CNHA.Room type] and characteristic [CNHA.Characteristic]. Every room has a number of passenger restrictions. The minimum and maximum paxes ([CNHA.Minimum pax] and [CNHA.Maximum pax]), the maximum adults ([CNHA.Maximum adults]) and children ([CNHA.Maximum child]).

The number of adults needs to be greater or equal than [CNHA.Minimum adults] and the number of infants lower or equal than [CNHA.Maximum infants].

The standard capacity [CNHA.Standard capacity] is needed in the valuation process.

[CNIN] Inventory

The inventory inform about the available dates, allotment free and release days.

The header of the structure informs two dates, the start and end date where the inventory is informed [CNIN.Initial date] and [CNIN.Final date].

For every room defined in the contract you will see the inventory information in a different section.

[CNSR] Board

In addition of the base board informed at [CCON.Base board] more boards can be supported by the contract. This information corresponds to the board supplements and discounts structure [CNSR].

[CNPV] Stop sales

The structure CNPV informs about the stop of sales in the contract. The criterion for the valid records is:

  • The initial and end date overlaps one day of the booking
  • The rate is the same or the value is null
  • The room type is the same or the value is null
  • The room characteristic is the same or the value is null
  • The board is the same or the value is null

If one of the records is valid then the booking is not possible due to stop of sales contract restriction. 

[CNEM] Minimum and maximum stay

The structure CNEM informs about the minimum and maximum days required for the service stay.

We can distinguish 2 different types:

  1. Per stay: when [CNEM.Type] value is T
  2. Per dates: when [CNEM.Type] value is E

All these items are common to both types of minimum stay (T and E) the difference is the number of days that are valid restriction of stay:

  • Minimum stay per stay (T). The total length of the stay is compared against the minimum and maximum days of stay.
  • Minimum stay per dates (E). The number of days we use to compare with the defined minimum and maximum is the number of days of stay requested that overlap with those defined in the record.

Example:

CNEM record with minimum days 5 and type T from 1st July to 31st July

Availability from 29th July to 05th August is available. The travel stay is greater than 5 days.

Example:

CNEM record with minimum days 5 and type E from 1st July to 31st July

Availability from 29th July to 05th August is not available. The minimum stay considered is only 3 days during CNEM record applicability.

The checking algorithm must be considering both types [E and T]. And for each type the process is the same:

The applicability of the record depends on:

  • The requested stay overlaps
  • The application date is valid for the booking creation day
  • The minimum stay rule includes days of operation. The record is applicable only if the days of operation are valid [the value is true] for all of the days of stay required in minimum and maximum days
  • Matches the rate requested or is generic [null]
  • Matches the requested room type or is generic [null]
  • Matches requested room characteristic or is generic [null]
  • Matches the board requested or is generic [null]

If they have the same priority in those fields (generic), the highest priority would be for the CNEM line which higher application date.

First we will review the records of specific minimum stay (rate, room, characteristic or board informed). In that case, every day affected by one or more minimum stay rules must comply with the most restrictive minimum stay. The following priority must be considered in the restriction:

  1. Rate
  2. Room
  3. Characteristic
  4. Board

Later we will review those records that are generic minimum stay, with the Rate, Characteristic, Room and Board fields empty. Day by day, we select the most restrictive one.

Every day affected by one or more minimum stay rules must comply at least one of them, or what is the same, we select the most restrictive one (which includes huge range of dates).

Application procedure:

  1. Check the rules type E in order to determine which of them to bear in mind. It must comply:
    1. There is overlapping between the range of dates in CNEM and the stay of the booking.
    2. It complies the restrictions of room, board, characteristic and rate (if they are informed).
    3. It complies the restriction of the application date.
  2. For every day in the stay
    1. Rules obtained in previous step are filtered according the days of the week indicators and the range of initial and final date.
    2. If while checking the rest of the rules there are some that are not by default (some of the fields rate, room, characteristic and board are not empty), the one with most priority should be applied (priority above). The day will be valid if it complies this rule.
    3. If all rules are by default, it is enough that the day we are checking complies one of them to consider it valid.
    4. If there is not any rule to validate, the day is valid.
  1. If all days are valid, the stay is valid too.
  2. Repeat the same process (points 1, 2 and 3) with rules type T. Stay must be valid for both types.

It is necessary the process is day by day because it is possible the same rule is not applied for all days, for example:

{CNEM}

:20150220:20150401:T:::::1:99:Y:Y:Y:Y:Y:N:N

:20150220:20150401:T:::::2:99:N:N:N:N:N:Y:Y

{/CNEM}

In this case, we would apply one or another according the day of the week.

Once we have the result of both minimum stay, the overall result will be the most restrictive. So, all the selected rules must apply in order to have the service available.

Example:

Two records at CNEM

  • Minimum stay restriction of 2 days. Operation days: Mon, Tue, Wed, Thu, Fri and Sun
  • Minimum stay restriction of 3 days. Operation days: Sat

Availability from Saturday to Sunday will not be available. The most restrictive record does not apply [the second one].
 

[CNES] Check in and check out days

This information is informed at CNES structure.

The [CNES.type] indicator informs about the application: if it is a restriction to check in or check out date.

In both cases seek applicable records, they shall fulfil the following conditions:

  • The date of check in/out is included
  • Matches the requested room or is generic
  • Matches requested characteristic or is generic
  • The application date is valid for the booking creation day

After that, we will validate the days when the contract requires checking in or checking out. Every record informs about the day of the week. This value must be true.

In the case of more than one applicable record (check in and check out) and they coincide in dates, both records should bear in mind in order the booking is valid.

When you have just one of them to allow checking in or checking out then it will be valid for booking but you should bear in mind the possible restrictions regarding operational days.

In the absence of any record, then booking is allowed.

[CNCL] Valid countries

This option is only available for clients that will work with different countries (different origin markets). Otherwise, this information will be always empty (the same for fields [CNCT.Market price], [CNSR.Market price] and [CNSU.Market price]).

A client interested in countries CA, DE, ES, UK and RU, and the default country for the client is DE, CNCL (below) indicates:

-          Contract is valid for countries AT, CH, CA, ES, UK and DE. However, as markets AT y CH have the value N (these are not defined by client in cache) they will not be calculated in the cache file. The rest of markets with value Y will have a row per room type in CNCT which informs about the prices per market for this client.

-          If the price in CNCT has no country indication you need to use this price to calculate the rest of the valid markets defined for cache for this client. In this case market CA would be calculated over this row with no market indication.

-          Contract is valid for countries AT and CH, but the prices for those countries will not be calculated during the generation of the AIF file (cache file will be generated depending on the countries configured).

-          Only if it appears in CNCL means the country is valid, otherwise it is not valid (If the market does NOT appear in CNCL, then the market is not valid for this contract.)

{CNCT}
20150225:20150430:DBT:ST::ES:(Y,0.000,0.000,3,HB,37.920)(Y,0.000,0.000,3,HB,37.920)...
20150225:20150430:DBT:ST::UK:(Y,0.000,0.000,3,HB,38.920)(Y,0.000,0.000,3,HB,38.920)...
20150225:20150430:DBT:ST::DE:(Y,0.000,0.000,3,HB,39.920)(Y,0.000,0.000,3,HB,39.920)...

20150225:20150430:DBT:ST:::(Y,0.000,0.000,3,HB,39.920)(Y,0.000,0.000,3,HB,39.920)...

{/CNCT}
[…]
{CNCL}
DE:Y
ES:Y
UK:Y

CA:Y
AT:N
CH:N
{/CNCL}

Valuation rules and process

Once we have checked the availability of the service for the requested dates, then you can calculate the price.

The service and all the information you need in order to get the price are:

  • Travel start date
  • Travel end date
  • Room type
  • Room characteristic
  • Board or meal plan
  • Occupancy information
  • Rate [if the contract has fixed rate [CCON.Fix rate] is true]

The valuation process is composed by:

  1. Calculate the base price
  2. Calculate the board supplement and discount
  3. Calculate the occupancy supplements and discounts
  • Child
  • Additional bed
  • Individual use
  1. Calculate the general supplements and discounts
  2. Calculate the frees
  3. Check the combinable supplements and discounts
  4. Calculate the handling fees

Docs Navigation