Как вести учёт бронирований посуточной аренды и сохранять историю изменений

Чтобы вести учёт бронирований посуточной аренды, каждой брони нужен постоянный ID, запись об условиях проживания и связанные записи платежей. Изменения сохраняют в журнале, а реестр ежедневно сверяют с подтверждениями, поступлениями и фактическими заездами. Ниже — предлагаемый внутренний порядок для собственника и менеджера: от создания записи до проверки её истории.

Начните с единого реестра и ответственного за запись

Организуйте учёт вокруг одной записи на каждую бронь: присвойте ей постоянный идентификатор, сохраните согласованные условия и свяжите с платежами. Назначьте человека, который обновляет запись и проверяет её по источникам. Такой предлагаемый внутренний порядок можно адаптировать для собственника, менеджера бронирований или управляющего с несколькими сотрудниками. При ежедневной сверке они проверяют расхождения между реестром, подтверждениями и фактическим проживанием.

Рабочая запись отвечает на вопросы: какой объект забронирован, на каких условиях, сколько осталось оплатить и кто отвечает за дальнейшие действия. Переписка, кабинет площадки и подтверждения поступления денег помогают проверить ответы. Ссылка на источник нужна рядом с соответствующим условием или операцией, чтобы сотрудник мог открыть основание записи.

До начала работы подготовьте справочник объектов с постоянными кодами, перечень источников продаж и доступ к подтверждениям условий. Определите, где сотрудники проверяют платежи и кто сообщает о заездах. Названия квартир в объявлениях могут различаться; внутренний код должен однозначно указывать на объект.

Ответственному назначьте подмену.

Зафиксируйте границу между оперативным учётом и документами, подтверждающими расчёты. В предлагаемом порядке отметка «оплачено» требует ссылки на подтверждение операции и проверки её назначения. Самостоятельно введённая сумма в реестре не подтверждает поступление денег.

При передаче смены сотрудник сообщает о неподтверждённых условиях, ожидаемых оплатах и открытых расхождениях. Подмена получает доступ к рабочим источникам. Если подтверждение доступно только первому менеджеру, следующий сотрудник не сможет проверить запись самостоятельно.

Бронь можно проверить, когда запись, платежи и история изменений связаны одним постоянным ID.

Какие поля включить в реестр бронирований

Включите в запись идентификаторы, объект размещения, условия проживания, три группы статусов и ссылки на расчёты. Для каждого поля задайте формат и источник проверки. В предлагаемом порядке обязательность зависит от ситуации: внутренний ID нужен всегда, номер площадки — для брони из соответствующего канала. Запись относится к конкретному объекту, который сотрудники находят по постоянному коду.

Таблица содержит условный пример одной обезличенной брони. Все суммы, идентификаторы, число гостей и часы — учебные значения. Даты заезда и выезда в рабочей записи указывают полностью; в примере показан только формат времени.

Различайте неизвестное значение, ноль и неприменимость. «Удержание неизвестно» требует проверки; нулевая сумма требует основания. «Не предусмотрен» означает отсутствие условия, а пустая ячейка оставляет вопрос открытым.

Неизвестная стоимость не равна нулевой.

Для записи с непроверенной ценой сохраните статус проверки и ответственного. До согласования суммы не выводите числовой остаток как подтверждённый долг. Если формула показывает ноль из-за пустой ячейки, сотрудник может ошибочно принять запись за полностью оплаченную.

Как связать бронь с платежами и журналом изменений

Разделите данные на четыре группы: бронирования, платёжные операции, изменения и расхождения. В таблице это могут быть отдельные листы. Постоянный внутренний ID идентифицирует бронь и связывает её с остальными записями. Номер строки для такой связи не подходит: после сортировки или удаления соседней записи положение строки может измениться.

В записи брони храните действующие условия. В платежах — движение денег. Журнал изменений сохраняет историю условий, а журнал расхождений показывает вопросы, которые сотрудникам ещё предстоит разрешить. Это предлагаемая структура внутреннего учёта; возможность поддерживать такие связи проверяют в выбранном инструменте.

У платёжной операции предусмотрите собственный ID, дату и время, сумму, валюту, направление, назначение и источник подтверждения. Связь с бронью храните отдельным полем или записью распределения. Возврату добавьте ссылку на исходную оплату.

Одна бронь может иметь несколько операций.

