CRM/ERP для турбазы «Звезда Юга»

Цель: автоматизировать онлайн-бронирование с сайта (Tilda) → оплату → попадание данных в систему → управление заселениями (шахматка) → питание/кухня/официанты/охрана → отчеты → интеграция с МВД (resident.sady) → доп. услуги → продления.

Текущее состояние:

• Сайт на Tilda, на карточках домиков и на главной есть кнопка «Забронировать».
• Форма сейчас собирает: Имя, телефон, дата заезда, дата выезда, кол-во гостей, но никуда не отправляет (нет backend).

Результат проекта:

• Единая система, куда попадают оплаты/брони, ведется шахматка, карточки гостей, питание, услуги, отчеты и интеграции.
• Доступ с ролями (менеджер/кухня/официанты/охрана/админ).
  

1) Варианты реализации (архитектурная опция)

Вариант A: «Своя система + (опционально) интеграция с Битрикс24»

• Система бронирования и операционная часть (шахматка, кухня, отчеты, домики) — своя.
• CRM (лиды, коммуникации, задачи) — Bitrix24 (по желанию), синхронизация гостей/сделок.

Вариант B: «Все внутри Битрикс24 (если возможно по формату)»

• Шахматка, тарифы, отчеты кухни/официантов/охраны и интеграции — часто требуют кастомной разработки/приложения.
• Реально, но обычно сложнее и дороже по кастомизации.

Требование: разработчик должен предложить итоговую архитектуру и подтвердить, что выбранный вариант закрывает шахматку, тарифы по календарю, отчеты и интеграцию с resident.sady.

2) Роли и права доступа

1. Администратор

• управляет пользователями/ролями
• справочники домиков, тарифы, питание, услуги
• доступ ко всем отчетам и настройкам

1. Менеджер

• видит/редактирует брони, шахматку, карточки гостей
• ручное создание бронирования (без сайта)
• продления, переселения, отмены, возвраты (если предусмотрены)
• выставление доп. услуг, корректировка питания

1. Кухня

• видит отчеты по блюдам на дату
• не видит персональные данные (или видит минимально — по настройке)

1. Официанты

• видят отчет по столам на дату
• минимум персональных данных

1. Охрана

• видит список ожидаемых заездов/выездов по дням и времени
• минимум персональных данных

3) Основные сущности данных (минимальная модель)

4.1 Домик (AccommodationUnit)

• ID, Название (Дом1/Дом2/…)
• Вместимость (взрослые/дети, макс)
• Тип/категория (по желанию)
• Статус: активен/скрыт/ремонт
• Примечания
• Теги: “убран/не убран/ремонт/проверка” и т.п.

3.2 Бронирование (Booking)

• ID, источник (Tilda / менеджер / партнер)
• Домик
• Даты: заезд/выезд
• Время заезда/выезда (план)
• Кол-во гостей: взрослые/дети
• Главный гость: ФИО, телефон
• Доп. гости: список (ФИО, дата рождения/документ — если нужно для МВД)
• Питание: формат (см. ниже)
• Статусы: создано → ожидает оплаты → оплачено → заселен → выехал → отменено
• Суммы: проживание, питание, доп. услуги, итог
• Оплата: метод, транзакция, чек/квитанция, статус платежа
• Теги (гость приехал/уехал, VIP, конфликт и т.д.)
• История изменений (audit log): кто и что поменял

3.3 Питание (MealPlan)

• Тип питания (например):
• Без питания
• Завтрак
• Полупансион (завтрак+ужин)
• Полный пансион (завтрак+обед+ужин)
• Учет по гостям (взрослые/дети), возможны исключения по гостю

3.4 Меню/блюда (MenuItem)

• Наименование
• Прием пищи (завтрак/обед/ужин)
• Дата действия/расписание (если меню меняется по дням)
• Норма на 1 человека (или “1 порция на человека”)

3.5 Доп. услуги (ExtraService)

• Наименование (баня/чан/катер/велосипеды/лыжи…)
• Цена (фикс/по часам/по количеству)
• Правила начисления
• Привязка к брони + статус оказания

4) Интеграция с сайтом Tilda (форма “Забронировать”)

5.1 Поля формы (что надо собирать)

