Очень длительная активация и на продуктиве? Ну если у вас продуктив это проходной двор и туда можно таскать что угодно и когда угодно, то установка рекомендованной вам службой поддержки SAP-ноты, может вызвать тот же эффект и даже значительно хуже, но это я думаю не значит что ноты ставить не нужно, как и в целом обновлять всю систему, там вообще генерация может часами идти.
 
По поводу всем материалам, ну да вот такой вот справочник кодирования принятый в организации и материалы все там кодируются согласно справочника. В 40 символов не влезает, в тексты толкать не выход, работать с этим потом не очень реально.
 
Ну что ж, я рад что где-то есть системы в которых нет ни одного экзита или расширения таблиц. Мне такие не попадались, хотя в своей системе миграции проходили с 3.0 -> 4.0 -> 4.6С -> 6.0 и если честно то чем-то значительным такие миграции небыли и проблем никаких небыло, генерация была :-), как и архивация данных, тоже как-то не запомнилось. Хотя знаю другие системы где миграция вызывает обморок у группы поддержки.
 
Что касается нормализации, то этот вопрос оставил за бортом не я, а компания SAP, причем году так... в девяностых а то и ранее. Кстати, а чем два поля CHAR повлияли на нормализацию? Приведите какое правило нормализации я нарушил этими полями? Я чего-то знаю три и считаю что их достаточно, хотя там дальше теоретики намутили еще вроде как три, но они прошли мимо меня, но было бы интересно.
 
По поводу классификации, это очень тормозной путь, если данные требуется использовать в отчетах, причем массово. Кстати не к ночи упомянутый BW читать данные классификации в экстраторе будет значительно дольше, чем через расширение MARA.
 
Расширения системы - допустимые, т.е. те которые не требуют получения ключа модификации на объект (хотя в SD есть момент когда ключ нужен, но расширение освящено гнездом), гарантируются компаний SAP как работающие и не нарушающие ничего в системе, так что не скажу что это именно проблема, если вы сделали все в рамках стандарта.
 
PS: Кстати, а что такое фундаментальный объект? Для вас это вот таблица, для кого-то может быть код, соответственно если я активирую экзит, то я уже как бы изменил фундамент? Но папа то сказал что это не только в этом месте можно делать, но и нужно делать, если мне нужен вот такой вот бизнес-процесс.

Эх давно я в банках не был, но поправьте меня если это не так, но , АБС несет очень тупую функцию ввод первички и баланс по главной книге, а вот кредиты, аудиты и прочая аналитика это к АБС не очень это больше как раз сфера BW или HANA (банк аналайзер им помощь), которая типа когда много данных, она это дело быстро может в разных срезах вытащить, но BW и операционный день банка, это несколько разные вещи. или у нас теперь модно АСБ на системах класса BW строить? Ну если да тогда хозяин барин, а я видно тему протупил.
 
Теперь что касается 10 лет, в 1997 году НБУ (Национальный Банк Украины) запустил проект внедрения SAP, тогда же была разработана АБС на SAP (сам SAP только году в 1999-2000) приступил к этой теме Ну там БАРС-ик в конечном итоге похоронил АБС на SAP и отнюдь не потому что был лучше, а SAP хуже... конъюнктура так сложилась на тот момент. Но даже ERP-шная часть банкинга, на которую SAP по старой доброй традиции в данный момент забил, поверьте очень мощная вещь, а разрабатывать ее начали году как я говорю 1999-2000 и бундес-банк ее вроде как использует как и банки Швецарии. Почему так думаю, ну пришлось поковыряться год назад, так там что не код, то комментарии типа реализация для бундеса или для Швейцарии. Так что 10 лет, этому банкингу уже есть и даже больше.
 
Аэрофлот если это сделал, молодец. Потому что... все знают Райфайзен банк, так вот в Украине как мне было озвучено в нем используется свыше 800 информационных систем и что вы думаете?! Ага они покупают 801 систему, которая по их мысли, наведет порядок в предыдущих 800 системах и поверьте когда я в первый раз узнал сколько стоит внедрение SAP меня это сильно озадачило, но тогда я был маленьким и верил в сказки, позже я увидел системы которые из себя представляли работы на неделю, но стоили  в 4-5 раз больше чем внедрение SAP и я как-то перестал верить в сказки о целесообразности внедрения :-)

А текущую АБС вы предлагаете выкинуть ?
SAP HANA - cлишком молодой продукт, чтобы банк первой сотни заменил им АБС.
Банковскому модулю под РФ насколько я помню примерно столько же, так что думаю ПОКА ваш интерес - это только ваш интерес,как продавца и ему есть существенная альтернатива...
Вот если бы SAP на этот рынок пришёл бы лет так 10 назад - это было бы существенно интересно.
Хотя, смогли же в Аэрофлоте по заявлениям менеджмента заменить 180 систем на 3, может и в банковской сфере - ктото рискнёт....
Банковская сфера достаточно консервативная.
Но я думаю, того, кто рискнёт мы узнаем сразу, ибо тогда САПовские маркетологи расскажут "sucsess story" во всех презентациях к месту и не только..

