Схема с двумя планами
Стандартные учебники по сводному планированию детально описывают идею использования схемы с двумя планами.Коротко говоря, у нас есть два плана - статический и динамический. Статический план полностью пересчитывается в режиме регенерации каждую ночь (каждую вторую ночь, каждую субботу и тп), а затем копируется в динамический план. Днем (строго говоря - в любое время между двумя перегенерациями статического плана), департаменты закупок, логистики и производства работают со статическим планом (поскольку он стабилен и лучше соответствует,эээ, набору правил планирования); В то же время менеджеры по продажам работают с динамическим планом и могут запускать развертывание для вновь созданных заказов на закупку. При данном подходе, менеджеры по продажам имеют инструмент, позволяющий им прикинуть реалистичную дату поставки по размещенному заказу, а все остальные подразделения работают со стабильной версией плана, которая не имеет проблем вызванных оперативными обновлениями. В этом случае, если исполняется
Полное MRP и
Набор сесии содержит всю номенклатуру и включен режим автоматического копирования статического плана в динамический, во время фазы обновления, все содержимое таблицы InventSumLogTTS удаляется. Причина этого ясня: Поскольку мы перегенерируем весь план и собираемся результат планирования скопировать в динамический план, нет никакого смысла сохранять старый журнал обновлений.В начале мы вычистим всю информацию из inventSumLogTTS, создадим статический план с ноля, затем, когда MRP завершится, мы скопируем статический план в динамический. В этот момент, в таблицу inventSumLogTTS будет хранится протокол изменений складских проводок, выполненых после завершения начальной фазы обновления. Если пользователь попробует запустить развертывание или перепланирование в режиме Накопленных Изменений или Минимальных Изменений, система отработает в обычном режиме динамического обновления динамического плана...
Смена текущего динамического плана
Если вы попытаетесь сменить текущий динамический план, вы столкнетесь со странным поведением системы. При попытке замены, система выкинет диалоговое окно с загадочным сообщением: "Обновить и переместить проводки в новый динамический генеральный план?" (Кстати хочу отметить традиционно низкое качество перевода. Не очень понятное английское сообщение было заменено на абсолютно непонятное русское.) Если вы согласитесь, в момент записи изменений, система надолго зависнет. А затем, вас ждет большой сюрприз: Ваш новый текущий динамический план будет содержать в точности те же самые данные что и ваш бывший динамический план.Система висела как раз потому что она копировала содержимое из старого динамического планеа в новый.
На первый взгляд, это выглядит ненормальным и неожиданным. Мы осознано решили сменить динамический план, но, тем не менее, в качестве результата мы получили тот же самый старый план, просто под другим именем.Но если мы разберемся в проблеме глубже, всё это не так уж и ненормально. Допустим мы поменяли текущий диинамический план без копирования. Что делать следующему развертыванию ? У нас в InventSumLogTTS хранится информация о куче изменений; Какие из них должны быть применены к новому динамическому плану, а какие -нет ? В системе для этого нету необходимой информации. Есть только один динамический план, который засинхронизирован с состоянием данных в таблицах inventTrans/inventSumLogTTS. И когда мы меняем текущий динамический план, существует только один относительно быстрый способ засинхронизировать новый план с этими данными - это скопировать старый план в новый. Альтерантивой был бы запуск
Полного MRP в режиме регенерации, но это потребовало бы значительно больше времени и ресурсов от серверов БД и AOS. Именно по этому, разработчики модуля сводного планирования в Аксапте предпочли копировать старый план в новый при любой попытке изменения текущего динамического плана.
Процесс динамического обновления
Процесс динамического обновления достаточно прямолинеен.Система пробегает по записям таблицы inventSumLogTTS, для данной номенклатуры, отсортированным по номеру обновления (sequence number) и применяет каждое запротоколированное изменение к соответствующей записи чистых потребностей. Тем не менее, я хочу отметить несколько фактов:
- Работа с таблице inventSumLogTTS происходит в режиме пессимистических блокировок. Если два пользователя пытаются запустить планирование или развертывание одной и той же номенклатуры, один из них будет заблокирован.Если у нас для данной номенклатуры накопилось много обновлений, заблокированный пользователь может прождать порядка 20-30 секунд.В версии 2012, разработчики слегка изменили принципы работы с этой таблицей, и теперь блокировка выполняется в оптимистическом режиме.
- Динамическое обновление запускается не только из сводного планирования или развертывания, но также и в тех случаях, когда пользователь открывает форму Чистые Потребности или Развертывание. Если у вас в таблице inventSumLogTTS накопилось много записей для данной номенклатуры, не удивляйтесь если при открытии одной из этих форм, ваш аксаптовский клиент зависнет ненадолго. (До нескольких минут, если вы давно не запускали перегенерацию плана или если у вас слабенький сервер БД). Кроме того, даже если вы только что создали новую строку заказа (допустим - заказа на продажу) и после этого пока не запускали Сводное/Развертывание, в форме Чистых потребностей вы все равно увидите чистую потребность в свежесозданной строке заказа - как раз таки результат работы данного механизма.
- Когда система выполняет процедуру Динамического обновления, она запоминает список обновленных складских аналитик и измененных количеств. В конце обновления, система пытается найти парные изменения Чистых Потребностей с одинаковыми складскими аналитиками и так сказать 'перепрошить' данные о покрытии между ними. Допустим, мы поменяли склад в строке закупки и система автоматически поменяла склад в примаркированной складской проводке по продажам. Следующее Динамическое обновление удалит, а потом пересоздаст информацию о покрытии, даже без необходимости запуска настоящего сводного планирования со стадией рассчета покрытия. (Вы можете попробовать открыть формы Чистых потребностей после смены заказа но до запуска развертывания или сводного планирования).
- Я никогда не сталкивался со следующей ситуацией, но я все равно считаю что она может иногда случаться:Поскольку Аксапта не поддерживает сериализуемый уровень изоляции транзакций, может случится что во время планирования, на фазе обновления, после переноса информации из складских проводок в чистые потребности, но до очистки данных inventSumLogTTS, какой-то пользователь изменит какие-то складские проводоки. В результате - информация об обновлении будет удалена изinventSumLogTTS (поскольку мы там вообще все записи удаляем), и не скопирована в чистые потребности (поскольку в момент копирования, складские проводки еще не были изменены). Вероятность такой ситуации невысока, а последствия - не особо тяжелы.Я думаю, что единственным способом, который смог бы исправить ситуацию, была бы реализация поддержки Snapshot Transaction Isolation Level и использование этого уровня изоляции при обновлении данных чистых потребностей из складских проводок...