В старой базе один клиент записан трижды: с рабочей почтой, с личной почтой и под названием компании. При переносе разработчик объединяет похожие записи, после чего часть заказов оказывается в чужом кабинете. Ошибка возникла ещё до импорта, когда по сходству полей решили, что записи принадлежат одному человеку.
Дубли клиентской базы нужно разбирать по правилам, согласованным с сотрудниками. Автоматическая проверка может собрать кандидатов на объединение. Решение зависит от того, что именно означает запись: человека, организацию, контактное лицо или отдельный договор.
В статье использован учебный пример поставщика расходных материалов. У него есть сайт, система учёта клиентов и старые таблицы менеджеров. Все названия и ситуации вымышлены. Пять типов совпадений помогут составить план очистки и сохранить связи с заказами.
Сначала определите, какие записи переносите
До поиска дублей составьте карту сущностей. Сущность здесь означает отдельный вид данных, например организацию или контактное лицо. Человек может работать с двумя компаниями, а у одной компании бывает несколько закупщиков. Такая структура естественна и сама по себе не означает ошибку.
В старой таблице эти роли часто смешаны в одной строке. Поле «Клиент» содержит то фамилию, то название организации, то адрес магазина. Перед переносом нужно определить, куда попадёт каждое значение в новой системе и какие связи следует сохранить.
Назначьте каждой исходной записи устойчивый идентификатор. Если в таблице его нет, техническая команда создаёт отдельный номер строки в сохранённой исходной версии. После сортировки или фильтрации запись должна оставаться узнаваемой. Номер текущей строки открытого файла для этого ненадёжен.
Исходную выгрузку сохраняйте без редактирования. Все исправления фиксируйте в отдельной таблице решений. Тогда команда сможет объяснить, почему две записи объединили, и воспроизвести перенос заново. Ручная правка единственного файла лишает проект этой возможности.
Параллельно определите связи, которые нельзя потерять. Для клиента это могут быть заказы, обращения, адреса доставки и права сотрудников. Подход к описанию связей пригодится и при интеграции сайта с учётной системой. Перенос одной контактной карточки без её истории редко решает задачу бизнеса.
Тип 1. Точная копия с разными номерами
Две записи совпадают по всем содержательным полям, но имеют разные внутренние номера. Одна могла появиться после повторного импорта. Это сильный кандидат на объединение, однако сначала проверьте связанные объекты.
В учебной базе у первой записи есть три заказа, у второй сохранён договор. Если удалить вторую строку без переноса связи, договор пропадёт из кабинета. При объединении нужно выбрать итоговую запись и перенаправить к ней все допустимые связи.
Точная копия также может скрывать разный статус. Одна запись активна, другая архивная. Узнайте, почему её закрыли. Возможно, компания перестала работать с этим контрагентом, и автоматическое объединение снова откроет доступ к заказам.
Для такого типа дублей полезна проверка количества связанных объектов до и после переноса. Считать только клиентов недостаточно. Итоговая запись должна содержать ожидаемые заказы и документы, а исходные номера должны находиться в таблице соответствий.
Если источников несколько, запишите приоритет полей. Например, актуальный телефон подтверждает менеджер, адрес доставки берётся из последнего согласованного заказа. Приоритет выбирает бизнес. Дата последнего изменения строки не всегда означает свежесть всех её данных.
Тип 2. Один контакт записан в разном формате
Телефон с кодом страны, скобками и пробелами может обозначать тот же номер, что и строка из цифр. Адрес почты иногда содержит случайный пробел в конце. Такие различия удобно выявлять после подготовки значений для сравнения.
Подготовленная копия поля нужна именно для поиска совпадений. Исходное значение сохраняйте отдельно. Если алгоритм ошибся, сотрудник сможет увидеть, что было в старой системе, и исправить правило без потери данных.
Когда приводите телефоны к единому формату, учитывайте страны, в которых находятся клиенты. Механическое добавление одного кода страны всем коротким номерам может исказить иностранные контакты. Добавочный номер тоже имеет смысл: несколько сотрудников могут использовать общий городской телефон.
Почтовый адрес проверяйте осторожно. Общий адрес отдела закупок принадлежит нескольким сотрудникам. У одного человека рабочая почта могла измениться после переименования компании. Совпадение или различие строки даёт основание для проверки, но не завершает её.
В учебном примере два менеджера занесли контакт «Отдел снабжения» с одинаковым общим телефоном. При этом один ведёт московский филиал, другой работает с региональным складом. Полное объединение способно смешать адреса и ответственных. Команда должна решить, хранит ли новая система филиалы отдельно.
Тип 3. Одна организация представлена несколькими подразделениями
Название компании часто записано с сокращением или без него. В другой строке к названию добавлен город. Поиск похожих названий соберёт такие записи вместе, но бизнесу ещё предстоит определить их устройство.
Проверьте официальные реквизиты по данным, которые компания использует в своей работе. Состав и правила проверки согласуйте с ответственными за договоры сотрудниками. В статье мы рассматриваем перенос данных, поэтому конкретные юридические выводы по реквизитам здесь не делаем.
Одна организация может иметь несколько договоров, складов получения и ответственных менеджеров. Объединение карточек организации не должно уничтожить эти различия. В новой системе они могут стать связанными объектами или отдельными полями по принятой модели.
Учебный поставщик хранит «Ромашка, склад» и «Ромашка, офис» как двух клиентов. После переноса это одна организация с двумя адресами доставки. При этом права сотрудников различаются: кладовщик видит свои поставки, закупщик работает со всеми заказами. Решение затрагивает доступ к данным, поэтому его проверяют вместе с владельцем процесса.
