Собственно, проблема: сложные документы и справочники могут содержать огромное количество реквизитов, причём некоторые из них критически важны для правильной работы конфигурации и их заполнение является обязательным, а некоторые – не очень важны (или совсем не важны) и заполнять их не обязательно (хотя и желательно).

Это не всё – у разных документов или справочников одинаковые реквизиты могут относиться к разным категориям важности.

Самое простое решение – при сохранении (проведении, etc.) документа (элемента справочника) делать проверку на заполненность (или, при необходимости, на корректность значения) того или иного реквизита. Но это явно не лучший выход – придётся написать очень много рутинного кода, и гибкость у такого механизма будет нулевая (любое изменение политики придётся прописывать руками в коде).

Второй, более изящный вариант (который и используется в большинстве конфигураций) – вынести проверку реквизитов в глобальный модуль. Глобальная функция через объект "Метаданные" получает список реквизитов проверяемого объекта, перебирает их и проверяет. Флаг "реквизит не должен быть пустым" можно передавать, например, через ключевое слово, помещённое в комментарий к реквизиту (скажем, в "Астор: Торговый Дом v5" этот флаг обозначается в комментарии знаком "!").

Решение красивое, но возникают вопросы: а если необходимость проверки того или иного реквизита надо изменять непосредственно в течении работы системы, без перезаписи структуры меданных? Как быть с проверкой не только на "пусто/не пусто", но и на допустимое значение проверяемого реквизита?

Мною реализован следующий вариант решения проблемы проверок реквизитов. В конфигурации создается служебный справоник "СтруктураКонфигурации". Структура справочника произвольная, как кому удобнее, например: первый уровень "Документы/Справочники", второй уровень "конкретный объект", третий уровень "Реквизиты Шапки/Табличной части", и наконец сами реквизиты, представленные в виде элементов. У каждого элемента служебного справочника есть реквизит-флаг, определяющий необходимость проверки.

Далее, специальная обработка выполняет анализ структуры метаданных и заполняет справочник. В результате информация о всех объектах (документах и справочниках) и всех реквизитах этих объектов записывается в служебный справочник.

В глобальный модуль добавляется универсальная функция проверки реквизитов, которая получает ссылку на объект, определяет его тип, находит его описание в справочнике "СтруктураКонфигурации", перебирает реквизиты и выполняет проверку (если флаг указывает на необходимость таковой).

После этого администратору БД остаётся только открыть справочник "СтруктураКонфигурации" и проставить флаги тем реквизитам, которые необходимо проверять. Изменения в политику вносятся прямо в процессе работы с базой, буквально двумя кликами.

Я не буду детально расписывать мою реализацию описанного механизма – если общая идея понятна, реализация особого труда не составит. Более того, механизм можно доработать и внести в него какие-то дополнительные функции – условия, используемые в проверках на корректность заполнения реквизитов, и т.д.