Полностью согласен с Jedi. Знаний предметной области ой как не хватает как стажерам, так и некоторым консультантам по функционалу.
А foxkid'у прямая дорога в абаперы.

Эх, наивный... ну ничего, мозги тебе вправят быстро, как только на проект какой нибудь попадешь

Я почти согласен с jedi. но вот знание преметной области не мешайет и абаперу - так качественнее будет решение.

да и базиснику тоже просвещаться надо

Лень в умеренных дозах полезна в любых количествах

Знание функциональных областей полезно в любых количествах

Да ну... Хороший абапер ещё и консультанта поправит, когда нужно. А вот сможет ли хороший консультант поправить абапера? Из-за таких как Вы и формирутется пренебрежительное отношение к абаперам. Звиняйте на оффтоп, просто наболело.

Молчал бы лучше, того и гляди за умного сошёл бы, может быть...
Будем надеятся, что не попадёт!

Не совсем согласен. АБАПер может не знать предметную область только на начальном (стажерском) этапе работы с R/3. В дальнейшем он либо зависает на уровне "покорми собачек", либо таки развивается и в сторону функционала тоже. Требовать от него каких-то настроек или проектных решений, естесственно, никто не будет, но вот знать хотя бы чем данный модуль занимается , с какими бизнесс-процессами и бизнесс-объектами работает, где они лежат в R/3 и как их оттуда выколупать - обязан. ИМХО.
С другой стороны, часто даже очень хороший консультант видит проблему только с одной стороны. Назовем ее "гуманитарно-экономической". И, собственно, задачей хорошего абапера будет работа совместно с консультантом для выработки наиболее правильного решения. А для этого функционал абаперу нужно знать уже на весьма неплохом уровне.

2ALL: Всем спасибо за советы, замечания принял к сведению.
2Пашенька Твои выпады в дальнейшем буду игнорировать!

ну чо вам сказать - я же писал что абапер МОЖЕТ СЕБЕ ПОЗВОЛИТЬ не знать функционал - даже вернее не функционал, а предметную область. Что в каких табличках лежит - это тоже часть функционала, и без этого абаперу никак.

Все зависит, конечно, от стажера. Если он перешел в стажеры из предметной области (например, работал бухгалтером (FI, CO) или в отделе логистики (MM, SD), или сисадмином (Basis)), то ему проще. Он осваивает стандарт, потом нестандарт, здесь сложности исключительно технические. Если же в стажеры приходит вчерашний студент, ему придется изучать предмет вместе с системой, а это долгий и тернистый путь.
Если время терпит, поработай с предметом с годик, а потом иди в функциональщики - больше эффекта будет.

Он и впрямь МОГ БЫ такое себе позволить, но только при условии идеально составленного ТЗ. Я лично таких не встречал - наверное, не повезло. А если ТЗ есть такое, какое оно обычно есть, то при незнании предметной области абапер обречён на многократное переписываение программ, чего ему, абаперу, совсем не хочется. Поэтому он идёт к консультанту, вникает в предметную область, и уточняет все вопросы и непонятки на этапе проектирования. И часто случается так, что после всех уточнений и исправлений проект программы очень сильно отличается от первоначального. Так что увы, не может позволить себе абапер не знать функционал и тем более предметную область.

С ТЗ то целые истории. )) Действительно, чтобы грамотно составить ТЗ, именно в виде руководства для абапера, чтобы ему оставалось только тупо следовать инструкциям, нужно самому иметь представление о том, как строится абап-программа, какие таблицы и в каком порядке будут там задействованы, по каким полям быстрее произвести выборку. А лучше уметь писать самому, но никому об этом не говорить
Я встречала абаперов, которые пишут сразу для трех модулей и нередко предлагают консультанту лучшее решение проблемы, чем в ТЗ. Но то редкие и ценные абаперы и большинство идет потом в функциональщики.
[/b]

Это возникает потому, что консультант не знает ни сап, ни предметную область, ни абап в должной мере. Работая в буржуйской конторе с абап-пулом в ньб-джерси я приучился писать ТЗ с раскладом до уровня полей и формул - так что абаперу оставалось только написать код и нарисовать ALV по экселевскому шаблону. А от абапера требовалось не столько знать предметную область, сколько хорошо знать структуру данных и базис. Правда тут надо отдать должное американским абаперам - хоть они и отсылали обратно на доработку невнятное ТЗ без всяких разбиралок с функционалом, но уж абапили так абапили.

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

А то что вы писали - да,так у нас и есть. Когда я сходил поработать в россиянский крнсалт так там и было - посмотрев мои ТЗ руководитель направления бурчал "зачем ты это все пишешь - нарисовал селекшн скрин и выходную форму, а дальше абапер умный, сам разберется".

Бу-га-га-га-га! Как ты думаешь, а мне не пофиг?

To Jedi и кто знает.

А могли бы сформулировать необходимые знания для консультанта по CO. Я сейчас устроился стажером по этому модулю. Пока проходил процесс приема на работу хорошенько поботал с бухгалтерией. Сейчас изучаю ABAP. Что мне еще из предметной области нужно: затариться литературой по аудиту, либо управленческому учету? По самому контроллингу смотрел, но пока на русском или английском ничего путного не нашел (немецким пока не владею). Из толстого правда заглядываюсь на "Планирование и контроль" Хана.
Что еще нуна?
P.S. Знание БД и так есть на продвинутом уровне (Oracle OCP).

Ну в стажеры то ты уже попал - а дальнейшее выяснится в ходе работы. Ну и рекомендация - заниматься СО без FI можно, но тяжко - так что концентрируясь на СО всетаки учи и FI