iCal notifications
While importing iCal blocks, conflicts may occur. We explain some examples below.
Accepts agreements without domain
When you import and export availability with one or more external parties, the following situation may arise if the iCal calendar imports feeds (Blocked periods) and does not split by domain.
A reservation is placed in Booking Experts, this availability is exported via the iCal to an external party. This party sets the period as blocked in the iCal calendar. Then when the system imports availability, it sees this blocked period and retrieves it. Booking Experts then gets a conflict because the period is already occupied, which is correct because it is after all the same Reservation. This is only not recognised by iCal as the same Reservation. As a Booking Experts employee, you will get a Reception message saying that there is a conflict in the import. If you open this you will see that it is the same Reservation and you can ignore the message. We just can't prevent this.
When you want to import an iCal calendar, the system assumes by default that the iCal calendar contains feeds (blocks) separating the domain. If it fails to find a domain, you get a notification on the screen. You can still use the iCal, but you must check the Accept appointments without domain option, taking the above into account.
If an iCal calendar has a separate domain, this situation will not occur because only the availability created by that domain will be retrieved.
Different parties use iCal in different ways. This leads to different problems. Some properties that an iCal feed may or may not have:
Domain UIDs:
This means we can tell the reservations of multiple parties apart. The lack of these can cause problems when importing multiple feeds to one accommodation.
Stable UIDs:
This means that the uid of one Reservation is always the same. The lack of this means reservations cannot be taken over in their own Administration. It also causes many conflicts.
Dates:
This means the feed contains dates instead of specific times. This has no effect on importing, but for a system that has dates in the iCal feed, our feed (or any other feed with dates) may not work.
An example of a situation where stable UIDs are not used:
Period 01-01 to 10-01 there is a Reservation in system A, it would normally get = UID 1.
Period 11-01 to 18-01 there is a Reservation in Booking Experts, this would normally get = UID 2.
Period 19-01 to 22-01 has the owner blocked for maintenance, this would normally get = UID 3.
The other system can then assign their own IDs to this, which means we cannot match it in the system, this causes conflicts. Also, the other system can make this, for example, 1 block = ID 4, which again creates conflicts.
You then modify something in your Reservation, it gets cancelled.
The iCal shoots this through to their system. But because the ID doesn't match, they don't delete the block but send it back. In addition, before they have processed it, ID 4 from the example of 1 long blockade may have already been reloaded.
The period is blocked again (there will be a conflict again, as none of the other IDs match 4).
Message no price when converting a block to a Reservation
When converting a block to a Reservation, you may get the message that converting is not possible because no price has been set, even though prices have been entered.
If you get this message, the Reservation probably has a different period from the prices entered. For example, if you have a weekend price from Friday to Monday and a blocking from Friday to Sunday, Booking Experts cannot calculate a price for the period and therefore cannot create the Reservation.
What you can then do is temporarily create a price period that matches the period in which the lockout was created. Then convert the blocking to a Reservation and remove the price you just created from your price list again.
Only import if no conflict
Since some parties do not include a domain in the iCal feed, this can lead to an unnecessary number of internal messages about conflicts. In the iCal link, you can now check the box if you only want to import when imports do not lead to a conflict.
iCal block on cluster type
If an iCal block comes in on a cluster type, the underlying Rentals are not automatically blocked.
You want to prevent the underlying types from being bookable if the grouped type is reserved. You do this by setting self-blocks on the underlying Rentals.
To notify you of an iCal block on a cluster type, we send a reception message. You can resolve this reception message by making a reservation for the cluster type: the reservation will also block the underlying objects.
The underlying objects are not automatically blocked via the iCal because as an organisation you want to have the option of not offering the group in a certain period but still offering the individual objects.
iCal overwrite periods not possible
Within the iCal link you can get conflicts. Sometimes, for example, you have periods that overlap. This could be because a booking has been changed (extended). In many cases, we then show the option to overwrite the periods. If you choose to overwrite the periods, the periods that overlap will be removed.
Note: You can only overwrite manually created periods. Manually created means: periods created by you as an organisation or by the owner. You cannot overwrite other iCal periods, otherwise this will be automatically re-imported via the iCal when the re-synchronises iCal.