Как реализовать разное наименование одного документа для разных пользователей в 1С

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

Метод 1: Использование обработчиков в модуле менеджера

Для того чтобы документ назывался по-разному не только в заголовке окна, но и во всех списках, ссылках и полях выбора, нам необходимо переопределить стандартный механизм получения представления объекта. Рассмотрим основной инструмент программиста в этой задаче — обработчик ОбработкаПолученияПредставления.

Проанализируем работу этого метода в модуле менеджера документа. Этот обработчик вызывается системой каждый раз, когда ей нужно отобразить текстовое описание ссылки на документ. Мы можем написать условие, которое будет проверять роли текущего пользователя или параметры сеанса.

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

Процедура ОбработкаПолученияПредставления(Данные, Представление, СтандартнаяОбработка)
    
    СтандартнаяОбработка = Ложь;
    
    // Определяем роль пользователя через параметры сеанса или роли
    Если РольДоступна("Кладовщик") Тогда
        Префикс = "Приходный ордер ";
    Иначе
        Префикс = "Поступление товаров ";
    EndЕсли;
    
    Представление = Префикс + "№ " + ОбщегоНазначения.ПолучитьНомерНаПечать(Данные.Номер) + " от " + Формат(Данные.Дата, "ДФ=dd.MM.yyyy");
    
КонецПроцедуры

Используя этот метод, мы добиваемся того, что во всех динамических списках и отчетах пользователь будет видеть именно то название, которое соответствует его бизнес-логике. Однако стоит помнить, что чрезмерная сложность кода в этом обработчике может замедлить работу интерфейса, так как он вызывается очень часто.

Метод 2: Динамическое управление заголовками форм

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

Посмотрим на реализацию в модуле формы документа. Основную работу выполнит процедура ПриСозданииНаСервере. Мы можем проанализировать, из какой подсистемы или с какими правами открывается форма, и установить свойство Заголовок.

&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
    
    Если РольДоступна("Кладовщик") Тогда
        ЭтаФорма.Заголовок = "Складская накладная (создание)";
        Если ЗначениеЗаполнено(Объект.Ссылка) Тогда
            ЭтаФорма.Заголовок = "Складская накладная № " + Объект.Номер;
        КонецЕсли;
    КонецЕсли;
    
КонецПроцедуры

Этот способ позволяет гибко управлять визуальным восприятием формы. Если же требования дизайна подразумевают кардинально разный состав полей, то лучше создать две разные формы (например, ФормаДокументаБухгалтер и ФормаДокументаСклад) и настроить их открытие через обработчик ОбработкаПолученияФормы в модуле менеджера.

Метод 3: Использование общих команд для интерфейса

Одной из самых сложных задач является изменение названия документа в панели разделов (в командном интерфейсе подсистем). Синоним в дереве метаданных изменить динамически невозможно. Но мы можем применить архитектурную хитрость: использовать Общие команды.

Выясним, как это работает по шагам:

1. Создаем две общие команды: ОткрытьСписокДляБухгалтера и ОткрытьСписокДляКладовщика.
2. В свойстве Синоним каждой команды пишем нужное название (например, «Реестр закупок» и «Складской учет»).
3. В модуле команды прописываем код открытия формы списка документа ОткрытьФорму("Документ.НашДокумент.ФормаСписка").
4. Включаем каждую команду в соответствующую подсистему и настраиваем права доступа через роли.

Таким образом, в интерфейсе бухгалтера будет отображаться команда «Реестр закупок», а в интерфейсе кладовщика — «Складской учет», хотя вести они будут на один и тот же список документов.

Метод 4: Особенности отображения в отчетах (СКД)

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

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

Рекомендации по реализации

Подводя итог, выделим наиболее «чистый» алгоритм действий для решения этой задачи:

• Используйте ОбработкаПолученияПредставления для глобальной подмены названия ссылки во всей системе.
• Применяйте Общие команды для изменения названия в меню разделов.
• Программно меняйте свойство ЭтаФорма.Заголовок в обработчике ПриСозданииНаСервере для обеспечения комфортной работы в самой форме.
• Не забывайте про ОбработкаПолученияДанныхВыбора, чтобы при поиске документа (например, вводом по строке) пользователь также видел корректное название.

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