Например, гость вносит предоплату, затем доплачивает, а после изменения условий получает частичный возврат. Все события остаются отдельными записями. Сотрудник восстанавливает расчёт по суммам и основаниям, а комментарий поясняет причину.

В предлагаемом порядке сумма операции хранится положительным числом, направление — отдельным полем: поступление или возврат. Формула сама учитывает направление. Если инструмент использует отрицательные суммы для возвратов, закрепите другое единое правило и проверьте, что возврат не учитывается дважды.

Для общей выплаты площадки сохраните исходную операцию и отдельные распределения по броням. Не копируйте полную сумму поступления в каждую бронь. Сумма распределений должна совпасть с подтверждённой выплатой либо оставить видимое расхождение.

Связи удобно проверять на обезличенной записи: от ID брони должны находиться условия, операции, изменения и нерешённые вопросы. Сумму, направление платежа и основание возврата храните в отдельных полях. Свободный комментарий оставьте для пояснений, которые не участвуют в расчёте.

Разделите статусы брони, проживания и оплаты

Ведите три независимые группы статусов: договорённость о бронировании, фактическое проживание и состояние оплаты. Подтверждённая бронь может оставаться неоплаченной, а отменённая — ожидать возврата. Предлагаемые названия служат внутреннему учёту; обозначение площадки сохраняйте отдельно. Каждый переход связывайте с событием, ответственным сотрудником и подтверждением, по которому можно проверить запись.

Состояние возврата ведите отдельным полем: согласован, ожидает выполнения или выполнен. Оно не заменяет статус оплаты проживания. Если после отмены сумма обязательств обнулена, отметьте «нет суммы к оплате», сохранив вопрос о возврате.

Для предварительной брони запишите дату и время окончания удержания, часовой пояс и следующее действие. Срок берите из условий конкретной брони. После его истечения ответственный проверяет основание продления, подтверждения или снятия удержания.

Отмена требует отдельной проверки расчётов.

Сотрудник сохраняет подтверждение отмены, решение о сумме обязательств и связанные платёжные операции. Изменение внутреннего статуса само по себе не подтверждает изменение записи в источнике. В реестре отдельно отмечают, какие сведения уже проверены, а какие ещё требуют подтверждения.

У статуса «оплачено» должна быть воспроизводимая опора: действующая сумма обязательств и зачтённые операции. При изменении цены статус проверяют заново, даже если гость уже выехал. Отрицательный остаток выделяйте как переплату для проверки, а не скрывайте общим статусом.

Как добавить новую бронь и проверить запись

Создавайте запись по подтверждённым условиям и сначала проверяйте, нет ли такой брони в реестре. В предлагаемом порядке менеджер сверяет объект, даты, время, число гостей, стоимость и основания статусов. Условия прямой или телефонной продажи тоже сохраняют в проверяемом подтверждении. Второй сотрудник должен понять договорённость без устного пересказа первым менеджером.

1. Получите подтверждение условий. Сохраните ссылку на запись кабинета площадки или согласованную переписку. После звонка зафиксируйте условия и запросите подтверждение гостя.
2. Проверьте существующую запись. Ищите по источнику и ID площадки, затем по объекту, датам и доступным сведениям о госте.
3. Присвойте внутренний ID. Используйте установленное правило создания идентификаторов и сохраните внешний номер отдельно.
4. Заполните поля. Перенесите условия из подтверждения, укажите часовой пояс и разделите статусы брони, проживания и оплаты.
5. Проверьте результат. Сопоставьте запись с источником, проверьте пересечение дат и назначьте ответственного.

Совпадение признаков — повод открыть обе записи и проверить основание. Оно ещё не доказывает дубль: один гость может бронировать несколько квартир или обращаться через разные каналы. До выяснения сохраните обе исходные записи и отметьте предполагаемую связь между ними.

Проверка пересечения дат включает конкретный объект и согласованные границы проживания. Обнаруженное пересечение запишите как расхождение с ответственным. Спорные условия не меняйте по догадке: сначала выясните, какая запись подтверждена и что именно согласовано.

Для обезличенного фрагмента реестра достаточно внутреннего ID, кода объекта, источника, статусов и отметки проверки. Личные контакты в таком примере не нужны.

Сначала подтверждение, затем отметка проверки.

