Как сохранить имена пользователей для входа при переходе с 1С:Бухгалтерия 2.0 на 3.0?

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

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

Выясним причину конфликта в архитектуре БСП

Современная «1С:Бухгалтерия 3.0» построена на базе Библиотеки стандартных подсистем (БСП). В этой архитектуре реализована жесткая связь между элементами справочника Пользователи и списком пользователей информационной базы (ИБ), который настраивается в Конфигураторе. Алгоритмы БСП при первом запуске после обновления пытаются сопоставить объекты старой базы с новой структурой.

Проанализируем логику системы: в концепции БСП один реальный человек (одно физическое лицо) должен иметь одну учетную запись. Если в БП 2.0 создано пять пользователей с абсолютно одинаковым значением в поле «Полное имя» (например, «Иванов Иван Иванович»), система миграции воспринимает их как дубли одного и того же человека. В результате она переносит настройки только для первой найденной записи, а остальные помечает как некорректные, сбрасывая им параметры аутентификации.

Разберем проблему «Имя (для входа) уже занято»

Когда мы пытаемся вручную восстановить логин в БП 3.0 после неудачного перехода, мы сталкиваемся с ошибкой уникальности. Это происходит потому, что записи в таблице пользователей информационной базы (в метаданных) фактически существуют, но они «отвязаны» от элементов справочника Пользователи. Система видит, что логин «Ivanov_1» уже зарезервирован за неким внутренним идентификатором (UUID), и не позволяет назначить его повторно другому элементу справочника.

Инструкция по подготовке пользователей в БП 2.0 перед переходом

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

1. Откроем базу БП 2.0 в режиме «1С:Предприятие».
2. Перейдем в справочник «Пользователи».
3. Проверим поле «Полное имя» у всех сотрудников. Если у вас используется схема «один сотрудник — несколько логинов для разных организаций», необходимо сделать полные имена уникальными. Например:
   • «Иванов Иван Иванович (Организация 1)»
   • «Иванов Иван Иванович (Организация 2)»
4. Важный технический нюанс: эти изменения должны быть продублированы в списке пользователей информационной базы в Конфигураторе.

Проанализируем ситуацию, когда данные в справочнике и в Конфигураторе различаются. Если в справочнике имя изменено, а в списке пользователей ИБ (через меню «Администрирование — Пользователи») осталось старое «Полное имя», сопоставление при переходе на БП 3.0 снова может дать сбой. Проверьте, чтобы значения совпадали в обоих местах.

Как обеспечить соответствие пользователей справочнику

Для того чтобы программно или полуавтоматически выровнять данные, можно воспользоваться следующим подходом. Проверим наличие соответствующих записей в списке пользователей ИБ. Если для элемента справочника Пользователи нет сопоставленного пользователя в Конфигураторе, его нужно создать или перепривязать. Рассмотрим пример кода, который может помочь в анализе соответствия (использовать в обработке в БП 2.0):

Выборка = Справочники.Пользователи.Выбрать();
Пока Выборка.Следующий() Цикл
    ИмяПользователяИБ = Выборка.Наименование; // Логин
    ПользовательИБ = ПользователиИнформационнойБазы.НайтиПоИмени(ИмяПользователяИБ);
    
    Если ПользовательИБ = Неопределено Тогда
        Сообщить("Для пользователя " + Выборка.ПолноеИмя + " не найден логин в ИБ!");
    Иначе
        Если ПользовательИБ.ПолноеИмя <> Выборка.ПолноеИмя Тогда
            Сообщить("Несовпадение полных имен для: " + ИмяПользователяИБ);
        КонецЕсли;
    КонецЕсли;
КонецЦикла;

Что делать, если переход уже выполнен?

Если вы уже обновились до БП 3.0 и обнаружили «размножение» или «зависание» пользователей, рассмотрим план действий по исправлению ситуации в новой базе:

1. Зайдите в базу через Конфигуратор.
2. Откройте список пользователей информационной базы.
3. Найдите записи, у которых нет связи со справочником (они могут выглядеть как записи с логинами, но без привязки к объектам 1С).
4. Удалите лишние записи или переименуйте их логины, чтобы освободить нужные имена для входа.
5. В режиме «1С:Предприятие» зайдите в справочник Пользователи, установите флаг «Вход в программу разрешен» и заново выберите аутентификацию 1С, указав корректное имя для входа.

Рекомендации по дальнейшей работе (механизм RLS)

Метод создания пяти разных учетных записей для одного человека, чтобы он «не перепутал организации», в современных версиях 1С считается устаревшим. Проанализируем более эффективный подход, который предлагает архитектура БП 3.0.

Вместо создания множества логинов рекомендуется использовать механизм RLS (Row Level Security) — ограничение доступа на уровне записей. Рассмотрим, как это работает:

1. Создается одна учетная запись для пользователя.
2. В разделе «Администрирование — Настройки пользователей и прав» включается возможность ограничения доступа на уровне записей.
3. Для пользователя создаются разные Группы доступа, в каждой из которых в качестве ограничения указана конкретная организация.
4. Пользователь заходит под одним именем, но видит документы только тех организаций, которые ему разрешены.

Это решение гораздо стабильнее при обновлениях и позволяет избежать путаницы с паролями и именами для входа. Однако, если бизнес-процесс требует именно разных сеансов, обязательно соблюдайте правило уникальности Полного имени в связке Пользователи — ПользователиИнформационнойБазы.

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