Перенос с чужой CRM: почему это не выгрузка и загрузка, а сверка каждой цифры

Всё лето мы переводили точки сети с чужой CRM — HelloClient — на свою. На бумаге задача звучит просто: выгрузить заказы, клиентов и историю из одной системы, загрузить в другую. На практике это заняло в разы больше времени, чем мы закладывали, и почти всё это время ушло не на перенос, а на сверку.

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

Скидка считалась не на то, на что мы думали

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

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

Часовой пояс точки никуда не переехал

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

Починили это только тогда, когда завели явную привязку IANA-пояса к каждой точке ещё на этапе справочников — до того, как переносить сами заказы. Урок простой: часовой пояс — это не метаданные, это часть заказа, и переносить его нужно раньше денег, а не после.

Исполнители на услугах приезжали сразу с тринадцати точек

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

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

Что мы теперь делаем иначе

Главный вывод: перенос данных из чужой системы — это не техническая операция «экспорт-импорт», а полноценный аудит того, как устроена чужая модель данных. Прежде чем переносить хоть один заказ, нужно понять: на каком уровне считается скидка, привязан ли часовой пояс к точке, и как устроены связи между сущностями, которые в новой системе выглядят иначе.

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