Меню

Добавление пользовательских полей в ОЗМ

|

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

Система SAP позволяет расширять её стандартную функциональность путём добавления собственных данных как в таблицы базы данных, так и на экраны стандартных транзакций. При этом, если механизм расширения таблиц в системы стандартный, то механизмы добавления собственных данных на экраны стандартных транзакций отличаются даже внутри одной функциональности. Механизм расширения ОЗМ описан в ноте SAP 44410, однако разобраться, что и как нужно делать оказалось не просто, так как в данном случае предлагается использовать уникальный механизм создания собственных полей. В большинстве транзакций есть user-exit[1] для изменения подэкрана пользователя, куда и можно добавлять свои данные. В случае с транзакциями управления ОЗМ (mm01, mm02, mm03) все немного сложнее, так как экранные формы этих транзакций фактически представляет собой большой набор подэкранов, которые можно комбинировать по закладкам и т.д., а также создавать дополнительно свои подэкраны.

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

Вариант 1. Вы расширяет какую-то из стандартных таблиц путем добавления своих полей данных.

Вариант 2. Вы создаёте свою таблицу, в которую пишете данные со «своего» экрана.

В случае 2 необходимо активировать user-exit, который срабатывает при сохранении изменений в ОЗМ и который будет записывать данные в эту таблицу. Этот user-exit должен обеспечить чтение данных и запись этих данных, а также проверки: новая ли запись или изменение существующей и т.д.

Я рассмотрю вариант 1, когда данные заносятся в поля, которые находятся в стандартных таблицах системы. Задача: добавить на экран ОЗМ в ракурс «Основные данные» два поля по 150 символов, которые содержат расширенное описание основной записи материла. Такая задача возникает, когда нужно обойти ограничение в 40 символов для поля «Краткое название» ОЗМ. Я не рассматриваю вариант, когда такие тексты нужно вести на разных языках, поэтому данные предлагаю хранить в таблице MARA.

Идём в ведение таблиц, транзакция SE11, и там выбираем просмотр таблицы MARA, переходим к созданию дополнительной структуры (Расширения) к таблице, Рис.1.

Рис.1

В появившемся экране выбираем создание нового Расширения, начинаем его как обычно на Z или Y. Я сделал расширение с именем ZMYMARA, Рис.2.

Рис.2

В данное Расширение я добавил два поля длиной 128 символов. Пример на Рис.3 ниже. В общем случае, можно добавить любое количество полей с требуемыми типами данных.

Обратите внимание: имена полей (компонент) должны начинаться со сдвоенного символа ZZ или YY, для защиты от дублирования имён.

Рис.3

После создания Расширения требуется задать категорию расширения структуры по меню: Дополнительная информация – Категория расширения, Рис.4. Требуется выбрать один из списка вариантов категории расширения структуры для вашего Расширения (дополнения).

Рис.4

При активации созданного Расширения, система не выдаст сообщения об ошибках, если имена дополнительных полей не совпали с уже существующими полями в таблице MARA и выбрана категория расширения для структуры.

Теперь разместим эти поля в целевом ракурсе и определим правила обработки этих полей. Начиная с версии 4.0, в системе имеется специальная программа, которая позволяет сгенерировать шаблон группы функций. Далее эту группу и созданный собственный подэкран мы добавим в нужную последовательность ракурсов для нужного нам вида ОЗМ. Пример как это выполняется, рассмотрен в статье: «Управление визуализацией полей в основной записи материала» http://www.sapland.ru/articles/spj/2012/2/upravlenie-vizualizatsiei-polei-v-osnovnoi-zapisi-materiala.html.

Для создания своей программы по обработке подэкрана с созданными полями используем программу COPYMGD1, и транзакцию SE38, пример на Рис.5.

Рис.5

Выполняем эту программу: если у вас ритейл система, то выберите RETAIL, иначе INDUSTRY, Рис.6.

Рис.6

Система запросит имя группы функций, задайте его, не забывая, что это имя должно начинаться с Z или Y, например так, как  на Рис.7, не забудьте при этом назначит себя ответственным в нижем поле экрана. Затем нажмите «сохранить», система спросит имя пакета и запроса, в который будет включена ваша программа.

