← На главную

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

Ограничения типовых инструментов БСП и платформы

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

При этом штатный алгоритм выполняет следующие действия:

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

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

Кнопки с названиями вроде «Поменять местами», встречающиеся в некоторых внешних обработках поиска и замены значений, не выполняют перекрестный обмен в базе данных. Они лишь меняют местами значения в полях формы (меняя местами образец для поиска и целевое значение для подстановки), оставляя саму замену строго однонаправленной.

Способ 1. Трехэтапная замена через промежуточный объект

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

Последовательность действий включает следующие шаги:

1. В соответствующем справочнике создается временный служебный элемент (например, с наименованием «Временный_Буфер»).
2. С помощью штатной обработки поиска и удаления дублей или обработки замены ссылок выполняется замена ссылок первого сотрудника на созданный временный элемент.
3. С первого сотрудника снимается пометка на удаление, которую типовая обработка устанавливает автоматически в процессе слияния.
4. Выполняется вторая замена: ссылки второго сотрудника заменяются на первого сотрудника.
5. Со второго сотрудника также снимается установленная обработкой пометка на удаление.
6. Выполняется третья замена: ссылки с временного служебного элемента заменяются на второго сотрудника.
7. Временный служебный элемент, ссылки на который больше нигде не используются, удаляется стандартной процедурой удаления помеченных объектов.

При использовании программных механизмов БСП, таких как вызов экспортных методов модулей ПоискИУдалениеДублей или ОбщегоНазначения (процедура ЗаменитьСсылки), принцип остается тем же: в структуру замен нельзя передавать циклическую пару без транзитного элемента, так как обработка коллекций записей выполняется последовательно.

Способ 2. Изменение реквизитов в карточках элементов

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

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

Однако применимость этого варианта существенно ограничена архитектурой конкретной конфигурации:

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

Недопустимость прямой модификации таблиц СУБД

Иногда высказывается предположение о возможности обмена ссылками путем прямых SQL-запросов к таблицам СУБД с обновлением полей ссылочных идентификаторов. Подобный подход категорически не рекомендуется по следующим причинам:

• Прямое изменение данных в таблицах СУБД в обход сервера «1С:Предприятие» нарушает условия лицензионного соглашения.
• Платформа 1С использует кэширование метаданных и объектных данных, поэтому изменения, внесенные на уровне СУБД, вызывают рассинхронизацию серверного кэша.
• При прямом обновлении SQL-таблиц не отрабатывают прикладные подписки на события, не проверяются правила ссылочной целостности и не пересчитываются итоги регистров, что с высокой вероятностью приводит к скрытому разрушению информационной базы.

Обязательные подготовительные действия

Массовая замена ссылок затрагивает ключевые таблицы базы данных и приводит к блокировкам и модификации существенного объема записей. Перед выполнением любых операций по замене необходимо:

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