iCal notifications in reception messages

If any of your iCal links result in a calendar conflict, you will receive a message.

iCal block conflict with identical reservation

It may happen that you receive a message that a block imported through iCal cannot be applied because there is already a reservation in that space, even though the reservation is identical.

Why does this happen?
This happens if a reservation is registered in your PMS, which is included in the exported availability through iCal to an external party. This external party blocks their own calendar accordingly, but without the domain UID. Then, availability is re-imported from the external party to your PMS, including that same block that is already in your system. This will result in a conflict.

How to handle:
If you can see the reservation is identical, ignore the message.

As standard, the external calendar should register a domain with a block to avoid this issue. If they don’t, you will have received a notification of this when setting up the link. If you then chose to go through with the iCal link, you would have needed to check the option 'accept reservations without domain'. This means you accepted that you may get notified of unnecessary conflicts.

New conflicts when importing availability for a specific object

You receive a message when iCal tries to import a block that partially overlaps an existing block/reservation in BEX PMS. When solving this problem, you have the choice between adjusting the overlap to make room for the iCal block you are trying to import, or to ignore the issue and not accept the iCal block.

Missing domain UID or missing stable UID

You may receive a message when an imported iCal feed causes issues due to a missing UID.

Why does this happen?
UIDs are indicators in the imported iCal feed.
A domain UID is an identification used to tell the reservations of multiple parties apart. If an iCal feed does not have a domain UID, this may cause conflicts when importing multiple feeds to one object.
A stable UID is an identification attached to a specific block/reservation. If this is missing, a reservation may not be imported correctly, causing conflicts.

How to avoid:
The issue here is that the other party has not included the proper UIDs for identification of blocks/reservations in your import. If this leads to a disproportionate amount of conflicts, you can choose to edit the relevant iCal channel and check the box 'Only import if it doesn't trigger any conflicts'. This way you simply do not accept any blocks/reservations that cause conflicts.

The other party specifies only dates, not times

This has no effect on importing iCal feeds, but exporting may cause issues due to our exports containing times.

'No price' error when converting a block into a reservation

When converting a block into a reservation, you may get a notification that converting is not possible because no price has been set, even though prices have been entered.

Why does this happen?
The reservation probably has a different length of stay than specified in the prices entered. For example: there is a weekend price from Friday to Monday; but the block you want to convert into a reservation is Friday to Sunday. BEX PMS cannot calculate a price because there aren’t any night prices, and therefore cannot create the reservation.

How to fix:
Temporarily create a price period that matches the block you want to convert into a reservation. In the example, this is a new length of stay price for Friday to Sunday. This will enable you to convert the block into a reservation. Afterwards, remove the price period you just created to avoid it being used anywhere else.

iCal block on a cluster object

You will receive a notification in your reception messages for every iCal block of a cluster.

Why does this happen?
Like any other object, a cluster object can be connected through iCal. However, imported blocks through iCal will not automatically apply to the underlying objects that are part of the cluster. Manual action is required.

How to fix:
Click the button in the message to convert the cluster block into a reservation. Once there is a reservation, the underlying objects of the cluster will also be blocked.