Как программно убрать проверку заполнения поля Аналитика расходов по условию из документа-основания

← На главную

В процессе разработки в среде 1С:Предприятие 8.3 (особенно в конфигурациях ERP 2, Комплексная автоматизация или Управление торговлей 11) часто возникает необходимость сделать стандартные проверки более гибкими. Типовые механизмы контроля заполнения реквизитов иногда вступают в противоречие с реальными бизнес-процессами компании. Рассмотрим ситуацию, когда в документе Заказ поставщику необходимо отменить обязательное заполнение поля Аналитика расходов, но только в том случае, если документ создан на основании специфического Заказа в снабжение с определенными параметрами.

Анализируем исходную задачу

Представим ситуацию: пользователь создает Заказ поставщику (ЗП) на основании Заказа в снабжении (ЗС). В типовом функционале поле Аналитика расходов может быть обязательным для заполнения, если выбрана соответствующая статья расходов. Однако, если вид операции в исходном заказе — Закупка МТС или Заказ образцов, а причиной списания указаны Образцы НИОКР, проверка становится избыточной и мешает работе. Наша задача — проанализировать данные документа-основания и, если условия соблюдены, "заглушить" стандартную проверку.

Шаг 1. Получение данных из документа-основания

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

Создадим в модуле объекта (или в общем модуле, если это предусмотрено архитектурой) функцию СТ_ПроверкаОперацииСписания:


Функция СТ_ПроверкаОперацииСписания(Знач ЗаказВСнабжение) Экспорт
    
    // Если основание не заполнено, возвращаем Ложь
    Если ЗаказВСнабжение.Пустая() Тогда
        Возврат Ложь;
    КонецЕсли;

    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |   Заказ.ВидОперации КАК ВидОперации,
        |   Заказ.ПричинаСписания КАК ПричинаСписания
        |ИЗ
        |   Документ.СТ_ЗаказВСнабжение КАК Заказ
        |ГДЕ
        |   Заказ.Ссылка = &ЗаказВСнабжение";

    Запрос.УстановитьПараметр("ЗаказВСнабжение", ЗаказВСнабжение);
    
    РезультатЗапроса = Запрос.Выполнить();
    Выборка = РезультатЗапроса.Выбрать();

    Если Выборка.Следующий() Тогда
        // Проверяем условия по Виду операции и Причине списания
        УсловиеПоВиду = (Выборка.ВидОперации = Перечисления.СТ_ВидыОперацийЗаказовВСнабжение.ЗакупкаМТС 
                        ИЛИ Выборка.ВидОперации = Перечисления.СТ_ВидыОперацийЗаказовВСнабжение.ЗакупкаОбразцов);
        
        // Важно: Поиск по наименованию или коду — не лучший вариант, 
        // но в рамках примера используем получение ссылки через вспомогательную функцию
        ПричинаНИОКР = ОбщегоНазначения.СТ_ПолучитьПричинаСписания("Образцы (НИОКР)");
        
        Если УсловиеПоВиду И Выборка.ПричинаСписания = ПричинаНИОКР Тогда
            Возврат Истина; // Условие выполнено, проверку можно отключать
        КонецЕсли;
    КонецЕсли;

    Возврат Ложь;
КонецФункции

Шаг 2. Интеграция в ОбработкуПроверкиЗаполнения

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

В типовых конфигурациях проверка аналитик часто выносится в отдельные процедуры, например, ПланыВидовХарактеристик.СтатьиРасходов.ПроверитьЗаполнениеАналитик. Нам нужно обернуть вызов этой процедуры в наше условие.


Процедура ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)
    
    // Вызываем стандартную логику (или расширяем её)
    // ... здесь может быть другой код ...

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

КонецПроцедуры

Шаг 3. Оптимизация через ДополнительныеСвойства

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

В процедуре ОбработкаЗаполнения (когда документ создается на основании), мы можем добавить признак в ДополнительныеСвойства объекта:


Процедура ОбработкаЗаполнения(ДанныеЗаполнения, ТекстЗаполнения, СтандартнаяОбработка)
    // Код заполнения документа на основании
    // ...
    
    Если ТипЗнч(ДанныеЗаполнения) = Тип("ДокументСсылка.СТ_ЗаказВСнабжение") Тогда
        // Проверяем условия сразу при создании
        Если СТ_ПроверкаОперацииСписания(ДанныеЗаполнения) Тогда
            ЭтотОбъект.ДополнительныеСвойства.Вставить("ПропускатьПроверкуАналитикиНИОКР", Истина);
        КонецЕсли;
    КонецЕсли;
КонецПроцедуры

Тогда в ОбработкаПроверкиЗаполнения код станет значительно проще и быстрее, так как данные уже будут в памяти объекта 1С:


ПропускатьПроверку = Ложь;
ЭтотОбъект.ДополнительныеСвойства.Свойство("ПропускатьПроверкуАналитикиНИОКР", ПропускатьПроверку);

Если НЕ ПропускатьПроверку Тогда
    // Стандартная проверка
КонецЕсли;

Важные замечания и риски

Проанализируем последствия отключения проверки. Нужно понимать, что Аналитика расходов в ERP-системах — это не просто "текстовое поле". Оно напрямую влияет на:

Закрытие месяца: Если аналитика не заполнена, система может не знать, на какой объект (например, на какой склад или заказ) распределить затраты. Это может привести к ошибкам при расчете себестоимости.
Регистры накопления: Данные попадают в регистр Прочие расходы. Пустая аналитика сделает отчеты по расходам менее детализированными.
Человеческий фактор: Убедитесь, что статья расходов, используемая в этих документах, действительно допускает отсутствие аналитики в долгосрочной перспективе.

Выясним причину, почему пользователи просят об этом. Если это разовые случаи, программное решение идеально. Если же это массовое явление для определенных типов затрат, возможно, правильнее будет создать в справочнике Статьи расходов отдельную статью, у которой в настройках указано, что аналитика не обязательна. Это позволит решить задачу без вмешательства в программный код 1С, сохранив конфигурацию на поддержке.

Подведем итог: мы разобрали, как с помощью функции-помощника и модификации обработчика ОбработкаПроверкиЗаполнения реализовать гибкую логику контроля данных в ТЧ. Используйте метод с ДополнительныеСвойства для повышения производительности и всегда проверяйте влияние таких изменений на финансовый результат при закрытии периода.