Список партий, по которым есть остатки (на дату)

[Eldar9x]

Подскажите, пожалуйста, как получить список партий по которым были остатки, скажем, позавчера?

[EVGL]

Отчет "физическое наличие по аналитикам" с фильтром по "Доступное количество" !0.

[Starling]

Путь в 3-ке - УЗ \ Отчеты \ Статус \ Физ. наличие по складам
Путь в 4-ке - нет под рукой
Путь в 2009 УЗ \ Отчеты \ Статус \ Физические запасы по складским аналитикам
Путь в 2012 - похоже также как и в 2009
Указать:
1. Дата = позавчера
2. Просмотр в разрезе партий.
3. В фильтре указать не пустую партию по InventDim
Добавлено:
EVGL опередил)

[Eldar9x]

А как программно это сделать?

[Starling]

Вообще рекомендую
http://axapta.mazzy.ru/lib/inventsumdate/
Это по 3-ке, но для 2009 тоже актуально.

[Vals]

Ещё есть отчёт в УЗ, что-то типа "Просроченные партии"

[Ace of Database]

В примере в качестве параметров используется _itemId (если не задан - то по всем номенклатурам), _dateFrom - дата, на которую нужны остатки, _inventLocationId - склад.

    while select
    sum(Qty), sum(costAmountPosted), sum(costAmountAdjustment) from InventTrans
    group by ItemId
    where
    (
        !_itemId || InventTrans.ItemId == _itemId
    )
    &&
    (
        InventTrans.DatePhysical < _dateFrom
    )
    &&
    (
        InventTrans.StatusReceipt == StatusReceipt::Purchased ||
        InventTrans.StatusReceipt == StatusReceipt::Received ||
        InventTrans.StatusIssue == StatusIssue::Sold ||
        InventTrans.StatusIssue == StatusIssue::Deducted
    )
    join inventDim group by InventBatchId
    where inventDim.inventDimId == inventTrans.inventDimId &&
    (!_inventLocationId || inventDim.InventLocationId == _inventLocationId)
    {
    }

[Starling]

to Ace of Database
Предложенный вами способ:
1. Будет работать значительно медленнее чем подход, который используется в стандартной функциональности.
2. Не учитывает, что дата корректировки себестоимости может (и обычно будет) отличаться от даты проводки, тем более физической даты.
3. Не учитывает статусы скомплектовано и зарегистрировано, которые влияют на остатки в наличии.
4. Опирается только на физическую дату, что не всегда верно.
Т.е. как одноразовая активность может быть и подойдет, в общем случае нет.

Я бы советовал автору все таки смотреть в сторону классов InventSumDate* в их реализации все эти нюансы учтены.

[Eldar9x]

Цитата:

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

to Ace of Database
Предложенный вами способ:
1. Будет работать значительно медленнее чем подход, который используется в стандартной функциональности.
2. Не учитывает, что дата корректировки себестоимости может (и обычно будет) отличаться от даты проводки, тем более физической даты.
3. Не учитывает статусы скомплектовано и зарегистрировано, которые влияют на остатки в наличии.
4. Опирается только на физическую дату, что не всегда верно.
Т.е. как одноразовая активность может быть и подойдет, в общем случае нет.

Я бы советовал автору все таки смотреть в сторону классов InventSumDate* в их реализации все эти нюансы учтены.

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

[Starling]

Как пример можно использовать код метода fetch() отчета InventDimPosted.
Все необходимые для вас параметры доступны в этом методе.
Вам необходимо изначально указать условия в query, согласно которым вы будете выбирать только те записи в InventSum для которых в InventDim заполнено поле "Партия".
Дальше дело техники.
Более того в отчете даже есть такой параметр как Показывать нулевые строки. Как раз он и отвечает за то, чтобы выводить только не нулевые остатки.

Сам отчет запускает в 2009 по пути УЗ \ Отчеты \ Статус \ Стоимость запасов \ Стоимость запасов по складской аналитике.

[Ace of Database]

Цитата:

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

to Ace of Database
Предложенный вами способ:
1. Будет работать значительно медленнее чем подход, который используется в стандартной функциональности.

У нас отчет по движению товаров состоит из более чем 50 колонок, для вычисления каждой из которой применяется подобный запрос. Для 2500 номенклатур и 7 миллионов проводок отчет выполняется за 15 минут. Если же сделать так, как считает Аксапта в стандартных отчетах, то время выполнения отчета стремится к бесконечности.

По остальным замечаниям, все зависит от конкретной задачи.

[Ace of Database]

Цитата:

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

to Ace of Database.
Т.е. как одноразовая активность может быть и подойдет, в общем случае нет.

Я бы советовал автору все таки смотреть в сторону классов InventSumDate* в их реализации все эти нюансы учтены.

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

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

[Evgeniy_R]

Цитата:

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

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

С некой условностью можно узнать сколько было скомплектовано на дату. Есть такое поле InventTrans.DateInvent, которое запоминает первую дату физической регистрации или комплектации складской проводки.
Если доля разукомлектации и хождения статусов из скомплектовано в физ. резерв не велика, то можно основываться с некоторой поправкой на это поле. Ограничение в том, что это поле обновляется только в момент первичного перехода в нужный статус и потом не сбрасывается.
Может кто использовал это поле, меня поправит...

[Ace of Database]

Тогда придется писать хитрый запрос, в котором проверять, что если DatePhysical больше, чем DateInvent, то считать что в промежутке между DateInvent и DatePhysical проводка была скомплектована. Дело дойдет до того, что придется анализировать каждую проводку в цикле.

[Evgeniy_R]

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

В остальном as you like)

[Maxim Gorbunov]

Цитата:

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

У нас отчет по движению товаров состоит из более чем 50 колонок, для вычисления каждой из которой применяется подобный запрос. Для 2500 номенклатур и 7 миллионов проводок отчет выполняется за 15 минут. Если же сделать так, как считает Аксапта в стандартных отчетах, то время выполнения отчета стремится к бесконечности.

По остальным замечаниям, все зависит от конкретной задачи.

Интересно узнать, как вы объясняете своим пользователям, почему остатки по вашему отчёту отличаются от остатков по стандартным отчётам по складу.

[Ace of Database]

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

[Starling]

Цитата:

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

У нас остатки не отличаются.

А себестоимость?

[Ace of Database]

В рамках принятой у нас практики, такой расчет себестоимости всех устраивает. Я не говорю, что это устроит всех. На двух предприятиях, на которых я работал, и в которых велся учет себестоимости в Аксапте, придумывали что-то свое и не пользовались стандартными отчетами по себестоимости. И это не я придумывал. Были большие команды внедренцев.
Наверное я зря включил поля CostAmountPosted и CostAmoutAdjustment в пример. Скорее всего, автора интересовали количественные остатки на дату.

[Ace of Database]

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