Сводное планирование (собственная сортировка номенклатур)

[fed]

Я тут тоже подумал на эту тему и понял что просто сортировкой потребностей тут не обойдешся.
1. В стандарте - система сначала проверяет (по итогам создания чистых потребностей) - какие уровни вложености спецификаций у нас используются и затем идет по уровням.
2. Внутри уровня она бежит по номенклатурам (по моему - без специфичного порядка).
3. Внутри номенклатуры - по аналитикам (при этом грубо говоря, пополняемые склады должны обрабатываться до складов пополнения).
При этом распараллеливание идет на уровне номенклатуры. То есть - каждый хелпер берет свою номенклатуру и обрабатывает целиком - все аналитики. При завершении номенклатур очередного уровня вложености, хелпер ждет до тех пор, пока все другие хелперы не обработают этот уровень и только затем переходит к следующему уровню и номенклатурам следующего уровня. Наконец - надо помнить что существует механизм восстановления в случае неправильного уровня BOMLevel записанного в справочнике номенклатуры. Если система натыкается на следующем уровне вложености на номенклатуру которая была обработана на текущем или предыдущих уровнях, система помечает эту номенклатуру как номенклатуру с неправильным уровнем и перед обработкой номенклатур следующего уровня, удаляет плановые заказы на эту номенклатуру.
Поверх всего этого - тебе нужно будет для стадий покрытия и рассчета фьючерсов накрутить дополнительный цикл, обрабатывающий приоритеты один за одним.
1. Во первых - во все складские проводки по конечным потребностям (то есть - по заказам на продажу), тебе придется добавить в складские проводки уровень приоритета и затем протащить его в чистые потребности.
2. Во вторых при рассчете покрытия, надо будет присваивать приоритеты приходным проводкам. То есть - приоритет приходной чистой потребности равен максимальному из приоритетов расходных чистых потребностей, которые она покрывает.
3. Аналогично надо будет притаскивать приоритет в порожденные расходные чистые потребности по переносам, производственным заказам и тп.
4. Во все таблицы синхронизации между хелперами (все эти reqProcess*) надо будет писать не только уровень вложенности, но и уровень приоритета. Вся логика синхронизации должна будет обрабатывать и приоритет и уровень вложености. И да - как заметил S.Kuskov - это будет снижать производительность распараллеливания (хотя и не до нуля конечно). Просто если у вас, скажем, 10 разных уровней приоритета, число чистых потребностей, обрабатываемых в одном проходе будет раз в 7-8 меньше чем до разбиения по приоритетам.
5.Я пока не совсем понял что делать со стадией обработки действий. По моему она должна идти не по приоритетам, а просто так - как в старой версии.
А о недостатках этого подхода - в следующем сообщении.

[fed]

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

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

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

[Cardagant]

Спасибо вам за ответы и очень интересные и полезные мысли, S.Kuskov и fed!
Пока думаю как сделать лучше. Если будут ещё идеи, обязательно напишу сюда.