Остатки по номенклатуре в разрезе складов внутри транзакции

[Ace of Database]

Правда все равно остаются ограничения у такого механизма по сравнению с прямым запросом к InvenSum-InventDim.

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

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

[raz]

Цитата:

Сообщение от Ace of Database

Правда все равно остаются ограничения у такого механизма по сравнению с прямым запросом к InvenSum-InventDim.

А сравни результат через класс и так:

    queryRun = new QueryRun(InventSum::newQuery(null, itemId, inventDimCriteriaLocal, inventDimParmLocal, inventDimParmGroupByLocal));

    while (queryRun.next())
    {
        inventSumLocal = queryRun.get(tableNum(InventSum));
        inventDimLocal = queryRun.get(tableNum(InventDim));

        if (InventUpdateOnhandGlobal::mustAddInventSumDeltaOnhand(itemId))
        {
            select #inventSumFields from inventSumDeltaLocal
                where inventSumDeltaLocal.ItemId        == itemId    &&
                      inventSumDeltaLocal.IsAggregated  == NoYes::No &&
                      inventSumDeltaLocal.TTSId         == appl.inventUpdateOnhandGlobal().inventUpdateOnhand().tTSId()
                #InventDimExistsJoin(inventSumDeltaLocal.inventDimId,inventDim2Local,inventDimLocal,inventDimParmLocal);

            inventSumLocal.addInventSumDelta(inventSumDeltaLocal);
        }

        .......

    }

[SRF]

Цитата:

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

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

А в чем принципиальная разница поиска по двум таблицам и использования класса InventOnHand - он же делает те же самые 2 select'а, по тем же таблицам. Кстати о какой сложности идет речь ?

Цитата:

Сообщение от Ace of Database

Правда все равно остаются ограничения у такого механизма по сравнению с прямым запросом к InvenSum-InventDim.

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

Так используйте стандартные методы InventSum::newQuery(...) и InventSumDelta::newQueryAggregated(...) - они вернут вам Query, а дальше какие хотите условия такие и добавляйте.

[someOne]

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

Пвтался использовать метод с использованием класса "inventDimParmOnHandLevel".
Остался пример кода.

    inventDim.InventLocationId = "Склад";
    inventDim = inventDim::findDim(inventDim);

    inventDimParm.InventLocationIdFlag = true;

    inventDimParmOnHandLevel.ItemIdFlag = true;
    inventDimParmOnHandLevel.InventLocationIdFlag = true;
    inventDimParmOnHandLevel.WMSLocationIdFlag = true;

    hand = InventDimOnHand::newAvailPhysical('29530', inventDim, inventDimParm, InventDimOnHandLevel::DimParm, inventDimParmOnHandLevel);

    iterator = hand.onHandIterator();

    while (iterator.more())
    {
        member = iterator.value();


        info(member.parmInventQty());

        info(InventDim::find(member.parmInventDimId()).wMSLocationId);

        iterator.next();
    }

Но такой способ работает очень медленно. (у меня по крайней мере...). Запрос по каждой номенклатуре длится более секунды!!!.
Может в настройках классов указал что то не правильно ?

Так как мне нужно было это использовать при резервировании, то есть довольно активно, такой способ оказался не приемлем.

В общем переделал все на прямые запросы к таблицам
- InventSum
- InventSumDelta

(Что то на подобие того как предложил raz). Так все "летает".

Только нужно учесть что вариант с циклом по текущим остаткам (inventSum) с прибавлением к нему InventSumDelta по аналитикам
группкировки inventSum может дать искаженный результат.

Так как в InventSumDelta могут быть остатки по аналитикам, которых нет в inventSum.

Правильный результат будет если:

1. Получить остатки в разрезе ячеек по InventSum, например так (для моей задачи):

    inventDimParm.initFromInventDim(inventDim);
    inventDimParm.ItemIdFlag = NoYes::Yes;
    inventDimParm.ClosedQtyFlag = NoYes::Yes;

    inventDimParmGroupBy.WMSLocationIdFlag = NoYes::Yes;

    query = inventSum::newQuery(query, itemId, inventDim, inventDimParm, inventDimParmGroupBy);

    queryRange = query.dataSourceTable(tableNum(inventSum)).addRange(FieldNum(InventSum, ClosedQty));
    queryRange.value(queryValue(0));

    queryRun = new QueryRun(query);

    while (queryRun.next())
    {
        inventSum = queryRun.get(tableNum(inventSum));
        inventDimLoc = queryRun.get(tableNum(inventDim));

        if (inventSum.AvailPhysical != 0)
        {
		//Тут текущий остаток в ячейках хранения
        }
    }

