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

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

В статье приводятся интересные примеры, которые помогут сохранить команду BW в кризисные времена. Сохранить команду, обеспечить ей работу и развитие в момент, когда отсутствуют проекты - очень важно!
В статье приводятся примеры, которые легко и просто можно реализовать на практике...

Неплохая статья, но всегда интересно получить обзор  практической реализации различных бизнес-кейзов на реальных проектах, типа:
- \"Договор аренды в иностранной валюте\",
- \"Договор аренды в иностранной валюте с договорным курсом\"
- \"Договор в У.Е.\"
- \"Пролонгация договора аренды\"

Вполне  доступным языком описанная Технология Web Dynpro for ABAP дает полное представление о создании веб-экранов. Зачет.

Очень качественная инструкция для создания расширений стандартной функциональности при помощи BAPI. Зачет 100%.

Добрый день!
Данная статья, на мой взгляд, является эталоном технической статьи для экспертов. Что я имею в виду? Во-первых, затронута действительно актуальная тема - \"Дополнительные фильтры в ALE\". Эта тема с завидной периодичностью возникает на крупных проектах (в моей памяти ТНК-BP, ГазпромНефть). Почему возникает я, наверное, описывать не будет, т.к. это от проекта зависит, но что тема актуальная - факт. Во-вторых, в изложении автора видна пошаговость действий, сопровождение материала скриншотами, приведение примера BADI, который можно на своем проекте уже взять за основу. В итоге, прочитав данную статью, консультант сможет сразу же приступить к действию. Чтобы я добавил: это примеры из бизнес-практики. Почему так получилось, что потребовались новые фильтры. Спасибо.

статья ориентирована на группу поддержки SAP bi на сторне клиента. Потому как с точки зрения консалтинга все указанные методы являются прямыми затратами на внедерение проекта. Поиск новых возможностей применимости SAP BI внутри компании со стороны консалтинга означает что консультант будет расширять свой бизнес, вводя в дополнительные затраты клиента. С другой стороны, поиск новых применений - это тоже работа и затраты консультанта, которая в итоге должна быть оплачена клиентом. Поэтому выводы .которые сделаны в статье, мягко говоря, неоднозначны.
Но в целом для развития команды применение ротации - весьма полезное занятие

Данная статья на мой взгляд является рекламным буклетом из серии Успешные внедрения, которые САП распространяет.
Из сказанного можно вынести:
1. Обсуждения являются основным фактором успеха. причем чем больше, тем качетсвеннее будет реализация. В больших проектах это не проходит, так как превращается все в балаган
2. Судя повсему сделана \"долбилка\" в виде нескольких форм без каких то сложных расчетов. Эффект, судя по статье - сокращение времени за счет того, что все данные за спецалисов в центре в систему \"заливают\" все. Ну для этого не стоило внедрять такой продукт.
 
В общем то и все.
 
на мой взгляд, ценным в статье явилось то, что активно использовались технологии удаленного обучения и web сессий, что не сильно распространено в России.
 

Хорошая статья, которая позволяет структурировать свои знания, полученные в процессе изучения NWDI. Огромным недостатком является перевод всех технических определений, используемых в системе. Например, Sofrware Component или Development Configuration. Проще читать англоязычный вариант, который полностью соответствует тому, что видишь на экране в системе, чем постоянно держать в памяти соответствие между русскими и английскими понятиями.

Отличная статья, являющаяся логичным продолжением первой части.

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

Статья неплохая. Подходит для вводного курса - для тех, кто никогда не внедрял IM.
Для себя не обнаружил ничего нового.

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

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

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

Очень полезно для первоначального ознакомления c SNP перед его внедрением

О применении методик к инструментам САП ни слова.

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

Много пустых слов, ничего конкретного про BPC, нету картинок, похоже автор намекает что о BPC уже пора забыть.