Контроль сроков поставки товаров — одна из ключевых задач управления закупками и складскими запасами. Нередко возникает ситуация, когда менеджеры по закупкам переносят дату поступления товаров задним числом, чтобы скрыть срыв сроков или сгладить статистику работы с поставщиками. Разберем, как решить задачу ограничения редактирования даты доставки в программе 1С:Управление торговлей 11, какие ограничения накладывает типовой функционал платформы и как правильно реализовать контроль через доработку конфигурации без снятия с поддержки.
Выясним причину, почему настроить выборочный запрет штатными профилями групп доступа невозможно. В платформе 1С:Предприятие отсутствует разграничение прав доступа на уровне отдельных реквизитов документа (Field-Level Security). Роли пользователей определяют права на весь объект целиком: чтение, добавление, изменение или удаление документа. Если менеджеру предоставлено право редактировать заказ поставщику, он имеет доступ ко всем доступным для ввода полям этого документа.
Типовой механизм БСП Даты запрета изменения в данном сценарии также не поможет: он контролирует дату самого документа либо дату совершения хозяйственной операции в прошлых закрытых периодах, но не отслеживает плановые даты поступления в будущих периодах и строки табличной части.
Кроме того, проанализируем структуру хранения даты: в зависимости от используемой опции («Поступление одной датой» или несколькими датами) срок доставки может храниться либо в реквизите шапки (ДатаПоступления), либо построчно в табличной части Товары. Это означает, что любой механизм ограничения должен учитывать оба сценария.
Рассмотрим подход без программирования, основанный на административном контроле и фиксации фактов изменений. Если цель состоит в том, чтобы видеть реальную историю смещения сроков и дисциплинировать сотрудников, настроим версионирование объектов:
Теперь при любом изменении даты доставки и повторном проведении документа система сохраняет снимок объекта. В форме документа по кнопке История изменений ответственный руководитель или аудитор сможет увидеть точное время правки, автора изменений и предыдущее значение реквизита. Это позволяет применять организационные меры воздействия к нарушителям регламента.
Разберем способ блокировки редактирования даты на уровне пользовательского интерфейса, доступный администратору системы без изменения конфигурации:
Дата поступления в таблице Товары.Обратите внимание на ограничения этого способа: если у пользователя есть право на изменение формы, он сможет сбросить настройки к стандартным. Кроме того, поле станет недоступным и в момент первичного ввода нового документа, если дата не заполняется автоматически по умолчанию.
Посмотрим на сценарий, в котором задействован штатный бизнес-процесс согласования закупок:
Не согласован до статуса К поступлению.Если требуется жесткий запрет с проверкой прав конкретных пользователей, разберем разработку расширения конфигурации. Это надежный метод, гарантирующий защиту данных как в интерфейсе, так и при программной записи документа.
Для визуального отключения поля перехватим событие формы документа ПриЧтенииНаСервере в модуле формы расширения:
&После("ПриЧтенииНаСервере")
Процедура Расш1_ПриЧтенииНаСервере(ТекущийОбъект)
// Проверяем, не является ли документ новым
Если Не ТекущийОбъект.ЭтоНовый() Тогда
// Проверяем наличие специальной роли у пользователя
Если Не РольДоступна("Расш1_ПравоИзмененияДатыДоставки") Тогда
// Блокируем дату в шапке
Если Элементы.Найти("ДатаПоступления") <> Неопределено Тогда
Элементы.ДатаПоступления.ТолькоПросмотр = Истина;
КонецЕсли;
// Блокируем колонку даты в табличной части
Если Элементы.Найти("ТоварыДатаПоступления") <> Неопределено Тогда
Элементы.ТоварыДатаПоступления.ТолькоПросмотр = Истина;
КонецЕсли;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Однако одной блокировки элементов формы недостаточно: дату могут изменить с помощью групповой обработки реквизитов или внешних обработок. Защитим данные на уровне модуля объекта документа через обработчик ПередЗаписью:
&Перед("ПередЗаписью")
Процедура Расш1_ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
// Контролируем только существующие в базе документы
Если ЭтотОбъект.ЭтоНовый() Тогда
Возврат;
КонецЕсли;
// Если у пользователя есть специальная роль, пропускаем проверку
Если РольДоступна("Расш1_ПравоИзмененияДатыДоставки") Тогда
Возврат;
КонецЕсли;
// Считываем первоначальные данные из базы через Ссылку
СтараяДатаШапки = ЭтотОбъект.Ссылка.ДатаПоступления;
Если ЭтотОбъект.ДатаПоступления <> СтараяДатаШапки Тогда
Отказ = Истина;
ОбщегоНазначенияКлиентСервер.СообщитьПользователю(
"Изменение даты доставки в шапке документа запрещено правилами системы!",
ЭтотОбъект.Ссылка,
"ДатаПоступления");
Возврат;
КонецЕсли;
// Проверяем изменение дат в табличной части Товары
ТаблицаБазы = ЭтотОбъект.Ссылка.Товары.Выгрузить();
Для Каждого СтрТЧ Из ЭтотОбъект.Товары Цикл
НайденныеСтроки = ТаблицаБазы.НайтиСтроки(Новый Структура("НомерСтроки", СтрТЧ.НомерСтроки));
Если НайденныеСтроки.Количество() > 0 Тогда
Если СтрТЧ.ДатаПоступления <> НайденныеСтроки[0].ДатаПоступления Тогда
Отказ = Истина;
ОбщегоНазначенияКлиентСервер.СообщитьПользователю(
СтрШаблон("Запрещено изменять дату доставки в строке №%1!", СтрТЧ.НомерСтроки),
ЭтотОбъект.Ссылка,
"Товары");
Прервать;
КонецЕсли;
КонецЕсли;
КонецЦикла;
КонецПроцедуры
Рассмотрим ситуацию с точки зрения реальных бизнес-процессов. Дата доставки поставщиком нередко смещается по объективным внешним причинам: транспортные задержки, отсутствие товара на складе поставщика. Если заблокировать дату поступления полностью, менеджеры не смогут поддерживать корректный график движения товаров, что нарушит работу подсистемы обеспечения потребностей предприятия.
Практичным выходом из этой ситуации является разделение понятий «плановая дата» и «оперативная дата»:
ДатаПоступления оставим открытым для корректировки, чтобы закупки отражали актуальное положение дел.