Как решить проблемы с пользователями, видимостью документов и сверткой данных при переносе между базами 1С:Управление торговлей 11?

Перенос данных между двумя одинаковыми конфигурациями 1С часто кажется тривиальной задачей. Мы ожидаем, что выгрузка через стандартную обработку Выгрузка и загрузка данных XML решит все проблемы в один клик. Однако на практике разработчики сталкиваются с неочевидным поведением платформы и прикладных решений: «пропадают» пользователи, очищаются пароли, перенесенные документы не отображаются в журналах, а попытка свернуть базу стандартными средствами приводит к падению СУБД из-за нехватки памяти.

В этой статье мы подробно разберем три ключевые проблемы, возникшие при частичном переносе данных в конфигурации «1С:Управление торговлей 11» (на платформе 1С:Предприятие 8.3), проанализируем причины их возникновения и найдем оптимальные технические решения.

Проблема 1. Перенос пользователей: сброс паролей и признака «Вход в программу разрешен»

Выясним причину происходящего. При использовании обработки Выгрузка и загрузка данных XML переносятся только элементы справочника Пользователи. Но в платформе 1С:Предприятие учетные записи пользователей разделены на две сущности:

1. Справочник «Пользователи» — это объект метаданных прикладного решения. Данные хранятся в стандартных таблицах СУБД. Именно этот справочник мы видим в пользовательском интерфейсе.
2. Пользователи информационной базы (ИБ) — это системные учетные записи самой платформы. Они хранятся на уровне СУБД в служебных таблицах (например, в таблице v8users) или в специальном файле базы данных. Доступ к ним осуществляется только через платформенные методы.

Когда мы переносим справочник XML-выгрузкой, элементы справочника успешно загружаются в новую базу. Однако на уровне платформы новые пользователи ИБ автоматически не создаются. Из-за этого при открытии карточки пользователя флаг «Вход в программу разрешен» оказывается снят, а пароли «слетают», поскольку физически отсутствуют хэши паролей в системной таблице.

Когда вы вручную ставите галочку разрешения входа и записываете карточку, срабатывают механизмы Библиотеки стандартных подсистем (БСП). Система программно создает пользователя ИБ и связывает его с элементом справочника Пользователи.

Решение проблемы:

Для корректного переноса пользователей вместе с паролями стандартная XML-выгрузка не подходит. Рассмотрим два альтернативных варианта решения этой задачи:

1. Использование специализированных обработок. Существуют готовые решения, которые считывают системных пользователей из исходной базы через COM-соединение или специализированный файл обмена и воссоздают их в приемнике с сохранением хэшей паролей.
2. Программный перенос через «1С:Конвертация данных». Если вы настраиваете правила обмена, вы можете прописать произвольный алгоритм в обработчиках. Платформа 1С позволяет получить хэш пароля и записать его в приемник программным путем с помощью объекта ПользовательИнформационнойБазы.

Проблема 2. Документы перенесены, но их не видно в журналах («Внутренние документы» и др.)

Проанализируем ситуацию. В современных конфигурациях 1С (УТ 11, Комплексная автоматизация, ERP) для оптимизации работы динамических списков используется специальный механизм. Вместо того чтобы при открытии общего журнала документов (например, «Внутренние документы все») делать тяжелые запросы к множеству таблиц различных документов, система обращается к одному вспомогательному регистру сведений — «Реестр документов».

Именно этот регистр выступает в роли единого хранилища облегченных данных для отображения списков. Когда мы записываем или проводим документ в обычном режиме, подсистема БСП автоматически делает запись в регистр Реестр документов.

Однако при переносе данных через обработку Выгрузка и загрузка данных XML запись объектов происходит в специальном режиме: Загрузка = Истина. В этом режиме платформа отключает выполнение всех стандартных обработчиков событий (таких как ПриЗаписи, ПередЗаписью, ОбработкаПроведения), чтобы обеспечить максимальную скорость загрузки и избежать конфликтов ссылочной целостности. Как результат — документы физически перенесены в базу данных, но записи в регистре Реестр документов для них отсутствуют. Из-за этого документы видны в списке «Все функции» (где отображается прямая таблица документа), но полностью отсутствуют в стандартных журналах.

Решение проблемы:

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

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

Разберем пример кода для заполнения реестра:

