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

[Starling]

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

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

[Eldar9x]

Цитата:

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

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

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

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

[Ace of Database]

Цитата:

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

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

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

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

[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 колонок в Экселе, с красивыми группировками. Каждый новый менеждер привносит в систему что-то свое.
При этом нанимать менеджеров со знанием Аксапты и с аксаптовским подходом к делу, видимо, не соответствует рыночным условиям.

[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)