Нужно после отмены проведения документа программно выполнить некие действия. В обработчике "ОбработкаУдаленияПроведения" документ все еще числится проведенным, поэтому не подходит. Думаю делать в ПриЗаписи(), так как при отмене проведения, там он уже не проведен, но как там понять, что это не запись, а именно отмена проведения?

Объект.Проведен = Ложь

(1) это в ОбработкаУдаленияПроведения самому написать?

Нет, это ты спрашиваешь, как в процедуре по подписке узнать о состоянии объекта, который снят с проведения.

(1) Документ мог никогда не быть проведенным

(0) Какие "некие действия" нужно делать?

хм...

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

Если же таких ссылок найти нет возможности, т.е. некие процедуры проводились/действовали не оставляя ссылок на объект проведения... Ну что тут еще придумаешь? Ничего.

(6) Узнать режим записи не проблема:
Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
    ДополнительныеСвойства.Вставить("РежимЗаписи", РежимЗаписи);
КонецПроцедуры

Процедура ПриЗаписи(Отказ)
    ЭтоОтменаПроведения = (ДополнительныеСвойства.РежимЗаписи = РежимЗаписиДокумента.ОтменаПроведения);
КонецПроцедуры

Вопрос в том какие действия собирается делать ТС, не факт, что это можно делать при записи.

Еще интересный момент, подходит ли под задачи автора случай, когда происходит просто запись документа в режиме "Запись" и флаг "Проведен" и с флагом "Проведен" = Ложь, а по ссылке этот флаг еще Истина

(7) спасибо за идею. дело в том, что в момент проведение кое-что в кое-каком другом документе должно записываться. При отмене проведения откатываться.

(9) но таким образом, что этот документ уже должен быть не проведен

(10) короче причина почему именно так глубока и запутанная)

(9) Изменение состояния одного документа не должно вызывать изменение состояние другого явно.
Это основы архитектуры.
В данной постановке - грабли которые уже положены на землю, рано или поздно вы на них все таки наступите.

Тем более интерактивное, документ прилетает с обменом и в базе начинается каша.

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

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

(14) Это не отменяет коллизий при обмене. Весь текущий функционал завязан на интерактивные действие.

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

(15) да какие там коллизии, о чем ты? Какие там обмены?
И так все понимают, что обмен непроведенными документами не всякому разработчику в голову придет.

(16) переход на РС был ожидаем, я аналогичные вещи делал еще года 4 назад, другое дело что надо аккуратно, сдуру много что сломать можно.
Мой посыл в том, что если есть возможность по человечьи - лучше сделать.
Завязываться на интерактивный функционал и менять состояния других объектов - должно быть крайне осмысленное решение.
(17) Это случается чаще чем кажется) Если бы я не видел как наступают на эти грабли - прошел бы мимо.

А чорт это модуль объекта, а не форма, что то меня сглючило, сорри.

Тогда слова про интерактивный функционал забираю обратно)

(12) В БП 3 счет-фактура обновляется при обновлении ПТУ. В линейке ЕРП пока такое не сделали, там обошлись сердито - интерактивная заглушка с предложением ввести корректировочную СФ ))

(21) Да знаю я)
Я просто предупреждаю о том что у такого решения могут быть паоследствия.

Да в 9 из 10 случаев любое сколько-нибудь "синхронное" изменение документов - это решение, от которого потом голова болит.
А уж если учесть, что обычно внедренцы делают такие решения через *опу, то вероятность боли возрастает еще больше.

Мне на ум приходит только взаимосвязь реализации и счета-фактуры выданной. Можно там подсмотреть.

(0) В отмене проведения пиши куда то "задание на обработку" (например в РС) со ссылкой на документ.
Затем фоновое задание проверяет список заданий, смотрит документа и если он не проведен то выполняет некие действия.

Предусмотреть варианта когда документа уже снова проведен или дважды отменен и уже два (или больше) задания в списке.

(25) Угу, а еще предусмотреть вариант, когда фоновое задания по обработке документов из очереди (регистра) уже началось и приступило к очередному документу, и этот документ в этот же момент по обмену или интерактивно пользователем меняет свое состояние (проводится / разпроводится). Кстати, в ЕРП это одна из причин, когда у непроведенных документов остаются движения, сформированные фоновым заданием допроведения, бгг.

Хотя казалось бы простейшая вещь - до начала обработки очередного документа считать его версию данных и после завершения обработки этого документа еще раз версию данных считать и сравнить. Если различаются - откатить результат обработки (допроведение по регистрам) и отложить документ для повторной обработки.

Но нет, ребятки из 1С почему-то пошли по пути "дешево и сердито" ))

(26) ERP меня уже ничему не удивляет, там ситуация "у семи нянек".
Вместо того чтобы нанять мало дорогих-хороших сама 1С ищет/нанимает подешевле, ниже чем средняя на рынке, но зато много.

(29) Вроде же в самой 1с рынок\выше рынка дают

(30) Если и выше рынка, то совсем чутка. А работа там далеко не сахар.