Sapforum.Biz
Логистика => Управление материальными потоками (MM) => Тема начата: Roman от Январь 05, 2011, 05:45:23 pm
-
Доброго времени суток!
Я простой пользователь SAP, не консультант и не суперспециалист.
На нашем предприятии недавно запустили SAP и на сегодняшний день стоит задача запустить систему автоматического формирования заявок на закуп, с целью поддержания на складе необходимого количества материала. Если я правильно понимаю это и есть ППМ.
Прошу подсказать где можно получить информацию о том какие данные необходимо внести в систему и, самое главное, где и как это все нужно указывать? Есть некоторые собственные соображения по этому поводу, но этого совсем даже недостаточно.
Буду благодарен за любую информацию.
Заранее большое человеческое спасибо.
-
Ну наверное надо начинать с чтения: http://help.sap.com/saphelp_erp2004/helpdata/ru/7d/c2821c454011d182b40000e829fbfe/frameset.htm
-
Ну наверное надо начинать с чтения: http://help.sap.com/saphelp_erp2004/helpdata/ru/7d/c2821c454011d182b40000e829fbfe/frameset.htm
Пока печатал, Уукрул меня опередил.
А инструкций консультанты и проектная команда не оставляли?
Буду дома - отвечу, попробую кратко и емко.
А пока, Вам бы, не мешало хоть бы посмотреть следующую инфу
Если есть курс SCM525 - почитать хотя бы бегло, что бы понимать.
Еще тут http://help.sap.com/saphelp_erp2005/helpdata/ru/7d/c2821c454011d182b40000e829fbfe/frameset.htm
-
Спасибо большое за оперативные ответы.
-
Первое, у Вас то хоть ППМ настроен?
- попробуйте посмотреть код ППМ в ОЗМ (mm02/mm42) любого материала который Вы знаете (должен быть любой кроме ND)
- запустите md04 по заводу который вы используете и по провереному материалу
Ну ладно, озадачил, теперь побежал домой, вечером пообщаемся
-
Ну ладно, озадачил, теперь побежал домой, вечером пообщаемся
Долго ты однако домой бежал, народ тут уже волноваться начал... разные предположения пошли, через что и как ты бежал ???
-
Долго ты однако домой бежал, народ тут уже волноваться начал... разные предположения пошли, через что и как ты бежал ???
хм, ссори, запамятовал ... :)
Дык человек больше не спрашивал.... написать то дело не хитрое... ППМ он как двери... все просто, формулы состава только посложнее будут ...
Молодой человек, Вам еще актуально?
-
Буду дома - отвечу, попробую кратко и емко.
ничего не понятно...вот тоже похожий вопрос возник. Вы же вот написали, что ответите, потом еще было: озадачили. Побежал. Вечером напишу. Теперь - а больше не спрашивали. А чего еще раз спрашивать то? Вы же, молодой человек - пообещали! Или это было просто так, для поддержания разговора? Тут заходишь на сайт, видишь, что не просто не игнорируют, а и помогают. Зачем же еще раз спрашивать? Надеемся же вот...что сдержите слово, поможете, к тому же мне например не понятно, так этим вопросом озадачили все-таки или это просто?
-
ничего не понятно...вот тоже похожий вопрос возник. Вы же вот написали, что ответите, потом еще было: озадачили. Побежал. Вечером напишу. Теперь - а больше не спрашивали. А чего еще раз спрашивать то? Вы же, молодой человек - пообещали! Или это было просто так, для поддержания разговора? Тут заходишь на сайт, видишь, что не просто не игнорируют, а и помогают. Зачем же еще раз спрашивать? Надеемся же вот...что сдержите слово, поможете, к тому же мне например не понятно, так этим вопросом озадачили все-таки или это просто?
Ок, признаю.
Теперь попорядку, пока я пишу (готовлю описание), посмотрите это (мне нужно понимать хоть что у Вас есть).
Первое, у Вас то хоть ППМ настроен?
- попробуйте посмотреть код ППМ в ОЗМ (mm02/mm42) любого материала который Вы знаете (должен быть любой кроме ND)
- запустите md04 по заводу который вы используете и по провереному материалу
Хотя мне кажется что у Вас ППМ не настроен, а консультанта или настройщика нет?
-
ничего не понятно... вот тоже похожий вопрос возник. Вы же вот написали, что ответите, потом еще было: озадачили. Побежал. Вечером напишу. Теперь - а больше не спрашивали. А чего еще раз спрашивать то? Вы же, молодой человек - пообещали! Или это было просто так, для поддержания разговора? Тут заходишь на сайт, видишь, что не просто не игнорируют, а и помогают. Зачем же еще раз спрашивать? Надеемся же вот... что сдержите слово, поможете, к тому же мне, например не понятно, так этим вопросом озадачили все-таки или это просто?
А можете уточнить Ваш вопрос, а то, я понял, только, что у Вас подобный вопрос возник.
Может, четче сформулируете свой вопрос?
В обоих случаях, для меня слишком мало информации, что бы понять, что человек хочет.
И лично я Вам ничего не обещал, Roman"у, я пообещал - сделаю, приблизительно по таким пунктам:
1. Краткое введение (что такое ППМ, какие типы бывают)
2. Как это работает
3. Основные данные
4. Выполнение и просмотр результатов (созданных заявок)
5. Преобразование заявок в заказы
6. Основные настройки (в последнюю очередь, так как объем большой, и тема не для одной заметки)
-
А можете уточнить Ваш вопрос, а то, я понял, только, что у Вас подобный вопрос возник.
Может, четче сформулируете свой вопрос?
В обоих случаях, для меня слишком мало информации, что бы понять, что человек хочет.
И лично я Вам ничего не обещал, Roman"у, я пообещал - сделаю, приблизительно по таким пунктам:
1. Краткое введение (что такое ППМ, какие типы бывают)
2. Как это работает
3. Основные данные
4. Выполнение и просмотр результатов (созданных заявок)
5. Преобразование заявок в заказы
6. Основные настройки (в последнюю очередь, так как объем большой, и тема не для одной заметки)
Вопрос действительно такой же. Поэтому и жду тоже Вашего ответа.
Ссылки это конечно хорошо и большое спасибо... но заинтриговали ведь тем, что постараетесь кратко и емко. А по данной программе, когда ее не чувствуешь, можно читать долго, только понять сложно. Если есть форумы где могут подсказать какие-то моменты, которые с Вашей точки зрения простые, а для меня непомерно сложные, то почему же не обратиться? Повторно задавать тот же вопрос, как на меня, смысла не было. Я тоже простой пользователь.
Я не прошу, что-то мне лично обещать :-) я просто ждала, когда Вы напишите ответ.
Вроде как нет же такого правила на данном форуме, что написанное можно использовать только тому кто спросил...или есть?
Вы же для аудитории неограниченной выкладываете все описания, доработки и тому подобные вещи?
Насколько я могу понять из перечисленных пунктов, меня интересуют только первые пять. Может автору вопроса - Roman"у необходимо больше...это я не подскажу.
В любом случае, право конечно Ваше сдерживать обещанное или нет, но мне было бы интересно почитать, может Вы сможете объяснить более доступно для простых пользователей.
-
Дальше я постараюсь кратко рассказать о том что такое ППМ и с чем его едят.
Не стоит обольщаться, что прочитав эту статью Вы сразу сможете это все настроить и запустить (особенно в том случае, если у Вас в системе ничего не настроено).
В любом случае, Вам придется читать, спрашивать.
Я укажу какие нужны настройки, но читать документацию к настройкам (F1 на каждой галочке) Вам все же надо.
Я предполагаю (надеюсь) что Вы знаете что такое: ОЗМ, заявка, заказ, основная запись поставщика (если не ясно - спрашивайте)
План
1. Краткое введение (что такое ППМ, какие типы бывают)
2. Основные данные и предпосылки
3. Как это работает
4. Выполнение и просмотр результатов (созданных заявок)
5. Преобразование заявок в заказы
6. Основные настройки
По ходу написания, я возможно буду менять или дополнять.
1. Краткое введение
Итак, постараюсь по максимуму просто.
Что такое ППМ и зачем оно нужно.
Основное предназначение ППМ, обеспечить доступность необходимого запаса на складе, на необходимое время.
Как она это делает? Упрощено, это приблизительно так: берет планируемый расход (см. ниже типы ППМ), отнимает запас на складе, добавляет страховой запас* (определённое к-во материала, которое остается не тронутым, на крайний случай, например срыв сроков поставки, перерасход), отнимает планируемые поступления (открытые заказы, т.е. те по которым не выполнено поступление всего заказного к-в.), таким образом вычисляется необходимое к-во.
Далее, при прогоне ППМ, система создает заявки на закупку либо плановые заказы (специальные документы, которые потом могут быть преобразованы в заявки или производственные заказа (если у Вас производственное предприятие, и материал по которому есть потребность производится на Вашем предприятии).
При этом при создании этих документов, учитываются даты потребности, время на поставку материала от поставщика, и в соответствии с этими факторами - документы создаются на необходимые даты.
Например (упрощено) система знает (см. ниже) что на 29.03.2011 нужно 100кг алюминия, время на доставку 10 дней, значит система закажет (создаст заявку/плановый заказ) дато1 19.03.2011)
Дополнительно, советую почитать статью с www.logist.org.ua "Сказка для взрослых
о деде, бабе, производстве и MRP" - доступно, с юмором..... (см. вложение)
* Страховой запас — это часть производственных запасов, формируемых на случай непредвиденных обстоятельств (недопоставок, просроченных поставок) или чрезвычайных положений (аварийные ситуации у поставщика, негативные природные явления). Предположения о возникновении непредвиденных ситуаций не случайны.
Продолжение следует ....
-
У кого Сказка нормально не открывается, повторно залил
(Uukrul) PS: Прицепил файл.
-
План
1. Краткое введение (что такое ППМ, какие типы бывают)
Что такое ППМ вроде понятно, а какие типы бывают Вы позже добавите?
За сказку отдельное спасибо!
-
Что такое ППМ вроде понятно, а какие типы бывают Вы позже добавите?
За сказку отдельное спасибо!
Да добавлю, в процессе написания (все таки еще и работу работать приходится)
-
Виды ППМ
Пока я пишу, кратко о типах ППМ ( буду указывать транзакции, потом приведу скриншоты и более подробно опишу)
По простому, существует два типа ППМ: регулируемое расходом и детерминированное.
Детерминированное - вы просто задаете системе к-во, которое вам нужно и дату, на которую это количество необходимо (тр. md61-mb62), потом запускаете ППМ (md61), система вычисляет (с учетом страхового запаса, остатков, планируемого поступления) сколько надо заказать и формирует заявки на даты потребности,
дальше происходит процесс закупки.
Регулируемое расходом ППМ, основано на том, что к-во потребности вычисляется на основе статистики расхода (например продаж) материала.
Т.е. во время отпуска материала в производство (если у Вас производственная система) или во время продаж (если
у вас розница, опт), система фиксирует расход (записывает в карточке материала, к-во за период, за какой период хранить статистику расхода, так же задается в карточке материала (день, месяц, год).
Например, у нас стоит код неделя и карточке материала имеем следующую картину
1 (нед) - 100
2 (нед) - 100
3 (нед) - 300
В детерминируемом ППМ используется еще так называемый прогноз (перед прогоном ППМ, происходит вычисление планируемого к-ва расхода (тр. mp30)
Способы (формулы) по которым система определяет план зависят от т.е, модели прогноза (константная, тренд, сезон, трендово-сезонная модель) модель прогноза задается в карточке товара, но есть возможность автоматического определения какую модель использовать (по данным расхода прошлых периодов, система сам вычисляет, какую же модель использовать.
C формулами ознакомится можно по ссылке http://help.sap.com/saphelp_erp2005/helpdata/ru/7d/c279b9454011d182b40000e829fbfe/frameset.htm
к сожалению только на английском, переводов не видел.
-
хм, ссори, запамятовал ... :)
Дык человек больше не спрашивал.... написать то дело не хитрое... ППМ он как двери... все просто, формулы состава только посложнее будут ...
Молодой человек, Вам еще актуально?
Добрый вечер!
Неделю не заглядывал сюда...оказалось за это время столько информации выложено.
Да, я вроде разобрался с ППМ, правда не все пока корректно работает, но это дело времени. Воспользовался Вашими подсказками и в инете нарыл немного допинфо.
Еще раз благодарен за информацию.
-
...потом приведу скриншоты и более подробно опишу...
вот это было бы очень интересно посмотреть
-
вот это было бы очень интересно посмотреть
Спасибо за поддержку, могласитесь сами, писать ради того что бы просто писать - графоманство...
-
Добрый вечер!
Неделю не заглядывал сюда...оказалось за это время столько информации выложено.
Да, я вроде разобрался с ППМ, правда не все пока корректно работает, но это дело времени. Воспользовался Вашими подсказками и в инете нарыл немного допинфо.
Еще раз благодарен за информацию.
Может Вы уточните, что не получается или что было бы интересно почитать... мне по крайней мере было бы проще рассказывать ...
-
Спасибо за поддержку, могласитесь сами, писать ради того что бы просто писать - графоманство...
Паганель, вы возможно не подумав такое написали...но боюсь Ваше ,,не подумав,, будет достаточно неприятно прочитать тем немногим, но похоже таки очень разбирающимся людям, которые выкладывают здесь информацию, тем более когда пишут своими силами, тратят свое время, но понимают, что записав и выложив именно на этом сайте, эта информация будет полезна многим и найти для себя при необходимости ее будет легче. Если Вы не хотите писать сами, Вам это тяжело, то хотя бы не обижайте тех кто в этот сайт вселяет жизнь...для всех кому пригодиться. Причем безвозмездно. То бишь - даром! Что на сегодня - большая редкость.
-
согласитесь сами, писать ради того что бы просто писать - графоманство...
Не соглашусь... ну это так в качестве небольшого флуда...
-
Способы (формулы) по которым система определяет план зависят от т.е, модели прогноза (константная, тренд, сезон, трендово-сезонная модель) модель прогноза задается в карточке товара, но есть возможность автоматического определения какую модель использовать (по данным расхода прошлых периодов, система сам вычисляет, какую же модель использовать.
несколько раз прочитала. Так и не могу осилить ??? Вы не могли бы как-то более четко сформулировать эту мысль?
-
Может Вы уточните, что не получается или что было бы интересно почитать... мне по крайней мере было бы проще рассказывать ...
Паганель, я вас очень попрошу, хоть я и не являюсь автором темы...пожалуйста добавьте скриншоты с необходимыми полями для выбора. В том числе и в карточках материала. Дело в том, что тема не будет без этого содержать полную информацию. И последующие, кто найдет ссылку на тему не смогут воспользоваться Вашей информацией в полной мере.
-
несколько раз прочитала. Так и не могу осилить ??? Вы не могли бы как-то более четко сформулировать эту мысль?
Ну возможно тут понятнее
http://help.sap.com/saphelp_erp2005/helpdata/ru/7d/c27285454011d182b40000e829fbfe/frameset.htm
-
Ну возможно тут понятнее
http://help.sap.com/saphelp_erp2005/helpdata/ru/7d/c27285454011d182b40000e829fbfe/frameset.htm
Мда...ну в общем все ясно. Спасибо Паганель, Вы мне очень "помогли"...
-
Мда...ну в общем все ясно. Спасибо Паганель, Вы мне очень "помогли"...
Всегда пожалуйста рад "помочь", таким "благодарным" людям
-
Ну не знаю, как это еще можно сказать попроще.
Выше было описано, что система в регулируемом расходе ППМ использует данные прогноза.
Значит перед прогоном ППМ запускают, выполнение прогноза, в ходе которого, система на основании данных расхода прошлых периодов, предсказывает, какой расход будет в будущем.
Как она это делает? Не просто копирует значение из прошлого месяца а использует определенные алгоритмы (формулы, модели) для обработки данных прошлых периодов и «предсказания» будущего. Способ интерпретации (алгоритм) можно указать в карточке товара (см. рис1)
При анализе прошлых значений расхода отслеживаются закономерности, исходя из которых предлагаются различные модели прогноза.
Дополнительно, цитата с курса и рис2
Устойчивая модель используется в случае колебаний значений расхода относительно некоторого постоянного (среднего) значения.
Трендовая модель используется, когда наблюдается постоянный рост или снижение расхода на протяжении длительного периода времени (сопровождается случайными колебаниями).
Сезонная модель применяется в случае повторяющихся с некоторой периодичностью изменений значений расхода относительно некоторого базисного значения.
Сезонно-трендовая модель: сезонные изменения относительно постоянно растущего значения расхода.
Если в изменениях значений расхода не прослеживается ни одна из перечисленных выше закономерностей, говорят о нерегулярных изменениях.
-
Всегда пожалуйста рад "помочь", таким "благодарным" людям
Паганель, я Вам написала спасибо за Ваше направление меня по ссылке повторно.
Ссылка на help.sap.com была Вами дана еще в первом ответе и еще чуть позже тоже.
Поэтому выглядело так, как Вы пытаетесь отмахнуться, раз я не поняла того, как Вы объяснили.
В общем-то консультантам всегда не легко с пользователями (из моих личных наблюдений).
Мне так же трудно объяснить Вам четко и конкретно что именно мне не понятно, как и Вам похоже тяжело объяснить задачу другим (тема - Варианты реализации "Запаса в пути").
Поэтому если Вам сложно, то пожалуйста так и скажите. Не надо больше поссылать по ссылкам, я там уже была, и от того, что не совсем поняла, Ваш ответ прозвучал еще более неприятно.
-
Я думаю, что бы просто обяснить данную тему, нужна обратная связь, и я бы был Вам очень благодарен, если бы Вы задавали вопросы по теме.
-
Итак, если с моделями прогноза все понятно, то еще немного теории, и переходим к более конкретным вещам (со скриншотами, как и обещал :)) т.е. пунктам:
2. Основные данные и предпосылки
3. Как это работает
В регулируемом расходом ППМ, есть такие основные подтипы
- стохастическое
- циклическое
- по точке заказа, которое так же делится на
- ППМ по точке заказа
- ППМ по точке автоматическое
Они, упрощенно, различаются способом использования значений прогноза
- Стохастическое ППМ - данные прогноза, используются как потребности
- Циклическое - аналогично, но про данный тип ППМ выполняется только в определенные дни
- ППМ по точке атоматичесское - значения прогноза используется, как точка заказа.
Немного уточню, что такое точка заказа и ППМ по точке заказа.
Это поле в карточке товара (ОЗМ), в котором указывается количество остатка, при достижении которого, система начинает создавать заявки, что бы восполнить запас. см. рис3.
Обычно это среднее от расхода за период, умноженное на время восстановления запасов (за сколько поставщик привезет товар) Также в точку заказа включен страховой запас.
Основой для ППМ по точке заказа является сравнение доступного складского запаса и поступлений с точкой заказа. Если доступный запас становится меньше точки заказа, начинается выполнение ППМ.
Точка заказа составляется из ожидаемой средней потребности в материале во время восстановления запасов и страхового запаса. При определении точки заказа должны быть учтены следующие значения:
- страховой запас
- предыдущий расход или будущая потребность
- время восстановления запасов
Страховой запас предназначен для покрытия как незапланированного расхода материала во время восстановления запасов, так и дополнительной потребности при отсрочках поставок.
Если заказы клиентов и резервирования вручную имеют отношение к планированию, используется собственный способ ППМ по точке заказа с учетом внешних потребностей.
Т.е. возвращаясь к выше описанному, при ручном ППМ по точке заказа, к-во задается вручную, а при автоматическом система как точку заказа берет данные из прогноза.
-
Всем привет!!!
может кому нить это поможет)
-
Добрый день,
а у меня такой вопрос:
на нашем предприятии используется область планирования завод (все центальные склады) и области планирований подразделений (цеховые склады), используем склады подрядчиков - не входят в склады подразделений, а соответсвенно входят в область планирования завод, также как центальные склады, но возник случай, который я не могу понять. Воощем ППМ работает так, создается потребность - резервирование на цеховом складе, при прогоне ППМ (по области подразделения) создается резервироевание на перемещение в цех, при прогоне ППМ (завод) создается заявка. Иногда у нас создаются резервирования на перемещение на склад подрядчика, в ведомости данную потребность не вижу. Вопрос почему, где и как в складе это настраивается? Исключений в BAdi вроде не нашел...
Спасибо
-
На сколько, я знаю, в складе это не настраивается.
В чем ошибка, так сразу и не скажешь... Но мне кажется, что у Вас что-то не то с проверкой доступности. Какая проверка стоит в карточке товара и какое правило проверки в настройках завода?
Кстати,
создается резервирование на перемещение в цех
Резервирование на 311 ВД?
А этот склад включен в область ППМ?
Можно скриншот md04?
P.S. Попытался воспроизвести у себя такую ситуацию - не получилось, резервирования попадают в ведомость ППМ в любом случае, если только в позиции резервирования не стоит метка конечной поставки.
Посмотрите, возможно, у Вас такая же ситуация?
-
Есть вопрос. что бы не создовать новую тему, источник ППМ, буду писать сдесь. Понадобится для начинающих.
Запустили сап без ППМ (ППМ был настроен). В ОЗМ тип ППМ стоял ND, проверка доступности CH. Решили запусить ППМ. Проверяю карточку и вижу, что в ОЗМ в кнопке ""Значение расхода" стоят данные на будущий период, тоесть сегодня 01.03.11 г. а общий объем расхода стоит на 5 и 4 недели (код периода неделя.)
Ворос, почему эти данный заполинились если тип ППМ стоял ND, и вручную никто не заносил эти значения. Откуда эти значения могли подтянутся.
-
Откуда эти значения могли подтянутся.
На этот вопрос я уже нашла ответ. Значения подтянулись со статистики продаж, при условии, что в ОЗМ стоял тип периода "Неделя". На второй вопрос не нашла ответ.
-
Еще один вопрос. По детерминированому ППМ.
Про регулируемый расходом ППМ очент много инф., в том числе и в sap.help.com. Как было сказано, детерминируемое ППМ - колич-во товара которое хотим получить + дата на какую хотим спрогнозировать, тоесть совокупность значений текущих и будущих потребностей. Вопрос, зачем проводить прогноз mp30/mp31. если детерминированое ППМ не основывается на значениях прошлых периодов (статистике продаж, например).
Паганель упомянул выше, что детериминирование ППМ можно делать mp30/mp31. Есто меня сбило с толку.
Решила провести, при этом удалила в ОЗМ значения расхода и выставли все праметры для детерминированого ППМ, после нажатия кнопки "Выполнить" в тран. mp30, система выдала сообщение, что нет значений прошлых периодов. Система правильно с работала. Но зачем при Детерми. ППМ использовать тран. mp30/mb31. (прогноз), ведь можно сразуже переходить к созданию плановой первичной потребности тран. md61
-
Вопрос, зачем проводить прогноз mp30/mp31. если детерминированое ППМ не основывается на значениях прошлых периодов (статистике продаж, например).
Это где я такое написал? (кнопка цитировать)
-
В детерминируемом ППМ используется еще так называемый прогноз (перед прогоном ППМ, происходит вычисление планируемого к-ва расхода (тр. mp30)
Вот сдесь
-
Вот сдесь
Да, описка, спасибо
-
У нас есть потребности по товару с типом ППМ «Детерминированное ППМ»
Есть страховой запас. Есть доступный остаток. Страховой запас меньше доступного остатка. Планируем на 2 недели. Делаем ППМ. Получаем картину. (Рис 1.)
Преобразуем заявки в заказ (Рис 2)
Что бы покрыть страховой запас нам нужно 5000 кг.
Ждем прихода товара на склад. Делаем еще одну потребность на 6000 кг (Рис 3)
Делаем прогон ППМ. По идеи система должна создать заявку на 6000 кг. Поскольку все потребности, которые у нас были до этого, уже преобразованы в заказы и жду прихода. То есть, нет отрицательного доступного количество. Есть нулевой остаток.
Но система создает заявку не на 6000 кг а на 5000 кг (как предыдущую заявку по покрытию страхового запаса). (Рис 4)
Вопрос по чему именно 5000 кг? Почему создается потребность на страховой запас, котрый уже покрыт ожидающим заказом в пути? Ведь до создания потребности у нас был ноль доступного количества. Почему именно 5000 кг, а не 6000 кг или 300 кг?
-
Попробуй настоить доступность страхового запаса см. рис.
Если Вы используете группы ППМ, в настройках группы есть аналогичная настройка.
-
Добрый день,
у меня возник следующий вопрос,
можно ли сделать, чтобы ППМ рождал заявку на каждую потребность, поясню, сейчас работает так, создаются потребности - резервирования на списание от всех подразделений, к примеру цех1 (рез1: 5 шт, дата потребности 01.03.2011 ), цех2 (рез2: 3 шт дата потребности 01.03.2011), первый прогон ППМ создает резервирования (рез1: 5 шт, дата потребности 01.03.2011 ), цех2 (рез2: 3 шт дата потребности 01.03.2011) на перемещение в цех с центральных складов, второй прогон ППМ по заводу создаст одну объединенную заявку на 8 шт соответственно. Вопрос можно ли как-то сделать, чтобы ППМ создал две заявки на 5 шт и 3 шт?
Спасибо за ответы
-
Честно говоря не пробовал, у меня в свое время возник другой вопрос (как их не группировать :)), поищите, была там какая то настройка связанная с группировкой или объединением потребности....
-
Кстати, кажется есть UserExit в котором можно управлять созданием заявок, посмотрите вот эти расширения:
LMDR2001 ПрогрПользоват к профилям ограничений ОптимОбъединенЗаказов
LMDZU001 Программы пользователя в дополнительном планировании
Если там ничего интересного нет, тогда есть куча BADI и точек расширения, которое тоже неплохо бы просмотреть, транзакция SE18 там веток открывается с расширениями вагон, тока описания нет ни на русском ни английском, так что надо пробовать.
Почему советую искать, мне что-то помниться, что есть точка где этим можно управлять и система будет генерировать данные так как вам надо. Могу и ошибаться, давно было когда в ППМ-е ковырялся, но вот что-то кажется, что встречал похожее.
-
Особенности «русского» ППМ
Идеальный ППМ то что имели ввиду разработчики САП. Мы точно заранее знаем потребности (погрешность в несколько %) и в состоянии их в точно и в срок удовлетворить (опять же с погрешностью не более несколько %). Высочайшая «культура логистики», точные остатки по складам, каждое перемещение материала производиться строго для известной цели (ремонта) и точно в срок списывается (не раньше и не позже). Результат все работает идеально, живем как немцы.
Русский ППМ то что мы пытаемся внедрить. Точность определения потребности совершенно неприемлемая. Насколько закупщики сумеют удовлетворить потребность не ясно (бюрократические препоны + возможное снижение финансирования). На складах полу-бардак (или того хуже сознательное списывание/не списывание в зависимости от текущего «политического момента»).
В настоящий момент разговоры о идеальном ППМ являются чистейшей воды популизмом и не имеет никакого отношения к реальности.
Особенности русского ППМ:
1) Создание заявок прошедшей датой (минимизируется ущерб от несвоевременного закрытия ТОРО-заказов). Не своевременно созданные/деблокированные заявки не удовлетворяются, но если на складе есть свободный запас, он будет зарезервирован.
2) Так как заведомо известно, что значительная часть заявок не будет полностью удовлетворена, производить их закрытие в системе бессмысленно (собственно мы точно и не знаем для какого ремонта будет использован перемещаемый материал). Но т. к. мы все время «смотрим вперед» на 2 месяца судьба предыдущих заявок уже никак не может повлиять на текущий расчет.
3) Ввиду безответственности значительного числа пользователей заявка фиксируется после ее деблокирования (как немцы могут работать без этого не представляю колоссальный уровень компетенции и ответственности)
4) Т. к. значительные ошибки в заявках неизбежны необходимо их как-то компенсировать. Поэтому для закупщиков (УПТК) заявка носит рекомендательный (прогнозный) характер.
5) Ввиду чуждой для немцев системы контроля за расходованием средств (по списанию со складов, а не по денежным тратам) контроль сумм следует производить по стоимости материалов в ТОРО-заказах. Фактом признания их корректности считать утверждение заявки на перемещение в филиал (хотя сумма в ней будет значительно меньшей).
6) Утверждения заявки на закупку в системе носит формальный характер. Единственная польза ее фиксация от дальнейших изменений. Т. к. финансирование труднопрогнозируемо и сроки закупки и размеры партий весьма относительны, закупщики (УПТК) не могут вести свою деятельность в соответствии с формальными процедурами.
7) В данный момент подобное планирование делается (а возможно и делалось ранее) в ручную. Переход к электронной форме:
четко формализует процесс
усиливает контроль и ответственность
снижает количество ошибок по номенклатуре
8) Точность планирования далека от идеала, но скорее всего точнее, чем делали вручную (так как мы все время смотрим на 2 месяца вперед влияние складских ошибок снижается). Основная польза собственно не во внедрении процедуры ППМ, как таковой, а в вынужденном наведении порядка.
9) Обязательным условием наведения порядка является строгий контроль за соответствием отпускаемых ТМЦ заявке. Необходимо определить должностное лицо разрешающее перемещение материалов не соответствующих заявке в связи с «объективными факторами» и принимающее решения о предотвращении их в будущем.
Оригинал папы Яна: http://fatheryan.narod.ru/rusmrp.html
-
Попробуй настоить доступность страхового запаса см. рис.
Если Вы используете группы ППМ, в настройках группы есть аналогичная настройка.
От задвоения страхового запаса избавились, теперь появился еще один вопрос с страховым запасом. Может быть это и не проблема, но я не много не могу понять почему так а не и наче. Значит.
Есть такая ситуация см. рис.1
Время обработки товара 23 дня. Есть три потребности после прогона ППМ система создает 3 заявки - на поплнение страхового запаса и на 2 потребности которые мы внесли. Рис.2
Преобразуем заявку на пополнение страхового запаса в заказ на закупку. Рис.3
Добавляем еще одну потребность на август месяц. И прогоняем ППМ. Рис.4
В следствии чего получаем, что система создает кроме завки на потребность, еще и заявку на пополнение страхового запаса (разбыла заявку на первую петребность на 2 заявки страх.запас и 1-я потребность). Хотя страховой запас у нас уже до этого был пополнен (заказ на закупку).
Эсли это оставить, то получится так, что каждый раз добавляя потребность система будет добавлять заявку на пополение стра.запаса, при этом разбывая самую первую (непреобразованую) заявку на 2 заявки. Итого - будет висеть доступный остаток (сумма страх. запаса).
Может кто-то с этим сталкивался и может мне помоч?
-
Добрый день!
Пытаемся настроить ППМ, очень благодарна за предедущее инфо о ППМ. Жду продолжения
-
Всем привет.
И снова , в n-й раз о ППМ.
А точнее о Прогнозе в ППМ, а еще точнее о Округлениях результатов прогноза.
Самая простая устойчивая модель на 2 периода в перед
Выполняем прогноз, дает некоторое среднее значение, которое отличается от базисного значения за счет "странного округления". Наприм. "Базисное значение" 2.499,357 шт, а полученное прогнозное значение 2.500 шт. Вроде бы должно быть 2.499 или 2.499,36.
Вообще не понятно почему именно так округляет, а так же почему вообще эти данные разные, хотя должны быть равны, ведь я не сравниваю наприм. базисное значение с исправленным прогнозным значением, кото-е может отличаться за счет корректировочных коээф.?!
-
Наприм. "Базисное значение" 2.499,357 шт, а полученное прогнозное значение 2.500 шт. Вроде бы должно быть 2.499 или 2.499,36.
Вообще-то в ракурсе ППМ1 есть поле, которое называется "Профиль округления", вот там можно настроить как и что нужно округлять при расчетах.
-
Вообще-то в ракурсе ППМ1 есть поле, которое называется "Профиль округления", вот там можно настроить как и что нужно округлять при расчетах.
- Уточнение: включен Retail, поэтому место ракурса ППМ1 и остальных ракурсов есть ракурс "Логистика: Центр распределения", где действительно есть профиль округления
- Я смотрела, пыталась использовать данный профиль для прогнозирования, перед тем как изначально писать, но положительного результата это не дало. Если я не ошибаюсь, то данный профиль не работает на прогнозирование.
Но я еще раз пересмотрела его.
И вот, что у меня получилось.
Прогнозы, и данные по продажам в ОЗМ представлены в базовой единице, составляются в базовой единице, в нашем примере - штука.
В настройке профиля есть метод округление и правило округление. Допустим, что метод округления выбран "Округлить до единицы заказа/сбыта/логистической единицы измерения", и в карточке товара штука отвечает за все эти ЕИ и базисную тоже. Правило настроено, округлять в меньшую сторону. Если промоделировать профиль, то при занесении значения 2499,357, выдает 2.544 и в поле "Округление ЕИ" ставит ящик, хотя везде фигурирует штука.
-
результата это не дало. Если я не ошибаюсь, то данный профиль не работает на прогнозирование.
Не знаю, если честно с ритейлом как-то не сталкивался. Профиль округления работает вроде как для расчета размера партии, после получения необходимого количества при прогоне ППМ. Ниже описание из курса вроде как.
-
Кто-то настраивал свои сообщения об особых ситуациях в ППМ? В "Определении и группировка сообщение об особых ситуациях" можно только определить приоритет, объединить в группы..., но создать свое условие нет возможности.
-
Кто-то настраивал свои сообщения об особых ситуациях в ППМ? -> но создать свое условие нет возможности.
Ну вот вы и сами ответили на свой вопрос. Ну добавите вы свой код сообщения а дальше что? Обработчик данного кода где предполагается написать и кто это будет делать?
PS: Кстати, по поводу профиля округления, что скажете?
-
Не знаю, если честно с ритейлом как-то не сталкивался. Профиль округления работает вроде как для расчета размера партии, после получения необходимого количества при прогоне ППМ. Ниже описание из курса вроде как.
У меня была ОЗМ в которой шт - БЕИ, ящ - ЕИЗ, ПЕИ, ЛЕИ. Прогноз делает, стандартом, в штуках.
Стоит профиль округления, или стоит значение округление - на расчет прогнозных нетто значений это не как не влияло.
А вот если делать планирование, md04, то округление влияет на расчет нетто потребности в ящике. Наприм. 8 шт в 1 ящ, при включенном округлении показывало 398 шт или 50 ящ, а при не включенном округлении 398 шт или 49,750 ящиков.
А мне надо было что бы округлении срабатывало при прогнозировании, mp30.
-
Будем дальше ломать стандартный ППМ. Ломать не строить.
Сейчас рассматриваем как можно заставить корректировочные (поправочные) коээф. работать на нас а не против требований бизнеса.
Когда делается прогнозирование mp30, есть коээф. которое по умолчанию = 0, но при настройке они будут умножатся на прогнозное значение и выдавать уже необходимое прогнозное значение, которо-е потом будет отображено/участвовать в планировании в ведомости ППМ.
Стандартная настройка SPRO-УПМ-Регулируемое расходом ППМ-Планирование- Определить коээф. корректировки для прогноза (у меня тес.система на укр. языке, поэтому перевод может не совпадать с реальностью, но путь тот же).
Где для Завода (одно из ключевых поле) указывается код периода, период, месяц и коэффициент.
Наприм. рис1.
Нам нужно что бы не только по заводу указывался коээф., а "завод-код ОЗМ". Допустим это делаем через свою z таблицу (в стандарт не можем засунуть).
Вопрос остается только как заставить систему при расчете прогнозного значения взять данные не из стандартной таблицы, а из Z-таблицы. Может есть какое-то замещение или bapi...?
-
Вопрос остается только как заставить систему при расчете прогнозного значения взять данные не из стандартной таблицы, а из Z-таблицы. Может есть какое-то замещение или bapi...?
Посмотрите вот эти экзиты, у меня сейчас нет доступа к системам где бы можно это было промоделировать и IDES тоже нет. Поэтому чем могу тем помогаю 8), особенно второй экзит интересен. Работают при вызове MP30
LMDR2001 Ел.пошир.корист. - профілі обмежен.для оптиміз.об'єд.замов.
LMDZU001 Елементи поширення користувача у додатковому плануванні
-
Кто-то объединял заявки в одну при прогоне ППМ (md01/md02) по товару?
-
Посмотрите вот эти экзиты, у меня сейчас нет доступа к системам где бы можно это было промоделировать и IDES тоже нет. Поэтому чем могу тем помогаю 8), особенно второй экзит интересен. Работают при вызове MP30
LMDR2001 Ел.пошир.корист. - профілі обмежен.для оптиміз.об'єд.замов.
LMDZU001 Елементи поширення користувача у додатковому плануванні
Программеры сказали, что не подходит. :-\
-
Кто-то объединял заявки в одну при прогоне ППМ (md01/md02) по товару?
Ранее использовался метод расчета размера партии EX - точный размер партии. Сейчас использую MB - месячный размер партии. В настройке самого MB количество периодов - 3, нам нужно что бы прогнозы за 3 месяца объединялись в одну заявку. В курсе SCM525 об этом написано, только не указаны минусы.
-
Еще интересная информация, которой делюсь с Вами, да и что бы самой потом не искать везде.
1.Если необходимо вытащить прогнозные значения (рассчитанные скорректированные), которо-е выполнялись в MP30 или в mm42, то это можно сделать следующим образом
Таблица-поле (запускать в порядке как написано).
MAPR- PNUM1 (PNUM1 у товара один)
PROP- PNUM1 (узнаем значение PNUM2)
PROW- PNUM2
2. Если необходимо вытащить фактические (общие, скорректированные) данные продаж, которые находятся в mm42 на вкладке "Логистика:Центр Распределения", то это можно вытащить из таблицы MVER. Поле в данной таблице зависит от того какой Вам значение необходимо.
Так же обратите внимание, что данная таблица разбита на 4 строки, и так само пронумерована, а поле, наприм.GSV01-GSV013. Это означает, что если у вас период не месяц,, а неделя, то 4*13=52 недели. Наприм. 2013г. содержит 53 недели, но только 2 дня находятся на 53 недели. Как запишутся эти два дня в 2013г., когда всего 43 поля для недель - непонятно, посмотрим после новогодних праздников.
если Увас взят период месяц, то нумерация первого месяца начинается с GSV01 - проверено.
-
Теперь нужна помощь.
После прогона ППМ создается заявка в которой срок обработки ПМ - 0, хотя в карточке товара указано 2 дня. Есть скрин с начала внедрения SAP, когда еще были консультанты, так там указано значение из карточки. Что могло вызвать перезатирание. От этого, походу у меня неверно считаются даты поставки в заявке.
-
Теперь нужна помощь.
После прогона ППМ создается заявка в которой срок обработки ПМ - 0, хотя в карточке товара указано 2 дня. Есть скрин с начала внедрения SAP, когда еще были консультанты, так там указано значение из карточки. Что могло вызвать перезатирание. От этого, походу у меня неверно считаются даты поставки в заявке.
Перезатирание вызывает настройка SPRO-УПМ-ППМ, рег.расходом-Параметры завода-Общие настройки завода. Для конкретного завода в кнопке "Определения планового срока поставки" указан индикатор.
-
Регулируемое расходом ППМ, основано на том, что к-во потребности вычисляется на основе статистики расхода (например продаж) материала.
Т.е. во время отпуска материала в производство (если у Вас производственная система) или во время продаж (если
у вас розница, опт), система фиксирует расход (записывает в карточке материала, к-во за период, за какой период хранить статистику расхода, так же задается в карточке материала (день, месяц, год).
Например, у нас стоит код неделя и карточке материала имеем следующую картину
1 (нед) - 100
2 (нед) - 100
3 (нед) - 300
Уточнение по расходу.
Расход в SAP - это все что идет со знаком (-) свободно используемого запаса (не блокированного некотроля качества). И эти данные обновляются каждый раз в ОЗМ.
-
Кто-то делал ППМ одного и того же товара на разных заводах SAP? Заявки создаются как для Завода №1 так и для Завода №2. Объединить эти заявки в один заказ на закупку - SAP позволяет. Но это полный бред.
У кого-то что-то подобное было?
P.S. У меня не чистое производство "PP", - ММ в Retail с использованием ППМ по курсу 525.
-
Кто-то делал ППМ одного и того же товара на разных заводах SAP? Заявки создаются как для Завода №1 так и для Завода №2. Объединить эти заявки в один заказ на закупку - SAP позволяет. Но это полный бред.
У кого-то что-то подобное было?
P.S. У меня не чистое производство "PP", - ММ в Retail с использованием ППМ по курсу 525.
Да оно как бы все равно и там и там один и тот же ППМ, но советуют настройку делать через ветку производства, там параметров больше открыто. Далее что касается основного вопроса, а в чем бред? Вы понимаете что технически объединить две позиции заявки в одну позицию заказа в текущей реализации не возможно, так как в позиции стоит ссылка на заявку, соответственно сделать в одной позиции ссылку на две заявки не возможно, поэтому я бы наверное сделал так. Указал завод 1 основным заводом закупки, а завод 2 сделал бы при прогоне чтобы генерировались резервирования на перемещение запаса, т.е. завод 1 для него будет поставщиком. Таким образом прогнав сначала ППМ на заводе 2 получим резервирования на пополнение запаса завода 2 с завода 1, далее прогнав ППМ на заводе 1 получим общую сумму закупки с учетом резервирований на перемещение запаса на завод 2. Как-то так 8)
-
Да оно как бы все равно и там и там один и тот же ППМ, но советуют настройку делать через ветку производства, там параметров больше открыто. Далее что касается основного вопроса, а в чем бред? Вы понимаете что технически объединить две позиции заявки в одну позицию заказа в текущей реализации не возможно, так как в позиции стоит ссылка на заявку, соответственно сделать в одной позиции ссылку на две заявки не возможно, поэтому я бы наверное сделал так. Указал завод 1 основным заводом закупки, а завод 2 сделал бы при прогоне чтобы генерировались резервирования на перемещение запаса, т.е. завод 1 для него будет поставщиком. Таким образом прогнав сначала ППМ на заводе 2 получим резервирования на пополнение запаса завода 2 с завода 1, далее прогнав ППМ на заводе 1 получим общую сумму закупки с учетом резервирований на перемещение запаса на завод 2. Как-то так 8)
Спасибо, попробовала. Я вчера тоже смотрела, но не в сторону использования специального вида заготовки с типом перемещение, а с типом производство на альтернативном заводе. Не подошёл.
Что касается с заготовкой на перемещение, то:
Тогда для завода 1 ,будет две заявки одна с типом позиции U (перемещение), вторая - (обычная). Как потом делать обычную закупку по этим двум заявкам и одним общим заказом на Завод 1? Ведь в заказе все-равно получается два завода.
У нас два разных по системе завода водной БЕ, но физически это один и тот же. Перемещение м/д заводами через 311 ВД. Между заводами сущ. одинаковые товары. Но, заказ, до ППМ, делался всегда только на один завод, а потом перемещение. Соот. считалась общая потребность двух заводов в Excel.
-
Да оно как бы все равно и там и там один и тот же ППМ
Не помню писала я здесь или нет, но наприм. области ППМ в Retail - не работают. Это официальная информация из SAP.
-
Тогда для завода 1 ,будет две заявки одна с типом позиции U (перемещение), вторая - (обычная). Как потом делать обычную закупку по этим двум заявкам и одним общим заказом на Завод 1? Ведь в заказе все-равно получается два завода.
Настройте чтобы создавался документ резервирования на перемещение запаса, а не заявка на перемещение запаса. Тогда по резервированиям будете просто формировать документы движения на перемещение.
-
Проверяю ППМ на новый период. Вот что получается.
На 29.11.13г. был открыт в скл. учете 11 месяц - текущий, 10 -предыдущий.
Физически на 29.11.13г. сущ. открытые потребности на 11/2013, 12/2013, 01/2014
Физически на 02.12.13, в ведомости ППМ (планирование еще 02.12.13г. не было) есть только потребности на 12/2013 и 01/2014.
Я так понимаю, что физически сист. по календарю смотрит, что сегодня 02.12.13, значит потребность на 11/2013 - не актуальна и не будет покрыта. Есть уц кого-то какие-то еще варианты?
------------------------------
Дальше.
Так как физически, т.е сегодня, у нас 12/2013 и он в скл. учете не открыт, а док. проводить надо за 12/2013, то открываем в MMPV 12/2013г. Тогда у нас 12/2013 - текущий, а 11/2013 - предыдущий.
Заходим в ведомость ППМ, планирования еще не было. В ведомости потребность только за 01/2014. Т.е при открытии 12/2013 в MMPV потребность за 12/2013 была затерта, хотя 12/2013 - тек. месяц.
Может, при запуске MMPV необходимо, что-то указывать, чтобы потребности за тек. месяц оставались?
-
Настройте чтобы создавался документ резервирования на перемещение запаса, а не заявка на перемещение запаса. Тогда по резервированиям будете просто формировать документы движения на перемещение.
Однако к сожалению, специальный вид заготовки U, когда создается документ резервирования на перемещение запаса, работает только при использовании областей планирования, который по вашим словам в ритейл системах не работают, а поэтому вам этот вариант не поможет к сожалению.
Заготовка материалов, планируемых в области планирования потребности,
может производиться с использованием специального вида заготовки
“Перемещение из завода в область планирования потребности”.
Для этого необходимо создать код специального вида заготовки в
пользовательской настройке ППМ (шаг пользовательской настройки
“Определение специального вида заготовки”), содержащий вид заготовки
“F” (заготовка на стороне), специальный вид заготовки “U” (перемещение
запаса) и собственный завод в качестве завода перемещения запаса.
Этот код специального вида заготовки вводится в сегмент области ППМ
соответствующей области планирования потребности.
Перемещение запаса выполняется аналогично перемещению в ППМ
на уровне склада: резервирование перемещаемого запаса создается на
уровне области планирования потребности, а на основе резервирования
перемещаемого запаса создается резервирование на уровне завода. После
завершения заготовки на заводе в области планирования потребности
выполняется проводка переноса в управлении запасами со ссылкой на
резервирование перемещаемого запаса.
-
Заходим в ведомость ППМ, планирования еще не было. В ведомости потребность только за 01/2014. Т.е при открытии 12/2013 в MMPV потребность за 12/2013 была затерта, хотя 12/2013 - тек. месяц.
Может я что-то путаю, но так как планирования небыло то ведомость планирования:
"Ведомость ППМ включает результат последнего прогона планирования и поэтому является статической: изменения, внесенные после прогона планирования, не видны."
Поэтому я не очень понимаю как вы видите какие-то изменения, если само планирование вы не выполняете. Может вы имеете в виду:
"Текущая ведомость потребности/запасов – это динамический список, который содержит фактические уровни запаса, потребности и поступлений. Изменения отображаются немедленно при вызове текущей ведомости потребности/запасов или при считывании
элементов на текущем экране ведомости потребности/запасов из базы данных в реальном времени после выбора функции “Обновить”.
Может, при запуске MMPV необходимо, что-то указывать, чтобы потребности за тек. месяц оставались?
Нет эта функция просто открывает новый период проводки, и больше ничего. При этом с версии 4.6 оно вообще фактически делает только маркировку какой период считать текущим и все, поэтому смена периода происходит фактически мгновенно.
-
Может я что-то путаю, но так как планирования небыло то ведомость планирования:
"Ведомость ППМ включает результат последнего прогона планирования и поэтому является статической: изменения, внесенные после прогона планирования, не видны."
Поэтому я не очень понимаю как вы видите какие-то изменения, если само планирование вы не выполняете. Может вы имеете в виду:
"Текущая ведомость потребности/запасов – это динамический список, который содержит фактические уровни запаса, потребности и поступлений. Изменения отображаются немедленно при вызове текущей ведомости потребности/запасов или при считывании
элементов на текущем экране ведомости потребности/запасов из базы данных в реальном времени после выбора функции “Обновить”.
Нет эта функция просто открывает новый период проводки, и больше ничего. При этом с версии 4.6 оно вообще фактически делает только маркировку какой период считать текущим и все, поэтому смена периода происходит фактически мгновенно.
Текущая ведомость потребности/запасов md04
-
Запланированная дата поставки в MD04
Есть три потребности на 12/2013, 01/2014, 02/2014. На 2 и 3 потребность нам уже не хватит запаса - создастся заявка.
Данные:
Расчет размера партии - месячный (кол.периодов 3).
Время обработки товара в mm42 - 3 дня
Плановое время поставки в mm 42- 30 дней (1 вариант) и 23 дня (2 вариант)
Время обработки заявки в заказ, пока, - 0 дней.
Дата запуска ППМ 06.12.13.
Выходные дни по производственному и праздничному календарю 01/2014 и 07/2014
1 вариант
06.12.13+30+3+0=10.01.14
2 вариант
06.12.13+23+3+0=02.01.14 (01.01.14 - праздничный выходной)
По второму варианту система рассчитывает запланированную дату поставки - 03.01.14. Где я что-то упускаю, то у меня для второго варианта не выходит?
-
2 вариант
06.12.13+23+3+0=02.01.14 (01.01.14 - праздничный выходной)
По второму варианту система рассчитывает запланированную дату поставки - 03.01.14. Где я что-то упускаю, то у меня для второго варианта не выходит?
Ну 06.12.13+23 = 29.12.2013, теперь 3 дня на обработку товара, т.е. 30.12, 31.12 потом 01.01 праздник (пропускаем) и 02.01. Значит товар будет готов 03.01.2014., т.е. 3 дня.. это 3 дня, полных, т.е. 02.01.2014 это еще третий день обработки по вашей формуле 3 дня на время обработки товара, так что правильно вам система говорит что товар будет готов на 03.01.2014
По первой формуле тоже 10.01 выходи потому что 07 выходной, поэтому 30 дней это 05.01 получается а дальше обработка 06, 08 и 09, три дня с одним выходным, вот и выходит что товар будет готов 10.01
PS: У меня сейчас нет доступного IDES под рукой, так что даже и проверить негде, но по датам вроде как все правильно выходит.
-
Как у Вас работает таблица PROP? А именно, сколько указателей результата PNUM2 отображается для каждого указателя PNUM1?
У меня для PNUM1 только 3 PNUM2. Т.е. если каждый месяц делаю прогноз, то каждый последний номер PNUM2 затирается, а первый номер, что был до прогноза становится не 00 версия, а 01 версия.
Просто мне кажется, что данная таблица должна содержать все значения, для того, что бы можно было вытянутся исторические плановые прогнозы, т.е прогнозы прошлых периодов.
-
Как у Вас работает таблица PROP? А именно, сколько указателей результата PNUM2 отображается для каждого указателя PNUM1?
У меня для PNUM1 только 3 PNUM2.
Ну исходя из того, что в IDES тоже только максимум 3 записи, скорее всего что:
Просто мне кажется, что данная таблица должна содержать все значения
вам кажется не правильно. Или точнее разработчикам SAP это кажется по другому.
-
Сегодня увидели, случайно, что отсутствует нумерация позиций в заявке, которая создана после прогона планирования.
Я думаю, что если планирование на каждый товар создает свою заявку, то логично не вести нумерацию позиций в заявке. Может кто-то считает по другому, или у кого-то все-таки, стандартно, ведется нумерация позиции?
Заметили это когда стал вопрос об установке метку "удаления" в заявке на уровне позиций - массово.
Вспомнила, как Uukrul писал об транзакции MASS. Попробовала ее использовать. Повезло, объект, который отвечает за изменение заявок был в MASS.
Но в самом объекте BUS2105 отсутствовало поле "EBAN-LOEKZ". В нетте нашла хорошую инструкцию по добавление нужных полей для объекта в транзакцию MASS. Если Uukrul разрешит выложить ссылку, выложу, а описывать все со скринами - нет пока времени. Но вкратце, поле добавили через SM30 в ракурс MASSFLDLST.
Теперь осталось запустить MASS выбрать объект BUS2105, выбрать EBAN, указать нужные заявки, выбрать поле LOEKZ - поставить X индикатор удаления.
Но не сработало.
После того, как установили индикатор Xи запустили транзакцию для выполнения - выскочила ошибка 06360 "Требуется ввести EBLN".
В таб. EBAN EBLN это №заказа на закупку. При этом если менять другое поле то та же ошибка. Если менять что-то в заявке, которая создана не через ППМ - все работает.
При чем здесь заказ на закупку? Есть у кого-то соображения?
-
В теме "Исключение расхода из ППМ" Uukrul писал
"Вообще еще есть закладка ППМ4 и там можно поставить для склада галку типа данные этого склада не учитываются в ППМ, тогда можно обойтись без использования областей, но склад отключить для ППМ."
А если № последовательностей экранов в ОЗМ был выбран для работы не "01" Промышленный стандарт", а наприм. "03 "Стандарт для торговли", то как необходимые поля, которые есть на вкладке "ППМ4" (для промышленности) будут называться на "Логистике: Центр распределения" (для торговли)?
просто я чета такого не видела у себя в "торговле".
-
Но в самом объекте BUS2105 отсутствовало поле "EBAN-LOEKZ". В нетте нашла хорошую инструкцию по добавление нужных полей для объекта в транзакцию MASS. Если Uukrul разрешит выложить ссылку, выложу, а описывать все со скринами - нет пока времени. Но
Да приводи, интересно просто... что за статья.
А если № последовательностей экранов в ОЗМ был выбран для работы не "01" Промышленный стандарт", а наприм. "03 "Стандарт для торговли", то как необходимые поля, которые есть на вкладке "ППМ4" (для промышленности) будут называться на "Логистике: Центр распределения" (для торговли)?
Ну на рисунке ниже видно как оно выглядит в ERP, это поле MARD-DISKZ, поищите у себя в системе вообще это есть?
-
Да приводи, интересно просто... что за статья.
http://scn.sap.com/docs/DOC-25758 - mass
-
http://scn.sap.com/docs/DOC-25758 - mass
Ну там частный случай описан и то работать он будет не всегда к сожалению, так как зависти от реализации маппинга полей. Вообще можно вот этим путем добавлять свои объекты: http://sapforum.biz/index.php?topic=2021.10
-
Всем привет.
Вроде бы как все было решено с ППМ, а не тут то было.
Нужен совет.
Допустим есть 2 товара c тип ппм не ND.
После прогона ППМ (md01) сформировались заявки на открытые потребности. Эти заявки нужно преобразовать в заказ на закупку. По 1 товару 400 ящ требуемого количества заявки; по 2 товару 500 ящ требуемого количества заявки. В итоге заказ должен быть на 900ящ - согласно ППМ.
Но!
Заказ должен быть создан не на 900 ящ, а на 1000ящ, поскольку именно этих товаров (определенного поставщика, группы товаров) должно быть контейнере. Т.е заказ кратный контейнеру, а не тому что создал ППМ. В карточке товара ведется ЕИ шт (базовая) ящ (продажная).
Есть какие-то идеи?
-
Заказ должен быть создан не на 900 ящ, а на 1000ящ, поскольку именно этих товаров (определенного поставщика, группы товаров) должно быть контейнере. Т.е заказ кратный контейнеру, а не тому что создал ППМ. В карточке товара ведется ЕИ шт (базовая) ящ (продажная).
Ну тут вам обычный ППМ не поможет, поскольку он базируется на работы с единицей материала, т.е. при прогоне ППМ зависимости запасов одной ОЗМ от другой ОЗМ не строится. Поэтому когда система рассчитывает размер партии, она базируется на текущей потребности обрабатываемого материала, без учета параметров закупки других ППМ. Ну тут еще проблема, что такая обработка не может быть проведена при прогоне ППМ, это уже какая-то постобработка, когда все материала рассчитаны, количества закупки зафиксированы.
Есть какие-то идеи?
Да элементарно ватсон, абап в руки, т.е. делаем настройку групп материалов и минимальный размер лота, по аналогии со стандартной настройкой ППМ для материала, но в данном случае это делаем для группы. Далее после формирования всех заявок запускаем программу которая по нашим настроенным правилам корректирует запасы материалов. Тут кстати сразу надо учитывать какой материал добавлять в лоте, например добавлять последний материал в лоте или же пропорционально добавлять, но с учетом настройки лотов из ОЗМ и т.д. Короче, по моей оценке дней 10, на всю красоту для решения проблемы. Да только АБАП, но кто сказал что будет шара 8)
-
Да элементарно ватсон, абап в руки, т.е. делаем настройку групп материалов и минимальный размер лота, по аналогии со стандартной настройкой ППМ для материала, но в данном случае это делаем для группы. Далее после формирования всех заявок запускаем программу которая по нашим настроенным правилам корректирует запасы материалов. Тут кстати сразу надо учитывать какой материал добавлять в лоте, например добавлять последний материал в лоте или же пропорционально добавлять, но с учетом настройки лотов из ОЗМ и т.д. Короче, по моей оценке дней 10, на всю красоту для решения проблемы. Да только АБАП, но кто сказал что будет шара 8)
Можно уточнить? А то я что-то дремлю.
делаем настройку групп материалов и минимальный размер лота, по аналогии со стандартной настройкой ППМ для материала, но в данном случае это делаем для группы.
Это в SPRO или АБАП? Что имелось в виду по аналогии со стандарт. настрой. ППМ для материала - т.е. параметры, которые заносятся в ОЗМ для ППМ?
Далее после формирования всех заявок
Заявки будут формироваться по отдельному товару и рассчитанной потребности как есть сейчас, а далее обрабатываться программой, чтобы докрутить необходимое количество?
-
...
Да элементарно ватсон,...
Самое главное забыла спасибо за наводку.
-
Можно уточнить? А то я что-то дремлю.Это в SPRO или АБАП? Что имелось в виду по аналогии со стандарт. настрой. ППМ для материала - т.е. параметры, которые заносятся в ОЗМ для ППМ?
Ну т.е. берем пишем программу на абапе. Для гибкости работы делаем свои настроечные таблицы, в которых собственно определяем алгоритмы группировки данных и расчета лимитов. В общем чистая разработка.
Заявки будут формироваться по отдельному товару и рассчитанной потребности как есть сейчас, а далее обрабатываться программой, чтобы докрутить необходимое количество?
Да именно, но там не так все просто, начиная с того, что как определять какой товар из группы увеличивать в поставке? По каким правилам, как согласовывать это с лимитами заданными в ППМ для ОЗМ и т.д. Короче, разработка, степень сложности средняя. Оценочное время 10 дней.