Ведение учета нескольких юридических лиц в одной информационной базе 1С — распространенная практика для небольших компаний и холдингов. Однако по мере роста бизнеса, увеличения объема данных, изменения структуры собственности или при возникновении требований конфиденциальности возникает необходимость разделить общую базу на несколько независимых. В этой статье мы подробно разберем, как грамотно выполнить разделение базы 1С:Бухгалтерия предприятия 3.0 по организациям, рассмотрим основные технологические подходы, проанализируем неочевидные подводные камни и предложим пошаговые инструкции для каждого метода.
Метод №1. Распределенная информационная база (РИБ) с фильтром по организации
Использование штатного механизма Распределенных информационных баз (РИБ) — это наиболее надежный, быстрый и технологически правильный способ разделения учета. В типовой конфигурации 1С:Бухгалтерия предприятия 3.0 уже присутствует готовый план обмена «По организациям», что позволяет обойтись без написания сложных правил конвертации данных.
Рассмотрим пошагово, как реализовать этот метод:
Подготовка исходной базы: Перед началом любых манипуляций обязательно создаем резервную копию исходной базы. Убеждаемся, что в базе проведены все регламентные операции и отсутствуют ошибки в транзакциях.
Настройка синхронизации данных: В исходной базе переходим в раздел Администрирование — Синхронизация данных. Включаем флаг синхронизации и переходим в список настроек. Создаем новую синхронизацию через распределенную информационную базу (РИБ) с фильтром по организации.
Выбор организации-фильтра: В мастере настройки указываем конкретную организацию, которую необходимо выделить в новую базу. Система автоматически определит список связанных документов и движений регистра.
Создание начального образа: Запускаем процесс создания начального образа подчиненного узла. Платформа сформирует файл базы данных (файловый или выгрузку для SQL), содержащий только те документы, которые относятся к выбранной организации. При этом вся нормативно-справочная информация (НСИ), включая справочники контрагентов, номенклатуры и договоров, перенесется целиком, что гарантирует целостность ссылочных связей.
Отключение подчиненного узла от главного: Полученный образ базы изначально функционирует в режиме подчиненного узла РИБ. В нем заблокирована возможность изменения конфигурации и ожидается постоянная синхронизация с центром. Чтобы превратить эту базу в полностью автономную, нам необходимо программно разорвать связь с главным узлом.
Для отключения от главного узла откроем созданную периферийную базу в режиме «1С:Предприятие» под правами администратора, запустим внешнюю обработку «Групповое изменение реквизитов» или выполним в консоли кода следующий фрагмент:
// Программное отключение связи с главным узлом распределенной базы
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
После выполнения этой команды база станет полностью самостоятельной, и в ней можно будет полноценно вести учет, обновлять конфигурацию независимо от источника и вносить любые изменения.
Метод №2. Создание копий базы и последующая очистка лишних данных
Этот метод часто называют методом «грубой силы». Суть его заключается в создании нескольких копий исходной базы (по количеству выделяемых организаций) и последующем удалении из каждой копии документов всех остальных организаций. Рассмотрим особенности этого подхода.
Если выполнять удаление документов обычным интерактивным способом через пометку удаления и стандартное монопольное удаление объектов, процесс может затянуться на десятки часов или даже дней, особенно при больших объемах регистров. Чтобы оптимизировать этот процесс, выполним следующие шаги:
Делаем копию исходной базы для конкретной организации.
С помощью специализированных обработок (например, групповой обработки данных) находим все документы, у которых реквизит Организация не равен нашей целевой организации.
Для ускорения процесса сначала программно очищаем движения этих документов по всем регистрам накопления, бухгалтерии и сведений.
Помечаем документы на удаление и удаляем их из базы данных.
Главная проблема этого метода — очистка нормативно-справочной информации (НСИ). В базе остается огромное количество неиспользуемых карточек контрагентов, договоров и номенклатуры, которые принадлежали другим фирмам. Давайте разберем простой и безопасный алгоритм очистки справочников без написания сложного кода:
В очищенной базе заходим в справочники Номенклатура, Контрагенты и ДоговорыКонтрагентов.
С помощью встроенной обработки «Групповое изменение реквизитов» устанавливаем пометку на удаление абсолютно для всех элементов этих справочников.
Запускаем стандартное «Удаление помеченных объектов» (раздел Администрирование — Обслуживание — Удаление помеченных объектов) в режиме удаления только тех объектов, на которые нет ссылок в документах.
Платформа автоматически проанализирует зависимости и безвозвратно удалит только те карточки, которые реально не использовались в оставшихся документах нашей организации. На те элементы, которые задействованы в учете, система выдаст предупреждение и откажется их удалять.
После завершения процедуры удаления нам останется лишь массово снять пометку на удаление с оставшихся в живых элементов справочников.
Метод №3. Выгрузка и загрузка данных с помощью универсальных инструментов
Еще один рабочий сценарий — использование стандартных инструментов выгрузки данных от компании 1С. Рассмотрим два основных инструмента:
ВыгрузкаЗагрузкаДанныхXML.epf: Эта обработка позволяет выгружать данные напрямую по ссылкам с установкой жестких отборов по реквизиту организации.
Важный нюанс: При переносе данных в чистую пустую базу-приемник вы можете столкнуться с проблемой предопределенных элементов (например, базовые валюты, ставки НДС, системные папки). Платформа при создании пустой базы генерирует их со своими уникальными идентификаторами (GUID). При загрузке XML-файла из старой базы могут возникнуть дубли предопределенных элементов. Чтобы избежать этой проблемы, перед началом работы рекомендуется использовать стандартную обработку поиска и удаления дублей.
ВыгрузкаЗагрузкаEnterpriseData.epf: Более современный инструмент, осуществляющий перенос данных через универсальный формат обмена. Он автоматически сопоставляет системные справочники и предопределенные элементы по ключевым полям, предотвращая задвоение. Однако стоит учитывать, что через EnterpriseData могут переноситься не все специфические регистры сведений, важные для регламентированного учета, поэтому после загрузки потребуется детальная сверка оборотно-сальдовой ведомости.
Технологическая альтернатива: Разделение данных (технология «1С:Фреш» локально)
Если перед вами стоит задача изолировать данные пользователей разных организаций друг от друга, но при этом вы хотите избежать рутинного администрирования 10 различных баз (их обновления, архивации, поддержки производительности), проанализируем встроенный механизм платформы — разделение данных (multi-tenancy).
В этом случае физически база данных остается одна. На уровне платформы настраивается общий разделитель (обычно это справочник «Области данных»). Пользователи каждой организации авторизуются в своей области данных и видят исключительно свои документы, контрагентов и номенклатуру. При этом системный администратор обновляет только одну конфигурацию, а данные хранятся в единой СУБД. Этот вариант идеален, если у холдинга в будущем планируется консолидация отчетности или ведение сквозных бизнес-процессов.
Специфические подводные камни при разделении баз 1С:Бухгалтерия 3.0
Перенос документов и очистка справочников — это лишь техническая верхушка айсберга. Выясним, с какими учетными и интеграционными трудностями нам придется столкнуться на практике после физического разделения баз:
Единый налоговый счет (ЕНС): Начиная с 2023 года, учет расчетов по налогам в 1С:БП ведется на сложных регистрах ЕНС. При разделении баз необходимо тщательно проконтролировать остатки на счетах 68.90, сверить распределение платежей по налогам и заново настроить интеграцию с Личным кабинетом ФНС для каждой организации в ее новой обособленной базе.
Межфирменные продажи (Intercompany): Если организации внутри единого холдинга активно торговали между собой, в исходной базе неизбежно присутствовали «зеркальные» документы (например, организация «А» продает товар организации «Б», создавая в одной базе документ реализации и документ поступления соответственно). После разделения баз автоматическая связь между этими документами разорвется. Взаиморасчеты превратятся во внешние, и любые корректировки придется делать вручную или продумывать механизмы интеграции между базами.
Синхронизация с ЗУП: Проанализируем ситуацию, когда расчет зарплаты продолжает вестись в единой базе 1С:ЗУП, а регламентированный учет разделяется на несколько баз 1С:БП. Стандартная синхронизация усложняется:
В ЗУП придется настроить несколько отдельных подключений к синхронизации (по одному для каждой новой базы БП).
В правилах отправки данных для каждой настройки синхронизации в ЗУП необходимо установить строгий фильтр по конкретной организации.
Необходимо строго следить за синхронностью справочников «Физические лица» и «Способы отражения зарплаты в бухучете», чтобы избежать хаоса в аналитике субконто.
Организационные риски и психология заказчика: Почти всегда при разделении баз клиенты уверяют, что им больше не потребуется общая аналитика. Однако на практике уже через несколько месяцев возникает потребность во встречной выписке документов, сквозном контроле остатков или консолидированном балансе холдинга. Обязательно доведите эти последствия до инициаторов проекта разделения баз до начала выполнения технических работ.