Как объединить несколько баз БГУ 1.0 в одну с разделением прав доступа и нумерации?

← На главную

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

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

1. Выбор инструмента для переноса данных

Для качественного объединения баз стандартной «Универсальной выгрузки/загрузки данных» через XML может быть недостаточно, так как она не позволяет гибко трансформировать данные в процессе обмена. Рассмотрим использование конфигурации «1С:Конвертация данных 2.1». Это позволит нам:

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

2. Разделение данных через общий реквизит

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

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

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

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

3. Организация префиксации документов

Чтобы документы разных филиалов не пересекались по номерам, необходимо настроить префиксацию. В БГУ 1.0 префикс обычно формируется исходя из кода организации и префикса информационной базы. В нашем случае организация одна, поэтому стандартный механизм не подходит.

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


Процедура ПриУстановкеНовогоНомераДокумента(Источник, СтандартнаяОбработка, Префикс) Экспорт
    // Получаем текущего пользователя и его привязку к филиалу
    ВиртуальныйФилиал = ПолучитьФилиалТекущегоПользователя();
    
    // Устанавливаем префикс на основании филиала
    Если ЗначениеЗаполнено(ВиртуальныйФилиал) Тогда
        Префикс = ВиртуальныйФилиал.Префикс + Префикс;
    КонецЕсли;
КонецПроцедуры

Таким образом, при создании нового документа пользователем Филиала №1, система автоматически подставит нужный буквенный код в начало номера, предотвращая коллизии в нумерации.

4. Настройка прав доступа (RLS)

Одной из самых сложных задач является ограничение видимости данных. Пользователи Филиала №1 не должны видеть документы Филиала №2. Поскольку мы используем один общий реквизит для разделения, нам потребуется переписать шаблоны ограничений RLS (Row Level Security) в ролях пользователей.

Выясним причину, по которой это необходимо: стандартные роли в БГУ 1.0 настроены на фильтрацию по полю Учреждение. Нам нужно изменить тексты запросов в ролях, чтобы фильтрация шла по нашему новому общему реквизиту ВиртуальноеПодразделение.

Пример логики запроса в RLS:


ТекущаяТаблица ГДЕ ВиртуальноеПодразделение В (
    ВЫБРАТЬ ДоступныеПодразделения ИЗ РегистрСведений.Доступ Пользователей ГДЕ Пользователь = &ПараметрСеансаТекущийПользователь
)

Важный момент: использование RLS может снизить производительность системы, поэтому индексы по новому реквизиту должны быть созданы в обязательном порядке.

5. Контроль ссылочной целостности и НСИ

Проанализируем ситуацию с Планом счетов и справочниками КБК (КПС). В разных базах БГУ 1.0 могут быть настроены разные бюджетные классификаторы. Перед слиянием необходимо привести справочники бюджетной классификации во всех пяти базах к единому стандарту.

Посмотрим, что нужно проверить в первую очередь:

Единообразие структуры КПС (произвольный, классификационный).
Соответствие КЭК (КОСГУ) текущему законодательству.
Наличие и актуальность учетной политики для центрального учреждения.

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

6. Альтернативный путь: Переход на БГУ 2.0

Рассмотрим перспективность выполнения этой задачи в редакции 1.0. Данная редакция является устаревшей и базируется на обычных формах. Возможно, стоит совместить процесс объединения баз с переходом на «1С:Бухгалтерия государственного учреждения 2.0».

В БГУ 2.0 на базе БСП (Библиотеки стандартных подсистем) механизмы RLS и работа с дополнительными реквизитами реализованы значительно гибче. Кроме того, в редакции 2.0 штатно поддерживается учет по подразделениям на балансовых счетах, что может полностью снять проблему «отсутствия поля подразделения в документах», с которой автор столкнулся в БГУ 1.0.

Подводя итог, можно сказать, что задача решаема и в рамках БГУ 1.0 через внедрение общего реквизита и модификацию RLS, но требует высокой квалификации программиста для обеспечения стабильности и производительности системы после слияния.