Как выделить одну организацию в отдельную базу из общей 1С:Бухгалтерия 3.0?

Программист 1С v8.3 (Управляемые формы) 1C:Бухгалтерия Бухгалтерский учет
← На главную

Рассмотрим распространенную задачу: в одной базе данных 1С:Бухгалтерия 3.0 ведется учет по нескольким юридическим лицам. В какой-то момент одно из них решает "отделиться" и вести учет в собственной, чистой базе. Основная проблема заключается в том, как корректно перенести все данные, относящиеся только к этой организации, особенно если база существует много лет и накопила огромный объем информации.

Проанализируем ситуацию, с которой столкнулся пользователь: база ведется 11 лет, в ней 4 организации и почти 3 миллиона объектов. Стандартные подходы, такие как создание начального образа РИБ или удаление помеченных объектов, работают недопустимо долго — часами или даже сутками. Разберем все возможные методы решения этой задачи, их плюсы, минусы и подводные камни.

Метод 1: Использование "Конвертации данных" (КД 2.1)

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

Рассмотрим по шагам, как это должно работать в теории:

  1. Создание правил выгрузки данных (ПВД). Для каждого объекта, который нужно перенести (справочники, документы, регистры), настраивается правило. В большинстве правил для объектов, имеющих реквизит Организация, настраивается простой отбор по этому реквизиту.
  2. Использование параметров. Чтобы правила были универсальными, создается параметр, например, НужнаяОрганизация. Перед запуском выгрузки в обработке "Универсальный обмен данными в формате XML" этому параметру присваивается значение — ссылка на ту организацию, которую мы "отделяем".
  3. Обработка связанных данных. Сложность начинается с объектов, которые не имеют прямого реквизита Организация, но связаны с ней. Например, записи регистров сведений или накопления. Для них отбор нужно настраивать по измерениям или реквизитам, которые ссылаются на документ или справочник с нужной организацией. Это требует глубокого анализа структуры метаданных.

Недостатки:

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

Вывод: Этот метод подходит для небольших, нетиповых конфигураций или для опытных специалистов по КД, готовых потратить значительное время на разработку и отладку правил. Для большой и старой типовой базы БП 3.0 это, скорее всего, нерациональный путь.

Метод 2: Использование механизма РИБ (Распределенные информационные базы)

Это штатный, предусмотренный разработчиками 1С механизм для создания обменов. В конфигурации "Бухгалтерия предприятия" есть встроенная возможность настройки обмена с фильтром по организации. Это самый надежный способ с точки зрения целостности данных.

Процесс выглядит так:

  1. В исходной базе настраивается новый план обмена.
  2. В настройках узла обмена указывается фильтр — отбор по одной или нескольким организациям.
  3. Запускается процедура создания начального образа для нового узла. Система сама анализирует все связи и выгружает полный срез данных по выбранной организации в файл.
  4. Этот файл загружается в новую, чистую базу, которая становится подчиненным узлом.

Недостатки:

Основная проблема, с которой столкнулся автор, — крайне низкая производительность на больших базах. Процесс создания начального образа может занимать десятки часов, а то и несколько дней. Система анализирует миллионы объектов и их взаимосвязи, что создает колоссальную нагрузку. В нашем примере процесс "завис" на 0% на целый час, что говорит о его нежизнеспособности для срочной задачи.

Вывод: Идеологически правильный и надежный метод, но на практике он может быть неприменим для "тяжелых" баз из-за огромных временных затрат.

Метод 3: Копирование базы с последующим удалением ненужных данных

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

Стандартное удаление:

Пользователь пытается пометить на удаление все документы и справочники трех "лишних" организаций и запустить стандартную обработку "Удаление помеченных объектов". И тут же сталкивается с той же проблемой, что и с РИБ, — производительностью. Процесс удаления 127 000 документов длится вторые сутки. Причина в том, что 1С при удалении выполняет проверку ссылочной целостности: для каждого удаляемого объекта система ищет все ссылки на него в базе, чтобы не оставить "битых" ссылок. На базе с 11-летней историей таких ссылок миллиарды.

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

Программное удаление (быстрое, но опасное):

Есть альтернативный, "хакерский" способ. Можно написать небольшую обработку, которая будет удалять объекты напрямую, без проверки ссылочной целостности.

Внимание: Этот метод очень рискованный и требует высокой квалификации. Вы можете нарушить целостность данных и получить нерабочую базу.

Идея в том, чтобы программно отобрать объекты (документы, элементы справочников), принадлежащие ненужным организациям, и удалить их методом Удалить() в транзакции, игнорируя ошибки ссылочной целостности. После такого "хирургического" вмешательства необходимо выполнить полное тестирование и обслуживание базы: тестирование и исправление, перепроведение документов за все периоды, полную сверку отчетов.

Вывод: Стандартное удаление не подходит для больших баз. Программное удаление — это мощный, но опасный инструмент для опытных разработчиков, который можно применять, только полностью осознавая риски.

Метод 4: Перенос данных за ограниченный период (самый прагматичный)

Этот подход является "золотой серединой" и часто оказывается самым эффективным решением для старых, больших баз. Суть в том, чтобы не тащить в новую базу всю многолетнюю историю, а перенести только самое необходимое.

Разберем по шагам:

  1. Подготовка. Создается новая, абсолютно чистая база данных с той же конфигурацией.
  2. Ввод начальных остатков. В старой базе на определенную дату (например, на 31 декабря прошлого года) формируются отчеты по остаткам (ОСВ, анализ счетов и т.д.) в разрезе нужной организации. На основании этих данных в новой базе с помощью стандартного "Помощника ввода начальных остатков" вводятся остатки на 1 января текущего года.
  3. Перенос документов. С помощью стандартной обработки ВыгрузкаЗагрузкаДанныхXML.epf (или аналогов) из старой базы выгружаются только документы за текущий год, относящиеся к нужной организации. Важно настроить выгрузку так, чтобы она не переносила движения по регистрам. Также нужно перенести связанную нормативно-справочную информацию (контрагентов, номенклатуру и т.д.), которая использовалась в этих документах.
  4. Перепроведение. После загрузки документов в новую базу запускается групповое перепроведение всех документов с начала года. Так как база "легкая" и содержит данные только за один год, это произойдет очень быстро. В результате будут сформированы корректные, актуальные движения по всем регистрам.

Преимущества этого метода:

Недостатки:

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

← На главную