Запись готова к работе, когда её можно найти по ID, обязательные сведения заполнены, а источник условий доступен. У проверки пересечений должен быть результат. Неизвестную цену обозначьте как вопрос для согласования; такая запись остаётся непроверенной в части расчётов.

При подтверждённом дубле укажите, какая запись становится основной и почему. Проверьте связанные платежи до объединения сведений. Вторую запись сохраните с пометкой о дубле и ссылкой на основную, чтобы её прежний ID не потерял смысл.

Как считать остаток гостя и ожидаемую выплату

Считайте отдельно обязательства гостя и ожидаемое поступление от площадки. Для остатка используйте действующую согласованную стоимость, зачтённые оплаты и выполненные возвраты этих оплат. Обеспечительный платёж исключайте из расчёта проживания. Ожидаемую выплату проверяйте по подтверждённой схеме перечисления и удержаниям. Эти формулы предлагаются для оперативного контроля и не заменяют отдельный порядок бухгалтерского учёта.

При согласованном ночном тарифе число ночей определяйте по разнице календарных дат выезда и заезда в часовом поясе объекта. Ранний заезд, поздний выезд и другие доплаты сохраняйте отдельными условиями. Если стороны согласовали общую стоимость проживания, используйте её, не восстанавливая тариф по догадке.

Остаток гостя = действующая сумма к оплате − зачтённые платежи + выполненные возвраты зачтённых платежей.

В этой формуле зачтённые платежи — сумма до вычета возвратов. Если инструмент уже показывает оплаты за вычетом возвратов, прибавлять возвраты повторно нельзя. Выберите один способ расчёта и проверьте его на условных операциях.

Условный пример: проживание стоит 12 000 рублей, в погашение зачтено 4 000 рублей. Остаток — 8 000 рублей. Затем стороны согласовали стоимость 10 000 рублей, и 1 000 рублей из прежней оплаты фактически вернули. Остаток составит 10 000 − 4 000 + 1 000 = 7 000 рублей.

После выполненного возврата зачтённая сумма составляет 3 000 рублей.

Согласованный, но ещё не выполненный возврат храните как предстоящее действие. Он не меняет сумму фактически прошедших операций. В условном примере до перевода возврата остаток по формуле равен 6 000 рублей, а ожидаемый возврат указан отдельно.

Для выплаты площадки используйте другой расчёт: база перечисления минус подтверждённые удержания с учётом корректировок. Возврат учитывайте по детализации, чтобы не вычесть одну операцию дважды. Название поля «база перечисления» заранее объясните сотрудникам: какая сумма берётся и из какого подтверждения.

Условный пример: гость полностью оплатил 12 000 рублей через площадку. Учебная комиссия составляет 1 200 рублей; других удержаний нет. Ожидаемая выплата — 10 800 рублей. Эти значения не описывают тариф или правила реальной площадки.

По условиям этого примера гость оплатил обязательство полностью, хотя оператор ожидает меньшую сумму. Разницу объясняет удержание. Выплату площадки нельзя повторно прибавлять к оплате гостя: это поступление по другому участку расчётов.

Как сохранять переносы дат, замену квартиры и изменение цены

Каждое согласованное изменение записывайте отдельным событием: кто внёс правку, когда, какое поле изменил и на каком основании. В предлагаемом порядке журнал сохраняет прежние условия, а запись бронирования показывает действующие. При переносе дат или замене квартиры сначала проверьте доступность объекта. После подтверждения новых условий обновите запись и пересчитайте связанные показатели.

Для события предусмотрите ID изменения, внутренний ID брони, дату и время с часовым поясом, сотрудника и изменяемое поле. Добавьте старое значение, новое значение, причину и ссылку на подтверждение. Несколько правок одной договорённости можно объединить общим ID события, сохранив значения каждого поля.

1. Проверьте основание. Найдите согласованные условия и уточните спорные детали.
2. Сохраните прежние значения. Зафиксируйте их до обновления рабочей записи.
3. Запишите новые условия. Укажите автора правки и подтверждение договорённости.
4. Пересчитайте показатели. Обновите стоимость, остаток и связанные статусы.
5. Проверьте результат. Сопоставьте запись с подтверждением и убедитесь, что история доступна.

