При масштабировании бизнеса или изменении структуры владения компаниями часто возникает задача «отпочкования» одного или нескольких юридических лиц из общей многофирменной базы 1С:ERP Управление предприятием. В отличие от более простых конфигураций, таких как «1С:Бухгалтерия» или «1С:ЗУП», в ERP эта процедура сопряжена с серьезными трудностями из-за высокой степени интеграции данных и отсутствия простого типового механизма РИБ с фильтрацией по организации.
В этой статье мы подробно рассмотрим все возможные стратегии решения этой задачи, проанализируем их достоинства и недостатки, разберем скрытые риски учета и предоставим пошаговые инструкции для реализации каждого сценария.
Для начала выясним причину, почему разработчики фирмы «1С» не добавили стандартную настройку фильтрации по организации в распределенных информационных базах (РИБ) для ERP. Дело в том, что архитектура ERP построена на сквозном управленческом учете. Многие справочники и регистры здесь не имеют прямого разреза по юридическим лицам. Например, справочник СтруктураПредприятия (подразделения), структура целей, направления деятельности, а также механизмы обеспечения потребностей и схемы производства являются общими для всей информационной базы.
Попытка автоматического разделения «в лоб» через РИБ привела бы к массовому появлению «битых ссылок» (объектов с пометкой «Объект не найден») или к необходимости переносить колоссальный объем связанных данных других организаций, что сводит саму идею разделения на нет.
Тем не менее решить задачу обособления фирмы можно. Ниже мы детально разберем пять основных методов.
Этот способ на практике оказывается наиболее надежным для средних и крупных баз, так как он гарантирует полную идентичность всех настроек системы, учетных политик, прав доступа, ролей и, самое главное, конфигурации. Мы не собираем базу заново, а берем готовую и «вычищаем» из нее все лишнее.
Рассмотрим алгоритм реализации этого метода по шагам:
Shrink (сжатие) базы данных средствами MS SQL Server или PostgreSQL, а также произвести полную реиндексацию таблиц.Если копирование и очистка не подходят из-за гигантского объема исходной базы, мы можем использовать механизм РИБ, предварительно доработав правила регистрации объектов (ПРО) через программу «1С:Конвертация данных 2.0».
Проанализируем этот процесс:
В плане обмена РИБ по умолчанию зарегистрированы абсолютно все объекты конфигурации. Наша задача — ограничить эту регистрацию. Для этого мы выгружаем правила регистрации объектов из конфигурации 1С:ERP, открываем их в «Конвертации данных» и для каждого ключевого документа и справочника прописываем условие фильтрации по организации.
Пример кода в обработчике правил регистрации ПередОбработкой или ПриРегистрацииОбъекта может выглядеть следующим образом:
Если ПолучитьОбщуюОрганизациюУзла() <> Объект.Организация Тогда
Отказ = Истина;
КонецЕсли;
После изменения правил выполняем следующие действия:
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
Теперь база абсолютно независима, и в ней присутствуют только данные целевой организации.
Этот метод основан на использовании встроенного механизма синхронизации данных. В 1С:ERP предусмотрен обмен по универсальному формату через план обмена «Синхронизация данных через универсальный формат» (в интерфейсе он настраивается как обмен с «Другой программой»).
Рассмотрим, как его настроить:
Важное ограничение метода: Формат EnterpriseData разрабатывался главным образом для обмена финансовыми и регламентированными данными (как при обмене с «1С:Бухгалтерией»). При переносе ERP -> ERP через этот формат теряются сложные производственные данные, специфичные для ERP: ресурсные спецификации, маршрутные карты, заказы на производство со всей структурой рабочих центров, а также оперативные данные по планированию. Если выделяемая организация ведет сложный производственный учет, этот метод использовать нельзя.
Для небольших баз или при переносе строго ограниченных срезов данных программисты часто используют универсальную обработку ВыгрузкаЗагрузкаДанныхXML. Она позволяет выгружать данные с установкой произвольных отборов (в том числе по реквизиту Организация).
Однако при переносе в пустую базу ERP этим способом возникает критическая проблема — задвоение предопределенных данных. Разберем, почему это происходит.
В любой пустой базе 1С при первом запуске программно создаются предопределенные элементы справочников (например, статьи расходов, направления деятельности, типы налогообложения). Если мы переносим документы и справочники «в лоб» через XML, обработка создает новые элементы с уникальными идентификаторами (GUID) из исходной базы. В результате в базе-приемнике образуются дубли предопределенных элементов, что неизбежно приведет к сбоям в алгоритмах проведения документов и процедуре закрытия месяца.
Чтобы избежать этого, перед загрузкой XML-данных необходимо сопоставить ключевые справочники и предопределенные элементы или использовать специализированные правила конвертации данных, которые ищут предопределенные элементы по их имени (имени предопределенного), а не по GUID.
Очень часто инициаторами разделения баз выступают внешние аудиторы или новые владельцы бизнеса, которым передаются права на организацию. На практике им редко требуется весь громоздкий функционал ERP с его сложным производственным и складским контуром.
Если цель разделения — предоставить отчетность или вести только регламентированный учет, наиболее рациональным решением будет **настройка типового обмена ERP -> БП 3.0** с отбором по выделяемой организации.
Преимущества этого подхода очевидны:
Вне зависимости от выбранного технического метода, после разделения баз вы гарантированно столкнетесь с методологическими проблемами учета. Рассмотрим две главные из них.
Если в исходной базе организации торговали между собой, то в системе присутствует множество документов ПередачаТоваровМеждуОрганизациями, в которых одна наша фирма является отправителем, а другая — получателем. При разделении баз эти документы потеряют связь со второй стороной.
Решение: В отделившейся базе «чужую» организацию придется переоформить как обычного внешнего контрагента (клиента или поставщика), а документы внутренних передач программно или вручную преобразовать в стандартные документы купли-продажи (РеализацияТоваровУслуг и ПриобретениеТоваровУслуг).
После переноса данных в новую базу (особенно методами РИБ или EnterpriseData) учетные политики, настройки счетов учета номенклатуры, статьи расходов и расчеты по налогам могут «слететь» или потребовать ручного переназначения. Будьте готовы к тому, что придется заново настраивать правила отражения документов в рег. учете и перезакрывать прошлые периоды (месяцы) для восстановления корректной оборотно-сальдовой ведомости (ОСВ).
Мы рекомендуем обязательно проводить сверку ОСВ по всем счетам учета между исходной базой (по конкретной организации) и новой выделенной базой до и после проведения регламентных операций закрытия месяца.