Возникла необходимость зафиксировать дату первого проведения документа (не создания, не записи, не перепроведения).
Добавил реквизит - в него буду писать эту дату.
Встроенный механизм фиксирования даты документа как-то это видит (при первом проведении не выдает запрос "оперативно/неоперативно").
Но как я могу узнать, что Документ проводится первый раз?

2(0) ну дак очевидно же - первый, это когда твой реквизит незаполнен!

Журнал регистрации?

Движений нет   ---   Значит первый.....

(3) движений может не быть совсем, да и могли его перед этим снять с проведения.
Правильный ответ (1), причем заполнять когда режим записи=проведение и при этом ссылка пустая или ссылка.проведен=ложь и твой реквизит не заполнен

Но как система узнает, что документ проводится ПЕРВЫЙ раз?
Даже если он распроведен (движений нет) - при следующем проведении уже выдается сообщение "оперативно/неоперативно".

Но при проведении Документа В ПЕРВЫЙ РАЗ такого сообщения не выдается.

2(6) это не от того - первый он или не первый раз проводится. а от того, последний ли он на оси времен.

чем вариант из (1) не устраивает?

(8) Если документ не проведен (просто создан и, например  сохранен) то в нем должна храниться дата создания. Но при проведении она должна смениться...

чувак, давай ты еще подумаешь все условия, и заново их сформулируешь сам для себя, а потом заведешь новую ветку, а не будешь эти условия и ограничения на ходу придумывать.

детали довести наждачкой:


Процедура ПередЗаписью()
  Если РежимЗаписи = проведение и не ЗначениеЗаполнено(Ссылка.ДатаПервогоПроведения) Тогда
      //Документ пытаются провести первый раз
      ДатаПервогоПроведения = ТекущаяДата();

Не пятница? Точно?

(2) если эту дату надо в центре контролировать по документам из периферии, то журнал регистрации не поможет

ЭтоНовый() не канает?

(14) сначала жмем "Записать", а потом "Провести" и у нас будет проведенный документ с пустой датой первого проведения

(14) или у тебя может быть сначала записан и висеть несколько дней просто?

(15) Почему-же "поведенный с пустой"? дату первого проведения надо проверять и, если она пуста - записывать при первом проведении

(17) перед записью заполнил дату, в обработке проведения напоролся на проверку, пока исправлял ошибку, время прошло. В результате дата будет неправильная

короче, на любую хитрую тётьку обнаружится дядька с винтом

Если Новый - пишем дату.
При проведении проверяем - если дата пустая - пишем.

"Возникла необходимость " - а вопрос "а зачем?" задавали?.. вдруг человек огород городит))

+(20) Не, Новый - убрать.

(0) "Встроенный механизм фиксирования даты документа как-то это видит" - ничего он не видит. Если документ не проведен, и дата - сегодняшняя, он проводит оперативно без вопросов. Если проведен - задает вопрос.

(0) создай РС с датой первого проведения.
2 колонки: ссылка(документ любого типа) и дата

(18)  Сделали последнюю запись в регистр при проведении - проверяем Дату. Если пустая - поменять.. Так вот мне мнится..

(24) да не надо так усложнять конфу.. Реквизит вполне решит задачу.

ЗЫ. вроде-б и задача не сложна, а вот поди-ж ты.. :)

(23) даже если дата сегодняшняя - при перепроведении все равно спрашивает "оперативно/неопративно"

+(24) хватит одного измерения ССЫЛКА (документ любого типа)
Периодический - год
Подписку на проведение
если есть движения - лесом, нет добавляешь

(27) Не подходит. При распроведении движений нет. Но при этом дата уже зафиксирована должна быть.

На вопрос "Зачем?" ответ будет?

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

(28) в (11) уже всё написано, что еще ты ищёшь?

Глянул в УТ 10.3 - окошко оперативно/неоперативно появляется при проведении документа из формы (неважно как - Записать / ОК / Провести), только если документ уже проведен на этот момент.
Никакой связи с первым или не первым проведением не увидел.
Автор, поясни о чем ты толкуешь тут.

Ну и ИспользоватьРежимПроведения в СП и в коде погляди

А главный вопрос нах... уже отвечали? Пиши в регистр сведений текущую дату, ссылку, время проведения. Потом срез первых, последних, автора, поля ключевые...

(34) +1, (2) Программно анализировать ЖР - крайне плохое решение.

(29) Предвижу, это будет самое смешное.