Массовое изменение реквизитов справочников через внешнюю обработку

В крупных базах 1С регулярно возникает задача привести в порядок реквизиты сотен или тысяч элементов справочников, не прибегая к ручной правке. Обработки, открывающие по одному элементу и сохраняющие изменения, занимают слишком много времени у администратора.

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

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

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

Зачем нужна отдельная обработка

Штатный механизм «Групповое изменение реквизитов» работает в пределах одного справочника и не поддерживает сложные условия отбора. Когда нужно связать изменения с данными других таблиц или выполнить вычисления, штатных средств не хватает.

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

Код хранится в системе контроля версий, проходит ревью и поставляется на тестовые стенды. Это снижает риск случайных правок и упрощает аудит изменений.

Сравнение подходов к групповому изменению

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

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

Структура объекта метаданных

Основой служит объект «Внешняя обработка» с реквизитом формы, отвечающим за отбор элементов. В модуле объекта располагаются серверные процедуры, в модуле формы — клиентские обработчики.

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

Список доступных справочников заполняется программно через метаданные. Это сокращает объём ручных настроек и снижает вероятность ошибок при выборе объекта.

Алгоритм перебора элементов

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

Полученную выборку обрабатывают порциями, передавая в метод «Записать()» только элементы, удовлетворяющие условиям. Между итерациями вставляют вызовы обработки ожидания, чтобы избежать блокировок.

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

Транзакции и контроль ошибок

Групповое обновление проводят в рамках явной транзакции, границы которой задают через «НачатьТранзакцию()» и «ЗафиксироватьТранзакцию()». Вложенные транзакции используют только для изолированных блоков.

При ошибке выполняют «ОтменитьТранзакцию()» и записывают подробности в журнал регистрации. Сценарий предусматривает прерывание обработки по команде администратора.

Перед записью проверяют заполненность обязательных полей и корректность ссылочных типов, чтобы исключить появление «битых» ссылок.

Интерфейс и параметры формы

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

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

Команды, изменяющие данные, доступны только пользователям с ролью администратора. Дополнительная проверка через «РольДоступна()» защищает от случайного запуска с недостаточными правами.

Отладка и тестирование

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

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

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

Практические рекомендации

Готовый набор советов помогает избежать типичных ошибок и ускорить внедрение обработки на реальных данных.

• Перед запуском делайте полный бэкап и фиксируйте контрольные суммы файла базы.
• Запрашивайте выборку с явным указанием полей, чтобы снизить нагрузку на сервер.
• Разбивайте обработку на порции по 500-1000 элементов с промежуточной фиксацией.
• Пишите логи изменений в отдельный регистр сведений для последующего аудита.
• Предусматривайте возможность прерывания по команде пользователя с отменой транзакции.
• Тестируйте обработку на копии с реалистичным объёмом данных, а не на десятке элементов.
• Согласовывайте список изменяемых реквизитов с владельцами данных до запуска.

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