Остатки на дату.

[UNRW]

физ остаток на дату:

select sum(Qty) from inventTrans
where
inventTrans.ItemId == "MyItem" &&
inventTrans.DatePhysical <= dateTo &&
inventTrans.StatusIssue <= StatusIssue:educted &&
inventTrans.StatusReceipt<= StatusReceipt::Receipt
join inventDim
where inventDim.InventDimId == inventTrans.InventDimId &&
inventDim.InventLocationId == "MyLocation";

[mazzy]

Цитата:

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

физ остаток на дату:

select sum(Qty) from inventTrans
where
inventTrans.ItemId == "MyItem" &&
inventTrans.DatePhysical <= dateTo &&
inventTrans.StatusIssue <= StatusIssue:educted &&
inventTrans.StatusReceipt<= StatusReceipt::Receipt
join inventDim
where inventDim.InventDimId == inventTrans.InventDimId &&
inventDim.InventLocationId == "MyLocation";

НЕТ! НЕТ! НЕТ!!! И еще раз НЕТ!!!
НИКОГДА так не делайте.

Этот код работат боль-мень приемлимо только на игрушечных данных малого объема!
Стоит вам только приблизиться к нормальному рабочему объему - ваша база умрет.

Здесь написано как Аксапта получает остатки на произвольную дату
http://axapta.mazzy.ru/lib/inventsumdate/

[Bars]

Цитата:

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

НЕТ! НЕТ! НЕТ!!! И еще раз НЕТ!!!
НИКОГДА так не делайте.

Этот код работат боль-мень приемлимо только на игрушечных данных малого объема!
Стоит вам только приблизиться к нормальному рабочему объему - ваша база умрет.

Здесь написано как Аксапта получает остатки на произвольную дату
http://axapta.mazzy.ru/lib/inventsumdate/

Прочитал, понял, спасибо).

Все равно медленно.

[Recoilme]

Цитата:

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

Прочитал, понял, спасибо).

Все равно медленно.

Может опишешь задачу полностью? Другими словами - на фига тебе остатки на дату в форме, да ещё и быстро ???

[dn]

Цитата:

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

Здесь написано как Аксапта получает остатки на произвольную дату
http://axapta.mazzy.ru/lib/inventsumdate/

В этой статье рассмотрен механизм работы стандартных классов, что наверное тоже не бесполезно. Но эти классы ещё можно как-то использовать для расчета остатков на дату по одной номенклатуре. Но для 10000 позиций это уже не будет работает даже для "игрушечных" данных, созданных за несколько месяцев.
Наиболее правильным вариантом является создание отдельной OLAP-базы, в которую с ежедневной периодичностью переносятся нужные данные из axapta. По этой базе уже и строятся отчеты по остаткам на дату. При этом понятно, что будет запаздывание, поэтому текущие остатки нужно брать из Axapta.
Однако в качестве промежуточного решения я бы всё же использовал запрос "с начала времен". Его план выполнения по-крайней мере можно оптимизировать средствами СУБД (Oracle)...

[Владимир Максимов]

Цитата:

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

НЕТ! НЕТ! НЕТ!!! И еще раз НЕТ!!!
НИКОГДА так не делайте.

Этот код работат боль-мень приемлимо только на игрушечных данных малого объема!
Стоит вам только приблизиться к нормальному рабочему объему - ваша база умрет.

Здесь написано как Аксапта получает остатки на произвольную дату
http://axapta.mazzy.ru/lib/inventsumdate/

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

30 тысяч артикулов. Рассчитать остаток для каждого артикула на начало мая 2005 года по 2 фиксированным складам (InventLocationId). Это около 2 миллионов складских проводок

InventSumDatePhysicalDim:: onHandQty() - отработал примерно за 50 минут
Прямой запрос в Query Analyzer по схеме: InventSum - SUM(InventTrans) выполнился за 2 минуты (т.е. остаток на сегодня минус все складские проводки до интересующей даты)

