Показать сообщение отдельно
Старый 30.04.2012, 15:48   #12  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Более сложный пример: Регенерация динамического плана
Регенерация динамического плана работает примерно также как и регенерация статического, однако несколько шагов все-таки добавлено:
  • Прежде чем проимпортировать данные inventSum/inventTrans (шаг 4 из предыдущего раздела) для данной номенклатуры, система вычищает все записи таблицы inventSumLogTTS, относящиеся к данной номенклатуре.
  • Во время стадии покрытия, перед тем как обработать номенклатуру (даже если она не включена в Номенклатуры сессии) система запускает специальный класс (reqTransUpdate), который которая переносит запротоколированные обновления по данной номенклатуре из inventSumLogTTS в чистые потребности (reqTrans), а затем вычищает перенесенную информацию из первой из этих таблиц. Я буду называть этот процесс Динамическим Обновлением
Таким образом, используется следующая последовательность продвижения информации: Когда пользователь изменяет логистический документ, измененные данные переносятся в складские проводки (inventTrans); Далее в конце транзации БД, данные копируются в inventSumLogTTS; Затем, в конце концов, запротоколированные изменения переносятся в данные чистых потребностей (reqTrans). После того как запротоколированные в таблице inventSumLogTTS изменения были применены к данным чистых потребностей, эти изменения удаляются из протокола, поскольку смысла их хранить уже нету.
Я хочу специально заметить, что те чистые потребгости, которые оказались обновлены на стадии Динамического обновления не включаются автоматически в Рабочее множество. Динамическое обновление не особо изберательно; Оно выполняется на уровне конкретной номенклатуры. Может так случится, что Динамическое обновление обновило чистые потребности с конфигурациями, размерами или цветами, которые ничего не имеют общего с текущей Номенклатурой сессии. Таким образом, включение всех случайно обновленных чистых потребностей по номенклатуре в Рабочий Набор вызвало бы ненужное увеличение размера Рабочего набора и увеличило бы сложность планирования.

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