Рис.7

После этих действий вы получите сообщение «Группа функций: YMY_MGD1: – создано». Теперь можно посмотреть, что система создала; для этого используем транзакцию SE80 и выберем просмотр «Группы функции», Рис.8.

Рис.8

Теперь перейдем в группу функций системы MGD1 и там найдём подэкран, на который стандартно выводится код материала и краткий текст, длинной 40 символов. Я использовал в качестве примера подэкран «2002 – Основные данные – прочие данные», Рис.9.

Рис. 9

Установите курсор на подэкран с номером 2002 в дереве справа и правой кнопкой вызовите контекстное меню. В меню будет команда «Скопировать», после выбора данного пункта, будет открыто диалоговое окно копирования, Рис.10.

Рис.10

Выбранный подэкран нужно скопировать в нашу, ранее созданную группу функций YMY_MG. Так как группа функций называется YMY_MGD1, то программа будет называться SAPLYMY_MGD1, а номер подэкрана можем задать любой, например 1001, так как нумерация экранов/подэкранов уникальная в рамках группы функций. После копирования, ваша группа функций, будет выглядеть просто страшно, так как копирование подэкрана тянет за собой очень много различного функционала. Пример на Рис.11.

Рис.11

Как видно из Рис.11, в нашу группу функций добавилось очень много различных модулей. Нас же будет интересовать только появившийся подэкран 1001. Копию подэкрана назовем «Длинные тексты материала». Теперь, переходим в режим редактирования экрана и жмем кнопку «Формат». Затем удаляем с экрана все поля, которые попали нам из копии и создаем два поля как на Рис.12.

Внимание! Так как поля были добавлено в таблицу MARA, то имена создаваемых полей экрана должны называться как MARA-ZZ_TXT_ONE и MARA-ZZ_TXT_TWO. Это важно, так как иначе работать ничего не будет.

Кстати, когда вы назовёте поля как в таблице, система предложит вам скопировать определение форматов из словаря, соглашаемся с таким предложением.

Рис.12

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

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

У вас уже есть учетная запись?

Войти

Обсуждения Количество комментариев9

Комментарий от  

Олег Точенюк

  |  19 сентября 2012, 10:17

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

Комментарий от  

Александр Дублин

  |  19 сентября 2012, 15:14

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

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

Комментарий от  

Олег Точенюк

  |  20 сентября 2012, 01:41

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

Да какая там статья, так программа на 300 строк. Из плюсов разве что второй режим работы, который позволяет собрать все активированные или отключенные расширения (экзиты) и увидеть в каких они проектах с датами и логинами кто из сделал и кто последний трогал. Перед миграцией или обновлениями полезная иногда вещь.

Комментарий от  

Сергей Трапезников

  |  04 октября 2012, 09:43

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

Комментарий от  

Олег Точенюк

  |  04 октября 2012, 14:04

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

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

Комментарий от  

Сергей Трапезников

  |  04 октября 2012, 15:37

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

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

Комментарий от  

Олег Точенюк

  |  04 октября 2012, 16:52

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

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

Комментарий от  

Олег Точенюк

  |  05 октября 2012, 09:26

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

Если кратко то 3 нормальные формы по простому:
 
1 НФ - Атомарность данных.
2.НФ - Не ключевые поля в записи зависят только от ключа.
3 НФ - Отсутствие транзитивных зависимостей, т.е. обновление не ключевого поля в одной из таблиц, не должно требовать обновления аналогичного не ключевого поля в другой таблице.

Комментарий от  

Олег Точенюк

  |  06 ноября 2013, 16:43

Небольшая тонкость при копировании экрана группы MGD1 в собственную группу функций, после копирования получили проблему, т.е. зависимые инклуды вроде как не скопировались. На самом деле все скопировалось, просто после копирования, делаете клик мышью на любом из двух инклудов которые есть в группе функций, чтобы справа открылся текст модуля, затем по меню идете: "Утилиты" - "Актуализировать индекс навигации". Ждете пока оно там чего-то актуализирует и после этого получаете картинку из статьи. Похоже какие-то проблемки при копировании экранов в новых версиях системы.