23.09.2013, 10:59 | #1 |
Участник
|
Сводное планирование (собственная сортировка номенклатур)
Всем доброго дня!
Хочу попросить совета у людей, которые разбирались в функциональности сводного планирования. Знаю, что Сводное планирование, запущенное по всем номенклатурным единицам из Периодических операций производит "сортировку" номеклатур по уровням в Set'ы, ну в а Set'ах уже сортировка происходит по номенклатурам. Ограничимся Планированием из Периодических операций. Задача в следующем: следует в определённом пользователем порядке загружать мощности рабочих центров. К примеру, для упрощения понимания задачи, пусть поле "Приоритет загрузки" будет находиться для каждой проводки в отдельном числовом поле InventTrans. При этом сохранить разбивку по уровням, то есть сортировку произвести непосредственно в Set'ах уровней. Думая об этом, пришёл к выводу, что могу в классе ReqTransCache_Periodic изменить Set'ы из стринговых в контейнерные, где первым элементом добавлять именно тот самый приоритет загрузки, конечно, модифицировав работу с новым типом Value Set'a. При этом дополнительно на этапе инициализации выбрать это поле из InvenTrans. Также 2 проводки с одной и той же номенклатурой смогут иметь разное значение в поле приоритетности и будут обработаны в разной очерёдности. Смогу ли я зацепить что-то важное, реализуя такое решение? Или это можно сделать лучшим альтернативным способом! Буду рад любым советам! DAX 2009 Благодарю! |
|
23.09.2013, 11:30 | #2 |
Аманд
|
Группа задач не подходит?
|
|
23.09.2013, 11:38 | #3 |
Участник
|
Если Вы имеете ввиду группу задач, которая располагается в маршрутах и рабочих центрах, то не совсем понимаю как это поможет мне изменить номенклатурный приоритет при загрузке мощности.
Дополню предыдущее сообщение. При этом я понимаю, что нужно сохранять "приоритет" для номенклатур, которые являются результатом раскрытия Спланированных производственных заказов. |
|
23.09.2013, 11:45 | #4 |
Moderator
|
Внутри одного BOMLevel, номенклатуру можно планировать в произвольном порядке. Внутри одной номенклатуры, система сортирует inventDimId (в методе ReqTransCache.listCovDimSorted() и классе reqAnalyzer), так чтобы потребности на обычных складах обрабатывались ДО потребностей на складах пополнения. Если вы в эту последовательность вклинетесь - будет плохо.
Внутри данного itemId+InventDimid - можно в любом порядке потребности сортировать. (Я не до конца уверен - но процентов на 95). В худшем случае, кроме загрузки мощностей у вас еще и текущие запасы раздербаняться на покрытие более приоритетных заказов, а не на более ранних. Рискну предположить - что это позитивный побочный эффект. Правда тут другая проблема возникнет - если у вас суперприоритетный заказ, у которого 9 из 10 компонент на складе, а 1 не будет до декабря месяца, то в таком случае все складские запасы будут прикреплены к производственному заказу, который реально только в декабре стартует. Не самое криминальное конечно, но оборачиваемость малость просадит. Кроме того - можно подумать чтобы приоритеты наследовались из покрываемых потребностей в покрывающие и, соответственно, в их зависимые потребности. В общем - резюме - можно попробовать, но надо быть готовым интерпретировать 'странные результаты' планирования... Последний раз редактировалось fed; 23.09.2013 в 12:13. |
|
|
За это сообщение автора поблагодарили: gl00mie (5), Cardagant (1). |
23.09.2013, 12:24 | #5 |
Участник
|
Спасибо за Ваше мнение, fed.
Цитата:
Цитата:
Но также в принципе возможна следующая ситуация, когда в InventTrans имеется несколько проводок одной номенклатуры и что-то вроде следующей последовательности отрицательных потребностей: Приоритет 1 - Номенклатура 1 Аналитика 1 - 1 шт. Приоритет 2 - Номенклатура 2 Аналитика 2 - 2 шт. ... Приоритет 100 - Номенклатура 1 Аналитика 1 - 5 шт. ... Тогда и правда стоит задуматься о наследовании приоритетов в потребностях. При этом получается следует 2 раза спланировать покрыв 2 отрицательные потребности, разделив их обработку на 2 разных этапа. Допустимо ли это с точки зрения текущей реализации? |
|
23.09.2013, 12:39 | #6 |
Moderator
|
Вам надо разделить понятие приоритетов номенклатуры и приоритетов проводки (ну или потребности). Приоритеты номенклатуры хранятся в inventTable и определяют, какие номенклатуры с данным BOMLevel планируются раньше, а какие - позже. Приоритет проводки (потребности) копируется из inventTrans в reqTrans и определяет какие потребности (в рамках данной номенклатуры и данной комбинаций аналитик покрытия) покрываются раньше, а какие - позже.
Соответственно - протаскивать приоритеты из покрываемых потребностей в покрывающие и порожденные зависимые потребности - можно только для приоритетов проводок (потребностей). Последний раз редактировалось fed; 23.09.2013 в 12:44. |
|
23.09.2013, 12:47 | #7 |
Участник
|
Цитата:
Сообщение от fed
Вам надо разделить понятие приоритетов номенклатуры и приоритетов проводки (ну или потребности). Приоритеты номенклатуры хранятся в inventTable и определяют, какие номенклатуры с данным BOMLevel планируются раньше, а какие - позже. Приоритет проводки (потребности) копируется из inventTrans в reqTrans и определяет какие потребности (в рамках данной номенклатуры и данной комбинаций аналитик покрытия) покрываются раньше, а какие - позже.
Соответственно - протаскивать приоритеты из покрываемых потребностей в покрывающие и порожденные зависимые потребности - можно только для приоритетов проводок (потребностей). |
|
23.09.2013, 12:53 | #8 |
Аманд
|
Кстати, чем вызвана такая задача? Что производится?
|
|
31.01.2014, 12:45 | #9 |
Участник
|
Цитата:
Сообщение от fed
Вам надо разделить понятие приоритетов номенклатуры и приоритетов проводки (ну или потребности). Приоритеты номенклатуры хранятся в inventTable и определяют, какие номенклатуры с данным BOMLevel планируются раньше, а какие - позже. Приоритет проводки (потребности) копируется из inventTrans в reqTrans и определяет какие потребности (в рамках данной номенклатуры и данной комбинаций аналитик покрытия) покрываются раньше, а какие - позже.
Соответственно - протаскивать приоритеты из покрываемых потребностей в покрывающие и порожденные зависимые потребности - можно только для приоритетов проводок (потребностей). Итак, имеется список номенклатур для планирования и остальные параметры, необходимые для создания отрицательных чистых потребностей, в некоторой таблице Пользователь задаёт список номенклатур, заполняет сопутствующие поля, а также задаёт приоритетность номенклатур для планирования (некоторое целочисленное поле) и загрузки в этой последовательности номенклатур рабочих центров. Далее, согласно заданному списку, требуется создать отрицательные чистые потребности, которые будут "разделены" приоритетностью, то есть возможна следующая ситация, приводимая уже ниже Приоритет 1 - Номенклатура 1 Аналитика 1 - 1 шт. Приоритет 2 - Номенклатура 2 Аналитика 2 - 2 шт. ... Приоритет 3- Номенклатура 1 Аналитика 1 - 5 шт. При этом, планирование Номенклатуры 1 следует производить первый раз, согласно приоритетности 1, второй раз согласно приоритетности 3 после планирования приоритетности 2 с номенклатурой 2, а не разом в рамках одной номенклатуры 1 (Приоритетность 1, потом приоритетность 3, потом приоритетность 2). (при условии, что все номенклатуры имеют одинаковый BOMLevel) Есть идея преобразовать тип данных сетов уровней в контейнеры, где первым значением контейнера вносить именно это значение приоритетности для "сортировки", далее притянуть эти приоритетности в таблицу ReqProcessItemListLine, также, модифицировать класс ReqTransCache_Periodic для возможностей работы с контейнерами и корректного получение номекнлатуры каждой новой итерации. Также, следует добавить это поле в ReqTrans, чтобы работать только с потребностями данной "сессии приоритетности". Вполне вероятно, что список объектов для модификации расширится при её реализации и более подробном разборе. Как-то всё в этом решении слишком сложно на мой взгляд и очень легко что-то упустить/пропустить. Может из-за недостаточных знаний о модуле упускаю более простое решение? Буду рад любым мыслям. Спасибо! Последний раз редактировалось Cardagant; 31.01.2014 в 12:54. |
|
31.01.2014, 12:47 | #10 |
Участник
|
|
|
31.01.2014, 13:43 | #11 |
Участник
|
Возможно будет проще автоматизировать последовательный запуск расчета нескольких планов. В каждом плане по одному приоритету. По моему можно придумать что-нибудь, что бы каждый следующий план не удалял результаты предыдущего, а учитывал их и планировал поверх.
|
|
31.01.2014, 14:51 | #12 |
Участник
|
Да, это хорошая идея. Но при планировании из Периодических операций хотелось бы использовать возможности многопоточности. Насколько я понимаю, в данном варианте, преимущества многопоточности теряются.
|
|
31.01.2014, 15:21 | #13 |
Участник
|
В общем случае с указанными ограничениями на изоляцию приоритетов многопоточность не применить. Я же правильно понял что для удовлетворения условий задачи пока не будут покрыты все уровни первого приоритета, второй уровень покрывать нельзя? Иначе в общем случае на каком-нибудь уровне могут встретиться общие с другим приоритетом потребности. Внутри одного приоритета - распараллеливайте на здоровье.
|
|
31.01.2014, 15:57 | #14 |
Участник
|
Цитата:
Сообщение от S.Kuskov
В общем случае с указанными ограничениями на изоляцию приоритетов многопоточность не применить. Я же правильно понял что для удовлетворения условий задачи пока не будут покрыты все уровни первого приоритета, второй уровень покрывать нельзя? Иначе в общем случае на каком-нибудь уровне могут встретиться общие с другим приоритетом потребности. Внутри одного приоритета - распараллеливайте на здоровье.
То есть, если я правильно понимаю, Ваш вариант предполагает некий последовательный запуск Периодического сводного для каждой отдельной Приоритетности/номенклатуры и использование распараллеливания в контексте дерева для каждой отдельной приоритетности? |
|
31.01.2014, 16:19 | #15 |
Banned
|
Подсмотрите, как это сделано в Ax2012 R2 и скопируйте логику.
|
|
31.01.2014, 16:44 | #16 |
Участник
|
|
|
31.01.2014, 16:56 | #17 |
Участник
|
У вас одна и та же входящая номенклатура может присутствовать на разных уровнях? Если сначала сортировать по уровням, а только потом по приоритетам, то может возникнуть ситуация при которой менее приоритетная потребность у которой уровень меньше будет покрыта раньше более приоритетной потребности с большим уровнем. Вас это устраивает?
|
|
31.01.2014, 18:21 | #18 |
Участник
|
Цитата:
Сообщение от S.Kuskov
У вас одна и та же входящая номенклатура может присутствовать на разных уровнях? Если сначала сортировать по уровням, а только потом по приоритетам, то может возникнуть ситуация при которой менее приоритетная потребность у которой уровень меньше будет покрыта раньше более приоритетной потребности с большим уровнем. Вас это устраивает?
По специфике построения наших спецификаций это может быть крайне редко, но всё же может быть. Вы правы. Я, конечно, посмотрю подробнее, но мне казалось, что распределение по уровням делалось на основе поля BOMLevel Номеклатурника. Точно видел это для номенклатур "исходного набора", но не помню на основе какой информации об уровнях помещаются в мэп уровней номенклатуры вновь раскрываемых уровней (не уж то currentLevel + 1). Последний раз редактировалось Cardagant; 31.01.2014 в 19:02. |
|
31.01.2014, 20:54 | #19 |
Участник
|
Цитата:
Сообщение от Cardagant
Я, конечно, посмотрю подробнее, но мне казалось, что распределение по уровням делалось на основе поля BOMLevel Номеклатурника. Точно видел это для номенклатур "исходного набора", но не помню на основе какой информации об уровнях помещаются в мэп уровней номенклатуры вновь раскрываемых уровней (не уж то currentLevel + 1).
|
|
31.01.2014, 21:00 | #20 |
Участник
|
Возвращаясь к многопоточности, у меня все равно устойчивое ощущение что необходимость последовательной обработки приоритетов не позволит распараллелить потребности одного уровня больше чем одного приоритета. Абсолютно такое же распараллеливание будет при использовании варианта, предложенного мной.
Обсчитывать одновременно потребности нескольких приоритетов можно только для не конкурирующих друг с другом потребностей. Т.е. выигрыш от распараллеливания можно получить если сначала в разрезе приоритетов рассчитать пересекающиеся потребности, а оставшиеся максимально распараллелить. Стоит ли оно того в вашем случае? |
|
|
За это сообщение автора поблагодарили: Cardagant (1). |
Теги |
сводное планирование, чистые потребности |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|