Производительность запроса Оборотная ведомость по складу

[SolNik]

В DAX2009 (у нас RU5) появилась новая версия оборотки по складу (Управление запасами/ Запросы/ Проводки).
Кто нибудь использует ее в своих проектах? Нет претензий к производительности?
На нашей базе с 30000 номенклатур, на месяц назад от текущего отчет строится около 48 часов
По идее ускорить построение отчета должен запуск периодической операции "Управление запасами/ Периодические операции/ Запасы в наличии на указанную дату". Но как я понял из кода, даже при наличии обсчитанных данных отчет все равно лезет в лоб, в складские проводки.
Какая методика предварительного обсчета данных? Их нужно обсчитывать на каждую дату в рамках периода закрытия или только на дату самого закрытия?
Буду благодарен за любую информацию об опыте использования этого отчета.

[Ivanhoe]

Аналогично, строится очень долго. Пока спасает OLAP, но хотелось бы разобраться со стандартными функциями.

[SolNik]

Просто мы уже запостили issue в поддержку MS на эту тему. Но в MS нам ответили, что этот отчет и так уже очень сильно оптимизирован и для дальнейших работ по его оптимизации нужны очень веские доводы.
В отчете кстати есть еще ошибка - он неправильно выдает остаток на конец периода, в случае если в периоде были закупки, по которым отборочная накладная была обработана позже финансовой. На эту тему тоже отправили запрос в поддержку, он сейчас в работе.

[gene]

Цитата:

Сообщение от SolNik

По идее ускорить построение отчета должен запуск периодической операции "Управление запасами/ Периодические операции/ Запасы в наличии на указанную дату". Но как я понял из кода, даже при наличии обсчитанных данных отчет все равно лезет в лоб, в складские проводки.
Какая методика предварительного обсчета данных? Их нужно обсчитывать на каждую дату в рамках периода закрытия или только на дату самого закрытия?

В документации на данный запрос написано:

Цитата:

Для оптимизации производительности запроса Оборотная ведомость по складу используются предварительно рассчитанные данные – запасы на дату закрытия склада. Используется дата закрытия склада, поскольку запасы, зафиксированные закрытием склада, не могут быть уже изменены задним числом. При выполнении запроса система определяет, может ли запрос быть (частично) выполнен с использованием предварительно рассчитанных запасов, и при необходимости дополняет указанные данные расчетом на основании складских проводок.

Естественно, запрос вынужден лезть в складские проводки в тех случаях, когда период запроса не точно совпадает с периодами, на которые есть эти предварительно рассчитанные данные.

Цитата:

Дата для расчета запасов в наличии
Дата закрытия склада, для которого необходимо выполнить расчет запасов. По умолчанию определяется как дата первого по времени закрытия склада, для которого расчет запасов еще не выполнялся

То есть процедура запускается только на даты операций закрытия склада.

[Ivanhoe]

В моем случае проблема не 48ми часов, но все же.

Есть рабочий сервер, который нормально обслуживает порядка 100 человек (закупки, перемещения, продажи). Есть начальное сальдо, заведенное как 11 000 строк журналом Проводка. Есть закрытие склада на эту же дату.

На ночь (нет активности) запускаем расчет остатков (пара часов), запускаем сам запрос на дату закрытия - еще пара часов. Мне кажется это ненормально.

[SolNik]

Цитата:

Сообщение от gene

В документации на данный запрос написано:

Спасибо за ответ. А не подскажете, где взять эту чудо-документацию? В стандартных мануалах по российскому функционалу Управления запасами я этого не нашел

Цитата:

Сообщение от gene

Естественно, запрос вынужден лезть в складские проводки в тех случаях, когда период запроса не точно совпадает с периодами, на которые есть эти предварительно рассчитанные данные.

То есть процедура запускается только на даты операций закрытия склада.

Странно, мы пробовали строить отчет за период [Дата предыдущего закрытия+1, Дата текущего закрытия], но особой прибавки в скорости не заметили...и при этом InventTrans все равно активно лопатился...

Я вот не понимаю, если уж решили использовать предрасчитанные данные по закрытому периоду, почему не пошли до конца?...сделали бы аналог LedgerBalancesDimTrans и строили бы отчет только по нему...

[Ivanhoe]

Выше были выдержки из описания RU3, скачать можно тут.

[gene]

Цитата:

Сообщение от SolNik

Спасибо за ответ. А не подскажете, где взять эту чудо-документацию? В стандартных мануалах по российскому функционалу Управления запасами я этого не нашел

На фичи, выходящие в ролапах, документация делается в виде What's new, распространяемых вместе с ролапом. Эта документация выложена здесь по ссылке, которую выше дал Ivanhoe, а также на сайте msbpartners.ru (насколько я понимаю, доступно только партнерам). Кстати, выдержки были из доки на РУ-5, где запрос был немного модифицирован по сравнению с РУ-3, а дока была соответствующим образом поправлена.

Цитата:

Сообщение от SolNik

Странно, мы пробовали строить отчет за период [Дата предыдущего закрытия+1, Дата текущего закрытия], но особой прибавки в скорости не заметили...и при этом InventTrans все равно активно лопатился...

Я вот не понимаю, если уж решили использовать предрасчитанные данные по закрытому периоду, почему не пошли до конца?...сделали бы аналог LedgerBalancesDimTrans и строили бы отчет только по нему...

Почему не заметили прибавки, нужно разбираться... Как и с тем, почему лезет в складские проводки.
Насчет того, почему реализовано именно так: хотя бы потому, что процедура предрасчета оборотов или остатков на каждый день вместо одного дня закрытия периода и работала бы соответствующим образом дольше, и данных порождала соответствующим образом больше, с неочевидным выигрышем в производительности относительно текущей реализации. Вообще, при разработке данного запроса анализировались различные подходы, но есть определенные ограничения, которым мы должны следовать, и поэтому был выбран тот подход, который был выбран.

[Mikky]

Цитата:

Сообщение от SolNik

Странно, мы пробовали строить отчет за период [Дата предыдущего закрытия+1, Дата текущего закрытия], но особой прибавки в скорости не заметили...и при этом InventTrans все равно активно лопатился...

Цитата:

Сообщение от gene

Почему не заметили прибавки, нужно разбираться... Как и с тем, почему лезет в складские проводки.

"Лезет", потому что в периодической операции расчета запасов в наличии на указанную дату не учитываются складские проводки в статусах расхода == Deducted (Отпущено) и прихода == Received (Получено), т.е. проводки, по которым разнесены отборочные накладные. Расчет ведется только по проводкам, соответствующим финансовым накладным. При запуске же запроса Оборотная ведомость по складу статусы отборочных накладных учитываются и происходит расчет остатка по ним на дату и оборота по ним за период. Отсюда и запросы к InventTrans. Все это прослеживается при трассировке в методе calcItem() класса InventSumDateFinancialCalc_RU.
Может попробовать перенести расчет по этим статусам в периодическую операцию расчета запасов на дату?