"
СТОП!! Почему пользователь делает это в Excel? ALV имеет те же функции – сортировка, фильтр, группировка данных.
"
в SAP ALV сложно восстановить данные в первоначальный вид (по сортировке, подитогам и прочее), иногда даже невозможно - только повторная выборка.
 
+ популярная функция VLOOKUP, не только в ALV, даже в ABAP, отсутствует (если я не прав, прошу поправить - реализовать можно, но прямой такой функции я не видел, но я не абапер, могу не знать).
 
+ еще около 100 встроенных функций, позволяющих складывать данные, вычислять сложные проценты, искать нужный текст в строке, создавать свои формулы.
 
+ когда система попытается записать в числовое поле текст (из-за недотестирования, или кривого кода), система выдаст всплывающее сообщение, или скажет "not defined", а не упадет в runtine error. Т.о., пользователь: 1) получит оставшуюся часть отчета, 2) поймет, в чем ошибка, хотя не факт.
 
+ Вы еще про графическую часть ALV не рассказали, но на ней викинги температуру анализировали, когда корабли начинали строить ...
.....
 
а теперь Вам вопрос, как среагирует SAP ALV, если:
 
1) прервется соединение с сетью на 2 сек из-за "тех.причин", а пользователь до этого 10 мин "выгружал данные и наводил красоту"?
 
2) понадобиться скопировать все записи столбца данных с количеством записей около 2000?
 
3) потребуется подсчитать количеством строк там, где валюта EUR и там, где валюта RUB?
 
Мой вывод:
SAP ALV мощный инструмент отчетности, он предоставляет функции сортировки, фильтра, возможность перехода непосредственно в документ системы (например, из me2l в заказ на поставку).
Если посмотреть отчеты в других, так называемых, ERP системах (не буду называть), то пожалуй для оперативной отчетности, это один из лучших инструментов оперативной отчетности.
 
Но противопоставлять его Excel в части обработки таблиц, все равно что сравнивать горный велосипед и BMW. Каждый хорош в своем назначении, но как траспорт для жизни BMW - один из лучших.
В части обработки таблиц Excel мощнейшее средство, причем в разных операционных системах (включая мобильные).
С ним могут конкурировать, пожалуй, только научные программы и то только при решении какой-то конкретной задачи.

Здравствуйте.
В данном способе есть одна большая проблема. Вы можете узнать сам факт того что объект был изменен. Но так как в запросе, чаще всего прописывается ключ объекта (из таблицы), а само изменение берется при деблокировании, то можно увидеть только ключ переносимого объекта или часть ключа и *. Если есть способ узнать все поля, которые неслись в запросе, это было бы еще интереснее.

а где же звук?

Несколько незначительных дополнений:
1) Для поиска через точку останова модулей процесса - ФМ PC_FUNCTION_FIND, для P/S модулей - ФМ BF_FUNCTIONS_FIND, как и указано;
2) следовало бы упомянуть мандантозависимость настройки активности замещений этого типа;
3) Транзакция BERP никак нам не поможет увязать модуль с конкретной транзакцией, так что фраза "Для получения информации по существующим событиями в конкретной транзакции перейдите ..." может ввести в заблуждение :)
 
В целом, написано практично и добротно.
 
Еще одно интересное, на мой взгляд, практическое применение модулей событий бизнес-операций - генерация события бизнес-объекта, которое можно в дальнейшем обработать.
Простой пример из жизни - реализация записи номера создаваемого документа FI в формате "номер/год" в поле, например, текста его же заголовка.
Событие 1120 не подойдет, поскольку в нем номер еще не известен, а в P/S модулях 1030 и/или 1050 изменение собственного заголовка уже невозможно.

Документационная поддержка бизнес-процессов, безусловно, является одним из важных вопросов, возникающих при внедрении ERP-системы. Практически на каждом проекте внедрения мы сталкиваемся с этой задачей. По моему опыту, в случае, когда основным внедряемым функционалом являются процессы FI и MM/SD, в первую очередь возникает задача хранения оригиналов и отслеживания статусов закупочных и сбытовых договоров, а также первичных бухгалтерских документов. В ситуации, когда автоматизируем процессы ТОРО, возникает вопрос структурированного хранения проектной и эксплуатационной документации с привязкой к техническим местам в SAP.

В течение долгого времени модуль SAP DMS являлся самым «правильным» инструментом для решения этих задач, и на наших проектах для решения первоочередной задачи по управлению договорами в SAP мы применяли с 2003 г. именно его. В то же время стоит помнить о сложностях, которые несет такое «частичное» решение задачи документационной поддержки.

Давайте рассмотрим пример с управлением договорными документами. Если мы организовываем процесс хранения и отслеживания исполнения договоров в SAP DMS, то необходимо также подумать о процессе подготовки и согласования договоров – в какой системе будет проходить он? Кроме того, договор, хранящийся в SAP DMS, также востребован в других существующих на предприятии системах. Например, договоры по производственным проектам, очевидно, должны быть доступны в составе проектной документации в системе управления проектами.

Обобщая эту ситуацию, можно сделать вывод, что любое разделение контента (в данном случае значимых для производственной деятельности документов) предприятия на различные информационные системы, неизбежно порождает дублирование документов и потенциальное их расхождение в различных системах.

