Складские остатки на дату

[Logger]

К вопросу о складских остатках на дату.
Недавно перечитывал статьи
http://axapta.mazzy.ru/lib/inventsumdate/

обратил внимание на то, что скомплектованное количество в данных классах считается и при этом учитывается дата InventTrans.DateExpected

а зарезервированное количество не рассчитывается, так что нет метода который бы, скажем, вернул на дату аналог значения InventSum.AvailPhysical, но есть метод для значения на дату InventSum.PhysicalInvent

Интересно, почему так ?

[S.Kuskov]

Вы имеете в виду на дату в будущем? Если так, то для этого нужно использовать функционал сводного планирования. Например на форме "Чистые потребности" есть поле "Накоплено".

А если в прошлом, то какой от этого прок?

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

По банальной причине. Это бессмысленно. Не имеет "физического" смысл

"Физ.наличие" - это то, сколько товара физически вообще есть на складе.
"Физ.доступно" - это то, сколько товара из того, что физически есть, можно использовать при создании новых заказов. Сколько товара "свободно". Никем не зарезервировано под свои нужды.

Как рассчитать эти параметры на заданную дату?

Очевидно, что для "Физ.наличия" все просто. Достаточно просто сложить количества складских проводок, вне зависимости от того, какой статус прихода/расхода они имеют в настоящее время. История изменения статусов роли не играет. Досточно знать их статус на текущий момент и когда произошел физический приход/расход товара. Дата прихода/расхода зафиксирована в полях DatePhysical/DateFinancial/DateInvent

А вот для "Физ.доступно" просто сложить проводки - невозможно! Ведь надо знать не просто статус проводки, который она имеет сейчас, а тот статус проводки, который у нее был на интересующую дату! И даже дату установить не возможно, ведь установка/снятие с резерва не порождает новых проводок.

Ну, например, если 1 штука была зарезервирована вчера, а сегодня уже снята с резерва, то, очевидно, чтобы определить тот факт, что вчера "Физ.доступно" было 0, а сегодня - 1 надо хранить историю. Недостаточно знать, что есть сейчас. Необходимо знать, что было вчера

А для расчета "Физ.наличие" история не нужна. Что вчера товар был на складе, что сегодня он есть. Ну и что, что в другом статусе. Но ведь есть же! Есть физическое наличие товара.

Вот и получается, что "Физ.доступно" на дату рассчитать просто невозможно. Нет необходимой информации (истории изменения статусов проводок). Так зачем вычислять бесполезную информацию?

[Logger]

Хм.
Один в один ваши рассуждения можно применить к комплектации. А она учитывается при расчете на дату. И также товар можно раскомплектовать так что в истории нигде не останется что он был скомплектован.

В общем непонятка как раз в том, что если считаем скомплектованное количество на дату то и зарезервированное тоже надо. Либо ни то ни другое не считать.

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

Цель работы этих классов получить значение "Физ.наличие". Все остальное - это промежуточные результаты. Рассматривать отдельные слагаемые как реальное количество на дату следует с осторожностью.

Комплектация и регистрация - оказывает влияние на "Физ.наличие", поэтому учитывать их необходимо. А тот факт, что невозможно получить "комплектацию (регистрацию) на дату" по причине отсутствия истории не отменяет необходимости их как-то учесть.

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

Физ.зарезервировано также невозможно получить на дату. Но это значение не участвую в расчете "Физ.наличие", поэтому и никак не фигурирует даже в виде слагаемых.

PS: Кстати, добавлю, что и отфактурованное/отгруженное количество на дату тоже величина достаточно условная. Ведь анализ выполняется по дате документа, а не по дате создания. А пользователи очень любят ставить эту дату раньше/позже текущей даты...

[glibs]

Цитата:

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

...
если считаем скомплектованное количество на дату то и зарезервированное тоже надо
...

Что значит "Надо"?

Скомплектованное количество, равно как и зарегистрированное, влияет на остатки. Резерв — это некая блокировка. В системе нет отчетности по истории резервов. По остаткам есть + инвентаризация.

Если нужно персонально вам... это другое совсем дело. Резерв сам по себе умирает при смене статуса на более поздний. По регистрации-комплектации хоть след остается.

По регистрации-комплектации возможен сценарий: одной датой зарегистрировали, другой сняли регистрацию, третьей опять поставили. В отчет по остаткам попадет только последний факт. Вас "Тоже" в вашем отчете с учетом резервов устроит?

[glibs]

Цитата:

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

...
учитывается дата InventTrans.DateExpected
...

По-моему, InventTrans.DatePhysical

Цитата:

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

...
нет метода который бы, скажем, вернул на дату аналог значения InventSum.AvailPhysical, но есть метод для значения на дату InventSum.PhysicalInvent
...

Б-р-р-р... Не понял. InventSum возвращает на дату? Ваша фраза очень непонятна.

[pitersky]

Цитата:

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

