Я не называю импорт данных загрузкой, пока проверка и применение живут в одной кнопке

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

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

Сначала показать, потом менять

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

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

Файл — не источник истины сам по себе

Даже аккуратный Excel или выгрузка из другой системы не должны автоматически командовать живой базой. У каждой строки есть вопрос: с чем она должна совпасть? По внешнему коду, по договору, по адресу, по комбинации полей? Если этот ответ не зафиксирован, совпадение по названию легко заменит одну сущность другой.

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

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

Проверяйте не только формат

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

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

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

Не применяйте пакет дважды

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

Для крупных операций я бы добавил короткое подтверждение перед применением: вот количество новых записей, вот количество обновлений, вот список исключений. Это не бюрократия. Это последняя точка, где владелец процесса может заметить: «мы собирались загрузить 200 позиций, почему тут 20 000?»

История важнее красивого финального сообщения

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

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

Как я бы проверил новый импорт

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

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

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

Хороший импорт не прячет ответственность

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

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