При работе с типовыми конфигурациями 1С:Предприятие, такими как "Управление торговлей", редакция 10.3, у пользователей часто возникает потребность в добавлении новых полей или флагов для отражения специфических бизнес-процессов. Одним из таких распространённых требований является необходимость отметки документов как "проверенных". В этой статье мы подробно рассмотрим, как можно реализовать добавление такого пользовательского реквизита под названием "Проверено" в документы вашей системы, проанализируем различные подходы и выясним их особенности, особенно в контексте устаревших, но всё ещё актуальных конфигураций, таких как УТ 10.3.
Мы столкнёмся с тем, что прямое добавление "стандартного" реквизита в 1С невозможно, так как "стандартные" реквизиты (например, Дата, Номер) являются частью платформы или типовой структуры объектов и не могут быть произвольно изменены пользователем. Однако, существует несколько механизмов, позволяющих гибко расширять функциональность документов. Мы разберем два основных метода: использование дополнительных реквизитов и использование общих реквизитов, а также уделим внимание важному аспекту разграничения прав доступа.
Наиболее рекомендуемым и гибким решением для добавления пользовательских полей, таких как наш реквизит "Проверено", является использование механизма дополнительных реквизитов. Этот подход позволяет вносить изменения в структуру данных документов и справочников непосредственно в режиме "1С:Предприятие", без необходимости заходить в "Конфигуратор" и снимать конфигурацию с поддержки. Это критически важно для сохранения возможности лёгкого обновления типовой конфигурации в будущем.
Рассмотрим по шагам, как добавить дополнительный реквизит "Проверено" в документы УТ 10.3.
Прежде всего, нам необходимо убедиться, что функционал дополнительных реквизитов и сведений активен в вашей базе 1С. Для этого мы последовательно выполняем следующие действия в режиме "1С:Предприятие":
После активации функционала система может предложить перезапустить программу, чтобы изменения вступили в силу.
Теперь, когда механизм включён, мы можем приступить к созданию самого реквизита "Проверено".
После создания дополнительный реквизит автоматически появится на форме выбранного документа. Обычно он размещается на отдельной закладке, часто называемой "Дополнительно", "Реквизиты" или в специальном разделе формы документа. Пользователи смогут отмечать этот флажок непосредственно при работе с документом.
Преимущества использования дополнительных реквизитов очевидны:
Помимо дополнительных реквизитов, существует другой механизм – общие реквизиты. Этот подход также позволяет добавлять новые поля, но требует внесения изменений в конфигурацию в режиме "Конфигуратор".
Рассмотрим, в каких случаях мы можем использовать общие реквизиты и как это делается:
Общие реквизиты предназначены для добавления одинаковых по имени и типу реквизитов сразу для нескольких или даже всех объектов метаданных (документов, справочников и т.п.) в конфигурации. Они используются в двух основных сценариях:
Для добавления общего реквизита мы должны:
ПровереноОбщий) и выбрать тип значения "Булево".Как было упомянуто в обсуждении на форуме, в конфигурации УТ 10.3 могут существовать определённые ограничения или особенности режима совместимости платформы, которые могут усложнить или сделать менее предпочтительным использование общих реквизитов для простых пользовательских флагов. Работа с общими реквизитами в старых конфигурациях требует осторожности, так как любое изменение в "Конфигураторе" несёт риски и требует тестирования. Кроме того, любое изменение конфигурации в "Конфигураторе" ведёт к снятию с поддержки или созданию расширения (что не всегда доступно в УТ 10.3), что может затруднить будущие обновления.
Исходя из этих соображений, для задачи добавления простого флага "Проверено" мы чаще всего рекомендуем прибегать к дополнительным реквизитам, как к более простому и безопасному способу.
Вопрос разграничения прав доступа к созданному реквизиту – это не менее важный аспект, который мы должны обязательно рассмотреть. Часто бывает так, что не все пользователи должны иметь возможность устанавливать или снимать отметку "Проверено". Например, только главный бухгалтер или руководитель отдела должен иметь право на такую отметку.
Разберем, как мы можем управлять правами доступа для наших реквизитов.
Для дополнительных реквизитов права на их изменение обычно тесно связаны с правами пользователя на сам объект (документ). Это означает, что:
// Пример программной проверки прав при записи документа
// (Добавляется в обработчик ПередЗаписью() или ПриЗаписи() документа в Конфигураторе)
Если НЕ ЭтоНовый Тогда // Проверяем только при изменении существующего документа
// Получаем текущее значение реквизита "Проверено" из базы данных
// Предполагается, что 'ДополнительныеСвойства' - это коллекция доп. реквизитов
// и 'Проверено' - имя вашего дополнительного реквизита.
// Реальный способ получения может отличаться в зависимости от платформы и настроек.
// В УТ 10.3 это может быть более сложный запрос к регистру сведений.
// Для простоты примера предположим, что доп. реквизит доступен через свойство.
СтароеЗначениеПроверено = СсылкаНаОбъект.ПолучитьДополнительноеСвойство("Проверено");
// Получаем новое значение флага с формы документа
НовоеЗначениеПроверено = ДополнительныеСвойства.Проверено; // Пример получения с формы
Если СтароеЗначениеПроверено <> НовоеЗначениеПроверено Тогда // Если значение флага изменилось
// Проверяем, есть ли у текущего пользователя роль для изменения флага "Проверено"
Если НЕ РольДоступна("ПолныеПрава") И НЕ РольДоступна("ИзменениеФлагаПроверено") Тогда
Отказ = Истина;
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = "У Вас нет прав на изменение флага 'Проверено'.";
Сообщение.Поле = "ДополнительныеСвойства.Проверено"; // Указываем поле на форме
Сообщение.УстановитьДанные(ЭтотОбъект);
Сообщение.Вывести();
КонецЕсли;
КонецЕсли;
КонецЕсли;
В этом примере, мы бы создали новую роль "ИзменениеФлагаПроверено" и назначили бы её тем пользователям, которые должны иметь такое право. Отметим, что механизм получения дополнительного свойства (ПолучитьДополнительноеСвойство("Проверено")) может потребовать адаптации под конкретный способ хранения и доступа к дополнительным реквизитам в УТ 10.3, которые часто хранятся в отдельных регистрах сведений.
Для общих реквизитов ситуация аналогична: права на изменение общего реквизита определяются правами на сам объект. Однако, так как общие реквизиты создаются непосредственно в "Конфигураторе", у нас есть чуть больше возможностей для программного контроля доступа, интегрированного в код модулей объектов.
В обоих случаях, для детального контроля доступа в 1С используются стандартные механизмы ролей и профилей групп доступа. В разделе "Администрирование" -> "Настройки пользователей и прав" мы можем настроить роли и профили, которые определяют, какие действия разрешены или запрещены для различных групп пользователей. В УТ 10.3 этот функционал может быть менее развит по сравнению с более новыми версиями, поэтому для специфических требований к безопасности может потребоваться доработка конфигурации.
Особо хотим отметить ограничение доступа на уровне записей (RLS - Record Level Security). В УТ 10.3 RLS не был так развит, как в современных конфигурациях, и его использование для отдельных полей без глубоких изменений конфигурации может быть затруднительным. Если требуется ограничить доступ не только к изменению, но и к просмотру флага "Проверено" для определённых документов, это уже будет сложной задачей, требующей значительной доработки.
Подводя итог, для задачи добавления реквизита "Проверено" в документы 1С: Управление торговлей 10.3 мы настоятельно рекомендуем использовать механизм дополнительных реквизитов. Это решение обеспечивает максимальную гибкость, позволяет избежать изменений в конфигурации и значительно упрощает процесс поддержки и обновления системы.
Вопросы разграничения доступа, хотя и могут потребовать небольшой доработки конфигурации для тонкой настройки, в большинстве случаев решаются через стандартные механизмы прав пользователей 1С. Важно заранее продумать, кто и какие права будет иметь на изменение этого флага, чтобы обеспечить соответствие вашим бизнес-процессам и требованиям безопасности.
Всегда помним, что перед внесением любых изменений в рабочую базу данных рекомендуется сделать её резервную копию и протестировать изменения на тестовой копии, чтобы избежать непредвиденных проблем. При обслуживании нескольких баз для этого можно использовать автоматическое архивирование и тестирование баз 1С.