При посменной работе нескольких сотрудников на одном физическом компьютере часто возникает критическая проблема: действия, совершаемые пользователем А (звонки, продажи, создание документов, заметки), система внезапно записывает на пользователя Б. Ситуация становится абсурдной, когда сотрудник находится на больничном или в отпуске, но под его учетной записью в базе продолжают регистрироваться звонки и оформляться заказы. При этом сами сотрудники уверяют, что заходят под своими личными паролями и не передают их коллегам.
В этой статье мы подробно разберем, почему возникает путаница с авторизацией и фиксацией действий пользователей в 1С, проанализируем программные и системные причины этой ошибки, а также выработаем пошаговый план решения проблемы.
Первое, на что необходимо обратить внимание — это то, как именно прикладное решение определяет текущего авторизованного пользователя в момент записи документов или создания событий. В платформе 1С запущенный сеанс жестко привязан к конкретной учетной записи информационной базы. Однако разработчики конфигураций (особенно кастомных или сильно доработанных) часто используют собственные механизмы для определения автора действий.
Проанализируем ситуацию: если в журнале регистрации 1С сеанс зафиксирован под пользователем Б, но созданные им документы записываются на пользователя А, проблема гарантированно кроется в программном коде. Чаще всего разработчики совершают две ошибки:
ТекущийПользователь. Если инициализация этого параметра происходит с ошибкой или значение кэшируется некорректно, система может подставлять данные предыдущего сеанса.Рассмотрим пример ошибочной логики, при которой система пытается определить пользователя по наименованию учетной записи операционной системы:
// Пример НЕКОРРЕКТНОГО определения пользователя в коде
Функция ОпределитьТекущегоПользователя() Экспорт
ИмяОС = ИмяПользователяОС();
// Опасный поиск: если на ПК используется общая учетная запись Windows,
// система всегда будет возвращать одного и того же первого найденного пользователя
НайденныйПользователь = Справочники.Пользователи.НайтиПоНаименованию(ИмяОС);
Возврат НайденныйПользователь;
КонецФункции
Чтобы исключить подобные сбои, необходимо реализовать жесткую привязку к уникальному идентификатору пользователя информационной базы. Посмотрим на пример корректной инициализации параметра сеанса в модуле сеанса:
// Корректная установка параметра сеанса при запуске системы
Процедура УстановкаПараметровСеанса(ТребуемыеПараметры)
Если ТребуемыеПараметры = Неопределено
Или ТребуемыеПараметры.Найти("ТекущийПользователь") <> Неопределено Тогда
ТекущийПользовательИБ = ПользователиИнформационнойБазы.ТекущийПользователь();
УникальныйID = ТекущийПользовательИБ.УникальныйИдентификатор;
// Поиск пользователя по уникальному идентификатору связи с ИБ
НайденныйПользователь = Справочники.Пользователи.НайтиПоРеквизиту("ИдентификаторПользователяИБ", УникальныйID);
Если НайденныйПользователь.Пустая() Тогда
// Резервный поиск по точному имени учетной записи 1С
НайденныйПользователь = Справочники.Пользователи.НайтиПоРеквизиту("ИмяВхода", ТекущийПользовательИБ.Имя);
КонецЕсли;
ПараметрыСеанса.ТекущийПользователь = НайденныйПользователь;
КонецЕсли;
КонецПроцедуры
При записи любых документов, звонков или задач реквизит "Ответственный" или "Автор" должен заполняться исключительно из параметра сеанса: ПараметрыСеанса.ТекущийПользователь.
Симптом, при котором сотрудник находится на больничном, но система упорно регистрирует звонки от его имени — это классическая проблема настройки телефонии (Mango Office, МИКО, Рарус:СофтФон, Asterisk и др.).
Разберем, почему так происходит. При интеграции АТС с 1С часто настраивается статическая привязка физического телефона или софтфона (программы для звонков на компьютере) к конкретному сотруднику. Например, за рабочим местом №3 закреплен внутренний номер 103, который в настройках телефонии жестко ассоциирован со справочником пользователей 1С на имя «Сотрудник А».
Когда «Сотрудник А» уходит на больничный, а за его рабочий стол садится посменный «Сотрудник Б» под своей учетной записью 1С, интеграционный модуль телефонии продолжает работать по старой схеме. При поступлении входящего или совершении исходящего звонка АТС отправляет в 1С событие, привязанное к внутреннему номеру 103. Робот или регламентное задание 1С обрабатывает это событие и автоматически создает документ «Телефонный звонок», указывая автором «Сотрудника А» на основе статических настроек сопоставления линий, полностью игнорируя текущую активную сессию 1С.
Решение проблемы телефонии:
При оформлении розничных продаж, чеков ККМ и работе с торговым оборудованием система 1С использует механизмы Библиотеки стандартных подсистем (БСП) для определения текущего «Рабочего места». Рабочее место в 1С — это уникальный идентификатор (GUID), который генерируется при первом подключении оборудования и записывается в локальный кэш пользователя Windows.
Если посменные сотрудники работают на одном компьютере под одной и той же учетной записью операционной системы Windows, у них будет абсолютно идентичный локальный кэш и одинаковый ID рабочего места. В результате кассовые смены открываются «в кучу», а продажи могут записываться на того пользователя, который первым открыл смену или зарегистрировал оборудование в текущих сутках.
Чтобы решить эту проблему, необходимо настроить операционную систему так, чтобы каждый физический сотрудник имел свою персональную учетную запись Windows. Это гарантирует разделение локальных папок кэша, реестра и настроек торгового оборудования.
Очень часто посменная работа организуется на терминальном сервере (RDP). Здесь кроется серьезная организационно-техническая проблема: некорректное завершение работы пользователями.
Выясним типичный сценарий: сотрудник А завершает смену и вместо того, чтобы нажать «Выход» (Logoff) в Windows, просто закрывает окно удаленного рабочего стола «крестиком». На сервере его сессия переходит в статус Disconnected (Отключена), но все запущенные программы, включая 1С, продолжают активно работать в оперативной памяти сервера.
Когда за этот же физический компьютер садится сотрудник Б, запускает RDP-подключение (особенно если используются общие учетные записи для авторизации на терминале), сервер может автоматически восстановить старую «зависшую» сессию сотрудника А. Сотрудник Б видит перед собой уже открытую базу 1С под чужим именем и начинает в ней работать, даже не обращая внимания на заголовок программы.
Как предотвратить путаницу в RDP:
Disconnected более 5–10 минут, сервер должен принудительно закрывать все процессы (выполнять Logoff).Если работа с 1С ведется через браузер (веб-клиент) под управлением веб-серверов IIS или Apache, то причиной путаницы может стать пул сессий (Session Pooling) и cookies браузера.
Если пользователь А просто закрыл вкладку браузера с 1С, его сессия на веб-сервере продолжает жить (по умолчанию до 20 минут). Если в этот момент за компьютер садится пользователь Б, открывает тот же браузер и переходит по ссылке в 1С, веб-сервер по сохраненным cookies может мгновенно восстановить сессию пользователя А без запроса логина и пароля.
Приучите сотрудников выходить из системы строго через меню «Сервис и настройки» — «Завершить работу» (или кнопку «Выход» в интерфейсе), а не простым закрытием вкладки или браузера. При корректном выходе cookies авторизации уничтожаются, предотвращая несанкционированный доступ.
Постоянная смена пользователей на одном ПК под одной учетной записью Windows приводит к быстрому засорению и повреждению локального кэша платформы 1С. В кэше могут некорректно сохраняться настройки форм, значения по умолчанию и параметры предыдущих сеансов, что вызывает непредвиденное поведение интерфейса.
Рекомендуется настроить регулярную очистку кэша. Самый простой способ — добавить параметр запуска /ClearCache в настройки запуска базы в стартере 1С:
/ClearCacheЧтобы раз и навсегда исключить ситуации, когда действия сотрудников записываются на чужие учетные записи, выполните следующие шаги: