Khue Trinh: How to get Inventory On-hand number

[kashperuk]

Ну, раз уж на то пошло, то думаю оптимальным вариантом здесь является использование класса InventDimOnHand - я про это ему в комментарии тоже написал

И самый лаконичный, и самый re-using existing code

[mazzy]

Цитата:

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

Ну, раз уж на то пошло, то думаю оптимальным вариантом здесь является использование класса InventDimOnHand - я про это ему в комментарии тоже написал

И самый лаконичный, и самый re-using existing code

Хм... Спасибо. А почему не InventOnHand?

Вообще говоря, да. Было бы замечательно, если бы чел вместо "quick and dirty" примеров показал бы как правильно работать с классами. Чем классы отличаются друг от друга и в каких случаях лучше так, а в каких иначе...

Было бы замечательно, если бы он рассказал что класс InventOnHand прекрасно заточен на получение итога по одной номенклатуре и одной складской аналитике. Но этот класс становится чертовски неэффективным в цикле при переборе.

Было бы замечательно, если бы он рассказал о том как правильно перебирать итоги по разным номенклатурам и анлитикам в цикле.

Было бы замечтаельно, если бы он проанализировал что это за уровни в InventDimOnHand и почему эта сволочь делает кучу запросов, собирает все в итератор, хранит результаты в памяти и занимается прочей ерундой вместо того, чтобы сделать один простой запрос и этим же запросом вернуть результаты (за это я этот класс и не люблю. Может быть, просто не понимаю? Может, расскажешь подробнее нафига надо было городить такую сложную и неочевидную обертку над простой, в общем то, сущностью?)

Если человек хотел сказать, что:
1. InventSum хранит итоги по каждому конкретному InventDim (склад, цвет, размер, конфигурация, партия, серийный номер, паллета, ячейка)
2. Чтобы собрать итоги по одной аналитике (например, складу) придется просуммировать несколько InventSum.

То так бы и сказал.

Но чел написал "quick and dirty" пример. К тому же содержащий элементарные ошибки.
Именно это и взбесило - убежденность автора, что данного примера будет достаточно для enjoy.

[mazzy]

Цитата:

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

Ну, раз уж на то пошло, то думаю оптимальным вариантом здесь является использование класса InventDimOnHand

Посмотрел еще раз.
Не. Этот класс используется сугубо в WMS. Этот класс позволяет хранить результаты и перебирать их повторно в алгоритме оптимального поиска ячеек.

В остальных случаях этот класс явно избыточен, на мой взгляд.
Кроме того, этот класс выбирает несколько результатов в цикле (!) при помощи InventOnHand. А inventOnHand заточен на получение итога по одной аналитике. В цикле этот класс чудовищно неэффективен. А следовательно, неэффективен и InventDimOnHand.

По-моему, InventDimOnHand был и остается примером крайне неудачного использования инструмента InventOnHand. Разработчикам InventDimOnHand надо было использовать InventSum::newQuery, а не InventOnHand.

Или я чего-то не понимаю?

[kashperuk]

InventOnHand, конечно
Dim я туда случайно всунул, так как АХ не открыл, чтобы проверить, что это тот класс, который на уме. Сорри за запутывание

Вот пример написал, что исправиться

static void InventOnHandExample(Args _args)
{
    InventDim       inventDim;
    InventDimParm   inventDimParm;
    #define.InventLocationId("MW")
    #define.ItemId("ESB-005")
    ;
    inventDimParm.InventLocationIdFlag = NoYes::Yes;
    inventDim.InventLocationId = #InventLocationId;

    box::info(strFmt("%1", InventOnHand::newItemDim(#ItemId, inventDim, inventDimParm).availPhysical()));
}

Очень аккуратно, imho.

А про InventSum::newQuery() - ты немного просто напутал, когда написал цикл. Ведь этот запрос, по сути, уже возвращает готовый запрос с агрегированием, поэтому цикла там никогда не будет - хотя код, естественно, будет работать.

[mazzy]

Цитата:

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

А про InventSum::newQuery() - ты немного просто напутал, когда написал цикл. Ведь этот запрос, по сути, уже возвращает готовый запрос с агрегированием, поэтому цикла там никогда не будет - хотя код, естественно, будет работать.

Я думал об этом когда писал пример

Цикла не будет только в этом примере. Я специально сделал группировку как у Тринха. При его группировке и условиях цикл действительно не нужен. В реальности параметры ParmCriteria, ParmGroupBy могут и не совпадать. А также ParmGroupBy может содержать больше галочек, чем ParmCriteria. Тогда цикл очень даже нужен.

Кстати, InventOnHand как раз предполагает совпадение. За счет такого предположения они сократили число параметров и убрали ParmGroupBy.

Я же старался написать действительно универсальный код, который можно использовать как паттерн в любых случаях. Какие бы галки не включили в ParmCriteria и ParmGroupBy - мой код будет работать корректно.

[mazzy]

Цитата:

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

Очень аккуратно, imho.

Да. Единственное ограничение - не наод использовать конструкцию с InventOnHand внутри цикла. Только для одноразового запроса.

[mazzy]

Цитата:

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

Очень аккуратно, imho.

Кстати, если говорить об аккуратности и краткости при предположениях и в частных случаях...
Если нужно получить только по непустым складским аналитикам, то можно упростить и унифицировать инициализацию InventDimParm.
Вот так.

static void InventOnHandExample(Args _args)
{
    InventDim       inventDim;
    InventDimParm inventDimParm;
    #define.InventLocationId("MW")
    #define.ItemId("ESB-005")
    ;
    inventDim.InventLocationId = #InventLocationId;
    inventDimParm.initFromInventDim(InventDim); // галочки берем из непустых полей InventDim

    info(strFmt("%1",
        InventOnHand::newItemDim(#ItemId,inventDim,inventDimParm).availPhysical()
    ));
}