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

[Cardagant]

Всем доброго дня!
Хочу попросить совета у людей, которые разбирались в функциональности сводного планирования.

Знаю, что Сводное планирование, запущенное по всем номенклатурным единицам из Периодических операций производит "сортировку" номеклатур по уровням в Set'ы, ну в а Set'ах уже сортировка происходит по номенклатурам. Ограничимся Планированием из Периодических операций.

Задача в следующем: следует в определённом пользователем порядке загружать мощности рабочих центров. К примеру, для упрощения понимания задачи, пусть поле "Приоритет загрузки" будет находиться для каждой проводки в отдельном числовом поле InventTrans. При этом сохранить разбивку по уровням, то есть сортировку произвести непосредственно в Set'ах уровней.

Думая об этом, пришёл к выводу, что могу в классе ReqTransCache_Periodic изменить Set'ы из стринговых в контейнерные, где первым элементом добавлять именно тот самый приоритет загрузки, конечно, модифицировав работу с новым типом Value Set'a. При этом дополнительно на этапе инициализации выбрать это поле из InvenTrans.
Также 2 проводки с одной и той же номенклатурой смогут иметь разное значение в поле приоритетности и будут обработаны в разной очерёдности.

Смогу ли я зацепить что-то важное, реализуя такое решение? Или это можно сделать лучшим альтернативным способом! Буду рад любым советам!

DAX 2009

Благодарю!

[Vals]

Группа задач не подходит?

[Cardagant]

Если Вы имеете ввиду группу задач, которая располагается в маршрутах и рабочих центрах, то не совсем понимаю как это поможет мне изменить номенклатурный приоритет при загрузке мощности.

Дополню предыдущее сообщение.
При этом я понимаю, что нужно сохранять "приоритет" для номенклатур, которые являются результатом раскрытия Спланированных производственных заказов.

[fed]

Внутри одного BOMLevel, номенклатуру можно планировать в произвольном порядке. Внутри одной номенклатуры, система сортирует inventDimId (в методе ReqTransCache.listCovDimSorted() и классе reqAnalyzer), так чтобы потребности на обычных складах обрабатывались ДО потребностей на складах пополнения. Если вы в эту последовательность вклинетесь - будет плохо.

Внутри данного itemId+InventDimid - можно в любом порядке потребности сортировать. (Я не до конца уверен - но процентов на 95). В худшем случае, кроме загрузки мощностей у вас еще и текущие запасы раздербаняться на покрытие более приоритетных заказов, а не на более ранних. Рискну предположить - что это позитивный побочный эффект. Правда тут другая проблема возникнет - если у вас суперприоритетный заказ, у которого 9 из 10 компонент на складе, а 1 не будет до декабря месяца, то в таком случае все складские запасы будут прикреплены к производственному заказу, который реально только в декабре стартует. Не самое криминальное конечно, но оборачиваемость малость просадит. Кроме того - можно подумать чтобы приоритеты наследовались из покрываемых потребностей в покрывающие и, соответственно, в их зависимые потребности. В общем - резюме - можно попробовать, но надо быть готовым интерпретировать 'странные результаты' планирования...

[Cardagant]

Спасибо за Ваше мнение, fed.

Цитата:

Сообщение от fed

В худшем случае, кроме загрузки мощностей у вас еще и текущие запасы раздербаняться покрытие более приоритетных заказы, а не на более ранних. Рискну предположить - что это позитивный побочный эффект.

Да, думаю это будет положительным побочным эффектом.

Цитата:

Сообщение от fed

Кроме того - можно подумать чтобы приоритеты наследовались из покрываемых потребностей в покрывающие и, соответственно, в их зависимые потребности.

Да, я также думал об этом, это хорошая идея!

Но также в принципе возможна следующая ситуация, когда в InventTrans имеется несколько проводок одной номенклатуры и что-то вроде следующей последовательности отрицательных потребностей:

Приоритет 1 - Номенклатура 1 Аналитика 1 - 1 шт.
Приоритет 2 - Номенклатура 2 Аналитика 2 - 2 шт.
...
Приоритет 100 - Номенклатура 1 Аналитика 1 - 5 шт.
...

Тогда и правда стоит задуматься о наследовании приоритетов в потребностях. При этом получается следует 2 раза спланировать

Цитата:

Сообщение от fed

itemId+InventDimid

покрыв 2 отрицательные потребности, разделив их обработку на 2 разных этапа.
Допустимо ли это с точки зрения текущей реализации?

[fed]

Вам надо разделить понятие приоритетов номенклатуры и приоритетов проводки (ну или потребности). Приоритеты номенклатуры хранятся в inventTable и определяют, какие номенклатуры с данным BOMLevel планируются раньше, а какие - позже. Приоритет проводки (потребности) копируется из inventTrans в reqTrans и определяет какие потребности (в рамках данной номенклатуры и данной комбинаций аналитик покрытия) покрываются раньше, а какие - позже.
Соответственно - протаскивать приоритеты из покрываемых потребностей в покрывающие и порожденные зависимые потребности - можно только для приоритетов проводок (потребностей).

[Cardagant]

Цитата:

Сообщение от fed

Вам надо разделить понятие приоритетов номенклатуры и приоритетов проводки (ну или потребности). Приоритеты номенклатуры хранятся в inventTable и определяют, какие номенклатуры с данным BOMLevel планируются раньше, а какие - позже. Приоритет проводки (потребности) копируется из inventTrans в reqTrans и определяет какие потребности (в рамках данной номенклатуры и данной комбинаций аналитик покрытия) покрываются раньше, а какие - позже.
Соответственно - протаскивать приоритеты из покрываемых потребностей в покрывающие и порожденные зависимые потребности - можно только для приоритетов проводок (потребностей).

