Крайне полезной для меня оказалась статья, все очень подробно и грамотно расписано. Хотелось бы еще описание ситуации не только последовательного изготовления на разных заводах, но еже и при возврате полуфабриката на исходный завод: завод1 -> завод2 -> завод1.

спасибо за статью.
абзац ШАГ2 я бы немного скорректировал для лучшего восприятия читателем:
Шаг 2.
(Общее описание процесса)На втором шаге выполняется вызов программы периодического переноса данных и сохранение варианта экрана выбора для объекта LSMW, который требуется выполнить.
 
(Наименование объекта) Техническое имя программы периодического переноса данных LSMW – /SAPDMC/SAP_LSMW_INTERFACE
 
(Детализация процесса): Вызов этой программы в целях данной статьи осуществляется на экране настройки LSMW “Frame Program for Periodic Data Transfer”. (рис.3)
 
(Указание конкретного действия) Создайте вариант экрана выбора для программы периодического переноса данных, для этого сохраните вариант экрана выбора с помощью кнопки “Save” в верхней области экрана. В результате откроется экран “Variant Attributes” (Рис. 4).

В принципе описано все понятно и доходчиво. Единственное, на что не обратили должного внимания, так это \"Activity Update Relevant to Price Determination = 2\" (т.е. ведение фактического тарифа работ в регистре материалов). В этом случае нарушается принятая последовательность закрытия периода в контроллинге, т.к. переоценка производственных заказов по фактическим тарифам не происходит, что соответственно ведет к тому, что по заказам отражаются только нормативные затраты по работам.
 
Основная цель, для чего используется повторная оценка НЗП - это предотвращение зависания многоуровневых отклонений по потребленным полуфабрикатам на производственные заказы, оставшиеся в НзП, а для данных целей совсем нет необходимости вести фактические тарифы работ в регистре материалов.

В принципе, написано достаточно четко и по существу. Жаль, не приведены кейсы(примеры бы не помешали).

Рекомендации очевидные, автор статьи Америки не открыл. Для новичков может быть полезно в качестве общего обзора.

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

Стаья написана достаточно простым и понятным языком. Понравилось, что заострено внимание на важных моментах процесса. Хорошо проиллюстрирована.
Хотя на практике такая необходимость встречается редко, но знать подобные  возможности полезно.

Достаточно интересная статья особенно в рамках введение в действие ФЗ об обработке персональных данных.

Конечно в период кризиса все хотят уменьшить свои расходы и экономят на всем, это не новость. Только по-моему опасно отказываться от обновлений, которые содержат изменения в логике работы программы в соответствии с изменением законодательства.

Первые два способа имеют право на существование, но в моей практике ни разу не использовались, т.к. при изменении бизнес-логики приложения очень часто нужно знать не все BADI/USER-EXIT\'ы которые имеются в программе, а только те которые будут относиться к какому-то событию. Для этого больше всего подходит способ \"Поиск BAdI при помощи трассировки SQL\", но у него есть огромный недостаток, это наличие прав на запуск ST05. На некоторых проектах в которых участвовал я, базисники отказывались давать права на ST05. В таких ситуациях помогало наличие прав на запуск отладчика(у ABAP-разработчиков они практически всегда есть). На примере который привел УСМАН необходимо запустить отладчик(/h или /hs), непосредственно перед нажатием кнопки \"save\". Потом нажимаем кнопку \"save\" и в отладчике нажимаем F9 и вводим CALL CUSTOMER-FUNCTION для остановки на всех USER-EXIT\'ах и F9 на вкладке Method вводим
Class name: CL_EXITHANDLER
Method name: GET_INSTANCE
и нажимаем F8. Теперь мы будем останавливаться на каждом расширении и можно будет изучить передаваемые в расширение  параметры. Так проще найти BADI, которые лучше всего подходят, для данного случая. Есть и другие способы, но использование отладчика помогает решить 90% проблем с поиском расширений.

Интересная статья. По сути небольшой и очень простой проект с технической точки зрения, т.к. нет интеграции с другими решениями, а для крупных проектов это почти всегда необходимо; также довольно простой воркфлоу без кучи согласований \"всех со всеми\":). В общем, почти Best Practice.

Интересно, но все-таки до интегрированности BPS или IP с BW еще далеко.

На удивление сбалансированная и качественная статья.
 
Понятное изложение. Весма полезна, так как на официальных сайтах нет внятного позиционирования продуктов.

весьма неплохая статья. Имеет качественно другой уровень, нежели предыдущие статьи.
 
Я бы здесь дополнительно рассмотрел бы связку xs - sap nw в режиме доступа online. Но в целом автору удалось осветить основные моменты интеграции продуктов

очередной плохо переписанный хелп. В аннотации говориться о методах, которые позволят свести к нулю время простоя. В самой статье ничего об этом не сказано, тупо переписан хелп и курсы и сделана отсылка к статье Майкла Лавлеса (Michael Loveless) и Георгия Патчова (Gueorgui Patchov) Load Data into Two BW Systems from One R/3 Source with Zero Downtime (“Загрузка данных из одной исходной системы R/3 в две системы BW с нулевым периодом простоя”). Эта статья была опубликована в базе знаний BI Expert в феврале 2005 г.
 
Ценность данной статьи равна нулю.

Для внедрения больших проектов - очень актуально

Познавательно, но к сожалению ничего нет для Retail.

что и следовало ожидать в период кризиса.

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

Рекомендации достаточно очевидные. Если работаешь не консультантом по внедрению, а на внтуреннем проекте, то так и так сталкиваешься практически со всеми описываемыми задачами.
Но удобно, что они собраны в одной статье. Хорошая стартовая точка для специалистов (наверное, в основном молодых :) ), чтобы улучшить свою квалификацию и повысить стоимость.