Мы рассмотрим сложную, но часто востребованную задачу: предоставление доступа внешним контрагентам, таким как дилеры, к информационной базе 1С:Управление нашей фирмой (УНФ). Цель состоит в том, чтобы они могли самостоятельно формировать заказы, просматривать актуальные остатки товаров, видеть свои задолженности и цены. Мы выясним, почему типовой функционал БСП «Внешние пользователи» не работает в УНФ, и предложим различные пути решения этой задачи.
Начнем с главной проблемы: несмотря на то, что конфигурация 1С:УНФ построена на базе Библиотеки стандартных подсистем (БСП), которая включает функционал внешних пользователей, разработчики 1С официально заявляют, что в типовой конфигурации УНФ внешние пользователи не используются. Более того, при попытке принудительного включения соответствующей константы в последних релизах УНФ может появиться информационное сообщение: "Использование внешних пользователей в программе не предусмотрено". Это означает, что даже если нам удастся включить константу ИспользоватьВнешнихПользователей, логика программы УНФ не настроена на корректную работу с такими пользователями, и попытки входа под ними, скорее всего, будут безуспешными.
Разберем причину этого ограничения. Функционал внешних пользователей БСП — это не просто константа. Он требует глубокой интеграции с объектами конкретной конфигурации. В БСП есть общие механизмы управления доступом, но для их полноценной работы необходимо, чтобы конфигурация-наследник (в нашем случае УНФ) адаптировала свои объекты (документы, справочники, отчеты) для взаимодействия с этим механизмом. Если разработчики УНФ не реализовали такую адаптацию, то даже при наличии подсистемы внешних пользователей в составе БСП, она не сможет функционировать корректно.
Представим, что у вас есть самописная конфигурация. Вы успешно объединили ее с БСП. Можем ли мы сразу пользоваться всеми подсистемами БСП, включая внешних пользователей? Нет, не в полной мере. Некоторые подсистемы БСП (например, сохранение файлов или отправка SMS) интегрируются относительно легко, поскольку они не требуют глубокой переработки существующих объектов вашей конфигурации. Однако подсистема внешних пользователей требует, чтобы ваши бизнес-объекты (такие как "Заказ покупателя", "Реализация товаров и услуг", "Справочник Контрагенты") были адаптированы для работы с новым типом пользователя. Например, реквизит "Пользователь", который сейчас ссылается на справочник "Пользователи", должен быть изменен или дополнен для работы со справочником "Внешние пользователи". Это влечет за собой изменения в шаблонах ограничений, ролях, правах доступа и бизнес-логике всех связанных документов.
Таким образом, мы сталкиваемся с тем, что, хотя возможность технически присутствует в составе БСП, она "полукастрирована" в УНФ из-за отсутствия необходимой логики и адаптации со стороны разработчиков 1С. Это вынуждает нас либо идти по пути серьезной доработки, либо искать альтернативные решения.
Если ваша конфигурация 1С:УНФ уже снята с поддержки и активно дорабатывается под заказчика (как это часто бывает), мы можем рассмотреть возможность полноценного внедрения подсистемы внешних пользователей БСП. Это трудоемкий процесс, который фактически означает интеграцию новой подсистемы с нуля, используя БСП как основу. Вот что нам предстоит сделать:
Изучение реализации внешних пользователей в БСП: Мы должны получить актуальную версию БСП, не интегрированную ни в какую типовую конфигурацию, и детально изучить, как там реализован вход внешнего пользователя, его авторизация, работа с ролями, профилями и группами доступа. Мы анализируем все переопределяемые модули (ПереопределяемыеМодулиБСП), которые отвечают за эту функциональность, и понимаем их структуру и назначение.
Для этого мы можем:
Перенос и адаптация логики в УНФ: После того как мы глубоко разобрались в механизме БСП, мы переносим необходимую логику и объекты в нашу конфигурацию УНФ. Это часто включает в себя корректировку существующих модулей и добавление нового кода. Нам придется "перетянуть" все, что отвечает за внешних пользователей, и адаптировать это под особенности УНФ.
Ключевые шаги здесь:
Работа с переопределяемыми модулями: Многие ключевые места в БСП реализованы через переопределяемые модули. Нам придется реализовать или скорректировать процедуры в этих модулях, чтобы они вызывали нужные функции для работы с внешними пользователями в контексте УНФ. Это может быть:
// Пример возможной корректировки в переопределяемом модуле
// В модуле объекта "Пользователь" или "ОбщийМодульКлиентСервер"
Процедура ПриЗаписи(Отказ)
Если ТипЗнч(ЭтотОбъект) = Тип("СправочникОбъект.ВнешниеПользователи") Тогда
// Дополнительная логика обработки внешнего пользователя
// ...
КонецЕсли;
КонецПроцедуры
Корректировка ролей, профилей и групп доступа: Мы должны создать или модифицировать роли, которые будут доступны внешним пользователям. Эти роли должны быть очень специфичными и предоставлять доступ только к минимально необходимому функционалу (создание заказов, просмотр остатков, задолженности). Нам потребуется:
Доработка документов и объектов УНФ: Это один из самых трудоемких шагов. Все документы и справочники, которые должны взаимодействовать с внешними пользователями, необходимо доработать. Например, документ ЗаказПокупателя должен быть изменен так, чтобы он мог быть сформирован внешним пользователем и корректно связываться с ним.
ЗаказПокупателя) реквизит, который будет ссылаться на Справочник.ВнешниеПользователи, чтобы четко фиксировать, кто создал документ.Механизм аутентификации: Мы должны обеспечить, чтобы механизм входа внешнего пользователя работал корректно. Это может потребовать изменения общих модулей, отвечающих за аутентификацию и инициализацию сеанса пользователя.
Этот подход требует глубоких знаний платформы 1С, БСП и конфигурации УНФ. Это полноценное внедрение новой подсистемы на ваших эксклюзивных доработках, что влечет за собой высокие трудозатраты и потенциальные сложности при обновлении конфигурации.
Это более простой и менее инвазивный подход, который не требует активации механизма "Внешние пользователи" БСП в УНФ. Мы можем создать в нашей базе УНФ обычных пользователей 1С (то есть пользователей, которые хранятся в списке пользователей информационной базы 1С), но с крайне ограниченными правами доступа.
Создание новых пользователей: Для каждого дилера мы создаем отдельную учетную запись в списке пользователей 1С.
Разработка специализированных ролей: Это самый важный шаг. Мы создаем одну или несколько новых ролей, например, "ВнешнийДоступДилер", которые предоставляют минимально необходимый набор прав:
Номенклатура (возможно, с ограничением по группам номенклатуры).ЦеныНоменклатуры (с ограничениями по типам цен).ЗаказПокупателя (с ограничением на выбор своего контрагента).Мы используем ограничения прав доступа на уровне записей (RLS), чтобы каждый дилер мог видеть только свои заказы, свою задолженность и, возможно, только определенный ассортимент товаров или цены, актуальные для него.
// Пример запроса RLS для ограничения по контрагенту
#Если (ЗначениеДоступно("Чтение", "Справочник.Контрагенты")
ИЛИ ЗначениеДоступно("Добавление", "Справочник.Контрагенты")) #Тогда
ГДЕ Ссылка В (&МоиКонтрагенты)
#КонецЕсли
Где &МоиКонтрагенты — это список контрагентов, связанных с текущим пользователем. Этот список должен формироваться программно при старте сеанса или быть привязан к группам доступа.
Настройка профилей групп доступа: Создаем новый профиль, например, "ПрофильДилера", который будет содержать только нашу специализированную роль. Затем создаем группу доступа "Дилеры" и назначаем ей этот профиль. Каждый новый пользователь-дилер включается в эту группу.
Публикация базы на веб-сервере: Чтобы дилеры могли заходить удаленно, база должна быть опубликована на веб-сервере. Они будут использовать веб-клиент или тонкий клиент для доступа.
Преимущества: Этот метод более стабилен с точки зрения обновлений, так как мы не вмешиваемся в основные механизмы БСП по работе с внешними пользователями, которые не поддерживаются в УНФ. Он использует стандартные механизмы разграничения прав платформы 1С.
Недостатки: Количество пользователей ограничено лицензиями 1С. Требуется тщательная настройка RLS, чтобы избежать утечек данных.
Этот подход предлагает создать отдельную информационную базу, которая будет служить интерфейсом для внешних пользователей, а затем настроить обмен данными с основной базой 1С:УНФ. Эта база может быть как упрощенной конфигурацией, так и, например, "1С:Управление торговлей" или специально разработанной для этих целей.
Создание дополнительной ИБ: Мы разворачиваем новую информационную базу. В ней уже можем использовать или дорабатывать функционал внешних пользователей БСП без опасений за стабильность основной УНФ. Или же просто создавать там обычных пользователей, которые будут полноценными пользователями этой "дилерской" базы.
Реализация функционала для дилеров: В этой дополнительной базе мы реализуем весь необходимый функционал: создание заказов, просмотр наличия, цен, задолженностей. Здесь внешние пользователи будут работать как обычные пользователи, без ограничений, присущих УНФ.
Настройка обмена данными: Настраиваем обмен данными между дополнительной базой и основной УНФ. Обмен может быть:
Для реализации онлайн-обмена через COM-соединение, как упомянуто в одном из сообщений, нам потребуется роль ЗапускВнешнегоСоединения. Однако следует помнить, что эта настройка может "слетать", если другие пользователи меняют параметры через программу, что требует дополнительных механизмов контроля и восстановления прав.
// Пример упрощенного кода для работы с COM-соединением (требует доработки)
Попытка
COMОбъект = Новый COMОбъект("V83.Application");
COMОбъект.Connect("Srvr='Сервер1С';Ref='БазаУНФ';Usr='ПользовательОбмена';Pwd='ПарольОбмена';");
// Выполнение операций через COMОбъект
// Например, создание документа:
НовыйЗаказ = COMОбъект.NewObject("Документ.ЗаказПокупателя");
// ... заполнение реквизитов ...
НовыйЗаказ.Записать();
Исключение
Сообщить("Ошибка подключения или выполнения операции: " + ОписаниеОшибки());
КонецПопытки;
Важно: Автор темы явно выразил желание "сделать всё без обменов", поскольку "в он-лайне должен видеть текущее состояние дел. Очень быстро всё меняется". Однако, если глубокая доработка УНФ кажется слишком рискованной или затратной, онлайн-обмен с дополнительной базой может быть компромиссным, но жизнеспособным решением, позволяющим обеспечить требуемую актуальность данных.
Преимущества: Полностью изолирует внешних пользователей от основной УНФ, повышает безопасность. Упрощает обновления основной конфигурации УНФ. Позволяет реализовать любой специфический функционал для дилеров без влияния на УНФ.
Недостатки: Усложняет архитектуру системы, требует настройки и поддержки обменов. Затраты на разработку и лицензии для дополнительной базы.
Для предоставления доступа дилерам через привычный веб-интерфейс, мы можем разработать отдельный клиентский портал, интернет-магазин или мобильное приложение. Эти внешние системы будут интегрированы с УНФ.
Разработка внешнего интерфейса: Мы создаем веб-сайт, портал или мобильное приложение, которое предоставит дилерам удобный инструмент для:
Интеграция с 1С:УНФ: Для синхронизации данных и выполнения операций (например, создания заказов в УНФ) используются различные механизмы интеграции:
Преимущества: Гибкость в дизайне пользовательского интерфейса. Возможность создания богатого функционала. Высокая масштабируемость и безопасность, так как внешние пользователи не имеют прямого доступа к базе 1С.
Недостатки: Дополнительные затраты на разработку и поддержку веб-сайта/портала/приложения. Необходимость настройки и поддержания интеграционных механизмов.
Мы видим, что задача настройки внешних пользователей в 1С:УНФ не имеет простого типового решения. Официальная позиция 1С остается неизменной: этот функционал не предназначен для использования в типовой УНФ. Поэтому, перед нами стоит выбор между несколькими путями:
Глубокая доработка конфигурации: Это самый сложный и ресурсоемкий путь, требующий квалифицированных программистов и значительных изменений в конфигурации УНФ. Мы фактически берем на себя ответственность за поддержку и развитие этой части функционала, и каждое обновление БСП или УНФ может принести новые сложности.
Использование обычных пользователей 1С с ограниченными правами: Это более безопасный и менее затратный способ, который использует стандартные механизмы платформы 1С. Он подходит, если количество дилеров не очень велико и не требуется сверхсложный функционал.
Альтернативные архитектурные решения (дополнительная база, веб-портал): Эти подходы позволяют создать полноценное решение для внешних пользователей без глубокой модификации основной УНФ, но требуют создания и поддержания отдельных систем и механизмов обмена данными. Они обеспечивают максимальную гибкость и безопасность.
Выбор конкретного пути зависит от множества факторов: вашего бюджета, сроков, требований к безопасности, готовности к глубоким доработкам и квалификации вашей команды. Мы рекомендуем тщательно взвесить все "за" и "против" каждого подхода, прежде чем приступать к реализации.
Помните, что, если разработчики типовой конфигурации до сих пор не реализовали этот функционал, это может быть связано с серьезными трудностями, подводными камнями или умышленным ограничением, чтобы подтолкнуть к использованию более сложных систем или решений. В любом случае, мы не тратим время на поиск "простого включения" внешних пользователей в УНФ, а фокусируемся на реальных путях решения поставленной бизнес-задачи.