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

(0)

ПроведениеСерверУТ.ВыполнитьКонтрольРезультатовПроведения(...)

Объект.ДополнительныеСвойства.ДляПроведения.СтруктураВременныеТаблицы;

Временная таблица "ДвиженияСвободныеОстаткиИзменение"

P.S.

Ты бы лучше написал какую задачу пытаешься решить.
SQL-сервер конечной железный, но иногда его жаль.

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

+(2) после вынесения всего этого в РС, получил ускорение в несколько раз

(2) Такая же идея пришла в голову фирме 1С и они переделали хранение свободных остатков в версии 11.5.7, и Вам придется переделывать свой костылик, когда придёт время обновляться на эту версию (это будет нескоро).

Если получить вот так: Для каждого запись из ЭтотОбъект Цикл в процедуре СформироватьТаблицуИзмененийДвижений() - какие тут могут быть подводные камни? и правильно ли так изменения получать?

(4) эх... на 11.5 не скоро будет переход, пишем свое

(5) а если будет записан пустой набор? т.е. отмена проведения

(7) ну вот поэтому и создал тему. Подскажите - как правильно сделать

(2) почему нельзя остатки брать из своего РС и подкидывать ему обороты из РН за последние нерассчитанные часы?

(9) потому что в базе 150 человек активно колотят документы, надо сразу дублировать запись из РН в свой РС, иначе данные могут быть неактуальные

(10) был у меня клиент 3 менеджера и два кладовщика, но подбор тормозил жутко - пришлось именно его оптимизировать. разным менеджерам нужная разная инфа, а не все что есть

кстати очень помогло использование общих модулей с повторным использованием, зуб даю что вы при своих поделках этим не заморачивались )))

(12) не очень вижу что там можно закешировать, данные меняются

ап. Как правильно такое организовать? уверен что делалось уже кем то такое и не раз. УТ 11.5 конечно вариант посмотреть, но может кто подскажет что-то еще?

Неужели никто ничего дельного не посоветует?

(2) план обмена используйте, через него регистрируйте изменения документов в течение дня. Далее регламентным заданием пробегайте по изменениям и по ним уже обновляйте ваш РС. Что считать изменением, это уже вам решать, можете свою функцию проверки создать, если она не сильно долгая по выполнению. А по результату уже записывать изменение в узел. Можете все записывать в узел без проверки, а далее по измененным данным (что за записали) делаете запрос к вашему РС, сравниваете 2 таблицы, если значения отличаются, то для тех строк записываете новые значения.

Одно не пойму.

РегистрНакопления.СвободныеОстатки.Остатки () -- это агрегат (итоги).
Данный регистр пересчитывается (блокировки, оптимизация, бла-бла-бла) на уровне платформы.
Почему, регистр сведений изобретаемый топикпастером, софтовый аналог этого агрегата, на прикладном уровне будет заполняться и работать быстрее?

(17) скорее всего запрос сложный у него в подборе с кучей соединений и условий. Вот он и хочет львиную часть на формирование переложить на регламент, а в течение дня пользоваться уже результирующим РС.

(18) именно так, там кроме остатков еще ресурсов более 10 штук, все собирается из множества таблиц

+(19) из-за этого тормозит динамический список так, что работать невозможно, РС дал ускорение в 3-4 раза, осталось данные в течении дня актуализировать

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

(21) неужели нет универсального способа? Нельзя отследить движения регистра, без разницы, пустой набор или нет? не очень хочется по документно регистрировать изменения

Подписка на событие "ПриЗаписи" регистра накоплений не подойдет?

(23) когда идет движение расход или приход - все видно, проблема с отменой проведения документа, это я поймать не могу в ПриЗаписи

В общем вижу сейчас 2 варианта - вариант из (16), и вариант - создать подписку с событием ОбработкаУдаленияПроведения для всех документов которые могут двигать СвободныеОстатки, и уже там проверять по ТЧ изменились ли остатки, если да - обновлять эту запись в своем регистре. Пока склоняюсь ко второму варианту, поскольку с планами обмена очень мало сталкивался.
На что еще стоит обратить внимание?

(11) Из оптимизаций на маленьких базах - в файловой помогает включение индексирования в измерениях регистра.

(26) с этим вопросов нет.

(25) есть ещё один вариант - написать свою обработку рабочего места, чтобы в ней не было километрового типового запроса.

(25) только вот нужно понимать сколько времени будет ваша проверка отрабатывать. К примеру у вас в день проводят 2000 документов, если проверка занимает 3-5 сек, то это будет просто жесть, вас юзверы съедят. А еще есть различные случаи, когда надо за старый период документы провести, или там месяц закрыть. Если в этом случае будете свою проверку юзать, то время выполнения значительно увеличится. Еще не дай бог проблемы с блокировкой таблиц появится. Так что надо все это дело учитывать, прежде чем утяжелять проведение документов.

(28) ну вот сейчас начал проверять на большом объеме данных - не устраивает все равно скорость работы "подбор в документы продаж". Походу придется вообще запрос типовой убирать (я его оптимизировал).
(29) в фоновое задание вынесу проверку/обнновление