Расчет резервного запаса – бага?

[Starling]

По-моему в алгоритме расчета резервного запаса есть серьезная бага. И если я прав, то вообще не понятно как им можно пользоваться.
Для расчёта статистики, на основании которой затем считается уровень минимального запаса, формируется запрос типа:

SELECT WITH SELECT_ORDER, NESTED_LOOP, FORCE_PLACEHOLDERS INDEXISHINT SUM(Qty), MAX(DatePhysical) 
FROM InventTrans GROUP BY InventTrans.ItemId ASC USING INDEX ItemIdx  
WHERE ((DatePhysical>=01.01.2012 AND DatePhysical<=30.06.2012)) AND ((StatusReceipt = 0)) AND ((StatusIssue>= AND StatusIssue<=)) AND 
((InvoiceReturned = )) AND ((PackingSlipReturned = )) 
JOIN INDEXISHINT * FROM InventDim GROUP BY InventDim.configId ASC, InventDim.InventSizeId ASC, InventDim.InventColorId ASC USING INDEX DimIdIdx
 WHERE InventTrans.inventDimId = InventDim.inventDimId

Т.е. система выбирает все списания за указанный период в разрезе номенклатуры и аналитик, входящих в план покрытия.
Как по мне мы должны исключать из этого запроса переносы, которые не меняют аналитику из плана покрытия. Но этого не происходит.
Т.е. если у вас склад в план покрытия не входит, а вы перемещаете номенклатуру со склада производства на склад продаж, то статистика потребностей будет завышена в два раза.
См. метод newQueryInventTransIssue класса ReqItemJournalCreate
З.Ы.: наткнулся я на это в 3-ке. Судя по коду в DAX2009 тоже самое. Позже проверю еще и DAX2012.

[Ivanhoe]

При этом у вас планирование в разрезе складов? Почему в запросе нет фильтра по складу?

[Starling]

Цитата:

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

При этом у вас планирование в разрезе складов? Почему в запросе нет фильтра по складу?

В том то и дело, что нет.
Склад не входит в план покрытия. Но списания, которые порождаются проводками списания по журналу переноса между складами, попадают в этот запрос и увеличивают количество списаний.
Пример:
Исходные данные:
1. Ном_1
2. Аналитики

a. Конфигурация. План покрытия = Да.
b. Цвет. План покрытия = Да.
c. Размер. План покрытия = Да.
d. Склад. План покрытия = Нет.

3. Операции:

a. Закупка

i. Ном_1 Кон_1 Цв_1 Раз_1 Скл_1 + 10

b. Перенос

i. Ном_1 Кон_1 Цв_1 Раз_1 Скл_1 – 10
ii. Ном_1 Кон_1 Цв_1 Раз_1 Скл_2 + 10

c. Продажа:

i. Ном_1 Кон_1 Цв_1 Раз_1 Скл_2 - 10

4. Журнал резервного запаса посчитает, что по данному набору операций статистика следующая:

a. Ном_1 Кон_1 Цв_1 Раз_1 в количестве 20! Хотя правильно 10.

[Ivanhoe]

Честно говоря, трудно представляю себе вашу задачу (без покрытия по складам). Вполне возможно, что такой сценарий не предусматривался для этой функциональности.

[Starling]

Цитата:

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

Честно говоря, трудно представляю себе вашу задачу (без покрытия по складам).

Да не вопрос пусть склад входит в план покрытия, а перенос будет между ячейками одного склада. Результат будет такой же - 20.
Я надеюсь включать план покрытия по ячейкам вы предлагать не будете? Хотя и по поводу склада можно было бы поспорить.

Цитата:

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

Вполне возможно, что такой сценарий не предусматривался для этой функциональности.

Т.е. сценарий, когда в системе регистрируется перемещение между аналитиками, не входящими в план покрытия не предусматривался разработчиками, данной функциональности.
Бага – это. Непонятно только почему ее не исправили от 3-ки до 2009.

[Ivanhoe]

Под рукой только 2009. Смотрим указанный вами метод:

Цитата:

/// <summary>
/// Makes a query in order to find used coverage dimensions for an item.

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

В классе есть отдельный метод calcDemandPeriod() в котором следующие комменты:

Цитата:

/// Demand is calculated as issues in the specified period. However not all issues should be included in the calculation.
/// Issues having a corresponding receipt on the same coverage dimension should not be included.
...
// find demand - internal transfers must not count as demand
// internal transfer means that the issue and receipt has same coverage dimensions.
// if warehouse isn't a coverage dimension then don't count transfer orders as demand

Ну и в методе соответствующий запрос, который считает статистику.

[Starling]

Упс... не доглядел. Похоже в 2009 таки исправили.

В 3-ке метода calcDemandPeriod нет вообще.
Спасибо.

[Starling]

Эта же проблема с журналами переноса, но в другом месте.
При просмотре данных в форме «Чистые потребности», в ней отображается информация по строкам журнала переноса, которые не меняют аналитику из плана покрытия. Похоже (при корректных данных) это не влияет на результаты планирования, но значительно усложняет анализ информации в этой форме, так как одна строка журнала переноса сначала отображается с «+» потом с «-». Итог в течение дня не меняется, но данный эти пользователь видит и вынужден как-то их фильтровать.
Я проверял в версии AX2009 ситуация не изменилась.
Пример:
1. Есть номенклатура со следующими аналитиками:

a. Сайт. План покрытия = Да.
b. Склад. План покрытия = Нет.

2. Остатки:

a. 10 штук Сайт = 1, Склад 11.

3. Потребность (пусть прогноз продаж):

a. -20 Сайт 1

4. Не разнесенный журнал переноса:

a. -5 штук, с Сайт1, Склад 11, на Сайт1, Склад 12

5. Запускаю сводное – получаю результат – спланированная закупка на 10 штук на сайте 1.
6. Смотрю форму чистые потребности по Сайт 1 и вижу:

a. В наличии + 10
b. Журнал переноса + 5
c. Спланированная закупка + 10
d. Журнал переноса – 5
e. Прогноз продаж – 20.

7. Хотелось бы видеть:

a. В наличии + 10
b. Спланированная закупка + 10
c. Прогноз продаж – 20.

Может кто-то модифицировал функционал в этой части? На сколько это вообще реально?

[Starling]

В 2012 уже исправлено. Но вопрос актуальный. На сколько сложно это перенести на AX30?

[S.Kuskov]

RecCalc.insertInventTrans()

В этом методе происходит формирование первичных данных в "Чистых потребностях" из неразнесённых складских проводок. Если исключать "внутренние" переносы из анализа, то наверное здесь.

[Starling]

Цитата:

Сообщение от S.Kuskov

RecCalc.insertInventTrans()

В этом методе происходит формирование первичных данных в "Чистых потребностях" из неразнесённых складских проводок. Если исключать "внутренние" переносы из анализа, то наверное здесь.

Я вот тоже об этом думаю. Но похоже этого недостаточно. Если используется динамический сводный план, то данные в ReqTrans попадают минуя этот метод. Также насколько я понимаю из этой статьи от fed в зависимости от способа вызова планирования могут также работать разные классы.
Ладно будем рыть.

[S.Kuskov]

Цитата:

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

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

Все эти классы являются наследниками ReqCalc, так что метод всё равно должен сработать