Сделать ресурсы глобальными для планирования

[sgt.Pepper]

Всем добрый день,

AX 2012 R3 CU9
задача достаточно обширная, поэтому спрашиваю только об идеях реализации.

Есть несколько компаний (текстильная промышленность), каждая из которых изготавливает собственную продукцию.
НО: ресурсы у всех этих компаний общие, то есть заводы, изготовляющие части продукции или материалы могут располагаться в Китае или Польше,
сами компании соответственно находиться в Германии или Франции.

При планировании операций или задач может оказаться, что был использован один и тот же ресурс, что приводит к конфликтам планирования.

Чтобы этого не происходило, необходимо сделать ресурсы глобальными.
Здесь речь не идет о планировании между компаниями (intercompany planning), речь идет только о ресурсах.

От виртуальных компаний отказались ввиду ряда факторов.

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

2. Альтернативный подход: для планирования использовать одно централизованное место (службу или менеджер), который при поступлении запроса на планирование ресурсов будет проверять ресурс,
и если он доступен то делать его резервирование для всех компаний.
Достоинства: меньшая степень изменения структуры базы, для внедрения сделать необходимо некую надстройку, которая будет управлять стандартным функционалом.
Недостатки: при проводках в разы увеличивается загрузка базы, поскольку обновление нужно проводить во всех компаниях.

3. Использовать Views для просмотра/редактирования ресурсов и их загруженности, которые тоже будут глобальными.
Этот вариант особо не рассматривается как возможный, поскольку возникает проблема с обновлением данных, но было бы интересно, хотя бы часть задачи решить таким образом.

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

[Михаил Андреев]

Цитата:

Сообщение от sgt.Pepper

От виртуальных компаний отказались ввиду ряда факторов.

Можно озвучить факторы и почему не рассмотрели вариант общих таблиц (Save Data per Company = No)?

[sgt.Pepper]

Основной аргумент заказчика, почему не использовать виртуальные компании, то что эта фича не будет поддерживаться в AX7 ввиду ряда причин,. Кроме того, создавать пост-фактум виртуальную компанию и сливать в нее данные достаточно трудная и опасная (в плане потерять данные) задача, особенно с таким количеством таблиц (кто пробовал тот знает).

Вариант с SaveDataPerCompany = No тоже рассматривается, вижу следующие проблемы:
1. Все ссылки на таблицы поплывут. При смене SaveDataPercompany = No перегенерируется RecId, DataAreaId удаляется. Соответственно нужно: данные из всех компаний слить в одну, обновить ссылки и во все Relations от ресурсных таблиц добавлять DataAreaId.

Кроме того, придется систему модифицировать: например пришло 2 заказа на планирование - один из компании А, другой из Б, нужно естественно при обработке указать, для какой компании запланирован ресурс.

В общем-то это вариант 1 с преимуществами, что не надо дублировать таблицы.

Я бы смотрел в сторону решения по номенклатуре идеологически:
номенклатура общая, но настраивается для конкретных компаний которые ее юзают и тп
Т.е. за SaveDataPercompany = No в части таблиц
Чуток индуса (может понятнее будет моя корявая мысль)
https://dynamicsaxgyan.wordpress.com...amics-ax-2012/

[sgt.Pepper]

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

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

[fed]

Мне вариант 1 кажется наиболее реалистичным. Сделать тупое зеркалирование самих ресурсных таблиц - не сложно и не очень рисковано. Кроме того - понадобится сделать зеркалирования календаря и таблицы резервирования ресурсов (WrkCtrCapRes). Это несколько облегчается тем чт о в резервирование ресурсов данные пишутся буквально в паре 3-4 местах - WrkCtrScheduler, ReqCalc, еще классы копирования и удаления сводного плана. Конечно зеркалирование подъест ресурсов, но сам перебор рабочих центров при ресурсном планировании съедает больше чем запись информации о резервах в БД.
Ну и наконец - однозначно надо будет глобализовать (установить SaveDataPerCompany=No) для таблицы WrkCtrSchedulerLock. Возможно не все это знают, но в данный момент времени, ресурсным планированием может заниматься только одна сессия - которая эту самую таблицу и залокировала. (Кстати - по этой причине если у тебя много плановых производственных заказов, распараллеливание на несколько пакетников не дает большого эффекта - большая часть задач просто тупо ждет освобождения этого семафора). В вашем случае, чтобы несколько сессий в разных компаниях не попатались запланировать одни и те же мощности, надо сделать этот семафор глобальным. Тогда следующая сессия начнет планирование только после того как текущая сессия запишет во все компании все свои резервирования.

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

