Пользователь с таким именем уже существует в 1С:ЗУП: решение

📅 Опубликовано 20 августа 2026 г.

Коротко: сообщение «Ошибка регистрации в базе данных: пользователь с таким именем уже существует» в 1С:ЗУП относится не к кадровым данным, а к имени входа. Платформа хранит имена пользователей информационной базы в едином пространстве имён и не учитывает регистр букв, поэтому второй такой же логин создать невозможно. Чаще всего имя занял пользователь, помеченный на удаление, помеченный как недействительный или вообще не связанный со справочником «Пользователи». Исправление занимает немного времени и не требует программирования.

Главное об ошибке

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

Что означает «Ошибка регистрации в базе данных» в 1С:ЗУП?

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

Чем пользователь ИБ отличается от элемента справочника «Пользователи»?

Это два разных объекта, и путаница между ними — источник большинства обращений в поддержку. Элемент справочника «Пользователи» — прикладная сущность: к ней привязываются права доступа, настройки, физическое лицо, подразделение. Пользователь информационной базы — техническая учётная запись платформы: имя входа, пароль или аутентификация ОС, набор ролей, язык интерфейса. Связь между ними хранится по внутреннему идентификатору.

Разрыв этой связи и порождает эффект «невидимого двойника»: в справочнике «Пользователи» нужного логина нет, а на уровне платформы он есть и занимает имя. Такое происходит после восстановления базы из архива, выгрузки-загрузки файла .dt, обмена данными между базами, ручного создания учётных записей в Конфигураторе или удаления элемента справочника без удаления самой учётной записи.

На каком именно шаге найма появляется сообщение?

Ошибка возникает не в самом документе «Приём на работу», а в смежных операциях, которые обычно выполняются в тот же день:

создание доступа новому сотруднику в разделе «Администрирование» → «Настройки пользователей и прав» → «Пользователи»;
выдача прав из карточки сотрудника — по гиперссылке «Права доступа» или «Вход в программу»;
подключение сотрудника к сервису «1С:Кабинет сотрудника», где логином выступает адрес электронной почты;
массовая загрузка сотрудников из файла или из другой базы, когда учётные записи создаются пакетно;
синхронизация 1С:ЗУП с 1С:Бухгалтерией, при которой пользователи переносятся вместе с прочими данными.

Почему ошибка появляется именно при приёме на работу?

Приём — это единственная кадровая операция, которая почти всегда сопровождается заведением новой учётной записи. Кроме того, именно в момент найма проявляются накопленные ранее проблемы: старые уволенные сотрудники с теми же фамилиями, дубли физических лиц, «осиротевшие» учётные записи после переноса базы. Пока новых логинов не создают, конфликт спит; первая же попытка выдать доступ его вскрывает.

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

7 причин ошибки и как их проверить

Ниже — сводная таблица типовых сценариев. Она закрывает практически все обращения по этой ошибке в 1С:ЗУП 3.1.

№	Причина	Как проверить	Что сделать
1	Логин занят недействительным пользователем	В списке «Пользователи» включить «Показывать недействительных пользователей»	Переиспользовать запись или сменить имя входа
2	Пользователь помечен на удаление, но не удалён	Включить отображение помеченных объектов в списке	Снять пометку и переназначить или полностью удалить объект
3	Учётная запись ИБ без связи со справочником	Список пользователей ИБ (Конфигуратор или команда «Пользователи информационной базы»)	Восстановить связь либо удалить «осиротевшую» запись
4	Имя занято внешним пользователем или кабинетом сотрудника	Проверить раздел внешних пользователей и настройки сервиса кабинета	Задать другой логин или отвязать лишнюю учётную запись
5	Однофамильцы с одинаковыми инициалами	Сравнить формируемое имя входа с существующими	Добавить второй инициал, цифру или табельный номер
6	Повторный приём ранее уволенного сотрудника	Найти физлицо в списке физических лиц и его прежние доступы	Активировать старую учётную запись, не создавая новую
7	Пользователь пришёл из другой базы при синхронизации	Проверить состав правил обмена и дату создания записи	Исключить пользователей из обмена, устранить дубль

Почему однофамильцы — самая частая причина?

