fed: Net requirements update in MRP Module and Working Set of MRP

[fed]

Цитата:

Более сложный пример: Регенерация динамического плана
Регенерация динамического плана работает примерно также как и регенерация статического, однако несколько шагов все-таки добавлено:

• Прежде чем проимпортировать данные inventSum/inventTrans (шаг 4 из предыдущего раздела) для данной номенклатуры, система вычищает все записи таблицы inventSumLogTTS, относящиеся к данной номенклатуре.
• Во время стадии покрытия, перед тем как обработать номенклатуру (даже если она не включена в Номенклатуры сессии) система запускает специальный класс (reqTransUpdate), который которая переносит запротоколированные обновления по данной номенклатуре из inventSumLogTTS в чистые потребности (reqTrans), а затем вычищает перенесенную информацию из первой из этих таблиц. Я буду называть этот процесс Динамическим Обновлением

Таким образом, используется следующая последовательность продвижения информации: Когда пользователь изменяет логистический документ, измененные данные переносятся в складские проводки (inventTrans); Далее в конце транзации БД, данные копируются в inventSumLogTTS; Затем, в конце концов, запротоколированные изменения переносятся в данные чистых потребностей (reqTrans). После того как запротоколированные в таблице inventSumLogTTS изменения были применены к данным чистых потребностей, эти изменения удаляются из протокола, поскольку смысла их хранить уже нету.
Я хочу специально заметить, что те чистые потребгости, которые оказались обновлены на стадии Динамического обновления не включаются автоматически в Рабочее множество. Динамическое обновление не особо изберательно; Оно выполняется на уровне конкретной номенклатуры. Может так случится, что Динамическое обновление обновило чистые потребности с конфигурациями, размерами или цветами, которые ничего не имеют общего с текущей Номенклатурой сессии. Таким образом, включение всех случайно обновленных чистых потребностей по номенклатуре в Рабочий Набор вызвало бы ненужное увеличение размера Рабочего набора и увеличило бы сложность планирования.

Интересный побочный эффект от применения данных в inventSumLogTTS состоит в том, что сессия сводного планирования может адаптироваться к последним изменениям складских проводок, сделанных пользователями во время работы планирования. Предположим, что у нас в Номенклатуре сессии присутствует некая номенклатура с уровнем вложенности 4.Может так случится, что между начальной регенерацией чистых потребностей, какой-то пользователь выполнит складские операции по данной номенклатуре (например порезервирует какие-то заказы). Поскольку рассчет покрытия по номенклатуре начинается с применения к чистым потребностям записанного в inventSumLogTTS протокола по данной номенклатуре, результаты расчета будут соответствовать состоянию inventTrans на момент начала рассчета покрытия по данной номенклатуре.В то же время, в случае регенерации статического плана, состояние чистых потребностей соответствует состоянию inventTrans в момент начальной регенерации чистых потребностей. Все последующие изменения складских проводок не отражаются в чистых потребностях.

Продолжаем...