Условный пример: гость согласовал продление на одну ночь, стоимость изменилась с 12 000 до 15 000 рублей. Журнал хранит прежний и новый выезд, обе суммы и основание изменения. Если позднее продление отменят, появится новое событие; первое останется в истории.

Замена квартиры требует проверки нового кода объекта, доступности и согласованных условий. Старый код сохраняют в журнале. По действующей записи должно быть понятно, куда заселяют гостя, а по истории — какой объект был согласован прежде.

Новый внешний номер требует проверки.

Если источник изменил номер той же брони, сохраните оба внешних ID и подтверждение их связи с внутренней записью. Если прежняя бронь отменена и создана самостоятельная новая, заведите новый внутренний ID. Свяжите записи как замену и отдельно проверьте, к какой из них относятся оплаты.

Не переносите деньги между записями только из-за совпадения гостя. В предлагаемом порядке зачёт на новую бронь требует сохранённого основания. Иначе в старой записи может исчезнуть ожидаемый возврат, а в новой — появиться необъяснённая оплата.

Историю версий файла проверьте отдельно. Возможность открыть старую копию ещё не показывает причину правки или согласование гостя. Сотрудник должен восстановить событие без сравнения всего файла вручную.

Из журнала должно быть понятно, какие условия изменились, кто внёс правку и чем её подтвердил.

Что записывать при отмене, незаезде и общей выплате площадки

Отмену, незаезд и возврат отражайте отдельными событиями, сохраняя исходную бронь и операции. Записывайте финансовое решение вместе с основанием, не подставляя универсальный штраф или сумму возврата. Общую выплату площадки распределяйте по подтверждённой детализации; нераспределённую часть оставляйте в журнале расхождений. Обеспечительный платёж ведите отдельно, включая поступление, возврат и подтверждение согласованного решения.

Запись «отменена» оставляет открытыми несколько вопросов: какова подтверждённая сумма обязательств, какую сумму решено вернуть и выполнен ли возврат. Зафиксируйте ответы независимо. Обещание вернуть деньги храните как решение; подтверждённый перевод добавляйте платёжной операцией.

Отмена не подтверждает возврат денег.

Для незаезда сохраните источник проверки и действие ответственного. Если финансовое решение ещё не принято, отметьте это отдельно. Менеджер передаёт спорный вопрос уполномоченному сотруднику и сохраняет полученное решение с основанием, не меняя стоимость самостоятельно.

При продлении сначала проверьте доступность новых дат. После согласования цены внесите событие изменения и пересчитайте остаток. Если условия ещё обсуждаются, сохраните запрос отдельно от действующих дат проживания.

Если выплата площадки не раскладывается по броням, зафиксируйте её полную сумму и подтверждённые распределения. Остаток покажите как нераспределённый. Предполагаемое распределение можно сохранить для проверки, но оно не должно автоматически становиться подтверждённым расчётом.

Уточните, каких сведений не хватает: номера брони, детализации удержания или подтверждения корректировки. Подгонка стоимости одной брони под банковское поступление скроет причину расхождения. Исправлять нужно поле, для которого найдено основание.

Отменённая запись остаётся доступной для сверки. По её ID сотрудник находит прежние условия, основание отмены, оплаты и возвраты. Незавершённые действия видны независимо от статуса проживания.

Ежедневная сверка: пять шагов от проверки до закрытия

Пять шагов ежедневной сверки бронирований

Ежедневная сверка сопоставляет реестр с подтверждениями бронирований, платежами и фактическим проживанием. В предлагаемом порядке команда заранее назначает время, часовой пояс, период проверки, ответственного и подмену. Результат сохраняют даже при незакрытых вопросах. У каждого расхождения должны быть ответственный, источник проверки и срок следующего действия; отсутствие ответа не считается подтверждением записи.

Журнал расхождений фиксирует результаты проверки. В запись включите ID брони, проверяемое поле, ожидаемое и фактическое значение, источник, сотрудника и дальнейшее действие. Для общей выплаты без установленной брони используйте ID платёжной операции.

Открытый вопрос должен оставаться видимым.

Перед проверкой определите границы периода, чтобы сотрудники одинаково отбирали новые записи и изменения. Если источник недоступен, отметьте непроверенную часть и назначьте повторную проверку. Завершение сверки означает фиксацию результата; закрытие отдельного расхождения требует подтверждения исправления.

