В этой статье мы рассмотрим:

• стандартный интерфейс Web Dynpro для документов оценки модуля SAP HCM Performance Management (PM);
• стандартные возможности SAP по изменению текстов.

Глава 1. Стандартный интерфейс Web Dynpro для документов оценки модуля SAP HCM Performance Management

Документы оценки модуля SAP HCM Performance Management (PM) отображаются на портале с помощью одного из следующих интерфейсов: BSP, UI5 и Web Dynpro.

BSP и UI5 предоставляют значительную свободу при построении интерфейса, поскольку разработчик строит интерфейс практически «с нуля» и может определить: взаимное расположение элементов отображения, источники текста, количество символов, выводимых для подписей к элементам и многое другое. Web Dynpro предоставляет меньше свободы, но обладает важным преимуществом – поставляемым SAP набором элементов интерфейса, с помощью которого можно отобразить документ оценки на портале.

В условиях ограниченного бюджета проекта Web Dynpro является идеальным вариантом, поскольку не требуется тратить дополнительные ресурсы проекта на разработку интерфейса с нуля. Тем не менее, стандартный интерфейс WD многих клиентов не устраивает, причём наиболее распространённым требованием клиентов, по праву, является адаптация наименований элементов. Например, наименование Appraisal Document при переводе на русский язык отображается как «Документ аттестации». Документы PM на проектах используются для многих нужд и помимо аттестаций, это может быть оценка по целям, оценка 360, анкеты обратной связи, анкеты для сбора данных интервью с кандидатом и так далее. Поэтому слово «аттестация» зачастую следует переименовать. Список требований по переименованию может быть весьма обширным. Но удовлетворить этим требованиям не всегда просто по причине того, что тексты для портала хранятся в разных местах. Изменения текстов можно добиться путем выполнения действий из следующего списка процедур:

• настройки в основных транзакциях настройки процесса оценки;
• перевод кратких статичных текстов Object Text Repository (OTR);
• корректировка сообщений, которые ведутся через транзакцию SE91;
• изменение подробных текстов;
• перевод текстов элементов данных;
• перевод текстовых элементов групп функций.

Этот список не претендует на полноту, но это – те области, с которыми «сталкивался» автор статьи. Помимо перечисленных процедур, о которых подробно речь пойдет ниже, наименования также хранятся в портальных компонентах iView или Page, а также в панелях запуска LPD_CUST. Коротко скажу об этих компонентах и панелях.

iView и Page

Когда мы нажимаем на ссылку для документа оценки в списке документов ESS или MSS, то открывается всплывающее окно. У данного окна есть наименование. Это наименование является названием iView или Page. Проверить и изменить наименования можно при наличии портальной роли Content Administration.

LPD_CUST

Наименования окон на портале также могут настраиваться с помощью транзакции LPD_CUST. Например, если заголовок окна значится как Mitarbeiterdokument («документ оценки» по нем.), то изменить его перевод на русский язык можно с помощью этой транзакции. Настройки, отвечающие за документ оценки гибкого процесса (Flexible), хранятся в инстанции HAP_GENERIC_UI роли HAP, а за документ оценки предопределенного процесса (Predefined) – в инстанции PMP роли HAP.

А теперь рассмотрим стандартные подходы к работе для каждой из процедур, вышеприведенного перечня. Стандартные возможности SAP освещены в соответствующих разделах Главы 2.

Глава 2. Стандартные возможности SAP по изменению текстов

1.     Настройки в основных транзакциях настройки процесса оценки

Начнём с основных транзакций, в которых выполняется настройка процесса и элементов оценки.

1.1.   Транзакция PHAP_CATALOG

Транзакция PHAP_CATALOG – это центральная транзакция для настройки формуляров, на основе которых создаются документы оценки. В этой транзакции мы можем настроить весьма ограниченный набор текстов, поэтому давайте перечислим все возможности:

