Коллеги, а никто случайно не озадачивался составлением описания:
1.) Типичных программерских ошибок. Вроде того, что FOR ALL ENTRIES будет работать некорректно, если состав полей слишком сильно обрезать, или что из ALV нужно по-хитрому удалять выделенные строки.
2.) Модели данных по модулям, с описанием особенностей заполнения таблиц данными.

Книгу пишите?

Нет. Просто надо . А самому писать некогда, да и упустить что-то могу.

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

По пункту один:
ровно одна - нежелание подумать как следует, прочитать доки и подумать еще раз

Тоже подобные мысли недавно приходили,
меня последнее время достаёт соответствие полей различных структур,
имена и типы полей от версии к версии BAPI и п.р. меняются в результате move-corresponding отрабатывает криво

Вот сделать бы ФМ для мапинга соответствия полей между структурами словаря, а табличку соответствия и преобразования в инете вести...

сюда же можно отнести соответствие имён полей "старых" таблиц и соотв. структур BAPI...

На некоторые BAPI есть ФМ мапинга полей ) Видно саповцев это дело тоже напрягало, но пока только некоторых)
Самая распространенная ошибка программиста - очистка переменных перед их использованием.

ф/м для мэппинга генерятся в bdbs

помоему, самая разрушительная программерская ошибка - это снос в продуктив какойнить разработки, которой в этот момент много народу пользуется (особенно екситов, openfi и расширения структур таблиц касается).

Вообще-то перенос разработки - дело базиса

1. Иногда к большим неприятностям ведет отсутствие проверок sy-subrc после SELECT, READ TABLE и LOOP.
2. Не стоит забывать о необходимости чистить переменные и внутр. таблицы. Особенно в ФМ.
3. Огромный вред несет написание не структурированного кода. Т.е. код без процедур и т.д.
4. Использование только глобальных переменных и неиспользование констант порождает совершенно демонический код. Здесь особенно стоит упомянуть следующую болезнь: использование процедурами глобальных переменных и таблиц, которые используются в основном коде. Проще говоря все подобные объекты должны передаваться через параметры. Процедура должна опираться только на глобальные данные, которые кроме нее никто не использует. Как правило, это забуферизованные данные справочников.
5. Беспричинное использование динамического программирования (field-symbol и т.д.). При всей гибкости таких программ происходит потеря читаемости кода. Здесь есть еще одна спорная тема. Я - противник LOOP в field-symbol. Любители этой конструкции апеллируют к быстродействию. Мой аргумент - читаемость кода. Ее обеспечивает оператор MODIFY TABLE TRANSPORTING FIELDS ... позволяющий без вникания в подробности сразу понять, какие поля менялись в цикле. MODIFY TABLE без TRANSPORTING FIELDS я бы запретил

Согласен с Tim, за исключением п.5: для обеспечения читаемости кода с FIELD-SYMBOLS заполнение отдельных полей можно вынести в отдельные процедуры: get_mara, get_lfa и т.п.

Спасибо, друзья, о конечных результатах отпишусь!

Дык, по голове настучат обоим
И потом, базисник реально не всегда поймёт, чем чреват перенос того или иного куска кода?

Именно поэтому грамотные базисники переносы в продуктив оставляют на вечер
Это не типичная программерская ошибка, а типичная организационная.

Только, ещё-б грамотных сотрудников кто выгнал с рабочих мест (они бывает тоже оставляют работу на вечер). Насчёт организационного фактора согласне, но доля вины абапера там тоже зачастую просматривается (если например расширяешь какуюнить структуру, глянь средством поиска, не задейстована-ли она в критичных ОпенФи, или того хуже, в ключевых ФИ/ЦО таблицах...особенно если разработка по времени совпадает с закрытием периода в контроллинге)