Имя: Пароль:
1C
1С v8
Событие на изменение реквизита
, ,
0 Awalon
 
27.05.19
22:14
Здравствуйте! У меня учебная задача, делаю свою легонькую конфигурацию.
Есть документ и в нем ТЧ. См. изображение.
Реквизит "Цена одного изделия" получаю на сервере по ссылке из другого дока при событии на изменение реквизита "Ссылка на изделие". Вопрос такой:каким событием я смогу отследить изменение нужного мне реквизита в другом доке? То есть если я там эту цену поменяю, в моем доке она останется неизменной.
[url=https://radikal.ru][img]https://b.radikal.ru/b26/1905/50/a650a13ec22a.png[/img][/url]
1 palsergeich
 
27.05.19
22:17
(0) Тебе это не нужно.
Чисто теоретически это возможно через костыли.
Разрабатывать архитектуру надо так, что бы интерактивная работа не зависела от изменения состояния сущностей в других сеансах.
2 palsergeich
 
27.05.19
22:19
Методически верно финальную цену расчитывать уже в транзакции.
Да при вводе цена подставляется, но в Перед записью уже в транзакции получаются сиеминутные значения.
Если они не совпадают с документом - отказ и вывод пользователю сообщения.
3 Awalon
 
27.05.19
22:21
(2) как тогда правильнее цену получать?
4 palsergeich
 
27.05.19
22:23
Как в типовых.
при изменении номенклатуры запрос в РС цены номенклатуры неконтекстным серверным вызовом
5 palsergeich
 
27.05.19
22:24
А ПередЗаписью делаешь проверку что цены в ТЧ соовпадают с ценами в РС цены номенклатуры.
Чисто теоретически - документ может вводиться продолжительное время и цены в ТЧ в момент проведения будут неактуалоьны
6 palsergeich
 
27.05.19
22:25
А то что ты хочешь в (0), реализуемо конечно через всякие обработчики ожидания, но это костыль и лишняя нагрузка на базу.
7 Йохохо
 
27.05.19
22:27
(2) "Перед записью уже в транзакции получаются сиеминутные значения." это ужасно, провестись должно с данными которые видно на форме, а афтору надо кнопку обновить
8 palsergeich
 
27.05.19
22:29
(7) Не согласен.
Формально документ может вводиться много часов и это приведет к коллизиям. Что в документе, проведенном в 18, цены, которые уже не актуальны были в 12.
Проверка в транзакции должна быть, что введенные данные соответствуют учетным с удобным диагностическим сообщением.
Кнопка - как изюминнка, ее можно сделать, но проверка должна быть.
9 palsergeich
 
27.05.19
22:30
На сколько я помню - в типовых такая проверка есть
10 palsergeich
 
27.05.19
22:34
+ продажники и закупщики это очень хитрые жопы, год назад на мисте или ИС были излияния души, про то как они наепывали систему резеров и как с этим боролись. Заполнить документ с утра и держать его до вечера заполненным это была только первая стадия борьбы.
11 Йохохо
 
27.05.19
22:37
котрпримеры есть, но они совсем не очевидны, например прилетели бонусы и скидку надо пересчитать, или 23 и корзинку надо облегчить
12 palsergeich
 
27.05.19
22:41
(11) Когда я работал в рознице, да при вводе это считалось, но опять же - просто обязательная проверка в момент продажи.
Ибо акция могла на момент пробития чека быть завершена.
Или антифродовое условие появиться (о сколько фрода на скидках было, это ужас, почти половина времени - антифродовые мероприятия). Всегда проверка в момент фиксации хозяйственной операции с выдачей понятного для человека любой квалификации сообщения (Внимание, примененная акция уже не действительна, необходимо сделать то то).
13 palsergeich
 
27.05.19
22:42
Были даже акции длинной в пару часов за счет вендора.
Так что не все так однозначно
Программист всегда исправляет последнюю ошибку.