Обязательные:

• Домик (или идентификатор домика из кнопки/страницы)
• Имя
• Телефон
• Дата заезда
• Дата выезда
• Кол-во гостей (взрослые)
• Кол-во детей (добавить поле)
• Питание (вариант/галочки)

Желательные:

• Время заезда/выезда (по умолчанию шаблонное, но можно выбор)
• Комментарий

4.2 Логика после отправки формы

1. Клиент заполняет форму на Tilda
2. Нажимает “Продолжить / Перейти к оплате”
3. Система:
• проверяет доступность домика на выбранные даты
• рассчитывает стоимость (проживание + питание + доп. услуги, если есть)
4. Клиента перенаправляет на страницу оплаты
5. После успешной оплаты:
• создается бронь со статусом “Оплачено”
• бронь появляется в шахматке
• отправляется подтверждение клиенту (SMS/WhatsApp/email — если нужно)
6. Если оплата не прошла:
• бронь может быть “Ожидает оплаты” (резерв на X минут) или не создаваться — по решению
• должно быть единое правило “таймаут резерва” (например 15 минут)

Важно: предусмотреть защиту от дублей (повторная оплата/повторная отправка формы).

5) Оплата

Требование: интеграция с платежным провайдером (варианты: CloudPayments / ЮKassa / Tinkoff / Stripe — выбирается заказчиком).
Функции:

• выставление счета на итоговую сумму
• прием оплат онлайн
• получение webhook/уведомления об успехе
• запись транзакции в бронь
• режим частичной оплаты/предоплаты (опционально): процент/фикс
• возврат (опционально): ручной из админки

6) Основной интерфейс менеджера

6.1 “Шахматка” (календарь занятости)

• По вертикали: Дом1, Дом2, Дом3…
• По горизонтали: даты
• В ячейке показывать минимум: имя/телефон или имя + кол-во гостей + статус
• Цветовая индикация статуса (бронь/оплачено/заселен/выехал/отмена)
• Клик по ячейке → карточка бронирования
• Поиск/фильтры: по имени, телефону, статусу, тегам, домику, дате
• Создание брони “вручную” из шахматки (drag/select диапазон дат)

Операции в шахматке:

• изменить даты (если нет конфликта)
• переселить в другой домик (если свободен)
• продлить (если даты свободны)
• отменить/пометить как no-show (по желанию)

6.2 Карточка брони (редактируемая)

Поля:

• Имя главного гостя, телефон
• Доп. гости (список)
• Взрослые/дети
• Питание (тип + уточнения)
• Время заезда/выезда
• Домик
• Статусы
• Теги
• Суммы (проживание/питание/услуги/итог)
• История изменений

7) Управление домиками и ценами

8.1 Управление домиками

• добавить домик
• удалить домик (или “архивировать”, чтобы не ломать историю)
• менять порядок в списке шахматки
• статусы домика (активен/скрыт/ремонт)
• теги домика (убран/не убран и т.д.)

7.2 Ценообразование (обязательно “в виде календаря”)

Нужно сделать гибкую систему тарифов:

• цена за сутки по домику
• цена может отличаться по:
• сезону/датам (календарь)
• дням недели (опционально)
• праздникам (опционально)
• массовое применение цены диапазоном дат
• сохранение истории изменений цен (кто/когда)

8) Питание и отчеты

9.1 Логика питания

Система должна по каждой брони знать:

• сколько гостей питается и как (взр/дети)
• в какие дни питания включено (обычно все дни проживания, но в день заезда/выезда может отличаться — нужно правило)

Правило питания (нужно реализовать настройкой):

• например: “завтрак начинается на следующий день после заезда” / или “в день заезда тоже есть ужин”
• желательно сделать это настройкой проекта

8.2 Отчет для кухни (файл)

Генерировать отчет на выбранную дату или диапазон дат в формате XLSX/PDF/CSV:

• дата
• прием пищи (завтрак/обед/ужин)
• блюдо → количество порций (расчет по меню и числу гостей, с учетом их плана питания)

8.3 Отчет для официантов (по столам)

Требуется логика “столы”:

• создать справочник столов (Стол №1, №2…)
• каждому домику/брони можно присвоить стол (или вручную в день)
  Отчет на дату:
