При масштабировании бизнеса или оптимизации производительности учетных систем часто возникает задача разделения одной крупной базы «1С:Комплексная автоматизация 2» (КА 2) на несколько обособленных баз по конкретным организациям. Основным мотивом для этого обычно выступает желание ускорить тяжелые процедуры, такие как Закрытие месяца и Расчет себестоимости, которые в единой базе могут вызывать длительные блокировки и мешать повседневной работе пользователей. Рассмотрим подробно, как правильно решить эту задачу, какие подводные камни ожидают при различных подходах и почему стандартный обмен через Универсальный формат (Enterprise Data) в данном случае не подходит.
На первый взгляд идея использовать стандартный план обмена СинхронизацияДанныхЧерезУниверсальныйФормат выглядит привлекательно. Кажется, достаточно настроить фильтр по организации и запустить выгрузку. Однако на практике этот метод приводит к серьезным техническим проблемам:
СтруктураПредприятия (Подразделения) является единым для управленческого и регламентированного учета. Если подразделение не связано напрямую через правила регистрации с выгружаемыми объектами или нарушена его иерархия, оно просто не попадет в файл обмена, что приведет к появлению пустых полей в документах приемника. Договоры контрагентов также привязаны к партнерам, и при наличии расчетов по нескольким организациям правила обмена могут отсечь «чужие» договоры, оставив документы без ключевой аналитики.Использование технологии РИБ по организации является классическим и наиболее надежным методом решения этой задачи. Основное опасение бухгалтеров и администраторов при внедрении РИБ заключается в том, что «данные полезут обратно в центральную базу». Однако этот процесс полностью поддается контролю.
Выясним, как настроить односторонний обмен, исключающий возврат измененных данных из дочерних баз в главную. Разберем два основных сценария.
Если вам требуется создать независимую базу для организации и в дальнейшем вести в ней учет автономно, выполните следующие шаги:
// Отключение периферийного узла РИБ от главного для перевода в автономный режим
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
После выполнения этой команды база навсегда теряет статус подчиненного узла РИБ, становится обычной файловой или клиент-серверной базой, и никакой случайный обмен с центральной базой будет физически невозможен.
Если вам необходимо ежедневно обновлять дочерние базы актуальными данными из центра, но при этом запретить передачу любых изменений обратно, выполните настройку регистрации изменений:
Рассмотрим пример кода для принудительного снятия регистрации изменений на узле перед отправкой данных, чтобы гарантировать односторонность:
// Снятие регистрации изменений на подчиненном узле для предотвращения отправки данных в центр
Процедура ОтменитьРегистрациюНаПодчиненномУзле(СсылкаНаУзел) Экспорт
Для Каждого ЭлементПланаОбмена Из СсылкаНаУзел.Метаданные().Состав Цикл
ПланыОбмена.УдалитьРегистрациюИзменений(СсылкаНаУзел, ЭлементПланаОбмена.Метаданные);
КонецЦикла;
КонецПроцедуры
Проанализируем первоначальную проблему: бухгалтерии требуется разделение, чтобы «Закрытие месяца» не тормозило работу пользователей. Вместо создания 10 отдельных баз для 10 организаций (что потребует огромных затрат на администрирование, обновление конфигураций и сверку взаиморасчетов) можно применить концепцию «выделенного узла для тяжелых операций».
Рассмотрим этот подход по шагам:
Если архитектура вашей базы не позволяет запустить РИБ (например, из-за нетипичных доработок или использования сложных внешних интеграций), рекомендуется использовать метод очистки копии. Вместо переноса данных «снизу вверх» в пустые базы, мы идем от обратного:
Этот подход гарантирует стопроцентное совпадение нормативно-справочной информации (НСИ), настроек учетной политики, регистров сведений и, самое главное, — сохранение абсолютно точных исторических проводок и движений, которые были рассчитаны до момента разделения баз.
Перед тем как приступать к разделению единого информационного пространства на 10 изолированных баз, обязательно взвесьте все риски. Поддержка актуальности нормативно-справочной информации (синхронизация партнеров, контрагентов, номенклатуры), постоянные сверки остатков и затраты на администрирование 10 баз могут обойтись компании значительно дороже, чем покупка более мощного серверного оборудования. Зачастую перевод СУБД на быстрые NVMe-накопители, оптимизация индексов и увеличение оперативной памяти сервера решают проблему блокировок при «Закрытии месяца» без необходимости разделения баз.