[fed]

Во первых - хочу заметить, что из за планирования по приоритетам, у вас будут весьма неоптимально закупаться и производится материалы. Есть сильное подозрение что у вас для многих дешевых материалов стоит вид потребности "Период" и их закупают или производят раз в месяц. При планировании по приоритетам - у вас таких производств/закупок будет запланировано в n-раз больше чем при старом подходе. Конечно стадия обработки действий (если ее запускать не по уровням) нагенерит действий по объединению подобных закупок и производств, но ведь их потом придется ведь ручками объединять.

Во вторых - давайте посмотрим - как сводное работает в реальной жизни:
1. При обработке конечных потребностей по заказам, система генерирует плановые производственные заказы. При этом планируются производственные мощности, но система совершенно не думает о том (по крайней мере для строк типа "номенклатура") о том как будут покрыты эти заказы. Она просто планирует их, заботясь о том чтобы мощностей рабочих центров хватило бы на выполнение операций.
2. Затем система порождает новые зависимые потребности, покрывает их, создает плановые производственные заказы (на все более раннюю дату), и тп. При этом, поскольку сейлы всегда хотят больше чем производство может, рано или поздно это планирование упирается в текущую дату. При этом - система помечает всю цепочку покрытия как фьючерс и продолжает планировать назад в прошлое.
3. В итоге - при рассчете фьючерсов, система находит все заказы в прошлом, планирует их вперех от текущей даты и перепланирует вперед все заказы, которые от этих заказов зависят.
В итоге - типичный результат планирования состоит в том, что у тебя есть куча просроченных заказов в будущем и на текущей неделе у тебя есть куча свободных производственных ресурсов. (Они были заняты в момент рассчета покрытия, но затем рассчет фьючерсов все эти приоритетные заказы отодвинул в будущее.) В итоге - если ты ручками поправишь дату доставки у каких-то плановых производственных заказов на более раннюю, вполне возможно что этот плановый заказ замечательно перепланируется на текущую неделю, занимая освободившиеся мощности.

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