Имел ввиду именно приоритет проводки. Буду пробовать реализовать такое решение данной задачи! Благодарю за ответы.

[Vals]

Кстати, чем вызвана такая задача? Что производится?

[Cardagant]

Цитата:

Сообщение от 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]

Цитата:

Сообщение от Vals

Кстати, чем вызвана такая задача? Что производится?

Крупное позаказное производство.
Требуется изменять приоритетность заказов и, соответственно, изменять загрузку оборудования согласно новым, более приоритетным заказам.

[S.Kuskov]

Возможно будет проще автоматизировать последовательный запуск расчета нескольких планов. В каждом плане по одному приоритету. По моему можно придумать что-нибудь, что бы каждый следующий план не удалял результаты предыдущего, а учитывал их и планировал поверх.

[Cardagant]

Цитата:

Сообщение от S.Kuskov

Возможно будет проще автоматизировать последовательный запуск расчета нескольких планов. В каждом плане по одному приоритету. По моему можно придумать что-нибудь, что бы каждый следующий план не удалял результаты предыдущего, а учитывал их и планировал поверх.

Да, это хорошая идея. Но при планировании из Периодических операций хотелось бы использовать возможности многопоточности. Насколько я понимаю, в данном варианте, преимущества многопоточности теряются.

[S.Kuskov]

В общем случае с указанными ограничениями на изоляцию приоритетов многопоточность не применить. Я же правильно понял что для удовлетворения условий задачи пока не будут покрыты все уровни первого приоритета, второй уровень покрывать нельзя? Иначе в общем случае на каком-нибудь уровне могут встретиться общие с другим приоритетом потребности. Внутри одного приоритета - распараллеливайте на здоровье.

[Cardagant]

Цитата:

Сообщение от S.Kuskov

В общем случае с указанными ограничениями на изоляцию приоритетов многопоточность не применить. Я же правильно понял что для удовлетворения условий задачи пока не будут покрыты все уровни первого приоритета, второй уровень покрывать нельзя? Иначе в общем случае на каком-нибудь уровне могут встретиться общие с другим приоритетом потребности. Внутри одного приоритета - распараллеливайте на здоровье.

Да, с началом каждого уровне должны покрываться отсортированные по приоритетности номенклатуры (отрицательные чистые потребности)

То есть, если я правильно понимаю, Ваш вариант предполагает некий последовательный запуск Периодического сводного для каждой отдельной Приоритетности/номенклатуры и использование распараллеливания в контексте дерева для каждой отдельной приоритетности?

[EVGL]

Подсмотрите, как это сделано в Ax2012 R2 и скопируйте логику.

[Cardagant]

Цитата:

Сообщение от EVGL

Подсмотрите, как это сделано в Ax2012 R2 и скопируйте логику.

Интересно, там реализовано что-то подобное? Спасибо, загляну вечером!

[S.Kuskov]

Цитата:

Сообщение от Cardagant

Да, с началом каждого уровне должны покрываться отсортированные по приоритетности номенклатуры (отрицательные чистые потребности)

У вас одна и та же входящая номенклатура может присутствовать на разных уровнях? Если сначала сортировать по уровням, а только потом по приоритетам, то может возникнуть ситуация при которой менее приоритетная потребность у которой уровень меньше будет покрыта раньше более приоритетной потребности с большим уровнем. Вас это устраивает?

[Cardagant]

Цитата:

Сообщение от S.Kuskov

У вас одна и та же входящая номенклатура может присутствовать на разных уровнях? Если сначала сортировать по уровням, а только потом по приоритетам, то может возникнуть ситуация при которой менее приоритетная потребность у которой уровень меньше будет покрыта раньше более приоритетной потребности с большим уровнем. Вас это устраивает?

Это, конечно же, не устраивает.
По специфике построения наших спецификаций это может быть крайне редко, но всё же может быть. Вы правы. Я, конечно, посмотрю подробнее, но мне казалось, что распределение по уровням делалось на основе поля BOMLevel Номеклатурника. Точно видел это для номенклатур "исходного набора", но не помню на основе какой информации об уровнях помещаются в мэп уровней номенклатуры вновь раскрываемых уровней (не уж то currentLevel + 1).

[S.Kuskov]

Цитата:

Сообщение от Cardagant

Я, конечно, посмотрю подробнее, но мне казалось, что распределение по уровням делалось на основе поля BOMLevel Номеклатурника. Точно видел это для номенклатур "исходного набора", но не помню на основе какой информации об уровнях помещаются в мэп уровней номенклатуры вновь раскрываемых уровней (не уж то currentLevel + 1).

Нужно смотреть. Возможно там все хорошо. Для номенклатуры, во сколько спецификаций она бы не входила BOMLevel рассчитывается однозначно, как максимальный из имеющихся. Действительно логично было бы не только на первой итерации, но и на всех последующих обрабатывать номенклатуры именно в этом порядке.

[S.Kuskov]

Возвращаясь к многопоточности, у меня все равно устойчивое ощущение что необходимость последовательной обработки приоритетов не позволит распараллелить потребности одного уровня больше чем одного приоритета. Абсолютно такое же распараллеливание будет при использовании варианта, предложенного мной.

Обсчитывать одновременно потребности нескольких приоритетов можно только для не конкурирующих друг с другом потребностей. Т.е. выигрыш от распараллеливания можно получить если сначала в разрезе приоритетов рассчитать пересекающиеся потребности, а оставшиеся максимально распараллелить. Стоит ли оно того в вашем случае?