Как выполнить свёртку или ограничить объем данных при создании узла РИБ в 1С:Розница 3.0 и 1С:УНФ

Переход с конфигурации 1С:Розница 2.3 на новую версию 3.0 (или на УНФ) часто вызывает вопросы у технических специалистов, привыкших к определенным механизмам распределенных информационных баз (РИБ). Одной из самых востребованных функций в 2.3 была возможность указать Дату свёртки непосредственно при создании подчиненного узла. Это позволяло выгружать в магазин «легкую» базу только с актуальными остатками и документами за текущий год. В 1С:Розница 3.0 и 1С:УНФ этот параметр исчез из настроек синхронизации. Проанализируем ситуацию и разберем, как добиться аналогичного результата в современных конфигурациях.

Почему изменился механизм РИБ

Прежде всего, разберем причину изменений. Версия Розница 2.3 строилась на архитектуре, близкой к старым решениям, где механизмы обмена были глубоко кастомизированы. Розница 3.0 разработана на базе 1С:Управление нашей фирмой (УНФ) и использует современные Библиотеки стандартных подсистем (БСП). В актуальных версиях БСП для «Полного» обмена в РИБ заложена концепция идентичности данных. Предполагается, что периферийный узел должен полностью дублировать структуру и состав данных центрального узла, если не используются специальные фильтры по организациям или складам.

Вариант 1: Использование штатной обработки «Свёртка информационной базы»

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

Выполним следующие шаги:

1. Перейдем в раздел Настройки — Сервис — Свертка информационной базы.
2. Проанализируем период: выберем дату, на которую будут сформированы остатки. Программа автоматически создаст документы Ввод остатков по всем регистрам.
3. Запустим процесс формирования остатков. По завершении система пометит на удаление все документы до даты свёртки (для ускорения процесса при больших объемах рекомендуется фоновое удаление документов).
4. Важный технический момент: само по себе помечание на удаление и даже физическое удаление объектов из интерфейса не уменьшает размер файла .1CD в файловом варианте. Чтобы освободить место, нам необходимо зайти в Конфигуратор и выполнить Тестирование и исправление с установленным флагом Сжатие таблиц информационной базы.

Вариант 2: Переход на синхронизацию через формат EnterpriseData

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

Посмотрим на преимущества этого метода:

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

Однако стоит учитывать, что при таком подходе не переносятся настройки пользователей, макеты печатных форм и расширения (если они не установлены в обоих узлах независимо).

Вариант 3: Создание новой базы через «Выгрузку и загрузку данных XML»

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

Алгоритм действий будет следующим:

1. Создаем новую пустую базу той же версии конфигурации.
2. В старой базе выполняем свёртку (как описано в Варианте 1), чтобы получить документы Ввод остатков.
3. С помощью обработки выгружаем все справочники и только документы Ввод остатков.
4. Загружаем данные в новую базу.

Этот метод позволяет полностью избавиться от «мусора», логов регистрации и истории изменений, которые часто переезжают вместе с узлом РИБ, продолжая занимать место.

Проблема производительности файловых баз в Рознице 3.0

Выясним причину, по которой пользователи чаще стали сталкиваться с необходимостью свёртки. Архитектура Розницы 3.0 / УНФ более сложная, чем у Розницы 2.3. Здесь активно используется версионирование объектов и хранение дополнительных аналитик в регистрах. Это приводит к тому, что файловая база (.1CD) растет значительно быстрее. Если размер файла приближается к 4–6 Гб, никакая свёртка не даст долгосрочного прироста скорости.

В такой ситуации настоятельно рекомендуем рассмотреть переход на клиент-серверный вариант (SQL). Для небольших розничных точек эффективным решением будет использование бесплатной СУБД PostgreSQL. Это снимает ограничения на размер таблиц и существенно повышает стабильность работы при многопользовательском доступе.

Особенности РИБ и регистрации изменений

Разберем типичную ошибку: попытку вручную удалить данные в периферийном узле РИБ в Рознице 3.0. Если вы просто удалите старые документы в подчиненной базе, при следующей синхронизации механизм РИБ увидит, что в главном узле эти данные есть, а в подчиненном — нет. Система может попытаться либо восстановить их, либо зафиксировать коллизию.

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

ПланыОбмена.УдалитьРегистрациюИзменений(УзелОБмена, Тип("ДокументСсылка.Продажа"));
// Данный код очищает очередь выгрузки для конкретного типа объекта, 
// чтобы старые данные не пытались синхронизироваться.

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