Добрый день.
У меня такой вопрос, в данный момент нет проекта и я изучаю различные настройки и материалы которые могут пригодиться. Я консультант по модулю ММ и у меня сейчас появилась мысль изучить работу отладчика, находить в чем ошибка(разумеется если она не серьезная), либо как заполняется какое то поле, то есть откуда подтягивается значение из какой таблицы и т.д. Стоит ли тратить время на изучение, не раз была ситуация, что коллега помогал за 10 минут найти проблему используя отладчик.
Просто мне показалось что это будет "+" знать его.
И из опыта как много времени может это занять? Может быть материалами какими-нибудь поделитесь или просто советом с чего начать?

безусловно))

а также на абап стоит потратить время, ваша цена как специалиста только вырастет))

Тогда надо мне искать материал, буду пытаться научиться) Раз это действительно стоит.

Есть несколько практических навыков, которые просто мегаполезны консультанту:
1. Понимание базовых технологий отладчика: просмотр переменных, стека вызовов, точки наблюдения, точки прерывания на конкретном операторе.

2. Поиск таблиц, которые хранят поля экрана в тех случаях, когда F1 не дает на это ответ.
То есть грубо говоря из F1 находим программу и поле структуры, которые выводтся на экран и вешаем на него точку наблюдения.
По точке наблюдения в отладчике попадаем на место, где это поле заполняется из какой-то другой переменной, фиксируем его. И далее откручиваем все эти присвоения из переменной в переменную, пока не доберемся до корня (обычно, это комбинация какого-то количества полей таблиц в БД)

3. Поиск места возникновения сообщения об ошибке и далее причины вывода этого сообщения.
Если сообщение выводится напрямую, ставим в отладчике либо "Break at statment" на оператор message, либо точку наблюдения на sy-msgid, sy-msgno.
Если сообщение выводится через какой-нибудь лог (аля перечень сообщений в закупочном заказе), находим что используется для записи в лог (метод класса, ФМ, процедура и т.п.), ставим точку прерывания там, дожидаемся нашего сообщения и по стеку вызовов смотрим, откуда же оно взялось.

4. Умение находить место, где считывается определенная настройка из spro при помощи st05 (хинт: надо ставить галку table buffer trace).

5. Ну и уже более специфическая вещь - анализ производительности / поиск узких мест в программах (st05, st30).

В качестве модератора: я подумал и переместил тему из MM в "Обсуждение рынка труда".

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

В некоторых случаях это увеличивает скорость решения конкретных задач по настройки системы в разы, иногда превращает нерешаемые задачи во вполне подъемные. Как результат - существенное увеличение стоимости такого консультанта на рынке.

LKU всё расставил по полочкам.

Полностью согласен.

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

Вот это не обязательно, и зависит от сознательности самого консультанта. Никогда не пложу [censored], если есть есть хотя бы малейшая надежда обойтись настройками.
Но знание абапа и отладчика в частности, как уже и писали, существенно повышает скорость работы и поиск решений.

ИМХО консультант, не знающий ABAP похож на управленца, не знающего предметную область в которой он управляет. Например, проджект-менеджеры, не знающие SAP, или министры, ни дня не проработавшие в отрасли. Т.е. у человека нет понимания, как работает то, чем он управляет, изнутри. Сферический, такой, менэджер в вакууме...

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

При этом хороший консультант обязан свободно ЧИТАТЬ чужой abap-код и владеть навыками использования отладчика, про которые я писал выше.

LKU, спасибо большое за ответ.
В целом я понимаю плюсы, и пытаясь изучить отладчик и понимать код, лично я не ставлю себе в будущем цель работать за абапера, ну если только как вы сказали в схеме калькуляции и подобных моментах.

Нет ли какого-нибудь примера по шагам, я думаю мне один раз сделать по инструкции или гайду, а там уже по накатанной пойдет, начать бы с чего нить малого. Хочу начать с 3 пункта, поиска ошибки а именно места его возникновения.
Может быть встречали когда-нибудь гайд по шагам, хотя возможно после обеда я смогу частично самостоятельно разобраться и по вашему ответу.
Да и 4 пунктик бы для начала тоже не повредил, потом остальные буду уже разбирать.
Еще раз спасибо!

Есть инструкция по работе с дебагером. Шлите свой ящик в личку, отправлю файл.

Эм... А немцы-то и не знают. Я бы сказала - наоборот.

msv
Сознательность любит отключаться, когда времени на поиск нужной настройки мало, а абапом точно знаешь, как вставить костыль; не у вас конкретно, а в принципе такое очень часто встречается. Хотя в основных 4-х модулях настроить можно едва ли не всё, что душе угодно.

LKU
Чтобы действительно хорошо понимать абап и тыкать абапера в его же ошибки - надо язык изучать, то есть уметь на нём писать. Иначе "просто читать" не особо научишься... А это время, экономически невыгодное, как ты правильно заметил.
С другой стороны, существует ряд компаний и проектов, где абап - основное, и как раз экономически невыгодны консультанты без умения писать на языке; чем все и занимаются большую часть времени. Относится не только к BI, естественно.

axion
И мне тоже вышлите, пожалуйста, ящик в профиле.

Лев, по поиску сообщений об ошибках читайте здесь:
http://platon69.narod.ru/4.html

И это резон не подучить абап? Незнание во благо? )))))