При работе в информационных системах, таких как 1С:Управление нашей фирмой (УНФ), часто возникает необходимость строго контролировать действия пользователей, особенно когда речь идет о финансовых или управленческих документах. Одной из распространенных задач является запрет печати документов, которые еще не были проведены. Это логичное требование, поскольку непроведенный документ может содержать предварительную или некорректную информацию, и его печать может привести к ошибкам в учете или в работе с клиентами и поставщиками.
Рассмотрим ситуацию, когда возникает потребность ограничить печать непроведенных документов для определенных групп пользователей. Например, менеджеры по продажам могут создавать заказы, но распечатывать их должны только после подтверждения и проведения. В других конфигурациях 1С для таких целей обычно предусмотрены специальные роли или настройки прав доступа. Однако, как показывает практика и обсуждение на форумах, в 1С:УНФ этот вопрос оказывается не таким прямолинейным.
Приступая к решению задачи по запрету печати непроведенных документов, мы, как правило, начинаем с поиска стандартных механизмов конфигурации. В нашем случае, пользователь попытался найти предопределенную роль, которая могла бы управлять данным функционалом. Искали по ключевым словам, таким как "ПечатьНепров", и обнаружили упоминание роли ПечатьНепроведенныхДокументов в комментариях к коду или описаниях, что вселяло надежду на штатное решение. Однако, при детальной проверке конфигурации оказалось, что такой роли попросту не существует. Это указывает на отсутствие встроенного механизма, который бы позволял гибко управлять данным разрешением на уровне ролей и прав доступа для каждого пользователя.
Это наблюдение подтверждается и официальной позицией разработчика. Как было выяснено в ходе общения со службой поддержки 1С, на данный момент в конфигурации 1С:УНФ не предусмотрен штатный функционал для установки запрета на печать непроведенных документов, и его внедрение пока не планируется. Этот факт означает, что для реализации такой возможности нам придется прибегать к программным доработкам или использованию расширений.
Несмотря на отсутствие штатной роли, существует программный способ, который позволяет активировать проверку проведения документа перед его печатью. Этот метод, предложенный участниками обсуждения, является достаточно эффективным для реализации глобального запрета на печать непроведенных документов для всех пользователей.
Давайте разберем этот подход подробнее. Механизм печати в 1С:Предприятии, особенно на управляемых формах, часто использует так называемые "команды печати", которые формируются в модулях менеджеров документов. Наша задача будет заключаться в изменении свойства одной из таких команд.
ПроверкаПроведенияПередПечатьюНам необходимо открыть конфигуратор и найти соответствующий модуль менеджера для того типа документа, печать которого мы хотим ограничить (например, "Заказ покупателя", "Расходная накладная" и т.д.). В этом модуле мы будем искать процедуру или функцию, которая отвечает за добавление команд печати. Обычно такая процедура называется ДобавитьКомандыПечати.
Внутри этой процедуры, как правило, формируется список команд печати для различных макетов или комплектов документов. Каждая команда печати представляет собой объект, которому присваиваются различные свойства. Одно из ключевых свойств, которое нас интересует, это ПроверкаПроведенияПередПечатью.
Рассмотрим пример программного кода, который демонстрирует, как это свойство устанавливается:
// Пример кода из модуля менеджера документа
Процедура ДобавитьКомандыПечати(КомандыПечати) Экспорт
// ... Другие команды печати ...
КомандаПечати = КомандыПечати.Добавить();
КомандаПечати.Идентификатор = "МояПечатнаяФорма"; // Уникальный идентификатор команды
КомандаПечати.Представление = НСтр("ru = 'Моя печатная форма'"); // Представление для пользователя
КомандаПечати.ПроверкаПроведенияПередПечатью = Истина; // Ключевое изменение!
КомандаПечати.ДополнитьКомплектВнешнимиПечатнымиФормами = Истина;
КомандаПечати.Порядок = 1;
// ... Другие команды печати ...
КонецПроцедуры
В этом примере мы видим, что для объекта КомандаПечати устанавливается свойство ПроверкаПроведенияПередПечатью в значение Истина. Именно это изменение заставляет систему проверять, проведен ли документ, прежде чем разрешить его печать. Если документ не проведен, пользователю будет выдано соответствующее сообщение, и печать будет заблокирована.
Важно отметить, что данное изменение является глобальным. То есть, после его внесения, проверка проведения будет выполняться для данной печатной формы для *всех* пользователей. Если нам требуется более гибкое управление с разграничением по пользователям или группам доступа, этот подход требует дополнительных программных доработок, включающих проверку прав текущего пользователя.
Данный метод требует изменения типовой конфигурации, что не всегда желательно, так как усложняет процесс обновления. Тем не менее, это прямой и эффективный способ для установления общесистемного запрета.
Поскольку 1С:УНФ не предоставляет готового функционала для запрета печати непроведенных документов на уровне прав доступа, для реализации избирательного запрета нам потребуется более сложная программная доработка. Это можно осуществить несколькими способами, избегая при этом прямого изменения типовой конфигурации, используя механизмы расширений или модифицируя модули документов с учетом текущих прав пользователя.
Расширения конфигурации – это предпочтительный способ внесения изменений в типовые конфигурации 1С:Предприятия. Они позволяют добавлять, изменять или переопределять объекты и функциональность без снятия конфигурации с поддержки, что значительно упрощает обновление системы. Для нашей задачи мы можем создать расширение, которое будет содержать следующую логику:
ЗапретПечатиНепроведенныхДокументов. Эта роль сама по себе не будет предоставлять никаких прав, но будет служить маркером.ДобавитьКомандыПечати: В расширении мы переопределим процедуру ДобавитьКомандыПечати из модуля менеджера интересующего нас документа.ЗапретПечатиНепроведенныхДокументов.КомандаПечати.ПроверкаПроведенияПередПечатью = Истина;. В противном случае, оставим его значение Ложь (или как было изначально).
Примерная логика в расширении могла бы выглядеть так:
// В расширении, в модуле менеджера документа "ЗаказПокупателя"
// Переопределенная процедура ДобавитьКомандыПечати
Процедура ДобавитьКомандыПечати(КомандыПечати) Экспорт
// Вызываем оригинальную процедуру, чтобы получить стандартные команды печати
// Если расширение полностью переопределяет, то может быть и без вызова
// Мы можем добавить свою логику до или после вызова оригинальной
// ... Логика получения команды печати, например, для "Заказа покупателя" ...
Для Каждого КомандаПечати Из КомандыПечати Цикл
Если КомандаПечати.Идентификатор = "ЗаказПокупателя" Тогда // Или другой идентификатор нужной формы
// Проверяем, есть ли у текущего пользователя наша ограничивающая роль
Если РольДоступна("ЗапретПечатиНепроведенныхДокументов") Тогда
КомандаПечати.ПроверкаПроведенияПередПечатью = Истина;
Иначе
// Если роли нет, разрешаем печать непроведенных (или оставляем как было по умолчанию)
КомандаПечати.ПроверкаПроведенияПередПечатью = Ложь;
КонецЕсли;
Прервать; // Если нашли нужную команду, можно выйти из цикла
КонецЕсли;
КонецЦикла;
КонецПроцедуры
// Функция для проверки доступности роли (пример)
Функция РольДоступна(ИмяРоли)
Возврат Пользователи.ТекущийПользователь().ДоступныеРоли.Содержит(Метаданные.Роли[ИмяРоли]);
КонецФункции
Использование расширений является наиболее гибким и безопасным методом, так как оно не модифицирует основную конфигурацию и легко отключается при необходимости. Это позволяет управлять ограничениями через стандартные механизмы назначения ролей пользователям.
Если мы хотим реализовать запрет не для всех печатных форм документа, а только для конкретных, или если подход с переопределением через расширения кажется слишком сложным, мы можем внести изменения непосредственно в код конкретной печатной формы или в модуль объекта документа, где происходит вызов печати.
Этот подход менее универсален и требует более точечных изменений:
ПечатьМенеджер.НапечататьДокументы(...)) мы можем добавить проверку проведения документа и прав пользователя.Примерная логика:
// Пример в модуле объекта документа или в модуле команды печати
Процедура Печать(ИдентификаторКоманды)
// Проверяем, проведен ли документ
Если Не ЭтотОбъект.Проведен Тогда
// Проверяем, имеет ли текущий пользователь право печатать непроведенные документы
// Для этого нужна своя функция проверки прав
Если Не ДоступноПечататьНепроведенные(ИдентификаторКоманды) Тогда
ПоказатьПредупреждение(, "Печать непроведенного документа запрещена.");
Возврат;
КонецЕсли;
КонецЕсли;
// Продолжаем обычную логику печати
// ...
КонецПроцедуры
// Пример функции проверки прав (потребует создания новой роли и настройки прав)
Функция ДоступноПечататьНепроведенные(ИдентификаторКоманды)
// Здесь можно реализовать сложную логику проверки ролей,
// или использовать регистры сведений для хранения настроек прав пользователей.
// Например, если существует роль "РазрешитьПечатьНепроведенных"
Возврат РольДоступна("РазрешитьПечатьНепроведенных");
КонецФункции
Этот метод дает нам полный контроль над логикой, но требует тщательного анализа, чтобы не нарушить стандартную работу конфигурации. Важно помнить, что любые изменения в типовой конфигурации влекут за собой риски при обновлении и требуют особого внимания.
Для организаций с высокими требованиями к безопасности и разграничению прав доступа существуют сторонние разработки или более сложные системы управления правами, которые могут быть интегрированы с 1С:УНФ. Эти решения часто предоставляют широкий спектр возможностей, включая:
Такие решения могут быть весьма мощными, но их внедрение обычно требует значительных ресурсов и квалифицированных специалистов. Они могут предоставить более унифицированный подход к управлению безопасностью, выходящий за рамки только запрета печати. При необходимости скрыть или заблокировать кнопки печати для конкретных пользователей подойдёт расширение для управления видимостью и доступностью элементов формы.
При реализации любого из предложенных методов, мы должны учитывать несколько важных моментов:
Таким образом, хотя 1С:УНФ не предлагает готового "флажка" для запрета печати непроведенных документов на уровне прав доступа, мы имеем в своем распоряжении мощные инструменты платформы 1С:Предприятие, позволяющие реализовать этот функционал через программные доработки. Выбор конкретного метода зависит от требований к гибкости, сложности конфигурации и готовности к поддержке внесенных изменений. Для защиты проведенных и распечатанных данных от последующей отмены проведения подойдёт расширение для блокировки изменений выбранных документов.