Здравствуйте!
Известно, что в модуле объекта есть обработчики событий ПередЗаписью(), ПриЗаписи(), ОбработкаПроведения(). Все они выполняются внутри транзакции записи, до её завершения. Также есть одноименные подписки на события, которые выполняются после соответствующих обработчиков.
А это означает, что мы нигде, ни в обработчиках модуля объекта, ни в подписках не можем быть уверены в том, что объект успешно запишется, ведь транзакция не завершена. Вдобавок к этому есть ещё событие модуля формы ПриЗаписиНаСервере, у которого есть параметр Отказ.
Вопрос: почему так сделали разработчики? Почему в модуле объекта не существует события ПослеЗаписи()? Если это сделано намеренно, то как следует правильно получать и обрабатывать событие записи нового объекта?
Можно, конечно, использовать "кривые" пути, например, создавать фоновое задание, которое будет ждать на блокировке освобождение объекта, а потом проверять его версию, чтобы знать наверняка, успешно ли записался документ.
Но это некрасиво по сравнению с методом ПослеЗаписи(), который не предоставляется платформой.

(0) Какой смысл?
Чем "не запись" отличается от записи и удаления?

Цель обработчиков выполнить дополнительные действия
А не контроль успешности записи

Если так хочется то взводи фоновое задание ПриЗаписи() и потом да проверяй чтением объект

Или используй метод формы ПослеЗаписиНаСервере если интерактивно

(0) Лентяи.
Фоновое задание, в которое передаешь Ссылку и НовуюВерсиюДанных, а в фоновом читаешь по ссылке зафиксированную версию раз в секунду и сравниваешь с переданной. Как только станут равны - транзакция зафиксена. Паузу возьмете там же, где и ПослеЗаписи()

(3)(4) я в своём первом посте сам описал подобный приём с фоновым заданием, как вариант решения
И тут же добавил, что это криво и некрасиво по сравнению с ПослеЗаписи(), если бы он существовал

(3) если интерактивно, то вопросов нет, это очевидно.
Хотелось бы универсальное красивое решение, которое не предоставляет платформа.
Вот и вопрос, почему не предоставляет. Разве это так сложно для разработчиков? Что они имеют в виду, лишая нас такой полезной функции?

(6) Надеюсь, ты в курсе про ситуацию с реализацией функционала Пауза() в платформе, ведь да?

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

(8) Пауза нужна на сервере прежде всего

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

(6) Всё далее сказанное - "имхо" разумеется:

Все связанные между собой изменения желательно делать в пределах одной общей для всех транзакции.

Всё, что хотелось бы сделать в обработчике события "после записи"(с) - желательно делать ПриЗаписи (или при обработке проведения для документа, который проводится/перепроводится при записи).

Да, не совсем удобно согласен.

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

Вам точно нужна такая неопределенность в информационной базе? Я так не думаю.

(0) а проблема-то в чем?
может нету, потому что это нафиг никому не надо?

(0) а расширение и &После ?

(0) Напиши пару примеров зачем это тебе нужно.

(0)
ПриЗаписи() Объект уже записан.
Осталось только транзакцию завершить
На мой взгляд это и есть ПослеЗаписи.
Если эта процедура будет пустая, то и объект уже записан.

Видимо уже после записи есть желание перезаписать?
Так это не правильно.

Зачем?

Если что то после записи куда-то записать, есть опасения что битая ссылка будет,
так оно в транзакции ...

(0) >>как следует правильно получать и обрабатывать событие записи нового объекта?

Если я правильно все понял, то это больше к "ни в подписках не можем быть уверены в том, что объект успешно запишется, ведь транзакция не завершена." - ты там у себя хочешь нагенерить каких-то связанных объектов, но уверенности нет, что оно тебе точно надо? В этом корень вопроса, иначе не понятно, что ты там собрался правильно обрабатывать в модуле объекта?

Я думаю, они так сделали, потому что им так было проще. ПослеЗаписи объекта вызывалось бы после деструктора какого-то, пришлось бы делать дополнительную обвязку кода. Очень похоже, что просто поленились.

(4) В твоём-то сценарии нахрена Пауза()?

(7) Нет, расскажи

(19) Как ты без нее подождешь окончания записи в основном потоке?

(21) А в чем технологический смысл отдавать в другой поток запись объекта, чтобы обрабатывать его "ПослеЗапись" в основном?

(22)
Светило солнышко и ночью и днём
Не бывает атеистов в окопах под огнём
Добежит слепой,победит ничтожный
Такое вам и не снилось

Пояснение для тех, кто сомневается, зачем это вообще нужно.
Вот вам пример: нужно послать уведомление о том, что документ провёлся (создался). Как узнать, что документ действительно создался? Пока транзакция не завершена, это нельзя знать наверняка. А уведомление запихивать в транзакцию бессмысленно — если оно ушло, его не вернуть.

(24) Записать уведомление в РС и отправить его потом, по расписанию.
Если транзакция не завершится, то и записи в РС не будет))

(25) А если запись в РС создаст ошибку, которая в итоге отменит основную транзакцию?)

(24) создать регистр для уведомлений.
в транзакции пихать туда запись. - документ не создался(не провелся) - транзакция обломалась - запись регистра отменит.
бегать регламентным по регистру

(24) А как убедится, что после завершения успешной транзакции у вас без ошибок рассылка отработала?

(26) Если без уведомления совсем нельзя. То значит основная транзакция и должна быть отменена.
А если можно, то в попытке))

(29) Вот будет прикол, если первичка вся колом встанет, из-за того, что почтовик нагнулся))
"А если можно, то в попытке))" - а это не поможет, будет ошибка, в данной транзакции уже происходили ошибки и пошлет лесом)

(24) Я думаю, что тут никто не сомневается, что наличие такой возможности было бы неплохо.
Есть еще куча всяких возможностей, наличие которых в 1с было бы совсем неплохо, но их тоже нет.

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

(30) вот именно по этому я и сделал у себя отправку уведомлений через регистр с фоновым заданием

(32) Мы так и не поняли зачем тебе это нужно, но если для отправки, например, уведомлений по эл. почте, то я не советую, ибо (30)

(32) Для почты в типовых есть документ Электронное письмо исходящее. У него есть типовой регламент по рассылке. Всего лишь нужно создать этот документ в транзакции, дальше все само отработает. Если же запись не удалась, то и документ не создастся. Тот же пример как с РС, только типовыми инструментами.

(30) Ну ладно, тогда сдаюсь...Нужно регламентное задание стартовать.

но вообще в обработке проведения дописал вот такой код.
И у меня он выполнился. И транзакция сломанной не стала.

    попытка
        ВызватьИсключение ("Какая-то ошибка");
    Исключение
        дата=ТекущаяДата();
    КонецПопытки;
    
    запрос=новый запрос;
    запрос.Текст=  "ВЫБРАТЬ ПЕРВЫЕ 1
                   |    АвансовыйОтчет.Ссылка КАК Ссылка
                   |ИЗ
                   |    Документ.АвансовыйОтчет КАК АвансовыйОтчет";
    результат=запрос.Выполнить().Выгрузить();

(36) Запрос - это чтобы проверить. Сломанная транзакция или нет.

[мысли в слух]
В платформе есть такая служба - "Служба регистрации изменений" механизма обмена данных,- работает точно и надёжно как швейцарские часы... к чему это я? Да, так просто, чего-то вспомнилось. Кто сказал, что план обмена нельзя использовать для функционала уведомлений? Это вам не квадратные колеса придумывать для своего лисапеда :)