Как эффективно сравнить две версии табличной части документа в 1С при его перепроведении?

При разработке прикладных решений на платформе 1С часто возникает задача отследить изменения, которые пользователь внес в табличную часть документа. Типичный сценарий: при проведении документа создаются связанные записи (например, путевые листы), и при изменении состава строк (замене автомобиля или удалении маршрута) необходимо актуализировать или удалить уже созданные объекты. Разберем, как правильно подходить к этой задаче.

Почему сложные SQL-запросы — это не всегда лучшее решение

В начале пути многие разработчики пытаются реализовать сравнение через сложные запросы с объединением (ОБЪЕДИНИТЬ ВСЕ) и последующей группировкой данных. Хотя такой подход кажется логичным, он обладает рядом существенных недостатков:

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

Поэтому проанализируем более надежные и профессиональные подходы.

Решение 1: Использование КлючаСтроки

В платформе 1С каждая строка табличной части имеет уникальный идентификатор — КлючСтроки. Это самый надежный способ сопоставить состояние «До» и «После».

Рассмотрим пошаговый алгоритм:

1. При получении данных из базы данных до начала транзакции записи (или при использовании версионирования) мы имеем коллекцию старых строк.
2. При проведении документа мы работаем с текущей коллекцией строк в объекте.
3. Используем КлючСтроки как первичный ключ для сравнения.

Если КлючСтроки присутствует в старой версии, но отсутствует в новой — строка была удалена. Если КлючСтроки есть в новой, но нет в старой — добавлена новая строка. Если идентификатор совпадает, но значения полей (например, автомобиль или маршрут) изменились — значит, мы имеем дело с модификацией строки.

Решение 2: Использование регистра сведений для связей

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

Структура регистра:

• ДокументНазначения (измерение)
• НомерСтрокиИлиКлючСтроки (измерение)
• ПутевойЛист (ресурс, ссылка)

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

Решение 3: Левое соединение таблиц

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

Допустим, нам нужно найти строки, которые были в первой таблице, но исчезли из второй. Мы создаем временную таблицу ТаблицаИсходная и ТаблицаРезультат. Далее строим запрос:

ВЫБРАТЬ
    ТаблицаИсходная.Автомобиль,
    ТаблицаИсходная.Номер
ИЗ
    ТаблицаИсходная КАК ТаблицаИсходная
ЛЕВОЕ СОЕДИНЕНИЕ
    ТаблицаРезультат КАК ТаблицаРезультат
ПО
    ТаблицаИсходная.Автомобиль = ТаблицаРезультат.Автомобиль
ГДЕ
    ТаблицаРезультат.Автомобиль ЕСТЬ NULL

Этот метод позволяет быстро выявить те записи, которые пользователь удалил из документа. Аналогично, меняя местами таблицы в соединении, вы найдете добавленные строки.

Общие рекомендации по реализации

Чтобы ваша система работала стабильно, придерживайтесь следующих правил:

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

Подводя итог: самый элегантный способ — это создание регистра связей, который «помнит», какой путевой лист соответствует какой строке документа. Это снимает все вопросы о том, как вычислить изменения — вы просто берете КлючСтроки, находите запись в регистре и обновляете данные путевого листа.