@shreesh Thank you very much again. I think that is enough to make the required programs. I will keep you posted. Regards

@maurice OR you could have a calendar for EACH room as an alternative.

@faiz Hi Faiz again thank you. Sorry to be so insistent. You are right in the frontend side. If a guest searchs for a date range its obvious he will get results for a single room available for the WHOLE range. It is his search and his problem and the algorithm is correct.

However on the backend, if you receive a phone call for searching availability, thats the way you mazimize your rooms occupation. Otherwise there would be no sense to have the tabs for patially availability and booked rooms at the bottom and at the right of the screen on the BACKEND. The system is not reporting nothing on such fields. You would always have to answer with no availabiity even if you can offer availability changing rooms in certain days and making that kind of searchs you have the chance to reallocate rooms to liberate more continuous days for another room.

How could you check what days are free for each of your rooms for maintenance, special offers or relocations?

The frontend and backend searches have to be different, or at least on the backend has to report the partial availability. Thats my point of view. Thanks again for your disposition. Best personal regards.

@maurice

Tabs on partially booked rooms doesn't shown any info in anyone.

Total booked rooms should display number of bookings in such dates

@shreesh said in iCalendars:

htl_booking_detail

Hi shreesh

To avoid a mess mixing orders/invoicing and rooms, on the same system, lets say that each system no matter the domain, will take care of the invoicing and related customer stuff or you will use a centralized customer system for all domains, so let simplify this question to be just a matter of handling the calendars coordinated between all systems and forget about orders and related stuff:

1. In such case, table htl_booking_detail has all necessary fields to create an ical file (supposing all bookings are sored there and nowhere else) to be used as export ical file to other systems. Seems that is correct. Just confirm please.

2. If you write to such table through phpmyadmin or with a normal or backend order, the booking room catalog subsystem seems to be working as it is now with the issue for which I raised a threat on Bugs in this forum "V 1.5.1.0 Manual Booking Blocks room all dates and makes it unavailable". However and because the issue is just to handle calendars and we will not be displaying or using your calendar, the main problem to coordinate calendars arises here, if we were writing to htl_booking_detail table from imported calendars:

If you make a global search, the manual input of a single booking through phpmyadmin (or program) and even a backend or frontend order, table htl_booking_detail is not considered and on results, such room appears unavailable for all searched dates in the future as stated on the bug "V 1.5.1.0 Manual Booking Blocks room all dates and makes it unavailable"

So the global search does not consider the dates for each room as per booking details on table htl_booking_detail to display the available rooms. I can not find where and what tables are considered to show results, or the search algorith would have to be changed, how and where. Search availability algorithm seems to be the problem. Your advise will be again appreciated.

Any record there is not shown on search availability result.

I dont know if the system is deleting such records in certain cases (which will be a killer) but you need a table which maintains booking from present to future and I dont find any other table taking care of that.

@shreesh Hi and Thank you very much. Sure. I will keep you posted.

@faiz Thx. I see what you say but shouldnt be that way.

1. In order to have ical funcionality in the system, you need to have only one room in each category. It is not a big deal if you run small hotels, you can have named rooms. It is one calendar per room and thats the way it works with OTA's. Thats the reason you see 1 room in "such category". One room one calendar.

2. Of course if I search for avalibility for any date in the month where I have one booking in room "A", the other rooms will appear as available, but you are blocking the availability of room "A" for the available dates besides the booking it already has.

That way I am not only missing the opportunity to book room "A". I would be telling the other systems that room "A" is not available not only on such month ... is blocked forever (until I create another room which means the same room or delete the cart or delete the dates restriction.

No matter the order status, the room (because it is defined with the blocking dates) will remain blocked and unavailable ...

3. You would have to create "another room", but doing that had to be on the checkout date of the booking you already have and thats is not possible on the backend.

If you create another room as it is, it will appear on the search as available (now you have two rooms one blocked forever no matter its booked dates and another one with all dates available (including the blocked dates which will be available).

Imagine if you have many bookings in the future...

The system seems not to be caring about this "considering you have 20 rooms on same category" ... "it doesnt matter if you block one room you have the other available" until someone delete (maybe at checkout date) the partial availability definition on the catalog for another room in such category.

Thats the point.

@maurice Above statement does not work all times, I dont know why, but if you continue without being able to log into your backend, go to config folder and on file settings.inc.php look for a _COOKIE_KEY value. It is unique for every Prestashop installation. Copy such key and go to your phpmyadmin and create a new employee on table employee. On row password put that COOKIE_KEY value FOLLOWED WITH YOUR NEW DESIRED PASSWORD and on field function put MD5 coding. Now, you will be able to enter your backend with the new user and password (the value after you put after COOKIE_KEY) that you just created. Create new and delete old employees which for some unknown reason are not working anymore. It happened to me, when making a backup of the database and restoring it inside qlo apps. Employees on restored DB were not able to log-in.

@faiz Hi. Thank you very much again. I will keep you posted.