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

ОбработкаПроведения - это вообщето транзакция.Пока не завершится нет никаких движений в базе. Так что ты что-то путаешь.

Ну кстати да, но как то оно криво срабатывало же.

должно всё правильно показывать. внутри транзакции эти данные уже "записаны", вне транзакции они не "видны", а внутрях видны

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

(4)Сейчас еще он спросит "как записать статус дока из обработки проведения" и будет еще постов 100:-)

Старые движения стираются к моменту выполнения обработки проведения?

(6) от тебя зависит

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

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

(9) История статусов в отдельном регистре хранится.
(4) Остановился на таком варианте.