В процессе реорганизации бизнеса или изменения учетной политики нередко возникает задача: выделить из общей рабочей базы 1С:ERP данные только по одной определенной организации, удалив все остальные юридические лица. На первый взгляд, задача кажется тривиальной — пометить лишние документы на удаление или выгрузить данные нужной организации в чистую базу. Однако на практике в 1С:ERP 2.5 разработчики сталкиваются со сложными архитектурными взаимосвязями, разрушением партионного учета и битыми ссылками. Рассмотрим подробно все подводные камни и разберем проверенные подходы к решению этой задачи.
Архитектурные сложности 1С:ERP 2.5
Перед тем как приступать к разделению базы, проанализируем, почему стандартные методы удаления и обмена не работают «из коробки»:
Отсутствие типового РИБ по организациям. В отличие от старых конфигураций предыдущих поколений (таких как 1С:УПП), в 1С:ERP 2.5 отсутствует типовой план обмена для распределенной информационной базы с фильтрацией по организации. Сквозные механизмы системы архитектурно исключают простое секционирование данных штатными средствами платформы.
Механизм ключей аналитики. В большинстве ключевых регистров накопления ERP (взаиморасчеты, себестоимость, регистры учета номенклатуры) измерение Организация отсутствует в явном виде. Вместо него используются ссылки на специальные справочники: КлючиАналитикиУчетаНоменклатуры, КлючиАналитикиУчетаПоПартнерам и другие. Простая фильтрация или удаление документов по реквизиту организации оставляет записи регистров нетронутыми либо приводит к появлению некорректных записей и нарушению целостности данных.
Схемы Интеркампани. Если между организациями велись межогранизационные продажи (документы ПередачаТоваровМеждуОрганизациями), разрыв этих цепочек делает невозможным расчет себестоимости и приводит к зависанию партий товаров.
Партионный учет и процедура закрытия месяца. Прямое удаление документов или остатков неизбежно ломает регистры СебестоимостьТоваров и ПартииТоваровПредприятий. Последующее регламентное закрытие месяца завершится ошибками расхождения остатков и отрицательными суммами.
Служебные очереди и фоновые задания. ERP использует множество системных очередей (очереди расчета себестоимости, очереди обновления взаиморасчетов). Если объект удален, а его идентификатор остался в таблице очереди, регламентные задания будут падать в аварийный режим.
Подход 1. Очистка копии рабочей базы
Данный вариант предполагает создание полной копии базы с последующим удалением лишней информации. Разберем по шагам, как правильно реализовать этот процесс, минимизируя риски:
Анализ межогранизационных связей. Выясним, имеются ли в базе операции Интеркампани с участием удаляемых компаний. Документы передач между организациями нельзя просто удалить: если товар был куплен одной организацией и перепродан другой, удаление исходной закупки приведет к отрицательным остаткам на складе. В таких ситуациях межогранизационные документы переделывают во входящие документы от внешних контрагентов.
Построение дерева зависимостей и распроведение документов. На больших базах стандартное интерактивное распроведение не сработает из-за огромного объема ссылочных связей. Распроведение и отмену проводок необходимо производить строго от конца периода к началу, предварительно собрав дерево подчиненности объектов.
Удаление записей через прямые запросы к СУБД. Для ускорения очистки на промышленных базах прибегают к прямым запросам на уровне SQL. Чтобы получить актуальные имена таблиц и полей в СУБД, используем метод платформы ПолучитьСтруктуруХраненияБазыДанных().
Посмотрим на пример получения имени таблицы регистра в СУБД:
ПараметрыИмен = Новый Массив;
ПараметрыИмен.Добавить("РегистрНакопления.СебестоимостьТоваров");
ТаблицыСУБД = ПолучитьСтруктуруХраненияБазыДанных(ПараметрыИмен, Истина);
Для Каждого СтрокаТаблицы Из ТаблицыСУБД Цикл
ИмяТаблицыSQL = СтрокаТаблицы.ИмяТаблицыХранения;
КонецЦикла;
Сброс итогов регистров и исправление базы.Критически важно: при удалении строк напрямую из таблиц движений в СУБД данные в отчетах продолжат отображаться некорректно, так как они читаются из таблиц агрегированных итогов. После любых прямых SQL-манипуляций обязательно выполняем операцию Тестирование и исправление информационной базы из конфигуратора с обязательными флагами «Пересчет итогов» и «Реструктуризация таблиц информационной базы».
Очистка служебных регистров сведений и очередей. Проверяем таблицы регистрации изменений планов обмена, независимые регистры сведений и очереди закрытия месяца, очищая записи, ссылающиеся на удаленные сущности.
Подход 2. Выгрузка и загрузка данных XML
Рассмотрим попытку выгрузки данных только нужной организации с помощью универсальной выгрузки/загрузки данных XML. Применение этого способа в ERP 2.5 связано с серьезными ограничениями:
Если включить опцию «Выгружать по ссылке», из-за сквозных регистров сведений, договоров, единых складов и взаиморасчетов за требуемой организацией неизбежно потянутся связанные документы остальных организаций. Фильтрации не произойдет.
Если отключить выгрузку по ссылкам, загруженная новая база окажется непригодной к эксплуатации из-за тысяч объектов типа Объект не найден. В ERP даже статус заказа или ключ аналитики являются ссылочными типами данных.
По этой причине перенос всей истории документов через XML по одной организации на практике признается неэффективным и трудоемким.
Подход 3. Рекомендуемый метод: перенос НСИ и ввод остатков
Проанализируем наиболее стабильный и архитектурно чистый подход, рекомендуемый при разделении баз класса ERP. Вместо очистки терабайтов исторических данных и восстановления сломанных партий применяется свертка через ввод остатков:
Подготовка целевой базы. Создаем пустую базу из того же файла конфигурации (включая все используемые расширения и доработки).
Перенос справочников (НСИ). С помощью правил конвертации данных (КД 2 или КД 3) переносим только нормативно-справочную информацию: номенклатуру, склады, контрагентов, партнеров, статьи расходов и статьи ДДС. Фильтруем справочники так, чтобы исключить элементы, относившиеся исключительно к удаляемым организациям.
Фиксация точки перехода. Выбираем контрольную дату (например, 1 января или начало квартала). На эту дату в исходной базе полностью закрываем месяцы и проверяем баланс.
Ввод начальных остатков. В целевой информационной базе создаем документы из раздела Ввод начальных остатков строго по требуемой организации:
Остатки собственных товаров на складах;
Остатки взаиморасчетов с клиентами и поставщиками;
Остатки денежных средств на расчетных счетах и в кассах;
Остатки по основным средствам и НМА.
Архивация исходной базы. Исходная база со всеми 5 организациями переводится в режим Только для чтения и сохраняется как исторический архив для получения регламентированной или управленческой отчетности за прошлые периоды.
Такой сценарий полностью исключает ошибки в расчете себестоимости, гарантирует чистые очереди заданий и обеспечивает стабильную производительность новой базы данных 1С:ERP.