Даже с учетом того, что при переносе запроса в синтаксис AXAPTA он слегка "притормозит", все равно ускорение получаю в разы

Конечно, это несколько не то, что предложил UNRW. Я иду не "с начала времен", а от текущей даты назад. Но, по большому счету, на вывод это не влияет.

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

[mazzy]

Цитата:

Сообщение от Владимир Максимов

Вообще-то, даже чисто логически, вывод будет прямо противополжным. Одна групповая команда по всякому быстрее работает чем куча одиночных команд в цикле.

1. Вы почему то обсуждаете конкретную реализацию, а не принцип. Принцип - считаем проводки от конца, а не от начала времен.
2. Вы забываете об аналитике. Аналитика у каждой номенклатуры - разная. Вообще говоря, мало кто хочет получить остатки на произвольную дату. Запрос UNRW является неправильным, поскольку не учитывает параметры в группе аналитики. Но я это дело пропустил, поскольку посчитал неважным.

ОДНАКО: если вы говорите о групповой обработке, то расскажите как вы обработаете аналитике корректно в групповой обработке?

Еще раз: уважаемые, подумайте.

[Владимир Максимов]

Цитата:

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

1. Вы почему то обсуждаете конкретную реализацию, а не принцип. Принцип - считаем проводки от конца, а не от начала времен.

Как минимум, спорный.

Если структура базы корректна, то, должно быть все-равно идем с начала в конец или с конца в начало. Результат должен быть одинаковый. По крайней мере в штуках.

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

В общем случае, от текущей даты будет быстрее. А в конкретном, надо смотреть на месте.

Цитата:

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

2. Вы забываете об аналитике. Аналитика у каждой номенклатуры - разная. Вообще говоря, мало кто хочет получить остатки на произвольную дату.
...
ОДНАКО: если вы говорите о групповой обработке, то расскажите как вы обработаете аналитике корректно в групповой обработке?

Не знаю, у меня как раз пользователи хотят получить остатки не в разрезе складской аналитики, а по конкретному реквизиту аналитики. Т.е. "вообще все остатки вот по этому складу". Просто соответствующий фильтр на InventDim.

Или что Вы понимаете под термином "аналитика номенклатуры" применительно к расчету остатков?

[mazzy]

Цитата:

Сообщение от Владимир Максимов

Т.е. "вообще все остатки вот по этому складу". Просто соответствующий фильтр на InventDim.

Или что Вы понимаете под термином "аналитика номенклатуры" применительно к расчету остатков?

Извините. Сейчас используется термин Складская аналитика.
Конурация, Цвет, Размер, Склад, Ячейка, Партия, ... ГТД(!)

Я не верю, что для всех аналитик пользователи будут хотеть "получить остатки не в разрезе складской аналитики, а по конкретному реквизиту аналитики"

Конечно, если у вас используется ТОЛЬКО склад...
Причем НЕ БЫВАЕТ аналитики с выключенным складом (обычно это услуги)...
Если ваши пользователи НЕ ХОТЯТ видеть отчет в разрезе всех (или нескольких выбранны) аналитик...

[Владимир Максимов]

Цитата:

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

Я не верю, что для всех аналитик пользователи будут хотеть "получить остатки не в разрезе складской аналитики, а по конкретному реквизиту аналитики"
...
Если ваши пользователи НЕ ХОТЯТ видеть отчет в разрезе всех (или нескольких выбранны) аналитик...

Видимо, мне пока везет (или не везет, это как посмотреть). Но именно это от меня и хотят (или пользователи не хотят)

Хорошо. Если говорить "в общем случае". Почему при расчете остатка на дату от текущей даты назад в разрезе складских аналитик недостаточно будет добавить группировку по соответствующим полям InventDim?

Т.е. логика та же, что и в классе: берем текущий остаток по InventSum, из него вычитаем сумму InventTrans до нужной даты. Это 2 последовательных запроса.

Каждый запрос имеет группировку по нужным полям InventDim.

Какие здесь проблемы? Чем это принципиально отличается от работы классов InventSumDate?