Здравствуйте! У меня учебная задача, делаю свою легонькую конфигурацию.
Есть документ и в нем ТЧ. См. изображение.
Реквизит "Цена одного изделия" получаю на сервере по ссылке из другого дока при событии на изменение реквизита "Ссылка на изделие". Вопрос такой:каким событием я смогу отследить изменение нужного мне реквизита в другом доке? То есть если я там эту цену поменяю, в моем доке она останется неизменной.
[url=https://radikal.ru][img]https://b.radikal.ru/b26/1905/50/a650a13ec22a.png[/img][/url]

(0) Тебе это не нужно.
Чисто теоретически это возможно через костыли.
Разрабатывать архитектуру надо так, что бы интерактивная работа не зависела от изменения состояния сущностей в других сеансах.

Методически верно финальную цену расчитывать уже в транзакции.
Да при вводе цена подставляется, но в Перед записью уже в транзакции получаются сиеминутные значения.
Если они не совпадают с документом - отказ и вывод пользователю сообщения.

(2) как тогда правильнее цену получать?

Как в типовых.
при изменении номенклатуры запрос в РС цены номенклатуры неконтекстным серверным вызовом

А ПередЗаписью делаешь проверку что цены в ТЧ соовпадают с ценами в РС цены номенклатуры.
Чисто теоретически - документ может вводиться продолжительное время и цены в ТЧ в момент проведения будут неактуалоьны

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

(2) "Перед записью уже в транзакции получаются сиеминутные значения." это ужасно, провестись должно с данными которые видно на форме, а афтору надо кнопку обновить

(7) Не согласен.
Формально документ может вводиться много часов и это приведет к коллизиям. Что в документе, проведенном в 18, цены, которые уже не актуальны были в 12.
Проверка в транзакции должна быть, что введенные данные соответствуют учетным с удобным диагностическим сообщением.
Кнопка - как изюминнка, ее можно сделать, но проверка должна быть.

На сколько я помню - в типовых такая проверка есть

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

котрпримеры есть, но они совсем не очевидны, например прилетели бонусы и скидку надо пересчитать, или 23 и корзинку надо облегчить

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

Были даже акции длинной в пару часов за счет вендора.
Так что не все так однозначно