Как создать начальный образ РИБ по организации в 1С:ERP и почему этого механизма нет из коробки?

← На главную

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

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

Архитектурный тупик: почему в 1С:ERP нет встроенного РИБ по организации?

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

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

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

Тем не менее, задача разделения баз остается актуальной. Рассмотрим эффективные практические сценарии ее решения.

Метод 1: Программное удаление данных через копию базы (Рекомендуемый метод)

Простое удаление документов через стандартный интерфейс или пометка на удаление с последующим запуском обработки «Удаление помеченных объектов» в ERP практически невыполнимы. Система контроля остатков, проверки проведения и многочисленные подписки на события заблокируют удаление большинства связанных документов. Чтобы обойти эти ограничения, применим низкоуровневое программное удаление на копии базы данных.

Рассмотрим алгоритм действий по шагам:

Создаем полную резервную копию рабочей информационной базы. Все последующие действия выполняются исключительно в этой копии!
Разрабатываем или используем внешнюю обработку, которая будет обходить документы и регистры, подлежащие удалению.
Ключевой момент: все операции удаления и записи объектов необходимо выполнять с установленным свойством ОбменДанными.Загрузка = Истина. Этот режим отключает платформенные и прикладные проверки бизнес-логики (проверки проведения, контроли остатков, проведение по регистрам при записи и т.д.).

Проанализируем пример кода для удаления документов «ненужной» организации:


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

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

Разберем, как программно очистить движения в регистре накопления с отбором по организации:


НаборЗаписей = РегистрыНакопления.ВыручкаИСебестоимостьПродаж.СоздатьНаборЗаписей();
// Устанавливаем отбор по организации, которую мы вырезаем из базы
НаборЗаписей.Отбор.Организация.Установить(ОрганизацияДляУдаления);

// Записываем пустой набор записей, тем самым очищая движения по данному отбору
НаборЗаписей.ОбменДанными.Загрузка = Истина;
НаборЗаписей.Записать();

После завершения работы скрипта очистки в базе обязательно останутся «битые» ссылки. Для их устранения необходимо запустить стандартную утилиту платформы: Администрирование -> Тестирование и исправление информационной базы, установив флаги проверки ссылочной целостности и выбрав вариант «Очищать объекты» или «Удалять ссылки» при наличии неразрешимых связей.

Метод 2: Полуавтоматическое удаление через стандартные обработки

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

Рассмотрим этот процесс подробнее:

Запустите стандартную обработку «Поиск и замена дублей» или «Поиск ссылок на объекты».
Найдите все элементы и документы, связанные с удаляемой организацией.
Для массовой пометки на удаление используйте групповую обработку состава документов. На этом этапе вы столкнетесь с жестким сопротивлением системы: ERP не позволит пометить на удаление документы, на которые ссылаются другие объекты (например, этапы производства, заказы, подчиненные ордера).
Выясним причину блокировки: вам придется двигаться по цепочке связей снизу вверх. Сначала необходимо пометить на удаление самые «глубокие» подчиненные документы — зарплатные ведомости, кассовые ордера, складские акты, цепочки обеспечения и производства. И только после этого переходить к крупным объектам (заказам и реализациям).
Для упрощения процедуры временно отключите контроли в системе. Перейдите в раздел НСИ и администрирование -> Настройка разделов и временно отключите контроли остатков товаров, контроли лимитов денежных средств и ордерные схемы на складах. Это позволит обойти часть платформенных проверок при интерактивном удалении.

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

Метод 3: Использование конфигурации «Конвертация данных» (КД 2.1 / 3.0)

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

Рассмотрим, как это реализовать:

Разверните чистую базу 1С:ERP того же релиза, что и исходная.
С помощью конфигурации «Конвертация данных 2.1» создайте правила обмена между идентичными конфигурациями.
В правилах выгрузки данных (ПВД) для всех ключевых объектов настройте жесткую фильтрацию по реквизиту Организация.
Перенос нормативно-справочной информации (НСИ): Настройте правила так, чтобы справочники (Контрагенты, Номенклатура, Склады) переносились только по ссылкам из переносимых документов. Это предотвратит замусоривание новой базы неиспользуемыми элементами.
Ограничение по периоду и остаткам: Вместо переноса всех документов за несколько лет (что приведет к огромному объему передаваемых данных и сложностям сопоставления), рекомендуется перенести только справочники и документы ввода остатков на начало отчетного периода. Для этого можно использовать стандартные обработки свертки базы и выгрузить уже свернутые остатки по конкретной организации.

Важные нюансы и лицензионная политика

При выполнении работ по разделению баз данных 1С:ERP обязательно обратите внимание на следующие технические и юридические аспекты:

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

Мы подробно разобрали, почему в 1С:ERP нет штатного РИБ по организации, и рассмотрели наиболее эффективные способы решения этой задачи. Выбор конкретного метода зависит от объемов вашей базы данных, квалификации разработчика и требований к чистоте итоговых данных.