Как провести переезд с другой PMS без потери броней?

Переезд между гостиничными системами срывается не из-за кнопки «Импорт». Брони теряются раньше: когда владелец просит у прежнего вендора «всю базу», получает одну таблицу без оплат и номеров ОТА, а потом открывает продажи из новой системы, не сверив остатки по датам.

Безопасный переезд состоит из трех отдельных работ: забрать данные, доказать совпадение будущей загрузки и передать управление каналами ровно одной системе. Новая шахматка может выглядеть правильно и при этом продавать уже занятый номер. Поэтому критерием готовности служит не красивый экран, а сверка каждой активной брони и каждого остатка на контрольном горизонте.

Переезд начинается с контрольной даты, а не с экспорта

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

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

Основную выгрузку делайте заранее, чтобы успеть очистить данные. После нее прежняя PMS остается рабочей, но администратор записывает каждое изменение в отдельный дельта-журнал. Для маленького объекта достаточно таблицы со столбцами «время», «номер брони», «что было», «что стало», «кто изменил», «внесено в новую PMS». В эту таблицу попадает даже исправленный телефон: иначе гость позвонит, а в новой карточке останется старый контакт.

Не назначайте переключение на полночь только потому, что календарные сутки выглядят аккуратно. В гостинице важнее фактическое движение гостей. Подходящее окно начинается после последнего планового заезда и заканчивается до первого выезда или утренней смены. Если в 02:30 ожидается гость с самостоятельным заселением, это тоже заезд, хотя стойка закрыта.

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

У прежнего вендора нужно забрать четыре набора данных

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

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

В денежном наборе разделите полную стоимость, фактические оплаты, возвраты, удержания и долг. Поле «оплачено» без даты и способа платежа не заменяет журнал операций. При переносе нельзя превращать внесенные 12 000 рублей в новую оплату сегодняшним числом, если бухгалтерский учет и касса уже отражают ее в прошлом периоде. В новой PMS такая сумма может храниться как начальный баланс или информационная предоплата, порядок зависит от возможностей системы и вашей учетной политики.

Гостевой набор содержит ФИО, телефон, электронную почту, гражданство, дату рождения и реквизиты документа лишь в том объеме, который нужен для действующего проживания и законной работы объекта. Не отправляйте паспортные данные обычной почтой по привычке. Согласуйте с обоими вендорами защищенный способ передачи, круг сотрудников с доступом и срок удаления промежуточных файлов. После импорта временные копии не должны годами лежать в папке «Загрузки».

Справочники включают категории, физические номера и койки, варианты размещения, тарифы, источники, компании и агентства, дополнительные услуги, ограничения продаж и сопоставления с каналами. Экспорт справочников часто забывают, а потом категория «Стандарт двухместный» из старой PMS встречает «DBL Standard» в новой. Импорт не знает, что это одно и то же, пока человек не составит карту соответствий.

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

Инструкция Bnovo по экспорту хорошо показывает неприятную особенность старых PMS: бронирования можно выгружать по разным вкладкам и фильтрам, а файл содержит только то, что пользователь открыл. Я бы не принимал архив с названием «bookings.xlsx» без снимка фильтров и количества строк. Один неверный статус в фильтре тихо убирает из переноса целую группу гостей.

Файл для переноса должен читаться без прежней PMS

Рабочий файл должен быть самодостаточным: одна строка описывает одну бронь или одну часть групповой брони, а значения понятны без цветных ячеек и комментариев «как обычно». Лучший обменный формат для небольшого объекта - XLSX с фиксированными столбцами либо CSV в UTF-8, если обе стороны заранее согласовали разделитель и формат дат.

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

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

legacy_booking_id;external_booking_id;source;status;arrival_date;arrival_time;departure_date;departure_time;room_type_old;room_old;adults;children;guest_last_name;guest_first_name;phone;total_amount;paid_amount;currency;last_changed_at;comment
OLD-1842;OTA-771903;Ozon Travel;confirmed;2026-08-14;14:00;2026-08-18;12:00;Стандарт 2м;203;2;1;Иванова;Анна;+79990000000;28600.00;10000.00;RUB;2026-07-29 16:42;Детская кроватка

Дата должна иметь один формат во всех строках. Для CSV удобно использовать YYYY-MM-DD, время хранить отдельно как HH:MM, деньги передавать числом без пробелов и знака рубля, а кодировку фиксировать как UTF-8. Если импортный шаблон требует ДД.ММ.ГГГГ, преобразуйте копию, но сохраните исходный файл без правок.

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

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

Сделайте лист README или отдельную записку к файлу. Укажите дату и время выгрузки, часовой пояс, фильтры, число строк по статусам, формат сумм, расшифровку статусов и контакт человека, который понимает старую систему. Через неделю даже автор выгрузки забудет, чем «закрыта» отличается от «выехал».

Категории и номера сопоставляют до первой загрузки

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

Карта соответствий может содержать четыре строки:

• «Стандарт 2м», номер 203 переходит в «Стандарт», номер 203 без изменения.
• «Эконом Twin», номер 7 переходит в «Эконом с двумя кроватями», номер 107 после переименования.
• «DBL+EXB» переходит в «Стандарт с допместом» как вариант размещения, а не отдельная категория.
• Номер 12 на ремонте переходит в номер 112, но продажи на него остаются закрытыми.

