← На главную

При администрировании крупных баз данных «1С:Предприятие 8.3» часто возникает задача оптимизации производительности или разделения учета перед началом нового отчетного периода. Один из популярных вариантов — создание распределенной информационной базы (РИБ), где в подчиненном узле должна начаться работа «с чистого листа», но при этом необходимо сохранить синхронизацию справочников и настроек с центральной базой.

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

В чем кроется опасность создания РИБ из пустого файла конфигурации (.cf)?

Для того чтобы понять природу возникновения дублей, проанализируем внутреннее устройство современных конфигураций на базе БСП (Библиотеки стандартных подсистем), к которым относится и «1С:Бухгалтерия предприятия 3.0».

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

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

Когда вы попытаетесь связать такую «чистую» базу с центральной через механизм РИБ, стандартная система обмена, ориентированная исключительно на сопоставление по GUID, не сможет сопоставить эти элементы. Платформа воспримет их как разные объекты. В результате произойдет массовое дублирование служебных данных: появятся две валюты «руб.», два предопределенных счета «20.01», дубли ставок НДС и ключевых регистров сведений. База станет полностью непригодной для ведения учета.

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

Сценарий 1. Временное изменение состава плана обмена (Решение с форума)

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

Разберем этот алгоритм по шагам:

1. Создаем копию центральной базы. Все манипуляции крайне важно производить на копии рабочей базы, чтобы не мешать текущим пользователям и случайно не повредить боевую конфигурацию.
2. Корректируем состав плана обмена в копии. Открываем копию базы в режиме «Конфигуратор». Находим интересующий нас план обмена (например, ПланыОбмена.Полный или ПланыОбмена.ПоОрганизациям). Переходим на вкладку «Состав» и временно снимаем флаги авторегистрации (или полностью исключаем из состава) со всех документов, регистров накопления, регистров бухгалтерии и регистров сведений, содержащих движения. Справочники, константы, классификаторы и планы счетов обязательно оставляем в составе.
3. Создаем начальный образ подчиненного узла. Запускаем копию базы в режиме «Предприятие» и создаем начальный образ для нового подчиненного узла. Поскольку в составе плана обмена остались только справочники и настройки, созданный начальный образ будет содержать всю необходимую системную информацию с оригинальными GUID, но в нем не будет ни одного документа и ни одной проводки.
4. Восстанавливаем оригинальную конфигурацию. Теперь нам нужно вернуть измененную структуру плана обмена в исходное состояние. Для этого выгружаем оригинальный файл конфигурации .cf из центральной рабочей базы и загружаем его через конфигуратор как в нашу копию, так и в созданный чистый подчиненный узел.
5. Устанавливаем связь и запускаем обмен. Подключаем очищенный узел к центральной базе. При первом обмене платформа сопоставит конфигурации, а справочники синхронизируются идеально «один в один», поскольку их уникальные идентификаторы полностью совпадают.

Сценарий 2. Создание копии с последующей программной очисткой

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

Схема действий выглядит следующим образом:

1. Снимаем полную копию с центральной информационной базы.
2. Открываем копию в монопольном режиме. Нам необходимо программно «отвязать» базу от главного узла, превратив ее в самостоятельную. Для этого используем запуск с параметром командной строки /ResetMasterNode или выполняем следующий код во внешней обработке: ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
3. Запускаем процедуру очистки документов. Поскольку база теперь не связана с РИБ, мы можем безопасно удалить все документы, используя стандартную обработку «Групповое изменение реквизитов» (пометить на удаление и запустить удаление помеченных объектов). Также можно воспользоваться специализированными скриптами для быстрой очистки таблиц документов. Важно: не пытайтесь удалять таблицы напрямую через СУБД (SQL) запросами TRUNCATE или DELETE, если вы не уверены на 100% в структуре физических таблиц. Это может привести к появлению «битых» ссылок и фантомных записей в таблицах итогов регистров, которые потом крайне сложно вычистить средствами ТИС (Тестирование и исправление). Используйте штатные объектные методы удаления в 1С.
4. После того как документы и движения удалены, а справочники и классификаторы остались нетронутыми, мы программно привязываем эту базу обратно к центральному узлу в качестве подчиненного. Для этого выполняем код:
   Скопировать код

   
   СсылкаНаЦентр = ПланыОбмена.Полный.НайтиПоКоду("ЦН"); // "ЦН" - код центрального узла
   Если ЗначениеЗаполнено(СсылкаНаЦентр) Тогда
       ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаЦентр);
       Сообщить("Узел успешно назначен подчиненным!");
   КонецЕсли;
   

5. Сбрасываем номера принятых и отправленных сообщений в обмене в обеих базах на «0», чтобы синхронизация началась корректно, без конфликтов номеров пакетов.

Сценарий 3. Использование переносимых XML-данных (Выгрузка/Загрузка XML)

Для ИТ-специалистов, предпочитающих полный контроль над переносимыми объектами, отлично подойдет вариант с использованием универсальной обработки «Выгрузка и загрузка данных XML» (ее можно найти на ИТС или в составе инструментов разработчика).

Главное преимущество этой обработки — она выгружает данные в формате XML с обязательным сохранением оригинальных UUID всех объектов.

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

1. Создаем новую чистую базу из оригинального .cf центральной базы.
2. При первом запуске новой базы по возможности отменяем или пропускаем автоматические шаги заполнения и настройки классификаторов БСП.
3. В центральной базе открываем обработку «Выгрузка и загрузка данных XML» и выбираем для выгрузки только справочники, константы, планы видов характеристик и планы счетов. Документы и регистры движений полностью исключаем из выгрузки. Получаем файл данных.
4. В новой пустой базе открываем эту же обработку и загружаем полученный XML-файл. Произойдет загрузка справочников, причем все предопределенные элементы и настройки перезапишутся правильными системными GUID из центральной базы.
5. После успешной загрузки программно объявляем эту базу подчиненным узлом РИБ с помощью метода ПланыОбмена.УстановитьГлавныйУзел(), как было описано во втором сценарии.

Сценарий 4. Штатный механизм БСП «РИБ с фильтрами»

В современных релизах «1С:Бухгалтерия предприятия 3.0» встроен продвинутый механизм обмена БСП, который позволяет решить задачу без «хакерских» манипуляций с планами обмена и кодом.

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

1. Перейдем в раздел «Администрирование» — «Синхронизация данных» — «Настройки синхронизации».
2. При создании новой настройки выберем пункт «Распределенная информационная база (РИБ) с фильтрами».
3. В настройках фильтрации укажем дату начала выгрузки документов (например, начало следующего отчетного периода или текущий день). Также можно установить отбор по конкретным организациям.
4. Запустим создание начального образа.

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

Выводы и рекомендации

Выбор конкретного метода зависит от масштаба вашей информационной базы и ваших технических навыков:

• Если вы работаете на актуальном релизе БП 3.0 и вам нужно отсечь документы по дате, оптимальным выбором будет Сценарий 4 (РИБ с фильтрами).
• Если вам требуется получить абсолютно пустую от транзакций базу, но со сложными настройками НСИ, воспользуйтесь Сценарием 1 (Изменение состава плана обмена) или Сценарием 2 (Очистка отвязанной копии).
• Ни в коем случае не пытайтесь связывать пустую базу из .cf напрямую с рабочей базой через РИБ без предварительной подготовки справочников — исправление последствий появления дублей GUID в рабочей базе может потребовать колоссальных временных затрат.