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

Не благодари: http://catalog.mista.ru/public/1207330/

(1)
большое спасибо, первый вопрос думаю решен - завтра на свежую голову опробую
а что насчет второго вопроса?

(2) Только своя кнопка вместо "Провести и закрыть", где взводишь семафор и потом где-то его анализируешь

(3) а если форма модифицирована, ее закрывают и соглашаются с сохранением данных?

(4) Кажется, по этому кейсу решение так никем и не придумано

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

(6) в данном случае после записи на сервере - уходить в клиента и снова дергать сервер не хочется

(7) Тогда своя кнопка-команда на просто записать, где и будет взводиться флаг необходимости пересчета

(8) ну такое себе решение )))

(7) А пуркуа бы и не па.  Это ведь будет пессимистический вариант - только если пользователь сознательно нажимает из формы именно кнопку "Провести", чтобы увидеть результат пересчета. Подождет. В этот момент он готов к ожиданию.

(10) только делает он это довольно часто в борьбе за резерв товара

(11) Если это типовой вариант, то тогда оптимизация ускорения интерактивного проведения от отказа пересчета в остальных случаях будет ничтожной. А учитывая, что пересчет выполняется уже не в транзакции, то и фиг бы с ним. Не. Были бы простые варианты - то хорошо. Но похоже, что простых вариантов нет.

Тонкая грань между оптимизацией и оверинженирингом :)

(12)(13) спасибо за участие
рано нам оптимизацией преждевременной заниматься, это был скорее политический вопрос

И еще вопрос: почему в палитре свойств элемента формы (конкретно таблицы ТЧ Товары) я вижу гораздо меньше доступных событий, чем есть
Хотя если взять обработчик события и добавить в расширение, то добавляется и срабатывает, но в палитре все равно нет

(15) Покажи на картинке и огласи релиз платформы

(16) вот так в расширении https://cdn1.savepice.ru/uploads/2020/5/20/f5dca291f09614f017350ee9581359dc-full.png
релиз платформы 8.3.16.1063

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

(18) так он мне притянет в расширение все справочники, имеющие ссылки в этой ТЧ

+(19) но да - события отобразились полностью