Каждый администратор и разработчик 1С рано или поздно сталкивается с ситуацией, когда пользователи в процессе работы создают дублирующиеся элементы в справочнике Контрагенты. Для наведения порядка в базе данных традиционно используется стандартная обработка «Поиск и замена дублирующихся элементов» (или «Поиск и замена значений»).
Однако при попытке объединить двух клиентов в конфигурации «Управление торговлей», редакция 10.3 (работающей на обычных формах), система часто выдает неприятную ошибку: «Существуют документы, оформленные по договору "Основной договор". Контрагент договора не может быть изменен, элемент не записан». Процесс слияния прерывается, оставляя дубли на месте. В этой статье мы подробно разберем, почему возникает данная ошибка, и рассмотрим эффективные технические и административные способы ее обхода.
Для начала проанализируем внутреннюю логику конфигурации «Управление торговлей 10.3». Ошибка возникает не из-за сбоя в платформе, а из-за жестко прописанной проверки целостности данных на уровне конфигурации.
В модуле объекта справочника ДоговорыКонтрагентов в процедуре ПередЗаписью содержится программный код, который проверяет, задействован ли данный договор в проведенных документах. Если система находит хотя бы один проведенный документ по этому договору, она блокирует изменение ключевых реквизитов. Одним из таких реквизитов является владелец договора — поле Владелец (ссылка на элемент справочника Контрагенты).
Когда стандартная обработка пытается заменить дублирующегося контрагента на правильного, она «напрямую» пробует перезаписать владельца у существующих договоров дубликата. Натыкаясь на проверку в процедуре ПередЗаписью, транзакция откатывается, и пользователь видит сообщение об ошибке.
Рассмотрим подробнее три основных способа решения этой проблемы — от быстрого программного обхода до аккуратного ручного исправления.
Это самый быстрый и технологичный метод, который активно используют программисты 1С. В платформе 1С:Предприятие предусмотрен специальный режим записи объектов, предназначенный для обмена данными. При его активации система игнорирует стандартные проверки бизнес-логики, расположенные в модулях объектов (включая процедуру ПередЗаписью договора).
Для реализации этого способа мы можем пойти двумя путями.
Путь А: Программное изменение владельца через внешнюю обработку или консоль кода
Перед тем как запускать стандартный поиск и замену дублей, мы можем принудительно переподчинить договоры дублирующегося контрагента «правильному» контрагенту с помощью короткого скрипта. Проанализируем пример такого кода:
ВыборкаДоговоров = Справочники.ДоговорыКонтрагентов.Выбрать(, ДублирующийсяКонтрагент);
Пока ВыборкаДоговоров.Следующий() Цикл
ДоговорОбъект = ВыборкаДоговоров.ПолучитьОбъект();
ДоговорОбъект.Владелец = ПравильныйКонтрагент;
// Отключаем проверку бизнес-логики:
ДоговорОбъект.ОбменДанными.Загрузка = Истина;
Попытка
ДоговорОбъект.Записать();
Сообщить("Договор успешно перенесен: " + ДоговорОбъект.Наименование);
Исключение
Сообщить("Не удалось записать договор: " + ОписаниеОшибки(), СтатусСообщения.Важное);
КонецПопытки;
КонецЦикла;
После выполнения этого кода все договоры дубликата станут принадлежать правильному контрагенту. Теперь стандартная обработка «Поиск и замена дублирующихся элементов» отработает без ошибок, так как ей больше не придется менять владельцев у заблокированных договоров.
Путь Б: Модификация самой обработки поиска и замены
Если вы часто сталкиваетесь с подобной задачей, имеет смысл один раз доработать обработку «Поиск и замена значений» (взяв ее за основу с диска ИТС). Мы можем добавить на форму флаг «Выполнять замену в режиме загрузки данных». При его установке в коде обработки перед вызовом метода Записать() для любого изменяемого объекта (документа, договора или справочника) будет динамически устанавливаться свойство ОбменДанными.Загрузка = Истина.
Если у вас нет прав на выполнение программного кода или отсутствует возможность изменять конфигурацию, проблему можно решить штатными интерактивными средствами. Главное — строго соблюдать правильную последовательность действий.
Разберем этот процесс по шагам:
В среде разработчиков 1С существует множество альтернативных и усовершенствованных обработок для поиска и замены дублей, оптимизированных для работы со старыми конфигурациями на обычных формах (такими как УТ 10.3 или УПП 1.3). Многие из них умеют:
Использование таких инструментов значительно экономит время администратора базы данных.
Если объем документов в базе огромен, а проведение за прошлые периоды жестко закрыто (или может исказить финансовую отчетность и последовательность партионного учета), изменять проведенные документы крайне нежелательно. В этом случае мы рекомендуем использовать организационный метод контроля дублей:
Контрагенты специальную группу (папку) с названием, например, «_ПОМЕЧЕННЫЕ НА УДАЛЕНИЕ (НЕ ИСПОЛЬЗОВАТЬ)». Использование спецсимвола или подчеркивания в начале названия позволит этой папке всегда находиться в самом низу или верху списка.«ДУБЛЬ_ООО Ромашка»). Это исключит его случайный выбор менеджерами при создании новых документов.Помните, что появление дублей — это следствие отсутствия регламентов. Для предотвращения подобных проблем в будущем настройте права доступа пользователей (запретите рядовым менеджерам создавать контрагентов без согласования) и проведите их обучение.
Какой бы из способов вы ни выбрали, всегда соблюдайте правила безопасности при работе с метаданными 1С:
ОбменДанными.Загрузка = Истина, необратимы. Перед началом работы создайте резервную копию базы данных (файловый вариант — скопируйте файл 1Cv8.1CD, клиент-серверный — сделайте бэкап средствами SQL Server).