Часто возникает административная задача: единая информационная база, в которой велся учет по нескольким (например, десяти) юридическим лицам, должна быть разделена на отдельные, независимые базы для каждой организации. Это может быть связано с реструктуризацией бизнеса, продажей части компаний или требованиями информационной безопасности. Рассмотрим, какой способ разделения базы является оптимальным, и проанализируем преимущества и недостатки каждого подхода.
Существует три основных стратегии для решения этой задачи:
Создание РИБ (Распределенной Информационной Базы) с фильтрацией по организациям.
Удаление лишних данных в нескольких копиях исходной базы.
Перенос данных по каждой организации в новую, пустую базу.
Проанализируем каждый из этих методов, чтобы вы могли выбрать наиболее подходящий для вашей ситуации.
Решение 1: Использование РИБ (самый надежный и рекомендуемый способ)
Этот метод использует штатный механизм платформы 1С и считается наиболее безопасным и профессиональным, особенно для больших и сложных баз данных с многолетней историей.
Суть метода: Исходная база становится главным узлом РИБ. Для каждой из 10 организаций создается свой подчиненный узел. В настройках обмена для каждого узла устанавливается фильтр, который обеспечивает миграцию данных, относящихся только к одной, конкретной организации. После первой полной синхронизации каждая подчиненная база будет содержать всю необходимую информацию по своей организации.
Разберем по шагам:
Создайте полную резервную копию вашей исходной базы. Это обязательный шаг перед любыми серьезными изменениями.
В исходной базе (в режиме «Конфигуратор») создайте главный узел РИБ.
Далее создайте подчиненные узлы для каждой организации. В типовой конфигурации 1С:Бухгалтерия 3.0 существует специальный план обмена «По организации». Именно его и следует использовать.
В настройках каждого подчиненного узла укажите отбор по конкретной организации. Платформа будет автоматически отслеживать, какие документы, справочники и записи регистров относятся к этой организации, и включать в обмен только их.
Выполните первоначальное создание образов подчиненных баз. После этого у вас будет 10 файлов выгрузки.
Разверните каждую выгрузку в отдельную информационную базу. После первой синхронизации в каждой из них будут данные только по "своей" организации.
Преимущества этого подхода:
Надежность и целостность данных. Так как это стандартный механизм платформы, риск потери данных или нарушения связей между объектами минимален. Система сама корректно переносит все связанные записи регистров, подчиненные справочники и т.д.
Возможность будущей консолидации. Как справедливо отмечают эксперты, даже после разделения бизнеса может возникнуть потребность в сводной отчетности. Если не разрывать связь РИБ, вы сможете легко собирать данные в центральном узле. Восстановить обмен в будущем будет гораздо проще, чем пытаться объединить 10 разрозненных баз.
Управляемость. Процесс полностью контролируется стандартными инструментами 1С.
Автономность. В любой момент после разделения вы можете сделать подчиненные узлы полностью автономными. Для этого достаточно просто удалить план обмена в дочерней базе. Она станет обычной, независимой базой данных.
Когда выбирать этот метод: Практически всегда. Особенно рекомендуется для больших баз, где ручное удаление займет огромное время и сопряжено с высокими рисками.
Решение 2: Удаление лишних данных в копиях базы
Этот подход кажется интуитивно простым: сделать N копий базы и в каждой удалить N-1 лишнюю организацию. На практике он сопряжен с рядом трудностей, но может быть применим для небольших баз.
Суть метода: Вы создаете 10 полных копий вашей рабочей базы. Затем в первой копии вы оставляете Организацию №1 и удаляете организации №2-10. Во второй копии оставляете Организацию №2 и удаляете №1, №3-10, и так далее.
Техническая реализация:
Удалять данные вручную — практически невыполнимая задача. Для этого используются специальные обработки для удаления данных, которые можно найти на профессиональных ресурсах — для этой задачи есть обработка удаления выбранных организаций и связанных данных. Логика такой обработки сводится к поиску всех объектов системы (документов, записей регистров, элементов справочников), связанных с удаляемыми организациями, и их пометке на удаление с последующим полным удалением.
Примерная логика кода для поиска документов, подлежащих удалению, может выглядеть так:
// Псевдокод для понимания принципа
Для Каждого Док Из Документы Цикл
Если Метаданные.Документы[Док.Метаданные().Имя].Реквизиты.Найти("Организация") <> Неопределено Тогда
Если Док.Организация <> МояНужнаяОрганизация Тогда
// Пометить документ на удаление
ДокОбъект = Док.ПолучитьОбъект();
ДокОбъект.ПометкаУдаления = Истина;
ДокОбъект.Записать();
КонецЕсли;
КонецЕсли;
КонецЦикла;
Важно: Это очень упрощенный пример. Реальная обработка должна анализировать все регистры и связанные данные.
Потенциальные проблемы и недостатки:
Проблема общих данных. Что делать, если один и тот же контрагент или элемент номенклатуры использовался в документах разных организаций? Неосторожное удаление может привести к потере важных данных в справочниках, которые нужны оставшейся организации. Обработка удаления должна иметь очень гибкие настройки.
"Битые" ссылки. Даже после самого тщательного удаления в системе могут остаться ссылки на уже не существующие объекты, что в будущем вызовет ошибки.
Длительность процесса. На больших базах процесс пометки на удаление, а затем и само физическое удаление объектов с последующим пересчетом итогов может занимать десятки часов или даже несколько дней.
"Замусоривание" базы. В таблицах базы данных остается много "пустых" мест от удаленных записей, что может незначительно влиять на производительность. База не будет такой "чистой", как созданная с нуля — решить проблему поможет обработка безопасного удаления данных для очистки базы.
Когда выбирать этот метод: Только для небольших и несложных баз, если у вас есть проверенная и надежная обработка для удаления данных и вы готовы к тщательному тестированию результата.
Решение 3: Перенос данных в пустые базы через выгрузку/загрузку
Этот метод предполагает создание абсолютно "чистых" баз и перенос в них только нужной информации. Это самый трудоемкий с точки зрения проверки метод.
Суть метода: Создается 10 новых, пустых информационных баз с той же конфигурацией, что и исходная. Затем из исходной базы выгружаются данные, относящиеся только к одной организации, и загружаются в соответствующую пустую базу. Для этой задачи есть перенос документов и остатков между базами 1С:БП.
Инструменты для переноса:
Стандартная обработка «Выгрузка и загрузка данных XML». Она позволяет выгружать данные с отборами (поможет выгрузка и загрузка XML с гибкими отборами). Можно настроить правила для выгрузки всех документов и записей регистров с отбором по организации, а также связанных данных справочников.
Технология «Конвертация данных». Это более мощный и гибкий инструмент, который позволяет создавать сложные правила переноса данных между базами. Для нашей задачи он может быть избыточен, но дает максимальный контроль над процессом.
Преимущества и сложности:
(+) Абсолютно чистая база. В результате вы получаете базу, которая не содержит никаких следов удаленных объектов, старых записей и прочего "мусора".
(-) Высокий риск неполного переноса. Это главная проблема. Очень легко забыть перенести какой-нибудь неявный, но важный регистр сведений или настройки учета.
(-) Необходимость тотальной проверки. После переноса требуется скрупулезная сверка данных: оборотно-сальдовые ведомости по всем счетам, остатки по складам, взаиморасчеты с контрагентами. Эта проверка может занять больше времени, чем сам перенос.
Когда выбирать этот метод: Если критически важно получить "чистую" базу, и у вас есть ресурсы (время и специалисты) для разработки правил переноса данных и последующей многоэтапной проверки корректности результата.
Итоговые рекомендации
Подведем итог и сформулируем четкие рекомендации по выбору метода.
Для 95% случаев, особенно при работе с важными бухгалтерскими базами любого размера, оптимальным и самым безопасным методом является создание РИБ по организациям. Он сохраняет целостность данных, оставляет возможность для консолидации и управляется стандартными средствами платформы.
Метод удаления лишних данных можно рассматривать как компромиссный вариант для небольших баз, при условии наличия надежной внешней обработки и готовности к возможным ошибкам — для этого есть обработка группового удаления организаций по фильтрам.
Перенос в пустые базы — это специфическое решение для перфекционистов, требующее наибольших трудозатрат на проверку результата. Его стоит применять, только если есть веские причины не использовать РИБ.
Таким образом, несмотря на кажущееся разнообразие вариантов, в большинстве практических ситуаций выбор очевиден в пользу штатного механизма распределенных информационных баз.