• Стол №
• Кол-во гостей на стол
• Список блюд и кол-во порций

9) Отчет для охраны

Экран/отчет “Сегодня/Завтра заезды и выезды”:

• кто заезжает, сколько человек, время прибытия (план)
• кто выезжает, время выезда
• домик
• телефон (по настройке — можно скрыть)
  Экспорт в файл (PDF/XLSX) + режим “табло” на экране.

10) Интеграция с resident.sady (МВД)

Требование: интеграция с сервисом resident.sady для передачи данных о заселении в МВД.

Функции:

• при переводе брони в статус “Заселен” формируется и отправляется событие/заявка в resident.sady
• хранить статус отправки: отправлено/ошибка/в очереди
• лог ошибок + возможность повторить отправку
• обязательные поля для МВД (уточняются по API/формату resident.sady): ФИО, дата рождения, документ, гражданство и т.д.

Важно: предусмотреть, что менеджер может не иметь всех данных заранее → нужна “проверка полноты данных” перед отправкой.

11) Продление проживания

Функционал продления:

• в карточке брони кнопка “Продлить”
• система проверяет доступность домика на новые даты
• пересчет стоимости проживания/питания
• если требуется доплата → выставить счет и принять оплату
• фиксация изменения в истории

12) Дополнительные услуги

Каталог услуг:

• баня (затопка)
• чан
• прогулка на катере
• аренда велосипедов
• аренда лыж
• и т.д.

Функции:

• добавление услуги к брони (кол-во/время/дата)
• цена и скидки (опционально)
• статус услуги: заказано/оказано/отменено
• оплата: включено в общий счет или отдельной оплатой

13) Уведомления (опционально, но желательно)

• клиенту: подтверждение оплаты + детали брони
• менеджеру: новая оплаченная бронь
  Каналы: email/SMS/WhatsApp/Telegram — выбирается.

14) Нефункциональные требования

Безопасность и доступ:

• авторизация по логину/паролю, роли
• журнал действий (кто что менял)
• защита персональных данных (минимизация доступа для кухни/охраны/официантов)

Надежность:

• резервное копирование БД (ежедневно)
• обработка сбоев платежей и вебхуков

Производительность:

• шахматка должна открываться быстро (цель: до 2–3 сек на месяц отображения при N домиков)

Платформа:

• Web-приложение (ПК + адаптив под мобильный для охраны/менеджера)
• хранение в облаке/VPS (уточнить)

15) API и интеграции (требования к backend)

Нужно реализовать:

• API приема брони из Tilda (endpoint)
• API расчета стоимости
• API платежей + webhook обработчики
• API/модуль resident.sady
• генерация отчетов (XLSX/PDF)
• импорт/экспорт справочников (по необходимости)

16) Критерии приемки (что считается “сделано”)

1. С формы Tilda можно создать бронь, пройти оплату, после оплаты бронь появляется в системе.
2. В шахматке корректно отражается занятость домиков по датам, конфликты не допускаются.
3. Менеджер может открыть бронь, отредактировать поля, добавить гостей, изменить питание, изменить статусы.
4. Админ может добавлять/удалять(архивировать) домики и менять цены по календарю.
5. Отчет кухни формируется на выбранную дату и правильно считает блюда по числу гостей и типу питания.
6. Отчет официантов формируется по столам и показывает блюда/кол-во.
7. Отчет охраны показывает заезды/выезды и времена.
8. Интеграция resident.sady: при заселении отправка проходит, ошибки логируются и можно повторить.
9. Реализовано продление брони с проверкой доступности и пересчетом суммы.
10. Реализовано добавление доп. услуг к брони.

17) Этапы разработки (рекомендуемая структура работ)

Этап 1 (MVP):

• домики, шахматка, ручные брони
• интеграция Tilda → создание брони
• оплата + webhook
• карточка брони + редактирование
• базовые цены

Этап 2:

• питание + меню
• отчеты кухни и официантов
• столы

Этап 3:

• охрана отчет
• resident.sady
• продления
• доп. услуги

Этап 4 (опционально):

• интеграция с Bitrix24
• уведомления
• возвраты/предоплаты/сложные тарифы