Добрый день,
подскажите, есть в ведомости потребности ППМ сформированная заявка на закупку,
при нажатии "Разметка потребн. к элементу" мы видим из каких потребностей она сформировалась, вопрос как система ищет?
Подскажите таблицы или ФМ?

Спасибо

Явных ссылок в заявке на элементы потребности нет. Поэтому скорее всего идет мини "реконструкция" прогона ППМ. Поэтому надо искать в отладке ФМ. Самим через таблицы будет сложновато я думаю (в общем случае).

Нашел ФМ MD_PEGGING_NODIALOG.

Исходные потребности к заявке поднимаются по последней ведомости ППМ.

Проблема в том что при каждом прогоне ППМ ведомости регенерируются, и исходные потребности могут измениться, либо исчезнуть.

Почему проблема? С т.з. логистики и SAP'a всё верно. Разметка потребности должна идти по актуальной потребности, а не по историческим данным, которые могут быть неактуальны.

Проблема в том что как правило пользователи хотят видеть отчет, под какие потребности сгенерировались эти заявки.
Чтобы понять например, для чего закупили лишнее, и кто заявлял.

Если при повторном прогоне ППМ потребности уже изменились, то следов в системе не останется и у плановика не будет обоснования под свои заявки. Только отговорка, что ППМ так напланировал

А в общем конечно в логике SAP все верно.

Т.е. с ППМ можно работать, только в случае если запасы и все потребности в системе актуальны. Но я не верю что в России так бывает

Для того, чтобы использовать "исторические данные", надо создавать сценарий (MS31) и прогонять ППМ в нем MS01. Тогда можно читать ведомости сценария. Они при обычном "оперативном" прогоне ППМ не меняются.

Особые ситуации в ППМ рулят данные "расхождения". при каждом прогоне, если были фиксированные заявки, то вылезет особая ситуация.
Можно чуть-чуть подабапить, чтобы это вылезало не в момент прогона ППМ, а раньше. Например, при изменении потребности моделировался бы ППМ и если есть особые ситуации, обрабатывать их каким-нибудь алгоритмом. Типа приоритизация потребности, согласование и т.п.

2 Левон: Анализ ведомости ППМ и так обычным плановикам взрывает голову, стоит ли игра свеч если еще и несколько ведомостей хранить в разных сценариях? Насколько я понимаю прогон ППМ в отдельном сценарии создаст отдельную ведомость ППМ а не новую версию старой.

2 waverzzz: особые ситуации при ППМ покажут что были изменения, но изначальные потребности уже будут утеряны. На чуть-чуть подабапить тут не похоже Думаю что абапские проверки до прогона ППМ в качестве предупреждения не эффективны, потому что потребности генерят подразделения а результаты ППМ плановики.

Думаю оптимальный вариант - сохранять в каком то виде архивы ведомости ППМ. Потом анализировать. Но это опять не стандартом делать нужно %)

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

Ведомость ППМ в сценарии - это, в этом случае, и есть архив ведомости ППМ, причем стандартом. У нас так деалали - мозг не взрывает нисколько....а ведомости были огого, да еще с Z в ППМ..

Так ведь потребность изменилась де-факто, значит нужно изменять ее и в системе! Или вы хотите сделать так, чтобы в системе одно, а в жизни -- другое? В Z происходит моделирование ППМ, поэтому все особые ситуации обрабатываются в момент создания потребности, а уж как их обработать -- это зависит от бизнеса. Пример: деталь доставляется 180 дней (откуда-нибудь из Австралии) и вдруг случилась предъаварийная ситуация, создается потребность на ее срочную замену. При планировании в подразделении выдается особая ситуация, что "невозможно обеспечить в срок". Несмотря на это сохранить? Потребность сохраняется, но плановику и закупщику по workflow или как-то еще (а может вообще просто в отчете с приоритетами потребности) отправляется сообщение на согласование. Если деталь критична, то за ней могут и на самолете полететь, т.е. потребность будет согласована и будет создан заказ на закупку со сроками поставки через 2 дня. Так что тут уже система не решит: можно или нельзя купить, изменить потребность и т.п.
По схеме "нельзя менять потребность" может работать только плановая потребность. Такую как раз можно запретить сохранять уже в момент ее создания с учетом прогнанного в фоне моделирования ППМ. В случае аварийной потребности все решается индивидуально.

Вот уже достаточное большое время используем отчет, который работает на основе ФМ MD_PEGGING_NODIALOG для определения исходных потребностей по заявкам и заказам.
Но теперь пытаемся решать вопрос с его производительностью, так как MD_PEGGING_NODIALOG запускается по каждому материалу, работает отчет долго. Поделитесь пожалуйста опытом, кто строил подобный отчет, может необходимо использовать другие способы? MRP Live пока не планируем использовать.