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