Очень качественная инструкция для создания расширений стандартной функциональности при помощи 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 уже пора забыть.

Качественно, поскольку от разработчика. Объясняются основы построения, но слишком сложно для понимания людей, не имеющих представления о сабже. Бесполезно, поскольку непонятно как применять в целом.
К счастью, как раз в этой области есть опыт, могу поделиться. Несмотря на сложность настройки, эта штука работает и работает устойчиво. Более того, результаты планирования в некотором смысле оптимальны, поскольку более гибки, чем любая эвристика и объяснимы в отличие от оптимайзера. Поскольку мастер-данные планирования изменяются мало, то грубые отклонения от оптимального решения отлавливаюся и правятся с помощью настройки выбора источника. Для реализации сложных задач возможно сценарное планирование поочередно с различными профилями. Полученные данные реально можно использовать как среднесрочный производственный план.
Недостатки: непростой инструмент, требующий высокой квалификации при настройке.
  

Полезные вещи для разработчика.
Спасибо за доступность изложения материала.

В принципе действенные способы, но BAdI в новых системах вызываются не только с помощью CL_EXITHANDLER, но и с помощью специального оператора CALL BADI.
 
По моему мнению легче искать отладчиком. Ставим точку остановки CL_EXITHANDLER=>GET_INSTANCE, так как для старых BAdI вызывается данный метод и также в отладчике ставим точку остановки по оператору CALL BADI.

Очень детальная статья, которая в четко, доступно для понимания, очень детально описывает все шаги процесса разработки веб приложений в среде SAP. Статья очень полезна для создания начального представления о программирование веб интерфейсов для программистов.
Обязательня для прочтения всем кто хочет разрабатывать веб приложения для систем SAP, и в частности для разработчиков в системе Solution Manager, потому что именно в ней очень часто используется веб функциональность.

Полезная статья как для разработчика так и для консультанта, который пишет функциональные спецификации. Раскрывает возможности расширений в системе SAP. На мой взгляд, написана статья не очень понятным языком. Скобки, которые добавляет автор для «(простых) точек расширения» очень визуально дробят текст и делают его очень трудночитаемым. Не понятно как нужно читать предложение со словом в скобках или без слов в скобках. Вторая часть стать, где приводится конкретный пример расширения, конечно же более полезна для разработчиков, чем для консультантов. Считаю статью необходимой для прочтения консультанту, который пишет технические спецификации на модификации системы, чтобы знать все возможности в этом направлении.