У объектов есть событие ПриЗаписи. И выполняется оно уже в транзакции.
Для чего это делать в транзакции, какие выгоды мы получаем от этого?

(0) Когда движения документа записываются?

я опечатался
Имел ввиду перед записью

очевидно, чтобы можно было откатить все сделанные изменения. Не?

(3) а если транзакцию начать после ПередЗаписью, разве изменения не откатятся?

(4) В таком случае изменения, которые сделал в ПередЗаписью не откатятся.

(5) об изменениях какого рода ты говоришь? приведи пример кода

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

(6)Например проверояешь правильность заполнения документа и если чтото не сошлось со звездами - шлешь пользователя в сад и Отказ=Истина.

(7) если ты хочешь делать такие изменения то их нужно делать ПриЗаписи

(8) но что должно откатиться с помощью транзакции? там про это речь была
ты не написал про это

(9)А я хочу перед записью.Что мне помешает?

(6) обычно перед записью какие-то реквизиты меняем. Например СуммаДокумента всегда считается в типовых.

(9) Да ну?

(10)Все. Документ просто не будет записан. И останется в редактируемом состоянии.или просто не запишется если програмно пишешь

(12) в таком случае ты меняешь реквизиты у объекта, который находится в памяти, а не в БД
транзакция откатывает изменения в БД

(9) Смешно. это ты мощно протупил. ПриЗаписи уже всё записано, вся фишка в том, что ПриЗаписи вызывается фактически уже после записи. Непонятно, почему-то назвали ПриЗаписи.

(15)Если попростому останется то, что лежит в .Ссылка.

(15)Сам попробуй сначала, а потом будешь писать уствердительные предлоэжения

(18) а что именно пробовать? я знаю что следующий код не меняет БД:

Процедура ПередЗаписью(Отказ)
    
    Реквизит1 = 1;
    
КонецПроцедуры

(19)Ну и что? Ты в документе поменяй реквизиты, они тоже пока не записаны в БД. Если будет отказ в ПередЗаписью, то и не будут записаны. Транзакция записи откатится, .Ссылка останется такой же как до записи

(20) что именно ты предлагаешь мне попробовать сделать в (18) того что я не сделал в (19)
?

(21)Ну и в чем вопрос тогда?

воду варишь.

(23) ответь на вопрос

(24)Сформулиру его

(24) мне тоже интересно, что же он ответит )
(25) вопрос в (21)

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

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

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

+(29)Но на форме  он останется

(27) http://catalog.mista.ru/public/153748/

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

(31 зачем создавать связанные объекты ПередЗаписью если это можно сделать при записи?

(29) отказаться от записи можно и до транзакции

+(32) точнее так: зачем создавать связанные объекты если ты еще не определился, будешь ли ты записывать текущий объект

(33)Интересно, если ты объект создал программно, где ты собираешься отказываться от записи?

(34)Перед записью можно сравнить версию в базе с текущей версией. При фиксации версионирования без транзакции перед записью очень грустно было бы.

(32) например: создать новый элемент справочника и присвоить ссылку реквизиту документа, как это сделать в ПриЗаписи?

Для того, чтобы объект в памяти сохранил свою целостность.
Например, в перед записью ты изменяешь какой-то реквизит, а следующей строкой ты пишешь отказ, так вот чтобы реквизит остался в состоянии как был "перед записью".

(32) В ПриЗаписи ты меняешь реквизит только в памяти. В базу он не попадет. Так и останется в оперативной памяти.

(32) Кто говорил про связанные объекты? Связанные объекты ПередЗаписью создавать, теоретически можно, но с плясками, так как ссылки на основной в этот момент ещё нет.

Разговор (у меня) шел об изменениях реквизитов этого самого объекта.

(35) в смысле где?
Предположим есть обработчик ПередЗаписью, транзакция еще не началась, и ты там выставляешь Отказ=Истина (до транзакции). Не вижу здесь проблем. К слову, именно так сейчас работает обработчик ПередЗаписью у формы. Он находится на клиенте, транзакция там еще не началась и запись можно прервать.

(38) да, это интересное полезное поведение, но это не результат работы транзакции

(37) с этим согласен

(36) если бы в ПередЗаписью не было транзакции то, не думаю, что были бы сложности с версионированием
сравнить можно было бы ПередЗаписью, а записывать в ПриЗаписи

(44) Устройся работать в 1С в раздел разработки платформы, реализуй хотелку и уволься.

(45) хотелка? ты шутишь, старичок?!
ветку я создал чтобы разобраться

Меня больше волнует почему нет события ПослеЗаписи в модуле объекта.
По сабжу, почему так сделано я не знаю. Определенная логика в этом есть. Это среда разработки упрощенная, создана так специально для низкого входного порога студентов. Миллион событий ПередТранзакциейЗаписи, ВСамомНачалеТранзакцииЗаписи и так далее посчитали ненужным.

Если очень надо что-то ПередЗаписью сделать вне транзакции, то фоновые задания помогут. Хотя метод извращенный и по производительности ресурсоемкий, но однажды я столкнулся, что по-другому никак.
Когда результаты проверок на разрешение записи и проведения надо было записывать для дальнейшего анализа. Просто ПередЗаписью куда-то там писать нельзя, т.к. если запись не состоится, то транзакция откатится. Внешнюю базу использовать не захотелось.

(46) Я серьезно, сынуля.

(47) зачем тебе ПослеЗаписи?

(49) Выполнить синхронизацию данных текущего объекта с остальными объектами БД, которой не хочется нагружать транзакцию самой записи объекта.

(50) а если ошибка случится? как здесь без транзакции?

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

(52) да ты не переживай, что я переживаю)
у тебя дублирование операции получается, не видно в необходимости ПослеЗаписи

(53) Дублирования операций нет, есть вынос части операции вне основной транзакции записи. Нужно для того, чтобы пользователь не ждал завершения этой синхронизации.

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

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

в общем, пока вижу единственный правильный ответ в (37)

(0) Мой вариант ответа.

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

(56) вариант принимается