По-моему, InventTrans.DatePhysical

А разве для скомплектованных проводок DatePhysical заполнено? Ведь разноски ещё не было...

[glibs]

Виноват, DateInvent. По памяти писал.

[Logger]

Цитата:

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

По-моему, InventTrans.DatePhysical

Б-р-р-р... Не понял. InventSum возвращает на дату? Ваша фраза очень непонятна.

Неточно выразился. Речь идет о семействе классом описанных в ссылке у Маззи. Некоторые методы в этих классах возвращают на дату +бесконечность то же значение которое лежит в в определенных полях в InventSum.

Именно в таком смысле было сказано "InventSum на дату"

[pitersky]

Подниму тему, ибо обнаружилось любопытное исключение из правил расчёта.
Если InventSum и InventTrans различаются на порядки (т.е. по каждому остатку много проводок), то схема mazzy однозначно оптимальна. А вот если разница менее порядка (т.е. по каждому разрезу было лишь несколько движений) - то оказывается выгоднее именно считать сумму количества в проводках с начала времён. Как я понимаю, это результат специфики работы SQL, который занимается черновой работой по схлопыванию записей - когда складских проводок по разрезу мало, то перебор свёрнутых по аналитике InventTrans идёт быстрее, чем перебор InventSum с расчётом остатка по каждому из них.

Вот пример такой ситуации. В InventSum 1,5 млн. строк, в InventTrans - 8 млн. Стоит задача определить отрицательный остаток во всех разрезах за определённый период (т.е. номенклатура-дата из периода-разрез-отрицательное количество). По схеме mazzy аксапта работала 13,5 часов. Суммированием InventTrans - полчаса. Результаты совпали

[mazzy]

в статье так и говорилось
http://axapta.mazzy.ru/lib/inventsumdate/

Цитата:

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

поэтому вполне возможно, что анализ старых периодов лучше вести от начала времен.
===============

Цитата:

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

А вот если разница менее порядка (т.е. по каждому разрезу было лишь несколько движений) - то оказывается выгоднее именно считать сумму количества в проводках с начала времён. Как я понимаю, это результат специфики работы SQL, который занимается черновой работой по схлопыванию записей - когда складских проводок по разрезу мало, то перебор свёрнутых по аналитике InventTrans идёт быстрее, чем перебор InventSum с расчётом остатка по каждому из них.

Да, и это условие тоже есть.

Но соотношение между таблицами - это не все.
Дело в том, что InventSum содержит как закрытые, так и открытые записи.

закрытая запись - это запись по какой-то комбинации аналитик, с полностью нулевыми количествами-суммами. (см. метод InventSum.isAllFieldsZero(), а также поле InventSum.Closed и перекрестные ссылки по нему, где это поле записывается)



поле Closed используется в индексах



предполагается, что:
= при большом количестве комбинаций складских аналитик (серийные номера, партии, ячейки) большинство записей в InventSum будет закрыто
= следовательно в выборку попадет относительно небольшое число активных (ненулевых) записей.

Поэтому: надо анализировать не общий объем таблицы InventSum, а число открытых записей в InventSum.

ЕСЛИ же у вас комбинаций аналитик так много И большинство записей в InventSum незакрыты, то у вас где-то нарушена логика работы Аксапты.

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

[pitersky]

Я в курсе про закрытые записи.
Но задача формулируется так "вывести отрицательные остатки на дату". Если мы будем обрабатывать только открытый InventSum, то из расчёта сразу выпадут разрезы, которые были закрыты из минуса после требуемой даты. А эта информация тоже (точнее - в первую очередь) нужна.
Кстати, в приведённом мной примере целевая дата была 01.07.2010. Это не так уж и давно.

[fed]

Я бы еще добавил, что при использовании inventSumDate() возникает некоторый накладняк (и довольно заметный) в связи с тем что на SQL Server отсылается много мелких запросов, каждый из которых отдельно разбирается и исполняется. Кроме того - по каждому из этих запросов случается трафик между SQL и AOS. В то же время если у тебя тупой запрос по inventTrans, то у тебя на сервер уходит один могучий запрос, потом сервер думает и сразу присылает данные на клиента крупным оптом, так сказать. Так что если у тебя сервер БД мощный, то тупое чтение с начала времен может запросто выиграть у хитроумных подходов со сбором данных из inventSum/inventTrans/inventSettlement/InventTransPosting. В сущности - 6 миллионов записей - это ведь порядка полутора гигабайт данных. Даже если у нас в кэше ничего нету - сколько времени с приличного дискового массива будут данные читаться ? Около минуты наверное... А если у тебя дисковые подсистемы на разных каналах висят и данные по этим каналам размазаны, то за счет параллельного чтения запросто можно и в секунд 15-20 уложиться...
К слову сказать - если в системе номера партий используются (а это правильное и вполне поддерживаемое создателями системы ее использование), то размерность inventSum и inventTrans может быть вполне сопоставимой...