Комментарий от 13 октября 2011, 20:11:

«

1. Для того, чтобы пользователи при проведении проверки доступности не блокировали друг друга  необходимо произвести соответствующую настройку в системе SAP с помощью транзакции OVZ1. Как правило бизнес – пользователям не имеют доступа к данной транзакции. За помощью в реализации данной настройки Вам следует обратиться в отдел ИТ своей компании.
2. Да, такое решение реализуемо. Для этого необходимо внедрение модуля APO (расширенное планирование и оптимизация). Без модуля APO возможно автоматическое создание заказов на перемещение с заранее определенными источниками поставок (складов), без возможности автоматического определения «лучшего» для поставки склада. Для такого решения склады должны быть определены как отдельные области ППМ. За помощью в реализации этой настройки Вам также следует обратиться в отдел ИТ своей компании.

»

Комментарий от 9 мая 2011, 21:14:

«Спасибо, поправил.»

Комментарий от 22 марта 2011, 09:51:

«Авизо об отправке - это входящая поставка
Накладные - исходящая поставка
Зависимые резервирования - это потребности РР/РМ заказов
Потребности отзыва - заказы/заявки на перемещение.»

Комментарий от 22 марта 2011, 09:23:

«Да, это значит, что для сбытовых заказов и поставок объем проверки зависит только от материала (группы проверки).»

Комментарий от 27 августа 2010, 09:25:

«Статья неплохая, но читается сложно.
Так же, было бы целесообразно, указать, какие из описываемых методов есть в ECC (как было замечено в комментарии ранее).
 
Как ни странно, в ECC возможно практически все, что описано выше используя стандартную функциональности или минимальные доработки.
 
1) Фиксированное количество страхового запаса так же поддерживается в ECC. Для этого необходимо просто указать поле Страховой запас (MARC-EISBE).
 
2) Обеспеченность запасами поддерживается в ECC. Для использования необходимо указать в поле "Страховое время/ФактОборЗап"(MARC-SHZET) в рабочих днях. Так же необходимо используя индикатор Страховое время(MARC-SHFLG) указать, какая потребность будет "отодвигаться" - первичная или все. Кстати, данная возможность не описана. Не думаю, что это нельзя реализовать в APO.
Альтернативно, можно использовать профиль страхового времни (MARC-SHPRO), который можно использовать для того, чтобы задавать страховое время с привязкой к жестким периодам по датам.
 
3) Максимальное количество из фиксированного количества и обеспеченности запасами. Данного метода в ECC нет.
 
4) Страховой запас, как прогноз/потребность. Данный способ можно так же аналогично реализовать в MRP. Например, используя ведение дополнительных первичных потребностей по данному материалу в отдельной версии. Это вообще универсальный способ сделать практически любую модель, т.к. всегда можно написать АВАР программу по формированию данной потребности по любому алгоритму, и просто запускать ее перед кажжым запуском ППМ.
 
5) Статистический метод. В ЕСС можно так же использовать уровень сервисного обслуживания (указывается в ОЗМ поле MARC-MARC-LGRAD - уровень обеспеченности поставками) используя который на основании исторически-прогнозных данных может рассчитываться страховой запас.
 
6) Гибкое, экономически выгодное поддержание запаса. Очень похожая функциональность есть в ЕСС - в ОЗМ можно указать профиль динамической обеспеченности (MARC-RWPRO), который так же определяет методы расчета средней дневной потребности и уровни поддержания запаса в днях. Чего нет в стандарте - это учета количество дней распределения страхового запаса. Но мне кажется, что похожего результата можно добиться "играясь" имеющимися настройками.»

Комментарий от 17 июля 2010, 18:14:

«Неплохая статья. Для тех, кто первый раз сталкивается с загрузкой остатков - может быть полезной. »

Комментарий от 17 июля 2010, 16:27:

«Рекомендации понятны. И скорее всего, действительно имеют место быть. Но, они как-то все вокруг ведения основных данных: пункты 1, 2, 6, 9 и 10 - это по сути все о ведении основных данных.
Пункт 3 - это понятно, но слишком очевидно чтобы быть дельной рекомендацией.
Пункт 5 - по сути частный случай пункта 3.
Пункты 4, 7 и 8 - рекомендации относительно производительности. Это полезные рекомендации, особенно для тех, кто не имел опыта продуктивных эксплуатаций.
 
