Приоритет проводок сводного планирования

[KiselevSA]

Доброго времени суток, коллеги.
На одном из проектов возникла потребность приоритезации сопоставления потребностей и покрытия. Понадеявшись на поле Priority в ReqTrans, копировали расчетное значение из прогноза спроса в прогноз запасов, но сводное планирование упорно, если посмотреть в развертывание, игнорирует при сопоставлении потребности и покрытия значение приоритета. Возникло ощущение, что покрытие из запасов в наличии "ищет" потребности в следующем порядке: потребность меньше остатка; код склада; приоритет.
В статье Дениса ( fed: Net requirements update in MRP Module and Working Set of MRP ) этот вопрос либо слегка обойден стороной, либо у меня глаза смотрят в книгу, а видят ... ничего не видят.
Как заставить AX сопоставлять потребности и покрытия с учетом приоритета без участия склада?
(Пысы. Во вложении постарался свести отдельные посты в теме в один документ)

[fed]

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

P.S. А какая у вас версия кстати ? В подних CU DAX2012 появилась настройка, позволяющая играть использованием складского запаса для покрытия незарезерированых чистых потребностей.

[KiselevSA]

Ну не совсем так: для запасов в наличии и закупок приоритет всегда нулевой, а вот для расходных операций в стандарте он всегда отрицательный и зависит от источника. Заказ на продажу - -1, складские журналы и перемещения - -2.

[fed]

Цитата:

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

Ну не совсем так: для запасов в наличии и закупок приоритет всегда нулевой, а вот для расходных операций в стандарте он всегда отрицательный и зависит от источника. Заказ на продажу - -1, складские журналы и перемещения - -2.

А как вообще должен приоритет на покрытие влиять ? Ну вот допустим у нас есть какое-то количество складских запасов, есть запланированные приходы с датами. Есть также запланированные расходы с датами и приоритетами. Как приоритет должен комбинироваться с датами при рассчете покрытия ? Например - у меня есть суперприоритетная продажа в начале мая и низкоприоритетная, но послезавтра. Есть складские запасы, есть плановый приход завтра, есть плановый приход в конце апреля. Какая продажа чем должна быть покрыта в подобной конфигурации ?

[KiselevSA]

В моем случае задача немного другая: есть план продаж на одну дату по куче складов (розничные точки), приоритет по строке плана рассчитывается по определенным алгоритмам (ABC-классификация по продажам, сроки доставки, ну и т.п.). Потом план утверждается и превращается в прогноз спроса с переносом приоритета из плана продаж в прогноз. Сводник копирует приоритет из строки прогноза спроса в ReqTrans. Задача: при связывании проводки покрытия из той же ReqTrans с потребностью при равенстве дат в первую очередь обрабатывать проводки с наивысшим приоритетом (меньшим значением Priority, хелп: Приоритет проводки: более низкий номер соответствует более высокому приоритету))

[fed]

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

[KiselevSA]

С приходными проводками, скорее всего, тоже есть обработка приоритетов. Я не включал в настройке сводного планирования признаки учета предложений по покупкам и продажам, но, я думаю, они как раз и будут иметь приоритеты, отличающиеся от текущих. В текущих реалиях покрытие в первую очередь обрабатывает складские операции, запланированные продажи с учетом плановой даты, а потом предложения по продажам и прогнозы спроса. Так вот хотелось бы, чтобы внутри сущности "Прогноз спроса" на определенную дату, в первую очередь обрабатывались операции с наивысшим приоритетом (меньшим значением приоритета).
Т.е., например (предположим на всех складах остатки 0):
прогноз спроса на складе A - 8 штук, приоритет прогноза 1234;
прогноз спроса на складе B - 6 штук, приоритет прогноза 1121;
прогноз спроса на складе С - 12 штук, приоритет прогноза 1113.
На главном складе 10 штук.
Запуск сводного планирования:
Спланированное перемещение на склад A - 8 штук;
Спланированное перемещение на склад В - 6 штук;
Спланированное перемещение на склад С - 12 штук.
Сопоставление потребности и покрытия:
1. Сортируем по приоритету по возрастанию (С, В, А);
2. Покрытие С: недостаточно в наличии, планируем закупку на разницу между общей потребностью и запасом в наличии;
3. Покрытие В: покрываем запасом в наличии;
4. Покрытие A: покрываем остатком в наличии и закупкой (т.е. если остатка оказалось бы больше потребности, то надо было бы остаток в наличии связать с потребностью С).
Схема, конечно, не совсем тривиальная, но позволяет автоматизировать предварительное утверждение спланированных заказов, у которых последней записью в развертывании является "В наличии".
Это избавит логистов от ручной приоритезации перемещений и, при правильной настройке группировки по датам, позволит одним махом утвердить спланированные перемещения с созданием заказов, отфильтровав записи с предварительным утверждением. Такие записи, кстати, не "пересоздаются" в результате повторного вызова сводного планирования.

[fed]

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

[KiselevSA]

Заставить хотя бы приоритет учитывать, об остальном я пока не мечтаю. Сейчас не удается пока понять последовательность заполнения ReqTransCov. Есть предположение, что надо покопаться в логике ReqCalc.reqTransCoverage2SortKey(). Но тут моих навыков в программировании явно не хватит ("а вот нефига консультанту лазить в чужой огород" )

[KiselevSA]

Небольшие замечания по результатам исследования приоритезации сводного планирования:
1. При формировании рабочего набора класс расчета использует set по InventDim, который автоматически сортирует набор по InventDimId. Таким образом, в первую очередь обрабатываются самые "старые" склады при равенстве даты потребности;
2. Приоритет отрабатывает только в пределах склада. Чтобы сортировка сработала правильно с учетом знака, к фактическому приоритету добавляется магическая константа 50, и полученный суммарный приоритет преобразуется в строку с минимальной длиной 3 символа с дополнением ведущими нулями. Т.е., если собираетесь автоматически рассчитывать значение приоритета для проводок прогноза запасов, не забудьте расширить длину макроса numLength в методе ReqCalc::reqTransCoverage2SortKey() до МаксРанг+1.

ПыСы: Пытка системы апельсинами продолжается ....