![]() |
#15 |
Moderator
|
Цитата:
Схема с двумя планами Стандартные учебники по сводному планированию детально описывают идею использования схемы с двумя планами.Коротко говоря, у нас есть два плана - статический и динамический. Статический план полностью пересчитывается в режиме регенерации каждую ночь (каждую вторую ночь, каждую субботу и тп), а затем копируется в динамический план. Днем (строго говоря - в любое время между двумя перегенерациями статического плана), департаменты закупок, логистики и производства работают со статическим планом (поскольку он стабилен и лучше соответствует,эээ, набору правил планирования); В то же время менеджеры по продажам работают с динамическим планом и могут запускать развертывание для вновь созданных заказов на закупку. При данном подходе, менеджеры по продажам имеют инструмент, позволяющий им прикинуть реалистичную дату поставки по размещенному заказу, а все остальные подразделения работают со стабильной версией плана, которая не имеет проблем вызванных оперативными обновлениями. В этом случае, если исполняется Полное MRP и Набор сесии содержит всю номенклатуру и включен режим автоматического копирования статического плана в динамический, во время фазы обновления, все содержимое таблицы InventSumLogTTS удаляется. Причина этого ясня: Поскольку мы перегенерируем весь план и собираемся результат планирования скопировать в динамический план, нет никакого смысла сохранять старый журнал обновлений.В начале мы вычистим всю информацию из inventSumLogTTS, создадим статический план с ноля, затем, когда MRP завершится, мы скопируем статический план в динамический. В этот момент, в таблицу inventSumLogTTS будет хранится протокол изменений складских проводок, выполненых после завершения начальной фазы обновления. Если пользователь попробует запустить развертывание или перепланирование в режиме Накопленных Изменений или Минимальных Изменений, система отработает в обычном режиме динамического обновления динамического плана... Смена текущего динамического плана Если вы попытаетесь сменить текущий динамический план, вы столкнетесь со странным поведением системы. При попытке замены, система выкинет диалоговое окно с загадочным сообщением: "Обновить и переместить проводки в новый динамический генеральный план?" (Кстати хочу отметить традиционно низкое качество перевода. Не очень понятное английское сообщение было заменено на абсолютно непонятное русское.) Если вы согласитесь, в момент записи изменений, система надолго зависнет. А затем, вас ждет большой сюрприз: Ваш новый текущий динамический план будет содержать в точности те же самые данные что и ваш бывший динамический план.Система висела как раз потому что она копировала содержимое из старого динамического планеа в новый. На первый взгляд, это выглядит ненормальным и неожиданным. Мы осознано решили сменить динамический план, но, тем не менее, в качестве результата мы получили тот же самый старый план, просто под другим именем.Но если мы разберемся в проблеме глубже, всё это не так уж и ненормально. Допустим мы поменяли текущий диинамический план без копирования. Что делать следующему развертыванию ? У нас в InventSumLogTTS хранится информация о куче изменений; Какие из них должны быть применены к новому динамическому плану, а какие -нет ? В системе для этого нету необходимой информации. Есть только один динамический план, который засинхронизирован с состоянием данных в таблицах inventTrans/inventSumLogTTS. И когда мы меняем текущий динамический план, существует только один относительно быстрый способ засинхронизировать новый план с этими данными - это скопировать старый план в новый. Альтерантивой был бы запуск Полного MRP в режиме регенерации, но это потребовало бы значительно больше времени и ресурсов от серверов БД и AOS. Именно по этому, разработчики модуля сводного планирования в Аксапте предпочли копировать старый план в новый при любой попытке изменения текущего динамического плана. Процесс динамического обновления Процесс динамического обновления достаточно прямолинеен.Система пробегает по записям таблицы inventSumLogTTS, для данной номенклатуры, отсортированным по номеру обновления (sequence number) и применяет каждое запротоколированное изменение к соответствующей записи чистых потребностей. Тем не менее, я хочу отметить несколько фактов:
|
|
|
За это сообщение автора поблагодарили: AlGol (2), Maximin (6), db (10), sukhanchik (20), lev (16), serg.epshtein (1). |
Теги |
сводное планирование |
|
![]() |
||||
Тема | Ответов | |||
fed: Two stories about inventory closing and SQL Locks | 3 |
|