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