Как проверить, проведен ли документ, и управлять доступностью кнопок в 1С

← На главную

В процессе разработки конфигураций на платформе 1С:Предприятие 8.3 часто возникает задача ограничения действий пользователя в зависимости от состояния документа. Типичный пример: запрет выгрузки данных или печати, если документ еще не проведен. Рассмотрим подробно, как технически реализовать такую проверку, как правильно управлять элементами интерфейса и какие нюансы следует учитывать при работе с модифицированностью данных. В ряде случаев для исключения ручных операций настраивается автоматизация регулярного обмена данными между базами по расписанию.

Проверка статуса проведения в контексте команды

Первое, с чем сталкивается разработчик — это определение места, где выполняется код. В управляемом приложении команды могут быть реализованы как команды самой формы, так и как общие команды объекта. Проанализируем разницу в обращениях:

Команда формы: Если кнопка создана непосредственно в редакторе формы, доступ к данным документа осуществляется через основной реквизит формы (обычно с именем Объект). Здесь полезно изучить использование на форме одного объекта реквизитов и функциональности другого объекта. Проверка выполняется крайне просто: Объект.Проведен.
Команда объекта: Если команда вынесена в дерево метаданных документа, в обработчик передается параметр команды. В этом случае мы обращаемся к ссылке: ПараметрКоманды.Проведен.

Важно помнить, что ЭтотОбъект в контексте модуля формы не содержит свойства Проведен, так как ЭтотОбъект в данном случае — это сама форма. Именно поэтому попытка обращения ЭтотОбъект.Проведен выдаст ошибку. Правильный путь — использовать обращение к реквизиту Объект.

Управление доступностью кнопки (Enabled)

Чтобы пользователь не пытался нажать кнопку выгрузки на непроведенном документе, целесообразно сделать её неактивной (серой). Рассмотрим, как программно достучаться до кнопки. В управляемых формах не рекомендуется использовать индексы (например, Элементы[0]), так как порядок элементов может измениться. Правильно обращаться по имени элемента, заданному в конфигураторе.

Рассмотрим пример кода, который устанавливает доступность кнопки в зависимости от статуса документа:


// В процедуре на клиенте или сервере
Элементы.ИмяКнопкиВыгрузки.Доступность = Объект.Проведен;

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

При чтении на сервере: Это событие срабатывает при открытии формы. Здесь мы устанавливаем начальное состояние кнопки, задействуя еще один модификатор форм (Yet Another Form Modificator).
После записи: Это критически важный момент. Если пользователь нажал «Провести», документ сменил статус, но форма осталась открытой. Чтобы кнопка «ожила» без перезапуска формы, код изменения доступности должен быть вызван в обработчике ПослеЗаписи.

Пример реализации в модуле формы:


&НаКлиенте
Процедура ПослеЗаписи(ПараметрыЗаписи)
    // Обновляем доступность команд после проведения или записи
    УстановитьДоступностьКоманд();
КонецПроцедуры

&НаСервере
Процедура УстановитьДоступностьКоманд()
    Элементы.ФормаВыгрузитьДанные.Доступность = Объект.Проведен;
КонецПроцедуры

Дилемма модифицированности: сохранять или не сохранять?

Проанализируем ситуацию, вызвавшую жаркие споры среди экспертов: нужно ли проверять свойство ЭтаФорма.Модифицированность перед выгрузкой? Представим ситуацию: документ проведен, пользователь открыл его, изменил количество товара в строке, но не нажал «Записать». В этот момент он нажимает «Выгрузить».

Что произойдет? Если мы просто проверяем Объект.Проведен, выгрузка начнется. Но данные в файле выгрузки не будут соответствовать тому, что пользователь видит на экране, так как выгрузка обычно берет данные из базы или из актуального состояния объекта, которое еще не зафиксировано. Чтобы избежать расхождений, рекомендуется следовать стандартам типовых конфигураций (БСП):

Перед выполнением действия проверять ЭтаФорма.Модифицированность.
Если форма модифицирована, предложить пользователю сохранить изменения: «Данные были изменены. Сохранить изменения перед выгрузкой?».
Или же программно вызывать Записать() перед выполнением логики выгрузки.

Рассмотрим пример кода для команды выгрузки с учетом этой логики:


&НаКлиенте
Процедура ВыгрузитьДанные(Команда)
    
    Если Не Объект.Проведен Тогда
        Сообщить("Выгрузка возможна только для проведенных документов!");
        Возврат;
    КонецЕсли;
    
    Если Модифицированность Тогда
        // Опционально: спрашиваем пользователя или просто записываем
        ВопросТекст = "Для выгрузки актуальных данных необходимо записать документ. Записать?";
        // Здесь логика вызова вопроса и последующей записи
    КонецЕсли;
    
    // Сама процедура выгрузки
    ВыполнитьВыгрузкуНаСервере();
    
КонецПроцедуры

Нюансы работы с новыми документами

Разберем еще одну деталь: если документ совершенно новый и еще ни разу не записывался в базу данных, свойство Объект.Проведен всегда будет Ложь. Более того, у такого документа еще нет ссылки (Объект.Ссылка.Пустая() вернет Истина). При проектировании универсальных команд выгрузки всегда стоит добавлять проверку на наличие ссылки, так как выгружать «пустой» объект, не имеющий уникального идентификатора в системе, в большинстве случаев некорректно.

UX-рекомендации: неактивная кнопка или сообщение об ошибке?

Проанализируем подход к удобству пользователя. Существует две школы мысли:

Строгий запрет: Кнопка неактивна (Enabled = False). Плюс: пользователь сразу видит, что действие недоступно. Минус: пользователь может не понимать, почему оно недоступно, если только рядом нет подсказки. Для исключения подобных сложностей при выполнении рутинных операций применяется роботизация действий пользователя в интерфейсе 1С.
Информативный запрет: Кнопка активна, но при нажатии выдается четкое сообщение: «Документ должен быть проведен для выполнения этой операции». Это более дружелюбный подход, так как он обучает пользователя правильному порядку действий. Для дополнительного контроля и проверки корректности выполненных операций применяется автоматическое сравнение проводок между базами 1С.

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

Резюме

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