Развитие в экосистеме SAP
Обучение и развитие проектных команд
Станьте участником SAPLAND и получите доступ к самым интересным публикациям SAPPRO
Зарегистрироваться
Обучение и развитие проектных команд
Станьте участником SAPLAND и получите доступ к самым интересным публикациям SAPPRO
Зарегистрироваться
Развитие в экосистеме SAP
Так этож вендор свое оборудование пиарит, а про собственно хану лучше у первоисточника читать.
Традиционно help.sap.com и experiencesaphana.com вам в помощь.
Ну так вместо красивой картинки из которой я вот ничего не понял, но нарисовано красиво, сервера, сервера, протоколы, протоколы как говорится, ты не мудри, ты пальцем покажи где можно прочитать, но только на простых примерах как это работает. Все что я встречал, это вот такого плана буклеты, о том как это круто и как это быстро ну опять же сервера, сервера и между ними шныряют протоколы, обычно TCP/IP и ВСЕ!
Олег, судя по тексту вашего комментария вы совершенно незнакомы с технологией, применяемой в данном продукте, поэтому большинство ваших суждений - ошибочны.
Вся база в памяти не лежит, слой хранения по-прежнему остался.
Революционность, если это слово вообще применимо, в другом подходе к организации хранения данных (поколоночное) и к их обработке в памяти.
Это если кратко.
Извините конечно, а в чем революционность данной технологии? Все загнали в память, добились устойчивости работы оборудования и? Так вы знаете лет 20 или около того, назад когда DOS был маленький, а памяти стало много, ее под RAM-диски стали отдавать и знаете компилировалось там все очень быстро, одна проблема была если это все вдруг зависало, то становилось чуть обидно за прошедшие час или два. А так, ну стало у вас сейчас памяти много, надежность работы выше, поэтому не страшно там базу держать и что? Революционность то в чем? Что-то принципиально новое придумали? Скорость выше? Так в памяти же все держите...
Ну красиво, хотя тоже самое можно сделать и без классов, сделать настроечную таблицу, в которой для ключа банка задавать код ФМ который следует вызывать для обработки. Получаем аналогичную гибкую функциональность... только чуток по проще как мне кажется. Хотя кто на что учился :-)
Очень интересный подход. А исходный код тестовой программы прилагается или по запросу?
Ну красиво, хотя тоже самое можно сделать и без классов, сделать настроечную таблицу, в которой для ключа банка задавать код ФМ который следует вызывать для обработки. Получаем аналогичную гибкую функциональность... только чуток по проще как мне кажется. Хотя кто на что учился :-)
Мне кажется, уместной будет небольшая демонстрация работы данного решения.
В целом различий при первоначальном признании активов по стандартам US GAAP и МСФО не так уж и много. По обоим стандартам учета первоначальная стоимость включает:
В отношении последнего пункта – по US GAAP также с отчетных периодов, начинающихся после 15 июня 2002 года, обязательства по выбытию активов должны быть признаны по справедливой стоимости с соответствующим увеличением балансовой стоимости соответствующего актива.
Есть некоторое различие в признании затрат на исследования и разработки. По стандартам МСФО затраты на исследования всегда признаются текущими затратами. Затраты на разработки, при соответствии следующим условиям, могут быть признаны нематериальными активами:
Компания должна продемонстрировать:
По стандартам US GAAP стоимость приобретенных материалов, оборудования, технических средств и нематериальных активов, которые используются в исследованиях и разработках, капитализируются, только если они имеют альтернативное будущее использование. За исключением затрат на собственные разработки программного обеспечения все остальные затраты на исследования и разработки признаются расходами по мере их возникновения. Затраты, включающие в себя прямые затраты на материалы и услуги, заработная плата и расходы сотрудников, которые непосредственно участвуют в программном проекте, процентные расходы, понесенные на фазе разработки приложений (проектирование, кодирование, монтаж и тестирование), могут быть капитализированы.
Итак, в нашем примере – необходимо отразить стоимость разработки программного обеспечения в размере затрат, понесенных на стадии разработки (по US GAAP), например, 10,000$ и полную стоимость данной разработки по МСФО, например, 15,000$.
Выполняем поступление 10,000$ обычным видом движения на карточку основного средства в классе «Программное обеспечение (Software)» (Рис. 1А).
Рис 1A. Поступление стоимости по 01 области
По области 40 (реальная область оценки по МСФО) отобразится поступление стоимости, аналогичной стоимости отраженной по области 01 (Рис. 2А).
Рис 2A. Поступление стоимости по области 40
По области 50 (производная область разниц) проведено 0$ (разница область 01 10,000 –область 40 10,000).
Проведем дополнительное поступление 5,000$ по области оценки 40 (по МСФО). Используем вид движения Z02 (данный вид движения ограничен только областью оценки 40). По области 50 (производная область по МСФО) отобразится разница стоимости 15,000 – 10,000 = 5,000$. Проводка по первоначальной стоимости по области оценки 50 также выполняется напрямую.
Итак, по счетам Главной книги имеем следующую картину:
По ведущему регистру – Рис. 3А.
По неведущему регистру – Рис. 4А.
Всего по неведущему регистру – стоимость поступления по МСФО – Рис. 5А.
Рис 3A. Проводка первоначальной стоимости по ведущему регистру
Рис 4A. Проводка разницы (область 40 – область 01) первоначальной стоимости по неведущему регистру
Рис 5A. Стоимость поступления по МСФО
По карточке «Программное обеспечение» видим соответствующие стоимости по разным областям оценки. По области 01 – первоначальное поступление 10,000$ (отражено по ведущему и неведущему регистрам), по области 40 (без проводки поступления, формирование базы для последующего расчета амортизации) – 10,000 + 5,000=15,000$, по области 50 – проводка поступления запасов напрямую разницы 15,000 – 10,000=5,000$, причем проводка выполняется только по неведущему регистру (Рис. 6А).
Рис 6A. Стоимость программного обеспечения по US GAAP (01 область) и МСФО (область 40)
Начисление типовой амортизации выполняется по регистрам, в суммах, запланированных по каждой из областей оценки (Рис. 7А).
Рис 7A. Расчет амортизации по областям оценки 01 и 40, по ведущему и неведущему регистрам
При выбытии происходит списание общей части суммы (10,000$) по всем регистрам, по области 50 отражается списание разницы между учетом по US GAAP и МСФО и отражается только по неведущему регистру, и таким образом результат от выбытия основных средств отражается корректно для каждого из учетов.
Гораздо быстрее можно найти используя Debugger Scripting. В случае его использования мы сравниваем значение переменной (структуры) и находим место где оно изменилось (в программе ей присваивается значение структуры - MEPO1222_pbo), далее по стеку выясняем откуда она заполняется. Написав один раз скрипт, мы избавим себя от необходимости анализа большого трейса.
Гораздо быстрее можно найти используя Debugger Scripting. В случае его использования мы сравниваем значение переменной (структуры) и находим место где оно изменилось (в программе ей присваивается значение структуры - MEPO1222_pbo), далее по стеку выясняем откуда она заполняется. Написав один раз скрипт, мы избавим себя от необходимости анализа большого трейса.
Спасибо большое! Очень полезная статья
Применение SAP TDMS представляется наиболее оптимальным в случаях, когда требуется организовать тестовые среды для особо больших баз данных (несколько терабайт и более) и в случае участия в тестировании сторонних подрядных организаций. В обоих случаях TDMS позволяет получить сравнительно небольшие по объемам, консистентные и обезличенные тестовые среды. Отдельным случаем где может с успехом применяться TDMS является применение так называемых библиотек бизнес процессов (включены в стандартную функциональность TDMS). В рамках использования этих библиотек появляется возможность копирования отдельных объектов и связанных с ними документов из продуктивной системы например в систему разработки. Наиболее показательным примеров в данном случае может быть копирования в HR системе персональных данных какого либо работника и связанных с этими данными документов.
Аннотация к комментарию
Используя предложенные в комментарии к статье пошаговые инструкции, вы сможете сэкономить порядка 80% времени при решении задач массового изменения данных, а также сможете создавать унифицированный интерфейс для работы с изменениями любых типов объектов системы конечным пользователем.
Довольно часто возникает необходимость массового изменения данных в SAP ERP. Например, это данные технических мест или данные карточек ОС. Делать обновление данных в таблицах системы «вручную» категорически запрещено, допустимо только изменение данных с использованием стандартных транзакций системы так, чтобы информация об изменениях осталась в журналах обработки и т.д.
Компания SAP предоставляет программные интерфейсы в виде функций BAPI, которые позволяют выполнять изменения объектов путём написания собственной Z-программы массовой обработки данных. Разработка Z-программы такого рода обычно состоит из следующих шагов:
Если теперь перевести эти соображения на язык программы, то скорее всего самой сложной частью работ будет обработка диалога с пользователем, так как шаг 4, при наличии соответствующих BAPI-функций (в крайнем случае, можно использовать пакетный ввод) занимает в среднем около 20% от всей разработки. Используя предложенные ниже инструкции, вы сможете сэкономить порядка 80% времени при решении задач массового изменения данных, также получите унифицированный интерфейс для работы с изменениями любых объектов системы конечным пользователем.
В системе SAP ERP есть хорошая транзакция для выполнения массового изменения данных – MASS, которая позволяет это выполнять такие операции. Описание работы с транзакцией MASS приведено в комментируемой статье.
Когда у меня появилась задача массового изменения карточек ОС (Основных средств), я попытался использовать транзакцию MASS, но обнаружил, что она не работает с типом объекта «Техническое место». В стандартной системе перечень типов объектов, с которыми работает данная транзакция невелик. Стандартный список объектов транзакции MASS, приведен на рисунке MASS-01.png.
Я задался целью расширить список типов объектов, данных которых можно массово изменять с помощью данной транзакции, объектом «Техническое место». В данной статье описывается методика (пошаговое руководство) такого расширения.
Рис 1. MASS-01.png: Стандартный список объектов транзакции MASS
Нужно задать имя бизнес-объекта для объекта «Техническое место». Имя можно добавить любое. Существующие в системе имена типов объектов, используемых в транзакции MASS, можно увидеть через код поиска в таблицах:
После добавления в эти таблицы «вашего типа объекта» он будет отображаться для выбора в транзакции MASS. Для ввода требуемых данных можно воспользоваться ракурсом ведения, транзакция SM30: MASSFUNC, в которой добавим наш новый тип объекта – «Техническое место».
| Примечание |
| Так как для объектов «Техническое место» в системе есть код бизнес-объекта, то воспользуемся существующим именем. Определить имя бизнес объекта, можно используя таблицу TOJTB – Основные данные репозитария бизнес-объектов. Для этого нужно зайти в просмотр данных таблицы и через код поиска значений к полю NAME можно определить, какие есть бизнес-объекты для технических мест. Как видим, в системе существует 4 типа объекта (см. Рис. 2: MASS-02.png), мы возьмём BUS0010, чтобы было похоже на то, что есть в таблицах транзакции MASS. Еще раз напоминаю, что на самом деле никакой связи транзакции MASS с данными бизнес-объектов нет, поэтому будет ли это имя из таблицы TOJTB или же это будет ваше собственное имя, в принципе все равно, но в целом для поддержания общих принципов наименования объектов, правильно будет использовать имена стандартных бизнес-объектов из таблицы TOJTB. |
Рис 2. MASS-02.png: Выбор типа объекта
Добавим в ракурсе ведения MASSFUNC, следующие данные, Рис. 3: MASS-03.png.
Рис 3. MASS-03.png: Добавление данных в в ракурсе ведения MASSFUNC
Имя объекта берем из таблицы TOJTB, указав в комментарии, что это объект массового изменения для технических мест, далее имя функции: Y_TSH_MASS_CHANGE_IFLOT, этой функции еще не существует, это ваше пользовательское имя функции, которую будет вызывать транзакция MASS, для физического изменения технических мест в базе данных. О реализации функции будет рассказано ниже. Пока просто «придумаем» имя, правила наименования пользовательских объектов разработки стандартные, я назвал функциональный модуль, начиная с буквы Y_. Сохраним данные: система запросит имя транспорта для переноса. Создадим запрос, в который будем записывать, как данные настройки, так и программный код, который создадим позже.
Если теперь зайти в транзакцию MASS, то на первом экране в списке выбора появится наш объект ведения данных для технических мест. Правда пока ничего еще не работает, так что, переходить к ведению данных еще рано, хотя если и перейти, то закладки выбора данных будут пустыми. Как видим, объект уже выбирается и транзакция MASS, что-то уже об этом объекте знает, Рис. 4: MASS-04.png.
Рис 4. MASS-04.png: транзакция MASS
Теперь добавим имена таблиц и полей, которые можно будет изменять в транзакции MASS. В общем виде можно указать все таблицы, в которых хранятся данные технических места, например, это таблицы IFLOT, ILOA и другие, а затем перечислить все поля этих таблиц. Однако нужно понимать, что фактически система не даст изменить все поля технического места. Если вы зайдёте в транзакцию изменения технических мест IL02, то сможете определить: какие поля можно менять, а какие закрыты от изменений, (например, код технического места и код балансовой единицы, изменить нельзя).
Мы будем добавлять для возможности использования в транзакции MASS таблицу IFLOT и следующие поля этой таблицы:
MAPAR – Номер детали производителя
IWERK – Завод, планирующий ТОРО
EQART – Вид технического объекта
INVNR – Инвентарный номер
GROES – Величина/размер
BRGEW – Вес брутто
GEWEI – Единица измерения веса
ANSDT – Дата покупки
SERGE – Серийный номер изготовителя
Есть несколько вариантов определения возможности изменения данных транзакцией MASS. Первый вариант: перечислить таблицы и поля в «ручном режиме»; второй вариант: указать «использовать все поля», а затем написать специальный функциональный модуль, который удалит из полного списка те поля, которые нельзя изменять; третий вариант: сделать структуру/ракурс, в который включить только поля, разрешенные для изменения. Какой вариант выбрать? Если предполагается разрешить пользователю для изменения 2 – 5 полей из 59, которые есть в таблице IFLOT, тогда, вероятно, проще выбрать вариант 1 или вариант 3. Если - 50 полей из 59, то вариант 2 будет оптимальным, т.е. даем изменять все поля, и пишем модуль, который исключит из этого списка 9 полей, запрещенных к изменению.
Имена таблиц требуется задать в таблице MASSTAB, а поля, если нужно, в таблице MASSFLDLST. Если выбран вариант ведения 2, то для данной таблицы также есть ракурс ведения. Какие внести данные, можно легко определить: в таблице MASSFLDLST всего три поля. Для нашего примера предпочтителен вариант 3, т.е. необходимо создать ракурс ведения таблицы IFLOT, в который включить только разрешённые к изменениям поля, перечисленные выше. Как было сказано, для задания значений у таблиц существуют ракурсы ведения, с такими же точно именами, как и у таблиц.
Итак, сначала идем в создание ракурса ведения для таблицы IFLOT, транзакция SE11 - создать ракурс. Создаём ракурс YTSH_IFLOTSTRUCT – Ведение технических мест для транзакции MASS - ракурс только для чтения таблицы IFLOT, Рис. 5: MASS-05.png. Кроме полей, предназначенных для изменения в транзакции MASS, в ракурс требуется включить также ключевые поля таблицы IFLOT.
Рис 5. MASS-05.png: ракурс YTSH_IFLOTSTRUCT
Теперь укажем этот ракурс в таблице MASSTAB через транзакцию ведения SM30. Тип объекта укажем BUS0010, который мы выбрали ранее. В поле имя таблицы зададим имя ракурса YTSH_IFLOTSTRUCT. Далее в поле «Число» укажем, например, значение 10. Данное поле служит для упорядочивания списка таблиц: если, например, таблиц/сегментов для обновления больше одной (что в нашем примере неактуально, так как у нас всего одна таблица). В поле «Таб БД» укажем имя таблицы базы данных, из которой фактически будет идти выборка. Для чего требуется указать имя таблицы в колонке «Таб. БД»? Суть заключается в следующем: в поле «Таблица» задаём имя структуры, содержащей только поля, разрешенные для изменения, которые и предложит транзакция MASS для выбора пользователю.
Однако часто ситуация заключается в том, что, например, мы разрешаем изменять поле «Серийный номер», при этом критерием выбора записей для обработки, в которых будет изменяться, является значение поля «Вид технического места», при этом не должно быть разрешено изменять это поле. Мы задали имя основной таблицы базы данных - IFLOT, что служит для транзакции MASS командой предложить пользователю все поля этой таблицы на селекционном экране выбора записей, которые предполагается изменить. Если выборка данных должна выполняться как-то особенно, то в поле «ФМ выбора», нужно задать имя функционального модуля выполняющего выборку данных. В общем случае достаточно стандартных функций выбора данных. И последнее, поле «Без нов. сегментов», в котором поставлена галка, представляет чек-бокса определяющий то, что транзакция MASS позволяет не только изменять данные, но и массово создавать новые данные. В рассматриваемом примере создание новых записей технических мест рассматриваться не будет, по этому мы отключили закладку создания новых технических мест (так как не будем использовать эту функциональность). Пример создания записи, Рис. 6: MASS-06.png.
Рис 6. MASS-06.png: Пример создания записи
Теперь, если перейти в транзакцию MASS, то картина будет более интересной, Рис. 7, MASS-07.png. Как видим, теперь транзакция MASS знает нашу структуру и поля, которые мы хотим разрешить изменять. Кроме этого программа уже умеет искать поля, используя кнопки поиска 
(справа от списка полей). Поиск может идти как по названию, так и техническому имени поля. Конечно, в данном случае, это не очень важно, так как набор полей для изменения ограничен, однако, если полей в списке много, то такая возможность не является лишней.
Рис 7. MASS-07.png: Транзакция MASS
Фактически, в данный момент мы должны выбрать нашу таблицу, она одна в списке и выбрать поля которые хотим изменить: можно выбрать как весь набор полей, так и отдельные поля, например, пусть это будет поле «Планирующий завод» и «Дата покупки». Для выбора выделим эти поля в таблице, нажав кнопки выбора слева от каждого поля, после чего можно нажать кнопку выполнить вверху экрана, Рис. 8: MASS-08.png.
Рис 8. MASS-08.png: транзакция MASS, выбор полей для изменения
Транзакция перейдет к экрану выбора технических мест, которые мы хотим изменить. Фактически, это уже описание работы с транзакцией MASS. По умолчанию, выбор предполагается по ключевым полям, в данном случае – это поле кодов технических мест. Однако транзакция MASS разрешает сделать выбор данных по любым полям, которые есть в таблице IFLOT, так как мы задали именно эту таблицу в настройке выше. Добавим на экран выбора поля: «планирующий завод» и «тип технического места», Рис. 9: MASS-09.png.
Затем укажем – выбрать все технические места, у которых не задан планирующий завод, после чего нажмём F8 – выполнить выбор данных. Система сообщит, сколько записей попадают под указанные критерии и предложит: или перейти к обработке изменений в диалоге, или выполнить фоновое изменение данных, используя создание варианта выполнения. В данный момент мы будем выполнять все операции в диалоговом режиме, поэтому выберем кнопку «Просмотреть все записи». В тестовой системе было выбрано 127 записей без присвоенного планирующего завода.
Рис 9. MASS-09.png: транзакция MASS, выбор полей для изменения
Описание работы с транзакцией MASS выходит за рамки данной статьи, поэтому, что и как можно задавать на экране ввода значений определяйте экспериментальным путем или прочитайте статью, на которую была дана ссылка вначале (возможно, что-то найдется в документации SAP). В примере мы задали «установить завод 1000», а для формирования серийного номера изготовителя задали кодировку на языке ABAP, т.е. фактически там идет генерация GUID-а, после чего нажал кнопку 
– копирования значений в поля и система показала какими значениями, будет выполнено заполнение полей, Рис. 10: MASS-10.png.
Рис 10. MASS-10.png
Как видим, для поля серийного номера изготовителя были сгенерированы уникальные серийные номера. Пример подпрограммы кодировки для генерации внешних серийных номеров для транзакции MASS следующий (система сама генерируют заголовок подпрограммы):
Для обновления данных следует нажать кнопку сохранения результата. Однако пока еще не готова реализация собственно самого функционального модуля Y_TSH_MASS_CHANGE_IFLOT, который выполнит обновление данных на основании заполненных пользователями критериям. Фактически, не более чем за 15-20 минут мы создали диалоговую транзакцию для массового изменения необходимых нам данных с гибким вводом. Реализация, функции изменения данных объекта, будет рассмотрена ниже.
Все сообщения, возникшие в ходе обновления данных, должны быть записаны в журнал обработки данных (далее журнал) и затем транзакция MASS покажет для каждой записи статус обновления или любую другую информацию, которая будет записана в журнал. Поэтому надо настроить наш бизнес-объект на управление журналом. Журнал настраивается с помощью ракурса ведения V_BALSUB – Журнал приложений: ракурс для ведения подобъектов. Для этого через транзакцию SM30 выполним ведение ракурса, появится экран запроса рабочей области, Рис. 11: MASS-11.png.
Рис 11. MASS-11.png: транзакция SM30 – экран запроса рабочей области
Имя рабочей области MASS, как и у транзакции ведения данных, поэтому введем код области и перейдем на следующий экран ведения данных, где добавим новую запись, Рис. 12: MASS-12.png (нужно ввести только имя объекта и текст описания).
Рис 12. MASS-12.png: ввод имени объекта и текста описания
Сохраним значения в запрос, фактически еще одни шаг по настройке транзакции MASS выполнен.
Эта настройка необязательна, но если необходимо, чтобы массовое ведение выглядело как в стандарте, то её лучше сделать. Назначение настройки заключается в том, что она обеспечивает переход из журнала транзакции MASS в просмотр или изменение обрабатываемых объектов (в нашем примере - технических мест). Если данную настройку не сделать, то журнал обработки будет выглядеть следующим образом, Рис. 13: MASS-13.png.
Рис 13. MASS-13.png: вид журнала обработки без настройки
Мы видим на панели инструментов только кнопку просмотра подробного текста к сообщениям об обработке. На рисунке отображён результата попытки присвоить значение поля «завод», равное 1200, для двух объектов. Система не разрешила выполнить такую операцию и сообщила причину.
Перейдём к ведению ракурса MASSAPPEX, в который добавим имена двух функциональных модулей, один для просмотра данных объекта (технического места), а другой для изменения. Как только такие данные будут добавлены, транзакция MASS выведет на панели инструментов две кнопки, для просмотра и изменения объектов из журнала, Рис. 14: MASS-14.png.
Рис 14. MASS-14.png: ведение ракурса MASSAPPEX
В поле CHAR20 имена событий, которые можно выбрать. Имена функциональных модулей, как и в случае с модулем обновления данных, пока только задаем, а их реализация будет описана ниже. Сохраняем данные, если теперь выполнить запуск массового изменения, то в журнале обработки появятся две кнопки, просмотра и изменения обрабатываемых объектов, Рис. 15: MASS-15.png.
Рис 15. MASS-15.png: вид журнала обработки с настройкой
| Примечание |
| Вы не сможете получить журнал обработки до реализации пункта «Реализация функции обновления данных Y_TSH_MASS_CHANGE_IFLOT», т.е. результаты обработки будут видны только после того, как будут написаны объявленные ранее функциональные модули изменения и просмотра объектов. |
Для возможности запуска транзакции MASS в тестовом режиме необходимо добавить событие «TEST_MODE_KNOWN», так как описано в предыдущем разделе, в ракурс ведения MASSAPPEX в имени функционального модуля необходимо указать *, Рис. 16: MASS-16.png. Данное событие, позволит запускать транзакцию массового изменения с признаком тестового режима. Описание параметров будет сделано ниже.
Рис 16. MASS-16.png: настройка тестового запуска
После добавления этого события, если перейти в режим обработки данных транзакции MASS, на экране обновления данных на панели инструментов появится кнопка запуска транзакции в тестовом режиме, Рис. 17: MASS-17.png.
Рис 17. MASS-17.png: режим обработки данных
Если выполнить транзакцию в тестовом режиме, то в журнале появится сообщение, что изменения не сохранены, Рис. 18: MASS-18.png. Необходимо всегда обращать внимание на режим запуска транзакции MASS: тестовый или продуктивный, в функции Y_TSH_MASS_CHANGE_IFLOT, когда будете выполнять ее реализацию.
Рис 18. MASS-18.png: выполнение транзакции в тестовом режиме
Для типов объектов «техническое место», начиная с версии системы 4.6, существует BAPI функция, которая позволяет изменять программно данные технического места: BAPI_FUNCLOC_CHANGE. Если до этого места особого знания языка ABAP не требовалось, то реализация данного пункта невозможна без знаний ABAP, так как функция Y_TSH_MASS_CHANGE_IFLOT будет являться окаймляющей функцией вокруг стандартной BAPI. Параметры этой функции должны быть заданы по определенной маске, так как её вызов происходит динамически транзакций MASS для каждой записи отмеченной в этой транзакции для обработки.
На Рис. 19: FNMASS-01.png представлены входные и выходные параметры функционального модуля Y_TSH_MASS_CHANGE_IFLOT, который надо создать.
Рис 19. FNMASS-01.png: входные и выходные параметры функционального модуля Y_TSH_MASS_CHANGE_IFLOT
| Внимание |
| Обратите внимание на то, что имена параметров и типы должны быть заданы в таком же виде, как показано на Рис. 20: FNMASS-01.png, кроме закладки «Таблицы», правила формирования имен которой, будут описаны отдельно. |
Сам текст функционального модуля, реализующего обновление технических мест, представлен ниже. Обратите внимание на параметры заполнения журнала транзакции MASS, особенно на формирование ключа объекта. В данном случае ключ формируется очень просто, так как это код технического места. Например, если бы это были изменения карточек ОС, то там ключ объекта должен был бы быть как соединение трех полей: <Код БЕ> + <Номер карточки ОС> + <Субномер карточки ОС>, т.е. ключ должен однозначно определять обрабатываемую запись.
Переменная журнала ls_msg-objkey должна содержать ключ обрабатываемого объекта. В дальнейшем, при вызове функций просмотра или изменения этот ключ будет передаваться в заданные вами функциональные модули, чтобы вы смогли перейти к выдранному пользователем объекту. Для просмотра объекта мы объявляли функцию Y_TSH_MASS_VIEW_IFLOT, Рис. 20: FNMASS-02.png
Рис 20. FNMASS-02.png
Сам текст модуля очень простой:
Аналогично выполняется объявление функционального модуля для изменений обрабатываемых объектов Y_TSH_MASS_EDIT_IFLOT, Рис. 21: FNMASS-03.png
Рис 21. FNMASS-03.png
Текст функционального модуля практически такой же, как и при просмотре, отличается только код транзакции:
Итак, фактически за три часа рабочего времени была создана настройка и разработка для массового изменения технических мест, при этом, если нужно добавить какие-то дополнительные поля для обработки, то их просто нужно внести в ракурс ведения YTSH_IFLOTSTRUCT, конечно при условии, что эти переменные находятся только в таблице IFLOT. Функциональный модуль изменения технических мест, написан так, что корректно будет обрабатывать такие добавления.
Управление сложными личностями в проектной группе – тема интересная, актуальная, хотя и довольно амбивалентная.
Практический опыт доказывает справедливость концепции Уильяма Зиска о том, что выбор в пользу стратегии ориентации на профессиональные навыки и уровень квалификации как показатель эффективности и перспективности проекта является достаточно рискованным.
Успех проекта в первую очередь зависит от способности каждого члена проектной группы работать в команде, поэтому на первый план выходит эмоциональное состояние каждого сотрудника – то, что автор называет «эмоциональным интеллектом».
По нашему мнению, данная статья будет чрезвычайно полезна как информационная платформа для начинающих руководителей проектов, как обзор проблем, с которыми неизбежно придется столкнуться на практике. Однако, по нашему убеждению, нужно делать серьезную поправку на менталитет членов команды. Наша многолетняя практика показывает, что применение западных методик воспитания и воздействия на личность малоэффективны в условиях работы в коллективе представителей постсоветского пространства. Исторически так сложилось, что славяне – люди более закрытые: взрослым, сформировавшимся личностям сложнее осознать необходимость качественного преобразования своего характера. Именно поэтому, в целях минимизирования рисков, потенциально угрожающих проекту, мы делаем ставку на подбор команды, состоящей из эмоционально лояльных специалистов в большей степени, чем на перспективу исправления «сложных» личностей.
Безусловно, советы по «перевоспитанию» сотрудников с тяжелым характером стоит пробовать применять на практике, но не нужно рассчитывать на сиюминутный результат. Мы абсолютно убеждены, что единственный способ достичь эмпатии со специалистом, склонным к конфликту, - это способность помочь ему осознать необходимость работы над собой.
Руководитель успешной проектной группы – в первую очередь, тонкий психолог, способный найти правильный подход к каждому члену команды, сформировать конструктивное отношение сотрудников к критике. Управлять командой специалистов – задача сложная, ответственная и, вместе с тем, творческая, т.к. проектная команда – это, в определенной степени, микрокосм, жизнедеятельность которого зависит от сбалансированности внутренних взаимоотношений: они должны быть доверительными, демократичными и в меру дружескими.
Комментарий от
Алексей Селин
| 13 июля 2012, 09:13
Олег Точенюк 12 июля 2012, 22:59
Спасибо конечно... я вот не понимаю как консалт выживает в этом мире, когда есть такой чудесный традиционный сайт help.sap.com/ :-)