При этом компромиссные решения принципиально проблему не решают. Относительно примера с управлением договорами мы в наших проектах чаще всего приходили к варианту – автоматизировать подготовку и согласование договоров в отдельной системе управленческого (обще-распорядительного) документооборота, разработав при этом интерфейсы, обеспечивающие синхронизацию данных между SAP DMS и внешней системой документооборота. Но, даже не рассматривая трудоемкость создания и сопровождения таких интерфейсов, можно видеть, что проблема возникает повторно, как только возникает третья (четвертая, пятая, …) система, которой нужно обращаться к этому же договору.

Таким образом, как только мы начинаем использовать SAP DMS для обеспечения документационной поддержки отдельного бизнес-процесса, мы понимаем, что самым эффективным было бы реализовать в DMS управление всеми документами предприятия. В некоторых крупных российских компаниях такая задача была успешно решена, но это, к сожалению, на общем фоне можно считать скорее исключением, чем общей тенденцией. Общепризнанной особенностью российского документооборота является жесткая регламентированность процессов согласования документов. Даже специализированные системы документооборота далеко не всегда могут «из коробки» предоставить такие возможности как параллельно-последовательное согласование, нормирование сроков согласования в зависимости от объема документа (с учетом производственного календаря рабочих и праздничных дней), согласование «по умолчанию», механизмы посредников, делегирование полномочий, и т.д. Когда мы начинаем реализовывать все перечисленные особенности с помощью ABAP-разработок в DMS, это сразу же утяжеляет решение и значительно увеличивает сроки и бюджет внедрения. Кроме того, как многие столкнулись на практике, использование механизмов классификации SAP для создания дополнительных атрибутов документов, может в дальнейшем вызывать сложности в построении отчетов. Механизм классификации привлекает своей универсальностью, но оборотной стороной универсальности является более сложная и менее читаемая структура хранения данных (по сравнению со стандартными таблицами других модулей).

Поэтому 2 года назад, когда у SAP появился продукт SAP Extended ECM, его появление вызвало огромный интерес и вопросы – сможет ли он более широко и эффективно решить задачу управления документами? К настоящему времени, когда сразу несколько крупных российских компаний завершают проекты его внедрения, можно сделать выводы, что Extended ECM и его основной модуль Content Server позволяют реализовать эффективную систему управления контентом предприятия и организовать доступ к документам из различных транзакций SAP ERP. В качестве одного из примеров таких компаний можно привести ЛУКОЙЛ Оверсиз Холдинг Лтд, где с помощью Content Server реализован как управленческий, так и производственно-технический документооборот.

Соглашаясь с описанными в статье сильными сторонами SAP DMS, для условий российского документооборота я бы предложил рассматривать более широкий функционал SAP Extended ECM.

Можно и не создавать ракурс ведения, а для просмотра изменений воспользоваться транзакцией SCU3. Кроме того, параметр профиля rec/client должен быть корректно установлен, иначе изменения таблиц вообще записываться не будут.

Согласен, но зачем же грубить. Не надо никого убивать, коллеги, нас итак осталось немного (если сравнивать с индусами...)

Андрей а вам никто никогда не говорил, что обновлять таблицы базы данных SAP категорически запрещено, независимо от того чем обусловлены такие желания. Свои Z-таблицы, да сколько угодно, но... стандартные SAP-таблицы?!? Как говорил товарищЪ Бендер, за это надо убивать в зародыше из рогатки.

Касательно последней архитектуры.
 
С одной стороны в тексте прозвучала ключевая фраза: "все доработки и исправления выполняемые в системе BW DEV, параллельно учитываются в системе BW NEW DEV", но на схеме это никак не отражено.
Схема, я считаю, не правильная.
Дело в том, что данная схема предполагала ведение параллельных работ по поддержке существующего решения (исправление ошибок, мелкие доработки) и внедрение новой функциональности (существенные разработки).
Так вот, из предложенной архитектуры мы видим, что все наработки, связанные с исправлением ошибок будут потеряны с выключением "BW DEV", и ландшафт станет неконсистентным, т.е. "BW NEW DEV" не будет равен "BW PRD".
 
Можно поступить след. образом:
- скопировать "BW DEV" в "BW NEW DEV";
- текущие работы по поддержке существующего решения вести в "BW DEV"
- Новая функциональность должна настраиваться в "BW NEW DEV"
- И сам ландшафт должен выглядеть так:
 
(BW NEW DEV)=>(BW DEV)=>(BW QA)=>(BW PRD)
 
таким образом, будет соблюдена консистентонсть систем, и не нужно инсталлировать одну лишнюю инстанцию (BW NEW QA)
 
С уважнием,
Владимир.

JavaScript в большинстве своем один не работает: всегда есть сопутствующие технологии (css, dhtml, ajax и т.д.).
 
Возможно, эти книги тоже как-то помогут (хотя тут я Америку, конечно, не открываю)
javascript.ru/book
 
Если Вы используете указанный Вами ресурс, то Ваши знания больше, чем просто базовые знания.
 
Хотелось бы услышать рекомендации автора статьи :-)