Как я уже писал в Как в фоновом задании узнать завершено ли проведение документа остатки при перепроведении документа изменяются 4 раза. Автоудаление движений по двум регистрам (которые меня интересуют) и затем запись новых движений в эти же регистры.

Сделал подписку на события ПередЗаписью (чтобы отследить удаляемые из документа товары) и ПриЗаписи для наборов записей по этим регистрам. Соответственно имею 8 вызовов, в которых собираю массив товаров, требующих обновления остатков во внешней системе.

Теперь вопрос: Где хранить этот массив, чтобы он был доступен во всех восьми вызовах обработчиков событий (разных объектов иначе бы заюзал ДополнительныеСвойства) и затем в фоновом задании, обновляющем остатки во внешней системе?

Напрашивается вроде ВременноеХранилище, но тогда нужно сгенерить какой-то адрес и дальше сделать его доступным во всех этих вызовах. Как? Или может быть как-то еще?

Ну у тебя же полосочка длинная, должен же понимать, что этот твой огромный колосс не устоит на ногах. Меняй его на что-то более устойчивое.

параметр сеанса

хз в константу

будет видно во всех сеаесах даже. для сеанса хз в (2)

(4) сеанс ликвидируется в самый неудачный момент (а это точно произойдет), и все тру ляля по одному месту.
Не надо городить колхоз.

(0) Заведи план обмена

(6) К этому и склоняюсь, но думал обойтись без лишних обращений к БД

(7) Не надо городить колхоз.

Параметр сеанса для этого и создан

(8) Ок. Спасибо. Убедил )

(10) Если что-то пойдет не так и транзакция в документе завершится, а онлайн обновление упадет, то ждать когда по этим же товарам будут следующие движения можно долго, а так при следующем обмене из плана все изменения накатятся. Наверное да, так правильно.

Я правда планы обмена никогда не юзал. Пойду курить доки

(11) Ой, там легко. Создай предопределённый узел, настрой состав.
Записал регистрацию изменений, выгрузил, удалил регистрацию изменений.

(12) Со слова "Предопределенный" становится не понятно. Ну я подозреваю, что это похоже на предопределенные элементы справочников например, но я сильно от этого далёк. Что-то слышал краем уха, что они бывают ))

(11) не очищай данные узла, если "обновление упадет". Прогрузишь следующим регламентом.

(0) однозначно ПОСЛЕДОВАТЕЛЬНОСТЬ

(15) +
1. в случае сбоя сразу видно и номенклатуру и регистратор
2. сразу можно включать в последовательнось документы имеющие взаимное влияние
3. удобный механизм востановления, в том числе при штатном перепроведении

(16) Как ты в последовательности собираешься хранить только измененную номенклатуру?

(17) последовательность с 1 измерением "номенклатура", ему надо контролировать удаление номенклатуры из документа, и когда удалили он хочет ее удалять в других документах. Это 100% задача для последовательности

почему константа не подойдет?

(18) А какие в этом случае преимущества у последовательности перед регистром сведений? Гранулярность до момента времени наверное только, по сравнению с измерением РС, где максимум только миллисекунды хранить можно. Но ведь можно в РС и сам документ точно так же схоронить.

а вообще похоже не правильно задача поставлена... городьбы много

хотя конечно если он делает интерфейс к внешней базе, то может логичнее будет план обменов...

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

(20) последовательность работает с регистратором, а РС тебе придется делать независимый. Это я к вопросу блокировок и скорости работы индексов

(23) тут вопрос еще не ясно каким рабочим способом решать, а ты уже про скорости работы индексов....

даже не через константу, наверное так можно что-то подобное... http://catalog.mista.ru/public/1142470/ (Обмен через регистр сведений)

Да не. Решил через регистр сведений. Кстати это решает проблему и с завершением транзакции.

1. Запускаю фоновое, которое раз в секунду опрашивает регистр сведений.
2. Пишу в регистр сведений с одним измерением "Номенклатура".
3. Когда фоновое что-то получило из регистра - значит и транзакция завершена и она обновляет остатки во внешней системе. Вуаля.

Осталось придумать как не запускать 8 фоновых заданий по 8 событиям. Ну положим 4 можно сразу отфильтровать это ПередЗаписью.
Остается 4 вызова ПриЗаписи. Понять сколько их будет реально 4, 2 или одно (если движения только по одному регистру и это отмена проведения) не возможно. Поэтому фоновое запускается в первом же вызове ПриЗаписи.

Но пока не понятно как не запускать новые фоновые в оставшихся вызовах ПриЗаписи если таковые будут.

А, понятно. Просто фоновое запускается событием ПередЗаписью самого документа. Оно срабатывает и при перепроведении или отмене проведения из формы списка

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

самое правильно подписка на событие ПриЗаписи у регистра, там в собитии можно отследить это удаление или запись

(28) Приведите пример изменения регистра ТоварыНаСкладах (УТ 10.3) без записи документа. Точнее без генерации события ПередЗаписью

(28) "ПриЗаписи у регистра" там идет сбор данных, проблема в том, что эти события вызываются слишком много раз для одного проведения, а мне нужно одно фоновое задание, которое подождет пока документ проведется. см. ссылку в (0) если интересно

(29) например типовой обмен данными с режимом загрузки движений