Доброго времени суток!
Такая проблема:Запрет создания новых элементов справочника не подходящих под определенные критерии.
Элементы справочника могут создаваться как программно так и интерактивно.
Где прописать в ОДНОМ месте (как для программного так и интерактивного создания элементов справочника) код, который бы не давал создаваться либо записываться элементам справочника не подходящим под критерии?

В подписке на "ПриЗаписи"

Потому что в "ПередЗаписью" после твоей подписки с проверкой могут в будущем насоздавать еще подписок, которые будут выполняться уже после твоей проверки.

Ну а для интерактивного запрета, чтоб было все по чертежу - вызов той же самой проверки в обработке проверки заполнения

(3) Двойная проверка при интерактивном?

(3) Можно, но зачем, все равно в призаписи попадешь.

(4) Не двойная - отлуп же взведется

(5) А оттуда можно вывести сообщения, чтоб они к интерактивчику подвязались (к полям формы)?

В подписке ПередЗаписью объекта.

Потому что в ПриЗаписи вызывается уже после фактической записи объекта в базу данных. Зачем делать лишние манипуляции (запись с последующим откатом транзакции), если планируем отказаться от записи? Мне лично это непонятно.

Аргумент из (2) - какая-то мутная история непонятно о чем. Как будто в ПриЗаписи никто другой никаких других проверок запилить не сможет. С этой точки зрения (наличия чьих-то дополнительных добавленных обработчиков) разницы между ПередЗаписью и ПриЗаписи нет никакой.

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

В интерактиве лучше сразу подсветить незаполненные, неправильно заполненные данные

Товарищу из (8) могу только предложить перечитывать (2) до наступления просветления :) Не каждому дано создавать надежные решения, это да. Ну и защитная реакция на устоявшуюся привычку срабатывает, вероятно

(7) можно.

Но с точки зрения технологичности, вариант с вызовом процедуры ОМ на форме и в призаписи, да лучше, не будут устанавливаться лишние блокировки транзакции, там где они не нужны

По хорошему делается так 2 модуля ПроверкаГраблиКлиент (для процедуры проверки в форме еще до попытки записи ) ПроверкаГраблиСервер (для подписки при записи, и главной процедуры проверки граблей) Проверку делает общая функция ПроверитьГрабли(СтруктураПараметров) в ПроверкаГраблиСервер

(2) аналогично в будущем могут насоздавать подписки "ПриЗаписи". Преимуществ это не дает.

(14)В ПриЗаписи не напихают изменений реквизитов. А в ПередЗаписью могут. И если подписка ПередЗаписью с новыми реквизитами отработает после подписки с проверками, может случиться конфуз.

(7) Используй СообщениеПользователю. В синтаксис-помощнике прописан удачный пример использования.

(15) да, логично.
Но в типовых проверки в основном идут в ПередЗаписью (и в ОбработкаПроверкиЗаполнения конечно же)

в призаписи уже будет отмена транзакции, а в перед записью до транзакции не дойдет

(14) Не тупи, как (8): надежно (а Я вкладываю в это слово смысл "со 100% гарантией") реализовать отлуп вида "Ты не пройдешь" в ПередЗаписью нельзя, т.к. после проверки и _одобрения_ объект может быть еще изменен, а в ПриЗаписи - не может, так что насчет "преимуществ не дает" и "разницы нет" это ты погорячился.
Даже если кто-то решит написать *овнокод с получением и изменением объекта по ссылке в ПриЗаписи (после нашей проверки и одобрения), измененный объект все равно второй раз в ПриЗаписи прилетит и уже получит отлуп.
Плата за такую надежность (со 100% гарантией) - это потенциально ненужная запись объекта в БД, с этим не спорю.

(17) "в типовых проверки в основном идут в ПередЗаписью" // Это мина замедленного действия. Кто-то еще называет это "граблями", на которые наступить потом можно. Другое дело, что для принятия решения нужно знать соотношение затратности проверки и требуемой степени надежности.

(0) Если справочник твой, то в модуле объекта, ПередЗаписью.

Если правишь типовую, то подписка.