← На главную

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

Метод 1: Использование механизма Распределенных информационных баз (РИБ)

Этот способ считается одним из самых надежных для типовых конфигураций «1С:Бухгалтерия предприятия». Мы воспользуемся встроенным функционалом фильтрации данных по организации при создании начального образа подчиненного узла.

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

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

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

ПланыОбмена.УстановитьГлавныйУзел(Неопределено);

После выполнения этой команды база станет автономной, и мы сможем вносить в нее любые изменения.

Метод 2: Универсальная выгрузка и загрузка данных XML

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

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

Основное преимущество этого метода в том, что он переносит объекты «как есть» с сохранением их внутренних идентификаторов (UUID). Однако здесь кроется главная опасность — задвоение предопределенных элементов (например, счета учета, виды налогов, статьи затрат). Если в базе-приемнике уже есть свои предопределенные элементы, а мы загружаем такие же из источника, могут появиться дубли.

Чтобы избежать этой проблемы, проанализируем настройки обработки. В современных версиях, входящих в состав подсистемы «Инструменты разработчика» или поставляемых с КД 2.0 (Конвертация данных), реализован механизм сопоставления предопределенных элементов по имени. Проверим, чтобы при загрузке стоял флаг «Сопоставлять объекты по идентификатору». Если дубли все же появились, используем стандартную обработку Поиск и замена значений для перепривязки ссылок на «родные» элементы базы.

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

Метод 3: Очистка копии информационной базы («От обратного»)

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

Алгоритм действий:

1. Создадим полную копию текущей информационной базы.
2. Разберем механизм удаления: нам потребуется обработка для удаления объектов по условию. Выберем все документы и записи регистров, где реквизит Организация не равен нашей целевой организации.
3. Выполним непосредственное удаление отобранных объектов. Это значительно быстрее, чем удаление с контролем ссылочной целостности, но требует последующей проверки.
4. После массового удаления запустим процедуру Тестирование и исправление (ТиИ). В настройках ТиИ обязательно выберем пункты:
   • Реиндексация таблиц;
   • Проверка ссылочной целостности (с параметром «Очищать ссылки» или «Создавать объекты» для битых ссылок);
   • Сжатие таблиц.

Проанализируем результат: после удаления данных физический размер базы может не уменьшиться. Для файловых баз обязательно используем утилиту chdbfl.exe или функцию Сжать в ТиИ. Для клиент-серверных баз необходимо выполнить процедуру Shrink (сжатие) базы данных средствами MS SQL Server или PostgreSQL, чтобы вернуть свободное место операционной системе.

Сравнение и выбор оптимального пути

Выясним причину выбора того или иного метода в зависимости от условий:

1. Объем данных: Если база весит сотни гигабайт, метод РИБ может «упасть» по таймауту при формировании начального образа. В этом случае метод очистки копии (Метод 3) будет более предпочтительным.

2. Чистота данных: Метод РИБ и XML-выгрузка позволяют получить «чистую» базу без исторического мусора других организаций. Метод копирования (Метод 3) оставляет в базе все справочники (даже те, что использовались только другими фирмами) и настройки, что может привести к избыточному размеру справочников Номенклатура или Контрагенты.

3. Версия конфигурации: Если базы источника и приемника имеют разные релизы, использование РИБ и прямой XML-выгрузки невозможно. В этой ситуации поможет только использование Конвертации данных (КД 2.0 или 3.0) с написанием правил обмена.

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