Есть 2 варианта выполнения:
1) Событие ПередЗаписью. В коде делать проверку на проведение
Если РежимЗаписи = РежимЗаписиДокумента.Проведение тогда
...
КонецЕсли

2) Событие ОбработкаПроведения. Пишем в нем без всяких условий.

Какой вариант более верный? Где какие + и -. У варината 1) есть минус, что надо для сохранения документа нажимать кнопку "Записать", зато как понимаю выполняется вне транзакции, надо принудительно в коде для сохранения записывать документ. Вариант 2) более привычный

что за проверки проведения ?

(0) 1 вариант

...более вернее выполнять проверки проведения документов...

Пестня!

не догнал что же автор хочет...

имхо гамнокодом попахивает...

(0) По уму в проведении вообще никаких проверок быть не должно. Защиту от дурака в форме делать надо. Максимум контроль остатков, но и тут уже после проведения выполняют.

проверка проведения в модуле проведения, какая запись - автор, ты о чем?

(6) это не верно
(7) в типовых сделано в ОбработкаПроведения

(1) например нельзя проводить документы с суммой меньше 500 руб
(5) почему
(6) вот это точно гупость. Если проведение будет выполняться регламентным заданием, то ни одна из проверок не выполниться.
Согласно стандартам разработки от 1C должен записываться любой документ с любыми данными т.к он является "черновиком", а вот проводиться только корректный документ.
(7) Пользователь забил документ. Нажимает кнопку ОК. Условие проверки не проходит (т.е Отказ = истина). При 1) документ не будет вообще записан и не будет проведен, при 2) документ будет записан, но непровен. При 1) чтобы сохранить надо будет нажать "Записать"

(4) Хочу научиться писать код правильно и верно.

(0) Как это "Записать" вне транзакции?

И в каком месте ПередЗаписью планируете? В модуле формы или модуле документа?

(8) Спорить на стану.
(9) А зачем что-то проверять в уже записанном документе? Или его программно с ошибкой создали

(9) имхо - документ должен быть записан в любом случае(если иное не обусловлено необходимостью)
а вот провестись - тут уже проверять

(9) Пример пользователь не знает как заполнить реквизит. Сохранила документ и побежала к другой тетеньке, чтобы спросить у нее. На компе 2-й тетеньки открывают сохраненный документ и смотрят его. Или забивали документ на 100 позиций, но из-за ошибки прав нет его провести. Сохранили и могут спать спокойно. С 1С полностью согласен, что непроведенный документ это черновик и в учете он не должен фигуровать (а учет идет по регистрам)
(10) в модуле объекта. Считаю, что проверки на форме вообще нельзя делать т.к будет различаться функционал системы при работе на клиенте и на сервере

думал хоть постов 50 будет

вариант 2 конечно. чего думать непонятно вобще

(15) аргументы?

Такие вопросы:
1) в событии "перед записью" уже начинается транзакция или нет?

2) Ошибка или нет, если в событии ПередЗаписью, будет код

НачатьТранзакцию();
// отменяем проведение других документов
ЗафиксироватьТранзакцию();

3) В событии при записи, можно записывать в значения в РС ЗначенияСвойствОбъектов? Блокируется ли он при таком коде:

   СсылкаНастройки = ПланыВидовХарактеристик.СвойстваОбъектов[аСвойство];
   МенеджерЗаписи = РегистрыСведений.ЗначенияСвойствОбъектов.СоздатьМенеджерЗаписи();
   МенеджерЗаписи.Объект = аОбъект;
   МенеджерЗаписи.Свойство = СсылкаНастройки;
   МенеджерЗаписи.Значение = аЗначение;
   МенеджерЗаписи.Записать(Истина);

(16)
1. есть транзакция записи/проведения (При проведении транзакция одна, стартует в ПриЗаписи). "В перед записью" транзакции нет по сути, и не нужна.
2. Это в "ПриЗаписи" делается обычно. Зачем в Перед? А если в ПриЗаписи будет Отказ - то доки те распроведённые не вернутся в предыдущее положение.
3. В обработке проведения делай, зачем тут?

(17) + стоп, вру.
В "перед записью" транзакция записи уже активна, но это событие вызывается до непосредственной записи объекта, т.е. по ссылке - старый объект

а вот напрмер в УФ процедура ПередЗаписьюНаСервере идёт вне транзакции

(17) "В перед записью" транзакции нет по сути, и не нужна. Есть если это в объекте!

(20) > (18). я уже исправил свой косяк)

(0) Думаю правильнее проверять что либо в транзакции, в самом её начале. т.е. перед записью т.к. транзакция имеет изоляцию и  правильнее ее прервать в самом начале.

(22) чтобы проверить - надо собрать данные записываемого объекта. Как сделаешь это в ПередЗаписью? если объекта нет в базе в рамках транзакции, запросом не собрать

(23) в "Объект" все данные и есть, засунуть в запрос проблем нет.

(17) надо сохранять значения свойств объектов. Мне это не нравить, но так надо сделать. Вот сейчас думаю как сделать, так чтобы не было ошибок по транзакциям и блокировкам при чтении и записи в РС ЗначенияСвойствОбъектов

(24) каким образом? из ТЧ формировать ТЗ, пихать в запрос и т.д.? просто реквизиты как пихать в запрос будешь? Всё это настолько геморой, что и говорить не хочется. Даннче тянем из записанного внутри транзакции объекта

(25) записывать свойства документа? Определиться, какие свойства документа имеют отношение к проведению документа, а какие нет - соответствено, записывать их в обработчике проведения или просто при записи

(0) Все зависит от ситуации: если не важен результат проведения, то перед записью; а если нужно учесть результат проведения, тогда в обработке проведения.

(27) в форме тогда, что ли запись выполнять?

(29) Зачем? В обработчике можно просто проверить на открытую форму документа.

(29) сделать как в типовых не предлагать чтоли?
Или передай с формы набор записей регистра не записанный в объект, в обработку проведения, де факто запись сделаешь только когда будет проведён объект

(29) а как в типовых? Там все интерактивно через специальную форму, а у меня, для удобства пользователя, вынесено на форму отдельным полем.

(32) в типовых пишется с формы прямо в регистр, если тебе надо только вместе с объектом записывать - передавай туда незаписанный набор

(0) Проверку делаем в процедуре
ОбработкаПроведения(Отказ, Режим)