|
Событие на изменение реквизита | ☑ | ||
---|---|---|---|---|
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
|
Были даже акции длинной в пару часов за счет вендора.
Так что не все так однозначно |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |