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