Обновление динамического плана в режиме Накопленные изменения(Net Change)
В режиме Накопленные изменения/Минимальные изменения (кстати отмечу неудачность русского перевода терминов Net Change/Net Change Minimized), фаза Обновления плана выполняется совершенно другим образом. Попросту говоря, это последовательность
Динамических обновлений для всей номенклатуры из
Набора сессии. Система пробегается по всем номенклатурам из
Набора сессии и для каждой номенклатуры вызывается обычный класс обновления чистых потребностей (reqTransUpdate), который собственно и переносит в чистые потребности накопленную информацию об изменениях, хранящуюся в таблице inventSumLogTTS. В результате этого обновления, часть чистых потребностей удаляется, часть - создается, для у части чистых потребностей изменяется количество или другие релевантные поля. Затем, во время фазы рассчета покрытия, система пробегается по всем непокрытым отрицательным чистым потребностям в
Рабочем множестве. Как и в режиме регенерации динамического плана, система, перед рассчетом покрытия по каждой номенклатуре, запускает стандартную процедуру
Динамического обновления. Таким образом, даже для номенклатур не входящих в
Набор сессии данные чистых потребностей актуализуются в соответствии с текущим состоянием складских проводок.
С точки зрения фазы обновления чистых потребностей, хочу отметить два отличия между режимами Накопленных изменений и Минимальных изменений:
- В Режиме минимальных изменений,система включает в Начальный Рабочий Набор только те отрицательные чистые потребности, которые были помечены как непокрытые. Поскольку после пересчета плана в режиме регенерации, ни одна чистая потребность не может остаться не покрытой, технически Начальный Рабочий Набор состоит только из чистых потребностей обновленных на стадии Обновления. Поскольку во время фазы обновления, положительные чистые потребности не включаются в Начальный рабочий набор последующие стадии рассчета фьючерсов и действий работают только с чистыми потребностями, которые действительно были задействованы на стадии покрытия (в случае Номенклатурного MRP) или со всеми чистыми потребностями, имеющими ту же номенклатуру и аналитику что и одна из чистых потребностей задействованных на стадии покрытия (в случае Полного MRP.
- В режиме Накопленных изменений, система включает в в Начальный Рабочий Набор все чистые потребности для всех номенклатур из Набора сессии.Кроме того, система удаляет из плана всю информацию о действиях (количество и дату действия в таблицах чистых потребностей и покрытия) для всех чистых потребностей в Начальном Рабочем Наборе.Как результат, на фазе рассчета действий, система обрабатывает все чистые потребности из номенклатуры в Наборе сессии.(Включение в Начальный рабочий набор всех чистых потребностей никак не влияет на работу стадии покрытия, поскольку рассчет покрытия попросту игнорирует все уже покрытые чистые потребности).
Коротко говоря, режим Накопленных изменений/Минимальных изменений это самый быстрый способ привести сводный план в соответствие с текущим состоянием дел. Но как это обычно и бывает, за высокую скорость обновления плана приходится расплачиватьcя. Зачастую, в режиме Накопленых изменений, система генерирует неоптимальный план. (Я имею в виде - даже более неоптимальный чем результаты планирования в режиме регенерации для части номенклатуры.)
Допустим у нас на складе есть 80 штук некой номенклатуры, а также имеется заказ на продажу 50 штук этой же номенклатуры с датой доставки из далекого будущего (Допустим - через 6 месяцев). Регулярное ночное сводное планирование, создало запись о покрытии между двумя соответствующими чистыми потребностями. Потребность заказа на продажу полностью покрыта запасами в наличии, в то же время у чистой потребности запасов в наличии осталось неиспользованных 30 штук. Эти 30 штук могут быть использованы для того чтобы в будущем покрыть что-то еще.Предположим что на следующее утро пришел клиент и попросил срочно отгрузить ему 70 штук нашей номенклатуры. Здравый смысл подсказывает нам, что мы должны покрыть этот заказ номенклатурой в наличии, а для оставшихся непокрытыми 40 штук несрочного заказа создать плановый заказ эдак за пару дней до планирующейся даты отгрузки этого несрочного заказа.
Вместо этого, планирование в режиме Накопленных изменений использует для покрытия срочного заказа только те 30 штук из запаса в наличии, которые остались свободными после ночного перепланирования 30 штук из номенклатуры в наличии, а для недостающих 40 штук оно создаст срочный плановый заказ с сегодняшней датой исполнения.
Это происходит, поскольку планирование в режиме Накопленых обновлений/Минимальных обновлений никогда не трогает те чистые потребности, у которых не было изменены соответствующие складские проводки. На фазе обновления, система создает новую чистую потребность на 70 штук с завтрашней датой. Система не может 'Освободить' чистую потребность 'В наличии', для срочного заказа, поскольку она не может модифицировать эту чистую потребность ! Во время фазы покрытия, система создает запись покрытия на 30 штук между новым заказом и запасами в наличии (чистая потребность которых не была модифицирована
Динамическим обновлением), а затем, для покрытия оставшихся 40 штук, система порождает новый спланированный заказ.
Единственный способ исправить эту ситуации - это запуск сводного в режиме регенерации для данной номенклатуры и для всех субкомпонентов данной номенклатуры (или вообще для всех номенклатур в системе).Если мы запустим регенерацию только для данной номенклатуры, то с чистыми потребностями по самой номенклатуре все будет хорошо. Однако же если данная номенклатура - это спецификация с субкомпонентами, это означает что для субкомпонентов чистые потребности не будут удалены и перегенерированы с ноля и точно такая же проблема может возникнуть на следующих уровнях вложености.
Я слегка удивлен что стандартная версия Dynamics AX не поддерживает некого специального режима "Регенерации развертывания", который бы получал на входе номенклатуру или маску номенклатуры, а затем бы строил
НАЧАЛЬНЫЙ рабочий набор из указанных номенклатур и всех их субкомпонентов.Я реализовал подобную функциональность для пары проектов; Она работает заметно быстрее чем полная регенерация плана (для всех номенклатур) и заметно медленнее чем стандартное развертывание.(Которое работает на другом наборе принципов и является частным случаем режима Минимальных обновлений).К слову сказать, это расширение стандарта MRP также исправляет проблему некорректного планирования для режима покрытия Период, о котором я писал в позапрошлом разделе.