Чаще всего ошибаются с виртуальными категориями. Старый менеджер каналов мог держать «двухместный с завтраком» как отдельный вариант, хотя физически это тот же номер, что «двухместный без питания». Если создать два независимых номера в новой PMS, остаток удвоится. Тариф, питание, число гостей и физический номер надо разнести по своим сущностям.

С койками в хостеле обратная проблема. Бронь категории «Койка в женском номере» занимает одну койку, а не весь номер. Если импорт посадит ее на комнату целиком, система занизит остаток; если групповую бронь на четыре койки запишет одной строкой без количества мест, остаток завысится. До импорта определите, что именно считает единицей каждая категория.

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

После настройки загрузите две-три сложные записи вручную: групповую бронь, переселение между номерами, бронь с ребенком или допместом, частично оплаченную бронь из ОТА. Посмотрите, куда попали даты, люди, деньги и источник. Если тест не проходит, массовый импорт умножит ошибку на сотни строк.

Остатки сверяют по каждой дате и категории

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

Для каждой категории и даты посчитайте:

остаток = физический фонд - занятые единицы - технические блокировки - жесткие квоты

Считайте по ночам, а не по календарным событиям. Гость с заездом 10 августа и выездом 12 августа занимает ночь 10 на 11 и ночь 11 на 12, но не ночь после выезда 12 августа. Ранний заезд и поздний выезд могут влиять на уборку, однако не создают дополнительную ночь без отдельного правила объекта.

Постройте матрицу минимум на 90 дней, а лучше на весь открытый горизонт продаж. В строках будут категории, в столбцах - даты, в ячейках - остаток. Рядом нужны такие же матрицы из старой PMS, новой PMS и экстранета каждого крупного канала. Формула сравнения примитивна: разница = новый остаток - старый остаток. Любое ненулевое значение требует объяснения до открытия продаж.

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

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

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

Автоматический импорт не переносит смысл брони

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

Свежая инструкция Bnovo по импорту из другой PMS дает полезный пример таких потерь. Она прямо предупреждает, что импортированные брони получают основной тариф, количество проживающих становится равным одному, связанные брони разделяются, а статусы и отмены из ОТА дальше не синхронизируются для строк, пришедших из Excel. Дата создания брони также может стать датой импорта. Это не дефект конкретной кнопки, а честное описание границы табличного переноса.

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

Будущие брони из каналов требуют отдельного согласования. Некоторые подключения при первом запуске сами забирают будущие заявки из ОТА. Если те же строки уже загрузили из Excel, появятся дубли. Инструкция Bnovo советует не добавлять вручную будущие брони ряда каналов, которые система подтянет после подключения. Для другой PMS список и поведение будут иными, поэтому получите ответ по каждому каналу, а не распространяйте одно правило на все подключения.

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

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

Менеджер каналов переключают с нулевыми остатками

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

Проведите переключение в таком порядке:

1. Закройте продажи или установите нулевое наличие из действующего менеджера каналов на согласованный период, затем проверьте результат в экстранетах ОТА.
2. Заберите финальную дельту новых, отмененных и измененных броней, внесите ее в новую PMS и повторите сверку ближайших дат.
3. Отключите старую связку на стороне каждого канала, а не только удалите канал в интерфейсе прежней PMS.
4. Подключите новый менеджер с нулевым наличием, сопоставьте категории и тарифы, проверьте цены, ограничения и прием будущих броней.
5. Передайте тестовый остаток на одну дальнюю дату, убедитесь в журнале обмена и экстранете, затем открывайте весь согласованный горизонт.

Пункт об отключении на стороне ОТА часто пропускают. Инструкция Bnovo по удалению каналов прямо говорит: удаление канала внутри PMS не останавливает синхронизацию на стороне площадки; статус отключения может обновляться до 24 часов. Это хороший повод запросить порядок и сроки заранее, а не выяснять их в ночь переезда.

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

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

Во время переключения держите телефоны поддержек и идентификаторы объекта под рукой: ID объекта в ОТА, старый и новый ID подключения, категории, тарифы, номера договоров и заявки на смену провайдера. Фраза «у нас не обновляется июль» без ID заставит поддержку сначала искать объект, пока продажи закрыты.

Окно запуска должно помещаться между движением гостей

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

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

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

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

Определите условия отмены запуска заранее. Например, вы не открываете продажи, если расходится хотя бы один остаток на ближайшие 30 дней, отсутствует бронь с заездом в течение недели, неясен статус подключения крупного канала или новая PMS неверно считает койки. При таком условии команда не спорит в 01:00, достаточно ли «почти все».

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

Старую систему сохраняют в режиме чтения

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

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

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

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

Плацкарт принимает миграцию из Excel или другой PMS и дает рабочую шахматку в первый день, но исходную выгрузку и контрольные суммы все равно должен подтвердить владелец объекта. Ни одна система не узнает, что в строке забыли групповую бронь, если ее нет ни в файле, ни в журнале изменений.

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