Но есть проблема: при редактировании если в гриде есть текстовые поля, то они все переводятся в верхний регистр!
Не смог найти как это обойти!
Может Вы знаете?

В верхний регистр если тип данных CHAR используете. Попробуйте SSTRING.

Но есть проблема: при редактировании если в гриде есть текстовые поля, то они все переводятся в верхний регистр!
Не смог найти как это обойти!
Может Вы знаете?

Открыл статью, в надежде увидеть дорожную карту. По факту реклама курсов от SAP...
 
Что касается дорожной карты консультанта, я бы для начала определил, в какую сторону хочется развиваться - в сторону архитектора или эксперта. Для архитектора необходимы широкие знания, выходящие не только за рамки модуля, но и за рамки системы. Для эксперта необходимо углубляться внутрь модуля. В обоих случаях минимальный срок развития следует представлять в районе 10 лет.
 
Развитие ни того, ни другого невозможно в штате клиента в виду ограниченности процессов.
 
Примерная карта для архитектора:
1. Стажёр
2. Консультант по модулю
3. Старший консультант, начало работы с новым модулем. Развитие навыков программирования, методов интеграции систем
4. Повторение шагов 2 и 3 в рамках области, интеграция с другими системами в области, участие в проектировании архитектуры
5. После того как знания во всех модулях выбранной области дошли до уровня старшего консультанта, можно называть себя архитектором
 
Карта для эксперта:
1. Стажёр
2. Консультант по модулю
3. Развитие навыков интеграции с другими модулями и системами, изучение программирование
4. Старший консультант
5. Совершенствование навыков интеграции, смена различных проектов. Интеграция с современными технологическими системами. Расширение знаний в различных ответвлениях процессов.
6. Эксперт
 
Как в одном, так  и во втором случае, на мой взгляд, определяющую роль играют не курсы, а систематизация знаний. Книги дают в этом случае наибольший эффект.
 
Я являюсь экспертом по логистике SAP с опытом более 12 лет. 6 лет я успел поработать как фрилансер. Сейчас тружусь в Германии. Заходите на мою страницу. Например в LinkedIn, я публикую различную информацию по логистике.

Есть опыт создания примерно 250 000 материалов через Staging Tables. Система 1809. В стандартном объекте отключили маппинг значений кодов материалов. В остальном по скорости примерно так же как с LSMW. В плоскую таблицу по методу из статьи мигрировано около 200 000 записей. Из неудобств можно отметить необходимость разбить пакет на 4 файла. В целом примерно то же, что и в старом инструменте. Из достоинств - прямо из коробки 100 готовых объектов, которые реально работают. Если потратить пару недель на изучение и потренироваться, то вполне себе удобный инструмент.

Хорошая, качественная статья. Я бы смог применить эти шаги на практике.
 
Интересно было бы посмотреть, что если есть зависимости между несколькими таблицами, и нужно сохранить консистенцию данных при миграции.
 
Также интересно сравнить данный метод с прямой миграцией, которая доступна с версии 1909.

Не скажу как в 1909, но в 1709 пришлось устать с этим кокпитом, сырой зараза и скорость работы, короче не реально с этой штукой что-то серьезное мигрировать. 5000 объектов за сеанс?! Ребята вы серьезно систему рассчитали на ЧП палатка номер 5 с базара? Да еще и 12 часов эти 5000 ОС грузятся?! Короче надеялся что к 1909 исправили, но реализация прямой миграции, говорит что похоже как обычно, у сапа новая игрушка, и этот кокпит так и будет сырым по жизни. Хотя к какой-то 2510 наверное до ума доведут.

Хорошая, качественная статья. Я бы смог применить эти шаги на практике.
 
Интересно было бы посмотреть, что если есть зависимости между несколькими таблицами, и нужно сохранить консистенцию данных при миграции.
 
Также интересно сравнить данный метод с прямой миграцией, которая доступна с версии 1909.

Андрей, спасибо. Я понимаю, что тема сложная и имеет много нюансов, но это то чего не хватало - объяснить доступно общую картину.