чтобы избежать вот этого момента:
Ошибка при вызове метода контекста (Записать): Ошибка при выполнении обработчика - 'ПередЗаписью': Ошибка при вызове метода контекста (Записать): Операция не может быть выполнена из-за несоответствия версии или отсутствия записи базы данных (возможно, запись была изменена или удалена)!

(0) ВерсияДанных возможно тебе поможет.
Но если это регулярно, то нужно с причинами разбираться, а не костыли пристраивать

Используй блокировки

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

(3) В (0) про другое: снеговик не даст записать объект если между чтением объекта и записью произошла его запись (в другом сеансе например). А сравнить реквизиты можно и в снеговике без проблем.

(3) а как проверишь? Два человека корректируют документ. Кто первый нажмет ОК, того и тапки.

(4): в (3) про то самое (в смысле "что"). ты зачем-то упоминаешь про "зачем" - про которое не говорилось в (3)

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

(6) Ничего не понял)

(0) в типовой же 11 торговле это реализовано, посмотри как в к примеру в заказах клиента это работает

перед записью сравнить объект и объект. ссылка

(10) Даже если все реквизиты совпадают (кроме ВерсияДанных), всё равно получишь ошибку

(7) это в семерке как раз было.

(12) В семерке при открытии формы блокировка была

(10) только сравнивать надо вроде Ссылка и Объект.Ссылка...

БудетЖопа = ( ЭтотОбъект.ВерсияДанных <> ЭтотОбъект.Ссылка.ВерсияДанных )

(15) ага

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

Серёга. с тебя пиво.

(18) Он тебе мобилку даст... Но и попросит потом )))

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

(20) проблема в кодинге?

(21) да, в кодинге программистов типовых конфигураций УНФ

на уны самые джуны сидят

(22) сам выбирал.

(23) ты про клиентов?

(25) клиенты сами не выбирают. Они всегда ведутся на то, что им втюхивают.

Клиент всегда выбирает сам,но так как он,обычно,не специалист,то ведётся на рекомендации,а каждый кулик свое болото хвалит,хоть потом в нем и потонет.

(22) может в том, что твой код противоречит типовому, но виноват типовой конечно

(28) ну хз. при массовом перепроведении документов оказалось, что ошибка возникает из-за подсистемы сообщений. т.е. при отмене проведения и последующем проведении возникают вот такие конфликты версий объектов-сообщений. Код не мой, типовой.
Но я отключил запись сообщений и понеслось норм.

(29) сказки какие-то... Нашел запись объектов в подсистеме сообщений? Если там нет записи, то причина не в этом.

(29) некогда разбираться, надо отключать!

(30) да, нашел.

(31) после отключения работает. да, разбирательства в счет не включены и не интересны.