SAPфорум.RU https://www.sapboard.ru/forum/ |
|
Исходная потребность в ППМ https://www.sapboard.ru/forum/viewtopic.php?f=97&t=66858 |
Страница 1 из 1 |
Автор: | VLAVLA [ Чт, янв 20 2011, 09:46 ] |
Заголовок сообщения: | Исходная потребность в ППМ |
Добрый день, подскажите, есть в ведомости потребности ППМ сформированная заявка на закупку, при нажатии "Разметка потребн. к элементу" мы видим из каких потребностей она сформировалась, вопрос как система ищет? Подскажите таблицы или ФМ? Спасибо |
Автор: | Левон [ Пт, янв 28 2011, 13:33 ] |
Заголовок сообщения: | Re: Исходная потребность в ППМ |
Явных ссылок в заявке на элементы потребности нет. Поэтому скорее всего идет мини "реконструкция" прогона ППМ. Поэтому надо искать в отладке ФМ. Самим через таблицы будет сложновато я думаю (в общем случае). |
Автор: | VLAVLA [ Пт, янв 28 2011, 17:18 ] |
Заголовок сообщения: | Re: Исходная потребность в ППМ |
Левон написал: Явных ссылок в заявке на элементы потребности нет. Поэтому скорее всего идет мини "реконструкция" прогона ППМ. Поэтому надо искать в отладке ФМ. Самим через таблицы будет сложновато я думаю (в общем случае). Нашел ФМ MD_PEGGING_NODIALOG. |
Автор: | Liposome [ Ср, мар 16 2011, 05:48 ] |
Заголовок сообщения: | Re: Исходная потребность в ППМ |
Исходные потребности к заявке поднимаются по последней ведомости ППМ. Проблема в том что при каждом прогоне ППМ ведомости регенерируются, и исходные потребности могут измениться, либо исчезнуть. |
Автор: | waverzzz [ Вт, мар 22 2011, 11:30 ] |
Заголовок сообщения: | Re: Исходная потребность в ППМ |
Liposome написал: Проблема в том что при каждом прогоне ППМ ведомости регенерируются, и исходные потребности могут измениться, либо исчезнуть. Почему проблема? С т.з. логистики и SAP'a всё верно. Разметка потребности должна идти по актуальной потребности, а не по историческим данным, которые могут быть неактуальны. |
Автор: | Liposome [ Вт, мар 22 2011, 12:49 ] |
Заголовок сообщения: | Re: Исходная потребность в ППМ |
Проблема в том что как правило пользователи хотят видеть отчет, под какие потребности сгенерировались эти заявки. Чтобы понять например, для чего закупили лишнее, и кто заявлял. Если при повторном прогоне ППМ потребности уже изменились, то следов в системе не останется и у плановика не будет обоснования под свои заявки. Только отговорка, что ППМ так напланировал А в общем конечно в логике SAP все верно. Т.е. с ППМ можно работать, только в случае если запасы и все потребности в системе актуальны. Но я не верю что в России так бывает |
Автор: | Левон [ Вт, мар 22 2011, 13:01 ] |
Заголовок сообщения: | Re: Исходная потребность в ППМ |
Для того, чтобы использовать "исторические данные", надо создавать сценарий (MS31) и прогонять ППМ в нем MS01. Тогда можно читать ведомости сценария. Они при обычном "оперативном" прогоне ППМ не меняются. |
Автор: | waverzzz [ Вт, мар 22 2011, 13:13 ] |
Заголовок сообщения: | Re: Исходная потребность в ППМ |
Liposome написал: Проблема в том что как правило пользователи хотят видеть отчет, под какие потребности сгенерировались эти заявки. Чтобы понять например, для чего закупили лишнее, и кто заявлял. Если при повторном прогоне ППМ потребности уже изменились, то следов в системе не останется и у плановика не будет обоснования под свои заявки. Только отговорка, что ППМ так напланировал Особые ситуации в ППМ рулят данные "расхождения". при каждом прогоне, если были фиксированные заявки, то вылезет особая ситуация. Можно чуть-чуть подабапить, чтобы это вылезало не в момент прогона ППМ, а раньше. Например, при изменении потребности моделировался бы ППМ и если есть особые ситуации, обрабатывать их каким-нибудь алгоритмом. Типа приоритизация потребности, согласование и т.п. |
Автор: | Liposome [ Вт, мар 22 2011, 13:49 ] |
Заголовок сообщения: | Re: Исходная потребность в ППМ |
2 Левон: Анализ ведомости ППМ и так обычным плановикам взрывает голову, стоит ли игра свеч если еще и несколько ведомостей хранить в разных сценариях? Насколько я понимаю прогон ППМ в отдельном сценарии создаст отдельную ведомость ППМ а не новую версию старой. 2 waverzzz: особые ситуации при ППМ покажут что были изменения, но изначальные потребности уже будут утеряны. На чуть-чуть подабапить тут не похоже Думаю что абапские проверки до прогона ППМ в качестве предупреждения не эффективны, потому что потребности генерят подразделения а результаты ППМ плановики. Думаю оптимальный вариант - сохранять в каком то виде архивы ведомости ППМ. Потом анализировать. Но это опять не стандартом делать нужно %) |
Автор: | Левон [ Вт, мар 22 2011, 14:00 ] |
Заголовок сообщения: | Re: Исходная потребность в ППМ |
Liposome написал: 2 Левон: Анализ ведомости ППМ и так обычным плановикам взрывает голову, стоит ли игра свеч если еще и несколько ведомостей хранить в разных сценариях? Насколько я понимаю прогон ППМ в отдельном сценарии создаст отдельную ведомость ППМ а не новую версию старой. Думаю оптимальный вариант - сохранять в каком то виде архивы ведомости ППМ. Потом анализировать. Но это опять не стандартом делать нужно %) Да ведомость будет отдельная, но если правильно настроить сценарий, то она будет идентична ведосмости ППМ на момент создания. Ведомость ППМ в сценарии - это, в этом случае, и есть архив ведомости ППМ, причем стандартом. У нас так деалали - мозг не взрывает нисколько....а ведомости были огого, да еще с Z в ППМ.. |
Автор: | waverzzz [ Пт, мар 25 2011, 21:29 ] |
Заголовок сообщения: | Re: Исходная потребность в ППМ |
Liposome написал: 2 waverzzz: особые ситуации при ППМ покажут что были изменения, но изначальные потребности уже будут утеряны. На чуть-чуть подабапить тут не похоже Думаю что абапские проверки до прогона ППМ в качестве предупреждения не эффективны, потому что потребности генерят подразделения а результаты ППМ плановики. Думаю оптимальный вариант - сохранять в каком то виде архивы ведомости ППМ. Потом анализировать. Но это опять не стандартом делать нужно %) Так ведь потребность изменилась де-факто, значит нужно изменять ее и в системе! Или вы хотите сделать так, чтобы в системе одно, а в жизни -- другое? В Z происходит моделирование ППМ, поэтому все особые ситуации обрабатываются в момент создания потребности, а уж как их обработать -- это зависит от бизнеса. Пример: деталь доставляется 180 дней (откуда-нибудь из Австралии) и вдруг случилась предъаварийная ситуация, создается потребность на ее срочную замену. При планировании в подразделении выдается особая ситуация, что "невозможно обеспечить в срок". Несмотря на это сохранить? Потребность сохраняется, но плановику и закупщику по workflow или как-то еще (а может вообще просто в отчете с приоритетами потребности) отправляется сообщение на согласование. Если деталь критична, то за ней могут и на самолете полететь, т.е. потребность будет согласована и будет создан заказ на закупку со сроками поставки через 2 дня. Так что тут уже система не решит: можно или нельзя купить, изменить потребность и т.п. По схеме "нельзя менять потребность" может работать только плановая потребность. Такую как раз можно запретить сохранять уже в момент ее создания с учетом прогнанного в фоне моделирования ППМ. В случае аварийной потребности все решается индивидуально. |
Автор: | VLAVLA [ Вт, июн 14 2016, 14:38 ] |
Заголовок сообщения: | Re: Исходная потребность в ППМ |
Вот уже достаточное большое время используем отчет, который работает на основе ФМ MD_PEGGING_NODIALOG для определения исходных потребностей по заявкам и заказам. Но теперь пытаемся решать вопрос с его производительностью, так как MD_PEGGING_NODIALOG запускается по каждому материалу, работает отчет долго. Поделитесь пожалуйста опытом, кто строил подобный отчет, может необходимо использовать другие способы? MRP Live пока не планируем использовать. |
Страница 1 из 1 | Часовой пояс: UTC + 3 часа |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |