[oneBooking] Посуточная система бронирования
Это дополнение для сбора заявок по бронированию объектов (например, номеров, автомобилей и т.д.). Представляет собой календарь с возможностью выделения периода бронирования. Минимальный период бронирования — 1 день. Система контролирует количество свободных объектов в указанном периоде, поэтому забронировать его не получится, если хотя бы в какой-нибудь день из выбранного периода таких свободных объектов нет.
Вызывается сниппетом obCalendar. В параметрах можно указать месяц и год для первоначального вызова.
Работать с ним просто. Выделяем период и в появившемся окне указываем необходимые данные.
Если все ОК, то пользователю на указанный email отправиться уведомление с введенными данными. Более подробная копия отправится администратору сайта.
Системные настройки
У компонента есть 2 настройки:
— обязательные поля для заполнения пользователями. По-умолчанию, object,start_date,fullname,email,phone. Думаю, без перевода понятно. Если дата выезда пустая, то она приравнивается к дате въезда. Поэтому указывать ее не обязательно.
— выключатель уведомления администратора.
Административная часть состоит из 2-х вкладок.
Первая — это список забронированных объектов. Истекшая бронь не отображается. Чтобы ее увидеть, нужно включить чекбокс «Показать все».
Бронь можно редактировать и удалять.
Вторая вкладка — это список объектов. Перед началом работы необходимо заполнить этот справочник, чтобы пользователю было что выбирать.
Классы календаря
У ячейки может быть несколько классов:
— класс рабочего дня. Указывается через параметр сниппета. По-умолчанию «ob-weekday».
— класс выходного дня. Указывается через параметр сниппета. По-умолчанию «ob-weekend».
— available. Указывается, если есть хотя бы один свободный объект.
— notavailable. Указывается, если нет ни одного свободного объектаа.
— cell-special. Указывается, если есть спец. предложения.
У каждого элемента календаря (шапка, строка, ячейка) есть шаблоны.
Таким образом, возможностей для кастомизации вполне достаточно.
Важно! По-умолчанию, система настроена на бронирование номеров. Чтобы изменить на что-то другое, нужно просто поправить соответствующие записи в лексиконе.
Жду пожеланий и замечаний.
oneBooking. Версия 2.
oneBooking. Версия 3. Интеграция с минишоп для онлайн оплаты.
oneBooking. Версия 3.1.0.
Вызывается сниппетом obCalendar. В параметрах можно указать месяц и год для первоначального вызова.
[[!obCalendar? &month=`1` &year=`2016`]]
Если эти параметры не указаны, то выводится текущий месяц.Работать с ним просто. Выделяем период и в появившемся окне указываем необходимые данные.
Если все ОК, то пользователю на указанный email отправиться уведомление с введенными данными. Более подробная копия отправится администратору сайта.
Системные настройки
У компонента есть 2 настройки:
— обязательные поля для заполнения пользователями. По-умолчанию, object,start_date,fullname,email,phone. Думаю, без перевода понятно. Если дата выезда пустая, то она приравнивается к дате въезда. Поэтому указывать ее не обязательно.
— выключатель уведомления администратора.
Административная часть состоит из 2-х вкладок.
Первая — это список забронированных объектов. Истекшая бронь не отображается. Чтобы ее увидеть, нужно включить чекбокс «Показать все».
Бронь можно редактировать и удалять.
Вторая вкладка — это список объектов. Перед началом работы необходимо заполнить этот справочник, чтобы пользователю было что выбирать.
Классы календаря
У ячейки может быть несколько классов:
— класс рабочего дня. Указывается через параметр сниппета. По-умолчанию «ob-weekday».
— класс выходного дня. Указывается через параметр сниппета. По-умолчанию «ob-weekend».
— available. Указывается, если есть хотя бы один свободный объект.
— notavailable. Указывается, если нет ни одного свободного объектаа.
— cell-special. Указывается, если есть спец. предложения.
У каждого элемента календаря (шапка, строка, ячейка) есть шаблоны.
Таким образом, возможностей для кастомизации вполне достаточно.
Важно! По-умолчанию, система настроена на бронирование номеров. Чтобы изменить на что-то другое, нужно просто поправить соответствующие записи в лексиконе.
$_lang['onebooking_tab2'] = 'Номера';
$_lang['ob.object'] = 'Номер';
и т.д.
Жду пожеланий и замечаний.
Дополнительные материалы
Подробная документация.oneBooking. Версия 2.
oneBooking. Версия 3. Интеграция с минишоп для онлайн оплаты.
oneBooking. Версия 3.1.0.
Поблагодарить автора
Отправить деньги
Комментарии: 83
круто блин!
Наверное было бы здорово еще уметь бронировать номер, находясь на странице этого номера. Например админ набил список ресурсов — каждый представляет собой страницу с подробным описанием номера с фотками. И с этой страницы пользователь мог бы забронировать его на какой-либо срок. Наверное что-то вроде такого же календаря, только с указанием занятости только одного номера. Думаю пригодится:)
Наверное было бы здорово еще уметь бронировать номер, находясь на странице этого номера. Например админ набил список ресурсов — каждый представляет собой страницу с подробным описанием номера с фотками. И с этой страницы пользователь мог бы забронировать его на какой-либо срок. Наверное что-то вроде такого же календаря, только с указанием занятости только одного номера. Думаю пригодится:)
Хорошая мысль. Сделаем.
Сергей, спасибо за компонент! Круто!
Дмитрий, вы же еще не пробовали :)
Для меня сам факт его появления — уже радость. А то, что он допилится и станет лучше — лучшего даже не сомневаюсь :)
И я не сомневаюсь. :)
это ж можно хоть для бронирования столиков в ресторанах или кафе использовать) кучу всего можно бронировать)
Думаю, что не очень подходит. Столики — это почасовое бронирование, а тут минимальный период — 1 день.
ну да, точно… не подумал. а вот еще вопрос: при редактировании/удалении брони администратором, письмо клиенту высылается с соответствующим сообщением?
Нет. Не до конца понимаю как это должно выглядеть. Т.е. админ изменил бронь, а пользователю идет письмо — «Вы бронировали номер на июль, а мы перенесли ее на январь»? Может быть админу запретить изменять бронь.
При удалении наверно нужно написать чего-то.
П.С. Услышать бы мнение знающих тему.
При удалении наверно нужно написать чего-то.
П.С. Услышать бы мнение знающих тему.
ну например возможна такая ситуация: в заказаном номере произошла поломка и человека нужно переселить. Админ связывается с пользователем, а затем через админку меняет номер для заселения. Или например, просто меняет номер для заселения (когда не смог связаться с пользователем). И тогда уведомление на почту было бы кстати… При этом, думаю, было бы удобно, что бы было еще одно поле, в которое админ мог писать комментарии, например, «Извините, не смогли с вами связаться. В вашем номере поломка, и мы заменили его на аналогичный. Приносим извинения!»
А менять дату заселения, наверное, стоит запретить)
А менять дату заселения, наверное, стоит запретить)
Согласен.
А менять дату заселения наверное стоит запретитьТут непростой вопрос. А если он созвонился с пользователем и тот решил изменить дату.
Ну да, тогда лучше полный доступ к редактированию…
И еще, вот скажем, хостелы… Там есть номера, в которые могут заселяться сразу несколько человек. Может быть к номеру добавить опцию типа «Разрешить заселение разных пользователей» и «Количество мест в номере»? А для посетителя эти номера бы помечались особым образом и был бы виден остаток койко-мест.
И тогда для сайта хостела это был бы просто шикарный компонент:)
И еще, вот скажем, хостелы… Там есть номера, в которые могут заселяться сразу несколько человек. Может быть к номеру добавить опцию типа «Разрешить заселение разных пользователей» и «Количество мест в номере»? А для посетителя эти номера бы помечались особым образом и был бы виден остаток койко-мест.
И тогда для сайта хостела это был бы просто шикарный компонент:)
Да, накидал ты мне работы :)
Будем думать.
Будем думать.
ты сам про пожелания написал :)
Я же ж не против. :)
Вот с заселением разных пользователей сложновато. Ведь бронируются не сами номера (комнаты), а типы номеров (однокомнатные, люксы и т.п.). Не вываливать же пользователю все комнаты с номерами. Это такая простыня получится. А у хостела нужно знать занятость именно конкретной комнаты.
Но функционал нужный. Так что будем думать.
Вот с заселением разных пользователей сложновато. Ведь бронируются не сами номера (комнаты), а типы номеров (однокомнатные, люксы и т.п.). Не вываливать же пользователю все комнаты с номерами. Это такая простыня получится. А у хостела нужно знать занятость именно конкретной комнаты.
Но функционал нужный. Так что будем думать.
Когда-то я изучал вопросы бронирования номеров. Основное, что вспомнилось:
1. Возможность бронирования 1-2-3 номеров одновременно. В частности, каждому номеру указывается вместимость, а при поиске пользователь указывает количество заезжающих. Ищутся номера сразу для всех заезжающих. У номеров бывают дополнительные платные места. Часто один ребенок до 7 лет без отдельного места живет бесплатно., Это все тоже желательно учитывать.
2. В случае форс-мажоров, о которых писал Андрей, полезна возможность разбиения брони на периоды для частичного переноса в другой номер.
3. Статусы броней как в минишопе с возможностью указания необходимости рассылки писем при изменении статусов. Таким образом, внутренние изменения гостю будут неизвестны, но по существенным он получит письма.
4. Изменение дат необходимо как менеджером, так и гостем.
5. Аннулирование брони — тоже доступно обоим, но только в виде статуса. Физически удалять не нужно, ибо тогда теряется контроль отмен.
6. Ценовые периоды. Белые ночи, Новый год, майские праздники и т.д. — это все разные цены. Должна быть возможность создания различных периодов и проставления цены каждого номера для каждого периода. Примеры периодов: 30.12-11.01, 12.01-29.04, 30.04-12.05, 13.05-15.06, 16.06-15.07 и т.д.
7. Помимо периодов, цены могут быть разными в зависимости от дня недели — будни дешевле выходных. Наценка в виде процента или фиксированная надбавка.
8. Желательно это все связать с минишопом для онлайн-оплаты. Востребованная функция в последнее время.
Явно еще что-то забыл…
1. Возможность бронирования 1-2-3 номеров одновременно. В частности, каждому номеру указывается вместимость, а при поиске пользователь указывает количество заезжающих. Ищутся номера сразу для всех заезжающих. У номеров бывают дополнительные платные места. Часто один ребенок до 7 лет без отдельного места живет бесплатно., Это все тоже желательно учитывать.
2. В случае форс-мажоров, о которых писал Андрей, полезна возможность разбиения брони на периоды для частичного переноса в другой номер.
3. Статусы броней как в минишопе с возможностью указания необходимости рассылки писем при изменении статусов. Таким образом, внутренние изменения гостю будут неизвестны, но по существенным он получит письма.
4. Изменение дат необходимо как менеджером, так и гостем.
5. Аннулирование брони — тоже доступно обоим, но только в виде статуса. Физически удалять не нужно, ибо тогда теряется контроль отмен.
6. Ценовые периоды. Белые ночи, Новый год, майские праздники и т.д. — это все разные цены. Должна быть возможность создания различных периодов и проставления цены каждого номера для каждого периода. Примеры периодов: 30.12-11.01, 12.01-29.04, 30.04-12.05, 13.05-15.06, 16.06-15.07 и т.д.
7. Помимо периодов, цены могут быть разными в зависимости от дня недели — будни дешевле выходных. Наценка в виде процента или фиксированная надбавка.
8. Желательно это все связать с минишопом для онлайн-оплаты. Востребованная функция в последнее время.
Явно еще что-то забыл…
Спасибо за подробную информацию.
По пунктам 1,2,3 буду думать.
По пунктам 4 и 5. Чтобы гость имел право изменять или аннулировать бронь, он должен быть зарегистрированным пользователем, а значит иметь личный кабинет… со всеми вытекающими.
По пунктам 1,2,3 буду думать.
По пунктам 4 и 5. Чтобы гость имел право изменять или аннулировать бронь, он должен быть зарегистрированным пользователем, а значит иметь личный кабинет… со всеми вытекающими.
6. Ценовые периоды.Реализованы.
7. Помимо периодов, цены могут быть разными в зависимости от дня недели — будни дешевле выходных. Наценка в виде процента или фиксированная надбавка.Все таки это система сбора заявок на бронирование. Наверное, такой функционал излишен. Пользователь видит все это на страничке номера. А расчеты ведутся в бухгалтерии.
8. Желательно это все связать с минишопом для онлайн-оплаты. Востребованная функция в последнее время.То же самое. Для системы сбора заявок может быть и не нужно. Но вещь полезная. Повод изучить minishop.
4, 5, 7, 8 — это все логичное развитие компонента. Поэтому стоит заранее закладывать такую степень масштабируемости, чтобы не изобретать потом костыли или писать заново.
Что касается расчетов и бухгалтерии — не будьте столь категоричными. Простая ситуация — гость смотрит на сайте цены, бронирует и, чтобы не ждать, хочет сразу оплатить. Если в компоненте не будет реализована гибкая логика расчета цены, мгновенная оплата будет невозможна.
А теперь о применении — в простом варианте это, согласен, только система сбора заявок. Но при развитии компонент сможет стать не только полноценным сервисом бронирований для отелей/хостелов/гостиниц, но и платформой для создания на базе MODX агрегаторов бронирований для нескольких гостиниц. Более того, следующей ступенью (достаточно легко реализуемой) станет расчет комиссий для таких сервисов.
Но это я уже далеко смотрю. Можно будет сделать 2 версии — бронирование для одной гостиницы / сети гостиниц, когда все гостиницы принадлежат одному владельцу, и вторую версию — с комиссиями агентов и расширенными возможностями.
Еще одно направление — почасовое бронирование. Прием врача, игры и многое другое — сфера применения обширна, а базовая часть кода очень сильно будет совпадать с посуточным бронированием.
Сергей, Вы очень интересное направление взяли в работу. Уверен, что при реализации хотя бы половины описанного, компонент будет очень востребован. Причем, 1500 руб. за него будет абсолютно адекватной ценой. Или даже больше.
Что касается расчетов и бухгалтерии — не будьте столь категоричными. Простая ситуация — гость смотрит на сайте цены, бронирует и, чтобы не ждать, хочет сразу оплатить. Если в компоненте не будет реализована гибкая логика расчета цены, мгновенная оплата будет невозможна.
А теперь о применении — в простом варианте это, согласен, только система сбора заявок. Но при развитии компонент сможет стать не только полноценным сервисом бронирований для отелей/хостелов/гостиниц, но и платформой для создания на базе MODX агрегаторов бронирований для нескольких гостиниц. Более того, следующей ступенью (достаточно легко реализуемой) станет расчет комиссий для таких сервисов.
Но это я уже далеко смотрю. Можно будет сделать 2 версии — бронирование для одной гостиницы / сети гостиниц, когда все гостиницы принадлежат одному владельцу, и вторую версию — с комиссиями агентов и расширенными возможностями.
Еще одно направление — почасовое бронирование. Прием врача, игры и многое другое — сфера применения обширна, а базовая часть кода очень сильно будет совпадать с посуточным бронированием.
Сергей, Вы очень интересное направление взяли в работу. Уверен, что при реализации хотя бы половины описанного, компонент будет очень востребован. Причем, 1500 руб. за него будет абсолютно адекватной ценой. Или даже больше.
Абсолютно согласен. Сейчас очень востребовано именно почасовое (и даже меньше) бронирование. Лично готов больше 1 500 платить )).
Чтобы сделать такой сервис нужно как минимум быть в теме. Сложно сделать хорошее приложение не зная тему изнутри. Поэтому я и сделал просто систему сбора заявок.
Ваши предложения тянут на новое дополнение. Так как в текущую информационную модель эти предложения уже не вписываются.
По поводу пункта 4,5 я уже писал. Не совсем непонятно как это реализовать. Так как управлять своей бронью может только зарегистрированный пользователь, а у него должен быть личный кабинет. И вот тут вопрос — на сайте уже есть личный кабинет пользователя? Или делать свой? А если есть, как их сопрягать?
По остальному очень интересные предложения. Их просто обдумывать нужно не один день.
А по поводу агрегаторов даже страшно и подумать. :)
П.С. Кстати, в сети есть предложения и с почасовым бронированием. Платные конечно.
Ваши предложения тянут на новое дополнение. Так как в текущую информационную модель эти предложения уже не вписываются.
По поводу пункта 4,5 я уже писал. Не совсем непонятно как это реализовать. Так как управлять своей бронью может только зарегистрированный пользователь, а у него должен быть личный кабинет. И вот тут вопрос — на сайте уже есть личный кабинет пользователя? Или делать свой? А если есть, как их сопрягать?
По остальному очень интересные предложения. Их просто обдумывать нужно не один день.
А по поводу агрегаторов даже страшно и подумать. :)
П.С. Кстати, в сети есть предложения и с почасовым бронированием. Платные конечно.
4, 5 со стороны гостя требует Office — это нормально. Но со стороны менеджера Office не нужен.
Получается, что если предполагается самостоятельная отмена/изменение брони, то Office докупить будет дешевле, чем дорабатывать что-то дополнительное.
Или же в компоненте бронирования пара простых сниппетов для вывода списка броней заданного пользователя и выполнения действий с ними. Без реализации полноценного ЛК со всеми наворотами.
Что же до менеджера — он все равно работает со страницей в админке. Здесь функционал изменения и отмены Вы можете реализовать без лишних усилий. А после этого и сниппеты для гостей станут очень легкими в создании :)
Кстати, еще одно предложение — добавить права доступа отдельно для работы с бронями и отдельно для настройки/изменения параметров.
Рядовым администраторам в гостиницах не всегда можно давать возможность изменения цен/описаний/перечня услуг.
В целом, согласен с Вашей мыслью о необходимости быть «в теме». НО! Вы уже взялись за календари и бронирование. Так продолжайте :)
Чтобы изучить бронирования с нюансами, обратитесь в гостиницу и предложите им взаимовыгодное сотрудничество — они помогают выработать ТЗ и оттестировать новый функционал, а Вы по итогу работы предоставляете им полностью рабочий инструмент бронирований с их сайта.
Еще момент, почему гостиницы заинтересуются — многие на своем сайте размещают форму онлайн-бронирования для удобства гостей. Но операторам этих форм платят 2-5%. За несколько месяцев сумма может набежать значительно больше, чем стоимость компонента и работ по его установке.
Получается, что если предполагается самостоятельная отмена/изменение брони, то Office докупить будет дешевле, чем дорабатывать что-то дополнительное.
Или же в компоненте бронирования пара простых сниппетов для вывода списка броней заданного пользователя и выполнения действий с ними. Без реализации полноценного ЛК со всеми наворотами.
Что же до менеджера — он все равно работает со страницей в админке. Здесь функционал изменения и отмены Вы можете реализовать без лишних усилий. А после этого и сниппеты для гостей станут очень легкими в создании :)
Кстати, еще одно предложение — добавить права доступа отдельно для работы с бронями и отдельно для настройки/изменения параметров.
Рядовым администраторам в гостиницах не всегда можно давать возможность изменения цен/описаний/перечня услуг.
В целом, согласен с Вашей мыслью о необходимости быть «в теме». НО! Вы уже взялись за календари и бронирование. Так продолжайте :)
Чтобы изучить бронирования с нюансами, обратитесь в гостиницу и предложите им взаимовыгодное сотрудничество — они помогают выработать ТЗ и оттестировать новый функционал, а Вы по итогу работы предоставляете им полностью рабочий инструмент бронирований с их сайта.
Еще момент, почему гостиницы заинтересуются — многие на своем сайте размещают форму онлайн-бронирования для удобства гостей. Но операторам этих форм платят 2-5%. За несколько месяцев сумма может набежать значительно больше, чем стоимость компонента и работ по его установке.
Рядовым администраторам в гостиницах не всегда можно давать возможность изменения цен/описаний/перечня услуг.Мне кажется рядовым администраторам вообще не нужно давать доступ в админку. Им, наверно, нужно во фронте интерфейс сделать. Я вообще сторонник фронт-энда. Работать в админке можно только с крепкими нервами — слишком тяжелый интерфейс с кучей запросов. Плюс, с правами заморочки, с формами.
Чтобы изучить бронирования с нюансами, обратитесь в гостиницу и предложите им взаимовыгодное сотрудничество — они помогают выработать ТЗ и оттестировать новый функционал, а Вы по итогу работы предоставляете им полностью рабочий инструмент бронирований с их сайта.Это нужно искать гостиницы с сайтами на MODX. То же и для форм онлайн-бронирования. Они платформо-независимы. Поэтому, думаю, не каждая гостиница заинтересуется моим дополнением. Ведь тогда придется переделывать сайт. А это гораздо больше, чем 2-5%. Более вероятно, что они наймут программиста и попросят сделать по аналогии.
Мне кажется рядовым администраторам вообще не нужно давать доступ в админку. Им, наверно, нужно во фронте интерфейс сделать. Я вообще сторонник фронт-энда. Работать в админке можно только с крепкими нервами — слишком тяжелый интерфейс с кучей запросов. Плюс, с правами заморочки, с формами.Согласен.
Но сделать такой интерфейс не так уж сложно.
Это нужно искать гостиницы с сайтами на MODX. То же и для форм онлайн-бронирования. Они платформо-независимы. Поэтому, думаю, не каждая гостиница заинтересуется моим дополнением. Ведь тогда придется переделывать сайт.Знаю одну гостиницу, у которой сайт на Revo с момента выхода системы в 2010 году, и еще одну, которой сейчас создают на ней сайт с нуля.
При наличии у Вас интереса, могу связать с ними для обсуждения возможного сотрудничества.
Но сделать такой интерфейс не так уж сложно.Нет. Я об этом и говорю.
Знаю одну гостиницу, у которой сайт на Revo с момента выхода системы в 2010 году, и еще одну, которой сейчас создают на ней сайт с нуля.Михаил, большое спасибо за предложение. В самое ближайшее время пока не планирую новую разработку. Очень много других дел. А это уже очень сложная система получается. Нужно много свободного времени. Лучше дайте им ссылку на эту тему.
При наличии у Вас интереса, могу связать с ними для обсуждения возможного сотрудничества
Михаил, вопрос по онлайн-оплате. Вы вроде как в теме.
Я правильно понимаю, что при использовании miniShop там будет всего один товар — бронь? В связи с чем вопрос — целесообразно ли заставлять пользователя (например, отели) устанавливать такой мощный магазин ради одного товара?
Я правильно понимаю, что при использовании miniShop там будет всего один товар — бронь? В связи с чем вопрос — целесообразно ли заставлять пользователя (например, отели) устанавливать такой мощный магазин ради одного товара?
Сергей, все правильно — товар один, опции разные. Можно несколько товаров — по количеству типов номеров. Но это уже нюансы.
Смысл есть. Во-первых, Ваш компонент не надо будет раздувать, так как в минишопе очень много нужного функционала готово.
Плюс к тому, уже есть много дополнений для онлайн-оплаты. Зачем изобретать велосипед?
Для обычного сайта гостиницы наличие или отсутствие минишопа никак не скажется, а вот на компоненте бронирования его наличие отразится исключительно положительно.
Не забывайте еще вот о чем: все доп.услуги, которые гость заказывает к номеру, можно сделать отдельными товарами тогда значительно упростится процесс формирования брони и последующего учета этих услуг.
Смысл есть. Во-первых, Ваш компонент не надо будет раздувать, так как в минишопе очень много нужного функционала готово.
Плюс к тому, уже есть много дополнений для онлайн-оплаты. Зачем изобретать велосипед?
Для обычного сайта гостиницы наличие или отсутствие минишопа никак не скажется, а вот на компоненте бронирования его наличие отразится исключительно положительно.
Не забывайте еще вот о чем: все доп.услуги, которые гость заказывает к номеру, можно сделать отдельными товарами тогда значительно упростится процесс формирования брони и последующего учета этих услуг.
Понял. Спасибо.
Еще один аргумент: как думаете, что выберут клиенты — oneBooking за 990 р. + свободный minishop2 или только oneBooking, но за 2990 р.?
oneBooking всегда 990 руб.
Выбор будет между oneBooking с одним, двумя методами оплаты или oneBooking + miniShop2 с большим набором дополнений к нему.
Выбор будет между oneBooking с одним, двумя методами оплаты или oneBooking + miniShop2 с большим набором дополнений к нему.
Сергей, я немного не о том, не предлагаю сделать 2 версии с разной стоимостью. Если делать мощный компонент без привязки к minishop2, то получится огромный объем работ. Но компонент коммерческий, поэтому такой объем тоже должен оплачиваться. Соответственно, может вырасти цена. Либо же добавить к oneBooking привязку к магазину и использовать всю его мощь, оставив стоимость на прежнем уровне.
Вариант, который Вы сейчас озвучили весьма интересен. Из коробки — простое бронирование с малым количеством способов оплаты. При необходимости наращивания возможностей — всего лишь добавить minishop2 к уже настроенному бронированию.
Отличный и правильный путь!
Хотя, лично я, сразу бы делал с максимальной привязкой. На мой взгляд, не всегда нужно предоставлять большую свободу выбора пользователю. Иногда именно из-за этого появляется слишком много лишних вопросов.
Вариант, который Вы сейчас озвучили весьма интересен. Из коробки — простое бронирование с малым количеством способов оплаты. При необходимости наращивания возможностей — всего лишь добавить minishop2 к уже настроенному бронированию.
Отличный и правильный путь!
Хотя, лично я, сразу бы делал с максимальной привязкой. На мой взгляд, не всегда нужно предоставлять большую свободу выбора пользователю. Иногда именно из-за этого появляется слишком много лишних вопросов.
Мне тоже больше нравится вариант с minishop. Работы меньше, а возможностей больше. Просто интересно мнение с той стороны, т.е. пользователей. Поэтому к вам и обратился.
Уже достаю minishop из коробки. Но боюсь, за выходные вряд ли сумею найти место, куда вставляются батарейки.
Уже достаю minishop из коробки. Но боюсь, за выходные вряд ли сумею найти место, куда вставляются батарейки.
Мой скайп: whiteflag.ru
Постучитесь — помогу, чем смогу. Это будет быстрее и проще, чем здесь продолжать.
Постучитесь — помогу, чем смогу. Это будет быстрее и проще, чем здесь продолжать.
Спасибо, Михаил. Обязательно воспользуюсь вашим предложением.
Каждый объект — отдельный ресурс.
Номер:
— объекту присваивается уникальный номер
Категория:
— объекту присваивается своя категория (кровать, номер, квартира, дом и т.д)
Количество проживающих:
— Указываем количество спальных мест (п.2 Стоимости).
Календарь:
— День разделить на 2 части: «до 12.00» (выселение) и «после 12.00» (расселение), так как общепринятое расчетное время 12.00.
— Стоимость аренды (проживания) указывается на каждую дату
— День заселения и выселения маркировать половинным «зачеркиванием», при совпадении — «зачеркивать» полностью
— Возможность маркировки сразу диапазона дат
Стоимость:
— Меняется в зависимости от выбранных дат (п.2 Календаря), т.е есть возможность добавлять поля «дата-стоимость»
— Меняется в зависимости от количества проживающих (для хостелов)
— Указывается за номер либо спальное место
— Автоматически переносится на следующий год с возможностью редактирования.
— Возможность увеличить на указанный процент (процентная надбавка) — очень важно!
— Возможность снизить на указанный процент (дисконт)
Оплата:
Выбор способа оплаты:
— заявка оплачивается после подтверждения брони
— заявка оплачивается сразу (онлайн-бронирование).
Желательна интеграция с уже разработанными компонентами (https://modstore.pro/packages/payment-system/)
Форма заявки:
— Заявки на бронирование отправляются только через форму размещенную на странице ресурса.
Форма заявки «обрабатывает»
— данные календаря (не дает бронировать занятые даты)
— рассчитывает стоимость в зависимости от указанного количества проживающих (п. 3 Стоимости) и срока аренды
Поиск — самое главное!
Данный компонент необходимо интегрировать с msearch2 (https://modstore.pro/packages/ecommerce/msearch2) — возможность поиска объектов по уникальному номеру, категориям, датам заезда-выезда, стоимости, количеству спальных мест.
Это минимальные пожелания… Суточной арендой квартир занимался 5 лет, есть работающий сайт, могу в личку скинуть доступы
Номер:
— объекту присваивается уникальный номер
Категория:
— объекту присваивается своя категория (кровать, номер, квартира, дом и т.д)
Количество проживающих:
— Указываем количество спальных мест (п.2 Стоимости).
Календарь:
— День разделить на 2 части: «до 12.00» (выселение) и «после 12.00» (расселение), так как общепринятое расчетное время 12.00.
— Стоимость аренды (проживания) указывается на каждую дату
— День заселения и выселения маркировать половинным «зачеркиванием», при совпадении — «зачеркивать» полностью
— Возможность маркировки сразу диапазона дат
Стоимость:
— Меняется в зависимости от выбранных дат (п.2 Календаря), т.е есть возможность добавлять поля «дата-стоимость»
— Меняется в зависимости от количества проживающих (для хостелов)
— Указывается за номер либо спальное место
— Автоматически переносится на следующий год с возможностью редактирования.
— Возможность увеличить на указанный процент (процентная надбавка) — очень важно!
— Возможность снизить на указанный процент (дисконт)
Оплата:
Выбор способа оплаты:
— заявка оплачивается после подтверждения брони
— заявка оплачивается сразу (онлайн-бронирование).
Желательна интеграция с уже разработанными компонентами (https://modstore.pro/packages/payment-system/)
Форма заявки:
— Заявки на бронирование отправляются только через форму размещенную на странице ресурса.
Форма заявки «обрабатывает»
— данные календаря (не дает бронировать занятые даты)
— рассчитывает стоимость в зависимости от указанного количества проживающих (п. 3 Стоимости) и срока аренды
Поиск — самое главное!
Данный компонент необходимо интегрировать с msearch2 (https://modstore.pro/packages/ecommerce/msearch2) — возможность поиска объектов по уникальному номеру, категориям, датам заезда-выезда, стоимости, количеству спальных мест.
Это минимальные пожелания… Суточной арендой квартир занимался 5 лет, есть работающий сайт, могу в личку скинуть доступы
Игорь, спасибо! Я так понимаю, это кусок готового ТЗ.
есть работающий сайт, могу в личку скинуть доступыБыло бы интересно в живую пощупать. Моя почта sergant210@bk.ru.
Отправил!
Поймал. Спасибо.
Ничего себе компонент. Поздравляю, круто!
Спасибо.
Тут ребята предлагают замахнуться сразу на «Шекспира»… с блэкджеком и кончитами. :)
Тут ребята предлагают замахнуться сразу на «Шекспира»… с блэкджеком и кончитами. :)
Было бы круто интегрировать это дело с минишопом, тогда все компоненты написанные под магазин, работали бы и с этой системой.
Вопрос: есть ли возможность указать несколько скидочных периодов?
Т.е. сейчас стоит задача построить сайт, где будет 3 сезона: высокий, средний, низкий. У каждого своя цена за сутки.
Вопрос: есть ли возможность указать несколько скидочных периодов?
Т.е. сейчас стоит задача построить сайт, где будет 3 сезона: высокий, средний, низкий. У каждого своя цена за сутки.
Я с минишопом пока не знаком. В планах разобраться и если получится, прикручу. А вот с остальным — это уже только в новом компоненте — с почасовым бронированием, сезонами, правами, интерфейсами для администраторов во фронтэнде.
В данном случае, если сезоны идут последовательно, то их можно указывать последовательно — новый сезон выставлять по окончании старого.
В данном случае, если сезоны идут последовательно, то их можно указывать последовательно — новый сезон выставлять по окончании старого.
Не совсем понял с последовательным выставлением сезонов.
Просто забронировать квартиру могу то в период на стыке двух сезонов. Т.е. 2 дня в одном и 3 дня во втором, к примеру. И цену необходимо будет посчитать по ценам двух сезонов :)
Просто забронировать квартиру могу то в период на стыке двух сезонов. Т.е. 2 дня в одном и 3 дня во втором, к примеру. И цену необходимо будет посчитать по ценам двух сезонов :)
2 сезона потянет (вернее две разных цены), а вот больше нет.
Например, берем 2 сезона по месяцам — июнь и июль.
У нас есть 2 цены — текущая и специальная. Текущая действует в июне, а спец. цена начинает действовать в июле. В августе опять начинает действовать текущая цена (третью цену определить нельзя). Тогда все посчитается правильно и на стыках и так. А если в августе нужна другая спец. цена, то надо ждать когда июнь кончится, тогда и определить цену августа. Только так.
Например, берем 2 сезона по месяцам — июнь и июль.
У нас есть 2 цены — текущая и специальная. Текущая действует в июне, а спец. цена начинает действовать в июле. В августе опять начинает действовать текущая цена (третью цену определить нельзя). Тогда все посчитается правильно и на стыках и так. А если в августе нужна другая спец. цена, то надо ждать когда июнь кончится, тогда и определить цену августа. Только так.
Добрый день Нужна система бронирования услуги. например время массажа. Он может идти несколько часов, можно ли допилить модуль чтобы по часам бронь выставлять?
Все-таки вам нужна система онлайн записи. Это своя специфика — более строгое подтверждение записи, смс уведомления, бронирование услуги с привязкой мастера, другие интерфейсы.
А есть ли природе готовый модуль для онлайн записи?
То мне не ведомо.
Здравствуйте!
Можно ли использовать дополнение для бронирования номеров в небольшой сети домашних гостиницы (частные дома, квартиры)? Там каждый объект может иметь от 1 до 3 номеров и описывается отдельно.
Можно ли использовать дополнение для бронирования номеров в небольшой сети домашних гостиницы (частные дома, квартиры)? Там каждый объект может иметь от 1 до 3 номеров и описывается отдельно.
На данный момент разделения по гостиницам нет. Список номеров общий — или в описании указывать где находится или в названии объекта. Пока только так. На сайте разделить их не проблема — отдельных ресурс для каждого дома/квартиры. А вот в админке все номера в общем списке.
На сайте разделить их не проблема — отдельных ресурс для каждого дома/квартирыОтдельный ресурс, что подразумевается под этим?
А вот в админке все номера в общем списке.Если админку видят только админы и модераторы, то это нормально
Отдельный ресурс, что подразумевается под этим?Отдельная страница для каждой квартиры или дома. Если делать всё на одной странице, то придется дописывать логику самому, чтобы при выборе квартиры показывались только соответствующие комнаты.
Если админку видят только админы и модераторы, то это нормальноЭто как завести объекты. Если будет 5 записей «Комната 1», то даже админам будет сложно понять для какой квартиры каждая комната.
То есть можно будет сделать так, чтобы:
1) список квартир и домов, когда нажимаешь на конкретный объект — выходит страница квартиры или дома с описанием характеристик каждого объекта;
2) пользователь нажимает на кнопку «забронировать» и дальше выскакивает окно бронирования как в вашем дополнении
1) список квартир и домов, когда нажимаешь на конкретный объект — выходит страница квартиры или дома с описанием характеристик каждого объекта;
2) пользователь нажимает на кнопку «забронировать» и дальше выскакивает окно бронирования как в вашем дополнении
Точно так.
Забыл еще про возможность добавлять свои поля. Можно создать свое поле «Квартира» или «Адрес».
Последний вопрос: как можно связаться с Вами лично?
Лучше всего по скайпу.
Обнаружил баг, неуверен на 100%, что проблема не в моем единичном случае.
Сниппет [[!obSearch]]
Отдает строчки без учета cultureKey в лексиконе.
Чанк:
Думаю, может модуль переключается в тот контекст, где лежат товары?
В кнопке тоже вызов из лексикона выдается с лексиконом ru.
Сниппет [[!obSearch]]
Отдает строчки без учета cultureKey в лексиконе.
Чанк:
<div class="room-row">
<div class="row">
<div class="col-xs-5">
<div><img alt="room-thumb-1" class="img-responsive" src="[[#[[+ob_search.ms_product]].image:phpthumbon=`w=294&h=199&zc=1`]]"></div>
</div>
<div class="col-xs-7">
<div class="">
<h4 class="subtitle">[[+ob_search.name]]</h4>
<em>[[!%rz.from? &namespace=`rz` &language=`[[!++cultureKey]]`]] <span class="price">[[+ob_search.price]]</span> [[!%rz.night? &namespace=`rz` &language=`[[!++cultureKey]]`]]</em>
[[!$tpl.onebooking.button2]]
</div>
</div>
</div>
</div>
Что с ru cultureKey, что с en, отдает ru.Думаю, может модуль переключается в тот контекст, где лежат товары?
В кнопке тоже вызов из лексикона выдается с лексиконом ru.
Это баг именно oneBooking? Т.е. на остальных страницах всё работает?
Да. Я так понимаю, когда oneBooking обращается к товарам минишопа, переключает контекст туда, где товары лежат.
Создавать те же товары в другом контексте нелогично (те же товары получается).
Создавать те же товары в другом контексте нелогично (те же товары получается).
action.php
// Switch context
if (!empty($_SESSION['oneBooking']['ctx'])) {
$context = $_SESSION['oneBooking']['ctx'];
} else {
$context = 'web';
}
if ($context != 'web') {
$modx->switchContext($context);
}
А сниппет obSearch в каком контексте вызывается?
в обоих котекстах
Здравствуйте! Дополнительный модуль с возможностью почасового бронирования еще планируется?
Добрый вечер!
В обозримом будущем не планирую каких-то разработок в MODX. Погружаюсь в Laravel, вынырну не скоро.
По oneBooking планирую единственную доработку — решить проблему совместимости с новым miniShop2 — перестали работать оплаты.
В обозримом будущем не планирую каких-то разработок в MODX. Погружаюсь в Laravel, вынырну не скоро.
По oneBooking планирую единственную доработку — решить проблему совместимости с новым miniShop2 — перестали работать оплаты.
На modstore.pro написано:
Данная версия не совместима с miniShop2 версии выше 2.1.12.
А какая версия Modx тогда нужна? Чтобы все корректно работало?
Данная версия не совместима с miniShop2 версии выше 2.1.12.
А какая версия Modx тогда нужна? Чтобы все корректно работало?
Особых требований по этому поводу нет.
Сергей, дайте подсказку
После обновления до версии 3.4.2 перестала работать выборка по номерам, и при поиске номеров выдает все существующие, вместо указанного типа. После, при нажатии кнопки «Забронировать», при попытке посчитать сумму вылетает ошибка «Не выбран ни один объект»
После обновления до версии 3.4.2 перестала работать выборка по номерам, и при поиске номеров выдает все существующие, вместо указанного типа. После, при нажатии кнопки «Забронировать», при попытке посчитать сумму вылетает ошибка «Не выбран ни один объект»
Странно. Вчера целый день тестировал. И на моем сайте всё работает.
1. Откатите на предыдущую версию.
2. Создайте запрос в техподдержку.
Будем решать.
П.С. Для начала попробуйте сбросить кэш браузера.
1. Откатите на предыдущую версию.
2. Создайте запрос в техподдержку.
Будем решать.
П.С. Для начала попробуйте сбросить кэш браузера.
Очистка кэша помогла, спасибо вам
Возможно ли использовать этот компонент для записи на семинар?
или для записи к мастерам в салон красоты?
или для записи к мастерам в салон красоты?
Если б я знал.
Подскажите, компонент подходит только для одного объекта? Или можно на несколько повесить?
Например, имеется каталог гостиниц, и нужно на каждую из них прикрутить бронирование. Или бронирование возможно только, если сайт представляет одну гостиницу?
Например, имеется каталог гостиниц, и нужно на каждую из них прикрутить бронирование. Или бронирование возможно только, если сайт представляет одну гостиницу?
Наверно, вы имели ввиду только для одной гостиницы. Объекты (в вашем случае номера) не имеют возможности привязки к какому-либо контейнеру (гостинице). Как вариант, создаёте номера для всех гостиниц, а затем при вызове сниппета указываете только нужные — для одной гостиницы одни айдишники, для другой — следующие. Только так.
Есть сайт гостиницы на Revo. Готов помочь с описанием необходимого функционала. В общем функционал устраивает, но нужно еще или в админке или лучше на фронте с правами менеджера отеля сделать:
1) шахматка броней (создание, редактирование, выезд, удаление броней)
2) Ведение клиентской базы (сохранение данных клиентов из форм и их редактирование)
3) Создание броней с подстановкой данных клиента из клиентской базы
4) Оповещение о новом бронировании
5) Отчеты за период времени
6) Печатные формы (Анкета. Форма №5)
7) Бронирование по койко-местам.
1) шахматка броней (создание, редактирование, выезд, удаление броней)
2) Ведение клиентской базы (сохранение данных клиентов из форм и их редактирование)
3) Создание броней с подстановкой данных клиента из клиентской базы
4) Оповещение о новом бронировании
5) Отчеты за период времени
6) Печатные формы (Анкета. Форма №5)
7) Бронирование по койко-местам.
8) Пирожное
9) Мороженое
П.С. Думается мне, что такая работа стоит не меньше тридцатки. Лучше обратиться в раздел «Работа», ребята подскажут точнее. Я с MODX не работаю.
9) Мороженое
П.С. Думается мне, что такая работа стоит не меньше тридцатки. Лучше обратиться в раздел «Работа», ребята подскажут точнее. Я с MODX не работаю.
Добрый день! Скажите пожалуйста, а работа с бронями происходит только через админку? Можно как-то их вывести во фронтенд для залогиненых пользователей, чтобы не пускать кого попало в админку?
Скажите пожалуйста, а работа с бронями происходит только через админку?Да.
Можно как-то их вывести во фронтенд для залогиненых пользователей, чтобы не пускать кого попало в админку?Не берите в менеджеры «кого попало». :) Просто настройте админку под эту задачу, а остальное запретите.
Не нашел в документации, как подключить оплату.
Можно начать отсюда.
Роман, дальнейшее общение предлагаю перенести в техподдержку магазина modstore.pro.
Роман, дальнейшее общение предлагаю перенести в техподдержку магазина modstore.pro.
Я понял, напишу тогда там.
Спасибо большое за решение, я думаю попробовать его для аренды техники — тоже посуточно.
Правда появились вопросы — везде теперь написано «аренда номера» и надо это как-то мне выпиливать.
И второе — подключается bootstrap и jq которые у меня уже подключены и хотелось бы иметь возможность их отключить ((
Благодарю
Правда появились вопросы — везде теперь написано «аренда номера» и надо это как-то мне выпиливать.
И второе — подключается bootstrap и jq которые у меня уже подключены и хотелось бы иметь возможность их отключить ((
Благодарю
вопрос с текстом был решен в «Управление словарями», а вот со скриптами прищлось редактировать php файл сниппета и комментировать некоторые js и css файлы
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.