[sgt.Pepper]

Сначала я был склонен ко 2-му варианту, но после вашего поста тоже склоняюсь к первому, во всяком случае трудозатраты будут меньше.

[sgt.Pepper]

Вчера-сегодня порылся в логике и обнаружил, что все данные в таблицу WrkCtrCapRes (Резервирование мощностей), из-за которой собственно весь сыр-бор пишутся через класс WrkCtrSchedulerJobSchedulingEngine, а тот в свою очередь вызывает классы из библиотеки Microsoft.Dynamics.AX.Planning.JobScheduling.dll, которая доступна в АОТ как reference, то есть исходников нету.

В интернете нашел очень мало информации по поводу того, как сделать модификацию на основе интерфейса WrkCtrSchedulerEngineInterface, только вот это
Adding Fixed Lead Time to a Resource Schedule [AX 2012]
поэтому сейчас даже не представляю, как в такой ситуации, сделав глобальную копию этой таблицы например WrkCtrCapResGlobal, поменять логику так, чтобы писать именно в нее, или сделав какой-нибудь EventHandler на WrkCtrCapRes.insert(), рикошетить в глобальную

Дальше опять размышления - если поставить в таблице WrkCtrCapRes SaveDataPerCompany = No, как в нее добавить ID той компании, в которой производился расчет?

В свете этих рассуждений опять прихожу ко 2-му варианту, хотя как по мне не очень желаемому.

[fed]

Цитата:

Сообщение от sgt.Pepper

Вчера-сегодня порылся в логике и обнаружил, что все данные в таблицу WrkCtrCapRes (Резервирование мощностей), из-за которой собственно весь сыр-бор пишутся через класс WrkCtrSchedulerJobSchedulingEngine, а тот в свою очередь вызывает классы из библиотеки Microsoft.Dynamics.AX.Planning.JobScheduling.dll, которая доступна в АОТ как reference, то есть исходников нету.

В интернете нашел очень мало информации по поводу того, как сделать модификацию на основе интерфейса WrkCtrSchedulerEngineInterface, только вот это
Adding Fixed Lead Time to a Resource Schedule [AX 2012]
поэтому сейчас даже не представляю, как в такой ситуации, сделав глобальную копию этой таблицы например WrkCtrCapResGlobal, поменять логику так, чтобы писать именно в нее, или сделав какой-нибудь EventHandler на WrkCtrCapRes.insert(), рикошетить в глобальную

Дальше опять размышления - если поставить в таблице WrkCtrCapRes SaveDataPerCompany = No, как в нее добавить ID той компании, в которой производился расчет?

В свете этих рассуждений опять прихожу ко 2-му варианту, хотя как по мне не очень желаемому.

На самом деле - та самая assembly - это чисто математический оптимизатор, который сам ни с какими таблицами не работает, а вызывает через интерфейс аксаптовские классы, которые и подгружают/пишут данные в реальные таблицы джобов и ресурсов. То есть - надо просто тупо найти то места в WrkCtrScheduler, которые пишут в WrkCtrCapRes (на вскидку -это методы writeCapacityReservation, и writeAllCapacityReservationProperties) и добавить логику, при которой каждая запись дуплицируется во все компании.
Кроме того - делать глобальную таблицу не нужно, нужно просто дублировать записи (вероятно - добавив там отдельное поле с кодом компании-источника).