Как сравнить две версии таблицы и найти изменения в данных

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

Построчное сравнение по позиции ненадёжно: после сортировки строка № 12 в первом файле может оказаться строкой № 40 во втором. Сопоставлять нужно по смыслу, используя идентификатор, который сохраняется между выгрузками: номер заказа, код товара, инвентарный номер, сочетание даты и номера операции. Это и есть ключ строки.

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

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

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

Перед сравнением сохраните исходные файлы отдельно и назовите их с датой, источником и версией. Например: «остатки_склад_2026-09-21.csv» и «остатки_склад_2026-09-24.csv». Не перезаписывайте старый файл новой выгрузкой: без исходной версии нельзя проверить спорную строку или повторить анализ.

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

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

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

После сопоставления выводите три категории с недвусмысленными названиями:

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

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

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

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

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

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

Не называйте удаление отменой, а добавление — созданием, если система не знает, что произошло в источнике. Сравнение двух снимков фиксирует разницу, но само по себе не доказывает причину. Запись могла исчезнуть из-за фильтра, перемещения в архив или ошибки выгрузки. Точная формулировка результата: «нет в новой версии», а не «удалена пользователем».

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

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

**Изменилась структура.** Новый столбец не означает, что у каждой записи появилось новое значение; возможно, раньше показатель просто не выгружали. Отразите изменение схемы отдельно от изменений строк. Аналогично удалённый столбец не должен создавать пометку «очищено» для каждой записи, если поля больше нет в версии.

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

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

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

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

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

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

В старой выгрузке три строки с кодами A-14, B-08 и C-22. В новой — A-14, B-08 и D-31. Код A-14 присутствует в обеих версиях, но цена изменилась: это одна изменённая запись. B-08 совпадает по проверяемым полям. C-22 есть только в старом файле, D-31 — только в новом.

В сводке будет: одна добавленная запись, одна удалённая, одна изменённая и одна неизменённая. В строке A-14 пользователь увидит поле «Цена», прежнее значение и новое. Если сортировка в двух файлах разная, результат останется тем же, потому что пары собраны по коду, а не по позиции.

Если код C-22 встречается дважды, автоматическую сверку нельзя считать однозначной. Сначала нужно уточнить, действительно ли это две разные позиции, добавить вариант или склад в составной ключ либо исправить дубли. Иначе счётчики изменений могут выглядеть аккуратно, но содержать неверные пары.

**Сравнивать строки по номеру.** После сортировки позиции меняются. Используйте устойчивый ключ и проверяйте его уникальность.

**Считать отсутствие строки доказанным удалением.** Запись могла исчезнуть из-за фильтра или смены периода. Называйте результат наблюдаемым фактом и указывайте охват выгрузки.

**Объединять пусто и ноль.** Это разные значения во многих предметных областях. Задайте правило для каждого столбца до сравнения.

**Показывать только цвет.** Пользователь может не различить оттенки, распечатать отчёт или открыть его в другом приложении. Добавьте текстовую метку и явные значения «до/после».

**Молчаливо сопоставлять дубли.** Автоматический выбор первой пары создаёт ложную уверенность. Отправляйте повторные ключи на разбор.

**Экспортировать результат без версии источников.** Через неделю отчёт становится трудно повторить. Включите названия сравниваемых файлов и настройки сверки.

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

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

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

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

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

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

Надёжная сверка начинается с устойчивого ключа и сохранённых исходных файлов. Разделяйте добавления, удаления и изменения, показывайте значения до и после, а неоднозначные пары обозначайте явно. Когда вы готовите собственный шрифт для таблиц или служебных надписей, проверьте цифры, дефисы, двоеточия и длинные коды в реальном примере на [Fontgenerator](https://fontgenerator.ru): так проще увидеть, где похожие знаки мешают быстро сравнивать данные.