• На уровне категории формуляра (что можно выполнить также с помощью транзакции OOHAP_CATEGORY, см. Рисунок 1):
  • Наименования участников процесса оценки (на какие слова заменить стандартные термины «Оценивающий», «Аттестуемый», «Проводящий отдельную аттестацию» и «Другие участники»).
  • Наименование периода действия для документов.

Рисунок 1. Настройка текстов на уровне категории формуляра

• На уровне формуляра, группы критериев и критериев:
• Описание элементов.
• Описание значений (см. Рисунок 2) – можно изменить описание каждого уровня шкалы, используемой для элемента, но, если честно, ни разу не видел использование этой настройки на проектах. Проще создать новую шкалу через транзакцию OOHAP_VALUE_TYPE или OOSC. Хотя не исключено, что у нас может быть одна общая шкала (например, ABCDE), а в разных случаях описания для шкалы будут разные.

Рисунок 2. Изменение описаний значений шкалы

Остановимся чуть подробнее на вводе описания элементов. Описания можно вести в двух форматах: стандарт и веб-формат. Если наши пользователи будут вести документы оценки только в бэкэнде (SAP GUI), то про веб-формат можно забыть. Текст, введенный в формате «стандарт» (см. Рисунок 3), будет отображаться в документе по нажатию на любой элемент структуры (формуляр, группу критериев или критерий, см. Рисунок 4). В этом формате никак нельзя повлиять на форматирование, правда переносы на другую строку обрабатываются, но опять же только для бэкэнда.

Рисунок 3. Описание в формате «Стандарт»

Рисунок 4. Отображение описания в бэкэнде

При отображении документа оценки на портале (см. Рисунок 6) описание «веб-формата» будет иметь более высокий приоритет. Описание в формате «стандарт» на портале будет отображаться только если в «веб-формате» нет текста. Также нельзя забывать, что переносы на другую строку не поддерживаются, поэтому весь текст будет в одном абзаце. «Веб-формат» позволяет форматировать текст с помощью HTML-тегов (см. Рисунок 5), однако: во-первых, их набор тоже ограничен, а во-вторых, здесь все теги должны быть парными, что свойственно скорее XML, чем HTML. Мы имеем в распоряжении только следующие теги:

• <h1>, <h2>, <h3>, <h4> – теги заголовков, и, да, заголовков 5-го и 6-го уровней нет;
• <br> – перенос на другую строку;
• <strong> – полужирный текст;
• <em> – курсив;
• <ul> – маркированный список;
• <ol> – нумерованный список;
• <li> – каждый пункт маркированного или нумерованного списка;
• <div>.

Рисунок 5. Описание в «Веб-формате»

Рисунок 6. Отображение описание в «Веб-формате» на портале

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

• Транзакция OOHAP_CATEGORY – если настройки текстов для категории выполнены в транзакции PHAP_CATALOG, то автоматически в запрос они не складываются, поэтому мы можем пойти в транзакцию OOHAP_CATEGORY и сложить настройки принудительно. Для этого необходимо выделить нужную нам строку, затем выполняем команду «Ракурс таблицы –> Перенос», выбираем запрос, нажимаем на кнопку «Включить в запрос» и затем нажимаем на кнопку «Сохранить».
• Отчет RHMOVE30 – с помощью данного отчета мы можем сложить в запрос объекты организационного менеджмента, в том числе объекты VA, VB, VC и VH. Соответственно, этот инструмент нам подойдет, если мы выполнили настройки в одном или нескольких объектах формуляра или конфигурации процесса, и мы хотим перенести только эти измененные объекты, но не весь формуляр.
• Транзакция PHAP_TRANSPORT – универсальная транзакция для комплексного переноса настроек формуляра, конфигурации формата, процесса, кроме того можно включить настройки категории.

1.2.   Транзакция OOHAP_BASIC

Транзакция OOHAP_BASIC – это важная транзакция для настройки вспомогательных компонентов процесса оценки (см. Рисунок 7). Это кластер настроечных ракурсов и почти на каждом можно указывать наименования. Среди этих наименований для интерфейса пользователя имеют значения следующие:

• Столбцы – наименования отображаются всегда,