Шаблон «фамилия + первая буква имени» кажется удобным ровно до момента, когда в компанию приходит второй Иванов Иван. Коллизия возникает и при транслитерации: Кузнецов может быть записан как Kuznecov и Kuznetsov — оба варианта уникальны для платформы, но человек путается, а администратор создаёт третий. Второй подводный камень — визуально одинаковые символы кириллицы и латиницы (А, С, Е, О, Р). Логин «выглядит новым», а платформа считает иначе, если раньше уже был создан такой же набор символов.

Что происходит при повторном найме уволенного?

Кадровик оформляет нового сотрудника, но физическое лицо в базе уже существует — со всеми старыми настройками и учётной записью. Если при приёме создать новый элемент справочника «Сотрудники» и попытаться выдать ему прежний логин, платформа откажет. Хуже, если создаётся ещё и дубль физлица: тогда к ошибке доступа добавляются проблемы с исчислением НДФЛ и страховых взносов нарастающим итогом, а также некорректная отчётность в СФР. Похожие последствия рассинхронизации данных мы разбирали в материале про протокол об ошибке из СФР в 1С:ЗУП 3.1.

Как найти пользователя, который занял имя?

Задача — увидеть полный список имён входа, а не отфильтрованную витрину справочника. Есть три способа, они дополняют друг друга.

Способ 1. Через режим «1С:Предприятие»

Откройте раздел «Администрирование» → «Настройки пользователей и прав» → «Пользователи».
Нажмите «Ещё» и включите «Показывать недействительных пользователей».
В том же меню включите отображение помеченных на удаление объектов (либо снимите фильтр в настройках списка).
Отсортируйте список по колонке с именем входа: если колонка не выведена, добавьте её через «Ещё» → «Изменить форму».
Если у вас есть административные права, откройте «Ещё» → «Пользователи информационной базы»: здесь видны все учётные записи платформы, включая те, у которых нет пары в справочнике.

Этот путь безопасен: он не требует монопольного режима и не затрагивает работу других пользователей.

Способ 2. Через Конфигуратор

Если административной команды в интерфейсе нет или список выглядит подозрительно коротким, зайдите в Конфигуратор под учётной записью с полными правами и откройте «Администрирование» → «Пользователи». Здесь платформа показывает абсолютно все имена входа — именно с этим перечнем сверяется проверка уникальности. Найдите строку с конфликтующим именем и посмотрите, какие роли ей назначены и есть ли у неё осмысленное полное имя.

Способ 3. Через консоль администрирования кластера

В клиент-серверном варианте полезно заглянуть в консоль администрирования кластера: там видно, есть ли активные сеансы под спорным именем. Иногда «занятость» логина объясняется просто — под ним прямо сейчас работает сотрудник другого филиала, о котором в головном офисе забыли.

Как исправить ошибку: пошаговый алгоритм

Порядок действий зависит от того, кем оказался «двойник». Универсальная последовательность выглядит так.

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

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

Что делать при повторном приёме и дублях физлиц?

Повторный приём требует аккуратности не только в части доступа. Прежде чем создавать нового сотрудника, найдите физическое лицо в разделе «Кадры» → «Физические лица» по ИНН и СНИЛС — это надёжнее поиска по ФИО, особенно после смены фамилии. Если физлицо найдено, оформляйте приём на существующее физлицо: тогда налоговая база и вычеты продолжатся корректно.

Если дубль всё же создан, не редактируйте документы вручную. Воспользуйтесь стандартным инструментом: «Администрирование» → «Обслуживание» → «Корректировка данных» → «Поиск и удаление дублей». Обработка покажет ссылки на дублирующий элемент и предложит заменить их на основной. После объединения обязательно перепроведите документы месяца и сверьте суммы НДФЛ и взносов — ошибки, всплывающие уже на этапе отчётности, разбирались в разборе про ошибку логического контроля СФР.

Дубли физлиц влияют и на кадровые механизмы расчёта: у «нового» сотрудника нет истории отпусков и среднего заработка, из-за чего появляются смежные сбои — например, ситуация, когда программа не может подобрать вид начисления для оплаты отпуска. Поэтому чистка дублей — не косметика, а профилактика отчётных проблем.

Найдите специалиста для решения этой задачи на koderion.ru

Нужна помощь с расчётом зарплаты в 1С — исполнители по 1С:ЗУП на бирже.