К сожаление не описано ничего касательно именно самой функциональности SNP. Видимо это было за рамками того, что автор хотел описать в статье, но тем не менее - это по сути именно то, ради чего ставят АРО. Систему не ставят чтобы озадачиться ведением основных данных или оптимизацией быстродействия. Основная задача SNP - оптимизация долгосрочного и среднесрочного планирования. А особенности и рекомендации именно применение оптимизационных алгоритмов APO в данной статье не описаны. »

Комментарий от 16 июля 2010, 16:06:

«Есть программа для поиска расширений, которая делает все описанные действия и не только их.
Исходник можно взять например тут: http://wiki.sdn.sap.com/wiki/display/Snippets/Find+User-exits,+BADIs,+BTEs,+Etc+by+TCode+or+Program»

Комментарий от 16 июля 2010, 12:14:

«Удобная функция. В российских реалиях может быть применена для копирования номера ГТД партии импортного сырья в признак партии готовой продукции, что часто требуется заказчиком.»

Комментарий от 16 июля 2010, 11:25:

«Проблема того, что APO до версии 4.1 не видел заказов ТОРО, действительно могла быть актуальной. И описанная функциональность, действительно, будет востребована бизнесом.
 
Хотелось бы сделать несколько отступлений по возможностям интеграции без APO и потенциальные ситуации, которые предложенная интеграция не решает.
 
Стандартаня интеграция модулей PP и PM при ведении основных данных так, как это описано в статье, позволяет при балансировке производственных мощностей в CM25 видеть данные о ремонтах согласно РМ-заказам. Поэтому реализация данной функции в АРО является, по сути, дублированием имеющейся в ERP. Хотя, безусловно, данное дублирование требуется, т.к. планирование должно проводиться в одной системе, и APO PP/DS более предпочтительно.
 
Аналогичная ситуация и с планированием материалов для заказов ТОРО. Стандартный MRP ERP системы видел потребность как ТОРО заказов, так и производственных. Опять-таки,  данное дублирование требуется, т.к. планирование должно проводиться в одной системе.
 
Чего нет в данной интеграции, и что это не позволит сделать: интеграция основана на заказе ТОРО - это означает, что план ТОРО никак не интегрирован в систему планирования АРО.
 
Де факто, в жизни ремонты не проводятся согласно некому четкому графику, а разрешены различные отклонения, чтобы оптимально подстроить сроки ремонта под производственную программу. И потенциально, от АРО (например оптимизатора) можно было бы ожидать предложения о наиболее эффективном времени проведения ремонта с учетом производственного фактора. К сожалению, этого нет.
 
Проблема выбора оптимального времени может быть усложнена тем, что потенциально, для более быстрого проведения ремонта, ремонтные службы могут увеличивать свою производительность или за счет сверхурочной работы, или привлечения подрядчика. Понятно, что это потребует дополнительных затрат (с точки зрения АРО - у ресурса создается дополнительные Capacity Variant). И в производстве оптимизатор APO умеет выбирать оптимальный вариант использования мощности. На сколько я понимаю, для ТОРО заказов эта задача пока не решается.
 
Кроме того, до тех пор, пока по плану ТОРО не будет сделан отзыв, и не будет создан заказ ни ERP ни APO не видят потребности в материалах. С одной стороны это логично. Но с другой стороны, как только заказ создан, ERP перестает перепланировать сроки проведения ремонта на соответствующие новым реалиям (например, если ремонтная стратегия по наработке часов). И АРО не помогает решить этой задачи. »

Комментарий от 16 июля 2010, 10:47:

«Многое конечно написано по делу. Не понтяно - для кого эта статья. Сложилось впечатление, что тот, кто не понимает/не сталкивался/не знает того, о чем написно в статье реально ничего дополнительного для себя не подчерпнет. Где-то будет просто не понтяно о чем речь, где-то даже не будет видна проблема, которую пытается объяснить автор. В статье не хватает реальных примеров, реальных аппеляций к опыту автора и не растывлены \"акценты\" на важность тех или иных аспектов.»