Процедура ЗаполнитьРеестрДокументовНаСервере()
    
    // Выберем все документы "Перемещение товаров" за нужный период
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |   ПеремещениеТоваров.Ссылка КАК Ссылка
        |ИЗ
        |   Документ.ПеремещениеТоваров КАК ПеремещениеТоваров
        |ГДЕ
        |   ПеремещениеТоваров.Дата МЕЖДУ &НачалоПериода И &КонецПериода";
        
    Запрос.УстановитьПараметр("НачалоПериода", НачалоДня(Объект.ПериодРегистрации.ДатаНачала));
    Запрос.УстановитьПараметр("КонецПериода", КонецДня(Объект.ПериодРегистрации.ДатаОкончания));
    
    РезультатЗапроса = Запрос.Выполнить();
    ВыборкаДетальныеЗаписи = РезультатЗапроса.Выбрать();
    
    Пока ВыборкаДетальныеЗаписи.Следующий() Цикл
        
        // Используем встроенный метод менеджера регистра сведений "РеестрДокументов"
        // Этот метод сформирует записи в регистре без изменения самого документа
        Отказ = Ложь;
        ДополнительныеСвойства = Новый Структура;
        
        РегистрыСведений.РеестрДокументов.ЗаписатьДанныеДокумента(
            ВыборкаДетальныеЗаписи.Ссылка, 
            ДополнительныеСвойства, 
            Отказ
        );
        
    КонецЦикла;
    
КонецПроцедуры

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

Проблема 3. Стандартная свертка базы «вешает» SQL-сервер

Выясним причину проблемы. При попытке свернуть базу размером около 7 Гб стандартными механизмами и последующем удалении помеченных объектов система 1С начинает проверять ссылочную целостность для сотен тысяч документов. SQL-сервер пытается удержать в оперативной памяти гигантские таблицы блокировок и временные данные транзакций, что приводит к переполнению памяти СУБД и падению процесса с ошибкой Нехватка памяти.

Вместо долгого удаления старых документов стандартными методами или написания сложных обработок очистки, мы можем применить альтернативный, гораздо более быстрый и изящный метод свертки — использование распределенной информационной базы (РИБ).

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

1. Создание плана обмена. В исходной базе мы находим или создаем план обмена (например, типовой план обмена по организациям или создаем новый тестовый план обмена).
2. Настройка правил регистрации. В правилах регистрации объектов для созданного плана обмена мы жестко прописываем ограничение по дате: регистрировать и переносить документы только начиная с 01.08.2018. Справочники при этом настраиваем на полную выгрузку.
3. Создание начального образа. Мы запускаем процесс создания начального образа подчиненного узла РИБ. Платформа 1С самостоятельно и на уровне СУБД сгенерирует новую базу данных. При этом в нее попадут абсолютно все справочники, но документы перенесутся только за период с 01.08.2018. Все старые документы будут проигнорированы. Процесс создания образа происходит значительно быстрее, чем транзакционное удаление миллионов записей.
4. Отвязка подчиненного узла от главного. Полученную подчиненную базу необходимо превратить в самостоятельную рабочую базу. Для этого мы должны отключить ее от главного узла. Разберем, как это сделать программно.

Для отключения базы от РИБ запустим базу-приемник в режиме 1С:Предприятие под правами администратора и выполним следующий код:

Процедура ОтвязатьБазуОтРИБ()
    
    // Сбрасываем связь с главным узлом
    ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
    
    // В базах на БСП необходимо также очистить служебные константы,
    // чтобы система не считала себя автономным рабочим местом
    ОбновлениеИнформационнойБазы.ЗаписатьКонстанту("НастройкаПодчиненногоУзлаРИБЗавершена", Ложь);
    ОбновлениеИнформационнойБазы.ЗаписатьКонстанту("ЭтоАвтономноеРабочееМесто", Ложь);
    
    ВызватьИсключение "База успешно отвязана от РИБ. Перезапустите сеанс!";
    
КонецПроцедуры

Также отвязать базу от главного узла можно через командную строку, запустив Конфигуратор базы-приемника с параметром /ResetMasterNode.

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

Резюме

Мы детально рассмотрели процесс частичного переноса данных и выявили ключевые особенности работы платформы 1С:Предприятие 8.3:

1. При переносе справочника Пользователи стандартным XML-обменом всегда требуется повторная программная или ручная инициализация пользователей информационной базы на уровне СУБД.
2. Загрузка документов в режиме Загрузка = Истина требует обязательного последующего обновления вспомогательного регистра Реестр документов для восстановления их видимости в динамических списках.
3. Для частичного переноса данных или свертки крупных баз использование механизма РИБ с фильтрацией по дате является гораздо более надежным и производительным решением, чем стандартное удаление помеченных объектов средствами СУБД.