← На главную

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

Вариант 1: Единая информационная база для всех организаций

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

Основные преимущества:

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

Критический недостаток: Разграничение прав доступа (RLS).

Как только возникает необходимость скрыть данные одной фирмы от сотрудников другой, мы сталкиваемся с механизмом RLS (Row Level Security — безопасность на уровне записей). Проанализируем ситуацию: на больших объемах данных типовые шаблоны RLS могут вызывать серьезные замедления. Пользователи могут наблюдать ситуацию, когда список документов открывается несколько минут. Это происходит из-за того, что к каждому SQL-запросу система добавляет сложные условия фильтрации по разрешенным организациям.

Вариант 2: Каждая организация в своей базе данных

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

Основные преимущества:

1. Абсолютное разграничение прав. Нам не нужно настраивать сложные роли и механизмы RLS. Достаточно просто не давать пользователю доступ к конкретной базе. Это гарантирует максимальную производительность системы, так как база работает на «полных правах».
2. Безопасность при проверках. Проанализируем сценарий визита налоговой или аудиторов. Если проверяют только ОАО, мы можем предоставить копию именно этой базы, не рискуя засветить данные других ООО. Аудиторы часто требуют именно копию базы на свой носитель, и в случае единой базы скрыть «лишние» организации технически очень сложно (даже с RLS опытный специалист может добраться до данных через прямые SQL-запросы).
3. Мобильность бизнеса. Если одно из подразделений продают или выделяют в отдельный бизнес, мы просто отдаем им их базу. В случае единой базы нам пришлось бы заниматься сложной процедурой выгрузки данных по одной организации.
4. Снижение нагрузки на файловую систему. Если мы используем файловый режим работы, разделение на базы позволяет избежать превышения лимита в 4 Гб на таблицу.

Минусы:

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

Особенности учета в «1С:Зарплата и Управление Персоналом» (ЗУП)

Разберем, почему для зарплатного учета логика может отличаться. В ЗУП крайне рекомендуется вести все связанные организации в одной базе. Выясним причину:

1. Общие сотрудники. Один и тот же человек может работать по совместительству в двух ваших фирмах. Если вести их в разных базах, система не увидит общую сумму дохода физического лица.
2. Налоги и взносы. Расчет НДФЛ и страховых взносов (особенно с учетом предельных величин базы) требует видеть все доходы человека внутри одного юридического контура. В разных базах возникнет переплата взносов или ошибки в отчетности 6-НДФЛ и РСВ.

Технические решения для оптимизации работы

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

Посмотрим на пример логики: мы можем поместить список разрешенных организаций в ПараметрыСеанса в виде объекта ФиксированныйМассив. Тогда условие в RLS будет максимально простым:

ГДЕ Организация В (&ПараметрыСеанса_РазрешенныеОрганизации)

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

Для тех, кто выбрал раздельные базы, но хочет упростить процесс передачи данных, эффективным инструментом является механизм РИБ (Распределенные информационные базы). Мы можем создать план обмена с фильтром ПоОрганизации. Рассмотрим этот алгоритм:

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

Механизм разделения данных (Multitenancy)

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

Итоговые рекомендации

Проанализировав все факторы, можно вывести следующую формулу выбора:

1. Выбирайте одну базу, если у вас общие склады, общая номенклатура, много операций перепродажи между своими фирмами и один бухгалтерский состав. При этом будьте готовы к переходу на SQL-версию и возможной оптимизации прав доступа.

2. Выбирайте разные базы, если организации принципиально разные (например, одна на ОСНО, другая на патенте), у них разные бухгалтеры, и вы хотите иметь возможность в любой момент «отдать» базу одной из фирм без лишних хлопот.

3. Для ЗУП практически всегда лучше использовать единую базу для корректного расчета налогов по общим сотрудникам.