Дмитрий.
Внедрения в банках промышленных продуктов (HCM, PI/XI, MDM, FI-AA, FI-CO, FI-FM и проч.) малоинтересны для меня. Эти модули успешно внедряются везде.
Намного больший интерес представляют банки, которые переходят на продукты SAP в основных, зарабатывающих направлениях, внедряют банковско-специфичные продукты. Интересны внедрения SAP CRM в качестве системы "первого контакта" с клиентом. Интересны попытки заменить АБС. Надеюсь что кто-то попробует внедрить SAP Bank Analyzer, на платформе SAP HANA.  Эти проекты интересны из-за специфичности и сложности.
Я думаю, что Вы ошибаетесь про внедрение в банках первой сотни. SAP - это капитализируемый бренд. Успешное внедрение SAP покажет, что у банка сильная команда управления, налажены процессы и, что он стоит своих денег.

Что касается ауканья  - был прецедент, после "законных" действий программиста шла очень длительная активация, случись такое на продуктиве - была бы авария.
Всем материалам - не могу такого придумать, не верю. Длинный текст и так есть в ОЗМ, даже несколько. Более 12 лет работаем c R3 и как то без расширений.
Далее к нормализации данных - согласитесь, кроме минутной выгоды,в упрощении получения отчета,Вы оставили за бортом вопросы нормализации данных. После этого, все ОЗМ пожизненно награждены доп.аттрибутами, нужны они там, или не нужны. Далее велик соблазн еще и еще применить такое решение, и только потом дозреть до классификации.
За бортом остались вопросы архивации, средств поиска, экстракторов BW и других объектов SAP.
Резюме - если SAP пишет ноты, то кто-то ими пользуется. С моей точки зрения - расширение фундаментальных объектов SAP порочный путь

Андрей, о внедрении какого из множества продуктов SAP вы ведёте речь на этих страницах ?
Если вы рассуждаете о чисто АБСном продукте SAP, то соглашусь - несомненно, и думаю что его внедрение в банках первой сотни - маловероятное событие, ибо там давно уже всё распределено между другими игроками рынка.
Если речь идёт о других продуктах, то много где и что используется.
 
Бондарев Дмитрий, SAP Basis администратор,
Банк "Хоумкsapland.ru/blogs/raksinskiy#редит"

1. Мне сложно оценить, чем может аукнутся допустимое и корректное расширение объекта SAP? По крайней мере из моей практики, лет за много, такое расширение таблицы, ни разу не аукнулось. Так что примеры, для оценки эха в студию :-)
 
2. Классификация не нравится так как названия надо присвоить не НУЖНЫМ материалам, а ВСЕМ материалам, ну и далее про ум программиста, а вы пробовали делать отчеты по данным ОЗМ, партий и т.д. где используется классификация? А то что классификация может быть активирована не только для ОЗМ а еще для двух десятков объектов и значения признаков в таком случае будут хранится в одной таблице?
 
3. Ну и в общем данные можно хранить не SAP-таблице, а в своей Z-таблице, но для этого надо еще активировать экзит записи данных.
 
PS: Данная статья не о том как что-то поломать в системе, а о том, как нужно читать ноту 44410 :-)

Первое, что приходит на ум программиста при решении поставленной задачи  - расширить таблицу.
Если смотреть на перспективу - апгрейды, апдейты , расширение функционала - то эти расширения таблиц будут занозой и рано или поздно аукнутся.
А чем классификация материалов не нравится?
Создается класс для материалов с двумя полями, дополнительные данные присваивается только НУЖНЫМ ОЗМ и все, никакого колхоза.

Гораздо быстрее можно найти используя Debugger Scripting. В случае его использования мы сравниваем значение переменной (структуры) и находим место где оно изменилось (в программе ей присваивается значение структуры - MEPO1222_pbo), далее по стеку выясняем откуда она заполняется. Написав один раз скрипт, мы избавим себя от необходимости анализа  большого трейса.

Михаил.
 
Если Вы можете написать статью-рекомендацию по поиску таблиц - источников данных с помощью Debugger Scripting, то мы с удовольствием её опубликуем.
 
С уважением, Александр Дублин.

Вот и тема новой статьи

Наконец-то это "тайное" знание консультантов - формализовано.
Спасибо, полезно.

Вообще то для поиска именно userexit-тов я пользуюсь вот такой вот программой: sapforum.biz/index.php/topic,654.msg9769.html#msg9769 более быстро и наглядно выдает информацию по коду транзакции, ну и сразу выдает имя расширения которое надо включить в проект.
 
Выглядит где-то так:

Михаил, добрый день!
 
Полезно было бы почитать подобные публикации по SAP BPC версии 10.0. Это сейчас актуально и, возможно, вызвало бы больший интерес к Вашей колонке.
В любом случае спасибо - очень доступно и понятно :)
 
С уважением,
Александра