2. Получить остатки в разрезе ячеек InventSumDelta, например так (для моей задачи)

    while select sum(AvailPhysical) from inventSumDelta
    where inventSumDelta.ItemId         == itemId    &&
          inventSumDelta.IsAggregated   == NoYes::No &&
          inventSumDelta.ttsId          == appl.inventUpdateOnhandGlobal().inventUpdateOnhand().ttsId()
    join inventDimLoc
    group by WMSLocationId
    where (inventDimLoc.inventDimId      == inventSumDelta.InventDimId) &&
          (inventDimLoc.InventLocationId == "Склад")
    {
        if (inventSumDelta.AvailPhysical != 0)
        {
		//Тут изменнный остаток в ячейках хранения в данной транзакции
        }
    }

3. Объеденить два этих набора записей ("сложить" результат).

Это кроме того и самый производительный способ - всего два запроса к БД.

[Ace of Database]

Спасибо большое Raz и SomeOne!

Метод с получением двух query для InventSum и InventSumDelta с последубщими добавлениями в них дополнительных источников данных универсален для всех задач. С последующим суммированием результата через inventSum.addInventSumDelta(inventSumDelta);

Я все понял. Осталось заставить себя в следующий раз применить этот способ, а не считать по-старинке прямыми запросами

Еще один способ - оптимизировать код таким образом, чтобы алгоритму было без разницы, внутри транзакции идет подсчет остатков или за ее пределами, и в этом случае вынести подсчет остатков за пределы транзакции. Это самый оптимальный вариант, но к сожалению не всегда допустимый.

В общем, подсчет остатков - деликатная и объемная тема, достойная диссертации.

[Ярослав Щекин]

Извините, что поднимаю старую тему...

Коллеги, а Вам не кажется, что вот это:

Цитата:

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

Только нужно учесть что вариант с циклом по текущим остаткам (inventSum) с прибавлением к нему InventSumDelta по аналитикам
группкировки inventSum может дать искаженный результат.

Так как в InventSumDelta могут быть остатки по аналитикам, которых нет в inventSum.

вообще говоря, косяк в стандартном InventDimOnHand (Ax2009), или я чего-то не понимаю?
Может быть, это исправлено в каком-то SP?

[Logger]

Цитата:

Сообщение от Ярослав Щекин

Извините, что поднимаю старую тему...

Коллеги, а Вам не кажется, что вот это:

вообще говоря, косяк в стандартном InventDimOnHand (Ax2009), или я чего-то не понимаю?
Может быть, это исправлено в каком-то SP?

Это не косяк, а так спроектировано. Если сразу добавлять запись (пусть и с пустыми остатками) в InventSum одновременно с созданием InventSumDelta, то можно нарваться на блокировки/конфликт уникального ключа. А InventSumDelta как раз и делали, чтобы этого избежать.

[Ярослав Щекин]

Цитата:

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

Это не косяк, а так спроектировано. Если сразу добавлять запись (пусть и с пустыми остатками) в InventSum одновременно с созданием InventSumDelta, то можно нарваться на блокировки/конфликт уникального ключа. А InventSumDelta как раз и делали, чтобы этого избежать.

Подождите, причём тут внесение записи в InventSum? Мне было непонятно, почему InventSumDelta не обрабатывается в классе InventDimOnHand.

[Maxim Gorbunov]

Цитата:

Сообщение от Ярослав Щекин

Мне было непонятно, почему InventSumDelta не обрабатывается в классе InventDimOnHand.

Обрабатывается. См. InventOnhand.addInventSumDelta().

someOne имел в виду, что надо быть аккуратным, когда не используется InventDimOnHand, а остатки выбираются прямыми запросами к InventSum/InventSumDelta.

Кстати, в AX 2012 R3 появились View (InventSumAggrDeltaView и InventSumUnionDeltaPhysicalQty), в которых InventSum и InventSumDelta уже связаны. Идея была в том, чтобы читать остатки из этих View, и не заморачиваться с классами InventOnhand. Идея, вероятно, была неплохая, но реализация подкачала: во View забыли добавить TTSId, и теперь любые запросы к ним блокируют и InventSum, и InventSumDelta целиком. Используются эти View в новом Warehouse Management. В блогах и на форумах есть несколько статей, в которых люди пытаются что-то шаманить с индексами на InventSumDelta, чтобы блокировки уменьшить, но корень проблемы в том, что InventSumDelta просто неправильно используется в стандартном коде.