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