Пять шагов ниже — предлагаемый внутренний маршрут. Его результатом становится отметка о проверенном периоде и перечень оставшихся вопросов.

1. Сопоставьте новые брони и изменения с источниками

Проверьте внутренний и внешний ID, объект, даты, стоимость и состояние брони по подтверждению источника. Найдите отсутствующие записи и возможные дубли. Изменённые условия сопоставьте с журналом: у переноса или новой цены должно быть основание. Если источник и реестр расходятся, сохраните оба значения до выяснения причины и назначьте проверку.

Отдельно проверьте записи без подтверждённой стоимости. Они не должны исчезать из проверки только потому, что формула остатка ещё не рассчитана.

2. Сверьте платежи, возвраты и выплаты

Сопоставьте платёжные операции с подтверждениями поступлений и детализацией выплат. Проверьте назначение, сумму, валюту и связь с бронью. Разделите расчёты за проживание, обеспечительные платежи и нераспределённые суммы. Возврат найдите по исходной оплате. Отдельно проверьте, не попала ли одна операция в реестр повторно под другим внутренним номером.

Согласованные возвраты сопоставьте с выполненными. У ожидающего перевода должно оставаться следующее действие, а у выполненного — подтверждение операции.

3. Проверьте фактические заезды и выезды

Сравните план проживания с сообщениями ответственных сотрудников. Заезд подтверждайте рабочей отметкой, выезд — результатом проверки объекта или другим принятым подтверждением. Отдельно разберите незаезды, досрочные выезды и продления. Запланированный выезд сам по себе не подтверждает освобождение квартиры. Неясное состояние передайте сотруднику, который может проверить факт и сообщить результат.

Досрочный выезд не меняет цену автоматически. Если стороны согласовали перерасчёт, сохраните его отдельным событием с новыми условиями.

4. Назначьте действия по расхождениям

Запишите проблему, ожидаемое и фактическое значение, источник проверки, ответственного и срок следующего действия. Сформулируйте конкретный запрос: найти детализацию выплаты, подтвердить перенос или проверить возврат. Спорные значения сохраняйте до получения основания. Если решение зависит от другого сотрудника, укажите, кто запрашивает ответ и контролирует дальнейшее действие.

Фраза «разобраться с оплатой» не объясняет задачу. Укажите, какую операцию ищут, за какой период и с какой бронью её нужно сопоставить.

5. Проверьте исправления и зафиксируйте результат

Повторно сопоставьте исправленную запись с источником и проверьте журнал изменений. Пересчитайте связанные остатки и статусы. Сохраните отметку о сверке с периодом, исполнителем и перечнем открытых расхождений. Для закрытого вопроса укажите подтверждение результата. Следующий ответственный должен видеть, что проверили, что исправили и какое действие ещё ожидает выполнения.

Закрытая задача сохраняет историю решения. Не удаляйте расхождение после исправления: оно объясняет, почему и на каком основании изменили запись.

Где чаще ошибаются: ручные правки, доступы и данные гостей

Ограничьте операции, которые могут уничтожить историю или исказить расчёт: удаление брони, перезапись суммы, свободный ввод статусов и изменение формулы остатка. В предлагаемом порядке права сотрудников соответствуют их рабочим задачам. Возможности разграничения доступа, сохранения событий и восстановления данных нужно проверить в выбранном инструменте до переноса рабочих записей.

Свободный ввод порождает неоднозначные значения: «оплата есть», «внесено», «всё оплачено». Назначьте справочник статусов и объясните основания переходов. При нехватке состояния согласуйте новое значение, затем обновите справочник для всех сотрудников.

Перезапись цены без события стирает объяснение остатка. Удаление отменённой брони обрывает связь с возвратом. Смешение обеспечительного платежа с оплатой проживания может скрыть долг гостя. Ручное изменение вычисляемого остатка нарушает связь суммы с операциями.

Формулу защитите от случайной правки.

Разделите права просмотра, изменения условий и работы с расчётами. Используйте отдельные учётные записи сотрудников: общий логин не позволяет надёжно различать авторов правок. При увольнении или смене задач включите проверку доступов в предлагаемый внутренний порядок. Для справочников определите ответственного за изменения.

Запись имени сотрудника вручную не заменяет проверку автора события. Если инструмент не сохраняет пользователя и время правки, отметьте это ограничение. Не описывайте такой журнал как защиту от незаметного изменения истории.

