В принципе описано все понятно и доходчиво. Единственное, на что не обратили должного внимания, так это \"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.

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

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

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

Экстракция из логистических источников данных сложный процесс и освещен здесь не полностью. Ничего не сказано про настройку пульта управления, про специфические очереди (типа MCEX03) из которых данные попадают в очереди BW (*2LIS*) только после выполнения задания.
Но если уже приходилось сталкиваться с загрузкой 2 lis, то можно воспользоваться идеей использования DSO для устранения двойных документов, вместо ручного удаления их из очереди. Хорошо бы еще сказать о плюсах и минусах(дополнительные собственные объекты) этого решения.

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