В общем реестре оставьте необходимые рабочие сведения и ссылку на контактную карточку с ограниченным доступом. Предлагаемый минимум для сверки — ID брони, объект, условия, суммы и статусы. Паспортные данные и сканы документов в этот рабочий набор не включайте.

Состав данных и порядок доступа требуют отдельного решения.

Предусмотрите резервное копирование и проверку восстановления на обезличенных данных. Убедитесь, что восстанавливаются связи между бронями, операциями и журналами. Восстановление старой версии не должно незаметно стирать события, внесённые после создания копии.

Для исправления ошибочной платёжной записи закрепите отдельный порядок. Сохраните исходную запись, причину исправления и связь с корректировкой. Не называйте корректировку возвратом, если деньги фактически не переводили: иначе журнал покажет вымышленное движение средств.

При подготовке требований к проекту софта Rent System для посуточной аренды эти операции можно использовать как контрольные сценарии. Здесь описан предлагаемый порядок учёта, а не подтверждённые функции разрабатываемого продукта.

Как проверить, что реестр готов к ежедневной работе

Проверьте реестр на условных данных до переноса рабочих записей. Создайте бронь, внесите частичную оплату, перенесите даты, оформите отмену с возвратом и распределите общую выплату площадки. Результат должен позволять найти запись по ID, воспроизвести остаток по операциям, восстановить прежние условия и увидеть ответственного за каждое открытое расхождение.

Для проверки используйте связанные события и отдельную операцию общей выплаты. Так сотрудник увидит, сохраняет ли реестр связь между первоначальными условиями и последующими решениями. Все тестовые записи пометьте как учебные, чтобы они не попали в рабочую сверку.

Проверку проводит сотрудник, который не создавал учебные записи. Ему нужны ID и доступ к основаниям, без устного объяснения каждого шага. Если расчёт понятен только автору таблицы, уточните поля или инструкцию.

Особенно проверьте возврат.

Сначала отметьте согласованный возврат без перевода денег, затем добавьте условную выполненную операцию. Остаток по фактическим платежам должен измениться только после второй записи. Проверка показывает, разделяет ли реестр решение и движение средств.

Если сценарий не проходит, сформулируйте конкретное требование: постоянный ID, связь возврата с оплатой, сохранение прежнего значения или ограничение доступа к формуле. Экспорт, историю и права сотрудников проверяйте по документации и пробной работе выбранного инструмента. Не заменяйте проверку предположением о том, что функция должна быть доступна.

Рабочий реестр позволяет объяснить каждую сумму и каждое изменение по сохранённым основаниям.

После проверки проведите пробную ежедневную сверку и сохраните её результат. Затем внесите недостающие правила в короткую инструкцию: где находятся подтверждения, кто исправляет записи и как передают открытые вопросы. Укажите, какие ограничения инструмента пока остаются.

Чтобы обсудить требования к рабочему реестру, оставьте заявку на странице проекта софта Rent System. Софт находится в разработке; перечисленные сценарии не означают, что эти функции уже доступны.

Частые вопросы

Как передать реестр другому управляющему?

Подготовьте копию данных, справочники и инструкцию по связям между записями. Передайте доступ к подтверждениям через согласованный порядок. Новый управляющий проверяет открытые расхождения и пробный расчёт остатка. После передачи пересмотрите доступы прежних сотрудников.

Что делать, если менеджер обнаружил ошибку в закрытой брони?

Откройте расхождение, сохраните исходное значение и найдите подтверждение. Исправление внесите новым событием с причиной. Если ошибка затрагивает расчёты или документы, передайте вопрос ответственному за соответствующий участок.

Как начать учёт, если старые переписки сохранились не полностью?

Отделите подтверждённые сведения от непроверенных. Для неизвестных условий создайте вопросы с ответственным и следующим действием. Не восстанавливайте цену или оплату по памяти. Начните с действующих броней и незавершённых расчётов.

Источники

Материалы поставщиков по теме учёта бронирований. Поля, статусы, формулы и последовательность проверки в статье — предлагаемый внутренний порядок редакции. Они не описывают обязательные требования или подтверждённые возможности Rent System.

• Система бронирования в посуточной аренде — тематическая публикация RealtyCalendar.
• Программа для сдачи квартир — описание продукта MaxiBooking.